From nobody Mon Jan 4 10:23:52 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F37D1A906C; Mon, 4 Jan 2016 10:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLyicD-IewHW; Mon, 4 Jan 2016 10:23:45 -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 BD0FB1A9078; Mon, 4 Jan 2016 10:23:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1786; q=dns/txt; s=iport; t=1451931822; x=1453141422; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=kiKH1zDA9LpzBqdaTYIrz7QfhqeCjkxU3mqonV6fTQI=; b=F+5ZB2KpYD3tm4L0vNLfdSutb3jZ9YcrdfsSAVXo7rSUs4f40lsgvflB Npl/TpbqO6sNgigTwgnC9YFCBPU/W5O9Lv5Bt474o5tPKrRxPCWNBfAHW bA0JYD9UZQu+dVdDrzV3sTcsgh3u1/6gtN/3x930wczfzZjHYJ8KSifx8 k=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoBAAHuIpW/xbLJq1ejVK1aIYPAoFoA?= =?us-ascii?q?QEBAQEBgQuENQEBAwEjVQYLCw4TFgQHAgIJAwIBAgFFBgEMCAEBiCMIsDaRBwE?= =?us-ascii?q?BAQEBAQEDAQEBAQEBARMJi1WHc4FJAQSNOYlNgnKBZIh7gVyHS4VUikeDc2SCE?= =?us-ascii?q?RwdgUE9hUQBAQE?= X-IronPort-AV: E=Sophos;i="5.20,521,1444694400"; d="asc'?scan'208";a="623228149" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jan 2016 18:23:39 +0000 Received: from [10.61.163.217] ([10.61.163.217]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u04INdSe012346; Mon, 4 Jan 2016 18:23:39 GMT To: Dean Bogdanovic , Nadeau Thomas , Benoit Claise , RTG YANG Design Team , netmod WG References: <20151211113156.GA43862@elstar.local> <2059AD77-5375-4DB0-A1BF-432835F11A9F@gmail.com> <20151221153312.GA43316@elstar.local> From: Eliot Lear X-Enigmail-Draft-Status: N1110 Message-ID: <568AB8AA.8070404@cisco.com> Date: Mon, 4 Jan 2016 19:23:38 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20151221153312.GA43316@elstar.local> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qKnrsOgws9iBGRMmWNM1uPTD2qSpEKdAn" Archived-At: Subject: Re: [netmod] [Rtg-dt-yang-arch] [yang-doctors] Working group Last Call: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 18:23:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qKnrsOgws9iBGRMmWNM1uPTD2qSpEKdAn Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Juergen, On this point: On 12/21/15 4:33 PM, Juergen Schoenwaelder wrote: > And > should the interface reference not use a more specific type than > 'string=E2=80=99? >> Interface references can be many things, from standard naming we are f= amiliar, e.g. ge-1/0/0.1 to a numerical value like 13276. Leaving it as s= tring gives us most flexibility in that regards. > I disagree that the goal here is most flexibility. We do have an > interfaces data model in the IETF. Why are we avoiding to refer to it > here? > I think it would be helpful if you could be specific as to your concern. It is absolutely the case that the SNMP folk did an awful lot of work on managing interfaces. While I am not concerned about the form of the name, I wonder if your concern is around some of the semantics, but I can't tell. Eliot --qKnrsOgws9iBGRMmWNM1uPTD2qSpEKdAn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJWirirAAoJEIe2a0bZ0nozX88IAJr2jmXvFkVzZdodQ9819h7l PJf5Eaaj5bPYhDRTEBOvaS7gEI1G9Cz9E1YI0bRpO8mJcmuty+HY0cM1/lAXz5Xi IXV3PWIvUeE4cxrvHvzxs/4iYLGOhmWLPWGAZF3gxpvh0ISeTIEck33UhrsWzT96 x1Dhi3TylZCIUC3VaxnC40QkoldwAnTaw5jdf8P4Fpf8z9trO3wTqLv+S+Q27LrS n9ucQUT5slOutxTRRbOn3Suvr0vSy6OecNDb+pcXG+vzwRMkrtzIQo3KoWEktNv7 r4cbcja9zkbNxtAXoQepJw8YpOr76BB8+ytQrD2r55Sfsmq7rpYfIl6YpJMBjO4= =hhc6 -----END PGP SIGNATURE----- --qKnrsOgws9iBGRMmWNM1uPTD2qSpEKdAn-- From nobody Mon Jan 4 10:45:08 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E1B1A1A1E for ; Mon, 4 Jan 2016 10:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ceE5QhZIFlx for ; Mon, 4 Jan 2016 10:45:06 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::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 CF6661A1A14 for ; Mon, 4 Jan 2016 10:45:05 -0800 (PST) Received: by mail-lb0-x230.google.com with SMTP id oh2so163278262lbb.3 for ; Mon, 04 Jan 2016 10:45: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:date:message-id:subject:from:to :cc:content-type; bh=4kaIbJnUcEEfS2gMt0K/mR0L0sfXGiSGO/DDqRe8hWs=; b=uE8V8DaOtj91LggF6Wt+ypIW30TqH3ZW9a2CxLQo6a4I3trluoFploF3qvZ7wt0nAv bLe29IFR/jzm2djdimAF3TMk8QLuTjga/18gQf95m6telSij+oj+EO6HhawDFYhhTv2W HCLAwUMrVfjT1bCOZCE/3IPfpLSKduKKYIhi1Xp0G7Zcv+WgZ9MXGjAB6DIQYOkmUPQ3 rP1M3IP/B+sgcjJJSZqbz1Cpju8BUb9GOv1ZGw21JPXgtbIvob0LWZb21djCI1ofQlL/ LWKtVnanheNizepXUlBqRepSVpRS8oT020lr5PB/KfSUxAU04ZkjJkrYcbNzWW/rHI8u c5/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4kaIbJnUcEEfS2gMt0K/mR0L0sfXGiSGO/DDqRe8hWs=; b=LrDNJ52Ot2XZRZN8v1fyOiaCT+Czf/rRBvbkgGoGncBfyn673wCtq7HUoatdCKWybr azcjWFzoYnJihn5sXBZMHoa6BngIUoypdG6PuSUE5ObwKxaPrP2U2wFlUqd/H7wG5rV0 aBj+sngD//kwnyBiofBJ/gXyada2M9fMSqQ1hcM6tgO2yx01BUvrTFsCZxWNMYHpahj9 7aQjBj+JEZdED0uzi/KuGDolTOA4u0WJ9/sjRJ01+Kg39VuuZhoSzE5ZqTmCYbWZeTG0 P/1fz7bz8t0zlpUU+sRJeCnfYcNDj+il+TXLYHrOC4QEqXTsOQkw1mvta+56YbT5cLBx CbZA== X-Gm-Message-State: ALoCoQlicQVqo3jOgnQlLCpe9CAWHxtNmGBOfns+dSCkJhCTlTfRl+7PAGxI9Ezzpy/GjJlM5xaZokgHXF5uXhlthjyoeC38WQ== MIME-Version: 1.0 X-Received: by 10.112.78.2 with SMTP id x2mr20783086lbw.65.1451933104010; Mon, 04 Jan 2016 10:45:04 -0800 (PST) Received: by 10.112.144.36 with HTTP; Mon, 4 Jan 2016 10:45:03 -0800 (PST) In-Reply-To: <568AB8AA.8070404@cisco.com> References: <20151211113156.GA43862@elstar.local> <2059AD77-5375-4DB0-A1BF-432835F11A9F@gmail.com> <20151221153312.GA43316@elstar.local> <568AB8AA.8070404@cisco.com> Date: Mon, 4 Jan 2016 10:45:03 -0800 Message-ID: From: Andy Bierman To: Eliot Lear Content-Type: multipart/alternative; boundary=001a11c3bf72e744280528868456 Archived-At: Cc: Benoit Claise , RTG YANG Design Team , netmod WG Subject: Re: [netmod] [yang-doctors] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 18:45:07 -0000 --001a11c3bf72e744280528868456 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I think this issue was discussed at length during ietf-interfaces work. The WG gave up on the ideal goal that an NMS can pick the interface name as if it were just another administrative string. Instead, every vendor can have their own rules for embedded semantics in the identifier. Every server can reject perfectly valid interface names because they are the "wrong" value for that specific port (where the "right" value is up to the NMS to know because it is out of scope for the standard). It may take another decade to get rid of all the bad decisions CLI has given to network management. Andy On Mon, Jan 4, 2016 at 10:23 AM, Eliot Lear wrote: > Hi Juergen, > > On this point: > > On 12/21/15 4:33 PM, Juergen Schoenwaelder wrote: > > > And > > should the interface reference not use a more specific type than > > 'string=E2=80=99? > >> Interface references can be many things, from standard naming we are > familiar, e.g. ge-1/0/0.1 to a numerical value like 13276. Leaving it as > string gives us most flexibility in that regards. > > I disagree that the goal here is most flexibility. We do have an > > interfaces data model in the IETF. Why are we avoiding to refer to it > > here? > > > > I think it would be helpful if you could be specific as to your > concern. It is absolutely the case that the SNMP folk did an awful lot > of work on managing interfaces. While I am not concerned about the form > of the name, I wonder if your concern is around some of the semantics, > but I can't tell. > > Eliot > > > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors > > --001a11c3bf72e744280528868456 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I think this issue was discussed at= length during ietf-interfaces work.
The WG gave up on the ideal = goal that an NMS can pick the interface name
as if it were just a= nother administrative string.=C2=A0 Instead, every vendor can have
their own rules for embedded semantics in the identifier.=C2=A0 Every ser= ver can
reject perfectly valid interface names because they are t= he "wrong" value
for that specific port (where the &quo= t;right" value is up to the NMS to know
because it is out of= scope for the standard).

It may take another deca= de to get rid of all the bad decisions CLI
has given to network m= anagement.


Andy




On Mon, Jan 4, 2016 at 10:23 AM, Eliot Lear <lear@cisco= .com> wrote:
Hi Juergen,
On this point:

On 12/21/15 4:33 PM, Juergen Schoenwaelder wrote:

> And
>=C2=A0 should the interface reference not use a more specific type than=
>=C2=A0 'string=E2=80=99?
>> Interface references can be many things, from standard naming we a= re familiar, e.g. ge-1/0/0.1 to a numerical value like 13276. Leaving it as= string gives us most flexibility in that regards.
> I disagree that the goal here is most flexibility. We do have an
> interfaces data model in the IETF. Why are we avoiding to refer to it<= br> > here?
>

I think it would be helpful if you could be specific as to your
concern.=C2=A0 It is absolutely the case that the SNMP folk did an awful lo= t
of work on managing interfaces.=C2=A0 While I am not concerned about the fo= rm
of the name, I wonder if your concern is around some of the semantics,
but I can't tell.

Eliot



_______________________________________________
yang-doctors mailing list
yang-doctors@ietf.org
https://www.ietf.org/mailman/listinfo/yang-doctors=


--001a11c3bf72e744280528868456-- From nobody Mon Jan 4 11:02:02 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875441A871E; Mon, 4 Jan 2016 11:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.258 X-Spam-Level: X-Spam-Status: No, score=-96.258 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YUk-ZUcY0aW; Mon, 4 Jan 2016 11:01:51 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 9FC411A870B; Mon, 4 Jan 2016 11:01:43 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.177; From: "Susan Hares" To: , , References: <20160104170330.13929.73845.idtracker@ietfa.amsl.com> In-Reply-To: <20160104170330.13929.73845.idtracker@ietfa.amsl.com> Date: Mon, 4 Jan 2016 14:01:55 -0500 Message-ID: <006701d14722$616c6950$24453bf0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQHC7aVhYcGa1ChTuo//84M/O+4YZ58IZpiA X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [netmod] FW: New Version Notification for draft-hares-i2rs-bnp-eca-data-model-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 19:01:53 -0000 This model provides a Event-Condition-Action (ECA) policy model. The I2RS FB-RIB yang data model utilizes this model, but to my knowledge = the=20 Netmod or netconf has not adopted an ECA policy model to parallel the ACL model.=20 Chen and co-authors have created the model: =20 draft-chen-supa-eca-data-model-05.txt=20 But it does not align with this yang model or seem sufficient to support the FB-RIB information model. At IETF 94, I presented a discussion of the issues I found with the=20 draft-chen-supa-eca-data-model-05.txt, but it has not been updated. We would appreciate feedback on this version of yang model.=20 =20 In my role as I2RS chair, I2RS needs to make progress soon on the I2RS FB-RIB data model. We would appreciate your aid.=20 =20 Sue=20 -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Monday, January 04, 2016 12:04 PM To: Susan Hares; Qin Wu; Russ White Subject: New Version Notification for = draft-hares-i2rs-bnp-eca-data-model-03.txt A new version of I-D, draft-hares-i2rs-bnp-eca-data-model-03.txt has been successfully submitted by Susan Hares and posted to the IETF = repository. Name: draft-hares-i2rs-bnp-eca-data-model Revision: 03 Title: An Information Model for Basic Network Policy and Filter Rules Document date: 2016-01-04 Group: Individual Submission Pages: 30 URL: = https://www.ietf.org/internet-drafts/draft-hares-i2rs-bnp-eca-data-model-= 03.txt Status: = https://datatracker.ietf.org/doc/draft-hares-i2rs-bnp-eca-data-model/ Htmlized: = https://tools.ietf.org/html/draft-hares-i2rs-bnp-eca-data-model-03 Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-hares-i2rs-bnp-eca-data-model-0= 3 Abstract: This document contains the Basic Network Policy and Filters (BNP IM) Data Model which provides a policy model that support an ordered list of match-condition-action (aka event-condition-action (ECA)) for multiple layers (interface, L1-L4, application) and other factors (size of packet, time of day). The actions allow for setting actions (QOS and other), decapsulation, encapsulation, plus forwarding actions. The policy model can be used with the I2RS filter-based RIB. = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. The IETF Secretariat From nobody Mon Jan 4 12:54:33 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54CA91A92ED; Mon, 4 Jan 2016 12:54:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mnr-lj5RyE6I; Mon, 4 Jan 2016 12:54:30 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8C401A92EB; Mon, 4 Jan 2016 12:54:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id B163125DBA5; Mon, 4 Jan 2016 12:54:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1451940869; bh=oIotwmIeXlL58bL7VXd3wMLgBte+TzwkWvuGYhtdwy8=; h=Subject:To:References:From:Date:In-Reply-To:From; b=JAdQeC/zqPBOmOaGOJcw8xOlWsUp1kpT7BQ8Je5rhbNPEw4y7JYWa35+a7BwszPuq MNXUoOnhFxBU1E8PFtMKXwHtB0WfB1B6oJdNXqcL/roocpE/j0OqiQyt93R7IM9zP/ jATSNv0f/C9fRhTmLIbs+IvH1PiRL7EbtCvRu3GI= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 1B904240FDE; Mon, 4 Jan 2016 12:54:28 -0800 (PST) To: Susan Hares , i2rs@ietf.org, netmod@ietf.org, supa@ietf.org References: <20160104170330.13929.73845.idtracker@ietfa.amsl.com> <006701d14722$616c6950$24453bf0$@ndzh.com> From: "Joel M. Halpern" Message-ID: <568ADBE7.3030101@joelhalpern.com> Date: Mon, 4 Jan 2016 15:53:59 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <006701d14722$616c6950$24453bf0$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] [i2rs] FW: New Version Notification for draft-hares-i2rs-bnp-eca-data-model-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 20:54:32 -0000 I think there are two issues here. 1) It is not clear to me why there is any dependence of the fb-rib data model on an eca data model. While supa does allow for policy model to be sent directly to the router, it also allows many other cases. 2) The approach with the supa eca data model is still under development. Having said that, the material in there is intended to be very general. From what I understand, there should be no difficulty in refining the action side of that model to actions which affect the fb-rib in ways that are consistent with the fb-dib data model. Yours, Joel On 1/4/16 2:01 PM, Susan Hares wrote: > This model provides a Event-Condition-Action (ECA) policy model. > The I2RS FB-RIB yang data model utilizes this model, but to my knowledge the > Netmod or netconf has not adopted an ECA policy model to > parallel the ACL model. > > Chen and co-authors have created the model: > > draft-chen-supa-eca-data-model-05.txt > > But it does not align with this yang model or seem sufficient to > support the FB-RIB information model. At IETF 94, > I presented a discussion of the issues I found with the > draft-chen-supa-eca-data-model-05.txt, but it has not been updated. > We would appreciate feedback on this version of yang model. > > > In my role as I2RS chair, I2RS needs to make progress soon on the > I2RS FB-RIB data model. We would appreciate your aid. > > > Sue > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, January 04, 2016 12:04 PM > To: Susan Hares; Qin Wu; Russ White > Subject: New Version Notification for draft-hares-i2rs-bnp-eca-data-model-03.txt > > > A new version of I-D, draft-hares-i2rs-bnp-eca-data-model-03.txt > has been successfully submitted by Susan Hares and posted to the IETF repository. > > Name: draft-hares-i2rs-bnp-eca-data-model > Revision: 03 > Title: An Information Model for Basic Network Policy and Filter Rules > Document date: 2016-01-04 > Group: Individual Submission > Pages: 30 > URL: https://www.ietf.org/internet-drafts/draft-hares-i2rs-bnp-eca-data-model-03.txt > Status: https://datatracker.ietf.org/doc/draft-hares-i2rs-bnp-eca-data-model/ > Htmlized: https://tools.ietf.org/html/draft-hares-i2rs-bnp-eca-data-model-03 > Diff: https://www.ietf.org/rfcdiff?url2=draft-hares-i2rs-bnp-eca-data-model-03 > > Abstract: > This document contains the Basic Network Policy and Filters (BNP IM) > Data Model which provides a policy model that support an ordered list > of match-condition-action (aka event-condition-action (ECA)) for > multiple layers (interface, L1-L4, application) and other factors > (size of packet, time of day). The actions allow for setting actions > (QOS and other), decapsulation, encapsulation, plus forwarding > actions. The policy model can be used with the I2RS filter-based > RIB. > > > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Mon Jan 4 13:24:49 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC481AC3B0; Mon, 4 Jan 2016 13:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3lyHgxVA4Bm; Mon, 4 Jan 2016 13:24:43 -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 E7AB11AC3A1; Mon, 4 Jan 2016 13:24:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3970; q=dns/txt; s=iport; t=1451942683; x=1453152283; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=4EZarxlBHNzg8yLjBWHIraI/kZQZ+2DGuMydUJDK2WQ=; b=kyhoS+ljk+RAcDPsFCVTMXlaWTMADq+eotay4XjdyEKs70HrkjGl79ui lRAeFuLrpSzkEPMPU0xFY5wtpQG0Zt+vlLmd5zyqcD+wiyvj1e7TjKEtf tB0TWjYpPUmplhqENgDZ5deKouUGedCRyuXHUQ132E9SynKVA2ul4hmsl s=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B9AgDR4YpW/xbLJq1ehAxtiFmzdw6BZ?= =?us-ascii?q?BgKhSNKAoFVFAEBAQEBAQGBCoQ0AQEBBAEBASBLCgEMBAsOAwQBAQEJFggDAgI?= =?us-ascii?q?JAwIBAgEVHwkIBg0GAgEBiCsOsEORHwEBAQEBAQEBAQEBAQEBAQEBAQEBAQ8FB?= =?us-ascii?q?ItVh3OBSQWNOYlNgnKBZIh7iSeFVI46IAFDgkqBQT00hRABAQE?= X-IronPort-AV: E=Sophos;i="5.20,522,1444694400"; d="asc'?scan'208";a="648251012" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jan 2016 21:24:39 +0000 Received: from [10.61.163.217] ([10.61.163.217]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u04LOcJ5021242; Mon, 4 Jan 2016 21:24:38 GMT To: Dean Bogdanovic , "Sterne, Jason (Jason)" References: <5672BAD7.2080003@cisco.com> <1B2DACE1-A8F0-493B-8B61-EF6321790ECE@lucidvision.com> <5672CA38.4060709@cisco.com> <4A6F06C5-7198-4FCA-A10C-0377F595D704@gmail.com> From: Eliot Lear Message-ID: <568AE314.4080401@cisco.com> Date: Mon, 4 Jan 2016 22:24:36 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <4A6F06C5-7198-4FCA-A10C-0377F595D704@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MdQTKN6KGc7Os5ojdIndUTI8c6J7dHwH7" Archived-At: Cc: RTG YANG Design Team , netmod WG , Benoit Claise Subject: Re: [netmod] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 21:24:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MdQTKN6KGc7Os5ojdIndUTI8c6J7dHwH7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I guess what I'm hearing is that we should do a hopefully very short augmentation for domain names in the matches clause and standardize that separately. Does that seem reasonable? Eliot On 12/19/15 2:05 PM, Dean Bogdanovic wrote: > The basic design idea for the base model is structure that all vendors = support. Some of the examples mentioned below, like FQDN, are not support= ed by all vendors and are protected by IPR (which I wasn=E2=80=99t aware = of it). There are many possible match conditions that could be added to t= he base model, like Auth header in IPSec or IPSec encapsulation security = payload to keep it with security. There are many match conditions in Clas= s of Services as well. All these match conditions would have created more= issues to come to consensus about the base model, so for that reason we = went with the minimal model that would be easy for all vendors to impleme= nt. > > Dean > >> On Dec 18, 2015, at 5:21 PM, Sterne, Jason (Jason) wrote: >> >> I'm not a fan of adding something like that in the base model. Let's = get a basic model done and then we can consider an extension draft. I'd = think that things like TCP flags, for example, would be a more natural & = common thing to add to an ACL model than a host name match so I can't see= host name being in there before TCP flags (which I'm not advocating for = in the base model). >> >> I also don't think the metadata interface match should be in this base= model either. That is out of place IMO. The base model provides an ACL= that can then get associated with objects like interfaces (as in the exa= mple in section A.3) >> I'd also suggest we consider making the actions 'deny' and 'permit' pr= esence containers instead of empty leafs. That would allow easier augmen= tations (e.g. additional 'permit' parameters for policy based forwarding = for example). >> >> Regards, >> Jason >> >> -----Original Message----- >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Nadeau Thom= as >> Sent: Thursday, December 17, 2015 10:53 >> To: Lear Eliot >> Cc: Benoit Claise; RTG YANG Design Team; netmod WG >> Subject: Re: [netmod] Working group Last Call: draft-ietf-netmod-acl-m= odel-06 >> >> >> You raise a good point. Do the contributors/editors have any thoughts= on this suggestion? >> >> =E2=80=94Tom >> >> >>> On Dec 17, 2015:9:44 AM, at 9:44 AM, Eliot Lear wrot= e: >>> >>> >>> >>> On 12/17/15 2:45 PM, Nadeau Thomas wrote: >>>> Do you mean an ASCII DNS name (versus an IP address w a mask)? >>> I was thinking of "host" in RFC 6021. >>> >>> Eliot >>> >>> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> _______________________________________________ >> Rtg-dt-yang-arch mailing list >> Rtg-dt-yang-arch@ietf.org >> https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch > --MdQTKN6KGc7Os5ojdIndUTI8c6J7dHwH7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJWiuMVAAoJEIe2a0bZ0nozJmgH/1uH2lR80/HaxTsBVdYrw38M iIUSqGoRVvyrEnnBjjjlDhLZQ0IHP8DQ5Uq13OkX/e5n/tjaoYDCdONPa631OSS/ RxugY5L+jgB/T2YwjpgKHPGZvqSMRdJis7x+7l/GVyap71eENkKiftgk9KetZqBN bfpiDX07tFpLRNsGqwZ4GeZLMli/ji+ZyMwCaIe0LpKQM74an4h4lolt2D50N2Ro I9Fr95RIEE5uHTMLkpiUqLrvUobjvVHw3jqA3EuIQQY+mjG+j+ecgV37VRaOtGjd YJCqESAT+X39+MZc41dSzugMfg0m6HS41TTMlQEtp60lKqkqOQ+OrqCVr3246fA= =prkb -----END PGP SIGNATURE----- --MdQTKN6KGc7Os5ojdIndUTI8c6J7dHwH7-- From nobody Mon Jan 4 14:17:01 2016 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6BF1AC424; Mon, 4 Jan 2016 14:17:00 -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.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160104221700.28629.34622.idtracker@ietfa.amsl.com> Date: Mon, 04 Jan 2016 14:17:00 -0800 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 22:17:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : Terminology and Requirements for Enhanced Operational State Visibility and Control Authors : Kent Watsen Thomas Nadeau Filename : draft-ietf-netmod-opstate-reqs-02.txt Pages : 6 Date : 2016-01-04 Abstract: This document discusses the difference between intended configuration and applied configuration of a device and how intended and applied configuration relate to the operational state of a device. The document defines the necessary terminology and identifies requirements enabling visibility into the difference of intended configuration and applied configuration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-opstate-reqs-02 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 Mon Jan 4 14:30:22 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1CC81AC427 for ; Mon, 4 Jan 2016 14:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pI5tC1FbgPyX for ; Mon, 4 Jan 2016 14:30:17 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0733.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26AFC1AC425 for ; Mon, 4 Jan 2016 14:30:16 -0800 (PST) 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 (TLS) id 15.1.361.13; Mon, 4 Jan 2016 22:29:54 +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.0361.006; Mon, 4 Jan 2016 22:29:54 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt Thread-Index: AQHRRz2lEErWj+iSeUCXhpFM5+aasZ7rnI4A Date: Mon, 4 Jan 2016 22:29:54 +0000 Message-ID: <8A6CD12B-8B34-4F7B-83F2-E56361F998AA@juniper.net> References: <20160104221700.28629.34622.idtracker@ietfa.amsl.com> In-Reply-To: <20160104221700.28629.34622.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151105 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.12] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 5:/B1ec0rWeHrxFb0JJ5op+sKQ3ABJRdESmZwLzol32WSktCaEXfiCHfXFYFyfU7MmuNfDaR/k/ni1nXMHLQQyXu/+SQmx9v5k5gaUaaZXggeEnJHxem6bai5+OtyuWjyL0uOnUHxsTgVy0b8CmB4mYg==; 24:HJpqfmxOMBrtOB76eR44GsI7nW5GlbyVIXZnKVMRFjHH4ofMahl8kOTCSucV/auO+Mw6pAsN8pgBrWuVO1J3DZTad4CXC2NmFt1H9dlCJRg= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 08118EFC2B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(377424004)(199003)(24454002)(377454003)(189002)(87936001)(40100003)(101416001)(5004730100002)(105586002)(99286002)(83716003)(122556002)(11100500001)(450100001)(36756003)(106116001)(230783001)(110136002)(19580395003)(2501003)(4001350100001)(3846002)(97736004)(1730700002)(2351001)(76176999)(54356999)(5002640100001)(189998001)(33656002)(106356001)(2950100001)(19580405001)(107886002)(86362001)(586003)(1096002)(2900100001)(66066001)(5001960100002)(5008740100001)(10400500002)(81156007)(92566002)(6116002)(77096005)(50986999)(1220700001)(102836003)(83506001)(82746002)(15975445007)(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:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <83C953A5648D0048B10D57B6F701EA18@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2016 22:29:54.0322 (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: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 22:30:22 -0000 DQpUaGlzIHVwZGF0ZSBhZGRyZXNzZXMgY29tbWVudHMgcmVjZWl2ZWQgZHVyaW5nIHRoZSBMYXN0 IENhbGwuDQoNCldhcm5pbmchICAtIHRoZSBEaWZmMSBhbmQgRGlmZjIgb3V0cHV0cyBzb21laG93 IG1hbmdsZSB0aGUgQXBwbGllZCBDb25maWd1cmF0aW9uIHRlcm0uICBQbGVhc2UgbG9vayBhdCB0 aGUgZHJhZnQgaXRzZWxmIGZvciB0aGUgY29ycmVjdCB0ZXh0Lg0KDQpLZW50DQoNCg0KDQpPbiAx LzQvMTYsIDU6MTcgUE0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyIgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc+IHdyb3RlOg0KDQo+DQo+QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxh YmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPiBUaGlz IGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBORVRDT05GIERhdGEgTW9kZWxpbmcgTGFuZ3Vh Z2UgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4NCj4NCj4gICAgICAgIFRpdGxlICAgICAgICAg ICA6IFRlcm1pbm9sb2d5IGFuZCBSZXF1aXJlbWVudHMgZm9yIEVuaGFuY2VkIE9wZXJhdGlvbmFs IFN0YXRlIFZpc2liaWxpdHkgYW5kIENvbnRyb2wNCj4gICAgICAgIEF1dGhvcnMgICAgICAgICA6 IEtlbnQgV2F0c2VuDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBUaG9tYXMgTmFkZWF1DQo+ CUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtbmV0bW9kLW9wc3RhdGUtcmVxcy0wMi50eHQN Cj4JUGFnZXMgICAgICAgICAgIDogNg0KPglEYXRlICAgICAgICAgICAgOiAyMDE2LTAxLTA0DQo+ DQo+QWJzdHJhY3Q6DQo+ICAgVGhpcyBkb2N1bWVudCBkaXNjdXNzZXMgdGhlIGRpZmZlcmVuY2Ug YmV0d2VlbiBpbnRlbmRlZCBjb25maWd1cmF0aW9uDQo+ICAgYW5kIGFwcGxpZWQgY29uZmlndXJh dGlvbiBvZiBhIGRldmljZSBhbmQgaG93IGludGVuZGVkIGFuZCBhcHBsaWVkDQo+ICAgY29uZmln dXJhdGlvbiByZWxhdGUgdG8gdGhlIG9wZXJhdGlvbmFsIHN0YXRlIG9mIGEgZGV2aWNlLiAgVGhl DQo+ICAgZG9jdW1lbnQgZGVmaW5lcyB0aGUgbmVjZXNzYXJ5IHRlcm1pbm9sb2d5IGFuZCBpZGVu dGlmaWVzDQo+ICAgcmVxdWlyZW1lbnRzIGVuYWJsaW5nIHZpc2liaWxpdHkgaW50byB0aGUgZGlm ZmVyZW5jZSBvZiBpbnRlbmRlZA0KPiAgIGNvbmZpZ3VyYXRpb24gYW5kIGFwcGxpZWQgY29uZmln dXJhdGlvbi4NCj4NCj4NCj5UaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhp cyBkcmFmdCBpczoNCj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LW5ldG1vZC1vcHN0YXRlLXJlcXMvDQo+DQo+VGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lv biBhdmFpbGFibGUgYXQ6DQo+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt bmV0bW9kLW9wc3RhdGUtcmVxcy0wMg0KPg0KPkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJz aW9uIGlzIGF2YWlsYWJsZSBhdDoNCj5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtaWV0Zi1uZXRtb2Qtb3BzdGF0ZS1yZXFzLTAyDQo+DQo+DQo+UGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbg0KPnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmcuDQo+DQo+SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJs ZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj5uZXRtb2QgbWFpbGluZyBsaXN0DQo+bmV0bW9kQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg== From nobody Mon Jan 4 14:33:49 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51D71AC438; Mon, 4 Jan 2016 14:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.257 X-Spam-Level: X-Spam-Status: No, score=-96.257 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ux-VTgtvkUyC; Mon, 4 Jan 2016 14:33:43 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 65A4F1A079D; Mon, 4 Jan 2016 14:33:43 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.177; From: "Susan Hares" To: "'Joel M. Halpern'" , , , References: <20160104170330.13929.73845.idtracker@ietfa.amsl.com> <006701d14722$616c6950$24453bf0$@ndzh.com> <568ADBE7.3030101@joelhalpern.com> In-Reply-To: <568ADBE7.3030101@joelhalpern.com> Date: Mon, 4 Jan 2016 17:33:54 -0500 Message-ID: <00b501d1473f$fef22990$fcd67cb0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B6_01D14716.1620B570" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQHC7aVhYcGa1ChTuo//84M/O+4YZwFG1DOWAZ3SDjie8XuAkA== X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [netmod] [i2rs] FW: New Version Notification for draft-hares-i2rs-bnp-eca-data-model-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2016 22:33:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B6_01D14716.1620B570 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Joel: On #1) the dependency between I2RS Filter-based RIB (FB-RIB) and ECA, please see draft-kini-i2rs-fb-rib-info-model-02.txt. In section 1.1, it gives the definition of the FB-RIB. In section 1.2, it links this to an event-condition-action model. If you disagree with the definition of I2RS FB-RIB, then we should probably restrict this conversation to the I2RS mail list. Any feedback on the Info-model or data-model would be helpful. The authors hoped to go to a WG adoption call at the end of this week. One challenge for the ephemeral I2RS FB-RIB, is there is no definition of the non-ephemeral FB-RIB. If you think there should be a non-ephemeral FB-RIB - that discussion may be useful between I2RS, Netmod and SUPA. On #2) SUPA ECA model, I agree that we should be able to have a common draft. At IETF 94, I raised issues regarding the SUPA versus my ECA definition. Cheerily, Sue -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Monday, January 04, 2016 3:54 PM To: Susan Hares; i2rs@ietf.org; netmod@ietf.org; supa@ietf.org Subject: Re: [i2rs] FW: New Version Notification for draft-hares-i2rs-bnp-eca-data-model-03.txt I think there are two issues here. 1) It is not clear to me why there is any dependence of the fb-rib data model on an eca data model. While supa does allow for policy model to be sent directly to the router, it also allows many other cases. 2) The approach with the supa eca data model is still under development. Having said that, the material in there is intended to be very general. >From what I understand, there should be no difficulty in refining the action side of that model to actions which affect the fb-rib in ways that are consistent with the fb-dib data model. Yours, Joel On 1/4/16 2:01 PM, Susan Hares wrote: > This model provides a Event-Condition-Action (ECA) policy model. > The I2RS FB-RIB yang data model utilizes this model, but to my > knowledge the Netmod or netconf has not adopted an ECA policy model to > parallel the ACL model. > > Chen and co-authors have created the model: > > draft-chen-supa-eca-data-model-05.txt > > But it does not align with this yang model or seem sufficient to > support the FB-RIB information model. At IETF 94, > I presented a discussion of the issues I found with the > draft-chen-supa-eca-data-model-05.txt, but it has not been updated. > We would appreciate feedback on this version of yang model. > > > In my role as I2RS chair, I2RS needs to make progress soon on the > I2RS FB-RIB data model. We would appreciate your aid. > > > Sue > > -----Original Message----- > From: internet-drafts@ietf.org [ mailto:internet-drafts@ietf.org] > Sent: Monday, January 04, 2016 12:04 PM > To: Susan Hares; Qin Wu; Russ White > Subject: New Version Notification for > draft-hares-i2rs-bnp-eca-data-model-03.txt > > > A new version of I-D, draft-hares-i2rs-bnp-eca-data-model-03.txt > has been successfully submitted by Susan Hares and posted to the IETF repository. > > Name: draft-hares-i2rs-bnp-eca-data-model > Revision: 03 > Title: An Information Model for Basic Network Policy and Filter Rules > Document date: 2016-01-04 > Group: Individual Submission > Pages: 30 > URL: https://www.ietf.org/internet-drafts/draft-hares-i2rs-bnp-eca-data-model-03. txt > Status: https://datatracker.ietf.org/doc/draft-hares-i2rs-bnp-eca-data-model/ > Htmlized: https://tools.ietf.org/html/draft-hares-i2rs-bnp-eca-data-model-03 > Diff: https://www.ietf.org/rfcdiff?url2=draft-hares-i2rs-bnp-eca-data-model-03 > > Abstract: > This document contains the Basic Network Policy and Filters (BNP IM) > Data Model which provides a policy model that support an ordered list > of match-condition-action (aka event-condition-action (ECA)) for > multiple layers (interface, L1-L4, application) and other factors > (size of packet, time of day). The actions allow for setting actions > (QOS and other), decapsulation, encapsulation, plus forwarding > actions. The policy model can be used with the I2RS filter-based > RIB. > > > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > ------=_NextPart_000_00B6_01D14716.1620B570 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Joel: =

 

On #1) the dependency between I2RS Filter-based RIB = (FB-RIB) and ECA, please see draft-kini-i2rs-fb-rib-info-model-02.txt. = In section 1.1, it gives the definition of the FB-RIB.  In section = 1.2, it links this to an event-condition-action model.  If you = disagree with the definition of  I2RS FB-RIB, then we should = probably restrict this conversation to the I2RS mail list.  Any = feedback on the Info-model or data-model would be helpful.  The = authors hoped to go to a WG adoption call at the end of this week. =

 

One challenge for the ephemeral I2RS FB-RIB, is = there is no definition of the non-ephemeral FB-RIB.  If you think = there should be a non-ephemeral FB-RIB – that discussion may be = useful between I2RS, Netmod and SUPA.

 

On #2) = SUPA ECA model, I agree that we should be able to have a common = draft.  At IETF 94, I raised issues regarding the SUPA versus my = ECA definition.   

 

Cheerily,

 

Sue =

 

-----Original Message-----
From: Joel M. Halpern = [mailto:jmh@joelhalpern.com]
Sent: Monday, January 04, 2016 3:54 = PM
To: Susan Hares; i2rs@ietf.org; netmod@ietf.org; = supa@ietf.org
Subject: Re: [i2rs] FW: New Version Notification for = draft-hares-i2rs-bnp-eca-data-model-03.txt

 

I = think there are two issues here.

 

1) It = is not clear to me why there is any dependence of the fb-rib data model = on an eca data model.  While supa does allow for policy model to be = sent directly to the router, it also allows many other = cases.

 

2) The approach with the supa eca data model is = still under development.

  Having said that, the material in there = is intended to be very general.  From what I understand, there = should be no difficulty in refining the action side of that model to = actions which affect the fb-rib in ways that are consistent with the = fb-dib data model.

 

Yours,

Joel

 

On = 1/4/16 2:01 PM, Susan Hares wrote:

> This model provides a Event-Condition-Action = (ECA) policy model.

> The I2RS = FB-RIB yang data model utilizes this model, but to my

> knowledge the Netmod or netconf has not = adopted an ECA policy model to

> parallel the ACL model.

> 

> Chen and co-authors have created the = model:

> 

> = draft-chen-supa-eca-data-model-05.txt

> 

> But it does not align with this yang model or = seem sufficient to

> support = the FB-RIB information model.   At IETF 94,

> I presented a discussion of the issues I found = with the

> = draft-chen-supa-eca-data-model-05.txt, but it has not been = updated.

> We would appreciate = feedback on this version of yang model.

> 

> <i2rs Chair hat on>

> In my role as I2RS chair,  I2RS needs to = make progress soon on the

> = I2RS FB-RIB data model.  We would appreciate your = aid.

> <i2rs chair hat = off>

> 

> Sue

> 

> -----Original Message-----

> From: internet-drafts@ietf.org<= /span> [mailto:internet-drafts@ie= tf.org]

> Sent: = Monday, January 04, 2016 12:04 PM

> To: Susan Hares; Qin Wu; Russ = White

> Subject: New Version = Notification for

> = draft-hares-i2rs-bnp-eca-data-model-03.txt

> 

> 

> A new version of I-D, = draft-hares-i2rs-bnp-eca-data-model-03.txt

> has been successfully submitted by Susan Hares = and posted to the IETF repository.

> 

> = Name:           &n= bsp;           &nb= sp;       = draft-hares-i2rs-bnp-eca-data-model

> = Revision:          = 03

> = Title:           &= nbsp;      An Information Model for Basic = Network Policy and Filter Rules

> Document = date:           = 2016-01-04

> = Group:           &= nbsp;           &n= bsp;      Individual = Submission

> = Pages:           &= nbsp;           &n= bsp;       30

> = URL:            = https://www.ietf.org/inte= rnet-drafts/draft-hares-i2rs-bnp-eca-data-model-03.txt

> = Status:         https://datatracker.ietf.= org/doc/draft-hares-i2rs-bnp-eca-data-model/

> Htmlized:       = https://tools.ietf.org/ht= ml/draft-hares-i2rs-bnp-eca-data-model-03

> = Diff:           https://www.ietf.org/rfcd= iff?url2=3Ddraft-hares-i2rs-bnp-eca-data-model-03

> 

> Abstract:

>     This document contains = the Basic Network Policy and Filters (BNP IM)

>     Data Model which = provides a policy model that support an ordered list

>     of = match-condition-action (aka event-condition-action (ECA)) = for

>     = multiple layers (interface, L1-L4, application) and other = factors

>     (size of packet, time = of day).  The actions allow for setting actions

>     (QOS and other), = decapsulation, encapsulation, plus forwarding

>     actions.  The = policy model can be used with the I2RS filter-based

>     RIB.

> 

> 

> 

> 

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

> 

> The IETF Secretariat

> 

> 

> = _______________________________________________

> i2rs mailing list

> i2rs@ietf.org<= o:p>

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

> 

------=_NextPart_000_00B6_01D14716.1620B570-- From nobody Tue Jan 5 07:05:01 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D9F1A8781 for ; Tue, 5 Jan 2016 07:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wd5RlcyxeaH5 for ; Tue, 5 Jan 2016 07:04: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 336521A8761 for ; Tue, 5 Jan 2016 07:04:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17646; q=dns/txt; s=iport; t=1452006296; x=1453215896; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=gwUq6VtJ6LgthxZGbwnlzUq1X7E8cjNWbRWTUX4njbE=; b=W/wHEolAKFc06PRuKGl3ar5ldSRIPtBYK2usEBxokFOm4Ayj/eZZbFeW XcRBj/rOdyqpUuCqr4EIVOeO2VoAddi5+IFQBUui88PyPLCalAmupCoc/ EZAFrvorx5zvtKX2+RSnI0fRPh4HKHDRLstAeNbjt+pybJXYtKVMtDZD7 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CwBABq2otW/xbLJq1egm6BHm2IWbVbG?= =?us-ascii?q?AEJhSNKAoFqAQEBAQEBgQuENAEBAQQBAQEkICcKARALDgMDAQIBCRYIBwkDAgE?= =?us-ascii?q?CARUfCQgGDQYCAQGIKw62AYtlAQEBAQEBAQEBAQEBAQEBAQEBAQEBFASGVoR/h?= =?us-ascii?q?D45hEUFh1uHEogbjVOBXIRHgwaFVI5BZIQKPjSFEAEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,525,1444694400"; d="scan'208,217";a="623242576" 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; 05 Jan 2016 15:04:53 +0000 Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u05F4r2R017148; Tue, 5 Jan 2016 15:04:53 GMT To: Gert Grammel References: <56784B9B.5020408@cisco.com> <327E370C-4D5F-4F9A-B982-B71108CEBC08@juniper.net> <567A5B39.3010909@wilton.org.uk> <567B1129.9090104@wilton.org.uk> <5CB86359-D6B1-4D84-962C-750A8D7AE174@juniper.net> From: Robert Wilton Message-ID: <568BDB95.4060203@cisco.com> Date: Tue, 5 Jan 2016 15:04:53 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <5CB86359-D6B1-4D84-962C-750A8D7AE174@juniper.net> Content-Type: multipart/alternative; boundary="------------070902030600080704080803" Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 15:04:59 -0000 This is a multi-part message in MIME format. --------------070902030600080704080803 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Gert, Considering a rollback-on-error request that failed: If you leave the configuration in intended config then what happens if a separate config request comes in from another client? Should that request be processed in the context of the failed intended config, or the last successful config change, or must it wait for the original client to decide how to process the failure that occurred? Also what would happen if the client disconnects from the server when a rollback-on-error request has failed, and the server is waiting for the client to tell it what to do? I think that what you describe sounds more like a config request to a candidate configuration datastore. I.e. write the config to candidate, and then commit. If the commit fails, the configuration in the running datastore is rolled back but the configuration remains in the candidate datastore. But note that in this scenario both the intended and applied configuration have both been reverted to the state before the commit operation was attempted. Thanks, Rob On 28/12/2015 17:40, Gert Grammel wrote: > Rob, > > From a client perspective there should be no difference in the > intended state behavior depending on error conditions, if > continue-on-error leaves the intended state, a rollback-on-error > should keep it as well. Moreover, a client reaction on a unsuccessful > application of intended state could be to a) re-try, b) retry with > continue-on-error or c) retry wit stop-on-error. Those actions would > not require any change of intended state. > It shouldn't be the server to decide what the intended state is > supposed to be or hoe long it should last. > > Gert > > > Sent from my Apple ][ > > On 23 Dec 2015, at 22:25, Robert Wilton > wrote: > >> Hi Gert, >> >> Please see one comment inline ... >> >> On 23/12/2015 10:24, Gert Grammel wrote: >>> Rob, Kent, >>> >>> Adding to Robs comments: >>> >>> >>> >>> From: netmod on behalf of Robert Wilton >>> > >>> Date: Wednesday 23 December 2015 09:28 >>> To: Kent Watsen , "netmod@ietf.org >>> " > >>> Subject: Re: [netmod] netmod-opstate-reqs and error option terms >>> (rollback on error) >>> >>> Hi Kent, >>> >>> Yes, I think that we are in agreement. >>> >>> I've one further comment inline below ... >>> >>> On 23/12/2015 02:41, Kent Watsen wrote: >>> >>> [As a contributor] >>> >>> Hi Robert, I want to go back to Jasons original questions. I >>> think were aligned on this, but please check my answers below. >>> >>> Quoting Jasons original text now: >>> >>> >>> Is there some intention in the opstate requirements to add >>> some sort >>> of all-or-nothing behavior to transition (C)? >>> >>> Yes >>> >>> +1 (if rollback-on-error has been requested) >>> >>> >>> >>> i.e. if some part of >>> an edit fails during the transition from intended->applied >>> we should >>> "rollback" the other parts that may have already been applied ? >>> >>> Yes >>> >>> +1 (if rollback-on-error has been requested) >>> >>> >>> >>> Would we then remove it all from intended as well ? >>> >>> IMO, yes. This is more easily understood when thinking about >>> Synchronous Configuration Operations (defined in opstate-reqs), >>> but I believe that it equally applies to Asynchronous >>> Configuration Operations, so long as the client explicitly >>> ops-in for the behavior. >>> >>> IMO no. The intended config is imposed by the client to the server >>> and other than performing some syntax check, the server has no >>> choice to accept it as-is. If the server cant apply the intended >>> config, obviously the mismatch between intended and applied config >>> needs to be notified. As a result, it is up to the client to decide >>> what to do. Actions can vary according to the situation naming a >>> few: 1) retry intended config, 2) retry intended config with >>> continue-on-error, 3) re-apply the previous intended config, >>> In other words: >>> >>> 1. the client shall not touch the applied config directly, >>> 2. the server shall not touch the intended config, >>> 3. its up to the server to align the intended with the applied >>> config in a way requested by the client (i.e. rollback-on-error, ) >>> 4. Once applied, the server notifies the client about success or >>> failure to do so >>> >> I think that it cleaner just to fail and roll back the entire request >> (both intended and applied), i.e. effectively implementing default >> transaction semantics. The client still has full control as to what >> to do after the failure has occurred. I'm not sure how leaving it in >> intended config would pragmatically work with subsequent requests >> that may have been queued up. >> >> Thanks, >> Rob >> > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------070902030600080704080803 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Gert,

Considering a rollback-on-error request that failed:

If you leave the configuration in intended config then what happens if a separate config request comes in from another client? Should that request be processed in the context of the failed intended config, or the last successful config change, or must it wait for the original client to decide how to process the failure that occurred?

Also what would happen if the client disconnects from the server when a rollback-on-error request has failed, and the server is waiting for the client to tell it what to do?


I think that what you describe sounds more like a config request to a candidate configuration datastore. I.e. write the config to candidate, and then commit. If the commit fails, the configuration in the running datastore is rolled back but the configuration remains in the candidate datastore. But note that in this scenario both the intended and applied configuration have both been reverted to the state before the commit operation was attempted.

Thanks,
Rob


On 28/12/2015 17:40, Gert Grammel wrote:
Rob,

From a client perspective there should be no difference in the intended state behavior depending on error conditions, if continue-on-error leaves the intended state, a rollback-on-error should keep it as well. Moreover, a client reaction on a unsuccessful application of intended state could be to a) re-try, b) retry with continue-on-error or c) retry wit stop-on-error. Those actions would not require any change of intended state.
It shouldn't be the server to decide what the intended state is supposed to be or hoe long it should last.

Gert


Sent from my Apple ][

On 23 Dec 2015, at 22:25, Robert Wilton <robert.public@wilton.org.uk> wrote:

Hi Gert,

Please see one comment inline ...

On 23/12/2015 10:24, Gert Grammel wrote:
Rob, Kent,

Adding to Robs comments:



From: netmod <netmod-bounces@ietf.org> on behalf of Robert Wilton <robert.public@wilton.org.uk>
Date: Wednesday 23 December 2015 09:28
To: Kent Watsen <kwatsen@juniper.net>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)

Hi Kent,

Yes, I think that we are in agreement.

I've one further comment inline below ...

On 23/12/2015 02:41, Kent Watsen wrote:
[As a contributor]

Hi Robert, I want to go back to Jasons original questions.I think were aligned on this, but please check my answers below.

Quoting Jasons original text now:


Is there some intention in the opstate requirements to add some sort
of all-or-nothing behavior to transition (C)?
Yes
+1 (if rollback-on-error has been requested)



i.e. if some part of
an edit fails during the transition from intended->applied we should
"rollback" the other parts that may have already been applied ?
Yes
+1 (if rollback-on-error has been requested)


Would we then remove it all from intended as well ?
IMO, yes.This is more easily understood when thinking about Synchronous Configuration Operations (defined in opstate-reqs), but I believe that it equally applies to Asynchronous Configuration Operations, so long as the client explicitly ops-in for the behavior.
IMO no. The intended config is imposed by the client to the server and other than performing some syntax check, the server has no choice to accept it as-is. If the server cant apply the intended config, obviously the mismatch between intended and applied config needs to be notified. As a result, it is up to the client to decide what to do. Actions can vary according to the situation naming a few: 1) retry intended config, 2) retry intended config with continue-on-error, 3) re-apply the previous intended config,
In other words:
  1. the client shall not touch the applied config directly,
  2. the server shall not touch the intended config,
  3. its up to the server to align the intended with the applied config in a way requested by the client (i.e. rollback-on-error, )
  4. Once applied, the server notifies the client about success or failure to do so
I think that it cleaner just to fail and roll back the entire request (both intended and applied), i.e. effectively implementing default transaction semantics. The client still has full control as to what to do after the failure has occurred. I'm not sure how leaving it in intended config would pragmatically work with subsequent requests that may have been queued up.

Thanks,
Rob



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

--------------070902030600080704080803-- From nobody Tue Jan 5 10:09:11 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFEA21A8AFD for ; Tue, 5 Jan 2016 10:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0baAql0E5NEs for ; Tue, 5 Jan 2016 10:09:02 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0763.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::763]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A29121A8AE8 for ; Tue, 5 Jan 2016 10:09:02 -0800 (PST) Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1444.namprd05.prod.outlook.com (10.160.117.153) with Microsoft SMTP Server (TLS) id 15.1.361.13; Tue, 5 Jan 2016 18:08:44 +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.0361.006; Tue, 5 Jan 2016 18:08:44 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt Thread-Index: AQHRRz2lEErWj+iSeUCXhpFM5+aasZ7rnI4AgAFJXoA= Date: Tue, 5 Jan 2016 18:08:44 +0000 Message-ID: <7C709427-849E-4C30-A5E0-7D447FDA364B@juniper.net> References: <20160104221700.28629.34622.idtracker@ietfa.amsl.com> <8A6CD12B-8B34-4F7B-83F2-E56361F998AA@juniper.net> In-Reply-To: <8A6CD12B-8B34-4F7B-83F2-E56361F998AA@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151105 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.12] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 5:hdZYsG+8d6gTU6Q1yN3F0x5AL7jOKVdJvu9YuAi5G2l1gZ6bNd20r4C5IFEGGX/hMYAjL9ujupLJkBujYlDHRShVq7ryG9YoamVCAAmTF4Li4/AG2X7YB/95d+UZsaAZd33p3AGwV4sKz1cVdqxtLw==; 24:joPzT7O1oM6cxEt4LAE/SI4EdiifPGYaYyHiudA7zbB+ZO/227Eo9ZxtglnYKAVYXiaMlPyoKQz9OIlcV7lLy/SQE31sZ01eyfLh4rfRSY0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 0812095267 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(377454003)(199003)(377424004)(24454002)(479174004)(189002)(19580405001)(6116002)(3846002)(2950100001)(2900100001)(101416001)(102836003)(11100500001)(5008740100001)(92566002)(82746002)(122556002)(87936001)(83506001)(1220700001)(10400500002)(19580395003)(1730700002)(40100003)(83716003)(2501003)(66066001)(15975445007)(5004730100002)(1096002)(86362001)(97736004)(54356999)(2351001)(106356001)(99286002)(36756003)(107886002)(189998001)(5001960100002)(81156007)(586003)(105586002)(77096005)(50986999)(110136002)(450100001)(33656002)(76176999)(5002640100001)(106116001)(4001350100001)(230783001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; 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:23 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: 05 Jan 2016 18:08:44.4404 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1444 Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 18:09:10 -0000 DQpUaGVyZSBhcmUgYSBmZXcgZWRpdG9yaWFsIGlzc3VlcyAoc2VlIGJlbG93KSB0aGF0IEnigJlk IGxpa2UgdG8gZml4IGJlZm9yZSBCZW5vaXQgZ2V0cyBiYWNrICh0b21vcnJvdywgSSB0aGluayku ICBQbGVhc2UgbGV0IG1lIGtub3cgaWYgeW91IHNwb3QgYW55IG90aGVyIGlzc3VlcyBsaWtlIHRo ZXNlLCB0b2RheSBpZiBwb3NzaWJsZS4NCg0KVGhhbmtzLA0KS2VudA0KDQoNCg0KDQoNCi0gZW5z dXJlIHRoYXQgdGhpcyBpbmNvbnNpc3RlbmN5IG1pbmltaXplcyBnYXBzIGluIHRoZSBhcHBsaWNh dGlvbiBvZg0KDQorIGVuc3VyZSB0aGF0IHRoaXMgcHJvY2VzcyBtaW5pbWl6ZXMgZ2FwcyBpbiB0 aGUgYXBwbGljYXRpb24gb2YNCiAgICAgICAgICAgICAgICAgICBeXl5eXl5eDQoNCi0gcG9saWNp ZXMgb3Igbm90IGRlcGVuZGVudCBvbiBleHRlcm5hbCBpbnB1dCB0aGF0IGFuIGF0dGFja2VyIG1p Z2h0DQoNCisgcG9saWNpZXMgYXJlIG5vdCBkZXBlbmRlbnQgb24gZXh0ZXJuYWwgaW5wdXQgdGhh dCBhbiBhdHRhY2tlciBtaWdodA0KICAgICAgICAgICBeXl4NCg0KDQotIFN0ZXJuZSwgSmFzb24N CisgSmFzb24gU3Rlcm5lDQoNCg0KDQoNCg0KDQoNCg0KT24gMS80LzE2LCA1OjI5IFBNLCAibmV0 bW9kIG9uIGJlaGFsZiBvZiBLZW50IFdhdHNlbiIgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9u IGJlaGFsZiBvZiBrd2F0c2VuQGp1bmlwZXIubmV0PiB3cm90ZToNCg0KPg0KPlRoaXMgdXBkYXRl IGFkZHJlc3NlcyBjb21tZW50cyByZWNlaXZlZCBkdXJpbmcgdGhlIExhc3QgQ2FsbC4NCj4NCj5X YXJuaW5nISAgLSB0aGUgRGlmZjEgYW5kIERpZmYyIG91dHB1dHMgc29tZWhvdyBtYW5nbGUgdGhl IEFwcGxpZWQgQ29uZmlndXJhdGlvbiB0ZXJtLiAgUGxlYXNlIGxvb2sgYXQgdGhlIGRyYWZ0IGl0 c2VsZiBmb3IgdGhlIGNvcnJlY3QgdGV4dC4NCj4NCj5LZW50DQo+DQo+DQo+DQo+T24gMS80LzE2 LCA1OjE3IFBNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmci IDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgaW50ZXJuZXQtZHJhZnRzQGll dGYub3JnPiB3cm90ZToNCj4NCj4+DQo+PkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJs ZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4+IFRoaXMg ZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE5FVENPTkYgRGF0YSBNb2RlbGluZyBMYW5ndWFn ZSBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLg0KPj4NCj4+ICAgICAgICBUaXRsZSAgICAgICAg ICAgOiBUZXJtaW5vbG9neSBhbmQgUmVxdWlyZW1lbnRzIGZvciBFbmhhbmNlZCBPcGVyYXRpb25h bCBTdGF0ZSBWaXNpYmlsaXR5IGFuZCBDb250cm9sDQo+PiAgICAgICAgQXV0aG9ycyAgICAgICAg IDogS2VudCBXYXRzZW4NCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICBUaG9tYXMgTmFkZWF1 DQo+PglGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLW5ldG1vZC1vcHN0YXRlLXJlcXMtMDIu dHh0DQo+PglQYWdlcyAgICAgICAgICAgOiA2DQo+PglEYXRlICAgICAgICAgICAgOiAyMDE2LTAx LTA0DQo+Pg0KPj5BYnN0cmFjdDoNCj4+ICAgVGhpcyBkb2N1bWVudCBkaXNjdXNzZXMgdGhlIGRp ZmZlcmVuY2UgYmV0d2VlbiBpbnRlbmRlZCBjb25maWd1cmF0aW9uDQo+PiAgIGFuZCBhcHBsaWVk IGNvbmZpZ3VyYXRpb24gb2YgYSBkZXZpY2UgYW5kIGhvdyBpbnRlbmRlZCBhbmQgYXBwbGllZA0K Pj4gICBjb25maWd1cmF0aW9uIHJlbGF0ZSB0byB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgb2YgYSBk ZXZpY2UuICBUaGUNCj4+ICAgZG9jdW1lbnQgZGVmaW5lcyB0aGUgbmVjZXNzYXJ5IHRlcm1pbm9s b2d5IGFuZCBpZGVudGlmaWVzDQo+PiAgIHJlcXVpcmVtZW50cyBlbmFibGluZyB2aXNpYmlsaXR5 IGludG8gdGhlIGRpZmZlcmVuY2Ugb2YgaW50ZW5kZWQNCj4+ICAgY29uZmlndXJhdGlvbiBhbmQg YXBwbGllZCBjb25maWd1cmF0aW9uLg0KPj4NCj4+DQo+PlRoZSBJRVRGIGRhdGF0cmFja2VyIHN0 YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPj5odHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLW5ldG1vZC1vcHN0YXRlLXJlcXMvDQo+Pg0KPj5UaGVyZSdzIGFs c28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4+aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0bW9kLW9wc3RhdGUtcmVxcy0wMg0KPj4NCj4+QSBkaWZm IGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPj5odHRwczovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1uZXRtb2Qtb3BzdGF0ZS1yZXFzLTAy DQo+Pg0KPj4NCj4+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51 dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPj51bnRpbCB0aGUgaHRtbGl6ZWQgdmVy c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPj4NCj4+SW50 ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPj5m dHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4NCj4+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+bmV0bW9kIG1haWxpbmcgbGlzdA0K Pj5uZXRtb2RAaWV0Zi5vcmcNCj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRtb2QNCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPm5ldG1vZCBtYWlsaW5nIGxpc3QNCj5uZXRtb2RAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K From nobody Tue Jan 5 11:42:36 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5151B2C34 for ; Tue, 5 Jan 2016 11:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8tIYcsQSo0T for ; Tue, 5 Jan 2016 11:42:31 -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 9BF901A6F62 for ; Tue, 5 Jan 2016 11:42:31 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9E7C51273 for ; Tue, 5 Jan 2016 20:42:29 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 74fJgQhYQ1Ly for ; Tue, 5 Jan 2016 20:42: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 for ; Tue, 5 Jan 2016 20:42:28 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6F1B420056 for ; Tue, 5 Jan 2016 20:42:28 +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 76uDaqsJklph; Tue, 5 Jan 2016 20:42:27 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E709B20055; Tue, 5 Jan 2016 20:42:26 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id EB289397C5D8; Tue, 5 Jan 2016 20:42:25 +0100 (CET) Date: Tue, 5 Jan 2016 20:42:25 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20160105194222.GA24227@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20151214191724.GA51110@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151214191724.GA51110@elstar.local> User-Agent: Mutt/1.4.2.3i Archived-At: Subject: Re: [netmod] 2nd WG Last Call on YANG 1.1 (draft-ietf-netmod-rfc6020bis-09) [until 2016-01-06] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 19:42:34 -0000 Hi, I hope you all had a good start into 2016. I like to remind you that we have the second WG last call on YANG 1.1 running, which closes tomorrow. Please send your reviews and input. In case you need a few more days to do a review, please let me know as well. /js On Mon, Dec 14, 2015 at 08:17:25PM +0100, Juergen Schoenwaelder wrote: > This is a notice to start the second NETMOD WG last-call for the > document "The YANG 1.1 Data Modeling Language": > > https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-09 > > Due to the upcoming holiday season, the WG last-call runs until > Wednesday January 6th, 2016. Please indicate your support of this > version of the document. We are not only interested in receiving > defect reports, we are equally interested in statements of the form: > > "I have reviewed I-D XYZ and I found no issues" > "I have implemented I-D XYZ" > "I am implementing I-D XYZ" > "I am considering to implement I-D XYZ" > > We will track non-editorial defect reports in this document: > > https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/last-call-comments.html > > This is the second WG last-call for this document. The first WG > last-call (draft-ietf-netmod-rfc6020bis-07) did end on October 12th > 2015 and lead to a number of changes. A diff of -07 to -09 can be > found here: > > http://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-netmod-rfc6020bis-07.txt&url2=https://tools.ietf.org/id/draft-ietf-netmod-rfc6020bis-09.txt > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jan 5 12:02:20 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92CE71A8A7F for ; Tue, 5 Jan 2016 12:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umevZ9IeWPVZ for ; Tue, 5 Jan 2016 12:02:18 -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 3C42C1A9094 for ; Tue, 5 Jan 2016 12:02:18 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DF3B7145B; Tue, 5 Jan 2016 21:02:16 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id VqrE00mxRMBL; Tue, 5 Jan 2016 21:02:15 +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, 5 Jan 2016 21:02:15 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 92ACD20055; Tue, 5 Jan 2016 21:02:15 +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 DWWUtKzLBh2X; Tue, 5 Jan 2016 21:02:15 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 90EDB20056; Tue, 5 Jan 2016 21:02:14 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8471B397C627; Tue, 5 Jan 2016 21:02:14 +0100 (CET) Date: Tue, 5 Jan 2016 21:02:14 +0100 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20160105200214.GA24262@elstar.local> Mail-Followup-To: Kent Watsen , "netmod@ietf.org" References: <20160104221700.28629.34622.idtracker@ietfa.amsl.com> <8A6CD12B-8B34-4F7B-83F2-E56361F998AA@juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8A6CD12B-8B34-4F7B-83F2-E56361F998AA@juniper.net> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 20:02:19 -0000 On Mon, Jan 04, 2016 at 10:29:54PM +0000, Kent Watsen wrote: > > This update addresses comments received during the Last Call. > I not entirely happy with the new title: Terminology and Requirements for Enhanced Operational State Visibility and Control Since the key contribution is the concept of intended configuration and applied configuration, why not put these terms into the title instead of "Enhanced Operational State Visibility and Control", which is somewhat vague? What about this proposal: Terminology and Requirements for Distinguishing Intended and Applied Configuration /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 5 12:08:34 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E91B1A913E for ; Tue, 5 Jan 2016 12:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkQKecY17dzQ for ; Tue, 5 Jan 2016 12:08:31 -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 4A8701A913D for ; Tue, 5 Jan 2016 12:08:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1938; q=dns/txt; s=iport; t=1452024511; x=1453234111; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=0GMtF9jYv3P6NeGaStKn+40QL/VgtwqrX29YJhiQsNA=; b=hkjYKBlFf/6Fl5iy+cbtp4J7Jsy+2hB9Ujcp+t0fxvZnXbrCzRZIwawJ MNlaqRkuTY5iAlk8QNGpQTBD7ZYbgBnTqVNEqnveqzd7vRehZfFQ6F4Jt pRQZ1ihk7kRT9KPVh3YxwTS3MSzn/kSyW7+pLQ+s1OltiGVZ62g4Wyjun k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BIBQADIoxW/5pdJa1bA4M6Um0GiFOzd?= =?us-ascii?q?4FkGAqFI0oCHIEDORMBAQEBAQEBgQqENQEBBAEBASAROgsOAgIBCA4CCAICJgI?= =?us-ascii?q?CAhkMCxUQAgQBDQWILw6xO5BrAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAR9ilSEV?= =?us-ascii?q?RgLJoJVgUkFlwgBjVKBXI0hhVuIZQEkAz2ECnKEWYEIAQEB?= X-IronPort-AV: E=Sophos;i="5.20,525,1444694400"; d="scan'208";a="58708159" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jan 2016 20:08:30 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u05K8Uh8023460 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Jan 2016 20:08:30 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 5 Jan 2016 15:08:29 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Tue, 5 Jan 2016 15:08:29 -0500 From: "Acee Lindem (acee)" To: Juergen Schoenwaelder , Kent Watsen Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt Thread-Index: AQHRRz2nOvQMyiQN+k2oelLD0j5Ct57sRDQAgAFpEwD//63ogA== Date: Tue, 5 Jan 2016 20:08:29 +0000 Message-ID: References: <20160104221700.28629.34622.idtracker@ietfa.amsl.com> <8A6CD12B-8B34-4F7B-83F2-E56361F998AA@juniper.net> <20160105200214.GA24262@elstar.local> In-Reply-To: <20160105200214.GA24262@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.203] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 20:08:33 -0000 SnVlcmdlbiwgDQoNCkFzIGFub3RoZXIgbm9uLWF1dGhvciwgSSBkaXNhZ3JlZSB3aXRoIHRoaXMg Y2hhcmFjdGVyaXphdGlvbiBvZiB0aGUgZHJhZnQuDQpUaGUgaW50ZW5kZWQvYXBwbGllZCBjb25m aWd1cmF0aW9uIGlzIGFuIGltcG9ydGFudCByZXF1aXJlbWVudCBidXQNCmNlcnRhaW5seSBub3Qg dGhlIG9ubHkgb25lIHByZWNpc2VseSBhcnRpY3VsYXRlZCBpbiB0aGUgZHJhZnQuDQoNCkFjZWUg DQoNCk9uIDEvNS8xNiwgMzowMiBQTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgSnVlcmdlbiBTY2hv ZW53YWVsZGVyIg0KPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZg0Kai5zY2hv ZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCg0KPk9uIE1vbiwgSmFuIDA0 LCAyMDE2IGF0IDEwOjI5OjU0UE0gKzAwMDAsIEtlbnQgV2F0c2VuIHdyb3RlOg0KPj4gDQo+PiBU aGlzIHVwZGF0ZSBhZGRyZXNzZXMgY29tbWVudHMgcmVjZWl2ZWQgZHVyaW5nIHRoZSBMYXN0IENh bGwuDQo+Pg0KPg0KPkkgbm90IGVudGlyZWx5IGhhcHB5IHdpdGggdGhlIG5ldyB0aXRsZToNCj4N Cj4gICAgICAgICAgICAgICBUZXJtaW5vbG9neSBhbmQgUmVxdWlyZW1lbnRzIGZvciBFbmhhbmNl ZA0KPiAgICAgICAgICAgICAgICBPcGVyYXRpb25hbCBTdGF0ZSBWaXNpYmlsaXR5IGFuZCBDb250 cm9sDQo+DQo+U2luY2UgdGhlIGtleSBjb250cmlidXRpb24gaXMgdGhlIGNvbmNlcHQgb2YgaW50 ZW5kZWQgY29uZmlndXJhdGlvbg0KPmFuZCBhcHBsaWVkIGNvbmZpZ3VyYXRpb24sIHdoeSBub3Qg cHV0IHRoZXNlIHRlcm1zIGludG8gdGhlIHRpdGxlDQo+aW5zdGVhZCBvZiAiRW5oYW5jZWQgT3Bl cmF0aW9uYWwgU3RhdGUgVmlzaWJpbGl0eSBhbmQgQ29udHJvbCIsIHdoaWNoDQo+aXMgc29tZXdo YXQgdmFndWU/IFdoYXQgYWJvdXQgdGhpcyBwcm9wb3NhbDoNCj4NCj4JICAgVGVybWlub2xvZ3kg YW5kIFJlcXVpcmVtZW50cyBmb3IgRGlzdGluZ3Vpc2hpbmcNCj4JCSAgSW50ZW5kZWQgYW5kIEFw cGxpZWQgQ29uZmlndXJhdGlvbg0KPg0KPi9qcw0KPg0KPi0tIA0KPkp1ZXJnZW4gU2Nob2Vud2Fl bGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+UGhvbmU6ICs0 OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2Vy bWFueQ0KPkZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2Jz LXVuaXZlcnNpdHkuZGUvPg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+bmV0bW9kIG1haWxpbmcgbGlzdA0KPm5ldG1vZEBpZXRmLm9yZw0KPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg== From nobody Tue Jan 5 22:30:25 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0EF1AC429 for ; Tue, 5 Jan 2016 22:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2RaOcaFRkWZ for ; Tue, 5 Jan 2016 22:30:22 -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 BC3961AC424 for ; Tue, 5 Jan 2016 22:30:20 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 005121412; Wed, 6 Jan 2016 07:30:18 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id lBFDRqcbkolT; Wed, 6 Jan 2016 07:30: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; Wed, 6 Jan 2016 07:30:18 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id DC46620056; Wed, 6 Jan 2016 07:30:17 +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 feQ4uYrKwRLv; Wed, 6 Jan 2016 07:30:16 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D72BA20055; Wed, 6 Jan 2016 07:30:15 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 23F74397C917; Wed, 6 Jan 2016 07:30:14 +0100 (CET) Date: Wed, 6 Jan 2016 07:30:14 +0100 From: Juergen Schoenwaelder To: "Acee Lindem (acee)" Message-ID: <20160106063014.GA25143@elstar.local> Mail-Followup-To: "Acee Lindem (acee)" , Kent Watsen , "netmod@ietf.org" References: <20160104221700.28629.34622.idtracker@ietfa.amsl.com> <8A6CD12B-8B34-4F7B-83F2-E56361F998AA@juniper.net> <20160105200214.GA24262@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 06:30:24 -0000 Acee, for me the document is centered around the notion of intended / applied config: #1 is clearly about intended/applied cfg #2 is about intended/applied cfg (since sync config operations is largely defined using intended/applied cfg) #3 is about the relationship of applied config and derived state #4 is about the relationship of intended / applied config and operational state I find "Enhanced Operational State Visibility and Control" abstract and somewhat confusing (what is visibility? what is control?). /js On Tue, Jan 05, 2016 at 08:08:29PM +0000, Acee Lindem (acee) wrote: > Juergen, > > As another non-author, I disagree with this characterization of the draft. > The intended/applied configuration is an important requirement but > certainly not the only one precisely articulated in the draft. > > Acee > > On 1/5/16, 3:02 PM, "netmod on behalf of Juergen Schoenwaelder" > j.schoenwaelder@jacobs-university.de> wrote: > > >On Mon, Jan 04, 2016 at 10:29:54PM +0000, Kent Watsen wrote: > >> > >> This update addresses comments received during the Last Call. > >> > > > >I not entirely happy with the new title: > > > > Terminology and Requirements for Enhanced > > Operational State Visibility and Control > > > >Since the key contribution is the concept of intended configuration > >and applied configuration, why not put these terms into the title > >instead of "Enhanced Operational State Visibility and Control", which > >is somewhat vague? What about this proposal: > > > > Terminology and Requirements for Distinguishing > > Intended and Applied Configuration > > > >/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 > -- 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 6 01:20:26 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53BC1A8A86; Tue, 5 Jan 2016 19:12:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvYFoGccMAVu; Tue, 5 Jan 2016 19:12:14 -0800 (PST) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::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 6F0C61A8A6E; Tue, 5 Jan 2016 19:12:13 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id p203so307916843lfa.0; Tue, 05 Jan 2016 19:12:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sqf7qbpyfX8rIBG2j5kAOHtYljnReiD5nC9Biw0mClU=; b=SXvyHMJGtlyo1pHXMTQ4W8fWbU0RCaq6glYgPM2MyjQQ9omKeUVd6rCJSPv1mnYPLT xR2C4+qpUK4PEpL20NuE1KPF97tOMmkJ5URnZeZMow2r1G8+sBm0hnNthccQOuoNmnum L7T8NWFiUDqt2UWSzSbDrqL0HnJJmhWmIUMJONNsQPivq8jP0BytR+5/SCkhFdVQbn+9 n44wWMk6PDxqMfQbzQ9dois3YCnEBeBrIIgDvEeyipD3qiX2zjU3IuPE2Q0auW2RNvKA 1vXARagokqyg3lNCjp98PDyx5JL7MmtiCpF4/Uj5880FjZMVRcYhkZYDo5GNEQGJRS2s SYOg== MIME-Version: 1.0 X-Received: by 10.25.170.210 with SMTP id t201mr37004359lfe.16.1452049931626; Tue, 05 Jan 2016 19:12:11 -0800 (PST) Received: by 10.25.89.12 with HTTP; Tue, 5 Jan 2016 19:12:11 -0800 (PST) In-Reply-To: <568ADBE7.3030101@joelhalpern.com> References: <20160104170330.13929.73845.idtracker@ietfa.amsl.com> <006701d14722$616c6950$24453bf0$@ndzh.com> <568ADBE7.3030101@joelhalpern.com> Date: Tue, 5 Jan 2016 19:12:11 -0800 Message-ID: From: John Strassner To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a114111945ef1370528a1b8f0 Archived-At: X-Mailman-Approved-At: Wed, 06 Jan 2016 01:20:22 -0800 Cc: i2rs@ietf.org, "supa@ietf.org" , netmod@ietf.org, Susan Hares Subject: Re: [netmod] [Supa] [i2rs] FW: New Version Notification for draft-hares-i2rs-bnp-eca-data-model-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 03:12:17 -0000 --001a114111945ef1370528a1b8f0 Content-Type: text/plain; charset=UTF-8 Hi Joe, et al., > 1) It is not clear to me why there is any dependence of the fb-rib > data model on an eca data model. While supa does allow for > policy model to be sent directly to the router, it also allows many > other cases. Exactly. More particularly, in scanning this draft, I fail to see how this is an accepted definition of ECA. In particular, there doesn't seem to be any event in the rule definition. Hence, I would suggest that you add wording that says that this is one of many ways to build such a mapping. > 2) The approach with the supa eca data model is still under > development. Absolutely agree. In particular, draft-chen was the first attempt at trying to conceptualize what such a data model should look like. > Having said that, the material in there is intended to be very > general. IFF you mean the SUPA info model, then absolutely (otherwise, it has failed in its primary mission of providing an extensible framework to define policies). IFF you mean draft-chen, then I think it agrees with the spirit of what you said. I think that we need to discuss how to map from an info model to a data model in more detail before we come to any conclusions of its efficacy. > From what I understand, there should be no difficulty in > refining the action side of that model to actions which affect > the fb-rib in ways that are consistent with the fb-dib data model. +1. In fact, the whole point of SUPA is to provide different ways of forming an ECA policy rule to meet different demands of the user. More particularly, at IETF94, you (Sue) assumed that an ECA policy rule was made up of Event, Condition, and Action objects. While that is certainly one alternative, there are others as well. In addition, please note that the presence of these objects is NOT sufficient to build an ECA policy rule (e.g., the Event object needs an attribute (or multiple attributes) to be compared to something in order to determine if the event CLAUSE evaluates to TRUE or not. regards, John On Mon, Jan 4, 2016 at 12:53 PM, Joel M. Halpern wrote: > I think there are two issues here. > > 1) It is not clear to me why there is any dependence of the fb-rib data > model on an eca data model. While supa does allow for policy model to be > sent directly to the router, it also allows many other cases. > > 2) The approach with the supa eca data model is still under development. > Having said that, the material in there is intended to be very general. > From what I understand, there should be no difficulty in refining the > action side of that model to actions which affect the fb-rib in ways that > are consistent with the fb-dib data model. > > Yours, > Joel > > On 1/4/16 2:01 PM, Susan Hares wrote: > >> This model provides a Event-Condition-Action (ECA) policy model. >> The I2RS FB-RIB yang data model utilizes this model, but to my knowledge >> the >> Netmod or netconf has not adopted an ECA policy model to >> parallel the ACL model. >> >> Chen and co-authors have created the model: >> >> draft-chen-supa-eca-data-model-05.txt >> >> But it does not align with this yang model or seem sufficient to >> support the FB-RIB information model. At IETF 94, >> I presented a discussion of the issues I found with the >> draft-chen-supa-eca-data-model-05.txt, but it has not been updated. >> We would appreciate feedback on this version of yang model. >> >> >> In my role as I2RS chair, I2RS needs to make progress soon on the >> I2RS FB-RIB data model. We would appreciate your aid. >> >> >> Sue >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Monday, January 04, 2016 12:04 PM >> To: Susan Hares; Qin Wu; Russ White >> Subject: New Version Notification for >> draft-hares-i2rs-bnp-eca-data-model-03.txt >> >> >> A new version of I-D, draft-hares-i2rs-bnp-eca-data-model-03.txt >> has been successfully submitted by Susan Hares and posted to the IETF >> repository. >> >> Name: draft-hares-i2rs-bnp-eca-data-model >> Revision: 03 >> Title: An Information Model for Basic Network Policy and Filter >> Rules >> Document date: 2016-01-04 >> Group: Individual Submission >> Pages: 30 >> URL: >> https://www.ietf.org/internet-drafts/draft-hares-i2rs-bnp-eca-data-model-03.txt >> Status: >> https://datatracker.ietf.org/doc/draft-hares-i2rs-bnp-eca-data-model/ >> Htmlized: >> https://tools.ietf.org/html/draft-hares-i2rs-bnp-eca-data-model-03 >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-hares-i2rs-bnp-eca-data-model-03 >> >> Abstract: >> This document contains the Basic Network Policy and Filters (BNP IM) >> Data Model which provides a policy model that support an ordered list >> of match-condition-action (aka event-condition-action (ECA)) for >> multiple layers (interface, L1-L4, application) and other factors >> (size of packet, time of day). The actions allow for setting actions >> (QOS and other), decapsulation, encapsulation, plus forwarding >> actions. The policy model can be used with the I2RS filter-based >> RIB. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> The IETF Secretariat >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > -- regards, John --001a114111945ef1370528a1b8f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joe, et al.,

> 1) It i= s not clear to me why there is any dependence of the fb-rib
>= =C2=A0data model on an eca data model.=C2=A0 While supa does allow for
> policy model to be sent directly to the router, it also allows = many
>=C2=A0other cases.

Exactly.= More particularly, in scanning this draft, I fail to see how
thi= s is an accepted definition of ECA. In particular, there doesn't
<= div>seem to be any event in the rule definition.

H= ence, I would suggest that you add wording that says that this is
one of many ways to build such a mapping.


>=C2=A02) The approach with the supa eca data model is still und= er
>=C2=A0development.

Absolutely agr= ee. In particular, draft-chen was the first attempt at
trying to = conceptualize what such a data model should look like.

=
>=C2=A0 Having said that, the material in there is intended to be v= ery
>=C2=A0general.

IFF you mean the = SUPA info model, then absolutely (otherwise,
it has failed in its= primary mission of providing an extensible
framework to define p= olicies).

IFF you mean draft-chen, then=C2=A0I thi= nk it=C2=A0agrees with the spirit of
what you said. I think that = we need to discuss how to map from
an info model to a data model= =C2=A0in more detail before we come to
any conclusions of its eff= icacy.

>=C2=A0 From what I understand, there sh= ould be no difficulty in
>=C2=A0refining the action side of th= at model to actions which affect
>=C2=A0the fb-rib in ways tha= t are consistent with the fb-dib data model.

+1. I= n fact, the whole point of SUPA is to provide different ways
of f= orming an ECA policy rule to meet different demands of the
user. = More particularly, at IETF94, you (Sue) assumed that an
ECA polic= y rule was made up of Event, Condition, and Action
objects. While= that is certainly one alternative, there are others
as well. In = addition, please note that the presence of these
objects is NOT s= ufficient to build an ECA policy rule (e.g., the
Event object nee= ds an attribute (or multiple attributes) to be
compared to somet= hing in order to determine if the event
CLAUSE evaluates to TRUE= or not.


regards,
John

On M= on, Jan 4, 2016 at 12:53 PM, Joel M. Halpern <jmh@joelhalpern.com&g= t; wrote:
I think there are two is= sues here.

1) It is not clear to me why there is any dependence of the fb-rib data mod= el on an eca data model.=C2=A0 While supa does allow for policy model to be= sent directly to the router, it also allows many other cases.

2) The approach with the supa eca data model is still under development.=C2= =A0 Having said that, the material in there is intended to be very general.= =C2=A0 From what I understand, there should be no difficulty in refining th= e action side of that model to actions which affect the fb-rib in ways that= are consistent with the fb-dib data model.

Yours,
Joel

On 1/4/16 2:01 PM, Susan Hares wrote:
This model provides a Event-Condition-Action (ECA) policy model.
The I2RS FB-RIB yang data model utilizes this model, but to my knowledge th= e
Netmod or netconf has not adopted an ECA policy model to
parallel the ACL model.

Chen and co-authors have created the model:

draft-chen-supa-eca-data-model-05.txt

But it does not align with this yang model or seem sufficient to
support the FB-RIB information model.=C2=A0 =C2=A0At IETF 94,
I presented a discussion of the issues I found with the
draft-chen-supa-eca-data-model-05.txt, but it has not been updated.
We would appreciate feedback on this version of yang model.

<i2rs Chair hat on>
In my role as I2RS chair,=C2=A0 I2RS needs to make progress soon on the
I2RS FB-RIB data model.=C2=A0 We would appreciate your aid.
<i2rs chair hat off>

Sue

-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Monday, January 04, 2016 12:04 PM
To: Susan Hares; Qin Wu; Russ White
Subject: New Version Notification for draft-hares-i2rs-bnp-eca-data-model-0= 3.txt


A new version of I-D, draft-hares-i2rs-bnp-eca-data-model-03.txt
has been successfully submitted by Susan Hares and posted to the IETF repos= itory.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hares-i2rs-bnp-eca-data= -model
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A003
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 An Information Model for Basic Net= work Policy and Filter Rules
Document date:=C2=A0 2016-01-04
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 30
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-hares-i= 2rs-bnp-eca-data-model-03.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-hares-i2rs-bnp-eca-data-mo= del/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-hares-i2rs-bnp-eca-data-model-03 Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-hares-i2rs-bn= p-eca-data-model-03

Abstract:
=C2=A0 =C2=A0 This document contains the Basic Network Policy and Filters (= BNP IM)
=C2=A0 =C2=A0 Data Model which provides a policy model that support an orde= red list
=C2=A0 =C2=A0 of match-condition-action (aka event-condition-action (ECA)) = for
=C2=A0 =C2=A0 multiple layers (interface, L1-L4, application) and other fac= tors
=C2=A0 =C2=A0 (size of packet, time of day).=C2=A0 The actions allow for se= tting actions
=C2=A0 =C2=A0 (QOS and other), decapsulation, encapsulation, plus forwardin= g
=C2=A0 =C2=A0 actions.=C2=A0 The policy model can be used with the I2RS fil= ter-based
=C2=A0 =C2=A0 RIB.




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

The IETF Secretariat


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


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



--
regards,
John
--001a114111945ef1370528a1b8f0-- From nobody Wed Jan 6 01:20:27 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148C91A8AD1; Tue, 5 Jan 2016 19:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FThLQjltJsR1; Tue, 5 Jan 2016 19:27:47 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 0CB221A8AC8; Tue, 5 Jan 2016 19:27:47 -0800 (PST) Received: by mail-lf0-x22a.google.com with SMTP id c192so129524375lfe.2; Tue, 05 Jan 2016 19:27:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O/hutANSbakogS0d9e3FD1igoweRHjzqM037hqpTKAE=; b=yBoVAPjvvsssgwbC17EAubvGK28yuCRuDKUOFPvWpT42emxXaQLCgmyaXHmSuAJqvl TBBOHA1CkIrEhngcZCWfblFKIdmJpja7Gbe7p7sbjgCsUT5rvRcR+PEd6YRBzDJzlqfb 3BwsyecYY8RHa+hra0TAL7AGJ8eIHzWXRs5LSggULcv14hjk0cTrBJ5FMvE3gZZXL392 mV4/5Y1j9NZlDsADT5s4IRVj5LLSX07ruKzff8Eqmlt/hvtUGOA+6gTYmKpB7JM+Vax0 mNac9AYUcRS42TSiBiD2EFRVd51Mbo7oti9oL0gDbwXdOPutEBSnel6yfxHOkLQzwcis ThDw== MIME-Version: 1.0 X-Received: by 10.25.145.14 with SMTP id t14mr18797351lfd.100.1452050865264; Tue, 05 Jan 2016 19:27:45 -0800 (PST) Received: by 10.25.89.12 with HTTP; Tue, 5 Jan 2016 19:27:45 -0800 (PST) In-Reply-To: <00b501d1473f$fef22990$fcd67cb0$@ndzh.com> References: <20160104170330.13929.73845.idtracker@ietfa.amsl.com> <006701d14722$616c6950$24453bf0$@ndzh.com> <568ADBE7.3030101@joelhalpern.com> <00b501d1473f$fef22990$fcd67cb0$@ndzh.com> Date: Tue, 5 Jan 2016 19:27:45 -0800 Message-ID: From: John Strassner To: Susan Hares Content-Type: multipart/alternative; boundary=001a11401eb20522780528a1f064 Archived-At: X-Mailman-Approved-At: Wed, 06 Jan 2016 01:20:25 -0800 Cc: i2rs@ietf.org, "supa@ietf.org" , netmod@ietf.org, John Strassner Subject: Re: [netmod] [Supa] [i2rs] FW: New Version Notification for draft-hares-i2rs-bnp-eca-data-model-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 03:27:51 -0000 --001a11401eb20522780528a1f064 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sue, > On #1) the dependency between I2RS Filter-based RIB (FB-RIB) and > ECA, please see draft-kini-i2rs-fb-rib-info-model-02.txt. In section 1.1, > it gives the definition of the FB-RIB. Sorry, it does NOT do this. To quote from this section: A Filter Based RIB uses Event-Condition-Action policy. A Filter- based RIB entry specifies matches on fields in a packet (which may include layer 2 fields, IP header fields, transport or application fields) or size of the packet or interface received on. The matches are contained in an ordered list of filters which contain pairs of match condition-action (aka event-condition-action). Please tell me WHERE the event is in the above definition. All I see is a condition-action rule. (BTW, the analysis of PCIM and PCIMe is also not quite correct in your draft). > In section 1.2, it links this to an event-condition-action model. Sorry, it does NOT do this. First, this section simply says, and I quote: "The filter based-RIB uses event-condition-action policy (ECA) rules." That is a tautology at best. Second, in Section 2, under the definition of FB-Route, the draft says: "The policy rules in the filter-based RIB are prescriptive of the Event-Condition-Action form which is often represented by if Condition then action." Please note that this definition is incorrect, and in conflict with SUPA. The whole point of an EVENT-condition-action policy rule is to define a rule of the form: IF evaluates to TRUE IF ENDIF ENDIF This definition has been established in the industry and academia for at least 2 decades. Variations of the above have been defined and published (e.g., FOCALE has an alternate set of actions to execute if the condition clause evaluated to FALSE; this has NOT been proposed for SUPA at this time). There have also been extensions to handle sets and groups, as well as specific ordering (DEN-ng, SID, FOCALE). Therefore, I would suggest that you change your drafts to use a condition-action policy rule, OR update the drafts (I would be happy to help) to use a correct definition of an ECA policy rule. regards, John On Mon, Jan 4, 2016 at 2:33 PM, Susan Hares wrote: > Joel: > > > > On #1) the dependency between I2RS Filter-based RIB (FB-RIB) and ECA, > please see draft-kini-i2rs-fb-rib-info-model-02.txt. In section 1.1, it > gives the definition of the FB-RIB. In section 1.2, it links this to an > event-condition-action model. If you disagree with the definition of I2= RS > FB-RIB, then we should probably restrict this conversation to the I2RS ma= il > list. Any feedback on the Info-model or data-model would be helpful. Th= e > authors hoped to go to a WG adoption call at the end of this week. > > > > One challenge for the ephemeral I2RS FB-RIB, is there is no definition of > the non-ephemeral FB-RIB. If you think there should be a non-ephemeral > FB-RIB =E2=80=93 that discussion may be useful between I2RS, Netmod and S= UPA. > > > > On #2) SUPA ECA model, I agree that we should be able to have a common > draft. At IETF 94, I raised issues regarding the SUPA versus my ECA > definition. > > > > Cheerily, > > > > Sue > > > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Monday, January 04, 2016 3:54 PM > To: Susan Hares; i2rs@ietf.org; netmod@ietf.org; supa@ietf.org > Subject: Re: [i2rs] FW: New Version Notification for > draft-hares-i2rs-bnp-eca-data-model-03.txt > > > > I think there are two issues here. > > > > 1) It is not clear to me why there is any dependence of the fb-rib data > model on an eca data model. While supa does allow for policy model to be > sent directly to the router, it also allows many other cases. > > > > 2) The approach with the supa eca data model is still under development. > > Having said that, the material in there is intended to be very general. > From what I understand, there should be no difficulty in refining the > action side of that model to actions which affect the fb-rib in ways that > are consistent with the fb-dib data model. > > > > Yours, > > Joel > > > > On 1/4/16 2:01 PM, Susan Hares wrote: > > > This model provides a Event-Condition-Action (ECA) policy model. > > > The I2RS FB-RIB yang data model utilizes this model, but to my > > > knowledge the Netmod or netconf has not adopted an ECA policy model to > > > parallel the ACL model. > > > > > > Chen and co-authors have created the model: > > > > > > draft-chen-supa-eca-data-model-05.txt > > > > > > But it does not align with this yang model or seem sufficient to > > > support the FB-RIB information model. At IETF 94, > > > I presented a discussion of the issues I found with the > > > draft-chen-supa-eca-data-model-05.txt, but it has not been updated. > > > We would appreciate feedback on this version of yang model. > > > > > > > > > In my role as I2RS chair, I2RS needs to make progress soon on the > > > I2RS FB-RIB data model. We would appreciate your aid. > > > > > > > > > Sue > > > > > > -----Original Message----- > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org > ] > > > Sent: Monday, January 04, 2016 12:04 PM > > > To: Susan Hares; Qin Wu; Russ White > > > Subject: New Version Notification for > > > draft-hares-i2rs-bnp-eca-data-model-03.txt > > > > > > > > > A new version of I-D, draft-hares-i2rs-bnp-eca-data-model-03.txt > > > has been successfully submitted by Susan Hares and posted to the IETF > repository. > > > > > > Name: draft-hares-i2rs-bnp-eca-data-model > > > Revision: 03 > > > Title: An Information Model for Basic Network Policy > and Filter Rules > > > Document date: 2016-01-04 > > > Group: Individual Submission > > > Pages: 30 > > > URL: > https://www.ietf.org/internet-drafts/draft-hares-i2rs-bnp-eca-data-model-= 03.txt > > > Status: > https://datatracker.ietf.org/doc/draft-hares-i2rs-bnp-eca-data-model/ > > > Htmlized: > https://tools.ietf.org/html/draft-hares-i2rs-bnp-eca-data-model-03 > > > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-hares-i2rs-bnp-eca-data-model-0= 3 > > > > > > Abstract: > > > This document contains the Basic Network Policy and Filters (BNP IM= ) > > > Data Model which provides a policy model that support an ordered li= st > > > of match-condition-action (aka event-condition-action (ECA)) for > > > multiple layers (interface, L1-L4, application) and other factors > > > (size of packet, time of day). The actions allow for setting actio= ns > > > (QOS and other), decapsulation, encapsulation, plus forwarding > > > actions. The policy model can be used with the I2RS filter-based > > > RIB. > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > > > The IETF Secretariat > > > > > > > > > _______________________________________________ > > > i2rs mailing list > > > i2rs@ietf.org > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > _______________________________________________ > Supa mailing list > Supa@ietf.org > https://www.ietf.org/mailman/listinfo/supa > > --=20 regards, John --001a11401eb20522780528a1f064 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sue,

> On #1) the dependency betw= een I2RS Filter-based RIB (FB-RIB) and
>=C2=A0ECA, please see draft-k= ini-i2rs-fb-rib-info-model-02.txt. In section 1.1,
> it gives the def= inition of the FB-RIB.

Sorry, it does NOT do this. To quote from this= section:

=C2=A0 =C2=A0A Filter Based RIB uses Even= t-Condition-Action policy. A Filter-
=C2=A0 =C2=A0based RIB entry speci= fies matches on fields in a packet (which may
=C2=A0 =C2=A0include layer= 2 fields, IP header fields, transport or application
=C2=A0 =C2=A0field= s) or size of the packet or interface received on. The matches
=C2=A0 = =C2=A0are contained in an ordered list of filters which contain pairs of=C2=A0=C2=A0 match condition-action (aka event-condition-action).

Please tell me WHERE the event is in the above definition. All I see i= s
a condition-action rule. (BTW, the analysis of PCIM and PCIMe is also<= br>not quite correct in your draft).

> In section 1.2, it links th= is to an event-condition-action model.

Sorry, it does NOT do this.

First, this section simply says, and I quote:

= =C2=A0=C2=A0 "The filter based-RIB uses event-condition-action policy = (ECA) rules."

That is a tautology at best.

Second, in Sect= ion 2, under the definition of FB-Route, the draft says:

=C2=A0=C2=A0= "The policy rules in the filter-based RIB are prescriptive of the
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Event-Condition-Action form which is often re= presented by
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if Condition the= n action."

Please note that this definition is= incorrect, and in conflict with SUPA.
The whole point of an EVENT-condi= tion-action policy rule is to define
a rule of the form:

=C2=A0=C2= =A0=C2=A0 IF <event_clause> evaluates to TRUE
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 IF <condition_clause evaluates to TRUE
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 THEN execut= e actions in <action_clause>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 ENDIF
=C2=A0=C2=A0=C2=A0 ENDIF

This definition has been est= ablished in the industry and academia
for at least 2 decades.

Vari= ations of the above have been defined and published (e.g.,
FOCALE has an= alternate set of actions to execute if the condition
clause evaluated t= o FALSE; this has NOT been proposed for SUPA
at this time). There have a= lso been extensions to handle sets and
groups, as well as specific order= ing (DEN-ng, SID, FOCALE).

Therefore, I would suggest that you change= your drafts to use a
condition-action policy rule, OR update the drafts= (I would be happy
to help) to use a correct definition of an ECA policy= rule.

regards,
John


On Mon, Jan 4, 2016 at 2:3= 3 PM, Susan Hares <shares@ndzh.com> wrote:

J= oel:

=C2=A0

On #1) the dependency = between I2RS Filter-based RIB (FB-RIB) and ECA, please see draft-kini-i2rs-= fb-rib-info-model-02.txt. In section 1.1, it gives the definition of the FB= -RIB.=C2=A0 In section 1.2, it links this to an event-condition-action mode= l.=C2=A0 If you disagree with the definition of =C2=A0I2RS FB-RIB, then we = should probably restrict this conversation to the I2RS mail list.=C2=A0 Any= feedback on the Info-model or data-model would be helpful.=C2=A0 The autho= rs hoped to go to a WG adoption call at the end of this week.

=C2=A0

One challenge for the ephemeral I2RS FB-= RIB, is there is no definition of the non-ephemeral FB-RIB.=C2=A0 If you th= ink there should be a non-ephemeral FB-RIB =E2=80=93 that discussion may be= useful between I2RS, Netmod and SUPA.

=C2=A0

On #2) SUPA ECA model, I agree that we should be able to have a= common draft.=C2=A0 At IETF 94, I raised issues regarding the SUPA versus = my ECA definition.=C2=A0 =C2=A0

=C2=A0

Cheerily,

=C2=A0

Sue

=C2=A0

-----Original Message-----
From: = Joel M. Halpern [mailto:jmh@joelhalpern.com]
Sent: Monday, January 04, 2016 3:54 PMTo: Susan Hares; i2rs@= ietf.org; netmod@i= etf.org; supa@ietf.o= rg
Subject: Re: [i2rs] FW: New Version Notification for draft-hares-= i2rs-bnp-eca-data-model-03.txt

=C2=A0

I think the= re are two issues here.

=C2=A0

1) I= t is not clear to me why there is any dependence of the fb-rib data model o= n an eca data model.=C2=A0 While supa does allow for policy model to be sen= t directly to the router, it also allows many other cases.

=C2=A0

2) The approach with the supa eca data model= is still under development.

=C2=A0=C2=A0Having said t= hat, the material in there is intended to be very general.=C2=A0 From what = I understand, there should be no difficulty in refining the action side of = that model to actions which affect the fb-rib in ways that are consistent w= ith the fb-dib data model.

=C2=A0

Y= ours,

Joel

=C2=A0

=

On 1/4/16 2:01 PM, Susan Hares wrote:

> This mode= l provides a Event-Condition-Action (ECA) policy model.

> The I2RS FB-RIB yang data model utilizes this model, but to my

> knowledge the Netmod or netconf has not adopted an ECA = policy model to

> parallel the ACL model.=

>=C2=A0

> Chen and co-authors have cre= ated the model:

>=C2=A0

> dra= ft-chen-supa-eca-data-model-05.txt

>=C2=A0=

> But it does not align with this yang model or seem sufficie= nt to

> support the FB-RIB information model.=C2=A0= =C2=A0 At IETF 94,

> I presented a discussion of the= issues I found with the

> draft-chen-supa-eca-data= -model-05.txt, but it has not been updated.

> We wou= ld appreciate feedback on this version of yang model.

&= gt;=C2=A0

> <i2rs Chair hat on><= /p>

> In my role as I2RS chair,=C2=A0 I2RS needs to make progress soon= on the

> I2RS FB-RIB data model.=C2=A0 We would ap= preciate your aid.

> <i2rs chair hat off>

>=C2=A0

> Sue

>=C2=A0

> -----Original Message-----

> From: internet-draft= s@ietf.org [mailto:in= ternet-drafts@ietf.org]

> Sent: Monday, J= anuary 04, 2016 12:04 PM

> To: Susan Hares; Qin Wu; = Russ White

> Subject: New Version Notification for <= u>

> draft-hares-i2rs-bnp-eca-data-model-03.txt<= u>

>=C2=A0

>=C2=A0

= > A new version of I-D, draft-hares-i2rs-bnp-eca-data-model-03.txt

> has been successfully submitted by Susan Hares and post= ed to the IETF repository.

>=C2=A0

=

> 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=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 draft-hares-i2rs-bnp-eca-data= -model

> Revision:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 03

> Title:=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 An Information Model for Basic Network Policy and Filter Rules=

> Document date:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 2016-01-04

> Group:=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Individual Submission

> Pages:=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 30

> URL:=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://w= ww.ietf.org/internet-drafts/draft-hares-i2rs-bnp-eca-data-model-03.txt

> Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 https://datatracker.ietf.org/doc/draft-hares-i2rs-bnp-eca-= data-model/

> Htmlized:=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 https://tools.ietf.org/html/draft-hares-i2rs-bnp-eca-da= ta-model-03

> Diff:=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org/rfcdi= ff?url2=3Ddraft-hares-i2rs-bnp-eca-data-model-03

>=C2=A0

> Abstract:

>= =C2=A0=C2=A0=C2=A0=C2=A0 This document contains the Basic Network Policy an= d Filters (BNP IM)

>=C2=A0=C2=A0=C2=A0=C2=A0 Data Mo= del which provides a policy model that support an ordered list

>=C2=A0=C2=A0=C2=A0=C2=A0 of match-condition-action (aka event-c= ondition-action (ECA)) for

>=C2=A0=C2=A0=C2=A0=C2=A0= multiple layers (interface, L1-L4, application) and other factors

>=C2=A0=C2=A0=C2=A0=C2=A0 (size of packet, time of day).=C2= =A0 The actions allow for setting actions

>=C2=A0=C2= =A0=C2=A0=C2=A0 (QOS and other), decapsulation, encapsulation, plus forward= ing

>=C2=A0=C2=A0=C2=A0=C2=A0 actions.=C2=A0 The pol= icy model can be used with the I2RS filter-based

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

>=C2=A0<= /p>

>=C2=A0

>=C2=A0

>= =C2=A0

> Please note that it may take a couple of minut= es from the time of submission until the htmlized version and diff are avai= lable at tools.ietf.org= .

>=C2=A0

> The IETF Secr= etariat

>=C2=A0

>=C2= =A0

> _______________________________________________

> i2rs mailing list

> i2rs@ietf.org

> https://www.ietf.org/mailman/l= istinfo/i2rs

>=C2=A0


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




--
regards,
John
--001a11401eb20522780528a1f064-- From nobody Wed Jan 6 01:30:39 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0901ACDF3; Wed, 6 Jan 2016 01:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRnXkjrWuDwG; Wed, 6 Jan 2016 01:30:35 -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 741361ACDF2; Wed, 6 Jan 2016 01:30:35 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B191710AC; Wed, 6 Jan 2016 10:30:33 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id qYvK7qQ0vCNZ; Wed, 6 Jan 2016 10:30:32 +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, 6 Jan 2016 10:30:32 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 48CB620056; Wed, 6 Jan 2016 10:30:32 +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 7o5G-nOXLh43; Wed, 6 Jan 2016 10:30: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 5147220055; Wed, 6 Jan 2016 10:30:30 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7025A397CAF4; Wed, 6 Jan 2016 10:30:29 +0100 (CET) Date: Wed, 6 Jan 2016 10:30:28 +0100 From: Juergen Schoenwaelder To: Eliot Lear Message-ID: <20160106093026.GB25431@elstar.local> Mail-Followup-To: Eliot Lear , Dean Bogdanovic , Nadeau Thomas , Benoit Claise , RTG YANG Design Team , netmod WG References: <20151211113156.GA43862@elstar.local> <2059AD77-5375-4DB0-A1BF-432835F11A9F@gmail.com> <20151221153312.GA43316@elstar.local> <568AB8AA.8070404@cisco.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: <568AB8AA.8070404@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Benoit Claise , RTG YANG Design Team , netmod WG Subject: Re: [netmod] [Rtg-dt-yang-arch] [yang-doctors] Working group Last Call: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 09:30:38 -0000 On Mon, Jan 04, 2016 at 07:23:38PM +0100, Eliot Lear wrote: > Hi Juergen, > > On this point: > > On 12/21/15 4:33 PM, Juergen Schoenwaelder wrote: > > > And > > should the interface reference not use a more specific type than > > 'string’? > >> Interface references can be many things, from standard naming we are familiar, e.g. ge-1/0/0.1 to a numerical value like 13276. Leaving it as string gives us most flexibility in that regards. > > I disagree that the goal here is most flexibility. We do have an > > interfaces data model in the IETF. Why are we avoiding to refer to it > > here? > > > > I think it would be helpful if you could be specific as to your > concern. It is absolutely the case that the SNMP folk did an awful lot > of work on managing interfaces. While I am not concerned about the form > of the name, I wonder if your concern is around some of the semantics, > but I can't tell. > My question is why the model does not use interface-ref or interface-state-ref defined in RFC 7223 but instead an opaque string to refer to an interface. Have we thought about the design tradeoffs? My question is _not_ about how we deal with interface naming schemes, that discussion took place when RFC 7223 was created. /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 6 06:12:51 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB12F1B2BE6; Wed, 6 Jan 2016 06:12:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.257 X-Spam-Level: X-Spam-Status: No, score=-96.257 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5VieYiYdxSM; Wed, 6 Jan 2016 06:12:45 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 7AC511ACE6B; Wed, 6 Jan 2016 06:12:44 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.177; From: "Susan Hares" To: "'John Strassner'" , "'Joel M. Halpern'" References: <20160104170330.13929.73845.idtracker@ietfa.amsl.com> <006701d14722$616c6950$24453bf0$@ndzh.com> <568ADBE7.3030101@joelhalpern.com> In-Reply-To: Date: Wed, 6 Jan 2016 09:12:57 -0500 Message-ID: <03c101d1488c$587503a0$095f0ae0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03C2_01D14862.6FA51620" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHC7aVhYcGa1ChTuo//84M/O+4YZwFG1DOWAZ3SDjgCrQyIcJ7eqKQQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, netmod@ietf.org, supa@ietf.org Subject: Re: [netmod] [Supa] [i2rs] FW: New Version Notification for draft-hares-i2rs-bnp-eca-data-model-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 14:12:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03C2_01D14862.6FA51620 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable John:=20 =20 Thank you for your response. For filter-based FIB,=20 =20 Event =3D receiving packet information on the interface=20 Condition =3D match on a variety of conditions (see the draft)=20 Action =3D a choice of actions modify packet, forward/drop packet, and = count packet. =20 You are correct, it is a very simple case, with one type of event. = Joel indicated flaws in the document that it did not indicate the event = was a =E2=80=9Cpacket reception=E2=80=9D. At this point, it sounds like = you and Joel are suggesting that this particular simplistic case of = Event-Condition-Action is OK to go forward with in the I2RS (for = ephemeral state), and in appropriate WG for the non-ephemeral case. Is = this correct?=20 =20 At IETF 94, I was simply comparing Chen=E2=80=99s document versus this = very simple case of an ECA. I did not mean to imply it was the only = possible ECA case. I look forward to hearing from the SUPA list = regarding the generic ECA information model and the different types of = ECA. =20 =20 Sue=20 =20 From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of John Strassner Sent: Tuesday, January 05, 2016 10:12 PM To: Joel M. Halpern Cc: i2rs@ietf.org; supa@ietf.org; netmod@ietf.org; Susan Hares Subject: Re: [Supa] [i2rs] FW: New Version Notification for = draft-hares-i2rs-bnp-eca-data-model-03.txt =20 Hi Joe, et al., =20 > 1) It is not clear to me why there is any dependence of the fb-rib > data model on an eca data model. While supa does allow for=20 > policy model to be sent directly to the router, it also allows many > other cases. =20 Exactly. More particularly, in scanning this draft, I fail to see how this is an accepted definition of ECA. In particular, there doesn't seem to be any event in the rule definition. =20 Hence, I would suggest that you add wording that says that this is one of many ways to build such a mapping. =20 =20 > 2) The approach with the supa eca data model is still under > development. =20 Absolutely agree. In particular, draft-chen was the first attempt at trying to conceptualize what such a data model should look like. =20 > Having said that, the material in there is intended to be very > general. =20 IFF you mean the SUPA info model, then absolutely (otherwise, it has failed in its primary mission of providing an extensible framework to define policies). =20 IFF you mean draft-chen, then I think it agrees with the spirit of what you said. I think that we need to discuss how to map from an info model to a data model in more detail before we come to any conclusions of its efficacy. =20 > From what I understand, there should be no difficulty in > refining the action side of that model to actions which affect > the fb-rib in ways that are consistent with the fb-dib data model. =20 +1. In fact, the whole point of SUPA is to provide different ways of forming an ECA policy rule to meet different demands of the user. More particularly, at IETF94, you (Sue) assumed that an ECA policy rule was made up of Event, Condition, and Action objects. While that is certainly one alternative, there are others as well. In addition, please note that the presence of these objects is NOT sufficient to build an ECA policy rule (e.g., the Event object needs an attribute (or multiple attributes) to be=20 compared to something in order to determine if the event=20 CLAUSE evaluates to TRUE or not. =20 =20 regards, John =20 On Mon, Jan 4, 2016 at 12:53 PM, Joel M. Halpern = wrote: I think there are two issues here. 1) It is not clear to me why there is any dependence of the fb-rib data = model on an eca data model. While supa does allow for policy model to = be sent directly to the router, it also allows many other cases. 2) The approach with the supa eca data model is still under development. = Having said that, the material in there is intended to be very general. = From what I understand, there should be no difficulty in refining the = action side of that model to actions which affect the fb-rib in ways = that are consistent with the fb-dib data model. Yours, Joel On 1/4/16 2:01 PM, Susan Hares wrote: This model provides a Event-Condition-Action (ECA) policy model. The I2RS FB-RIB yang data model utilizes this model, but to my knowledge = the Netmod or netconf has not adopted an ECA policy model to parallel the ACL model. Chen and co-authors have created the model: draft-chen-supa-eca-data-model-05.txt But it does not align with this yang model or seem sufficient to support the FB-RIB information model. At IETF 94, I presented a discussion of the issues I found with the draft-chen-supa-eca-data-model-05.txt, but it has not been updated. We would appreciate feedback on this version of yang model. In my role as I2RS chair, I2RS needs to make progress soon on the I2RS FB-RIB data model. We would appreciate your aid. Sue -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, January 04, 2016 12:04 PM To: Susan Hares; Qin Wu; Russ White Subject: New Version Notification for = draft-hares-i2rs-bnp-eca-data-model-03.txt A new version of I-D, draft-hares-i2rs-bnp-eca-data-model-03.txt has been successfully submitted by Susan Hares and posted to the IETF = repository. Name: draft-hares-i2rs-bnp-eca-data-model Revision: 03 Title: An Information Model for Basic Network Policy and Filter = Rules Document date: 2016-01-04 Group: Individual Submission Pages: 30 URL: = https://www.ietf.org/internet-drafts/draft-hares-i2rs-bnp-eca-data-model-= 03.txt Status: = https://datatracker.ietf.org/doc/draft-hares-i2rs-bnp-eca-data-model/ Htmlized: = https://tools.ietf.org/html/draft-hares-i2rs-bnp-eca-data-model-03 Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-hares-i2rs-bnp-eca-data-model-0= 3 Abstract: This document contains the Basic Network Policy and Filters (BNP IM) Data Model which provides a policy model that support an ordered = list of match-condition-action (aka event-condition-action (ECA)) for multiple layers (interface, L1-L4, application) and other factors (size of packet, time of day). The actions allow for setting = actions (QOS and other), decapsulation, encapsulation, plus forwarding actions. The policy model can be used with the I2RS filter-based RIB. Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. The IETF Secretariat _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ Supa mailing list Supa@ietf.org https://www.ietf.org/mailman/listinfo/supa --=20 regards, John ------=_NextPart_000_03C2_01D14862.6FA51620 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

John:

 

Thank you for your response. =C2=A0=C2=A0For filter-based FIB, =

 

Event =3D receiving packet information on the interface =

Condition =3D match on a variety of conditions (see the draft) =

Action =3D a choice of actions modify packet, forward/drop packet, = and count packet.

 

You are correct, it is a very simple case, with one type of event. = =C2=A0=C2=A0Joel indicated flaws in the document that it did not = indicate the event was a =E2=80=9Cpacket reception=E2=80=9D.=C2=A0 At = this point, it sounds like you and Joel are suggesting that this = particular simplistic case of Event-Condition-Action is OK to go forward = with in the I2RS (for ephemeral state), and in appropriate WG for the = non-ephemeral case.=C2=A0 Is this correct?

 

At IETF 94, I was simply comparing Chen=E2=80=99s document versus = this very simple case of an ECA. =C2=A0I did not mean to imply it was = the only possible ECA case.=C2=A0 =C2=A0I look forward to hearing from = the SUPA list regarding the generic ECA information model and the = different types of ECA. =C2=A0

 

Sue

 

From:= = Supa [mailto:supa-bounces@ietf.org] On Behalf Of John = Strassner
Sent: Tuesday, January 05, 2016 10:12 = PM
To: Joel M. Halpern
Cc: i2rs@ietf.org; = supa@ietf.org; netmod@ietf.org; Susan Hares
Subject: Re: = [Supa] [i2rs] FW: New Version Notification for = draft-hares-i2rs-bnp-eca-data-model-03.txt

 

Hi = Joe, et al.,

 

> 1) It is not clear to me why there is any = dependence of the fb-rib

> data model on an eca data model.  While = supa does allow for

> = policy model to be sent directly to the router, it also allows = many

> other = cases.

 

Exactly. More particularly, in scanning this draft, I = fail to see how

this is an = accepted definition of ECA. In particular, there = doesn't

seem to be any = event in the rule definition.

 

Hence, I would suggest that you add wording that says = that this is

one of many = ways to build such a mapping.

 

 

> 2) The approach with the supa eca data model = is still under

> development.

 

Absolutely agree. In particular, draft-chen was the = first attempt at

trying to = conceptualize what such a data model should look = like.

 

>  Having said that, the material in there is = intended to be very

> general.

 

IFF you mean the SUPA info model, then absolutely = (otherwise,

it has failed = in its primary mission of providing an = extensible

framework to = define policies).

 

IFF you mean draft-chen, then I think = it agrees with the spirit of

what you said. I think that we need to discuss how to = map from

an info model to = a data model in more detail before we come = to

any conclusions of its = efficacy.

 

>  From what I understand, there should be no = difficulty in

> refining the action side of that model to = actions which affect

> the fb-rib in ways that are consistent with = the fb-dib data model.

 

+1. In fact, the whole point of SUPA is to provide = different ways

of forming = an ECA policy rule to meet different demands of = the

user. More = particularly, at IETF94, you (Sue) assumed that = an

ECA policy rule was = made up of Event, Condition, and Action

objects. While that is certainly one alternative, = there are others

as well. = In addition, please note that the presence of = these

objects is NOT = sufficient to build an ECA policy rule (e.g., = the

Event object needs an = attribute (or multiple attributes) to be

compared to something in order to determine if the = event

CLAUSE evaluates to = TRUE or not.

 

 

regards,

John

 

On Mon, = Jan 4, 2016 at 12:53 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:

I think there are two issues here.

1) It is not = clear to me why there is any dependence of the fb-rib data model on an = eca data model.  While supa does allow for policy model to be sent = directly to the router, it also allows many other cases.

2) The = approach with the supa eca data model is still under development.  = Having said that, the material in there is intended to be very = general.  From what I understand, there should be no difficulty in = refining the action side of that model to actions which affect the = fb-rib in ways that are consistent with the fb-dib data = model.

Yours,
Joel

On 1/4/16 2:01 PM, Susan Hares = wrote:

This model provides a = Event-Condition-Action (ECA) policy model.
The I2RS FB-RIB yang data = model utilizes this model, but to my knowledge the
Netmod or netconf = has not adopted an ECA policy model to
parallel the ACL = model.

Chen and co-authors have created the = model:

draft-chen-supa-eca-data-model-05.txt

But it does = not align with this yang model or seem sufficient to
support the = FB-RIB information model.   At IETF 94,
I presented a = discussion of the issues I found with = the
draft-chen-supa-eca-data-model-05.txt, but it has not been = updated.
We would appreciate feedback on this version of yang = model.

<i2rs Chair hat on>
In my role as I2RS = chair,  I2RS needs to make progress soon on the
I2RS FB-RIB data = model.  We would appreciate your aid.
<i2rs chair hat = off>

Sue

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Monday, January = 04, 2016 12:04 PM
To: Susan Hares; Qin Wu; Russ White
Subject: New = Version Notification for = draft-hares-i2rs-bnp-eca-data-model-03.txt


A new version of = I-D, draft-hares-i2rs-bnp-eca-data-model-03.txt
has been successfully = submitted by Susan Hares and posted to the IETF = repository.

Name:          =  draft-hares-i2rs-bnp-eca-data-model
Revision:    =    03
Title:          An = Information Model for Basic Network Policy and Filter Rules
Document = date:  2016-01-04
Group:          = Individual Submission
Pages:          = 30
URL:            https://www.ietf.org/internet-drafts/draft-hares-i2rs-b= np-eca-data-model-03.txt
Status:        =  https://datatracker.ietf.org/doc/draft-hares-i2rs-bnp-e= ca-data-model/
Htmlized:       https://tools.ietf.org/html/draft-hares-i2rs-bnp-eca-da= ta-model-03
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-hares-i2rs-bn= p-eca-data-model-03

Abstract:
    This document = contains the Basic Network Policy and Filters (BNP IM)
    = Data Model which provides a policy model that support an ordered = list
    of match-condition-action (aka = event-condition-action (ECA)) for
    multiple layers = (interface, L1-L4, application) and other factors
    (size = of packet, time of day).  The actions allow for setting = actions
    (QOS and other), decapsulation, encapsulation, = plus forwarding
    actions.  The policy model can be = used with the I2RS filter-based
    = RIB.




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

The IETF = Secretariat


_______________________________________________i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs


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




-- =

regards,

John

------=_NextPart_000_03C2_01D14862.6FA51620-- From nobody Wed Jan 6 08:00:07 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B531C1B2C1D; Wed, 6 Jan 2016 08:00:01 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRt6tf_-pPHT; Wed, 6 Jan 2016 07:59:58 -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 80C111B2BFB; Wed, 6 Jan 2016 07:59:58 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id b14so81933183wmb.1; Wed, 06 Jan 2016 07:59:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7iPSxNeTtoQaMmgyfzOefPPpBcxiR45l4KDRHtwkpIk=; b=Tvi9Rijtb+1Qq1+M7kCPTT82Hi8kag1QwfdPWvT5V2/rbnQQUUHJ3gZbSecVQgbyfp s6Rm76y/a30eOJ1fS6+eTVhsr0yMzIRGKqjDZQK8rcnfIZZxw1odf5ypnWi2neqcbm6Z Sp5oi0731Z76k1wXqK4IEc6JptQIojNZqby3+3lW0W5DZCZTf4DON9znfvEVdvLmfajV NxITKl726HyEdi8PK3dxGh1V17hYbhGLWTrsBsGZHMRhtuNG8nj1g1w4DlwyOPcItQuf T4N90RIf+4O4EO3WxEPteMGFn1cJdyRZRvYhGp0CDVxrnBkcUxAhsI370Vfbrs7USn21 Imdw== X-Received: by 10.28.182.135 with SMTP id g129mr11733683wmf.55.1452095997083; Wed, 06 Jan 2016 07:59:57 -0800 (PST) Received: from [192.168.254.198] ([147.83.206.82]) by smtp.gmail.com with ESMTPSA id w73sm9305167wmw.21.2016.01.06.07.59.55 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 06 Jan 2016 07:59:56 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dean Bogdanovic In-Reply-To: <568AE314.4080401@cisco.com> Date: Wed, 6 Jan 2016 16:59:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <131CFB2F-429A-4FC2-95CE-EF616B969145@gmail.com> References: <5672BAD7.2080003@cisco.com> <1B2DACE1-A8F0-493B-8B61-EF6321790ECE@lucidvision.com> <5672CA38.4060709@cisco.com> <4A6F06C5-7198-4FCA-A10C-0377F595D704@gmail.com> <568AE314.4080401@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.3112) Archived-At: Cc: RTG YANG Design Team , netmod WG , Benoit Claise Subject: Re: [netmod] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 16:00:01 -0000 > On Jan 4, 2016, at 10:24 PM, Eliot Lear wrote: >=20 > Hi, >=20 > I guess what I'm hearing is that we should do a hopefully very short > augmentation for domain names in the matches clause and standardize = that > separately. Does that seem reasonable? Yes, if you think there is a need for such a draft and IPR issue is = cleared, WG adopts it, why not Dean >=20 > Eliot >=20 > On 12/19/15 2:05 PM, Dean Bogdanovic wrote: >> The basic design idea for the base model is structure that all = vendors support. Some of the examples mentioned below, like FQDN, are = not supported by all vendors and are protected by IPR (which I wasn=E2=80=99= t aware of it). There are many possible match conditions that could be = added to the base model, like Auth header in IPSec or IPSec = encapsulation security payload to keep it with security. There are many = match conditions in Class of Services as well. All these match = conditions would have created more issues to come to consensus about the = base model, so for that reason we went with the minimal model that would = be easy for all vendors to implement. >>=20 >> Dean >>=20 >>> On Dec 18, 2015, at 5:21 PM, Sterne, Jason (Jason) = wrote: >>>=20 >>> I'm not a fan of adding something like that in the base model. = Let's get a basic model done and then we can consider an extension = draft. I'd think that things like TCP flags, for example, would be a = more natural & common thing to add to an ACL model than a host name = match so I can't see host name being in there before TCP flags (which = I'm not advocating for in the base model). >>>=20 >>> I also don't think the metadata interface match should be in this = base model either. That is out of place IMO. The base model provides = an ACL that can then get associated with objects like interfaces (as in = the example in section A.3) >>> I'd also suggest we consider making the actions 'deny' and 'permit' = presence containers instead of empty leafs. That would allow easier = augmentations (e.g. additional 'permit' parameters for policy based = forwarding for example). >>>=20 >>> Regards, >>> Jason >>>=20 >>> -----Original Message----- >>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Nadeau = Thomas >>> Sent: Thursday, December 17, 2015 10:53 >>> To: Lear Eliot >>> Cc: Benoit Claise; RTG YANG Design Team; netmod WG >>> Subject: Re: [netmod] Working group Last Call: = draft-ietf-netmod-acl-model-06 >>>=20 >>>=20 >>> You raise a good point. Do the contributors/editors have any = thoughts on this suggestion? >>>=20 >>> =E2=80=94Tom >>>=20 >>>=20 >>>> On Dec 17, 2015:9:44 AM, at 9:44 AM, Eliot Lear = wrote: >>>>=20 >>>>=20 >>>>=20 >>>> On 12/17/15 2:45 PM, Nadeau Thomas wrote: >>>>> Do you mean an ASCII DNS name (versus an IP address w a mask)? >>>> I was thinking of "host" in RFC 6021. >>>>=20 >>>> Eliot >>>>=20 >>>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> _______________________________________________ >>> Rtg-dt-yang-arch mailing list >>> Rtg-dt-yang-arch@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch >>=20 >=20 >=20 From nobody Wed Jan 6 08:03:37 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F511B2B8B for ; Wed, 6 Jan 2016 08:03:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39aY1XJtxZDk for ; Wed, 6 Jan 2016 08:03:28 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0129.outbound.protection.outlook.com [65.55.169.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 198BA1B2C60 for ; Wed, 6 Jan 2016 08:03:20 -0800 (PST) Received: from BY1PR0501MB1605.namprd05.prod.outlook.com (10.160.203.154) by BY1PR0501MB1607.namprd05.prod.outlook.com (10.160.203.156) with Microsoft SMTP Server (TLS) id 15.1.361.13; Wed, 6 Jan 2016 16:03:18 +0000 Received: from BY1PR0501MB1605.namprd05.prod.outlook.com ([10.160.203.154]) by BY1PR0501MB1605.namprd05.prod.outlook.com ([10.160.203.154]) with mapi id 15.01.0361.006; Wed, 6 Jan 2016 16:03:18 +0000 From: Gert Grammel To: Robert Wilton Thread-Topic: [netmod] netmod-opstate-reqs and error option terms (rollback on error) Thread-Index: AQHRR8pu4DRwZNkgdE+qlT203xB9S57ukwZQ Date: Wed, 6 Jan 2016 16:03:18 +0000 Message-ID: References: <56784B9B.5020408@cisco.com> <327E370C-4D5F-4F9A-B982-B71108CEBC08@juniper.net> <567A5B39.3010909@wilton.org.uk> <567B1129.9090104@wilton.org.uk> <5CB86359-D6B1-4D84-962C-750A8D7AE174@juniper.net> <568BDB95.4060203@cisco.com> In-Reply-To: <568BDB95.4060203@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; x-originating-ip: [193.110.55.12] x-microsoft-exchange-diagnostics: 1; BY1PR0501MB1607; 5:IMcjXaC6HEJ/Szw3wrHZX7kzLZg4KHFbnfkkF5IJ/FQB4ztOy+yK8T1+eKrLSGmWTvKqTGMDAvJcSs28lQcoLnMhNytQZw9bZ3gK6Q3FqjCrOfxCJqPjSvrc8ivn/XteltnxJLQqUg5il1875TOryg==; 24:xyx4AOwUt8OhgdyGRpoJtoYhlui3fBZFT7qt23+Q2yujmTVMzruWlzk0kCHPZ5ncgc+5LXyeg+StpHayufafabVcecWiZZ47ILbUZUZulA4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1607; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:BY1PR0501MB1607; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1607; x-forefront-prvs: 0813C68E65 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(24454002)(164054003)(51444003)(479174004)(199003)(102836003)(86362001)(2950100001)(16236675004)(19625215002)(586003)(5008740100001)(6116002)(97736004)(2900100001)(3846002)(230783001)(92566002)(790700001)(11100500001)(93886004)(19580405001)(5003600100002)(81156007)(110136002)(50986999)(106356001)(1096002)(5002640100001)(106116001)(551934003)(105586002)(99286002)(19580395003)(4326007)(1220700001)(15975445007)(19300405004)(77096005)(122556002)(66066001)(54356999)(19617315012)(74316001)(76176999)(33656002)(5004730100002)(189998001)(76576001)(40100003)(5001960100002)(101416001)(87936001)(10400500002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1607; H:BY1PR0501MB1605.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:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY1PR0501MB1605CBBB80B314C184B4653BCEF40BY1PR0501MB1605_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2016 16:03:18.0157 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1607 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 16:03:36 -0000 --_000_BY1PR0501MB1605CBBB80B314C184B4653BCEF40BY1PR0501MB1605_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rob, See below ... --Gert From: Robert Wilton [mailto:rwilton@cisco.com] Sent: 05 January 2016 16:05 To: Gert Grammel Cc: netmod@ietf.org Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback = on error) Hi Gert, Considering a rollback-on-error request that failed: If you leave the configuration in intended config then what happens if a se= parate config request comes in from another client? Should that request be= processed in the context of the failed intended config, or the last succes= sful config change, or must it wait for the original client to decide how t= o process the failure that occurred? Gert> If a client is has the intention to update/change a config, its decis= ion is based on the present state of the configuration when the decision is= taken. Ideally the present configuration is in a state where intended =3D= =3D applied config, so there is stable ground upon which a change is applie= d. However there is also the case where intended !=3D applied config and th= ere are two reasons for that. a) a previous intended config is in the process of being applied b) a previous configuration failed due to an error In case a) the following config just needs to wait, or if it can be applied= without interfering with the previous intended config *may* be executed in= parallel (up to the server to implement) Case b) is just about the same as stop-on-error or continue-on-error. If th= ere is an error in configuring a node and the new intended config uses stop= -on-error, then it should not be executed. In contrast, a continue-on-error= configuration can be applied independently. Also what would happen if the client disconnects from the server when a rol= lback-on-error request has failed, and the server is waiting for the client= to tell it what to do? Gert> the previous (rolled-back) configuration is applied and the intended = config remains different from the applied config. It will stay like that un= til the Client figured out what to do. E.g. one option is to re-apply the i= ntended config with a continue-on-error semantic. If a second client, despi= te the server calamities, decides to change the config, it can try to do so= in a continue-on-error mode as well. I think that what you describe sounds more like a config request to a candi= date configuration datastore. I.e. write the config to candidate, and then= commit. If the commit fails, the configuration in the running datastore i= s rolled back but the configuration remains in the candidate datastore. Bu= t note that in this scenario both the intended and applied configuration ha= ve both been reverted to the state before the commit operation was attempte= d. Gert> bear with me but I don't parse the two sentences as they seem contrad= ictory. Perhaps you could spend a few more words. I am advocating for a case with a consistent behavior in case of failures i= n all execution models. Irrespective of stop-on-error, continue-on-error or= rollback-on-error, the non-performing configuration is the diff between in= tended and applied configuration that can conveniently be reported by the s= erver. In any of those cases, the server is rightfully in an errored state = with respect to configuration and it is risky to attempt a new configuratio= n unless the client resolves the misalignment. It appears to me that we hav= e broadly 3 failure cases to deal with: 1) The client did a poor job in figuring out which configuration to pu= sh on a server 2) The server did a poor job in reporting its own state to the client = (see cheating synchronous), which in turn can lead to 1) 3) Something unexpected happens in between the client figuring out the= intended config and the server applying it. Case 1) can only be dealt by the Client. 2) is often dealt with re-applying= the same intended config a bit later, hoping the server is in a better moo= d now (by experience it often works). If it still doesn't, it's again up to= the client to figure out what's best now. Since the event in 3) may impact= the state of the node quite a bit, also here it is the job of the client t= o figure out which config to apply based on the new state. Thanks, Rob On 28/12/2015 17:40, Gert Grammel wrote: Rob, >From a client perspective there should be no difference in the intended sta= te behavior depending on error conditions, if continue-on-error leaves the = intended state, a rollback-on-error should keep it as well. Moreover, a cli= ent reaction on a unsuccessful application of intended state could be to a)= re-try, b) retry with continue-on-error or c) retry wit stop-on-error. Tho= se actions would not require any change of intended state. It shouldn't be the server to decide what the intended state is supposed to= be or hoe long it should last. Gert Sent from my Apple ][ On 23 Dec 2015, at 22:25, Robert Wilton > wrote: Hi Gert, Please see one comment inline ... On 23/12/2015 10:24, Gert Grammel wrote: Rob, Kent, Adding to Rob's comments: From: netmod > on b= ehalf of Robert Wilton > Date: Wednesday 23 December 2015 09:28 To: Kent Watsen >, "netmod@= ietf.org" > Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback = on error) Hi Kent, Yes, I think that we are in agreement. I've one further comment inline below ... On 23/12/2015 02:41, Kent Watsen wrote: [As a contributor] Hi Robert, I want to go back to Jason's original questions. I think we're = aligned on this, but please check my answers below. Quoting Jason's original text now: Is there some intention in the opstate requirements to add some sort of all-or-nothing behavior to transition (C)? Yes +1 (if rollback-on-error has been requested) i.e. if some part of an edit fails during the transition from intended->applied we should "rollback" the other parts that may have already been applied ? Yes +1 (if rollback-on-error has been requested) Would we then remove it all from intended as well ? IMO, yes. This is more easily understood when thinking about Synchronous C= onfiguration Operations (defined in opstate-reqs), but I believe that it eq= ually applies to Asynchronous Configuration Operations, so long as the clie= nt explicitly ops-in for the behavior. IMO no. The intended config is imposed by the client to the server and othe= r than performing some syntax check, the server has no choice to accept it = as-is. If the server can't apply the intended config, obviously the mismatc= h between intended and applied config needs to be notified. As a result, it= is up to the client to decide what to do. Actions can vary according to th= e situation naming a few: 1) retry intended config, 2) retry intended confi= g with continue-on-error, 3) re-apply the previous intended config, ... In other words: 1. the client shall not touch the applied config directly, 2. the server shall not touch the intended config, 3. it's up to the server to align the intended with the applied config i= n a way requested by the client (i.e. rollback-on-error, ...) 4. Once applied, the server notifies the client about success or failure= to do so I think that it cleaner just to fail and roll back the entire request (both= intended and applied), i.e. effectively implementing default transaction s= emantics. The client still has full control as to what to do after the fai= lure has occurred. I'm not sure how leaving it in intended config would pr= agmatically work with subsequent requests that may have been queued up. Thanks, Rob _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_000_BY1PR0501MB1605CBBB80B314C184B4653BCEF40BY1PR0501MB1605_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Rob,=

 <= /p>

See below …

 <= /p>

--Gert<= /p>

 <= /p>

From: Robert Wilton [mailto:rwilton@cisco.com]
Sent: 05 January 2016 16:05
To: Gert Grammel
Cc: netmod@ietf.org
Subject: Re: [netmod] netmod-opstate-reqs and error option terms (ro= llback on error)

 

Hi Gert,

Considering a rollback-on-error request that failed:

If you leave the configuration in intended config then what happens if a se= parate config request comes in from another client?  Should that reque= st be processed in the context of the failed intended config, or the last s= uccessful config change, or must it wait for the original client to decide how to process the failure that occurred= ?

Gert> If a client is has the intention to update/change a config, = its decision is based on the present state of the configuration when the decision is taken. Ideally the present configuration is in a stat= e where intended =3D=3D applied config, so there is stable ground upon whic= h a change is applied. However there is also the case where intended !=3D a= pplied config and there are two reasons for that.

a)  &= nbsp;   a previous intend= ed config is in the process of being applied

b)  &= nbsp;   a previous config= uration failed due to an error

In case a) the following config just needs to wait, or if it can b= e applied without interfering with the previous intended config *may= * be executed in parallel (up to the server to implement)

Case b) is just about the same as stop-on-error or continue-on-err= or. If there is an error in configuring a node and the new intended config = uses stop-on-error, then it should not be executed. In contrast, a continue-on-error configuration can be applied= independently.

Also what would happen if the client disconnects from the server when a rol= lback-on-error request has failed, and the server is waiting for the client= to tell it what to do?
Gert> the previous (rolled-back) configura= tion is applied and the intended config remains different from the applied = config. It will stay like that until the Client figured out what to do. E.g= . one option is to re-apply the intended config with a continue-on-error semantic. If a second client, despite the = server calamities, decides to change the config, it can try to do so in a c= ontinue-on-error mode as well.


I think that what you describe sounds more like a config request to a candi= date configuration datastore.  I.e. write the config to candidate, and= then commit.  If the commit fails, the configuration in the running d= atastore is rolled back but the configuration remains in the candidate datastore.  But note that in this scenario b= oth the intended and applied configuration have both been reverted to the s= tate before the commit operation was attempted.

Gert> bear with me but I don’t parse the two sentences as th= ey seem contradictory. Perhaps you could spend a few more words.

I am advocating for a case with a consistent behavior in case of fail= ures in all execution models. Irrespective of stop-on-error, continue-on-error or rollback-on-error, the non-performing configuration i= s the diff between intended and applied configuration that can conveniently= be reported by the server. In any of those cases, the server is rightfully= in an errored state with respect to configuration and it is risky to attempt a new configuration unless the= client resolves the misalignment. It appears to me that we have broadly 3 = failure cases to deal with:

1)  &= nbsp;   The client did a = poor job in figuring out which configuration to push on a server=

2)  &= nbsp;   The server did a = poor job in reporting its own state to the client (see cheating synchronous= ), which in turn can lead to 1)

3)  &= nbsp;   Something unexpec= ted happens in between the client figuring out the intended config and the = server applying it.

Case 1) can only be dealt by the Client. 2) is often dealt with re= -applying the same intended config a bit later, hoping the server is in a b= etter mood now (by experience it often works). If it still doesn’t, it’s again up to the client to fi= gure out what’s best now. Since the event in 3) may impact the state = of the node quite a bit, also here it is the job of the client to figure ou= t which config to apply based on the new state.   

Thanks,
Rob

On 28/12/2015 17:40, Gert Grammel wrote:<= /p>

Rob,

 

From a client perspective there should be no differe= nce in the intended state behavior depending on error conditions, if contin= ue-on-error leaves the intended state, a rollback-on-error should keep it a= s well. Moreover, a client reaction on a unsuccessful application of intended state could be to a) re-try, b) = retry with continue-on-error or c) retry wit stop-on-error. Those actions w= ould not require any change of intended state.

It shouldn't be the server to decide what the intend= ed state is supposed to be or hoe long it should last. 

 

Gert



Sent from my Apple ][


On 23 Dec 2015, at 22:25, Robert Wilton <robert.public@wilton.org.uk> wrote:

Hi Gert,

Please see one comment inline ...

On 23/12/2015 10:24, Gert Grammel wrote:

Rob, Kent,

 

Adding to Rob’s comments:

 

 

 

From: netmod <netmod-bounces@ietf.org> on behalf of Robert Wilton <robert.public@wilton.org.uk>=
Date: Wednesday 23 December 2015 09:28
To: Kent Watsen <kwatsen@j= uniper.net>, "netmod@ietf.or= g" <netmod@ietf.org><= br> Subject: Re: [netmod] netmod-opstate-reqs and error option terms (ro= llback on error)

 

Hi Kent,

 

Yes, I think that we are in agreement.

 

I've one further comment inline below ...=

 

On 23/12/2015 02:41, Kent Watsen wrote:

[As a contributor]

 

Hi Robert, I want to go back to Jason’s origin= al questions.  I think we’re aligned on this, but please ch= eck my answers below.

 

Quoting Jason’s original text now:<= /p>

 

 

Is there some intention in the opstate requirements = to add some sort

of all-or-nothing behavior to transition (C)?

Yes

+1 (if rollback-on-error has been requested)

 

 

 

i.e. if some part of

an edit fails during the transition from intended-&g= t;applied we should

"rollback" the other parts that may have a= lready been applied ?

Yes

+1 (if rollback-on-error has been requested)

 

 

Would we then remove it all from intended as well ?<= o:p>

IMO, yes.  This is more easily understood = when thinking about Synchronous Configuration Operations (defined in opstat= e-reqs), but I believe that it equally applies to Asynchronous Configuratio= n Operations, so long as the client explicitly ops-in for the behavior.

IMO no. The intended config is imposed by the client= to the server and other than performing some syntax check, the server has = no choice to accept it as-is. If the server can’t apply the intended = config, obviously the mismatch between intended and applied config needs to be notified. As a result, it is up to the clie= nt to decide what to do. Actions can vary according to the situation naming= a few: 1) retry intended config, 2) retry intended config with continue-on= -error, 3) re-apply the previous intended config, …

In other words: 

  1. the client shall not touch the applied config directly, 
  2. the server shall not touch the intended config, 
  3. it’s up to the server to align the intended with the applied config i= n a way requested by the client (i.e. rollback-on-error, …)
  4. Once applied, the server notifies the client about success or failure to do= so

I think that it clean= er just to fail and roll back the entire request (both intended and applied= ), i.e. effectively implementing default transaction semantics.  The c= lient still has full control as to what to do after the failure has occurred.  I'm not sure how leaving it in in= tended config would pragmatically work with subsequent requests that may ha= ve been queued up.

Thanks,
Rob




_______________________________________________
netmod mailing list
netmod@ietf.org

https://www.i=
etf.org/mailman/listinfo/netmod

 

--_000_BY1PR0501MB1605CBBB80B314C184B4653BCEF40BY1PR0501MB1605_-- From nobody Wed Jan 6 08:43:36 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394081B2B4E for ; Wed, 6 Jan 2016 08:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvx196kgvmzH for ; Wed, 6 Jan 2016 08:43:23 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0761.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::761]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A4F71A8840 for ; Wed, 6 Jan 2016 08:43:22 -0800 (PST) Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1602.namprd05.prod.outlook.com (10.161.217.19) with Microsoft SMTP Server (TLS) id 15.1.361.13; Wed, 6 Jan 2016 16:43: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.0361.006; Wed, 6 Jan 2016 16:43:04 +0000 From: Kent Watsen To: Gert Grammel , Robert Wilton Thread-Topic: [netmod] netmod-opstate-reqs and error option terms (rollback on error) Thread-Index: AQHRPCF5wOz/ziSgLkOMFH9D1Q78057Xis8AgAC0yYCAACBCAIAAuKGAgAedAACADGcegIABoqcA//+3R4A= Date: Wed, 6 Jan 2016 16:43:03 +0000 Message-ID: <45EE4FB3-39BC-48D6-934E-C46E0B107A41@juniper.net> References: <56784B9B.5020408@cisco.com> <327E370C-4D5F-4F9A-B982-B71108CEBC08@juniper.net> <567A5B39.3010909@wilton.org.uk> <567B1129.9090104@wilton.org.uk> <5CB86359-D6B1-4D84-962C-750A8D7AE174@juniper.net> <568BDB95.4060203@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/0.0.0.151105 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.12] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1602; 5:lOXAGjaM1OfOO23CwwZ50GjzJ6tkJrxPHegiv/SnlLiX00S3a+a6QHXcQ8/RZpC7CHZCdXQUtp7cO+vAc+eiDjdgR/b8lipWw/oT5MtnSlmGh96kaGva2cA1eAQKExzvUJHdaMdyJARxf0bcSLQ6SQ==; 24:czJBXHaDLuxUemB7zt+6IPkwRlXFZdvardqEtQ5ozT7jz5sa6fn5siCEswgE69jtjCYly7J9+vxM2h9nFYKKfRiU7z3pS3nJbAibTJmvDj4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1602; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:BN3PR0501MB1602; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1602; x-forefront-prvs: 0813C68E65 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(54356999)(2900100001)(2950100001)(106116001)(1220700001)(101416001)(76176999)(19580395003)(86362001)(1941001)(92566002)(3846002)(105586002)(15975445007)(5004730100002)(77096005)(5002640100001)(66066001)(4326007)(586003)(33656002)(19300405004)(19625215002)(11100500001)(6116002)(99286002)(189998001)(82746002)(87936001)(4001350100001)(50986999)(5001960100002)(10400500002)(1096002)(40100003)(102836003)(83716003)(81156007)(97736004)(122556002)(15187005004)(83506001)(93886004)(36756003)(5008740100001)(106356001)(230783001)(5001770100001)(16236675004)(104396002)(19623405001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1602; 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) Content-Type: multipart/alternative; boundary="_000_45EE4FB339BC48D6934EC46E0B107A41junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2016 16:43:03.4490 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1602 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 16:43:32 -0000 --_000_45EE4FB339BC48D6934EC46E0B107A41junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 W0FzIGEgY29udHJpYnV0b3JdDQoNCkdlcnQ+IElmIGEgY2xpZW50IGlzIGhhcyB0aGUgaW50ZW50 aW9uIHRvIHVwZGF0ZS9jaGFuZ2UgYSBjb25maWcsIGl0cyBkZWNpc2lvbiBpcyBiYXNlZCBvbiB0 aGUgcHJlc2VudCBzdGF0ZSBvZiB0aGUgY29uZmlndXJhdGlvbiB3aGVuIHRoZSBkZWNpc2lvbiBp cyB0YWtlbi4gSWRlYWxseSB0aGUgcHJlc2VudCBjb25maWd1cmF0aW9uIGlzIGluIGEgc3RhdGUg d2hlcmUgaW50ZW5kZWQgPT0gYXBwbGllZCBjb25maWcsIHNvIHRoZXJlIGlzIHN0YWJsZSBncm91 bmQgdXBvbiB3aGljaCBhIGNoYW5nZSBpcyBhcHBsaWVkLiBIb3dldmVyIHRoZXJlIGlzIGFsc28g dGhlIGNhc2Ugd2hlcmUgaW50ZW5kZWQgIT0gYXBwbGllZCBjb25maWcgYW5kIHRoZXJlIGFyZSB0 d28gcmVhc29ucyBmb3IgdGhhdC4NCg0KYSkgICAgICBhIHByZXZpb3VzIGludGVuZGVkIGNvbmZp ZyBpcyBpbiB0aGUgcHJvY2VzcyBvZiBiZWluZyBhcHBsaWVkDQoNCmIpICAgICAgYSBwcmV2aW91 cyBjb25maWd1cmF0aW9uIGZhaWxlZCBkdWUgdG8gYW4gZXJyb3INCg0KW0tFTlRdIG9yIGR1ZSB0 byBtaXNzaW5nIGhhcmR3YXJlLCByaWdodD8gICBSZWdhcmRsZXNzLCBJIGRvbuKAmXQgdGhpbmsg dGhpcyB0aHJlYWQgaGFzIGJlYXJpbmcgb2YgdGhlIHJlcXVpcmVtZW50cyBkcmFmdC4gIE5vdGUg dGhhdCBJIHJlbW92ZWQgdGhlICotb24tZXJyb3IgdGVybXMgZnJvbSB0aGUgVGVybWlub2xvZ3kg c2VjdGlvbiBpbiAtMDIgYnkgaW5zdGVhZCByZXdvcmRpbmcgcmVxdWlyZW1lbnQgMi1DLCB3aGlj aCB3YXMgdGhlIG9ubHkgcGxhY2UgdGhleSB3ZXJlIGJlaW5nIHJlZmVyZW5jZWQgYmVmb3JlIGFu ZCB0aGUgcmVmZXJlbmNlIHdhcyBtZXJlbHkgc3VnZ2VzdGl2ZSAobm90IG5vcm1hdGl2ZSkuICBD YW4gd2UgbGVhdmUgaXQgdG8gdGhlIHNvbHV0aW9uIGRyYWZ0cyB0byBzb3J0IG91dD8NCg0KDQo= --_000_45EE4FB339BC48D6934EC46E0B107A41junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <07B45476214C4740A3AF4F2B2D4918DC@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PltBcyBhIGNvbnRyaWJ1dG9yXTwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiB4bWxuczp2PSJ1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29t Om9mZmljZTp3b3JkIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmlj ZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4N CjxkaXYgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3 MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTFw dDsiPkdlcnQmZ3Q7IElmIGEgY2xpZW50IGlzIGhhcyB0aGUgaW50ZW50aW9uIHRvIHVwZGF0ZS9j aGFuZ2UgYSBjb25maWcsIGl0cyBkZWNpc2lvbiBpcyBiYXNlZCBvbiB0aGUgcHJlc2VudCBzdGF0 ZSBvZiB0aGUgY29uZmlndXJhdGlvbg0KIHdoZW4gdGhlIGRlY2lzaW9uIGlzIHRha2VuLiBJZGVh bGx5IHRoZSBwcmVzZW50IGNvbmZpZ3VyYXRpb24gaXMgaW4gYSBzdGF0ZSB3aGVyZSBpbnRlbmRl ZCA9PSBhcHBsaWVkIGNvbmZpZywgc28gdGhlcmUgaXMgc3RhYmxlIGdyb3VuZCB1cG9uIHdoaWNo IGEgY2hhbmdlIGlzIGFwcGxpZWQuIEhvd2V2ZXIgdGhlcmUgaXMgYWxzbyB0aGUgY2FzZSB3aGVy ZSBpbnRlbmRlZCAhPSBhcHBsaWVkIGNvbmZpZyBhbmQgdGhlcmUgYXJlIHR3byByZWFzb25zDQog Zm9yIHRoYXQuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMyBsZXZl bDEgbGZvMiI+DQo8IS0tW2lmICFzdXBwb3J0TGlzdHNdLS0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmEpPHNw YW4gc3R5bGU9ImZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGZvbnQtc2l6ZTogN3B0OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhLS1bZW5kaWZdLS0+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2Io MzEsIDczLCAxMjUpOyI+YSBwcmV2aW91cyBpbnRlbmRlZCBjb25maWcgaXMgaW4gdGhlIHByb2Nl c3Mgb2YgYmVpbmcgYXBwbGllZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7dGV4dC1pbmRlbnQ6LTE4 LjBwdDttc28tbGlzdDpsMyBsZXZlbDEgbGZvMiI+DQo8IS0tW2lmICFzdXBwb3J0TGlzdHNdLS0+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPmIpPHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGZvbnQtc2l6ZTogN3B0OyBsaW5l LWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhLS1bZW5kaWZd LS0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+YSBwcmV2aW91cyBjb25maWd1cmF0 aW9uIGZhaWxlZCBkdWUgdG8gYW4gZXJyb3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8ZGl2PltLRU5UXSBvciBkdWUgdG8gbWlzc2luZyBo YXJkd2FyZSwgcmlnaHQ/ICZuYnNwOyBSZWdhcmRsZXNzLCBJIGRvbuKAmXQgdGhpbmsgdGhpcyB0 aHJlYWQgaGFzIGJlYXJpbmcgb2YgdGhlIHJlcXVpcmVtZW50cyBkcmFmdC4gJm5ic3A7Tm90ZSB0 aGF0IEkgcmVtb3ZlZCB0aGUgKi1vbi1lcnJvciB0ZXJtcyBmcm9tIHRoZSBUZXJtaW5vbG9neSBz ZWN0aW9uIGluIC0wMiBieSBpbnN0ZWFkIHJld29yZGluZyByZXF1aXJlbWVudCAyLUMsIHdoaWNo IHdhcyB0aGUgb25seQ0KIHBsYWNlIHRoZXkgd2VyZSBiZWluZyByZWZlcmVuY2VkIGJlZm9yZSBh bmQgdGhlIHJlZmVyZW5jZSB3YXMgbWVyZWx5IHN1Z2dlc3RpdmUgKG5vdCBub3JtYXRpdmUpLiAm bmJzcDtDYW4gd2UgbGVhdmUgaXQgdG8gdGhlIHNvbHV0aW9uIGRyYWZ0cyB0byBzb3J0IG91dD88 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHN0eWxlPjwhLS0N Ci8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2Rp bmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAx MSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxp bmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNl dGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQ YXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsN CgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNt Ow0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNv bG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb25zb2xhcyIs InNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOmJsYWNrO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVm aW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE0NzcxMjUzOw0KCW1zby1saXN0 LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczozNzAyOTI3NzAgMjA1OTA1MDg2 NCA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2 NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4t bGVmdDoxOC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJbXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo1 NC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgltYXJnaW4tbGVmdDo5MC4wcHQ7 DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxl ZnQ6MTI2LjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTYy LjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCW1hcmdpbi1sZWZ0OjE5OC4wcHQ7 DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxl ZnQ6MjM0LjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6Mjcw LjBwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCW1hcmdpbi1sZWZ0OjMwNi4wcHQ7 DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjM4NDA2MjAw MjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MjAwMzAy MTQ2IDY3Njk4NzA1IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1 IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2 ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZl bDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 O30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwx OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRl eHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDo5NDE2NDY5Nzg7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOjYyOTA1OTkyNjt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1p ZDoxNDUxMjQ1MzU0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRl LWlkczoxMjgzNjE3NjA4IDY3Njk4NzExIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4 NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwzOmxldmVs MQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGV4 dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0O30NCkBsaXN0IGwzOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21h bi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7 bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDM6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBs aXN0IGwzOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0 Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDcNCgl7bXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDM6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwzOmxldmVs OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5k ZW50Oi05LjBwdDt9DQpAbGlzdCBsNA0KCXttc28tbGlzdC1pZDoxNDk0NDE4NjIyOw0KCW1zby1s aXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTgxOTQ4ODcwNiA0NjE1 NDMyNzAgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3 MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDQ6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDQ6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGw0 OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRl eHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsNDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7fQ0KQGxpc3QgbDQ6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhh LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGw0OmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05 LjBwdDt9DQpAbGlzdCBsNDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxp c3QgbDQ6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGw0OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlz dCBsNQ0KCXttc28tbGlzdC1pZDoxNzM4Mjc4NjEwOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0K CW1zby1saXN0LXRlbXBsYXRlLWlkczotMjEwNjc4OTQ4NiAxMjcyMDY2MTQ2IDY3Njk4NzEzIDY3 Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4 NzE1O30NCkBsaXN0IGw1OmxldmVsMQ0KCXttc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGw1OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBs NTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0 ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDU6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0O30NCkBsaXN0IGw1OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBo YS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsNTpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDot OS4wcHQ7fQ0KQGxpc3QgbDU6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBs aXN0IGw1OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsNTpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxp c3QgbDYNCgl7bXNvLWxpc3QtaWQ6MTkzNzAxMTc3MTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTExMjkxNDQ1NTQgNjc2OTg2ODkgNjc2OTg2OTEgNjc2 OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2 OTM7fQ0KQGxpc3QgbDY6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDY6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDY6bGV2ZWwzDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBBNzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDY6 bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDY6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDY6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBBNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDY6bGV2ZWw3DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBCNzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDY6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KQGxpc3QgbDY6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpcRjBBNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDcNCgl7bXNvLWxpc3QtaWQ6MTk0MzI5NDYxMzsNCglt c28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTUwMjAxOTU0NiA2 NzY5ODcwNSA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5 ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsNzpsZXZlbDENCgl7bXNvLWxldmVsLXRl eHQ6IiUxXCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGw3OmxldmVsMg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDt9DQpAbGlzdCBsNzpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9t YW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDc6bGV2ZWw0DQoJ e21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGw3OmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpA bGlzdCBsNzpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdo dDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDc6bGV2ZWw3DQoJe21zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0O30NCkBsaXN0IGw3OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsNzpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWlu ZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJv dHRvbTowY207fQ0KLS0+PC9zdHlsZT4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_45EE4FB339BC48D6934EC46E0B107A41junipernet_-- From nobody Wed Jan 6 08:48:39 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E1F1A8A23 for ; Wed, 6 Jan 2016 08:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oouern2TTg8d for ; Wed, 6 Jan 2016 08:48:36 -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 49E741A909D for ; Wed, 6 Jan 2016 08:48:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5909; q=dns/txt; s=iport; t=1452098916; x=1453308516; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=OBpWu38vychrn9zEV9KSFRqo7TcZNuaZwRs7Yx++NXs=; b=YvixVy1F4xOXkZcV6wCxLLfAL9oDo/5zS2Cv7Js4l9+qzCSo/21/j4Xm Zy8vTI2AdUhMzA/+TygvMy+JTXnv+ocJuSGSGoTBQfZL1OS4BfTMj2AWJ F0cV6A8jN7CA41t3v37fL7Eb8hSryOhE2F9/0XIWeibgv6z0uc2tPXLwg 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqBACURI1W/xbLJq1egm6BHolGtUmGD?= =?us-ascii?q?wKBbwEBAQEBAYELhDUBAQQjCksBEAkCDgoJFgsCAgkDAgECAUUGAQwIAQEXiBS?= =?us-ascii?q?UEp00kFABAQEBAQEBAQEBAQEBAQEBAQEBAQEYhlaEf4dzgUkBBIdbhxKIHY1Vg?= =?us-ascii?q?VyHSoVUhV6IaWSECj6GFQEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,529,1444694400"; d="scan'208,217";a="624309177" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jan 2016 16:48:34 +0000 Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u06GmYhp018770; Wed, 6 Jan 2016 16:48:34 GMT To: Kent Watsen , Gert Grammel References: <56784B9B.5020408@cisco.com> <327E370C-4D5F-4F9A-B982-B71108CEBC08@juniper.net> <567A5B39.3010909@wilton.org.uk> <567B1129.9090104@wilton.org.uk> <5CB86359-D6B1-4D84-962C-750A8D7AE174@juniper.net> <568BDB95.4060203@cisco.com> <45EE4FB3-39BC-48D6-934E-C46E0B107A41@juniper.net> From: Robert Wilton Message-ID: <568D4562.9000800@cisco.com> Date: Wed, 6 Jan 2016 16:48:34 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <45EE4FB3-39BC-48D6-934E-C46E0B107A41@juniper.net> Content-Type: multipart/alternative; boundary="------------000108010200050901030906" Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 16:48:38 -0000 This is a multi-part message in MIME format. --------------000108010200050901030906 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Kent, On 06/01/2016 16:43, Kent Watsen wrote: > [As a contributor] > > Gert> If a client is has the intention to update/change a config, its > decision is based on the present state of the configuration when the > decision is taken. Ideally the present configuration is in a state > where intended == applied config, so there is stable ground upon which > a change is applied. However there is also the case where intended != > applied config and there are two reasons for that. > > a)a previous intended config is in the process of being applied > > b)a previous configuration failed due to an error > > [KENT] or due to missing hardware, right? Regardless, I don’t think > this thread has bearing of the requirements draft. Note that I > removed the *-on-error terms from the Terminology section in -02 by > instead rewording requirement 2-C, which was the only place they were > being referenced before and the reference was merely suggestive (not > normative). Can we leave it to the solution drafts to sort out? Yes, deferring this issue to the solutions draft works for me. I don't think that it will have any bearing on the discussion of the overall solution approach. Thanks, Rob --------------000108010200050901030906 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Kent,

On 06/01/2016 16:43, Kent Watsen wrote:
[As a contributor]

Gert> If a client is has the intention to update/change a config, its decision is based on the present state of the configuration when the decision is taken. Ideally the present configuration is in a state where intended == applied config, so there is stable ground upon which a change is applied. However there is also the case where intended != applied config and there are two reasons for that.

a)      a previous intended config is in the process of being applied

b)      a previous configuration failed due to an error
[KENT] or due to missing hardware, right?   Regardless, I don’t think this thread has bearing of the requirements draft.  Note that I removed the *-on-error terms from the Terminology section in -02 by instead rewording requirement 2-C, which was the only place they were being referenced before and the reference was merely suggestive (not normative).  Can we leave it to the solution drafts to sort out?

Yes, deferring this issue to the solutions draft works for me.

I don't think that it will have any bearing on the discussion of the overall solution approach.

Thanks,
Rob

--------------000108010200050901030906-- From nobody Wed Jan 6 09:00:38 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51551B2DE4 for ; Wed, 6 Jan 2016 09:00:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gy5fbx0Mu3CT for ; Wed, 6 Jan 2016 09:00:35 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0768.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:768]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F35321B2DE6 for ; Wed, 6 Jan 2016 09:00:33 -0800 (PST) Received: from BY1PR0501MB1605.namprd05.prod.outlook.com (10.160.203.154) by BY1PR0501MB1446.namprd05.prod.outlook.com (10.160.107.156) with Microsoft SMTP Server (TLS) id 15.1.361.13; Wed, 6 Jan 2016 17:00:09 +0000 Received: from BY1PR0501MB1605.namprd05.prod.outlook.com ([10.160.203.154]) by BY1PR0501MB1605.namprd05.prod.outlook.com ([10.160.203.154]) with mapi id 15.01.0361.006; Wed, 6 Jan 2016 17:00:09 +0000 From: Gert Grammel To: Kent Watsen , Robert Wilton Thread-Topic: [netmod] netmod-opstate-reqs and error option terms (rollback on error) Thread-Index: AQHRR8pu4DRwZNkgdE+qlT203xB9S57ukwZQgAAgBICAAARw4A== Date: Wed, 6 Jan 2016 17:00:09 +0000 Message-ID: References: <56784B9B.5020408@cisco.com> <327E370C-4D5F-4F9A-B982-B71108CEBC08@juniper.net> <567A5B39.3010909@wilton.org.uk> <567B1129.9090104@wilton.org.uk> <5CB86359-D6B1-4D84-962C-750A8D7AE174@juniper.net> <568BDB95.4060203@cisco.com> <45EE4FB3-39BC-48D6-934E-C46E0B107A41@juniper.net> In-Reply-To: <45EE4FB3-39BC-48D6-934E-C46E0B107A41@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; x-originating-ip: [193.110.55.12] x-microsoft-exchange-diagnostics: 1; BY1PR0501MB1446; 5:t6umIMJzU3CqPyEXLFKK4G3IJLsWrWu20ZIrrlnYztV7tEYoEkf8/UvA+Zcc6slajFNx7wQJLfxBBZTA7SHj/+7BnUpKhwfI+SoBJHbOyR9jca5eg1+MKfuAbhmpthtw9mWzn7WYGTfFa/FM5cD3aw==; 24:FGlwT9rwHx1GdAyeBBMOGIHt+tOZxBufBiYlNmq9ZgxeDslmuv/o1UtyuzsAd6Kakjje0ONwC2vwyNAdcfhHzLVQ0doManCrSpU2vFmjRo8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1446; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001); SRVR:BY1PR0501MB1446; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1446; x-forefront-prvs: 0813C68E65 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(19625215002)(19300405004)(19580395003)(5003600100002)(19580405001)(230783001)(106356001)(101416001)(93886004)(74316001)(40100003)(586003)(11100500001)(790700001)(87936001)(66066001)(3846002)(106116001)(92566002)(19609705001)(77096005)(105586002)(1096002)(1220700001)(6116002)(99286002)(54356999)(97736004)(5004730100002)(76176999)(102836003)(33656002)(10400500002)(1941001)(15975445007)(16236675004)(5001770100001)(4326007)(189998001)(86362001)(76576001)(122556002)(2900100001)(5001960100002)(5002640100001)(5008740100001)(2950100001)(50986999)(81156007); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1446; H:BY1PR0501MB1605.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) Content-Type: multipart/alternative; boundary="_000_BY1PR0501MB1605E5AD40F4CFEB63634FC6CEF40BY1PR0501MB1605_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2016 17:00:09.6219 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1446 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 17:00:38 -0000 --_000_BY1PR0501MB1605E5AD40F4CFEB63634FC6CEF40BY1PR0501MB1605_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 S2VudCwNCg0KSSB3b3VsZCBhZ3JlZSB0aGF0IHRoZSBkaXNjdXNzaW9uIGRvZXNu4oCZdCBhZmZl Y3QgdGhlIHJlcXVpcmVtZW50cyBkcmFmdCBpbiBpdHMgY3VycmVudCBzdGF0ZS4gVGhlIHNvbHV0 aW9ucyBkcmFmdCB3b3VsZCBiZSBhIGJldHRlciBwbGFjZSBwcm9iYWJseS4NCg0KR2VydA0KDQpG cm9tOiBLZW50IFdhdHNlbg0KU2VudDogMDYgSmFudWFyeSAyMDE2IDE3OjQzDQpUbzogR2VydCBH cmFtbWVsOyBSb2JlcnQgV2lsdG9uDQpDYzogbmV0bW9kQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W25ldG1vZF0gbmV0bW9kLW9wc3RhdGUtcmVxcyBhbmQgZXJyb3Igb3B0aW9uIHRlcm1zIChyb2xs YmFjayBvbiBlcnJvcikNCg0KW0FzIGEgY29udHJpYnV0b3JdDQoNCkdlcnQ+IElmIGEgY2xpZW50 IGlzIGhhcyB0aGUgaW50ZW50aW9uIHRvIHVwZGF0ZS9jaGFuZ2UgYSBjb25maWcsIGl0cyBkZWNp c2lvbiBpcyBiYXNlZCBvbiB0aGUgcHJlc2VudCBzdGF0ZSBvZiB0aGUgY29uZmlndXJhdGlvbiB3 aGVuIHRoZSBkZWNpc2lvbiBpcyB0YWtlbi4gSWRlYWxseSB0aGUgcHJlc2VudCBjb25maWd1cmF0 aW9uIGlzIGluIGEgc3RhdGUgd2hlcmUgaW50ZW5kZWQgPT0gYXBwbGllZCBjb25maWcsIHNvIHRo ZXJlIGlzIHN0YWJsZSBncm91bmQgdXBvbiB3aGljaCBhIGNoYW5nZSBpcyBhcHBsaWVkLiBIb3dl dmVyIHRoZXJlIGlzIGFsc28gdGhlIGNhc2Ugd2hlcmUgaW50ZW5kZWQgIT0gYXBwbGllZCBjb25m aWcgYW5kIHRoZXJlIGFyZSB0d28gcmVhc29ucyBmb3IgdGhhdC4NCg0KYSkgICAgICBhIHByZXZp b3VzIGludGVuZGVkIGNvbmZpZyBpcyBpbiB0aGUgcHJvY2VzcyBvZiBiZWluZyBhcHBsaWVkDQoN CmIpICAgICAgYSBwcmV2aW91cyBjb25maWd1cmF0aW9uIGZhaWxlZCBkdWUgdG8gYW4gZXJyb3IN CltLRU5UXSBvciBkdWUgdG8gbWlzc2luZyBoYXJkd2FyZSwgcmlnaHQ/ICAgUmVnYXJkbGVzcywg SSBkb27igJl0IHRoaW5rIHRoaXMgdGhyZWFkIGhhcyBiZWFyaW5nIG9mIHRoZSByZXF1aXJlbWVu dHMgZHJhZnQuICBOb3RlIHRoYXQgSSByZW1vdmVkIHRoZSAqLW9uLWVycm9yIHRlcm1zIGZyb20g dGhlIFRlcm1pbm9sb2d5IHNlY3Rpb24gaW4gLTAyIGJ5IGluc3RlYWQgcmV3b3JkaW5nIHJlcXVp cmVtZW50IDItQywgd2hpY2ggd2FzIHRoZSBvbmx5IHBsYWNlIHRoZXkgd2VyZSBiZWluZyByZWZl cmVuY2VkIGJlZm9yZSBhbmQgdGhlIHJlZmVyZW5jZSB3YXMgbWVyZWx5IHN1Z2dlc3RpdmUgKG5v dCBub3JtYXRpdmUpLiAgQ2FuIHdlIGxlYXZlIGl0IHRvIHRoZSBzb2x1dGlvbiBkcmFmdHMgdG8g c29ydCBvdXQ/DQoNCg0K --_000_BY1PR0501MB1605E5AD40F4CFEB63634FC6CEF40BY1PR0501MB1605_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29s b3I6YmxhY2s7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBD aGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNr O30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQ YXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1h cmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0 Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1M UHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv cm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5C YWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJ Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4u RW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUy Mw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVw dCAyLjBjbSA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5LZW50LDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SSB3b3VsZCBhZ3JlZSB0aGF0IHRoZSBkaXNjdXNzaW9uIGRvZXNu4oCZdCBhZmZlY3QgdGhlIHJl cXVpcmVtZW50cyBkcmFmdCBpbiBpdHMgY3VycmVudCBzdGF0ZS4gVGhlIHNvbHV0aW9ucyBkcmFm dCB3b3VsZCBiZSBhIGJldHRlciBwbGFjZSBwcm9iYWJseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkdlcnQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gS2VudCBXYXRz ZW4NCjxicj4NCjxiPlNlbnQ6PC9iPiAwNiBKYW51YXJ5IDIwMTYgMTc6NDM8YnI+DQo8Yj5Ubzo8 L2I+IEdlcnQgR3JhbW1lbDsgUm9iZXJ0IFdpbHRvbjxicj4NCjxiPkNjOjwvYj4gbmV0bW9kQGll dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0bW9kXSBuZXRtb2Qtb3BzdGF0ZS1y ZXFzIGFuZCBlcnJvciBvcHRpb24gdGVybXMgKHJvbGxiYWNrIG9uIGVycm9yKTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+W0FzIGEgY29udHJpYnV0b3JdPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5HZXJ0Jmd0OyBJZiBh IGNsaWVudCBpcyBoYXMgdGhlIGludGVudGlvbiB0byB1cGRhdGUvY2hhbmdlIGEgY29uZmlnLCBp dHMgZGVjaXNpb24gaXMgYmFzZWQgb24gdGhlIHByZXNlbnQNCiBzdGF0ZSBvZiB0aGUgY29uZmln dXJhdGlvbiB3aGVuIHRoZSBkZWNpc2lvbiBpcyB0YWtlbi4gSWRlYWxseSB0aGUgcHJlc2VudCBj b25maWd1cmF0aW9uIGlzIGluIGEgc3RhdGUgd2hlcmUgaW50ZW5kZWQgPT0gYXBwbGllZCBjb25m aWcsIHNvIHRoZXJlIGlzIHN0YWJsZSBncm91bmQgdXBvbiB3aGljaCBhIGNoYW5nZSBpcyBhcHBs aWVkLiBIb3dldmVyIHRoZXJlIGlzIGFsc28gdGhlIGNhc2Ugd2hlcmUgaW50ZW5kZWQgIT0gYXBw bGllZCBjb25maWcNCiBhbmQgdGhlcmUgYXJlIHR3byByZWFzb25zIGZvciB0aGF0Ljwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmEpPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4w cHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmEgcHJldmlvdXMgaW50 ZW5kZWQgY29uZmlnIGlzIGluIHRoZSBwcm9jZXNzIG9mIGJlaW5nIGFwcGxpZWQ8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O3RleHQtaW5k ZW50Oi0xOC4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5i KTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5hIHByZXZpb3VzIGNvbmZpZ3VyYXRpb24gZmFpbGVkIGR1ZSB0 byBhbiBlcnJvcjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPltLRU5UXSBvciBkdWUgdG8gbWlz c2luZyBoYXJkd2FyZSwgcmlnaHQ/ICZuYnNwOyBSZWdhcmRsZXNzLCBJIGRvbuKAmXQgdGhpbmsg dGhpcyB0aHJlYWQgaGFzIGJlYXJpbmcgb2YgdGhlIHJlcXVpcmVtZW50cyBkcmFmdC4gJm5ic3A7 Tm90ZSB0aGF0IEkgcmVtb3ZlZCB0aGUgKi1vbi1lcnJvciB0ZXJtcyBmcm9tIHRoZQ0KIFRlcm1p bm9sb2d5IHNlY3Rpb24gaW4gLTAyIGJ5IGluc3RlYWQgcmV3b3JkaW5nIHJlcXVpcmVtZW50IDIt Qywgd2hpY2ggd2FzIHRoZSBvbmx5IHBsYWNlIHRoZXkgd2VyZSBiZWluZyByZWZlcmVuY2VkIGJl Zm9yZSBhbmQgdGhlIHJlZmVyZW5jZSB3YXMgbWVyZWx5IHN1Z2dlc3RpdmUgKG5vdCBub3JtYXRp dmUpLiAmbmJzcDtDYW4gd2UgbGVhdmUgaXQgdG8gdGhlIHNvbHV0aW9uIGRyYWZ0cyB0byBzb3J0 IG91dD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BY1PR0501MB1605E5AD40F4CFEB63634FC6CEF40BY1PR0501MB1605_-- From nobody Wed Jan 6 09:08:10 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6EAA1B2E05 for ; Wed, 6 Jan 2016 09:08:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-1KJMirh-TJ for ; Wed, 6 Jan 2016 09:08:06 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0101.outbound.protection.outlook.com [65.55.169.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 AAC851B2E02 for ; Wed, 6 Jan 2016 09:08:04 -0800 (PST) Received: from BY1PR0501MB1605.namprd05.prod.outlook.com (10.160.203.154) by BY1PR0501MB1448.namprd05.prod.outlook.com (10.160.108.12) with Microsoft SMTP Server (TLS) id 15.1.361.13; Wed, 6 Jan 2016 17:08:02 +0000 Received: from BY1PR0501MB1605.namprd05.prod.outlook.com ([10.160.203.154]) by BY1PR0501MB1605.namprd05.prod.outlook.com ([10.160.203.154]) with mapi id 15.01.0361.006; Wed, 6 Jan 2016 17:08:02 +0000 From: Gert Grammel To: Robert Wilton , Kent Watsen Thread-Topic: [netmod] netmod-opstate-reqs and error option terms (rollback on error) Thread-Index: AQHRR8pu4DRwZNkgdE+qlT203xB9S57ukwZQgAAgBICAAAGKAIAAA1YQ Date: Wed, 6 Jan 2016 17:08:02 +0000 Message-ID: References: <56784B9B.5020408@cisco.com> <327E370C-4D5F-4F9A-B982-B71108CEBC08@juniper.net> <567A5B39.3010909@wilton.org.uk> <567B1129.9090104@wilton.org.uk> <5CB86359-D6B1-4D84-962C-750A8D7AE174@juniper.net> <568BDB95.4060203@cisco.com> <45EE4FB3-39BC-48D6-934E-C46E0B107A41@juniper.net> <568D4562.9000800@cisco.com> In-Reply-To: <568D4562.9000800@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; x-originating-ip: [193.110.55.12] x-microsoft-exchange-diagnostics: 1; BY1PR0501MB1448; 5:3irA8wwaMbP8pnAJXQ+KGwt0V0U9wNi4dikhyDOZmW4t1cl4TatRqu2rEH3kbVNCynqLx6l5YxQwV14xaKlAge3QwatkrJaXtNAhd1vtCfSMDbEooIr7SQfu7KB9XHOFgqAe+s2+9hV61wNy2sytZQ==; 24:TWQ9EJ7ec05cV+OTflEvB4FiNFAmi0KOEMO+oKYQCdNyzzSwXEGc+JiFMPtaDN2Scp7IH9S0PjCl1tCw38DoF0O8fSNcnLuJlpupJq3KGhU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1448; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001); SRVR:BY1PR0501MB1448; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1448; x-forefront-prvs: 0813C68E65 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(199003)(479174004)(24454002)(189002)(2950100001)(77096005)(5003600100002)(586003)(54356999)(5008740100001)(1096002)(76576001)(2900100001)(6116002)(5002640100001)(74316001)(3846002)(189998001)(93886004)(106116001)(81156007)(790700001)(10400500002)(1941001)(5001770100001)(5001960100002)(50986999)(19580405001)(99286002)(15975445007)(5004730100002)(102836003)(122556002)(76176999)(105586002)(101416001)(4326007)(19580395003)(1220700001)(86362001)(19625215002)(16236675004)(11100500001)(230783001)(33656002)(19300405004)(87936001)(40100003)(97736004)(4001450100002)(106356001)(66066001)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1448; H:BY1PR0501MB1605.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) Content-Type: multipart/alternative; boundary="_000_BY1PR0501MB1605B76B032A5B00E809BAF1CEF40BY1PR0501MB1605_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2016 17:08:02.3203 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1448 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 17:08:07 -0000 --_000_BY1PR0501MB1605B76B032A5B00E809BAF1CEF40BY1PR0501MB1605_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpTb3JyeSwgbWlzc2VkIEtlbnTigJlzIHJlbWFyazoNCltLRU5UXSBvciBkdWUgdG8gbWlzc2lu ZyBoYXJkd2FyZSwgcmlnaHQ/DQoNClRoYXTigJlzIG9uZSByb290IGNhdXNlLCBidXQgSSBkaWRu 4oCZdCB3YW50IHRvIGdvIGludG8gbXVjaCBkZXRhaWxzIGhlcmUuIE1pc3NpbmcgSGFyZHdhcmUg aXMgb25lIGlzc3VlLCBvdGhlciBpc3N1ZXMgYXJlIHVuY29uc2Npb3VzIGNvbmZpZ3VyYXRpb24g cmVxdWVzdHMgZnJvbSB0aGUgY2xpZW50LCBmYXVsdHkgSFcsIGJ1Z3MgZXRjLiBXaGF0ZXZlciB0 aGUgcm9vdCBjYXVzZSwgdGhlIHJlc3VsdCBpcyBpbnRlbmRlZCAhPSBhcHBsaWVkIGFuZCBDbGll bnQrU2VydmVyIGhhdmUgdG8gZGVhbCB3aXRoIGl0IGluIGEgbWVhbmluZ2Z1bCBtYW5uZXIuDQoN CkdlcnQNCg0KRnJvbTogUm9iZXJ0IFdpbHRvbiBbbWFpbHRvOnJ3aWx0b25AY2lzY28uY29tXQ0K U2VudDogMDYgSmFudWFyeSAyMDE2IDE3OjQ5DQpUbzogS2VudCBXYXRzZW47IEdlcnQgR3JhbW1l bA0KQ2M6IG5ldG1vZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRtb2RdIG5ldG1vZC1vcHN0 YXRlLXJlcXMgYW5kIGVycm9yIG9wdGlvbiB0ZXJtcyAocm9sbGJhY2sgb24gZXJyb3IpDQoNCkhp IEtlbnQsDQpPbiAwNi8wMS8yMDE2IDE2OjQzLCBLZW50IFdhdHNlbiB3cm90ZToNCltBcyBhIGNv bnRyaWJ1dG9yXQ0KDQpHZXJ0PiBJZiBhIGNsaWVudCBpcyBoYXMgdGhlIGludGVudGlvbiB0byB1 cGRhdGUvY2hhbmdlIGEgY29uZmlnLCBpdHMgZGVjaXNpb24gaXMgYmFzZWQgb24gdGhlIHByZXNl bnQgc3RhdGUgb2YgdGhlIGNvbmZpZ3VyYXRpb24gd2hlbiB0aGUgZGVjaXNpb24gaXMgdGFrZW4u IElkZWFsbHkgdGhlIHByZXNlbnQgY29uZmlndXJhdGlvbiBpcyBpbiBhIHN0YXRlIHdoZXJlIGlu dGVuZGVkID09IGFwcGxpZWQgY29uZmlnLCBzbyB0aGVyZSBpcyBzdGFibGUgZ3JvdW5kIHVwb24g d2hpY2ggYSBjaGFuZ2UgaXMgYXBwbGllZC4gSG93ZXZlciB0aGVyZSBpcyBhbHNvIHRoZSBjYXNl IHdoZXJlIGludGVuZGVkICE9IGFwcGxpZWQgY29uZmlnIGFuZCB0aGVyZSBhcmUgdHdvIHJlYXNv bnMgZm9yIHRoYXQuDQoNCmEpICAgICAgYSBwcmV2aW91cyBpbnRlbmRlZCBjb25maWcgaXMgaW4g dGhlIHByb2Nlc3Mgb2YgYmVpbmcgYXBwbGllZA0KDQpiKSAgICAgIGEgcHJldmlvdXMgY29uZmln dXJhdGlvbiBmYWlsZWQgZHVlIHRvIGFuIGVycm9yDQpbS0VOVF0gb3IgZHVlIHRvIG1pc3Npbmcg aGFyZHdhcmUsIHJpZ2h0PyAgIFJlZ2FyZGxlc3MsIEkgZG9u4oCZdCB0aGluayB0aGlzIHRocmVh ZCBoYXMgYmVhcmluZyBvZiB0aGUgcmVxdWlyZW1lbnRzIGRyYWZ0LiAgTm90ZSB0aGF0IEkgcmVt b3ZlZCB0aGUgKi1vbi1lcnJvciB0ZXJtcyBmcm9tIHRoZSBUZXJtaW5vbG9neSBzZWN0aW9uIGlu IC0wMiBieSBpbnN0ZWFkIHJld29yZGluZyByZXF1aXJlbWVudCAyLUMsIHdoaWNoIHdhcyB0aGUg b25seSBwbGFjZSB0aGV5IHdlcmUgYmVpbmcgcmVmZXJlbmNlZCBiZWZvcmUgYW5kIHRoZSByZWZl cmVuY2Ugd2FzIG1lcmVseSBzdWdnZXN0aXZlIChub3Qgbm9ybWF0aXZlKS4gIENhbiB3ZSBsZWF2 ZSBpdCB0byB0aGUgc29sdXRpb24gZHJhZnRzIHRvIHNvcnQgb3V0Pw0KDQpZZXMsIGRlZmVycmlu ZyB0aGlzIGlzc3VlIHRvIHRoZSBzb2x1dGlvbnMgZHJhZnQgd29ya3MgZm9yIG1lLg0KDQpJIGRv bid0IHRoaW5rIHRoYXQgaXQgd2lsbCBoYXZlIGFueSBiZWFyaW5nIG9uIHRoZSBkaXNjdXNzaW9u IG9mIHRoZSBvdmVyYWxsIHNvbHV0aW9uIGFwcHJvYWNoLg0KDQpUaGFua3MsDQpSb2INCg== --_000_BY1PR0501MB1605B76B032A5B00E809BAF1CEF40BY1PR0501MB1605_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29s b3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0 UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow Y207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDIuMGNtIDcwLjg1cHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+U29ycnksIG1pc3NlZCBLZW504oCZcyByZW1hcms6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W0tFTlRdIG9yIGR1ZSB0byBt aXNzaW5nIGhhcmR3YXJlLCByaWdodD8gJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGF04oCZcyBvbmUgcm9v dCBjYXVzZSwgYnV0IEkgZGlkbuKAmXQgd2FudCB0byBnbyBpbnRvIG11Y2ggZGV0YWlscyBoZXJl LiBNaXNzaW5nIEhhcmR3YXJlIGlzIG9uZSBpc3N1ZSwgb3RoZXIgaXNzdWVzIGFyZSB1bmNvbnNj aW91cyBjb25maWd1cmF0aW9uIHJlcXVlc3RzIGZyb20NCiB0aGUgY2xpZW50LCBmYXVsdHkgSFcs IGJ1Z3MgZXRjLiBXaGF0ZXZlciB0aGUgcm9vdCBjYXVzZSwgdGhlIHJlc3VsdCBpcyBpbnRlbmRl ZCAhPSBhcHBsaWVkIGFuZCBDbGllbnQmIzQzO1NlcnZlciBoYXZlIHRvIGRlYWwgd2l0aCBpdCBp biBhIG1lYW5pbmdmdWwgbWFubmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+R2VydDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBSb2JlcnQgV2lsdG9uIFttYWlsdG86 cndpbHRvbkBjaXNjby5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMDYgSmFudWFyeSAyMDE2IDE3 OjQ5PGJyPg0KPGI+VG86PC9iPiBLZW50IFdhdHNlbjsgR2VydCBHcmFtbWVsPGJyPg0KPGI+Q2M6 PC9iPiBuZXRtb2RAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtuZXRtb2RdIG5l dG1vZC1vcHN0YXRlLXJlcXMgYW5kIGVycm9yIG9wdGlvbiB0ZXJtcyAocm9sbGJhY2sgb24gZXJy b3IpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSBLZW50LDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIDA2LzAxLzIwMTYgMTY6NDMsIEtlbnQgV2F0c2VuIHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPltBcyBhIGNvbnRyaWJ1dG9yXTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5HZXJ0Jmd0OyBJZiBhIGNs aWVudCBpcyBoYXMgdGhlIGludGVudGlvbiB0byB1cGRhdGUvY2hhbmdlIGEgY29uZmlnLCBpdHMg ZGVjaXNpb24gaXMgYmFzZWQgb24gdGhlIHByZXNlbnQNCiBzdGF0ZSBvZiB0aGUgY29uZmlndXJh dGlvbiB3aGVuIHRoZSBkZWNpc2lvbiBpcyB0YWtlbi4gSWRlYWxseSB0aGUgcHJlc2VudCBjb25m aWd1cmF0aW9uIGlzIGluIGEgc3RhdGUgd2hlcmUgaW50ZW5kZWQgPT0gYXBwbGllZCBjb25maWcs IHNvIHRoZXJlIGlzIHN0YWJsZSBncm91bmQgdXBvbiB3aGljaCBhIGNoYW5nZSBpcyBhcHBsaWVk LiBIb3dldmVyIHRoZXJlIGlzIGFsc28gdGhlIGNhc2Ugd2hlcmUgaW50ZW5kZWQgIT0gYXBwbGll ZCBjb25maWcNCiBhbmQgdGhlcmUgYXJlIHR3byByZWFzb25zIGZvciB0aGF0Ljwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPmEpPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmEgcHJldmlvdXMgaW50ZW5k ZWQgY29uZmlnIGlzIGluIHRoZSBwcm9jZXNzIG9mIGJlaW5nIGFwcGxpZWQ8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5iKTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5hIHByZXZpb3VzIGNvbmZpZ3Vy YXRpb24gZmFpbGVkIGR1ZSB0byBhbiBlcnJvcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bS0VOVF0gb3Ig ZHVlIHRvIG1pc3NpbmcgaGFyZHdhcmUsIHJpZ2h0PyAmbmJzcDsgUmVnYXJkbGVzcywgSSBkb27i gJl0IHRoaW5rIHRoaXMgdGhyZWFkIGhhcyBiZWFyaW5nIG9mIHRoZSByZXF1aXJlbWVudHMgZHJh ZnQuICZuYnNwO05vdGUgdGhhdCBJIHJlbW92ZWQgdGhlICotb24tZXJyb3IgdGVybXMgZnJvbSB0 aGUgVGVybWlub2xvZ3kgc2VjdGlvbiBpbiAtMDIgYnkgaW5zdGVhZCByZXdvcmRpbmcgcmVxdWly ZW1lbnQgMi1DLA0KIHdoaWNoIHdhcyB0aGUgb25seSBwbGFjZSB0aGV5IHdlcmUgYmVpbmcgcmVm ZXJlbmNlZCBiZWZvcmUgYW5kIHRoZSByZWZlcmVuY2Ugd2FzIG1lcmVseSBzdWdnZXN0aXZlIChu b3Qgbm9ybWF0aXZlKS4gJm5ic3A7Q2FuIHdlIGxlYXZlIGl0IHRvIHRoZSBzb2x1dGlvbiBkcmFm dHMgdG8gc29ydCBvdXQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KWWVz LCBkZWZlcnJpbmcgdGhpcyBpc3N1ZSB0byB0aGUgc29sdXRpb25zIGRyYWZ0IHdvcmtzIGZvciBt ZS48YnI+DQo8YnI+DQpJIGRvbid0IHRoaW5rIHRoYXQgaXQgd2lsbCBoYXZlIGFueSBiZWFyaW5n IG9uIHRoZSBkaXNjdXNzaW9uIG9mIHRoZSBvdmVyYWxsIHNvbHV0aW9uIGFwcHJvYWNoLjxicj4N Cjxicj4NClRoYW5rcyw8YnI+DQpSb2I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_BY1PR0501MB1605B76B032A5B00E809BAF1CEF40BY1PR0501MB1605_-- From nobody Wed Jan 6 09:28:49 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D461B2E07; Wed, 6 Jan 2016 09:28:47 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpbha7QwtVzH; Wed, 6 Jan 2016 09:28:45 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c: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 624E71A6FE5; Wed, 6 Jan 2016 09:28:45 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id f206so67709918wmf.0; Wed, 06 Jan 2016 09:28:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZSxGnfH77OEKorIDXgrNAZFFfBlv6O8/nhDqUyfcFvU=; b=RvFXBJU4F5Hd9km3uC/nDvg9ab+Fyem87wjIsFEK8FF+qIioHfmMLesqt2HA2vGmAG PYgs/hCl4lJM/lLlxMHagrS08wMmUq1t/hcOLGjRFJbV5F5Nk+lJDmiJmS1E+OwC5IGG dTWqNCQQpP6HI1yorLkm8EitrxJeOxJULkKJWJ2KqQlQ8d0uZBy3iRJbCVrlo2jpYTi/ SqM9QrB49lDO8MLlJtCBdlhFF8TNGWOjxVFyqjnoSjpA3vY0TPdKHR+YRItDO75mILQn rPoks8wpdmvN78nZVje3XA17JTM+TyVxqe/KnwKxmtF/cCkLSiFUs7p+u9rFXwIvdiTB 2I6w== X-Received: by 10.194.2.168 with SMTP id 8mr126932472wjv.66.1452101324021; Wed, 06 Jan 2016 09:28:44 -0800 (PST) Received: from [192.168.254.198] ([147.83.206.82]) by smtp.gmail.com with ESMTPSA id s2sm41927606wjs.43.2016.01.06.09.28.43 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 06 Jan 2016 09:28:43 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dean Bogdanovic In-Reply-To: <20160106093026.GB25431@elstar.local> Date: Wed, 6 Jan 2016 18:28:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <509C88A7-5F33-4CF2-BE5B-284F180F0FEC@gmail.com> References: <20151211113156.GA43862@elstar.local> <2059AD77-5375-4DB0-A1BF-432835F11A9F@gmail.com> <20151221153312.GA43316@elstar.local> <568AB8AA.8070404@cisco.com> <20160106093026.GB25431@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3112) Archived-At: Cc: RTG YANG Design Team , netmod WG , Benoit Claise Subject: Re: [netmod] [Rtg-dt-yang-arch] [yang-doctors] Working group Last Call: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 17:28:47 -0000 > On Jan 6, 2016, at 10:30 AM, Juergen Schoenwaelder = wrote: >=20 > On Mon, Jan 04, 2016 at 07:23:38PM +0100, Eliot Lear wrote: >> Hi Juergen, >>=20 >> On this point: >>=20 >> On 12/21/15 4:33 PM, Juergen Schoenwaelder wrote: >>=20 >>> And >>> should the interface reference not use a more specific type than >>> 'string=E2=80=99? >>>> Interface references can be many things, from standard naming we = are familiar, e.g. ge-1/0/0.1 to a numerical value like 13276. Leaving = it as string gives us most flexibility in that regards. >>> I disagree that the goal here is most flexibility. We do have an >>> interfaces data model in the IETF. Why are we avoiding to refer to = it >>> here? >>>=20 >>=20 >> I think it would be helpful if you could be specific as to your >> concern. It is absolutely the case that the SNMP folk did an awful = lot >> of work on managing interfaces. While I am not concerned about the = form >> of the name, I wonder if your concern is around some of the = semantics, >> but I can't tell. >>=20 >=20 > My question is why the model does not use interface-ref or > interface-state-ref defined in RFC 7223 but instead an opaque string > to refer to an interface. Have we thought about the design tradeoffs? >=20 > My question is _not_ about how we deal with interface naming schemes, > that discussion took place when RFC 7223 was created. In the example where the ACL is attached to the interface, we are using = interface-ref, so replacing interface in the metadata, can be easily = done. >=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 From nobody Wed Jan 6 10:18:52 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C248D1A0083 for ; Wed, 6 Jan 2016 10:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7gKEqYdo00T for ; Wed, 6 Jan 2016 10:18:49 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0145.outbound.protection.outlook.com [65.55.169.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 722AC1A007C for ; Wed, 6 Jan 2016 10:18:48 -0800 (PST) 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 (TLS) id 15.1.361.13; Wed, 6 Jan 2016 18:18:46 +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.0361.006; Wed, 6 Jan 2016 18:18:46 +0000 From: Kent Watsen To: Juergen Schoenwaelder , "Acee Lindem (acee)" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt Thread-Index: AQHRRz2lEErWj+iSeUCXhpFM5+aasZ7rnI4AgAG85wCAAAG/gIAArbcAgAByIgA= Date: Wed, 6 Jan 2016 18:18:46 +0000 Message-ID: References: <20160104221700.28629.34622.idtracker@ietfa.amsl.com> <8A6CD12B-8B34-4F7B-83F2-E56361F998AA@juniper.net> <20160105200214.GA24262@elstar.local> <20160106063014.GA25143@elstar.local> In-Reply-To: <20160106063014.GA25143@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151105 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.12] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 5:QKCsfRI0xCeMtCfkVE+btzRQOBLg4Yb+Jl42VesRYh7rytMXJh0wQ9LfJN1JcKTSF1KDll8yAP8D69TCD7jVMbkQWQ5YLdWjJRSVmHjnkT5p+sxfnoCfBnoWxFC+O7WJxsb91N4MKRo2C02C/p0mLw==; 24:33S1cJ5GaF7eIc8ZdckPk7u6ZQCXNvghBW0qDE0Yq52VnEHxHMrSrCnrR7Qlx4LsgzYWIutIhjgO2qXYzQpdOaNHsBtxwynpHuvyzxpQWBs= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(10201501046)(3002001); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 0813C68E65 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(189002)(51444003)(164054003)(479174004)(199003)(87936001)(5002640100001)(106356001)(2950100001)(1096002)(76176999)(81156007)(586003)(5001770100001)(86362001)(4326007)(19580405001)(189998001)(3846002)(33656002)(97736004)(102836003)(54356999)(15975445007)(83506001)(82746002)(5008740100001)(10400500002)(77096005)(5001960100002)(50986999)(66066001)(1220700001)(2900100001)(6116002)(92566002)(4001350100001)(105586002)(101416001)(83716003)(99286002)(106116001)(5004730100002)(40100003)(11100500001)(19580395003)(122556002)(230783001)(36756003)(561944003)(93886004)(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:23 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: 06 Jan 2016 18:18:46.5782 (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: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 18:18:51 -0000 DQpJdOKAmXMgdHJ1ZSB0aGF0IHRoZSBkcmFmdCBpcyBsYXJnZWx5IGNlbnRlcmVkIGFyb3VuZCB0 aGUgaW50ZW5kZWQvYXBwbGllZCBjb25maWcgbm90aW9uLCBidXQgbm90IGV4Y2x1c2l2ZWx5LiAg U3BlY2lmaWNhbGx5LCA0LUIgaGFzICJBYmlsaXR5IHRvIG1hcCBpbnRlbmRlZCBjb25maWcgbm9k ZXMgdG8gYXNzb2NpYXRlZCBkZXJpdmVkIHN0YXRlIG5vZGVzIi4gIEkgdGhpbmsgdGhhdCB0aGlz IG1pZ2h0IGJlIHRoZSBvbmx5IGV4Y2x1c2lvbiB0aG91Z2ggYW5kLCBpZiBpdCB3ZXJlbuKAmXQg Zm9yIGl0IEkgd291bGTigJl2ZSB1c2VkIHlvdXIgdGl0bGUgc3VnZ2VzdGlvbiBmcm9tIHRoZSBM QyByZXZpZXcuICAgU2hvdWxkIG9uZSByZXF1aXJlbWVudCBoYXZlIHN1Y2ggaW5mbHVlbmNlIG92 ZXIgdGhlIHRpdGxlIGlzIHRoZSBxdWVzdGlvbi4gIEkgd2FzIHRyeWluZyB0byBiZSBmYWlyIHRv IGl0LCBidXQgbWF5YmUgaXQncyBnb2luZyB0b28gZmFyLg0KDQpSZWdhcmRpbmcgdmlzaWJpbGl0 eSBhbmQgY29udHJvbCwgSSB3YXMgYXR0ZW1wdGluZyB0byB1c2UgY29tbW9uIHdvcmRzIChub3Qg bm9ybWF0aXZlIHRlcm1zKSBoZXJlLiAgTXkgaW50ZW50IGZvciB0aGVtIGlzIHNvbWV0aGluZyBh bG9uZyB0aGUgbGluZXMgb2Y6DQoNCgl2aXNpYmlsaXR5OiByZWFkL3VuZGVyc3RhbmQNCgljb250 cm9sOiB3cml0ZS9vcmNoZXN0cmF0ZQ0KDQpUaGFua3MsDQoNCg0KS2VudA0KDQoNCk9uIDEvNi8x NiwgMTozMCBBTSwgIkp1ZXJnZW4gU2Nob2Vud2FlbGRlciIgPGouc2Nob2Vud2FlbGRlckBqYWNv YnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQoNCj5BY2VlLA0KPg0KPmZvciBtZSB0aGUgZG9jdW1l bnQgaXMgY2VudGVyZWQgYXJvdW5kIHRoZSBub3Rpb24gb2YgaW50ZW5kZWQgLw0KPmFwcGxpZWQg Y29uZmlnOg0KPg0KPiMxIGlzIGNsZWFybHkgYWJvdXQgaW50ZW5kZWQvYXBwbGllZCBjZmcNCj4N Cj4jMiBpcyBhYm91dCBpbnRlbmRlZC9hcHBsaWVkIGNmZyAoc2luY2Ugc3luYyBjb25maWcgb3Bl cmF0aW9ucyBpcw0KPiAgIGxhcmdlbHkgZGVmaW5lZCB1c2luZyBpbnRlbmRlZC9hcHBsaWVkIGNm ZykNCj4NCj4jMyBpcyBhYm91dCB0aGUgcmVsYXRpb25zaGlwIG9mIGFwcGxpZWQgY29uZmlnIGFu ZCBkZXJpdmVkIHN0YXRlDQo+DQo+IzQgaXMgYWJvdXQgdGhlIHJlbGF0aW9uc2hpcCBvZiBpbnRl bmRlZCAvIGFwcGxpZWQgY29uZmlnIGFuZA0KPiAgIG9wZXJhdGlvbmFsIHN0YXRlDQo+DQo+SSBm aW5kICJFbmhhbmNlZCBPcGVyYXRpb25hbCBTdGF0ZSBWaXNpYmlsaXR5IGFuZCBDb250cm9sIiBh YnN0cmFjdA0KPmFuZCBzb21ld2hhdCBjb25mdXNpbmcgKHdoYXQgaXMgdmlzaWJpbGl0eT8gd2hh dCBpcyBjb250cm9sPykuDQo+DQo+L2pzDQo+DQo+T24gVHVlLCBKYW4gMDUsIDIwMTYgYXQgMDg6 MDg6MjlQTSArMDAwMCwgQWNlZSBMaW5kZW0gKGFjZWUpIHdyb3RlOg0KPj4gSnVlcmdlbiwgDQo+ PiANCj4+IEFzIGFub3RoZXIgbm9uLWF1dGhvciwgSSBkaXNhZ3JlZSB3aXRoIHRoaXMgY2hhcmFj dGVyaXphdGlvbiBvZiB0aGUgZHJhZnQuDQo+PiBUaGUgaW50ZW5kZWQvYXBwbGllZCBjb25maWd1 cmF0aW9uIGlzIGFuIGltcG9ydGFudCByZXF1aXJlbWVudCBidXQNCj4+IGNlcnRhaW5seSBub3Qg dGhlIG9ubHkgb25lIHByZWNpc2VseSBhcnRpY3VsYXRlZCBpbiB0aGUgZHJhZnQuDQo+PiANCj4+ IEFjZWUgDQo+PiANCj4+IE9uIDEvNS8xNiwgMzowMiBQTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2Yg SnVlcmdlbiBTY2hvZW53YWVsZGVyIg0KPj4gPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJl aGFsZiBvZg0KPj4gai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToN Cj4+IA0KPj4gPk9uIE1vbiwgSmFuIDA0LCAyMDE2IGF0IDEwOjI5OjU0UE0gKzAwMDAsIEtlbnQg V2F0c2VuIHdyb3RlOg0KPj4gPj4gDQo+PiA+PiBUaGlzIHVwZGF0ZSBhZGRyZXNzZXMgY29tbWVu dHMgcmVjZWl2ZWQgZHVyaW5nIHRoZSBMYXN0IENhbGwuDQo+PiA+Pg0KPj4gPg0KPj4gPkkgbm90 IGVudGlyZWx5IGhhcHB5IHdpdGggdGhlIG5ldyB0aXRsZToNCj4+ID4NCj4+ID4gICAgICAgICAg ICAgICBUZXJtaW5vbG9neSBhbmQgUmVxdWlyZW1lbnRzIGZvciBFbmhhbmNlZA0KPj4gPiAgICAg ICAgICAgICAgICBPcGVyYXRpb25hbCBTdGF0ZSBWaXNpYmlsaXR5IGFuZCBDb250cm9sDQo+PiA+ DQo+PiA+U2luY2UgdGhlIGtleSBjb250cmlidXRpb24gaXMgdGhlIGNvbmNlcHQgb2YgaW50ZW5k ZWQgY29uZmlndXJhdGlvbg0KPj4gPmFuZCBhcHBsaWVkIGNvbmZpZ3VyYXRpb24sIHdoeSBub3Qg cHV0IHRoZXNlIHRlcm1zIGludG8gdGhlIHRpdGxlDQo+PiA+aW5zdGVhZCBvZiAiRW5oYW5jZWQg T3BlcmF0aW9uYWwgU3RhdGUgVmlzaWJpbGl0eSBhbmQgQ29udHJvbCIsIHdoaWNoDQo+PiA+aXMg c29tZXdoYXQgdmFndWU/IFdoYXQgYWJvdXQgdGhpcyBwcm9wb3NhbDoNCj4+ID4NCj4+ID4JICAg VGVybWlub2xvZ3kgYW5kIFJlcXVpcmVtZW50cyBmb3IgRGlzdGluZ3Vpc2hpbmcNCj4+ID4JCSAg SW50ZW5kZWQgYW5kIEFwcGxpZWQgQ29uZmlndXJhdGlvbg0KPj4gPg0KPj4gPi9qcw0KPj4gPg0K Pj4gPi0tIA0KPj4gPkp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZl cnNpdHkgQnJlbWVuIGdHbWJIDQo+PiA+UGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBD YW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KPj4gPkZheDogICArNDkgNDIx IDIwMCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KPj4g Pg0KPj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ PiA+bmV0bW9kIG1haWxpbmcgbGlzdA0KPj4gPm5ldG1vZEBpZXRmLm9yZw0KPj4gPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+PiANCj4NCj4tLSANCj5KdWVy Z2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21i SA0KPlBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5 IEJyZW1lbiB8IEdlcm1hbnkNCj5GYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRw Oi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCg== From nobody Wed Jan 6 10:31:41 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E4A1A00A3; Wed, 6 Jan 2016 10:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfKK8uoI7_gS; Wed, 6 Jan 2016 10:31:38 -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 0927E1A00AC; Wed, 6 Jan 2016 10:31:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1541; q=dns/txt; s=iport; t=1452105098; x=1453314698; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=ckSVlK83U6sDeiRq4O3smt9pkZwdTzSqLmlmH/SRDxM=; b=FRozzfOn1FpsNCPQtoMlL/4e8TBttoWdnn7DqS0zrkxpGXN1CK/I+VV5 EW+qpB96Qfm86GLVEKBfAMARglPDVJY7+F3oe06Ix2d/kOpBqKd7z28VD yOERsC1JspjyoiL7qhmCxnLE4nUp/kc/foUeVhAY+wduqlKwyYW3XvsdG Q=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpBABGXI1W/xbLJq1ehHmIWbVJhg8Cg?= =?us-ascii?q?XIBAQEBAQGBC4Q1AQEEI1UBEAsOCgkWCwICCQMCAQIBRQYNBgIBAYgrsTaQXAE?= =?us-ascii?q?BAQEBAQEBAgEBAQEBAQEBEgmLVYdzgUkBBJcKgnOBZYh9iSaFVI5HZIJKgUE9N?= =?us-ascii?q?IVhAQEB?= X-IronPort-AV: E=Sophos;i="5.20,530,1444694400"; d="asc'?scan'208";a="623281188" 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; 06 Jan 2016 18:31:36 +0000 Received: from [10.61.164.98] ([10.61.164.98]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u06IVZwN025198; Wed, 6 Jan 2016 18:31:35 GMT To: Dean Bogdanovic References: <5672BAD7.2080003@cisco.com> <1B2DACE1-A8F0-493B-8B61-EF6321790ECE@lucidvision.com> <5672CA38.4060709@cisco.com> <4A6F06C5-7198-4FCA-A10C-0377F595D704@gmail.com> <568AE314.4080401@cisco.com> <131CFB2F-429A-4FC2-95CE-EF616B969145@gmail.com> From: Eliot Lear Message-ID: <568D5D87.2070401@cisco.com> Date: Wed, 6 Jan 2016 19:31:35 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <131CFB2F-429A-4FC2-95CE-EF616B969145@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rtJlwGOoU84UdkBD0tSQ2fCB9cMVwIgjv" Archived-At: Cc: RTG YANG Design Team , netmod WG , Benoit Claise Subject: Re: [netmod] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 18:31:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rtJlwGOoU84UdkBD0tSQ2fCB9cMVwIgjv Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 1/6/16 4:59 PM, Dean Bogdanovic wrote: >> On Jan 4, 2016, at 10:24 PM, Eliot Lear wrote: >> >> Hi, >> >> I guess what I'm hearing is that we should do a hopefully very short >> augmentation for domain names in the matches clause and standardize th= at >> separately. Does that seem reasonable? > Yes, if you think there is a need for such a draft and IPR issue is cle= ared, WG adopts it, why not The only reason not to do that is you will end up many many of drafts like mine, dinking the model. I realize some view that as a positive.=20 I'm not so sure. Eliot --rtJlwGOoU84UdkBD0tSQ2fCB9cMVwIgjv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJWjV2HAAoJEIe2a0bZ0noz398IAJdCcH8z6plGyO9S/rUgxVDa rAuTrzGhCIY3Jcr711SqKafavSEHp1Wo752ASFTuKf5vk7+Rpuwq3TK382MjuRuH MCrchmctSE3U4dtgLi13NOzZ4c50zwJV8H4tveYA4u1pXp33E/jluq8SJWKF9E8d CN/7q5R1/oP3ZbcoBNX0ij+Wckvfq359APuFoD7WffMNSNeZxb8tBFHipvzNilNx Ky+U2CIA+OiyvUQ3oQxDJrDdKBw/q2nfaFOwh1j4ZLKFJLqCuHxAV4C7R0USA87E hZsl9XHxPbsZczzkVc628/3dz5JDZnxLUwirjfwBTsKzbGk5hGFwVih+Ynkk93I= =afdp -----END PGP SIGNATURE----- --rtJlwGOoU84UdkBD0tSQ2fCB9cMVwIgjv-- From nobody Wed Jan 6 15:24:53 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0E91A1BCB; Wed, 6 Jan 2016 15:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.257 X-Spam-Level: X-Spam-Status: No, score=-96.257 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Raf8XrOck1Nr; Wed, 6 Jan 2016 15:24:46 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 D89DA1A1BCA; Wed, 6 Jan 2016 15:24:45 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.177; From: "Susan Hares" To: "'John Strassner'" References: <20160104170330.13929.73845.idtracker@ietfa.amsl.com> <006701d14722$616c6950$24453bf0$@ndzh.com> <568ADBE7.3030101@joelhalpern.com> <00b501d1473f$fef22990$fcd67cb0$@ndzh.com> In-Reply-To: Date: Wed, 6 Jan 2016 18:25:00 -0500 Message-ID: <013001d148d9$770626d0$65127470$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0131_01D148AF.8E363950" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHC7aVhYcGa1ChTuo//84M/O+4YZwFG1DOWAZ3SDjgCb9eFfwLXL+Oqnsp5rGA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, supa@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Supa] [i2rs] FW: New Version Notification for draft-hares-i2rs-bnp-eca-data-model-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 23:24:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0131_01D148AF.8E363950 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable John:=20 =20 You are correct in indicating that the draft assumes you understand the = event =3D Packet reception. It is a failing in the draft that Joel has = indicated on these lists. I will be updating the ECA drafts and FB-RIB = drafts. I will send a copy to you and Joel for review this week.=20 =20 Thank you for pointing out the errors in the drafts,=20 =20 Sue=20 =20 From: John Strassner [mailto:strazpdj@gmail.com]=20 Sent: Tuesday, January 05, 2016 10:28 PM To: Susan Hares Cc: Joel M. Halpern; i2rs@ietf.org; netmod@ietf.org; supa@ietf.org; John = Strassner Subject: Re: [Supa] [i2rs] FW: New Version Notification for = draft-hares-i2rs-bnp-eca-data-model-03.txt =20 Sue, > On #1) the dependency between I2RS Filter-based RIB (FB-RIB) and > ECA, please see draft-kini-i2rs-fb-rib-info-model-02.txt. In section = 1.1, > it gives the definition of the FB-RIB. Sorry, it does NOT do this. To quote from this section: A Filter Based RIB uses Event-Condition-Action policy. A Filter- based RIB entry specifies matches on fields in a packet (which may include layer 2 fields, IP header fields, transport or application fields) or size of the packet or interface received on. The matches are contained in an ordered list of filters which contain pairs of match condition-action (aka event-condition-action). Please tell me WHERE the event is in the above definition. All I see is a condition-action rule. (BTW, the analysis of PCIM and PCIMe is also not quite correct in your draft). > In section 1.2, it links this to an event-condition-action model. Sorry, it does NOT do this. First, this section simply says, and I quote: "The filter based-RIB uses event-condition-action policy (ECA) = rules." That is a tautology at best. Second, in Section 2, under the definition of FB-Route, the draft says: "The policy rules in the filter-based RIB are prescriptive of the Event-Condition-Action form which is often represented by if Condition then action." Please note that this definition is incorrect, and in conflict with = SUPA. The whole point of an EVENT-condition-action policy rule is to define a rule of the form: IF evaluates to TRUE IF ENDIF ENDIF This definition has been established in the industry and academia for at least 2 decades. Variations of the above have been defined and published (e.g., FOCALE has an alternate set of actions to execute if the condition clause evaluated to FALSE; this has NOT been proposed for SUPA at this time). There have also been extensions to handle sets and groups, as well as specific ordering (DEN-ng, SID, FOCALE). Therefore, I would suggest that you change your drafts to use a condition-action policy rule, OR update the drafts (I would be happy to help) to use a correct definition of an ECA policy rule. regards, John =20 On Mon, Jan 4, 2016 at 2:33 PM, Susan Hares wrote: Joel:=20 =20 On #1) the dependency between I2RS Filter-based RIB (FB-RIB) and ECA, = please see draft-kini-i2rs-fb-rib-info-model-02.txt. In section 1.1, it = gives the definition of the FB-RIB. In section 1.2, it links this to an = event-condition-action model. If you disagree with the definition of = I2RS FB-RIB, then we should probably restrict this conversation to the = I2RS mail list. Any feedback on the Info-model or data-model would be = helpful. The authors hoped to go to a WG adoption call at the end of = this week.=20 =20 One challenge for the ephemeral I2RS FB-RIB, is there is no definition = of the non-ephemeral FB-RIB. If you think there should be a = non-ephemeral FB-RIB =E2=80=93 that discussion may be useful between = I2RS, Netmod and SUPA.=20 =20 On #2) SUPA ECA model, I agree that we should be able to have a common = draft. At IETF 94, I raised issues regarding the SUPA versus my ECA = definition. =20 =20 Cheerily,=20 =20 Sue=20 =20 -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Monday, January 04, 2016 3:54 PM To: Susan Hares; i2rs@ietf.org; netmod@ietf.org; supa@ietf.org Subject: Re: [i2rs] FW: New Version Notification for = draft-hares-i2rs-bnp-eca-data-model-03.txt =20 I think there are two issues here. =20 1) It is not clear to me why there is any dependence of the fb-rib data = model on an eca data model. While supa does allow for policy model to = be sent directly to the router, it also allows many other cases. =20 2) The approach with the supa eca data model is still under development. = Having said that, the material in there is intended to be very = general. From what I understand, there should be no difficulty in = refining the action side of that model to actions which affect the = fb-rib in ways that are consistent with the fb-dib data model. =20 Yours, Joel =20 On 1/4/16 2:01 PM, Susan Hares wrote: > This model provides a Event-Condition-Action (ECA) policy model. > The I2RS FB-RIB yang data model utilizes this model, but to my=20 > knowledge the Netmod or netconf has not adopted an ECA policy model to = > parallel the ACL model. >=20 > Chen and co-authors have created the model: >=20 > draft-chen-supa-eca-data-model-05.txt >=20 > But it does not align with this yang model or seem sufficient to > support the FB-RIB information model. At IETF 94, > I presented a discussion of the issues I found with the=20 > draft-chen-supa-eca-data-model-05.txt, but it has not been updated. > We would appreciate feedback on this version of yang model. >=20 > > In my role as I2RS chair, I2RS needs to make progress soon on the=20 > I2RS FB-RIB data model. We would appreciate your aid. > >=20 > Sue >=20 > -----Original Message----- > From: internet-drafts@ietf.org [ = mailto:internet-drafts@ietf.org] > Sent: Monday, January 04, 2016 12:04 PM > To: Susan Hares; Qin Wu; Russ White > Subject: New Version Notification for=20 > draft-hares-i2rs-bnp-eca-data-model-03.txt >=20 >=20 > A new version of I-D, draft-hares-i2rs-bnp-eca-data-model-03.txt > has been successfully submitted by Susan Hares and posted to the IETF = repository. >=20 > Name: = draft-hares-i2rs-bnp-eca-data-model > Revision: 03 > Title: An Information Model for Basic Network Policy = and Filter Rules > Document date: 2016-01-04 > Group: Individual Submission > Pages: 30 > URL: = = https://www.ietf.org/internet-drafts/draft-hares-i2rs-bnp-eca-data-model-= 03.txt > Status: = = https://datatracker.ietf.org/doc/draft-hares-i2rs-bnp-eca-data-model/ > Htmlized: = = https://tools.ietf.org/html/draft-hares-i2rs-bnp-eca-data-model-03 > Diff: = = https://www.ietf.org/rfcdiff?url2=3Ddraft-hares-i2rs-bnp-eca-data-model-0= 3 >=20 > Abstract: > This document contains the Basic Network Policy and Filters (BNP = IM) > Data Model which provides a policy model that support an ordered = list > of match-condition-action (aka event-condition-action (ECA)) for > multiple layers (interface, L1-L4, application) and other factors > (size of packet, time of day). The actions allow for setting = actions > (QOS and other), decapsulation, encapsulation, plus forwarding > actions. The policy model can be used with the I2RS filter-based > RIB. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > = https://www.ietf.org/mailman/listinfo/i2rs >=20 _______________________________________________ Supa mailing list Supa@ietf.org https://www.ietf.org/mailman/listinfo/supa --=20 regards, John ------=_NextPart_000_0131_01D148AF.8E363950 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

John:

 

You are correct in indicating that the draft assumes you understand = the event =3D Packet reception.=C2=A0 It is a failing in the draft that = Joel has indicated on these lists. =C2=A0I will be updating the ECA = drafts and FB-RIB drafts.=C2=A0 I will send a copy to you and Joel for = review this week.

 

Thank you for pointing out the errors in the drafts, =

 

Sue

 

From:= = John Strassner [mailto:strazpdj@gmail.com]
Sent: Tuesday, = January 05, 2016 10:28 PM
To: Susan Hares
Cc: Joel = M. Halpern; i2rs@ietf.org; netmod@ietf.org; supa@ietf.org; John = Strassner
Subject: Re: [Supa] [i2rs] FW: New Version = Notification for = draft-hares-i2rs-bnp-eca-data-model-03.txt

 

Sue,

> On #1) the = dependency between I2RS Filter-based RIB (FB-RIB) and
> ECA, = please see draft-kini-i2rs-fb-rib-info-model-02.txt. In section = 1.1,
> it gives the definition of the = FB-RIB.

Sorry, it does NOT do this. To quote from this = section:

   A Filter Based = RIB uses Event-Condition-Action policy. A Filter-
   based = RIB entry specifies matches on fields in a packet (which may
  =  include layer 2 fields, IP header fields, transport or = application
   fields) or size of the packet or interface = received on. The matches
   are contained in an ordered = list of filters which contain pairs of
   match = condition-action (aka = event-condition-action).

Please tell me WHERE = the event is in the above definition. All I see is
a condition-action = rule. (BTW, the analysis of PCIM and PCIMe is also
not quite correct = in your draft).

> In section 1.2, it links this to = an event-condition-action model.

Sorry, it does NOT do = this.

First, this section simply says, and I = quote:

   "The filter = based-RIB uses event-condition-action policy (ECA) = rules."

That is a tautology = at best.

Second, in Section 2, = under the definition of FB-Route, the draft = says:

   "The = policy rules in the filter-based RIB are prescriptive of = the
     Event-Condition-Action form which = is often represented by
        if = Condition then action."

Please note that this definition is incorrect, and in conflict = with SUPA.
The whole point of an EVENT-condition-action policy rule = is to define
a rule of the form:

    IF <event_clause> evaluates to = TRUE
        IF = <condition_clause evaluates to = TRUE
           = ; THEN execute actions in = <action_clause>
        = ENDIF
    ENDIF

This definition has been established in the industry and = academia
for at least 2 decades.

Variations of the above have been defined and published = (e.g.,
FOCALE has an alternate set of actions to execute if the = condition
clause evaluated to FALSE; this has NOT been proposed for = SUPA
at this time). There have also been extensions to handle sets = and
groups, as well as specific ordering (DEN-ng, SID, = FOCALE).

Therefore, I would = suggest that you change your drafts to use a
condition-action policy = rule, OR update the drafts (I would be happy
to help) to use a = correct definition of an ECA policy rule.

regards,
John

 

On Mon, = Jan 4, 2016 at 2:33 PM, Susan Hares <shares@ndzh.com> = wrote:

Joel: =

 

On #1) the dependency between = I2RS Filter-based RIB (FB-RIB) and ECA, please see = draft-kini-i2rs-fb-rib-info-model-02.txt. In section 1.1, it gives the = definition of the FB-RIB.  In section 1.2, it links this to an = event-condition-action model.  If you disagree with the definition = of  I2RS FB-RIB, then we should probably restrict this conversation = to the I2RS mail list.  Any feedback on the Info-model or = data-model would be helpful.  The authors hoped to go to a WG = adoption call at the end of this week. =

 

One challenge for the = ephemeral I2RS FB-RIB, is there is no definition of the non-ephemeral = FB-RIB.  If you think there should be a non-ephemeral FB-RIB = =E2=80=93 that discussion may be useful between I2RS, Netmod and SUPA. =

 

On #2) SUPA ECA model, I agree = that we should be able to have a common draft.  At IETF 94, I = raised issues regarding the SUPA versus my ECA definition.  =  

 

Cheerily, =

 

Sue =

 

-----Original = Message-----
From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
Sent: Monday, January 04, = 2016 3:54 PM
To: Susan Hares; i2rs@ietf.org; netmod@ietf.org; supa@ietf.org
Subject: Re: [i2rs] FW: New = Version Notification for = draft-hares-i2rs-bnp-eca-data-model-03.txt

 

I think there are two issues = here.

 

1) It is not clear to me = why there is any dependence of the fb-rib data model on an eca data = model.  While supa does allow for policy model to be sent directly = to the router, it also allows many other = cases.

 

2) The approach with the = supa eca data model is still under development. =

  Having said that, the material in there is = intended to be very general.  From what I understand, there should = be no difficulty in refining the action side of that model to actions = which affect the fb-rib in ways that are consistent with the fb-dib data = model.

 

Yours,

J= oel

 

On 1/4/16 2:01 PM, Susan = Hares wrote:

> This model provides a = Event-Condition-Action (ECA) policy model.

> The = I2RS FB-RIB yang data model utilizes this model, but to my =

> knowledge the Netmod or netconf has not adopted = an ECA policy model to

> parallel the ACL = model.

> 

> Chen and = co-authors have created the = model:

> 

> = draft-chen-supa-eca-data-model-05.txt

> 

> But it does not align with this yang model or seem = sufficient to

> support the FB-RIB information = model.   At IETF 94,

> I presented a = discussion of the issues I found with the

> = draft-chen-supa-eca-data-model-05.txt, but it has not been = updated.

> We would appreciate feedback on this = version of yang model.

> 

> = <i2rs Chair hat on>

> In my role as I2RS = chair,  I2RS needs to make progress soon on the =

> I2RS FB-RIB data model.  We would appreciate = your aid.

> <i2rs chair hat = off>

> 

> = Sue

> 

> -----Original = Message-----

> From: internet-drafts@ietf.org<= /span> [mailto:internet-drafts@ie= tf.org]

> Sent: Monday, January 04, 2016 = 12:04 PM

> To: Susan Hares; Qin Wu; Russ = White

> Subject: New Version Notification for =

> = draft-hares-i2rs-bnp-eca-data-model-03.txt

> 

> 

> A new version of I-D, = draft-hares-i2rs-bnp-eca-data-model-03.txt

> has = been successfully submitted by Susan Hares and posted to the IETF = repository.

> 

> = Name:           &n= bsp;           &nb= sp;       = draft-hares-i2rs-bnp-eca-data-model

> = Revision:          = 03

> = Title:           &= nbsp;      An Information Model for Basic = Network Policy and Filter Rules

> Document = date:           = 2016-01-04

> = Group:           &= nbsp;           &n= bsp;      Individual = Submission

> = Pages:           &= nbsp;           &n= bsp;       30

> = URL:            = https://www.ietf.org/inte= rnet-drafts/draft-hares-i2rs-bnp-eca-data-model-03.txt

> Status:         = https://datatracker.ietf.= org/doc/draft-hares-i2rs-bnp-eca-data-model/

= > Htmlized:       https://tools.ietf.org/ht= ml/draft-hares-i2rs-bnp-eca-data-model-03

>= ; Diff:           https://www.ietf.org/rfcd= iff?url2=3Ddraft-hares-i2rs-bnp-eca-data-model-03

> 

> = Abstract:

>     This document = contains the Basic Network Policy and Filters (BNP = IM)

>     Data Model which = provides a policy model that support an ordered = list

>     of = match-condition-action (aka event-condition-action (ECA)) = for

>     multiple layers = (interface, L1-L4, application) and other = factors

>     (size of packet, = time of day).  The actions allow for setting = actions

>     (QOS and other), = decapsulation, encapsulation, plus = forwarding

>     actions.  = The policy model can be used with the I2RS = filter-based

>     = RIB.

> 

> 

> 

> 

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

> 

> The IETF = Secretariat

> 

> <= /o:p>

> = _______________________________________________

> = i2rs mailing list

> i2rs@ietf.org<= o:p>

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

> 


______________________________________= _________
Supa mailing list
Supa@ietf.org
https://www.ietf.org/mailman/listinfo/supa




-- =

regards,

John

------=_NextPart_000_0131_01D148AF.8E363950-- From nobody Wed Jan 6 16:04:29 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976E01A1EFA for ; Wed, 6 Jan 2016 16:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXhN1JB8Xfah for ; Wed, 6 Jan 2016 16:04:25 -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 6CAA41A1EF7 for ; Wed, 6 Jan 2016 16:04:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7372; q=dns/txt; s=iport; t=1452125065; x=1453334665; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=NUifER6Cx/AWCQCgF0xvvAAy7hrj8TnNkeKK3HPEmeo=; b=OAJOx5TJ0zEoEjNHHLR7wRyJ67mhGC4YBIGFa5hjIlwrDffo4XUA39+y 6aJPsAS7cmJ18bDK9Pk+bQeO8KGBZ4yOxab1wrBGhyzch4keMXCB/CXFS efZY0yRKNlDw5IrsHUqtPSBEXwtmxxiCTep+33SbPQ16gMWjpKAZALGNf o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuBADMqo1W/xbLJq1egm6BHm0GiFO1T?= =?us-ascii?q?BqFdQIcgVUBAQEBAQGBC4Q0AQEBBCMKXAIBCBEEAQEoAwICAjAUCQgCBAESCIg?= =?us-ascii?q?SAxKxGo1uGIJhAQEBAQEBAQEBAQEBAQEBAQEBAQEBFASLVYUECYJmgUkFlwoBh?= =?us-ascii?q?UGIDI8BjkYBZIQKcoRZgQgBAQE?= X-IronPort-AV: E=Sophos;i="5.20,530,1444694400"; d="scan'208,217";a="624318664" 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; 07 Jan 2016 00:04:23 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u0704Mth028386 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Jan 2016 00:04:23 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 6 Jan 2016 19:04:21 -0500 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Wed, 6 Jan 2016 19:04:21 -0500 From: "Alexander Clemm (alex)" To: "rohitrranade@outlook.com" , "netmod@ietf.org" Thread-Topic: [netmod] Draft clemm netmod mount draft Thread-Index: AQHRPK4pJt5mrGs2Wky9oR8fFVfm4Z7vQzeg Date: Thu, 7 Jan 2016 00:04:21 +0000 Message-ID: <4bddb837fe03458c8ca98f513f88aa8e@XCH-RTP-001.cisco.com> 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.24.110.161] Content-Type: multipart/alternative; boundary="_000_4bddb837fe03458c8ca98f513f88aa8eXCHRTP001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] Draft clemm netmod mount draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 00:04:27 -0000 --_000_4bddb837fe03458c8ca98f513f88aa8eXCHRTP001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCnRoaXMgd2FzIGludGVuZGVkIGFzIGFuIGV4YW1wbGUuICBUaGUgcmVhc29uIHRvIGlu Y2x1ZGUgdGhlIGludGVyZmFjZXMgbW9kdWxlIGlzIHRoZSBzY2VuYXJpbyBpbiB3aGljaCBhIGNv bnRyb2xsZXIgd291bGQgbGlrZSB0byBoYXZlIGEgbW9kZWwvaW52ZW50b3J5IG9mIHRoZSB2YXJp b3VzIGludGVyZmFjZXMgYWNyb3NzIHRoZSBuZXR3b3JrLiAgRWFjaCBuZXR3b3JrIGRldmljZSB3 aWxsIGhhdmUgaXRzIG93biBpbnN0YW50aWF0aW9uIG9mIHRoZSBpbnRlcmZhY2VzIG1vZHVsZS4g IFJhdGhlciB0aGFuIHJlcGxpY2F0aW5nIGludGVyZmFjZXMgaW5mb3JtYXRpb24gaW4gYSBuZXR3 b3JrIGNvbnRyb2xsZXIgbW9kZWwsIGJ5IG1vdW50aW5nIHRoaXMgZGF0YSB1bmRlciB0aGUgY29y cmVzcG9uZGluZyBuZXR3b3JrIGVsZW1lbnTigJlzIGxpc3QgZWxlbWVudCwgdGhlIG5lZWQgdG8g cmUtZGVmaW5lIGludGVyZmFjZSBkYXRhIChqdXN0IHRvIGJlIGluY2x1ZGVkIGluIGEgZGlmZmVy ZW50IHBsYWNlIGluIHRoZSBjb250YWlubWVudCBoaWVyYXJjaHkpIGlzIGF2b2lkZWQuDQoNCkhv cGUgdGhhdCBoZWxwcw0KLS0tIEFsZXggKGp1c3QgcmV0dXJuaW5nIGZyb20gaG9saWRheSBicmVh aywgaGVuY2UgdGhlIGRlbGF5ZWQgcmVzcG9uc2UpDQoNCkZyb206IG5ldG1vZCBbbWFpbHRvOm5l dG1vZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Ygcm9oaXRycmFuYWRlQG91dGxvb2su Y29tDQpTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAyMiwgMjAxNSAzOjQ1IEFNDQpUbzogbmV0bW9k QGlldGYub3JnDQpTdWJqZWN0OiBbbmV0bW9kXSBEcmFmdCBjbGVtbSBuZXRtb2QgbW91bnQgZHJh ZnQNCg0KDQpJbiB0aGUgY29udHJvbGxlci1uZXR3b3JrIGRhdGEgbW9kZWwgLCBpcyB0aGUgaW50 ZXJmYWNlcyBtb2R1bGUgaW1wb3J0ZWQgZm9yIGEgc3BlY2lmaWMgcmVhc29uID8NCg0KU2VudCBm cm9tIE91dGxvb2sgTW9iaWxlPGh0dHBzOi8vYWthLm1zL2JsaGd0ZT4NCg== --_000_4bddb837fe03458c8ca98f513f88aa8eXCHRTP001ciscocom_ 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 dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGksPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj50aGlzIHdhcyBpbnRlbmRlZCBhcyBh biBleGFtcGxlLiZuYnNwOyBUaGUgcmVhc29uIHRvIGluY2x1ZGUgdGhlIGludGVyZmFjZXMgbW9k dWxlIGlzIHRoZSBzY2VuYXJpbyBpbiB3aGljaCBhIGNvbnRyb2xsZXIgd291bGQgbGlrZSB0byBo YXZlIGEgbW9kZWwvaW52ZW50b3J5IG9mIHRoZQ0KIHZhcmlvdXMgaW50ZXJmYWNlcyBhY3Jvc3Mg dGhlIG5ldHdvcmsuJm5ic3A7IEVhY2ggbmV0d29yayBkZXZpY2Ugd2lsbCBoYXZlIGl0cyBvd24g aW5zdGFudGlhdGlvbiBvZiB0aGUgaW50ZXJmYWNlcyBtb2R1bGUuJm5ic3A7IFJhdGhlciB0aGFu IHJlcGxpY2F0aW5nIGludGVyZmFjZXMgaW5mb3JtYXRpb24gaW4gYSBuZXR3b3JrIGNvbnRyb2xs ZXIgbW9kZWwsIGJ5IG1vdW50aW5nIHRoaXMgZGF0YSB1bmRlciB0aGUgY29ycmVzcG9uZGluZyBu ZXR3b3JrIGVsZW1lbnTigJlzDQogbGlzdCBlbGVtZW50LCB0aGUgbmVlZCB0byByZS1kZWZpbmUg aW50ZXJmYWNlIGRhdGEgKGp1c3QgdG8gYmUgaW5jbHVkZWQgaW4gYSBkaWZmZXJlbnQgcGxhY2Ug aW4gdGhlIGNvbnRhaW5tZW50IGhpZXJhcmNoeSkgaXMgYXZvaWRlZC4mbmJzcDsNCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SG9wZSB0aGF0IGhlbHBzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPi0tLSBBbGV4IChqdXN0IHJldHVybmluZyBmcm9tIGhvbGlkYXkgYnJlYWss IGhlbmNlIHRoZSBkZWxheWVkIHJlc3BvbnNlKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBuZXRtb2QgW21haWx0bzpuZXRt b2QtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+cm9oaXRycmFuYWRlQG91 dGxvb2suY29tPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIERlY2VtYmVyIDIyLCAyMDE1IDM6 NDUgQU08YnI+DQo8Yj5Ubzo8L2I+IG5ldG1vZEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9i PiBbbmV0bW9kXSBEcmFmdCBjbGVtbSBuZXRtb2QgbW91bnQgZHJhZnQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SW4gdGhlIGNvbnRyb2xsZXItbmV0d29yayBkYXRh IG1vZGVsICwgaXMgdGhlIGludGVyZmFjZXMgbW9kdWxlIGltcG9ydGVkIGZvciBhIHNwZWNpZmlj IHJlYXNvbiA/PG86cD48L286cD48L3A+DQo8cD5TZW50IGZyb20gPGEgaHJlZj0iaHR0cHM6Ly9h a2EubXMvYmxoZ3RlIj5PdXRsb29rIE1vYmlsZTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_4bddb837fe03458c8ca98f513f88aa8eXCHRTP001ciscocom_-- From nobody Wed Jan 6 16:50:18 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 419D01A21A9; Wed, 6 Jan 2016 16:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XU7TaDYeeyqX; Wed, 6 Jan 2016 16:50:12 -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 94AA91A21A7; Wed, 6 Jan 2016 16:50:09 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CGL00628; Thu, 07 Jan 2016 00:50:06 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.218.25.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 7 Jan 2016 00:50:05 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.81]) by SJCEML703-CHM.china.huawei.com ([169.254.5.130]) with mapi id 14.03.0235.001; Wed, 6 Jan 2016 16:50:00 -0800 From: John Strassner To: Susan Hares , "'John Strassner'" , "'Joel M. Halpern'" Thread-Topic: [Supa] [i2rs] FW: New Version Notification for draft-hares-i2rs-bnp-eca-data-model-03.txt Thread-Index: AQHRSDASitFFz8IO2EOQtMd8cV25dJ7vDmuAgAAnhjA= Date: Thu, 7 Jan 2016 00:49:59 +0000 Message-ID: References: <20160104170330.13929.73845.idtracker@ietfa.amsl.com> <006701d14722$616c6950$24453bf0$@ndzh.com> <568ADBE7.3030101@joelhalpern.com> <03c101d1488c$587503a0$095f0ae0$@ndzh.com> In-Reply-To: <03c101d1488c$587503a0$095f0ae0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.96.255.167] Content-Type: multipart/alternative; boundary="_000_B818037A70EDCC4A86113DA25EC02098201B9466SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.568DB63F.00C2, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.81, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4d6003bfb2e2615615912651f617b7fb Archived-At: Cc: "i2rs@ietf.org" , "supa@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] [Supa] [i2rs] FW: New Version Notification for draft-hares-i2rs-bnp-eca-data-model-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 00:50:17 -0000 --_000_B818037A70EDCC4A86113DA25EC02098201B9466SJCEML701CHMchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3VlLA0KDQpZb3UgYXJlIGNvcnJlY3QsIGl0IGlzIGEgdmVyeSBzaW1wbGUgY2FzZSwgd2l0 aCBvbmUgdHlwZSBvZiBldmVudC4gICBKb2VsIGluZGljYXRlZCBmbGF3cyBpbiB0aGUgZG9jdW1l bnQgdGhhdCBpdCBkaWQgbm90IGluZGljYXRlIHRoZSBldmVudCB3YXMgYSDigJxwYWNrZXQgcmVj ZXB0aW9u4oCdLiAgQXQgdGhpcyBwb2ludCwgaXQgc291bmRzIGxpa2UgeW91IGFuZCBKb2VsIGFy ZSBzdWdnZXN0aW5nIHRoYXQgdGhpcyBwYXJ0aWN1bGFyIHNpbXBsaXN0aWMgY2FzZSBvZiBFdmVu dC1Db25kaXRpb24tQWN0aW9uIGlzIE9LIHRvIGdvIGZvcndhcmQgd2l0aCBpbiB0aGUgSTJSUyAo Zm9yIGVwaGVtZXJhbCBzdGF0ZSksIGFuZCBpbiBhcHByb3ByaWF0ZSBXRyBmb3IgdGhlIG5vbi1l cGhlbWVyYWwgY2FzZS4gIElzIHRoaXMgY29ycmVjdD8NCg0KPGpjcz4NCkFzIGxvbmcgYXMgaXQg aXMgY2xhcmlmaWVkIHRoYXQgdGhlcmUgaXMsIGluIGZhY3QsIGFuIGV2ZW50LCB0aGVuIEkgdGhp bmsgdGhhdCBpdCBpcyBmaW5lLiBOb3RlIHRoYXQgaXQgc2hvdWxkIGFsc28gYmUgY2xhcmlmaWVk IHRoYXQgaWYgdGhlIEV2ZW50IGlzIG5vdCByZWNlaXZlZCwgdGhlbiB0aGUgY29uZGl0aW9uIGNs YXVzZSBjYW4gbmV2ZXIgYmUgZXZhbHVhdGVkLg0KPC9qY3M+DQoNCkF0IElFVEYgOTQsIEkgd2Fz IHNpbXBseSBjb21wYXJpbmcgQ2hlbuKAmXMgZG9jdW1lbnQgdmVyc3VzIHRoaXMgdmVyeSBzaW1w bGUgY2FzZSBvZiBhbiBFQ0EuICBJIGRpZCBub3QgbWVhbiB0byBpbXBseSBpdCB3YXMgdGhlIG9u bHkgcG9zc2libGUgRUNBIGNhc2UuICAgSSBsb29rIGZvcndhcmQgdG8gaGVhcmluZyBmcm9tIHRo ZSBTVVBBIGxpc3QgcmVnYXJkaW5nIHRoZSBnZW5lcmljIEVDQSBpbmZvcm1hdGlvbiBtb2RlbCBh bmQgdGhlIGRpZmZlcmVudCB0eXBlcyBvZiBFQ0EuDQoNCjxqY3M+DQpUaGF0J3Mgd2hhdCBjb25m dXNlZCBtZSAtIHRoZSBjaGVuIGRvY3VtZW50IGRpZCBoYXZlIGV2ZW50IG5vZGVzIGluIGl0LCBh bmQgeW91ciBkcmFmdCBkaWRuJ3QuIFRoYXQgYmVpbmcgc2FpZCwgdGhlcmUgYXJlIG1hbnkgd2F5 cyB0byBkZWZpbmUgRXZlbnRzLiBJZiB5b3UgbG9vayBhdCB0aGUgU1VQQSBtb2RlbCwgeW91IHdp bGwgc2VlIHRoZSBmb2xsb3dpbmcgZXhlbXBsYXIgbWV0aG9kczoNCg0KDQrCtyAgICAgICAgIHlv dSBjYW4gZGVmaW5lIGEgY2xhdXNlLCBvZiB0aGUgY2Fub25pY2FsIGZvcm0ge3ZhcmlhYmxlLCBv cGVyYXRvciwgdmFsdWV9LCB0byByZXByZXNlbnQgYW4gZXZlbnQgKGUuZy4sIHRpbWUgPT0gMDg6 MDBhbSkNCg0KwrcgICAgICAgICB5b3UgY2FuIHVzZSBhbiBFdmVudCBvYmplY3QgYXMgdGhlIHZh cmlhYmxlIG9yIHRoZSB2YWx1ZSBpbiB0aGUgYWJvdmUgY2xhdXNlIChlLmcuLCB1c2Ugb25lIG9y IG1vcmUgYXR0cmlidXRlcyBmcm9tIG9uZSBvciBtb3JlIEV2ZW50IG9iamVjdHMgaW4gdGhlIGNv bXBhcmlzb24gY2xhdXNlKQ0KDQrCtyAgICAgICAgIHlvdSBjYW4gdXNlIGEgQ29sbGVjdGlvbiBh dHRyaWJ1dGVzIHRvIGNvbGxlY3QgZXZlbnRzIGZvciBhZ2dyZWdhdGlvbiwgZmlsdGVyaW5nLCBh bmQvb3IgY29ycmVsYXRpb24gb3BlcmF0aW9ucyBhcyBwYXJ0IG9mIHRoZSBldmVudCBjbGF1c2Ug cHJvY2Vzc2luZw0KDQrCtyAgICAgICAgIHlvdSBjYW4gZW5jb2RlIHRoZSBlbnRpcmUgZXZlbnQg ZXhwcmVzc2lvbiBpbnRvIGFuIGF0dHJpYnV0ZQ0KPC9qY3M+DQoNCnJlZ2FyZHMsDQpKb2huDQoN CkZyb206IFN1cGEgW21haWx0bzpzdXBhLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBT dXNhbiBIYXJlcw0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDA2LCAyMDE2IDY6MTMgQU0NClRv OiAnSm9obiBTdHJhc3NuZXInOyAnSm9lbCBNLiBIYWxwZXJuJw0KQ2M6IGkycnNAaWV0Zi5vcmc7 IG5ldG1vZEBpZXRmLm9yZzsgc3VwYUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtTdXBhXSBbaTJy c10gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaGFyZXMtaTJycy1ibnAt ZWNhLWRhdGEtbW9kZWwtMDMudHh0DQoNCkpvaG46DQoNClRoYW5rIHlvdSBmb3IgeW91ciByZXNw b25zZS4gICBGb3IgZmlsdGVyLWJhc2VkIEZJQiwNCg0KRXZlbnQgPSByZWNlaXZpbmcgcGFja2V0 IGluZm9ybWF0aW9uIG9uIHRoZSBpbnRlcmZhY2UNCkNvbmRpdGlvbiA9IG1hdGNoIG9uIGEgdmFy aWV0eSBvZiBjb25kaXRpb25zIChzZWUgdGhlIGRyYWZ0KQ0KQWN0aW9uID0gYSBjaG9pY2Ugb2Yg YWN0aW9ucyBtb2RpZnkgcGFja2V0LCBmb3J3YXJkL2Ryb3AgcGFja2V0LCBhbmQgY291bnQgcGFj a2V0Lg0KDQpZb3UgYXJlIGNvcnJlY3QsIGl0IGlzIGEgdmVyeSBzaW1wbGUgY2FzZSwgd2l0aCBv bmUgdHlwZSBvZiBldmVudC4gICBKb2VsIGluZGljYXRlZCBmbGF3cyBpbiB0aGUgZG9jdW1lbnQg dGhhdCBpdCBkaWQgbm90IGluZGljYXRlIHRoZSBldmVudCB3YXMgYSDigJxwYWNrZXQgcmVjZXB0 aW9u4oCdLiAgQXQgdGhpcyBwb2ludCwgaXQgc291bmRzIGxpa2UgeW91IGFuZCBKb2VsIGFyZSBz dWdnZXN0aW5nIHRoYXQgdGhpcyBwYXJ0aWN1bGFyIHNpbXBsaXN0aWMgY2FzZSBvZiBFdmVudC1D b25kaXRpb24tQWN0aW9uIGlzIE9LIHRvIGdvIGZvcndhcmQgd2l0aCBpbiB0aGUgSTJSUyAoZm9y IGVwaGVtZXJhbCBzdGF0ZSksIGFuZCBpbiBhcHByb3ByaWF0ZSBXRyBmb3IgdGhlIG5vbi1lcGhl bWVyYWwgY2FzZS4gIElzIHRoaXMgY29ycmVjdD8NCg0KQXQgSUVURiA5NCwgSSB3YXMgc2ltcGx5 IGNvbXBhcmluZyBDaGVu4oCZcyBkb2N1bWVudCB2ZXJzdXMgdGhpcyB2ZXJ5IHNpbXBsZSBjYXNl IG9mIGFuIEVDQS4gIEkgZGlkIG5vdCBtZWFuIHRvIGltcGx5IGl0IHdhcyB0aGUgb25seSBwb3Nz aWJsZSBFQ0EgY2FzZS4gICBJIGxvb2sgZm9yd2FyZCB0byBoZWFyaW5nIGZyb20gdGhlIFNVUEEg bGlzdCByZWdhcmRpbmcgdGhlIGdlbmVyaWMgRUNBIGluZm9ybWF0aW9uIG1vZGVsIGFuZCB0aGUg ZGlmZmVyZW50IHR5cGVzIG9mIEVDQS4NCg0KU3VlDQoNCkZyb206IFN1cGEgW21haWx0bzpzdXBh LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb2huIFN0cmFzc25lcg0KU2VudDogVHVl c2RheSwgSmFudWFyeSAwNSwgMjAxNiAxMDoxMiBQTQ0KVG86IEpvZWwgTS4gSGFscGVybg0KQ2M6 IGkycnNAaWV0Zi5vcmc7IHN1cGFAaWV0Zi5vcmc7IG5ldG1vZEBpZXRmLm9yZzsgU3VzYW4gSGFy ZXMNClN1YmplY3Q6IFJlOiBbU3VwYV0gW2kycnNdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LWhhcmVzLWkycnMtYm5wLWVjYS1kYXRhLW1vZGVsLTAzLnR4dA0KDQpIaSBK b2UsIGV0IGFsLiwNCg0KPiAxKSBJdCBpcyBub3QgY2xlYXIgdG8gbWUgd2h5IHRoZXJlIGlzIGFu eSBkZXBlbmRlbmNlIG9mIHRoZSBmYi1yaWINCj4gZGF0YSBtb2RlbCBvbiBhbiBlY2EgZGF0YSBt b2RlbC4gIFdoaWxlIHN1cGEgZG9lcyBhbGxvdyBmb3INCj4gcG9saWN5IG1vZGVsIHRvIGJlIHNl bnQgZGlyZWN0bHkgdG8gdGhlIHJvdXRlciwgaXQgYWxzbyBhbGxvd3MgbWFueQ0KPiBvdGhlciBj YXNlcy4NCg0KRXhhY3RseS4gTW9yZSBwYXJ0aWN1bGFybHksIGluIHNjYW5uaW5nIHRoaXMgZHJh ZnQsIEkgZmFpbCB0byBzZWUgaG93DQp0aGlzIGlzIGFuIGFjY2VwdGVkIGRlZmluaXRpb24gb2Yg RUNBLiBJbiBwYXJ0aWN1bGFyLCB0aGVyZSBkb2Vzbid0DQpzZWVtIHRvIGJlIGFueSBldmVudCBp biB0aGUgcnVsZSBkZWZpbml0aW9uLg0KDQpIZW5jZSwgSSB3b3VsZCBzdWdnZXN0IHRoYXQgeW91 IGFkZCB3b3JkaW5nIHRoYXQgc2F5cyB0aGF0IHRoaXMgaXMNCm9uZSBvZiBtYW55IHdheXMgdG8g YnVpbGQgc3VjaCBhIG1hcHBpbmcuDQoNCg0KPiAyKSBUaGUgYXBwcm9hY2ggd2l0aCB0aGUgc3Vw YSBlY2EgZGF0YSBtb2RlbCBpcyBzdGlsbCB1bmRlcg0KPiBkZXZlbG9wbWVudC4NCg0KQWJzb2x1 dGVseSBhZ3JlZS4gSW4gcGFydGljdWxhciwgZHJhZnQtY2hlbiB3YXMgdGhlIGZpcnN0IGF0dGVt cHQgYXQNCnRyeWluZyB0byBjb25jZXB0dWFsaXplIHdoYXQgc3VjaCBhIGRhdGEgbW9kZWwgc2hv dWxkIGxvb2sgbGlrZS4NCg0KPiAgSGF2aW5nIHNhaWQgdGhhdCwgdGhlIG1hdGVyaWFsIGluIHRo ZXJlIGlzIGludGVuZGVkIHRvIGJlIHZlcnkNCj4gZ2VuZXJhbC4NCg0KSUZGIHlvdSBtZWFuIHRo ZSBTVVBBIGluZm8gbW9kZWwsIHRoZW4gYWJzb2x1dGVseSAob3RoZXJ3aXNlLA0KaXQgaGFzIGZh aWxlZCBpbiBpdHMgcHJpbWFyeSBtaXNzaW9uIG9mIHByb3ZpZGluZyBhbiBleHRlbnNpYmxlDQpm cmFtZXdvcmsgdG8gZGVmaW5lIHBvbGljaWVzKS4NCg0KSUZGIHlvdSBtZWFuIGRyYWZ0LWNoZW4s IHRoZW4gSSB0aGluayBpdCBhZ3JlZXMgd2l0aCB0aGUgc3Bpcml0IG9mDQp3aGF0IHlvdSBzYWlk LiBJIHRoaW5rIHRoYXQgd2UgbmVlZCB0byBkaXNjdXNzIGhvdyB0byBtYXAgZnJvbQ0KYW4gaW5m byBtb2RlbCB0byBhIGRhdGEgbW9kZWwgaW4gbW9yZSBkZXRhaWwgYmVmb3JlIHdlIGNvbWUgdG8N CmFueSBjb25jbHVzaW9ucyBvZiBpdHMgZWZmaWNhY3kuDQoNCj4gIEZyb20gd2hhdCBJIHVuZGVy c3RhbmQsIHRoZXJlIHNob3VsZCBiZSBubyBkaWZmaWN1bHR5IGluDQo+IHJlZmluaW5nIHRoZSBh Y3Rpb24gc2lkZSBvZiB0aGF0IG1vZGVsIHRvIGFjdGlvbnMgd2hpY2ggYWZmZWN0DQo+IHRoZSBm Yi1yaWIgaW4gd2F5cyB0aGF0IGFyZSBjb25zaXN0ZW50IHdpdGggdGhlIGZiLWRpYiBkYXRhIG1v ZGVsLg0KDQorMS4gSW4gZmFjdCwgdGhlIHdob2xlIHBvaW50IG9mIFNVUEEgaXMgdG8gcHJvdmlk ZSBkaWZmZXJlbnQgd2F5cw0Kb2YgZm9ybWluZyBhbiBFQ0EgcG9saWN5IHJ1bGUgdG8gbWVldCBk aWZmZXJlbnQgZGVtYW5kcyBvZiB0aGUNCnVzZXIuIE1vcmUgcGFydGljdWxhcmx5LCBhdCBJRVRG OTQsIHlvdSAoU3VlKSBhc3N1bWVkIHRoYXQgYW4NCkVDQSBwb2xpY3kgcnVsZSB3YXMgbWFkZSB1 cCBvZiBFdmVudCwgQ29uZGl0aW9uLCBhbmQgQWN0aW9uDQpvYmplY3RzLiBXaGlsZSB0aGF0IGlz IGNlcnRhaW5seSBvbmUgYWx0ZXJuYXRpdmUsIHRoZXJlIGFyZSBvdGhlcnMNCmFzIHdlbGwuIElu IGFkZGl0aW9uLCBwbGVhc2Ugbm90ZSB0aGF0IHRoZSBwcmVzZW5jZSBvZiB0aGVzZQ0Kb2JqZWN0 cyBpcyBOT1Qgc3VmZmljaWVudCB0byBidWlsZCBhbiBFQ0EgcG9saWN5IHJ1bGUgKGUuZy4sIHRo ZQ0KRXZlbnQgb2JqZWN0IG5lZWRzIGFuIGF0dHJpYnV0ZSAob3IgbXVsdGlwbGUgYXR0cmlidXRl cykgdG8gYmUNCmNvbXBhcmVkIHRvIHNvbWV0aGluZyBpbiBvcmRlciB0byBkZXRlcm1pbmUgaWYg dGhlIGV2ZW50DQpDTEFVU0UgZXZhbHVhdGVzIHRvIFRSVUUgb3Igbm90Lg0KDQoNCnJlZ2FyZHMs DQpKb2huDQoNCk9uIE1vbiwgSmFuIDQsIDIwMTYgYXQgMTI6NTMgUE0sIEpvZWwgTS4gSGFscGVy biA8am1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+IHdyb3Rl Og0KSSB0aGluayB0aGVyZSBhcmUgdHdvIGlzc3VlcyBoZXJlLg0KDQoxKSBJdCBpcyBub3QgY2xl YXIgdG8gbWUgd2h5IHRoZXJlIGlzIGFueSBkZXBlbmRlbmNlIG9mIHRoZSBmYi1yaWIgZGF0YSBt b2RlbCBvbiBhbiBlY2EgZGF0YSBtb2RlbC4gIFdoaWxlIHN1cGEgZG9lcyBhbGxvdyBmb3IgcG9s aWN5IG1vZGVsIHRvIGJlIHNlbnQgZGlyZWN0bHkgdG8gdGhlIHJvdXRlciwgaXQgYWxzbyBhbGxv d3MgbWFueSBvdGhlciBjYXNlcy4NCg0KMikgVGhlIGFwcHJvYWNoIHdpdGggdGhlIHN1cGEgZWNh IGRhdGEgbW9kZWwgaXMgc3RpbGwgdW5kZXIgZGV2ZWxvcG1lbnQuICBIYXZpbmcgc2FpZCB0aGF0 LCB0aGUgbWF0ZXJpYWwgaW4gdGhlcmUgaXMgaW50ZW5kZWQgdG8gYmUgdmVyeSBnZW5lcmFsLiAg RnJvbSB3aGF0IEkgdW5kZXJzdGFuZCwgdGhlcmUgc2hvdWxkIGJlIG5vIGRpZmZpY3VsdHkgaW4g cmVmaW5pbmcgdGhlIGFjdGlvbiBzaWRlIG9mIHRoYXQgbW9kZWwgdG8gYWN0aW9ucyB3aGljaCBh ZmZlY3QgdGhlIGZiLXJpYiBpbiB3YXlzIHRoYXQgYXJlIGNvbnNpc3RlbnQgd2l0aCB0aGUgZmIt ZGliIGRhdGEgbW9kZWwuDQoNCllvdXJzLA0KSm9lbA0KDQpPbiAxLzQvMTYgMjowMSBQTSwgU3Vz YW4gSGFyZXMgd3JvdGU6DQpUaGlzIG1vZGVsIHByb3ZpZGVzIGEgRXZlbnQtQ29uZGl0aW9uLUFj dGlvbiAoRUNBKSBwb2xpY3kgbW9kZWwuDQpUaGUgSTJSUyBGQi1SSUIgeWFuZyBkYXRhIG1vZGVs IHV0aWxpemVzIHRoaXMgbW9kZWwsIGJ1dCB0byBteSBrbm93bGVkZ2UgdGhlDQpOZXRtb2Qgb3Ig bmV0Y29uZiBoYXMgbm90IGFkb3B0ZWQgYW4gRUNBIHBvbGljeSBtb2RlbCB0bw0KcGFyYWxsZWwg dGhlIEFDTCBtb2RlbC4NCg0KQ2hlbiBhbmQgY28tYXV0aG9ycyBoYXZlIGNyZWF0ZWQgdGhlIG1v ZGVsOg0KDQpkcmFmdC1jaGVuLXN1cGEtZWNhLWRhdGEtbW9kZWwtMDUudHh0DQoNCkJ1dCBpdCBk b2VzIG5vdCBhbGlnbiB3aXRoIHRoaXMgeWFuZyBtb2RlbCBvciBzZWVtIHN1ZmZpY2llbnQgdG8N CnN1cHBvcnQgdGhlIEZCLVJJQiBpbmZvcm1hdGlvbiBtb2RlbC4gICBBdCBJRVRGIDk0LA0KSSBw cmVzZW50ZWQgYSBkaXNjdXNzaW9uIG9mIHRoZSBpc3N1ZXMgSSBmb3VuZCB3aXRoIHRoZQ0KZHJh ZnQtY2hlbi1zdXBhLWVjYS1kYXRhLW1vZGVsLTA1LnR4dCwgYnV0IGl0IGhhcyBub3QgYmVlbiB1 cGRhdGVkLg0KV2Ugd291bGQgYXBwcmVjaWF0ZSBmZWVkYmFjayBvbiB0aGlzIHZlcnNpb24gb2Yg eWFuZyBtb2RlbC4NCg0KPGkycnMgQ2hhaXIgaGF0IG9uPg0KSW4gbXkgcm9sZSBhcyBJMlJTIGNo YWlyLCAgSTJSUyBuZWVkcyB0byBtYWtlIHByb2dyZXNzIHNvb24gb24gdGhlDQpJMlJTIEZCLVJJ QiBkYXRhIG1vZGVsLiAgV2Ugd291bGQgYXBwcmVjaWF0ZSB5b3VyIGFpZC4NCjxpMnJzIGNoYWly IGhhdCBvZmY+DQoNClN1ZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IFtt YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmc+XQ0KU2VudDogTW9uZGF5LCBKYW51YXJ5IDA0LCAyMDE2IDEyOjA0IFBNDQpUbzogU3Vz YW4gSGFyZXM7IFFpbiBXdTsgUnVzcyBXaGl0ZQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1oYXJlcy1pMnJzLWJucC1lY2EtZGF0YS1tb2RlbC0wMy50eHQNCg0K DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaGFyZXMtaTJycy1ibnAtZWNhLWRhdGEtbW9k ZWwtMDMudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFN1c2FuIEhhcmVz IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAgICAgICAgIGRy YWZ0LWhhcmVzLWkycnMtYm5wLWVjYS1kYXRhLW1vZGVsDQpSZXZpc2lvbjogICAgICAgMDMNClRp dGxlOiAgICAgICAgICBBbiBJbmZvcm1hdGlvbiBNb2RlbCBmb3IgQmFzaWMgTmV0d29yayBQb2xp Y3kgYW5kIEZpbHRlciBSdWxlcw0KRG9jdW1lbnQgZGF0ZTogIDIwMTYtMDEtMDQNCkdyb3VwOiAg ICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAgICAgICAzMA0KVVJMOiAg ICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1oYXJl cy1pMnJzLWJucC1lY2EtZGF0YS1tb2RlbC0wMy50eHQNClN0YXR1czogICAgICAgICBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1oYXJlcy1pMnJzLWJucC1lY2EtZGF0YS1t b2RlbC8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aGFyZXMtaTJycy1ibnAtZWNhLWRhdGEtbW9kZWwtMDMNCkRpZmY6ICAgICAgICAgICBodHRwczov L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaGFyZXMtaTJycy1ibnAtZWNhLWRhdGEt bW9kZWwtMDMNCg0KQWJzdHJhY3Q6DQogICAgVGhpcyBkb2N1bWVudCBjb250YWlucyB0aGUgQmFz aWMgTmV0d29yayBQb2xpY3kgYW5kIEZpbHRlcnMgKEJOUCBJTSkNCiAgICBEYXRhIE1vZGVsIHdo aWNoIHByb3ZpZGVzIGEgcG9saWN5IG1vZGVsIHRoYXQgc3VwcG9ydCBhbiBvcmRlcmVkIGxpc3QN CiAgICBvZiBtYXRjaC1jb25kaXRpb24tYWN0aW9uIChha2EgZXZlbnQtY29uZGl0aW9uLWFjdGlv biAoRUNBKSkgZm9yDQogICAgbXVsdGlwbGUgbGF5ZXJzIChpbnRlcmZhY2UsIEwxLUw0LCBhcHBs aWNhdGlvbikgYW5kIG90aGVyIGZhY3RvcnMNCiAgICAoc2l6ZSBvZiBwYWNrZXQsIHRpbWUgb2Yg ZGF5KS4gIFRoZSBhY3Rpb25zIGFsbG93IGZvciBzZXR0aW5nIGFjdGlvbnMNCiAgICAoUU9TIGFu ZCBvdGhlciksIGRlY2Fwc3VsYXRpb24sIGVuY2Fwc3VsYXRpb24sIHBsdXMgZm9yd2FyZGluZw0K ICAgIGFjdGlvbnMuICBUaGUgcG9saWN5IG1vZGVsIGNhbiBiZSB1c2VkIHdpdGggdGhlIEkyUlMg ZmlsdGVyLWJhc2VkDQogICAgUklCLg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGls IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0 Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KaTJycyBt YWlsaW5nIGxpc3QNCmkycnNAaWV0Zi5vcmc8bWFpbHRvOmkycnNAaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnMNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClN1cGEgbWFpbGluZyBsaXN0DQpTdXBhQGll dGYub3JnPG1haWx0bzpTdXBhQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zdXBhDQoNCg0KDQotLQ0KcmVnYXJkcywNCkpvaG4NCg== --_000_B818037A70EDCC4A86113DA25EC02098201B9466SJCEML701CHMchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQg NiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6 MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7 DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25z ICovDQogcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0 ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4 dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1l OiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm Ijt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCiAvKiBMaXN0 IERlZmluaXRpb25zICovDQogQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MjAwNzg1OTA0NjsNCglt c28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTUyMzM1ODQxMiA2 NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5 ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxl ZnQ6NDMuMHB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K b2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+ DQo8L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IlNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPkhpIFN1ZSw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0 OTdEIj5Zb3UgYXJlIGNvcnJlY3QsIGl0IGlzIGEgdmVyeSBzaW1wbGUgY2FzZSwgd2l0aCBvbmUg dHlwZSBvZiBldmVudC4gJm5ic3A7Jm5ic3A7Sm9lbCBpbmRpY2F0ZWQgZmxhd3MgaW4gdGhlIGRv Y3VtZW50IHRoYXQgaXQgZGlkIG5vdCBpbmRpY2F0ZSB0aGUgZXZlbnQgd2FzIGEg4oCccGFja2V0 DQogcmVjZXB0aW9u4oCdLiZuYnNwOyBBdCB0aGlzIHBvaW50LCBpdCBzb3VuZHMgbGlrZSB5b3Ug YW5kIEpvZWwgYXJlIHN1Z2dlc3RpbmcgdGhhdCB0aGlzIHBhcnRpY3VsYXIgc2ltcGxpc3RpYyBj YXNlIG9mIEV2ZW50LUNvbmRpdGlvbi1BY3Rpb24gaXMgT0sgdG8gZ28gZm9yd2FyZCB3aXRoIGlu IHRoZSBJMlJTIChmb3IgZXBoZW1lcmFsIHN0YXRlKSwgYW5kIGluIGFwcHJvcHJpYXRlIFdHIGZv ciB0aGUgbm9uLWVwaGVtZXJhbCBjYXNlLiZuYnNwOyBJcyB0aGlzIGNvcnJlY3Q/DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjoj MUY0OTdEIj4mbHQ7amNzJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPkFzIGxv bmcgYXMgaXQgaXMgY2xhcmlmaWVkIHRoYXQgdGhlcmUgaXMsIGluIGZhY3QsIGFuIGV2ZW50LCB0 aGVuIEkgdGhpbmsgdGhhdCBpdCBpcyBmaW5lLiBOb3RlIHRoYXQgaXQgc2hvdWxkIGFsc28gYmUg Y2xhcmlmaWVkIHRoYXQgaWYgdGhlIEV2ZW50IGlzIG5vdA0KIHJlY2VpdmVkLCB0aGVuIHRoZSBj b25kaXRpb24gY2xhdXNlIGNhbiBuZXZlciBiZSBldmFsdWF0ZWQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0K Y29sb3I6IzFGNDk3RCI+Jmx0Oy9qY3MmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+QXQgSUVURiA5NCwgSSB3 YXMgc2ltcGx5IGNvbXBhcmluZyBDaGVu4oCZcyBkb2N1bWVudCB2ZXJzdXMgdGhpcyB2ZXJ5IHNp bXBsZSBjYXNlIG9mIGFuIEVDQS4gJm5ic3A7SSBkaWQgbm90IG1lYW4gdG8gaW1wbHkgaXQgd2Fz IHRoZSBvbmx5IHBvc3NpYmxlIEVDQSBjYXNlLiZuYnNwOyAmbmJzcDtJDQogbG9vayBmb3J3YXJk IHRvIGhlYXJpbmcgZnJvbSB0aGUgU1VQQSBsaXN0IHJlZ2FyZGluZyB0aGUgZ2VuZXJpYyBFQ0Eg aW5mb3JtYXRpb24gbW9kZWwgYW5kIHRoZSBkaWZmZXJlbnQgdHlwZXMgb2YgRUNBLiAmbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpj b2xvcjojMUY0OTdEIj4mbHQ7amNzJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0Qi PlRoYXQncyB3aGF0IGNvbmZ1c2VkIG1lIC0gdGhlIGNoZW4gZG9jdW1lbnQgZGlkIGhhdmUgZXZl bnQgbm9kZXMgaW4gaXQsIGFuZCB5b3VyIGRyYWZ0IGRpZG4ndC4gVGhhdCBiZWluZyBzYWlkLCB0 aGVyZSBhcmUgbWFueSB3YXlzIHRvIGRlZmluZSBFdmVudHMuIElmIHlvdQ0KIGxvb2sgYXQgdGhl IFNVUEEgbW9kZWwsIHlvdSB3aWxsIHNlZSB0aGUgZm9sbG93aW5nIGV4ZW1wbGFyIG1ldGhvZHM6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo0My4w cHQ7dGV4dC1pbmRlbnQ6LS4yNWluOw0KbXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWls eTpTeW1ib2w7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8 c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMx RjQ5N0QiPnlvdSBjYW4gZGVmaW5lIGEgY2xhdXNlLCBvZiB0aGUgY2Fub25pY2FsIGZvcm0ge3Zh cmlhYmxlLCBvcGVyYXRvciwgdmFsdWV9LCB0byByZXByZXNlbnQgYW4gZXZlbnQgKGUuZy4sIHRp bWUgPT0gMDg6MDBhbSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjQzLjBwdDt0ZXh0LWluZGVudDotLjI1aW47DQpt c28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDsNCmZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMUY0OTdEIj48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+eW91IGNhbiB1c2UgYW4gRXZl bnQgb2JqZWN0IGFzIHRoZSB2YXJpYWJsZSBvciB0aGUgdmFsdWUgaW4gdGhlIGFib3ZlIGNsYXVz ZSAoZS5nLiwgdXNlIG9uZSBvciBtb3JlIGF0dHJpYnV0ZXMgZnJvbSBvbmUgb3IgbW9yZSBFdmVu dCBvYmplY3RzIGluDQogdGhlIGNvbXBhcmlzb24gY2xhdXNlKTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NDMuMHB0 O3RleHQtaW5kZW50Oi0uMjVpbjsNCm1zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ow0KZm9udC1mYW1pbHk6 U3ltYm9sO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0 OTdEIj55b3UgY2FuIHVzZSBhIENvbGxlY3Rpb24gYXR0cmlidXRlcyB0byBjb2xsZWN0IGV2ZW50 cyBmb3IgYWdncmVnYXRpb24sIGZpbHRlcmluZywgYW5kL29yIGNvcnJlbGF0aW9uIG9wZXJhdGlv bnMgYXMgcGFydCBvZiB0aGUgZXZlbnQgY2xhdXNlIHByb2Nlc3Npbmc8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjQz LjBwdDt0ZXh0LWluZGVudDotLjI1aW47DQptc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsNCmZvbnQtZmFt aWx5OlN5bWJvbDtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7C tzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6 IzFGNDk3RCI+eW91IGNhbiBlbmNvZGUgdGhlIGVudGlyZSBldmVudCBleHByZXNzaW9uIGludG8g YW4gYXR0cmlidXRlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+Jmx0Oy9qY3MmZ3Q7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0K Y29sb3I6IzFGNDk3RCI+cmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5K b2huPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBTdXBhIFttYWlsdG86c3VwYS1ib3VuY2VzQGlldGYu b3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5TdXNhbiBIYXJlczxicj4NCjxiPlNlbnQ6PC9iPiBX ZWRuZXNkYXksIEphbnVhcnkgMDYsIDIwMTYgNjoxMyBBTTxicj4NCjxiPlRvOjwvYj4gJ0pvaG4g U3RyYXNzbmVyJzsgJ0pvZWwgTS4gSGFscGVybic8YnI+DQo8Yj5DYzo8L2I+IGkycnNAaWV0Zi5v cmc7IG5ldG1vZEBpZXRmLm9yZzsgc3VwYUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW1N1cGFdIFtpMnJzXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1o YXJlcy1pMnJzLWJucC1lY2EtZGF0YS1tb2RlbC0wMy50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpj b2xvcjojMUY0OTdEIj5Kb2huOg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+VGhhbmsgeW91IGZvciB5b3VyIHJl c3BvbnNlLiAmbmJzcDsmbmJzcDtGb3IgZmlsdGVyLWJhc2VkIEZJQiwNCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0Qi PkV2ZW50ID0gcmVjZWl2aW5nIHBhY2tldCBpbmZvcm1hdGlvbiBvbiB0aGUgaW50ZXJmYWNlDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5Db25kaXRpb24gPSBtYXRjaCBvbiBhIHZh cmlldHkgb2YgY29uZGl0aW9ucyAoc2VlIHRoZSBkcmFmdCkNCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNv bG9yOiMxRjQ5N0QiPkFjdGlvbiA9IGEgY2hvaWNlIG9mIGFjdGlvbnMgbW9kaWZ5IHBhY2tldCwg Zm9yd2FyZC9kcm9wIHBhY2tldCwgYW5kIGNvdW50IHBhY2tldC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5Zb3Ug YXJlIGNvcnJlY3QsIGl0IGlzIGEgdmVyeSBzaW1wbGUgY2FzZSwgd2l0aCBvbmUgdHlwZSBvZiBl dmVudC4gJm5ic3A7Jm5ic3A7Sm9lbCBpbmRpY2F0ZWQgZmxhd3MgaW4gdGhlIGRvY3VtZW50IHRo YXQgaXQgZGlkIG5vdCBpbmRpY2F0ZSB0aGUgZXZlbnQgd2FzIGEg4oCccGFja2V0DQogcmVjZXB0 aW9u4oCdLiZuYnNwOyBBdCB0aGlzIHBvaW50LCBpdCBzb3VuZHMgbGlrZSB5b3UgYW5kIEpvZWwg YXJlIHN1Z2dlc3RpbmcgdGhhdCB0aGlzIHBhcnRpY3VsYXIgc2ltcGxpc3RpYyBjYXNlIG9mIEV2 ZW50LUNvbmRpdGlvbi1BY3Rpb24gaXMgT0sgdG8gZ28gZm9yd2FyZCB3aXRoIGluIHRoZSBJMlJT IChmb3IgZXBoZW1lcmFsIHN0YXRlKSwgYW5kIGluIGFwcHJvcHJpYXRlIFdHIGZvciB0aGUgbm9u LWVwaGVtZXJhbCBjYXNlLiZuYnNwOyBJcyB0aGlzIGNvcnJlY3Q/DQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5B dCBJRVRGIDk0LCBJIHdhcyBzaW1wbHkgY29tcGFyaW5nIENoZW7igJlzIGRvY3VtZW50IHZlcnN1 cyB0aGlzIHZlcnkgc2ltcGxlIGNhc2Ugb2YgYW4gRUNBLiAmbmJzcDtJIGRpZCBub3QgbWVhbiB0 byBpbXBseSBpdCB3YXMgdGhlIG9ubHkgcG9zc2libGUgRUNBIGNhc2UuJm5ic3A7ICZuYnNwO0kN CiBsb29rIGZvcndhcmQgdG8gaGVhcmluZyBmcm9tIHRoZSBTVVBBIGxpc3QgcmVnYXJkaW5nIHRo ZSBnZW5lcmljIEVDQSBpbmZvcm1hdGlvbiBtb2RlbCBhbmQgdGhlIGRpZmZlcmVudCB0eXBlcyBv ZiBFQ0EuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPlN1ZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFN1cGEgW21haWx0bzpzdXBhLWJvdW5jZXNAaWV0Zi5vcmdd DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkpvaG4gU3RyYXNzbmVyPGJyPg0KPGI+U2VudDo8L2I+IFR1 ZXNkYXksIEphbnVhcnkgMDUsIDIwMTYgMTA6MTIgUE08YnI+DQo8Yj5Ubzo8L2I+IEpvZWwgTS4g SGFscGVybjxicj4NCjxiPkNjOjwvYj4gaTJyc0BpZXRmLm9yZzsgc3VwYUBpZXRmLm9yZzsgbmV0 bW9kQGlldGYub3JnOyBTdXNhbiBIYXJlczxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1N1cGFd IFtpMnJzXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1oYXJlcy1pMnJz LWJucC1lY2EtZGF0YS1tb2RlbC0wMy50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SGkgSm9lLCBldCBhbC4sPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgMSkgSXQgaXMgbm90IGNsZWFyIHRvIG1l IHdoeSB0aGVyZSBpcyBhbnkgZGVwZW5kZW5jZSBvZiB0aGUgZmItcmliPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jm5ic3A7ZGF0YSBtb2Rl bCBvbiBhbiBlY2EgZGF0YSBtb2RlbC4mbmJzcDsgV2hpbGUgc3VwYSBkb2VzIGFsbG93IGZvcg0K PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7 IHBvbGljeSBtb2RlbCB0byBiZSBzZW50IGRpcmVjdGx5IHRvIHRoZSByb3V0ZXIsIGl0IGFsc28g YWxsb3dzIG1hbnk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZndDsmbmJzcDtvdGhlciBjYXNlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RXhhY3RseS4gTW9yZSBwYXJ0aWN1bGFybHksIGlu IHNjYW5uaW5nIHRoaXMgZHJhZnQsIEkgZmFpbCB0byBzZWUgaG93PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGlzIGlzIGFuIGFjY2VwdGVkIGRl ZmluaXRpb24gb2YgRUNBLiBJbiBwYXJ0aWN1bGFyLCB0aGVyZSBkb2Vzbid0PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zZWVtIHRvIGJlIGFueSBl dmVudCBpbiB0aGUgcnVsZSBkZWZpbml0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZW5jZSwgSSB3b3VsZCBzdWdnZXN0IHRoYXQgeW91 IGFkZCB3b3JkaW5nIHRoYXQgc2F5cyB0aGF0IHRoaXMgaXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm9uZSBvZiBtYW55IHdheXMgdG8gYnVpbGQg c3VjaCBhIG1hcHBpbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jmd0OyZuYnNwOzIpIFRoZSBhcHByb2FjaCB3aXRoIHRoZSBzdXBhIGVj YSBkYXRhIG1vZGVsIGlzIHN0aWxsIHVuZGVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jm5ic3A7ZGV2ZWxvcG1lbnQuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFic29sdXRlbHkgYWdy ZWUuIEluIHBhcnRpY3VsYXIsIGRyYWZ0LWNoZW4gd2FzIHRoZSBmaXJzdCBhdHRlbXB0IGF0PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50cnlpbmcg dG8gY29uY2VwdHVhbGl6ZSB3aGF0IHN1Y2ggYSBkYXRhIG1vZGVsIHNob3VsZCBsb29rIGxpa2Uu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZn dDsmbmJzcDsgSGF2aW5nIHNhaWQgdGhhdCwgdGhlIG1hdGVyaWFsIGluIHRoZXJlIGlzIGludGVu ZGVkIHRvIGJlIHZlcnk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZndDsmbmJzcDtnZW5lcmFsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JRkYgeW91IG1lYW4gdGhlIFNVUEEgaW5mbyBtb2Rl bCwgdGhlbiBhYnNvbHV0ZWx5IChvdGhlcndpc2UsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pdCBoYXMgZmFpbGVkIGluIGl0cyBwcmltYXJ5IG1p c3Npb24gb2YgcHJvdmlkaW5nIGFuIGV4dGVuc2libGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmZyYW1ld29yayB0byBkZWZpbmUgcG9saWNpZXMp LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J RkYgeW91IG1lYW4gZHJhZnQtY2hlbiwgdGhlbiZuYnNwO0kgdGhpbmsgaXQmbmJzcDthZ3JlZXMg d2l0aCB0aGUgc3Bpcml0IG9mPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj53aGF0IHlvdSBzYWlkLiBJIHRoaW5rIHRoYXQgd2UgbmVlZCB0byBkaXNj dXNzIGhvdyB0byBtYXAgZnJvbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+YW4gaW5mbyBtb2RlbCB0byBhIGRhdGEgbW9kZWwmbmJzcDtpbiBtb3Jl IGRldGFpbCBiZWZvcmUgd2UgY29tZSB0bzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+YW55IGNvbmNsdXNpb25zIG9mIGl0cyBlZmZpY2FjeS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZu YnNwOyBGcm9tIHdoYXQgSSB1bmRlcnN0YW5kLCB0aGVyZSBzaG91bGQgYmUgbm8gZGlmZmljdWx0 eSBpbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jmd0OyZuYnNwO3JlZmluaW5nIHRoZSBhY3Rpb24gc2lkZSBvZiB0aGF0IG1vZGVsIHRvIGFjdGlv bnMgd2hpY2ggYWZmZWN0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mZ3Q7Jm5ic3A7dGhlIGZiLXJpYiBpbiB3YXlzIHRoYXQgYXJlIGNvbnNpc3Rl bnQgd2l0aCB0aGUgZmItZGliIGRhdGEgbW9kZWwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7MS4gSW4gZmFjdCwgdGhlIHdob2xlIHBv aW50IG9mIFNVUEEgaXMgdG8gcHJvdmlkZSBkaWZmZXJlbnQgd2F5czxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+b2YgZm9ybWluZyBhbiBFQ0EgcG9s aWN5IHJ1bGUgdG8gbWVldCBkaWZmZXJlbnQgZGVtYW5kcyBvZiB0aGU8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnVzZXIuIE1vcmUgcGFydGljdWxh cmx5LCBhdCBJRVRGOTQsIHlvdSAoU3VlKSBhc3N1bWVkIHRoYXQgYW48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkVDQSBwb2xpY3kgcnVsZSB3YXMg bWFkZSB1cCBvZiBFdmVudCwgQ29uZGl0aW9uLCBhbmQgQWN0aW9uPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5vYmplY3RzLiBXaGlsZSB0aGF0IGlz IGNlcnRhaW5seSBvbmUgYWx0ZXJuYXRpdmUsIHRoZXJlIGFyZSBvdGhlcnM8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFzIHdlbGwuIEluIGFkZGl0 aW9uLCBwbGVhc2Ugbm90ZSB0aGF0IHRoZSBwcmVzZW5jZSBvZiB0aGVzZTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+b2JqZWN0cyBpcyBOT1Qgc3Vm ZmljaWVudCB0byBidWlsZCBhbiBFQ0EgcG9saWN5IHJ1bGUgKGUuZy4sIHRoZTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RXZlbnQgb2JqZWN0IG5l ZWRzIGFuIGF0dHJpYnV0ZSAob3IgbXVsdGlwbGUgYXR0cmlidXRlcykgdG8gYmUNCjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Y29tcGFyZWQgdG8g c29tZXRoaW5nIGluIG9yZGVyIHRvIGRldGVybWluZSBpZiB0aGUgZXZlbnQgPG86cD4NCjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNMQVVTRSBldmFsdWF0 ZXMgdG8gVFJVRSBvciBub3QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+cmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvaG48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBKYW4gNCwgMjAxNiBhdCAxMjo1MyBQTSwg Sm9lbCBNLiBIYWxwZXJuICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmptaEBqb2VsaGFscGVybi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhlcmUgYXJlIHR3byBpc3N1 ZXMgaGVyZS48YnI+DQo8YnI+DQoxKSBJdCBpcyBub3QgY2xlYXIgdG8gbWUgd2h5IHRoZXJlIGlz IGFueSBkZXBlbmRlbmNlIG9mIHRoZSBmYi1yaWIgZGF0YSBtb2RlbCBvbiBhbiBlY2EgZGF0YSBt b2RlbC4mbmJzcDsgV2hpbGUgc3VwYSBkb2VzIGFsbG93IGZvciBwb2xpY3kgbW9kZWwgdG8gYmUg c2VudCBkaXJlY3RseSB0byB0aGUgcm91dGVyLCBpdCBhbHNvIGFsbG93cyBtYW55IG90aGVyIGNh c2VzLjxicj4NCjxicj4NCjIpIFRoZSBhcHByb2FjaCB3aXRoIHRoZSBzdXBhIGVjYSBkYXRhIG1v ZGVsIGlzIHN0aWxsIHVuZGVyIGRldmVsb3BtZW50LiZuYnNwOyBIYXZpbmcgc2FpZCB0aGF0LCB0 aGUgbWF0ZXJpYWwgaW4gdGhlcmUgaXMgaW50ZW5kZWQgdG8gYmUgdmVyeSBnZW5lcmFsLiZuYnNw OyBGcm9tIHdoYXQgSSB1bmRlcnN0YW5kLCB0aGVyZSBzaG91bGQgYmUgbm8gZGlmZmljdWx0eSBp biByZWZpbmluZyB0aGUgYWN0aW9uIHNpZGUgb2YgdGhhdCBtb2RlbCB0byBhY3Rpb25zIHdoaWNo DQogYWZmZWN0IHRoZSBmYi1yaWIgaW4gd2F5cyB0aGF0IGFyZSBjb25zaXN0ZW50IHdpdGggdGhl IGZiLWRpYiBkYXRhIG1vZGVsLjxicj4NCjxicj4NCllvdXJzLDxicj4NCkpvZWw8YnI+DQo8YnI+ DQpPbiAxLzQvMTYgMjowMSBQTSwgU3VzYW4gSGFyZXMgd3JvdGU6PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlRoaXMgbW9k ZWwgcHJvdmlkZXMgYSBFdmVudC1Db25kaXRpb24tQWN0aW9uIChFQ0EpIHBvbGljeSBtb2RlbC48 YnI+DQpUaGUgSTJSUyBGQi1SSUIgeWFuZyBkYXRhIG1vZGVsIHV0aWxpemVzIHRoaXMgbW9kZWws IGJ1dCB0byBteSBrbm93bGVkZ2UgdGhlPGJyPg0KTmV0bW9kIG9yIG5ldGNvbmYgaGFzIG5vdCBh ZG9wdGVkIGFuIEVDQSBwb2xpY3kgbW9kZWwgdG88YnI+DQpwYXJhbGxlbCB0aGUgQUNMIG1vZGVs Ljxicj4NCjxicj4NCkNoZW4gYW5kIGNvLWF1dGhvcnMgaGF2ZSBjcmVhdGVkIHRoZSBtb2RlbDo8 YnI+DQo8YnI+DQpkcmFmdC1jaGVuLXN1cGEtZWNhLWRhdGEtbW9kZWwtMDUudHh0PGJyPg0KPGJy Pg0KQnV0IGl0IGRvZXMgbm90IGFsaWduIHdpdGggdGhpcyB5YW5nIG1vZGVsIG9yIHNlZW0gc3Vm ZmljaWVudCB0bzxicj4NCnN1cHBvcnQgdGhlIEZCLVJJQiBpbmZvcm1hdGlvbiBtb2RlbC4mbmJz cDsgJm5ic3A7QXQgSUVURiA5NCw8YnI+DQpJIHByZXNlbnRlZCBhIGRpc2N1c3Npb24gb2YgdGhl IGlzc3VlcyBJIGZvdW5kIHdpdGggdGhlPGJyPg0KZHJhZnQtY2hlbi1zdXBhLWVjYS1kYXRhLW1v ZGVsLTA1LnR4dCwgYnV0IGl0IGhhcyBub3QgYmVlbiB1cGRhdGVkLjxicj4NCldlIHdvdWxkIGFw cHJlY2lhdGUgZmVlZGJhY2sgb24gdGhpcyB2ZXJzaW9uIG9mIHlhbmcgbW9kZWwuPGJyPg0KPGJy Pg0KJmx0O2kycnMgQ2hhaXIgaGF0IG9uJmd0Ozxicj4NCkluIG15IHJvbGUgYXMgSTJSUyBjaGFp ciwmbmJzcDsgSTJSUyBuZWVkcyB0byBtYWtlIHByb2dyZXNzIHNvb24gb24gdGhlPGJyPg0KSTJS UyBGQi1SSUIgZGF0YSBtb2RlbC4mbmJzcDsgV2Ugd291bGQgYXBwcmVjaWF0ZSB5b3VyIGFpZC48 YnI+DQombHQ7aTJycyBjaGFpciBoYXQgb2ZmJmd0Ozxicj4NCjxicj4NClN1ZTxicj4NCjxicj4N Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogPGEgaHJlZj0ibWFpbHRvOmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZzwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPl08YnI+DQpT ZW50OiBNb25kYXksIEphbnVhcnkgMDQsIDIwMTYgMTI6MDQgUE08YnI+DQpUbzogU3VzYW4gSGFy ZXM7IFFpbiBXdTsgUnVzcyBXaGl0ZTxicj4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtaGFyZXMtaTJycy1ibnAtZWNhLWRhdGEtbW9kZWwtMDMudHh0PGJyPg0K PGJyPg0KPGJyPg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWhhcmVzLWkycnMtYm5wLWVj YS1kYXRhLW1vZGVsLTAzLnR4dDxicj4NCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg YnkgU3VzYW4gSGFyZXMgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Ljxicj4NCjxi cj4NCk5hbWU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC1o YXJlcy1pMnJzLWJucC1lY2EtZGF0YS1tb2RlbDxicj4NClJldmlzaW9uOiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOzAzPGJyPg0KVGl0bGU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBBbiBJbmZvcm1hdGlvbiBNb2RlbCBmb3IgQmFzaWMgTmV0d29yayBQb2xpY3kgYW5kIEZp bHRlciBSdWxlczxicj4NCkRvY3VtZW50IGRhdGU6Jm5ic3A7IDIwMTYtMDEtMDQ8YnI+DQpHcm91 cDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEluZGl2aWR1YWwgU3VibWlzc2lv bjxicj4NClBhZ2VzOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMzA8YnI+DQpV Ukw6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWhhcmVzLWkycnMtYm5wLWVj YS1kYXRhLW1vZGVsLTAzLnR4dCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWhhcmVzLWkycnMtYm5wLWVjYS1kYXRhLW1vZGVsLTAz LnR4dDwvYT48YnI+DQpTdGF0dXM6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxh IGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWhhcmVzLWkycnMt Ym5wLWVjYS1kYXRhLW1vZGVsLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWhhcmVzLWkycnMtYm5wLWVjYS1kYXRhLW1vZGVsLzwvYT48YnI+ DQpIdG1saXplZDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFyZXMtaTJycy1ibnAtZWNhLWRhdGEtbW9kZWwtMDMi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFyZXMt aTJycy1ibnAtZWNhLWRhdGEtbW9kZWwtMDM8L2E+PGJyPg0KRGlmZjombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1oYXJlcy1pMnJzLWJucC1lY2EtZGF0YS1tb2RlbC0wMyIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1oYXJlcy1p MnJzLWJucC1lY2EtZGF0YS1tb2RlbC0wMzwvYT48YnI+DQo8YnI+DQpBYnN0cmFjdDo8YnI+DQom bmJzcDsgJm5ic3A7IFRoaXMgZG9jdW1lbnQgY29udGFpbnMgdGhlIEJhc2ljIE5ldHdvcmsgUG9s aWN5IGFuZCBGaWx0ZXJzIChCTlAgSU0pPGJyPg0KJm5ic3A7ICZuYnNwOyBEYXRhIE1vZGVsIHdo aWNoIHByb3ZpZGVzIGEgcG9saWN5IG1vZGVsIHRoYXQgc3VwcG9ydCBhbiBvcmRlcmVkIGxpc3Q8 YnI+DQombmJzcDsgJm5ic3A7IG9mIG1hdGNoLWNvbmRpdGlvbi1hY3Rpb24gKGFrYSBldmVudC1j b25kaXRpb24tYWN0aW9uIChFQ0EpKSBmb3I8YnI+DQombmJzcDsgJm5ic3A7IG11bHRpcGxlIGxh eWVycyAoaW50ZXJmYWNlLCBMMS1MNCwgYXBwbGljYXRpb24pIGFuZCBvdGhlciBmYWN0b3JzPGJy Pg0KJm5ic3A7ICZuYnNwOyAoc2l6ZSBvZiBwYWNrZXQsIHRpbWUgb2YgZGF5KS4mbmJzcDsgVGhl IGFjdGlvbnMgYWxsb3cgZm9yIHNldHRpbmcgYWN0aW9uczxicj4NCiZuYnNwOyAmbmJzcDsgKFFP UyBhbmQgb3RoZXIpLCBkZWNhcHN1bGF0aW9uLCBlbmNhcHN1bGF0aW9uLCBwbHVzIGZvcndhcmRp bmc8YnI+DQombmJzcDsgJm5ic3A7IGFjdGlvbnMuJm5ic3A7IFRoZSBwb2xpY3kgbW9kZWwgY2Fu IGJlIHVzZWQgd2l0aCB0aGUgSTJSUyBmaWx0ZXItYmFzZWQ8YnI+DQombmJzcDsgJm5ic3A7IFJJ Qi48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGls IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCjxhIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRvb2xzLmlldGYub3JnPC9h Pi48YnI+DQo8YnI+DQpUaGUgSUVURiBTZWNyZXRhcmlhdDxicj4NCjxicj4NCjxicj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KaTJycyBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86aTJyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPmkycnNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pMnJzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pMnJzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpTdXBhIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpTdXBhQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+U3VwYUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1cGEiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1cGE8L2E+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiciBjbGVhcj0iYWxs Ij4NCjxicj4NCi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5yZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Sm9objxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_B818037A70EDCC4A86113DA25EC02098201B9466SJCEML701CHMchi_-- From nobody Wed Jan 6 16:51:09 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5B31A21A7; Wed, 6 Jan 2016 16:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLTpayH_HUw9; Wed, 6 Jan 2016 16:50:57 -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 BFFA41A21A9; Wed, 6 Jan 2016 16:50:45 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCO86899; Thu, 07 Jan 2016 00:50:43 +0000 (GMT) Received: from LHREML708-CAH.china.huawei.com (10.201.5.202) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 7 Jan 2016 00:50:42 +0000 Received: from SJCEML702-CHM.china.huawei.com (10.218.25.35) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 7 Jan 2016 00:50:42 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.81]) by SJCEML702-CHM.china.huawei.com ([169.254.4.118]) with mapi id 14.03.0235.001; Wed, 6 Jan 2016 16:50:39 -0800 From: John Strassner To: Susan Hares , "'John Strassner'" Thread-Topic: [netmod] [Supa] [i2rs] FW: New Version Notification for draft-hares-i2rs-bnp-eca-data-model-03.txt Thread-Index: AQHRR0AEWq+0Q6eGlUC48EIYXHelhZ7uXAaAgAFOggD//5Fl4A== Date: Thu, 7 Jan 2016 00:50:38 +0000 Message-ID: References: <20160104170330.13929.73845.idtracker@ietfa.amsl.com> <006701d14722$616c6950$24453bf0$@ndzh.com> <568ADBE7.3030101@joelhalpern.com> <00b501d1473f$fef22990$fcd67cb0$@ndzh.com> <013001d148d9$770626d0$65127470$@ndzh.com> In-Reply-To: <013001d148d9$770626d0$65127470$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.96.255.167] Content-Type: multipart/alternative; boundary="_000_B818037A70EDCC4A86113DA25EC02098201B9472SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.568DB663.0147, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.81, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 57dddf450da3b054edd93bf890d7e676 Archived-At: Cc: "i2rs@ietf.org" , "netmod@ietf.org" , "supa@ietf.org" Subject: Re: [netmod] [Supa] [i2rs] FW: New Version Notification for draft-hares-i2rs-bnp-eca-data-model-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 00:51:04 -0000 --_000_B818037A70EDCC4A86113DA25EC02098201B9472SJCEML701CHMchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VlOg0KDQpJJ20gaGFwcHkgdG8gaGVscC4gSTJSUyBpcyBpbXBvcnRhbnQgd29yaywgYW5kIEkg d291bGQgbGlrZSB0byBlbnN1cmUgdGhhdCBTVVBBIGNvdWxkIGhlbHAgeW91ciB3b3JrICh3aXRo b3V0IGRlbGF5aW5nIGl0LCBvZiBjb3Vyc2UpLg0KDQpBbHNvLCBJJ20gaW50ZXJlc3RlZCBpbiB0 aGUgZGF0YSBtb2RlbHMgdGhhdCB5b3UgY29tZSB1cCB3aXRoLCBhcyB0aGV5IGFyZSBleGNlbGxl bnQgZXhhbXBsZXMgb2Ygd2hhdCBTVVBBIG5lZWRzIHRvIHN1cHBvcnQuDQoNCnJlZ2FyZHMsDQpK b2huDQoNCkZyb206IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgU3VzYW4gSGFyZXMNClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAwNiwgMjAxNiAz OjI1IFBNDQpUbzogJ0pvaG4gU3RyYXNzbmVyJw0KQ2M6IGkycnNAaWV0Zi5vcmc7IHN1cGFAaWV0 Zi5vcmc7IG5ldG1vZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRtb2RdIFtTdXBhXSBbaTJy c10gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaGFyZXMtaTJycy1ibnAt ZWNhLWRhdGEtbW9kZWwtMDMudHh0DQoNCkpvaG46DQoNCllvdSBhcmUgY29ycmVjdCBpbiBpbmRp Y2F0aW5nIHRoYXQgdGhlIGRyYWZ0IGFzc3VtZXMgeW91IHVuZGVyc3RhbmQgdGhlIGV2ZW50ID0g UGFja2V0IHJlY2VwdGlvbi4gIEl0IGlzIGEgZmFpbGluZyBpbiB0aGUgZHJhZnQgdGhhdCBKb2Vs IGhhcyBpbmRpY2F0ZWQgb24gdGhlc2UgbGlzdHMuICBJIHdpbGwgYmUgdXBkYXRpbmcgdGhlIEVD QSBkcmFmdHMgYW5kIEZCLVJJQiBkcmFmdHMuICBJIHdpbGwgc2VuZCBhIGNvcHkgdG8geW91IGFu ZCBKb2VsIGZvciByZXZpZXcgdGhpcyB3ZWVrLg0KDQpUaGFuayB5b3UgZm9yIHBvaW50aW5nIG91 dCB0aGUgZXJyb3JzIGluIHRoZSBkcmFmdHMsDQoNClN1ZQ0KDQpGcm9tOiBKb2huIFN0cmFzc25l ciBbbWFpbHRvOnN0cmF6cGRqQGdtYWlsLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMDUs IDIwMTYgMTA6MjggUE0NClRvOiBTdXNhbiBIYXJlcw0KQ2M6IEpvZWwgTS4gSGFscGVybjsgaTJy c0BpZXRmLm9yZzsgbmV0bW9kQGlldGYub3JnOyBzdXBhQGlldGYub3JnOyBKb2huIFN0cmFzc25l cg0KU3ViamVjdDogUmU6IFtTdXBhXSBbaTJyc10gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtaGFyZXMtaTJycy1ibnAtZWNhLWRhdGEtbW9kZWwtMDMudHh0DQoNClN1ZSwN Cg0KPiBPbiAjMSkgdGhlIGRlcGVuZGVuY3kgYmV0d2VlbiBJMlJTIEZpbHRlci1iYXNlZCBSSUIg KEZCLVJJQikgYW5kDQo+IEVDQSwgcGxlYXNlIHNlZSBkcmFmdC1raW5pLWkycnMtZmItcmliLWlu Zm8tbW9kZWwtMDIudHh0LiBJbiBzZWN0aW9uIDEuMSwNCj4gaXQgZ2l2ZXMgdGhlIGRlZmluaXRp b24gb2YgdGhlIEZCLVJJQi4NCg0KU29ycnksIGl0IGRvZXMgTk9UIGRvIHRoaXMuIFRvIHF1b3Rl IGZyb20gdGhpcyBzZWN0aW9uOg0KDQogICBBIEZpbHRlciBCYXNlZCBSSUIgdXNlcyBFdmVudC1D b25kaXRpb24tQWN0aW9uIHBvbGljeS4gQSBGaWx0ZXItDQogICBiYXNlZCBSSUIgZW50cnkgc3Bl Y2lmaWVzIG1hdGNoZXMgb24gZmllbGRzIGluIGEgcGFja2V0ICh3aGljaCBtYXkNCiAgIGluY2x1 ZGUgbGF5ZXIgMiBmaWVsZHMsIElQIGhlYWRlciBmaWVsZHMsIHRyYW5zcG9ydCBvciBhcHBsaWNh dGlvbg0KICAgZmllbGRzKSBvciBzaXplIG9mIHRoZSBwYWNrZXQgb3IgaW50ZXJmYWNlIHJlY2Vp dmVkIG9uLiBUaGUgbWF0Y2hlcw0KICAgYXJlIGNvbnRhaW5lZCBpbiBhbiBvcmRlcmVkIGxpc3Qg b2YgZmlsdGVycyB3aGljaCBjb250YWluIHBhaXJzIG9mDQogICBtYXRjaCBjb25kaXRpb24tYWN0 aW9uIChha2EgZXZlbnQtY29uZGl0aW9uLWFjdGlvbikuDQoNClBsZWFzZSB0ZWxsIG1lIFdIRVJF IHRoZSBldmVudCBpcyBpbiB0aGUgYWJvdmUgZGVmaW5pdGlvbi4gQWxsIEkgc2VlIGlzDQphIGNv bmRpdGlvbi1hY3Rpb24gcnVsZS4gKEJUVywgdGhlIGFuYWx5c2lzIG9mIFBDSU0gYW5kIFBDSU1l IGlzIGFsc28NCm5vdCBxdWl0ZSBjb3JyZWN0IGluIHlvdXIgZHJhZnQpLg0KDQo+IEluIHNlY3Rp b24gMS4yLCBpdCBsaW5rcyB0aGlzIHRvIGFuIGV2ZW50LWNvbmRpdGlvbi1hY3Rpb24gbW9kZWwu DQoNClNvcnJ5LCBpdCBkb2VzIE5PVCBkbyB0aGlzLg0KDQpGaXJzdCwgdGhpcyBzZWN0aW9uIHNp bXBseSBzYXlzLCBhbmQgSSBxdW90ZToNCg0KICAgIlRoZSBmaWx0ZXIgYmFzZWQtUklCIHVzZXMg ZXZlbnQtY29uZGl0aW9uLWFjdGlvbiBwb2xpY3kgKEVDQSkgcnVsZXMuIg0KDQpUaGF0IGlzIGEg dGF1dG9sb2d5IGF0IGJlc3QuDQoNClNlY29uZCwgaW4gU2VjdGlvbiAyLCB1bmRlciB0aGUgZGVm aW5pdGlvbiBvZiBGQi1Sb3V0ZSwgdGhlIGRyYWZ0IHNheXM6DQoNCiAgICJUaGUgcG9saWN5IHJ1 bGVzIGluIHRoZSBmaWx0ZXItYmFzZWQgUklCIGFyZSBwcmVzY3JpcHRpdmUgb2YgdGhlDQogICAg IEV2ZW50LUNvbmRpdGlvbi1BY3Rpb24gZm9ybSB3aGljaCBpcyBvZnRlbiByZXByZXNlbnRlZCBi eQ0KICAgICAgICBpZiBDb25kaXRpb24gdGhlbiBhY3Rpb24uIg0KDQpQbGVhc2Ugbm90ZSB0aGF0 IHRoaXMgZGVmaW5pdGlvbiBpcyBpbmNvcnJlY3QsIGFuZCBpbiBjb25mbGljdCB3aXRoIFNVUEEu DQpUaGUgd2hvbGUgcG9pbnQgb2YgYW4gRVZFTlQtY29uZGl0aW9uLWFjdGlvbiBwb2xpY3kgcnVs ZSBpcyB0byBkZWZpbmUNCmEgcnVsZSBvZiB0aGUgZm9ybToNCg0KICAgIElGIDxldmVudF9jbGF1 c2U+IGV2YWx1YXRlcyB0byBUUlVFDQogICAgICAgIElGIDxjb25kaXRpb25fY2xhdXNlIGV2YWx1 YXRlcyB0byBUUlVFDQogICAgICAgICAgICBUSEVOIGV4ZWN1dGUgYWN0aW9ucyBpbiA8YWN0aW9u X2NsYXVzZT4NCiAgICAgICAgRU5ESUYNCiAgICBFTkRJRg0KDQpUaGlzIGRlZmluaXRpb24gaGFz IGJlZW4gZXN0YWJsaXNoZWQgaW4gdGhlIGluZHVzdHJ5IGFuZCBhY2FkZW1pYQ0KZm9yIGF0IGxl YXN0IDIgZGVjYWRlcy4NCg0KVmFyaWF0aW9ucyBvZiB0aGUgYWJvdmUgaGF2ZSBiZWVuIGRlZmlu ZWQgYW5kIHB1Ymxpc2hlZCAoZS5nLiwNCkZPQ0FMRSBoYXMgYW4gYWx0ZXJuYXRlIHNldCBvZiBh Y3Rpb25zIHRvIGV4ZWN1dGUgaWYgdGhlIGNvbmRpdGlvbg0KY2xhdXNlIGV2YWx1YXRlZCB0byBG QUxTRTsgdGhpcyBoYXMgTk9UIGJlZW4gcHJvcG9zZWQgZm9yIFNVUEENCmF0IHRoaXMgdGltZSku IFRoZXJlIGhhdmUgYWxzbyBiZWVuIGV4dGVuc2lvbnMgdG8gaGFuZGxlIHNldHMgYW5kDQpncm91 cHMsIGFzIHdlbGwgYXMgc3BlY2lmaWMgb3JkZXJpbmcgKERFTi1uZywgU0lELCBGT0NBTEUpLg0K DQpUaGVyZWZvcmUsIEkgd291bGQgc3VnZ2VzdCB0aGF0IHlvdSBjaGFuZ2UgeW91ciBkcmFmdHMg dG8gdXNlIGENCmNvbmRpdGlvbi1hY3Rpb24gcG9saWN5IHJ1bGUsIE9SIHVwZGF0ZSB0aGUgZHJh ZnRzIChJIHdvdWxkIGJlIGhhcHB5DQp0byBoZWxwKSB0byB1c2UgYSBjb3JyZWN0IGRlZmluaXRp b24gb2YgYW4gRUNBIHBvbGljeSBydWxlLg0KDQpyZWdhcmRzLA0KSm9obg0KDQpPbiBNb24sIEph biA0LCAyMDE2IGF0IDI6MzMgUE0sIFN1c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5jb208bWFpbHRv OnNoYXJlc0BuZHpoLmNvbT4+IHdyb3RlOg0KDQpKb2VsOg0KDQoNCg0KT24gIzEpIHRoZSBkZXBl bmRlbmN5IGJldHdlZW4gSTJSUyBGaWx0ZXItYmFzZWQgUklCIChGQi1SSUIpIGFuZCBFQ0EsIHBs ZWFzZSBzZWUgZHJhZnQta2luaS1pMnJzLWZiLXJpYi1pbmZvLW1vZGVsLTAyLnR4dC4gSW4gc2Vj dGlvbiAxLjEsIGl0IGdpdmVzIHRoZSBkZWZpbml0aW9uIG9mIHRoZSBGQi1SSUIuICBJbiBzZWN0 aW9uIDEuMiwgaXQgbGlua3MgdGhpcyB0byBhbiBldmVudC1jb25kaXRpb24tYWN0aW9uIG1vZGVs LiAgSWYgeW91IGRpc2FncmVlIHdpdGggdGhlIGRlZmluaXRpb24gb2YgIEkyUlMgRkItUklCLCB0 aGVuIHdlIHNob3VsZCBwcm9iYWJseSByZXN0cmljdCB0aGlzIGNvbnZlcnNhdGlvbiB0byB0aGUg STJSUyBtYWlsIGxpc3QuICBBbnkgZmVlZGJhY2sgb24gdGhlIEluZm8tbW9kZWwgb3IgZGF0YS1t b2RlbCB3b3VsZCBiZSBoZWxwZnVsLiAgVGhlIGF1dGhvcnMgaG9wZWQgdG8gZ28gdG8gYSBXRyBh ZG9wdGlvbiBjYWxsIGF0IHRoZSBlbmQgb2YgdGhpcyB3ZWVrLg0KDQoNCg0KT25lIGNoYWxsZW5n ZSBmb3IgdGhlIGVwaGVtZXJhbCBJMlJTIEZCLVJJQiwgaXMgdGhlcmUgaXMgbm8gZGVmaW5pdGlv biBvZiB0aGUgbm9uLWVwaGVtZXJhbCBGQi1SSUIuICBJZiB5b3UgdGhpbmsgdGhlcmUgc2hvdWxk IGJlIGEgbm9uLWVwaGVtZXJhbCBGQi1SSUIg4oCTIHRoYXQgZGlzY3Vzc2lvbiBtYXkgYmUgdXNl ZnVsIGJldHdlZW4gSTJSUywgTmV0bW9kIGFuZCBTVVBBLg0KDQoNCg0KT24gIzIpIFNVUEEgRUNB IG1vZGVsLCBJIGFncmVlIHRoYXQgd2Ugc2hvdWxkIGJlIGFibGUgdG8gaGF2ZSBhIGNvbW1vbiBk cmFmdC4gIEF0IElFVEYgOTQsIEkgcmFpc2VkIGlzc3VlcyByZWdhcmRpbmcgdGhlIFNVUEEgdmVy c3VzIG15IEVDQSBkZWZpbml0aW9uLg0KDQoNCg0KQ2hlZXJpbHksDQoNCg0KDQpTdWUNCg0KDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKb2VsIE0uIEhhbHBlcm4gW21haWx0 bzpqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPl0NClNlbnQ6 IE1vbmRheSwgSmFudWFyeSAwNCwgMjAxNiAzOjU0IFBNDQpUbzogU3VzYW4gSGFyZXM7IGkycnNA aWV0Zi5vcmc8bWFpbHRvOmkycnNAaWV0Zi5vcmc+OyBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5l dG1vZEBpZXRmLm9yZz47IHN1cGFAaWV0Zi5vcmc8bWFpbHRvOnN1cGFAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZTogW2kycnNdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhh cmVzLWkycnMtYm5wLWVjYS1kYXRhLW1vZGVsLTAzLnR4dA0KDQoNCg0KSSB0aGluayB0aGVyZSBh cmUgdHdvIGlzc3VlcyBoZXJlLg0KDQoNCg0KMSkgSXQgaXMgbm90IGNsZWFyIHRvIG1lIHdoeSB0 aGVyZSBpcyBhbnkgZGVwZW5kZW5jZSBvZiB0aGUgZmItcmliIGRhdGEgbW9kZWwgb24gYW4gZWNh IGRhdGEgbW9kZWwuICBXaGlsZSBzdXBhIGRvZXMgYWxsb3cgZm9yIHBvbGljeSBtb2RlbCB0byBi ZSBzZW50IGRpcmVjdGx5IHRvIHRoZSByb3V0ZXIsIGl0IGFsc28gYWxsb3dzIG1hbnkgb3RoZXIg Y2FzZXMuDQoNCg0KDQoyKSBUaGUgYXBwcm9hY2ggd2l0aCB0aGUgc3VwYSBlY2EgZGF0YSBtb2Rl bCBpcyBzdGlsbCB1bmRlciBkZXZlbG9wbWVudC4NCg0KICBIYXZpbmcgc2FpZCB0aGF0LCB0aGUg bWF0ZXJpYWwgaW4gdGhlcmUgaXMgaW50ZW5kZWQgdG8gYmUgdmVyeSBnZW5lcmFsLiAgRnJvbSB3 aGF0IEkgdW5kZXJzdGFuZCwgdGhlcmUgc2hvdWxkIGJlIG5vIGRpZmZpY3VsdHkgaW4gcmVmaW5p bmcgdGhlIGFjdGlvbiBzaWRlIG9mIHRoYXQgbW9kZWwgdG8gYWN0aW9ucyB3aGljaCBhZmZlY3Qg dGhlIGZiLXJpYiBpbiB3YXlzIHRoYXQgYXJlIGNvbnNpc3RlbnQgd2l0aCB0aGUgZmItZGliIGRh dGEgbW9kZWwuDQoNCg0KDQpZb3VycywNCg0KSm9lbA0KDQoNCg0KT24gMS80LzE2IDI6MDEgUE0s IFN1c2FuIEhhcmVzIHdyb3RlOg0KDQo+IFRoaXMgbW9kZWwgcHJvdmlkZXMgYSBFdmVudC1Db25k aXRpb24tQWN0aW9uIChFQ0EpIHBvbGljeSBtb2RlbC4NCg0KPiBUaGUgSTJSUyBGQi1SSUIgeWFu ZyBkYXRhIG1vZGVsIHV0aWxpemVzIHRoaXMgbW9kZWwsIGJ1dCB0byBteQ0KDQo+IGtub3dsZWRn ZSB0aGUgTmV0bW9kIG9yIG5ldGNvbmYgaGFzIG5vdCBhZG9wdGVkIGFuIEVDQSBwb2xpY3kgbW9k ZWwgdG8NCg0KPiBwYXJhbGxlbCB0aGUgQUNMIG1vZGVsLg0KDQo+DQoNCj4gQ2hlbiBhbmQgY28t YXV0aG9ycyBoYXZlIGNyZWF0ZWQgdGhlIG1vZGVsOg0KDQo+DQoNCj4gZHJhZnQtY2hlbi1zdXBh LWVjYS1kYXRhLW1vZGVsLTA1LnR4dA0KDQo+DQoNCj4gQnV0IGl0IGRvZXMgbm90IGFsaWduIHdp dGggdGhpcyB5YW5nIG1vZGVsIG9yIHNlZW0gc3VmZmljaWVudCB0bw0KDQo+IHN1cHBvcnQgdGhl IEZCLVJJQiBpbmZvcm1hdGlvbiBtb2RlbC4gICBBdCBJRVRGIDk0LA0KDQo+IEkgcHJlc2VudGVk IGEgZGlzY3Vzc2lvbiBvZiB0aGUgaXNzdWVzIEkgZm91bmQgd2l0aCB0aGUNCg0KPiBkcmFmdC1j aGVuLXN1cGEtZWNhLWRhdGEtbW9kZWwtMDUudHh0LCBidXQgaXQgaGFzIG5vdCBiZWVuIHVwZGF0 ZWQuDQoNCj4gV2Ugd291bGQgYXBwcmVjaWF0ZSBmZWVkYmFjayBvbiB0aGlzIHZlcnNpb24gb2Yg eWFuZyBtb2RlbC4NCg0KPg0KDQo+IDxpMnJzIENoYWlyIGhhdCBvbj4NCg0KPiBJbiBteSByb2xl IGFzIEkyUlMgY2hhaXIsICBJMlJTIG5lZWRzIHRvIG1ha2UgcHJvZ3Jlc3Mgc29vbiBvbiB0aGUN Cg0KPiBJMlJTIEZCLVJJQiBkYXRhIG1vZGVsLiAgV2Ugd291bGQgYXBwcmVjaWF0ZSB5b3VyIGFp ZC4NCg0KPiA8aTJycyBjaGFpciBoYXQgb2ZmPg0KDQo+DQoNCj4gU3VlDQoNCj4NCg0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQo+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiBbbWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZ10NCg0KPiBTZW50OiBNb25kYXksIEphbnVhcnkgMDQsIDIwMTYgMTI6MDQgUE0N Cg0KPiBUbzogU3VzYW4gSGFyZXM7IFFpbiBXdTsgUnVzcyBXaGl0ZQ0KDQo+IFN1YmplY3Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCg0KPiBkcmFmdC1oYXJlcy1pMnJzLWJucC1lY2Et ZGF0YS1tb2RlbC0wMy50eHQNCg0KPg0KDQo+DQoNCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LWhhcmVzLWkycnMtYm5wLWVjYS1kYXRhLW1vZGVsLTAzLnR4dA0KDQo+IGhhcyBiZWVuIHN1 Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgU3VzYW4gSGFyZXMgYW5kIHBvc3RlZCB0byB0aGUgSUVU RiByZXBvc2l0b3J5Lg0KDQo+DQoNCj4gTmFtZTogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgZHJhZnQtaGFyZXMtaTJycy1ibnAtZWNhLWRhdGEtbW9kZWwNCg0KPiBSZXZpc2lvbjogICAg ICAgICAgMDMNCg0KPiBUaXRsZTogICAgICAgICAgICAgICAgICBBbiBJbmZvcm1hdGlvbiBNb2Rl bCBmb3IgQmFzaWMgTmV0d29yayBQb2xpY3kgYW5kIEZpbHRlciBSdWxlcw0KDQo+IERvY3VtZW50 IGRhdGU6ICAgICAgICAgICAyMDE2LTAxLTA0DQoNCj4gR3JvdXA6ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQoNCj4gUGFnZXM6ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDMwDQoNCj4gVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1oYXJlcy1pMnJzLWJucC1lY2EtZGF0YS1tb2Rl bC0wMy50eHQNCg0KPiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaGFyZXMtaTJycy1ibnAtZWNhLWRhdGEtbW9kZWwvDQoNCj4gSHRtbGl6ZWQ6 ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oYXJlcy1pMnJzLWJucC1l Y2EtZGF0YS1tb2RlbC0wMw0KDQo+IERpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtaGFyZXMtaTJycy1ibnAtZWNhLWRhdGEtbW9kZWwtMDMNCg0K Pg0KDQo+IEFic3RyYWN0Og0KDQo+ICAgICBUaGlzIGRvY3VtZW50IGNvbnRhaW5zIHRoZSBCYXNp YyBOZXR3b3JrIFBvbGljeSBhbmQgRmlsdGVycyAoQk5QIElNKQ0KDQo+ICAgICBEYXRhIE1vZGVs IHdoaWNoIHByb3ZpZGVzIGEgcG9saWN5IG1vZGVsIHRoYXQgc3VwcG9ydCBhbiBvcmRlcmVkIGxp c3QNCg0KPiAgICAgb2YgbWF0Y2gtY29uZGl0aW9uLWFjdGlvbiAoYWthIGV2ZW50LWNvbmRpdGlv bi1hY3Rpb24gKEVDQSkpIGZvcg0KDQo+ICAgICBtdWx0aXBsZSBsYXllcnMgKGludGVyZmFjZSwg TDEtTDQsIGFwcGxpY2F0aW9uKSBhbmQgb3RoZXIgZmFjdG9ycw0KDQo+ICAgICAoc2l6ZSBvZiBw YWNrZXQsIHRpbWUgb2YgZGF5KS4gIFRoZSBhY3Rpb25zIGFsbG93IGZvciBzZXR0aW5nIGFjdGlv bnMNCg0KPiAgICAgKFFPUyBhbmQgb3RoZXIpLCBkZWNhcHN1bGF0aW9uLCBlbmNhcHN1bGF0aW9u LCBwbHVzIGZvcndhcmRpbmcNCg0KPiAgICAgYWN0aW9ucy4gIFRoZSBwb2xpY3kgbW9kZWwgY2Fu IGJlIHVzZWQgd2l0aCB0aGUgSTJSUyBmaWx0ZXItYmFzZWQNCg0KPiAgICAgUklCLg0KDQo+DQoN Cj4NCg0KPg0KDQo+DQoNCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90 b29scy5pZXRmLm9yZz4uDQoNCj4NCg0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo+DQoNCj4N Cg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQo+ IGkycnMgbWFpbGluZyBsaXN0DQoNCj4gaTJyc0BpZXRmLm9yZzxtYWlsdG86aTJyc0BpZXRmLm9y Zz4NCg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnMNCg0KPg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU3VwYSBt YWlsaW5nIGxpc3QNClN1cGFAaWV0Zi5vcmc8bWFpbHRvOlN1cGFAaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1cGENCg0KDQoNCi0tDQpyZWdhcmRzLA0K Sm9obg0K --_000_B818037A70EDCC4A86113DA25EC02098201B9472SJCEML701CHMchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIg MTEgNiA0IDMgNSA0IDQgMiA0O30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0K CW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2lu LWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsInNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0 YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBU ZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5C YWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJ Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LlNlY3Rp b24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KIDwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IlNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9y OiMxRjQ5N0QiPlN1ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5JJ20gaGFwcHkgdG8gaGVscC4gSTJSUyBpcyBp bXBvcnRhbnQgd29yaywgYW5kIEkgd291bGQgbGlrZSB0byBlbnN1cmUgdGhhdCBTVVBBIGNvdWxk IGhlbHAgeW91ciB3b3JrICh3aXRob3V0IGRlbGF5aW5nIGl0LCBvZiBjb3Vyc2UpLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMx RjQ5N0QiPkFsc28sIEknbSBpbnRlcmVzdGVkIGluIHRoZSBkYXRhIG1vZGVscyB0aGF0IHlvdSBj b21lIHVwIHdpdGgsIGFzIHRoZXkgYXJlIGV4Y2VsbGVudCBleGFtcGxlcyBvZiB3aGF0IFNVUEEg bmVlZHMgdG8gc3VwcG9ydC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5yZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsN CmNvbG9yOiMxRjQ5N0QiPkpvaG48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IG5ldG1vZCBbbWFpbHRv Om5ldG1vZC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5TdXNhbiBIYXJl czxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEphbnVhcnkgMDYsIDIwMTYgMzoyNSBQTTxi cj4NCjxiPlRvOjwvYj4gJ0pvaG4gU3RyYXNzbmVyJzxicj4NCjxiPkNjOjwvYj4gaTJyc0BpZXRm Lm9yZzsgc3VwYUBpZXRmLm9yZzsgbmV0bW9kQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbbmV0bW9kXSBbU3VwYV0gW2kycnNdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWhhcmVzLWkycnMtYm5wLWVjYS1kYXRhLW1vZGVsLTAzLnR4dDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPkpvaG46DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5Zb3UgYXJlIGNv cnJlY3QgaW4gaW5kaWNhdGluZyB0aGF0IHRoZSBkcmFmdCBhc3N1bWVzIHlvdSB1bmRlcnN0YW5k IHRoZSBldmVudCA9IFBhY2tldCByZWNlcHRpb24uJm5ic3A7IEl0IGlzIGEgZmFpbGluZyBpbiB0 aGUgZHJhZnQgdGhhdCBKb2VsIGhhcyBpbmRpY2F0ZWQgb24NCiB0aGVzZSBsaXN0cy4gJm5ic3A7 SSB3aWxsIGJlIHVwZGF0aW5nIHRoZSBFQ0EgZHJhZnRzIGFuZCBGQi1SSUIgZHJhZnRzLiZuYnNw OyBJIHdpbGwgc2VuZCBhIGNvcHkgdG8geW91IGFuZCBKb2VsIGZvciByZXZpZXcgdGhpcyB3ZWVr Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ow0KY29sb3I6IzFGNDk3RCI+VGhhbmsgeW91IGZvciBwb2ludGluZyBvdXQgdGhlIGVycm9ycyBp biB0aGUgZHJhZnRzLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+U3VlDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSm9obiBTdHJhc3NuZXIgW21haWx0bzpzdHJhenBkakBn bWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSmFudWFyeSAwNSwgMjAxNiAx MDoyOCBQTTxicj4NCjxiPlRvOjwvYj4gU3VzYW4gSGFyZXM8YnI+DQo8Yj5DYzo8L2I+IEpvZWwg TS4gSGFscGVybjsgaTJyc0BpZXRmLm9yZzsgbmV0bW9kQGlldGYub3JnOyBzdXBhQGlldGYub3Jn OyBKb2huIFN0cmFzc25lcjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1N1cGFdIFtpMnJzXSBG VzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1oYXJlcy1pMnJzLWJucC1lY2Et ZGF0YS1tb2RlbC0wMy50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+U3VlLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHA+Jmd0OyBPbiAjMSkg dGhlIGRlcGVuZGVuY3kgYmV0d2VlbiBJMlJTIEZpbHRlci1iYXNlZCBSSUIgKEZCLVJJQikgYW5k PGJyPg0KJmd0OyZuYnNwO0VDQSwgcGxlYXNlIHNlZSBkcmFmdC1raW5pLWkycnMtZmItcmliLWlu Zm8tbW9kZWwtMDIudHh0LiBJbiBzZWN0aW9uIDEuMSw8YnI+DQomZ3Q7IGl0IGdpdmVzIHRoZSBk ZWZpbml0aW9uIG9mIHRoZSBGQi1SSUIuPG86cD48L286cD48L3A+DQo8cD5Tb3JyeSwgaXQgZG9l cyBOT1QgZG8gdGhpcy4gVG8gcXVvdGUgZnJvbSB0aGlzIHNlY3Rpb246PG86cD48L286cD48L3A+ DQo8cD48c3BhbiBsYW5nPSJFTiI+Jm5ic3A7ICZuYnNwO0EgRmlsdGVyIEJhc2VkIFJJQiB1c2Vz IEV2ZW50LUNvbmRpdGlvbi1BY3Rpb24gcG9saWN5LiBBIEZpbHRlci08YnI+DQombmJzcDsgJm5i c3A7YmFzZWQgUklCIGVudHJ5IHNwZWNpZmllcyBtYXRjaGVzIG9uIGZpZWxkcyBpbiBhIHBhY2tl dCAod2hpY2ggbWF5PGJyPg0KJm5ic3A7ICZuYnNwO2luY2x1ZGUgbGF5ZXIgMiBmaWVsZHMsIElQ IGhlYWRlciBmaWVsZHMsIHRyYW5zcG9ydCBvciBhcHBsaWNhdGlvbjxicj4NCiZuYnNwOyAmbmJz cDtmaWVsZHMpIG9yIHNpemUgb2YgdGhlIHBhY2tldCBvciBpbnRlcmZhY2UgcmVjZWl2ZWQgb24u IFRoZSBtYXRjaGVzPGJyPg0KJm5ic3A7ICZuYnNwO2FyZSBjb250YWluZWQgaW4gYW4gb3JkZXJl ZCBsaXN0IG9mIGZpbHRlcnMgd2hpY2ggY29udGFpbiBwYWlycyBvZjxicj4NCiZuYnNwOyZuYnNw OyBtYXRjaCBjb25kaXRpb24tYWN0aW9uIChha2EgZXZlbnQtY29uZGl0aW9uLWFjdGlvbikuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHA+UGxlYXNlIHRlbGwgbWUgV0hFUkUgdGhlIGV2ZW50IGlz IGluIHRoZSBhYm92ZSBkZWZpbml0aW9uLiBBbGwgSSBzZWUgaXM8YnI+DQphIGNvbmRpdGlvbi1h Y3Rpb24gcnVsZS4gKEJUVywgdGhlIGFuYWx5c2lzIG9mIFBDSU0gYW5kIFBDSU1lIGlzIGFsc288 YnI+DQpub3QgcXVpdGUgY29ycmVjdCBpbiB5b3VyIGRyYWZ0KS48bzpwPjwvbzpwPjwvcD4NCjxw PiZndDsgSW4gc2VjdGlvbiAxLjIsIGl0IGxpbmtzIHRoaXMgdG8gYW4gZXZlbnQtY29uZGl0aW9u LWFjdGlvbiBtb2RlbC48bzpwPjwvbzpwPjwvcD4NCjxwPlNvcnJ5LCBpdCBkb2VzIE5PVCBkbyB0 aGlzLjxvOnA+PC9vOnA+PC9wPg0KPHA+Rmlyc3QsIHRoaXMgc2VjdGlvbiBzaW1wbHkgc2F5cywg YW5kIEkgcXVvdGU6PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTiI+Jm5ic3A7Jm5i c3A7ICZxdW90O1RoZSBmaWx0ZXIgYmFzZWQtUklCIHVzZXMgZXZlbnQtY29uZGl0aW9uLWFjdGlv biBwb2xpY3kgKEVDQSkgcnVsZXMuJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNw YW4gbGFuZz0iRU4iPlRoYXQgaXMgYSB0YXV0b2xvZ3kgYXQgYmVzdC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTiI+U2Vjb25kLCBpbiBTZWN0aW9uIDIsIHVuZGVyIHRo ZSBkZWZpbml0aW9uIG9mIEZCLVJvdXRlLCB0aGUgZHJhZnQgc2F5czo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTiI+Jm5ic3A7Jm5ic3A7ICZxdW90O1RoZSBwb2xpY3kg cnVsZXMgaW4gdGhlIGZpbHRlci1iYXNlZCBSSUIgYXJlIHByZXNjcmlwdGl2ZSBvZiB0aGU8YnI+ DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtFdmVudC1Db25kaXRpb24tQWN0aW9uIGZv cm0gd2hpY2ggaXMgb2Z0ZW4gcmVwcmVzZW50ZWQgYnk8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaWYgQ29uZGl0aW9uIHRoZW4gYWN0aW9uLiZxdW90Ozxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOIj5QbGVhc2Ugbm90ZSB0aGF0 IHRoaXMgZGVmaW5pdGlvbiBpcyBpbmNvcnJlY3QsIGFuZCBpbiBjb25mbGljdCB3aXRoIFNVUEEu PGJyPg0KVGhlIHdob2xlIHBvaW50IG9mIGFuIEVWRU5ULWNvbmRpdGlvbi1hY3Rpb24gcG9saWN5 IHJ1bGUgaXMgdG8gZGVmaW5lPGJyPg0KYSBydWxlIG9mIHRoZSBmb3JtOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOIj4mbmJzcDsmbmJzcDsmbmJzcDsgSUYgJmx0O2V2 ZW50X2NsYXVzZSZndDsgZXZhbHVhdGVzIHRvIFRSVUU8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSUYgJmx0O2NvbmRpdGlvbl9jbGF1c2UgZXZhbHVhdGVz IHRvIFRSVUU8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVEhFTiBleGVjdXRlIGFjdGlvbnMgaW4gJmx0O2FjdGlv bl9jbGF1c2UmZ3Q7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IEVORElGPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IEVORElGPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4iPlRoaXMgZGVmaW5pdGlvbiBoYXMgYmVlbiBlc3RhYmxp c2hlZCBpbiB0aGUgaW5kdXN0cnkgYW5kIGFjYWRlbWlhPGJyPg0KZm9yIGF0IGxlYXN0IDIgZGVj YWRlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTiI+VmFyaWF0aW9u cyBvZiB0aGUgYWJvdmUgaGF2ZSBiZWVuIGRlZmluZWQgYW5kIHB1Ymxpc2hlZCAoZS5nLiw8YnI+ DQpGT0NBTEUgaGFzIGFuIGFsdGVybmF0ZSBzZXQgb2YgYWN0aW9ucyB0byBleGVjdXRlIGlmIHRo ZSBjb25kaXRpb248YnI+DQpjbGF1c2UgZXZhbHVhdGVkIHRvIEZBTFNFOyB0aGlzIGhhcyBOT1Qg YmVlbiBwcm9wb3NlZCBmb3IgU1VQQTxicj4NCmF0IHRoaXMgdGltZSkuIFRoZXJlIGhhdmUgYWxz byBiZWVuIGV4dGVuc2lvbnMgdG8gaGFuZGxlIHNldHMgYW5kPGJyPg0KZ3JvdXBzLCBhcyB3ZWxs IGFzIHNwZWNpZmljIG9yZGVyaW5nIChERU4tbmcsIFNJRCwgRk9DQUxFKS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTiI+VGhlcmVmb3JlLCBJIHdvdWxkIHN1Z2dlc3Qg dGhhdCB5b3UgY2hhbmdlIHlvdXIgZHJhZnRzIHRvIHVzZSBhPGJyPg0KY29uZGl0aW9uLWFjdGlv biBwb2xpY3kgcnVsZSwgT1IgdXBkYXRlIHRoZSBkcmFmdHMgKEkgd291bGQgYmUgaGFwcHk8YnI+ DQp0byBoZWxwKSB0byB1c2UgYSBjb3JyZWN0IGRlZmluaXRpb24gb2YgYW4gRUNBIHBvbGljeSBy dWxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOIj5yZWdhcmRzLDxi cj4NCkpvaG48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIE1vbiwgSmFuIDQsIDIwMTYgYXQgMjozMyBQTSwgU3VzYW4gSGFyZXMg Jmx0OzxhIGhyZWY9Im1haWx0bzpzaGFyZXNAbmR6aC5jb20iIHRhcmdldD0iX2JsYW5rIj5zaGFy ZXNAbmR6aC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHA+Sm9lbDogPG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPk9u ICMxKSB0aGUgZGVwZW5kZW5jeSBiZXR3ZWVuIEkyUlMgRmlsdGVyLWJhc2VkIFJJQiAoRkItUklC KSBhbmQgRUNBLCBwbGVhc2Ugc2VlIGRyYWZ0LWtpbmktaTJycy1mYi1yaWItaW5mby1tb2RlbC0w Mi50eHQuIEluIHNlY3Rpb24gMS4xLCBpdCBnaXZlcyB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgRkIt UklCLiZuYnNwOyBJbiBzZWN0aW9uIDEuMiwgaXQgbGlua3MgdGhpcyB0byBhbiBldmVudC1jb25k aXRpb24tYWN0aW9uIG1vZGVsLiZuYnNwOyBJZiB5b3UgZGlzYWdyZWUNCiB3aXRoIHRoZSBkZWZp bml0aW9uIG9mICZuYnNwO0kyUlMgRkItUklCLCB0aGVuIHdlIHNob3VsZCBwcm9iYWJseSByZXN0 cmljdCB0aGlzIGNvbnZlcnNhdGlvbiB0byB0aGUgSTJSUyBtYWlsIGxpc3QuJm5ic3A7IEFueSBm ZWVkYmFjayBvbiB0aGUgSW5mby1tb2RlbCBvciBkYXRhLW1vZGVsIHdvdWxkIGJlIGhlbHBmdWwu Jm5ic3A7IFRoZSBhdXRob3JzIGhvcGVkIHRvIGdvIHRvIGEgV0cgYWRvcHRpb24gY2FsbCBhdCB0 aGUgZW5kIG9mIHRoaXMgd2Vlay4NCjxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cD5PbmUgY2hhbGxlbmdlIGZvciB0aGUgZXBoZW1lcmFsIEkyUlMgRkItUklCLCBp cyB0aGVyZSBpcyBubyBkZWZpbml0aW9uIG9mIHRoZSBub24tZXBoZW1lcmFsIEZCLVJJQi4mbmJz cDsgSWYgeW91IHRoaW5rIHRoZXJlIHNob3VsZCBiZSBhIG5vbi1lcGhlbWVyYWwgRkItUklCIOKA kyB0aGF0IGRpc2N1c3Npb24gbWF5IGJlIHVzZWZ1bCBiZXR3ZWVuIEkyUlMsIE5ldG1vZCBhbmQg U1VQQS4NCjxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5PbiAj MikgU1VQQSBFQ0EgbW9kZWwsIEkgYWdyZWUgdGhhdCB3ZSBzaG91bGQgYmUgYWJsZSB0byBoYXZl IGEgY29tbW9uIGRyYWZ0LiZuYnNwOyBBdCBJRVRGIDk0LCBJIHJhaXNlZCBpc3N1ZXMgcmVnYXJk aW5nIHRoZSBTVVBBIHZlcnN1cyBteSBFQ0EgZGVmaW5pdGlvbi4mbmJzcDsgJm5ic3A7PG86cD48 L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPkNoZWVyaWx5LCA8bzpwPjwv bzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+U3VlIDxvOnA+PC9vOnA+PC9w Pg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LTxicj4NCkZyb206IEpvZWwgTS4gSGFscGVybiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpqbWhA am9lbGhhbHBlcm4uY29tIiB0YXJnZXQ9Il9ibGFuayI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT5d DQo8YnI+DQpTZW50OiBNb25kYXksIEphbnVhcnkgMDQsIDIwMTYgMzo1NCBQTTxicj4NClRvOiBT dXNhbiBIYXJlczsgPGEgaHJlZj0ibWFpbHRvOmkycnNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5pMnJzQGlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5uZXRtb2RAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86c3VwYUBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0Kc3VwYUBpZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0 OiBSZTogW2kycnNdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhhcmVz LWkycnMtYm5wLWVjYS1kYXRhLW1vZGVsLTAzLnR4dDxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cD5JIHRoaW5rIHRoZXJlIGFyZSB0d28gaXNzdWVzIGhlcmUuPG86 cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPjEpIEl0IGlzIG5vdCBj bGVhciB0byBtZSB3aHkgdGhlcmUgaXMgYW55IGRlcGVuZGVuY2Ugb2YgdGhlIGZiLXJpYiBkYXRh IG1vZGVsIG9uIGFuIGVjYSBkYXRhIG1vZGVsLiZuYnNwOyBXaGlsZSBzdXBhIGRvZXMgYWxsb3cg Zm9yIHBvbGljeSBtb2RlbCB0byBiZSBzZW50IGRpcmVjdGx5IHRvIHRoZSByb3V0ZXIsIGl0IGFs c28gYWxsb3dzIG1hbnkgb3RoZXIgY2FzZXMuPG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwPjIpIFRoZSBhcHByb2FjaCB3aXRoIHRoZSBzdXBhIGVjYSBkYXRhIG1v ZGVsIGlzIHN0aWxsIHVuZGVyIGRldmVsb3BtZW50LiA8bzpwPg0KPC9vOnA+PC9wPg0KPHA+Jm5i c3A7Jm5ic3A7SGF2aW5nIHNhaWQgdGhhdCwgdGhlIG1hdGVyaWFsIGluIHRoZXJlIGlzIGludGVu ZGVkIHRvIGJlIHZlcnkgZ2VuZXJhbC4mbmJzcDsgRnJvbSB3aGF0IEkgdW5kZXJzdGFuZCwgdGhl cmUgc2hvdWxkIGJlIG5vIGRpZmZpY3VsdHkgaW4gcmVmaW5pbmcgdGhlIGFjdGlvbiBzaWRlIG9m IHRoYXQgbW9kZWwgdG8gYWN0aW9ucyB3aGljaCBhZmZlY3QgdGhlIGZiLXJpYiBpbiB3YXlzIHRo YXQgYXJlIGNvbnNpc3RlbnQgd2l0aCB0aGUgZmItZGliIGRhdGENCiBtb2RlbC48bzpwPjwvbzpw PjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+WW91cnMsPG86cD48L286cD48L3A+ DQo8cD5Kb2VsPG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPk9u IDEvNC8xNiAyOjAxIFBNLCBTdXNhbiBIYXJlcyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwPiZn dDsgVGhpcyBtb2RlbCBwcm92aWRlcyBhIEV2ZW50LUNvbmRpdGlvbi1BY3Rpb24gKEVDQSkgcG9s aWN5IG1vZGVsLjxvOnA+PC9vOnA+PC9wPg0KPHA+Jmd0OyBUaGUgSTJSUyBGQi1SSUIgeWFuZyBk YXRhIG1vZGVsIHV0aWxpemVzIHRoaXMgbW9kZWwsIGJ1dCB0byBteSA8bzpwPjwvbzpwPjwvcD4N CjxwPiZndDsga25vd2xlZGdlIHRoZSBOZXRtb2Qgb3IgbmV0Y29uZiBoYXMgbm90IGFkb3B0ZWQg YW4gRUNBIHBvbGljeSBtb2RlbCB0byA8bzpwPg0KPC9vOnA+PC9wPg0KPHA+Jmd0OyBwYXJhbGxl bCB0aGUgQUNMIG1vZGVsLjxvOnA+PC9vOnA+PC9wPg0KPHA+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHA+Jmd0OyBDaGVuIGFuZCBjby1hdXRob3JzIGhhdmUgY3JlYXRlZCB0aGUgbW9kZWw6 PG86cD48L286cD48L3A+DQo8cD4mZ3Q7Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD4mZ3Q7IGRy YWZ0LWNoZW4tc3VwYS1lY2EtZGF0YS1tb2RlbC0wNS50eHQ8bzpwPjwvbzpwPjwvcD4NCjxwPiZn dDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPiZndDsgQnV0IGl0IGRvZXMgbm90IGFsaWduIHdp dGggdGhpcyB5YW5nIG1vZGVsIG9yIHNlZW0gc3VmZmljaWVudCB0bzxvOnA+PC9vOnA+PC9wPg0K PHA+Jmd0OyBzdXBwb3J0IHRoZSBGQi1SSUIgaW5mb3JtYXRpb24gbW9kZWwuJm5ic3A7Jm5ic3A7 IEF0IElFVEYgOTQsPG86cD48L286cD48L3A+DQo8cD4mZ3Q7IEkgcHJlc2VudGVkIGEgZGlzY3Vz c2lvbiBvZiB0aGUgaXNzdWVzIEkgZm91bmQgd2l0aCB0aGUgPG86cD48L286cD48L3A+DQo8cD4m Z3Q7IGRyYWZ0LWNoZW4tc3VwYS1lY2EtZGF0YS1tb2RlbC0wNS50eHQsIGJ1dCBpdCBoYXMgbm90 IGJlZW4gdXBkYXRlZC48bzpwPjwvbzpwPjwvcD4NCjxwPiZndDsgV2Ugd291bGQgYXBwcmVjaWF0 ZSBmZWVkYmFjayBvbiB0aGlzIHZlcnNpb24gb2YgeWFuZyBtb2RlbC48bzpwPjwvbzpwPjwvcD4N CjxwPiZndDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPiZndDsgJmx0O2kycnMgQ2hhaXIgaGF0 IG9uJmd0OzxvOnA+PC9vOnA+PC9wPg0KPHA+Jmd0OyBJbiBteSByb2xlIGFzIEkyUlMgY2hhaXIs Jm5ic3A7IEkyUlMgbmVlZHMgdG8gbWFrZSBwcm9ncmVzcyBzb29uIG9uIHRoZSA8bzpwPjwvbzpw PjwvcD4NCjxwPiZndDsgSTJSUyBGQi1SSUIgZGF0YSBtb2RlbC4mbmJzcDsgV2Ugd291bGQgYXBw cmVjaWF0ZSB5b3VyIGFpZC48bzpwPjwvbzpwPjwvcD4NCjxwPiZndDsgJmx0O2kycnMgY2hhaXIg aGF0IG9mZiZndDs8bzpwPjwvbzpwPjwvcD4NCjxwPiZndDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwPiZndDsgU3VlPG86cD48L286cD48L3A+DQo8cD4mZ3Q7Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cD4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3A+DQo8cD4m Z3Q7IEZyb206IDxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246 bm9uZSI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9zcGFuPjwvYT4gWzxhIGhyZWY9Im1haWx0 bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i Y29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+bWFpbHRvOmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZzwvc3Bhbj48L2E+XTxvOnA+PC9vOnA+PC9wPg0KPHA+Jmd0OyBTZW50OiBN b25kYXksIEphbnVhcnkgMDQsIDIwMTYgMTI6MDQgUE08bzpwPjwvbzpwPjwvcD4NCjxwPiZndDsg VG86IFN1c2FuIEhhcmVzOyBRaW4gV3U7IFJ1c3MgV2hpdGU8bzpwPjwvbzpwPjwvcD4NCjxwPiZn dDsgU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciA8bzpwPjwvbzpwPjwvcD4N CjxwPiZndDsgZHJhZnQtaGFyZXMtaTJycy1ibnAtZWNhLWRhdGEtbW9kZWwtMDMudHh0PG86cD48 L286cD48L3A+DQo8cD4mZ3Q7Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD4mZ3Q7Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cD4mZ3Q7IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1oYXJlcy1p MnJzLWJucC1lY2EtZGF0YS1tb2RlbC0wMy50eHQ8bzpwPjwvbzpwPjwvcD4NCjxwPiZndDsgaGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBTdXNhbiBIYXJlcyBhbmQgcG9zdGVkIHRv IHRoZSBJRVRGIHJlcG9zaXRvcnkuPG86cD48L286cD48L3A+DQo8cD4mZ3Q7Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cD4mZ3Q7IE5hbWU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0LWhhcmVzLWkycnMtYm5wLWVj YS1kYXRhLW1vZGVsPG86cD48L286cD48L3A+DQo8cD4mZ3Q7IFJldmlzaW9uOiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwMzxvOnA+PC9vOnA+ PC9wPg0KPHA+Jmd0OyBUaXRsZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgQW4gSW5mb3JtYXRpb24gTW9kZWwgZm9yIEJhc2ljIE5ldHdvcmsgUG9saWN5IGFu ZCBGaWx0ZXIgUnVsZXM8bzpwPjwvbzpwPjwvcD4NCjxwPiZndDsgRG9jdW1lbnQgZGF0ZTombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg MjAxNi0wMS0wNDxvOnA+PC9vOnA+PC9wPg0KPHA+Jmd0OyBHcm91cDombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSW5kaXZpZHVhbCBT dWJtaXNzaW9uPG86cD48L286cD48L3A+DQo8cD4mZ3Q7IFBhZ2VzOiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAzMDxvOnA+ PC9vOnA+PC9wPg0KPHA+Jmd0OyBVUkw6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1oYXJlcy1pMnJzLWJucC1lY2EtZGF0YS1tb2Rl bC0wMy50eHQiIHRhcmdldD0iX2JsYW5rIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0 O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtaGFyZXMtaTJycy1ibnAtZWNhLWRhdGEtbW9kZWwtMDMudHh0PC9zcGFuPjwvYT48 bzpwPjwvbzpwPjwvcD4NCjxwPiZndDsgU3RhdHVzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1oYXJlcy1pMnJzLWJucC1lY2EtZGF0YS1tb2RlbC8iIHRhcmdldD0iX2Js YW5rIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25l Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1oYXJlcy1pMnJzLWJucC1l Y2EtZGF0YS1tb2RlbC88L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHA+Jmd0OyBIdG1saXpl ZDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhhcmVzLWkycnMtYm5wLWVjYS1kYXRhLW1vZGVsLTAz IiB0YXJnZXQ9Il9ibGFuayI+DQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRl Y29yYXRpb246bm9uZSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhhcmVzLWky cnMtYm5wLWVjYS1kYXRhLW1vZGVsLTAzPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwPiZn dDsgRGlmZjombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LWhhcmVzLWkycnMtYm5wLWVjYS1kYXRhLW1vZGVsLTAzIiB0YXJnZXQ9Il9ibGFuayI+DQo8 c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWhhcmVzLWkycnMtYm5wLWVjYS1kYXRh LW1vZGVsLTAzPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwPiZndDsmbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwPiZndDsgQWJzdHJhY3Q6PG86cD48L286cD48L3A+DQo8cD4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoaXMgZG9jdW1lbnQgY29udGFpbnMgdGhlIEJhc2ljIE5ldHdv cmsgUG9saWN5IGFuZCBGaWx0ZXJzIChCTlAgSU0pPG86cD48L286cD48L3A+DQo8cD4mZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERhdGEgTW9kZWwgd2hpY2ggcHJvdmlkZXMgYSBwb2xpY3kg bW9kZWwgdGhhdCBzdXBwb3J0IGFuIG9yZGVyZWQgbGlzdDxvOnA+PC9vOnA+PC9wPg0KPHA+Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvZiBtYXRjaC1jb25kaXRpb24tYWN0aW9uIChha2Eg ZXZlbnQtY29uZGl0aW9uLWFjdGlvbiAoRUNBKSkgZm9yPG86cD48L286cD48L3A+DQo8cD4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG11bHRpcGxlIGxheWVycyAoaW50ZXJmYWNlLCBMMS1M NCwgYXBwbGljYXRpb24pIGFuZCBvdGhlciBmYWN0b3JzPG86cD48L286cD48L3A+DQo8cD4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IChzaXplIG9mIHBhY2tldCwgdGltZSBvZiBkYXkpLiZu YnNwOyBUaGUgYWN0aW9ucyBhbGxvdyBmb3Igc2V0dGluZyBhY3Rpb25zPG86cD48L286cD48L3A+ DQo8cD4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IChRT1MgYW5kIG90aGVyKSwgZGVjYXBz dWxhdGlvbiwgZW5jYXBzdWxhdGlvbiwgcGx1cyBmb3J3YXJkaW5nPG86cD48L286cD48L3A+DQo8 cD4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFjdGlvbnMuJm5ic3A7IFRoZSBwb2xpY3kg bW9kZWwgY2FuIGJlIHVzZWQgd2l0aCB0aGUgSTJSUyBmaWx0ZXItYmFzZWQ8bzpwPjwvbzpwPjwv cD4NCjxwPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUklCLjxvOnA+PC9vOnA+PC9wPg0K PHA+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHA+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHA+Jmd0OyBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p bnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJz aW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRvb2xzLmlldGYub3JnPC9hPi48bzpwPjwvbzpwPjwvcD4N CjxwPiZndDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPiZndDsgVGhlIElFVEYgU2VjcmV0YXJp YXQ8bzpwPjwvbzpwPjwvcD4NCjxwPiZndDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPiZndDsm bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcD4NCjxwPiZndDsgaTJycyBtYWlsaW5n IGxpc3Q8bzpwPjwvbzpwPjwvcD4NCjxwPiZndDsgPGEgaHJlZj0ibWFpbHRvOmkycnNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDsNCnRleHQt ZGVjb3JhdGlvbjpub25lIj5pMnJzQGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4N CjxwPiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p MnJzIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1k ZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJy czwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cD4mZ3Q7Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NClN1cGEgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlN1cGFA aWV0Zi5vcmciPlN1cGFAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdXBhIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdXBhPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8YnI+DQotLSA8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cmVnYXJk cyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpv aG48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_B818037A70EDCC4A86113DA25EC02098201B9472SJCEML701CHMchi_-- From nobody Wed Jan 6 19:26:36 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2EBE1A6FB4 for ; Wed, 6 Jan 2016 19:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHmH9Vptg9cD for ; Wed, 6 Jan 2016 19:26:33 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::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 2CADD1A6FB8 for ; Wed, 6 Jan 2016 19:26:31 -0800 (PST) Received: by mail-lb0-x230.google.com with SMTP id bc4so200439901lbc.2 for ; Wed, 06 Jan 2016 19:26:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=rU3SOuIfEt1ouqQ8gAXsyM9AVaM+moDyMvAC9Bymy1M=; b=jUZkpMcSxT+iw8bkXP2fi4s9FEqQkTD0Bk3Pv+Jhp0adLdXGBOpIubAI/S6wFan328 syDH80Zad2UiuQkXLXcp0KS/cd08xSUvRt4XzdttHRVyDo+kAcA3lVjUBDRmxUOqdj75 RddV65TXr1tsHun0pILpLBnqotXurSHobaJwykpdAehFUWEjC94j5bz1Qazcai0So0nf mRPRbOW06LFA9zSUC1JcMMr3gCaGZdkuCk1G4QKTBpz9p8NMub4Zzd8NWTFibm8vrw/D kYOc92LuK+wcLaiX56hGAqBAHL92yxV2X3ctqshhSkpR3ti/tMDrMo5WQFxfXTHadYsw k9wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=rU3SOuIfEt1ouqQ8gAXsyM9AVaM+moDyMvAC9Bymy1M=; b=SScLyy8FeeeThDAf/n0RMu6kbZfrodXUEZ9mJ5Ro5eLWNSBdQPZ403VRnRK7mreePA oqHvraybBCBGpKQr36TwNwpWnyKRwwe1FT1bgJLXZjvQktMF2GsWImTQXDdymX1Mb/PD KZuisk5bL6iMqbRpAaol7W8zWBb/wyZemD3uZ5qslUjRciYJZJj6tbwcuKbTFFicpggd qdN3PyIMD2Nf8uI+0hB/PjTe3ior5/JQIUPAFOcylmGxyMC4yiWgVeO7gDsbMfo7qVOe JWpmMQQ6skugFzNu13nV5nAnIU66Y0RU88+elTu0XWgrgerkrtCEd+hhARXkp2IgUR4Z 47aw== X-Gm-Message-State: ALoCoQl9Wzcvkh+8WOQ/MZc3quhbxPv31ttyjQ4xcY04zoXWe+yeXskFA0lgega4edWceXS90uM50pbh1RUBP2tYNpo9U0nx/w== MIME-Version: 1.0 X-Received: by 10.112.199.41 with SMTP id jh9mr29255893lbc.119.1452137189155; Wed, 06 Jan 2016 19:26:29 -0800 (PST) Received: by 10.112.144.36 with HTTP; Wed, 6 Jan 2016 19:26:29 -0800 (PST) Date: Wed, 6 Jan 2016 19:26:29 -0800 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c23682533cea0528b609e5 Archived-At: Subject: [netmod] action-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 03:26:34 -0000 --001a11c23682533cea0528b609e5 Content-Type: text/plain; charset=UTF-8 Hi, The action-stmt example on page 27 is wrong. The element is missing. It is shown correctly on page 105. p27 eth1 192.0.2.1 p105 apache-1 2014-07-29T13:42:00Z Sec. 7.15 provides few details wrt/ input processing. Extra input is ignored? (draft is silent about that). YANG attributes like "insert"or "operation" are ignored? (also silent). Sec 7.15.2, para 2 is not clear whether the XML hierarchy has to exist in any particular datastore (or opstate). Since there is no mention of datastores in 7.15, I assume the text just refers to the input containing schema-valid XML, which may or may not correspond to actual data instances somewhere inn the server. Andy --001a11c23682533cea0528b609e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The action-stmt example on page 27 = is wrong.
The <action> element is missing.=C2=A0 It is show= n correctly
on page 105.
p27
=C2=A0= <rpc message-id=3D"102"
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
=C2=A0 =C2=A0 =C2=A0 =C2=A0<interface xmlns=3D"http://acme.example.com/system"><= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>eth1</name>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<ping>
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<destination>192.0.2.1</destinat= ion>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</ping>
=C2=A0 =C2=A0 =C2=A0 =C2=A0</interface>
=C2=A0 =C2=A0 =C2= =A0</rpc>


p1= 05

=C2=A0 =C2=A0 =C2=A0<rpc message-id=3D"= 101"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns=3D"urn:ie= tf:params:xml:ns:netconf:base:1.0">
=C2=A0 =C2=A0 =C2=A0 = =C2=A0<action xmlns=3D"urn:ietf:params:xml:ns:yang:1">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<server xmlns=3D"http://example.net/server-farm"&g= t;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>apache-1&= lt;/name>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<reset&g= t;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<reset-at&g= t;2014-07-29T13:42:00Z</reset-at>
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0</reset>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0</server>
=C2=A0 =C2=A0 =C2=A0 =C2=A0</action>
=C2=A0 =C2=A0 =C2=A0</rpc>


=
Sec. 7.15 =C2=A0provides few details wrt/ input processing.
Extra input is ignored? (draft is silent about that).
YANG = attributes like "insert"or "operation" are ignored? (al= so silent).

Sec 7.15.2, para 2 is not clear whethe= r the XML hierarchy
has to exist in any particular datastore (or = opstate).
Since there is no mention of datastores in 7.15, I
assume the text just refers to the input containing=C2=A0
s= chema-valid XML, which may or may not correspond
to actual data i= nstances somewhere inn the server.


=
Andy

--001a11c23682533cea0528b609e5-- From nobody Thu Jan 7 00:23:45 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 536D01A8797; Thu, 7 Jan 2016 00:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_T77WPeDEzr; Thu, 7 Jan 2016 00:23:41 -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 BDC2A1A8752; Thu, 7 Jan 2016 00:23:40 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C0908784; Thu, 7 Jan 2016 09:23:38 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id OpyQZX8lgelv; Thu, 7 Jan 2016 09:23: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, 7 Jan 2016 09:23:38 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E33C82005C; Thu, 7 Jan 2016 09:23:37 +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 OgIcAb7qpMO1; Thu, 7 Jan 2016 09:23: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 922E820058; Thu, 7 Jan 2016 09:23:36 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 81229397D1C7; Thu, 7 Jan 2016 09:23:36 +0100 (CET) Date: Thu, 7 Jan 2016 09:23:36 +0100 From: Juergen Schoenwaelder To: Dean Bogdanovic Message-ID: <20160107082336.GA27362@elstar.local> Mail-Followup-To: Dean Bogdanovic , Eliot Lear , Nadeau Thomas , Benoit Claise , RTG YANG Design Team , netmod WG References: <20151211113156.GA43862@elstar.local> <2059AD77-5375-4DB0-A1BF-432835F11A9F@gmail.com> <20151221153312.GA43316@elstar.local> <568AB8AA.8070404@cisco.com> <20160106093026.GB25431@elstar.local> <509C88A7-5F33-4CF2-BE5B-284F180F0FEC@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: <509C88A7-5F33-4CF2-BE5B-284F180F0FEC@gmail.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: RTG YANG Design Team , netmod WG , Benoit Claise Subject: Re: [netmod] [Rtg-dt-yang-arch] [yang-doctors] Working group Last Call: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 08:23:43 -0000 On Wed, Jan 06, 2016 at 06:28:41PM +0100, Dean Bogdanovic wrote: > > > On Jan 6, 2016, at 10:30 AM, Juergen Schoenwaelder wrote: > > > > On Mon, Jan 04, 2016 at 07:23:38PM +0100, Eliot Lear wrote: > >> Hi Juergen, > >> > >> On this point: > >> > >> On 12/21/15 4:33 PM, Juergen Schoenwaelder wrote: > >> > >>> And > >>> should the interface reference not use a more specific type than > >>> 'string’? > >>>> Interface references can be many things, from standard naming we are familiar, e.g. ge-1/0/0.1 to a numerical value like 13276. Leaving it as string gives us most flexibility in that regards. > >>> I disagree that the goal here is most flexibility. We do have an > >>> interfaces data model in the IETF. Why are we avoiding to refer to it > >>> here? > >>> > >> > >> I think it would be helpful if you could be specific as to your > >> concern. It is absolutely the case that the SNMP folk did an awful lot > >> of work on managing interfaces. While I am not concerned about the form > >> of the name, I wonder if your concern is around some of the semantics, > >> but I can't tell. > >> > > > > My question is why the model does not use interface-ref or > > interface-state-ref defined in RFC 7223 but instead an opaque string > > to refer to an interface. Have we thought about the design tradeoffs? > > > > My question is _not_ about how we deal with interface naming schemes, > > that discussion took place when RFC 7223 was created. > > In the example where the ACL is attached to the interface, we are using interface-ref, so replacing interface in the metadata, can be easily done. > This does not answer why input-interface is of type string... I do not understand what 'replacing interface in the metadata, can be easily done' tells me. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jan 7 00:59:06 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B389F1A87CE; Thu, 7 Jan 2016 00:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNSjnZiIouZI; Thu, 7 Jan 2016 00:59:04 -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 271DC1A87C7; Thu, 7 Jan 2016 00:59:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1142; q=dns/txt; s=iport; t=1452157144; x=1453366744; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=75DLBwt8CB/h0gRZyHH1Wh4O/5iYfid9cTL3adTluIM=; b=i2KTqk+YV0PdtPkWCmzOEzY7cUqWLTFKUyg6L/Ed+wlv+Jug5/lcNGAl 4Ax9OFajW5NwUu0aAfVLrEQQXPGuGCyqL5WVxlACWvIdkqSTF0vo4Nj+p PeHJTtoP5c3JCUH034EAXXg1JRix5lG1TBPWiTZH5JLN1g4/2Sxpmqmm6 4=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B6AgCFJ45W/xbLJq1ejVKzUg6BZIYPA?= =?us-ascii?q?oFaFAEBAQEBAQGBCoQ1AQEEI1URCw4KCRYEBwICCQMCAQIBRQYBDAgBAYgrsG2?= =?us-ascii?q?QXwEBAQEBAQEDAQEBAQEBARMJi1WHc4FJAQSXC4JzgWWIfYkmhVSOSyABQ4JKg?= =?us-ascii?q?UE9hhUBAQE?= X-IronPort-AV: E=Sophos;i="5.20,532,1444694400"; d="asc'?scan'208";a="648318289" 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; 07 Jan 2016 08:59:02 +0000 Received: from [10.61.64.178] (ams3-vpn-dhcp178.cisco.com [10.61.64.178]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u078x2AB021787; Thu, 7 Jan 2016 08:59:02 GMT To: Dean Bogdanovic , Nadeau Thomas , Benoit Claise , RTG YANG Design Team , netmod WG References: <20151211113156.GA43862@elstar.local> <2059AD77-5375-4DB0-A1BF-432835F11A9F@gmail.com> <20151221153312.GA43316@elstar.local> <568AB8AA.8070404@cisco.com> <20160106093026.GB25431@elstar.local> <509C88A7-5F33-4CF2-BE5B-284F180F0FEC@gmail.com> <20160107082336.GA27362@elstar.local> From: Eliot Lear Message-ID: <568E28D5.6070109@cisco.com> Date: Thu, 7 Jan 2016 09:59:01 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160107082336.GA27362@elstar.local> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OsJa8tFM53PB3WW1bkTGLUNSpW64bcOLw" Archived-At: Subject: Re: [netmod] [Rtg-dt-yang-arch] [yang-doctors] Working group Last Call: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 08:59:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OsJa8tFM53PB3WW1bkTGLUNSpW64bcOLw Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 1/7/16 9:23 AM, Juergen Schoenwaelder wrote: > This does not answer why input-interface is of type string... To be perfectly clear you seek that type string be replaced with interface-ref? Eliot --OsJa8tFM53PB3WW1bkTGLUNSpW64bcOLw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJWjijVAAoJEIe2a0bZ0nozo9gH/0IhfucA2bouFxEJKLMgWIR/ fc1tFVKPc4RwbZCbxdXl/Kvg92bAm5feQ3lx8PNRTptqPUgOBTPquVW9QXpJz4VB YesaNmpqNQ4wXpZOMibxqTSkOTcd8UDEZZcfa6j8MBMErkS1ouBO7w/R/Ga6Gkuc AECE+w/WfgNUz1kSoRIf7uoMrOGfQLy1u/Gu7YYPYzxBpUKRVmhYY9JI+tm7drrX Hy5JiA4i2bBKbB+51BEL9gSTlkxdnLwocTHD63Wi2101wrO846Oh8h8WPUfnoMF/ ciKu53JuN1AheVn3mB/mtNGu7R69pvfWRlEZbOJ9jm8fg3TNdRQjl/IefM/tLMw= =Zb68 -----END PGP SIGNATURE----- --OsJa8tFM53PB3WW1bkTGLUNSpW64bcOLw-- From nobody Thu Jan 7 01:07:23 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 734F41A87E7; Thu, 7 Jan 2016 01:07:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwQkPYMmKNd6; Thu, 7 Jan 2016 01:07: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 238781A87E3; Thu, 7 Jan 2016 01:07: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 E0903E89; Thu, 7 Jan 2016 10:07:19 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id WGFMNWSpy8Li; Thu, 7 Jan 2016 10:07:19 +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, 7 Jan 2016 10:07:19 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id ECA982005E; Thu, 7 Jan 2016 10:07:18 +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 MMoJmshi01R9; Thu, 7 Jan 2016 10:07:18 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8B8B920056; Thu, 7 Jan 2016 10:07:17 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 562BB397D235; Thu, 7 Jan 2016 10:07:16 +0100 (CET) Date: Thu, 7 Jan 2016 10:07:15 +0100 From: Juergen Schoenwaelder To: Eliot Lear Message-ID: <20160107090713.GA27458@elstar.local> Mail-Followup-To: Eliot Lear , Dean Bogdanovic , Nadeau Thomas , Benoit Claise , RTG YANG Design Team , netmod WG References: <20151211113156.GA43862@elstar.local> <2059AD77-5375-4DB0-A1BF-432835F11A9F@gmail.com> <20151221153312.GA43316@elstar.local> <568AB8AA.8070404@cisco.com> <20160106093026.GB25431@elstar.local> <509C88A7-5F33-4CF2-BE5B-284F180F0FEC@gmail.com> <20160107082336.GA27362@elstar.local> <568E28D5.6070109@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <568E28D5.6070109@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Benoit Claise , RTG YANG Design Team , netmod WG Subject: Re: [netmod] [yang-doctors] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 09:07:22 -0000 On Thu, Jan 07, 2016 at 09:59:01AM +0100, Eliot Lear wrote: > > > On 1/7/16 9:23 AM, Juergen Schoenwaelder wrote: > > This does not answer why input-interface is of type string... > > To be perfectly clear you seek that type string be replaced with > interface-ref? > I think for this leaf the type of choice would be interface-state-ref unless there are strong reasons to use something opaque. /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 7 01:16:51 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC5181A8826; Thu, 7 Jan 2016 01:16:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lkyDXSlA6DO; Thu, 7 Jan 2016 01:16:46 -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 A18781A8821; Thu, 7 Jan 2016 01:16:46 -0800 (PST) Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:22] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:22]) by mail.nic.cz (Postfix) with ESMTPSA id 38781181AE0; Thu, 7 Jan 2016 10:16:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452158204; bh=LsrnPvHeSutybLYAGHgPbQwZtB45v6o7Yb3p0YY6cCQ=; h=From:Date:To; b=KDxo7zwBqecXpL3WzoXaA88btgHvlaO7n5M2WTEm7fVnVjsHBB9wxcwHuXZHdcKvT EBatIoat5mrsRj9u6MJVlUOCH9J275yy0JZK/V3Usz8xsOZ23LZCi920HhDWonJpxP yAVOnfxl6ONxYNB3PxwL3agLBLZxBtSnE70h8d1Y= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160107090713.GA27458@elstar.local> Date: Thu, 7 Jan 2016 10:16:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1E1ECFB7-7A6E-47EB-A375-3E565B15D38D@nic.cz> References: <20151211113156.GA43862@elstar.local> <2059AD77-5375-4DB0-A1BF-432835F11A9F@gmail.com> <20151221153312.GA43316@elstar.local> <568AB8AA.8070404@cisco.com> <20160106093026.GB25431@elstar.local> <509C88A7-5F33-4CF2-BE5B-284F180F0FEC@gmail.com> <20160107082336.GA27362@elstar.local> <568E28D5.6070109@cisco.com> <20160107090713.GA27458@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Benoit Claise , RTG YANG Design Team , netmod WG Subject: Re: [netmod] [yang-doctors] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 09:16:50 -0000 > On 07 Jan 2016, at 10:07, Juergen Schoenwaelder = wrote: >=20 > On Thu, Jan 07, 2016 at 09:59:01AM +0100, Eliot Lear wrote: >>=20 >>=20 >> On 1/7/16 9:23 AM, Juergen Schoenwaelder wrote: >>> This does not answer why input-interface is of type string... >>=20 >> To be perfectly clear you seek that type string be replaced with >> interface-ref? >>=20 >=20 > I think for this leaf the type of choice would be interface-state-ref > unless there are strong reasons to use something opaque. Unfortunately, this is impossible because configuration leafrefs cannot = refer to leafs in state data. Should this CLR be removed? IMO, yes. 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 > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jan 7 01:24:50 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A93371A8831; Thu, 7 Jan 2016 01:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvEryspvSOAA; Thu, 7 Jan 2016 01:24:46 -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 1C9951A882F; Thu, 7 Jan 2016 01:24:46 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DF8E011D9; Thu, 7 Jan 2016 10:24:44 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Axm6W5LC1P8y; Thu, 7 Jan 2016 10:24:44 +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, 7 Jan 2016 10:24:44 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 34CFD20056; Thu, 7 Jan 2016 10:24:44 +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 uOgdmJdxA-5M; Thu, 7 Jan 2016 10:24:43 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3B56920055; Thu, 7 Jan 2016 10:24:43 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2F687397D2CF; Thu, 7 Jan 2016 10:24:43 +0100 (CET) Date: Thu, 7 Jan 2016 10:24:43 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20160107092443.GC27458@elstar.local> Mail-Followup-To: Ladislav Lhotka , Eliot Lear , Benoit Claise , RTG YANG Design Team , netmod WG References: <20151211113156.GA43862@elstar.local> <2059AD77-5375-4DB0-A1BF-432835F11A9F@gmail.com> <20151221153312.GA43316@elstar.local> <568AB8AA.8070404@cisco.com> <20160106093026.GB25431@elstar.local> <509C88A7-5F33-4CF2-BE5B-284F180F0FEC@gmail.com> <20160107082336.GA27362@elstar.local> <568E28D5.6070109@cisco.com> <20160107090713.GA27458@elstar.local> <1E1ECFB7-7A6E-47EB-A375-3E565B15D38D@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1E1ECFB7-7A6E-47EB-A375-3E565B15D38D@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Benoit Claise , RTG YANG Design Team , netmod WG Subject: Re: [netmod] [yang-doctors] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 09:24:48 -0000 On Thu, Jan 07, 2016 at 10:16:43AM +0100, Ladislav Lhotka wrote: > > > On 07 Jan 2016, at 10:07, Juergen Schoenwaelder wrote: > > > > On Thu, Jan 07, 2016 at 09:59:01AM +0100, Eliot Lear wrote: > >> > >> > >> On 1/7/16 9:23 AM, Juergen Schoenwaelder wrote: > >>> This does not answer why input-interface is of type string... > >> > >> To be perfectly clear you seek that type string be replaced with > >> interface-ref? > >> > > > > I think for this leaf the type of choice would be interface-state-ref > > unless there are strong reasons to use something opaque. > > Unfortunately, this is impossible because configuration leafrefs cannot refer to leafs in state data. > The problem is that the config true on input-interface is perhaps an error given the description: leaf input-interface { type string; description "Packet was received on this interface."; } This sounds to me like state data. > Should this CLR be removed? IMO, yes. No. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jan 7 01:26:53 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A164B1A882F; Thu, 7 Jan 2016 01:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOz9sVU4-vCs; Thu, 7 Jan 2016 01:26: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 530A41A8833; Thu, 7 Jan 2016 01:26:48 -0800 (PST) Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:22] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:22]) by mail.nic.cz (Postfix) with ESMTPSA id E354D181B19; Thu, 7 Jan 2016 10:26:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452158807; bh=ZpxU97YFrb04zKZeP4mpl1ao2i7j1Gzei4osCsi+ito=; h=From:Date:To; b=rj2jU1RsmVBPmAJAymG+mMRg1tjI4rLWtFrxcXjbQT1n1Zdo40jZDhJX5PpTdL+wZ Xz/V+NUqxHxLwGYkqvwkJhsvyMT+40/zvF4leBpvutMVNdgcAteDswlxh1FbsCqZ9U czvvA1puOrpVVIEE3JacF4gL4tkJ3t1a3dVPGvN4= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160107092443.GC27458@elstar.local> Date: Thu, 7 Jan 2016 10:26:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151211113156.GA43862@elstar.local> <2059AD77-5375-4DB0-A1BF-432835F11A9F@gmail.com> <20151221153312.GA43316@elstar.local> <568AB8AA.8070404@cisco.com> <20160106093026.GB25431@elstar.local> <509C88A7-5F33-4CF2-BE5B-284F180F0FEC@gmail.com> <20160107082336.GA27362@elstar.local> <568E28D5.6070109@cisco.com> <20160107090713.GA27458@elstar.local> <1E1ECFB7-7A6E-47EB-A375-3E565B15D38D@nic.cz> <20160107092443.GC27458@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Benoit Claise , RTG YANG Design Team , netmod WG Subject: Re: [netmod] [yang-doctors] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 09:26:49 -0000 > On 07 Jan 2016, at 10:24, Juergen Schoenwaelder = wrote: >=20 > On Thu, Jan 07, 2016 at 10:16:43AM +0100, Ladislav Lhotka wrote: >>=20 >>> On 07 Jan 2016, at 10:07, Juergen Schoenwaelder = wrote: >>>=20 >>> On Thu, Jan 07, 2016 at 09:59:01AM +0100, Eliot Lear wrote: >>>>=20 >>>>=20 >>>> On 1/7/16 9:23 AM, Juergen Schoenwaelder wrote: >>>>> This does not answer why input-interface is of type string... >>>>=20 >>>> To be perfectly clear you seek that type string be replaced with >>>> interface-ref? >>>>=20 >>>=20 >>> I think for this leaf the type of choice would be = interface-state-ref >>> unless there are strong reasons to use something opaque. >>=20 >> Unfortunately, this is impossible because configuration leafrefs = cannot refer to leafs in state data. >>=20 >=20 > The problem is that the config true on input-interface is perhaps an > error given the description: >=20 > leaf input-interface { > type string; > description > "Packet was received on this interface."; > } >=20 > This sounds to me like state data. As I understand it, it is a match condition for a received packet, i.e. = configuration. Lada >=20 >> Should this CLR be removed? IMO, yes. >=20 > No. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jan 7 01:30:05 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDD61A883C; Thu, 7 Jan 2016 01:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4U6LQzEvU0n; Thu, 7 Jan 2016 01:30: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 948CA1A882F; Thu, 7 Jan 2016 01:30: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 623C1145B; Thu, 7 Jan 2016 10:29:59 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id c5bfcx9JRKGP; Thu, 7 Jan 2016 10:29: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, 7 Jan 2016 10:29:58 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8E15C20056; Thu, 7 Jan 2016 10:29:58 +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 9gdGzVWXZfk4; Thu, 7 Jan 2016 10:29:57 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E24E420055; Thu, 7 Jan 2016 10:29:56 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1E5A7397D31C; Thu, 7 Jan 2016 10:29:55 +0100 (CET) Date: Thu, 7 Jan 2016 10:29:55 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20160107092953.GD27458@elstar.local> Mail-Followup-To: Ladislav Lhotka , Eliot Lear , Benoit Claise , RTG YANG Design Team , netmod WG References: <20151221153312.GA43316@elstar.local> <568AB8AA.8070404@cisco.com> <20160106093026.GB25431@elstar.local> <509C88A7-5F33-4CF2-BE5B-284F180F0FEC@gmail.com> <20160107082336.GA27362@elstar.local> <568E28D5.6070109@cisco.com> <20160107090713.GA27458@elstar.local> <1E1ECFB7-7A6E-47EB-A375-3E565B15D38D@nic.cz> <20160107092443.GC27458@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Benoit Claise , RTG YANG Design Team , netmod WG Subject: Re: [netmod] [yang-doctors] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 09:30:02 -0000 On Thu, Jan 07, 2016 at 10:26:45AM +0100, Ladislav Lhotka wrote: > > > On 07 Jan 2016, at 10:24, Juergen Schoenwaelder wrote: > > > > On Thu, Jan 07, 2016 at 10:16:43AM +0100, Ladislav Lhotka wrote: > >> > >>> On 07 Jan 2016, at 10:07, Juergen Schoenwaelder wrote: > >>> > >>> On Thu, Jan 07, 2016 at 09:59:01AM +0100, Eliot Lear wrote: > >>>> > >>>> > >>>> On 1/7/16 9:23 AM, Juergen Schoenwaelder wrote: > >>>>> This does not answer why input-interface is of type string... > >>>> > >>>> To be perfectly clear you seek that type string be replaced with > >>>> interface-ref? > >>>> > >>> > >>> I think for this leaf the type of choice would be interface-state-ref > >>> unless there are strong reasons to use something opaque. > >> > >> Unfortunately, this is impossible because configuration leafrefs cannot refer to leafs in state data. > >> > > > > The problem is that the config true on input-interface is perhaps an > > error given the description: > > > > leaf input-interface { > > type string; > > description > > "Packet was received on this interface."; > > } > > > > This sounds to me like state data. > > As I understand it, it is a match condition for a received packet, i.e. configuration. > Maybe that is true but then the description is rather misleading. /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 7 01:36:05 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918001A8848; Thu, 7 Jan 2016 01:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNrDA70-Usi7; Thu, 7 Jan 2016 01:36:00 -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 6E5771A8847; Thu, 7 Jan 2016 01:35:59 -0800 (PST) Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:22] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:22]) by mail.nic.cz (Postfix) with ESMTPSA id 27C42180C2B; Thu, 7 Jan 2016 10:35:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452159358; bh=3m6tGA63CpfmZ8L5sizJyVC7/o84BRbzLDznC/K2GzQ=; h=From:Date:To; b=TdKmsBR63rJyuFpdsj/xQiWG3hBlfpkVX7fYVLPtU5VjlcebxCxhqjzMZ6ohPty/H 2CUbDGDkvakfXOcMeeTpqTbR6Efh0WTyrpqtBPBwOYr4MW7MBldu2h2h5LnUfKoyqW 8Fiu8VgBUWdvFKdqZHnGQ/JWuZSDaK+UqHXv2vNs= Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_AF88274B-A5C7-4308-9882-4B646BE5C351"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 From: Ladislav Lhotka In-Reply-To: <568E28D5.6070109@cisco.com> Date: Thu, 7 Jan 2016 10:35:56 +0100 Message-Id: References: <20151211113156.GA43862@elstar.local> <2059AD77-5375-4DB0-A1BF-432835F11A9F@gmail.com> <20151221153312.GA43316@elstar.local> <568AB8AA.8070404@cisco.com> <20160106093026.GB25431@elstar.local> <509C88A7-5F33-4CF2-BE5B-284F180F0FEC@gmail.com> <20160107082336.GA27362@elstar.local> <568E28D5.6070109@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Benoit Claise , RTG YANG Design Team , netmod WG Subject: Re: [netmod] [Rtg-dt-yang-arch] [yang-doctors] Working group Last Call: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 09:36:01 -0000 --Apple-Mail=_AF88274B-A5C7-4308-9882-4B646BE5C351 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 07 Jan 2016, at 09:59, Eliot Lear wrote: >=20 >=20 >=20 > On 1/7/16 9:23 AM, Juergen Schoenwaelder wrote: >> This does not answer why input-interface is of type string... >=20 > To be perfectly clear you seek that type string be replaced with > interface-ref? This would be somewhat awkward for interfaces for which no configuration = exist - a dummy configuration entry would need to be created. This might = have been the reason why the authors chose a simple string. The same = problem appears elsewhere, too. Lada >=20 > Eliot >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C --Apple-Mail=_AF88274B-A5C7-4308-9882-4B646BE5C351 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlaOMX0ACgkQWQVCj+dOjAwq9QCgn+tdKukYVgmoLFeDWDffcPmZ eEQAn1C9/ggVkoyFYU4Eez91cxQaYHuW =wExM -----END PGP SIGNATURE----- --Apple-Mail=_AF88274B-A5C7-4308-9882-4B646BE5C351-- From nobody Thu Jan 7 02:20:20 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16DCD1A033B for ; Thu, 7 Jan 2016 02:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdbwSYGdO33Y for ; Thu, 7 Jan 2016 02:20:17 -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 67C181A0302 for ; Thu, 7 Jan 2016 02:20:17 -0800 (PST) Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:22] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:22]) by mail.nic.cz (Postfix) with ESMTPSA id A040C181A00 for ; Thu, 7 Jan 2016 11:20:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452162015; bh=2pEw33JSr6hkOFCnf6ewNAK8CyzpUYUPyvwInEQvJq0=; h=From:Date:To; b=kqknkrX27FgLReRfG8lzqYtX5gX7nG8hLeqWpaXDMabI72SSc3latrIoEwfHozRYT XHI2uwd7lNDe6zbAr2KI+EWrGfGqYm/hPgiqzZL08hS2cdKgeOz51CBTVSj49pJlot uVHJH8Ru6/769MKAHKMywrwJifkQoDfyLy229bvs= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> Date: Thu, 7 Jan 2016 11:20:14 +0100 To: NETMOD WG Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Subject: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 10:20:19 -0000 Hi, a good use of applied configuration could be to formalize the concept of = system-controlled entries as defined in RFC 7223, routing-cfg, and = probably elsewhere, too. My idea is that system-controlled interfaces or other entries would = appear in applied configuration, but not in intended configuration until = something needs to be really configured. We could then permit leafrefs = from intended configuration to refer to leafs in applied configuration. = One case where this would be useful is the ACL module, where match = conditions refering to interfaces currently have to use plain strings as = references to interface names. However, the above idea seems to be at odds with requirement 1D in = opstate-reqs-02. I wonder: could that requirement be relaxed or removed = so that the above use case can be supported? Thanks, Lada =20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Jan 7 06:23:20 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C382A1A8A9B; Thu, 7 Jan 2016 06:23:18 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVtn_JBLClxj; Thu, 7 Jan 2016 06:23:17 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c: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 62EF31A8A97; Thu, 7 Jan 2016 06:23:17 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id f206so125872782wmf.0; Thu, 07 Jan 2016 06:23:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tWfVx9RQ0eHtf8HrtcZuz0O+yEZBuTTyirINZycq6jQ=; b=J83eMhQWC38EQbVsH7F0JkgX8uxI3A1h0jh5f2/66iJl07CWMypwD0C+pTp2ekyvVO x1i2BE2uyOqEfb25AwHberrsWgHhhknkuTZSnXBM4nQzRl3HGmtjj6r8rfPw84pKqiHW 1QV5VpUMpFyfcV9EQyYCniegHMc5gRYEvy9ghrHrdfLDYyGtCGBwfLgayMRXgqF1pSFU BVKJSv6eZDclGSGIXEXqgwfep8EWOWobARfxy7ytbnqe0JiXxo7F234uE3btmrwY3iQp 8DzVIUTciioX7RRTgNAl2ainMmlOMbT8dIQ06EyvSTIusZlq7p7mrl2atplJLKVTSPHI PIbA== X-Received: by 10.28.20.83 with SMTP id 80mr17803301wmu.89.1452176595955; Thu, 07 Jan 2016 06:23:15 -0800 (PST) Received: from [192.168.254.207] ([147.83.206.82]) by smtp.gmail.com with ESMTPSA id t3sm101121602wjz.11.2016.01.07.06.23.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 07 Jan 2016 06:23:15 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dean Bogdanovic In-Reply-To: <20160107090713.GA27458@elstar.local> Date: Thu, 7 Jan 2016 15:23:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151211113156.GA43862@elstar.local> <2059AD77-5375-4DB0-A1BF-432835F11A9F@gmail.com> <20151221153312.GA43316@elstar.local> <568AB8AA.8070404@cisco.com> <20160106093026.GB25431@elstar.local> <509C88A7-5F33-4CF2-BE5B-284F180F0FEC@gmail.com> <20160107082336.GA27362@elstar.local> <568E28D5.6070109@cisco.com> <20160107090713.GA27458@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3112) Archived-At: Cc: RTG YANG Design Team , netmod WG , Benoit Claise Subject: Re: [netmod] [yang-doctors] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 14:23:18 -0000 > On Jan 7, 2016, at 10:07 AM, Juergen Schoenwaelder = wrote: >=20 > On Thu, Jan 07, 2016 at 09:59:01AM +0100, Eliot Lear wrote: >>=20 >>=20 >> On 1/7/16 9:23 AM, Juergen Schoenwaelder wrote: >>> This does not answer why input-interface is of type string... >>=20 >> To be perfectly clear you seek that type string be replaced with >> interface-ref? >>=20 >=20 > I think for this leaf the type of choice would be interface-state-ref > unless there are strong reasons to use something opaque. We interface-state-ref, the interface has to exists. With interface-ref, = the interface doesn=E2=80=99t have to exists in order for the = configuration to be committed. So if you reference to something opaque = is that interface doesn=E2=80=99t necessarily exist, then this is what = we wanted to achieve.= From nobody Thu Jan 7 06:36:07 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95FC1A8ABE; Thu, 7 Jan 2016 06:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lI6S9PtkDKnf; Thu, 7 Jan 2016 06:35:58 -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 802E31A8ABD; Thu, 7 Jan 2016 06:35:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1385; q=dns/txt; s=iport; t=1452177358; x=1453386958; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=9X4ncTD2tmuE0G/LKS623qhFc0udWt1Y4AQ+TyRho0s=; b=Rz0vpLgKvDFkx0zA8GyqDaFJscK1v4eGcbEqYgkvLwjzetdD06P19dKy NdIcyuZIse4DgepaJuG9CACY3LTocNM6TXX2GTc+q+oSTpx+7UKjtKOZ2 9h2iTJPmFfiu/uMlG72rSB9OLFGdULHxhd12qSmjQX4rEOoYowCnuosYn g=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B6AgBmd45W/xbLJq1ejVKzVQ6BZIYPA?= =?us-ascii?q?oFZFAEBAQEBAQGBCoQ1AQEEI1URCxgJFgQHAgIJAwIBAgFFBgEMCAEBiCuxJpB?= =?us-ascii?q?mAQEBAQEBAQMBAQEBAQEBEwmLVYdzgUkBBJcLgnOBZYh+iSaFVY5NIAFDgkqBQ?= =?us-ascii?q?T2GFQEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,533,1444694400"; d="asc'?scan'208";a="648327751" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jan 2016 14:35:44 +0000 Received: from [10.61.199.49] ([10.61.199.49]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u07EZiKM014549; Thu, 7 Jan 2016 14:35:44 GMT To: Ladislav Lhotka , Benoit Claise , RTG YANG Design Team , netmod WG References: <20151221153312.GA43316@elstar.local> <568AB8AA.8070404@cisco.com> <20160106093026.GB25431@elstar.local> <509C88A7-5F33-4CF2-BE5B-284F180F0FEC@gmail.com> <20160107082336.GA27362@elstar.local> <568E28D5.6070109@cisco.com> <20160107090713.GA27458@elstar.local> <1E1ECFB7-7A6E-47EB-A375-3E565B15D38D@nic.cz> <20160107092443.GC27458@elstar.local> <20160107092953.GD27458@elstar.local> From: Eliot Lear Message-ID: <568E77C0.4010104@cisco.com> Date: Thu, 7 Jan 2016 15:35:44 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160107092953.GD27458@elstar.local> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XCo3pAn7rSpiS44HM2tknlDNQaXPQl6ge" Archived-At: Subject: Re: [netmod] [yang-doctors] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 14:36:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XCo3pAn7rSpiS44HM2tknlDNQaXPQl6ge Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 1/7/16 10:29 AM, Juergen Schoenwaelder wrote: > On Thu, Jan 07, 2016 at 10:26:45AM +0100, Ladislav Lhotka wrote: >> As I understand it, it is a match condition for a received packet, >> i.e. configuration.=20 > Maybe that is true but then the description is rather misleading. > > I agree that is configuration information and that the wording is imperfect. How about this: "Interface upon which a packet is received." Eliot --XCo3pAn7rSpiS44HM2tknlDNQaXPQl6ge Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJWjnfAAAoJEIe2a0bZ0nozFsMH/R+ux89ZwwQ2SAymLecJ4rOM V55RIEStUKerFrI85kjQ4q3Ixkt+T+m6fcf3uWq+t2X2xv6Z1NNfOvsEfap0tyZL fA01pHIXgnniJcLzyPZpV9YaRIVuhQmH0TlBpiHyiJpPxCRSdqOOdv7ELzDsh/da UgFIcH0t57NCcm55m8XcprG7Dm5Qhg5WXFscTzKPP9Att3RTCHIhJXlAuf2wVHgr OabfY6/04V904zEl41FFbGUEY/nd7dskVoMq8X9sXZYt9w4K/Dpq5dOydHZ3GIxM xikofPd2Uxmnouxl8WFhhIUZlj/CmRnO1VxURxWL+MHTIXkhyzy942dfuR244+0= =GsU8 -----END PGP SIGNATURE----- --XCo3pAn7rSpiS44HM2tknlDNQaXPQl6ge-- From nobody Thu Jan 7 07:21:48 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7FB1A8BBD; Thu, 7 Jan 2016 07:21:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQVovTjmiPke; Thu, 7 Jan 2016 07:21:42 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4021A8BB6; Thu, 7 Jan 2016 07:21:42 -0800 (PST) Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id 433091AE0A3A; Thu, 7 Jan 2016 16:21:40 +0100 (CET) Date: Thu, 07 Jan 2016 16:21:42 +0100 (CET) Message-Id: <20160107.162142.1102381710329032385.mbj@tail-f.com> To: ivandean@gmail.com From: Martin Bjorklund In-Reply-To: References: <568E28D5.6070109@cisco.com> <20160107090713.GA27458@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: yang-doctors@ietf.org, rtg-dt-yang-arch@ietf.org, netmod@ietf.org Subject: Re: [netmod] [yang-doctors] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 15:21:43 -0000 RGVhbiBCb2dkYW5vdmljIDxpdmFuZGVhbkBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gPiBPbiBK YW4gNywgMjAxNiwgYXQgMTA6MDcgQU0sIEp1ZXJnZW4gU2Nob2Vud2FlbGRlcg0KPiA+IDxqLnNj aG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0KPiA+IA0KPiA+IE9uIFRo dSwgSmFuIDA3LCAyMDE2IGF0IDA5OjU5OjAxQU0gKzAxMDAsIEVsaW90IExlYXIgd3JvdGU6DQo+ ID4+IA0KPiA+PiANCj4gPj4gT24gMS83LzE2IDk6MjMgQU0sIEp1ZXJnZW4gU2Nob2Vud2FlbGRl ciB3cm90ZToNCj4gPj4+IFRoaXMgZG9lcyBub3QgYW5zd2VyIHdoeSBpbnB1dC1pbnRlcmZhY2Ug aXMgb2YgdHlwZSBzdHJpbmcuLi4NCj4gPj4gDQo+ID4+IFRvIGJlIHBlcmZlY3RseSBjbGVhciB5 b3Ugc2VlayB0aGF0IHR5cGUgc3RyaW5nIGJlIHJlcGxhY2VkIHdpdGgNCj4gPj4gaW50ZXJmYWNl LXJlZj8NCj4gPj4gDQo+ID4gDQo+ID4gSSB0aGluayBmb3IgdGhpcyBsZWFmIHRoZSB0eXBlIG9m IGNob2ljZSB3b3VsZCBiZSBpbnRlcmZhY2Utc3RhdGUtcmVmDQo+ID4gdW5sZXNzIHRoZXJlIGFy ZSBzdHJvbmcgcmVhc29ucyB0byB1c2Ugc29tZXRoaW5nIG9wYXF1ZS4NCj4gDQo+IFdlIGludGVy ZmFjZS1zdGF0ZS1yZWYsIHRoZSBpbnRlcmZhY2UgaGFzIHRvIGV4aXN0cy4NCg0KV2l0aCBZQU5H IDEuMSwgYSBsZWFmcmVmIGNhbiBiZSBtYXJrZWQgYXMgInJlcXVpcmUtaW5zdGFuY2UgZmFsc2Ui LA0Kd2hpY2ggYWxsb3dzIGEgaW50ZXJmYWNlLXN0YXRlLXJlZiB0byBiZSB1c2VkIGluIGNvbmZp ZzoNCg0KICAgdHlwZSBpZjppbnRlcmZhY2Utc3RhdGUtcmVmIHsNCiAgICAgcmVxdWlyZS1pbnN0 YW5jZSBmYWxzZTsNCiAgIH0NCiAgIC8vICsgYWRkIGRlc2NyaXB0aW9uIHRoYXQgZXhwbGFpbnMg d2hhdCBoYXBwZW5zIGlmIHRoZXJlIGlzIG5vIHN1Y2gNCiAgIC8vICAgaW5zdGFuY2UNCg0KDQoo Tk9URTogdGhpcyBkb2Vzbid0IHdvcmsgdy8gcHlhbmcgYXQgdGhlIG1vbWVtZW50LCBJIGFtIHdv cmtpbmcgb24gYQ0KZml4KQ0KDQoNCi9tYXJ0aW4NCg0KPiBXaXRoDQo+IGludGVyZmFjZS1yZWYs IHRoZSBpbnRlcmZhY2UgZG9lc27igJl0IGhhdmUgdG8gZXhpc3RzIGluIG9yZGVyIGZvciB0aGUN Cj4gY29uZmlndXJhdGlvbiB0byBiZSBjb21taXR0ZWQuIFNvIGlmIHlvdSByZWZlcmVuY2UgdG8g c29tZXRoaW5nIG9wYXF1ZQ0KPiBpcyB0aGF0IGludGVyZmFjZSBkb2VzbuKAmXQgbmVjZXNzYXJp bHkgZXhpc3QsIHRoZW4gdGhpcyBpcyB3aGF0IHdlDQo+IHdhbnRlZCB0byBhY2hpZXZlLg0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRtb2Qg bWFpbGluZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K From nobody Thu Jan 7 07:39:49 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55CF11A8F4A; Thu, 7 Jan 2016 07:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MCR-y-mAJZA; Thu, 7 Jan 2016 07:39:44 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5331A8F49; Thu, 7 Jan 2016 07:39:44 -0800 (PST) Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id 4C82F1AE0A3A; Thu, 7 Jan 2016 16:39:43 +0100 (CET) Date: Thu, 07 Jan 2016 16:39:45 +0100 (CET) Message-Id: <20160107.163945.2237345788114760828.mbj@tail-f.com> To: ivandean@gmail.com From: Martin Bjorklund In-Reply-To: <20160107.162142.1102381710329032385.mbj@tail-f.com> References: <20160107090713.GA27458@elstar.local> <20160107.162142.1102381710329032385.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: yang-doctors@ietf.org, rtg-dt-yang-arch@ietf.org, netmod@ietf.org Subject: Re: [netmod] [yang-doctors] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 15:39:45 -0000 Hi, Martin Bjorklund wrote: > With YANG 1.1, a leafref can be marked as "require-instance false", > which allows a interface-state-ref to be used in config: > > type if:interface-state-ref { > require-instance false; > } > // + add description that explains what happens if there is no such > // instance > > > (NOTE: this doesn't work w/ pyang at the momement, I am working on a > fix) FYI, I have fixed pyang now (branch yang-1.1) to allow require-instance in derived leafrefs. /martin From nobody Thu Jan 7 07:45:31 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E601A8FD3; Thu, 7 Jan 2016 07:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PokjVqBIt38; Thu, 7 Jan 2016 07:45: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 E19461A8F50; Thu, 7 Jan 2016 07:45:26 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0C02E72D; Thu, 7 Jan 2016 16:45:25 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id mCgd99s-DN1R; Thu, 7 Jan 2016 16:45:24 +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, 7 Jan 2016 16:45:24 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5EFF620056; Thu, 7 Jan 2016 16:45:24 +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 AVv-_muhsWZr; Thu, 7 Jan 2016 16:45:23 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3959520055; Thu, 7 Jan 2016 16:45:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 24EC6397D5CA; Thu, 7 Jan 2016 16:45:23 +0100 (CET) Date: Thu, 7 Jan 2016 16:45:23 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20160107154523.GB28062@elstar.local> Mail-Followup-To: Martin Bjorklund , ivandean@gmail.com, rtg-dt-yang-arch@ietf.org, netmod@ietf.org, yang-doctors@ietf.org References: <568E28D5.6070109@cisco.com> <20160107090713.GA27458@elstar.local> <20160107.162142.1102381710329032385.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160107.162142.1102381710329032385.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: rtg-dt-yang-arch@ietf.org, netmod@ietf.org, yang-doctors@ietf.org Subject: Re: [netmod] [yang-doctors] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 15:45:30 -0000 On Thu, Jan 07, 2016 at 04:21:42PM +0100, Martin Bjorklund wrote: > > With YANG 1.1, a leafref can be marked as "require-instance false", > which allows a interface-state-ref to be used in config: > > type if:interface-state-ref { > require-instance false; > } > // + add description that explains what happens if there is no such > // instance > > > (NOTE: this doesn't work w/ pyang at the momement, I am working on a > fix) > And it would have to be if:interface-ref instead if:interface-state-ref I think. /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 7 08:05:27 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D38561A9054 for ; Thu, 7 Jan 2016 08:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWrP0x1mt0rX for ; Thu, 7 Jan 2016 08:05:25 -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 632761A9053 for ; Thu, 7 Jan 2016 08:05:25 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2C5D8143A; Thu, 7 Jan 2016 17:05:24 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id u3K8tpUEALRQ; Thu, 7 Jan 2016 17:05: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; Thu, 7 Jan 2016 17:05:23 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 74CA220056; Thu, 7 Jan 2016 17:05:23 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id CaS3zR1PDq2D; Thu, 7 Jan 2016 17:05:22 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 399D720055; Thu, 7 Jan 2016 17:05:22 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2277A397D622; Thu, 7 Jan 2016 17:05:22 +0100 (CET) Date: Thu, 7 Jan 2016 17:05:21 +0100 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20160107160521.GC28062@elstar.local> Mail-Followup-To: Kent Watsen , "Acee Lindem (acee)" , "netmod@ietf.org" References: <20160104221700.28629.34622.idtracker@ietfa.amsl.com> <8A6CD12B-8B34-4F7B-83F2-E56361F998AA@juniper.net> <20160105200214.GA24262@elstar.local> <20160106063014.GA25143@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.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 16:05:27 -0000 On Wed, Jan 06, 2016 at 06:18:46PM +0000, Kent Watsen wrote: > > It’s true that the draft is largely centered around the intended/applied config notion, but not exclusively. Specifically, 4-B has "Ability to map intended config nodes to associated derived state nodes". I think that this might be the only exclusion though and, if it weren’t for it I would’ve used your title suggestion from the LC review. Should one requirement have such influence over the title is the question. I was trying to be fair to it, but maybe it's going too far. > > Regarding visibility and control, I was attempting to use common words (not normative terms) here. My intent for them is something along the lines of: > > visibility: read/understand > control: write/orchestrate > We do not write operational state. I have no clue how 'orchestrate' helps me either. What is wrong with using defined terminology in a title? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jan 7 08:43:38 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDE31A90B3 for ; Thu, 7 Jan 2016 08:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZmiRqjc6hpT for ; Thu, 7 Jan 2016 08:43:36 -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 7F5EC1A9098 for ; Thu, 7 Jan 2016 08:43:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1704; q=dns/txt; s=iport; t=1452185015; x=1453394615; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=Rk4bAyeThwK7KYzgv7PHMpK/ALIi7wPvi27Xz9ZSjcI=; b=LuWVph6dbsFy8b94fmKIjYiRWoEiMQ1ltDIzPTFnuSRsfijZAKDvGHr9 E2aur29WJmK8RN8T6yAGGSf1TTl3IH+50+ieKlnqkeTKXr1HybC8hSQ92 4kLoZ8VHtiScCoGgICOdX1nYUighIoP6UjO53sBlH1pK1bQLvZGVz6LSv 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtBADwlI5W/xbLJq1ehAxtiFm1RxgKh?= =?us-ascii?q?SNKAoFtAQEBAQEBgQuENQEBBAEBATU2ChELGAkWDwkDAgECARUwBgEMBgIBAYg?= =?us-ascii?q?rDsI+AQEBAQEBAQEBAQEBAQEBAQEBARYEhlaEf4k8AQSNOYlSjVaJJoVVjk1kh?= =?us-ascii?q?Ao+NIVhAQEB?= X-IronPort-AV: E=Sophos;i="5.20,533,1444694400"; d="scan'208";a="624342589" 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; 07 Jan 2016 16:43:32 +0000 Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u07GhW5E020538; Thu, 7 Jan 2016 16:43:32 GMT To: Ladislav Lhotka , NETMOD WG References: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> From: Robert Wilton Message-ID: <568E95B4.1070703@cisco.com> Date: Thu, 7 Jan 2016 16:43:32 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 16:43:37 -0000 Hi Lada, I think that requirement 1D is fairly key to what is being asked for here to allow both the user and system to easily relate between what the operator desires and what configuration the system is actually using, so I wouldn't be particularly keen on loosening this requirement. For the ACL example: Would it be feasible to change the ACL module to use a leafref to the interface name, with the added constraint that you have to at least configure the existence of an interface before you can have any configuration referring to it? Thanks, Rob On 07/01/2016 10:20, Ladislav Lhotka wrote: > Hi, > > a good use of applied configuration could be to formalize the concept of system-controlled entries as defined in RFC 7223, routing-cfg, and probably elsewhere, too. > > My idea is that system-controlled interfaces or other entries would appear in applied configuration, but not in intended configuration until something needs to be really configured. We could then permit leafrefs from intended configuration to refer to leafs in applied configuration. One case where this would be useful is the ACL module, where match conditions refering to interfaces currently have to use plain strings as references to interface names. > > However, the above idea seems to be at odds with requirement 1D in opstate-reqs-02. I wonder: could that requirement be relaxed or removed so that the above use case can be supported? > > Thanks, Lada > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Thu Jan 7 09:24:49 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D99C1A9104 for ; Thu, 7 Jan 2016 09:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7qf5mL9HBC9 for ; Thu, 7 Jan 2016 09:24:47 -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 D16CF1A9102 for ; Thu, 7 Jan 2016 09:24:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1736; q=dns/txt; s=iport; t=1452187487; x=1453397087; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=jiig0SIkxU7JWn6QaWMUx/T1Q5nb4QOC0030tRmm15g=; b=Qy7Lok4ZBAF9pPXvC/3jfVszQ0Pwm6DJlpVxwB5HIdZ2jPTV7WndUF1J vDraAh6zQTWxtcePh8QsfMguZeJbQYLBqx4j8QEJISmmWLL0tZ2ahaMCR K7+13qso3r1+aMmqrr1avmgIuaWVV7yOSkIX1YVfGpoYnlgamg0Kxn5xM s=; X-IronPort-AV: E=Sophos;i="5.20,533,1444694400"; d="scan'208";a="623314412" 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; 07 Jan 2016 17:24:44 +0000 Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u07HOiB4032430; Thu, 7 Jan 2016 17:24:44 GMT To: Kent Watsen , "Acee Lindem (acee)" , "netmod@ietf.org" References: <20160104221700.28629.34622.idtracker@ietfa.amsl.com> <8A6CD12B-8B34-4F7B-83F2-E56361F998AA@juniper.net> <20160105200214.GA24262@elstar.local> <20160106063014.GA25143@elstar.local> <20160107160521.GC28062@elstar.local> From: Robert Wilton Message-ID: <568E9F5D.3030500@cisco.com> Date: Thu, 7 Jan 2016 17:24:45 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160107160521.GC28062@elstar.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 17:24:48 -0000 Hi Juergen, On 07/01/2016 16:05, Juergen Schoenwaelder wrote: > On Wed, Jan 06, 2016 at 06:18:46PM +0000, Kent Watsen wrote: >> It’s true that the draft is largely centered around the intended/applied config notion, but not exclusively. Specifically, 4-B has "Ability to map intended config nodes to associated derived state nodes". I think that this might be the only exclusion though and, if it weren’t for it I would’ve used your title suggestion from the LC review. Should one requirement have such influence over the title is the question. I was trying to be fair to it, but maybe it's going too far. >> >> Regarding visibility and control, I was attempting to use common words (not normative terms) here. My intent for them is something along the lines of: >> >> visibility: read/understand >> control: write/orchestrate >> > We do not write operational state. I have no clue how 'orchestrate' > helps me either. What is wrong with using defined terminology in > a title? I don't think that using defined terminology is a problem. But I also think that the title that you have suggested seems to suggest a narrower scope that what the requirements articulate. In particular, the draft places requirements relating the configuration to the derived state (I.e. Req 4B). It also places further requirements on how management protocols are expected to handle synchronous and asynchronous config edit requests. (E.g. Req 2 A, B, C and associated definitions). I don't have a particular problem with the current title, but if you don't like visibility/control, then perhaps "Terminology and Requirements for Enhanced Handling of Operational State"? Thanks, Rob > > /js > From nobody Thu Jan 7 12:25:28 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDA01A0092 for ; Thu, 7 Jan 2016 12:25:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSKdBayR0pSE for ; Thu, 7 Jan 2016 12:25:21 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0796.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:796]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E01C1A0091 for ; Thu, 7 Jan 2016 12:25:20 -0800 (PST) Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1451.namprd05.prod.outlook.com (10.160.149.12) with Microsoft SMTP Server (TLS) id 15.1.361.13; Thu, 7 Jan 2016 20:24:58 +0000 Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.0361.006; Thu, 7 Jan 2016 20:24:58 +0000 From: Kent Watsen To: Robert Wilton , "Acee Lindem (acee)" , "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt Thread-Index: AQHRRz2lEErWj+iSeUCXhpFM5+aasZ7rnI4AgAG85wCAAAG/gIAArbcAgAByIgCAAcDigIAAFjCA///ehgA= Date: Thu, 7 Jan 2016 20:24:58 +0000 Message-ID: References: <20160104221700.28629.34622.idtracker@ietfa.amsl.com> <8A6CD12B-8B34-4F7B-83F2-E56361F998AA@juniper.net> <20160105200214.GA24262@elstar.local> <20160106063014.GA25143@elstar.local> <20160107160521.GC28062@elstar.local> <568E9F5D.3030500@cisco.com> In-Reply-To: <568E9F5D.3030500@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151105 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.12] x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1451; 5:El1IodQWxmRPo8/TNGQtrgSVW0983yynFfE1h2TODkLt1G4EaAgX1KV8CcBBMLlHW2kNmnjkdotXfr9LzT5Cipxfa80F4nf2quDELzpBBbqbgC7lwzUrrY/Dydtlud4vn67+dCDkXYeGPnDFVloo7g==; 24:oUoo4RLNnEIIP6suOjKrvA6pxKCeAUKi8HqCDadyLjCwpcqe1qawle1puj6N/QWm1oz0guZzzHMeEYcy9GS2wfAyOPRNKe9QCLRoJfcNz3U= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1451; x-ms-office365-filtering-correlation-id: 3aab6aa3-8219-4f9f-890f-08d317a09d0d x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001)(10201501046); SRVR:CY1PR0501MB1451; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1451; x-forefront-prvs: 0814A2C7A3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(24454002)(479174004)(377454003)(189002)(77096005)(2501003)(2950100001)(66066001)(4001350100001)(101416001)(76176999)(11100500001)(99286002)(5001770100001)(105586002)(2900100001)(50986999)(54356999)(83716003)(36756003)(97736004)(106356001)(19580395003)(19580405001)(83506001)(82746002)(122556002)(106116001)(92566002)(81156007)(5004730100002)(40100003)(33656002)(6116002)(1096002)(102836003)(3846002)(1220700001)(230783001)(586003)(87936001)(93886004)(5001960100002)(10400500002)(189998001)(86362001)(107886002)(5002640100001)(5008740100001)(2906002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1451; H:CY1PR0501MB1450.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:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <84CEDD7C8247F94F828892613C93F61E@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2016 20:24:58.5706 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1451 Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 20:25:27 -0000 DQoNCg0KDQoNCk9uIDEvNy8xNiwgMTI6MjQgUE0sICJSb2JlcnQgV2lsdG9uIiA8cndpbHRvbkBj aXNjby5jb20+IHdyb3RlOg0KDQo+SSBkb24ndCBoYXZlIGEgcGFydGljdWxhciBwcm9ibGVtIHdp dGggdGhlIGN1cnJlbnQgdGl0bGUsIGJ1dCBpZiB5b3UgDQo+ZG9uJ3QgbGlrZSB2aXNpYmlsaXR5 L2NvbnRyb2wsIHRoZW4gcGVyaGFwcyAiVGVybWlub2xvZ3kgYW5kIA0KPlJlcXVpcmVtZW50cyBm b3IgRW5oYW5jZWQgSGFuZGxpbmcgb2YgT3BlcmF0aW9uYWwgU3RhdGUiPw0KDQoNClRoaXMgbG9v a3MgZ29vZCB0byBtZS4gIElmIG5vIG9iamVjdGlvbnMgYXJlIHJhaXNlZCBieSB0b21vcnJvdywg SeKAmWxsIHBvc3QgLTAzIHVzaW5nIHRoaXMgdGl0bGUuDQoNCktlbnQNCg== From nobody Thu Jan 7 23:54:50 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED151ACE83 for ; Thu, 7 Jan 2016 23:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ak_Z8V6ue0PU for ; Thu, 7 Jan 2016 23:54:47 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A4B791ACE81 for ; Thu, 7 Jan 2016 23:54:47 -0800 (PST) Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id 1A4891AE047A; Fri, 8 Jan 2016 08:54:46 +0100 (CET) Date: Fri, 08 Jan 2016 08:54:47 +0100 (CET) Message-Id: <20160108.085447.1699532851849652427.mbj@tail-f.com> To: acee@cisco.com From: Martin Bjorklund In-Reply-To: References: <6AFC7C6C-61B7-4310-A0CA-08A7CD76A899@nic.cz> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 07:54:49 -0000 SGksDQoNCiJBY2VlIExpbmRlbSAoYWNlZSkiIDxhY2VlQGNpc2NvLmNvbT4gd3JvdGU6DQo+IA0K PiBPbiAxMi8yMy8xNSwgMzoyMiBBTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgTGFkaXNsYXYgTGhv dGthIg0KPiA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGxob3RrYUBuaWMu Y3o+IHdyb3RlOg0KPiANCj4gPg0KPiA+PiBPbiAyMyBEZWMgMjAxNSwgYXQgMDQ6MDYsIEtlbnQg V2F0c2VuIDxrd2F0c2VuQGp1bmlwZXIubmV0PiB3cm90ZToNCj4gPj4gDQo+ID4+IA0KPiA+PiAN Cj4gPj4gDQo+ID4+IA0KPiA+PiANCj4gPj4gT24gMTIvMjEvMTUsIDI6MjEgUE0sICJuZXRtb2Qg b24gYmVoYWxmIG9mIExhZGlzbGF2IExob3RrYSINCj4gPj48bmV0bW9kLWJvdW5jZXNAaWV0Zi5v cmcgb24gYmVoYWxmIG9mIGxob3RrYUBuaWMuY3o+IHdyb3RlOg0KPiA+PiANCj4gPj4+IA0KPiA+ Pj4+IE9uIDIxIERlYyAyMDE1LCBhdCAxOTowMiwgSnVlcmdlbiBTY2hvZW53YWVsZGVyDQo+ID4+ Pj48ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCj4gPj4+PiAN Cj4gPj4+PiBPbiBNb24sIERlYyAyMSwgMjAxNSBhdCAwNjo0Nzo0OVBNICswMTAwLCBCZW5vaXQg Q2xhaXNlIHdyb3RlOg0KPiA+Pj4+IA0KPiA+Pj4+PiBJIGhvcGUgdGhhdCBub2JvZHkgZGlzYWdy ZWVzIHRoYXQgdGhlIG9wZXJhdGlvbmFsIHN0YXRlIGRlc2lnbiBhbmQNCj4gPj4+Pj5ob3cgDQo+ ID4+Pj4+IHRvIHN0cnVjdHVyZSB0aGUgbW9kZWxzIGFyZSB0aGUgdHdvIGJsb2NraW5nIGZhY3Rv cnMgdG8gcHVibGlzaCBZQU5HDQo+ID4+Pj4+IG1vZGVscy4gSWYgeW91IGRpc2FncmVlIG9yIGRv bid0IHNlZSB0aGlzLCBsZXQgbWUga25vdywgSSBzaG91bGQNCj4gPj4+Pj4gY29tbXVuaWNhdGUg YmV0dGVyLg0KPiA+Pj4+IA0KPiA+Pj4+IEV2ZW4gaWYgaXQgbWF5IHNwb2lsIHlvdXIgZGF5LCBJ IGRpc2FncmVlIHRoYXQgdGhlcmUgaXMgYSBibG9ja2luZw0KPiA+Pj4+IGZhY3RvciB0aGF0IHNo b3VsZCBzdG9wIHVzIGZyb20gcHVibGlzaGluZyBtb2RlbHMuIFRoZXJlIHNlZW0gdG8gYmUNCj4g Pj4+PiB3YXlzIHRvIGFkZHJlc3MgdGhlIHJlcXVpcmVtZW50cyB3aXRob3V0IGhhdmluZyB0byBi bG9jayBhbGwgd29yayBvcg0KPiA+Pj4+IHRvIHJlZG8gd2hhdCB0aGF0IHdlIGhhdmUgcHVibGlz aGVkLiBCdXQgc3VyZSwgaWYgeW91IG1ha2UgaXQgYQ0KPiA+Pj4+IGJsb2NraW5nIGZhY3Rvciwg aXQgd2lsbCBiZSBvbmUuDQo+ID4+PiANCj4gPj4+IEkgYWdyZWUgd2l0aCBKdWVyZ2VuLiBJdCBp cyBub3QgY2xlYXIgdG8gbWUgaG93IHRoZSBwcm9wb3NlZCBzcGxpdA0KPiA+Pj5iZXR3ZWVuIGlu dGVuZGVkIGFuZCBhcHBsaWVkIGNvbmZpZ3VyYXRpb24gaXMgc3VwcG9zZWQgdG8gYWZmZWN0IHRo ZQ0KPiA+Pj5kYXRhIG1vZGVscyB3ZSBhcmUgd29ya2luZyBvbi4NCj4gPj4gDQo+ID4+IA0KPiA+ PiBBcyBJIHVuZGVyc3RhbmQgaXQsIHNvbHV0aW9uICMxIGFmZmVjdHMgdGhlIG1vZGVscyB0aGVt c2VsdmVzLCB3aGVyZWFzDQo+ID4+c29sdXRpb25zICMyIGFuZCAjMyBhcmUgdHJhbnNwYXJlbnQg dG8gdGhlIG1vZGVscy4NCj4gPg0KPiA+VGhlbiAjMSBsb29rcyBsaWtlIGEgbm9uLXN0YXJ0ZXIg dG8gbWUuDQo+IA0KPiBJ4oCZZCBsaWtlIHRvIHBvaW50IG91dCB0aGF0IHdlIGFsc28gaGF2ZSB0 aGUgcmVxdWlyZW1lbnQgdG8gYWxsb3cgcmV0cmlldmFsDQo+IG9mIGRlcml2ZWQtc3RhdGUgYWxv bmcgd2l0aCBpbnRlbmRlZC1jb25maWcgYW5kIGFwcGxpZWQtY29uZmlnLiBUaGlzIHdpbGwNCj4g cmVxdWlyZSBtb2RpZmljYXRpb24gdG8gbW9zdCBvZiB0aGUgZXhpc3RpbmcgWUFORyBkcmFmdHMg YXMgbW9zdCBub3cgaGF2ZQ0KPiBzZXBhcmF0ZSB0cmVlcyBmb3IgY29uZmlnIGFuZCBvcGVyYXRp b25hbCBzdGF0ZS4NCg0KSSBkb24ndCBhZ3JlZSB3aXRoIHRoZSBjb25jbHVzaW9uIHRoYXQgY2hh bmdlcyBhcmUgbmVlZGVkIGR1ZSB0byB0aGlzDQpyZXF1aXJlbWVudC4NCg0KU29sdXRpb24gIzEg KCJvcGVuY29uZmlnIikgcmVxdWlyZXMgY2hhbmdlcyB0byBoYW5kbGUgYXBwbGllZCBjb25maWcu DQpTb2x1dGlvbiAjMiAoImtlbnQncyIpIGRvZXMgbm90Lg0KDQpCb3RoIHNvbHV0aW9ucyAjMSBh bmQgIzIgdXNlIHNlcGFyYXRlIG5vZGVzIGZvciBkZXJpdmVkIHN0YXRlLg0KDQpJdCBtaWdodCBh cHBlYXIgYXMgIzEgYW5kICMyIGFyZSB2ZXJ5IGRpZmZlcmVudCBpbiB0aGVpciBoYW5kbGluZyBv Zg0KZGVyaXZlZCBzdGF0ZSwgc2luY2UgIzEgcHV0IGFsbCBjb25maWcgZmFsc2Ugbm9kZXMgZGly ZWN0bHkgdW5kZXIgdGhlDQpjb25maWcgdHJ1ZSBub2Rlcywgd2hlcmVhcyAjMiBpbiBzb21lIGNh c2VzIGhhdmUgYSB0b3AtbGV2ZWwNCiJ4eHgtc3RhdGUiIGNvbmZpZyBmYWxzZSBub2RlLg0KDQpC dXQgaW4gZmFjdCAjMiBhbGxvd3MgdGhlIHNvbHV0aW9uIGluICMxIGFzIG9uZSBzcGVjaWFsIGNh c2UuICBUaGUNCnJlYXNvbiB0aGF0IFJGQyA3MjIzIGhhcyBhIHNlcGFyYXRlIGxpc3QgZm9yIGRl cml2ZWQgc3RhdGUgaW50ZXJmYWNlcw0KaXMgdG8gYWxsb3cgZm9yIG5vbi1jb25maWd1cmVkIGlu dGVyZmFjZXMgdG8gYmUgbW9uaXRvcmVkLiAgSWYgdGhpcw0Kd2FzIG5vdCBhIHJlcXVpcmVtZW50 LCBhbGwgY29uZmlnIGZhbHNlIG5vZGVzIGNvdWxkICh3b3VsZCkgaGF2ZSBiZWVuDQpkZWZpbmVk IGluIHRoZSBjb25maWcgdHJ1ZSBpbnRlcmZhY2UgbGlzdC4NCg0KDQovbWFydGluDQo= From nobody Fri Jan 8 00:31:18 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79CD01ACEAC for ; Fri, 8 Jan 2016 00:31:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHycrDr_XaNQ for ; Fri, 8 Jan 2016 00:31: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 8CD541ACEAB for ; Fri, 8 Jan 2016 00:31:15 -0800 (PST) Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id 1020B1AE047A; Fri, 8 Jan 2016 09:31:14 +0100 (CET) Date: Fri, 08 Jan 2016 09:31:28 +0100 (CET) Message-Id: <20160108.093128.1503968515689611913.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <0CFCD92E-E220-4664-84E8-C2E2847F27EA@nic.cz> References: <0CFCD92E-E220-4664-84E8-C2E2847F27EA@nic.cz> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] whitespace characters X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 08:31:17 -0000 Ladislav Lhotka wrote: > Hi, > > the definition of "enum" argument (sec. 9.6.4 in 6020bis) says: > > The string MUST NOT be empty and MUST NOT have any leading or trailing > whitespace characters. > > It is not clear what "whitespace character" means. It is supposed to be unicode whitespace. Should we write: The string MUST NOT be empty and MUST NOT have any leading or trailing whitespace characters (any Unicode character with the "White_Space" property). or simply The string MUST NOT be empty and MUST NOT have any leading or trailing Unicode whitespace characters. > The ABNF indicates this: > > WSP = SP / HTAB > ; whitespace This is copied from RFC 5234. /martin > > I think in the "enum" definition LF (and maybe also CR?) should also count as a whitespace character. > > Lada > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Fri Jan 8 00:37:09 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964781ACEBA for ; Fri, 8 Jan 2016 00:37:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IDb44Cs_zUr for ; Fri, 8 Jan 2016 00:37:06 -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 28AD61A8750 for ; Fri, 8 Jan 2016 00:37:06 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 79821E86; Fri, 8 Jan 2016 09:37:04 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id zPctyx0V3dpU; Fri, 8 Jan 2016 09:37:03 +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, 8 Jan 2016 09:37:03 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7F10A20056; Fri, 8 Jan 2016 09:37:03 +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 WwR00wm9tpRo; Fri, 8 Jan 2016 09:37: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 CB47920055; Fri, 8 Jan 2016 09:37:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BEBAB397DAC4; Fri, 8 Jan 2016 09:37:00 +0100 (CET) Date: Fri, 8 Jan 2016 09:37:00 +0100 From: Juergen Schoenwaelder To: Robert Wilton Message-ID: <20160108083659.GA29486@elstar.local> Mail-Followup-To: Robert Wilton , Kent Watsen , "Acee Lindem (acee)" , "netmod@ietf.org" References: <20160104221700.28629.34622.idtracker@ietfa.amsl.com> <8A6CD12B-8B34-4F7B-83F2-E56361F998AA@juniper.net> <20160105200214.GA24262@elstar.local> <20160106063014.GA25143@elstar.local> <20160107160521.GC28062@elstar.local> <568E9F5D.3030500@cisco.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: <568E9F5D.3030500@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 08:37:08 -0000 On Thu, Jan 07, 2016 at 05:24:45PM +0000, Robert Wilton wrote: > Hi Juergen, > > On 07/01/2016 16:05, Juergen Schoenwaelder wrote: > >On Wed, Jan 06, 2016 at 06:18:46PM +0000, Kent Watsen wrote: > >>It’s true that the draft is largely centered around the > >>intended/applied config notion, but not exclusively. Specifically, 4-B > >>has "Ability to map intended config nodes to associated derived state > >>nodes". I think that this might be the only exclusion though and, if it > >>weren’t for it I would’ve used your title suggestion from the LC > >>review. Should one requirement have such influence over the title is > >>the question. I was trying to be fair to it, but maybe it's going too > >>far. > >> > >>Regarding visibility and control, I was attempting to use common words > >>(not normative terms) here. My intent for them is something along the > >>lines of: > >> > >> visibility: read/understand > >> control: write/orchestrate > >> > >We do not write operational state. I have no clue how 'orchestrate' > >helps me either. What is wrong with using defined terminology in > >a title? > I don't think that using defined terminology is a problem. But I also > think that the title that you have suggested seems to suggest a narrower > scope that what the requirements articulate. > > In particular, the draft places requirements relating the configuration > to the derived state (I.e. Req 4B). > > It also places further requirements on how management protocols are > expected to handle synchronous and asynchronous config edit requests. > (E.g. Req 2 A, B, C and associated definitions). Note that synchronous and asynchronous are defined in terms of intended / applied configuration. > I don't have a particular problem with the current title, but if you > don't like visibility/control, then perhaps "Terminology and > Requirements for Enhanced Handling of Operational State"? Better but I still think this proposal is too broad given the content of the document. I still believe my proposal is right to the point. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Jan 8 00:40:05 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB811ACEBF for ; Fri, 8 Jan 2016 00:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcoR4NqynBk9 for ; Fri, 8 Jan 2016 00:40:03 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CA03C1ACEBE for ; Fri, 8 Jan 2016 00:40:02 -0800 (PST) Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id 1793B1AE047A; Fri, 8 Jan 2016 09:40:02 +0100 (CET) Date: Fri, 08 Jan 2016 09:40:16 +0100 (CET) Message-Id: <20160108.094016.1754754608487174634.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <67AEC897-854A-4CF3-B531-A27B530FB5C7@nic.cz> References: <67AEC897-854A-4CF3-B531-A27B530FB5C7@nic.cz> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] comments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 08:40:04 -0000 Ladislav Lhotka wrote: > > > On 29 Dec 2015, at 17:47, Andy Bierman wrote: > > > > > > > > On Tue, Dec 29, 2015 at 1:09 AM, Ladislav Lhotka wrote: > > Hi, > > > > I propose the following change to sec. 14 in 6020bis (third paragraph): > > > > OLD > > This grammar assumes that the scanner replaces YANG comments with a > > single space character. > > > > NEW > > This grammar assumes that the scanner replaces YANG comments outside > > quoted arguments with a single space character. > > > > > > > > A comment inside a quoted string is not a YANG comment. > > It is just part of a string that happens to look like a comment. > > As far as I can tell, this is not clear from the text. Note that 6.1.3 says: If a string contains any space or tab characters, a semicolon (";"), braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then it MUST be enclosed within double or single quotes. Also, section 14 says: This grammar assumes that the scanner replaces YANG comments with a single space character. /martin From nobody Fri Jan 8 00:58:00 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE3D71A87D7 for ; Fri, 8 Jan 2016 00:57:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXfNlsl14gLn for ; Fri, 8 Jan 2016 00:57:57 -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 5047B1A87CD for ; Fri, 8 Jan 2016 00:57:57 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:d525:33e4:bc78:8665] (unknown [IPv6:2001:718:1a02:1:d525:33e4:bc78:8665]) by mail.nic.cz (Postfix) with ESMTPSA id BCB431819EB; Fri, 8 Jan 2016 09:57:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452243475; bh=Pn5Zsu5YkL/BzdyFrm3Ww5yxhaNu8dMKXqqGhn2jBmI=; h=From:Date:To; b=fkPVXwvxXC3U/pu6uZ1JW+0uTK1s8vIXQrrxuWr96Miy65NUOu5MlXkObbo9Tw/1e +qpBaUzEHRnn4hb6RmaauZIL3dkB73QV84mb5zpEhq+OArU28ODd/YiNA8AaEey63D Fh3IVYxwLWaZhwoYQvLul5g/dNScTDXdLieGUURM= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160108.094016.1754754608487174634.mbj@tail-f.com> Date: Fri, 8 Jan 2016 09:57:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <67AEC897-854A-4CF3-B531-A27B530FB5C7@nic.cz> <20160108.094016.1754754608487174634.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] comments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 08:57:59 -0000 > On 08 Jan 2016, at 09:40, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 29 Dec 2015, at 17:47, Andy Bierman wrote: >>>=20 >>>=20 >>>=20 >>> On Tue, Dec 29, 2015 at 1:09 AM, Ladislav Lhotka = wrote: >>> Hi, >>>=20 >>> I propose the following change to sec. 14 in 6020bis (third = paragraph): >>>=20 >>> OLD >>> This grammar assumes that the scanner replaces YANG comments with = a >>> single space character. >>>=20 >>> NEW >>> This grammar assumes that the scanner replaces YANG comments = outside >>> quoted arguments with a single space character. >>>=20 >>>=20 >>>=20 >>> A comment inside a quoted string is not a YANG comment. >>> It is just part of a string that happens to look like a comment. >>=20 >> As far as I can tell, this is not clear from the text. >=20 > Note that 6.1.3 says: >=20 > If a string contains any space or tab characters, a semicolon (";"), > braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), = then > it MUST be enclosed within double or single quotes. Yes, but it doesn't say that comment sequences inside a quoted string = are interpreted as literal characters. In another mail I proposed a simple change to sec. 6.1.1 that would = solve this issue: Inside a quoted argument string, the above character pairs are = never interpreted as the start or end of a comment. >=20 > Also, section 14 says: >=20 > This grammar assumes that the scanner replaces YANG comments with a > single space character. Yes, as long as it is clear that a comment cannot be inside a quoted = argument. Lada >=20 >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jan 8 01:54:07 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970811ACF19 for ; Fri, 8 Jan 2016 01:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwN5p2tg_si9 for ; Fri, 8 Jan 2016 01:54:04 -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 C69101ACF18 for ; Fri, 8 Jan 2016 01:54:03 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:d525:33e4:bc78:8665] (unknown [IPv6:2001:718:1a02:1:d525:33e4:bc78:8665]) by mail.nic.cz (Postfix) with ESMTPSA id 65AD618172D; Fri, 8 Jan 2016 10:54:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452246842; bh=3UGJZ1nu9yE0JKGGA3gBW6inrUbpyFWE7DrTHrmgCbk=; h=From:Date:To; b=nQ2t5ufOZX49W20IoKd9Td1de1crDDIWZWkfgVyM6R09PDZASJSD7+DgHYg/QwWlc L4e8phv/c1c4vkKwuAGzbZO6b45qiOaOyimYOC1afguW7GfCnVx7hf4jNI8Eb/W8/3 wrGkWR/EWfFvZzuIA77NXZ3NKnG4TGcRc0zyzIwY= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160108.093128.1503968515689611913.mbj@tail-f.com> Date: Fri, 8 Jan 2016 10:54:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0CFCD92E-E220-4664-84E8-C2E2847F27EA@nic.cz> <20160108.093128.1503968515689611913.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] whitespace characters X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 09:54:05 -0000 > On 08 Jan 2016, at 09:31, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >> Hi, >>=20 >> the definition of "enum" argument (sec. 9.6.4 in 6020bis) says: >>=20 >> The string MUST NOT be empty and MUST NOT have any leading or = trailing >> whitespace characters. >>=20 >> It is not clear what "whitespace character" means. >=20 > It is supposed to be unicode whitespace. Should we write: >=20 > The string MUST NOT be empty and MUST NOT have any leading or = trailing > whitespace characters (any Unicode character with the "White_Space" > property). >=20 > or simply >=20 > The string MUST NOT be empty and MUST NOT have any leading or = trailing > Unicode whitespace characters. >=20 I guess I prefer the more verbose version. >=20 >> The ABNF indicates this: >>=20 >> WSP =3D SP / HTAB >> ; whitespace >=20 > This is copied from RFC 5234. OK, but it's not the whitespace that the enum definition talks about. BTW, sec. 9.7.2 says that "bits" value is "a space-separated list". I = assume what's meant here is only the regular space, i.e. U+0020. Lada=20 >=20 >=20 > /martin >=20 >=20 >=20 >>=20 >> I think in the "enum" definition LF (and maybe also CR?) should also = count as a whitespace character. >>=20 >> Lada >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >>=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jan 8 02:11:42 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4511AD059 for ; Fri, 8 Jan 2016 02:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4EA2h_6MDHi for ; Fri, 8 Jan 2016 02:11:39 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5A79D1AD05B for ; Fri, 8 Jan 2016 02:11:39 -0800 (PST) Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id 9F0011AE047A; Fri, 8 Jan 2016 11:11:38 +0100 (CET) Date: Fri, 08 Jan 2016 11:11:53 +0100 (CET) Message-Id: <20160108.111153.195946708128024055.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <0CFCD92E-E220-4664-84E8-C2E2847F27EA@nic.cz> <20160108.093128.1503968515689611913.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] whitespace characters X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 10:11:41 -0000 Ladislav Lhotka wrote: > > > On 08 Jan 2016, at 09:31, Martin Bjorklund wrote: > > > > Ladislav Lhotka wrote: > >> Hi, > >> > >> the definition of "enum" argument (sec. 9.6.4 in 6020bis) says: > >> > >> The string MUST NOT be empty and MUST NOT have any leading or trailing > >> whitespace characters. > >> > >> It is not clear what "whitespace character" means. > > > > It is supposed to be unicode whitespace. Should we write: > > > > The string MUST NOT be empty and MUST NOT have any leading or trailing > > whitespace characters (any Unicode character with the "White_Space" > > property). > > > > or simply > > > > The string MUST NOT be empty and MUST NOT have any leading or trailing > > Unicode whitespace characters. > > > > I guess I prefer the more verbose version. Ok, fixed. > >> The ABNF indicates this: > >> > >> WSP = SP / HTAB > >> ; whitespace > > > > This is copied from RFC 5234. > > OK, but it's not the whitespace that the enum definition talks about. > > BTW, sec. 9.7.2 says that "bits" value is "a space-separated list". I > assume what's meant here is only the regular space, i.e. U+0020. Yes. It doesn't say "whitespace-separated list". /martin > > Lada > > > > > > > /martin > > > > > > > >> > >> I think in the "enum" definition LF (and maybe also CR?) should also > >> count as a whitespace character. > >> > >> Lada > >> > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: E74E8C0C > >> > >> > >> > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Fri Jan 8 02:13:50 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD56E1AD05D for ; Fri, 8 Jan 2016 02:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aux4sP5EiRWP for ; Fri, 8 Jan 2016 02:13:48 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 41C571AD05E for ; Fri, 8 Jan 2016 02:13:47 -0800 (PST) Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id 8421D1AE047A; Fri, 8 Jan 2016 11:13:46 +0100 (CET) Date: Fri, 08 Jan 2016 11:14:01 +0100 (CET) Message-Id: <20160108.111401.1959336636257209892.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <67AEC897-854A-4CF3-B531-A27B530FB5C7@nic.cz> <20160108.094016.1754754608487174634.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] comments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 10:13:50 -0000 Ladislav Lhotka wrote: > > > On 08 Jan 2016, at 09:40, Martin Bjorklund wrote: > > > > Ladislav Lhotka wrote: > >> > >>> On 29 Dec 2015, at 17:47, Andy Bierman wrote: > >>> > >>> > >>> > >>> On Tue, Dec 29, 2015 at 1:09 AM, Ladislav Lhotka wrote: > >>> Hi, > >>> > >>> I propose the following change to sec. 14 in 6020bis (third paragraph): > >>> > >>> OLD > >>> This grammar assumes that the scanner replaces YANG comments with a > >>> single space character. > >>> > >>> NEW > >>> This grammar assumes that the scanner replaces YANG comments outside > >>> quoted arguments with a single space character. > >>> > >>> > >>> > >>> A comment inside a quoted string is not a YANG comment. > >>> It is just part of a string that happens to look like a comment. > >> > >> As far as I can tell, this is not clear from the text. > > > > Note that 6.1.3 says: > > > > If a string contains any space or tab characters, a semicolon (";"), > > braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then > > it MUST be enclosed within double or single quotes. > > Yes, but it doesn't say that comment sequences inside a quoted > string are interpreted as literal characters. > In another mail I proposed a simple change to sec. 6.1.1 that would > solve this issue: > > Inside a quoted argument string, the above character pairs > are never interpreted > as the start or end of a comment. Ok, I added this clarification. /martin > > > > Also, section 14 says: > > > > This grammar assumes that the scanner replaces YANG comments with a > > single space character. > > Yes, as long as it is clear that a comment cannot be inside a quoted argument. > > Lada > > > > > > > > > /martin > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Fri Jan 8 03:52:27 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2022F1AD259; Fri, 8 Jan 2016 03:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aByPGWT707Gm; Fri, 8 Jan 2016 03:52:24 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id AB2121AD255; Fri, 8 Jan 2016 03:52:23 -0800 (PST) Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id 609C41AE047A; Fri, 8 Jan 2016 12:52:22 +0100 (CET) Date: Fri, 08 Jan 2016 12:52:37 +0100 (CET) Message-Id: <20160108.125237.1815033897965196525.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20160107154523.GB28062@elstar.local> References: <20160107.162142.1102381710329032385.mbj@tail-f.com> <20160107154523.GB28062@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: rtg-dt-yang-arch@ietf.org, netmod@ietf.org, yang-doctors@ietf.org Subject: Re: [netmod] [yang-doctors] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 11:52:25 -0000 Juergen Schoenwaelder wrote: > On Thu, Jan 07, 2016 at 04:21:42PM +0100, Martin Bjorklund wrote: > > > > With YANG 1.1, a leafref can be marked as "require-instance false", > > which allows a interface-state-ref to be used in config: > > > > type if:interface-state-ref { > > require-instance false; > > } > > // + add description that explains what happens if there is no such > > // instance > > > > > > (NOTE: this doesn't work w/ pyang at the momement, I am working on a > > fix) > > > > And it would have to be if:interface-ref instead if:interface-state-ref > I think. No, I meant interface-state-ref. This way you can put a filter on non-configured interfaces. /martin From nobody Fri Jan 8 04:09:09 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4181AD34C; Fri, 8 Jan 2016 04:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFHn-YoYYRCi; Fri, 8 Jan 2016 04:09:06 -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 657A61AD33F; Fri, 8 Jan 2016 04:09:06 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2F43C73C; Fri, 8 Jan 2016 13:09:05 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id nOpY8ErO9_P8; Fri, 8 Jan 2016 13:09:04 +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, 8 Jan 2016 13:09:04 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6E7BD20056; Fri, 8 Jan 2016 13:09:04 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id UOmPoOaFijLu; Fri, 8 Jan 2016 13:09:03 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 435D920055; Fri, 8 Jan 2016 13:09:03 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0A90A397E364; Fri, 8 Jan 2016 13:09:01 +0100 (CET) Date: Fri, 8 Jan 2016 13:09:00 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20160108120858.GA30099@elstar.local> Mail-Followup-To: Martin Bjorklund , ivandean@gmail.com, rtg-dt-yang-arch@ietf.org, netmod@ietf.org, yang-doctors@ietf.org References: <20160107.162142.1102381710329032385.mbj@tail-f.com> <20160107154523.GB28062@elstar.local> <20160108.125237.1815033897965196525.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160108.125237.1815033897965196525.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: rtg-dt-yang-arch@ietf.org, netmod@ietf.org, yang-doctors@ietf.org Subject: Re: [netmod] [yang-doctors] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 12:09:09 -0000 On Fri, Jan 08, 2016 at 12:52:37PM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Thu, Jan 07, 2016 at 04:21:42PM +0100, Martin Bjorklund wrote: > > > > > > With YANG 1.1, a leafref can be marked as "require-instance false", > > > which allows a interface-state-ref to be used in config: > > > > > > type if:interface-state-ref { > > > require-instance false; > > > } > > > // + add description that explains what happens if there is no such > > > // instance > > > > > > > > > (NOTE: this doesn't work w/ pyang at the momement, I am working on a > > > fix) > > > > > > > And it would have to be if:interface-ref instead if:interface-state-ref > > I think. > > No, I meant interface-state-ref. This way you can put a filter on > non-configured interfaces. > But with require-instance false, this is also true for if:interface-ref. If I preconfigure and interface, I might also want to preconfigure ACLs refering the preconfigure interface. And note that if:interface-state-ref refers to a config false leaf. /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 8 04:12:39 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32EDC1AD351; Fri, 8 Jan 2016 04:12:37 -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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWB3XpY5cYIa; Fri, 8 Jan 2016 04:12:35 -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 67D021AD352; Fri, 8 Jan 2016 04:12:35 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id b14so168347043wmb.1; Fri, 08 Jan 2016 04:12:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PmLAMF2qt6FFNewoGV+psFBt2DV3TZWWItzRo5dKCb8=; b=FNR/N9DhNdHCUyBzZayL95anURlod5glBf/18Lwny8mlmDiEzFFmxJhcwn9/rN9y5/ v1dLB0fRdrS3Aac3ur1lcU+Cxbgs1jY1lf/XLsd6BE3Us6MtF5GwEDZ8KCmQiOc4tII1 7d/x9HuBfgOjaQn/uxJOyjrSg5pO30dEyVvmSxlByY7bug+5pn+6dVMbwKFGGg1yRvLR obLY/0AkoJififSnMi3FD1aK6VpMbmn2ghFg3Ixf9ErUTiU5Y+IONh0M7MyoItJ32dJg ge/dVp1o460rfUuC3KDMf+wx/vjYVzmPRQRLxSJaoAzTcWJ0zZfY7rlCtn13CDjWykmD 4HgA== X-Received: by 10.28.72.2 with SMTP id v2mr23460618wma.84.1452255154010; Fri, 08 Jan 2016 04:12:34 -0800 (PST) Received: from [192.168.254.213] ([147.83.206.82]) by smtp.gmail.com with ESMTPSA id v2sm18277015wmv.12.2016.01.08.04.12.32 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 08 Jan 2016 04:12:33 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dean Bogdanovic In-Reply-To: <20160108120858.GA30099@elstar.local> Date: Fri, 8 Jan 2016 13:12:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160107.162142.1102381710329032385.mbj@tail-f.com> <20160107154523.GB28062@elstar.local> <20160108.125237.1815033897965196525.mbj@tail-f.com> <20160108120858.GA30099@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3112) Archived-At: Cc: yang-doctors@ietf.org, rtg-dt-yang-arch@ietf.org, netmod@ietf.org Subject: Re: [netmod] [yang-doctors] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 12:12:37 -0000 > On Jan 8, 2016, at 1:09 PM, Juergen Schoenwaelder = wrote: >=20 > On Fri, Jan 08, 2016 at 12:52:37PM +0100, Martin Bjorklund wrote: >> Juergen Schoenwaelder wrote: >>> On Thu, Jan 07, 2016 at 04:21:42PM +0100, Martin Bjorklund wrote: >>>>=20 >>>> With YANG 1.1, a leafref can be marked as "require-instance false", >>>> which allows a interface-state-ref to be used in config: >>>>=20 >>>> type if:interface-state-ref { >>>> require-instance false; >>>> } >>>> // + add description that explains what happens if there is no = such >>>> // instance >>>>=20 >>>>=20 >>>> (NOTE: this doesn't work w/ pyang at the momement, I am working on = a >>>> fix) >>>>=20 >>>=20 >>> And it would have to be if:interface-ref instead = if:interface-state-ref >>> I think. >>=20 >> No, I meant interface-state-ref. This way you can put a filter on >> non-configured interfaces. >>=20 >=20 > But with require-instance false, this is also true for > if:interface-ref. If I preconfigure and interface, I might also want > to preconfigure ACLs refering the preconfigure interface. And note > that if:interface-state-ref refers to a config false leaf. In this case we have to change to yang-version 1.1. The plan was to have = it for 1.0. Do we want to move the ACL model to YANG minimum version = 1.1? >=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 From nobody Fri Jan 8 04:24:12 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454E21AD36E; Fri, 8 Jan 2016 04:24:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwUUioasfaa1; Fri, 8 Jan 2016 04:24:08 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 831251AD36A; Fri, 8 Jan 2016 04:24:08 -0800 (PST) Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id 349EC1AE047A; Fri, 8 Jan 2016 13:24:07 +0100 (CET) Date: Fri, 08 Jan 2016 13:24:23 +0100 (CET) Message-Id: <20160108.132423.796967666017657492.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20160108120858.GA30099@elstar.local> References: <20160107154523.GB28062@elstar.local> <20160108.125237.1815033897965196525.mbj@tail-f.com> <20160108120858.GA30099@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: rtg-dt-yang-arch@ietf.org, netmod@ietf.org, yang-doctors@ietf.org Subject: Re: [netmod] [yang-doctors] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 12:24:10 -0000 Juergen Schoenwaelder wrote: > On Fri, Jan 08, 2016 at 12:52:37PM +0100, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > On Thu, Jan 07, 2016 at 04:21:42PM +0100, Martin Bjorklund wrote: > > > > > > > > With YANG 1.1, a leafref can be marked as "require-instance false", > > > > which allows a interface-state-ref to be used in config: > > > > > > > > type if:interface-state-ref { > > > > require-instance false; > > > > } > > > > // + add description that explains what happens if there is no such > > > > // instance > > > > > > > > > > > > (NOTE: this doesn't work w/ pyang at the momement, I am working on a > > > > fix) > > > > > > > > > > And it would have to be if:interface-ref instead if:interface-state-ref > > > I think. > > > > No, I meant interface-state-ref. This way you can put a filter on > > non-configured interfaces. > > > > But with require-instance false, this is also true for > if:interface-ref. Sure. > If I preconfigure and interface, I might also want > to preconfigure ACLs refering the preconfigure interface. But this is also ok for interface-state-ref with require-instance false. I prefer this, b/c then we can say that once the target leaf exists, the filter applies. > And note > that if:interface-state-ref refers to a config false leaf. Yes, this is ok w/ require-instance false. /martin From nobody Fri Jan 8 04:26:07 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70451AD370; Fri, 8 Jan 2016 04:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrKBiKv1uly4; Fri, 8 Jan 2016 04:26:05 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id BDE101AD36E; Fri, 8 Jan 2016 04:26:04 -0800 (PST) Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id 036CA1AE047A; Fri, 8 Jan 2016 13:26:04 +0100 (CET) Date: Fri, 08 Jan 2016 13:26:19 +0100 (CET) Message-Id: <20160108.132619.2106992589983161035.mbj@tail-f.com> To: ivandean@gmail.com From: Martin Bjorklund In-Reply-To: References: <20160108.125237.1815033897965196525.mbj@tail-f.com> <20160108120858.GA30099@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: yang-doctors@ietf.org, rtg-dt-yang-arch@ietf.org, netmod@ietf.org Subject: Re: [netmod] [yang-doctors] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 12:26:06 -0000 Dean Bogdanovic wrote: > > > On Jan 8, 2016, at 1:09 PM, Juergen Schoenwaelder > > wrote: > > > > On Fri, Jan 08, 2016 at 12:52:37PM +0100, Martin Bjorklund wrote: > >> Juergen Schoenwaelder wrote: > >>> On Thu, Jan 07, 2016 at 04:21:42PM +0100, Martin Bjorklund wrote: > >>>> > >>>> With YANG 1.1, a leafref can be marked as "require-instance false", > >>>> which allows a interface-state-ref to be used in config: > >>>> > >>>> type if:interface-state-ref { > >>>> require-instance false; > >>>> } > >>>> // + add description that explains what happens if there is no such > >>>> // instance > >>>> > >>>> > >>>> (NOTE: this doesn't work w/ pyang at the momement, I am working on a > >>>> fix) > >>>> > >>> > >>> And it would have to be if:interface-ref instead > >>> if:interface-state-ref > >>> I think. > >> > >> No, I meant interface-state-ref. This way you can put a filter on > >> non-configured interfaces. > >> > > > > But with require-instance false, this is also true for > > if:interface-ref. If I preconfigure and interface, I might also want > > to preconfigure ACLs refering the preconfigure interface. And note > > that if:interface-state-ref refers to a config false leaf. > > In this case we have to change to yang-version 1.1. The plan was to > have it for 1.0. Do we want to move the ACL model to YANG minimum > version 1.1? I think it is ok. We're fixing issues like this one in 1.1 so that we don't have to rely on various workarounds. Note that the second WGLC for 1.1 just ended, w/ mostly minor proposed edits. /martin From nobody Fri Jan 8 04:30:58 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6D31AD376 for ; Fri, 8 Jan 2016 04:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YVGVMt3Vnfp for ; Fri, 8 Jan 2016 04:30:55 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABC61AD372 for ; Fri, 8 Jan 2016 04:30:55 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 2D73A1CC006B; Fri, 8 Jan 2016 13:30:56 +0100 (CET) From: Ladislav Lhotka To: Robert Wilton , NETMOD WG In-Reply-To: <568E95B4.1070703@cisco.com> References: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> <568E95B4.1070703@cisco.com> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Fri, 08 Jan 2016 13:30:53 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 12:30:57 -0000 Robert Wilton writes: > Hi Lada, > > I think that requirement 1D is fairly key to what is being asked for > here to allow both the user and system to easily relate between what the > operator desires and what configuration the system is actually using, In a way, system-controlled interfaces are default entries in the interface list - and the system can certainly be using interfaces with no configuration installed by NETCONF/RESTCONF clients. > so I wouldn't be particularly keen on loosening this requirement. OK, but then IMO this intended-applied dualism is of limited utility. For many systems or services, asynchronicity is not an option, or isn't important. > > For the ACL example: > Would it be feasible to change the ACL module to use a leafref to the > interface name, with the added constraint that you have to at least > configure the existence of an interface before you can have any > configuration referring to it? Well, yes, that's how it is supposed to be done now - also, for example, for stacking interfaces as in Appendix B of RFC 7223. It is not only extra work: the interface list can be locked, so it may not be possible to immediately create a dummy interface entry and, consequently, an ACL rule with that interface cannot be configured. In this sense, using a string rather than a leafref looks like a reasonable choice. As Martin pointed out, with YANG 1.1 it would be possible to refer to an interface entry in state data from configuration. On the other hand, with "require-instance false" validation won't detect errors in ACL configuration such as referring to a non-existent interface. Lada > > Thanks, > Rob > > > On 07/01/2016 10:20, Ladislav Lhotka wrote: >> Hi, >> >> a good use of applied configuration could be to formalize the concept of system-controlled entries as defined in RFC 7223, routing-cfg, and probably elsewhere, too. >> >> My idea is that system-controlled interfaces or other entries would appear in applied configuration, but not in intended configuration until something needs to be really configured. We could then permit leafrefs from intended configuration to refer to leafs in applied configuration. One case where this would be useful is the ACL module, where match conditions refering to interfaces currently have to use plain strings as references to interface names. >> >> However, the above idea seems to be at odds with requirement 1D in opstate-reqs-02. I wonder: could that requirement be relaxed or removed so that the above use case can be supported? >> >> Thanks, Lada >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> . >> > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jan 8 04:47:29 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9AB1ADBFB for ; Fri, 8 Jan 2016 04:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WX_xgIt6X6QI for ; Fri, 8 Jan 2016 04:47:26 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5266F1AD481 for ; Fri, 8 Jan 2016 04:47:26 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 560E51CC006B; Fri, 8 Jan 2016 13:47:29 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder , Robert Wilton In-Reply-To: <20160108083659.GA29486@elstar.local> References: <20160104221700.28629.34622.idtracker@ietfa.amsl.com> <8A6CD12B-8B34-4F7B-83F2-E56361F998AA@juniper.net> <20160105200214.GA24262@elstar.local> <20160106063014.GA25143@elstar.local> <20160107160521.GC28062@elstar.local> <568E9F5D.3030500@cisco.com> <20160108083659.GA29486@elstar.local> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Fri, 08 Jan 2016 13:47:26 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 12:47:28 -0000 Juergen Schoenwaelder writes: > On Thu, Jan 07, 2016 at 05:24:45PM +0000, Robert Wilton wrote: >> Hi Juergen, >>=20 >> On 07/01/2016 16:05, Juergen Schoenwaelder wrote: >> >On Wed, Jan 06, 2016 at 06:18:46PM +0000, Kent Watsen wrote: >> >>It=E2=80=99s true that the draft is largely centered around the=20 >> >>intended/applied config notion, but not exclusively. Specifically, 4-= B=20 >> >>has "Ability to map intended config nodes to associated derived state= =20 >> >>nodes". I think that this might be the only exclusion though and, if = it=20 >> >>weren=E2=80=99t for it I would=E2=80=99ve used your title suggestion f= rom the LC=20 >> >>review. Should one requirement have such influence over the title is= =20 >> >>the question. I was trying to be fair to it, but maybe it's going too= =20 >> >>far. >> >> >> >>Regarding visibility and control, I was attempting to use common words= =20 >> >>(not normative terms) here. My intent for them is something along the= =20 >> >>lines of: >> >> >> >> visibility: read/understand >> >> control: write/orchestrate >> >> >> >We do not write operational state. I have no clue how 'orchestrate' >> >helps me either. What is wrong with using defined terminology in >> >a title? >> I don't think that using defined terminology is a problem. But I also=20 >> think that the title that you have suggested seems to suggest a narrower= =20 >> scope that what the requirements articulate. >>=20 >> In particular, the draft places requirements relating the configuration= =20 >> to the derived state (I.e. Req 4B). >>=20 >> It also places further requirements on how management protocols are=20 >> expected to handle synchronous and asynchronous config edit requests.=20 >> (E.g. Req 2 A, B, C and associated definitions). > > Note that synchronous and asynchronous are defined in terms of > intended / applied configuration. >=20=20 >> I don't have a particular problem with the current title, but if you=20 >> don't like visibility/control, then perhaps "Terminology and=20 >> Requirements for Enhanced Handling of Operational State"? > > Better but I still think this proposal is too broad given the content > of the document. I still believe my proposal is right to the point. +1 The draft talks about introducing applied configuration and its relationship to state data and intended configuration (which, I believe, is the good old "running"). I don't see any enhanced handling of operational state. Lada > > /js > > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jan 8 04:52:58 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBAE1AE4CB for ; Fri, 8 Jan 2016 04:52:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NU22jJXWzjZ4 for ; Fri, 8 Jan 2016 04:52:56 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C51921ADBFA for ; Fri, 8 Jan 2016 04:52:55 -0800 (PST) Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id 112BF1AE047A; Fri, 8 Jan 2016 13:52:55 +0100 (CET) Date: Fri, 08 Jan 2016 13:53:11 +0100 (CET) Message-Id: <20160108.135311.1322994157154983529.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <568E9F5D.3030500@cisco.com> <20160108083659.GA29486@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 12:52:57 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gSnVlcmdlbiBTY2hvZW53 YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyaXRlczoNCj4g DQo+ID4gT24gVGh1LCBKYW4gMDcsIDIwMTYgYXQgMDU6MjQ6NDVQTSArMDAwMCwgUm9iZXJ0IFdp bHRvbiB3cm90ZToNCj4gPj4gSGkgSnVlcmdlbiwNCj4gPj4gDQo+ID4+IE9uIDA3LzAxLzIwMTYg MTY6MDUsIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciB3cm90ZToNCj4gPj4gPk9uIFdlZCwgSmFuIDA2 LCAyMDE2IGF0IDA2OjE4OjQ2UE0gKzAwMDAsIEtlbnQgV2F0c2VuIHdyb3RlOg0KPiA+PiA+Pkl0 4oCZcyB0cnVlIHRoYXQgdGhlIGRyYWZ0IGlzIGxhcmdlbHkgY2VudGVyZWQgYXJvdW5kIHRoZSAN Cj4gPj4gPj5pbnRlbmRlZC9hcHBsaWVkIGNvbmZpZyBub3Rpb24sIGJ1dCBub3QgZXhjbHVzaXZl bHkuICBTcGVjaWZpY2FsbHksIDQtQiANCj4gPj4gPj5oYXMgIkFiaWxpdHkgdG8gbWFwIGludGVu ZGVkIGNvbmZpZyBub2RlcyB0byBhc3NvY2lhdGVkIGRlcml2ZWQgc3RhdGUgDQo+ID4+ID4+bm9k ZXMiLiAgSSB0aGluayB0aGF0IHRoaXMgbWlnaHQgYmUgdGhlIG9ubHkgZXhjbHVzaW9uIHRob3Vn aCBhbmQsIGlmIGl0IA0KPiA+PiA+PndlcmVu4oCZdCBmb3IgaXQgSSB3b3VsZOKAmXZlIHVzZWQg eW91ciB0aXRsZSBzdWdnZXN0aW9uIGZyb20gdGhlIExDIA0KPiA+PiA+PnJldmlldy4gICBTaG91 bGQgb25lIHJlcXVpcmVtZW50IGhhdmUgc3VjaCBpbmZsdWVuY2Ugb3ZlciB0aGUgdGl0bGUgaXMg DQo+ID4+ID4+dGhlIHF1ZXN0aW9uLiAgSSB3YXMgdHJ5aW5nIHRvIGJlIGZhaXIgdG8gaXQsIGJ1 dCBtYXliZSBpdCdzIGdvaW5nIHRvbyANCj4gPj4gPj5mYXIuDQo+ID4+ID4+DQo+ID4+ID4+UmVn YXJkaW5nIHZpc2liaWxpdHkgYW5kIGNvbnRyb2wsIEkgd2FzIGF0dGVtcHRpbmcgdG8gdXNlIGNv bW1vbiB3b3JkcyANCj4gPj4gPj4obm90IG5vcm1hdGl2ZSB0ZXJtcykgaGVyZS4gIE15IGludGVu dCBmb3IgdGhlbSBpcyBzb21ldGhpbmcgYWxvbmcgdGhlIA0KPiA+PiA+PmxpbmVzIG9mOg0KPiA+ PiA+Pg0KPiA+PiA+Pgl2aXNpYmlsaXR5OiByZWFkL3VuZGVyc3RhbmQNCj4gPj4gPj4JY29udHJv bDogd3JpdGUvb3JjaGVzdHJhdGUNCj4gPj4gPj4NCj4gPj4gPldlIGRvIG5vdCB3cml0ZSBvcGVy YXRpb25hbCBzdGF0ZS4gSSBoYXZlIG5vIGNsdWUgaG93ICdvcmNoZXN0cmF0ZScNCj4gPj4gPmhl bHBzIG1lIGVpdGhlci4gV2hhdCBpcyB3cm9uZyB3aXRoIHVzaW5nIGRlZmluZWQgdGVybWlub2xv Z3kgaW4NCj4gPj4gPmEgdGl0bGU/DQo+ID4+IEkgZG9uJ3QgdGhpbmsgdGhhdCB1c2luZyBkZWZp bmVkIHRlcm1pbm9sb2d5IGlzIGEgcHJvYmxlbS4gIEJ1dCBJIGFsc28gDQo+ID4+IHRoaW5rIHRo YXQgdGhlIHRpdGxlIHRoYXQgeW91IGhhdmUgc3VnZ2VzdGVkIHNlZW1zIHRvIHN1Z2dlc3QgYSBu YXJyb3dlciANCj4gPj4gc2NvcGUgdGhhdCB3aGF0IHRoZSByZXF1aXJlbWVudHMgYXJ0aWN1bGF0 ZS4NCj4gPj4gDQo+ID4+IEluIHBhcnRpY3VsYXIsIHRoZSBkcmFmdCBwbGFjZXMgcmVxdWlyZW1l bnRzIHJlbGF0aW5nIHRoZSBjb25maWd1cmF0aW9uIA0KPiA+PiB0byB0aGUgZGVyaXZlZCBzdGF0 ZSAoSS5lLiBSZXEgNEIpLg0KPiA+PiANCj4gPj4gSXQgYWxzbyBwbGFjZXMgZnVydGhlciByZXF1 aXJlbWVudHMgb24gaG93IG1hbmFnZW1lbnQgcHJvdG9jb2xzIGFyZSANCj4gPj4gZXhwZWN0ZWQg dG8gaGFuZGxlIHN5bmNocm9ub3VzIGFuZCBhc3luY2hyb25vdXMgY29uZmlnIGVkaXQgcmVxdWVz dHMuIA0KPiA+PiAoRS5nLiBSZXEgMiBBLCBCLCBDIGFuZCBhc3NvY2lhdGVkIGRlZmluaXRpb25z KS4NCj4gPg0KPiA+IE5vdGUgdGhhdCBzeW5jaHJvbm91cyBhbmQgYXN5bmNocm9ub3VzIGFyZSBk ZWZpbmVkIGluIHRlcm1zIG9mDQo+ID4gaW50ZW5kZWQgLyBhcHBsaWVkIGNvbmZpZ3VyYXRpb24u DQo+ID4gIA0KPiA+PiBJIGRvbid0IGhhdmUgYSBwYXJ0aWN1bGFyIHByb2JsZW0gd2l0aCB0aGUg Y3VycmVudCB0aXRsZSwgYnV0IGlmIHlvdSANCj4gPj4gZG9uJ3QgbGlrZSB2aXNpYmlsaXR5L2Nv bnRyb2wsIHRoZW4gcGVyaGFwcyAiVGVybWlub2xvZ3kgYW5kIA0KPiA+PiBSZXF1aXJlbWVudHMg Zm9yIEVuaGFuY2VkIEhhbmRsaW5nIG9mIE9wZXJhdGlvbmFsIFN0YXRlIj8NCj4gPg0KPiA+IEJl dHRlciBidXQgSSBzdGlsbCB0aGluayB0aGlzIHByb3Bvc2FsIGlzIHRvbyBicm9hZCBnaXZlbiB0 aGUgY29udGVudA0KPiA+IG9mIHRoZSBkb2N1bWVudC4gSSBzdGlsbCBiZWxpZXZlIG15IHByb3Bv c2FsIGlzIHJpZ2h0IHRvIHRoZSBwb2ludC4NCj4gDQo+ICsxDQo+IA0KPiBUaGUgZHJhZnQgdGFs a3MgYWJvdXQgaW50cm9kdWNpbmcgYXBwbGllZCBjb25maWd1cmF0aW9uIGFuZCBpdHMNCj4gcmVs YXRpb25zaGlwIHRvIHN0YXRlIGRhdGEgYW5kIGludGVuZGVkIGNvbmZpZ3VyYXRpb24gKHdoaWNo LCBJIGJlbGlldmUsDQo+IGlzIHRoZSBnb29kIG9sZCAicnVubmluZyIpLiBJIGRvbid0IHNlZSBh bnkgZW5oYW5jZWQgaGFuZGxpbmcgb2YNCj4gb3BlcmF0aW9uYWwgc3RhdGUuDQoNCldlbGwsIHRo ZSBhcHBsaWVkIGNvbmZpZyBpcyBwYXJ0IG9mIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSwgYW5kIHRo ZXJlDQphcmUgcmVxdWlyZW1lbnRzIGZvciByZXRyaWV2YWwgb2YgdGhlIG9wZXJhdGlvbmFsIHN0 YXRlLiAgU28gaXQgaXMNCnJlbGF0ZWQuICAgSSB0aGluayB0aGUgY3VycmVudCB0aXRsZSBpcyBm aW5lLg0KDQoNCi9tYXJ0aW4NCg== From nobody Fri Jan 8 04:57:24 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4683E1B29AD for ; Fri, 8 Jan 2016 04:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MGTvkbrBHkH for ; Fri, 8 Jan 2016 04:57:20 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B05AA1ADBF8 for ; Fri, 8 Jan 2016 04:57:20 -0800 (PST) Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id 024381AE047A; Fri, 8 Jan 2016 13:57:19 +0100 (CET) Date: Fri, 08 Jan 2016 13:57:36 +0100 (CET) Message-Id: <20160108.135736.371521840025425.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] action-stmt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 12:57:22 -0000 Hi, Andy Bierman wrote: > Hi, > > The action-stmt example on page 27 is wrong. > The element is missing. It is shown correctly > on page 105. > p27 > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > eth1 > > 192.0.2.1 > > > > > > p105 > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > apache-1 > > 2014-07-29T13:42:00Z > > > > Fixed. > Sec. 7.15 provides few details wrt/ input processing. > Extra input is ignored? (draft is silent about that). > YANG attributes like "insert"or "operation" are ignored? (also silent). Right, just as the text for rpcs. Do you think we need to add some text about this? > Sec 7.15.2, para 2 is not clear whether the XML hierarchy > has to exist in any particular datastore (or opstate). > Since there is no mention of datastores in 7.15, I > assume the text just refers to the input containing > schema-valid XML, which may or may not correspond > to actual data instances somewhere inn the server. Yes. /martin From nobody Fri Jan 8 04:58:00 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10AD31B29AD for ; Fri, 8 Jan 2016 04:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPT8cMRc1Fe5 for ; Fri, 8 Jan 2016 04:57:57 -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 8F2FD1B29A7 for ; Fri, 8 Jan 2016 04:57:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5358; q=dns/txt; s=iport; t=1452257877; x=1453467477; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GgdSJxrOU28KshOUK88yZepnoZLvNk/xQTUGH6+qw8c=; b=FDrF03Y+rEFLn11JB/zRZdqASRdRIMcNFwBPpsGA+CWUV+Np9tSrH3X/ +fXmdAXUaMuYlY8iTMlhJ0+Sq5/TMt14npF2ExjLPrEf5bPqNx9CGguQK ym/8fFX0SGBaBGEtKhKWK1fpbpTak+y/NEQkOzjvJR3XlhdFRBLk4C2/Z Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAgDVsY9W/5FdJa1egzqBPwaIU7FLg?= =?us-ascii?q?hMBDYFkhg8CHIEGOBQBAQEBAQEBgQqENQEBBCMRRRACAQgOAggCAiYCAgIwFRA?= =?us-ascii?q?CBA4FG4gUsQOQRgEBAQEBAQEBAQEBAQEBAQEBARuBAYpUhFWDHoFJBZcNAY1Xg?= =?us-ascii?q?VyNH4pbg3IBIAEBQoQKcoRZgQgBAQE?= X-IronPort-AV: E=Sophos;i="5.20,538,1444694400"; d="scan'208";a="64515916" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jan 2016 12:57:56 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u08Cvu7b016886 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Jan 2016 12:57:56 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 8 Jan 2016 07:57:55 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Fri, 8 Jan 2016 07:57:55 -0500 From: "Acee Lindem (acee)" To: Martin Bjorklund Thread-Topic: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01 Thread-Index: AQHROST+Qi5eUPyFCUOmbJF1PR1M/Z7Q8W4AgACOLQCAAASngIAEjK+AgAAEHICAABYDAIACFGgAgABYGQCAABvKAIAZAdyAgAAA3wA= Date: Fri, 8 Jan 2016 12:57:55 +0000 Message-ID: References: <6AFC7C6C-61B7-4310-A0CA-08A7CD76A899@nic.cz> <20160108.085447.1699532851849652427.mbj@tail-f.com> In-Reply-To: <20160108.085447.1699532851849652427.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.203] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 12:57:59 -0000 SGkgTWFydGluLCBldCBhbCwgDQoNCk9uIDEvOC8xNiwgMjo1NCBBTSwgIk1hcnRpbiBCam9ya2x1 bmQiIDxtYmpAdGFpbC1mLmNvbT4gd3JvdGU6DQoNCj5IaSwNCj4NCj4iQWNlZSBMaW5kZW0gKGFj ZWUpIiA8YWNlZUBjaXNjby5jb20+IHdyb3RlOg0KPj4gDQo+PiBPbiAxMi8yMy8xNSwgMzoyMiBB TSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgTGFkaXNsYXYgTGhvdGthIg0KPj4gPG5ldG1vZC1ib3Vu Y2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBsaG90a2FAbmljLmN6PiB3cm90ZToNCj4+IA0KPj4g Pg0KPj4gPj4gT24gMjMgRGVjIDIwMTUsIGF0IDA0OjA2LCBLZW50IFdhdHNlbiA8a3dhdHNlbkBq dW5pcGVyLm5ldD4gd3JvdGU6DQo+PiA+PiANCj4+ID4+IA0KPj4gPj4gDQo+PiA+PiANCj4+ID4+ IA0KPj4gPj4gDQo+PiA+PiBPbiAxMi8yMS8xNSwgMjoyMSBQTSwgIm5ldG1vZCBvbiBiZWhhbGYg b2YgTGFkaXNsYXYgTGhvdGthIg0KPj4gPj48bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVo YWxmIG9mIGxob3RrYUBuaWMuY3o+IHdyb3RlOg0KPj4gPj4gDQo+PiA+Pj4gDQo+PiA+Pj4+IE9u IDIxIERlYyAyMDE1LCBhdCAxOTowMiwgSnVlcmdlbiBTY2hvZW53YWVsZGVyDQo+PiA+Pj4+PGou c2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQo+PiA+Pj4+IA0KPj4g Pj4+PiBPbiBNb24sIERlYyAyMSwgMjAxNSBhdCAwNjo0Nzo0OVBNICswMTAwLCBCZW5vaXQgQ2xh aXNlIHdyb3RlOg0KPj4gPj4+PiANCj4+ID4+Pj4+IEkgaG9wZSB0aGF0IG5vYm9keSBkaXNhZ3Jl ZXMgdGhhdCB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgZGVzaWduIGFuZA0KPj4gPj4+Pj5ob3cgDQo+ PiA+Pj4+PiB0byBzdHJ1Y3R1cmUgdGhlIG1vZGVscyBhcmUgdGhlIHR3byBibG9ja2luZyBmYWN0 b3JzIHRvIHB1Ymxpc2gNCj4+WUFORw0KPj4gPj4+Pj4gbW9kZWxzLiBJZiB5b3UgZGlzYWdyZWUg b3IgZG9uJ3Qgc2VlIHRoaXMsIGxldCBtZSBrbm93LCBJIHNob3VsZA0KPj4gPj4+Pj4gY29tbXVu aWNhdGUgYmV0dGVyLg0KPj4gPj4+PiANCj4+ID4+Pj4gRXZlbiBpZiBpdCBtYXkgc3BvaWwgeW91 ciBkYXksIEkgZGlzYWdyZWUgdGhhdCB0aGVyZSBpcyBhIGJsb2NraW5nDQo+PiA+Pj4+IGZhY3Rv ciB0aGF0IHNob3VsZCBzdG9wIHVzIGZyb20gcHVibGlzaGluZyBtb2RlbHMuIFRoZXJlIHNlZW0g dG8gYmUNCj4+ID4+Pj4gd2F5cyB0byBhZGRyZXNzIHRoZSByZXF1aXJlbWVudHMgd2l0aG91dCBo YXZpbmcgdG8gYmxvY2sgYWxsIHdvcmsNCj4+b3INCj4+ID4+Pj4gdG8gcmVkbyB3aGF0IHRoYXQg d2UgaGF2ZSBwdWJsaXNoZWQuIEJ1dCBzdXJlLCBpZiB5b3UgbWFrZSBpdCBhDQo+PiA+Pj4+IGJs b2NraW5nIGZhY3RvciwgaXQgd2lsbCBiZSBvbmUuDQo+PiA+Pj4gDQo+PiA+Pj4gSSBhZ3JlZSB3 aXRoIEp1ZXJnZW4uIEl0IGlzIG5vdCBjbGVhciB0byBtZSBob3cgdGhlIHByb3Bvc2VkIHNwbGl0 DQo+PiA+Pj5iZXR3ZWVuIGludGVuZGVkIGFuZCBhcHBsaWVkIGNvbmZpZ3VyYXRpb24gaXMgc3Vw cG9zZWQgdG8gYWZmZWN0IHRoZQ0KPj4gPj4+ZGF0YSBtb2RlbHMgd2UgYXJlIHdvcmtpbmcgb24u DQo+PiA+PiANCj4+ID4+IA0KPj4gPj4gQXMgSSB1bmRlcnN0YW5kIGl0LCBzb2x1dGlvbiAjMSBh ZmZlY3RzIHRoZSBtb2RlbHMgdGhlbXNlbHZlcywNCj4+d2hlcmVhcw0KPj4gPj5zb2x1dGlvbnMg IzIgYW5kICMzIGFyZSB0cmFuc3BhcmVudCB0byB0aGUgbW9kZWxzLg0KPj4gPg0KPj4gPlRoZW4g IzEgbG9va3MgbGlrZSBhIG5vbi1zdGFydGVyIHRvIG1lLg0KPj4gDQo+PiBJ4oCZZCBsaWtlIHRv IHBvaW50IG91dCB0aGF0IHdlIGFsc28gaGF2ZSB0aGUgcmVxdWlyZW1lbnQgdG8gYWxsb3cNCj4+ cmV0cmlldmFsDQo+PiBvZiBkZXJpdmVkLXN0YXRlIGFsb25nIHdpdGggaW50ZW5kZWQtY29uZmln IGFuZCBhcHBsaWVkLWNvbmZpZy4gVGhpcw0KPj53aWxsDQo+PiByZXF1aXJlIG1vZGlmaWNhdGlv biB0byBtb3N0IG9mIHRoZSBleGlzdGluZyBZQU5HIGRyYWZ0cyBhcyBtb3N0IG5vdw0KPj5oYXZl DQo+PiBzZXBhcmF0ZSB0cmVlcyBmb3IgY29uZmlnIGFuZCBvcGVyYXRpb25hbCBzdGF0ZS4NCj4N Cj5JIGRvbid0IGFncmVlIHdpdGggdGhlIGNvbmNsdXNpb24gdGhhdCBjaGFuZ2VzIGFyZSBuZWVk ZWQgZHVlIHRvIHRoaXMNCj5yZXF1aXJlbWVudC4NCj4NCj5Tb2x1dGlvbiAjMSAoIm9wZW5jb25m aWciKSByZXF1aXJlcyBjaGFuZ2VzIHRvIGhhbmRsZSBhcHBsaWVkIGNvbmZpZy4NCj5Tb2x1dGlv biAjMiAoImtlbnQncyIpIGRvZXMgbm90Lg0KPg0KPkJvdGggc29sdXRpb25zICMxIGFuZCAjMiB1 c2Ugc2VwYXJhdGUgbm9kZXMgZm9yIGRlcml2ZWQgc3RhdGUuDQo+DQo+SXQgbWlnaHQgYXBwZWFy IGFzICMxIGFuZCAjMiBhcmUgdmVyeSBkaWZmZXJlbnQgaW4gdGhlaXIgaGFuZGxpbmcgb2YNCj5k ZXJpdmVkIHN0YXRlLCBzaW5jZSAjMSBwdXQgYWxsIGNvbmZpZyBmYWxzZSBub2RlcyBkaXJlY3Rs eSB1bmRlciB0aGUNCj5jb25maWcgdHJ1ZSBub2Rlcywgd2hlcmVhcyAjMiBpbiBzb21lIGNhc2Vz IGhhdmUgYSB0b3AtbGV2ZWwNCj4ieHh4LXN0YXRlIiBjb25maWcgZmFsc2Ugbm9kZS4NCj4NCj5C dXQgaW4gZmFjdCAjMiBhbGxvd3MgdGhlIHNvbHV0aW9uIGluICMxIGFzIG9uZSBzcGVjaWFsIGNh c2UuICBUaGUNCj5yZWFzb24gdGhhdCBSRkMgNzIyMyBoYXMgYSBzZXBhcmF0ZSBsaXN0IGZvciBk ZXJpdmVkIHN0YXRlIGludGVyZmFjZXMNCj5pcyB0byBhbGxvdyBmb3Igbm9uLWNvbmZpZ3VyZWQg aW50ZXJmYWNlcyB0byBiZSBtb25pdG9yZWQuICBJZiB0aGlzDQo+d2FzIG5vdCBhIHJlcXVpcmVt ZW50LCBhbGwgY29uZmlnIGZhbHNlIG5vZGVzIGNvdWxkICh3b3VsZCkgaGF2ZSBiZWVuDQo+ZGVm aW5lZCBpbiB0aGUgY29uZmlnIHRydWUgaW50ZXJmYWNlIGxpc3QuDQoNCkkgc2VlIHRoYXQgdGhp cyBpcyBkaXNjdXNzZWQgaW4gdGhlIGxhdGVzdCB2ZXJzaW9uIG9mDQpkcmFmdC1pZXRmLW5ldG1v ZC1yZmM2MDg3YmlzLTA1LnR4dCBhbmQgdGhhdCBpdCBpcyDigJxhcHByb3ByaWF0ZSIgdG8gcHV0 DQp0aGUgb3BlcmF0aW9uYWwgc3RhdGUgaW4gdGhlIHNhbWUgc3VidHJlZSBhcyB0aGUgY29uZmln IHN0YXRlIGlmIGl0IHdvdWxkDQpub3QgZXhpc3QgaWYgbm90IGNvbmZpZ3VyZWQuIElzIOKAnGFw cHJvcHJpYXRl4oCdIGEgcmVjb21tZW5kYXRpb24/DQoNCiAgIENhcmVmdWwgY29uc2lkZXJhdGlv biBuZWVkcyB0byBiZSBnaXZlbiB0byB0aGUgbG9jYXRpb24gb2YNCiAgIG9wZXJhdGlvbmFsIHN0 YXRlIGRhdGEuICBJdCBjYW4gZWl0aGVyIGJlIGxvY2F0ZWQgd2l0aGluIHRoZQ0KICAgY29uZmln dXJhdGlvbiBzdWJ0cmVlIGZvciB3aGljaCBpdCBhcHBsaWVzLCBvciBpdCBjYW4gYmUgbG9jYXRl ZA0KICAgb3V0c2lkZSB0aGUgcGFydGljdWxhciBjb25maWd1cmF0aW9uIHN1YnRyZWUuICBQbGFj aW5nIG9wZXJhdGlvbg0KICAgc3RhdGUgd2l0aGluIHRoZSBjb25maWd1cmF0aW9uIHN1YnRyZWUg aXMgYXBwcm9wcmlhdGUgaWYgdGhlDQogICBvcGVyYXRpb25hbCB2YWx1ZXMgY2FuIG9ubHkgZXhp c3QgaWYgdGhlIGNvbmZpZ3VyYXRpb24gZXhpc3RzLg0KDQoNCkhvd2V2ZXIsIHdlIGN1cnJlbnRs eSBoYXZlIG1hbnkgWUFORyBtb2RlbHMgaW4gcHJvZ3Jlc3Mgd2hlcmUgdGhlIGNvbmZpZw0KYW5k IHN0YXRlIHRyZWVzIGFyZSBzZXBhcmF0ZSBzdWJ0cmVlcy4gSWYgd2UgYWxsIGFncmVlIHdpdGgg dGhlIG9wc3RhdGUNCnJlcXVpcmVtZW50IGZvciBkZXJpdmVkIHN0YXRlLCBwZXJoYXBzIGl0IGlz IHRpbWUgdG8gZ2V0IHRoZSB3b3JkIG91dCBhbmQNCm1vZGlmeSB0aGVzZSBtb2RlbHMuDQoNClRo YW5rcywNCkFjZWUgDQoNCg0KDQo+DQo+DQo+L21hcnRpbg0KDQo= From nobody Fri Jan 8 05:06:10 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 716CF1B29B8 for ; Fri, 8 Jan 2016 05:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrWM3gtQxZrk for ; Fri, 8 Jan 2016 05:06: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 845D31B29B9 for ; Fri, 8 Jan 2016 05:06:06 -0800 (PST) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 35E4D181ACC; Fri, 8 Jan 2016 14:06:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452258365; bh=Ko27ArbueIeH/hfgBWgak+QcOWnUslvzUgnI35hTGfY=; h=From:Date:To; b=K3J+gHa/EZhQjmjlzSBEOpagEg/0FKpD7/kivhGztNIItxkM8Glnr54kys+rqjVUm GWDidl1hTKz9+NIfdRdYUUQxmrPcslqtmMN5jrdpG9eNFg2MqCFHNtGz8jAviyMQYv Z0rHJmysM4ZsjRj6e69ZEjX5Rv+y+xbHRc4kMakQ= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160108.135311.1322994157154983529.mbj@tail-f.com> Date: Fri, 8 Jan 2016 14:06:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <568E9F5D.3030500@cisco.com> <20160108083659.GA29486@elstar.local> <20160108.135311.1322994157154983529.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 13:06:08 -0000 > On 08 Jan 2016, at 13:53, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >> Juergen Schoenwaelder writes: >>=20 >>> On Thu, Jan 07, 2016 at 05:24:45PM +0000, Robert Wilton wrote: >>>> Hi Juergen, >>>>=20 >>>> On 07/01/2016 16:05, Juergen Schoenwaelder wrote: >>>>> On Wed, Jan 06, 2016 at 06:18:46PM +0000, Kent Watsen wrote: >>>>>> It=E2=80=99s true that the draft is largely centered around the=20= >>>>>> intended/applied config notion, but not exclusively. = Specifically, 4-B=20 >>>>>> has "Ability to map intended config nodes to associated derived = state=20 >>>>>> nodes". I think that this might be the only exclusion though = and, if it=20 >>>>>> weren=E2=80=99t for it I would=E2=80=99ve used your title = suggestion from the LC=20 >>>>>> review. Should one requirement have such influence over the = title is=20 >>>>>> the question. I was trying to be fair to it, but maybe it's = going too=20 >>>>>> far. >>>>>>=20 >>>>>> Regarding visibility and control, I was attempting to use common = words=20 >>>>>> (not normative terms) here. My intent for them is something = along the=20 >>>>>> lines of: >>>>>>=20 >>>>>> visibility: read/understand >>>>>> control: write/orchestrate >>>>>>=20 >>>>> We do not write operational state. I have no clue how = 'orchestrate' >>>>> helps me either. What is wrong with using defined terminology in >>>>> a title? >>>> I don't think that using defined terminology is a problem. But I = also=20 >>>> think that the title that you have suggested seems to suggest a = narrower=20 >>>> scope that what the requirements articulate. >>>>=20 >>>> In particular, the draft places requirements relating the = configuration=20 >>>> to the derived state (I.e. Req 4B). >>>>=20 >>>> It also places further requirements on how management protocols are=20= >>>> expected to handle synchronous and asynchronous config edit = requests.=20 >>>> (E.g. Req 2 A, B, C and associated definitions). >>>=20 >>> Note that synchronous and asynchronous are defined in terms of >>> intended / applied configuration. >>>=20 >>>> I don't have a particular problem with the current title, but if = you=20 >>>> don't like visibility/control, then perhaps "Terminology and=20 >>>> Requirements for Enhanced Handling of Operational State"? >>>=20 >>> Better but I still think this proposal is too broad given the = content >>> of the document. I still believe my proposal is right to the point. >>=20 >> +1 >>=20 >> The draft talks about introducing applied configuration and its >> relationship to state data and intended configuration (which, I = believe, >> is the good old "running"). I don't see any enhanced handling of >> operational state. >=20 > Well, the applied config is part of the operational state, and there According to 6020bis, state data are tagged with "config false" in YANG = modules. I don't think it is going to be the case of applied = configuration. Lada > are requirements for retrieval of the operational state. So it is > related. I think the current title is fine. >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jan 8 05:10:25 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339CB1A8980 for ; Fri, 8 Jan 2016 05:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiAQZz5nXCl9 for ; Fri, 8 Jan 2016 05:10:21 -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 19B111A8942 for ; Fri, 8 Jan 2016 05:10:21 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:d525:33e4:bc78:8665] (unknown [IPv6:2001:718:1a02:1:d525:33e4:bc78:8665]) by mail.nic.cz (Postfix) with ESMTPSA id C0198181BA7; Fri, 8 Jan 2016 14:10:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452258619; bh=uh37jrFTKi9Ygvt3vrsr6OKFTuTLB0PefOXZxNADTpU=; h=From:Date:To; b=TeAl/UZ2zTz42vaOIYguxccHMVNavWhsoN4bOsWpRGiTtcZKW0qA8Hh0iVBntaE9+ rLgg7b+SriVx7XUAYnsbteG01b7EFRYNjqVnbBGUseGoPevPVFQDQ32KbVOQE28SmD OKRATxmz21iPUIpJeph0y93nQWm2qshune5vt2Sc= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 8 Jan 2016 14:10:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6AFC7C6C-61B7-4310-A0CA-08A7CD76A899@nic.cz> <20160108.085447.1699532851849652427.mbj@tail-f.com> To: "Acee Lindem (acee)" X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 13:10:23 -0000 > On 08 Jan 2016, at 13:57, Acee Lindem (acee) wrote: >=20 > Hi Martin, et al,=20 >=20 > On 1/8/16, 2:54 AM, "Martin Bjorklund" wrote: >=20 >> Hi, >>=20 >> "Acee Lindem (acee)" wrote: >>>=20 >>> On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav Lhotka" >>> wrote: >>>=20 >>>>=20 >>>>> On 23 Dec 2015, at 04:06, Kent Watsen wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka" >>>>> wrote: >>>>>=20 >>>>>>=20 >>>>>>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder >>>>>>> wrote: >>>>>>>=20 >>>>>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote: >>>>>>>=20 >>>>>>>> I hope that nobody disagrees that the operational state design = and >>>>>>>> how=20 >>>>>>>> to structure the models are the two blocking factors to publish >>> YANG >>>>>>>> models. If you disagree or don't see this, let me know, I = should >>>>>>>> communicate better. >>>>>>>=20 >>>>>>> Even if it may spoil your day, I disagree that there is a = blocking >>>>>>> factor that should stop us from publishing models. There seem to = be >>>>>>> ways to address the requirements without having to block all = work >>> or >>>>>>> to redo what that we have published. But sure, if you make it a >>>>>>> blocking factor, it will be one. >>>>>>=20 >>>>>> I agree with Juergen. It is not clear to me how the proposed = split >>>>>> between intended and applied configuration is supposed to affect = the >>>>>> data models we are working on. >>>>>=20 >>>>>=20 >>>>> As I understand it, solution #1 affects the models themselves, >>> whereas >>>>> solutions #2 and #3 are transparent to the models. >>>>=20 >>>> Then #1 looks like a non-starter to me. >>>=20 >>> I=E2=80=99d like to point out that we also have the requirement to = allow >>> retrieval >>> of derived-state along with intended-config and applied-config. This >>> will >>> require modification to most of the existing YANG drafts as most now >>> have >>> separate trees for config and operational state. >>=20 >> I don't agree with the conclusion that changes are needed due to this >> requirement. >>=20 >> Solution #1 ("openconfig") requires changes to handle applied config. >> Solution #2 ("kent's") does not. >>=20 >> Both solutions #1 and #2 use separate nodes for derived state. >>=20 >> It might appear as #1 and #2 are very different in their handling of >> derived state, since #1 put all config false nodes directly under the >> config true nodes, whereas #2 in some cases have a top-level >> "xxx-state" config false node. >>=20 >> But in fact #2 allows the solution in #1 as one special case. The >> reason that RFC 7223 has a separate list for derived state interfaces >> is to allow for non-configured interfaces to be monitored. If this >> was not a requirement, all config false nodes could (would) have been >> defined in the config true interface list. >=20 > I see that this is discussed in the latest version of > draft-ietf-netmod-rfc6087bis-05.txt and that it is =E2=80=9Cappropriate"= to put > the operational state in the same subtree as the config state if it = would > not exist if not configured. Is =E2=80=9Cappropriate=E2=80=9D a = recommendation? >=20 > Careful consideration needs to be given to the location of > operational state data. It can either be located within the > configuration subtree for which it applies, or it can be located > outside the particular configuration subtree. Placing operation > state within the configuration subtree is appropriate if the > operational values can only exist if the configuration exists. >=20 >=20 > However, we currently have many YANG models in progress where the = config > and state trees are separate subtrees. If we all agree with the = opstate > requirement for derived state, perhaps it is time to get the word out = and > modify these models. I don't think that we all agree. :-) Lada >=20 > Thanks, > Acee=20 >=20 >=20 >=20 >>=20 >>=20 >> /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jan 8 05:17:29 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA351A8948 for ; Fri, 8 Jan 2016 05:17:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-3tuexxVXGp for ; Fri, 8 Jan 2016 05:17:27 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 142061A8945 for ; Fri, 8 Jan 2016 05:17:27 -0800 (PST) Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id 52F5E1AE047A; Fri, 8 Jan 2016 14:17:26 +0100 (CET) Date: Fri, 08 Jan 2016 14:17:42 +0100 (CET) Message-Id: <20160108.141742.389287274944356770.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20160108.135311.1322994157154983529.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 13:17:28 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+ID4gT24gMDggSmFu IDIwMTYsIGF0IDEzOjUzLCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4gd3JvdGU6 DQo+ID4gDQo+ID4gTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gPj4g SnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHku ZGU+IHdyaXRlczoNCj4gPj4gDQo+ID4+PiBPbiBUaHUsIEphbiAwNywgMjAxNiBhdCAwNToyNDo0 NVBNICswMDAwLCBSb2JlcnQgV2lsdG9uIHdyb3RlOg0KPiA+Pj4+IEhpIEp1ZXJnZW4sDQo+ID4+ Pj4gDQo+ID4+Pj4gT24gMDcvMDEvMjAxNiAxNjowNSwgSnVlcmdlbiBTY2hvZW53YWVsZGVyIHdy b3RlOg0KPiA+Pj4+PiBPbiBXZWQsIEphbiAwNiwgMjAxNiBhdCAwNjoxODo0NlBNICswMDAwLCBL ZW50IFdhdHNlbiB3cm90ZToNCj4gPj4+Pj4+IEl04oCZcyB0cnVlIHRoYXQgdGhlIGRyYWZ0IGlz IGxhcmdlbHkgY2VudGVyZWQgYXJvdW5kIHRoZSANCj4gPj4+Pj4+IGludGVuZGVkL2FwcGxpZWQg Y29uZmlnIG5vdGlvbiwgYnV0IG5vdCBleGNsdXNpdmVseS4gIFNwZWNpZmljYWxseSwNCj4gPj4+ Pj4+IDQtQg0KPiA+Pj4+Pj4gaGFzICJBYmlsaXR5IHRvIG1hcCBpbnRlbmRlZCBjb25maWcgbm9k ZXMgdG8gYXNzb2NpYXRlZCBkZXJpdmVkIHN0YXRlIA0KPiA+Pj4+Pj4gbm9kZXMiLiAgSSB0aGlu ayB0aGF0IHRoaXMgbWlnaHQgYmUgdGhlIG9ubHkgZXhjbHVzaW9uIHRob3VnaCBhbmQsIGlmDQo+ ID4+Pj4+PiBpdA0KPiA+Pj4+Pj4gd2VyZW7igJl0IGZvciBpdCBJIHdvdWxk4oCZdmUgdXNlZCB5 b3VyIHRpdGxlIHN1Z2dlc3Rpb24gZnJvbSB0aGUgTEMgDQo+ID4+Pj4+PiByZXZpZXcuICBTaG91 bGQgb25lIHJlcXVpcmVtZW50IGhhdmUgc3VjaCBpbmZsdWVuY2Ugb3ZlciB0aGUgdGl0bGUgaXMN Cj4gPj4+Pj4+IHRoZSBxdWVzdGlvbi4gIEkgd2FzIHRyeWluZyB0byBiZSBmYWlyIHRvIGl0LCBi dXQgbWF5YmUgaXQncyBnb2luZyB0b28NCj4gPj4+Pj4+IGZhci4NCj4gPj4+Pj4+IA0KPiA+Pj4+ Pj4gUmVnYXJkaW5nIHZpc2liaWxpdHkgYW5kIGNvbnRyb2wsIEkgd2FzIGF0dGVtcHRpbmcgdG8g dXNlIGNvbW1vbiB3b3Jkcw0KPiA+Pj4+Pj4gKG5vdCBub3JtYXRpdmUgdGVybXMpIGhlcmUuICBN eSBpbnRlbnQgZm9yIHRoZW0gaXMgc29tZXRoaW5nIGFsb25nIHRoZQ0KPiA+Pj4+Pj4gbGluZXMg b2Y6DQo+ID4+Pj4+PiANCj4gPj4+Pj4+IAl2aXNpYmlsaXR5OiByZWFkL3VuZGVyc3RhbmQNCj4g Pj4+Pj4+IAljb250cm9sOiB3cml0ZS9vcmNoZXN0cmF0ZQ0KPiA+Pj4+Pj4gDQo+ID4+Pj4+IFdl IGRvIG5vdCB3cml0ZSBvcGVyYXRpb25hbCBzdGF0ZS4gSSBoYXZlIG5vIGNsdWUgaG93ICdvcmNo ZXN0cmF0ZScNCj4gPj4+Pj4gaGVscHMgbWUgZWl0aGVyLiBXaGF0IGlzIHdyb25nIHdpdGggdXNp bmcgZGVmaW5lZCB0ZXJtaW5vbG9neSBpbg0KPiA+Pj4+PiBhIHRpdGxlPw0KPiA+Pj4+IEkgZG9u J3QgdGhpbmsgdGhhdCB1c2luZyBkZWZpbmVkIHRlcm1pbm9sb2d5IGlzIGEgcHJvYmxlbS4gIEJ1 dCBJIGFsc28NCj4gPj4+PiB0aGluayB0aGF0IHRoZSB0aXRsZSB0aGF0IHlvdSBoYXZlIHN1Z2dl c3RlZCBzZWVtcyB0byBzdWdnZXN0IGENCj4gPj4+PiBuYXJyb3dlcg0KPiA+Pj4+IHNjb3BlIHRo YXQgd2hhdCB0aGUgcmVxdWlyZW1lbnRzIGFydGljdWxhdGUuDQo+ID4+Pj4gDQo+ID4+Pj4gSW4g cGFydGljdWxhciwgdGhlIGRyYWZ0IHBsYWNlcyByZXF1aXJlbWVudHMgcmVsYXRpbmcgdGhlDQo+ ID4+Pj4gY29uZmlndXJhdGlvbg0KPiA+Pj4+IHRvIHRoZSBkZXJpdmVkIHN0YXRlIChJLmUuIFJl cSA0QikuDQo+ID4+Pj4gDQo+ID4+Pj4gSXQgYWxzbyBwbGFjZXMgZnVydGhlciByZXF1aXJlbWVu dHMgb24gaG93IG1hbmFnZW1lbnQgcHJvdG9jb2xzIGFyZSANCj4gPj4+PiBleHBlY3RlZCB0byBo YW5kbGUgc3luY2hyb25vdXMgYW5kIGFzeW5jaHJvbm91cyBjb25maWcgZWRpdCByZXF1ZXN0cy4g DQo+ID4+Pj4gKEUuZy4gUmVxIDIgQSwgQiwgQyBhbmQgYXNzb2NpYXRlZCBkZWZpbml0aW9ucyku DQo+ID4+PiANCj4gPj4+IE5vdGUgdGhhdCBzeW5jaHJvbm91cyBhbmQgYXN5bmNocm9ub3VzIGFy ZSBkZWZpbmVkIGluIHRlcm1zIG9mDQo+ID4+PiBpbnRlbmRlZCAvIGFwcGxpZWQgY29uZmlndXJh dGlvbi4NCj4gPj4+IA0KPiA+Pj4+IEkgZG9uJ3QgaGF2ZSBhIHBhcnRpY3VsYXIgcHJvYmxlbSB3 aXRoIHRoZSBjdXJyZW50IHRpdGxlLCBidXQgaWYgeW91IA0KPiA+Pj4+IGRvbid0IGxpa2Ugdmlz aWJpbGl0eS9jb250cm9sLCB0aGVuIHBlcmhhcHMgIlRlcm1pbm9sb2d5IGFuZCANCj4gPj4+PiBS ZXF1aXJlbWVudHMgZm9yIEVuaGFuY2VkIEhhbmRsaW5nIG9mIE9wZXJhdGlvbmFsIFN0YXRlIj8N Cj4gPj4+IA0KPiA+Pj4gQmV0dGVyIGJ1dCBJIHN0aWxsIHRoaW5rIHRoaXMgcHJvcG9zYWwgaXMg dG9vIGJyb2FkIGdpdmVuIHRoZSBjb250ZW50DQo+ID4+PiBvZiB0aGUgZG9jdW1lbnQuIEkgc3Rp bGwgYmVsaWV2ZSBteSBwcm9wb3NhbCBpcyByaWdodCB0byB0aGUgcG9pbnQuDQo+ID4+IA0KPiA+ PiArMQ0KPiA+PiANCj4gPj4gVGhlIGRyYWZ0IHRhbGtzIGFib3V0IGludHJvZHVjaW5nIGFwcGxp ZWQgY29uZmlndXJhdGlvbiBhbmQgaXRzDQo+ID4+IHJlbGF0aW9uc2hpcCB0byBzdGF0ZSBkYXRh IGFuZCBpbnRlbmRlZCBjb25maWd1cmF0aW9uICh3aGljaCwgSQ0KPiA+PiBiZWxpZXZlLA0KPiA+ PiBpcyB0aGUgZ29vZCBvbGQgInJ1bm5pbmciKS4gSSBkb24ndCBzZWUgYW55IGVuaGFuY2VkIGhh bmRsaW5nIG9mDQo+ID4+IG9wZXJhdGlvbmFsIHN0YXRlLg0KPiA+IA0KPiA+IFdlbGwsIHRoZSBh cHBsaWVkIGNvbmZpZyBpcyBwYXJ0IG9mIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSwgYW5kIHRoZXJl DQo+IA0KPiBBY2NvcmRpbmcgdG8gNjAyMGJpcywgc3RhdGUgZGF0YSBhcmUgdGFnZ2VkIHdpdGgg ImNvbmZpZyBmYWxzZSIgaW4NCj4gWUFORyBtb2R1bGVzLiBJIGRvbid0IHRoaW5rIGl0IGlzIGdv aW5nIHRvIGJlIHRoZSBjYXNlIG9mIGFwcGxpZWQNCj4gY29uZmlndXJhdGlvbi4NCg0KUmlnaHQ7 IGJ1dCB0aGlzIHRlcm0gInN0YXRlIGRhdGEiIGlzIG1vcmUgbGlrZSB0aGUgbmV3IHRlcm0gImRl cml2ZWQNCnN0YXRlIiAod2hpY2ggSSB0aGluayBpcyBhIGJpdCB1bmZvcnR1bmF0ZSAtIGRlcml2 ZWQgZnJvbSB3aGF0PykNCg0KDQovbWFydGluDQo= From nobody Fri Jan 8 05:28:20 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95511A896E for ; Fri, 8 Jan 2016 05:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPwv_e67F3Hj for ; Fri, 8 Jan 2016 05:28:17 -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 481D31A896C for ; Fri, 8 Jan 2016 05:28:17 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:d525:33e4:bc78:8665] (unknown [IPv6:2001:718:1a02:1:d525:33e4:bc78:8665]) by mail.nic.cz (Postfix) with ESMTPSA id 58E911810CE; Fri, 8 Jan 2016 14:28:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452259695; bh=mRMro0necKld32DJrm8doyItY7JAMGa26/uqA7Onk9M=; h=From:Date:To; b=HJPxTwZ0uUQLzjK5FRF7kGIQvbCbLVtwhFjBm8jSzaXMm7wmosgY7sobJkadRMyz8 kxpeIP8y6YtBvYBYnEFDJhCRT67kO9+wx4Su7kbs05DbX42nriCBdOjXTvH4WV6Urx ZWksrTIQ1jamXG/SET+V4IV6kmqFXV1MeQNkhP3g= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160108.141742.389287274944356770.mbj@tail-f.com> Date: Fri, 8 Jan 2016 14:28:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4DF5F47D-B82C-4B41-A925-3C6E19C8A0B7@nic.cz> References: <20160108.135311.1322994157154983529.mbj@tail-f.com> <20160108.141742.389287274944356770.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 13:28:19 -0000 > On 08 Jan 2016, at 14:17, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 08 Jan 2016, at 13:53, Martin Bjorklund wrote: >>>=20 >>> Ladislav Lhotka wrote: >>>> Juergen Schoenwaelder = writes: >>>>=20 >>>>> On Thu, Jan 07, 2016 at 05:24:45PM +0000, Robert Wilton wrote: >>>>>> Hi Juergen, >>>>>>=20 >>>>>> On 07/01/2016 16:05, Juergen Schoenwaelder wrote: >>>>>>> On Wed, Jan 06, 2016 at 06:18:46PM +0000, Kent Watsen wrote: >>>>>>>> It=E2=80=99s true that the draft is largely centered around the=20= >>>>>>>> intended/applied config notion, but not exclusively. = Specifically, >>>>>>>> 4-B >>>>>>>> has "Ability to map intended config nodes to associated derived = state=20 >>>>>>>> nodes". I think that this might be the only exclusion though = and, if >>>>>>>> it >>>>>>>> weren=E2=80=99t for it I would=E2=80=99ve used your title = suggestion from the LC=20 >>>>>>>> review. Should one requirement have such influence over the = title is >>>>>>>> the question. I was trying to be fair to it, but maybe it's = going too >>>>>>>> far. >>>>>>>>=20 >>>>>>>> Regarding visibility and control, I was attempting to use = common words >>>>>>>> (not normative terms) here. My intent for them is something = along the >>>>>>>> lines of: >>>>>>>>=20 >>>>>>>> visibility: read/understand >>>>>>>> control: write/orchestrate >>>>>>>>=20 >>>>>>> We do not write operational state. I have no clue how = 'orchestrate' >>>>>>> helps me either. What is wrong with using defined terminology in >>>>>>> a title? >>>>>> I don't think that using defined terminology is a problem. But I = also >>>>>> think that the title that you have suggested seems to suggest a >>>>>> narrower >>>>>> scope that what the requirements articulate. >>>>>>=20 >>>>>> In particular, the draft places requirements relating the >>>>>> configuration >>>>>> to the derived state (I.e. Req 4B). >>>>>>=20 >>>>>> It also places further requirements on how management protocols = are=20 >>>>>> expected to handle synchronous and asynchronous config edit = requests.=20 >>>>>> (E.g. Req 2 A, B, C and associated definitions). >>>>>=20 >>>>> Note that synchronous and asynchronous are defined in terms of >>>>> intended / applied configuration. >>>>>=20 >>>>>> I don't have a particular problem with the current title, but if = you=20 >>>>>> don't like visibility/control, then perhaps "Terminology and=20 >>>>>> Requirements for Enhanced Handling of Operational State"? >>>>>=20 >>>>> Better but I still think this proposal is too broad given the = content >>>>> of the document. I still believe my proposal is right to the = point. >>>>=20 >>>> +1 >>>>=20 >>>> The draft talks about introducing applied configuration and its >>>> relationship to state data and intended configuration (which, I >>>> believe, >>>> is the good old "running"). I don't see any enhanced handling of >>>> operational state. >>>=20 >>> Well, the applied config is part of the operational state, and there >>=20 >> According to 6020bis, state data are tagged with "config false" in >> YANG modules. I don't think it is going to be the case of applied >> configuration. >=20 > Right; but this term "state data" is more like the new term "derived > state" (which I think is a bit unfortunate - derived from what?) For me, operational state exists independently of management interfaces, = applied configuration doesn't - it is an artefact. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jan 8 05:46:50 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622971A897A for ; Fri, 8 Jan 2016 05:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ymbn2WkE9M7j for ; Fri, 8 Jan 2016 05:46:46 -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 B37251B29C5 for ; Fri, 8 Jan 2016 05:46:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6080; q=dns/txt; s=iport; t=1452260806; x=1453470406; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Zqn6B1O+E26M1dBepWm/ku+ToVqSOzgzZjhAZYK0+4o=; b=TomdI26V9oSh1/TVB8pX+xinjePRgBd8Bo8Iruqs0ws8TdRAV47SZgmo Q+FylKaPgUzdnidxls3vfmkJ5+TO0r4MpSb9iL1g/ulQ3qZrMfo5Kcl0V 9OyMFAAGvJjamvV7dOAkdMtzCjhVchRFjlrRA7sLE11rB8wlEk5a2nODB 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAgDovI9W/5ldJa1bA4M6Um0GiFOzX?= =?us-ascii?q?gENgWQYCoUjSgIcgQI4FAEBAQEBAQGBCoQ1AQEEAQEBIBE6BAcOAgIBCBAIAgI?= =?us-ascii?q?mAgICGQwLFRACBAENBYgvDrEUkEEBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBH2KV?= =?us-ascii?q?IRVGAsmglWBSQWXDQGNV4Fch22FMopbg3IBIAEBQoQKcoRZgQgBAQE?= X-IronPort-AV: E=Sophos;i="5.20,538,1444694400"; d="scan'208";a="225592067" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jan 2016 13:46:45 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u08Dkjp5019460 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Jan 2016 13:46:45 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 8 Jan 2016 08:46:44 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Fri, 8 Jan 2016 08:46:44 -0500 From: "Acee Lindem (acee)" To: Ladislav Lhotka , Juergen Schoenwaelder , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt Thread-Index: AQHRRz2nOvQMyiQN+k2oelLD0j5Ct57sRDQAgAFpEwD//63ogIABAY4AgADF9gCAAW0OgIAAFi+AgAD+4QCAAEX5AP//vL0A Date: Fri, 8 Jan 2016 13:46:44 +0000 Message-ID: References: <20160104221700.28629.34622.idtracker@ietfa.amsl.com> <8A6CD12B-8B34-4F7B-83F2-E56361F998AA@juniper.net> <20160105200214.GA24262@elstar.local> <20160106063014.GA25143@elstar.local> <20160107160521.GC28062@elstar.local> <568E9F5D.3030500@cisco.com> <20160108083659.GA29486@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.203] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 13:46:48 -0000 DQoNCk9uIDEvOC8xNiwgNzo0NyBBTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgTGFkaXNsYXYgTGhv dGthIg0KPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBsaG90a2FAbmljLmN6 PiB3cm90ZToNCg0KPkp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29i cy11bml2ZXJzaXR5LmRlPiB3cml0ZXM6DQo+DQo+PiBPbiBUaHUsIEphbiAwNywgMjAxNiBhdCAw NToyNDo0NVBNICswMDAwLCBSb2JlcnQgV2lsdG9uIHdyb3RlOg0KPj4+IEhpIEp1ZXJnZW4sDQo+ Pj4gDQo+Pj4gT24gMDcvMDEvMjAxNiAxNjowNSwgSnVlcmdlbiBTY2hvZW53YWVsZGVyIHdyb3Rl Og0KPj4+ID5PbiBXZWQsIEphbiAwNiwgMjAxNiBhdCAwNjoxODo0NlBNICswMDAwLCBLZW50IFdh dHNlbiB3cm90ZToNCj4+PiA+Pkl04oCZcyB0cnVlIHRoYXQgdGhlIGRyYWZ0IGlzIGxhcmdlbHkg Y2VudGVyZWQgYXJvdW5kIHRoZQ0KPj4+ID4+aW50ZW5kZWQvYXBwbGllZCBjb25maWcgbm90aW9u LCBidXQgbm90IGV4Y2x1c2l2ZWx5LiAgU3BlY2lmaWNhbGx5LA0KPj4+NC1CIA0KPj4+ID4+aGFz ICJBYmlsaXR5IHRvIG1hcCBpbnRlbmRlZCBjb25maWcgbm9kZXMgdG8gYXNzb2NpYXRlZCBkZXJp dmVkDQo+Pj5zdGF0ZSANCj4+PiA+Pm5vZGVzIi4gIEkgdGhpbmsgdGhhdCB0aGlzIG1pZ2h0IGJl IHRoZSBvbmx5IGV4Y2x1c2lvbiB0aG91Z2ggYW5kLA0KPj4+aWYgaXQgDQo+Pj4gPj53ZXJlbuKA mXQgZm9yIGl0IEkgd291bGTigJl2ZSB1c2VkIHlvdXIgdGl0bGUgc3VnZ2VzdGlvbiBmcm9tIHRo ZSBMQw0KPj4+ID4+cmV2aWV3LiAgIFNob3VsZCBvbmUgcmVxdWlyZW1lbnQgaGF2ZSBzdWNoIGlu Zmx1ZW5jZSBvdmVyIHRoZSB0aXRsZQ0KPj4+aXMgDQo+Pj4gPj50aGUgcXVlc3Rpb24uICBJIHdh cyB0cnlpbmcgdG8gYmUgZmFpciB0byBpdCwgYnV0IG1heWJlIGl0J3MgZ29pbmcNCj4+PnRvbyAN Cj4+PiA+PmZhci4NCj4+PiA+Pg0KPj4+ID4+UmVnYXJkaW5nIHZpc2liaWxpdHkgYW5kIGNvbnRy b2wsIEkgd2FzIGF0dGVtcHRpbmcgdG8gdXNlIGNvbW1vbg0KPj4+d29yZHMgDQo+Pj4gPj4obm90 IG5vcm1hdGl2ZSB0ZXJtcykgaGVyZS4gIE15IGludGVudCBmb3IgdGhlbSBpcyBzb21ldGhpbmcg YWxvbmcNCj4+PnRoZSANCj4+PiA+PmxpbmVzIG9mOg0KPj4+ID4+DQo+Pj4gPj4JdmlzaWJpbGl0 eTogcmVhZC91bmRlcnN0YW5kDQo+Pj4gPj4JY29udHJvbDogd3JpdGUvb3JjaGVzdHJhdGUNCj4+ PiA+Pg0KPj4+ID5XZSBkbyBub3Qgd3JpdGUgb3BlcmF0aW9uYWwgc3RhdGUuIEkgaGF2ZSBubyBj bHVlIGhvdyAnb3JjaGVzdHJhdGUnDQo+Pj4gPmhlbHBzIG1lIGVpdGhlci4gV2hhdCBpcyB3cm9u ZyB3aXRoIHVzaW5nIGRlZmluZWQgdGVybWlub2xvZ3kgaW4NCj4+PiA+YSB0aXRsZT8NCj4+PiBJ IGRvbid0IHRoaW5rIHRoYXQgdXNpbmcgZGVmaW5lZCB0ZXJtaW5vbG9neSBpcyBhIHByb2JsZW0u ICBCdXQgSSBhbHNvDQo+Pj4gdGhpbmsgdGhhdCB0aGUgdGl0bGUgdGhhdCB5b3UgaGF2ZSBzdWdn ZXN0ZWQgc2VlbXMgdG8gc3VnZ2VzdCBhDQo+Pj5uYXJyb3dlciANCj4+PiBzY29wZSB0aGF0IHdo YXQgdGhlIHJlcXVpcmVtZW50cyBhcnRpY3VsYXRlLg0KPj4+IA0KPj4+IEluIHBhcnRpY3VsYXIs IHRoZSBkcmFmdCBwbGFjZXMgcmVxdWlyZW1lbnRzIHJlbGF0aW5nIHRoZQ0KPj4+Y29uZmlndXJh dGlvbiANCj4+PiB0byB0aGUgZGVyaXZlZCBzdGF0ZSAoSS5lLiBSZXEgNEIpLg0KPj4+IA0KPj4+ IEl0IGFsc28gcGxhY2VzIGZ1cnRoZXIgcmVxdWlyZW1lbnRzIG9uIGhvdyBtYW5hZ2VtZW50IHBy b3RvY29scyBhcmUNCj4+PiBleHBlY3RlZCB0byBoYW5kbGUgc3luY2hyb25vdXMgYW5kIGFzeW5j aHJvbm91cyBjb25maWcgZWRpdCByZXF1ZXN0cy4NCj4+PiAoRS5nLiBSZXEgMiBBLCBCLCBDIGFu ZCBhc3NvY2lhdGVkIGRlZmluaXRpb25zKS4NCj4+DQo+PiBOb3RlIHRoYXQgc3luY2hyb25vdXMg YW5kIGFzeW5jaHJvbm91cyBhcmUgZGVmaW5lZCBpbiB0ZXJtcyBvZg0KPj4gaW50ZW5kZWQgLyBh cHBsaWVkIGNvbmZpZ3VyYXRpb24uDQo+PiAgDQo+Pj4gSSBkb24ndCBoYXZlIGEgcGFydGljdWxh ciBwcm9ibGVtIHdpdGggdGhlIGN1cnJlbnQgdGl0bGUsIGJ1dCBpZiB5b3UNCj4+PiBkb24ndCBs aWtlIHZpc2liaWxpdHkvY29udHJvbCwgdGhlbiBwZXJoYXBzICJUZXJtaW5vbG9neSBhbmQNCj4+ PiBSZXF1aXJlbWVudHMgZm9yIEVuaGFuY2VkIEhhbmRsaW5nIG9mIE9wZXJhdGlvbmFsIFN0YXRl Ij8NCj4+DQo+PiBCZXR0ZXIgYnV0IEkgc3RpbGwgdGhpbmsgdGhpcyBwcm9wb3NhbCBpcyB0b28g YnJvYWQgZ2l2ZW4gdGhlIGNvbnRlbnQNCj4+IG9mIHRoZSBkb2N1bWVudC4gSSBzdGlsbCBiZWxp ZXZlIG15IHByb3Bvc2FsIGlzIHJpZ2h0IHRvIHRoZSBwb2ludC4NCj4NCj4rMQ0KPg0KPlRoZSBk cmFmdCB0YWxrcyBhYm91dCBpbnRyb2R1Y2luZyBhcHBsaWVkIGNvbmZpZ3VyYXRpb24gYW5kIGl0 cw0KPnJlbGF0aW9uc2hpcCB0byBzdGF0ZSBkYXRhIGFuZCBpbnRlbmRlZCBjb25maWd1cmF0aW9u ICh3aGljaCwgSSBiZWxpZXZlLA0KPmlzIHRoZSBnb29kIG9sZCAicnVubmluZyIpLiBJIGRvbid0 IHNlZSBhbnkgZW5oYW5jZWQgaGFuZGxpbmcgb2YNCj5vcGVyYXRpb25hbCBzdGF0ZS4NCg0KVGhl IGRyYWZ0IGlzIHF1aXRlIHN1Y2NpbmN0IGFuZCBJ4oCZbSBub3Qgc3VyZSBob3cgeW91IGFuZCBK dWVyZ2VuIGRvIG5vdA0KYWdyZWUgdGhhdCB0aGVyZSBhcmUgcmVxdWlyZW1lbnRzIGJleW9uZCBp bnRlbmRlZC9hcHBsaWVkIHN0YXRlLiBQZXJoYXBzDQp5b3UgZG8gbm90IGFncmVlIHdpdGggdGhl bT8gUmVmZXIgdG8gcmVxdWlyZW1lbnRzIDMuKEIgJiBDKSBhbmQgNC4oQiAmIEMpLg0KRm9yIHlv dXIgY29udmVuaWVuY2UsIEnigJl2ZSBleGNlcnB0ZWQgdGhlbSBiZWxvdzoNCg0KDQogICAzLiAg U2VwYXJhdGlvbiBvZiB0aGUgYXBwbGllZCBjb25maWd1cmF0aW9uIGFuZCBkZXJpdmVkIHN0YXRl IGFzcGVjdHMNCiAgICAgICBvZiBvcGVyYXRpb25hbCBzdGF0ZTsgYWJpbGl0eSB0byByZXRyaWV2 ZSB0aGVtIGluZGVwZW5kZW50bHkgYW5kDQogICAgICAgdG9nZXRoZXINCg0KICAgICAgIEEuICBC ZSBhYmxlIHRvIHJldHJpZXZlIG9ubHkgdGhlIGFwcGxpZWQgY29uZmlndXJhdGlvbiBhc3BlY3Rz IG9mDQogICAgICAgICAgIG9wZXJhdGlvbmFsIHN0YXRlDQoNCiAgICAgICBCLiAgQmUgYWJsZSB0 byByZXRyaWV2ZSBvbmx5IHRoZSBkZXJpdmVkIHN0YXRlIGFzcGVjdHMgb2YNCiAgICAgICAgICAg b3BlcmF0aW9uYWwgc3RhdGUNCg0KICAgICAgIEMuICBCZSBhYmxlIHRvIHJldHJpZXZlIGJvdGgg dGhlIGFwcGxpZWQgY29uZmlndXJhdGlvbiBhbmQNCiAgICAgICAgICAgZGVyaXZlZCBzdGF0ZSBh c3BlY3RzIG9mIG9wZXJhdGlvbmFsIHN0YXRlIHRvZ2V0aGVyDQoNCiAgIDQuICBBYmlsaXR5IHRv IHJlbGF0ZSBjb25maWd1cmF0aW9uIHdpdGggaXRzIGNvcnJlc3BvbmRpbmcNCiAgICAgICBvcGVy YXRpb25hbCBzdGF0ZQ0KDQogICAgICAgQS4gIEFiaWxpdHkgdG8gbWFwIGludGVuZGVkIGNvbmZp ZyBub2RlcyB0byBjb3JyZXNwb25kaW5nIGFwcGxpZWQNCiAgICAgICAgICAgY29uZmlnIG5vZGVz DQoNCiAgICAgICBCLiAgQWJpbGl0eSB0byBtYXAgaW50ZW5kZWQgY29uZmlnIG5vZGVzIHRvIGFz c29jaWF0ZWQgZGVyaXZlZA0KICAgICAgICAgICBzdGF0ZSBub2Rlcw0KDQogICAgICAgQy4gIFRo ZSBtYXBwaW5ncyBuZWVkcyB0byBiZSBwcm9ncmFtbWF0aWNhbGx5IGNvbnN1bWFibGUNCg0KDQpU aGFua3MsDQpBY2VlIA0KDQoNCj4NCj5MYWRhDQo+DQo+Pg0KPj4gL2pzDQo+Pg0KPj4gLS0gDQo+ PiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1l biBnR21iSA0KPj4gUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAx IHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KPj4gRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAg ICAgICA8aHR0cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQo+Pg0KPj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IG5ldG1vZCBtYWlsaW5n IGxpc3QNCj4+IG5ldG1vZEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRtb2QNCj4NCj4tLSANCj5MYWRpc2xhdiBMaG90a2EsIENaLk5JQyBMYWJz DQo+UEdQIEtleSBJRDogRTc0RThDMEMNCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPm5ldG1vZCBtYWlsaW5nIGxpc3QNCj5uZXRtb2RAaWV0Zi5v cmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQo= From nobody Fri Jan 8 06:26:31 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8DCE1B2A0D for ; Fri, 8 Jan 2016 06:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrXTgYPnUHOL for ; Fri, 8 Jan 2016 06:26:27 -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 B5ADD1B2A0B for ; Fri, 8 Jan 2016 06:26:26 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:d525:33e4:bc78:8665] (unknown [IPv6:2001:718:1a02:1:d525:33e4:bc78:8665]) by mail.nic.cz (Postfix) with ESMTPSA id EE0C4181BA4; Fri, 8 Jan 2016 15:26:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452263185; bh=FNiKvqF1Zj+t0YiYk4JjZ6aA6aLi+yVgGcT64YFOtRs=; h=From:Date:To; b=PBg64sYfv6bCNIqsW5i+h0bKN8ssIy2NRzeBqmmd9gAFUKpGnJ4QNOP7bIUTDJGAf Pnwrw8aBu0Uy+uGYmuxY8Z+DF98zKPpB4uB1hNABmf+BYCtQ9IuD1TOsIGhF4LbFcR joGzj2GWSH4wG2xiRjsYVduGgm4kesAx49dpKWGE= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 8 Jan 2016 15:26:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160104221700.28629.34622.idtracker@ietfa.amsl.com> <8A6CD12B-8B34-4F7B-83F2-E56361F998AA@juniper.net> <20160105200214.GA24262@elstar.local> <20160106063014.GA25143@elstar.local> <20160107160521.GC28062@elstar.local> <568E9F5D.3030500@cisco.com> <20160108083659.GA29486@elstar.local> To: "Acee Lindem (acee)" X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 14:26:29 -0000 > On 08 Jan 2016, at 14:46, Acee Lindem (acee) wrote: >=20 >=20 >=20 > On 1/8/16, 7:47 AM, "netmod on behalf of Ladislav Lhotka" > wrote: >=20 >> Juergen Schoenwaelder writes: >>=20 >>> On Thu, Jan 07, 2016 at 05:24:45PM +0000, Robert Wilton wrote: >>>> Hi Juergen, >>>>=20 >>>> On 07/01/2016 16:05, Juergen Schoenwaelder wrote: >>>>> On Wed, Jan 06, 2016 at 06:18:46PM +0000, Kent Watsen wrote: >>>>>> It=E2=80=99s true that the draft is largely centered around the >>>>>> intended/applied config notion, but not exclusively. = Specifically, >>>> 4-B=20 >>>>>> has "Ability to map intended config nodes to associated derived >>>> state=20 >>>>>> nodes". I think that this might be the only exclusion though = and, >>>> if it=20 >>>>>> weren=E2=80=99t for it I would=E2=80=99ve used your title = suggestion from the LC >>>>>> review. Should one requirement have such influence over the = title >>>> is=20 >>>>>> the question. I was trying to be fair to it, but maybe it's = going >>>> too=20 >>>>>> far. >>>>>>=20 >>>>>> Regarding visibility and control, I was attempting to use common >>>> words=20 >>>>>> (not normative terms) here. My intent for them is something = along >>>> the=20 >>>>>> lines of: >>>>>>=20 >>>>>> visibility: read/understand >>>>>> control: write/orchestrate >>>>>>=20 >>>>> We do not write operational state. I have no clue how = 'orchestrate' >>>>> helps me either. What is wrong with using defined terminology in >>>>> a title? >>>> I don't think that using defined terminology is a problem. But I = also >>>> think that the title that you have suggested seems to suggest a >>>> narrower=20 >>>> scope that what the requirements articulate. >>>>=20 >>>> In particular, the draft places requirements relating the >>>> configuration=20 >>>> to the derived state (I.e. Req 4B). >>>>=20 >>>> It also places further requirements on how management protocols are >>>> expected to handle synchronous and asynchronous config edit = requests. >>>> (E.g. Req 2 A, B, C and associated definitions). >>>=20 >>> Note that synchronous and asynchronous are defined in terms of >>> intended / applied configuration. >>>=20 >>>> I don't have a particular problem with the current title, but if = you >>>> don't like visibility/control, then perhaps "Terminology and >>>> Requirements for Enhanced Handling of Operational State"? >>>=20 >>> Better but I still think this proposal is too broad given the = content >>> of the document. I still believe my proposal is right to the point. >>=20 >> +1 >>=20 >> The draft talks about introducing applied configuration and its >> relationship to state data and intended configuration (which, I = believe, >> is the good old "running"). I don't see any enhanced handling of >> operational state. >=20 > The draft is quite succinct and I=E2=80=99m not sure how you and = Juergen do not > agree that there are requirements beyond intended/applied state. = Perhaps > you do not agree with them? Refer to requirements 3.(B & C) and 4.(B & = C). > For your convenience, I=E2=80=99ve excerpted them below: >=20 Well, opstate-reqs defines applied configuration and *proclaims* it to = be a part of operational state, whereas it is a new artefact that has to = do with how the server processes configuration. With two exceptions commented on below, the requirements really are = directly related to the introduction of applied configuration. In other words: for those who don't want to use applied configuration, = there is very little benefit in terms of enhanced handling of = operational state. =20 >=20 > 3. Separation of the applied configuration and derived state = aspects > of operational state; ability to retrieve them independently and > together >=20 > A. Be able to retrieve only the applied configuration aspects = of > operational state >=20 > B. Be able to retrieve only the derived state aspects of > operational state Yes, the inability to retrieve state data separately is a known = shortcoming of NETCONF, and Andy proposed a solution long ago. RESTCONF = has this function out of the box. >=20 > C. Be able to retrieve both the applied configuration and > derived state aspects of operational state together >=20 > 4. Ability to relate configuration with its corresponding > operational state >=20 > A. Ability to map intended config nodes to corresponding = applied > config nodes >=20 > B. Ability to map intended config nodes to associated derived > state nodes This might be useful but I think it will only have a limited value = because it can't capture all possible semantics of such associations. = For example, we can indicate in the data model that static routes are = associated with RIBs, but it won't be possible to specify how = (formally).=20 Lada >=20 > C. The mappings needs to be programmatically consumable >=20 >=20 > Thanks, > Acee=20 >=20 >=20 >>=20 >> Lada >>=20 >>>=20 >>> /js >>>=20 >>> --=20 >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>> Fax: +49 421 200 3103 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> --=20 >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jan 8 06:30:10 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16BAA1A89F6 for ; Fri, 8 Jan 2016 06:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGHlOxr_2G6e for ; Fri, 8 Jan 2016 06:30:07 -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 EB9041A89FA for ; Fri, 8 Jan 2016 06:30:06 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B7EFB752; Fri, 8 Jan 2016 15:30:05 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Foq6qxzwDsjZ; Fri, 8 Jan 2016 15:30:04 +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, 8 Jan 2016 15:30:04 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6D37820058; Fri, 8 Jan 2016 15:30:04 +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 VqjGwTH7_Q7h; Fri, 8 Jan 2016 15:30: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 0D69820055; Fri, 8 Jan 2016 15:30:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8BE22397EAF3; Fri, 8 Jan 2016 15:30:01 +0100 (CET) Date: Fri, 8 Jan 2016 15:30:01 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20160108143001.GB30327@elstar.local> Mail-Followup-To: Ladislav Lhotka , "Acee Lindem (acee)" , "netmod@ietf.org" References: <6AFC7C6C-61B7-4310-A0CA-08A7CD76A899@nic.cz> <20160108.085447.1699532851849652427.mbj@tail-f.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: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 14:30:09 -0000 On Fri, Jan 08, 2016 at 02:10:20PM +0100, Ladislav Lhotka wrote: > > > On 08 Jan 2016, at 13:57, Acee Lindem (acee) wrote: > > > > Hi Martin, et al, > > > > On 1/8/16, 2:54 AM, "Martin Bjorklund" wrote: > > > >> Hi, > >> > >> "Acee Lindem (acee)" wrote: > >>> > >>> On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav Lhotka" > >>> wrote: > >>> > >>>> > >>>>> On 23 Dec 2015, at 04:06, Kent Watsen wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka" > >>>>> wrote: > >>>>> > >>>>>> > >>>>>>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder > >>>>>>> wrote: > >>>>>>> > >>>>>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote: > >>>>>>> > >>>>>>>> I hope that nobody disagrees that the operational state design and > >>>>>>>> how > >>>>>>>> to structure the models are the two blocking factors to publish > >>> YANG > >>>>>>>> models. If you disagree or don't see this, let me know, I should > >>>>>>>> communicate better. > >>>>>>> > >>>>>>> Even if it may spoil your day, I disagree that there is a blocking > >>>>>>> factor that should stop us from publishing models. There seem to be > >>>>>>> ways to address the requirements without having to block all work > >>> or > >>>>>>> to redo what that we have published. But sure, if you make it a > >>>>>>> blocking factor, it will be one. > >>>>>> > >>>>>> I agree with Juergen. It is not clear to me how the proposed split > >>>>>> between intended and applied configuration is supposed to affect the > >>>>>> data models we are working on. > >>>>> > >>>>> > >>>>> As I understand it, solution #1 affects the models themselves, > >>> whereas > >>>>> solutions #2 and #3 are transparent to the models. > >>>> > >>>> Then #1 looks like a non-starter to me. > >>> > >>> I’d like to point out that we also have the requirement to allow > >>> retrieval > >>> of derived-state along with intended-config and applied-config. This > >>> will > >>> require modification to most of the existing YANG drafts as most now > >>> have > >>> separate trees for config and operational state. > >> > >> I don't agree with the conclusion that changes are needed due to this > >> requirement. > >> > >> Solution #1 ("openconfig") requires changes to handle applied config. > >> Solution #2 ("kent's") does not. > >> > >> Both solutions #1 and #2 use separate nodes for derived state. > >> > >> It might appear as #1 and #2 are very different in their handling of > >> derived state, since #1 put all config false nodes directly under the > >> config true nodes, whereas #2 in some cases have a top-level > >> "xxx-state" config false node. > >> > >> But in fact #2 allows the solution in #1 as one special case. The > >> reason that RFC 7223 has a separate list for derived state interfaces > >> is to allow for non-configured interfaces to be monitored. If this > >> was not a requirement, all config false nodes could (would) have been > >> defined in the config true interface list. > > > > I see that this is discussed in the latest version of > > draft-ietf-netmod-rfc6087bis-05.txt and that it is “appropriate" to put > > the operational state in the same subtree as the config state if it would > > not exist if not configured. Is “appropriate” a recommendation? > > > > Careful consideration needs to be given to the location of > > operational state data. It can either be located within the > > configuration subtree for which it applies, or it can be located > > outside the particular configuration subtree. Placing operation > > state within the configuration subtree is appropriate if the > > operational values can only exist if the configuration exists. > > > > > > However, we currently have many YANG models in progress where the config > > and state trees are separate subtrees. If we all agree with the opstate > > requirement for derived state, perhaps it is time to get the word out and > > modify these models. > > I don't think that we all agree. :-) +1 And in many cases, state can exist without config being present. It would be truely backwards if systems would start to hide operational state in order to comply to some new overarching rules to make work with operational state 'easier'. /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 8 07:20:22 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C94491A8A60 for ; Fri, 8 Jan 2016 07:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qu44wWGEcjmI for ; Fri, 8 Jan 2016 07:20:20 -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 9A5FA1A8A51 for ; Fri, 8 Jan 2016 07:20:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5079; q=dns/txt; s=iport; t=1452266419; x=1453476019; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=PLpE/x9kSNQDbnlcyUQd/ot0TWpxIP8ArJymJud/lYM=; b=AgTKufS1cxmyBZvUfO8j9vdLV9Pq4rpWLiMQaAG3Brliza5WTptYLhIh +rsJCPKUJG03zXDDyhMtTC4Th1NZV6lNgBj3c3F/oFP7QMgFMvRGV0qUf Py9o438kXsJh2wCX7aELIEneK9lXRIA9CwRyjH9kRRSzWRWJouILsbgDl g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtBACs0o9W/xbLJq1WCIQMbYhZtTsYC?= =?us-ascii?q?oUjSgKBagEBAQEBAYELhDQBAQEDAQEBATU2ChELGAkWDwkDAgECARUwBgEMBgI?= =?us-ascii?q?BAYgjCA7BVQEBAQEBAQEBAQEBAQEBAQEBAQEWBIZWhH+EMAIMhH4FjTmJVI1Yi?= =?us-ascii?q?SaFVY5OZIQKPjSEFgIeB4EkAQEB?= X-IronPort-AV: E=Sophos;i="5.20,539,1444694400"; d="scan'208";a="624373273" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jan 2016 15:20:17 +0000 Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u08FKHqF008046; Fri, 8 Jan 2016 15:20:17 GMT To: Ladislav Lhotka , NETMOD WG References: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> <568E95B4.1070703@cisco.com> From: Robert Wilton Message-ID: <568FD3B0.2020702@cisco.com> Date: Fri, 8 Jan 2016 15:20:16 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 15:20:21 -0000 Hi Lada, On 08/01/2016 12:30, Ladislav Lhotka wrote: > Robert Wilton writes: > >> Hi Lada, >> >> I think that requirement 1D is fairly key to what is being asked for >> here to allow both the user and system to easily relate between what the >> operator desires and what configuration the system is actually using, > In a way, system-controlled interfaces are default entries in the > interface list - and the system can certainly be using interfaces with > no configuration installed by NETCONF/RESTCONF clients. > >> so I wouldn't be particularly keen on loosening this requirement. > OK, but then IMO this intended-applied dualism is of limited > utility. For many systems or services, asynchronicity is not an option, > or isn't important. I don't really agree. I think that this is plausibly important to anyone who wants to manage network devices in an automated way. Today, when a config request has been processed by NETCONF/YANG then it seems that the only thing the server actually promises is that it might apply the configuration at some point in the future. It makes no guarantees as to whether that configuration has or ever will be successfully applied! The expectation is that the operator can infer from the operational state of the system whether the configuration has been applied (which may not always be possible). Personally, if I was an operator coding to NETCONF/YANG then I would prefer a device that supported the opstate semantics because compliant devices will tell you what configuration that are actually running. This makes it easier to control/manage. I.e. I can easily find out if/when my configuration is applied, and I can easily retrieve any associated operational state. In some cases this may mean that I don't need to check the derived state at all, in other cases it may simplify the checking of the derived state that I need to perform. Again, regarding sync/async, I would also most likely choose async because I perceive that it is simpler to code in a robust fashion. > >> For the ACL example: >> Would it be feasible to change the ACL module to use a leafref to the >> interface name, with the added constraint that you have to at least >> configure the existence of an interface before you can have any >> configuration referring to it? > Well, yes, that's how it is supposed to be done now - also, for example, > for stacking interfaces as in Appendix B of RFC 7223. > > It is not only extra work: the interface list can be locked, so it may > not be possible to immediately create a dummy interface entry and, > consequently, an ACL rule with that interface cannot be configured. In > this sense, using a string rather than a leafref looks like a reasonable > choice. Locking is presumably specifically related to the config protocol being used. As such I don't think that it should be used as a reason to compromise the structure of data model. But having looked at the ACL model a bit more closely, and noticing how input_interface is used, then I agree with Martin, I think that it makes sense for the reference to be an interface-state-ref. > > As Martin pointed out, with YANG 1.1 it would be possible to refer to an > interface entry in state data from configuration. On the other hand, > with "require-instance false" validation won't detect errors in ACL > configuration such as referring to a non-existent interface. True, but for this particular scenario, it wouldn't be any different from matching on the wrong IP address (which also can't be validated by the device in question). Presumably the ACL is still valid even if the input-interface for one ACE doesn't exist. Wouldn't it just mean that one particular ACE entry wouldn't match any packets? Thanks, Rob > > Lada > >> Thanks, >> Rob >> >> >> On 07/01/2016 10:20, Ladislav Lhotka wrote: >>> Hi, >>> >>> a good use of applied configuration could be to formalize the concept of system-controlled entries as defined in RFC 7223, routing-cfg, and probably elsewhere, too. >>> >>> My idea is that system-controlled interfaces or other entries would appear in applied configuration, but not in intended configuration until something needs to be really configured. We could then permit leafrefs from intended configuration to refer to leafs in applied configuration. One case where this would be useful is the ACL module, where match conditions refering to interfaces currently have to use plain strings as references to interface names. >>> >>> However, the above idea seems to be at odds with requirement 1D in opstate-reqs-02. I wonder: could that requirement be relaxed or removed so that the above use case can be supported? >>> >>> Thanks, Lada >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> . >>> From nobody Fri Jan 8 07:42:51 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D40A1A8A8A for ; Fri, 8 Jan 2016 07:42:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QY5EjKZV6-tX for ; Fri, 8 Jan 2016 07:42:47 -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 521B41A8A7D for ; Fri, 8 Jan 2016 07:42:35 -0800 (PST) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 0F05418195E; Fri, 8 Jan 2016 16:42:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452267754; bh=Y7dOz14WmFINDxxNJkAqCe13ZlIftqMqPxcvmGoq6qE=; h=From:Date:To; b=ljJiP2uaLM+zGVmt0Cpq1ZOkWKmNn9n5q7j3X2+O10vZgXumY09wtO00RM26n63QF 7pxXKXKh764VQs8TMuHBeGb7RamRo+qh6YB7ddHIlsNnJjUlMHb1jHjTyp/zVMK9UZ ope+lpxJoA9ILcMBnIZENeQYcuxmd2fJNcSOUSgc= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <568FD3B0.2020702@cisco.com> Date: Fri, 8 Jan 2016 16:42:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> <568E95B4.1070703@cisco.com> <568FD3B0.2020702@cisco.com> To: Robert Wilton X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: NETMOD WG Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 15:42:49 -0000 > On 08 Jan 2016, at 16:20, Robert Wilton wrote: >=20 > Hi Lada, >=20 > On 08/01/2016 12:30, Ladislav Lhotka wrote: >> Robert Wilton writes: >>=20 >>> Hi Lada, >>>=20 >>> I think that requirement 1D is fairly key to what is being asked for >>> here to allow both the user and system to easily relate between what = the >>> operator desires and what configuration the system is actually = using, >> In a way, system-controlled interfaces are default entries in the >> interface list - and the system can certainly be using interfaces = with >> no configuration installed by NETCONF/RESTCONF clients. >>=20 >>> so I wouldn't be particularly keen on loosening this requirement. >> OK, but then IMO this intended-applied dualism is of limited >> utility. For many systems or services, asynchronicity is not an = option, >> or isn't important. > I don't really agree. I think that this is plausibly important to = anyone who wants to manage network devices in an automated way. I am currently working with my colleagues on two use cases: 1. RESTCONF interface to a DNS server that will cover the daemon = configuration, policies for zone signing, and zone provisioning. 2. RESTCONF interface to an OpenWRT-based router. For neither of them applied configuration seems to add any value. >=20 > Today, when a config request has been processed by NETCONF/YANG then = it seems that the only thing the server actually promises is that it = might apply the configuration at some point in the future. It makes no = guarantees as to whether that configuration has or ever The server may simply send a reply only after the configuration has been = completely applied. I understand that with complex devices it is not = possible or practical to wait, but in my use cases it is probably just = the right thing to do. > will be successfully applied! The expectation is that the operator = can infer from the operational state of the system whether the = configuration has been applied (which may not always be possible). >=20 > Personally, if I was an operator coding to NETCONF/YANG then I would = prefer a device that supported the opstate semantics because compliant = devices will tell you what configuration that are actually running. = This makes it easier to control/manage. I.e. I can easily find out = if/when my configuration is applied, and I can easily retrieve any = associated operational state. In some cases this may mean that I don't = need to check the derived state at all, in other cases it may simplify = the checking of the derived state that I need to perform. >=20 > Again, regarding sync/async, I would also most likely choose async = because I perceive that it is simpler to code in a robust fashion. >=20 >>=20 >>> For the ACL example: >>> Would it be feasible to change the ACL module to use a leafref to = the >>> interface name, with the added constraint that you have to at least >>> configure the existence of an interface before you can have any >>> configuration referring to it? >> Well, yes, that's how it is supposed to be done now - also, for = example, >> for stacking interfaces as in Appendix B of RFC 7223. >>=20 >> It is not only extra work: the interface list can be locked, so it = may >> not be possible to immediately create a dummy interface entry and, >> consequently, an ACL rule with that interface cannot be configured. = In >> this sense, using a string rather than a leafref looks like a = reasonable >> choice. > Locking is presumably specifically related to the config protocol = being used. As such I don't think that it should be used as a reason to = compromise the structure of data model. >=20 > But having looked at the ACL model a bit more closely, and noticing = how input_interface is used, then I agree with Martin, I think that it = makes sense for the reference to be an interface-state-ref. >=20 >>=20 >> As Martin pointed out, with YANG 1.1 it would be possible to refer to = an >> interface entry in state data from configuration. On the other hand, >> with "require-instance false" validation won't detect errors in ACL >> configuration such as referring to a non-existent interface. > True, but for this particular scenario, it wouldn't be any different = from matching on the wrong IP address (which also can't be validated by = the device in question). Sure, but my point is that a leafref with require-instance=3Dfalse isn't = that much different from a plain string. Lada >=20 > Presumably the ACL is still valid even if the input-interface for one = ACE doesn't exist. Wouldn't it just mean that one particular ACE entry = wouldn't match any packets? >=20 > Thanks, > Rob >=20 >=20 >>=20 >> Lada >>=20 >>> Thanks, >>> Rob >>>=20 >>>=20 >>> On 07/01/2016 10:20, Ladislav Lhotka wrote: >>>> Hi, >>>>=20 >>>> a good use of applied configuration could be to formalize the = concept of system-controlled entries as defined in RFC 7223, = routing-cfg, and probably elsewhere, too. >>>>=20 >>>> My idea is that system-controlled interfaces or other entries would = appear in applied configuration, but not in intended configuration until = something needs to be really configured. We could then permit leafrefs = from intended configuration to refer to leafs in applied configuration. = One case where this would be useful is the ACL module, where match = conditions refering to interfaces currently have to use plain strings as = references to interface names. >>>>=20 >>>> However, the above idea seems to be at odds with requirement 1D in = opstate-reqs-02. I wonder: could that requirement be relaxed or removed = so that the above use case can be supported? >>>>=20 >>>> Thanks, Lada >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>> . -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Jan 8 08:22:16 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF661B2A22 for ; Fri, 8 Jan 2016 08:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlWrSAMLMY8V for ; Fri, 8 Jan 2016 08:22:13 -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 5F7CB1B2A1F for ; Fri, 8 Jan 2016 08:22:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8036; q=dns/txt; s=iport; t=1452270132; x=1453479732; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=HWaqrdtFrVL5hhumm3o1oYabuxAGNDkeqoEFRFf94lY=; b=VvQqvkEke3rV8MWJQauDxn5njUh/fY+h2z1fYVqJOvCnUWVo1EOvunqC ZhQemoT7x+RdLkzvC8ucjCURLXI+pnbPZn9m+RqvtFzGXQDQoGm9CUNBB TxfAs0pgJSyJlkwi//9U1715p+ZIfhrzx4UXiqdXskt7ry1dz9T1+fc8b c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQC74Y9W/xbLJq1WCIQMbYhZs0kBD?= =?us-ascii?q?YFkGAqFI0oCgVYUAQEBAQEBAYEKhDQBAQEDAQEBATU2CgEFCwsYCRYPCQMCAQI?= =?us-ascii?q?BFTAGDQYCAQGIIwgOwVsBAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZWhH+EMAIMh?= =?us-ascii?q?H4FjTmJVI1YgVyHSoVViluDcyABAUKECj40hBYCHgeBJAEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,539,1444694400"; d="scan'208";a="631488379" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jan 2016 16:22:08 +0000 Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u08GM8qx023273; Fri, 8 Jan 2016 16:22:08 GMT To: Ladislav Lhotka References: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> <568E95B4.1070703@cisco.com> <568FD3B0.2020702@cisco.com> From: Robert Wilton Message-ID: <568FE22F.7040202@cisco.com> Date: Fri, 8 Jan 2016 16:22:07 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: NETMOD WG Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2016 16:22:15 -0000 On 08/01/2016 15:42, Ladislav Lhotka wrote: >> On 08 Jan 2016, at 16:20, Robert Wilton wrote: >> >> Hi Lada, >> >> On 08/01/2016 12:30, Ladislav Lhotka wrote: >>> Robert Wilton writes: >>> >>>> Hi Lada, >>>> >>>> I think that requirement 1D is fairly key to what is being asked for >>>> here to allow both the user and system to easily relate between what the >>>> operator desires and what configuration the system is actually using, >>> In a way, system-controlled interfaces are default entries in the >>> interface list - and the system can certainly be using interfaces with >>> no configuration installed by NETCONF/RESTCONF clients. >>> >>>> so I wouldn't be particularly keen on loosening this requirement. >>> OK, but then IMO this intended-applied dualism is of limited >>> utility. For many systems or services, asynchronicity is not an option, >>> or isn't important. >> I don't really agree. I think that this is plausibly important to anyone who wants to manage network devices in an automated way. > I am currently working with my colleagues on two use cases: > > 1. RESTCONF interface to a DNS server that will cover the daemon configuration, policies for zone signing, and zone provisioning. > > 2. RESTCONF interface to an OpenWRT-based router. > > For neither of them applied configuration seems to add any value. OK. > >> Today, when a config request has been processed by NETCONF/YANG then it seems that the only thing the server actually promises is that it might apply the configuration at some point in the future. It makes no guarantees as to whether that configuration has or ever > The server may simply send a reply only after the configuration has been completely applied. Yes, the server may do this. But the client cannot rely on that behaviour for a NETCONF server today. When I first got involved in the opstate discussions, I mistakenly thought that when a NETCONF server replies to a request it mean that the configuration was applied (for some definition of applied). From my reading of draft-openconfig-netmod-opstate-01 section 4.2, I suspect that the authors were also under that impression. However, several folks on the WG alias have made it clear that this behaviour is not specified by the NETCONF draft. But the nice thing is, if the server complies with the opstate requirements draft, then when the client receives a successful reply to the synchronous configuration request it knows that configuration has actually been applied successfully. It seems to me that these are the semantics that your client code probably desires. Alternatively, perhaps the client code doesn't directly care whether or not the configuration has been successfully applied because it will infer it from the operational state. In this case it can make async requests, with the knowledge that any server should reply to the config request reasonably expediently. From a client perspective, either of these two requests seem to be better than the status quo, where it can infer very little from the result of a request. Two different server implementations may have very different behaviour and hence a robust client has to be coded to assume the least desirable behaviour. > I understand that with complex devices it is not possible or practical to wait, but in my use cases it is probably just the right thing to do. For me, it is about what a client can reasonably assume about the servers behaviour, and I think that the tighter behaviour specified in the opstate requirements means that servers should behave how clients expect them to. > >> will be successfully applied! The expectation is that the operator can infer from the operational state of the system whether the configuration has been applied (which may not always be possible). >> >> Personally, if I was an operator coding to NETCONF/YANG then I would prefer a device that supported the opstate semantics because compliant devices will tell you what configuration that are actually running. This makes it easier to control/manage. I.e. I can easily find out if/when my configuration is applied, and I can easily retrieve any associated operational state. In some cases this may mean that I don't need to check the derived state at all, in other cases it may simplify the checking of the derived state that I need to perform. >> >> Again, regarding sync/async, I would also most likely choose async because I perceive that it is simpler to code in a robust fashion. >> >>>> For the ACL example: >>>> Would it be feasible to change the ACL module to use a leafref to the >>>> interface name, with the added constraint that you have to at least >>>> configure the existence of an interface before you can have any >>>> configuration referring to it? >>> Well, yes, that's how it is supposed to be done now - also, for example, >>> for stacking interfaces as in Appendix B of RFC 7223. >>> >>> It is not only extra work: the interface list can be locked, so it may >>> not be possible to immediately create a dummy interface entry and, >>> consequently, an ACL rule with that interface cannot be configured. In >>> this sense, using a string rather than a leafref looks like a reasonable >>> choice. >> Locking is presumably specifically related to the config protocol being used. As such I don't think that it should be used as a reason to compromise the structure of data model. >> >> But having looked at the ACL model a bit more closely, and noticing how input_interface is used, then I agree with Martin, I think that it makes sense for the reference to be an interface-state-ref. >> >>> As Martin pointed out, with YANG 1.1 it would be possible to refer to an >>> interface entry in state data from configuration. On the other hand, >>> with "require-instance false" validation won't detect errors in ACL >>> configuration such as referring to a non-existent interface. >> True, but for this particular scenario, it wouldn't be any different from matching on the wrong IP address (which also can't be validated by the device in question). > Sure, but my point is that a leafref with require-instance=false isn't that much different from a plain string. Yes, it may not tell you much extra over a plain string, but it still gives a clearer indication as to what the field is. Thanks, Rob > > Lada > >> Presumably the ACL is still valid even if the input-interface for one ACE doesn't exist. Wouldn't it just mean that one particular ACE entry wouldn't match any packets? >> >> Thanks, >> Rob >> >> >>> Lada >>> >>>> Thanks, >>>> Rob >>>> >>>> >>>> On 07/01/2016 10:20, Ladislav Lhotka wrote: >>>>> Hi, >>>>> >>>>> a good use of applied configuration could be to formalize the concept of system-controlled entries as defined in RFC 7223, routing-cfg, and probably elsewhere, too. >>>>> >>>>> My idea is that system-controlled interfaces or other entries would appear in applied configuration, but not in intended configuration until something needs to be really configured. We could then permit leafrefs from intended configuration to refer to leafs in applied configuration. One case where this would be useful is the ACL module, where match conditions refering to interfaces currently have to use plain strings as references to interface names. >>>>> >>>>> However, the above idea seems to be at odds with requirement 1D in opstate-reqs-02. I wonder: could that requirement be relaxed or removed so that the above use case can be supported? >>>>> >>>>> Thanks, Lada >>>>> -- >>>>> Ladislav Lhotka, CZ.NIC Labs >>>>> PGP Key ID: E74E8C0C >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>> . > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > . > From nobody Fri Jan 8 16:33:10 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848721B2CE0 for ; Fri, 8 Jan 2016 16:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MrhnBHncg6Q for ; Fri, 8 Jan 2016 16:33:06 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0146.outbound.protection.outlook.com [65.55.169.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19D471B2CDF for ; Fri, 8 Jan 2016 16:33:05 -0800 (PST) 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 (TLS) id 15.1.365.19; Sat, 9 Jan 2016 00:33:02 +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.0365.020; Sat, 9 Jan 2016 00:33:02 +0000 From: Kent Watsen To: Ladislav Lhotka , "Acee Lindem (acee)" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt Thread-Index: AQHRRz2lEErWj+iSeUCXhpFM5+aasZ7rnI4AgAG85wCAAAG/gIAArbcAgAByIgCAAcDigIAAFjCAgAD+4QCAAEX4AIAAEJIAgAALFoCAAFWqgA== Date: Sat, 9 Jan 2016 00:33:02 +0000 Message-ID: References: <20160104221700.28629.34622.idtracker@ietfa.amsl.com> <8A6CD12B-8B34-4F7B-83F2-E56361F998AA@juniper.net> <20160105200214.GA24262@elstar.local> <20160106063014.GA25143@elstar.local> <20160107160521.GC28062@elstar.local> <568E9F5D.3030500@cisco.com> <20160108083659.GA29486@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/0.0.0.151105 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-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 5:NaK/cPdHPWWn366h7TbosoWbtUA0thScacUntlZJxqgoecwu3UNm2iVVBMbvEhKgBH4YkKGUfrqvtX5+INQodBOSCwDAG+Xf9ghRBtFT0Q3l3HFudlaTzzcxyDOvPuOHLkT1VukOTsWGuKhDWo5kfg==; 24:dhmWPZt3sVcuBbxlliZZk8zWRtAYQo/uuU+Ojv8UuBt4wmhOzXhuTG11eBbEr1bhG7sd/VHLfpl/AYBF/y0mzKKgN/BicAoMabqspG0TJeg= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1443; x-ms-office365-filtering-correlation-id: 3df9a5a9-2e3a-48d0-6724-08d3188c6f2c x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(10201501046)(3002001); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 0816F1D86E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(479174004)(189002)(199003)(24454002)(51444003)(164054003)(106116001)(102836003)(5001960100002)(189998001)(99286002)(81156007)(36756003)(5002640100001)(586003)(561944003)(1096002)(106356001)(93886004)(1220700001)(6116002)(2950100001)(105586002)(4001350100001)(5001770100001)(3846002)(11100500001)(97736004)(575784001)(86362001)(230783001)(87936001)(76176999)(82746002)(122556002)(40100003)(15975445007)(5004730100002)(2906002)(83716003)(10400500002)(83506001)(54356999)(2900100001)(66066001)(77096005)(33656002)(92566002)(101416001)(19580395003)(5008740100001)(50986999)(4326007)(19580405001)(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:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <1C50589650A5C844AB64F3A1A47E86FF@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2016 00:33:02.6384 (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: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2016 00:33:08 -0000 W0FzIGEgY29udHJpYnV0b3JdDQoNCkFzIEkgY291bnQgaXQsIHRoZXJlIGFyZSBmb3VyIGluIGZh dm9yIGFuZCB0d28gbm90IGluIGZhdm9yIG9mIHRoZSB0aXRsZSBwcm9wb3NlZCBieSBSb2JlcnQs IHNvIEnigJltIGdvaW5nIHRvIHBvc3QgLTAzIHdpdGggdGhhdCBvbmUuDQoNCktlbnQNCg0KDQoN Ck9uIDEvOC8xNiwgOToyNiBBTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgTGFkaXNsYXYgTGhvdGth IiA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGxob3RrYUBuaWMuY3o+IHdy b3RlOg0KDQo+DQo+PiBPbiAwOCBKYW4gMjAxNiwgYXQgMTQ6NDYsIEFjZWUgTGluZGVtIChhY2Vl KSA8YWNlZUBjaXNjby5jb20+IHdyb3RlOg0KPj4gDQo+PiANCj4+IA0KPj4gT24gMS84LzE2LCA3 OjQ3IEFNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBMYWRpc2xhdiBMaG90a2EiDQo+PiA8bmV0bW9k LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGxob3RrYUBuaWMuY3o+IHdyb3RlOg0KPj4g DQo+Pj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZl cnNpdHkuZGU+IHdyaXRlczoNCj4+PiANCj4+Pj4gT24gVGh1LCBKYW4gMDcsIDIwMTYgYXQgMDU6 MjQ6NDVQTSArMDAwMCwgUm9iZXJ0IFdpbHRvbiB3cm90ZToNCj4+Pj4+IEhpIEp1ZXJnZW4sDQo+ Pj4+PiANCj4+Pj4+IE9uIDA3LzAxLzIwMTYgMTY6MDUsIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciB3 cm90ZToNCj4+Pj4+PiBPbiBXZWQsIEphbiAwNiwgMjAxNiBhdCAwNjoxODo0NlBNICswMDAwLCBL ZW50IFdhdHNlbiB3cm90ZToNCj4+Pj4+Pj4gSXTigJlzIHRydWUgdGhhdCB0aGUgZHJhZnQgaXMg bGFyZ2VseSBjZW50ZXJlZCBhcm91bmQgdGhlDQo+Pj4+Pj4+IGludGVuZGVkL2FwcGxpZWQgY29u ZmlnIG5vdGlvbiwgYnV0IG5vdCBleGNsdXNpdmVseS4gIFNwZWNpZmljYWxseSwNCj4+Pj4+IDQt QiANCj4+Pj4+Pj4gaGFzICJBYmlsaXR5IHRvIG1hcCBpbnRlbmRlZCBjb25maWcgbm9kZXMgdG8g YXNzb2NpYXRlZCBkZXJpdmVkDQo+Pj4+PiBzdGF0ZSANCj4+Pj4+Pj4gbm9kZXMiLiAgSSB0aGlu ayB0aGF0IHRoaXMgbWlnaHQgYmUgdGhlIG9ubHkgZXhjbHVzaW9uIHRob3VnaCBhbmQsDQo+Pj4+ PiBpZiBpdCANCj4+Pj4+Pj4gd2VyZW7igJl0IGZvciBpdCBJIHdvdWxk4oCZdmUgdXNlZCB5b3Vy IHRpdGxlIHN1Z2dlc3Rpb24gZnJvbSB0aGUgTEMNCj4+Pj4+Pj4gcmV2aWV3LiAgIFNob3VsZCBv bmUgcmVxdWlyZW1lbnQgaGF2ZSBzdWNoIGluZmx1ZW5jZSBvdmVyIHRoZSB0aXRsZQ0KPj4+Pj4g aXMgDQo+Pj4+Pj4+IHRoZSBxdWVzdGlvbi4gIEkgd2FzIHRyeWluZyB0byBiZSBmYWlyIHRvIGl0 LCBidXQgbWF5YmUgaXQncyBnb2luZw0KPj4+Pj4gdG9vIA0KPj4+Pj4+PiBmYXIuDQo+Pj4+Pj4+ IA0KPj4+Pj4+PiBSZWdhcmRpbmcgdmlzaWJpbGl0eSBhbmQgY29udHJvbCwgSSB3YXMgYXR0ZW1w dGluZyB0byB1c2UgY29tbW9uDQo+Pj4+PiB3b3JkcyANCj4+Pj4+Pj4gKG5vdCBub3JtYXRpdmUg dGVybXMpIGhlcmUuICBNeSBpbnRlbnQgZm9yIHRoZW0gaXMgc29tZXRoaW5nIGFsb25nDQo+Pj4+ PiB0aGUgDQo+Pj4+Pj4+IGxpbmVzIG9mOg0KPj4+Pj4+PiANCj4+Pj4+Pj4gCXZpc2liaWxpdHk6 IHJlYWQvdW5kZXJzdGFuZA0KPj4+Pj4+PiAJY29udHJvbDogd3JpdGUvb3JjaGVzdHJhdGUNCj4+ Pj4+Pj4gDQo+Pj4+Pj4gV2UgZG8gbm90IHdyaXRlIG9wZXJhdGlvbmFsIHN0YXRlLiBJIGhhdmUg bm8gY2x1ZSBob3cgJ29yY2hlc3RyYXRlJw0KPj4+Pj4+IGhlbHBzIG1lIGVpdGhlci4gV2hhdCBp cyB3cm9uZyB3aXRoIHVzaW5nIGRlZmluZWQgdGVybWlub2xvZ3kgaW4NCj4+Pj4+PiBhIHRpdGxl Pw0KPj4+Pj4gSSBkb24ndCB0aGluayB0aGF0IHVzaW5nIGRlZmluZWQgdGVybWlub2xvZ3kgaXMg YSBwcm9ibGVtLiAgQnV0IEkgYWxzbw0KPj4+Pj4gdGhpbmsgdGhhdCB0aGUgdGl0bGUgdGhhdCB5 b3UgaGF2ZSBzdWdnZXN0ZWQgc2VlbXMgdG8gc3VnZ2VzdCBhDQo+Pj4+PiBuYXJyb3dlciANCj4+ Pj4+IHNjb3BlIHRoYXQgd2hhdCB0aGUgcmVxdWlyZW1lbnRzIGFydGljdWxhdGUuDQo+Pj4+PiAN Cj4+Pj4+IEluIHBhcnRpY3VsYXIsIHRoZSBkcmFmdCBwbGFjZXMgcmVxdWlyZW1lbnRzIHJlbGF0 aW5nIHRoZQ0KPj4+Pj4gY29uZmlndXJhdGlvbiANCj4+Pj4+IHRvIHRoZSBkZXJpdmVkIHN0YXRl IChJLmUuIFJlcSA0QikuDQo+Pj4+PiANCj4+Pj4+IEl0IGFsc28gcGxhY2VzIGZ1cnRoZXIgcmVx dWlyZW1lbnRzIG9uIGhvdyBtYW5hZ2VtZW50IHByb3RvY29scyBhcmUNCj4+Pj4+IGV4cGVjdGVk IHRvIGhhbmRsZSBzeW5jaHJvbm91cyBhbmQgYXN5bmNocm9ub3VzIGNvbmZpZyBlZGl0IHJlcXVl c3RzLg0KPj4+Pj4gKEUuZy4gUmVxIDIgQSwgQiwgQyBhbmQgYXNzb2NpYXRlZCBkZWZpbml0aW9u cykuDQo+Pj4+IA0KPj4+PiBOb3RlIHRoYXQgc3luY2hyb25vdXMgYW5kIGFzeW5jaHJvbm91cyBh cmUgZGVmaW5lZCBpbiB0ZXJtcyBvZg0KPj4+PiBpbnRlbmRlZCAvIGFwcGxpZWQgY29uZmlndXJh dGlvbi4NCj4+Pj4gDQo+Pj4+PiBJIGRvbid0IGhhdmUgYSBwYXJ0aWN1bGFyIHByb2JsZW0gd2l0 aCB0aGUgY3VycmVudCB0aXRsZSwgYnV0IGlmIHlvdQ0KPj4+Pj4gZG9uJ3QgbGlrZSB2aXNpYmls aXR5L2NvbnRyb2wsIHRoZW4gcGVyaGFwcyAiVGVybWlub2xvZ3kgYW5kDQo+Pj4+PiBSZXF1aXJl bWVudHMgZm9yIEVuaGFuY2VkIEhhbmRsaW5nIG9mIE9wZXJhdGlvbmFsIFN0YXRlIj8NCj4+Pj4g DQo+Pj4+IEJldHRlciBidXQgSSBzdGlsbCB0aGluayB0aGlzIHByb3Bvc2FsIGlzIHRvbyBicm9h ZCBnaXZlbiB0aGUgY29udGVudA0KPj4+PiBvZiB0aGUgZG9jdW1lbnQuIEkgc3RpbGwgYmVsaWV2 ZSBteSBwcm9wb3NhbCBpcyByaWdodCB0byB0aGUgcG9pbnQuDQo+Pj4gDQo+Pj4gKzENCj4+PiAN Cj4+PiBUaGUgZHJhZnQgdGFsa3MgYWJvdXQgaW50cm9kdWNpbmcgYXBwbGllZCBjb25maWd1cmF0 aW9uIGFuZCBpdHMNCj4+PiByZWxhdGlvbnNoaXAgdG8gc3RhdGUgZGF0YSBhbmQgaW50ZW5kZWQg Y29uZmlndXJhdGlvbiAod2hpY2gsIEkgYmVsaWV2ZSwNCj4+PiBpcyB0aGUgZ29vZCBvbGQgInJ1 bm5pbmciKS4gSSBkb24ndCBzZWUgYW55IGVuaGFuY2VkIGhhbmRsaW5nIG9mDQo+Pj4gb3BlcmF0 aW9uYWwgc3RhdGUuDQo+PiANCj4+IFRoZSBkcmFmdCBpcyBxdWl0ZSBzdWNjaW5jdCBhbmQgSeKA mW0gbm90IHN1cmUgaG93IHlvdSBhbmQgSnVlcmdlbiBkbyBub3QNCj4+IGFncmVlIHRoYXQgdGhl cmUgYXJlIHJlcXVpcmVtZW50cyBiZXlvbmQgaW50ZW5kZWQvYXBwbGllZCBzdGF0ZS4gUGVyaGFw cw0KPj4geW91IGRvIG5vdCBhZ3JlZSB3aXRoIHRoZW0/IFJlZmVyIHRvIHJlcXVpcmVtZW50cyAz LihCICYgQykgYW5kIDQuKEIgJiBDKS4NCj4+IEZvciB5b3VyIGNvbnZlbmllbmNlLCBJ4oCZdmUg ZXhjZXJwdGVkIHRoZW0gYmVsb3c6DQo+PiANCj4NCj5XZWxsLCBvcHN0YXRlLXJlcXMgZGVmaW5l cyBhcHBsaWVkIGNvbmZpZ3VyYXRpb24gYW5kICpwcm9jbGFpbXMqIGl0IHRvIGJlIGEgcGFydCBv ZiBvcGVyYXRpb25hbCBzdGF0ZSwgd2hlcmVhcyBpdCBpcyBhIG5ldyBhcnRlZmFjdCB0aGF0IGhh cyB0byBkbyB3aXRoIGhvdyB0aGUgc2VydmVyIHByb2Nlc3NlcyBjb25maWd1cmF0aW9uLg0KPg0K PldpdGggdHdvIGV4Y2VwdGlvbnMgY29tbWVudGVkIG9uIGJlbG93LCB0aGUgcmVxdWlyZW1lbnRz IHJlYWxseSBhcmUgZGlyZWN0bHkgcmVsYXRlZCB0byB0aGUgaW50cm9kdWN0aW9uIG9mIGFwcGxp ZWQgY29uZmlndXJhdGlvbi4NCj4NCj5JbiBvdGhlciB3b3JkczogZm9yIHRob3NlIHdobyBkb24n dCB3YW50IHRvIHVzZSBhcHBsaWVkIGNvbmZpZ3VyYXRpb24sIHRoZXJlIGlzIHZlcnkgbGl0dGxl IGJlbmVmaXQgaW4gdGVybXMgb2YgZW5oYW5jZWQgaGFuZGxpbmcgb2Ygb3BlcmF0aW9uYWwgc3Rh dGUuDQo+IA0KPj4gDQo+PiAgIDMuICBTZXBhcmF0aW9uIG9mIHRoZSBhcHBsaWVkIGNvbmZpZ3Vy YXRpb24gYW5kIGRlcml2ZWQgc3RhdGUgYXNwZWN0cw0KPj4gICAgICAgb2Ygb3BlcmF0aW9uYWwg c3RhdGU7IGFiaWxpdHkgdG8gcmV0cmlldmUgdGhlbSBpbmRlcGVuZGVudGx5IGFuZA0KPj4gICAg ICAgdG9nZXRoZXINCj4+IA0KPj4gICAgICAgQS4gIEJlIGFibGUgdG8gcmV0cmlldmUgb25seSB0 aGUgYXBwbGllZCBjb25maWd1cmF0aW9uIGFzcGVjdHMgb2YNCj4+ICAgICAgICAgICBvcGVyYXRp b25hbCBzdGF0ZQ0KPj4gDQo+PiAgICAgICBCLiAgQmUgYWJsZSB0byByZXRyaWV2ZSBvbmx5IHRo ZSBkZXJpdmVkIHN0YXRlIGFzcGVjdHMgb2YNCj4+ICAgICAgICAgICBvcGVyYXRpb25hbCBzdGF0 ZQ0KPg0KPlllcywgdGhlIGluYWJpbGl0eSB0byByZXRyaWV2ZSBzdGF0ZSBkYXRhIHNlcGFyYXRl bHkgaXMgYSBrbm93biBzaG9ydGNvbWluZyBvZiBORVRDT05GLCBhbmQgQW5keSBwcm9wb3NlZCBh IHNvbHV0aW9uIGxvbmcgYWdvLiBSRVNUQ09ORiBoYXMgdGhpcyBmdW5jdGlvbiBvdXQgb2YgdGhl IGJveC4NCj4NCj4+IA0KPj4gICAgICAgQy4gIEJlIGFibGUgdG8gcmV0cmlldmUgYm90aCB0aGUg YXBwbGllZCBjb25maWd1cmF0aW9uIGFuZA0KPj4gICAgICAgICAgIGRlcml2ZWQgc3RhdGUgYXNw ZWN0cyBvZiBvcGVyYXRpb25hbCBzdGF0ZSB0b2dldGhlcg0KPj4gDQo+PiAgIDQuICBBYmlsaXR5 IHRvIHJlbGF0ZSBjb25maWd1cmF0aW9uIHdpdGggaXRzIGNvcnJlc3BvbmRpbmcNCj4+ICAgICAg IG9wZXJhdGlvbmFsIHN0YXRlDQo+PiANCj4+ICAgICAgIEEuICBBYmlsaXR5IHRvIG1hcCBpbnRl bmRlZCBjb25maWcgbm9kZXMgdG8gY29ycmVzcG9uZGluZyBhcHBsaWVkDQo+PiAgICAgICAgICAg Y29uZmlnIG5vZGVzDQo+PiANCj4+ICAgICAgIEIuICBBYmlsaXR5IHRvIG1hcCBpbnRlbmRlZCBj b25maWcgbm9kZXMgdG8gYXNzb2NpYXRlZCBkZXJpdmVkDQo+PiAgICAgICAgICAgc3RhdGUgbm9k ZXMNCj4NCj5UaGlzIG1pZ2h0IGJlIHVzZWZ1bCBidXQgSSB0aGluayBpdCB3aWxsIG9ubHkgaGF2 ZSBhIGxpbWl0ZWQgdmFsdWUgYmVjYXVzZSBpdCBjYW4ndCBjYXB0dXJlIGFsbCBwb3NzaWJsZSBz ZW1hbnRpY3Mgb2Ygc3VjaCBhc3NvY2lhdGlvbnMuIEZvciBleGFtcGxlLCB3ZSBjYW4gaW5kaWNh dGUgaW4gdGhlIGRhdGEgbW9kZWwgdGhhdCBzdGF0aWMgcm91dGVzIGFyZSBhc3NvY2lhdGVkIHdp dGggUklCcywgYnV0IGl0IHdvbid0IGJlIHBvc3NpYmxlIHRvIHNwZWNpZnkgaG93IChmb3JtYWxs eSkuIA0KPg0KPkxhZGENCj4NCj4NCj4+IA0KPj4gICAgICAgQy4gIFRoZSBtYXBwaW5ncyBuZWVk cyB0byBiZSBwcm9ncmFtbWF0aWNhbGx5IGNvbnN1bWFibGUNCj4+IA0KPj4gDQo+PiBUaGFua3Ms DQo+PiBBY2VlIA0KPj4gDQo+PiANCj4+PiANCj4+PiBMYWRhDQo+Pj4gDQo+Pj4+IA0KPj4+PiAv anMNCj4+Pj4gDQo+Pj4+IC0tIA0KPj4+PiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAg IEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPj4+PiBQaG9uZTogKzQ5IDQyMSAyMDAg MzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQo+Pj4+ IEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZl cnNpdHkuZGUvPg0KPj4+PiANCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4+PiBuZXRtb2RAaWV0 Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QN Cj4+PiANCj4+PiAtLSANCj4+PiBMYWRpc2xhdiBMaG90a2EsIENaLk5JQyBMYWJzDQo+Pj4gUEdQ IEtleSBJRDogRTc0RThDMEMNCj4+PiANCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4+PiBuZXRtb2RA aWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1v ZA0KPg0KPi0tDQo+TGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPlBHUCBLZXkgSUQ6IEU3 NEU4QzBDDQo+DQo+DQo+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj5uZXRtb2QgbWFpbGluZyBsaXN0DQo+bmV0bW9kQGlldGYub3JnDQo+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg== From nobody Fri Jan 8 16:58:31 2016 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 63CE91B2D22; Fri, 8 Jan 2016 16:58:30 -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.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160109005830.20805.41463.idtracker@ietfa.amsl.com> Date: Fri, 08 Jan 2016 16:58:30 -0800 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2016 00:58:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : Terminology and Requirements for Enhanced Handling of Operational State Authors : Kent Watsen Thomas Nadeau Filename : draft-ietf-netmod-opstate-reqs-03.txt Pages : 7 Date : 2016-01-08 Abstract: This document primarily regards the difference between the intended configuration and the applied configuration of a device and how intended and applied configuration relate to the operational state of a device. This document defines requirements for the applied configuration's data model and its values, as well as for enabling a client to know when a configuration has been fully applied or not, how to access operational state, and how to relate intended configuration nodes to applied configuration and derived state nodes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-opstate-reqs-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 8 17:00:56 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 326041B2D0A for ; Fri, 8 Jan 2016 17:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJwSNWnriQoS for ; Fri, 8 Jan 2016 17:00:52 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0733.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:733]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 999291B2D02 for ; Fri, 8 Jan 2016 17:00:52 -0800 (PST) Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1444.namprd05.prod.outlook.com (10.160.117.153) with Microsoft SMTP Server (TLS) id 15.1.365.19; Sat, 9 Jan 2016 01:00:35 +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.0365.020; Sat, 9 Jan 2016 01:00:35 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-03.txt Thread-Index: AQHRSnjhPwhlEKSCNkWPsuBEQbmSJJ7yCYMA Date: Sat, 9 Jan 2016 01:00:34 +0000 Message-ID: References: <20160109005830.20805.41463.idtracker@ietfa.amsl.com> In-Reply-To: <20160109005830.20805.41463.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151105 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-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 5:vcNqwXTmfnfLwBd68Kf4C0uqQaLBc/6fud0/9tX1SaiJ/0lYGj9w5VmgwIAJBAB2kS28bNWavqB8/E1XcmcPgjZ90LSh61qocyjMTSL/I4k8aOqSCpY4td4QohrIJOMxIW/vzVj7GOZi9Yy2FPa9mg==; 24:bylpTC9iXV5iMzwSs4thxUIemwLi+ez/BgVpxjEdRRCqrsrXeFv2pByNwgCymK0sHKcG7W/AtxpqshDWoYpbkMy82qaGTcaQShHf5kUO3lw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1444; x-ms-office365-filtering-correlation-id: e21a2ba5-316d-4aa2-d2de-08d31890482b x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001)(10201501046); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 0816F1D86E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(189002)(377424004)(479174004)(24454002)(199003)(36756003)(40100003)(2501003)(97736004)(5004730100002)(86362001)(2900100001)(122556002)(5002640100001)(107886002)(110136002)(189998001)(19580395003)(5001960100002)(15975445007)(11100500001)(450100001)(76176999)(50986999)(54356999)(5008740100001)(77096005)(19580405001)(87936001)(83716003)(66066001)(106356001)(106116001)(1730700002)(10400500002)(2351001)(82746002)(33656002)(6116002)(2906002)(81156007)(4001350100001)(102836003)(2950100001)(3846002)(230783001)(105586002)(83506001)(92566002)(586003)(1096002)(101416001)(1220700001)(99286002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; 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:23 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: 09 Jan 2016 01:00:34.9091 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1444 Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2016 01:00:56 -0000 DQpJbiBhZGRpdGlvbiB0byB0aGUgdGl0bGUgdXBkYXRlLCBJIGFsc28gdXBkYXRlZCB0aGUgYWJz dHJhY3QvaW50cm9kdWN0aW9uIGFuZCBmaXhlZCBhIGNvdXBsZSBlZGl0b3JpYWwgaXRlbXMuDQoN CktlbnQNCg0KDQoNCg0KT24gMS84LzE2LCA3OjU4IFBNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhh bGYgb2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiB3cm90ZToNCg0KPg0KPkEgTmV3IEludGVy bmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBk aXJlY3Rvcmllcy4NCj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgTkVUQ09ORiBE YXRhIE1vZGVsaW5nIExhbmd1YWdlIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+DQo+ICAg ICAgICBUaXRsZSAgICAgICAgICAgOiBUZXJtaW5vbG9neSBhbmQgUmVxdWlyZW1lbnRzIGZvciBF bmhhbmNlZCBIYW5kbGluZyBvZiBPcGVyYXRpb25hbCBTdGF0ZQ0KPiAgICAgICAgQXV0aG9ycyAg ICAgICAgIDogS2VudCBXYXRzZW4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgIFRob21hcyBO YWRlYXUNCj4JRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1uZXRtb2Qtb3BzdGF0ZS1yZXFz LTAzLnR4dA0KPglQYWdlcyAgICAgICAgICAgOiA3DQo+CURhdGUgICAgICAgICAgICA6IDIwMTYt MDEtMDgNCj4NCj5BYnN0cmFjdDoNCj4gICBUaGlzIGRvY3VtZW50IHByaW1hcmlseSByZWdhcmRz IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIGludGVuZGVkDQo+ICAgY29uZmlndXJhdGlvbiBh bmQgdGhlIGFwcGxpZWQgY29uZmlndXJhdGlvbiBvZiBhIGRldmljZSBhbmQgaG93DQo+ICAgaW50 ZW5kZWQgYW5kIGFwcGxpZWQgY29uZmlndXJhdGlvbiByZWxhdGUgdG8gdGhlIG9wZXJhdGlvbmFs IHN0YXRlIG9mDQo+ICAgYSBkZXZpY2UuICBUaGlzIGRvY3VtZW50IGRlZmluZXMgcmVxdWlyZW1l bnRzIGZvciB0aGUgYXBwbGllZA0KPiAgIGNvbmZpZ3VyYXRpb24ncyBkYXRhIG1vZGVsIGFuZCBp dHMgdmFsdWVzLCBhcyB3ZWxsIGFzIGZvciBlbmFibGluZyBhDQo+ICAgY2xpZW50IHRvIGtub3cg d2hlbiBhIGNvbmZpZ3VyYXRpb24gaGFzIGJlZW4gZnVsbHkgYXBwbGllZCBvciBub3QsDQo+ICAg aG93IHRvIGFjY2VzcyBvcGVyYXRpb25hbCBzdGF0ZSwgYW5kIGhvdyB0byByZWxhdGUgaW50ZW5k ZWQNCj4gICBjb25maWd1cmF0aW9uIG5vZGVzIHRvIGFwcGxpZWQgY29uZmlndXJhdGlvbiBhbmQg ZGVyaXZlZCBzdGF0ZSBub2Rlcy4NCj4NCj4NCj5UaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMg cGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLW5ldG1vZC1vcHN0YXRlLXJlcXMvDQo+DQo+VGhlcmUncyBhbHNvIGEgaHRt bGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtbmV0bW9kLW9wc3RhdGUtcmVxcy0wMw0KPg0KPkEgZGlmZiBmcm9tIHRoZSBw cmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj5odHRwczovL3d3dy5pZXRmLm9yZy9y ZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1uZXRtb2Qtb3BzdGF0ZS1yZXFzLTAzDQo+DQo+DQo+UGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2Ygc3VibWlzc2lvbg0KPnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFy ZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+DQo+SW50ZXJuZXQtRHJhZnRzIGFyZSBh bHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPmZ0cDovL2Z0cC5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj5uZXRtb2QgbWFpbGluZyBsaXN0DQo+bmV0bW9kQGlldGYub3JnDQo+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg== From nobody Sun Jan 10 03:21:36 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6221AC42A for ; Sun, 10 Jan 2016 03:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuXvfhPnlSC3 for ; Sun, 10 Jan 2016 03:21:31 -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 03FA81AC424 for ; Sun, 10 Jan 2016 03:21:30 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A9750B1A; Sun, 10 Jan 2016 12:21:27 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id G6crshIEc_3m; Sun, 10 Jan 2016 12:21:26 +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; Sun, 10 Jan 2016 12:21:26 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id AB79C20056; Sun, 10 Jan 2016 12:21:26 +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 VQ54AhdOfbxH; Sun, 10 Jan 2016 12:21: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 CD60F20055; Sun, 10 Jan 2016 12:21:24 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B7AE63980B8B; Sun, 10 Jan 2016 12:21:23 +0100 (CET) Date: Sun, 10 Jan 2016 12:21:22 +0100 From: Juergen Schoenwaelder To: "Acee Lindem (acee)" Message-ID: <20160110112122.GA39699@elstar.local> Mail-Followup-To: "Acee Lindem (acee)" , Ladislav Lhotka , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" , "netmod@ietf.org" References: <8A6CD12B-8B34-4F7B-83F2-E56361F998AA@juniper.net> <20160105200214.GA24262@elstar.local> <20160106063014.GA25143@elstar.local> <20160107160521.GC28062@elstar.local> <568E9F5D.3030500@cisco.com> <20160108083659.GA29486@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.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2016 11:21:33 -0000 On Fri, Jan 08, 2016 at 01:46:44PM +0000, Acee Lindem (acee) wrote: > > The draft is quite succinct and I’m not sure how you and Juergen do not > agree that there are requirements beyond intended/applied state. Perhaps > you do not agree with them? Refer to requirements 3.(B & C) and 4.(B & C). > For your convenience, I’ve excerpted them below: > > > 3. Separation of the applied configuration and derived state aspects > of operational state; ability to retrieve them independently and > together > > A. Be able to retrieve only the applied configuration aspects of > operational state > > B. Be able to retrieve only the derived state aspects of > operational state This is nothing new. See for example section 4.3.3.2 of RFC 6244. > C. Be able to retrieve both the applied configuration and > derived state aspects of operational state together Did you notice that 3.C talks about 'applied configuration'? > 4. Ability to relate configuration with its corresponding > operational state > > A. Ability to map intended config nodes to corresponding applied > config nodes > > B. Ability to map intended config nodes to associated derived > state nodes > > C. The mappings needs to be programmatically consumable I do not agree that 4.B and 4.C require to broaden the title. In fact, I wonder why 4.B is useful. If we agree that the applied config (an extended subset of the intended config) is the configration that determines what the device is doing, then we likely should have a mapping of the applied config to associated derived state. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sun Jan 10 03:26:13 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92C31AC430 for ; Sun, 10 Jan 2016 03:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0igqghFdCet for ; Sun, 10 Jan 2016 03:26:10 -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 689C71AC424 for ; Sun, 10 Jan 2016 03:26:10 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 37CAEB1A; Sun, 10 Jan 2016 12:26:09 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 8AAYzDMlP5_n; Sun, 10 Jan 2016 12:26: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; Sun, 10 Jan 2016 12:26:08 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6651E20058; Sun, 10 Jan 2016 12:26:08 +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 0nYRkIjcKD6L; Sun, 10 Jan 2016 12:26:07 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4B69920055; Sun, 10 Jan 2016 12:26:07 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 516A13980BC9; Sun, 10 Jan 2016 12:26:06 +0100 (CET) Date: Sun, 10 Jan 2016 12:26:05 +0100 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20160110112605.GB39699@elstar.local> Mail-Followup-To: Kent Watsen , "netmod@ietf.org" References: <20160109005830.20805.41463.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2016 11:26:11 -0000 On Sat, Jan 09, 2016 at 01:00:34AM +0000, Kent Watsen wrote: > > In addition to the title update, I also updated the abstract/introduction and fixed a couple editorial items. > I do not like the changes of the abstract/introduction, in particular the phrase "requirements for the applied configuration's data model and its values". /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sun Jan 10 16:21:40 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D4B1A1B6F; Sun, 10 Jan 2016 16:21:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.697 X-Spam-Level: X-Spam-Status: No, score=0.697 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5dx4nIZoFpY; Sun, 10 Jan 2016 16:21:17 -0800 (PST) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5B091A1B6E; Sun, 10 Jan 2016 16:21:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1452471669; bh=AvufymwX3E7xWrw8VBhfNKte7uvm6hhw7x9ubGJOhJY=; h=From:Subject:Date:Cc:To; b=R27s6+rVqcgmhGFfmcZXI3E+8l0DxWrI4rD8QGVPViGYBGlTpEez17SHQGkzGSBjN ev4Lh2D1xVtmOup9HqPmUvfmJo5LcDBhLWpVfutzKMT1d551/xgyDfZJHHYi34b9a1 JrquiHLZTOAZhc+fdOzzKrSRcM6iPNJVJ6/kv5w4= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; From: Nadeau Thomas Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Sun, 10 Jan 2016 19:21:12 -0500 Message-Id: To: NETMOD WG Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=5 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 241, in=3014, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: joel jaeggli , Benoit Claise Subject: [netmod] Resigning Chair Position X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 00:21:19 -0000 I am writing to the NETMOD WG to inform you all that I will be = resigning my position as co-chair. I will remain on as co-chair and = continue my duties until Benoit finds a suitable replacement, which he = tells me will not be too long. It has been a challenge and pleasure = serving the community as co-chair over the past 2 years. I learned a lot = in this role, and I hope I served the community well. I hope to = continue working with many of you in the capacity of an individual = contributor in and around the area of Yang and model creation. Cheers, =E2=80=94Tom From nobody Mon Jan 11 01:15:43 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A934F1A884F for ; Mon, 11 Jan 2016 01:15:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQYx8-rwIlGb for ; Mon, 11 Jan 2016 01:15:28 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5BD1A8842 for ; Mon, 11 Jan 2016 01:15:26 -0800 (PST) Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id 8B4311AE047A for ; Mon, 11 Jan 2016 10:15:24 +0100 (CET) Date: Mon, 11 Jan 2016 10:15:26 +0100 (CET) Message-Id: <20160111.101526.1720014765007751699.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] 6087bis namespace recommendations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 09:15:30 -0000 Hi, Currently, 6087bis says that standards-track, published and unpublished modules SHOULD use the URN prefix "urn:ietf:params:xml:ns:yang:". There are two issues with this: 1. We already publish experimental modules w/ this prefix. (ietf-netconf-time and ietf-complex-types). So 6087bis should remove "standards track" from this recommendation. 2. There was some discussion about recommending a different URN prefix for unpublished modules (i.e., modules in Internet Drafts). Should 6087bis recommend some special urn prefix for drafts, with a note to the RFC editor to change the namespace once it has been registered with IANA? And another issue. 6087bis also has this: OLD: The following examples are for non-Standards-Track modules. The domain "example.com" SHOULD be used in all namespace URIs for example modules. http://example.com/ns/example-interfaces http://example.com/ns/example-system First of all, the sentence about non-Standards-Track modules is confusing. Second, since the publication of RFC 6087, RFC 6963 has been published, which defines a URN for examples. I suggest we update 6087bis like this: NEW: Example modules in all types of documents SHOULD use a namespace with either the example URN [RFC 6963] or the domain "example.com". For example: urn:example:interfaces http://example.com/ns/example-system /martin From nobody Mon Jan 11 01:28:40 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3EBD1A8863 for ; Mon, 11 Jan 2016 01:28:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ehxm4TYSYZn for ; Mon, 11 Jan 2016 01:28:36 -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 4DEE81A8862 for ; Mon, 11 Jan 2016 01:28:36 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7851E765; Mon, 11 Jan 2016 10:28:34 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 0BaOaVJvywti; Mon, 11 Jan 2016 10:28:33 +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, 11 Jan 2016 10:28:33 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8E8762002B; Mon, 11 Jan 2016 10:28:33 +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 Or-Q8plouDju; Mon, 11 Jan 2016 10:28:32 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3FA2C20013; Mon, 11 Jan 2016 10:28:32 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1156339811F0; Mon, 11 Jan 2016 10:28:31 +0100 (CET) Date: Mon, 11 Jan 2016 10:28:31 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20160111092831.GA41568@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20160111.101526.1720014765007751699.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160111.101526.1720014765007751699.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] 6087bis namespace recommendations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 09:28:39 -0000 On Mon, Jan 11, 2016 at 10:15:26AM +0100, Martin Bjorklund wrote: > Hi, > > Currently, 6087bis says that standards-track, published and > unpublished modules SHOULD use the URN prefix > "urn:ietf:params:xml:ns:yang:". > > There are two issues with this: > > 1. We already publish experimental modules w/ this prefix. > (ietf-netconf-time and ietf-complex-types). > > So 6087bis should remove "standards track" from this > recommendation. Well, the current text is silent about non-standards-track modules, so there is not really a conflict. While searching through 6087, I think it is more important to clarify the usage of 'publish'. One solution would be to use 'publishing' when we talk about the publication of RFCs and to use 'posting' when we talk about the posting of an Internet-Draft. But yes, this is a different can of worms. > 2. There was some discussion about recommending a different URN > prefix for unpublished modules (i.e., modules in Internet > Drafts). > > Should 6087bis recommend some special urn prefix for drafts, > with a note to the RFC editor to change the namespace once it > has been registered with IANA? Do we have evidence that having such a rule makes the Internet work better? > And another issue. 6087bis also has this: > > OLD: > > The following examples are for non-Standards-Track modules. > The domain "example.com" SHOULD be used in all namespace URIs > for example modules. > > http://example.com/ns/example-interfaces > > http://example.com/ns/example-system > > > First of all, the sentence about non-Standards-Track modules is > confusing. Second, since the publication of RFC 6087, RFC 6963 has > been published, which defines a URN for examples. I suggest we update > 6087bis like this: > > NEW: > > Example modules in all types of documents SHOULD use a namespace > with either the example URN [RFC 6963] or the domain "example.com". > For example: > > urn:example:interfaces > > http://example.com/ns/example-system Adopting urn:example 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 Mon Jan 11 02:21:46 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895391A88D7 for ; Mon, 11 Jan 2016 02:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vV9QlD2-uVW2 for ; Mon, 11 Jan 2016 02:21:43 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 32D861A88CB for ; Mon, 11 Jan 2016 02:21:43 -0800 (PST) Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id 465441AE047A; Mon, 11 Jan 2016 11:21:41 +0100 (CET) Date: Mon, 11 Jan 2016 11:21:43 +0100 (CET) Message-Id: <20160111.112143.1731089672764861015.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20160111092831.GA41568@elstar.local> References: <20160111.101526.1720014765007751699.mbj@tail-f.com> <20160111092831.GA41568@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] 6087bis namespace recommendations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 10:21:44 -0000 Juergen Schoenwaelder wrote: > On Mon, Jan 11, 2016 at 10:15:26AM +0100, Martin Bjorklund wrote: > > Hi, > > > > Currently, 6087bis says that standards-track, published and > > unpublished modules SHOULD use the URN prefix > > "urn:ietf:params:xml:ns:yang:". > > > > There are two issues with this: > > > > 1. We already publish experimental modules w/ this prefix. > > (ietf-netconf-time and ietf-complex-types). > > > > So 6087bis should remove "standards track" from this > > recommendation. > > Well, the current text is silent about non-standards-track modules No, it says: Note that a different URN prefix string SHOULD be used for non-Standards-Track modules. > so > there is not really a conflict. While searching through 6087, I think > it is more important to clarify the usage of 'publish'. One solution > would be to use 'publishing' when we talk about the publication of > RFCs and to use 'posting' when we talk about the posting of an > Internet-Draft. But yes, this is a different can of worms. > > > 2. There was some discussion about recommending a different URN > > prefix for unpublished modules (i.e., modules in Internet > > Drafts). > > > > Should 6087bis recommend some special urn prefix for drafts, > > with a note to the RFC editor to change the namespace once it > > has been registered with IANA? > > Do we have evidence that having such a rule makes the Internet work > better? I don't know, but apparently there can be confusion when an extracted module from a draft is passed around. What can we learn from the SNMP experience where the OID assignement is done by IANA - good or bad? /martin From nobody Mon Jan 11 02:49:05 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6739E1A88FA for ; Mon, 11 Jan 2016 02:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-RGOTLTHusf for ; Mon, 11 Jan 2016 02:49: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 719BD1A88F9 for ; Mon, 11 Jan 2016 02:49: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 3A1DC74A; Mon, 11 Jan 2016 11:49:01 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 6ucseR7xdVKS; Mon, 11 Jan 2016 11:49: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; Mon, 11 Jan 2016 11:49:00 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 18C222002B; Mon, 11 Jan 2016 11:49: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 9P0j41I3VIjl; Mon, 11 Jan 2016 11:48: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 622E820013; Mon, 11 Jan 2016 11:48:58 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8212B39812B0; Mon, 11 Jan 2016 11:48:56 +0100 (CET) Date: Mon, 11 Jan 2016 11:48:55 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20160111104855.GA41658@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20160111.101526.1720014765007751699.mbj@tail-f.com> <20160111092831.GA41568@elstar.local> <20160111.112143.1731089672764861015.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160111.112143.1731089672764861015.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] 6087bis namespace recommendations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 10:49:04 -0000 On Mon, Jan 11, 2016 at 11:21:43AM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Mon, Jan 11, 2016 at 10:15:26AM +0100, Martin Bjorklund wrote: > > > Hi, > > > > > > Currently, 6087bis says that standards-track, published and > > > unpublished modules SHOULD use the URN prefix > > > "urn:ietf:params:xml:ns:yang:". > > > > > > There are two issues with this: > > > > > > 1. We already publish experimental modules w/ this prefix. > > > (ietf-netconf-time and ietf-complex-types). > > > > > > So 6087bis should remove "standards track" from this > > > recommendation. > > > > Well, the current text is silent about non-standards-track modules > > No, it says: > > Note that a different URN prefix string SHOULD be used for > non-Standards-Track modules. Well, yes, this is likely in need of a fix then. > > so > > there is not really a conflict. While searching through 6087, I think > > it is more important to clarify the usage of 'publish'. One solution > > would be to use 'publishing' when we talk about the publication of > > RFCs and to use 'posting' when we talk about the posting of an > > Internet-Draft. But yes, this is a different can of worms. > > > > > 2. There was some discussion about recommending a different URN > > > prefix for unpublished modules (i.e., modules in Internet > > > Drafts). > > > > > > Should 6087bis recommend some special urn prefix for drafts, > > > with a note to the RFC editor to change the namespace once it > > > has been registered with IANA? > > > > Do we have evidence that having such a rule makes the Internet work > > better? > > I don't know, but apparently there can be confusion when an extracted > module from a draft is passed around. > > What can we learn from the SNMP experience where the OID assignement > is done by IANA - good or bad? With MIB modules, the module OID is assigned by IANA and we usually have a placeholder (which makes the module not compile). With SNMP, we converged to register the majority of modules below mib-2 and hence if people pick numbers, they have a high potential for collision. With NETCONF namespaces, the collision probability is rather low. The other aspect is that an official assignment happens late during the process, e.g., as part of the RFC publication process and there might be early implementations that use a 'speculative' namespace value. In a perfect world, we should likely use a different prefix while the module is under development and then let IANA have the final say on the official prefix. And if Lada is really concerned about problems caused if I-D implementations, we could do lets say a series of urn:ietf:params:xml:ns:yang:draft-ietf-netmod-routing-cfg-00 ... urn:ietf:params:xml:ns:yang:draft-ietf-netmod-routing-cfg-20 in I-Ds and then the RFC editor finally changes things to urn:ietf:params:xml:ns:yang:ietf-routing if IANA agrees to allocate this URN to the module. Of course, this means more work for the editors involved and so far our lax handling of this issue seems to have worked. (But so it did for MIB modules until problems started to show up.) /js PS: Note that JSON encoding uses the module name and not the namespace and hence even if we do the above, module names in JSON won't signal the difference between I-D and published RFC versions of a module. So to be really fool proof one would have to change the module name also with every posted I-D. The question is at which point in time bureaucracy hampers productivity and perhaps what we do today is not perfect but a reasonable trade-off. PS: Another option could be a YANG keyword that declares the status of a module, 'draft', 'published', 'experimental', 'example', 'obsolete' and then the RFC editor would only have to toggle this value and tools could still distinguish the different kinds of YANG modules. -- 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 11 03:02:34 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885151A890D for ; Mon, 11 Jan 2016 03:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNsvzZ1Sa7fo for ; Mon, 11 Jan 2016 03:02:31 -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 060561A8925 for ; Mon, 11 Jan 2016 03:02:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2512; q=dns/txt; s=iport; t=1452510150; x=1453719750; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=xqF5qOjME8P2zzRdggNtmQZwC67EUbLsD3pPUpXFkw8=; b=XpLMWJG7Rgy3imeuXWXlcJZ1BMVTXtke+G30hCok8rQycnKlgTuLY+3d 7ABHZdQK/qlZ7XjmJ+AN43ccZosXUNMS332lnhakse99R8PBe+WzHPSN9 +GbdjOnimOMoY0fg7kltSb//E4zdwn182+k0nhe0PTQlHLt/VroaMscaB U=; X-IronPort-AV: E=Sophos;i="5.20,552,1444694400"; d="scan'208";a="624417223" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jan 2016 11:02:27 +0000 Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u0BB2RG9000595; Mon, 11 Jan 2016 11:02:27 GMT To: "Acee Lindem (acee)" , Ladislav Lhotka , "netmod@ietf.org" References: <8A6CD12B-8B34-4F7B-83F2-E56361F998AA@juniper.net> <20160105200214.GA24262@elstar.local> <20160106063014.GA25143@elstar.local> <20160107160521.GC28062@elstar.local> <568E9F5D.3030500@cisco.com> <20160108083659.GA29486@elstar.local> <20160110112122.GA39699@elstar.local> From: Robert Wilton Message-ID: <56938BC6.80707@cisco.com> Date: Mon, 11 Jan 2016 11:02:30 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160110112122.GA39699@elstar.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 11:02:32 -0000 On 10/01/2016 11:21, Juergen Schoenwaelder wrote: > On Fri, Jan 08, 2016 at 01:46:44PM +0000, Acee Lindem (acee) wrote: >> The draft is quite succinct and I’m not sure how you and Juergen do not >> agree that there are requirements beyond intended/applied state. Perhaps >> you do not agree with them? Refer to requirements 3.(B & C) and 4.(B & C). >> For your convenience, I’ve excerpted them below: >> >> >> 3. Separation of the applied configuration and derived state aspects >> of operational state; ability to retrieve them independently and >> together >> >> A. Be able to retrieve only the applied configuration aspects of >> operational state >> >> B. Be able to retrieve only the derived state aspects of >> operational state > This is nothing new. See for example section 4.3.3.2 of RFC 6244. > >> C. Be able to retrieve both the applied configuration and >> derived state aspects of operational state together > Did you notice that 3.C talks about 'applied configuration'? > >> 4. Ability to relate configuration with its corresponding >> operational state >> >> A. Ability to map intended config nodes to corresponding applied >> config nodes >> >> B. Ability to map intended config nodes to associated derived >> state nodes >> >> C. The mappings needs to be programmatically consumable > I do not agree that 4.B and 4.C require to broaden the title. > > In fact, I wonder why 4.B is useful. If we agree that the applied > config (an extended subset of the intended config) is the configration > that determines what the device is doing, then we likely should have a > mapping of the applied config to associated derived state. Yes, in essence the relationship is intended config => applied config => derived state. So I would say that derived state has a transitive association with the intended config. Personally, I think that the relationship should be expressed in the reverse direction. I.e. a particular node of derived state should be allowed to refer back to the config (intended/applied) that is derived from. This is presumably an implementation detail rather than a requirement. However, I'm not sure that we actually need to change the text, I think that the requirement text is probably sufficiently clear to compare solutions. Thanks, Rob > > /js > From nobody Mon Jan 11 03:16:47 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256B01A8925; Mon, 11 Jan 2016 03:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wH6a8CKEod_D; Mon, 11 Jan 2016 03:16:43 -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 434761A8920; Mon, 11 Jan 2016 03:16:43 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id l65so206581823wmf.1; Mon, 11 Jan 2016 03:16:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=stkkr61Qla2yVddHAcD36azDRy3cURQ6iouyIkQqbGc=; b=iafrYhhUkwHT/0Ne7daOsIZpN0teavPdXyaFaMDmusbHLbrM2APHcARxBb/ok4fBxE +7QPiU51BKxuJJUY30cvAAJ/IbTuhmG6HEL7CzA0HVhUTrBUoq8uV6uZt0q4RJXYtjK1 uNl+tjyqEVR2lLRGnnPl8hMFoqJE1gRIE2ByrE6tloFib2KBZh9MuXOv+YY/ZBgw7LSy MCZfeop3zBReP9/GAl159OiZzKkRwtWotRccpss7nZ+1WKK+w8lDpdwtbns67ZI5UJbS 6fWRTgs7+IAnpGNY3QwlCQO5/tCWdEfiXHUiktX1Sl+8w8apKqhJjcJ9F7RPDq1xEhjf d5nA== X-Received: by 10.194.238.162 with SMTP id vl2mr107448067wjc.91.1452511001804; Mon, 11 Jan 2016 03:16:41 -0800 (PST) Received: from [192.168.254.224] ([147.83.206.82]) by smtp.gmail.com with ESMTPSA id l184sm12303955wmf.6.2016.01.11.03.16.40 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 11 Jan 2016 03:16:41 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_1BEEDA1C-919E-4A24-A200-CEA8839ED1CC" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dean Bogdanovic In-Reply-To: <20160108.132619.2106992589983161035.mbj@tail-f.com> Date: Mon, 11 Jan 2016 12:16:40 +0100 Message-Id: <4134AA7D-F3E0-4953-9E14-D0FEA1B68EEA@gmail.com> References: <20160108.125237.1815033897965196525.mbj@tail-f.com> <20160108120858.GA30099@elstar.local> <20160108.132619.2106992589983161035.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.3112) Archived-At: Cc: yang-doctors@ietf.org, RTG YANG Design Team , netmod WG Subject: Re: [netmod] [yang-doctors] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 11:16:45 -0000 --Apple-Mail=_1BEEDA1C-919E-4A24-A200-CEA8839ED1CC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Are there any other opinions on switching YANG version for ACL model = from 1.0 to 1.1? Would like to get more opinions on this, besides = Martin. Dean > On Jan 8, 2016, at 1:26 PM, Martin Bjorklund wrote: >=20 > Dean Bogdanovic > = wrote: >>=20 >>> On Jan 8, 2016, at 1:09 PM, Juergen Schoenwaelder >>> wrote: >>>=20 >>> On Fri, Jan 08, 2016 at 12:52:37PM +0100, Martin Bjorklund wrote: >>>> Juergen Schoenwaelder wrote: >>>>> On Thu, Jan 07, 2016 at 04:21:42PM +0100, Martin Bjorklund wrote: >>>>>>=20 >>>>>> With YANG 1.1, a leafref can be marked as "require-instance = false", >>>>>> which allows a interface-state-ref to be used in config: >>>>>>=20 >>>>>> type if:interface-state-ref { >>>>>> require-instance false; >>>>>> } >>>>>> // + add description that explains what happens if there is no = such >>>>>> // instance >>>>>>=20 >>>>>>=20 >>>>>> (NOTE: this doesn't work w/ pyang at the momement, I am working = on a >>>>>> fix) >>>>>>=20 >>>>>=20 >>>>> And it would have to be if:interface-ref instead >>>>> if:interface-state-ref >>>>> I think. >>>>=20 >>>> No, I meant interface-state-ref. This way you can put a filter on >>>> non-configured interfaces. >>>>=20 >>>=20 >>> But with require-instance false, this is also true for >>> if:interface-ref. If I preconfigure and interface, I might also = want >>> to preconfigure ACLs refering the preconfigure interface. And note >>> that if:interface-state-ref refers to a config false leaf. >>=20 >> In this case we have to change to yang-version 1.1. The plan was to >> have it for 1.0. Do we want to move the ACL model to YANG minimum >> version 1.1? >=20 > I think it is ok. We're fixing issues like this one in 1.1 so that we > don't have to rely on various workarounds. Note that the second WGLC > for 1.1 just ended, w/ mostly minor proposed edits. >=20 >=20 > /martin --Apple-Mail=_1BEEDA1C-919E-4A24-A200-CEA8839ED1CC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Are there any other opinions on switching YANG version for = ACL model from 1.0 to 1.1? Would like to get more opinions on this, = besides Martin.

Dean

On Jan 8, 2016, at 1:26 PM, = Martin Bjorklund <mbj@tail-f.com> wrote:

Dean Bogdanovic <ivandean@gmail.com> wrote:

On Jan 8, 2016, at 1:09 PM, Juergen = Schoenwaelder
<j.schoenwaelder@jacobs-university.de> wrote:

On Fri, Jan 08, 2016 at 12:52:37PM +0100, = Martin Bjorklund wrote:
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Jan 07, 2016 at = 04:21:42PM +0100, Martin Bjorklund wrote:

With YANG 1.1, a leafref can be = marked as "require-instance false",
which allows a = interface-state-ref to be used in config:

 type if:interface-state-ref {
   require-instance false;
 }
 // + add description that = explains what happens if there is no such
 // =   instance


(NOTE: = this doesn't work w/ pyang at the momement, I am working on a
fix)


And it would have to be if:interface-ref instead
if:interface-state-ref
I think.

No, I meant interface-state-ref. =  This way you can put a filter on
non-configured = interfaces.


But = with require-instance false, this is also true for
if:interface-ref.  If I preconfigure and interface, I = might also want
to preconfigure ACLs refering the = preconfigure interface. And note
that = if:interface-state-ref refers to a config false leaf.

In this case we have to change to = yang-version 1.1. The plan was to
have it for 1.0. Do we = want to move the ACL model to YANG minimum
version 1.1?

I think it is ok.  We're fixing issues like = this one in 1.1 so that we
don't have to rely on various workarounds. =  Note that the second WGLC
for 1.1 just ended, w/ mostly minor = proposed edits.


/martin

= --Apple-Mail=_1BEEDA1C-919E-4A24-A200-CEA8839ED1CC-- From nobody Mon Jan 11 03:26:07 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 211311A8937; Mon, 11 Jan 2016 03:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0yMDm2PTvBv; Mon, 11 Jan 2016 03:26:02 -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 63F1C1A8934; Mon, 11 Jan 2016 03:26:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15256; q=dns/txt; s=iport; t=1452511561; x=1453721161; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=/v5ZhBk5FW6ODw7/Z4ISvajsVM6ZQZqfNvKkTtjid6Y=; b=OxAYKcuMlK9qjGLomF4vom+GFdN7Pgzt7CfxM4AQEIMkq9YP1fBNPTyk 0+4EWm1mZDLnGcbeR0Gd3zNjiau2ZXm53xLWis56IdGv5iHYeJJQ1pFMN r15ln4m7QFZUoJPv11KwwwEXBmKsIG24QCDGDw/AKQ79/0Fn20EIaHlYx U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvBAAikJNW/xbLJq1egm6BHm2IWbVSG?= =?us-ascii?q?AEJhSNKAoFuAQEBAQEBgQuENQEBBAEBAWsKARALDgIICRYEBAcJAwIBAgEPBh8?= =?us-ascii?q?RBg0GAgEBF4d+AxIOu0YNgn8BAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZWhH+CT?= =?us-ascii?q?4ZtBZcTi2GBeIkohVWGcodfZIJKgUA+NIYoAQEB?= X-IronPort-AV: E=Sophos;i="5.20,552,1444694400"; d="scan'208,217";a="623387752" 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 2016 11:25:59 +0000 Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u0BBPxwN024077; Mon, 11 Jan 2016 11:25:59 GMT To: Dean Bogdanovic References: <20160108.125237.1815033897965196525.mbj@tail-f.com> <20160108120858.GA30099@elstar.local> <20160108.132619.2106992589983161035.mbj@tail-f.com> <4134AA7D-F3E0-4953-9E14-D0FEA1B68EEA@gmail.com> From: Robert Wilton Message-ID: <56939149.5000802@cisco.com> Date: Mon, 11 Jan 2016 11:26:01 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <4134AA7D-F3E0-4953-9E14-D0FEA1B68EEA@gmail.com> Content-Type: multipart/alternative; boundary="------------050300030606010602090601" Archived-At: Cc: yang-doctors@ietf.org, RTG YANG Design Team , netmod WG Subject: Re: [netmod] [yang-doctors] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 11:26:05 -0000 This is a multi-part message in MIME format. --------------050300030606010602090601 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Dean, I agree with Martin's proposed solution. I.e. switch to YANG 1.1, and use his proposed interface-state-ref & require-instance false solution. Thanks, Rob On 11/01/2016 11:16, Dean Bogdanovic wrote: > Are there any other opinions on switching YANG version for ACL model > from 1.0 to 1.1? Would like to get more opinions on this, besides Martin. > > Dean > >> On Jan 8, 2016, at 1:26 PM, Martin Bjorklund > > wrote: >> >> Dean Bogdanovic > wrote: >>> >>>> On Jan 8, 2016, at 1:09 PM, Juergen Schoenwaelder >>>> >>> > wrote: >>>> >>>> On Fri, Jan 08, 2016 at 12:52:37PM +0100, Martin Bjorklund wrote: >>>>> Juergen Schoenwaelder >>>> > wrote: >>>>>> On Thu, Jan 07, 2016 at 04:21:42PM +0100, Martin Bjorklund wrote: >>>>>>> >>>>>>> With YANG 1.1, a leafref can be marked as "require-instance false", >>>>>>> which allows a interface-state-ref to be used in config: >>>>>>> >>>>>>> type if:interface-state-ref { >>>>>>> require-instance false; >>>>>>> } >>>>>>> // + add description that explains what happens if there is no such >>>>>>> // instance >>>>>>> >>>>>>> >>>>>>> (NOTE: this doesn't work w/ pyang at the momement, I am working on a >>>>>>> fix) >>>>>>> >>>>>> >>>>>> And it would have to be if:interface-ref instead >>>>>> if:interface-state-ref >>>>>> I think. >>>>> >>>>> No, I meant interface-state-ref. This way you can put a filter on >>>>> non-configured interfaces. >>>>> >>>> >>>> But with require-instance false, this is also true for >>>> if:interface-ref. If I preconfigure and interface, I might also want >>>> to preconfigure ACLs refering the preconfigure interface. And note >>>> that if:interface-state-ref refers to a config false leaf. >>> >>> In this case we have to change to yang-version 1.1. The plan was to >>> have it for 1.0. Do we want to move the ACL model to YANG minimum >>> version 1.1? >> >> I think it is ok. We're fixing issues like this one in 1.1 so that we >> don't have to rely on various workarounds. Note that the second WGLC >> for 1.1 just ended, w/ mostly minor proposed edits. >> >> >> /martin > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------050300030606010602090601 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Dean,

I agree with Martin's proposed solution.

I.e. switch to YANG 1.1, and use his proposed interface-state-ref & require-instance false solution.

Thanks,
Rob


On 11/01/2016 11:16, Dean Bogdanovic wrote:
Are there any other opinions on switching YANG version for ACL model from 1.0 to 1.1? Would like to get more opinions on this, besides Martin.

Dean

On Jan 8, 2016, at 1:26 PM, Martin Bjorklund <mbj@tail-f.com> wrote:

Dean Bogdanovic <ivandean@gmail.com> wrote:

On Jan 8, 2016, at 1:09 PM, Juergen Schoenwaelder
<j.schoenwaelder@jacobs-university.de> wrote:

On Fri, Jan 08, 2016 at 12:52:37PM +0100, Martin Bjorklund wrote:
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Jan 07, 2016 at 04:21:42PM +0100, Martin Bjorklund wrote:

With YANG 1.1, a leafref can be marked as "require-instance false",
which allows a interface-state-ref to be used in config:

type if:interface-state-ref {
require-instance false;
}
// + add description that explains what happens if there is no such
// instance


(NOTE: this doesn't work w/ pyang at the momement, I am working on a
fix)


And it would have to be if:interface-ref instead
if:interface-state-ref
I think.

No, I meant interface-state-ref. This way you can put a filter on
non-configured interfaces.


But with require-instance false, this is also true for
if:interface-ref. If I preconfigure and interface, I might also want
to preconfigure ACLs refering the preconfigure interface. And note
that if:interface-state-ref refers to a config false leaf.

In this case we have to change to yang-version 1.1. The plan was to
have it for 1.0. Do we want to move the ACL model to YANG minimum
version 1.1?

I think it is ok. We're fixing issues like this one in 1.1 so that we
don't have to rely on various workarounds. Note that the second WGLC
for 1.1 just ended, w/ mostly minor proposed edits.


/martin



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

--------------050300030606010602090601-- From nobody Mon Jan 11 03:26:40 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428801A8934 for ; Mon, 11 Jan 2016 03:26:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hK3yy8Shl9a for ; Mon, 11 Jan 2016 03:26:35 -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 86F071A8954 for ; Mon, 11 Jan 2016 03:26:35 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4C34F6DE; Mon, 11 Jan 2016 12:26:34 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id UYF2Q92-z6Uj; Mon, 11 Jan 2016 12:26:33 +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, 11 Jan 2016 12:26:33 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 22A162002B; Mon, 11 Jan 2016 12:26:33 +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 MtxprzviUBBA; Mon, 11 Jan 2016 12:26:32 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 84B4F20013; Mon, 11 Jan 2016 12:26:31 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9F03F3981321; Mon, 11 Jan 2016 12:26:30 +0100 (CET) Date: Mon, 11 Jan 2016 12:26:30 +0100 From: Juergen Schoenwaelder To: Robert Wilton Message-ID: <20160111112629.GA41791@elstar.local> Mail-Followup-To: Robert Wilton , "Acee Lindem (acee)" , Ladislav Lhotka , "netmod@ietf.org" References: <20160106063014.GA25143@elstar.local> <20160107160521.GC28062@elstar.local> <568E9F5D.3030500@cisco.com> <20160108083659.GA29486@elstar.local> <20160110112122.GA39699@elstar.local> <56938BC6.80707@cisco.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: <56938BC6.80707@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 11:26:37 -0000 On Mon, Jan 11, 2016 at 11:02:30AM +0000, Robert Wilton wrote: > > > On 10/01/2016 11:21, Juergen Schoenwaelder wrote: > >On Fri, Jan 08, 2016 at 01:46:44PM +0000, Acee Lindem (acee) wrote: > >>The draft is quite succinct and I’m not sure how you and Juergen do not > >>agree that there are requirements beyond intended/applied state. Perhaps > >>you do not agree with them? Refer to requirements 3.(B & C) and 4.(B & C). > >>For your convenience, I’ve excerpted them below: > >> > >> > >> 3. Separation of the applied configuration and derived state aspects > >> of operational state; ability to retrieve them independently and > >> together > >> > >> A. Be able to retrieve only the applied configuration aspects of > >> operational state > >> > >> B. Be able to retrieve only the derived state aspects of > >> operational state > >This is nothing new. See for example section 4.3.3.2 of RFC 6244. > > > >> C. Be able to retrieve both the applied configuration and > >> derived state aspects of operational state together > >Did you notice that 3.C talks about 'applied configuration'? > > > >> 4. Ability to relate configuration with its corresponding > >> operational state > >> > >> A. Ability to map intended config nodes to corresponding applied > >> config nodes > >> > >> B. Ability to map intended config nodes to associated derived > >> state nodes > >> > >> C. The mappings needs to be programmatically consumable > >I do not agree that 4.B and 4.C require to broaden the title. > > > >In fact, I wonder why 4.B is useful. If we agree that the applied > >config (an extended subset of the intended config) is the configration > >that determines what the device is doing, then we likely should have a > >mapping of the applied config to associated derived state. > Yes, in essence the relationship is intended config => applied config => > derived state. So I would say that derived state has a transitive > association with the intended config. Yes. But applied config might include something that is not intended config, which would be lost if we map intended config => derived state. > Personally, I think that the relationship should be expressed in the > reverse direction. I.e. a particular node of derived state should be > allowed to refer back to the config (intended/applied) that is derived > from. This is presumably an implementation detail rather than a > requirement. Yes, I wrote about this earlier - some several weeks ago. What is really helpful for a managing system is to know the source of derived state, be it applied config, be it a routing protocol daemon, be it a dhcp server, be it a piece of tunneling software, be it an I2RS agent. So yes, I agree with you that the reverse direction is desirable (e.g., have meta data for derived state that explains where the state if originating from). What I also explained back then is that a standard Linux kernel does not track this context for many resources, which makes this somewhat difficult (= expensive) to implement. But yes, from a management point perspective, knowing the source of derived state is truly helpful in my experience. > However, I'm not sure that we actually need to change the text, I think > that the requirement text is probably sufficiently clear to compare > solutions. Perhaps. I just wanted to point out in my email that even 4.B involves applied config if done right and hence the document really is grounded on the distinction of applied config and intended config. /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 11 03:29:20 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD87C1A8949; Mon, 11 Jan 2016 03:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Od1CbnJ0IKFD; Mon, 11 Jan 2016 03:29: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 D2ECC1A8943; Mon, 11 Jan 2016 03:29: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 935856DE; Mon, 11 Jan 2016 12:29:13 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id NsVKLrxM3DLj; Mon, 11 Jan 2016 12:29:12 +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, 11 Jan 2016 12:29:12 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id AB21D2002C; Mon, 11 Jan 2016 12:29:12 +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 PozZBqlFPmC6; Mon, 11 Jan 2016 12:29: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 1740E20031; Mon, 11 Jan 2016 12:29:11 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 099803981357; Mon, 11 Jan 2016 12:29:11 +0100 (CET) Date: Mon, 11 Jan 2016 12:29:10 +0100 From: Juergen Schoenwaelder To: Dean Bogdanovic Message-ID: <20160111112910.GB41791@elstar.local> Mail-Followup-To: Dean Bogdanovic , Martin Bjorklund , RTG YANG Design Team , netmod WG , yang-doctors@ietf.org References: <20160108.125237.1815033897965196525.mbj@tail-f.com> <20160108120858.GA30099@elstar.local> <20160108.132619.2106992589983161035.mbj@tail-f.com> <4134AA7D-F3E0-4953-9E14-D0FEA1B68EEA@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4134AA7D-F3E0-4953-9E14-D0FEA1B68EEA@gmail.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: yang-doctors@ietf.org, RTG YANG Design Team , netmod WG Subject: Re: [netmod] [yang-doctors] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 11:29:17 -0000 I think we discussed at one of the previous IETFs that we will use YANG 1.1 in the IETF once it is published. Please check the archives. If I am correct, then you would have to be fast with finishing the ACL model. /js On Mon, Jan 11, 2016 at 12:16:40PM +0100, Dean Bogdanovic wrote: > Are there any other opinions on switching YANG version for ACL model from 1.0 to 1.1? Would like to get more opinions on this, besides Martin. > > Dean > > > On Jan 8, 2016, at 1:26 PM, Martin Bjorklund wrote: > > > > Dean Bogdanovic > wrote: > >> > >>> On Jan 8, 2016, at 1:09 PM, Juergen Schoenwaelder > >>> wrote: > >>> > >>> On Fri, Jan 08, 2016 at 12:52:37PM +0100, Martin Bjorklund wrote: > >>>> Juergen Schoenwaelder wrote: > >>>>> On Thu, Jan 07, 2016 at 04:21:42PM +0100, Martin Bjorklund wrote: > >>>>>> > >>>>>> With YANG 1.1, a leafref can be marked as "require-instance false", > >>>>>> which allows a interface-state-ref to be used in config: > >>>>>> > >>>>>> type if:interface-state-ref { > >>>>>> require-instance false; > >>>>>> } > >>>>>> // + add description that explains what happens if there is no such > >>>>>> // instance > >>>>>> > >>>>>> > >>>>>> (NOTE: this doesn't work w/ pyang at the momement, I am working on a > >>>>>> fix) > >>>>>> > >>>>> > >>>>> And it would have to be if:interface-ref instead > >>>>> if:interface-state-ref > >>>>> I think. > >>>> > >>>> No, I meant interface-state-ref. This way you can put a filter on > >>>> non-configured interfaces. > >>>> > >>> > >>> But with require-instance false, this is also true for > >>> if:interface-ref. If I preconfigure and interface, I might also want > >>> to preconfigure ACLs refering the preconfigure interface. And note > >>> that if:interface-state-ref refers to a config false leaf. > >> > >> In this case we have to change to yang-version 1.1. The plan was to > >> have it for 1.0. Do we want to move the ACL model to YANG minimum > >> version 1.1? > > > > I think it is ok. We're fixing issues like this one in 1.1 so that we > > don't have to rely on various workarounds. Note that the second WGLC > > for 1.1 just ended, w/ mostly minor proposed edits. > > > > > > /martin > -- 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 11 04:51:26 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883201A89FD; Mon, 11 Jan 2016 04:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6P0dPC9F0Avd; Mon, 11 Jan 2016 04:51:22 -0800 (PST) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17ED61A89F5; Mon, 11 Jan 2016 04:51:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1452516673; bh=pFg7Ig9jnZs9rDGdy5GU0lk+yB4WO1z2PztVVOo2JrY=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=U4M/G6O306p29PjhcjjNSfeh1NMsU5XpuLEMW4sPMVaUSxmBqFjnqV5FiZB6Fge3R fgO+l8XBXro3f7XI+Em9Nve76up+BFFMTDY2kESYC8zrqN2flLwl5D90NMG99lPeNw gRSw1R5xGBBXeKWuSxgljGsITKCDNEh8GPXcCL44= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Nadeau Thomas In-Reply-To: <20160111112910.GB41791@elstar.local> Date: Mon, 11 Jan 2016 07:51:14 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8C1F0E55-E767-4673-8294-709031C51B96@lucidvision.com> References: <20160108.125237.1815033897965196525.mbj@tail-f.com> <20160108120858.GA30099@elstar.local> <20160108.132619.2106992589983161035.mbj@tail-f.com> <4134AA7D-F3E0-4953-9E14-D0FEA1B68EEA@gmail.com> <20160111112910.GB41791@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3112) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=2 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 241, in=3018, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: RTG YANG Design Team , netmod WG , Benoit Claise Subject: Re: [netmod] [yang-doctors] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 12:51:23 -0000 Yes, this is correct. We agreed to this explicitly. =E2=80=94Tom > On Jan 11, 2016:6:29 AM, at 6:29 AM, Juergen Schoenwaelder = wrote: >=20 > I think we discussed at one of the previous IETFs that we will use > YANG 1.1 in the IETF once it is published. Please check the archives. > If I am correct, then you would have to be fast with finishing the ACL > model. >=20 > /js >=20 > On Mon, Jan 11, 2016 at 12:16:40PM +0100, Dean Bogdanovic wrote: >> Are there any other opinions on switching YANG version for ACL model = from 1.0 to 1.1? Would like to get more opinions on this, besides = Martin. >>=20 >> Dean >>=20 >>> On Jan 8, 2016, at 1:26 PM, Martin Bjorklund wrote: >>>=20 >>> Dean Bogdanovic > = wrote: >>>>=20 >>>>> On Jan 8, 2016, at 1:09 PM, Juergen Schoenwaelder >>>>> wrote: >>>>>=20 >>>>> On Fri, Jan 08, 2016 at 12:52:37PM +0100, Martin Bjorklund wrote: >>>>>> Juergen Schoenwaelder = wrote: >>>>>>> On Thu, Jan 07, 2016 at 04:21:42PM +0100, Martin Bjorklund = wrote: >>>>>>>>=20 >>>>>>>> With YANG 1.1, a leafref can be marked as "require-instance = false", >>>>>>>> which allows a interface-state-ref to be used in config: >>>>>>>>=20 >>>>>>>> type if:interface-state-ref { >>>>>>>> require-instance false; >>>>>>>> } >>>>>>>> // + add description that explains what happens if there is no = such >>>>>>>> // instance >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> (NOTE: this doesn't work w/ pyang at the momement, I am working = on a >>>>>>>> fix) >>>>>>>>=20 >>>>>>>=20 >>>>>>> And it would have to be if:interface-ref instead >>>>>>> if:interface-state-ref >>>>>>> I think. >>>>>>=20 >>>>>> No, I meant interface-state-ref. This way you can put a filter = on >>>>>> non-configured interfaces. >>>>>>=20 >>>>>=20 >>>>> But with require-instance false, this is also true for >>>>> if:interface-ref. If I preconfigure and interface, I might also = want >>>>> to preconfigure ACLs refering the preconfigure interface. And note >>>>> that if:interface-state-ref refers to a config false leaf. >>>>=20 >>>> In this case we have to change to yang-version 1.1. The plan was to >>>> have it for 1.0. Do we want to move the ACL model to YANG minimum >>>> version 1.1? >>>=20 >>> I think it is ok. We're fixing issues like this one in 1.1 so that = we >>> don't have to rely on various workarounds. Note that the second = WGLC >>> for 1.1 just ended, w/ mostly minor proposed edits. >>>=20 >>>=20 >>> /martin >>=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Jan 11 05:26:01 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3ACD1A8A51 for ; Mon, 11 Jan 2016 05:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqRQqXlEpZrI for ; Mon, 11 Jan 2016 05:25:56 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0790.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::790]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EFA11A8A47 for ; Mon, 11 Jan 2016 05:25:55 -0800 (PST) Received: from CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) by CY1PR0501MB1612.namprd05.prod.outlook.com (10.161.162.140) with Microsoft SMTP Server (TLS) id 15.1.361.13; Mon, 11 Jan 2016 13:25:33 +0000 Received: from CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) by CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) with mapi id 15.01.0361.006; Mon, 11 Jan 2016 13:25:34 +0000 From: Gert Grammel To: Ladislav Lhotka , NETMOD WG Thread-Topic: [netmod] applied configuration and system-controlled entries Thread-Index: AQHRSTUGxYtkEO44aUCWX59qiQKmfp72U6Bg Date: Mon, 11 Jan 2016 13:25:33 +0000 Message-ID: References: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> In-Reply-To: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; x-originating-ip: [193.110.55.14] x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1612; 5:Qc3NVpF2MTNHTiYhJgg4CrLctjZZyaE3lbFNPw54KXoniqVZeq5f72WSCUrthfNAAl+Gh+axgCy1lH+N6Nox96xLOJ6FmPjGkGeODnSwFn2vWBGDnaPMz5p0Eps+WjzUSp3yx3QsgiiWwz5Rcaehfw==; 24:MWpVBbBqzZEsWlwQzy4AyyeVfoPO6mDv8994NCAS9U9tAvHzKFA2Y2WIUCLIIWaSRxTo3lZGabhTrFv4B8geAmjyDQA1Vg4v/HnxwRC5Mt4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1612; x-ms-office365-filtering-correlation-id: d37101c5-8b42-44a1-7089-08d31a8aaf7a x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:CY1PR0501MB1612; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1612; x-forefront-prvs: 0818724663 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(199003)(13464003)(189002)(81156007)(1096002)(33656002)(122556002)(50986999)(101416001)(586003)(1220700001)(2950100001)(76576001)(2906002)(66066001)(19580395003)(575784001)(87936001)(99286002)(86362001)(76176999)(77096005)(15975445007)(6116002)(92566002)(40100003)(5001960100002)(102836003)(5003600100002)(189998001)(5008740100001)(74316001)(106356001)(10400500002)(54356999)(5002640100001)(97736004)(106116001)(3846002)(105586002)(107886002)(5004730100002)(5001770100001)(2900100001)(19580405001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1612; H:CY1PR0501MB1609.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:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2016 13:25:33.9499 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1612 Archived-At: Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 13:26:00 -0000 Lada, The requirement says: D. When a configuration change for any intended configuration node has been successfully applied to the server (e.g. not failed, nor deferred due to absent hardware) then the existence and value of the corresponding applied configuration node must match the intended configuration node. I don't see that this would limit the case you described below. In your cas= e there is no intended config, hence there is no "corresponding applied con= figuration" either. Besides that, the case you mentioned should be clearly in scope.=20 --Gert >-----Original Message----- >From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka >Sent: 07 January 2016 11:20 >To: NETMOD WG >Subject: [netmod] applied configuration and system-controlled entries > >Hi, > >a good use of applied configuration could be to formalize the concept of >system-controlled entries as defined in RFC 7223, routing-cfg, and probabl= y >elsewhere, too. > >My idea is that system-controlled interfaces or other entries would appear= in >applied configuration, but not in intended configuration until something n= eeds >to be really configured. We could then permit leafrefs from intended >configuration to refer to leafs in applied configuration. One case where t= his >would be useful is the ACL module, where match conditions refering to >interfaces currently have to use plain strings as references to interface = names. > >However, the above idea seems to be at odds with requirement 1D in opstate= - >reqs-02. I wonder: could that requirement be relaxed or removed so that th= e >above use case can be supported? > >Thanks, Lada > >-- >Ladislav Lhotka, CZ.NIC Labs >PGP Key ID: E74E8C0C > > > > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Jan 11 05:49:00 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF041A8A86 for ; Mon, 11 Jan 2016 05:48:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.652 X-Spam-Level: X-Spam-Status: No, score=-5.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeJPWYFG9NdO for ; Mon, 11 Jan 2016 05:48:56 -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 E22A51A8A7F for ; Mon, 11 Jan 2016 05:48:55 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:550b:3775:13a2:612b] (unknown [IPv6:2001:718:1a02:1:550b:3775:13a2:612b]) by mail.nic.cz (Postfix) with ESMTPSA id 374C11813A6; Mon, 11 Jan 2016 14:48:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452520134; bh=Qf/Be9ahP/6TWu9NRQNuWxUve2xcaxuRprfSbnIppko=; h=From:Date:To; b=BA90l/35ah4vQth50oSPZiB6M4Uce9imVYXgu6syUZdY7ERL/+rdLr7a8bAh3TLlw Et4S5RGDNWyYJtORN9LKTCRPx2j+yPh+Kk+09X90f+7WVJ/mBN+jhlaw8xgOMe8xe9 nwMGl3J3OKTltcfvSTchYsu5gEGvhwqlJGR6pRNU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 11 Jan 2016 14:48:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> To: Gert Grammel X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: NETMOD WG Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 13:48:58 -0000 Hi Gert, > On 11 Jan 2016, at 14:25, Gert Grammel wrote: >=20 > Lada, >=20 > The requirement says: > D. When a configuration change for any intended configuration > node has been successfully applied to the server (e.g. not > failed, nor deferred due to absent hardware) then the > existence and value of the corresponding applied > configuration node must match the intended configuration > node. >=20 > I don't see that this would limit the case you described below. In = your case there is no intended config, hence there is no "corresponding = applied configuration" either. You are right, the requirement can be interpreted this way. I thought = that applied configuration was supposed to be identical to intended = after some synchronization period. >=20 > Besides that, the case you mentioned should be clearly in scope. Great, then I am open to discussing what this could mean for the = existing modules (ietf-interfaces, ietf-routing, ACL etc.). One useful change to YANG semantics could be that a leafref with = require-instance=3Dtrue would refer to applied configuration. = Specifically, the ACL module could then simply use "if:interface-ref" = (with require-instance=3Dtrue) as the type for "input-interface".=20 Thanks, Lada > =20 >=20 > --Gert >=20 >> -----Original Message----- >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav = Lhotka >> Sent: 07 January 2016 11:20 >> To: NETMOD WG >> Subject: [netmod] applied configuration and system-controlled entries >>=20 >> Hi, >>=20 >> a good use of applied configuration could be to formalize the concept = of >> system-controlled entries as defined in RFC 7223, routing-cfg, and = probably >> elsewhere, too. >>=20 >> My idea is that system-controlled interfaces or other entries would = appear in >> applied configuration, but not in intended configuration until = something needs >> to be really configured. We could then permit leafrefs from intended >> configuration to refer to leafs in applied configuration. One case = where this >> would be useful is the ACL module, where match conditions refering to >> interfaces currently have to use plain strings as references to = interface names. >>=20 >> However, the above idea seems to be at odds with requirement 1D in = opstate- >> reqs-02. I wonder: could that requirement be relaxed or removed so = that the >> above use case can be supported? >>=20 >> Thanks, Lada >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jan 11 05:54:41 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574461A00B9 for ; Mon, 11 Jan 2016 05:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TALpyEknjXbt for ; Mon, 11 Jan 2016 05:54: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 3F4E11A00B8 for ; Mon, 11 Jan 2016 05:54:36 -0800 (PST) Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id DC3CE1AE047A; Mon, 11 Jan 2016 14:54:34 +0100 (CET) Date: Mon, 11 Jan 2016 14:54:36 +0100 (CET) Message-Id: <20160111.145436.1312067595929182117.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 13:54:38 -0000 Ladislav Lhotka wrote: > Hi Gert, > > > On 11 Jan 2016, at 14:25, Gert Grammel wrote: > > > > Lada, > > > > The requirement says: > > D. When a configuration change for any intended configuration > > node has been successfully applied to the server (e.g. not > > failed, nor deferred due to absent hardware) then the > > existence and value of the corresponding applied > > configuration node must match the intended configuration > > node. > > > > I don't see that this would limit the case you described below. In > > your case there is no intended config, hence there is no > > "corresponding applied configuration" either. > > You are right, the requirement can be interpreted this way. I thought > that applied configuration was supposed to be identical to intended > after some synchronization period. This is a very important point to clarify. Can there ever be data in "applied" that is not in "intended"? I think Anees & Rob previously said "no", but I might be wrong. /martin > > > > > Besides that, the case you mentioned should be clearly in scope. > > Great, then I am open to discussing what this could mean for the > existing modules (ietf-interfaces, ietf-routing, ACL etc.). > > One useful change to YANG semantics could be that a leafref with > require-instance=true would refer to applied > configuration. Specifically, the ACL module could then simply use > "if:interface-ref" (with require-instance=true) as the type for > "input-interface". > > Thanks, Lada > > > > > > > --Gert > > > >> -----Original Message----- > >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav > >> Lhotka > >> Sent: 07 January 2016 11:20 > >> To: NETMOD WG > >> Subject: [netmod] applied configuration and system-controlled entries > >> > >> Hi, > >> > >> a good use of applied configuration could be to formalize the concept > >> of > >> system-controlled entries as defined in RFC 7223, routing-cfg, and > >> probably > >> elsewhere, too. > >> > >> My idea is that system-controlled interfaces or other entries would > >> appear in > >> applied configuration, but not in intended configuration until > >> something needs > >> to be really configured. We could then permit leafrefs from intended > >> configuration to refer to leafs in applied configuration. One case > >> where this > >> would be useful is the ACL module, where match conditions refering to > >> interfaces currently have to use plain strings as references to > >> interface names. > >> > >> However, the above idea seems to be at odds with requirement 1D in > >> opstate- > >> reqs-02. I wonder: could that requirement be relaxed or removed so > >> that the > >> above use case can be supported? > >> > >> Thanks, Lada > >> > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: E74E8C0C > >> > >> > >> > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Mon Jan 11 05:56:29 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424D61A00B8 for ; Mon, 11 Jan 2016 05:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.352 X-Spam-Level: X-Spam-Status: No, score=-5.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13DyMN0USGSP for ; Mon, 11 Jan 2016 05:56:26 -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 3BAF31A00B0 for ; Mon, 11 Jan 2016 05:56:26 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:550b:3775:13a2:612b] (unknown [IPv6:2001:718:1a02:1:550b:3775:13a2:612b]) by mail.nic.cz (Postfix) with ESMTPSA id B680518181E; Mon, 11 Jan 2016 14:56:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452520584; bh=CwxX1Y0+4/9TgnZXJhhy/ZGJJKqEVOR80fNoREvvApc=; h=From:Date:To; b=j+EVtbmgSpwe978Llyafy7I7fVkovzbdsGhxsT9AYnQT/zkLHVsf11FXfEFQoAtFO 1btVOlpzTIMMKRthgNoTR+etkGJu44vGTEPXSAPu/B0Z9Uf/7VP/0wdZnJ96AFCDGr yxp5J/isqC68AoY02ELxctfwYYVyvJmOvcmbhyQU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160111.145436.1312067595929182117.mbj@tail-f.com> Date: Mon, 11 Jan 2016 14:56:25 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> <20160111.145436.1312067595929182117.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 13:56:28 -0000 > On 11 Jan 2016, at 14:54, Martin Bjorklund wrote: > > Ladislav Lhotka wrote: >> Hi Gert, >> >>> On 11 Jan 2016, at 14:25, Gert Grammel wrote: >>> >>> Lada, >>> >>> The requirement says: >>> D. When a configuration change for any intended configuration >>> node has been successfully applied to the server (e.g. not >>> failed, nor deferred due to absent hardware) then the >>> existence and value of the corresponding applied >>> configuration node must match the intended configuration >>> node. >>> >>> I don't see that this would limit the case you described below. In >>> your case there is no intended config, hence there is no >>> "corresponding applied configuration" either. >> >> You are right, the requirement can be interpreted this way. I thought >> that applied configuration was supposed to be identical to intended >> after some synchronization period. > > This is a very important point to clarify. Can there ever be data in > "applied" that is not in "intended"? I think Anees & Rob previously > said "no", but I might be wrong. > Yup, I also had this impression. Lada > > > /martin > > >> >>> >>> Besides that, the case you mentioned should be clearly in scope. >> >> Great, then I am open to discussing what this could mean for the >> existing modules (ietf-interfaces, ietf-routing, ACL etc.). >> >> One useful change to YANG semantics could be that a leafref with >> require-instance=true would refer to applied >> configuration. Specifically, the ACL module could then simply use >> "if:interface-ref" (with require-instance=true) as the type for >> "input-interface". >> >> Thanks, Lada >> >>> >>> >>> --Gert >>> >>>> -----Original Message----- >>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav >>>> Lhotka >>>> Sent: 07 January 2016 11:20 >>>> To: NETMOD WG >>>> Subject: [netmod] applied configuration and system-controlled entries >>>> >>>> Hi, >>>> >>>> a good use of applied configuration could be to formalize the concept >>>> of >>>> system-controlled entries as defined in RFC 7223, routing-cfg, and >>>> probably >>>> elsewhere, too. >>>> >>>> My idea is that system-controlled interfaces or other entries would >>>> appear in >>>> applied configuration, but not in intended configuration until >>>> something needs >>>> to be really configured. We could then permit leafrefs from intended >>>> configuration to refer to leafs in applied configuration. One case >>>> where this >>>> would be useful is the ACL module, where match conditions refering to >>>> interfaces currently have to use plain strings as references to >>>> interface names. >>>> >>>> However, the above idea seems to be at odds with requirement 1D in >>>> opstate- >>>> reqs-02. I wonder: could that requirement be relaxed or removed so >>>> that the >>>> above use case can be supported? >>>> >>>> Thanks, Lada >>>> >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jan 11 06:07:20 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB2D71A00E5 for ; Mon, 11 Jan 2016 06:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ef0ja_vMOQwP for ; Mon, 11 Jan 2016 06:07:15 -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 E61351A00E1 for ; Mon, 11 Jan 2016 06:07:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5338; q=dns/txt; s=iport; t=1452521234; x=1453730834; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=R54Cz1RIYY6u8MugTwsWo1mugTgB/cRGUU3rfNLol18=; b=IBJYly1XA9ehVrXipRR7t6dgIHqUCs9NxAQczo68Yl+2Mhtz2zJ64OGV 3UqVaH+OIqnZRVESJngUx4R/g90kPktwv+WC4Vy0ieND7xtCUYit4Fiea lZzSKojL5CHdn7thOfpf/3MLOTnGsBhHcDzxZhW7L3YvY9EfZPTSVI23L c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAgBitpNW/4ENJK1egzpSbQaIU7NeA?= =?us-ascii?q?Q2BZhgKhSNKAhyBBjgUAQEBAQEBAYEKhDQBAQEEAQEBIBE6BAcMBAIBCA4DBAE?= =?us-ascii?q?BAQICIwMCAgIlCxQBCAgCBAENBYguDq5yj30BAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEUBIEBilSEMQ2DNYFJBYdhhxKIIAGNWIFejR+KXoNyASABAUKCERyBXXKEXkK?= =?us-ascii?q?BCAEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,553,1444694400"; d="scan'208";a="226074471" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Jan 2016 14:07:14 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u0BE7D5r032183 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Jan 2016 14:07:14 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 11 Jan 2016 09:07:13 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Mon, 11 Jan 2016 09:07:13 -0500 From: "Acee Lindem (acee)" To: Martin Bjorklund , "lhotka@nic.cz" Thread-Topic: [netmod] applied configuration and system-controlled entries Thread-Index: AQHRSTUHdGA/4fiHbE6BWSvoked/1572qICAgAAGhgCAAAGYAIAAFEqA Date: Mon, 11 Jan 2016 14:07:13 +0000 Message-ID: References: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> <20160111.145436.1312067595929182117.mbj@tail-f.com> In-Reply-To: <20160111.145436.1312067595929182117.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.43.19] Content-Type: text/plain; charset="utf-8" Content-ID: <5479EDCA63432C44B1AF51C649264FD3@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 14:07:19 -0000 DQoNCk9uIDEvMTEvMTYsIDI6NTQgUE0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIE1hcnRpbiBCam9y a2x1bmQiDQo8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIG1iakB0YWlsLWYu Y29tPiB3cm90ZToNCg0KPkxhZGlzbGF2IExob3RrYSA8bGhvdGthQG5pYy5jej4gd3JvdGU6DQo+ PiBIaSBHZXJ0LA0KPj4gDQo+PiA+IE9uIDExIEphbiAyMDE2LCBhdCAxNDoyNSwgR2VydCBHcmFt bWVsIDxnZ3JhbW1lbEBqdW5pcGVyLm5ldD4gd3JvdGU6DQo+PiA+IA0KPj4gPiBMYWRhLA0KPj4g PiANCj4+ID4gVGhlIHJlcXVpcmVtZW50IHNheXM6DQo+PiA+ICAgICAgIEQuICBXaGVuIGEgY29u ZmlndXJhdGlvbiBjaGFuZ2UgZm9yIGFueSBpbnRlbmRlZCBjb25maWd1cmF0aW9uDQo+PiA+ICAg ICAgICAgICBub2RlIGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBhcHBsaWVkIHRvIHRoZSBzZXJ2ZXIg KGUuZy4gbm90DQo+PiA+ICAgICAgICAgICBmYWlsZWQsIG5vciBkZWZlcnJlZCBkdWUgdG8gYWJz ZW50IGhhcmR3YXJlKSB0aGVuIHRoZQ0KPj4gPiAgICAgICAgICAgZXhpc3RlbmNlIGFuZCB2YWx1 ZSBvZiB0aGUgY29ycmVzcG9uZGluZyBhcHBsaWVkDQo+PiA+ICAgICAgICAgICBjb25maWd1cmF0 aW9uIG5vZGUgbXVzdCBtYXRjaCB0aGUgaW50ZW5kZWQgY29uZmlndXJhdGlvbg0KPj4gPiAgICAg ICAgICAgbm9kZS4NCj4+ID4gDQo+PiA+IEkgZG9uJ3Qgc2VlIHRoYXQgdGhpcyB3b3VsZCBsaW1p dCB0aGUgY2FzZSB5b3UgZGVzY3JpYmVkIGJlbG93LiBJbg0KPj4gPiB5b3VyIGNhc2UgdGhlcmUg aXMgbm8gaW50ZW5kZWQgY29uZmlnLCBoZW5jZSB0aGVyZSBpcyBubw0KPj4gPiAiY29ycmVzcG9u ZGluZyBhcHBsaWVkIGNvbmZpZ3VyYXRpb24iIGVpdGhlci4NCj4+IA0KPj4gWW91IGFyZSByaWdo dCwgdGhlIHJlcXVpcmVtZW50IGNhbiBiZSBpbnRlcnByZXRlZCB0aGlzIHdheS4gSSB0aG91Z2h0 DQo+PiB0aGF0IGFwcGxpZWQgY29uZmlndXJhdGlvbiB3YXMgc3VwcG9zZWQgdG8gYmUgaWRlbnRp Y2FsIHRvIGludGVuZGVkDQo+PiBhZnRlciBzb21lIHN5bmNocm9uaXphdGlvbiBwZXJpb2QuDQo+ DQo+VGhpcyBpcyBhIHZlcnkgaW1wb3J0YW50IHBvaW50IHRvIGNsYXJpZnkuICBDYW4gdGhlcmUg ZXZlciBiZSBkYXRhIGluDQo+ImFwcGxpZWQiIHRoYXQgaXMgbm90IGluICJpbnRlbmRlZCI/ICBJ IHRoaW5rIEFuZWVzICYgUm9iIHByZXZpb3VzbHkNCj5zYWlkICJubyIsIGJ1dCBJIG1pZ2h0IGJl IHdyb25nLg0KDQpNeSBvcGluaW9uIGlzIHRoYXQgdGhlcmUgaXMgYSAxLTEgcmVsYXRpb25zaGlw IGJldHdlZW4g4oCcYXBwbGllZOKAnSBhbmQNCuKAnGludGVuZGVk4oCdIGNvbmZpZy4NCg0KVGhh bmtzLA0KQWNlZSANCg0KPg0KPg0KPg0KPi9tYXJ0aW4NCj4NCj4NCj4+IA0KPj4gPiANCj4+ID4g QmVzaWRlcyB0aGF0LCB0aGUgY2FzZSB5b3UgbWVudGlvbmVkIHNob3VsZCBiZSBjbGVhcmx5IGlu IHNjb3BlLg0KPj4gDQo+PiBHcmVhdCwgdGhlbiBJIGFtIG9wZW4gdG8gZGlzY3Vzc2luZyB3aGF0 IHRoaXMgY291bGQgbWVhbiBmb3IgdGhlDQo+PiBleGlzdGluZyBtb2R1bGVzIChpZXRmLWludGVy ZmFjZXMsIGlldGYtcm91dGluZywgQUNMIGV0Yy4pLg0KPj4gDQo+PiBPbmUgdXNlZnVsIGNoYW5n ZSB0byBZQU5HIHNlbWFudGljcyBjb3VsZCBiZSB0aGF0IGEgbGVhZnJlZiB3aXRoDQo+PiByZXF1 aXJlLWluc3RhbmNlPXRydWUgd291bGQgcmVmZXIgdG8gYXBwbGllZA0KPj4gY29uZmlndXJhdGlv bi4gU3BlY2lmaWNhbGx5LCB0aGUgQUNMIG1vZHVsZSBjb3VsZCB0aGVuIHNpbXBseSB1c2UNCj4+ ICJpZjppbnRlcmZhY2UtcmVmIiAod2l0aCByZXF1aXJlLWluc3RhbmNlPXRydWUpIGFzIHRoZSB0 eXBlIGZvcg0KPj4gImlucHV0LWludGVyZmFjZSIuDQo+PiANCj4+IFRoYW5rcywgTGFkYQ0KPj4g DQo+PiA+ICANCj4+ID4gDQo+PiA+IC0tR2VydA0KPj4gPiANCj4+ID4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+PiA+PiBGcm9tOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIExhZGlzbGF2DQo+PiA+PiBMaG90a2ENCj4+ID4+IFNlbnQ6 IDA3IEphbnVhcnkgMjAxNiAxMToyMA0KPj4gPj4gVG86IE5FVE1PRCBXRw0KPj4gPj4gU3ViamVj dDogW25ldG1vZF0gYXBwbGllZCBjb25maWd1cmF0aW9uIGFuZCBzeXN0ZW0tY29udHJvbGxlZCBl bnRyaWVzDQo+PiA+PiANCj4+ID4+IEhpLA0KPj4gPj4gDQo+PiA+PiBhIGdvb2QgdXNlIG9mIGFw cGxpZWQgY29uZmlndXJhdGlvbiBjb3VsZCBiZSB0byBmb3JtYWxpemUgdGhlIGNvbmNlcHQNCj4+ ID4+IG9mDQo+PiA+PiBzeXN0ZW0tY29udHJvbGxlZCBlbnRyaWVzIGFzIGRlZmluZWQgaW4gUkZD IDcyMjMsIHJvdXRpbmctY2ZnLCBhbmQNCj4+ID4+IHByb2JhYmx5DQo+PiA+PiBlbHNld2hlcmUs IHRvby4NCj4+ID4+IA0KPj4gPj4gTXkgaWRlYSBpcyB0aGF0IHN5c3RlbS1jb250cm9sbGVkIGlu dGVyZmFjZXMgb3Igb3RoZXIgZW50cmllcyB3b3VsZA0KPj4gPj4gYXBwZWFyIGluDQo+PiA+PiBh cHBsaWVkIGNvbmZpZ3VyYXRpb24sIGJ1dCBub3QgaW4gaW50ZW5kZWQgY29uZmlndXJhdGlvbiB1 bnRpbA0KPj4gPj4gc29tZXRoaW5nIG5lZWRzDQo+PiA+PiB0byBiZSByZWFsbHkgY29uZmlndXJl ZC4gV2UgY291bGQgdGhlbiBwZXJtaXQgbGVhZnJlZnMgZnJvbSBpbnRlbmRlZA0KPj4gPj4gY29u ZmlndXJhdGlvbiB0byByZWZlciB0byBsZWFmcyBpbiBhcHBsaWVkIGNvbmZpZ3VyYXRpb24uIE9u ZSBjYXNlDQo+PiA+PiB3aGVyZSB0aGlzDQo+PiA+PiB3b3VsZCBiZSB1c2VmdWwgaXMgdGhlIEFD TCBtb2R1bGUsIHdoZXJlIG1hdGNoIGNvbmRpdGlvbnMgcmVmZXJpbmcgdG8NCj4+ID4+IGludGVy ZmFjZXMgY3VycmVudGx5IGhhdmUgdG8gdXNlIHBsYWluIHN0cmluZ3MgYXMgcmVmZXJlbmNlcyB0 bw0KPj4gPj4gaW50ZXJmYWNlIG5hbWVzLg0KPj4gPj4gDQo+PiA+PiBIb3dldmVyLCB0aGUgYWJv dmUgaWRlYSBzZWVtcyB0byBiZSBhdCBvZGRzIHdpdGggcmVxdWlyZW1lbnQgMUQgaW4NCj4+ID4+ IG9wc3RhdGUtDQo+PiA+PiByZXFzLTAyLiBJIHdvbmRlcjogY291bGQgdGhhdCByZXF1aXJlbWVu dCBiZSByZWxheGVkIG9yIHJlbW92ZWQgc28NCj4+ID4+IHRoYXQgdGhlDQo+PiA+PiBhYm92ZSB1 c2UgY2FzZSBjYW4gYmUgc3VwcG9ydGVkPw0KPj4gPj4gDQo+PiA+PiBUaGFua3MsIExhZGENCj4+ ID4+IA0KPj4gPj4gLS0NCj4+ID4+IExhZGlzbGF2IExob3RrYSwgQ1ouTklDIExhYnMNCj4+ID4+ IFBHUCBLZXkgSUQ6IEU3NEU4QzBDDQo+PiA+PiANCj4+ID4+IA0KPj4gPj4gDQo+PiA+PiANCj4+ ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+ PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+PiA+PiBuZXRtb2RAaWV0Zi5vcmcNCj4+ID4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+PiANCj4+IC0tDQo+PiBM YWRpc2xhdiBMaG90a2EsIENaLk5JQyBMYWJzDQo+PiBQR1AgS2V5IElEOiBFNzRFOEMwQw0KPj4g DQo+PiANCj4+IA0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4gbmV0bW9kQGlldGYub3JnDQo+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPj4gDQo+DQo+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5uZXRtb2Qg bWFpbGluZyBsaXN0DQo+bmV0bW9kQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uZXRtb2QNCg0K From nobody Mon Jan 11 06:11:29 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0C91A00F1 for ; Mon, 11 Jan 2016 06:11:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BORxS1k37CXm for ; Mon, 11 Jan 2016 06:11:25 -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 F366D1A00EE for ; Mon, 11 Jan 2016 06:11:24 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C2676747; Mon, 11 Jan 2016 15:11:23 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id RjBwwJU-am4Y; Mon, 11 Jan 2016 15:11: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; Mon, 11 Jan 2016 15:11:23 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E0B412002C; Mon, 11 Jan 2016 15:11:22 +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 ZfNezAe8C-n1; Mon, 11 Jan 2016 15:11:21 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3020E20013; Mon, 11 Jan 2016 15:11:21 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1FF4639816B6; Mon, 11 Jan 2016 15:11:18 +0100 (CET) Date: Mon, 11 Jan 2016 15:11:18 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20160111141116.GB42469@elstar.local> Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, netmod@ietf.org References: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> <20160111.145436.1312067595929182117.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160111.145436.1312067595929182117.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 14:11:27 -0000 On Mon, Jan 11, 2016 at 02:54:36PM +0100, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > Hi Gert, > > > > > On 11 Jan 2016, at 14:25, Gert Grammel wrote: > > > > > > Lada, > > > > > > The requirement says: > > > D. When a configuration change for any intended configuration > > > node has been successfully applied to the server (e.g. not > > > failed, nor deferred due to absent hardware) then the > > > existence and value of the corresponding applied > > > configuration node must match the intended configuration > > > node. > > > > > > I don't see that this would limit the case you described below. In > > > your case there is no intended config, hence there is no > > > "corresponding applied configuration" either. > > > > You are right, the requirement can be interpreted this way. I thought > > that applied configuration was supposed to be identical to intended > > after some synchronization period. > > This is a very important point to clarify. Can there ever be data in > "applied" that is not in "intended"? I think Anees & Rob previously > said "no", but I might be wrong. > If there is time delay between editing intended and the applied config matching the edits of intended, then I supose this can happen (I delete a resource from intended but it is still around until intended has been fully synced). I would find it interesting if some edits are always assumed to be synchronous but others may be asynchronous. And Lada, I think applied may happen to be never identical to intended if, for example, hardware is absent or other missing resources prevent certain parts of intended to become applied. My understanding is that applied config in general forms an extended subset of intended config. And to fully understand what a device is doing, I may need to obtain its entire operational state since the applied config may not include state obtained dynamically from other sources. But I might still all be wrong... /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 11 06:11:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD65B1A00FC for ; Mon, 11 Jan 2016 06:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHO4G9kc6g4z for ; Mon, 11 Jan 2016 06:11:40 -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 54EB61A00FD for ; Mon, 11 Jan 2016 06:11:40 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:550b:3775:13a2:612b] (unknown [IPv6:2001:718:1a02:1:550b:3775:13a2:612b]) by mail.nic.cz (Postfix) with ESMTPSA id D09461810BA; Mon, 11 Jan 2016 15:11:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452521498; bh=XHYKDmN+Ks9hrcQG4Lop3U4CGvzByXBdJWsa0w71hs4=; h=From:Date:To; b=GGwAYsSXdIiS6UcBlRqw/0ltNrb5qjmmwNaMEJz+yFSam5lWuoxzpZQ/m+TT0p2ns U17Ng7yzFe0MbI97Ob035ENuPObzWLvpsgi9ogo7+OElBntHXDa6yDJkpaK9OzZBCV mWUFcXENY+WS+/A6kbvnJUMzCJi61MERRZGxL1kE= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 11 Jan 2016 15:11:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6C1140C1-26B6-44A9-AD77-7D9034DC3AE4@nic.cz> References: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> <20160111.145436.1312067595929182117.mbj@tail-f.com> To: "Acee Lindem (acee)" X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 14:11:42 -0000 > On 11 Jan 2016, at 15:07, Acee Lindem (acee) wrote: >=20 >=20 >=20 > On 1/11/16, 2:54 PM, "netmod on behalf of Martin Bjorklund" > wrote: >=20 >> Ladislav Lhotka wrote: >>> Hi Gert, >>>=20 >>>> On 11 Jan 2016, at 14:25, Gert Grammel = wrote: >>>>=20 >>>> Lada, >>>>=20 >>>> The requirement says: >>>> D. When a configuration change for any intended configuration >>>> node has been successfully applied to the server (e.g. not >>>> failed, nor deferred due to absent hardware) then the >>>> existence and value of the corresponding applied >>>> configuration node must match the intended configuration >>>> node. >>>>=20 >>>> I don't see that this would limit the case you described below. In >>>> your case there is no intended config, hence there is no >>>> "corresponding applied configuration" either. >>>=20 >>> You are right, the requirement can be interpreted this way. I = thought >>> that applied configuration was supposed to be identical to intended >>> after some synchronization period. >>=20 >> This is a very important point to clarify. Can there ever be data in >> "applied" that is not in "intended"? I think Anees & Rob previously >> said "no", but I might be wrong. >=20 > My opinion is that there is a 1-1 relationship between =E2=80=9Capplied=E2= =80=9D and > =E2=80=9Cintended=E2=80=9D config. Do you mean their data model or instances? The point is: if the device = has an interface, say "eth0" that is operational and configurable, but = hasn't been configured so far via intended config, then does "eth0" = entry appear in the "if:interface" list of applied config or not? Lada >=20 > Thanks, > Acee=20 >=20 >>=20 >>=20 >>=20 >> /martin >>=20 >>=20 >>>=20 >>>>=20 >>>> Besides that, the case you mentioned should be clearly in scope. >>>=20 >>> Great, then I am open to discussing what this could mean for the >>> existing modules (ietf-interfaces, ietf-routing, ACL etc.). >>>=20 >>> One useful change to YANG semantics could be that a leafref with >>> require-instance=3Dtrue would refer to applied >>> configuration. Specifically, the ACL module could then simply use >>> "if:interface-ref" (with require-instance=3Dtrue) as the type for >>> "input-interface". >>>=20 >>> Thanks, Lada >>>=20 >>>>=20 >>>>=20 >>>> --Gert >>>>=20 >>>>> -----Original Message----- >>>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of = Ladislav >>>>> Lhotka >>>>> Sent: 07 January 2016 11:20 >>>>> To: NETMOD WG >>>>> Subject: [netmod] applied configuration and system-controlled = entries >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> a good use of applied configuration could be to formalize the = concept >>>>> of >>>>> system-controlled entries as defined in RFC 7223, routing-cfg, and >>>>> probably >>>>> elsewhere, too. >>>>>=20 >>>>> My idea is that system-controlled interfaces or other entries = would >>>>> appear in >>>>> applied configuration, but not in intended configuration until >>>>> something needs >>>>> to be really configured. We could then permit leafrefs from = intended >>>>> configuration to refer to leafs in applied configuration. One case >>>>> where this >>>>> would be useful is the ACL module, where match conditions refering = to >>>>> interfaces currently have to use plain strings as references to >>>>> interface names. >>>>>=20 >>>>> However, the above idea seems to be at odds with requirement 1D in >>>>> opstate- >>>>> reqs-02. I wonder: could that requirement be relaxed or removed so >>>>> that the >>>>> above use case can be supported? >>>>>=20 >>>>> Thanks, Lada >>>>>=20 >>>>> -- >>>>> Ladislav Lhotka, CZ.NIC Labs >>>>> PGP Key ID: E74E8C0C >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>=20 >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jan 11 06:13:13 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D85371A00F9 for ; Mon, 11 Jan 2016 06:13:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-jAJMVN-Pat for ; Mon, 11 Jan 2016 06:13:10 -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 92CFA1A00F4 for ; Mon, 11 Jan 2016 06:13:10 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5DBEE751; Mon, 11 Jan 2016 15:13:09 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id BH74xdB2A613; Mon, 11 Jan 2016 15:13: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; Mon, 11 Jan 2016 15:13:08 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id ADF8420033; Mon, 11 Jan 2016 15:13:08 +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 ZOc4QftsGt8u; Mon, 11 Jan 2016 15:13:08 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 861492002B; Mon, 11 Jan 2016 15:13:07 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CF6923981700; Mon, 11 Jan 2016 15:13:06 +0100 (CET) Date: Mon, 11 Jan 2016 15:13:06 +0100 From: Juergen Schoenwaelder To: "Acee Lindem (acee)" Message-ID: <20160111141306.GC42469@elstar.local> Mail-Followup-To: "Acee Lindem (acee)" , Martin Bjorklund , "lhotka@nic.cz" , "netmod@ietf.org" References: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> <20160111.145436.1312067595929182117.mbj@tail-f.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: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 14:13:12 -0000 On Mon, Jan 11, 2016 at 02:07:13PM +0000, Acee Lindem (acee) wrote: > > My opinion is that there is a 1-1 relationship between “applied” and > “intended” config. > I do not understand. Please clarify what 1-1 means here. /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 11 06:14:13 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD691A00FF for ; Mon, 11 Jan 2016 06:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l_ZiVS0lhq30 for ; Mon, 11 Jan 2016 06:14:11 -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 049371A00FD for ; Mon, 11 Jan 2016 06:14:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6406; q=dns/txt; s=iport; t=1452521650; x=1453731250; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pUs+KZChIunxxIE9HUB+dAvYlnQ7QrTYi1YleGjTEjU=; b=bbA0P4kRVobprzC6ry+2B+QjL8ZaNudwwJb0Z587SbT77RJ81g7TajzS oXczyRzKD+Vnm+IqkLcS3ROS2rMau5qR+7kO++mPkMbajljGR6Gv0RBjh YDzcVfM80iIFsGWpyfcvy/EwW/xbqVaW1id5hClKluQEjKXAckghG3hEs Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAgBMt5NW/5JdJa1egzpSbQaIU7NfA?= =?us-ascii?q?Q2BZhgKhSNKAhyBBjgUAQEBAQEBAYEKhDQBAQEDAQEBASAROgQHDAQCAQgRBAE?= =?us-ascii?q?BAQICIwMCAgIlCxQBCAgCBA4FiCYIDq5yj34BAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEUBIEBilSEMQ0Xgx6BSQWHYYcShB2EAwGNWIFejR+KXoNyASABAUKCERyBXXK?= =?us-ascii?q?EXkKBCAEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,553,1444694400"; d="scan'208";a="225344126" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jan 2016 14:14:09 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u0BEE9ia005219 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Jan 2016 14:14:09 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 11 Jan 2016 09:14:08 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Mon, 11 Jan 2016 09:14:08 -0500 From: "Acee Lindem (acee)" To: Ladislav Lhotka Thread-Topic: [netmod] applied configuration and system-controlled entries Thread-Index: AQHRSTUHdGA/4fiHbE6BWSvoked/1572qICAgAAGhgCAAAGYAIAAFEqA///weYCAABF4AA== Date: Mon, 11 Jan 2016 14:14:08 +0000 Message-ID: References: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> <20160111.145436.1312067595929182117.mbj@tail-f.com> <6C1140C1-26B6-44A9-AD77-7D9034DC3AE4@nic.cz> In-Reply-To: <6C1140C1-26B6-44A9-AD77-7D9034DC3AE4@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.43.19] Content-Type: text/plain; charset="utf-8" Content-ID: <32DAF4D617317240A2FC9B0CAC55D657@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 14:14:12 -0000 DQoNCk9uIDEvMTEvMTYsIDM6MTEgUE0sICJMYWRpc2xhdiBMaG90a2EiIDxsaG90a2FAbmljLmN6 PiB3cm90ZToNCg0KPg0KPj4gT24gMTEgSmFuIDIwMTYsIGF0IDE1OjA3LCBBY2VlIExpbmRlbSAo YWNlZSkgPGFjZWVAY2lzY28uY29tPiB3cm90ZToNCj4+IA0KPj4gDQo+PiANCj4+IE9uIDEvMTEv MTYsIDI6NTQgUE0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIE1hcnRpbiBCam9ya2x1bmQiDQo+PiA8 bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIG1iakB0YWlsLWYuY29tPiB3cm90 ZToNCj4+IA0KPj4+IExhZGlzbGF2IExob3RrYSA8bGhvdGthQG5pYy5jej4gd3JvdGU6DQo+Pj4+ IEhpIEdlcnQsDQo+Pj4+IA0KPj4+Pj4gT24gMTEgSmFuIDIwMTYsIGF0IDE0OjI1LCBHZXJ0IEdy YW1tZWwgPGdncmFtbWVsQGp1bmlwZXIubmV0PiB3cm90ZToNCj4+Pj4+IA0KPj4+Pj4gTGFkYSwN Cj4+Pj4+IA0KPj4+Pj4gVGhlIHJlcXVpcmVtZW50IHNheXM6DQo+Pj4+PiAgICAgIEQuICBXaGVu IGEgY29uZmlndXJhdGlvbiBjaGFuZ2UgZm9yIGFueSBpbnRlbmRlZCBjb25maWd1cmF0aW9uDQo+ Pj4+PiAgICAgICAgICBub2RlIGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBhcHBsaWVkIHRvIHRoZSBz ZXJ2ZXIgKGUuZy4gbm90DQo+Pj4+PiAgICAgICAgICBmYWlsZWQsIG5vciBkZWZlcnJlZCBkdWUg dG8gYWJzZW50IGhhcmR3YXJlKSB0aGVuIHRoZQ0KPj4+Pj4gICAgICAgICAgZXhpc3RlbmNlIGFu ZCB2YWx1ZSBvZiB0aGUgY29ycmVzcG9uZGluZyBhcHBsaWVkDQo+Pj4+PiAgICAgICAgICBjb25m aWd1cmF0aW9uIG5vZGUgbXVzdCBtYXRjaCB0aGUgaW50ZW5kZWQgY29uZmlndXJhdGlvbg0KPj4+ Pj4gICAgICAgICAgbm9kZS4NCj4+Pj4+IA0KPj4+Pj4gSSBkb24ndCBzZWUgdGhhdCB0aGlzIHdv dWxkIGxpbWl0IHRoZSBjYXNlIHlvdSBkZXNjcmliZWQgYmVsb3cuIEluDQo+Pj4+PiB5b3VyIGNh c2UgdGhlcmUgaXMgbm8gaW50ZW5kZWQgY29uZmlnLCBoZW5jZSB0aGVyZSBpcyBubw0KPj4+Pj4g ImNvcnJlc3BvbmRpbmcgYXBwbGllZCBjb25maWd1cmF0aW9uIiBlaXRoZXIuDQo+Pj4+IA0KPj4+ PiBZb3UgYXJlIHJpZ2h0LCB0aGUgcmVxdWlyZW1lbnQgY2FuIGJlIGludGVycHJldGVkIHRoaXMg d2F5LiBJIHRob3VnaHQNCj4+Pj4gdGhhdCBhcHBsaWVkIGNvbmZpZ3VyYXRpb24gd2FzIHN1cHBv c2VkIHRvIGJlIGlkZW50aWNhbCB0byBpbnRlbmRlZA0KPj4+PiBhZnRlciBzb21lIHN5bmNocm9u aXphdGlvbiBwZXJpb2QuDQo+Pj4gDQo+Pj4gVGhpcyBpcyBhIHZlcnkgaW1wb3J0YW50IHBvaW50 IHRvIGNsYXJpZnkuICBDYW4gdGhlcmUgZXZlciBiZSBkYXRhIGluDQo+Pj4gImFwcGxpZWQiIHRo YXQgaXMgbm90IGluICJpbnRlbmRlZCI/ICBJIHRoaW5rIEFuZWVzICYgUm9iIHByZXZpb3VzbHkN Cj4+PiBzYWlkICJubyIsIGJ1dCBJIG1pZ2h0IGJlIHdyb25nLg0KPj4gDQo+PiBNeSBvcGluaW9u IGlzIHRoYXQgdGhlcmUgaXMgYSAxLTEgcmVsYXRpb25zaGlwIGJldHdlZW4g4oCcYXBwbGllZOKA nSBhbmQNCj4+IOKAnGludGVuZGVk4oCdIGNvbmZpZy4NCj4NCj5EbyB5b3UgbWVhbiB0aGVpciBk YXRhIG1vZGVsIG9yIGluc3RhbmNlcz8gVGhlIHBvaW50IGlzOiBpZiB0aGUgZGV2aWNlDQo+aGFz IGFuIGludGVyZmFjZSwgc2F5ICJldGgwIiB0aGF0IGlzIG9wZXJhdGlvbmFsIGFuZCBjb25maWd1 cmFibGUsIGJ1dA0KPmhhc24ndCBiZWVuIGNvbmZpZ3VyZWQgc28gZmFyIHZpYSBpbnRlbmRlZCBj b25maWcsIHRoZW4gZG9lcyAiZXRoMCIgZW50cnkNCj5hcHBlYXIgaW4gdGhlICJpZjppbnRlcmZh Y2UiIGxpc3Qgb2YgYXBwbGllZCBjb25maWcgb3Igbm90Pw0KDQpEYXRhIG1vZGVsLg0KDQpBY2Vl DQoNCg0KPg0KPkxhZGENCj4NCj4+IA0KPj4gVGhhbmtzLA0KPj4gQWNlZSANCj4+IA0KPj4+IA0K Pj4+IA0KPj4+IA0KPj4+IC9tYXJ0aW4NCj4+PiANCj4+PiANCj4+Pj4gDQo+Pj4+PiANCj4+Pj4+ IEJlc2lkZXMgdGhhdCwgdGhlIGNhc2UgeW91IG1lbnRpb25lZCBzaG91bGQgYmUgY2xlYXJseSBp biBzY29wZS4NCj4+Pj4gDQo+Pj4+IEdyZWF0LCB0aGVuIEkgYW0gb3BlbiB0byBkaXNjdXNzaW5n IHdoYXQgdGhpcyBjb3VsZCBtZWFuIGZvciB0aGUNCj4+Pj4gZXhpc3RpbmcgbW9kdWxlcyAoaWV0 Zi1pbnRlcmZhY2VzLCBpZXRmLXJvdXRpbmcsIEFDTCBldGMuKS4NCj4+Pj4gDQo+Pj4+IE9uZSB1 c2VmdWwgY2hhbmdlIHRvIFlBTkcgc2VtYW50aWNzIGNvdWxkIGJlIHRoYXQgYSBsZWFmcmVmIHdp dGgNCj4+Pj4gcmVxdWlyZS1pbnN0YW5jZT10cnVlIHdvdWxkIHJlZmVyIHRvIGFwcGxpZWQNCj4+ Pj4gY29uZmlndXJhdGlvbi4gU3BlY2lmaWNhbGx5LCB0aGUgQUNMIG1vZHVsZSBjb3VsZCB0aGVu IHNpbXBseSB1c2UNCj4+Pj4gImlmOmludGVyZmFjZS1yZWYiICh3aXRoIHJlcXVpcmUtaW5zdGFu Y2U9dHJ1ZSkgYXMgdGhlIHR5cGUgZm9yDQo+Pj4+ICJpbnB1dC1pbnRlcmZhY2UiLg0KPj4+PiAN Cj4+Pj4gVGhhbmtzLCBMYWRhDQo+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IC0tR2VydA0K Pj4+Pj4gDQo+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+PiBGcm9tOiBu ZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExhZGlz bGF2DQo+Pj4+Pj4gTGhvdGthDQo+Pj4+Pj4gU2VudDogMDcgSmFudWFyeSAyMDE2IDExOjIwDQo+ Pj4+Pj4gVG86IE5FVE1PRCBXRw0KPj4+Pj4+IFN1YmplY3Q6IFtuZXRtb2RdIGFwcGxpZWQgY29u ZmlndXJhdGlvbiBhbmQgc3lzdGVtLWNvbnRyb2xsZWQNCj4+Pj4+PmVudHJpZXMNCj4+Pj4+PiAN Cj4+Pj4+PiBIaSwNCj4+Pj4+PiANCj4+Pj4+PiBhIGdvb2QgdXNlIG9mIGFwcGxpZWQgY29uZmln dXJhdGlvbiBjb3VsZCBiZSB0byBmb3JtYWxpemUgdGhlDQo+Pj4+Pj5jb25jZXB0DQo+Pj4+Pj4g b2YNCj4+Pj4+PiBzeXN0ZW0tY29udHJvbGxlZCBlbnRyaWVzIGFzIGRlZmluZWQgaW4gUkZDIDcy MjMsIHJvdXRpbmctY2ZnLCBhbmQNCj4+Pj4+PiBwcm9iYWJseQ0KPj4+Pj4+IGVsc2V3aGVyZSwg dG9vLg0KPj4+Pj4+IA0KPj4+Pj4+IE15IGlkZWEgaXMgdGhhdCBzeXN0ZW0tY29udHJvbGxlZCBp bnRlcmZhY2VzIG9yIG90aGVyIGVudHJpZXMgd291bGQNCj4+Pj4+PiBhcHBlYXIgaW4NCj4+Pj4+ PiBhcHBsaWVkIGNvbmZpZ3VyYXRpb24sIGJ1dCBub3QgaW4gaW50ZW5kZWQgY29uZmlndXJhdGlv biB1bnRpbA0KPj4+Pj4+IHNvbWV0aGluZyBuZWVkcw0KPj4+Pj4+IHRvIGJlIHJlYWxseSBjb25m aWd1cmVkLiBXZSBjb3VsZCB0aGVuIHBlcm1pdCBsZWFmcmVmcyBmcm9tIGludGVuZGVkDQo+Pj4+ Pj4gY29uZmlndXJhdGlvbiB0byByZWZlciB0byBsZWFmcyBpbiBhcHBsaWVkIGNvbmZpZ3VyYXRp b24uIE9uZSBjYXNlDQo+Pj4+Pj4gd2hlcmUgdGhpcw0KPj4+Pj4+IHdvdWxkIGJlIHVzZWZ1bCBp cyB0aGUgQUNMIG1vZHVsZSwgd2hlcmUgbWF0Y2ggY29uZGl0aW9ucyByZWZlcmluZw0KPj4+Pj4+ dG8NCj4+Pj4+PiBpbnRlcmZhY2VzIGN1cnJlbnRseSBoYXZlIHRvIHVzZSBwbGFpbiBzdHJpbmdz IGFzIHJlZmVyZW5jZXMgdG8NCj4+Pj4+PiBpbnRlcmZhY2UgbmFtZXMuDQo+Pj4+Pj4gDQo+Pj4+ Pj4gSG93ZXZlciwgdGhlIGFib3ZlIGlkZWEgc2VlbXMgdG8gYmUgYXQgb2RkcyB3aXRoIHJlcXVp cmVtZW50IDFEIGluDQo+Pj4+Pj4gb3BzdGF0ZS0NCj4+Pj4+PiByZXFzLTAyLiBJIHdvbmRlcjog Y291bGQgdGhhdCByZXF1aXJlbWVudCBiZSByZWxheGVkIG9yIHJlbW92ZWQgc28NCj4+Pj4+PiB0 aGF0IHRoZQ0KPj4+Pj4+IGFib3ZlIHVzZSBjYXNlIGNhbiBiZSBzdXBwb3J0ZWQ/DQo+Pj4+Pj4g DQo+Pj4+Pj4gVGhhbmtzLCBMYWRhDQo+Pj4+Pj4gDQo+Pj4+Pj4gLS0NCj4+Pj4+PiBMYWRpc2xh diBMaG90a2EsIENaLk5JQyBMYWJzDQo+Pj4+Pj4gUEdQIEtleSBJRDogRTc0RThDMEMNCj4+Pj4+ PiANCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QN Cj4+Pj4+PiBuZXRtb2RAaWV0Zi5vcmcNCj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldG1vZA0KPj4+PiANCj4+Pj4gLS0NCj4+Pj4gTGFkaXNsYXYgTGhvdGth LCBDWi5OSUMgTGFicw0KPj4+PiBQR1AgS2V5IElEOiBFNzRFOEMwQw0KPj4+PiANCj4+Pj4gDQo+ Pj4+IA0KPj4+PiANCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4+PiBuZXRtb2RAaWV0Zi5vcmcN Cj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4+Pj4g DQo+Pj4gDQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+Pj4gbmV0bW9kQGlldGYub3JnDQo+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4NCj4tLQ0KPkxhZGlz bGF2IExob3RrYSwgQ1ouTklDIExhYnMNCj5QR1AgS2V5IElEOiBFNzRFOEMwQw0KPg0KPg0KPg0K Pg0KDQo= From nobody Mon Jan 11 06:15:55 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31E801A0104 for ; Mon, 11 Jan 2016 06:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YN9qsBwsvsH3 for ; Mon, 11 Jan 2016 06:15:51 -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 551261A00E8 for ; Mon, 11 Jan 2016 06:15:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3393; q=dns/txt; s=iport; t=1452521751; x=1453731351; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=ZPvscIXPlj39EoF/H9bKgiIT6Du43VcWQ8CMfnBIoqk=; b=aV5NqDAsG2cIwnKhHmGv3aB3h7wy+kPHZNx0p1sqOb40ttJrvZ2LdvuQ yZmjubABN6iBoPDlx79kQ+ysy5gJe9Bv/hfWN4VSL1WiAod3ZHpUuoW+z if8WOywsbiYbgqq2FMEC6Br1CsixtwP9SQhFMXWQH4ajeQpag14iq/x8I Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQDst5NW/xbLJq1ehAxtiFmzYAENg?= =?us-ascii?q?WYYCoUjSgKBWhQBAQEBAQEBgQqENAEBAQMBAQEBNTYKAQwECxEEAQEBCRYIBwk?= =?us-ascii?q?DAgECARUfCQgGAQwGAgEBiCIIDr5zAQEBAQEBAQEBAQEBAQEBAQEBAQEBFASGV?= =?us-ascii?q?oR/hDENhH4BBIdhhxKIII1ZgV6HSoVVil6DcyABAUKECj40hF6BSgEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,553,1444694400"; d="scan'208";a="631535621" 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; 11 Jan 2016 14:15:49 +0000 Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u0BEFnOb028800; Mon, 11 Jan 2016 14:15:49 GMT To: Ladislav Lhotka , Gert Grammel References: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> From: Robert Wilton Message-ID: <5693B918.2080006@cisco.com> Date: Mon, 11 Jan 2016 14:15:52 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: NETMOD WG Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 14:15:54 -0000 Hi Gert, Lada, On 11/01/2016 13:48, Ladislav Lhotka wrote: > Hi Gert, > >> On 11 Jan 2016, at 14:25, Gert Grammel wrote: >> >> Lada, >> >> The requirement says: >> D. When a configuration change for any intended configuration >> node has been successfully applied to the server (e.g. not >> failed, nor deferred due to absent hardware) then the >> existence and value of the corresponding applied >> configuration node must match the intended configuration >> node. >> >> I don't see that this would limit the case you described below. In your case there is no intended config, hence there is no "corresponding applied configuration" either. > You are right, the requirement can be interpreted this way. I thought that applied configuration was supposed to be identical to intended after some synchronization period. Yes, when the system settles, and assuming that all configuration has been successfully applied, then the applied config nodes MUST exactly match the intended config nodes. This point has been explicitly asked of Rob Shakir and Anees and they have confirmed that these are the semantics that are expected. Thanks, Rob > >> Besides that, the case you mentioned should be clearly in scope. > Great, then I am open to discussing what this could mean for the existing modules (ietf-interfaces, ietf-routing, ACL etc.). > > One useful change to YANG semantics could be that a leafref with require-instance=true would refer to applied configuration. Specifically, the ACL module could then simply use "if:interface-ref" (with require-instance=true) as the type for "input-interface". > > Thanks, Lada > >> >> >> --Gert >> >>> -----Original Message----- >>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka >>> Sent: 07 January 2016 11:20 >>> To: NETMOD WG >>> Subject: [netmod] applied configuration and system-controlled entries >>> >>> Hi, >>> >>> a good use of applied configuration could be to formalize the concept of >>> system-controlled entries as defined in RFC 7223, routing-cfg, and probably >>> elsewhere, too. >>> >>> My idea is that system-controlled interfaces or other entries would appear in >>> applied configuration, but not in intended configuration until something needs >>> to be really configured. We could then permit leafrefs from intended >>> configuration to refer to leafs in applied configuration. One case where this >>> would be useful is the ACL module, where match conditions refering to >>> interfaces currently have to use plain strings as references to interface names. >>> >>> However, the above idea seems to be at odds with requirement 1D in opstate- >>> reqs-02. I wonder: could that requirement be relaxed or removed so that the >>> above use case can be supported? >>> >>> Thanks, Lada >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Mon Jan 11 06:20:11 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D821A0108 for ; Mon, 11 Jan 2016 06:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tl7xm6QBTImx for ; Mon, 11 Jan 2016 06:20:07 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBE731A010C for ; Mon, 11 Jan 2016 06:20:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1130; q=dns/txt; s=iport; t=1452522007; x=1453731607; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1tjTcP1ev9qj9Qs6Ksd9C4O9Thtm9Sisy8jy82UQquM=; b=NDHEnOyldD/tee/GWnf84hUXedV9yCAY1a/CKfiz/vEbef1KwjGMhLyw JiklvIpLI+mcMIGvardpZ2cUBxJnfnKF8QfxzPsSMIUOdOwz2zjxbRyzZ i4fSH/evnp1sKf0FK49yh5dS85aWgPyx4qIkgc/C0qNattyv3Vhzjkj1R c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAgDsuJNW/4QNJK1bA4M6Um0GiFOzY?= =?us-ascii?q?QENgWYehXECHIEGOBQBAQEBAQEBgQqENQEBBCMRPgcOAgIBCA4CCAICJgICAhk?= =?us-ascii?q?XFRACBA4FiC6vC49+AQEBAQEBAQEBAQEBAQEBAQEBAQEBGAR9ilSEVRgLJoJVg?= =?us-ascii?q?UkFlxMBjViBXoRDiFyOUAEgAQFChApyhSCBCAEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,553,1444694400"; d="scan'208";a="62373464" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Jan 2016 14:20:06 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u0BEK6to017715 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Jan 2016 14:20:06 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 11 Jan 2016 09:20:06 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Mon, 11 Jan 2016 09:20:06 -0500 From: "Acee Lindem (acee)" To: Juergen Schoenwaelder Thread-Topic: [netmod] applied configuration and system-controlled entries Thread-Index: AQHRSTUHdGA/4fiHbE6BWSvoked/1572qICAgAAGhgCAAAGYAIAAFEqA///w4QCAABK2AA== Date: Mon, 11 Jan 2016 14:20:05 +0000 Message-ID: References: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> <20160111.145436.1312067595929182117.mbj@tail-f.com> <20160111141306.GC42469@elstar.local> In-Reply-To: <20160111141306.GC42469@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.43.19] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 14:20:09 -0000 DQoNCk9uIDEvMTEvMTYsIDM6MTMgUE0sICJKdWVyZ2VuIFNjaG9lbndhZWxkZXIiDQo8ai5zY2hv ZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCg0KPk9uIE1vbiwgSmFuIDEx LCAyMDE2IGF0IDAyOjA3OjEzUE0gKzAwMDAsIEFjZWUgTGluZGVtIChhY2VlKSB3cm90ZToNCj4+ IA0KPj4gTXkgb3BpbmlvbiBpcyB0aGF0IHRoZXJlIGlzIGEgMS0xIHJlbGF0aW9uc2hpcCBiZXR3 ZWVuIOKAnGFwcGxpZWTigJ0gYW5kDQo+PiDigJxpbnRlbmRlZOKAnSBjb25maWcuDQo+Pg0KPg0K PkkgZG8gbm90IHVuZGVyc3RhbmQuIFBsZWFzZSBjbGFyaWZ5IHdoYXQgMS0xIG1lYW5zIGhlcmUu DQoNCkluIHRoZSBjb250ZXh0IG9mIHRoZXNlIHJlcXVpcmVtZW50cywgSSBkbyBub3QgYWdyZWUg dGhhdCBhcHBsaWVkIGNvbmZpZw0KaW5jbHVkZXMgYW55dGhpbmcgZWxzZS4gVGhlIGRhdGEgbW9k ZWxzIGZvciB0aGUgaW50ZW5kZWQgYW5kIGFwcGxpZWQNCmNvbmZpZyBhcmUgdGhlIGFsaWduZWQg YW5kIGFsbCBvdGhlciBzdGF0ZSBmYWxscyBpbiB0aGUgY2F0ZWdvcnkgb2YNCmRlcml2ZWQgc3Rh dGUuICANCg0KVGhhbmtzLA0KQWNlZSANCg0KPg0KPi9qcw0KPg0KPi0tIA0KPkp1ZXJnZW4gU2No b2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+UGhv bmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVu IHwgR2VybWFueQ0KPkZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cu amFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KDQo= From nobody Mon Jan 11 06:23:08 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D85301A010C for ; Mon, 11 Jan 2016 06:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXbaGiYmumn2 for ; Mon, 11 Jan 2016 06:23:04 -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 114561A010D for ; Mon, 11 Jan 2016 06:23:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2241; q=dns/txt; s=iport; t=1452522184; x=1453731784; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=u3TdE2oY9vZTzoJBrdEkc9xQGAha+CVn5bkcCclkaNU=; b=GwsLPPFPGaJiZA2gfcVoRAIEDw1CUpgE9Y84XO0UKurZotUxzHXAPqCM 71lwA9jahQC0Iqvg2U1ZGxbVR0l6Hwr1+pawp8YYqkO4ZP8T36RIjZr8G gyjaygRXu0wgv0glrVSqUWjJYrQMI9OazUcIRaChyi532W3KSU7zcS8HS 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CGBQAgupNW/xbLJq1ehDhBiFmzYQENg?= =?us-ascii?q?WaGDwKBWhQBAQEBAQEBgQqENQEBBDhAEQsOCgkWDwkDAgECAUUGAQwGAgEBiCq?= =?us-ascii?q?/EwEBAQEBAQEBAQEBAQEBAQEBHIZWhH+EMQ2EfgEEh2GHEoggjVmBXodKhVWKX?= =?us-ascii?q?oNzIAEBQoIRHIFdPjSEXoFKAQEB?= X-IronPort-AV: E=Sophos;i="5.20,553,1444694400"; d="scan'208";a="631535824" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jan 2016 14:23:02 +0000 Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u0BEN25W006744; Mon, 11 Jan 2016 14:23:02 GMT To: Martin Bjorklund , lhotka@nic.cz, netmod@ietf.org References: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> <20160111.145436.1312067595929182117.mbj@tail-f.com> <20160111141116.GB42469@elstar.local> From: Robert Wilton Message-ID: <5693BAC9.2020607@cisco.com> Date: Mon, 11 Jan 2016 14:23:05 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160111141116.GB42469@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 14:23:07 -0000 On 11/01/2016 14:11, Juergen Schoenwaelder wrote: > On Mon, Jan 11, 2016 at 02:54:36PM +0100, Martin Bjorklund wrote: >> Ladislav Lhotka wrote: >>> Hi Gert, >>> >>>> On 11 Jan 2016, at 14:25, Gert Grammel wrote: >>>> >>>> Lada, >>>> >>>> The requirement says: >>>> D. When a configuration change for any intended configuration >>>> node has been successfully applied to the server (e.g. not >>>> failed, nor deferred due to absent hardware) then the >>>> existence and value of the corresponding applied >>>> configuration node must match the intended configuration >>>> node. >>>> >>>> I don't see that this would limit the case you described below. In >>>> your case there is no intended config, hence there is no >>>> "corresponding applied configuration" either. >>> You are right, the requirement can be interpreted this way. I thought >>> that applied configuration was supposed to be identical to intended >>> after some synchronization period. >> This is a very important point to clarify. Can there ever be data in >> "applied" that is not in "intended"? I think Anees & Rob previously >> said "no", but I might be wrong. >> > If there is time delay between editing intended and the applied config > matching the edits of intended, then I supose this can happen (I > delete a resource from intended but it is still around until intended > has been fully synced). I would find it interesting if some edits are > always assumed to be synchronous but others may be asynchronous. > > And Lada, I think applied may happen to be never identical to intended > if, for example, hardware is absent or other missing resources prevent > certain parts of intended to become applied. > > My understanding is that applied config in general forms an extended > subset of intended config. And to fully understand what a device is > doing, I may need to obtain its entire operational state since the > applied config may not include state obtained dynamically from other > sources. > > But I might still all be wrong... I think that your articulation is correct. Thanks, Rob > > /js > From nobody Mon Jan 11 06:28:44 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D76C1A0119 for ; Mon, 11 Jan 2016 06:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.352 X-Spam-Level: X-Spam-Status: No, score=-0.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdEaxzwkhsD2 for ; Mon, 11 Jan 2016 06:28:41 -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 D3DC31A014E for ; Mon, 11 Jan 2016 06:27:59 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:550b:3775:13a2:612b] (unknown [IPv6:2001:718:1a02:1:550b:3775:13a2:612b]) by mail.nic.cz (Postfix) with ESMTPSA id 40CCC181A96; Mon, 11 Jan 2016 15:27:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452522478; bh=+cXum4652Dc3ez5ubQFjNMVgv3x52q3RpCa82sSzrYA=; h=From:Date:To; b=os9QzPwnnLamOcfdJr7tvYy14E9Wuv42NbrR0BSJ3jcoienxBt4CH5wyDXEV6ygps l/2Qs9BwLkJXSSpCS8MFHu5xMJH9YCZGccBy4u2irPb9TEO++4U0fFOep+bQHrHn7I v6QawajdjJpg03trC8hoI7yenEaXXnvLzEcfWhwQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20160111141116.GB42469@elstar.local> Date: Mon, 11 Jan 2016 15:27:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> <20160111.145436.1312067595929182117.mbj@tail-f.com> <20160111141116.GB42469@elstar.local> To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 14:28:43 -0000 > On 11 Jan 2016, at 15:11, Juergen Schoenwaelder = wrote: >=20 > On Mon, Jan 11, 2016 at 02:54:36PM +0100, Martin Bjorklund wrote: >> Ladislav Lhotka wrote: >>> Hi Gert, >>>=20 >>>> On 11 Jan 2016, at 14:25, Gert Grammel = wrote: >>>>=20 >>>> Lada, >>>>=20 >>>> The requirement says: >>>> D. When a configuration change for any intended configuration >>>> node has been successfully applied to the server (e.g. not >>>> failed, nor deferred due to absent hardware) then the >>>> existence and value of the corresponding applied >>>> configuration node must match the intended configuration >>>> node. >>>>=20 >>>> I don't see that this would limit the case you described below. In >>>> your case there is no intended config, hence there is no >>>> "corresponding applied configuration" either. >>>=20 >>> You are right, the requirement can be interpreted this way. I = thought >>> that applied configuration was supposed to be identical to intended >>> after some synchronization period. >>=20 >> This is a very important point to clarify. Can there ever be data in >> "applied" that is not in "intended"? I think Anees & Rob previously >> said "no", but I might be wrong. >>=20 >=20 > If there is time delay between editing intended and the applied config > matching the edits of intended, then I supose this can happen (I > delete a resource from intended but it is still around until intended > has been fully synced). I would find it interesting if some edits are Using applied config for system-controlled entries would require that = such an entry stays (forever) in applied config even after it has been = deleted from intended.=20 > always assumed to be synchronous but others may be asynchronous. >=20 > And Lada, I think applied may happen to be never identical to intended > if, for example, hardware is absent or other missing resources prevent > certain parts of intended to become applied. Yes, this is the use case of pre-provisioning, which is important, too, = but in fact opposite: the question here is whether applied can contain = stuff that's not (and never been) in intended. Lada >=20 > My understanding is that applied config in general forms an extended > subset of intended config. And to fully understand what a device is > doing, I may need to obtain its entire operational state since the > applied config may not include state obtained dynamically from other > sources. >=20 > But I might still all be wrong... >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jan 11 06:50:00 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3374A1A01A2 for ; Mon, 11 Jan 2016 06:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0xYvaUFf8OD for ; Mon, 11 Jan 2016 06:49:58 -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 D61931A0191 for ; Mon, 11 Jan 2016 06:49:57 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A1EC173D; Mon, 11 Jan 2016 15:49:56 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 9_sz3rFVF1qT; Mon, 11 Jan 2016 15:49: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; Mon, 11 Jan 2016 15:49:56 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 034F22002C; Mon, 11 Jan 2016 15:49:56 +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 WEzMhfTXUywr; Mon, 11 Jan 2016 15:49:55 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B97C020013; Mon, 11 Jan 2016 15:49:54 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 09B2139817A5; Mon, 11 Jan 2016 15:49:53 +0100 (CET) Date: Mon, 11 Jan 2016 15:49:53 +0100 From: Juergen Schoenwaelder To: "Acee Lindem (acee)" Message-ID: <20160111144953.GD42469@elstar.local> Mail-Followup-To: "Acee Lindem (acee)" , Martin Bjorklund , "lhotka@nic.cz" , "netmod@ietf.org" References: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> <20160111.145436.1312067595929182117.mbj@tail-f.com> <20160111141306.GC42469@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.4.2.3i Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 14:49:59 -0000 On Mon, Jan 11, 2016 at 02:20:05PM +0000, Acee Lindem (acee) wrote: > > > On 1/11/16, 3:13 PM, "Juergen Schoenwaelder" > wrote: > > >On Mon, Jan 11, 2016 at 02:07:13PM +0000, Acee Lindem (acee) wrote: > >> > >> My opinion is that there is a 1-1 relationship between “applied” and > >> “intended” config. > >> > > > >I do not understand. Please clarify what 1-1 means here. > > In the context of these requirements, I do not agree that applied config > includes anything else. The data models for the intended and applied > config are the aligned and all other state falls in the category of > derived state. > Apparently, you talk about the data model while I think Martin's question and the subsequent discussion was about instances. /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 11 06:52:04 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB36A1A01A2 for ; Mon, 11 Jan 2016 06:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.652 X-Spam-Level: X-Spam-Status: No, score=-5.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiFI0TNOKiny for ; Mon, 11 Jan 2016 06:52:01 -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 3A3BE1A017D for ; Mon, 11 Jan 2016 06:52:01 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:550b:3775:13a2:612b] (unknown [IPv6:2001:718:1a02:1:550b:3775:13a2:612b]) by mail.nic.cz (Postfix) with ESMTPSA id D7088180D6E; Mon, 11 Jan 2016 15:51:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452523919; bh=DO4WdUiQDTI/cUCTX8G5U9A4WBHOTA/uQGK+RAjQ7Wg=; h=From:Date:To; b=ZIHAwm8ze0fLNwcWofbutVyAecl+8H3944HTAwJ67VcPu9YNNQmT9XfzmUEvy3lnH R0dU/5/6H9n18WJgGIAjN3xvf9p34ZL7/ttQgN9elpcQpJD/O7fSenD05GAaVChNPE gylL/55ZS4NdR8NDcKrEU8lbZmY9WzcOv+lasb/g= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <5693B918.2080006@cisco.com> Date: Mon, 11 Jan 2016 15:51:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> <5693B918.2080006@cisco.com> To: Robert Wilton X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: NETMOD WG Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 14:52:04 -0000 > On 11 Jan 2016, at 15:15, Robert Wilton wrote: >=20 > Hi Gert, Lada, >=20 > On 11/01/2016 13:48, Ladislav Lhotka wrote: >> Hi Gert, >>=20 >>> On 11 Jan 2016, at 14:25, Gert Grammel wrote: >>>=20 >>> Lada, >>>=20 >>> The requirement says: >>> D. When a configuration change for any intended configuration >>> node has been successfully applied to the server (e.g. not >>> failed, nor deferred due to absent hardware) then the >>> existence and value of the corresponding applied >>> configuration node must match the intended configuration >>> node. >>>=20 >>> I don't see that this would limit the case you described below. In = your case there is no intended config, hence there is no "corresponding = applied configuration" either. >> You are right, the requirement can be interpreted this way. I thought = that applied configuration was supposed to be identical to intended = after some synchronization period. > Yes, when the system settles, and assuming that all configuration has = been successfully applied, then the applied config nodes MUST exactly = match the intended config nodes. >=20 > This point has been explicitly asked of Rob Shakir and Anees and they = have confirmed that these are the semantics that are expected. OK, back to square 1. :-) Then I think the requirements should make this = point very clear. Lada >=20 > Thanks, > Rob >=20 >=20 >>=20 >>> Besides that, the case you mentioned should be clearly in scope. >> Great, then I am open to discussing what this could mean for the = existing modules (ietf-interfaces, ietf-routing, ACL etc.). >>=20 >> One useful change to YANG semantics could be that a leafref with = require-instance=3Dtrue would refer to applied configuration. = Specifically, the ACL module could then simply use "if:interface-ref" = (with require-instance=3Dtrue) as the type for "input-interface". >>=20 >> Thanks, Lada >>=20 >>> =20 >>> --Gert >>>=20 >>>> -----Original Message----- >>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav = Lhotka >>>> Sent: 07 January 2016 11:20 >>>> To: NETMOD WG >>>> Subject: [netmod] applied configuration and system-controlled = entries >>>>=20 >>>> Hi, >>>>=20 >>>> a good use of applied configuration could be to formalize the = concept of >>>> system-controlled entries as defined in RFC 7223, routing-cfg, and = probably >>>> elsewhere, too. >>>>=20 >>>> My idea is that system-controlled interfaces or other entries would = appear in >>>> applied configuration, but not in intended configuration until = something needs >>>> to be really configured. We could then permit leafrefs from = intended >>>> configuration to refer to leafs in applied configuration. One case = where this >>>> would be useful is the ACL module, where match conditions refering = to >>>> interfaces currently have to use plain strings as references to = interface names. >>>>=20 >>>> However, the above idea seems to be at odds with requirement 1D in = opstate- >>>> reqs-02. I wonder: could that requirement be relaxed or removed so = that the >>>> above use case can be supported? >>>>=20 >>>> Thanks, Lada >>>>=20 >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> . -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jan 11 06:59:12 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7788E1A01BA for ; Mon, 11 Jan 2016 06:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.202 X-Spam-Level: X-Spam-Status: No, score=-14.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fL2wInYPx6LR for ; Mon, 11 Jan 2016 06:59:09 -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 C295D1A01AE for ; Mon, 11 Jan 2016 06:59:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4002; q=dns/txt; s=iport; t=1452524349; x=1453733949; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=GAHV2d9yY0ADWKhZmERhvO0n0qZVCKpezmpHDdju+mo=; b=isQ9U/YRFXau5E0rP+eslSwma4t/0waL3uu9A+u9ujoeibat2abdWSUz qRpYKnGB4eI7hFm65YGSfMBehYV/10BXc5VRnWwFzoWaUkd+Pr1B6CE5M bvuPgZ3PK9xRQWY7WPlTMmleoztEqGoww89NdmvcZLn7hdnmc5IpDlycO U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABDgAEw5NW/xbLJq1bA4QMLEGIWbVVG?= =?us-ascii?q?AqFI0oCgW4BAQEBAQGBC4Q0AQEBAwEBAQE1NgQGAQ4CCxAICRYPCQMCAQIBCQw?= =?us-ascii?q?wBgEMBgIBARWFfYIQCA6/JgEBAQEBAQEBAQEBAQEBAQEBAQEBARgEhlKEf4QxD?= =?us-ascii?q?TomhB4Fh2GHEoggjVmBXodKhVWKXoNzZIIRHIFdPjSEXQEfgSsBAQE?= X-IronPort-AV: E=Sophos;i="5.20,553,1444694400"; d="scan'208";a="624423157" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jan 2016 14:58:51 +0000 Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u0BEwoVC031455; Mon, 11 Jan 2016 14:58:51 GMT To: Ladislav Lhotka , =?UTF-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= References: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> <20160111.145436.1312067595929182117.mbj@tail-f.com> <20160111141116.GB42469@elstar.local> From: Robert Wilton Message-ID: <5693C32E.7020708@cisco.com> Date: Mon, 11 Jan 2016 14:58:54 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 14:59:11 -0000 On 11/01/2016 14:27, Ladislav Lhotka wrote: >> On 11 Jan 2016, at 15:11, Juergen Schoenwaelder wrote: >> >> On Mon, Jan 11, 2016 at 02:54:36PM +0100, Martin Bjorklund wrote: >>> Ladislav Lhotka wrote: >>>> Hi Gert, >>>> >>>>> On 11 Jan 2016, at 14:25, Gert Grammel wrote: >>>>> >>>>> Lada, >>>>> >>>>> The requirement says: >>>>> D. When a configuration change for any intended configuration >>>>> node has been successfully applied to the server (e.g. not >>>>> failed, nor deferred due to absent hardware) then the >>>>> existence and value of the corresponding applied >>>>> configuration node must match the intended configuration >>>>> node. >>>>> >>>>> I don't see that this would limit the case you described below. In >>>>> your case there is no intended config, hence there is no >>>>> "corresponding applied configuration" either. >>>> You are right, the requirement can be interpreted this way. I thought >>>> that applied configuration was supposed to be identical to intended >>>> after some synchronization period. >>> This is a very important point to clarify. Can there ever be data in >>> "applied" that is not in "intended"? I think Anees & Rob previously >>> said "no", but I might be wrong. >>> >> If there is time delay between editing intended and the applied config >> matching the edits of intended, then I supose this can happen (I >> delete a resource from intended but it is still around until intended >> has been fully synced). I would find it interesting if some edits are > Using applied config for system-controlled entries would require that such an entry stays (forever) in applied config even after it has been deleted from intended. I think that this would make life harder for clients. With the requirements as they are today, the client gives the intended config to the system, which it can monitor until the applied config matches the intended config. At this point it knows everything is good and the config is fully applied. Over time, if everything is behaving as expected, the client can reasonably expect that the applied configuration will always converge on the intended configuration. Using applied config for system-controlled entries would break the simple logical relationship between intended and applied configuration, since there are now some special entries for which this rule does not always apply. > >> always assumed to be synchronous but others may be asynchronous. >> >> And Lada, I think applied may happen to be never identical to intended >> if, for example, hardware is absent or other missing resources prevent >> certain parts of intended to become applied. > Yes, this is the use case of pre-provisioning, which is important, too, but in fact opposite: the question here is whether applied can contain stuff that's not (and never been) in intended. I think that the answer is basically no, unless it is an error condition and it is representing configuration that should be deleted. Thanks, Rob > > Lada > >> My understanding is that applied config in general forms an extended >> subset of intended config. And to fully understand what a device is >> doing, I may need to obtain its entire operational state since the >> applied config may not include state obtained dynamically from other >> sources. >> >> But I might still all be wrong... >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Mon Jan 11 07:30:24 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD4F1A1A1E for ; Mon, 11 Jan 2016 07:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqzvLXiE4pwR for ; Mon, 11 Jan 2016 07:30:20 -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 15CDC1A03C7 for ; Mon, 11 Jan 2016 07:30:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4719; q=dns/txt; s=iport; t=1452526220; x=1453735820; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=E79iYzjTHA5YUWD2c20zSFBM9c/asdmXUaVgqkq43FM=; b=jX+UJQE9MDJJQywBtZpqrx3RAAIF2470Ye4QlfYo1WYyKxC3zh0BGfaO Gh21Bv078Ifl0xIGnC67yfma7MK4s0h2jMNYN2QdT+hMIBCV9KgbIDKLU jNIfy1m7mx2xOwe6Gn/IDFLjNL/6h3lRQKSb+Sms341e7v+qi/9+vKP3s k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQCKyZNW/xbLJq1ehAxtiFmzYQENg?= =?us-ascii?q?WYYCoUjSgKBWxQBAQEBAQEBgQqENAEBAQMBAQEBNTQCCAIBDAQLEQQBAQEJFgg?= =?us-ascii?q?HCQMCAQIBFR8JCAYNBgIBAReICwgOvzoBAQEBAQEBAQEBAQEBAQEBAQEBAQEUB?= =?us-ascii?q?IZWhH+EMQ2EfgEEh2GHEoggjVmBXodKhVWKXoNzIAEBQoQKPjSEXoFKAQEB?= X-IronPort-AV: E=Sophos;i="5.20,553,1444694400"; d="scan'208";a="648414140" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jan 2016 15:30:18 +0000 Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u0BFUH8F016826; Mon, 11 Jan 2016 15:30:18 GMT To: Ladislav Lhotka References: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> <5693B918.2080006@cisco.com> From: Robert Wilton Message-ID: <5693CA8A.7080805@cisco.com> Date: Mon, 11 Jan 2016 15:30:18 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: NETMOD WG Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 15:30:22 -0000 On 11/01/2016 14:51, Ladislav Lhotka wrote: >> On 11 Jan 2016, at 15:15, Robert Wilton wrote: >> >> Hi Gert, Lada, >> >> On 11/01/2016 13:48, Ladislav Lhotka wrote: >>> Hi Gert, >>> >>>> On 11 Jan 2016, at 14:25, Gert Grammel wrote: >>>> >>>> Lada, >>>> >>>> The requirement says: >>>> D. When a configuration change for any intended configuration >>>> node has been successfully applied to the server (e.g. not >>>> failed, nor deferred due to absent hardware) then the >>>> existence and value of the corresponding applied >>>> configuration node must match the intended configuration >>>> node. >>>> >>>> I don't see that this would limit the case you described below. In your case there is no intended config, hence there is no "corresponding applied configuration" either. >>> You are right, the requirement can be interpreted this way. I thought that applied configuration was supposed to be identical to intended after some synchronization period. >> Yes, when the system settles, and assuming that all configuration has been successfully applied, then the applied config nodes MUST exactly match the intended config nodes. >> >> This point has been explicitly asked of Rob Shakir and Anees and they have confirmed that these are the semantics that are expected. > OK, back to square 1. :-) Then I think the requirements should make this point very clear. They try to, but it is quite tricky to express given there are scenarios where the two can differ (e.g. failures (depending on config edit semantics), missing hardware, etc). The intention of the word existence in the paragraph above is meant to indicate that a node must either exist in both intended and applied, or not exist in either. Going back to your original problem, my understanding is that the only solution in YANG today is to have a config false hierarchy to represent system-controlled objects whose lifetime is independent from configuration, hence the existence of "interfaces-state" separate from "interfaces". With this approach you lose the ability to retrieve all configuration and state together in a single sub-tree within a request but gain the flexibility of independent data lifetime. Thanks, Rob > > Lada > >> Thanks, >> Rob >> >> >>>> Besides that, the case you mentioned should be clearly in scope. >>> Great, then I am open to discussing what this could mean for the existing modules (ietf-interfaces, ietf-routing, ACL etc.). >>> >>> One useful change to YANG semantics could be that a leafref with require-instance=true would refer to applied configuration. Specifically, the ACL module could then simply use "if:interface-ref" (with require-instance=true) as the type for "input-interface". >>> >>> Thanks, Lada >>> >>>> >>>> --Gert >>>> >>>>> -----Original Message----- >>>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka >>>>> Sent: 07 January 2016 11:20 >>>>> To: NETMOD WG >>>>> Subject: [netmod] applied configuration and system-controlled entries >>>>> >>>>> Hi, >>>>> >>>>> a good use of applied configuration could be to formalize the concept of >>>>> system-controlled entries as defined in RFC 7223, routing-cfg, and probably >>>>> elsewhere, too. >>>>> >>>>> My idea is that system-controlled interfaces or other entries would appear in >>>>> applied configuration, but not in intended configuration until something needs >>>>> to be really configured. We could then permit leafrefs from intended >>>>> configuration to refer to leafs in applied configuration. One case where this >>>>> would be useful is the ACL module, where match conditions refering to >>>>> interfaces currently have to use plain strings as references to interface names. >>>>> >>>>> However, the above idea seems to be at odds with requirement 1D in opstate- >>>>> reqs-02. I wonder: could that requirement be relaxed or removed so that the >>>>> above use case can be supported? >>>>> >>>>> Thanks, Lada >>>>> >>>>> -- >>>>> Ladislav Lhotka, CZ.NIC Labs >>>>> PGP Key ID: E74E8C0C >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> . > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > . > From nobody Mon Jan 11 07:36:32 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0FE31A1A88 for ; Mon, 11 Jan 2016 07:36:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.652 X-Spam-Level: X-Spam-Status: No, score=-5.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ut2re7M1p0Yn for ; Mon, 11 Jan 2016 07:36: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 30DAE1A1A45 for ; Mon, 11 Jan 2016 07:36:29 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:550b:3775:13a2:612b] (unknown [IPv6:2001:718:1a02:1:550b:3775:13a2:612b]) by mail.nic.cz (Postfix) with ESMTPSA id B313318104B; Mon, 11 Jan 2016 16:36:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452526587; bh=WwKqWqJZlgnYRdCZylOTgXwCcWj7Hmpf36tsLEF4yzM=; h=From:Date:To; b=BEq+ZB+FcQXSuSov03qCijljfGSUT1UHWirF3Wpi+9DHPCVJwUuLLHCH63BADJvEF GjqGH8XRm5VoSUS+s/cHqDFoypkfRXKsX1pXg6yGVaYMmdFQNKUJOLgGbvDj1wN8JU zq8DOz5sHIHLNOSKo9yef7kCCNB2S3CgMI59n+7s= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <5693C32E.7020708@cisco.com> Date: Mon, 11 Jan 2016 16:36:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <31E9D485-9349-448D-99A3-DD20F5E5AF09@nic.cz> References: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> <20160111.145436.1312067595929182117.mbj@tail-f.com> <20160111141116.GB42469@elstar.local> <5693C32E.7020708@cisco.com> To: Robert Wilton X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 15:36:31 -0000 > On 11 Jan 2016, at 15:58, Robert Wilton wrote: >=20 >=20 >=20 > On 11/01/2016 14:27, Ladislav Lhotka wrote: >>> On 11 Jan 2016, at 15:11, Juergen Schoenwaelder = wrote: >>>=20 >>> On Mon, Jan 11, 2016 at 02:54:36PM +0100, Martin Bjorklund wrote: >>>> Ladislav Lhotka wrote: >>>>> Hi Gert, >>>>>=20 >>>>>> On 11 Jan 2016, at 14:25, Gert Grammel = wrote: >>>>>>=20 >>>>>> Lada, >>>>>>=20 >>>>>> The requirement says: >>>>>> D. When a configuration change for any intended = configuration >>>>>> node has been successfully applied to the server (e.g. = not >>>>>> failed, nor deferred due to absent hardware) then the >>>>>> existence and value of the corresponding applied >>>>>> configuration node must match the intended configuration >>>>>> node. >>>>>>=20 >>>>>> I don't see that this would limit the case you described below. = In >>>>>> your case there is no intended config, hence there is no >>>>>> "corresponding applied configuration" either. >>>>> You are right, the requirement can be interpreted this way. I = thought >>>>> that applied configuration was supposed to be identical to = intended >>>>> after some synchronization period. >>>> This is a very important point to clarify. Can there ever be data = in >>>> "applied" that is not in "intended"? I think Anees & Rob = previously >>>> said "no", but I might be wrong. >>>>=20 >>> If there is time delay between editing intended and the applied = config >>> matching the edits of intended, then I supose this can happen (I >>> delete a resource from intended but it is still around until = intended >>> has been fully synced). I would find it interesting if some edits = are >> Using applied config for system-controlled entries would require that = such an entry stays (forever) in applied config even after it has been = deleted from intended. > I think that this would make life harder for clients. Hmm, I would say the opposite. For one, we could simplify the data = models by reducing the duplicities in configuration and state trees. >=20 > With the requirements as they are today, the client gives the intended = config to the system, which it can monitor until the applied config = matches the intended config. At this point it knows everything is good = and the config is fully applied. Over time, if everything is behaving = as expected, the client can reasonably expect that the applied = configuration will always converge on the intended configuration. One could argue that leafs with default values are in applied = configuration before they appear in intended. So my idea was to extend = this to default entries of certain lists. >=20 > Using applied config for system-controlled entries would break the = simple logical relationship between intended and applied configuration, = since there are now some special entries for which this rule does not = always apply. The introduction of applied configuration would mean significant = complications to all protocols, and perhaps even to YANG (although I'd = hope not). Solving only the synchonicity issue with it is IMO = insufficient payoff for all the troubles.=20 Lada >=20 >>=20 >>> always assumed to be synchronous but others may be asynchronous. >>>=20 >>> And Lada, I think applied may happen to be never identical to = intended >>> if, for example, hardware is absent or other missing resources = prevent >>> certain parts of intended to become applied. >> Yes, this is the use case of pre-provisioning, which is important, = too, but in fact opposite: the question here is whether applied can = contain stuff that's not (and never been) in intended. >=20 > I think that the answer is basically no, unless it is an error = condition and it is representing configuration that should be deleted. >=20 > Thanks, > Rob >=20 >=20 >>=20 >> Lada >>=20 >>> My understanding is that applied config in general forms an extended >>> subset of intended config. And to fully understand what a device is >>> doing, I may need to obtain its entire operational state since the >>> applied config may not include state obtained dynamically from other >>> sources. >>>=20 >>> But I might still all be wrong... >>>=20 >>> /js >>>=20 >>> --=20 >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>> Fax: +49 421 200 3103 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> . -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Jan 11 08:13:57 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 783DE1A7012 for ; Mon, 11 Jan 2016 08:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GeJI0DDsDoY for ; Mon, 11 Jan 2016 08:13:54 -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 A52601A6F63 for ; Mon, 11 Jan 2016 08:13:54 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CF6938A4; Mon, 11 Jan 2016 17:13:52 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id BxvQKIEDGN59; Mon, 11 Jan 2016 17:13: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; Mon, 11 Jan 2016 17:13:52 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2A0952002B; Mon, 11 Jan 2016 17:13:52 +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 nIOwNsxGHXuD; Mon, 11 Jan 2016 17:13:51 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1CB9120013; Mon, 11 Jan 2016 17:13:50 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4DAA93981A5A; Mon, 11 Jan 2016 17:13:49 +0100 (CET) Date: Mon, 11 Jan 2016 17:13:48 +0100 From: Juergen Schoenwaelder To: Robert Wilton Message-ID: <20160111161348.GA412@elstar.local> Mail-Followup-To: Robert Wilton , Ladislav Lhotka , NETMOD WG References: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> <5693B918.2080006@cisco.com> <5693CA8A.7080805@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5693CA8A.7080805@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: NETMOD WG Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 16:13:56 -0000 On Mon, Jan 11, 2016 at 03:30:18PM +0000, Robert Wilton wrote: > > Going back to your original problem, my understanding is that the only > solution in YANG today is to have a config false hierarchy to represent > system-controlled objects whose lifetime is independent from > configuration, hence the existence of "interfaces-state" separate from > "interfaces". With this approach you lose the ability to retrieve all > configuration and state together in a single sub-tree within a request > but gain the flexibility of independent data lifetime. > I think filters even today allow you to retrieve both subtrees (intended and operational state) together if that is desired. /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 11 08:19:27 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD5C1A8035 for ; Mon, 11 Jan 2016 08:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEyUin_TQjdP for ; Mon, 11 Jan 2016 08:19:19 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0136.outbound.protection.outlook.com [207.46.100.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F21F91A8025 for ; Mon, 11 Jan 2016 08:19:18 -0800 (PST) Received: from CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) by CY1PR0501MB1611.namprd05.prod.outlook.com (10.161.162.14) with Microsoft SMTP Server (TLS) id 15.1.361.13; Mon, 11 Jan 2016 16:19:17 +0000 Received: from CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) by CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) with mapi id 15.01.0361.006; Mon, 11 Jan 2016 16:19:16 +0000 From: Gert Grammel To: Ladislav Lhotka , Robert Wilton Thread-Topic: [netmod] applied configuration and system-controlled entries Thread-Index: AQHRSTUGxYtkEO44aUCWX59qiQKmfp72U6BggAAN6lSAAASVAIAACKQAgAAKfoCAAAPVYA== Date: Mon, 11 Jan 2016 16:19:16 +0000 Message-ID: References: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> <20160111.145436.1312067595929182117.mbj@tail-f.com> <20160111141116.GB42469@elstar.local> <5693C32E.7020708@cisco.com> <31E9D485-9349-448D-99A3-DD20F5E5AF09@nic.cz> In-Reply-To: <31E9D485-9349-448D-99A3-DD20F5E5AF09@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; x-originating-ip: [193.110.55.14] x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1611; 5:Sy/kB4oPhqgyQn/U6XnWJ+uQKa9/o2B/CbKhTt/wzMG2EZApqBJpUy6HES4yTiaXE+TEYQe1C1ndRbuTs8yEwNlPex8xjKDhpUZizAldza8rIIIyql03FfU8fkfEUN0UUSHMHJsGApnKmCN6IPSGaw==; 24:3HUSlLL1F4OcG8fnI52EX3il86cq6oJNrjFWTcKL+vZJWtVqPgPxYJOdk+LuHSH0AjGHi/llfkohaT6iFLlM33MxPWqnGyMhyRQsDIA7UCM= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1611; x-ms-office365-filtering-correlation-id: 1cb3ef56-6535-41cd-4eec-08d31aa2f3db x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:CY1PR0501MB1611; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1611; x-forefront-prvs: 0818724663 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(199003)(189002)(13464003)(479174004)(51444003)(164054003)(87936001)(76576001)(92566002)(106356001)(86362001)(122556002)(2950100001)(101416001)(19580395003)(66066001)(5001770100001)(76176999)(74316001)(77096005)(40100003)(19580405001)(15975445007)(2900100001)(575784001)(5001960100002)(189998001)(97736004)(33656002)(106116001)(50986999)(93886004)(5004730100002)(54356999)(10400500002)(586003)(1220700001)(105586002)(2906002)(3846002)(102836003)(5002640100001)(5008740100001)(81156007)(6116002)(5003600100002)(99286002)(4326007)(1096002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1611; H:CY1PR0501MB1609.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:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2016 16:19:16.6225 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1611 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 16:19:21 -0000 >-----Original Message----- >From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka >Sent: 11 January 2016 16:36 >To: Robert Wilton >Cc: netmod@ietf.org >Subject: Re: [netmod] applied configuration and system-controlled entries > > >> On 11 Jan 2016, at 15:58, Robert Wilton wrote: >> >> >> >> On 11/01/2016 14:27, Ladislav Lhotka wrote: >>>> On 11 Jan 2016, at 15:11, Juergen Schoenwaelder > wrote: >>>> >>>> On Mon, Jan 11, 2016 at 02:54:36PM +0100, Martin Bjorklund wrote: >>>>> Ladislav Lhotka wrote: >>>>>> Hi Gert, >>>>>> >>>>>>> On 11 Jan 2016, at 14:25, Gert Grammel >wrote: >>>>>>> >>>>>>> Lada, >>>>>>> >>>>>>> The requirement says: >>>>>>> D. When a configuration change for any intended configuration >>>>>>> node has been successfully applied to the server (e.g. not >>>>>>> failed, nor deferred due to absent hardware) then the >>>>>>> existence and value of the corresponding applied >>>>>>> configuration node must match the intended configuration >>>>>>> node. >>>>>>> >>>>>>> I don't see that this would limit the case you described below. >>>>>>> In your case there is no intended config, hence there is no >>>>>>> "corresponding applied configuration" either. >>>>>> You are right, the requirement can be interpreted this way. I >>>>>> thought that applied configuration was supposed to be identical to >>>>>> intended after some synchronization period. >>>>> This is a very important point to clarify. Can there ever be data >>>>> in "applied" that is not in "intended"? I think Anees & Rob >>>>> previously said "no", but I might be wrong. >>>>> >>>> If there is time delay between editing intended and the applied >>>> config matching the edits of intended, then I supose this can happen >>>> (I delete a resource from intended but it is still around until >>>> intended has been fully synced). I would find it interesting if some >>>> edits are >>> Using applied config for system-controlled entries would require that s= uch >an entry stays (forever) in applied config even after it has been deleted = from >intended. >> I think that this would make life harder for clients. > >Hmm, I would say the opposite. For one, we could simplify the data models = by >reducing the duplicities in configuration and state trees. > Let's look at a practical example and see if we can converge: 1) A Server is happily running with intended =3D=3D applied config and oper= ational state is aligned with intended config. 2) A new HW is plugged into that server and that HW has some kind of identi= fication number This can practically fall into 3 cases: a) it's a plug&play device and it is accepted to be used b) it's an accepted device but shall be configured prior to become operatio= nal c) it's considered a harmful (unplanned) event and the device shall be remo= ved In terms of a possible implementation, the event=20 1) would update the applied config which - among others - include the iden= tification number and update the operational state of that HW in line with = the applied config 2) Since the new applied config differs from the intended config, the clien= t is notified about the change 3) Upon inspection of the config change, the client decides how to deal wit= h the new item: a) accepting it the way it is: pushing down an intended config in line wit= h the applied config information b) accepting it with modifications: pushing down a new intended config wit= h additional leafs c) rejecting it: raising an alarm indicating the configuration mismatch, r= equiring manual intervention >> >> With the requirements as they are today, the client gives the intended c= onfig >to the system, which it can monitor until the applied config matches the >intended config. At this point it knows everything is good and the config= is >fully applied. Over time, if everything is behaving as expected, the clie= nt can >reasonably expect that the applied configuration will always converge on t= he >intended configuration. Which is the case above. By updating the intended config the client accepts= the config change. > >One could argue that leafs with default values are in applied configuratio= n >before they appear in intended. So my idea was to extend this to default >entries of certain lists. > >> >> Using applied config for system-controlled entries would break the simpl= e >logical relationship between intended and applied configuration, since the= re >are now some special entries for which this rule does not always apply. > Don't get to the same conclusion, see above. >The introduction of applied configuration would mean significant >complications to all protocols, and perhaps even to YANG (although I'd hop= e >not). Solving only the synchonicity issue with it is IMO insufficient payo= ff for all >the troubles. > Don't see this either. >Lada > >> >>> >>>> always assumed to be synchronous but others may be asynchronous. >>>> >>>> And Lada, I think applied may happen to be never identical to >>>> intended if, for example, hardware is absent or other missing >>>> resources prevent certain parts of intended to become applied. >>> Yes, this is the use case of pre-provisioning, which is important, too,= but in >fact opposite: the question here is whether applied can contain stuff that= 's not >(and never been) in intended. >> >> I think that the answer is basically no, unless it is an error condition= and it is >representing configuration that should be deleted. >> >> Thanks, >> Rob >> >> >>> >>> Lada >>> >>>> My understanding is that applied config in general forms an extended >>>> subset of intended config. And to fully understand what a device is >>>> doing, I may need to obtain its entire operational state since the >>>> applied config may not include state obtained dynamically from other >>>> sources. >>>> >>>> But I might still all be wrong... >>>> >>>> /js >>>> >>>> -- >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>>> Fax: +49 421 200 3103 >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> . > >-- >Ladislav Lhotka, CZ.NIC Labs >PGP Key ID: E74E8C0C > > > > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Jan 11 08:57:48 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59CDB1A8AB7 for ; Mon, 11 Jan 2016 08:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.902 X-Spam-Level: X-Spam-Status: No, score=-13.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgSk4YHawqIs for ; Mon, 11 Jan 2016 08:57:45 -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 044151A8AB4 for ; Mon, 11 Jan 2016 08:57:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8731; q=dns/txt; s=iport; t=1452531464; x=1453741064; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=4XJdFMkFhoEvGTvr3pGGkrvvKZDbVxMR2IPL796E9K0=; b=TpW3cpfTTCHn9IoFdEjf3sFAlA5Jnsq8QbqDgC4xlBfGm5MEJ1VxmH5l Jm/WsYnw3Ke3+NQKYnvms2t61/9nTWvGwTLuzgzasqVVEftw4Uq5zyBjw HIjCKIRoUUHJX8KwCXpPrqdf5jGPq/DiWW+nPechIQHSA7Hz1lfNPF28x c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DQAQCr3pNW/xbLJq1bA4QMbYhZs2IBD?= =?us-ascii?q?YFmGAqFI0oCgV8UAQEBAQEBAYEKhDQBAQEDAQEBATU2BAYBBQcCAgsOAgEEAQE?= =?us-ascii?q?BCRYIBwkDAgECAQkMHwkIBgEMBgIBARWFfYIQCA6/MQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBARgEhlKEf4QxDTomhB4BBIdhhxKIII1ZgV6EQ4MHhVWFZIR6g3MgAQF?= =?us-ascii?q?CghEcgV0+NIR6AR+BKwEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,553,1444694400"; d="scan'208";a="648417146" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jan 2016 16:57:30 +0000 Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u0BGvUd3001010; Mon, 11 Jan 2016 16:57:30 GMT To: Gert Grammel , Ladislav Lhotka References: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> <20160111.145436.1312067595929182117.mbj@tail-f.com> <20160111141116.GB42469@elstar.local> <5693C32E.7020708@cisco.com> <31E9D485-9349-448D-99A3-DD20F5E5AF09@nic.cz> From: Robert Wilton Message-ID: <5693DEFA.6080404@cisco.com> Date: Mon, 11 Jan 2016 16:57:30 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 16:57:47 -0000 Hi Gert, Please see inline ... On 11/01/2016 16:19, Gert Grammel wrote: > >> -----Original Message----- >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka >> Sent: 11 January 2016 16:36 >> To: Robert Wilton >> Cc: netmod@ietf.org >> Subject: Re: [netmod] applied configuration and system-controlled entries >> >> >>> On 11 Jan 2016, at 15:58, Robert Wilton wrote: >>> >>> >>> >>> On 11/01/2016 14:27, Ladislav Lhotka wrote: >>>>> On 11 Jan 2016, at 15:11, Juergen Schoenwaelder >> wrote: >>>>> On Mon, Jan 11, 2016 at 02:54:36PM +0100, Martin Bjorklund wrote: >>>>>> Ladislav Lhotka wrote: >>>>>>> Hi Gert, >>>>>>> >>>>>>>> On 11 Jan 2016, at 14:25, Gert Grammel >> wrote: >>>>>>>> Lada, >>>>>>>> >>>>>>>> The requirement says: >>>>>>>> D. When a configuration change for any intended configuration >>>>>>>> node has been successfully applied to the server (e.g. not >>>>>>>> failed, nor deferred due to absent hardware) then the >>>>>>>> existence and value of the corresponding applied >>>>>>>> configuration node must match the intended configuration >>>>>>>> node. >>>>>>>> >>>>>>>> I don't see that this would limit the case you described below. >>>>>>>> In your case there is no intended config, hence there is no >>>>>>>> "corresponding applied configuration" either. >>>>>>> You are right, the requirement can be interpreted this way. I >>>>>>> thought that applied configuration was supposed to be identical to >>>>>>> intended after some synchronization period. >>>>>> This is a very important point to clarify. Can there ever be data >>>>>> in "applied" that is not in "intended"? I think Anees & Rob >>>>>> previously said "no", but I might be wrong. >>>>>> >>>>> If there is time delay between editing intended and the applied >>>>> config matching the edits of intended, then I supose this can happen >>>>> (I delete a resource from intended but it is still around until >>>>> intended has been fully synced). I would find it interesting if some >>>>> edits are >>>> Using applied config for system-controlled entries would require that such >> an entry stays (forever) in applied config even after it has been deleted from >> intended. >>> I think that this would make life harder for clients. >> Hmm, I would say the opposite. For one, we could simplify the data models by >> reducing the duplicities in configuration and state trees. >> > Let's look at a practical example and see if we can converge: > 1) A Server is happily running with intended == applied config and operational state is aligned with intended config. > 2) A new HW is plugged into that server and that HW has some kind of identification number I think that you can solve this more cleanly with interfaces-state or equivalent. I don't think that a device should be creating configuration, the configuration should solely be controlled by the operator, and hence the ownership and flow of information is well defined. > > This can practically fall into 3 cases: > a) it's a plug&play device and it is accepted to be used In this case, it could generate a YANG notification from something like the Entity YANG model (or equivalent), and instantiate the new resources in interfaces-state as appropriate (or equivalent). The operator can then discover this and apply whatever configuration is appropriate (or perhaps they have put the configuration in previously waiting for the hardware to be inserted). > b) it's an accepted device but shall be configured prior to become operational Same as above. > c) it's considered a harmful (unplanned) event and the device shall be removed It generates a syslog error message, and perhaps Entity YANG model notification. The system doesn't accept any configuration related to the unsupported HW. > > In terms of a possible implementation, the event > 1) would update the applied config which - among others - include the identification number and update the operational state of that HW in line with the applied config > 2) Since the new applied config differs from the intended config, the client is notified about the change > 3) Upon inspection of the config change, the client decides how to deal with the new item: > a) accepting it the way it is: pushing down an intended config in line with the applied config information > b) accepting it with modifications: pushing down a new intended config with additional leafs > c) rejecting it: raising an alarm indicating the configuration mismatch, requiring manual intervention I don't think that you need to use applied config to solve this. You can support this using operational state and notifications, this then allows the configuration to be controlled by a single entity (i.e. the operator). > >>> With the requirements as they are today, the client gives the intended config >> to the system, which it can monitor until the applied config matches the >> intended config. At this point it knows everything is good and the config is >> fully applied. Over time, if everything is behaving as expected, the client can >> reasonably expect that the applied configuration will always converge on the >> intended configuration. > Which is the case above. By updating the intended config the client accepts the config change. Personally I don't think that it should be up to the client to accept/reject a config change that the server is making. The server should only notify what has changed in the system and leave it to the client to decide what configuration should be put on the system. Besides, I'm not sure that there is a clean way for the client to reject such an applied config change. I.e. I can't see how it can delete the configuration from the intended config because it already isn't there - it would need some special semantics and I don't think that they really help simplify this problem. Thanks, Rob >> One could argue that leafs with default values are in applied configuration >> before they appear in intended. So my idea was to extend this to default >> entries of certain lists. >> >>> Using applied config for system-controlled entries would break the simple >> logical relationship between intended and applied configuration, since there >> are now some special entries for which this rule does not always apply. >> > Don't get to the same conclusion, see above. > >> The introduction of applied configuration would mean significant >> complications to all protocols, and perhaps even to YANG (although I'd hope >> not). Solving only the synchonicity issue with it is IMO insufficient payoff for all >> the troubles. >> > Don't see this either. > > > >> Lada >> >>>>> always assumed to be synchronous but others may be asynchronous. >>>>> >>>>> And Lada, I think applied may happen to be never identical to >>>>> intended if, for example, hardware is absent or other missing >>>>> resources prevent certain parts of intended to become applied. >>>> Yes, this is the use case of pre-provisioning, which is important, too, but in >> fact opposite: the question here is whether applied can contain stuff that's not >> (and never been) in intended. >>> I think that the answer is basically no, unless it is an error condition and it is >> representing configuration that should be deleted. >>> Thanks, >>> Rob >>> >>> >>>> Lada >>>> >>>>> My understanding is that applied config in general forms an extended >>>>> subset of intended config. And to fully understand what a device is >>>>> doing, I may need to obtain its entire operational state since the >>>>> applied config may not include state obtained dynamically from other >>>>> sources. >>>>> >>>>> But I might still all be wrong... >>>>> >>>>> /js >>>>> >>>>> -- >>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>>>> Fax: +49 421 200 3103 >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>> . >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Mon Jan 11 08:59:03 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888AB1A8AB7; Mon, 11 Jan 2016 08:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcjW8084cFaY; Mon, 11 Jan 2016 08:58:57 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c: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 8A8B31A8ABB; Mon, 11 Jan 2016 08:58:56 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id f206so278942017wmf.0; Mon, 11 Jan 2016 08:58:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=uMeRkMfjtrgGSdczXIfm4KrHf+f/VVLd0jfI6retCmo=; b=v6q41ufiia4K0mhkYtXirjp/dpsOXL7s+l1yfaoVo/qVbZzplwyD674jQHfTV4aECJ q+Gdgs2558h8m/DCKAiDyZpH4lH0Wb2N14jvQCFlQdukGRKEe/DPQkwPYHACv/pKLEed vRRDq1JO6QkWI9ogZE9ZwDpr30cwg9gppQhsGTfef83eBshDz3Lww/OeYXfp+p5yNxxe NqTUvsTANpmCoec8KW0PhtYSU7oxM1enxOSMx/aK7nZWpoLFkKzHk47PGz7vRU72rusP Irhp5NREAIsK4ts0DV2lPq5RfXH9AHGHKav4XWyITemjWlQDBDU26cC2KN1IPgFfED7o qlqw== X-Received: by 10.194.243.103 with SMTP id wx7mr147825625wjc.136.1452531535142; Mon, 11 Jan 2016 08:58:55 -0800 (PST) Received: from [192.168.254.224] ([147.83.206.82]) by smtp.gmail.com with ESMTPSA id i2sm31279585wjx.42.2016.01.11.08.58.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 11 Jan 2016 08:58:53 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_6387A29F-02E7-4602-9ECE-850ED88EA289" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dean Bogdanovic In-Reply-To: <20151221153312.GA43316@elstar.local> Date: Mon, 11 Jan 2016 17:58:52 +0100 Message-Id: <2BAA2B26-EE40-4707-BBDB-C84E5653CF23@gmail.com> References: <20151211113156.GA43862@elstar.local> <2059AD77-5375-4DB0-A1BF-432835F11A9F@gmail.com> <20151221153312.GA43316@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3112) Archived-At: Cc: RTG YANG Design Team , netmod WG , Benoit Claise Subject: Re: [netmod] [Rtg-dt-yang-arch] [yang-doctors] Working group Last Call: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 16:59:02 -0000 --Apple-Mail=_6387A29F-02E7-4602-9ECE-850ED88EA289 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 21, 2015, at 4:33 PM, Juergen Schoenwaelder = wrote: >=20 > On Sat, Dec 19, 2015 at 07:50:58AM -0500, Dean Bogdanovic wrote: >> Juergen, >>=20 >> Please see answers inline >>=20 >> Dean >>=20 >>> On Dec 11, 2015, at 12:31 PM, Juergen Schoenwaelder = wrote: >>>=20 >>> On Wed, Dec 09, 2015 at 08:27:04AM -0800, Nadeau Thomas wrote: >>>>=20 >>>> This email initiates a NETMOD WG Last call for = draft-ietf-netmod-acl-model-06.=20 >>>> Please review the draft and make any comments to the list by = Wednesday, 16 December, 2015 >>>> by 8AM EST. >>>>=20 >>>=20 >>> Technical >>>=20 >>> - I am not sure I personally like the acl-oper-data and = ace-oper-data >>> containers in the middle of the config true tree. I understand that >>> operational state in this case is likely tightly bound to the >>> lifetime of the config state but I also generally prefer to have a >>> clean separation of config from state. But since I am not >>> implementing this, I am happy to leave the decision to those who >>> write the code. >>>=20 >>> - I would probably have used src-ipv4-prefix and dst-ipv4-prefix >>> instead of source-ipv4-network and destination-ipv4-network and >>> I would probably have used src-mac-address and src-mac-address-mask >>> and dst-mac-address and dst-mac-address-mask. Generally simple >>> src instead source and dst instead destination - lines up all >>> much more nicely. >>=20 >> I know that src and dst are pretty standard abbreviations, but have = preference to use full words. >>=20 >=20 > My eyes prefer the shorter versions but it might be subjective where > the line between arconyms and words is drawn. For me, things are not > done consistently according to my personal preferences. ;-) As many people, so many different preferences :) >=20 >>> - I would have put the acl-name and acl-type first followed by the >>> entries list. >>=20 >> Can you please expand on this? Is there any major difference? OR just = design choice? >=20 > Technically you can define key leafs anywhere but I think there are = some > benefits of defining them at the beginning of a list: >=20 > a) I find it nice if the leafs listed in the key statement follow the > key statement and not N pages down the document. > b) If you put them at the end and you have to add additional = definitions, > you will end up with leafs somewhere in the middle. > c) The XML encoding requires to ship key leafs first and it might be > simpler if the key leafs are also defined first in the data model > (so if you use the same order, you actually get things correct). >=20 > Now you tell me what the advantages are to put them at the end=E2=80=A6 I think this ended up being an edit oversight. In the draft 02, the = stated leafs were at the top module: ietf-acl +--rw access-lists +--rw access-list* [access-control-list-name] +--rw access-control-list-name string +--rw access-control-list-type? access-control-list-type +--ro access-control-list-oper-data | +--ro (targets)? | +--:(interface-name) | +--ro interface-name* string +--rw access-list-entries +--rw access-list-entry* [rule-name] I don=E2=80=99t remember if there was any specific reason to push the = acl-name and acl-type to the end. Will bring it back up. >=20 >>> - I also wonder why we use both the term 'entry' and 'rule', why not >>> pick one of them? You have for example rule-name (which is the key >>> of the list but again comes last). >> This is a bit of compromise between Cisco and Juniper terminology. In = Cisco it is ACE and in Juniper term. But in the yang model and in the = text we are using consistently one or the other word. >=20 > For the sake of clarity, I personally would prefer to have a single > term. I think Linux packet filters call things rules. I think BSD > packet filtering calls things rules. Wikipedia seem say that packet > filters consist of filtering rules... So I guess I have a preference > but I will not get a sleepless night over this. Authors are Cisco/Juniper people, so were using that terminology and I = believe that CSCO and JNPR are more used in networking then Linux :) >=20 >>> - Should there be features for ace-eth and ace-ipv4 and ace-ipv6 or = do >>> we expect that all implementations will always support all three? >>> Another option would be to have the generic model completely without >>> any protocol specific elements and to have separate models to >>> augment in ipv4, ipv6, and ethernet specific ace types. I actually >>> think this would make much more sense since you would not have a >>> module 'packet fields' but instead a clear extension of the >>> ietf-access-control-list module. You could also drop the examples >>> how to extend the core model since the ip and ethernet extensions >>> would already serve the purpose. You also would not need features >>> since an implementation advertises the extension modules. >>=20 >> We started early with such design, but then the WG feedback moved us = to the current design. >=20 > Can you provide pointers to minutes etc? I think the routing model > also has a core model where even unicast routing is augmented in. This > seems to make the boundary between the generic infrastructure and the > addins very clear. I haven=E2=80=99t seen a network device with filters without supporting = L2 and L3 types. This is how we started originally, but then comments = came in on the mailing list and wanted exact typing. Please see the = thread http://www.ietf.org/mail-archive/web/netmod/current/msg12144.html Model was changed for IETF 94 and at the WG meeting nobody raised the = issue. >=20 >>> - The 'uses packet-fields:metadata' resolves to a leaf >>> 'input-interface' which is of type string. Is this the only metadata >>> field we ever envision to be there? If so, why not make it part of >>> the base model? If not, what is the extensibility model here? =20 >>=20 >> It can be used for route filtering >=20 > Yeah, but the questions were: >=20 > - Is this the only metadata field we ever envision to be there? No, it can be timestamp, RIB, VRF, etc. > - If so, why not make it part of the base model? We are early in the modeling and people were asking to remove time range = from the base model and create separate draft, as many other features = are using time-range. > - If not, what is the extensibility model here? >=20 >>> And >>> should the interface reference not use a more specific type than >>> 'string=E2=80=99? >>=20 >> Interface references can be many things, from standard naming we are = familiar, e.g. ge-1/0/0.1 to a numerical value like 13276. Leaving it as = string gives us most flexibility in that regards. >=20 > I disagree that the goal here is most flexibility. We do have an > interfaces data model in the IETF. Why are we avoiding to refer to it > here? There is discussion in separate thread on this. And it seems we are in = agreement to move this model to YANG 1.1 and use Martin B proposed = solution. >=20 >>> - Some implementations support the action to jump or goto other >>> acls. Is this not common enough to include it as a base action, >>> perhaps protected by a feature? >>=20 >> Yes among vendors, but it can be very specific. Example, in Juniper = implementation there are two types of filters, classical and Fast Update = Filters (FUF). Classic filters support (on specific HW platforms) filter = as action, but FUF does not. Not all terms and not all actions are = supported on FUFs. So you have to see what filter type and what platform = it is, in order to such a specific action. >=20 > What speaks against making jump and/or call actions a feature? jump is not supported on all platforms and all types of filters. >=20 >>> - In the example in section 4.3, does the CLI shown really help = much? >>> The syntax is pretty system specific. >>=20 >> OTH, it is widely understood and self explanatory. >=20 > The question was whether it is needed to show system specific CLI. > BTW, I note that the textual description says "deny ... from > _leaving_". How is the 'from leaving' translated into the XML? Is > there any distinction between input and output filters (or forwarding > filters or whatever your engine supports)? We can improve the text description. Why not show system specific CLI? = It is something widely understood and it is an example.=20 This is what is being translated into XML access-list ip sample-ip-acl deny tcp host 10.10.10.1 host 10.10.10.255 And usually people understand real example better, then just text = description. >=20 >>> In the XML shown, can you not >>> leave out all the fields that are not set? This would remove a lot >>> of noise. I do not understand what having both actions deny and >>> permit at the same time means. Did you validate the example against >>> the data model? (I also find the keys at the end somewhat strange >>> and not that NETCONF XML serialization actually requires the keys to >>> be sent first.) >=20 >> We used pyang sample xml skeleton to create the xml example. >=20 > Whatever, the noise does not really help and the example might even > mislead people to believe they have to write down all unused leafs. We could edit the empty fields out, but from personal experience working = with customers, I was getting questions that the compiler output and the = examples are not matching (it was vendor data modeling language). >=20 >> Leaving both actions in the document is my fault. In the model, = action is a choice, and it was a bad copy paste job. Didn=E2=80=99t = choose :) >>>=20 >>> - The clarification whether the boundary port numbers are included = in >>> a port range should be in the YANG model. The YANG model should also >>> say what it means if one of the ranges is not present. We should not >>> define the semantics by examples. >> I=E2=80=99m loosing you here. We are stating in the model if the = boundary port numbers are included in a port rang. >=20 > Ack, I found it in the description of container source-port-range (and > previously I looked at lower-port and upper-port). >=20 >>>=20 >>> - I do not understand section 5. It shows some nftables syntax but >>> does not really shed a light on what the example shown does or how >>> that maps to the YANG data model. So I am left somewhat clueless. >>=20 >> Just wanted to point out that the basic structure of iptables is = similar to ACL yang model, so a translation from one to the other should = be a simple process. If someone wants to make it compliant. >=20 > It escapes me how the iptables fragment shown in page 18 maps to the > YANG model. What is the substance behind the statement "It should be > fairly easy to do translation between ACL YANG model described in this > draft and Linux nftables."? Has someone done a mapping? It is not > obvious to me how this works. No, the mapping between nftables and ACL YANG model has not been = finished.=20 >=20 >>> - Can I trigger multiple actions from an ace? Or do I have to >>> replicate the ace to do that? In general, there is extension of >>> a choice (means one of several) and there are extension of a >>> choice already present. >> Again, this is very platform dependent, so didn=E2=80=99t want to = include it in the base model. >>=20 >=20 > So what would I do if I want to 'log' and 'deny'? Even if the base > model does not do that, how can I augment this in? The base model must > provide the necessary extensibility hooks. Logging/counting and another action (permit/deny) is possible with most = vendors, but other multiple actions are not by most vendors, example to = jump to another ACE or ACL. You have to replicate the ACE to do that. So = to make it simple, this was the choice we made. >=20 >>> - Empty description statements or descriptions statements "(null)" >>> need to be fixed. >>=20 >> There are no empty descriptions. You are probably referring to = ietf-packet-fields.yang model. There is a bug in pyang which was = reported to Martin and fixed since. >=20 > I am talking about this (page 25): >=20 > description "(null)=E2=80=9D; OK, got it.=20 >=20 >>> - I am a bit surprised that we do not define how to attach an ACL to >>> an interfaces or a set of interfaces given that we do have an >>> interfaces YANG data model. The example given in A.3 makes me wonder >>> why there should be a counter in the interfaces config tree. The >>> targets/interface-name back-reference seems to indicate that I can >>> attach an ACL only to a single interface. >>=20 >> I wasn=E2=80=99t the author of that section >=20 > This is a WG document so this needs to be resolved. You are right.=20 >=20 >>> - I do not understand A.4 at all. Defining an identity does not make >>> the choice work differently. >>>=20 >>> - Has someone tried to implement this? >>=20 >> Was working on implementation while at my previous employer, but am = not aware of any other implementation. >=20 > I believe it will help a lot to have prototype implementations of this > data model in order to make sure the model does actually work and > provides the extensibility hooks that are necessary. In particular, I > would feel much more convinced if it would be clear (as a proof of > concept) how the model maps to say Linux packet filters. I would > actually not mind if mapping examples from the data model to various > filtering engines would be in the appendix. This would give evidence > that people have actually worked through a couple of concrete > examples. In this case, I can=E2=80=99t help at the moment, as have left the = previous company where I was working on an implementation.=20 >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 --Apple-Mail=_6387A29F-02E7-4602-9ECE-850ED88EA289 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Dec 21, 2015, at 4:33 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

On = Sat, Dec 19, 2015 at 07:50:58AM -0500, Dean Bogdanovic wrote:
Juergen,
Please see answers inline

Dean
On Dec = 11, 2015, at 12:31 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

On Wed, Dec 09, 2015 at 08:27:04AM -0800, = Nadeau Thomas wrote:

This email initiates a NETMOD WG = Last call for draft-ietf-netmod-acl-model-06.
Please = review the draft and make any comments to the list by Wednesday, 16 = December, 2015
by 8AM EST.


Technical

- I am not sure I personally like the acl-oper-data and = ace-oper-data
containers in the middle of the config true = tree. I understand that
operational state in this case is = likely tightly bound to the
lifetime of the config state = but I also generally prefer to have a
clean separation of = config from state. But since I am not
implementing this, = I am happy to leave the decision to those who
write the = code.

- I would probably have used = src-ipv4-prefix and dst-ipv4-prefix
instead of = source-ipv4-network and destination-ipv4-network and
I = would probably have used src-mac-address and src-mac-address-mask
and dst-mac-address and dst-mac-address-mask. Generally = simple
src instead source and dst instead destination - = lines up all
much more nicely.

I know that src and dst are = pretty standard abbreviations, but have preference to use full words.


My eyes prefer the = shorter versions but it might be subjective where
the line = between arconyms and words is drawn. For me, things are not
done consistently according to my personal preferences. = ;-)

As = many people, so many different preferences :)


- I would have put the acl-name and acl-type = first followed by the
entries list.

Can you please expand on this? Is = there any major difference? OR just design choice?

Technically you can define key = leafs anywhere but I think there are some
benefits of = defining them at the beginning of a list:

a) = I find it nice if the leafs listed in the key statement follow the
  key statement and not N pages down the = document.
b) If you put them at the end and you have to = add additional definitions,
  you will end up = with leafs somewhere in the middle.
c) The XML encoding = requires to ship key leafs first and it might be
=   simpler if the key leafs are also defined first in the data = model
  (so if you use the same order, you = actually get things correct).

Now you tell = me what the advantages are to put them at the = end=E2=80=A6

I think = this ended up being an edit oversight. In the draft 02, the stated leafs = were at the top

module: = ietf-acl
+--rw access-lists
+--rw access-list* = [access-control-list-name]
+--rw access-control-list-name =         string
+--rw = access-control-list-type?       =  access-control-list-type
+--ro = access-control-list-oper-data
|  +--ro = (targets)?
|     +--:(interface-name)
| =        +--ro interface-name*   = string
+--rw access-list-entries
+--rw = access-list-entry* [rule-name]

I = don=E2=80=99t remember if there was any specific reason to push the = acl-name and acl-type to the end. Will bring it back = up.

- I also wonder why we use both the term = 'entry' and 'rule', why not
pick one of them? You have = for example rule-name (which is the key
of the list but = again comes last).
This is a bit of = compromise between Cisco and Juniper terminology. In Cisco it is ACE and = in Juniper term. But in the yang model and in the text we are using = consistently one or the other word.

For the sake of clarity, I personally would prefer to have a = single
term. I think Linux packet filters call things = rules. I think BSD
packet filtering calls things rules. = Wikipedia seem say that packet
filters consist of = filtering rules... So I guess I have a preference
but I = will not get a sleepless night over this.

Authors= are Cisco/Juniper people, so were using that terminology and I believe = that CSCO and JNPR are more used in networking then Linux = :)


- Should = there be features for ace-eth and ace-ipv4 and ace-ipv6 or do
we expect that all implementations will always support all = three?
Another option would be to have the generic model = completely without
any protocol specific elements and to = have separate models to
augment in ipv4, ipv6, and = ethernet specific ace types. I actually
think this would = make much more sense since you would not have a
module = 'packet fields' but instead a clear extension of the
= ietf-access-control-list module. You could also drop the examples
how to extend the core model since the ip and ethernet = extensions
would already serve the purpose. You also = would not need features
since an implementation = advertises the extension modules.

We started early with such design, but then the WG feedback = moved us to the current  design.

Can you provide pointers to minutes etc? I think the routing = model
also has a core model where even unicast routing is = augmented in. This
seems to make the boundary between the = generic infrastructure and the
addins very clear.

I = haven=E2=80=99t seen a network device with filters without supporting L2 = and L3 types. This is how we started originally, but then comments came = in on the mailing list and wanted exact typing. Please see the = thread


Model was changed for IETF 94 = and at the WG meeting nobody raised the issue.


- The 'uses = packet-fields:metadata' resolves to a leaf
= 'input-interface' which is of type string. Is this the only metadata
field we ever envision to be there? If so, why not make it = part of
the base model? If not, what is the extensibility = model here?  

It can be = used for route filtering

Yeah, = but the questions were:

- Is this the only = metadata field we ever envision to be there?
No, it can be timestamp, RIB, VRF, = etc.

- If so, why not make it part of the base = model?

We are early in = the modeling and people were asking to remove time range from the base = model and create separate draft, as many other features are using = time-range.
- If not, what is the extensibility model = here?

And
= should the interface reference not use a more specific type than
'string=E2=80=99?

Interface references can be many things, from standard naming = we are familiar, e.g. ge-1/0/0.1 to a numerical value like 13276. = Leaving it as string gives us most flexibility in that regards.

I disagree that the goal here is = most flexibility. We do have an
interfaces data model in = the IETF. Why are we avoiding to refer to it
here?

There = is discussion in separate thread on this. And it seems we are in = agreement to move this model to YANG 1.1 and use Martin B proposed = solution.

- Some implementations support the action to = jump or goto other
acls. Is this not common enough to = include it as a base action,
perhaps protected by a = feature?

Yes among vendors, = but it can be very specific. Example, in Juniper implementation there = are two types of filters, classical and Fast Update Filters (FUF). = Classic filters support (on specific HW platforms) filter as action, but = FUF does not. Not all terms and not all actions are supported on FUFs. = So you have to see what filter type and what platform it is, in order to = such a specific action.

What = speaks against making jump and/or call actions a feature?

jump is = not supported on all platforms and all types of filters.

- In the example in section 4.3, does the CLI = shown really help much?
The syntax is pretty system = specific.

OTH, it is widely = understood and self explanatory.

The question was whether it is needed to show system specific = CLI.
BTW, I note that the textual description says "deny = ... from
_leaving_".  How is the 'from leaving' = translated into the XML? Is
there any distinction between = input and output filters (or forwarding
filters or = whatever your engine supports)?

We can = improve the text description. Why not show system specific CLI? It is = something widely understood and it is an example. 

This is what is being translated into = XML
              =  access-list ip sample-ip-acl
        =        deny tcp host 10.10.10.1 host = 10.10.10.255

And usually people = understand real example better, then just text = description.


In the XML = shown, can you not
leave out all the fields that are not = set? This would remove a lot
of noise. I do not = understand what having both actions deny and
permit at = the same time means. Did you validate the example against
= the data model? (I also find the keys at the end somewhat strange
and not that NETCONF XML serialization actually requires the = keys to
be sent first.)

We used pyang sample xml skeleton to create the = xml example.

Whatever, the = noise does not really help and the example might even
mislead people to believe they have to write down all unused = leafs.

We= could edit the empty fields out, but from personal experience working = with customers, I was getting questions that the compiler output and the = examples are not matching (it was vendor data modeling language).

Leaving = both actions in the document is my fault. In the model, action is a = choice, and it was a bad copy paste job. Didn=E2=80=99t choose :)

- The = clarification whether the boundary port numbers are included in
a port range should be in the YANG model. The YANG model = should also
say what it means if one of the ranges is not = present. We should not
define the semantics by = examples.
I=E2=80=99m loosing you here. We = are stating in the model if the boundary port numbers are included in a = port rang.

Ack, I found it in = the description of container source-port-range (and
previously I looked at lower-port and upper-port).


- I do not understand section = 5. It shows some nftables syntax but
does not really shed = a light on what the example shown does or how
that maps = to the YANG data model. So I am left somewhat clueless.

Just wanted to point out that the = basic structure of iptables is similar to ACL yang model, so a = translation from one to the other should be a  simple process. If = someone wants to make it compliant.

It escapes me how the iptables fragment shown in page 18 maps = to the
YANG model. What is the substance behind the = statement "It should be
fairly easy to do translation = between ACL YANG model described in this
draft and Linux = nftables."? Has someone done a mapping? It is not
obvious = to me how this works.

No, the mapping between nftables and ACL YANG model =  has not been finished. 

- Can I = trigger multiple actions from an ace? Or do I have to
= replicate the ace to do that? In general, there is extension of
a choice (means one of several) and there are extension of = a
choice already present.
Again,= this is very platform dependent, so didn=E2=80=99t want to include it = in the base model.


So what would I do if I want to 'log' and 'deny'? Even if the = base
model does not do that, how can I augment this in? = The base model must
provide the necessary extensibility = hooks.

Logging/counting and another action (permit/deny) is = possible with most vendors, but other multiple actions = are not by most vendors, example to jump to another ACE or ACL. You have = to replicate the ACE to do that. So to make it simple, this was the = choice we made.

- Empty description = statements or descriptions statements "(null)"
need to be = fixed.

There are no empty = descriptions. You are probably referring to ietf-packet-fields.yang = model. There is a bug in pyang which was reported to Martin and fixed = since.

I am talking about this = (page 25):

=      description "(null)=E2=80=9D;

OK, got = it. 

- I am a bit surprised = that we do not define how to attach an ACL to
an = interfaces or a set of interfaces given that we do have an
= interfaces YANG data model. The example given in A.3 makes me wonder
why there should be a counter in the interfaces config tree. = The
targets/interface-name back-reference seems to = indicate that I can
attach an ACL only to a single = interface.

I wasn=E2=80=99t = the author of that section

This = is a WG document so this needs to be resolved.

You = are right. 

- I do not understand = A.4 at all. Defining an identity does not make
the choice = work differently.

- Has someone tried to = implement this?

Was working on = implementation while at my previous employer, but am not aware of any = other implementation.

I = believe it will help a lot to have prototype implementations of this
data model in order to make sure the model does actually work = and
provides the extensibility hooks that are necessary. = In particular, I
would feel much more convinced if it = would be clear (as a proof of
concept) how the model maps = to say Linux packet filters. I would
actually not mind if = mapping examples from the data model to various
filtering = engines would be in the appendix. This would give evidence
that people have actually worked through a couple of = concrete
examples.

In this = case, I can=E2=80=99t help at the moment, as have left the previous = company where I was working on an implementation. 

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

= --Apple-Mail=_6387A29F-02E7-4602-9ECE-850ED88EA289-- From nobody Mon Jan 11 09:11:54 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3E31A8ACB for ; Mon, 11 Jan 2016 09:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWKnc2JpGdrQ for ; Mon, 11 Jan 2016 09:11:51 -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 2BCDC1A8AC9 for ; Mon, 11 Jan 2016 09:11:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1449; q=dns/txt; s=iport; t=1452532311; x=1453741911; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=jjWEuqCiR6Y3M66h6YDgSVkijeFS81R06EeYHP17BE4=; b=Xq1+yJKZUWlfOtRYAmHbHsHYbtdnfLWwvu3Mx5QMcleZCODkdNLflddr vky3HvrFjEI+awC1RVe8h1RenJbFVBOzjk9uOO+KD8Jv9cFa6xjQoaJK/ oDC55v/iJZywHX+Ec10w2I6AmQ3IV8pzb1WczXabTzwkktYTlgkg1vKly 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoBAB84ZNW/xbLJq1ejVK1VoYPAoFzA?= =?us-ascii?q?QEBAQEBgQuENQEBBDg0CgIRCxgJFg8JAwIBAgFFBgEMCAEBF4gTv1gBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBARyGVoR/iTwBBJcTjVmBXodKhVWKXoNzZIQKPoZ5AQEB?= X-IronPort-AV: E=Sophos;i="5.20,553,1444694400"; d="scan'208";a="624427637" 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; 11 Jan 2016 17:11:49 +0000 Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u0BHBm7i021674; Mon, 11 Jan 2016 17:11:49 GMT To: Ladislav Lhotka , NETMOD WG References: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> <5693B918.2080006@cisco.com> <5693CA8A.7080805@cisco.com> <20160111161348.GA412@elstar.local> From: Robert Wilton Message-ID: <5693E255.9030606@cisco.com> Date: Mon, 11 Jan 2016 17:11:49 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160111161348.GA412@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 17:11:54 -0000 On 11/01/2016 16:13, Juergen Schoenwaelder wrote: > On Mon, Jan 11, 2016 at 03:30:18PM +0000, Robert Wilton wrote: >> Going back to your original problem, my understanding is that the only >> solution in YANG today is to have a config false hierarchy to represent >> system-controlled objects whose lifetime is independent from >> configuration, hence the existence of "interfaces-state" separate from >> "interfaces". With this approach you lose the ability to retrieve all >> configuration and state together in a single sub-tree within a request >> but gain the flexibility of independent data lifetime. >> > I think filters even today allow you to retrieve both subtrees > (intended and operational state) together if that is desired. Yes, I think that this partly helps. I think that it may be desirable (perhaps via a protocol extension) to have the two sub-trees merged into a single tree so that the config and state data is co-located. However, to achieve this programmatically would probably require some more rules on consistent node naming between related config and state sub-trees. Arguably it is similar to having separate datastores for intended and applied configuration, but wanting to retrieve with the data co-located in the same tree structure. Which IIRC, you have previously suggested could be solved via an appropriate protocol extension as well. Thanks, Rob > > /js > From nobody Mon Jan 11 09:20:56 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF141A8AE8 for ; Mon, 11 Jan 2016 09:20:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRcPYB9qMUxX for ; Mon, 11 Jan 2016 09:20:54 -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 10C021A8A9B for ; Mon, 11 Jan 2016 09:20:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3019; q=dns/txt; s=iport; t=1452532854; x=1453742454; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=heFvhnFfcKU1FipJsXnWz11McW5IAbhXU58c00kMYmk=; b=Rogx5pWneXC5/IICbvs5OlSo7xOGfYAdTwaHzbAn7NFENlqSpcqblYd8 vePCJaqky+Kyo2bffnEhQxmq9dIbCA94PebVLduxsKCPD1uO/0gDWIiDK Z9p9IgZ9tRzMQb3z03ex/gHLJeQf7QY6YvRAJq0uvSmGZjpBvRn+jbzcx Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtBADc45NW/xbLJq1ehAxtiFm1VhgKh?= =?us-ascii?q?SNKAoFzAQEBAQEBgQuENAEBAQMBAQEBNTYKBgsLDgoJFg8JAwIBAgEVMAYBDAY?= =?us-ascii?q?CAQGIIggOv04BAQEBAQEBAQEBAQEBAQEBAQEBGoZWhH+JPAEElxOFQ4gWgV5Kg?= =?us-ascii?q?3mDB4VVhWSIbWSECz00hkUBAQE?= X-IronPort-AV: E=Sophos;i="5.20,553,1444694400"; d="scan'208";a="624427910" 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 2016 17:20:52 +0000 Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u0BHKkk6016740; Mon, 11 Jan 2016 17:20:47 GMT To: Kent Watsen , "netmod@ietf.org" References: <20160109005830.20805.41463.idtracker@ietfa.amsl.com> From: Benoit Claise Message-ID: <5693E46D.7080707@cisco.com> Date: Mon, 11 Jan 2016 18:20:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 17:20:56 -0000 Hi Kent, You use MUST, SHOULD, MAY, and you refer to RFC 2119. Fine. However, it might be beneficial to say something such as in RFC 7698 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. While [RFC2119] describes interpretations of these key words in terms of protocol specifications and implementations, they are used in this document to describe design requirements for protocol extensions. Btw, I never quite understood what a MAY means for a requirement. See requirement 2B and 2C Regards, Benoit > In addition to the title update, I also updated the abstract/introduction and fixed a couple editorial items. > > Kent > > > > > On 1/8/16, 7:58 PM, "netmod on behalf of internet-drafts@ietf.org" wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. >> >> Title : Terminology and Requirements for Enhanced Handling of Operational State >> Authors : Kent Watsen >> Thomas Nadeau >> Filename : draft-ietf-netmod-opstate-reqs-03.txt >> Pages : 7 >> Date : 2016-01-08 >> >> Abstract: >> This document primarily regards the difference between the intended >> configuration and the applied configuration of a device and how >> intended and applied configuration relate to the operational state of >> a device. This document defines requirements for the applied >> configuration's data model and its values, as well as for enabling a >> client to know when a configuration has been fully applied or not, >> how to access operational state, and how to relate intended >> configuration nodes to applied configuration and derived state nodes. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-03 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-opstate-reqs-03 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> 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 > . > From nobody Mon Jan 11 09:50:02 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7981A875A for ; Mon, 11 Jan 2016 09:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSurTEdJIL4P for ; Mon, 11 Jan 2016 09:49:51 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0714.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::714]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D21A31A0015 for ; Mon, 11 Jan 2016 09:49:50 -0800 (PST) Received: from CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) by CY1PR0501MB1610.namprd05.prod.outlook.com (10.161.162.139) with Microsoft SMTP Server (TLS) id 15.1.361.13; Mon, 11 Jan 2016 17:49:34 +0000 Received: from CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) by CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) with mapi id 15.01.0361.006; Mon, 11 Jan 2016 17:49:34 +0000 From: Gert Grammel To: Robert Wilton , Ladislav Lhotka Thread-Topic: [netmod] applied configuration and system-controlled entries Thread-Index: AQHRSTUGxYtkEO44aUCWX59qiQKmfp72U6BggAAN6lSAAASVAIAACKQAgAAKfoCAAAPVYIAAEtAAgAAB2xA= Date: Mon, 11 Jan 2016 17:49:34 +0000 Message-ID: References: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> <20160111.145436.1312067595929182117.mbj@tail-f.com> <20160111141116.GB42469@elstar.local> <5693C32E.7020708@cisco.com> <31E9D485-9349-448D-99A3-DD20F5E5AF09@nic.cz> <5693DEFA.6080404@cisco.com> In-Reply-To: <5693DEFA.6080404@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; x-originating-ip: [193.110.55.14] x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1610; 5:JThf/qTXJs8JDSUFJ7gIRzKBWZWjR04ISs2+id0qKsikfZJA7L4a9+pHZ1GF0iW9xxsp6tDqI8N/3kQSyDDJFJ4JvhdkRD3dOXRZAtAovm6zXiO2BwCfNLoVf1fTU/KQJqnSmg+lbKerTfHigBwiJg==; 24:ocIaM6Q69HC63HP4qv3+/gojVlQ2b8wk92xETXfK1B3K7hHdh5pC0EvF9P14D9ZFI+It26q4pvJYr7BEFlJm1QSDLXSgs9caG+EyIqjFo60= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1610; x-ms-office365-filtering-correlation-id: 43c8328b-6ce3-48a4-f81f-08d31aaf914c x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:CY1PR0501MB1610; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1610; x-forefront-prvs: 0818724663 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(189002)(164054003)(24454002)(51444003)(199003)(13464003)(97736004)(87936001)(575784001)(86362001)(106116001)(40100003)(19580405001)(93886004)(101416001)(19580395003)(33656002)(122556002)(5002640100001)(99286002)(74316001)(66066001)(5001770100001)(5003600100002)(106356001)(105586002)(76576001)(92566002)(81156007)(4326007)(2906002)(50986999)(1096002)(586003)(5008740100001)(189998001)(5001960100002)(3846002)(2950100001)(102836003)(11100500001)(77096005)(6116002)(10400500002)(15975445007)(54356999)(76176999)(5004730100002)(1220700001)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1610; H:CY1PR0501MB1609.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:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2016 17:49:34.6211 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1610 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 17:49:58 -0000 Rob, I realize that the pre-conditions of the example made weren't clear. There = is certainly the possibility to pre-configure a node in the intended config= and wait until some HW is inserted. Indeed in a Telco environment this is = the preferred case and will stay so for a while. Lada mentioned a case which didn't have an intended config to begin with an= d asked how it fits in the model. I was using the HW insertion case to show= how it can be dealt with: either by physical intervention (removing the HW= ) or by updating the intended config to accept the server state. Admittedly= this is not the norm, but rather an exception. In any event, the differenc= e between intended and applied is temporary. --Gert >-----Original Message----- >From: Robert Wilton [mailto:rwilton@cisco.com] >Sent: 11 January 2016 17:58 >To: Gert Grammel; Ladislav Lhotka >Cc: netmod@ietf.org >Subject: Re: [netmod] applied configuration and system-controlled entries > >Hi Gert, > >Please see inline ... > >On 11/01/2016 16:19, Gert Grammel wrote: >> >>> -----Original Message----- >>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav >>> Lhotka >>> Sent: 11 January 2016 16:36 >>> To: Robert Wilton >>> Cc: netmod@ietf.org >>> Subject: Re: [netmod] applied configuration and system-controlled >>> entries >>> >>> >>>> On 11 Jan 2016, at 15:58, Robert Wilton wrote: >>>> >>>> >>>> >>>> On 11/01/2016 14:27, Ladislav Lhotka wrote: >>>>>> On 11 Jan 2016, at 15:11, Juergen Schoenwaelder >>> wrote: >>>>>> On Mon, Jan 11, 2016 at 02:54:36PM +0100, Martin Bjorklund wrote: >>>>>>> Ladislav Lhotka wrote: >>>>>>>> Hi Gert, >>>>>>>> >>>>>>>>> On 11 Jan 2016, at 14:25, Gert Grammel >>> wrote: >>>>>>>>> Lada, >>>>>>>>> >>>>>>>>> The requirement says: >>>>>>>>> D. When a configuration change for any intended configurat= ion >>>>>>>>> node has been successfully applied to the server (e.g. = not >>>>>>>>> failed, nor deferred due to absent hardware) then the >>>>>>>>> existence and value of the corresponding applied >>>>>>>>> configuration node must match the intended configuratio= n >>>>>>>>> node. >>>>>>>>> >>>>>>>>> I don't see that this would limit the case you described below. >>>>>>>>> In your case there is no intended config, hence there is no >>>>>>>>> "corresponding applied configuration" either. >>>>>>>> You are right, the requirement can be interpreted this way. I >>>>>>>> thought that applied configuration was supposed to be identical >>>>>>>> to intended after some synchronization period. >>>>>>> This is a very important point to clarify. Can there ever be >>>>>>> data in "applied" that is not in "intended"? I think Anees & Rob >>>>>>> previously said "no", but I might be wrong. >>>>>>> >>>>>> If there is time delay between editing intended and the applied >>>>>> config matching the edits of intended, then I supose this can >>>>>> happen (I delete a resource from intended but it is still around >>>>>> until intended has been fully synced). I would find it interesting >>>>>> if some edits are >>>>> Using applied config for system-controlled entries would require >>>>> that such >>> an entry stays (forever) in applied config even after it has been >>> deleted from intended. >>>> I think that this would make life harder for clients. >>> Hmm, I would say the opposite. For one, we could simplify the data >>> models by reducing the duplicities in configuration and state trees. >>> >> Let's look at a practical example and see if we can converge: >> 1) A Server is happily running with intended =3D=3D applied config and >operational state is aligned with intended config. >> 2) A new HW is plugged into that server and that HW has some kind of >> identification number >I think that you can solve this more cleanly with interfaces-state or equi= valent. >I don't think that a device should be creating configuration, the configur= ation >should solely be controlled by the operator, and hence the ownership and f= low >of information is well defined. > I would rephrase your words a bit: I don't think that a device should be creating *intended* configuration, th= e *intended* configuration should solely be controlled by the operator, and hence the ownership and fl= ow of information is well defined. Instead the applied configuration should represent the server as-is and an = inserted HW can't be changed by SW.=20 However HW can be put in an operational state that inhibits it from being u= sed. > >> >> This can practically fall into 3 cases: >> a) it's a plug&play device and it is accepted to be used >In this case, it could generate a YANG notification from something like th= e >Entity YANG model (or equivalent), and instantiate the new resources in >interfaces-state as appropriate (or equivalent). The operator can then di= scover >this and apply whatever configuration is appropriate (or perhaps they have= put >the configuration in previously waiting for the hardware to be inserted). That would practically mean some pre-provisioning is already in the intende= d (and applied) config, and the operational state is aligned with the appli= ed configuration upon insertion. > >> b) it's an accepted device but shall be configured prior to become >> operational >Same as above. > >> c) it's considered a harmful (unplanned) event and the device shall be >> removed >It generates a syslog error message, and perhaps Entity YANG model >notification. The system doesn't accept any configuration related to the >unsupported HW. Which would mean there is an intended (and applied) config present in the s= erver that would require HW insertion to generate a syslog message. There a= re certainly environments where unplanned insertion of HW shall trigger sys= log error messages. However it wouldn't be a clean solution to require Erro= r messages triggering a Client to update the server's intended config. > > >> >> In terms of a possible implementation, the event >> 1) would update the applied config which - among others - include the >> identification number and update the operational state of that HW in >> line with the applied config >> 2) Since the new applied config differs from the intended config, the >> client is notified about the change >> 3) Upon inspection of the config change, the client decides how to deal = with >the new item: >> a) accepting it the way it is: pushing down an intended config in line >with the applied config information >> b) accepting it with modifications: pushing down a new intended config >with additional leafs >> c) rejecting it: raising an alarm indicating the configuration >> mismatch, requiring manual intervention > >I don't think that you need to use applied config to solve this. You can s= upport >this using operational state and notifications, this then allows the >configuration to be controlled by a single entity (i.e. the operator). > >> >>>> With the requirements as they are today, the client gives the intended >config >>> to the system, which it can monitor until the applied config matches th= e >>> intended config. At this point it knows everything is good and the con= fig is >>> fully applied. Over time, if everything is behaving as expected, the c= lient >can >>> reasonably expect that the applied configuration will always converge o= n >the >>> intended configuration. >> Which is the case above. By updating the intended config the client acce= pts >the config change. >Personally I don't think that it should be up to the client to >accept/reject a config change that the server is making. The server >should only notify what has changed in the system and leave it to the >client to decide what configuration should be put on the system. > >Besides, I'm not sure that there is a clean way for the client to reject >such an applied config change. I.e. I can't see how it can delete the >configuration from the intended config because it already isn't there - >it would need some special semantics and I don't think that they really >help simplify this problem. > >Thanks, >Rob > > >>> One could argue that leafs with default values are in applied configura= tion >>> before they appear in intended. So my idea was to extend this to defaul= t >>> entries of certain lists. >>> >>>> Using applied config for system-controlled entries would break the sim= ple >>> logical relationship between intended and applied configuration, since >there >>> are now some special entries for which this rule does not always apply. >>> >> Don't get to the same conclusion, see above. >> >>> The introduction of applied configuration would mean significant >>> complications to all protocols, and perhaps even to YANG (although I'd >hope >>> not). Solving only the synchonicity issue with it is IMO insufficient p= ayoff for >all >>> the troubles. >>> >> Don't see this either. >> >> >> >>> Lada >>> >>>>>> always assumed to be synchronous but others may be asynchronous. >>>>>> >>>>>> And Lada, I think applied may happen to be never identical to >>>>>> intended if, for example, hardware is absent or other missing >>>>>> resources prevent certain parts of intended to become applied. >>>>> Yes, this is the use case of pre-provisioning, which is important, to= o, but >in >>> fact opposite: the question here is whether applied can contain stuff t= hat's >not >>> (and never been) in intended. >>>> I think that the answer is basically no, unless it is an error conditi= on and it >is >>> representing configuration that should be deleted. >>>> Thanks, >>>> Rob >>>> >>>> >>>>> Lada >>>>> >>>>>> My understanding is that applied config in general forms an extended >>>>>> subset of intended config. And to fully understand what a device is >>>>>> doing, I may need to obtain its entire operational state since the >>>>>> applied config may not include state obtained dynamically from other >>>>>> sources. >>>>>> >>>>>> But I might still all be wrong... >>>>>> >>>>>> /js >>>>>> >>>>>> -- >>>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germa= ny >>>>>> Fax: +49 421 200 3103 >>>>> -- >>>>> Ladislav Lhotka, CZ.NIC Labs >>>>> PGP Key ID: E74E8C0C >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>> . >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> . >> From nobody Mon Jan 11 10:31:10 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384251A875A; Mon, 11 Jan 2016 10:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoaywP2HI_47; Mon, 11 Jan 2016 10:31: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 987CC1A01A2; Mon, 11 Jan 2016 10:31: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 4F329763; Mon, 11 Jan 2016 19:31:02 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id QAvuQO_B3oPx; Mon, 11 Jan 2016 19:30: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; Mon, 11 Jan 2016 19:30:59 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C71832002B; Mon, 11 Jan 2016 19:30:59 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id jeubFxC6wmaa; Mon, 11 Jan 2016 19:30:55 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 88DC720013; Mon, 11 Jan 2016 19:30:54 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C982C3981B4B; Mon, 11 Jan 2016 19:30:53 +0100 (CET) Date: Mon, 11 Jan 2016 19:30:53 +0100 From: Juergen Schoenwaelder To: Dean Bogdanovic Message-ID: <20160111183053.GA565@elstar.local> Mail-Followup-To: Dean Bogdanovic , Nadeau Thomas , Benoit Claise , RTG YANG Design Team , netmod WG References: <20151211113156.GA43862@elstar.local> <2059AD77-5375-4DB0-A1BF-432835F11A9F@gmail.com> <20151221153312.GA43316@elstar.local> <2BAA2B26-EE40-4707-BBDB-C84E5653CF23@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: <2BAA2B26-EE40-4707-BBDB-C84E5653CF23@gmail.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: RTG YANG Design Team , netmod WG , Benoit Claise Subject: Re: [netmod] [Rtg-dt-yang-arch] [yang-doctors] Working group Last Call: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 18:31:07 -0000 On Mon, Jan 11, 2016 at 05:58:52PM +0100, Dean Bogdanovic wrote: > > > > > For the sake of clarity, I personally would prefer to have a single > > term. I think Linux packet filters call things rules. I think BSD > > packet filtering calls things rules. Wikipedia seem say that packet > > filters consist of filtering rules... So I guess I have a preference > > but I will not get a sleepless night over this. > > Authors are Cisco/Juniper people, so were using that terminology and I believe that CSCO and JNPR are more used in networking then Linux :) > If I were to have the time, I would even challenge you on that. Clearly, when you consider # of devices connected to the Internet, I am sure CISCO and JNPR will loose. But even in enterprise networks, there are tons of Linux and BSD firewalls. Consider all the home routers running openWRT and packet filters. So yes, if I would have time, I would challenge you on that argument. In some Junos documentation (Junos 14.2), I have seen the terms 'filter' and 'term'. But I might be proven wrong... > >>> - Should there be features for ace-eth and ace-ipv4 and ace-ipv6 or do > >>> we expect that all implementations will always support all three? > >>> Another option would be to have the generic model completely without > >>> any protocol specific elements and to have separate models to > >>> augment in ipv4, ipv6, and ethernet specific ace types. I actually > >>> think this would make much more sense since you would not have a > >>> module 'packet fields' but instead a clear extension of the > >>> ietf-access-control-list module. You could also drop the examples > >>> how to extend the core model since the ip and ethernet extensions > >>> would already serve the purpose. You also would not need features > >>> since an implementation advertises the extension modules. > >> > >> We started early with such design, but then the WG feedback moved us to the current design. > > > > Can you provide pointers to minutes etc? I think the routing model > > also has a core model where even unicast routing is augmented in. This > > seems to make the boundary between the generic infrastructure and the > > addins very clear. > > I haven’t seen a network device with filters without supporting L2 and L3 types. This is how we started originally, but then comments came in on the mailing list and wanted exact typing. Please see the thread > > http://www.ietf.org/mail-archive/web/netmod/current/msg12144.html > > Model was changed for IETF 94 and at the WG meeting nobody raised the issue. I am talking about the modularity of the base model, I do not see how the cited thread relates to this. > >>> - The 'uses packet-fields:metadata' resolves to a leaf > >>> 'input-interface' which is of type string. Is this the only metadata > >>> field we ever envision to be there? If so, why not make it part of > >>> the base model? If not, what is the extensibility model here? > >> > >> It can be used for route filtering > > > > Yeah, but the questions were: > > > > - Is this the only metadata field we ever envision to be there? > No, it can be timestamp, RIB, VRF, etc. > > > - If so, why not make it part of the base model? > > We are early in the modeling and people were asking to remove time range from the base model and create separate draft, as many other features are using time-range. I agree that the decision is kind of tough to make. One option is to make the base model pretty much content free and to add pretty much everything in a modular way via extensions of the base model. > > - If not, what is the extensibility model here? Question remains open. > >>> And > >>> should the interface reference not use a more specific type than > >>> 'string’? > >> > >> Interface references can be many things, from standard naming we are familiar, e.g. ge-1/0/0.1 to a numerical value like 13276. Leaving it as string gives us most flexibility in that regards. > > > > I disagree that the goal here is most flexibility. We do have an > > interfaces data model in the IETF. Why are we avoiding to refer to it > > here? > > There is discussion in separate thread on this. And it seems we are in agreement to move this model to YANG 1.1 and use Martin B proposed solution. OK > >>> - Some implementations support the action to jump or goto other > >>> acls. Is this not common enough to include it as a base action, > >>> perhaps protected by a feature? > >> > >> Yes among vendors, but it can be very specific. Example, in Juniper implementation there are two types of filters, classical and Fast Update Filters (FUF). Classic filters support (on specific HW platforms) filter as action, but FUF does not. Not all terms and not all actions are supported on FUFs. So you have to see what filter type and what platform it is, in order to such a specific action. This is why getting the modularity right is very important here. > > What speaks against making jump and/or call actions a feature? > > jump is not supported on all platforms and all types of filters. A feature does not have to be supported by everyone. > >>> - In the example in section 4.3, does the CLI shown really help much? > >>> The syntax is pretty system specific. > >> > >> OTH, it is widely understood and self explanatory. > > > > The question was whether it is needed to show system specific CLI. > > BTW, I note that the textual description says "deny ... from > > _leaving_". How is the 'from leaving' translated into the XML? Is > > there any distinction between input and output filters (or forwarding > > filters or whatever your engine supports)? > > We can improve the text description. Why not show system specific CLI? It is something widely understood and it is an example. > > This is what is being translated into XML > access-list ip sample-ip-acl > deny tcp host 10.10.10.1 host 10.10.10.255 > > And usually people understand real example better, then just text description. May please CISCO people, others likely less. But so be it. > >>> In the XML shown, can you not > >>> leave out all the fields that are not set? This would remove a lot > >>> of noise. I do not understand what having both actions deny and > >>> permit at the same time means. Did you validate the example against > >>> the data model? (I also find the keys at the end somewhat strange > >>> and not that NETCONF XML serialization actually requires the keys to > >>> be sent first.) > > > >> We used pyang sample xml skeleton to create the xml example. > > > > Whatever, the noise does not really help and the example might even > > mislead people to believe they have to write down all unused leafs. > > We could edit the empty fields out, but from personal experience working with customers, I was getting questions that the compiler output and the examples are not matching (it was vendor data modeling language). Which compiler's output? I find it very distracting to list unused leafs. I assume most NETCONF implementations suppress unused leafs as well. (I might be proven wrong but I would have a preference to not use one that sends me tons of useless empty leafs.) > >> Leaving both actions in the document is my fault. In the model, action is a choice, and it was a bad copy paste job. Didn’t choose :) > >>> > >>> - The clarification whether the boundary port numbers are included in > >>> a port range should be in the YANG model. The YANG model should also > >>> say what it means if one of the ranges is not present. We should not > >>> define the semantics by examples. > >> I’m loosing you here. We are stating in the model if the boundary port numbers are included in a port rang. > > > > Ack, I found it in the description of container source-port-range (and > > previously I looked at lower-port and upper-port). > > > >>> > >>> - I do not understand section 5. It shows some nftables syntax but > >>> does not really shed a light on what the example shown does or how > >>> that maps to the YANG data model. So I am left somewhat clueless. > >> > >> Just wanted to point out that the basic structure of iptables is similar to ACL yang model, so a translation from one to the other should be a simple process. If someone wants to make it compliant. > > > > It escapes me how the iptables fragment shown in page 18 maps to the > > YANG model. What is the substance behind the statement "It should be > > fairly easy to do translation between ACL YANG model described in this > > draft and Linux nftables."? Has someone done a mapping? It is not > > obvious to me how this works. > > No, the mapping between nftables and ACL YANG model has not been finished. OK > >>> - Can I trigger multiple actions from an ace? Or do I have to > >>> replicate the ace to do that? In general, there is extension of > >>> a choice (means one of several) and there are extension of a > >>> choice already present. > >> Again, this is very platform dependent, so didn’t want to include it in the base model. > >> > > > > So what would I do if I want to 'log' and 'deny'? Even if the base > > model does not do that, how can I augment this in? The base model must > > provide the necessary extensibility hooks. > > Logging/counting and another action (permit/deny) is possible with most vendors, but other multiple actions are not by most vendors, example to jump to another ACE or ACL. You have to replicate the ACE to do that. So to make it simple, this was the choice we made. So what about counting logging? Can we make the base simple yet powerful enough via features to match what common open source software implementations can do? > > I believe it will help a lot to have prototype implementations of this > > data model in order to make sure the model does actually work and > > provides the extensibility hooks that are necessary. In particular, I > > would feel much more convinced if it would be clear (as a proof of > > concept) how the model maps to say Linux packet filters. I would > > actually not mind if mapping examples from the data model to various > > filtering engines would be in the appendix. This would give evidence > > that people have actually worked through a couple of concrete > > examples. > > In this case, I can’t help at the moment, as have left the previous company where I was working on an implementation. Perhaps there are others here with sufficient interested to work out (at least) how the model maps back and forth to the implementation(s) they are familiar with? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jan 11 12:17:54 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9061A90F1 for ; Mon, 11 Jan 2016 12:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljQn9FsLqjNp for ; Mon, 11 Jan 2016 12:17:51 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id BE0111A90F0 for ; Mon, 11 Jan 2016 12:17:51 -0800 (PST) Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id D33A31AE047A; Mon, 11 Jan 2016 21:17:49 +0100 (CET) Date: Mon, 11 Jan 2016 21:18:37 +0100 (CET) Message-Id: <20160111.211837.377848045119250710.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <31E9D485-9349-448D-99A3-DD20F5E5AF09@nic.cz> References: <5693C32E.7020708@cisco.com> <31E9D485-9349-448D-99A3-DD20F5E5AF09@nic.cz> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 20:17:53 -0000 Ladislav Lhotka wrote: > > > On 11 Jan 2016, at 15:58, Robert Wilton wrote: > > > > > > > > On 11/01/2016 14:27, Ladislav Lhotka wrote: > >>> On 11 Jan 2016, at 15:11, Juergen Schoenwaelder > >>> wrote: > >>> > >>> On Mon, Jan 11, 2016 at 02:54:36PM +0100, Martin Bjorklund wrote: > >>>> Ladislav Lhotka wrote: > >>>>> Hi Gert, > >>>>> > >>>>>> On 11 Jan 2016, at 14:25, Gert Grammel wrote: > >>>>>> > >>>>>> Lada, > >>>>>> > >>>>>> The requirement says: > >>>>>> D. When a configuration change for any intended configuration > >>>>>> node has been successfully applied to the server (e.g. not > >>>>>> failed, nor deferred due to absent hardware) then the > >>>>>> existence and value of the corresponding applied > >>>>>> configuration node must match the intended configuration > >>>>>> node. > >>>>>> > >>>>>> I don't see that this would limit the case you described below. In > >>>>>> your case there is no intended config, hence there is no > >>>>>> "corresponding applied configuration" either. > >>>>> You are right, the requirement can be interpreted this way. I thought > >>>>> that applied configuration was supposed to be identical to intended > >>>>> after some synchronization period. > >>>> This is a very important point to clarify. Can there ever be data in > >>>> "applied" that is not in "intended"? I think Anees & Rob previously > >>>> said "no", but I might be wrong. > >>>> > >>> If there is time delay between editing intended and the applied config > >>> matching the edits of intended, then I supose this can happen (I > >>> delete a resource from intended but it is still around until intended > >>> has been fully synced). I would find it interesting if some edits are > >> Using applied config for system-controlled entries would require that > >> such an entry stays (forever) in applied config even after it has been > >> deleted from intended. > > I think that this would make life harder for clients. > > Hmm, I would say the opposite. For one, we could simplify the data > models by reducing the duplicities in configuration and state trees. This is the old idea of having the "operational state" datastore, which would be all config true + all config false nodes. One issue with this is that the semantics of the node is different in the different data stores, even if the syntax (by definition!) is the same. In order to handle this properly you need either two different description statements, or two "sections" within the description statement. list interface { description-config "The list of configured interfaces on the device. ..."; description-oper "The list of interfaces on the device. System-controlled interfaces created by the system are always present in this list, whether they are configured or not. ..."; } /martin From nobody Mon Jan 11 12:59:47 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03CB1A914E for ; Mon, 11 Jan 2016 12:59:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DY9lrm-k3yvJ for ; Mon, 11 Jan 2016 12:59:42 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0117.outbound.protection.outlook.com [65.55.169.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1A751A913D for ; Mon, 11 Jan 2016 12:59:42 -0800 (PST) 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 (TLS) id 15.1.365.19; Mon, 11 Jan 2016 20:59:40 +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.0365.020; Mon, 11 Jan 2016 20:59:40 +0000 From: Kent Watsen To: Benoit Claise , "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-03.txt Thread-Index: AQHRSnjhPwhlEKSCNkWPsuBEQbmSJJ7yCYMAgASKWoD//+lYgA== Date: Mon, 11 Jan 2016 20:59:40 +0000 Message-ID: <3474CCCD-1B8B-40B7-B3BF-C1164C144A8F@juniper.net> References: <20160109005830.20805.41463.idtracker@ietfa.amsl.com> <5693E46D.7080707@cisco.com> In-Reply-To: <5693E46D.7080707@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151105 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-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 5:Hi1AuzskiHKefQc1bDR3Kq90eIiFwO+IVRxyLLVyrzRlmQb0LvMuym+1Sdp5leIcCIAloagWPyIBHuisBT+fgvsFw3MMwZBJDZIYKwO1f+aolMYxADCTtuR3Rc6/cs+bLonrhMNrDu86ZRC1RADq0Q==; 24:diQuqJPfjRhisf6WMXiMFRy7qDo7n4m6aD9yy7YL21YzFJhE/S/dMmEP5btG9kaoa5y/Q9DlsBJwQlENaOfMI/X8wklyhypBUZuvmWsRDEY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1443; x-ms-office365-filtering-correlation-id: bd77503e-6a16-4148-f4b9-08d31aca1fb4 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 0818724663 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(86362001)(2950100001)(5001960100002)(87936001)(99286002)(106116001)(82746002)(81156007)(36756003)(189998001)(1220700001)(107886002)(5002640100001)(11100500001)(4001350100001)(586003)(3846002)(1096002)(5001770100001)(97736004)(230783001)(6116002)(105586002)(40100003)(122556002)(2501003)(54356999)(83506001)(102836003)(2906002)(10400500002)(2900100001)(50986999)(33656002)(5008740100001)(101416001)(83716003)(106356001)(92566002)(66066001)(76176999)(5004730100002)(77096005)(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:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <79E296AA88FBBD4E8FDDD6A3BC7BE40E@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2016 20:59:40.5009 (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: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 20:59:46 -0000 DQpIaSBCZW5vaXQsDQoNCg0KPllvdSB1c2UgTVVTVCwgU0hPVUxELCBNQVksIGFuZCB5b3UgcmVm ZXIgdG8gUkZDIDIxMTkuIEZpbmUuDQo+SG93ZXZlciwgaXQgbWlnaHQgYmUgYmVuZWZpY2lhbCB0 byBzYXkgc29tZXRoaW5nIHN1Y2ggYXMgaW4gUkZDIDc2OTgNCj4NCj4gICAgVGhlIGtleSB3b3Jk cyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0K PiAgICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJP UFRJT05BTCIgaW4gdGhpcw0KPiAgICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMg ZGVzY3JpYmVkIGluIFtSRkMyMTE5XS4NCj4NCj4gICAgV2hpbGUgW1JGQzIxMTldIGRlc2NyaWJl cyBpbnRlcnByZXRhdGlvbnMgb2YgdGhlc2Uga2V5IHdvcmRzIGluIHRlcm1zDQo+ICAgIG9mIHBy b3RvY29sIHNwZWNpZmljYXRpb25zIGFuZCBpbXBsZW1lbnRhdGlvbnMsIHRoZXkgYXJlIHVzZWQg aW4gdGhpcw0KPiAgICBkb2N1bWVudCB0byBkZXNjcmliZSBkZXNpZ24gcmVxdWlyZW1lbnRzIGZv ciBwcm90b2NvbCBleHRlbnNpb25zLg0KDQpJcyB0aGlzIG5lZWRlZD8gIExvb2tpbmcgYXQgUkZD MjExOSwgSSBkb27igJl0IHJlYWQgaXQgYXMgYmVpbmcgdmVyeSBwYXJ0aWN1bGFyIGFib3V0IHRo ZSBjb250ZXh0IGl04oCZcyB0ZXJtcyBhcmUgdXNlZCBpbi4NCg0KQWRkaXRpb25hbGx5LCBvdGhl ciByZXF1aXJlbWVudHMgZG9jcyB1c2UgUkZDMjExOSB3aXRob3V0IGFueSBzdWNoIGEgcGFyYWdy YXBoIChlLmcuLCBSRkM3Njk4LCBSRkM3NDk3LCBSRkM3NDQ5LCBldGMuKS4uLg0KDQoNCj5CdHcs IEkgbmV2ZXIgcXVpdGUgdW5kZXJzdG9vZCB3aGF0IGEgTUFZIG1lYW5zIGZvciBhIHJlcXVpcmVt ZW50Lg0KPlNlZSByZXF1aXJlbWVudCAyQiBhbmQgMkMNCg0KRm9yIDJCLCB3b3VsZCB5b3UgcmF0 aGVyIGlzIGJlIGEgU0hPVUxEPw0KRm9yIDJDLCB3b3VsZCB5b3UgcmF0aGVyIHRoaXMgYmUgYSDi gJxtYXnigJ0/DQoNCkZXSVcsIHRoZSBvdGhlciByZXF1aXJlbWVudHMgZG9jcyBsaXN0ZWQgYWJv dmUgYWxzbyB1c2UgIk1BWSIgaW4gc29tZSBvZiB0aGVpciDigJxyZXF1aXJlbWVudHMiDQoNCg0K S2VudA0KDQoNCg== From nobody Mon Jan 11 14:00:26 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448121AC3B5; Mon, 11 Jan 2016 14:00:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QC6kBL3uPvbu; Mon, 11 Jan 2016 14:00:22 -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 1BC481ABD3E; Mon, 11 Jan 2016 14:00:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=870; q=dns/txt; s=iport; t=1452549622; x=1453759222; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=0WQtmuz4dzCqj7PIXIzj3GQqv4FWLUpboED1IfdE2vk=; b=Y86+oABnB18W38Bloxz0BxMgyRLVwTfU8c6QBl2qjFYr/zXwIeS4hmgh GZp1EYkHqDPE+PXObJxibRnvvMI+F6wAMplpn7woeons4FvX2+PKxBKF5 30atNwFV+VrGFLx6cVeMZHiTO8nuCBxsYT07dKS+s4FyaVdezB344Wqxl I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtBAACJZRW/xbLJq1ehAxtiFm1VxgKh?= =?us-ascii?q?W0CgWQRAQEBAQEBAYEKhDUBAQMBAQEBIA8BBTYKAQULCw4MAgUWCwICCQMCAQI?= =?us-ascii?q?BFTAGAQwGAgEBEIgSCA6vQZAuAQEBAQEBAQEBAQEBAQEBAQEBAQEBFASBAYVVh?= =?us-ascii?q?H+Hc4FJAQSXE4YthyyBXodKhVWKXoNzOCyECz00hkUBAQE?= X-IronPort-AV: E=Sophos;i="5.20,554,1444694400"; d="scan'208";a="648424308" 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 2016 22:00:19 +0000 Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u0BM0Ige023986; Mon, 11 Jan 2016 22:00:18 GMT To: Nadeau Thomas , NETMOD WG References: From: Benoit Claise Message-ID: <569425EB.5080400@cisco.com> Date: Mon, 11 Jan 2016 23:00:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Benoit Claise Subject: Re: [netmod] [yang-doctors] Resigning Chair Position X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 22:00:24 -0000 Thanks Tom for your years of service in this very important WG. Joel and I are working on a replacement plan. Regards, Benoit > I am writing to the NETMOD WG to inform you all that I will be resigning my position as co-chair. I will remain on as co-chair and continue my duties until Benoit finds a suitable replacement, which he tells me will not be too long. It has been a challenge and pleasure serving the community as co-chair over the past 2 years. I learned a lot in this role, and I hope I served the community well. I hope to continue working with many of you in the capacity of an individual contributor in and around the area of Yang and model creation. > > Cheers, > > —Tom > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors From nobody Mon Jan 11 16:12:43 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEA0F1AC43B for ; Mon, 11 Jan 2016 16:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRnE-C0m2Z2A for ; Mon, 11 Jan 2016 16:12:39 -0800 (PST) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::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 85BC91AC439 for ; Mon, 11 Jan 2016 16:12:39 -0800 (PST) Received: by mail-pa0-x22a.google.com with SMTP id yy13so236597069pab.3 for ; Mon, 11 Jan 2016 16:12:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=VIW66ejd14hoX5/6K5jg/wZq8h/jiLQWoVnJpoNTzBM=; b=cxqBV4DrfsIt8/kmwQ3vXR9odrahHe6V5L9Rxku80WfHQG54vqwj7KrE7Rnayw1M78 k7iP1LaeFvyRAxM7WfP5CaujZAHpj2SWYKjqGqj9zGb2KXtUirJchbblEm0uUOefpwqV KMTTNujJ/rKalZhfmtUwuHXPBRJFkDhEV8r5povpfn1ee3UvE3J7wrGsqeDR7NYOELOU ILY/z6KpHPdbFkqOBBBItwAXp357r5j2pqpNp5ZkNGfnqgOWqhxbDPc+TjAa45m6F6DX 4KB+lvXFrD/7liaK7gn+d+YzMZwj4ec/MLKougUSv3Ewmnupwp2moPXrJS3nwDqTMRlv +Ztw== X-Received: by 10.66.251.226 with SMTP id zn2mr185428718pac.44.1452557559233; Mon, 11 Jan 2016 16:12:39 -0800 (PST) Received: from [10.155.129.45] ([128.107.241.163]) by smtp.gmail.com with ESMTPSA id c90sm25709122pfd.31.2016.01.11.16.12.37 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 11 Jan 2016 16:12:38 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_615836C3-B2A2-480B-B6A4-D1341B595440" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mahesh Jethanandani In-Reply-To: <20160111.101526.1720014765007751699.mbj@tail-f.com> Date: Mon, 11 Jan 2016 16:12:35 -0800 Message-Id: <163715AC-361A-4500-B362-7283A573DB0D@gmail.com> References: <20160111.101526.1720014765007751699.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.2104) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] 6087bis namespace recommendations X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 00:12:41 -0000 --Apple-Mail=_615836C3-B2A2-480B-B6A4-D1341B595440 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jan 11, 2016, at 1:15 AM, Martin Bjorklund wrote: >=20 > Hi, >=20 > Currently, 6087bis says that standards-track, published and > unpublished modules SHOULD use the URN prefix > "urn:ietf:params:xml:ns:yang:". >=20 > There are two issues with this: >=20 > 1. We already publish experimental modules w/ this prefix. > (ietf-netconf-time and ietf-complex-types). True. >=20 > So 6087bis should remove "standards track" from this > recommendation. Yes.=20 >=20 > 2. There was some discussion about recommending a different URN > prefix for unpublished modules (i.e., modules in Internet > Drafts). >=20 > Should 6087bis recommend some special urn prefix for drafts, > with a note to the RFC editor to change the namespace once it > has been registered with IANA? I am inclined to let the urn prefixes be what they will be once the = document gets adopted as an RFC. There are plenty of tools and work = today that extracts the module and uses it as is on an experimental = basis. Having to change them every time the drafts changes or modify = existing code once the module it uses becomes RFC is painful. Besides, = the chances of conflict are low with the URN namespaces, so why make the = process onerous. >=20 > And another issue. 6087bis also has this: >=20 > OLD:=20 >=20 > The following examples are for non-Standards-Track modules. > The domain "example.com" SHOULD be used in all namespace URIs > for example modules. >=20 > http://example.com/ns/example-interfaces >=20 > http://example.com/ns/example-system >=20 >=20 > First of all, the sentence about non-Standards-Track modules is > confusing. Second, since the publication of RFC 6087, RFC 6963 has > been published, which defines a URN for examples. I suggest we update > 6087bis like this: >=20 > NEW: >=20 > Example modules in all types of documents SHOULD use a namespace > with either the example URN [RFC 6963] or the domain "example.com". > For example: >=20 > urn:example:interfaces >=20 > http://example.com/ns/example-system = Agree. >=20 >=20 >=20 > /martin >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_615836C3-B2A2-480B-B6A4-D1341B595440 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Jan 11, 2016, at 1:15 AM, Martin Bjorklund <mbj@tail-f.com> = wrote:

Hi,
Currently, 6087bis says that standards-track, = published and
unpublished modules SHOULD use the URN = prefix
"urn:ietf:params:xml:ns:yang:".

There are two issues with this:

=  1.  We already publish experimental modules w/ this = prefix.
     (ietf-netconf-time = and ietf-complex-types).

True.


=      So 6087bis should remove "standards track" = from this
=      recommendation.

Yes. 


 2. =  There was some discussion about recommending a different URN
     prefix for unpublished modules = (i.e., modules in Internet
=      Drafts).

=      Should 6087bis recommend some special urn = prefix for drafts,
     with a = note to the RFC editor to change the namespace once it
=      has been registered with IANA?

I am inclined to = let the urn prefixes be what they will be once the document gets adopted = as an RFC. There are plenty of tools and work today that extracts the = module and uses it as is on an experimental basis. Having to change them = every time the drafts changes or modify existing code once the module it = uses becomes RFC is painful. Besides, the chances of conflict are low = with the URN namespaces, so why make the process onerous.


And another issue.  6087bis also has this:

OLD:

 The = following examples are for non-Standards-Track modules.
=  The domain "example.com" SHOULD be used in all namespace URIs
 for example modules.

=      http://example.com/ns/example-interfaces

     http://example.com/ns/example-system


First of all, the sentence about = non-Standards-Track modules is
confusing.  Second, = since the publication of RFC 6087, RFC 6963 has
been = published, which defines a URN for examples.  I suggest we = update
6087bis like this:

NEW:

 Example modules in = all types of documents SHOULD use a namespace
 with = either the example URN [RFC 6963] or the domain "example.com".
=  For example:

=      urn:example:interfaces

     http://example.com/ns/example-system

Agree.




/martin



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

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_615836C3-B2A2-480B-B6A4-D1341B595440-- From nobody Tue Jan 12 01:05:47 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64B921A21C7 for ; Tue, 12 Jan 2016 01:05:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3vZkmHcPm0e for ; Tue, 12 Jan 2016 01:05:44 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id E0D7A1A1ABE for ; Tue, 12 Jan 2016 01:05:43 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id BFF431CC01E5; Tue, 12 Jan 2016 10:05:47 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20160111.211837.377848045119250710.mbj@tail-f.com> References: <5693C32E.7020708@cisco.com> <31E9D485-9349-448D-99A3-DD20F5E5AF09@nic.cz> <20160111.211837.377848045119250710.mbj@tail-f.com> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 12 Jan 2016 10:05:41 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 09:05:46 -0000 Martin Bjorklund writes: > Ladislav Lhotka wrote: >> >> > On 11 Jan 2016, at 15:58, Robert Wilton wrote: >> > >> > >> > >> > On 11/01/2016 14:27, Ladislav Lhotka wrote: >> >>> On 11 Jan 2016, at 15:11, Juergen Schoenwaelder >> >>> wrote: >> >>> >> >>> On Mon, Jan 11, 2016 at 02:54:36PM +0100, Martin Bjorklund wrote: >> >>>> Ladislav Lhotka wrote: >> >>>>> Hi Gert, >> >>>>> >> >>>>>> On 11 Jan 2016, at 14:25, Gert Grammel wrote: >> >>>>>> >> >>>>>> Lada, >> >>>>>> >> >>>>>> The requirement says: >> >>>>>> D. When a configuration change for any intended configuration >> >>>>>> node has been successfully applied to the server (e.g. not >> >>>>>> failed, nor deferred due to absent hardware) then the >> >>>>>> existence and value of the corresponding applied >> >>>>>> configuration node must match the intended configuration >> >>>>>> node. >> >>>>>> >> >>>>>> I don't see that this would limit the case you described below. In >> >>>>>> your case there is no intended config, hence there is no >> >>>>>> "corresponding applied configuration" either. >> >>>>> You are right, the requirement can be interpreted this way. I thought >> >>>>> that applied configuration was supposed to be identical to intended >> >>>>> after some synchronization period. >> >>>> This is a very important point to clarify. Can there ever be data in >> >>>> "applied" that is not in "intended"? I think Anees & Rob previously >> >>>> said "no", but I might be wrong. >> >>>> >> >>> If there is time delay between editing intended and the applied config >> >>> matching the edits of intended, then I supose this can happen (I >> >>> delete a resource from intended but it is still around until intended >> >>> has been fully synced). I would find it interesting if some edits are >> >> Using applied config for system-controlled entries would require that >> >> such an entry stays (forever) in applied config even after it has been >> >> deleted from intended. >> > I think that this would make life harder for clients. >> >> Hmm, I would say the opposite. For one, we could simplify the data >> models by reducing the duplicities in configuration and state trees. > > This is the old idea of having the "operational state" datastore, > which would be all config true + all config false nodes. One issue > with this is that the semantics of the node is different in the > different data stores, even if the syntax (by definition!) is the > same. In order to handle this properly you need either two different > description statements, or two "sections" within the description > statement. I think this is not much different from default values. Leafs and leaf-lists that have them defined in the data model may not be present in intended config, yet one can consider them to be in applied config. Lada > > list interface { > description-config > "The list of configured interfaces on the device. > ..."; > description-oper > "The list of interfaces on the device. > > System-controlled interfaces created by the system are > always present in this list, whether they are configured or > not. > ..."; > } > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jan 12 01:23:42 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAC71A6F6D for ; Tue, 12 Jan 2016 01:23:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngZcvmJdJtVD for ; Tue, 12 Jan 2016 01:23:34 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7461A6F5D for ; Tue, 12 Jan 2016 01:23:33 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id C61651CC01E5; Tue, 12 Jan 2016 10:23:38 +0100 (CET) From: Ladislav Lhotka To: Gert Grammel , Robert Wilton In-Reply-To: References: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> <20160111.145436.1312067595929182117.mbj@tail-f.com> <20160111141116.GB42469@elstar.local> <5693C32E.7020708@cisco.com> <31E9D485-9349-448D-99A3-DD20F5E5AF09@nic.cz> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 12 Jan 2016 10:23:33 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 09:23:36 -0000 Gert Grammel writes: >>-----Original Message----- >>From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka >>Sent: 11 January 2016 16:36 >>To: Robert Wilton >>Cc: netmod@ietf.org >>Subject: Re: [netmod] applied configuration and system-controlled entries >> >> >>> On 11 Jan 2016, at 15:58, Robert Wilton wrote: >>> >>> >>> >>> On 11/01/2016 14:27, Ladislav Lhotka wrote: >>>>> On 11 Jan 2016, at 15:11, Juergen Schoenwaelder >> wrote: >>>>> >>>>> On Mon, Jan 11, 2016 at 02:54:36PM +0100, Martin Bjorklund wrote: >>>>>> Ladislav Lhotka wrote: >>>>>>> Hi Gert, >>>>>>> >>>>>>>> On 11 Jan 2016, at 14:25, Gert Grammel >>wrote: >>>>>>>> >>>>>>>> Lada, >>>>>>>> >>>>>>>> The requirement says: >>>>>>>> D. When a configuration change for any intended configuration >>>>>>>> node has been successfully applied to the server (e.g. not >>>>>>>> failed, nor deferred due to absent hardware) then the >>>>>>>> existence and value of the corresponding applied >>>>>>>> configuration node must match the intended configuration >>>>>>>> node. >>>>>>>> >>>>>>>> I don't see that this would limit the case you described below. >>>>>>>> In your case there is no intended config, hence there is no >>>>>>>> "corresponding applied configuration" either. >>>>>>> You are right, the requirement can be interpreted this way. I >>>>>>> thought that applied configuration was supposed to be identical to >>>>>>> intended after some synchronization period. >>>>>> This is a very important point to clarify. Can there ever be data >>>>>> in "applied" that is not in "intended"? I think Anees & Rob >>>>>> previously said "no", but I might be wrong. >>>>>> >>>>> If there is time delay between editing intended and the applied >>>>> config matching the edits of intended, then I supose this can happen >>>>> (I delete a resource from intended but it is still around until >>>>> intended has been fully synced). I would find it interesting if some >>>>> edits are >>>> Using applied config for system-controlled entries would require that such >>an entry stays (forever) in applied config even after it has been deleted from >>intended. >>> I think that this would make life harder for clients. >> >>Hmm, I would say the opposite. For one, we could simplify the data models by >>reducing the duplicities in configuration and state trees. >> > > Let's look at a practical example and see if we can converge: > 1) A Server is happily running with intended == applied config and operational state is aligned with intended config. > 2) A new HW is plugged into that server and that HW has some kind of identification number > > This can practically fall into 3 cases: > a) it's a plug&play device and it is accepted to be used > b) it's an accepted device but shall be configured prior to become operational > c) it's considered a harmful (unplanned) event and the device shall be removed > > In terms of a possible implementation, the event > 1) would update the applied config which - among others - include the identification number and update the operational state of that HW in line with the applied config > 2) Since the new applied config differs from the intended config, the client is notified about the change > 3) Upon inspection of the config change, the client decides how to deal with the new item: > a) accepting it the way it is: pushing down an intended config > in line with the applied config information This shouldn't be necessary. Default values are also accepted as something the device operationally uses, but they needn't be copied to intended config. In fact, I think this intended-applied duality could be used for a sound definition of default contents: defaults would be present in applied but not in intended config. This would eliminate the need for with-defaults. Otherwise, your scenario looks good to me. Lada > b) accepting it with modifications: pushing down a new intended > config with additional leafs > c) rejecting it: raising an alarm indicating the configuration > mismatch, requiring manual intervention > >>> >>> With the requirements as they are today, the client gives the intended config >>to the system, which it can monitor until the applied config matches the >>intended config. At this point it knows everything is good and the config is >>fully applied. Over time, if everything is behaving as expected, the client can >>reasonably expect that the applied configuration will always converge on the >>intended configuration. > > Which is the case above. By updating the intended config the client accepts the config change. >> >>One could argue that leafs with default values are in applied configuration >>before they appear in intended. So my idea was to extend this to default >>entries of certain lists. >> >>> >>> Using applied config for system-controlled entries would break the simple >>logical relationship between intended and applied configuration, since there >>are now some special entries for which this rule does not always apply. >> > Don't get to the same conclusion, see above. > >>The introduction of applied configuration would mean significant >>complications to all protocols, and perhaps even to YANG (although I'd hope >>not). Solving only the synchonicity issue with it is IMO insufficient payoff for all >>the troubles. >> > Don't see this either. > > > >>Lada >> >>> >>>> >>>>> always assumed to be synchronous but others may be asynchronous. >>>>> >>>>> And Lada, I think applied may happen to be never identical to >>>>> intended if, for example, hardware is absent or other missing >>>>> resources prevent certain parts of intended to become applied. >>>> Yes, this is the use case of pre-provisioning, which is important, too, but in >>fact opposite: the question here is whether applied can contain stuff that's not >>(and never been) in intended. >>> >>> I think that the answer is basically no, unless it is an error condition and it is >>representing configuration that should be deleted. >>> >>> Thanks, >>> Rob >>> >>> >>>> >>>> Lada >>>> >>>>> My understanding is that applied config in general forms an extended >>>>> subset of intended config. And to fully understand what a device is >>>>> doing, I may need to obtain its entire operational state since the >>>>> applied config may not include state obtained dynamically from other >>>>> sources. >>>>> >>>>> But I might still all be wrong... >>>>> >>>>> /js >>>>> >>>>> -- >>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>>>> Fax: +49 421 200 3103 >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>> . >> >>-- >>Ladislav Lhotka, CZ.NIC Labs >>PGP Key ID: E74E8C0C >> >> >> >> >>_______________________________________________ >>netmod mailing list >>netmod@ietf.org >>https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jan 12 02:00:03 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9F21A6FD9 for ; Tue, 12 Jan 2016 02:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujHXBETlMYnd for ; Tue, 12 Jan 2016 01:59:53 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0712.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::712]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E39C1A6FD8 for ; Tue, 12 Jan 2016 01:59:52 -0800 (PST) Received: from CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) by CY1PR0501MB1612.namprd05.prod.outlook.com (10.161.162.140) with Microsoft SMTP Server (TLS) id 15.1.361.13; Tue, 12 Jan 2016 09:59:28 +0000 Received: from CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) by CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) with mapi id 15.01.0361.006; Tue, 12 Jan 2016 09:59:28 +0000 From: Gert Grammel To: Ladislav Lhotka , Robert Wilton Thread-Topic: [netmod] applied configuration and system-controlled entries Thread-Index: AQHRSTUGxYtkEO44aUCWX59qiQKmfp72U6BggAAN6lSAAASVAIAACKQAgAAKfoCAAAPVYIABJlCAgAAayAA= Date: Tue, 12 Jan 2016 09:59:28 +0000 Message-ID: References: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> <20160111.145436.1312067595929182117.mbj@tail-f.com> <20160111141116.GB42469@elstar.local> <5693C32E.7020708@cisco.com> <31E9D485-9349-448D-99A3-DD20F5E5AF09@nic.cz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [193.110.55.13] x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1612; 5:VCOoZKJWdwEW4gwXt195EBZMgRaofpXFRSgSqjSni22M83XbPmfUtDbDfUbr6u4RTJ6s3cPdWU5cKrPOD0b4DdAI3qUNVICqqNYxp6rn0NPOoSS7H8iY6/ZaC8UUZKRT9xDTSrDFR2Ty0fXFN6LpDg==; 24:PbthLJU4k4LJAjGjIBBAjWU6tVHrv48/dMAmoDEp3AgikIogVjqQj+iUgHVCf9XHH/ckmNmE2yCcdLn2R6VOBk7ZBBVzJs2TaSj+khTrrpY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1612; x-ms-office365-filtering-correlation-id: 66fa1095-67a0-4d82-a3e5-08d31b370f44 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:CY1PR0501MB1612; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1612; x-forefront-prvs: 081904387B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(479174004)(164054003)(199003)(189002)(13464003)(20264003)(51444003)(4326007)(5002640100001)(36756003)(97736004)(10400500002)(54356999)(19617315012)(189998001)(106356001)(5008740100001)(19580405001)(93886004)(2900100001)(3846002)(4001350100001)(5004730100002)(5001770100001)(106116001)(105586002)(11100500001)(586003)(16236675004)(1096002)(2950100001)(83506001)(81156007)(101416001)(5001960100002)(1220700001)(122556002)(77096005)(50986999)(76176999)(6116002)(40100003)(86362001)(15975445007)(66066001)(102836003)(99286002)(92566002)(575784001)(19580395003)(2906002)(87936001)(94096001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1612; H:CY1PR0501MB1609.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:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D2BA85E7D987ggrammeljunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2016 09:59:28.0961 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1612 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 10:00:00 -0000 --_000_D2BA85E7D987ggrammeljunipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Lada, Shortening the thread a bit, citing from your response: In fact, I think this intended-applied duality could be used for a sound de= finition of default contents: defaults would be present in applied but not = in intended config. This would eliminate the need for with-defaults. That=92s indeed what I am after. A lot of kludgy things could fall into the= ir place by applying intended/applied config sensibly. Default values are o= ne of them. Derived state of non-explicitly configured leafs (i.e. not part= of intended config) is another. That said, we consciously need to keep exi= sting models and implementation into account. IMO the overall guideline using intended vs. applied config should be: 1. Intended config is owned by the client and can only be modified by th= e client. A Server may reject an intended config only if it is syntacticall= y incorrect. 2. Applied config is owned by the server and can only be modified by the= server to reflect configuration changes or to apply intended config 3. A client has rwx access to intended config and r access to applied co= nfig (x meaning to request the server to apply it in a certain way) 4. A server has r accesss to intended config and rw access to applied co= nfig 5. If after attempting to apply the intended config there are still diff= erences between intended and applied, they shall be notified by the server = to the client 6. The client shall resolve the differences by either modifying the inte= nded config or by a maintenance action. In both cases, a difference is cons= idered temporary. With that guideline in mind, for a properly configured server, the intended= config is a true subset of the applied config with a 1:1 relationship. Gert From: Ladislav Lhotka > Date: Tuesday 12 January 2016 10:23 To: Gert Grammel >, Rober= t Wilton > Cc: "netmod@ietf.org" > Subject: RE: [netmod] applied configuration and system-controlled entries Gert Grammel > writes: -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka Sent: 11 January 2016 16:36 To: Robert Wilton Cc: netmod@ietf.org Subject: Re: [netmod] applied configuration and system-controlled entries On 11 Jan 2016, at 15:58, Robert Wilton > wrote: On 11/01/2016 14:27, Ladislav Lhotka wrote: On 11 Jan 2016, at 15:11, Juergen Schoenwaelder > wrote: On Mon, Jan 11, 2016 at 02:54:36PM +0100, Martin Bjorklund wrote: Ladislav Lhotka > wrote: Hi Gert, On 11 Jan 2016, at 14:25, Gert Grammel > wrote: Lada, The requirement says: D. When a configuration change for any intended configuration node has been successfully applied to the server (e.g. not failed, nor deferred due to absent hardware) then the existence and value of the corresponding applied configuration node must match the intended configuration node. I don't see that this would limit the case you described below. In your case there is no intended config, hence there is no "corresponding applied configuration" either. You are right, the requirement can be interpreted this way. I thought that applied configuration was supposed to be identical to intended after some synchronization period. This is a very important point to clarify. Can there ever be data in "applied" that is not in "intended"? I think Anees & Rob previously said "no", but I might be wrong. If there is time delay between editing intended and the applied config matching the edits of intended, then I supose this can happen (I delete a resource from intended but it is still around until intended has been fully synced). I would find it interesting if some edits are Using applied config for system-controlled entries would require that such an entry stays (forever) in applied config even after it has been deleted f= rom intended. I think that this would make life harder for clients. Hmm, I would say the opposite. For one, we could simplify the data models b= y reducing the duplicities in configuration and state trees. Let's look at a practical example and see if we can converge: 1) A Server is happily running with intended =3D=3D applied config and oper= ational state is aligned with intended config. 2) A new HW is plugged into that server and that HW has some kind of identi= fication number This can practically fall into 3 cases: a) it's a plug&play device and it is accepted to be used b) it's an accepted device but shall be configured prior to become operatio= nal c) it's considered a harmful (unplanned) event and the device shall be remo= ved In terms of a possible implementation, the event 1) would update the applied config which - among others - include the iden= tification number and update the operational state of that HW in line with = the applied config 2) Since the new applied config differs from the intended config, the clien= t is notified about the change 3) Upon inspection of the config change, the client decides how to deal wit= h the new item: a) accepting it the way it is: pushing down an intended config in line with the applied config information This shouldn't be necessary. Default values are also accepted as something the device operationally uses, but they needn't be copied to intended config. In fact, I think this intended-applied duality could be used for a sound definition of default contents: defaults would be present in applied but not in intended config. This would eliminate the need for with-defaults. Otherwise, your scenario looks good to me. Lada b) accepting it with modifications: pushing down a new intended config with additional leafs c) rejecting it: raising an alarm indicating the configuration mismatch, requiring manual intervention With the requirements as they are today, the client gives the intended conf= ig to the system, which it can monitor until the applied config matches the intended config. At this point it knows everything is good and the config = is fully applied. Over time, if everything is behaving as expected, the clien= t can reasonably expect that the applied configuration will always converge on th= e intended configuration. Which is the case above. By updating the intended config the client accepts= the config change. One could argue that leafs with default values are in applied configuration before they appear in intended. So my idea was to extend this to default entries of certain lists. Using applied config for system-controlled entries would break the simple logical relationship between intended and applied configuration, since ther= e are now some special entries for which this rule does not always apply. Don't get to the same conclusion, see above. The introduction of applied configuration would mean significant complications to all protocols, and perhaps even to YANG (although I'd hope not). Solving only the synchonicity issue with it is IMO insufficient payof= f for all the troubles. Don't see this either. Lada always assumed to be synchronous but others may be asynchronous. And Lada, I think applied may happen to be never identical to intended if, for example, hardware is absent or other missing resources prevent certain parts of intended to become applied. Yes, this is the use case of pre-provisioning, which is important, too, but= in fact opposite: the question here is whether applied can contain stuff that'= s not (and never been) in intended. I think that the answer is basically no, unless it is an error condition an= d it is representing configuration that should be deleted. Thanks, Rob Lada My understanding is that applied config in general forms an extended subset of intended config. And to fully understand what a device is doing, I may need to obtain its entire operational state since the applied config may not include state obtained dynamically from other sources. But I might still all be wrong... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod . -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C --_000_D2BA85E7D987ggrammeljunipernet_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Lada,

Shortening the thread a bit, citing from your response:
In fact, I think this intended-applied duality could be used for a sou= nd definition of default contents: defaults would be present in applied but= not in intended config. This would eliminate the need for with-defaults.

That=92s indeed what I am after. A lot of kludgy things could fall int= o their place by applying intended/applied config sensibly. Default values = are one of them. Derived state of non-explicitly configured leafs (i.e. not= part of intended config) is another. That said, we consciously need to keep existing models and implementation = into account.

IMO the overall guideline using intended vs. applied config should be:=
  1. Intended config is owned by the client and can only be modified by the = client. A Server may reject an intended config only if it is syntactically = incorrect.
  2. Applied config is owned by the server and can only be mo= dified by the server to reflect configuration changes or to apply intended = config
  3. A client has rwx access to intended config and r access to a= pplied config (x meaning to request the server to apply it in a certain way= )
  4. A server has r accesss to intended config and rw access to applie= d config
  5. If after attempting to apply the intended config there are= still differences between intended and applied, they shall be notified by = the server to the client
  6. The client shall resolve the differences b= y either modifying the intended config or by a maintenance action. In both = cases, a difference is considered temporary.
With that guideline in mind, for a properly configured server, the int= ended config is a true subset of the applied config with a 1:1 relationship= .

Gert

From: Ladislav Lhotka <lhotka@nic.cz>
Date: Tuesday 12 January 2016 10:23=
To: Gert Grammel <ggrammel@juniper.net>, Robert Wilton <<= a href=3D"mailto:rwilton@cisco.com">rwilton@cisco.com>
Cc: "netmod@ietf.org" <= netmod@ietf.org>
Subject: RE: [netmod] applied confi= guration and system-controlled entries

Gert Grammel <ggrammel@juni= per.net> writes:

-----Original Message-----
From: netmod [mailto:netmod= -bounces@ietf.org] On Behalf Of Ladislav Lhotka
Sent: 11 January 2016 16:36
To: Robert Wilton
Subject: Re: [netmod] applied configuration and system-controlled entr= ies


On 11 Jan 2016, at 15:58, Robert Wilton <rwilton@cisco.com> wrote:



On 11/01/2016 14:27, Ladislav Lhotka wrote:
On 11 Jan 2016, at 15:11, Juergen Schoenwaelder

On Mon, Jan 11, 2016 at 02:54:36PM +0100, Martin Bjorklund wrote:<= /div>
Ladislav Lhotka <lhotka@nic.cz= > wrote:
Hi Gert,

On 11 Jan 2016, at 14:25, Gert Grammel <ggrammel@juniper.net>
wrote:

Lada,

The requirement says:
      D.  When a configuration= change for any intended configuration
          node has b= een successfully applied to the server (e.g. not
          failed, no= r deferred due to absent hardware) then the
          existence = and value of the corresponding applied
          configurat= ion node must match the intended configuration
          node.

I don't see that this would limit the case you described below.
In your case there is no intended config, hence there is no
"corresponding applied configuration" either.
You are right, the requirement can be interpreted this way. I
thought that applied configuration was supposed to be identical to
intended after some synchronization period.
This is a very important point to clarify.  Can there ever b= e data
in "applied" that is not in "intended"?  = ;I think Anees & Rob
previously said "no", but I might be wrong.

If there is time delay between editing intended and the applied
config matching the edits of intended, then I supose this can happen
(I delete a resource from intended but it is still around until
intended has been fully synced). I would find it interesting if some
edits are
Using applied config for system-controlled entries would require that = such
an entry stays (forever) in applied config even after it has been dele= ted from
intended.
I think that this would make life harder for clients.

Hmm, I would say the opposite. For one, we could simplify the data mod= els by
reducing the duplicities in configuration and state trees.


Let's look at a practical example and see if we can converge:
1) A Server is happily running with intended =3D=3D applied config and= operational state is aligned with intended config.
2) A new HW is plugged into that server and that HW has some kind of i= dentification number

This can practically fall into 3 cases:
a) it's a plug&play device and it is accepted to be used
b) it's an accepted device but shall be configured prior to become ope= rational
c) it's considered a harmful (unplanned) event and the device shall be= removed

In terms of a possible implementation, the event
1) would update the applied config which -  among others - i= nclude the identification number and update the operational state of that H= W in line with the applied config
2) Since the new applied config differs from the intended config, the = client is notified about the change
3) Upon inspection of the config change, the client decides how to dea= l with the new item:

a) acc= epting it the way it is: pushing down an intended config
in lin= e with the applied config information

This shouldn't be necessary. Default values are also accepted as
something the device operationally uses, but they needn't be copied to=
intended config.

In fact, I think this intended-applied duality could be used for a sou= nd
definition of default contents: defaults would be present in applied b= ut
not in intended config. This would eliminate the need for with-default= s.

Otherwise, your scenario looks good to me.

Lada


b) acc= epting it with modifications: pushing down a new intended
config= with additional leafs
c) rej= ecting it: raising an alarm indicating the configuration
mismat= ch, requiring manual intervention


With the requirements as they are today, the client gives the intended= config
to the system, which it can monitor until the applied config matches t= he
intended config.  At this point it knows everything is good = and the config is
fully applied.  Over time, if everything is behaving as expe= cted, the client can
reasonably expect that the applied configuration will always converge = on the
intended configuration.

Which is the case above. By updating the intended config the client ac= cepts the config change.

One could argue that leafs with default values are in applied configur= ation
before they appear in intended. So my idea was to extend this to defau= lt
entries of certain lists.


Using applied config for system-controlled entries would break the sim= ple
logical relationship between intended and applied configuration, since= there
are now some special entries for which this rule does not always apply= .

Don't get to the same conclusion, see above.

The introduction of applied configuration would mean significant
complications to all protocols, and perhaps even to YANG (although I'd= hope
not). Solving only the synchonicity issue with it is IMO insufficient = payoff for all
the troubles.

Don't see this either.



Lada



always assumed to be synchronous but others may be asynchronous.

And Lada, I think applied may happen to be never identical to
intended if, for example, hardware is absent or other missing
resources prevent certain parts of intended to become applied.
Yes, this is the use case of pre-provisioning, which is important, too= , but in
fact opposite: the question here is whether applied can contain stuff = that's not
(and never been) in intended.

I think that the answer is basically no, unless it is an error conditi= on and it is
representing configuration that should be deleted.

Thanks,
Rob



Lada

My understanding is that applied config in general forms an extended
subset of intended config. And to fully understand what a device is
doing, I may need to obtain its entire operational state since the
applied config may not include state obtained dynamically from other
sources.

But I might still all be wrong...

/js

--
Juergen Schoenwaelder        &= nbsp;  Jacobs University Bremen gGmbH
Phone: +49 421 200 3587       &= nbsp; Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103     &nb= sp;   <http://www= .jacobs-university.de/>
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




_______________________________________________
netmod mailing list
.

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




_______________________________________________
netmod mailing list

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

 --_000_D2BA85E7D987ggrammeljunipernet_-- From nobody Tue Jan 12 02:12:22 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63D61A700B for ; Tue, 12 Jan 2016 02:12:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYJAH7AVY1gH for ; Tue, 12 Jan 2016 02:12:19 -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 9764B1A6FFA for ; Tue, 12 Jan 2016 02:12:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5328; q=dns/txt; s=iport; t=1452593538; x=1453803138; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=LijovfefV4XgLserXAlNzzvdrbAJ5b2mEzRhiT+v17U=; b=Q39JFVgLtIiaQWE7qiGjZ8mLtM74s6sPN3FKqYagdP8mXDob7ln9dZhN z812PHUXRIYr3jOC7NweAcfAVpysZQM20TEYI1R3fHTfTZIfwbh31tF4r vlY1r8QJDYy5srhXvXXXWMLeIuEy3zc1oYyS6nrED3I4+KBWXIBccB2Vg 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAQD/0JRW/xbLJq1ehHmIWbMvAQ2BZ?= =?us-ascii?q?oYPAoFbFAEBAQEBAQGBCoQ0AQEBAwE4QAEQCxAICRYPCQMCAQIBRQYBDAYCAQE?= =?us-ascii?q?VAogLCL9eAQEBAQEBAQEBAQEBAQEBAQEBG4ZWhH+EMQ2EfwEEh2GHEoggiDaFI?= =?us-ascii?q?4Feh0qFVIpgg3MgAQFCghEcgV0+NIRngUoBAQE?= X-IronPort-AV: E=Sophos;i="5.20,556,1444694400"; d="scan'208";a="631563881" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jan 2016 10:12:16 +0000 Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u0CACGW8017493; Tue, 12 Jan 2016 10:12:16 GMT To: Ladislav Lhotka , Martin Bjorklund References: <5693C32E.7020708@cisco.com> <31E9D485-9349-448D-99A3-DD20F5E5AF09@nic.cz> <20160111.211837.377848045119250710.mbj@tail-f.com> From: Robert Wilton Message-ID: <5694D180.6030300@cisco.com> Date: Tue, 12 Jan 2016 10:12:16 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 10:12:21 -0000 On 12/01/2016 09:05, Ladislav Lhotka wrote: > Martin Bjorklund writes: > >> Ladislav Lhotka wrote: >>>> On 11 Jan 2016, at 15:58, Robert Wilton wrote: >>>> >>>> >>>> >>>> On 11/01/2016 14:27, Ladislav Lhotka wrote: >>>>>> On 11 Jan 2016, at 15:11, Juergen Schoenwaelder >>>>>> wrote: >>>>>> >>>>>> On Mon, Jan 11, 2016 at 02:54:36PM +0100, Martin Bjorklund wrote: >>>>>>> Ladislav Lhotka wrote: >>>>>>>> Hi Gert, >>>>>>>> >>>>>>>>> On 11 Jan 2016, at 14:25, Gert Grammel wrote: >>>>>>>>> >>>>>>>>> Lada, >>>>>>>>> >>>>>>>>> The requirement says: >>>>>>>>> D. When a configuration change for any intended configuration >>>>>>>>> node has been successfully applied to the server (e.g. not >>>>>>>>> failed, nor deferred due to absent hardware) then the >>>>>>>>> existence and value of the corresponding applied >>>>>>>>> configuration node must match the intended configuration >>>>>>>>> node. >>>>>>>>> >>>>>>>>> I don't see that this would limit the case you described below. In >>>>>>>>> your case there is no intended config, hence there is no >>>>>>>>> "corresponding applied configuration" either. >>>>>>>> You are right, the requirement can be interpreted this way. I thought >>>>>>>> that applied configuration was supposed to be identical to intended >>>>>>>> after some synchronization period. >>>>>>> This is a very important point to clarify. Can there ever be data in >>>>>>> "applied" that is not in "intended"? I think Anees & Rob previously >>>>>>> said "no", but I might be wrong. >>>>>>> >>>>>> If there is time delay between editing intended and the applied config >>>>>> matching the edits of intended, then I supose this can happen (I >>>>>> delete a resource from intended but it is still around until intended >>>>>> has been fully synced). I would find it interesting if some edits are >>>>> Using applied config for system-controlled entries would require that >>>>> such an entry stays (forever) in applied config even after it has been >>>>> deleted from intended. >>>> I think that this would make life harder for clients. >>> Hmm, I would say the opposite. For one, we could simplify the data >>> models by reducing the duplicities in configuration and state trees. >> This is the old idea of having the "operational state" datastore, >> which would be all config true + all config false nodes. One issue >> with this is that the semantics of the node is different in the >> different data stores, even if the syntax (by definition!) is the >> same. In order to handle this properly you need either two different >> description statements, or two "sections" within the description >> statement. > I think this is not much different from default values. Leafs and > leaf-lists that have them defined in the data model may not be present > in intended config, yet one can consider them to be in applied config. I think that default values are logically just a way to make the configuration data more concise. I.e. everywhere you have a default value then the equivalent configuration could be expressed with a explicit value set instead. As such, I think that the default values apply equally to both the intended and applied configuration. If after a config request it takes time for the system to apply a default value, then ideally the applied configuration should have an explicit leaf to show what value is actually in effect until the default value has actually been applied in the system. This does open the question of how do you express the case that no value has been applied rather than a different value. For the opstate encoding solution draft that I put forward (or using meta-data), then I think that it would probably be possible to extend the encoding to explicitly include this information if required. Alternatively, and for the other proposed opstate solutions, then I expect that the most appropriate ideal semantics to handle this scenario would be to delay marking the parent object as being applied until every descendent child leaf with a default value set has a value applied in the system, either to the expected default value (in which case the child leaf wouldn't need to be present in the applied config), or transiently to another value (which would be in the applied config until the system updated and the correct default values have actually been applied). In real systems, I would have thought that the default values are often implicitly programmed when the parent containing object is created anyway, so I suspect that this behaviour wouldn't actually be that onerous to implement. Thanks, Rob > > Lada > >> list interface { >> description-config >> "The list of configured interfaces on the device. >> ..."; >> description-oper >> "The list of interfaces on the device. >> >> System-controlled interfaces created by the system are >> always present in this list, whether they are configured or >> not. >> ..."; >> } >> >> >> /martin From nobody Tue Jan 12 02:41:34 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2B51A8703 for ; Tue, 12 Jan 2016 02:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.652 X-Spam-Level: X-Spam-Status: No, score=-5.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSSWZyTOBf0g for ; Tue, 12 Jan 2016 02:41:31 -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 0FD871A86FA for ; Tue, 12 Jan 2016 02:41:30 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:1d89:22d0:490f:8894] (unknown [IPv6:2001:718:1a02:1:1d89:22d0:490f:8894]) by mail.nic.cz (Postfix) with ESMTPSA id E5141181A54; Tue, 12 Jan 2016 11:41:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452595288; bh=4g3B2z5uSBCj4gbmKP2QlS1wSa7s54/IvW02ce6rlto=; h=From:Date:To; b=eHPy9hhiC7/ifYXBagpdiKcODrp2PH3a6NQcoLrhW5CCITg+ddG9i9Gvqa/PRoEVb Xit49d/GWW3rTWd/qaitl9jvUw/JjV9KFGpfuG6Zth/jN9lOpH38TWaLe6izG79tVI tshpfD4P/8lCgF6iQMDiVlqqy+RKca2UdH2ktqE0= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <5694D180.6030300@cisco.com> Date: Tue, 12 Jan 2016 11:41:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5693C32E.7020708@cisco.com> <31E9D485-9349-448D-99A3-DD20F5E5AF09@nic.cz> <20160111.211837.377848045119250710.mbj@tail-f.com> <5694D180.6030300@cisco.com> To: Robert Wilton X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 10:41:34 -0000 > On 12 Jan 2016, at 11:12, Robert Wilton wrote: >=20 >=20 >=20 > On 12/01/2016 09:05, Ladislav Lhotka wrote: >> Martin Bjorklund writes: >>=20 >>> Ladislav Lhotka wrote: >>>>> On 11 Jan 2016, at 15:58, Robert Wilton wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 11/01/2016 14:27, Ladislav Lhotka wrote: >>>>>>> On 11 Jan 2016, at 15:11, Juergen Schoenwaelder >>>>>>> wrote: >>>>>>>=20 >>>>>>> On Mon, Jan 11, 2016 at 02:54:36PM +0100, Martin Bjorklund = wrote: >>>>>>>> Ladislav Lhotka wrote: >>>>>>>>> Hi Gert, >>>>>>>>>=20 >>>>>>>>>> On 11 Jan 2016, at 14:25, Gert Grammel = wrote: >>>>>>>>>>=20 >>>>>>>>>> Lada, >>>>>>>>>>=20 >>>>>>>>>> The requirement says: >>>>>>>>>> D. When a configuration change for any intended = configuration >>>>>>>>>> node has been successfully applied to the server = (e.g. not >>>>>>>>>> failed, nor deferred due to absent hardware) then = the >>>>>>>>>> existence and value of the corresponding applied >>>>>>>>>> configuration node must match the intended = configuration >>>>>>>>>> node. >>>>>>>>>>=20 >>>>>>>>>> I don't see that this would limit the case you described = below. In >>>>>>>>>> your case there is no intended config, hence there is no >>>>>>>>>> "corresponding applied configuration" either. >>>>>>>>> You are right, the requirement can be interpreted this way. I = thought >>>>>>>>> that applied configuration was supposed to be identical to = intended >>>>>>>>> after some synchronization period. >>>>>>>> This is a very important point to clarify. Can there ever be = data in >>>>>>>> "applied" that is not in "intended"? I think Anees & Rob = previously >>>>>>>> said "no", but I might be wrong. >>>>>>>>=20 >>>>>>> If there is time delay between editing intended and the applied = config >>>>>>> matching the edits of intended, then I supose this can happen (I >>>>>>> delete a resource from intended but it is still around until = intended >>>>>>> has been fully synced). I would find it interesting if some = edits are >>>>>> Using applied config for system-controlled entries would require = that >>>>>> such an entry stays (forever) in applied config even after it has = been >>>>>> deleted from intended. >>>>> I think that this would make life harder for clients. >>>> Hmm, I would say the opposite. For one, we could simplify the data >>>> models by reducing the duplicities in configuration and state = trees. >>> This is the old idea of having the "operational state" datastore, >>> which would be all config true + all config false nodes. One issue >>> with this is that the semantics of the node is different in the >>> different data stores, even if the syntax (by definition!) is the >>> same. In order to handle this properly you need either two = different >>> description statements, or two "sections" within the description >>> statement. >> I think this is not much different from default values. Leafs and >> leaf-lists that have them defined in the data model may not be = present >> in intended config, yet one can consider them to be in applied = config. > I think that default values are logically just a way to make the = configuration data more concise. I.e. everywhere you have a default = value then the equivalent configuration could be expressed with a = explicit value set instead. >=20 > As such, I think that the default values apply equally to both the = intended and applied configuration. It is useful if the operator is able to retrieve the parameter values = that the device is really using - which is the stated purpose of applied = config. There may also be vendor-specific defaults that aren't = documented in a data model, or defaults that are computed dynamically. >=20 > If after a config request it takes time for the system to apply a = default value, then ideally the applied configuration should have an = explicit leaf to show what value is actually in effect until the default = value has actually been applied in the system. My uderstanding is that default values come from the device so they = needn't be applied. For example, if an interface card is activated, it = will typically use some default values (e.g. MTU) without waiting for = any configuration. Lada=20 >=20 > This does open the question of how do you express the case that no = value has been applied rather than a different value. For the opstate = encoding solution draft that I put forward (or using meta-data), then I = think that it would probably be possible to extend the encoding to = explicitly include this information if required. >=20 > Alternatively, and for the other proposed opstate solutions, then I = expect that the most appropriate ideal semantics to handle this scenario = would be to delay marking the parent object as being applied until every = descendent child leaf with a default value set has a value applied in = the system, either to the expected default value (in which case the = child leaf wouldn't need to be present in the applied config), or = transiently to another value (which would be in the applied config until = the system updated and the correct default values have actually been = applied). In real systems, I would have thought that the default values = are often implicitly programmed when the parent containing object is = created anyway, so I suspect that this behaviour wouldn't actually be = that onerous to implement. >=20 > Thanks, > Rob >=20 >=20 >>=20 >> Lada >>=20 >>> list interface { >>> description-config >>> "The list of configured interfaces on the device. >>> ..."; >>> description-oper >>> "The list of interfaces on the device. >>> System-controlled interfaces created by the system = are >>> always present in this list, whether they are configured or >>> not. >>> ..."; >>> } >>>=20 >>>=20 >>> /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jan 12 02:43:01 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2B81A86FB for ; Tue, 12 Jan 2016 02:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5tuSe_LCSmT for ; Tue, 12 Jan 2016 02:42:51 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0758.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:758]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB67F1A8703 for ; Tue, 12 Jan 2016 02:42:50 -0800 (PST) Received: from CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) by CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) with Microsoft SMTP Server (TLS) id 15.1.361.13; Tue, 12 Jan 2016 10:42:33 +0000 Received: from CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) by CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) with mapi id 15.01.0361.006; Tue, 12 Jan 2016 10:42:33 +0000 From: Gert Grammel To: Robert Wilton , Ladislav Lhotka , "Martin Bjorklund" Thread-Topic: [netmod] applied configuration and system-controlled entries Thread-Index: AQHRSTUGxYtkEO44aUCWX59qiQKmfp72U6BggAAN6lSAAASVAIAACKQAgAAKfoCAAE7WgIAA1lGAgAASmgCAABk5AA== Date: Tue, 12 Jan 2016 10:42:33 +0000 Message-ID: References: <5693C32E.7020708@cisco.com> <31E9D485-9349-448D-99A3-DD20F5E5AF09@nic.cz> <20160111.211837.377848045119250710.mbj@tail-f.com> <5694D180.6030300@cisco.com> In-Reply-To: <5694D180.6030300@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [193.110.55.13] x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1609; 5:J9twaH98gWXu7lpX94WdPban9ve5qY22bIWQVT4uOF5P+gojDXqosJJdv3teOBEbjNhGsHjle5bUqTZDLhcc2gM5wxir/IsEl+FVnHeL3Q//wWFSq+TE6m73KbLkmr/fBZNQaeQiZtHULfmXQxVS6w==; 24:I5ZdilIrwRIzndGxkR6uFbx6ARHNazu9EEzt1WfRcaqhJgKrCp+e4JOnvD7rachCJstyEHbqkjUfwIkgcQBokhp1OD7xY/OCOOmnghfgvrc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1609; x-ms-office365-filtering-correlation-id: f8e967f1-be97-4497-c59a-08d31b3d1473 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:CY1PR0501MB1609; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1609; x-forefront-prvs: 081904387B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(377424004)(199003)(24454002)(51444003)(164054003)(52314003)(479174004)(586003)(83506001)(19580395003)(2950100001)(5001960100002)(5004730100002)(19580405001)(76176999)(189998001)(5008740100001)(2900100001)(66066001)(81156007)(50986999)(87936001)(92566002)(11100500001)(5001770100001)(105586002)(4001350100001)(101416001)(99286002)(1096002)(122556002)(102836003)(54356999)(36756003)(97736004)(15975445007)(93886004)(86362001)(10400500002)(40100003)(1220700001)(4326007)(6116002)(2906002)(106356001)(106116001)(5002640100001)(3846002)(77096005)(94096001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1609; H:CY1PR0501MB1609.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:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-ID: <6CBD5EF4C24C8446BF2D2B83856889B4@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2016 10:42:33.8520 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1609 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 10:42:58 -0000 On 2016-12-01 11:12, "netmod on behalf of Robert Wilton" wrote: > > >On 12/01/2016 09:05, Ladislav Lhotka wrote: >> Martin Bjorklund writes: >> >>> Ladislav Lhotka wrote: >>>>> On 11 Jan 2016, at 15:58, Robert Wilton wrote: >>>>> >>>>> >>>>> >>>>> On 11/01/2016 14:27, Ladislav Lhotka wrote: >>>>>>> On 11 Jan 2016, at 15:11, Juergen Schoenwaelder >>>>>>> wrote: >>>>>>> >>>>>>> On Mon, Jan 11, 2016 at 02:54:36PM +0100, Martin Bjorklund wrote: >>>>>>>> Ladislav Lhotka wrote: >>>>>>>>> Hi Gert, >>>>>>>>> >>>>>>>>>> On 11 Jan 2016, at 14:25, Gert Grammel >>>>>>>>>>wrote: >>>>>>>>>> >>>>>>>>>> Lada, >>>>>>>>>> >>>>>>>>>> The requirement says: >>>>>>>>>> D. When a configuration change for any intended >>>>>>>>>>configuration >>>>>>>>>> node has been successfully applied to the server >>>>>>>>>>(e.g. not >>>>>>>>>> failed, nor deferred due to absent hardware) then the >>>>>>>>>> existence and value of the corresponding applied >>>>>>>>>> configuration node must match the intended >>>>>>>>>>configuration >>>>>>>>>> node. >>>>>>>>>> >>>>>>>>>> I don't see that this would limit the case you described below. >>>>>>>>>>In >>>>>>>>>> your case there is no intended config, hence there is no >>>>>>>>>> "corresponding applied configuration" either. >>>>>>>>> You are right, the requirement can be interpreted this way. I >>>>>>>>>thought >>>>>>>>> that applied configuration was supposed to be identical to >>>>>>>>>intended >>>>>>>>> after some synchronization period. >>>>>>>> This is a very important point to clarify. Can there ever be >>>>>>>>data in >>>>>>>> "applied" that is not in "intended"? I think Anees & Rob >>>>>>>>previously >>>>>>>> said "no", but I might be wrong. >>>>>>>> >>>>>>> If there is time delay between editing intended and the applied >>>>>>>config >>>>>>> matching the edits of intended, then I supose this can happen (I >>>>>>> delete a resource from intended but it is still around until >>>>>>>intended >>>>>>> has been fully synced). I would find it interesting if some edits >>>>>>>are >>>>>> Using applied config for system-controlled entries would require >>>>>>that >>>>>> such an entry stays (forever) in applied config even after it has >>>>>>been >>>>>> deleted from intended. >>>>> I think that this would make life harder for clients. >>>> Hmm, I would say the opposite. For one, we could simplify the data >>>> models by reducing the duplicities in configuration and state trees. >>> This is the old idea of having the "operational state" datastore, >>> which would be all config true + all config false nodes. One issue >>> with this is that the semantics of the node is different in the >>> different data stores, even if the syntax (by definition!) is the >>> same. In order to handle this properly you need either two different >>> description statements, or two "sections" within the description >>> statement. >> I think this is not much different from default values. Leafs and >> leaf-lists that have them defined in the data model may not be present >> in intended config, yet one can consider them to be in applied config. >I think that default values are logically just a way to make the >configuration data more concise. I.e. everywhere you have a default >value then the equivalent configuration could be expressed with a >explicit value set instead. I think default values are just what they are. A set of values on the server that have not been explicitly set by the client via intended-config. It is certainly possible to set default values in intended-config explicitly, but it is not strictly needed. > >As such, I think that the default values apply equally to both the >intended and applied configuration. While this is allowed (see above), I would consider default values apply in practice to the applied config > >If after a config request it takes time for the system to apply a >default value, then ideally the applied configuration should have an >explicit leaf to show what value is actually in effect until the default >value has actually been applied in the system. If the client has an indication whether the configuration application is finished (with or without errors), it knows that the applied config is now stable to be read. Reading applied config during an operation should be avoided. Hence I would question the need for a per-leaf state and advocate for a per-server state. > >This does open the question of how do you express the case that no value >has been applied rather than a different value. For the opstate >encoding solution draft that I put forward (or using meta-data), then I >think that it would probably be possible to extend the encoding to >explicitly include this information if required. Perhaps I am missing something here. If the value supposed to be applied is the same that already exists, just skip it in the server. > >Alternatively, and for the other proposed opstate solutions, then I >expect that the most appropriate ideal semantics to handle this scenario >would be to delay marking the parent object as being applied until every >descendent child leaf with a default value set has a value applied in >the system, either to the expected default value (in which case the >child leaf wouldn't need to be present in the applied config), or >transiently to another value (which would be in the applied config until >the system updated and the correct default values have actually been >applied). In real systems, I would have thought that the default values >are often implicitly programmed when the parent containing object is >created anyway, so I suspect that this behaviour wouldn't actually be >that onerous to implement. It appears to me that we run into those issues by requiring the intended config to contain also the default values. That doesn=B9t seem necessary. I would also argue that marking the =8Capplied=3Dintended=B9 state per leaf i= s counter-productive. Assume the client sets an intended state of two values (A,B) on two different leafs with rollback-on-error semantic. If applying A succeeds and the client reads the applied state while applying B is still in progress, a rollback may still happen. That would invalidate the previous value of A. In other words it is unwise to read data from a source while it is actually writing. > >Thanks, >Rob > > >> >> Lada >> >>> list interface { >>> description-config >>> "The list of configured interfaces on the device. >>> ..."; >>> description-oper >>> "The list of interfaces on the device. >>> =20 >>> System-controlled interfaces created by the system are >>> always present in this list, whether they are configured or >>> not. >>> ..."; >>> } >>> >>> >>> /martin > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Jan 12 05:29:51 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1587F1AD2D9 for ; Tue, 12 Jan 2016 05:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRZ19OD-0TT6 for ; Tue, 12 Jan 2016 05:29:47 -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 770C31AD291 for ; Tue, 12 Jan 2016 05:29:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7836; q=dns/txt; s=iport; t=1452605387; x=1453814987; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=ii/CFWmGchavpO6JUHUT90LBC3dvnHZ4WD0zg3UkVm8=; b=CNV9JTRspcDhAdehT8DlJdLskjckm8Qb4ZJYeMyXQJVs/slX8FkZ6V+b IXcjz+o+UgeReTrdQ/coOyS9MjuhZf1eeSi17rcdqKG/RgbNRLQbfq1et iGHn079CvIPBnz21uv/Zbg0kns2k08R5yXEZAXq++wcDM8bMZDcVi1K1F 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqBAAz/5RW/xbLJq1ehHmIWbURhg8Cg?= =?us-ascii?q?XEBAQEBAQGBC4Q0AQEBAwE4QAEQCxAICRYPCQMCAQIBRQYNBgIBARUCiAsIv2M?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBARyGVoR/hDENhH8BBIdhhxKIIIg2hSOBXodKhVSKY?= =?us-ascii?q?INzZIIRHIFdPjSEZ4FKAQEB?= X-IronPort-AV: E=Sophos;i="5.20,557,1444694400"; d="scan'208";a="623424816" 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; 12 Jan 2016 13:29:45 +0000 Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u0CDTiZr016736; Tue, 12 Jan 2016 13:29:45 GMT To: Ladislav Lhotka References: <5693C32E.7020708@cisco.com> <31E9D485-9349-448D-99A3-DD20F5E5AF09@nic.cz> <20160111.211837.377848045119250710.mbj@tail-f.com> <5694D180.6030300@cisco.com> From: Robert Wilton Message-ID: <5694FFCA.4020408@cisco.com> Date: Tue, 12 Jan 2016 13:29:46 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 13:29:50 -0000 On 12/01/2016 10:41, Ladislav Lhotka wrote: >> On 12 Jan 2016, at 11:12, Robert Wilton wrote: >> >> >> >> On 12/01/2016 09:05, Ladislav Lhotka wrote: >>> Martin Bjorklund writes: >>> >>>> Ladislav Lhotka wrote: >>>>>> On 11 Jan 2016, at 15:58, Robert Wilton wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 11/01/2016 14:27, Ladislav Lhotka wrote: >>>>>>>> On 11 Jan 2016, at 15:11, Juergen Schoenwaelder >>>>>>>> wrote: >>>>>>>> >>>>>>>> On Mon, Jan 11, 2016 at 02:54:36PM +0100, Martin Bjorklund wrote: >>>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>> Hi Gert, >>>>>>>>>> >>>>>>>>>>> On 11 Jan 2016, at 14:25, Gert Grammel wrote: >>>>>>>>>>> >>>>>>>>>>> Lada, >>>>>>>>>>> >>>>>>>>>>> The requirement says: >>>>>>>>>>> D. When a configuration change for any intended configuration >>>>>>>>>>> node has been successfully applied to the server (e.g. not >>>>>>>>>>> failed, nor deferred due to absent hardware) then the >>>>>>>>>>> existence and value of the corresponding applied >>>>>>>>>>> configuration node must match the intended configuration >>>>>>>>>>> node. >>>>>>>>>>> >>>>>>>>>>> I don't see that this would limit the case you described below. In >>>>>>>>>>> your case there is no intended config, hence there is no >>>>>>>>>>> "corresponding applied configuration" either. >>>>>>>>>> You are right, the requirement can be interpreted this way. I thought >>>>>>>>>> that applied configuration was supposed to be identical to intended >>>>>>>>>> after some synchronization period. >>>>>>>>> This is a very important point to clarify. Can there ever be data in >>>>>>>>> "applied" that is not in "intended"? I think Anees & Rob previously >>>>>>>>> said "no", but I might be wrong. >>>>>>>>> >>>>>>>> If there is time delay between editing intended and the applied config >>>>>>>> matching the edits of intended, then I supose this can happen (I >>>>>>>> delete a resource from intended but it is still around until intended >>>>>>>> has been fully synced). I would find it interesting if some edits are >>>>>>> Using applied config for system-controlled entries would require that >>>>>>> such an entry stays (forever) in applied config even after it has been >>>>>>> deleted from intended. >>>>>> I think that this would make life harder for clients. >>>>> Hmm, I would say the opposite. For one, we could simplify the data >>>>> models by reducing the duplicities in configuration and state trees. >>>> This is the old idea of having the "operational state" datastore, >>>> which would be all config true + all config false nodes. One issue >>>> with this is that the semantics of the node is different in the >>>> different data stores, even if the syntax (by definition!) is the >>>> same. In order to handle this properly you need either two different >>>> description statements, or two "sections" within the description >>>> statement. >>> I think this is not much different from default values. Leafs and >>> leaf-lists that have them defined in the data model may not be present >>> in intended config, yet one can consider them to be in applied config. >> I think that default values are logically just a way to make the configuration data more concise. I.e. everywhere you have a default value then the equivalent configuration could be expressed with a explicit value set instead. >> >> As such, I think that the default values apply equally to both the intended and applied configuration. > It is useful if the operator is able to retrieve the parameter values that the device is really using - which is the stated purpose of applied config. There may also be vendor-specific defaults that aren't documented in a data model, or defaults that are computed dynamically. OK, so in essence you are proposing that the intended and applied config nodes have different schemas, in that any default values in the YANG schema only apply to the leaves in the intended config schema and not the applied config schema. As such, because the applied config schema doesn't haven't default values in the schema it must report all values it is using. But if we were to do this, then I'm not entirely sure why you would keep default values in the intended configuration schema (other than backwards compatibility, and potentially for documentation purposes)? Personally, I think that default values are a useful way to simply and shorten the configuration data set, but arguably this can apply equally to both intended and applied configuration. For me, the main argument for not allowing default values in the applied config is because of the difficultly for the server to differentiate between a leaf that hasn't been applied at all (e.g. for an optional feature) and the same leaf that is applied with the default value. I.e. I think that the applied configuration nodes already solve the problem of the device defaults not matching the configuration schema, since these differences should be reported in the applied configuration (or alternatively as deviations to the original schema that is being supported). >> If after a config request it takes time for the system to apply a default value, then ideally the applied configuration should have an explicit leaf to show what value is actually in effect until the default value has actually been applied in the system. > My uderstanding is that default values come from the device so they needn't be applied. For example, if an interface card is activated, it will typically use some default values (e.g. MTU) without waiting for any configuration. Yes. But if the default values that are actually being used by the device don't match the implicitly expected value from leaf defaults then these should be reported in the applied configuration with the value set to the actual applied value. Thanks, Rob > > Lada > >> This does open the question of how do you express the case that no value has been applied rather than a different value. For the opstate encoding solution draft that I put forward (or using meta-data), then I think that it would probably be possible to extend the encoding to explicitly include this information if required. >> >> Alternatively, and for the other proposed opstate solutions, then I expect that the most appropriate ideal semantics to handle this scenario would be to delay marking the parent object as being applied until every descendent child leaf with a default value set has a value applied in the system, either to the expected default value (in which case the child leaf wouldn't need to be present in the applied config), or transiently to another value (which would be in the applied config until the system updated and the correct default values have actually been applied). In real systems, I would have thought that the default values are often implicitly programmed when the parent containing object is created anyway, so I suspect that this behaviour wouldn't actually be that onerous to implement. >> >> Thanks, >> Rob >> >> >>> Lada >>> >>>> list interface { >>>> description-config >>>> "The list of configured interfaces on the device. >>>> ..."; >>>> description-oper >>>> "The list of interfaces on the device. >>>> System-controlled interfaces created by the system are >>>> always present in this list, whether they are configured or >>>> not. >>>> ..."; >>>> } >>>> >>>> >>>> /martin > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > . > From nobody Tue Jan 12 06:04:56 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAED1B29F7 for ; Tue, 12 Jan 2016 06:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmLNKvSMmkYi for ; Tue, 12 Jan 2016 06:04:52 -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 679D51B2A2A for ; Tue, 12 Jan 2016 06:04:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9939; q=dns/txt; s=iport; t=1452607484; x=1453817084; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=bEWxB2fnhmqx3C+ubrMxGAG6iBWGoZAmLuXS4U29ZHM=; b=Q0x3lH2s5P+2v1BUqbOMC8D3gMeNQaVPJXZkEx4RyvgznMWfEClpabWw ipuxtfhS7QuHWB0LXAluANqOsf6Rqj7V9c/qtlf9927bQkieZBZaImIn8 U9CuhxEnMoVQKjfy+yYGgsOgwsPFFbt0X4oxKPnkJJEsiqbQw103AMUtK Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQAfB5VW/xbLJq1ehAxtiFmzHgENg?= =?us-ascii?q?WYYCoUjSgKBXhQBAQEBAQEBgQqENAEBAQMBAQEBLwEFNgoBBQsLDgIICRYPCQM?= =?us-ascii?q?CAQIBFTAGAQwGAgEBFQKICwgOv1cBAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZWh?= =?us-ascii?q?H+EMQ2EfwEEh2GHEoggiDaFI4FehEODByOFMYpgg3MgAQFCghEcgV0+NIRmAR8?= =?us-ascii?q?EgScBAQE?= X-IronPort-AV: E=Sophos;i="5.20,557,1444694400"; d="scan'208";a="648446381" 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 2016 14:04:41 +0000 Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u0CE4eZK026656; Tue, 12 Jan 2016 14:04:40 GMT To: Gert Grammel , Ladislav Lhotka , Martin Bjorklund References: <5693C32E.7020708@cisco.com> <31E9D485-9349-448D-99A3-DD20F5E5AF09@nic.cz> <20160111.211837.377848045119250710.mbj@tail-f.com> <5694D180.6030300@cisco.com> From: Robert Wilton Message-ID: <569507FA.1070805@cisco.com> Date: Tue, 12 Jan 2016 14:04:42 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 14:04:54 -0000 On 12/01/2016 10:42, Gert Grammel wrote: > > On 2016-12-01 11:12, "netmod on behalf of Robert Wilton" > wrote: > >> >> On 12/01/2016 09:05, Ladislav Lhotka wrote: >>> Martin Bjorklund writes: >>> >>>> Ladislav Lhotka wrote: >>>>>> On 11 Jan 2016, at 15:58, Robert Wilton wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 11/01/2016 14:27, Ladislav Lhotka wrote: >>>>>>>> On 11 Jan 2016, at 15:11, Juergen Schoenwaelder >>>>>>>> wrote: >>>>>>>> >>>>>>>> On Mon, Jan 11, 2016 at 02:54:36PM +0100, Martin Bjorklund wrote: >>>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>> Hi Gert, >>>>>>>>>> >>>>>>>>>>> On 11 Jan 2016, at 14:25, Gert Grammel >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Lada, >>>>>>>>>>> >>>>>>>>>>> The requirement says: >>>>>>>>>>> D. When a configuration change for any intended >>>>>>>>>>> configuration >>>>>>>>>>> node has been successfully applied to the server >>>>>>>>>>> (e.g. not >>>>>>>>>>> failed, nor deferred due to absent hardware) then the >>>>>>>>>>> existence and value of the corresponding applied >>>>>>>>>>> configuration node must match the intended >>>>>>>>>>> configuration >>>>>>>>>>> node. >>>>>>>>>>> >>>>>>>>>>> I don't see that this would limit the case you described below. >>>>>>>>>>> In >>>>>>>>>>> your case there is no intended config, hence there is no >>>>>>>>>>> "corresponding applied configuration" either. >>>>>>>>>> You are right, the requirement can be interpreted this way. I >>>>>>>>>> thought >>>>>>>>>> that applied configuration was supposed to be identical to >>>>>>>>>> intended >>>>>>>>>> after some synchronization period. >>>>>>>>> This is a very important point to clarify. Can there ever be >>>>>>>>> data in >>>>>>>>> "applied" that is not in "intended"? I think Anees & Rob >>>>>>>>> previously >>>>>>>>> said "no", but I might be wrong. >>>>>>>>> >>>>>>>> If there is time delay between editing intended and the applied >>>>>>>> config >>>>>>>> matching the edits of intended, then I supose this can happen (I >>>>>>>> delete a resource from intended but it is still around until >>>>>>>> intended >>>>>>>> has been fully synced). I would find it interesting if some edits >>>>>>>> are >>>>>>> Using applied config for system-controlled entries would require >>>>>>> that >>>>>>> such an entry stays (forever) in applied config even after it has >>>>>>> been >>>>>>> deleted from intended. >>>>>> I think that this would make life harder for clients. >>>>> Hmm, I would say the opposite. For one, we could simplify the data >>>>> models by reducing the duplicities in configuration and state trees. >>>> This is the old idea of having the "operational state" datastore, >>>> which would be all config true + all config false nodes. One issue >>>> with this is that the semantics of the node is different in the >>>> different data stores, even if the syntax (by definition!) is the >>>> same. In order to handle this properly you need either two different >>>> description statements, or two "sections" within the description >>>> statement. >>> I think this is not much different from default values. Leafs and >>> leaf-lists that have them defined in the data model may not be present >>> in intended config, yet one can consider them to be in applied config. >> I think that default values are logically just a way to make the >> configuration data more concise. I.e. everywhere you have a default >> value then the equivalent configuration could be expressed with a >> explicit value set instead. > I think default values are just what they are. A set of values on the > server that have not been explicitly set by the client via > intended-config. The default values are determined by the schema and the intended configuration. You need to know both to know what default values the server is expected to use. But in terms of what is actually applied, an intended configuration with defaults values can be mapped into an equivalent intended configuration with all implicit defaults replaced by the equivalent explicit values. What gets applied in the device should be the same in both cases. > It is certainly possible to set default values in > intended-config explicitly, but it is not strictly needed. Yes, of course. >> As such, I think that the default values apply equally to both the >> intended and applied configuration. > While this is allowed (see above), I would consider default values apply > in practice to the applied config I think that I disagree on this point. The intended configuration is only complete when you consider its associated YANG schema and implicit default values. > >> If after a config request it takes time for the system to apply a >> default value, then ideally the applied configuration should have an >> explicit leaf to show what value is actually in effect until the default >> value has actually been applied in the system. > If the client has an indication whether the configuration application is > finished (with or without errors), it knows that the applied config is now > stable to be read. Reading applied config during an operation should be > avoided. Hence I would question the need for a per-leaf state and advocate > for a per-server state. I think that the whole purpose of the opstate requirements is that the operators effectively want to be able to track on a per leaf element rather than a per-server element. I might be wrong, but I think that the design being consider by the opstate operators is along the lines of an eventual consistent model. E.g. something along the lines of: At any point in time the operator knows what configuration state they would a device to be in (i.e. the intended configuration). Whenever the client changes their intended configuration, they push down the updated intended configuration to the device. The device starts applying the change (using the specified error handling semantics) They register for notification for changes to all intended/applied config and derived state on the device so that they have a feedback mechanism to know whether the configuration is being successfully applied. > >> This does open the question of how do you express the case that no value >> has been applied rather than a different value. For the opstate >> encoding solution draft that I put forward (or using meta-data), then I >> think that it would probably be possible to extend the encoding to >> explicitly include this information if required. > Perhaps I am missing something here. If the value supposed to be applied > is the same that already exists, just skip it in the server. The case I was considering is where the server has no value applied (e.g. for an optional feature) rather than the default value. >> Alternatively, and for the other proposed opstate solutions, then I >> expect that the most appropriate ideal semantics to handle this scenario >> would be to delay marking the parent object as being applied until every >> descendent child leaf with a default value set has a value applied in >> the system, either to the expected default value (in which case the >> child leaf wouldn't need to be present in the applied config), or >> transiently to another value (which would be in the applied config until >> the system updated and the correct default values have actually been >> applied). In real systems, I would have thought that the default values >> are often implicitly programmed when the parent containing object is >> created anyway, so I suspect that this behaviour wouldn't actually be >> that onerous to implement. > It appears to me that we run into those issues by requiring the intended > config to contain also the default values. That doesnt seem necessary. I I can't see how you can have default values apply only to the applied configuration and not the intended configuration. The intended configuration cannot be correctly interpreted if you don't also consider the default values specified in the schema. > would also argue that marking the applied=intended state per leaf is > counter-productive. Assume the client sets an intended state of two values Tracking intended vs applied on a per leaf basis is the essence of the opstate requirements, please lets not rehash these all yet again. :-) > (A,B) on two different leafs with rollback-on-error semantic. If applying > A succeeds and the client reads the applied state while applying B is > still in progress, a rollback may still happen. That would invalidate the > previous value of A. In other words it is unwise to read data from a > source while it is actually writing. No, this is fine, and isn't a problem. The server will eventually converge on a state and the client will be notified of that state. The fact that a client might temporarily see a valid state that is subsequently undone isn't a problem. Thanks, Rob > >> Thanks, >> Rob >> >> >>> Lada >>> >>>> list interface { >>>> description-config >>>> "The list of configured interfaces on the device. >>>> ..."; >>>> description-oper >>>> "The list of interfaces on the device. >>>> >>>> System-controlled interfaces created by the system are >>>> always present in this list, whether they are configured or >>>> not. >>>> ..."; >>>> } >>>> >>>> >>>> /martin >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Tue Jan 12 06:14:46 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE40C1AD363 for ; Tue, 12 Jan 2016 06:14:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.652 X-Spam-Level: X-Spam-Status: No, score=-5.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZXWtwbBD8m2 for ; Tue, 12 Jan 2016 06:14:41 -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 9BE3C1A86FD for ; Tue, 12 Jan 2016 06:14:40 -0800 (PST) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 3FCD118181C; Tue, 12 Jan 2016 15:14:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452608079; bh=slEmLwSUjSkPC76XXRH9Yr5YpyvFyfb6hBlmkdQ3Y18=; h=From:Date:To; b=LPR5QeuBDWT5YTefMEi0zUukBl2wOwav0ORfys8JbNld/EiRS8yZFmtG884lcqskL y7+UHjRWiG8mLQ8leiWhfCJC265jmmOuVmcThhsgQh4a0HzuF8QNBZD80L8kP88WeV fiJdblTG5LFbUokMGxMJAd5KMUZ1Lcrt13lwd4uU= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <5694FFCA.4020408@cisco.com> Date: Tue, 12 Jan 2016 15:14:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5693C32E.7020708@cisco.com> <31E9D485-9349-448D-99A3-DD20F5E5AF09@nic.cz> <20160111.211837.377848045119250710.mbj@tail-f.com> <5694D180.6030300@cisco.com> <5694FFCA.4020408@cisco.com> To: Robert Wilton X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 14:14:44 -0000 > On 12 Jan 2016, at 14:29, Robert Wilton wrote: >=20 >=20 >=20 > On 12/01/2016 10:41, Ladislav Lhotka wrote: >>> On 12 Jan 2016, at 11:12, Robert Wilton wrote: >>>=20 >>>=20 >>>=20 >>> On 12/01/2016 09:05, Ladislav Lhotka wrote: >>>> Martin Bjorklund writes: >>>>=20 >>>>> Ladislav Lhotka wrote: >>>>>>> On 11 Jan 2016, at 15:58, Robert Wilton = wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 11/01/2016 14:27, Ladislav Lhotka wrote: >>>>>>>>> On 11 Jan 2016, at 15:11, Juergen Schoenwaelder >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> On Mon, Jan 11, 2016 at 02:54:36PM +0100, Martin Bjorklund = wrote: >>>>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>>> Hi Gert, >>>>>>>>>>>=20 >>>>>>>>>>>> On 11 Jan 2016, at 14:25, Gert Grammel = wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> Lada, >>>>>>>>>>>>=20 >>>>>>>>>>>> The requirement says: >>>>>>>>>>>> D. When a configuration change for any intended = configuration >>>>>>>>>>>> node has been successfully applied to the server = (e.g. not >>>>>>>>>>>> failed, nor deferred due to absent hardware) then = the >>>>>>>>>>>> existence and value of the corresponding applied >>>>>>>>>>>> configuration node must match the intended = configuration >>>>>>>>>>>> node. >>>>>>>>>>>>=20 >>>>>>>>>>>> I don't see that this would limit the case you described = below. In >>>>>>>>>>>> your case there is no intended config, hence there is no >>>>>>>>>>>> "corresponding applied configuration" either. >>>>>>>>>>> You are right, the requirement can be interpreted this way. = I thought >>>>>>>>>>> that applied configuration was supposed to be identical to = intended >>>>>>>>>>> after some synchronization period. >>>>>>>>>> This is a very important point to clarify. Can there ever be = data in >>>>>>>>>> "applied" that is not in "intended"? I think Anees & Rob = previously >>>>>>>>>> said "no", but I might be wrong. >>>>>>>>>>=20 >>>>>>>>> If there is time delay between editing intended and the = applied config >>>>>>>>> matching the edits of intended, then I supose this can happen = (I >>>>>>>>> delete a resource from intended but it is still around until = intended >>>>>>>>> has been fully synced). I would find it interesting if some = edits are >>>>>>>> Using applied config for system-controlled entries would = require that >>>>>>>> such an entry stays (forever) in applied config even after it = has been >>>>>>>> deleted from intended. >>>>>>> I think that this would make life harder for clients. >>>>>> Hmm, I would say the opposite. For one, we could simplify the = data >>>>>> models by reducing the duplicities in configuration and state = trees. >>>>> This is the old idea of having the "operational state" datastore, >>>>> which would be all config true + all config false nodes. One = issue >>>>> with this is that the semantics of the node is different in the >>>>> different data stores, even if the syntax (by definition!) is the >>>>> same. In order to handle this properly you need either two = different >>>>> description statements, or two "sections" within the description >>>>> statement. >>>> I think this is not much different from default values. Leafs and >>>> leaf-lists that have them defined in the data model may not be = present >>>> in intended config, yet one can consider them to be in applied = config. >>> I think that default values are logically just a way to make the = configuration data more concise. I.e. everywhere you have a default = value then the equivalent configuration could be expressed with a = explicit value set instead. >>>=20 >>> As such, I think that the default values apply equally to both the = intended and applied configuration. >> It is useful if the operator is able to retrieve the parameter values = that the device is really using - which is the stated purpose of applied = config. There may also be vendor-specific defaults that aren't = documented in a data model, or defaults that are computed dynamically. > OK, so in essence you are proposing that the intended and applied = config nodes have different schemas, in that any default values in the = YANG schema only apply to the leaves in the intended config schema and = not the applied config schema. As such, because the applied config = schema doesn't haven't default values in the schema it must report all = values it is using. Yes. Whether it makes the schema different depends on the definition of = schema. In any case, this differentiation wouldn't be noticeable in YANG = modules, it is just semantics of intended and applied configurations. >=20 > But if we were to do this, then I'm not entirely sure why you would = keep default values in the intended configuration schema (other than = backwards compatibility, and potentially for documentation purposes)? Defaults have to be documented somewhere so that the client knows what = values will be used if they are omitted in the intended config. >=20 > Personally, I think that default values are a useful way to simply and = shorten the configuration data set, but arguably this can apply equally = to both intended and applied configuration. For me, the main argument = for not allowing default values in the applied config is because of the = difficultly for the server to differentiate between a leaf that hasn't = been applied at all (e.g. for an optional feature) and the same leaf = that is applied with the default value. Defaults serve two purposes: (1) they save clients from writing all = parameters explicitly, and (2) they make server's output more readable = by suppressing some (presumably uninteresting) information. Requiring = all defaults explicitly in applied config goes partly against #2, but on = the other hand it is also important to be able learn (somehow) what = values the device really uses. >=20 > I.e. I think that the applied configuration nodes already solve the = problem of the device defaults not matching the configuration schema, = since these differences should be reported in the applied configuration = (or alternatively as deviations to the original schema that is being = supported). Only in an ideal world. Defaults may sometimes change, and what's in the = data model may not be in sync what the device really uses. Not being = able to learn the truth is frustrating. Lada >=20 >>> If after a config request it takes time for the system to apply a = default value, then ideally the applied configuration should have an = explicit leaf to show what value is actually in effect until the default = value has actually been applied in the system. >> My uderstanding is that default values come from the device so they = needn't be applied. For example, if an interface card is activated, it = will typically use some default values (e.g. MTU) without waiting for = any configuration. >=20 > Yes. But if the default values that are actually being used by the = device don't match the implicitly expected value from leaf defaults then = these should be reported in the applied configuration with the value set = to the actual applied value. >=20 > Thanks, > Rob >=20 >=20 >>=20 >> Lada >>=20 >>> This does open the question of how do you express the case that no = value has been applied rather than a different value. For the opstate = encoding solution draft that I put forward (or using meta-data), then I = think that it would probably be possible to extend the encoding to = explicitly include this information if required. >>>=20 >>> Alternatively, and for the other proposed opstate solutions, then I = expect that the most appropriate ideal semantics to handle this scenario = would be to delay marking the parent object as being applied until every = descendent child leaf with a default value set has a value applied in = the system, either to the expected default value (in which case the = child leaf wouldn't need to be present in the applied config), or = transiently to another value (which would be in the applied config until = the system updated and the correct default values have actually been = applied). In real systems, I would have thought that the default values = are often implicitly programmed when the parent containing object is = created anyway, so I suspect that this behaviour wouldn't actually be = that onerous to implement. >>>=20 >>> Thanks, >>> Rob >>>=20 >>>=20 >>>> Lada >>>>=20 >>>>> list interface { >>>>> description-config >>>>> "The list of configured interfaces on the device. >>>>> ..."; >>>>> description-oper >>>>> "The list of interfaces on the device. >>>>> System-controlled interfaces created by the = system are >>>>> always present in this list, whether they are configured = or >>>>> not. >>>>> ..."; >>>>> } >>>>>=20 >>>>>=20 >>>>> /martin >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> . -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jan 12 07:29:18 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277921B2AA9 for ; Tue, 12 Jan 2016 07:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.909 X-Spam-Level: X-Spam-Status: No, score=-12.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7bLHCu7w8e0 for ; Tue, 12 Jan 2016 07:29:15 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 809521A0187 for ; Tue, 12 Jan 2016 07:29:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6682; q=dns/txt; s=iport; t=1452612555; x=1453822155; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=Zp7hd68cjah2M+R+hbMpy3ikb/y8ySeyTftzashhopU=; b=iPVAGBau/nctEVmfYpGIIK8NEjrv6dIvJ3Y32Vd1c8XBYNs7i0BpI0hD 9X2DpMBwHE62hEY1iPIvwdWw3utpv7AGAIQ15l9P5HVYwBESiaoZRvRo5 4XdK9XqRO0MKlC+vE26KdYm28qy01q3fvrIYgi1qNrsz6Iom3IOVM4Gkf 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALAgA/G5VW/4UNJK1eToJsihizIwENg?= =?us-ascii?q?WaGDwKBJTgUAQEBAQEBAYEKhDUBAQMBI1URCw4TFgsCAgkDAgECAUUGAQwIAQE?= =?us-ascii?q?XiAsIr0mQLwEBAQEBAQEDAQEBAQEBAQEbhlaEf4d0gUkFlxONWYFeh0ojhTGOU?= =?us-ascii?q?yABAUKECz2GZQEBAQ?= X-IronPort-AV: E=Sophos; i="5.20,558,1444694400"; d="scan'208,217"; a="62727717" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Jan 2016 15:29:14 +0000 Received: from [10.24.150.212] ([10.24.150.212]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u0CFT3ZD011677; Tue, 12 Jan 2016 15:29:09 GMT To: Kent Watsen , "netmod@ietf.org" References: <20160109005830.20805.41463.idtracker@ietfa.amsl.com> <5693E46D.7080707@cisco.com> <3474CCCD-1B8B-40B7-B3BF-C1164C144A8F@juniper.net> From: Benoit Claise Message-ID: <5694EC36.8010103@cisco.com> Date: Tue, 12 Jan 2016 13:06:14 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <3474CCCD-1B8B-40B7-B3BF-C1164C144A8F@juniper.net> Content-Type: multipart/alternative; boundary="------------050306030405070902000305" Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 15:29:17 -0000 This is a multi-part message in MIME format. --------------050306030405070902000305 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Kent, [btw, speaking as a contributor] > Hi Benoit, > > >> You use MUST, SHOULD, MAY, and you refer to RFC 2119. Fine. >> However, it might be beneficial to say something such as in RFC 7698 >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >> document are to be interpreted as described in [RFC2119]. >> >> While [RFC2119] describes interpretations of these key words in terms >> of protocol specifications and implementations, they are used in this >> document to describe design requirements for protocol extensions. > Is this needed? Looking at RFC2119, I don’t read it as being very particular about the context it’s terms are used in. > > Additionally, other requirements docs use RFC2119 without any such a paragraph (e.g., RFC7698, RFC7497, RFC7449, etc.)... Yes, I've seen those RFCs. The IETF is not really consistent regarding RFC 2119 and requirement documents. So I wanted to put the issue on the table. No strong view on way or the other. > > >> Btw, I never quite understood what a MAY means for a requirement. >> See requirement 2B and 2C > For 2B, would you rather is be a SHOULD? > For 2C, would you rather this be a “may”? > > FWIW, the other requirements docs listed above also use "MAY" in some of their “requirements" I saw that. Changing the MAY keywords the way you proposed is one solution, but more importantly, you should tell us what is intent behind a MAY sentence is. From 2119: 5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) So it means that the specified solution MAY or MAY not have this functionality, right? So what is the requirement? Maybe it's not a requirement, but just something to think about. Regards, Benoit > > > Kent > > --------------050306030405070902000305 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Kent,

[btw, speaking as a contributor]
Hi Benoit,



You use MUST, SHOULD, MAY, and you refer to RFC 2119. Fine.
However, it might be beneficial to say something such as in RFC 7698

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   While [RFC2119] describes interpretations of these key words in terms
   of protocol specifications and implementations, they are used in this
   document to describe design requirements for protocol extensions.

Is this needed?  Looking at RFC2119, I don’t read it as being very particular about the context it’s terms are used in.

Additionally, other requirements docs use RFC2119 without any such a paragraph (e.g., RFC7698, RFC7497, RFC7449, etc.)...
Yes, I've seen those RFCs. The IETF is not really consistent regarding RFC 2119 and requirement documents.
So I wanted to put the issue on the table. No strong view on way or the other.



Btw, I never quite understood what a MAY means for a requirement.
See requirement 2B and 2C

For 2B, would you rather is be a SHOULD?
For 2C, would you rather this be a “may”?

FWIW, the other requirements docs listed above also use "MAY" in some of their “requirements"
I saw that.
Changing the MAY keywords the way you proposed is one solution, but more importantly, you should tell us what is intent behind a MAY sentence is.
From 2119:
5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)
So it means that the specified solution MAY or MAY not have this functionality, right?
So what is the requirement? Maybe it's not a requirement, but just something to think about.

Regards, Benoit



Kent

--------------050306030405070902000305-- From nobody Tue Jan 12 07:39:18 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6C81B2A9F for ; Tue, 12 Jan 2016 07:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQCzBw1D2pvg for ; Tue, 12 Jan 2016 07:39:15 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 250E41B2AC2 for ; Tue, 12 Jan 2016 07:39:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1518; q=dns/txt; s=iport; t=1452613142; x=1453822742; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=0r21pNj0gmbiDB/SbNTenDYjhxMERCC6aH9mwET4uQk=; b=IKVcX2HA/RA4iVyfjU9YCPsgC2UziTaujzRc8OHjpI5KwanEWlFjC30g clRU9PE2urgnn9rQ5zCPK8kcIpHPOFQxcq2ticUvW+vkGn4d+l0TGIMw1 /R032dv4J0RMXW7FUimj83tVXeMkfQHxWV8+MYOS0ywiEq29N8LaKzkko o=; X-IronPort-AV: E=Sophos;i="5.20,558,1444694400"; d="scan'208";a="226453424" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jan 2016 15:39:01 +0000 Received: from [10.24.150.212] ([10.24.150.212]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u0CFcrSY003620; Tue, 12 Jan 2016 15:38:57 GMT To: Ladislav Lhotka , Robert Wilton References: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> <568E95B4.1070703@cisco.com> <568FD3B0.2020702@cisco.com> From: Benoit Claise Message-ID: <56951E08.7080507@cisco.com> Date: Tue, 12 Jan 2016 16:38:48 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: NETMOD WG Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 15:39:17 -0000 Lada, >> On 08 Jan 2016, at 16:20, Robert Wilton wrote: >> >> Hi Lada, >> >> On 08/01/2016 12:30, Ladislav Lhotka wrote: >>> Robert Wilton writes: >>> >>>> Hi Lada, >>>> >>>> I think that requirement 1D is fairly key to what is being asked for >>>> here to allow both the user and system to easily relate between what the >>>> operator desires and what configuration the system is actually using, >>> In a way, system-controlled interfaces are default entries in the >>> interface list - and the system can certainly be using interfaces with >>> no configuration installed by NETCONF/RESTCONF clients. >>> >>>> so I wouldn't be particularly keen on loosening this requirement. >>> OK, but then IMO this intended-applied dualism is of limited >>> utility. For many systems or services, asynchronicity is not an option, >>> or isn't important. >> I don't really agree. I think that this is plausibly important to anyone who wants to manage network devices in an automated way. > I am currently working with my colleagues on two use cases: > > 1. RESTCONF interface to a DNS server that will cover the daemon configuration, policies for zone signing, and zone provisioning. > > 2. RESTCONF interface to an OpenWRT-based router. > > For neither of them applied configuration seems to add any value. > Fair enough. However, it doesn't entail that the opstate has no value for anybody. Some operators have spoken loud and clear. Regards, Benoit From nobody Tue Jan 12 07:51:12 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83871B2AC6 for ; Tue, 12 Jan 2016 07:51:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WtvfimZEPRV for ; Tue, 12 Jan 2016 07:51:10 -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 3BF1B1B2ABB for ; Tue, 12 Jan 2016 07:51:10 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:1d89:22d0:490f:8894] (unknown [IPv6:2001:718:1a02:1:1d89:22d0:490f:8894]) by mail.nic.cz (Postfix) with ESMTPSA id 5D31A181526; Tue, 12 Jan 2016 16:51:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452613868; bh=mRthjB/WHpnK+glszrAztBiB+h9xDZoJxts1bfpx+B8=; h=From:Date:To; b=ZIAVJc9UpFj2CIkHM/mpaOGJ7yfe8QVebOSOoQyYqqwtEhD2WgbEDNhqHqBm+NnAn tgCrCdkU5rBS3/vSBfR0Uv+PyVxS503GHH2qDuQz1MfRYxs977z85XwCRcwKdz40fS tAX/T9ooBh5uzYFsWK88cX/6FqNxHGcOUxjaRW80= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <56951E08.7080507@cisco.com> Date: Tue, 12 Jan 2016 16:51:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5E335D62-2B0F-4EFC-89A7-C96AE5E14F37@nic.cz> <568E95B4.1070703@cisco.com> <568FD3B0.2020702@cisco.com> <56951E08.7080507@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: NETMOD WG Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 15:51:11 -0000 > On 12 Jan 2016, at 16:38, Benoit Claise wrote: >=20 > Lada, >>> On 08 Jan 2016, at 16:20, Robert Wilton wrote: >>>=20 >>> Hi Lada, >>>=20 >>> On 08/01/2016 12:30, Ladislav Lhotka wrote: >>>> Robert Wilton writes: >>>>=20 >>>>> Hi Lada, >>>>>=20 >>>>> I think that requirement 1D is fairly key to what is being asked = for >>>>> here to allow both the user and system to easily relate between = what the >>>>> operator desires and what configuration the system is actually = using, >>>> In a way, system-controlled interfaces are default entries in the >>>> interface list - and the system can certainly be using interfaces = with >>>> no configuration installed by NETCONF/RESTCONF clients. >>>>=20 >>>>> so I wouldn't be particularly keen on loosening this requirement. >>>> OK, but then IMO this intended-applied dualism is of limited >>>> utility. For many systems or services, asynchronicity is not an = option, >>>> or isn't important. >>> I don't really agree. I think that this is plausibly important to = anyone who wants to manage network devices in an automated way. >> I am currently working with my colleagues on two use cases: >>=20 >> 1. RESTCONF interface to a DNS server that will cover the daemon = configuration, policies for zone signing, and zone provisioning. >>=20 >> 2. RESTCONF interface to an OpenWRT-based router. >>=20 >> For neither of them applied configuration seems to add any value. >>=20 > Fair enough. However, it doesn't entail that the opstate has no value = for anybody. > Some operators have spoken loud and clear. Sure, what I wrote was: For many systems or services, asynchronicity is = not an option, or isn't important. Lada >=20 > Regards, Benoit >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Jan 12 08:03:19 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999F91B2ADF for ; Tue, 12 Jan 2016 08:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJgBRbkX8b3c for ; Tue, 12 Jan 2016 08:03:14 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0764.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:764]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84FF91B2ADE for ; Tue, 12 Jan 2016 08:03:13 -0800 (PST) Received: from CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) by CY1PR0501MB1610.namprd05.prod.outlook.com (10.161.162.139) with Microsoft SMTP Server (TLS) id 15.1.361.13; Tue, 12 Jan 2016 16:02:52 +0000 Received: from CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) by CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) with mapi id 15.01.0361.006; Tue, 12 Jan 2016 16:02:52 +0000 From: Gert Grammel To: Robert Wilton , Ladislav Lhotka , "Martin Bjorklund" Thread-Topic: [netmod] applied configuration and system-controlled entries Thread-Index: AQHRSTUGxYtkEO44aUCWX59qiQKmfp72U6BggAAN6lSAAASVAIAACKQAgAAKfoCAAE7WgIAA1lGAgAASmgCAABk5AIAAJ7gAgAAxxIA= Date: Tue, 12 Jan 2016 16:02:52 +0000 Message-ID: References: <5693C32E.7020708@cisco.com> <31E9D485-9349-448D-99A3-DD20F5E5AF09@nic.cz> <20160111.211837.377848045119250710.mbj@tail-f.com> <5694D180.6030300@cisco.com> <569507FA.1070805@cisco.com> In-Reply-To: <569507FA.1070805@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [193.110.55.13] x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1610; 5:VIHqEiKQ0i8Elz6r+30umq3fJOjvK/N7k2eXen9ARFQ8NywAfJ+uHjRtbS50DV+fGTNTVVnIm7e645DvpNPx6GnfWQihVqxT8xnHGG9O0P0zRi2J48nNsxClB2/oAXKViMIO8DVHUM47kTbFtGGseQ==; 24:joIRWj7sjqtak/kSEFAZlxiPtZVWACcrlFuJ3hWZDjeY9qOhx1cIlizt9sH3AoMjBYTI2qvlqLbmR8PxPbgdGmLkUShe4OY8Yfl1cMYYAXA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1610; x-ms-office365-filtering-correlation-id: 8b4678ec-5056-4d9b-1e8c-08d31b69d39e x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:CY1PR0501MB1610; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1610; x-forefront-prvs: 081904387B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377424004)(479174004)(52314003)(189002)(24454002)(164054003)(199003)(51444003)(97736004)(86362001)(106116001)(40100003)(99286002)(101416001)(93886004)(4001350100001)(122556002)(5002640100001)(87936001)(66066001)(5001770100001)(36756003)(106356001)(105586002)(19580405001)(81156007)(83506001)(92566002)(2906002)(3846002)(19580395003)(586003)(1096002)(4326007)(5008740100001)(2950100001)(2900100001)(5001960100002)(102836003)(189998001)(11100500001)(10400500002)(6116002)(54356999)(15975445007)(76176999)(1220700001)(77096005)(5004730100002)(50986999)(94096001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1610; H:CY1PR0501MB1609.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:23 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: 12 Jan 2016 16:02:52.1336 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1610 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 16:03:18 -0000 DQoNCk9uIDIwMTYtMTItMDEgMTU6MDQsICJSb2JlcnQgV2lsdG9uIiA8cndpbHRvbkBjaXNjby5j b20+IHdyb3RlOg0KDQo+DQo+DQo+T24gMTIvMDEvMjAxNiAxMDo0MiwgR2VydCBHcmFtbWVsIHdy b3RlOg0KPj4NCj4+IE9uIDIwMTYtMTItMDEgMTE6MTIsICJuZXRtb2Qgb24gYmVoYWxmIG9mIFJv YmVydCBXaWx0b24iDQo+PiA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHJ3 aWx0b25AY2lzY28uY29tPiB3cm90ZToNCj4+DQo+Pj4NCj4+PiBPbiAxMi8wMS8yMDE2IDA5OjA1 LCBMYWRpc2xhdiBMaG90a2Egd3JvdGU6DQo+Pj4+IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWls LWYuY29tPiB3cml0ZXM6DQo+Pj4+DQo+Pj4+PiBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBuaWMu Y3o+IHdyb3RlOg0KPj4+Pj4+PiBPbiAxMSBKYW4gMjAxNiwgYXQgMTU6NTgsIFJvYmVydCBXaWx0 b24gPHJ3aWx0b25AY2lzY28uY29tPiB3cm90ZToNCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4N Cj4+Pj4+Pj4gT24gMTEvMDEvMjAxNiAxNDoyNywgTGFkaXNsYXYgTGhvdGthIHdyb3RlOg0KPj4+ Pj4+Pj4+IE9uIDExIEphbiAyMDE2LCBhdCAxNToxMSwgSnVlcmdlbiBTY2hvZW53YWVsZGVyDQo+ Pj4+Pj4+Pj4gPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQo+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBPbiBNb24sIEphbiAxMSwgMjAxNiBhdCAwMjo1NDozNlBNICsw MTAwLCBNYXJ0aW4gQmpvcmtsdW5kIHdyb3RlOg0KPj4+Pj4+Pj4+PiBMYWRpc2xhdiBMaG90a2Eg PGxob3RrYUBuaWMuY3o+IHdyb3RlOg0KPj4+Pj4+Pj4+Pj4gSGkgR2VydCwNCj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+Pj4gT24gMTEgSmFuIDIwMTYsIGF0IDE0OjI1LCBHZXJ0IEdyYW1tZWwgPGdn cmFtbWVsQGp1bmlwZXIubmV0Pg0KPj4+Pj4+Pj4+Pj4+IHdyb3RlOg0KPj4+Pj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4+Pj4gTGFkYSwNCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IFRoZSByZXF1aXJl bWVudCBzYXlzOg0KPj4+Pj4+Pj4+Pj4+ICAgICAgICBELiAgV2hlbiBhIGNvbmZpZ3VyYXRpb24g Y2hhbmdlIGZvciBhbnkgaW50ZW5kZWQNCj4+Pj4+Pj4+Pj4+PiBjb25maWd1cmF0aW9uDQo+Pj4+ Pj4+Pj4+Pj4gICAgICAgICAgICBub2RlIGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBhcHBsaWVkIHRv IHRoZSBzZXJ2ZXINCj4+Pj4+Pj4+Pj4+PiAoZS5nLiBub3QNCj4+Pj4+Pj4+Pj4+PiAgICAgICAg ICAgIGZhaWxlZCwgbm9yIGRlZmVycmVkIGR1ZSB0byBhYnNlbnQgaGFyZHdhcmUpIHRoZW4NCj4+ Pj4+Pj4+Pj4+PnRoZQ0KPj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgZXhpc3RlbmNlIGFuZCB2YWx1 ZSBvZiB0aGUgY29ycmVzcG9uZGluZyBhcHBsaWVkDQo+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICBj b25maWd1cmF0aW9uIG5vZGUgbXVzdCBtYXRjaCB0aGUgaW50ZW5kZWQNCj4+Pj4+Pj4+Pj4+PiBj b25maWd1cmF0aW9uDQo+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICBub2RlLg0KPj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+Pj4gSSBkb24ndCBzZWUgdGhhdCB0aGlzIHdvdWxkIGxpbWl0IHRoZSBjYXNl IHlvdSBkZXNjcmliZWQNCj4+Pj4+Pj4+Pj4+PmJlbG93Lg0KPj4+Pj4+Pj4+Pj4+IEluDQo+Pj4+ Pj4+Pj4+Pj4geW91ciBjYXNlIHRoZXJlIGlzIG5vIGludGVuZGVkIGNvbmZpZywgaGVuY2UgdGhl cmUgaXMgbm8NCj4+Pj4+Pj4+Pj4+PiAiY29ycmVzcG9uZGluZyBhcHBsaWVkIGNvbmZpZ3VyYXRp b24iIGVpdGhlci4NCj4+Pj4+Pj4+Pj4+IFlvdSBhcmUgcmlnaHQsIHRoZSByZXF1aXJlbWVudCBj YW4gYmUgaW50ZXJwcmV0ZWQgdGhpcyB3YXkuIEkNCj4+Pj4+Pj4+Pj4+IHRob3VnaHQNCj4+Pj4+ Pj4+Pj4+IHRoYXQgYXBwbGllZCBjb25maWd1cmF0aW9uIHdhcyBzdXBwb3NlZCB0byBiZSBpZGVu dGljYWwgdG8NCj4+Pj4+Pj4+Pj4+IGludGVuZGVkDQo+Pj4+Pj4+Pj4+PiBhZnRlciBzb21lIHN5 bmNocm9uaXphdGlvbiBwZXJpb2QuDQo+Pj4+Pj4+Pj4+IFRoaXMgaXMgYSB2ZXJ5IGltcG9ydGFu dCBwb2ludCB0byBjbGFyaWZ5LiAgQ2FuIHRoZXJlIGV2ZXIgYmUNCj4+Pj4+Pj4+Pj4gZGF0YSBp bg0KPj4+Pj4+Pj4+PiAiYXBwbGllZCIgdGhhdCBpcyBub3QgaW4gImludGVuZGVkIj8gIEkgdGhp bmsgQW5lZXMgJiBSb2INCj4+Pj4+Pj4+Pj4gcHJldmlvdXNseQ0KPj4+Pj4+Pj4+PiBzYWlkICJu byIsIGJ1dCBJIG1pZ2h0IGJlIHdyb25nLg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IElmIHRoZXJl IGlzIHRpbWUgZGVsYXkgYmV0d2VlbiBlZGl0aW5nIGludGVuZGVkIGFuZCB0aGUgYXBwbGllZA0K Pj4+Pj4+Pj4+IGNvbmZpZw0KPj4+Pj4+Pj4+IG1hdGNoaW5nIHRoZSBlZGl0cyBvZiBpbnRlbmRl ZCwgdGhlbiBJIHN1cG9zZSB0aGlzIGNhbiBoYXBwZW4gKEkNCj4+Pj4+Pj4+PiBkZWxldGUgYSBy ZXNvdXJjZSBmcm9tIGludGVuZGVkIGJ1dCBpdCBpcyBzdGlsbCBhcm91bmQgdW50aWwNCj4+Pj4+ Pj4+PiBpbnRlbmRlZA0KPj4+Pj4+Pj4+IGhhcyBiZWVuIGZ1bGx5IHN5bmNlZCkuIEkgd291bGQg ZmluZCBpdCBpbnRlcmVzdGluZyBpZiBzb21lIGVkaXRzDQo+Pj4+Pj4+Pj4gYXJlDQo+Pj4+Pj4+ PiBVc2luZyBhcHBsaWVkIGNvbmZpZyBmb3Igc3lzdGVtLWNvbnRyb2xsZWQgZW50cmllcyB3b3Vs ZCByZXF1aXJlDQo+Pj4+Pj4+PiB0aGF0DQo+Pj4+Pj4+PiBzdWNoIGFuIGVudHJ5IHN0YXlzIChm b3JldmVyKSBpbiBhcHBsaWVkIGNvbmZpZyBldmVuIGFmdGVyIGl0IGhhcw0KPj4+Pj4+Pj4gYmVl bg0KPj4+Pj4+Pj4gZGVsZXRlZCBmcm9tIGludGVuZGVkLg0KPj4+Pj4+PiBJIHRoaW5rIHRoYXQg dGhpcyB3b3VsZCBtYWtlIGxpZmUgaGFyZGVyIGZvciBjbGllbnRzLg0KPj4+Pj4+IEhtbSwgSSB3 b3VsZCBzYXkgdGhlIG9wcG9zaXRlLiBGb3Igb25lLCB3ZSBjb3VsZCBzaW1wbGlmeSB0aGUgZGF0 YQ0KPj4+Pj4+IG1vZGVscyBieSByZWR1Y2luZyB0aGUgZHVwbGljaXRpZXMgaW4gY29uZmlndXJh dGlvbiBhbmQgc3RhdGUgdHJlZXMuDQo+Pj4+PiBUaGlzIGlzIHRoZSBvbGQgaWRlYSBvZiBoYXZp bmcgdGhlICJvcGVyYXRpb25hbCBzdGF0ZSIgZGF0YXN0b3JlLA0KPj4+Pj4gd2hpY2ggd291bGQg YmUgYWxsIGNvbmZpZyB0cnVlICsgYWxsIGNvbmZpZyBmYWxzZSBub2Rlcy4gIE9uZSBpc3N1ZQ0K Pj4+Pj4gd2l0aCB0aGlzIGlzIHRoYXQgdGhlIHNlbWFudGljcyBvZiB0aGUgbm9kZSBpcyBkaWZm ZXJlbnQgaW4gdGhlDQo+Pj4+PiBkaWZmZXJlbnQgZGF0YSBzdG9yZXMsIGV2ZW4gaWYgdGhlIHN5 bnRheCAoYnkgZGVmaW5pdGlvbiEpIGlzIHRoZQ0KPj4+Pj4gc2FtZS4gIEluIG9yZGVyIHRvIGhh bmRsZSB0aGlzIHByb3Blcmx5IHlvdSBuZWVkIGVpdGhlciB0d28gZGlmZmVyZW50DQo+Pj4+PiBk ZXNjcmlwdGlvbiBzdGF0ZW1lbnRzLCBvciB0d28gInNlY3Rpb25zIiB3aXRoaW4gdGhlIGRlc2Ny aXB0aW9uDQo+Pj4+PiBzdGF0ZW1lbnQuDQo+Pj4+IEkgdGhpbmsgdGhpcyBpcyBub3QgbXVjaCBk aWZmZXJlbnQgZnJvbSBkZWZhdWx0IHZhbHVlcy4gTGVhZnMgYW5kDQo+Pj4+IGxlYWYtbGlzdHMg dGhhdCBoYXZlIHRoZW0gZGVmaW5lZCBpbiB0aGUgZGF0YSBtb2RlbCBtYXkgbm90IGJlIHByZXNl bnQNCj4+Pj4gaW4gaW50ZW5kZWQgY29uZmlnLCB5ZXQgb25lIGNhbiBjb25zaWRlciB0aGVtIHRv IGJlIGluIGFwcGxpZWQgY29uZmlnLg0KPj4+IEkgdGhpbmsgdGhhdCBkZWZhdWx0IHZhbHVlcyBh cmUgbG9naWNhbGx5IGp1c3QgYSB3YXkgdG8gbWFrZSB0aGUNCj4+PiBjb25maWd1cmF0aW9uIGRh dGEgbW9yZSBjb25jaXNlLiAgSS5lLiBldmVyeXdoZXJlIHlvdSBoYXZlIGEgZGVmYXVsdA0KPj4+ IHZhbHVlIHRoZW4gdGhlIGVxdWl2YWxlbnQgY29uZmlndXJhdGlvbiBjb3VsZCBiZSBleHByZXNz ZWQgd2l0aCBhDQo+Pj4gZXhwbGljaXQgdmFsdWUgc2V0IGluc3RlYWQuDQo+PiBJIHRoaW5rIGRl ZmF1bHQgdmFsdWVzIGFyZSBqdXN0IHdoYXQgdGhleSBhcmUuIEEgc2V0IG9mIHZhbHVlcyBvbiB0 aGUNCj4+IHNlcnZlciB0aGF0IGhhdmUgbm90IGJlZW4gZXhwbGljaXRseSBzZXQgYnkgdGhlIGNs aWVudCB2aWENCj4+IGludGVuZGVkLWNvbmZpZy4NCj4NCj5UaGUgZGVmYXVsdCB2YWx1ZXMgYXJl IGRldGVybWluZWQgYnkgdGhlIHNjaGVtYSBhbmQgdGhlIGludGVuZGVkDQo+Y29uZmlndXJhdGlv bi4gIFlvdSBuZWVkIHRvIGtub3cgYm90aCB0byBrbm93IHdoYXQgZGVmYXVsdCB2YWx1ZXMgdGhl DQo+c2VydmVyIGlzIGV4cGVjdGVkIHRvIHVzZS4NCk5vIGRpc2FncmVlbWVudC4gVGhlIG9ubHkg cG9pbnQgaXMgd2hldGhlciBkZWZhdWx0IHZhbHVlcyAqc2hhbGwqIG9yICptYXkqDQpiZSBwcm92 aXNpb25lZCB2aWEgaW50ZW5kZWQgY29uZmlnDQo+DQo+QnV0IGluIHRlcm1zIG9mIHdoYXQgaXMg YWN0dWFsbHkgYXBwbGllZCwgYW4gaW50ZW5kZWQgY29uZmlndXJhdGlvbiB3aXRoDQo+ZGVmYXVs dHMgdmFsdWVzIGNhbiBiZSBtYXBwZWQgaW50byBhbiBlcXVpdmFsZW50IGludGVuZGVkIGNvbmZp Z3VyYXRpb24NCj53aXRoIGFsbCBpbXBsaWNpdCBkZWZhdWx0cyByZXBsYWNlZCBieSB0aGUgZXF1 aXZhbGVudCBleHBsaWNpdCB2YWx1ZXMuDQo+V2hhdCBnZXRzIGFwcGxpZWQgIGluIHRoZSBkZXZp Y2Ugc2hvdWxkIGJlIHRoZSBzYW1lIGluIGJvdGggY2FzZXMuDQo+DQo+DQo+PiAgIEl0IGlzIGNl cnRhaW5seSBwb3NzaWJsZSB0byBzZXQgZGVmYXVsdCB2YWx1ZXMgaW4NCj4+IGludGVuZGVkLWNv bmZpZyBleHBsaWNpdGx5LCBidXQgaXQgaXMgbm90IHN0cmljdGx5IG5lZWRlZC4NCj5ZZXMsIG9m IGNvdXJzZS4NCj4NCj4+PiBBcyBzdWNoLCBJIHRoaW5rIHRoYXQgdGhlIGRlZmF1bHQgdmFsdWVz IGFwcGx5IGVxdWFsbHkgdG8gYm90aCB0aGUNCj4+PiBpbnRlbmRlZCBhbmQgYXBwbGllZCBjb25m aWd1cmF0aW9uLg0KPj4gV2hpbGUgdGhpcyBpcyBhbGxvd2VkIChzZWUgYWJvdmUpLCBJIHdvdWxk IGNvbnNpZGVyIGRlZmF1bHQgdmFsdWVzIGFwcGx5DQo+PiBpbiBwcmFjdGljZSB0byB0aGUgYXBw bGllZCBjb25maWcNCj5JIHRoaW5rIHRoYXQgSSBkaXNhZ3JlZSBvbiB0aGlzIHBvaW50Lg0KT0ss IGxldOKAmXMga2VlcCB0aGlzIHBvaW50IGZvciBhIGZ1cnRoZXIgZGlzY3Vzc2lvbi4NCj4NCj5U aGUgaW50ZW5kZWQgY29uZmlndXJhdGlvbiBpcyBvbmx5IGNvbXBsZXRlIHdoZW4geW91IGNvbnNp ZGVyIGl0cw0KPmFzc29jaWF0ZWQgWUFORyBzY2hlbWEgYW5kIGltcGxpY2l0IGRlZmF1bHQgdmFs dWVzLg0KVHJ1ZSwgYnV0IGl0IGRvZXNu4oCZdCBtZWFuIHRoYXQgdGhlIGNsaWVudCB3aGljaCBo b2xkcyB0aGUgY29tcGxldGUNCmludGVuZGVkIGNvbmZpZyBoYXMgdG8gZXhwbGljaXRseSBwdXNo IGV2ZXJ5dGhpbmcgZG93biB0byB0aGUgc2VydmVyLg0KQWdhaW4gdGhpcyBpcyB0aGUgZGlzdGlu Y3Rpb24gYmV0d2VlbiAqbWF5KiBhbmQgKnNoYWxsKiBhbmQgd29ydGggYQ0KZGlzY3Vzc2lvbi4g DQo+DQo+DQo+Pg0KPj4+IElmIGFmdGVyIGEgY29uZmlnIHJlcXVlc3QgaXQgdGFrZXMgdGltZSBm b3IgdGhlIHN5c3RlbSB0byBhcHBseSBhDQo+Pj4gZGVmYXVsdCB2YWx1ZSwgdGhlbiBpZGVhbGx5 IHRoZSBhcHBsaWVkIGNvbmZpZ3VyYXRpb24gc2hvdWxkIGhhdmUgYW4NCj4+PiBleHBsaWNpdCBs ZWFmIHRvIHNob3cgd2hhdCB2YWx1ZSBpcyBhY3R1YWxseSBpbiBlZmZlY3QgdW50aWwgdGhlDQo+ Pj5kZWZhdWx0DQo+Pj4gdmFsdWUgaGFzIGFjdHVhbGx5IGJlZW4gYXBwbGllZCBpbiB0aGUgc3lz dGVtLg0KPj4gSWYgdGhlIGNsaWVudCBoYXMgYW4gaW5kaWNhdGlvbiB3aGV0aGVyIHRoZSBjb25m aWd1cmF0aW9uIGFwcGxpY2F0aW9uIGlzDQo+PiBmaW5pc2hlZCAod2l0aCBvciB3aXRob3V0IGVy cm9ycyksIGl0IGtub3dzIHRoYXQgdGhlIGFwcGxpZWQgY29uZmlnIGlzDQo+Pm5vdw0KPj4gc3Rh YmxlIHRvIGJlIHJlYWQuIFJlYWRpbmcgYXBwbGllZCBjb25maWcgZHVyaW5nIGFuIG9wZXJhdGlv biBzaG91bGQgYmUNCj4+IGF2b2lkZWQuIEhlbmNlIEkgd291bGQgcXVlc3Rpb24gdGhlIG5lZWQg Zm9yIGEgcGVyLWxlYWYgc3RhdGUgYW5kDQo+PmFkdm9jYXRlDQo+PiBmb3IgYSBwZXItc2VydmVy IHN0YXRlLg0KPkkgdGhpbmsgdGhhdCB0aGUgd2hvbGUgcHVycG9zZSBvZiB0aGUgb3BzdGF0ZSBy ZXF1aXJlbWVudHMgaXMgdGhhdCB0aGUNCj5vcGVyYXRvcnMgZWZmZWN0aXZlbHkgd2FudCB0byBi ZSBhYmxlIHRvIHRyYWNrIG9uIGEgcGVyIGxlYWYgZWxlbWVudA0KPnJhdGhlciB0aGFuIGEgcGVy LXNlcnZlciBlbGVtZW50Lg0KVGhlIHBvaW50IGhhcyBiZWVuIHRoYXQgdGhlIGNsaWVudCB3YW50 cyB0byBrbm93IHdoZXRoZXIgaXTigJlzIGludGVuZGVkDQpjb25maWd1cmF0aW9uIGhhcyBiZWVu IGFwcGxpZWQuIFRoaXMgaW5mb3JtYXRpb24gaXMgbWlzc2luZyBmcm9tIHRoZSBvbGQNCmFzeW5j aCBtb2RlbCBhbmQgaGVuY2UgY3JlYXRlcyB1bmNlcnRhaW50eS4gQW55IHJlYWQgYXR0ZW1wdCBv ZiB0aGUgY2xpZW50DQpyZWxhdGVkIHRvIGFwcGxpZWQgY29uZmlndXJhdGlvbiBtYXkgZmFsbCBp bnRvIGEgdHJhbnNpdGlvbiBwZXJpb2QgYW5kIGlzDQpvbmx5IGEgc25hcHNob3Qgb2YgYSB3b2Ji bHkgc3RhdGUuDQpFc3NlbnRpYWxseSB3ZSBhcmUgZGlzY3Vzc2luZyB3aGVyZSB0byBwdXQgYSBk aXJ0eS1mbGFnLiBJbiBteSAobGVzcw0KZ3JhbnVsYXIpIHZpZXcgaXQgaXMgcHJ1ZGVudCB0byBw dXQgdGhlIGRpcnR5LWZsYWcgaGlnaCB1cCBpbiB0aGUgdHJlZSBhbmQNCmtlZXAgaXQgdHJ1ZSB1 bnRpbCB0aGUgc3RhdGUgY2hhbmdlIGNvbXBsZXRlZCAoaXJyZXNwZWN0aXZlIGlmIGl0IHdhcw0K c3VjY2Vzc2Z1bCBvciBub3QpLiBBbm90aGVyIHdheSBpcyB0byBrZWVwIGEgdmVyeSBncmFudWxh ciB2aWV3IGFuZCBzdGljaw0KdGhlIGRpcnR5IGZsYWcgb24gYWxsIGxlYWZzIHRoYXQgYXJlIHN1 cHBvc2VkIHRvIGJlIHRvdWNoZWQgYnkgdGhlDQppbnRlbmRlZCBzdGF0ZSBhbmQgY2xlYW5pbmcg dGhlbSB1cCBhZnRlciAqYWxsKiBpbnRlbmRlZCBjb25maWcgaGFzIGJlZW4NCmF0dGVtcHRlZCB0 byBhcHBseS4gQSBiaXQgb2YgbW9yZSBoYXNzbGUgZnJvbSBhbiBpbXBsZW1lbnRlcnMgcG9pbnQg b2YNCnZpZXcsIGFuZCBJIGFtIG5vdCBzdXJlIGlmIGl0IGlzIHdvcnRoLg0KIA0KPg0KPkkgbWln aHQgYmUgd3JvbmcsIGJ1dCBJIHRoaW5rIHRoYXQgdGhlIGRlc2lnbiBiZWluZyBjb25zaWRlciBi eSB0aGUNCj5vcHN0YXRlIG9wZXJhdG9ycyBpcyBhbG9uZyB0aGUgbGluZXMgb2YgYW4gZXZlbnR1 YWwgY29uc2lzdGVudCBtb2RlbC4NCj5FLmcuIHNvbWV0aGluZyBhbG9uZyB0aGUgbGluZXMgb2Y6 DQo+DQo+QXQgYW55IHBvaW50IGluIHRpbWUgdGhlIG9wZXJhdG9yIGtub3dzIHdoYXQgY29uZmln dXJhdGlvbiBzdGF0ZSB0aGV5DQo+d291bGQgYSBkZXZpY2UgdG8gYmUgaW4gKGkuZS4gdGhlIGlu dGVuZGVkIGNvbmZpZ3VyYXRpb24pLg0KT0sNCj5XaGVuZXZlciB0aGUgY2xpZW50IGNoYW5nZXMg dGhlaXIgaW50ZW5kZWQgY29uZmlndXJhdGlvbiwgdGhleSBwdXNoIGRvd24NCj50aGUgdXBkYXRl ZCBpbnRlbmRlZCBjb25maWd1cmF0aW9uIHRvIHRoZSBkZXZpY2UuDQpPSywgZnJvbSBub3cgb24g dGhlIGNsaWVudCBpcyBibGluZCBhYm91dCB0aGUgYXBwbGllZCBzdGF0ZSBvZiB0aGUgc2VydmVy DQp1bmxlc3MgaXQgY2FuIGd1ZXNzIGl0IGZyb20gZS5nLiBEZXJpdmVkIHN0YXRlIGFuZCBzbyBv bi4NCj5UaGUgZGV2aWNlIHN0YXJ0cyBhcHBseWluZyB0aGUgY2hhbmdlICh1c2luZyB0aGUgc3Bl Y2lmaWVkIGVycm9yDQo+aGFuZGxpbmcgc2VtYW50aWNzKQ0KT0sNCj5UaGV5IHJlZ2lzdGVyIGZv ciBub3RpZmljYXRpb24gZm9yIGNoYW5nZXMgdG8gYWxsIGludGVuZGVkL2FwcGxpZWQNCj5jb25m aWcgYW5kIGRlcml2ZWQgc3RhdGUgb24gdGhlIGRldmljZSBzbyB0aGF0IHRoZXkgaGF2ZSBhIGZl ZWRiYWNrDQo+bWVjaGFuaXNtIHRvIGtub3cgd2hldGhlciB0aGUgY29uZmlndXJhdGlvbiBpcyBi ZWluZyBzdWNjZXNzZnVsbHkgYXBwbGllZC4NCk9LLCBzbyBmcm9tIG5vdyBvbiB0aGUgY2xpZW50 IGtub3dzIHRoYXQgdGhlIG5ldyBpbnRlbmRlZCBjb25maWcgaXMNCmFjdGl2ZS4gSXQgYWxzbyBt ZWFucyB0aGF0IHRoZSBjbGllbnQgY2FuIHJlbGlhYmx5IHJlYWQgYXBwbGllZCBzdGF0ZS4NCj4N Cj4+DQo+Pj4gVGhpcyBkb2VzIG9wZW4gdGhlIHF1ZXN0aW9uIG9mIGhvdyBkbyB5b3UgZXhwcmVz cyB0aGUgY2FzZSB0aGF0IG5vDQo+Pj52YWx1ZQ0KPj4+IGhhcyBiZWVuIGFwcGxpZWQgcmF0aGVy IHRoYW4gYSBkaWZmZXJlbnQgdmFsdWUuICBGb3IgdGhlIG9wc3RhdGUNCj4+PiBlbmNvZGluZyBz b2x1dGlvbiBkcmFmdCB0aGF0IEkgcHV0IGZvcndhcmQgKG9yIHVzaW5nIG1ldGEtZGF0YSksIHRo ZW4gSQ0KPj4+IHRoaW5rIHRoYXQgaXQgd291bGQgcHJvYmFibHkgYmUgcG9zc2libGUgdG8gZXh0 ZW5kIHRoZSBlbmNvZGluZyB0bw0KPj4+IGV4cGxpY2l0bHkgaW5jbHVkZSB0aGlzIGluZm9ybWF0 aW9uIGlmIHJlcXVpcmVkLg0KPj4gUGVyaGFwcyBJIGFtIG1pc3Npbmcgc29tZXRoaW5nIGhlcmUu IElmIHRoZSB2YWx1ZSBzdXBwb3NlZCB0byBiZSBhcHBsaWVkDQo+PiBpcyB0aGUgc2FtZSB0aGF0 IGFscmVhZHkgZXhpc3RzLCBqdXN0IHNraXAgaXQgaW4gdGhlIHNlcnZlci4NCj5UaGUgY2FzZSBJ IHdhcyBjb25zaWRlcmluZyBpcyB3aGVyZSB0aGUgc2VydmVyIGhhcyBubyB2YWx1ZSBhcHBsaWVk DQo+KGUuZy4gZm9yIGFuIG9wdGlvbmFsIGZlYXR1cmUpIHJhdGhlciB0aGFuIHRoZSBkZWZhdWx0 IHZhbHVlLg0KV2hhdGV2ZXIgdmFsdWUgdGhlIHNlcnZlciBhcHBsaWVkIChub25lIG9yIGRlZmF1 bHQpIHNob3VsZG7igJl0IGJlIGFuIGlzc3VlDQp1bmxlc3MgdGhlIGludGVuZGVkIGNvbmZpZyBp bXBvc2VzIGEgY2VydGFpbiB2YWx1ZS4gSSBndWVzcyB5b3UgaGFkIGluDQptaW5kIG9uIGhvdyB0 byBkZWFsIHdpdGggdGhlIG9wc3RhdGUgb2YgYSBub24tdmFsdWUuIFB1c2hpbmcgdGhlIG9wc3Rh dGUNCmhpZ2hlciB1cCB0aGUgdHJlZSB3b3VsZCBwcm9iYWJseSBhZGRyZXNzIHRoZSBpc3N1ZSAo c2VlIGFib3ZlKS4NCj4NCj4+PiBBbHRlcm5hdGl2ZWx5LCBhbmQgZm9yIHRoZSBvdGhlciBwcm9w b3NlZCBvcHN0YXRlIHNvbHV0aW9ucywgdGhlbiBJDQo+Pj4gZXhwZWN0IHRoYXQgdGhlIG1vc3Qg YXBwcm9wcmlhdGUgaWRlYWwgc2VtYW50aWNzIHRvIGhhbmRsZSB0aGlzDQo+Pj5zY2VuYXJpbw0K Pj4+IHdvdWxkIGJlIHRvIGRlbGF5IG1hcmtpbmcgdGhlIHBhcmVudCBvYmplY3QgYXMgYmVpbmcg YXBwbGllZCB1bnRpbA0KPj4+ZXZlcnkNCj4+PiBkZXNjZW5kZW50IGNoaWxkIGxlYWYgd2l0aCBh IGRlZmF1bHQgdmFsdWUgc2V0IGhhcyBhIHZhbHVlIGFwcGxpZWQgaW4NCj4+PiB0aGUgc3lzdGVt LCBlaXRoZXIgdG8gdGhlIGV4cGVjdGVkIGRlZmF1bHQgdmFsdWUgKGluIHdoaWNoIGNhc2UgdGhl DQo+Pj4gY2hpbGQgbGVhZiB3b3VsZG4ndCBuZWVkIHRvIGJlIHByZXNlbnQgaW4gdGhlIGFwcGxp ZWQgY29uZmlnKSwgb3INCj4+PiB0cmFuc2llbnRseSB0byBhbm90aGVyIHZhbHVlICh3aGljaCB3 b3VsZCBiZSBpbiB0aGUgYXBwbGllZCBjb25maWcNCj4+PnVudGlsDQo+Pj4gdGhlIHN5c3RlbSB1 cGRhdGVkIGFuZCB0aGUgY29ycmVjdCBkZWZhdWx0IHZhbHVlcyBoYXZlIGFjdHVhbGx5IGJlZW4N Cj4+PiBhcHBsaWVkKS4gIEluIHJlYWwgc3lzdGVtcywgSSB3b3VsZCBoYXZlIHRob3VnaHQgdGhh dCB0aGUgZGVmYXVsdA0KPj4+dmFsdWVzDQo+Pj4gYXJlIG9mdGVuIGltcGxpY2l0bHkgcHJvZ3Jh bW1lZCB3aGVuIHRoZSBwYXJlbnQgY29udGFpbmluZyBvYmplY3QgaXMNCj4+PiBjcmVhdGVkIGFu eXdheSwgc28gSSBzdXNwZWN0IHRoYXQgdGhpcyBiZWhhdmlvdXIgd291bGRuJ3QgYWN0dWFsbHkg YmUNCj4+PiB0aGF0IG9uZXJvdXMgdG8gaW1wbGVtZW50Lg0KPj4gSXQgYXBwZWFycyB0byBtZSB0 aGF0IHdlIHJ1biBpbnRvIHRob3NlIGlzc3VlcyBieSByZXF1aXJpbmcgdGhlIGludGVuZGVkDQo+ PiBjb25maWcgdG8gY29udGFpbiBhbHNvIHRoZSBkZWZhdWx0IHZhbHVlcy4gVGhhdCBkb2VzbsK5 dCBzZWVtIG5lY2Vzc2FyeS4NCj4+SQ0KPkkgY2FuJ3Qgc2VlIGhvdyB5b3UgY2FuIGhhdmUgZGVm YXVsdCB2YWx1ZXMgYXBwbHkgb25seSB0byB0aGUgYXBwbGllZA0KPmNvbmZpZ3VyYXRpb24gYW5k IG5vdCB0aGUgaW50ZW5kZWQgY29uZmlndXJhdGlvbi4gIFRoZSBpbnRlbmRlZA0KPmNvbmZpZ3Vy YXRpb24gY2Fubm90IGJlIGNvcnJlY3RseSBpbnRlcnByZXRlZCBpZiB5b3UgZG9uJ3QgYWxzbyBj b25zaWRlcg0KPnRoZSBkZWZhdWx0IHZhbHVlcyBzcGVjaWZpZWQgaW4gdGhlIHNjaGVtYS4NCkdp dmVuIHRoYXQgc2VydmVycyBub3dhZGF5cyBjb3ZlciBhIGh1Z2UgYW1vdW50IG9mIGZ1bmN0aW9u YWxpdHkgd2hlcmUNCm9mdGVuIG9ubHkgYSBzdWJzZXQgaXMgcmVxdWlyZWQgYnkgYSBjbGllbnQs IEkgd291bGQgY29uc2lkZXIgcXVpdGUgYSBiaXQNCm9mIGRlZmF1bHQgdmFsdWVzIGlycmVsZXZh bnQgZm9yIHRoZSBzY29wZSBvZiB0aGUgY2xpZW50LiBJZiBlLmcuIFlvdSBwbGFuDQp0byB1c2Ug YSByb3V0ZXIgdGhhdCBzdXBwb3J0cyBWUExTLCBidXQgeW91IGRvIG5vdCBjYXJlIHNpbmNlIGl0 IGlzIG5vdA0KbmVlZGVkLCB0aG9zZSBkZWZhdWx0cyBjYW4ganVzdCBiZSBsZWZ0IHRvIHRoZSBz ZXJ2ZXIuDQo+DQo+PiB3b3VsZCBhbHNvIGFyZ3VlIHRoYXQgbWFya2luZyB0aGUgxZJhcHBsaWVk PWludGVuZGVkwrkgc3RhdGUgcGVyIGxlYWYgaXMNCj4+IGNvdW50ZXItcHJvZHVjdGl2ZS4gQXNz dW1lIHRoZSBjbGllbnQgc2V0cyBhbiBpbnRlbmRlZCBzdGF0ZSBvZiB0d28NCj4+dmFsdWVzDQo+ VHJhY2tpbmcgaW50ZW5kZWQgdnMgYXBwbGllZCBvbiBhIHBlciBsZWFmIGJhc2lzIGlzIHRoZSBl c3NlbmNlIG9mIHRoZQ0KPm9wc3RhdGUgcmVxdWlyZW1lbnRzLCBwbGVhc2UgbGV0cyBub3QgcmVo YXNoIHRoZXNlIGFsbCB5ZXQgYWdhaW4uIDotKQ0KU2VlIGFib3ZlLCB5b3UgY2FuIGRvIHRoaXMg YnV0IGl04oCZcyBxdWl0ZSBhIGJpdCBvZiB3b3JrLiBUaGUgcmVxdWlyZW1lbnQNCnN0ZW1zIGZy b20gYSB0aW1lIHdoZXJlIGEgY2xpZW50IHdhc27igJl0IGFibGUgdG8gZmlndXJlIG91dCB3aGV0 aGVyIGEgbGVhZg0KaGFzIGJlZW4gY2hhbmdlZCBhbHJlYWR5IG9yIHdhcyBhYm91dCB0byBjaGFu Z2UgaW4gZnV0dXJlLiBUbyBtZSBpdA0KYXBwZWFycyBtb3JlIG9mIGFuIGltcGxlbWVudGF0aW9u IGNob2ljZS4NCj4NCj4+IChBLEIpIG9uIHR3byBkaWZmZXJlbnQgbGVhZnMgd2l0aCByb2xsYmFj ay1vbi1lcnJvciBzZW1hbnRpYy4gSWYNCj4+YXBwbHlpbmcNCj4+IEEgc3VjY2VlZHMgYW5kIHRo ZSBjbGllbnQgcmVhZHMgdGhlIGFwcGxpZWQgc3RhdGUgd2hpbGUgYXBwbHlpbmcgQiBpcw0KPj4g c3RpbGwgaW4gcHJvZ3Jlc3MsIGEgcm9sbGJhY2sgbWF5IHN0aWxsIGhhcHBlbi4gVGhhdCB3b3Vs ZCBpbnZhbGlkYXRlDQo+PnRoZQ0KPj4gcHJldmlvdXMgdmFsdWUgb2YgQS4gSW4gb3RoZXIgd29y ZHMgaXQgaXMgdW53aXNlIHRvIHJlYWQgZGF0YSBmcm9tIGENCj4+IHNvdXJjZSB3aGlsZSBpdCBp cyBhY3R1YWxseSB3cml0aW5nLg0KPk5vLCB0aGlzIGlzIGZpbmUsIGFuZCBpc24ndCBhIHByb2Js ZW0uICBUaGUgc2VydmVyIHdpbGwgZXZlbnR1YWxseQ0KPmNvbnZlcmdlIG9uIGEgc3RhdGUgYW5k IHRoZSBjbGllbnQgd2lsbCBiZSBub3RpZmllZCBvZiB0aGF0IHN0YXRlLg0KPlRoZSANCj5mYWN0 IHRoYXQgYSBjbGllbnQgbWlnaHQgdGVtcG9yYXJpbHkgc2VlIGEgdmFsaWQgc3RhdGUgdGhhdCBp cw0KPnN1YnNlcXVlbnRseSB1bmRvbmUgaXNuJ3QgYSBwcm9ibGVtLg0KSeKAmWQgc2VyaW91c2x5 IHF1ZXN0aW9uIHRob3NlIHR3byBzdGF0ZW1lbnRzLiBXaGVuIHRoZSBzZXJ2ZXIgaXMgdXBkYXRp bmcNCml0cyBhcHBsaWVkIHN0YXRlIHlvdSBoYXZlIGF0IGJlc3QgYSA1MCUgY2hhbmNlIHRvIHJl YWQgdGhlIGNvcnJlY3QgdmFsdWUuDQpXaGF0IG1lYW5pbmdmdWwgY29uY2x1c2lvbiBpcyB0aGUg Y2xpZW50IHN1cHBvc2VkIHRvIHRha2UgZnJvbSB0aGF0PyBPdXQNCm9mIGRlc3BlcmF0aW9uLCBj dXJyZW50IGltcGxlbWVudGF0aW9ucyB1c2UgdGhhdCDigJh0cmlja+KAmSBieSBwb2xsaW5nDQp2 YXJpb3VzIGxlYWYgdmFsdWVzIHRvIGZpZ3VyZSBvdXQgd2hldGhlciBhbiBpbnRlbmRlZCBzdGF0 ZSBoYXMgYWxyZWFkeQ0KYmVlbiBhcHBsaWVkIG9yIG5vdC4gSG93ZXZlciBzdWNoIGludGVuc2l2 ZSBwb2xsaW5nIGN5Y2xlcyBhcmUgbm8gbW9yZQ0KbmVlZGVkIG9uY2UgYSBzZXJ2ZXIgbm90aWZp ZXMgdGhlIGNsaWVudCB1cG9uIGNvbXBsZXRpb24gb2YgaW50ZW5kZWQgc3RhdGUNCmFwcGxpY2F0 aW9uLiANCklmIHRoZSBjbGllbnQgY2hvb3NlcyB0byByZWFkIGFwcGxpZWQgc3RhdGUgZHVyaW5n IHRoYXQgcGVyaW9kLCBpdCBpcyBhdA0KbGVhc3QgYXdhcmUgdGhhdCB0aGUgc3RhdGUgaXMganVz dCBhIHRlbXBvcmFyeSBzbmFwc2hvdC4NCg0KPg0KPlRoYW5rcywNCj5Sb2INCj4NCj4NCj4+DQo+ Pj4gVGhhbmtzLA0KPj4+IFJvYg0KPj4+DQo+Pj4NCj4+Pj4gTGFkYQ0KPj4+Pg0KPj4+Pj4gICAg ICBsaXN0IGludGVyZmFjZSB7DQo+Pj4+PiAgICAgICAgZGVzY3JpcHRpb24tY29uZmlnDQo+Pj4+ PiAgICAgICAgICAiVGhlIGxpc3Qgb2YgY29uZmlndXJlZCBpbnRlcmZhY2VzIG9uIHRoZSBkZXZp Y2UuDQo+Pj4+PiAgICAgICAgICAgLi4uIjsNCj4+Pj4+ICAgICAgICBkZXNjcmlwdGlvbi1vcGVy DQo+Pj4+PiAgICAgICAgICAiVGhlIGxpc3Qgb2YgaW50ZXJmYWNlcyBvbiB0aGUgZGV2aWNlLg0K Pj4+Pj4gICAgICAgICAgIA0KPj4+Pj4gICAgICAgICAgIFN5c3RlbS1jb250cm9sbGVkIGludGVy ZmFjZXMgY3JlYXRlZCBieSB0aGUgc3lzdGVtIGFyZQ0KPj4+Pj4gICAgICAgICAgIGFsd2F5cyBw cmVzZW50IGluIHRoaXMgbGlzdCwgd2hldGhlciB0aGV5IGFyZSBjb25maWd1cmVkIG9yDQo+Pj4+ PiAgICAgICAgICAgbm90Lg0KPj4+Pj4gICAgICAgICAgIC4uLiI7DQo+Pj4+PiAgICAgIH0NCj4+ Pj4+DQo+Pj4+Pg0KPj4+Pj4gL21hcnRpbg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4+IG5ldG1v ZEBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0 bW9kDQo+PiAuDQo+Pg0KPg0KDQo= From nobody Tue Jan 12 09:36:57 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A69B31A0103 for ; Tue, 12 Jan 2016 09:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKbVuTb6-NSw for ; Tue, 12 Jan 2016 09:36: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 F1C301A0104 for ; Tue, 12 Jan 2016 09:36:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16404; q=dns/txt; s=iport; t=1452620207; x=1453829807; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=PFkkYXRFwsfnSSLLN4XUdq8anVkHQ2Nsocy+WEzmdhM=; b=Ujo5TuR/NdYBat7jxw0wpkZDmwBf/TuAjWth0KhOItppCujYuR0rsXdC FAurLlHaLXmVNxA46f7rRrXfeYw43fevckYffMN8UB/LQHUdiCQruZHKy ju6S2q9BYxo4uDqBGqOJ5tLU/zUC4BMEXYUAinVsrq7/Okn0n/GNR5odm Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQBcOJVW/xbLJq1ehAxtiFmzJQENg?= =?us-ascii?q?WQYCoUjSgKBYBQBAQEBAQEBgQqENAEBAQMBAQEBIA8BBTYLBQsLDgIIAgIFIQI?= =?us-ascii?q?CDwIWMAYBDAYCAQEVAogLCA6vTJA6AQEBAQEBAQEBAQEBAQEBAQEBAQEBFASBA?= =?us-ascii?q?YVVhH+EMQ2DNoFJBYdhhxKIIIVDgnOFI4FehEODByOFMYVlhHuDcyABAUKCERy?= =?us-ascii?q?BXT40hHkBHwSBJwEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,558,1444694400"; d="scan'208";a="648452877" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jan 2016 17:36:44 +0000 Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u0CHahfa018125; Tue, 12 Jan 2016 17:36:43 GMT To: Gert Grammel , Ladislav Lhotka , Martin Bjorklund References: <5693C32E.7020708@cisco.com> <31E9D485-9349-448D-99A3-DD20F5E5AF09@nic.cz> <20160111.211837.377848045119250710.mbj@tail-f.com> <5694D180.6030300@cisco.com> <569507FA.1070805@cisco.com> From: Robert Wilton Message-ID: <569539AB.80007@cisco.com> Date: Tue, 12 Jan 2016 17:36:43 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] applied configuration and system-controlled entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 17:36:51 -0000 On 12/01/2016 16:02, Gert Grammel wrote: > > On 2016-12-01 15:04, "Robert Wilton" wrote: > >> >> On 12/01/2016 10:42, Gert Grammel wrote: >>> On 2016-12-01 11:12, "netmod on behalf of Robert Wilton" >>> wrote: >>> >>>> On 12/01/2016 09:05, Ladislav Lhotka wrote: >>>>> Martin Bjorklund writes: >>>>> >>>>>> Ladislav Lhotka wrote: >>>>>>>> On 11 Jan 2016, at 15:58, Robert Wilton wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 11/01/2016 14:27, Ladislav Lhotka wrote: >>>>>>>>>> On 11 Jan 2016, at 15:11, Juergen Schoenwaelder >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> On Mon, Jan 11, 2016 at 02:54:36PM +0100, Martin Bjorklund wrote: >>>>>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>>>> Hi Gert, >>>>>>>>>>>> >>>>>>>>>>>>> On 11 Jan 2016, at 14:25, Gert Grammel >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Lada, >>>>>>>>>>>>> >>>>>>>>>>>>> The requirement says: >>>>>>>>>>>>> D. When a configuration change for any intended >>>>>>>>>>>>> configuration >>>>>>>>>>>>> node has been successfully applied to the server >>>>>>>>>>>>> (e.g. not >>>>>>>>>>>>> failed, nor deferred due to absent hardware) then >>>>>>>>>>>>> the >>>>>>>>>>>>> existence and value of the corresponding applied >>>>>>>>>>>>> configuration node must match the intended >>>>>>>>>>>>> configuration >>>>>>>>>>>>> node. >>>>>>>>>>>>> >>>>>>>>>>>>> I don't see that this would limit the case you described >>>>>>>>>>>>> below. >>>>>>>>>>>>> In >>>>>>>>>>>>> your case there is no intended config, hence there is no >>>>>>>>>>>>> "corresponding applied configuration" either. >>>>>>>>>>>> You are right, the requirement can be interpreted this way. I >>>>>>>>>>>> thought >>>>>>>>>>>> that applied configuration was supposed to be identical to >>>>>>>>>>>> intended >>>>>>>>>>>> after some synchronization period. >>>>>>>>>>> This is a very important point to clarify. Can there ever be >>>>>>>>>>> data in >>>>>>>>>>> "applied" that is not in "intended"? I think Anees & Rob >>>>>>>>>>> previously >>>>>>>>>>> said "no", but I might be wrong. >>>>>>>>>>> >>>>>>>>>> If there is time delay between editing intended and the applied >>>>>>>>>> config >>>>>>>>>> matching the edits of intended, then I supose this can happen (I >>>>>>>>>> delete a resource from intended but it is still around until >>>>>>>>>> intended >>>>>>>>>> has been fully synced). I would find it interesting if some edits >>>>>>>>>> are >>>>>>>>> Using applied config for system-controlled entries would require >>>>>>>>> that >>>>>>>>> such an entry stays (forever) in applied config even after it has >>>>>>>>> been >>>>>>>>> deleted from intended. >>>>>>>> I think that this would make life harder for clients. >>>>>>> Hmm, I would say the opposite. For one, we could simplify the data >>>>>>> models by reducing the duplicities in configuration and state trees. >>>>>> This is the old idea of having the "operational state" datastore, >>>>>> which would be all config true + all config false nodes. One issue >>>>>> with this is that the semantics of the node is different in the >>>>>> different data stores, even if the syntax (by definition!) is the >>>>>> same. In order to handle this properly you need either two different >>>>>> description statements, or two "sections" within the description >>>>>> statement. >>>>> I think this is not much different from default values. Leafs and >>>>> leaf-lists that have them defined in the data model may not be present >>>>> in intended config, yet one can consider them to be in applied config. >>>> I think that default values are logically just a way to make the >>>> configuration data more concise. I.e. everywhere you have a default >>>> value then the equivalent configuration could be expressed with a >>>> explicit value set instead. >>> I think default values are just what they are. A set of values on the >>> server that have not been explicitly set by the client via >>> intended-config. >> The default values are determined by the schema and the intended >> configuration. You need to know both to know what default values the >> server is expected to use. > No disagreement. The only point is whether default values *shall* or *may* > be provisioned via intended config I meant "May". >> But in terms of what is actually applied, an intended configuration with >> defaults values can be mapped into an equivalent intended configuration >> with all implicit defaults replaced by the equivalent explicit values. >> What gets applied in the device should be the same in both cases. >> >> >>> It is certainly possible to set default values in >>> intended-config explicitly, but it is not strictly needed. >> Yes, of course. >> >>>> As such, I think that the default values apply equally to both the >>>> intended and applied configuration. >>> While this is allowed (see above), I would consider default values apply >>> in practice to the applied config >> I think that I disagree on this point. > OK, let’s keep this point for a further discussion. >> The intended configuration is only complete when you consider its >> associated YANG schema and implicit default values. > True, but it doesn’t mean that the client which holds the complete > intended config has to explicitly push everything down to the server. > Again this is the distinction between *may* and *shall* and worth a > discussion. Yes, I think that it is "may". > >> >>>> If after a config request it takes time for the system to apply a >>>> default value, then ideally the applied configuration should have an >>>> explicit leaf to show what value is actually in effect until the >>>> default >>>> value has actually been applied in the system. >>> If the client has an indication whether the configuration application is >>> finished (with or without errors), it knows that the applied config is >>> now >>> stable to be read. Reading applied config during an operation should be >>> avoided. Hence I would question the need for a per-leaf state and >>> advocate >>> for a per-server state. >> I think that the whole purpose of the opstate requirements is that the >> operators effectively want to be able to track on a per leaf element >> rather than a per-server element. > The point has been that the client wants to know whether it’s intended > configuration has been applied. This information is missing from the old > asynch model and hence creates uncertainty. Any read attempt of the client > related to applied configuration may fall into a transition period and is > only a snapshot of a wobbly state. Yes, and that isn't a problem. The intended config is updated, and then the applied config state converges on the intended config. > Essentially we are discussing where to put a dirty-flag. In my (less > granular) view it is prudent to put the dirty-flag high up in the tree and > keep it true until the state change completed (irrespective if it was > successful or not). Another way is to keep a very granular view and stick > the dirty flag on all leafs that are supposed to be touched by the > intended state and cleaning them up after *all* intended config has been > attempted to apply. A bit of more hassle from an implementers point of > view, and I am not sure if it is worth. Having a single dirty flag doesn't really meet the requirements (as stated in the requirements draft). It means that config reads from the server are unavailable (or stale) whilst a config change is in progress (which could take a long time). Instead, the operators requirement is that the tracking is done on a per leaf basis (e.g. like the OpenConfig YANG models on https://github.com/openconfig/public), I believe with the expectation that the server should update the leaves as the configuration is being applied. I.e. if the server had processed half the configuration from a 1 million entry config then ideally it should be updating the applied configuration leaves as it goes so that the client knows what is currently programmed at that particular point in time. In the ideal world the server should always be telling the client what configuration is applied at that specific point in time that the request is processed. > >> I might be wrong, but I think that the design being consider by the >> opstate operators is along the lines of an eventual consistent model. >> E.g. something along the lines of: >> >> At any point in time the operator knows what configuration state they >> would a device to be in (i.e. the intended configuration). > OK >> Whenever the client changes their intended configuration, they push down >> the updated intended configuration to the device. > OK, from now on the client is blind about the applied state of the server > unless it can guess it from e.g. Derived state and so on. No, the client can read the current state from the server at any point in time, and ideally it should reflect the configuration at that point in time (even if it is half way through a config request). >> The device starts applying the change (using the specified error >> handling semantics) > OK >> They register for notification for changes to all intended/applied >> config and derived state on the device so that they have a feedback >> mechanism to know whether the configuration is being successfully applied. > OK, so from now on the client knows that the new intended config is > active. It also means that the client can reliably read applied state. The changes to the individual leaves can be notified independently as they change state. The client can reliably read the applied state at any time. >>>> This does open the question of how do you express the case that no >>>> value >>>> has been applied rather than a different value. For the opstate >>>> encoding solution draft that I put forward (or using meta-data), then I >>>> think that it would probably be possible to extend the encoding to >>>> explicitly include this information if required. >>> Perhaps I am missing something here. If the value supposed to be applied >>> is the same that already exists, just skip it in the server. >> The case I was considering is where the server has no value applied >> (e.g. for an optional feature) rather than the default value. > Whatever value the server applied (none or default) shouldn’t be an issue > unless the intended config imposes a certain value. It is an issue because the client wants to know what configuration a device is actually running. Ideally it wants a given device to exactly implement the configuration that they are requesting. They don't really want lots of random device specific values that will require custom client code to handle. > I guess you had in > mind on how to deal with the opstate of a non-value. Pushing the opstate > higher up the tree would probably address the issue (see above). >>>> Alternatively, and for the other proposed opstate solutions, then I >>>> expect that the most appropriate ideal semantics to handle this >>>> scenario >>>> would be to delay marking the parent object as being applied until >>>> every >>>> descendent child leaf with a default value set has a value applied in >>>> the system, either to the expected default value (in which case the >>>> child leaf wouldn't need to be present in the applied config), or >>>> transiently to another value (which would be in the applied config >>>> until >>>> the system updated and the correct default values have actually been >>>> applied). In real systems, I would have thought that the default >>>> values >>>> are often implicitly programmed when the parent containing object is >>>> created anyway, so I suspect that this behaviour wouldn't actually be >>>> that onerous to implement. >>> It appears to me that we run into those issues by requiring the intended >>> config to contain also the default values. That doesn¹t seem necessary. >>> I >> I can't see how you can have default values apply only to the applied >> configuration and not the intended configuration. The intended >> configuration cannot be correctly interpreted if you don't also consider >> the default values specified in the schema. > Given that servers nowadays cover a huge amount of functionality where > often only a subset is required by a client, I would consider quite a bit > of default values irrelevant for the scope of the client. If e.g. You plan > to use a router that supports VPLS, but you do not care since it is not > needed, those defaults can just be left to the server. YANG already takes care of this, as per RFC6020bis section 7.6.1, only the defaults that are in scope for your configuration are relevant. >>> would also argue that marking the Œapplied=intended¹ state per leaf is >>> counter-productive. Assume the client sets an intended state of two >>> values >> Tracking intended vs applied on a per leaf basis is the essence of the >> opstate requirements, please lets not rehash these all yet again. :-) > See above, you can do this but it’s quite a bit of work. The requirement > stems from a time where a client wasn’t able to figure out whether a leaf > has been changed already or was about to change in future. To me it > appears more of an implementation choice. I disagree. The requirements are from the perceived deficiencies in NETCONF/YANG that need to be fixed for operators to use YANG effectively. >>> (A,B) on two different leafs with rollback-on-error semantic. If >>> applying >>> A succeeds and the client reads the applied state while applying B is >>> still in progress, a rollback may still happen. That would invalidate >>> the >>> previous value of A. In other words it is unwise to read data from a >>> source while it is actually writing. >> No, this is fine, and isn't a problem. The server will eventually >> converge on a state and the client will be notified of that state. >> The >> fact that a client might temporarily see a valid state that is >> subsequently undone isn't a problem. > I’d seriously question those two statements. When the server is updating > its applied state you have at best a 50% chance to read the correct value. > What meaningful conclusion is the client supposed to take from that? Out > of desperation, current implementations use that ‘trick’ by polling > various leaf values to figure out whether an intended state has already > been applied or not. However such intensive polling cycles are no more > needed once a server notifies the client upon completion of intended state > application. > If the client chooses to read applied state during that period, it is at > least aware that the state is just a temporary snapshot. The client doesn't poll. Instead it registers for notification of changes and receives a continuous stream of updates. At any point in time, the value read by the client is correct, it just happens that the system can be thought of being in the state of constant flux. E.g. the global BGP routing table is constantly changing, but that doesn't mean that you can't take a useful snapshot of it, or monitor how it is changing. Thanks, Rob > >> Thanks, >> Rob >> >> >>>> Thanks, >>>> Rob >>>> >>>> >>>>> Lada >>>>> >>>>>> list interface { >>>>>> description-config >>>>>> "The list of configured interfaces on the device. >>>>>> ..."; >>>>>> description-oper >>>>>> "The list of interfaces on the device. >>>>>> >>>>>> System-controlled interfaces created by the system are >>>>>> always present in this list, whether they are configured or >>>>>> not. >>>>>> ..."; >>>>>> } >>>>>> >>>>>> >>>>>> /martin >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>> . >>> From nobody Tue Jan 12 11:26:20 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C651A8738 for ; Tue, 12 Jan 2016 11:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxMD4yCy48zC for ; Tue, 12 Jan 2016 11:26:18 -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 D8A4B1A8737 for ; Tue, 12 Jan 2016 11:26:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1126; q=dns/txt; s=iport; t=1452626777; x=1453836377; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=Jf5H3qfDLNwZuqwixHoxwJ61c1F9t14sEwAUMxLILKs=; b=XeLeRHu6tJLmj5ZXIUSF5WYlUx4IOkYrGMCPUjKzcvy99AAtCEabUFU/ A0EpDODjpxyiemNfVm62i0ymAdvLRhMZCI75RQDWWLRcQQQ9NiENhCTXn 5FxS4vEhO/10sMhowWAzHFgPOrnl59YEOnryH5zDsPRGE0AHoDjx/ngYR 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BiBQAwUpVW/4gNJK1egzqKGLMzgWSHP?= =?us-ascii?q?ToSAQEBAQEBAYEKhF4VQDYCBRYLAgsDAgECAUsNCAEBF4gTn2GPb5A7AQEBBwI?= =?us-ascii?q?BIIEBhVWMc4FJBZcTiDaFI4Feh0ojhTGOUykHNIQLPYZ4AQEB?= X-IronPort-AV: E=Sophos;i="5.22,285,1449532800"; d="scan'208";a="60803768" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Jan 2016 19:26:17 +0000 Received: from [10.24.150.212] ([10.24.150.212]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u0CJQCoK016161 for ; Tue, 12 Jan 2016 19:26:14 GMT To: NETMOD Working Group From: Benoit Claise Message-ID: <56955350.3090503@cisco.com> Date: Tue, 12 Jan 2016 20:26:08 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] AD review: draft-ietf-netmod-opstate-reqs X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 19:26:19 -0000 Dear all, I know that this draft is not yet on my table, but in order to speed up the process, I read v3. - Editorial: I see many instances of (see term) or (see terms). This doesn't add any value IMO. If there are some chance for misinterpretation of those terms, capitalize the terms specified in the terminology section. - Any reason why the "backwards compatibility" (section 3) is not numbered as a requirement in section 4? I.e. a new requirement 5. Or is it because it's a special requirement? Numbering all the requirements might ease the comparison of the 3 different proposed solutions. - There is a requirement in asynchronous configuration operations definition: Once applied, there MUST be a mechanism for the client to determine when the request has completed processing and whether the intended config is now fully effective or there are any errors from applying the configuration change, which could be from an asynchronous notification or via a client operation. Why isn't it a numbered requirement in section 4? Regards, Benoit From nobody Tue Jan 12 13:04:55 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 247CC1A1AA1 for ; Tue, 12 Jan 2016 13:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nl8s6OpCYfF for ; Tue, 12 Jan 2016 13:04:50 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0105.outbound.protection.outlook.com [207.46.100.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F551A1B56 for ; Tue, 12 Jan 2016 13:04:50 -0800 (PST) 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 (TLS) id 15.1.365.19; Tue, 12 Jan 2016 21:04:49 +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.0365.020; Tue, 12 Jan 2016 21:04:49 +0000 From: Kent Watsen To: Benoit Claise , "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-03.txt Thread-Index: AQHRSnjhPwhlEKSCNkWPsuBEQbmSJJ7yCYMAgASKWoD//+lYgIABUR0AgABCqAA= Date: Tue, 12 Jan 2016 21:04:49 +0000 Message-ID: <10A0280A-94E5-42B4-99D0-ABAAF05DC14B@juniper.net> References: <20160109005830.20805.41463.idtracker@ietfa.amsl.com> <5693E46D.7080707@cisco.com> <3474CCCD-1B8B-40B7-B3BF-C1164C144A8F@juniper.net> <5694EC36.8010103@cisco.com> In-Reply-To: <5694EC36.8010103@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151105 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-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 5:WjQzQe8qdM3Iq8SaHrwFalshUCwutBPcw186vWGlvGX9pdyjV16pTTSSpIoP3tW0QpCDrygkZ6yxZpzA789AxSnXqjJQ7xVgajBBlwlR3c/7RcMJ4Kaj9lX7EELUovsukF6FBI8F9JNxZZEb+Ma07Q==; 24:pHXm7VTPXSLvfMbLVvAnMAqP63zPK3nSV+KmzAz27GUS7ThscWKlqxp/N/n67A6vhTsE3UHAl7Q/90yGghRjHxuZ/GmKDzXI/3upi6JdZ3A= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1443; x-ms-office365-filtering-correlation-id: 0e15e929-bfb3-4c01-d163-08d31b940237 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 081904387B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(164054003)(106116001)(97736004)(2900100001)(105586002)(5001770100001)(11100500001)(106356001)(1096002)(86362001)(87936001)(1220700001)(81156007)(189998001)(5001960100002)(107886002)(99286002)(2950100001)(5002640100001)(101416001)(92566002)(5008740100001)(83716003)(83506001)(77096005)(66066001)(82746002)(6116002)(102836003)(5004730100002)(3846002)(4001350100001)(2501003)(33656002)(76176999)(50986999)(230783001)(36756003)(19580395003)(54356999)(19580405001)(16236675004)(93886004)(122556002)(10400500002)(2906002)(40100003)(586003)(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:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_10A0280A94E542B499D0ABAAF05DC14Bjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2016 21:04:49.2725 (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: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 21:04:54 -0000 --_000_10A0280A94E542B499D0ABAAF05DC14Bjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 W0FzIGEgY29udHJpYnV0b3JdDQoNCkZyb20gQmVub2l0Og0KDQpZZXMsIEkndmUgc2VlbiB0aG9z ZSBSRkNzLiBUaGUgSUVURiBpcyBub3QgcmVhbGx5IGNvbnNpc3RlbnQgcmVnYXJkaW5nIFJGQyAy MTE5IGFuZCByZXF1aXJlbWVudCBkb2N1bWVudHMuDQpTbyBJIHdhbnRlZCB0byBwdXQgdGhlIGlz c3VlIG9uIHRoZSB0YWJsZS4gTm8gc3Ryb25nIHZpZXcgb24gd2F5IG9yIHRoZSBvdGhlci4NCg0K W0tlbnRdIHRoYW5rcy4NCg0KDQpDaGFuZ2luZyB0aGUgTUFZIGtleXdvcmRzIHRoZSB3YXkgeW91 IHByb3Bvc2VkIGlzIG9uZSBzb2x1dGlvbiwNCg0KW0tlbnRdIG9rYXksIEkgd2lsbCBkbyB0aGF0 Lg0KDQoNCmJ1dCBtb3JlIGltcG9ydGFudGx5LCB5b3Ugc2hvdWxkIHRlbGwgdXMgd2hhdCBpcyBp bnRlbnQgYmVoaW5kIGEgTUFZIHNlbnRlbmNlIGlzLg0KU28gaXQgbWVhbnMgdGhhdCB0aGUgc3Bl Y2lmaWVkIHNvbHV0aW9uIE1BWSBvciBNQVkgbm90IGhhdmUgdGhpcyBmdW5jdGlvbmFsaXR5LCBy aWdodD8NCg0KW0tlbnRdIHllcywgdGhhdCBpcyBob3cgSSBhbSBpbnRlcnByZXRpbmcgaXQNCg0K DQpTbyB3aGF0IGlzIHRoZSByZXF1aXJlbWVudD8gTWF5YmUgaXQncyBub3QgYSByZXF1aXJlbWVu dCwgYnV0IGp1c3Qgc29tZXRoaW5nIHRvIHRoaW5rIGFib3V0Lg0KDQpbS2VudF0ganVzdCBzb21l dGhpbmcgdG8gdGhpbmsgYWJvdXQgSSBndWVzcy4gIEJ1dCBJIHdpbGwgY2hhbmdlIHRoZSB0d28g TUFZIGluc3RhbmNlcyBpbiB0aGUgZHJhZnQsIHNvIHdlIGRvbuKAmXQgbmVlZCB0byB3b3JyeSBh Ym91dCBpdCBhbnltb3JlICA7KQ0KDQoNClRoYW5rcywNCktlbnQNCg== --_000_10A0280A94E542B499D0ABAAF05DC14Bjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PltBcyBhIGNvbnRyaWJ1dG9yXTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+RnJv bSBCZW5vaXQ6PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1BQ19P VVRMT09LX1NJR05BVFVSRSI+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Plll cywgSSd2ZSBzZWVuIHRob3NlIFJGQ3MuIFRoZSBJRVRGIGlzIG5vdCByZWFsbHkgY29uc2lzdGVu dCByZWdhcmRpbmcgUkZDIDIxMTkgYW5kIHJlcXVpcmVtZW50IGRvY3VtZW50cy48L2Rpdj4NCjxz cGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2Pg0KPGRpdiBiZ2NvbG9yPSIjRkZG RkZGIiB0ZXh0PSIjMDAwMDAwIj5TbyBJIHdhbnRlZCB0byBwdXQgdGhlIGlzc3VlIG9uIHRoZSB0 YWJsZS4gTm8gc3Ryb25nIHZpZXcgb24gd2F5IG9yIHRoZSBvdGhlci48L2Rpdj4NCjwvZGl2Pg0K PC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+W0tlbnRdIHRoYW5rcy48L2Rpdj4NCjxz cGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2Pg0KPGRpdiBiZ2NvbG9yPSIjRkZG RkZGIiB0ZXh0PSIjMDAwMDAwIj48YnI+DQo8YmxvY2txdW90ZSBjaXRlPSJtaWQ6MzQ3NENDQ0Qt MUI4Qi00MEI3LUIzQkYtQzExNjRDMTQ0QThGQGp1bmlwZXIubmV0IiB0eXBlPSJjaXRlIj4NCjxw cmUgd3JhcD0iIj48L3ByZT4NCjwvYmxvY2txdW90ZT4NCkNoYW5naW5nIHRoZSBNQVkga2V5d29y ZHMgdGhlIHdheSB5b3UgcHJvcG9zZWQgaXMgb25lIHNvbHV0aW9uLCA8L2Rpdj4NCjwvZGl2Pg0K PC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+W0tlbnRdIG9rYXksIEkgd2lsbCBkbyB0 aGF0LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBp ZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdj4NCjxkaXYgYmdjb2xvcj0iI0ZGRkZGRiIg dGV4dD0iIzAwMDAwMCI+YnV0IG1vcmUgaW1wb3J0YW50bHksIHlvdSBzaG91bGQgdGVsbCB1cyB3 aGF0IGlzIGludGVudCBiZWhpbmQgYSBNQVkgc2VudGVuY2UgaXMuICZuYnNwOzwvZGl2Pg0KPC9k aXY+DQo8L3NwYW4+DQo8ZGl2PlNvIGl0IG1lYW5zIHRoYXQgdGhlIHNwZWNpZmllZCBzb2x1dGlv biBNQVkgb3IgTUFZIG5vdCBoYXZlIHRoaXMgZnVuY3Rpb25hbGl0eSwgcmlnaHQ/PC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5bS2VudF0geWVzLCB0aGF0IGlzIGhvdyBJIGFtIGludGVy cHJldGluZyBpdDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JP RFlfU0VDVElPTiI+DQo8ZGl2Pg0KPGRpdiBiZ2NvbG9yPSIjRkZGRkZGIiB0ZXh0PSIjMDAwMDAw Ij48YnI+DQpTbyB3aGF0IGlzIHRoZSByZXF1aXJlbWVudD8gTWF5YmUgaXQncyBub3QgYSByZXF1 aXJlbWVudCwgYnV0IGp1c3Qgc29tZXRoaW5nIHRvIHRoaW5rIGFib3V0Ljxicj4NCjwvZGl2Pg0K PC9kaXY+DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5bS2VudF0ganVzdCBzb21l dGhpbmcgdG8gdGhpbmsgYWJvdXQgSSBndWVzcy4gJm5ic3A7QnV0IEkgd2lsbCBjaGFuZ2UgdGhl IHR3byBNQVkgaW5zdGFuY2VzIGluIHRoZSBkcmFmdCwgc28gd2UgZG9u4oCZdCBuZWVkIHRvIHdv cnJ5IGFib3V0IGl0IGFueW1vcmUgJm5ic3A7Oyk8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXY+ DQo8ZGl2IGJnY29sb3I9IiNGRkZGRkYiIHRleHQ9IiMwMDAwMDAiPlRoYW5rcyw8L2Rpdj4NCjwv ZGl2Pg0KPC9zcGFuPg0KPGRpdj5LZW50PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_10A0280A94E542B499D0ABAAF05DC14Bjunipernet_-- From nobody Tue Jan 12 13:23:43 2016 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B9C1A8952 for ; Tue, 12 Jan 2016 13:23:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xU8TDsWbX2A8 for ; Tue, 12 Jan 2016 13:23:39 -0800 (PST) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 AEBC01A894A for ; Tue, 12 Jan 2016 13:23:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1452633819; bh=2klNNtw3HqQeTmFvJJAza2+GBGLXop0wOdo00I8QuO0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=asoq+V/khljrIWJZ1Uo+Gkd5xHJOO6l99q1qL68uBXoQwE9vlqKl+dlncoE1xwf9N /1j78CP+EvsxCSB5RIJz+2PZCj+x+s9ZlfS2+Grm9QA+yUQZajxow7x06EaOiDm5fG G7uwe51klTjNk44gmy3/x8LBDM1T3VXQLadrQSSE= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: multipart/alternative; boundary="Apple-Mail=_CF7DEAC2-7D3B-4EBD-BD3D-9874717B3E58" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Nadeau Thomas In-Reply-To: <10A0280A-94E5-42B4-99D0-ABAAF05DC14B@juniper.net> Date: Tue, 12 Jan 2016 16:23:36 -0500 Message-Id: <391975DB-5357-4D95-AECF-1A75E61BA5C0@lucidvision.com> References: <20160109005830.20805.41463.idtracker@ietfa.amsl.com> <5693E46D.7080707@cisco.com> <3474CCCD-1B8B-40B7-B3BF-C1164C144A8F@juniper.net> <5694EC36.8010103@cisco.com> <10A0280A-94E5-42B4-99D0-ABAAF05DC14B@juniper.net> To: Kent Watsen X-Mailer: Apple Mail (2.3112) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=11 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 243, in=3038, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 21:23:41 -0000 --Apple-Mail=_CF7DEAC2-7D3B-4EBD-BD3D-9874717B3E58 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 12, 2016:4:04 PM, at 4:04 PM, Kent Watsen = wrote: >=20 > [As a contributor] >=20 > =46rom Benoit: >=20 > Yes, I've seen those RFCs. The IETF is not really consistent regarding = RFC 2119 and requirement documents. > So I wanted to put the issue on the table. No strong view on way or = the other. >=20 > [Kent] thanks. >=20 > Changing the MAY keywords the way you proposed is one solution, >=20 > [Kent] okay, I will do that. I=E2=80=99ve also used lower-case =E2=80=9Cmay=E2=80=9D as well, = to mean something less stricter. But Benoit is right in that in a requirements document we should really use MUST and SHOULD but not = MAY. A quick=20 perusal of a few random RFCs containing WG requirements confirms this - = at least with the sample I used. > but more importantly, you should tell us what is intent behind a MAY = sentence is. =20 > So it means that the specified solution MAY or MAY not have this = functionality, right? >=20 > [Kent] yes, that is how I am interpreting it It might be clearer to use SHOULD (or SHOULD NOT) instead of MAY = or MAY NOT. >=20 >=20 > So what is the requirement? Maybe it's not a requirement, but just = something to think about. >=20 > [Kent] just something to think about I guess. But I will change the = two MAY instances in the draft, so we don=E2=80=99t need to worry about = it anymore ;) >=20 >=20 > Thanks, > Kent > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_CF7DEAC2-7D3B-4EBD-BD3D-9874717B3E58 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jan 12, 2016:4:04 PM, at 4:04 PM, Kent Watsen <kwatsen@juniper.net>= wrote:

[As a contributor]

=46rom Benoit:

Yes, I've seen those RFCs. The IETF is not really = consistent regarding RFC 2119 and requirement documents.
So I wanted to put = the issue on the table. No strong view on way or the other.

[Kent] thanks.




Changing the MAY keywords the way you proposed is one solution, 










[Kent] okay, I will do =
that.

	I=E2=80=99v=
e also used lower-case =E2=80=9Cmay=E2=80=9D as well, to mean something =
less stricter. But Benoit is right in that
in a requirements =
document we should really use MUST and SHOULD but not MAY. A =
quick 
perusal of a few random RFCs containing WG =
requirements confirms this - at least with the
sample I =
used.



but more importantly, you should tell us what is intent =
behind a MAY sentence is.  


So it means that the specified solution MAY or MAY not =
have this functionality, right?







[Kent] yes, that is how I am interpreting =
it

	It might =
be clearer to use SHOULD (or SHOULD NOT) instead of MAY or MAY NOT.












So what is the requirement? Maybe it's not a requirement, but just =
something to think about.












[Kent] just something to think about I guess.  But =
I will change the two MAY instances in the draft, so we don=E2=80=99t =
need to worry about it anymore  ;)















Thanks,





Kent




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

=

--Apple-Mail=_CF7DEAC2-7D3B-4EBD-BD3D-9874717B3E58--


From nobody Tue Jan 12 13:31:24 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644991A89C7 for ; Tue, 12 Jan 2016 13:31:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYQtzqjG1Wbt for ; Tue, 12 Jan 2016 13:31:10 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0765.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:765]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85CA11A89A5 for ; Tue, 12 Jan 2016 13:31:10 -0800 (PST)
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 (TLS) id 15.1.365.19; Tue, 12 Jan 2016 21:30:53 +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.0365.020; Tue, 12 Jan 2016 21:30:53 +0000
From: Kent Watsen 
To: Benoit Claise , NETMOD Working Group 
Thread-Topic: [netmod] AD review: draft-ietf-netmod-opstate-reqs
Thread-Index: AQHRTW8fW/OO7tGDC0mOYFzy2NWXXJ74ElSA
Date: Tue, 12 Jan 2016 21:30:53 +0000
Message-ID: 
References: <56955350.3090503@cisco.com>
In-Reply-To: <56955350.3090503@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.151105
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-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 5:t0/+mrFd1cs7YE0iTjWlASNJTE7jsrok5w2ROdJTyLSFl+2SXXxafwz3Y+wG7LCuSiLa17mEp5U3dpEH/LKDJvqc56E9X4MuJNB5JUPwglCqkG0ShYC3NjKDsK6zG/UtbEeKoi5ZY2hopOoE3Tc6qA==; 24:C0WEYLSkMToKJErbjgXskmSnBjEJV2lHaz1cy7JvnwT2E3gzxupAHoIeQc5OSIjcqGpvx0zIJvbYaGVlIw+CdWJUgVi5LIS6xcdYrNYLxWA=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1442;
x-ms-office365-filtering-correlation-id: da545316-7460-4366-a1b2-08d31b97a668
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001)(10201501046); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; 
x-forefront-prvs: 081904387B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(43784003)(189002)(99286002)(102836003)(50986999)(36756003)(10400500002)(76176999)(1096002)(3846002)(5004730100002)(586003)(106116001)(82746002)(5008740100001)(5001770100001)(4001350100001)(106356001)(83506001)(122556002)(2906002)(97736004)(11100500001)(92566002)(1220700001)(83716003)(66066001)(5001960100002)(107886002)(81156007)(6116002)(2950100001)(86362001)(189998001)(101416001)(33656002)(230783001)(2900100001)(40100003)(105586002)(5002640100001)(54356999)(77096005)(87936001)(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:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <57E8CBB2EA30024081C0219BE5C9EEB6@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2016 21:30:53.3071 (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: Re: [netmod] AD review: draft-ietf-netmod-opstate-reqs
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Jan 2016 21:31:21 -0000

DQpbQXMgYSBjb250cmlidXRvcl0NCg0KSGkgQmVub2l0LA0KDQpUaGFuayB5b3UgZm9yIHlvdXIg
cHJvYWN0aXZlIEFEIHJldmlldy4gIEJlbG93IGFyZSBteSByZXNwb25zZXMgdG8geW91ciBjb21t
ZW50cy4NCg0KDQo+LSBFZGl0b3JpYWw6IEkgc2VlIG1hbnkgaW5zdGFuY2VzIG9mIChzZWUgdGVy
bSkgb3IgKHNlZSB0ZXJtcykuDQo+VGhpcyBkb2Vzbid0IGFkZCBhbnkgdmFsdWUgSU1PLg0KPklm
IHRoZXJlIGFyZSBzb21lIGNoYW5jZSBmb3IgbWlzaW50ZXJwcmV0YXRpb24gb2YgdGhvc2UgdGVy
bXMsIA0KPmNhcGl0YWxpemUgdGhlIHRlcm1zIHNwZWNpZmllZCBpbiB0aGUgdGVybWlub2xvZ3kg
c2VjdGlvbi4NCg0KSSByZW1vdmVkIOKAnChzZWUgdGVybVtzXSnigJ0gZnJvbSBteSBsb2NhbCBj
b3B5LiAgSSB2aWV3IHRoaXMgYXMgYW4gZWRpdG9yaWFsIGNoYW5nZS4NCg0KDQoNCj4tIEFueSBy
ZWFzb24gd2h5IHRoZSAiYmFja3dhcmRzIGNvbXBhdGliaWxpdHkiIChzZWN0aW9uIDMpIGlzIG5v
dCANCj5udW1iZXJlZCBhcyBhIHJlcXVpcmVtZW50IGluIHNlY3Rpb24gND8gIEkuZS4gYSBuZXcg
cmVxdWlyZW1lbnQgNS4gT3IgaXMgDQo+aXQgYmVjYXVzZSBpdCdzIGEgc3BlY2lhbCByZXF1aXJl
bWVudD8NCj5OdW1iZXJpbmcgYWxsIHRoZSByZXF1aXJlbWVudHMgbWlnaHQgZWFzZSB0aGUgY29t
cGFyaXNvbiBvZiB0aGUgMyANCj5kaWZmZXJlbnQgcHJvcG9zZWQgc29sdXRpb25zLg0KDQpGV0lX
LCB0aGUgQmFja3dhcmRzIENvbXBhdGliaWxpdHkgc2VjdGlvbiB3YXMgbm90IGluaXRpYWxseSBp
bmNvcnBvcmF0ZWQgaW50byB0aGUgUmVxdWlyZW1lbnRzIHNlY3Rpb24gYmVjYXVzZSBpdCBzZWVt
ZWQgbW9yZSBsaWtlIGFuIGltcGxpY2l0L2dlbmVyaWMgcmVxdWlyZW1lbnQsIG5vdCBhIHNvbHV0
aW9uLXNwZWNpZmljIHJlcXVpcmVtZW50LiAgIFRoYXQgc2FpZCwgSSBoYXZlIHRvIGFncmVlIHRo
YXQgaXQgd291bGQgaGVscCByZXZpZXdzLiAgRm9yIGluc3RhbmNlLCB3aGVuIHRyeWluZyB0byBk
ZXRlcm1pbmUgaG93IGEgc29sdXRpb24gc2F0aXNmaWVzIGVhY2ggcmVxdWlyZW1lbnQsIGl0IHdv
dWxkIGJlIGVhc2llciB0byBoYXZlIOKAnEJhY2t3YXJkcyBDb21wYXRpYmlsaXR54oCdIGZvbGRl
ZCBpbnRvIHRoZSBSZXF1aXJlbWVudHMg4oCcdHJlZeKAnSwgcmF0aGVyIHRoYW4gaGF2aW5nIHRv
IGNhbGwgaXQgb3V0IHNwZWNpYWwuICBTbywgaWYgbm8gb25lIG9iamVjdHMsIEkgd2lsbCBtYWtl
IHRoaXMgY2hhbmdlIHRvbW9ycm93Lg0KDQoNCj4tIFRoZXJlIGlzIGEgcmVxdWlyZW1lbnQgaW4g
YXN5bmNocm9ub3VzIGNvbmZpZ3VyYXRpb24gb3BlcmF0aW9ucyANCj5kZWZpbml0aW9uOg0KPiAg
ICAgICAgT25jZSBhcHBsaWVkLCB0aGVyZSBNVVNUIGJlIGEgbWVjaGFuaXNtIGZvciB0aGUgY2xp
ZW50DQo+ICAgICAgICB0byBkZXRlcm1pbmUgd2hlbiB0aGUgcmVxdWVzdCBoYXMgY29tcGxldGVk
IHByb2Nlc3NpbmcgYW5kDQo+ICAgICAgICB3aGV0aGVyIHRoZSBpbnRlbmRlZCBjb25maWcgaXMg
bm93IGZ1bGx5IGVmZmVjdGl2ZSBvciB0aGVyZSBhcmUNCj4gICAgICAgIGFueSBlcnJvcnMgZnJv
bSBhcHBseWluZyB0aGUgY29uZmlndXJhdGlvbiBjaGFuZ2UsIHdoaWNoIGNvdWxkIGJlDQo+ICAg
ICAgICBmcm9tIGFuIGFzeW5jaHJvbm91cyBub3RpZmljYXRpb24gb3IgdmlhIGEgY2xpZW50IG9w
ZXJhdGlvbi4NCj4NCj5XaHkgaXNuJ3QgaXQgYSBudW1iZXJlZCByZXF1aXJlbWVudCBpbiBzZWN0
aW9uIDQ/DQoNCkdvb2QgcG9pbnQsIGl0IGRvZXMgcmVhZCBsaWtlIGEgcmVxdWlyZW1lbnQgbW9y
ZSBzbyB0aGFuIGEgdGVybS4gICBJIG5vdGUgdGhhdCByZXF1aXJlbWVudCAyLUIgaGFzIG92ZXJs
YXAgd2l0aCB0aGUgIm9yIHZpYSBhIGNsaWVudCBvcGVyYXRpb24iIGNsYXVzZSwgc28gSSB0aGlu
ayBpdCBtYWtlcyBzZW5zZSB0byBtb3ZlIHRoaXMgdGV4dCBpbnRvIHJlcXVpcmVtZW50IDItQi4g
IEFnYWluLCBpZiBubyBvbmUgb2JqZWN0cywgSSB3aWxsIG1ha2UgdGhpcyBjaGFuZ2UgdG9tb3Jy
b3cuDQoNCg0KDQpUaGFua3MgYWdhaW4sDQpLZW50DQoNCg0KDQo=


From nobody Tue Jan 12 23:32:28 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D261A9132 for ; Tue, 12 Jan 2016 23:32:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlpl2EBHSbSU for ; Tue, 12 Jan 2016 23:32:23 -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 4CCF51A90C9 for ; Tue, 12 Jan 2016 23:32:22 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8D263733; Wed, 13 Jan 2016 08:32:20 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id eUqPkN6vzns2; Wed, 13 Jan 2016 08:32:20 +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, 13 Jan 2016 08:32:20 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E05EA2002B; Wed, 13 Jan 2016 08:32:19 +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 kHvdiAOoAVDy; Wed, 13 Jan 2016 08:32: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 70EFB20013; Wed, 13 Jan 2016 08:32:18 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 87A2639832C0; Wed, 13 Jan 2016 08:32:17 +0100 (CET)
Date: Wed, 13 Jan 2016 08:32:17 +0100
From: Juergen Schoenwaelder 
To: Nadeau Thomas 
Message-ID: <20160113073217.GA7305@elstar.local>
Mail-Followup-To: Nadeau Thomas , Kent Watsen , "netmod@ietf.org" 
References: <20160109005830.20805.41463.idtracker@ietfa.amsl.com>  <5693E46D.7080707@cisco.com> <3474CCCD-1B8B-40B7-B3BF-C1164C144A8F@juniper.net> <5694EC36.8010103@cisco.com> <10A0280A-94E5-42B4-99D0-ABAAF05DC14B@juniper.net> <391975DB-5357-4D95-AECF-1A75E61BA5C0@lucidvision.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <391975DB-5357-4D95-AECF-1A75E61BA5C0@lucidvision.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-03.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Jan 2016 07:32:25 -0000

On Tue, Jan 12, 2016 at 04:23:36PM -0500, Nadeau Thomas wrote:
> 
> 
> 	It might be clearer to use SHOULD (or SHOULD NOT) instead of MAY or MAY NOT.
> 

In RFC 2119, MAY and SHOULD mean two very different things so you
can't simply change MAY to SHOULD without likely going through another
round of discussion.

/js

PS: Noting that something is "truly optional" (MAY) in a requirements
    is a way of making it explicit that something is not a requirement.
    Having documented agreement on non-requirements is almost as
    useful as agreement on requirements so I do not follow the logic a
    requirements document should not have MAYs.

-- 
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 13 01:06:37 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330FF1ACCE5 for ; Wed, 13 Jan 2016 01:06:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgpwciaTq6jE for ; Wed, 13 Jan 2016 01:06:32 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id B67C71ACCE0 for ; Wed, 13 Jan 2016 01:06:32 -0800 (PST)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 35DAD1CC0337; Wed, 13 Jan 2016 10:06:36 +0100 (CET)
From: Ladislav Lhotka 
To: Martin Bjorklund , andy@yumaworks.com
In-Reply-To: <20160108.135736.371521840025425.mbj@tail-f.com>
References:  <20160108.135736.371521840025425.mbj@tail-f.com>
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Wed, 13 Jan 2016 10:06:30 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] action-stmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Jan 2016 09:06:35 -0000

Martin Bjorklund  writes:

> Hi,
>
> Andy Bierman  wrote:
>> Hi,
>> 
>> The action-stmt example on page 27 is wrong.
>> The  element is missing.  It is shown correctly
>> on page 105.
>> p27
>>   >           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>>        
>>          eth1
>>          
>>            192.0.2.1
>>          
>>        
>>      
>> 
>> 
>> p105
>> 
>>      >           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>>        
>>          
>>            apache-1
>>            
>>              2014-07-29T13:42:00Z
>>            
>>          
>>        
>>      
>
> Fixed.
>
>> Sec. 7.15  provides few details wrt/ input processing.
>> Extra input is ignored? (draft is silent about that).
>> YANG attributes like "insert"or "operation" are ignored? (also silent).
>
> Right, just as the text for rpcs.  Do you think we need to add some
> text about this?
>
>> Sec 7.15.2, para 2 is not clear whether the XML hierarchy
>> has to exist in any particular datastore (or opstate).
>> Since there is no mention of datastores in 7.15, I
>> assume the text just refers to the input containing
>> schema-valid XML, which may or may not correspond
>> to actual data instances somewhere inn the server.
>
> Yes.

Hmm, so if I understand in correctly, actions can be attached also to
state data nodes. But sec. 7.15.2 says: "For lists, all key leafs MUST
also be included." What if a list in state data has no keys?

Lada

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

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


From nobody Wed Jan 13 02:31:01 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8EBC1A1A7D for ; Wed, 13 Jan 2016 02:30:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBVdnF72YSen for ; Wed, 13 Jan 2016 02:30:58 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7C31A1A7C for ; Wed, 13 Jan 2016 02:30:58 -0800 (PST)
Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id 9180D1AE0A54; Wed, 13 Jan 2016 11:30:57 +0100 (CET)
Date: Wed, 13 Jan 2016 11:31:04 +0100 (CET)
Message-Id: <20160113.113104.343612206142993990.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References:  <20160108.135736.371521840025425.mbj@tail-f.com> 
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] action-stmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Jan 2016 10:30:59 -0000

Ladislav Lhotka  wrote:
> Martin Bjorklund  writes:
> 
> > Hi,
> >
> > Andy Bierman  wrote:
> >> Hi,
> >> 
> >> The action-stmt example on page 27 is wrong.
> >> The  element is missing.  It is shown correctly
> >> on page 105.
> >> p27
> >>    >>           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >>        
> >>          eth1
> >>          
> >>            192.0.2.1
> >>          
> >>        
> >>      
> >> 
> >> 
> >> p105
> >> 
> >>       >>           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >>        
> >>          
> >>            apache-1
> >>            
> >>              2014-07-29T13:42:00Z
> >>            
> >>          
> >>        
> >>      
> >
> > Fixed.
> >
> >> Sec. 7.15  provides few details wrt/ input processing.
> >> Extra input is ignored? (draft is silent about that).
> >> YANG attributes like "insert"or "operation" are ignored? (also silent).
> >
> > Right, just as the text for rpcs.  Do you think we need to add some
> > text about this?
> >
> >> Sec 7.15.2, para 2 is not clear whether the XML hierarchy
> >> has to exist in any particular datastore (or opstate).
> >> Since there is no mention of datastores in 7.15, I
> >> assume the text just refers to the input containing
> >> schema-valid XML, which may or may not correspond
> >> to actual data instances somewhere inn the server.
> >
> > Yes.
> 
> Hmm, so if I understand in correctly, actions can be attached also to
> state data nodes.

Correct.  But actually, I think that the data node instance that has
the action must exist at the time the action is applied.

> But sec. 7.15.2 says: "For lists, all key leafs MUST
> also be included." What if a list in state data has no keys?

No keys means that "all keys" is the empty set.


/martin


From nobody Wed Jan 13 02:52:07 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 641311A21B3 for ; Wed, 13 Jan 2016 02:52:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.352
X-Spam-Level: 
X-Spam-Status: No, score=-5.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sv6XYXyBLCYT for ; Wed, 13 Jan 2016 02:52:04 -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 E89A61A21A3 for ; Wed, 13 Jan 2016 02:52:03 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:193b:4fd8:2a5a:e737] (unknown [IPv6:2001:718:1a02:1:193b:4fd8:2a5a:e737]) by mail.nic.cz (Postfix) with ESMTPSA id 7BEE9181BD0; Wed, 13 Jan 2016 11:52:02 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452682322; bh=xgW30wqhZamqlYv9jQEp5AU6S1HFjrkY5zq/bwaVi6c=; h=From:Date:To; b=iE3X2gHazKquTkEDCSAR0Iag3DN4OQ0O4ka1OTeemIMBW057oeknd9LCCK5uT8i4V wcCEID75Q+U9OP819yx06obeHq74TA8dhYApvmnvv52T45GbMUhTeTe91kqrFzHgaG Mfaa0HVHERbYvTpGzwjVWZcLW+3kfXizbcowEVAc=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: <20160113.113104.343612206142993990.mbj@tail-f.com>
Date: Wed, 13 Jan 2016 11:52:03 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <4019146D-CBAA-498A-AB70-2E376807E729@nic.cz>
References:  <20160108.135736.371521840025425.mbj@tail-f.com>  <20160113.113104.343612206142993990.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] action-stmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Jan 2016 10:52:05 -0000

> On 13 Jan 2016, at 11:31, Martin Bjorklund  wrote:
>=20
> Ladislav Lhotka  wrote:
>> Martin Bjorklund  writes:
>>=20
>>> Hi,
>>>=20
>>> Andy Bierman  wrote:
>>>> Hi,
>>>>=20
>>>> The action-stmt example on page 27 is wrong.
>>>> The  element is missing.  It is shown correctly
>>>> on page 105.
>>>> p27
>>>>  >>>          xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
>>>>       
>>>>         eth1
>>>>         
>>>>           192.0.2.1
>>>>         
>>>>       
>>>>     
>>>>=20
>>>>=20
>>>> p105
>>>>=20
>>>>     >>>          xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
>>>>       
>>>>         
>>>>           apache-1
>>>>           
>>>>             2014-07-29T13:42:00Z
>>>>           
>>>>         
>>>>       
>>>>     
>>>=20
>>> Fixed.
>>>=20
>>>> Sec. 7.15  provides few details wrt/ input processing.
>>>> Extra input is ignored? (draft is silent about that).
>>>> YANG attributes like "insert"or "operation" are ignored? (also =
silent).
>>>=20
>>> Right, just as the text for rpcs.  Do you think we need to add some
>>> text about this?
>>>=20
>>>> Sec 7.15.2, para 2 is not clear whether the XML hierarchy
>>>> has to exist in any particular datastore (or opstate).
>>>> Since there is no mention of datastores in 7.15, I
>>>> assume the text just refers to the input containing
>>>> schema-valid XML, which may or may not correspond
>>>> to actual data instances somewhere inn the server.
>>>=20
>>> Yes.
>>=20
>> Hmm, so if I understand in correctly, actions can be attached also to
>> state data nodes.
>=20
> Correct.  But actually, I think that the data node instance that has
> the action must exist at the time the action is applied.

OK.

>=20
>> But sec. 7.15.2 says: "For lists, all key leafs MUST
>> also be included." What if a list in state data has no keys?
>=20
> No keys means that "all keys" is the empty set.

How does the server then select the list entry to which the action is to =
be applied?

Lada

>=20
>=20
> /martin

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





From nobody Wed Jan 13 03:07:23 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 246731A6F9F for ; Wed, 13 Jan 2016 03:07:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGa1XjIEK3h8 for ; Wed, 13 Jan 2016 03:07:19 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8277D1A6F9B for ; Wed, 13 Jan 2016 03:07:19 -0800 (PST)
Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id C437E1AE0A54; Wed, 13 Jan 2016 12:07:18 +0100 (CET)
Date: Wed, 13 Jan 2016 12:07:25 +0100 (CET)
Message-Id: <20160113.120725.2066939247728231437.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: <4019146D-CBAA-498A-AB70-2E376807E729@nic.cz>
References:  <20160113.113104.343612206142993990.mbj@tail-f.com> <4019146D-CBAA-498A-AB70-2E376807E729@nic.cz>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] action-stmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Jan 2016 11:07:21 -0000

Ladislav Lhotka  wrote:
> 
> > On 13 Jan 2016, at 11:31, Martin Bjorklund  wrote:
> > 
> > Ladislav Lhotka  wrote:
> >> Martin Bjorklund  writes:
> >> 
> >>> Hi,
> >>> 
> >>> Andy Bierman  wrote:
> >>>> Hi,
> >>>> 
> >>>> The action-stmt example on page 27 is wrong.
> >>>> The  element is missing.  It is shown correctly
> >>>> on page 105.
> >>>> p27
> >>>>   >>>>          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >>>>       
> >>>>         eth1
> >>>>         
> >>>>           192.0.2.1
> >>>>         
> >>>>       
> >>>>     
> >>>> 
> >>>> 
> >>>> p105
> >>>> 
> >>>>      >>>>          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >>>>       
> >>>>         
> >>>>           apache-1
> >>>>           
> >>>>             2014-07-29T13:42:00Z
> >>>>           
> >>>>         
> >>>>       
> >>>>     
> >>> 
> >>> Fixed.
> >>> 
> >>>> Sec. 7.15  provides few details wrt/ input processing.
> >>>> Extra input is ignored? (draft is silent about that).
> >>>> YANG attributes like "insert"or "operation" are ignored? (also silent).
> >>> 
> >>> Right, just as the text for rpcs.  Do you think we need to add some
> >>> text about this?
> >>> 
> >>>> Sec 7.15.2, para 2 is not clear whether the XML hierarchy
> >>>> has to exist in any particular datastore (or opstate).
> >>>> Since there is no mention of datastores in 7.15, I
> >>>> assume the text just refers to the input containing
> >>>> schema-valid XML, which may or may not correspond
> >>>> to actual data instances somewhere inn the server.
> >>> 
> >>> Yes.
> >> 
> >> Hmm, so if I understand in correctly, actions can be attached also to
> >> state data nodes.
> > 
> > Correct.  But actually, I think that the data node instance that has
> > the action must exist at the time the action is applied.
> 
> OK.
> 
> > 
> >> But sec. 7.15.2 says: "For lists, all key leafs MUST
> >> also be included." What if a list in state data has no keys?
> > 
> > No keys means that "all keys" is the empty set.
> 
> How does the server then select the list entry to which the action
> is to be applied? 

Sorry, I missed this point.  You are correct.  Invoking an action in a
descendant node to a list w/o keys is not possible.


/martin




From nobody Wed Jan 13 03:33:14 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314941A7022 for ; Wed, 13 Jan 2016 03:33:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iKJQw_Pl4jh for ; Wed, 13 Jan 2016 03:33:08 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0126.outbound.protection.outlook.com [207.46.100.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C4D41A7020 for ; Wed, 13 Jan 2016 03:33:08 -0800 (PST)
Received: from CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) by CY1PR0501MB1610.namprd05.prod.outlook.com (10.161.162.139) with Microsoft SMTP Server (TLS) id 15.1.361.13; Wed, 13 Jan 2016 11:33:05 +0000
Received: from CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) by CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) with mapi id 15.01.0361.006; Wed, 13 Jan 2016 11:33:05 +0000
From: Gert Grammel 
To: Robert Wilton , Ladislav Lhotka , "Martin Bjorklund" 
Thread-Topic: [netmod] applied configuration and system-controlled entries
Thread-Index: AQHRSTUGxYtkEO44aUCWX59qiQKmfp72U6BggAAN6lSAAASVAIAACKQAgAAKfoCAAE7WgIAA1lGAgAASmgCAABk5AIAAJ7gAgAAxxICAAAl5gIABPXqA
Date: Wed, 13 Jan 2016 11:33:04 +0000
Message-ID: 
References:  <5693C32E.7020708@cisco.com> <31E9D485-9349-448D-99A3-DD20F5E5AF09@nic.cz> <20160111.211837.377848045119250710.mbj@tail-f.com>  <5694D180.6030300@cisco.com>  <569507FA.1070805@cisco.com>  <569539AB.80007@cisco.com>
In-Reply-To: <569539AB.80007@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.5.9.151119
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [193.110.55.13]
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1610; 5:lGDcrT7Nd/7NFvc3FcVsBQ6XEw0S7tcLQb8lhf7bfT66kwbhklkRFhIIk08kq6OIvcDOoutqJkZoY5UrjWjDdO+pOhAumYY8IGh8/q9rl5bA1fHzkqL3qGm2h/FOP+M/4AsaNAd4ZeM0tSuR+y7d+w==; 24:MzYF5uX+58a0IhlEG+5aVZ6rmsOGhdrhcqaLrsRMhoPp9AAt2za74FSxyEx8KociQwOpdGpIw6roYSUA7WgxtYjlcrtfb6I1GNVSolDP3D0=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1610;
x-ms-office365-filtering-correlation-id: d97f05f1-19fc-4859-d429-08d31c0d4da2
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:CY1PR0501MB1610; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1610; 
x-forefront-prvs: 08200063E9
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(377424004)(55674003)(189002)(52314003)(24454002)(164054003)(51444003)(199003)(86362001)(122556002)(40100003)(101416001)(99286002)(93886004)(97736004)(106116001)(5002640100001)(66066001)(106356001)(36756003)(87936001)(105586002)(5001770100001)(19580405001)(4001350100001)(81156007)(83506001)(92566002)(3846002)(2906002)(586003)(19580395003)(4326007)(1096002)(2950100001)(5008740100001)(102836003)(189998001)(2900100001)(1220700001)(5001960100002)(11100500001)(6116002)(15975445007)(54356999)(76176999)(50986999)(77096005)(5004730100002)(10400500002)(94096001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1610; H:CY1PR0501MB1609.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:23
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: 13 Jan 2016 11:33:04.9384 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1610
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] applied configuration and system-controlled entries
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Jan 2016 11:33:13 -0000

DQoNCk9uIDIwMTYtMTItMDEgMTg6MzYsICJSb2JlcnQgV2lsdG9uIiA8cndpbHRvbkBjaXNjby5j
b20+IHdyb3RlOg0KDQo+DQo+DQo+T24gMTIvMDEvMjAxNiAxNjowMiwgR2VydCBHcmFtbWVsIHdy
b3RlOg0KPj4NCj4+IE9uIDIwMTYtMTItMDEgMTU6MDQsICJSb2JlcnQgV2lsdG9uIiA8cndpbHRv
bkBjaXNjby5jb20+IHdyb3RlOg0KPj4NCj4+Pg0KPj4+IE9uIDEyLzAxLzIwMTYgMTA6NDIsIEdl
cnQgR3JhbW1lbCB3cm90ZToNCj4+Pj4gT24gMjAxNi0xMi0wMSAxMToxMiwgIm5ldG1vZCBvbiBi
ZWhhbGYgb2YgUm9iZXJ0IFdpbHRvbiINCj4+Pj4gPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9u
IGJlaGFsZiBvZiByd2lsdG9uQGNpc2NvLmNvbT4gd3JvdGU6DQo+Pj4+DQo+Pj4+PiBPbiAxMi8w
MS8yMDE2IDA5OjA1LCBMYWRpc2xhdiBMaG90a2Egd3JvdGU6DQo+Pj4+Pj4gTWFydGluIEJqb3Jr
bHVuZCA8bWJqQHRhaWwtZi5jb20+IHdyaXRlczoNCj4+Pj4+Pg0KPj4+Pj4+PiBMYWRpc2xhdiBM
aG90a2EgPGxob3RrYUBuaWMuY3o+IHdyb3RlOg0KPj4+Pj4+Pj4+IE9uIDExIEphbiAyMDE2LCBh
dCAxNTo1OCwgUm9iZXJ0IFdpbHRvbiA8cndpbHRvbkBjaXNjby5jb20+DQo+Pj4+Pj4+Pj53cm90
ZToNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBPbiAxMS8wMS8y
MDE2IDE0OjI3LCBMYWRpc2xhdiBMaG90a2Egd3JvdGU6DQo+Pj4+Pj4+Pj4+PiBPbiAxMSBKYW4g
MjAxNiwgYXQgMTU6MTEsIEp1ZXJnZW4gU2Nob2Vud2FlbGRlcg0KPj4+Pj4+Pj4+Pj4gPGouc2No
b2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQo+Pj4+Pj4+Pj4+Pg0KPj4+
Pj4+Pj4+Pj4gT24gTW9uLCBKYW4gMTEsIDIwMTYgYXQgMDI6NTQ6MzZQTSArMDEwMCwgTWFydGlu
IEJqb3JrbHVuZA0KPj4+Pj4+Pj4+Pj53cm90ZToNCj4+Pj4+Pj4+Pj4+PiBMYWRpc2xhdiBMaG90
a2EgPGxob3RrYUBuaWMuY3o+IHdyb3RlOg0KPj4+Pj4+Pj4+Pj4+PiBIaSBHZXJ0LA0KPj4+Pj4+
Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4gT24gMTEgSmFuIDIwMTYsIGF0IDE0OjI1LCBHZXJ0IEdy
YW1tZWwNCj4+Pj4+Pj4+Pj4+Pj4+PGdncmFtbWVsQGp1bmlwZXIubmV0Pg0KPj4+Pj4+Pj4+Pj4+
Pj4gd3JvdGU6DQo+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4gTGFkYSwNCj4+Pj4+Pj4+
Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+PiBUaGUgcmVxdWlyZW1lbnQgc2F5czoNCj4+Pj4+Pj4+Pj4+
Pj4+ICAgICAgICAgRC4gIFdoZW4gYSBjb25maWd1cmF0aW9uIGNoYW5nZSBmb3IgYW55IGludGVu
ZGVkDQo+Pj4+Pj4+Pj4+Pj4+PiBjb25maWd1cmF0aW9uDQo+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAg
ICAgICBub2RlIGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBhcHBsaWVkIHRvIHRoZSBzZXJ2ZXINCj4+
Pj4+Pj4+Pj4+Pj4+IChlLmcuIG5vdA0KPj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgZmFpbGVk
LCBub3IgZGVmZXJyZWQgZHVlIHRvIGFic2VudCBoYXJkd2FyZSkNCj4+Pj4+Pj4+Pj4+Pj4+dGhl
bg0KPj4+Pj4+Pj4+Pj4+Pj4gdGhlDQo+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICBleGlzdGVu
Y2UgYW5kIHZhbHVlIG9mIHRoZSBjb3JyZXNwb25kaW5nIGFwcGxpZWQNCj4+Pj4+Pj4+Pj4+Pj4+
ICAgICAgICAgICAgIGNvbmZpZ3VyYXRpb24gbm9kZSBtdXN0IG1hdGNoIHRoZSBpbnRlbmRlZA0K
Pj4+Pj4+Pj4+Pj4+Pj4gY29uZmlndXJhdGlvbg0KPj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAg
bm9kZS4NCj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+PiBJIGRvbid0IHNlZSB0aGF0IHRo
aXMgd291bGQgbGltaXQgdGhlIGNhc2UgeW91IGRlc2NyaWJlZA0KPj4+Pj4+Pj4+Pj4+Pj4gYmVs
b3cuDQo+Pj4+Pj4+Pj4+Pj4+PiBJbg0KPj4+Pj4+Pj4+Pj4+Pj4geW91ciBjYXNlIHRoZXJlIGlz
IG5vIGludGVuZGVkIGNvbmZpZywgaGVuY2UgdGhlcmUgaXMgbm8NCj4+Pj4+Pj4+Pj4+Pj4+ICJj
b3JyZXNwb25kaW5nIGFwcGxpZWQgY29uZmlndXJhdGlvbiIgZWl0aGVyLg0KPj4+Pj4+Pj4+Pj4+
PiBZb3UgYXJlIHJpZ2h0LCB0aGUgcmVxdWlyZW1lbnQgY2FuIGJlIGludGVycHJldGVkIHRoaXMg
d2F5LiBJDQo+Pj4+Pj4+Pj4+Pj4+IHRob3VnaHQNCj4+Pj4+Pj4+Pj4+Pj4gdGhhdCBhcHBsaWVk
IGNvbmZpZ3VyYXRpb24gd2FzIHN1cHBvc2VkIHRvIGJlIGlkZW50aWNhbCB0bw0KPj4+Pj4+Pj4+
Pj4+PiBpbnRlbmRlZA0KPj4+Pj4+Pj4+Pj4+PiBhZnRlciBzb21lIHN5bmNocm9uaXphdGlvbiBw
ZXJpb2QuDQo+Pj4+Pj4+Pj4+Pj4gVGhpcyBpcyBhIHZlcnkgaW1wb3J0YW50IHBvaW50IHRvIGNs
YXJpZnkuICBDYW4gdGhlcmUgZXZlciBiZQ0KPj4+Pj4+Pj4+Pj4+IGRhdGEgaW4NCj4+Pj4+Pj4+
Pj4+PiAiYXBwbGllZCIgdGhhdCBpcyBub3QgaW4gImludGVuZGVkIj8gIEkgdGhpbmsgQW5lZXMg
JiBSb2INCj4+Pj4+Pj4+Pj4+PiBwcmV2aW91c2x5DQo+Pj4+Pj4+Pj4+Pj4gc2FpZCAibm8iLCBi
dXQgSSBtaWdodCBiZSB3cm9uZy4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gSWYgdGhlcmUg
aXMgdGltZSBkZWxheSBiZXR3ZWVuIGVkaXRpbmcgaW50ZW5kZWQgYW5kIHRoZSBhcHBsaWVkDQo+
Pj4+Pj4+Pj4+PiBjb25maWcNCj4+Pj4+Pj4+Pj4+IG1hdGNoaW5nIHRoZSBlZGl0cyBvZiBpbnRl
bmRlZCwgdGhlbiBJIHN1cG9zZSB0aGlzIGNhbiBoYXBwZW4NCj4+Pj4+Pj4+Pj4+KEkNCj4+Pj4+
Pj4+Pj4+IGRlbGV0ZSBhIHJlc291cmNlIGZyb20gaW50ZW5kZWQgYnV0IGl0IGlzIHN0aWxsIGFy
b3VuZCB1bnRpbA0KPj4+Pj4+Pj4+Pj4gaW50ZW5kZWQNCj4+Pj4+Pj4+Pj4+IGhhcyBiZWVuIGZ1
bGx5IHN5bmNlZCkuIEkgd291bGQgZmluZCBpdCBpbnRlcmVzdGluZyBpZiBzb21lDQo+Pj4+Pj4+
Pj4+PmVkaXRzDQo+Pj4+Pj4+Pj4+PiBhcmUNCj4+Pj4+Pj4+Pj4gVXNpbmcgYXBwbGllZCBjb25m
aWcgZm9yIHN5c3RlbS1jb250cm9sbGVkIGVudHJpZXMgd291bGQgcmVxdWlyZQ0KPj4+Pj4+Pj4+
PiB0aGF0DQo+Pj4+Pj4+Pj4+IHN1Y2ggYW4gZW50cnkgc3RheXMgKGZvcmV2ZXIpIGluIGFwcGxp
ZWQgY29uZmlnIGV2ZW4gYWZ0ZXIgaXQNCj4+Pj4+Pj4+Pj5oYXMNCj4+Pj4+Pj4+Pj4gYmVlbg0K
Pj4+Pj4+Pj4+PiBkZWxldGVkIGZyb20gaW50ZW5kZWQuDQo+Pj4+Pj4+Pj4gSSB0aGluayB0aGF0
IHRoaXMgd291bGQgbWFrZSBsaWZlIGhhcmRlciBmb3IgY2xpZW50cy4NCj4+Pj4+Pj4+IEhtbSwg
SSB3b3VsZCBzYXkgdGhlIG9wcG9zaXRlLiBGb3Igb25lLCB3ZSBjb3VsZCBzaW1wbGlmeSB0aGUg
ZGF0YQ0KPj4+Pj4+Pj4gbW9kZWxzIGJ5IHJlZHVjaW5nIHRoZSBkdXBsaWNpdGllcyBpbiBjb25m
aWd1cmF0aW9uIGFuZCBzdGF0ZQ0KPj4+Pj4+Pj50cmVlcy4NCj4+Pj4+Pj4gVGhpcyBpcyB0aGUg
b2xkIGlkZWEgb2YgaGF2aW5nIHRoZSAib3BlcmF0aW9uYWwgc3RhdGUiIGRhdGFzdG9yZSwNCj4+
Pj4+Pj4gd2hpY2ggd291bGQgYmUgYWxsIGNvbmZpZyB0cnVlICsgYWxsIGNvbmZpZyBmYWxzZSBu
b2Rlcy4gIE9uZSBpc3N1ZQ0KPj4+Pj4+PiB3aXRoIHRoaXMgaXMgdGhhdCB0aGUgc2VtYW50aWNz
IG9mIHRoZSBub2RlIGlzIGRpZmZlcmVudCBpbiB0aGUNCj4+Pj4+Pj4gZGlmZmVyZW50IGRhdGEg
c3RvcmVzLCBldmVuIGlmIHRoZSBzeW50YXggKGJ5IGRlZmluaXRpb24hKSBpcyB0aGUNCj4+Pj4+
Pj4gc2FtZS4gIEluIG9yZGVyIHRvIGhhbmRsZSB0aGlzIHByb3Blcmx5IHlvdSBuZWVkIGVpdGhl
ciB0d28NCj4+Pj4+Pj5kaWZmZXJlbnQNCj4+Pj4+Pj4gZGVzY3JpcHRpb24gc3RhdGVtZW50cywg
b3IgdHdvICJzZWN0aW9ucyIgd2l0aGluIHRoZSBkZXNjcmlwdGlvbg0KPj4+Pj4+PiBzdGF0ZW1l
bnQuDQo+Pj4+Pj4gSSB0aGluayB0aGlzIGlzIG5vdCBtdWNoIGRpZmZlcmVudCBmcm9tIGRlZmF1
bHQgdmFsdWVzLiBMZWF2ZXMgYW5kDQo+Pj4+Pj4gbGVhZi1saXN0cyB0aGF0IGhhdmUgdGhlbSBk
ZWZpbmVkIGluIHRoZSBkYXRhIG1vZGVsIG1heSBub3QgYmUNCj4+Pj4+PnByZXNlbnQNCj4+Pj4+
PiBpbiBpbnRlbmRlZCBjb25maWcsIHlldCBvbmUgY2FuIGNvbnNpZGVyIHRoZW0gdG8gYmUgaW4g
YXBwbGllZA0KPj4+Pj4+Y29uZmlnLg0KPj4+Pj4gSSB0aGluayB0aGF0IGRlZmF1bHQgdmFsdWVz
IGFyZSBsb2dpY2FsbHkganVzdCBhIHdheSB0byBtYWtlIHRoZQ0KPj4+Pj4gY29uZmlndXJhdGlv
biBkYXRhIG1vcmUgY29uY2lzZS4gIEkuZS4gZXZlcnl3aGVyZSB5b3UgaGF2ZSBhIGRlZmF1bHQN
Cj4+Pj4+IHZhbHVlIHRoZW4gdGhlIGVxdWl2YWxlbnQgY29uZmlndXJhdGlvbiBjb3VsZCBiZSBl
eHByZXNzZWQgd2l0aCBhDQo+Pj4+PiBleHBsaWNpdCB2YWx1ZSBzZXQgaW5zdGVhZC4NCj4+Pj4g
SSB0aGluayBkZWZhdWx0IHZhbHVlcyBhcmUganVzdCB3aGF0IHRoZXkgYXJlLiBBIHNldCBvZiB2
YWx1ZXMgb24gdGhlDQo+Pj4+IHNlcnZlciB0aGF0IGhhdmUgbm90IGJlZW4gZXhwbGljaXRseSBz
ZXQgYnkgdGhlIGNsaWVudCB2aWENCj4+Pj4gaW50ZW5kZWQtY29uZmlnLg0KPj4+IFRoZSBkZWZh
dWx0IHZhbHVlcyBhcmUgZGV0ZXJtaW5lZCBieSB0aGUgc2NoZW1hIGFuZCB0aGUgaW50ZW5kZWQN
Cj4+PiBjb25maWd1cmF0aW9uLiAgWW91IG5lZWQgdG8ga25vdyBib3RoIHRvIGtub3cgd2hhdCBk
ZWZhdWx0IHZhbHVlcyB0aGUNCj4+PiBzZXJ2ZXIgaXMgZXhwZWN0ZWQgdG8gdXNlLg0KPj4gTm8g
ZGlzYWdyZWVtZW50LiBUaGUgb25seSBwb2ludCBpcyB3aGV0aGVyIGRlZmF1bHQgdmFsdWVzICpz
aGFsbCogb3INCj4+Km1heSoNCj4+IGJlIHByb3Zpc2lvbmVkIHZpYSBpbnRlbmRlZCBjb25maWcN
Cj4NCj5JIG1lYW50ICJNYXkiLg0KYWdyZWVkOiBkZWZhdWx0IHZhbHVlcyAqbWF5KiBiZSBwcm92
aXNpb25lZCB2aWEgaW50ZW5kZWQgY29uZmlnDQoNCj4NCj4+PiBCdXQgaW4gdGVybXMgb2Ygd2hh
dCBpcyBhY3R1YWxseSBhcHBsaWVkLCBhbiBpbnRlbmRlZCBjb25maWd1cmF0aW9uDQo+Pj53aXRo
DQo+Pj4gZGVmYXVsdHMgdmFsdWVzIGNhbiBiZSBtYXBwZWQgaW50byBhbiBlcXVpdmFsZW50IGlu
dGVuZGVkIGNvbmZpZ3VyYXRpb24NCj4+PiB3aXRoIGFsbCBpbXBsaWNpdCBkZWZhdWx0cyByZXBs
YWNlZCBieSB0aGUgZXF1aXZhbGVudCBleHBsaWNpdCB2YWx1ZXMuDQo+Pj4gV2hhdCBnZXRzIGFw
cGxpZWQgIGluIHRoZSBkZXZpY2Ugc2hvdWxkIGJlIHRoZSBzYW1lIGluIGJvdGggY2FzZXMuDQo+
Pj4NCj4+Pg0KPj4+PiAgICBJdCBpcyBjZXJ0YWlubHkgcG9zc2libGUgdG8gc2V0IGRlZmF1bHQg
dmFsdWVzIGluDQo+Pj4+IGludGVuZGVkLWNvbmZpZyBleHBsaWNpdGx5LCBidXQgaXQgaXMgbm90
IHN0cmljdGx5IG5lZWRlZC4NCj4+PiBZZXMsIG9mIGNvdXJzZS4NCj4+Pg0KPj4+Pj4gQXMgc3Vj
aCwgSSB0aGluayB0aGF0IHRoZSBkZWZhdWx0IHZhbHVlcyBhcHBseSBlcXVhbGx5IHRvIGJvdGgg
dGhlDQo+Pj4+PiBpbnRlbmRlZCBhbmQgYXBwbGllZCBjb25maWd1cmF0aW9uLg0KPj4+PiBXaGls
ZSB0aGlzIGlzIGFsbG93ZWQgKHNlZSBhYm92ZSksIEkgd291bGQgY29uc2lkZXIgZGVmYXVsdCB2
YWx1ZXMNCj4+Pj5hcHBseQ0KPj4+PiBpbiBwcmFjdGljZSB0byB0aGUgYXBwbGllZCBjb25maWcN
Cj4+PiBJIHRoaW5rIHRoYXQgSSBkaXNhZ3JlZSBvbiB0aGlzIHBvaW50Lg0KPj4gT0ssIGxldOKA
mXMga2VlcCB0aGlzIHBvaW50IGZvciBhIGZ1cnRoZXIgZGlzY3Vzc2lvbi4NCj4+PiBUaGUgaW50
ZW5kZWQgY29uZmlndXJhdGlvbiBpcyBvbmx5IGNvbXBsZXRlIHdoZW4geW91IGNvbnNpZGVyIGl0
cw0KPj4+IGFzc29jaWF0ZWQgWUFORyBzY2hlbWEgYW5kIGltcGxpY2l0IGRlZmF1bHQgdmFsdWVz
Lg0KPj4gVHJ1ZSwgYnV0IGl0IGRvZXNu4oCZdCBtZWFuIHRoYXQgdGhlIGNsaWVudCB3aGljaCBo
b2xkcyB0aGUgY29tcGxldGUNCj4+IGludGVuZGVkIGNvbmZpZyBoYXMgdG8gZXhwbGljaXRseSBw
dXNoIGV2ZXJ5dGhpbmcgZG93biB0byB0aGUgc2VydmVyLg0KPj4gQWdhaW4gdGhpcyBpcyB0aGUg
ZGlzdGluY3Rpb24gYmV0d2VlbiAqbWF5KiBhbmQgKnNoYWxsKiBhbmQgd29ydGggYQ0KPj4gZGlz
Y3Vzc2lvbi4NCj5ZZXMsIEkgdGhpbmsgdGhhdCBpdCBpcyAibWF5Ii4NCj4NCj4+ICAgDQo+Pj4N
Cj4+Pj4+IElmIGFmdGVyIGEgY29uZmlnIHJlcXVlc3QgaXQgdGFrZXMgdGltZSBmb3IgdGhlIHN5
c3RlbSB0byBhcHBseSBhDQo+Pj4+PiBkZWZhdWx0IHZhbHVlLCB0aGVuIGlkZWFsbHkgdGhlIGFw
cGxpZWQgY29uZmlndXJhdGlvbiBzaG91bGQgaGF2ZSBhbg0KPj4+Pj4gZXhwbGljaXQgbGVhZiB0
byBzaG93IHdoYXQgdmFsdWUgaXMgYWN0dWFsbHkgaW4gZWZmZWN0IHVudGlsIHRoZQ0KPj4+Pj4g
ZGVmYXVsdA0KPj4+Pj4gdmFsdWUgaGFzIGFjdHVhbGx5IGJlZW4gYXBwbGllZCBpbiB0aGUgc3lz
dGVtLg0KPj4+PiBJZiB0aGUgY2xpZW50IGhhcyBhbiBpbmRpY2F0aW9uIHdoZXRoZXIgdGhlIGNv
bmZpZ3VyYXRpb24gYXBwbGljYXRpb24NCj4+Pj5pcw0KPj4+PiBmaW5pc2hlZCAod2l0aCBvciB3
aXRob3V0IGVycm9ycyksIGl0IGtub3dzIHRoYXQgdGhlIGFwcGxpZWQgY29uZmlnIGlzDQo+Pj4+
IG5vdw0KPj4+PiBzdGFibGUgdG8gYmUgcmVhZC4gUmVhZGluZyBhcHBsaWVkIGNvbmZpZyBkdXJp
bmcgYW4gb3BlcmF0aW9uIHNob3VsZA0KPj4+PmJlDQo+Pj4+IGF2b2lkZWQuIEhlbmNlIEkgd291
bGQgcXVlc3Rpb24gdGhlIG5lZWQgZm9yIGEgcGVyLWxlYWYgc3RhdGUgYW5kDQo+Pj4+IGFkdm9j
YXRlDQo+Pj4+IGZvciBhIHBlci1zZXJ2ZXIgc3RhdGUuDQo+Pj4gSSB0aGluayB0aGF0IHRoZSB3
aG9sZSBwdXJwb3NlIG9mIHRoZSBvcHN0YXRlIHJlcXVpcmVtZW50cyBpcyB0aGF0IHRoZQ0KPj4+
IG9wZXJhdG9ycyBlZmZlY3RpdmVseSB3YW50IHRvIGJlIGFibGUgdG8gdHJhY2sgb24gYSBwZXIg
bGVhZiBlbGVtZW50DQo+Pj4gcmF0aGVyIHRoYW4gYSBwZXItc2VydmVyIGVsZW1lbnQuDQo+PiBU
aGUgcG9pbnQgaGFzIGJlZW4gdGhhdCB0aGUgY2xpZW50IHdhbnRzIHRvIGtub3cgd2hldGhlciBp
dOKAmXMgaW50ZW5kZWQNCj4+IGNvbmZpZ3VyYXRpb24gaGFzIGJlZW4gYXBwbGllZC4gVGhpcyBp
bmZvcm1hdGlvbiBpcyBtaXNzaW5nIGZyb20gdGhlIG9sZA0KPj4gYXN5bmNoIG1vZGVsIGFuZCBo
ZW5jZSBjcmVhdGVzIHVuY2VydGFpbnR5LiBBbnkgcmVhZCBhdHRlbXB0IG9mIHRoZQ0KPj5jbGll
bnQNCj4+IHJlbGF0ZWQgdG8gYXBwbGllZCBjb25maWd1cmF0aW9uIG1heSBmYWxsIGludG8gYSB0
cmFuc2l0aW9uIHBlcmlvZCBhbmQNCj4+aXMNCj4+IG9ubHkgYSBzbmFwc2hvdCBvZiBhIHdvYmJs
eSBzdGF0ZS4NCj5ZZXMsIGFuZCB0aGF0IGlzbid0IGEgcHJvYmxlbS4NCldoZXRoZXIgaXQgaXMg
YSBwcm9ibGVtIGRlcGVuZHMgb24gd2hhdCBmb3IgdGhlIGluZm9ybWF0aW9uIGlzIHVzZWQgYnkg
dGhlDQpjbGllbnQuIElmIHRoZSBjbGllbnQgcGVyaW9kaWNhbGx5IGNoZWNrcyB2YWx1ZXMgdG8g
bW9uaXRvciB0aGUgcHJvZ3Jlc3MNCm9mIGFuIGludGVuZGVkIGNvbmZpZyBhcHBsaWNhdGlvbiwg
aXQgd291bGRu4oCZdCBiZSBhIHByb2JsZW0uIFRoaXMgaXMgd2hhdA0KaXMgYWN0dWFsbHkgZG9u
ZSBzaW5jZSB0aGVyZSBpcyBhIGxhY2sgb2YgaW5mb3JtYXRpb24gd2hldGhlciB0aGUgaW50ZW5k
ZWQNCmNvbmZpZ3VyYXRpb24gaXMgZnVsbHkgYXBwbGllZC4NCkhvd2V2ZXIgaWYgdGhlIGNsaWVu
dCBpcyBjb2xsZWN0aW5nIGxlYWYgaW5mb3JtYXRpb24gaW4gb3JkZXIgdG8gZGVyaXZlIGFuDQph
Y3Rpb24sIGl0IGhhcyB0byByZWx5IG9uIHRoZSBzdGF0ZS4gU28gaGVyZSB0aGVyZSBpcyBpbmZv
cm1hdGlvbiBuZWVkZWQNCnRoYXQgY2FuIGJlIHJlbGllZCB1cG9uLg0KV2UgYXJlIGRpc2N1c3Np
bmcgd2hldGhlciB0aGF0IGluZm9ybWF0aW9uIHNob3VsZCBiZSBvbiBhIHRyZWUgb3IgYSBsZWFm
DQpsZXZlbC4gTXkgcHJlZmVyZW5jZSBnb2VzIGZvciBhIGhpZ2hlciBsZXZlbCBiZWNhdXNlIGl0
IGlzIG1vcmUgcmVsaWFibGUNCnRvIGltcGxlbWVudCwgYnV0IGFzIHdpdGggYWxsIHByZWZlcmVu
Y2VzIHRoZXJlIG5lZWRzIHRvIGJlIGNvbnNlbnN1cy4NCklmIG9uZSAgaW1wbGVtZW50cyBzdGF0
ZSBvbiBhIGxlYWYgbGV2ZWwgdGhlcmUgYXJlIDMgY2FzZXMgdG8gY29uc2lkZXI6DQpBKSByb2xs
YmFjay1vbi1lcnJvcjogQWxsIGxlYWZzIHRvdWNoZWQgaW4gdGhlIGNvbmZpZyBoYXZlIHRvIHJl
bWFpbg0K4oCYZGlydHnigJkgKHNlZSBiZWxvdyBmb3IgZGVmaW5pdGlvbikgdW50aWwgdGhlIGxh
c3QgdmFsdWUgaGFzIGJlZW4gYXBwbGllZA0Kb3IgdGhlIHJvbGxiYWNrIGlzIGZpbmlzaGVkLiBU
aGVuIGluIGEgc2Vjb25kIHN0ZXAgdGhlIGRpcnR5IGZsYWcgaXMNCnJlbW92ZWQuDQpCKSBzdG9w
LW9uLWVycm9yOiBmaXJzdCBhbGwgbGVhZnMgc3VwcG9zZWQgdG8gYmUgdG91Y2hlZCBieSB0aGUg
aW50ZW5kZWQNCmNvbmZpZyBhcmUgbWFya2VkLCB0aGVuIGNvbmZpZyBpcyBhcHBsaWVkIGFuZCB0
aGUg4oCYZGlydHnigJkgZmxhZyBjYW4NCmltbWVkaWF0ZWx5IGJlIHJlbW92ZWQgZnJvbSB0aGUg
bGVhZnMuIEhvd2V2ZXIgaWYgYW4gZXJyb3Igb2NjdXJzIHRoZQ0KZGlydHkgZmxhZyBvZiBhbGwg
c3Vic2VxdWVudCBsZWFmcyBoYXMgdG8gYmUgY2xlYXJlZCBzaW5jZSB0aGVyZSBpcyBubw0KY29u
ZmlnIGluIHByb2dyZXNzIGFueW1vcmUNCkMpIGNvbnRpbnVlIG9uIGVycm9yOiBtYXJrIGFsbCBh
ZmZlY3RlZCBsZWFmcyB3aXRoIHRoZSBkaXJ0eSBmbGFnIGFuZA0KY2xlYXIgaXQgYWZ0ZXIgbGVh
ZnMgaGF2ZSBiZWVuIGNvbmZpZ3VyZWQgKHN1Y2Nlc3NmdWxseSBvciBub24tc3VjZXNzZnVsbHkp
DQoNCkkgZmVhciB0aGF0IHdl4oCZbGwgZXZlbnR1YWxseSBlbmQgdXAgd2l0aCBzb21ldGhpbmcg
bGlrZSBhbiBvcnBoYW4gY29udHJvbA0KZGFlbW9uIGluIHRoZSBzZXJ2ZXIgdG8gY2xlYW4gdXAg
YWxsIHRoZSBmb3Jnb3R0ZW4gc3RhdGVzLCByZW5kZXJpbmcgdGhlDQpmaW5lIGxldmVsIG9mIHN0
YXRlIGxlc3MgdXNlZnVsIHRoYW4gaXQgYXBwZWFyLg0KDQo+DQo+VGhlIGludGVuZGVkIGNvbmZp
ZyBpcyB1cGRhdGVkLCBhbmQgdGhlbiB0aGUgYXBwbGllZCBjb25maWcgc3RhdGUNCj5jb252ZXJn
ZXMgb24gdGhlIGludGVuZGVkIGNvbmZpZy4NCj4NCj4+IEVzc2VudGlhbGx5IHdlIGFyZSBkaXNj
dXNzaW5nIHdoZXJlIHRvIHB1dCBhIGRpcnR5LWZsYWcuIEluIG15IChsZXNzDQo+PiBncmFudWxh
cikgdmlldyBpdCBpcyBwcnVkZW50IHRvIHB1dCB0aGUgZGlydHktZmxhZyBoaWdoIHVwIGluIHRo
ZSB0cmVlDQo+PmFuZA0KPj4ga2VlcCBpdCB0cnVlIHVudGlsIHRoZSBzdGF0ZSBjaGFuZ2UgY29t
cGxldGVkIChpcnJlc3BlY3RpdmUgaWYgaXQgd2FzDQo+PiBzdWNjZXNzZnVsIG9yIG5vdCkuIEFu
b3RoZXIgd2F5IGlzIHRvIGtlZXAgYSB2ZXJ5IGdyYW51bGFyIHZpZXcgYW5kDQo+PnN0aWNrDQo+
PiB0aGUgZGlydHkgZmxhZyBvbiBhbGwgbGVhZnMgdGhhdCBhcmUgc3VwcG9zZWQgdG8gYmUgdG91
Y2hlZCBieSB0aGUNCj4+IGludGVuZGVkIHN0YXRlIGFuZCBjbGVhbmluZyB0aGVtIHVwIGFmdGVy
ICphbGwqIGludGVuZGVkIGNvbmZpZyBoYXMgYmVlbg0KPj4gYXR0ZW1wdGVkIHRvIGFwcGx5LiBB
IGJpdCBvZiBtb3JlIGhhc3NsZSBmcm9tIGFuIGltcGxlbWVudGVycyBwb2ludCBvZg0KPj4gdmll
dywgYW5kIEkgYW0gbm90IHN1cmUgaWYgaXQgaXMgd29ydGguDQo+DQo+SGF2aW5nIGEgc2luZ2xl
IGRpcnR5IGZsYWcgZG9lc24ndCByZWFsbHkgbWVldCB0aGUgcmVxdWlyZW1lbnRzIChhcw0KPnN0
YXRlZCBpbiB0aGUgcmVxdWlyZW1lbnRzIGRyYWZ0KS4gIEl0IG1lYW5zIHRoYXQgY29uZmlnIHJl
YWRzIGZyb20gdGhlDQo+c2VydmVyIGFyZSB1bmF2YWlsYWJsZSAob3Igc3RhbGUpIHdoaWxzdCBh
IGNvbmZpZyBjaGFuZ2UgaXMgaW4gcHJvZ3Jlc3MNCj4od2hpY2ggY291bGQgdGFrZSBhIGxvbmcg
dGltZSkuDQpTb3JyeSwgSSB3YXMgdXNpbmcgYSBzbG9wcHkgdGVybSB3aXRob3V0IGRlZmluaXRp
b24uIEkgbWVhbnQg4oCYZGlydHnigJkgZmxhZw0KaXMgYSBtYXJrZXIgaW5kaWNhdGluZyB0aGF0
IGEgY29uZmlndXJhdGlvbiBhcHBsaWNhdGlvbiBpcyBzdGlsbCBydW5uaW5nLg0KVGVjaG5pY2Fs
bHkgc3VjaCBhIGZsYWcgY291bGQgYmUgc3RpY2tlZCBhdCBhbnkgcG9pbnQgaW4gdGhlIHRyZWUN
CmluY2x1ZGluZyBsZWFmcy4gSW4gb3RoZXIgd29yZHMsIGEgY2xpZW50IGNhbiByZWFkIHdoYXRl
dmVyIGFuZCB3aGVuZXZlcg0KaXQgd2FudHMuIOKAmGRpcnR54oCZIGluZGljYXRlcyB0aGF0IHRo
ZSBhdHRyaWJ1dGUgdmFsdWUgY2Fubm90IGJlIHJlbGllZA0KdXBvbiwgc2luY2UgYSBjb25maWd1
cmF0aW9uIGlzIG9uZ29pbmcuIEhvcGUgdGhpcyBjbGFyaWZpZXMgdGhhdCB0aGVyZSBpcw0Kbm8g
dW5hdmFpbGFibGUgb3Igc3RhbGUgcGVyaW9kIGZvciByZWFkaW5nIGFzIHN0YXRlZCBpbiB0aGUg
cmVxdWlyZW1lbnRzLg0KDQo+DQo+SW5zdGVhZCwgdGhlIG9wZXJhdG9ycyByZXF1aXJlbWVudCBp
cyB0aGF0IHRoZSB0cmFja2luZyBpcyBkb25lIG9uIGEgcGVyDQo+bGVhZiBiYXNpcyAoZS5nLiBs
aWtlIHRoZSBPcGVuQ29uZmlnIFlBTkcgbW9kZWxzIG9uDQo+aHR0cHM6Ly9naXRodWIuY29tL29w
ZW5jb25maWcvcHVibGljKSwgSSBiZWxpZXZlIHdpdGggdGhlIGV4cGVjdGF0aW9uDQo+dGhhdCB0
aGUgc2VydmVyIHNob3VsZCB1cGRhdGUgdGhlIGxlYXZlcyBhcyB0aGUgY29uZmlndXJhdGlvbiBp
cyBiZWluZw0KPmFwcGxpZWQuICBJLmUuIGlmIHRoZSBzZXJ2ZXIgaGFkIHByb2Nlc3NlZCBoYWxm
IHRoZSBjb25maWd1cmF0aW9uIGZyb20gYQ0KPjEgbWlsbGlvbiBlbnRyeSBjb25maWcgdGhlbiBp
ZGVhbGx5IGl0IHNob3VsZCBiZSB1cGRhdGluZyB0aGUgYXBwbGllZA0KPmNvbmZpZ3VyYXRpb24g
bGVhdmVzIGFzIGl0IGdvZXMgc28gdGhhdCB0aGUgY2xpZW50IGtub3dzIHdoYXQgaXMNCj5jdXJy
ZW50bHkgcHJvZ3JhbW1lZCBhdCB0aGF0IHBhcnRpY3VsYXIgcG9pbnQgaW4gdGltZS4gIEluIHRo
ZSBpZGVhbA0KPndvcmxkIHRoZSBzZXJ2ZXIgc2hvdWxkIGFsd2F5cyBiZSB0ZWxsaW5nIHRoZSBj
bGllbnQgd2hhdCBjb25maWd1cmF0aW9uDQo+aXMgYXBwbGllZCBhdCB0aGF0IHNwZWNpZmljIHBv
aW50IGluIHRpbWUgdGhhdCB0aGUgcmVxdWVzdCBpcyBwcm9jZXNzZWQuDQo+DQo+PiAgIA0KPj4+
IEkgbWlnaHQgYmUgd3JvbmcsIGJ1dCBJIHRoaW5rIHRoYXQgdGhlIGRlc2lnbiBiZWluZyBjb25z
aWRlciBieSB0aGUNCj4+PiBvcHN0YXRlIG9wZXJhdG9ycyBpcyBhbG9uZyB0aGUgbGluZXMgb2Yg
YW4gZXZlbnR1YWwgY29uc2lzdGVudCBtb2RlbC4NCj4+PiBFLmcuIHNvbWV0aGluZyBhbG9uZyB0
aGUgbGluZXMgb2Y6DQo+Pj4NCj4+PiBBdCBhbnkgcG9pbnQgaW4gdGltZSB0aGUgb3BlcmF0b3Ig
a25vd3Mgd2hhdCBjb25maWd1cmF0aW9uIHN0YXRlIHRoZXkNCj4+PiB3b3VsZCBhIGRldmljZSB0
byBiZSBpbiAoaS5lLiB0aGUgaW50ZW5kZWQgY29uZmlndXJhdGlvbikuDQo+PiBPSw0KPj4+IFdo
ZW5ldmVyIHRoZSBjbGllbnQgY2hhbmdlcyB0aGVpciBpbnRlbmRlZCBjb25maWd1cmF0aW9uLCB0
aGV5IHB1c2gNCj4+PmRvd24NCj4+PiB0aGUgdXBkYXRlZCBpbnRlbmRlZCBjb25maWd1cmF0aW9u
IHRvIHRoZSBkZXZpY2UuDQo+PiBPSywgZnJvbSBub3cgb24gdGhlIGNsaWVudCBpcyBibGluZCBh
Ym91dCB0aGUgYXBwbGllZCBzdGF0ZSBvZiB0aGUNCj4+c2VydmVyDQo+PiB1bmxlc3MgaXQgY2Fu
IGd1ZXNzIGl0IGZyb20gZS5nLiBEZXJpdmVkIHN0YXRlIGFuZCBzbyBvbi4NCj5ObywgdGhlIGNs
aWVudCBjYW4gcmVhZCB0aGUgY3VycmVudCBzdGF0ZSBmcm9tIHRoZSBzZXJ2ZXIgYXQgYW55IHBv
aW50DQo+aW4gdGltZSwgYW5kIGlkZWFsbHkgaXQgc2hvdWxkIHJlZmxlY3QgdGhlIGNvbmZpZ3Vy
YXRpb24gYXQgdGhhdCBwb2ludA0KPmluIHRpbWUgKGV2ZW4gaWYgaXQgaXMgaGFsZiB3YXkgdGhy
b3VnaCBhIGNvbmZpZyByZXF1ZXN0KS4NCldoaWxlIHdlIGFyZSBpbiBhZ3JlZW1lbnQgdGhhdCB0
aGUgY2xpZW50IGNhbiBwb2xsIHRoZSBhcHBsaWVkIHN0YXRlIGF0DQphbnkgcG9pbnQgaW4gdGlt
ZSAoc2VlIGFib3ZlKSwgaXQgaXMgbm90IG9ibGlnZWQgdG8gZG8gc28gZ2l2ZW4gdGhhdCB0aGUN
CnNlcnZlciBzZW5kcyBhbiBpbmRpY2F0aW9uIHdoZW4gdGhlIGNvbmZpZyBpcyBhcHBsaWVkLg0K
SSBhbHNvIHJlYWxpemVkIHRoYXQgSSBkaWRu4oCZdCBleHBsYWluIHN1ZmZpY2llbnRseSB3aGF0
IGkgbWVhbnQgd2l0aA0K4oCYYmxpbmTigJkuIFRha2UgdGhlIGNhc2Ugb2YgMiBkaWZmZXJlbnQg
aW1wbGVtZW50YXRpb25zIG9mIGEgc2VydmVyIGFwcGx5aW5nDQpjb25maWd1cmF0aW9uOg0KQSkg
Zmlyc3Qgc2V0IHRoZSBuZXcgdmFsdWUgaW4gdGhlIGludGVybmFsIGRhdGFiYXNlIChha2EuIGFw
cGxpZWQgY29uZmlnKQ0KYW5kIHRoZW4gcHJvZ3JhbSB0aGUgSFcuDQpCKSBmaXJzdCBwcm9ncmFt
IHRoZSBIVyBhbmQgdGhlbiByZWZsZWN0IHRoZSBzdGF0ZSBpbiB0aGUgaW50ZXJuYWwgZGF0YWJh
c2UNCg0KU2F5IHRoZSBjbGllbnTigJlzIGludGVudGlvbiBpcyB0byBjaGFuZ2UgYSBsZWFmIHZh
bHVlIGZyb20gWCB0byBZLiBBZnRlcg0KY29uZmlndXJpbmcsIHRoZSBjbGllbnQgaXMgcmVhZGlu
ZyB0aGUgbGVhZiB2YWx1ZSBiZXR3ZWVuIHRoZSBmaXJzdCBhbmQNCnRoZSBzZWNvbmQgd3JpdGU6
DQpBKSB3aWxsIHJlcG9ydCBZLCBidXQgc3RpbGwgcnVucyB3aXRoIFgNCkIpIHdpbGwgcmVwb3J0
IFgsIGJ1dCBydW5zIGFscmVhZHkgd2l0aCBZDQoNCkFmdGVyIHN1Y2Nlc3NmdWwgYXBwbGljYXRp
b24gKGFmdGVyIHN0ZXAgMiksIGJvdGggaW1wbGVtZW50YXRpb25zIHdpbGwNCmNvbnNpc3RlbnRs
eSBleGVjdXRlIGluIEhXIGFuZCByZXBvcnQgdGhlIHNhbWUgdmFsdWUgaW4gdGhlIGFwcGxpZWQN
CmNvbmZpZy4gSG93ZXZlciB0aGUgY2xpZW50IGNhbuKAmXQgcmVseSBvbiB0aGUgaW5mb3JtYXRp
b24gaXQgcmVhZHMgaW4gdGhlDQptZWFudGltZSAtIHRoYXTigJlzIHdoYXQgSSBtZWFudCB3aXRo
IOKAmGJsaW5k4oCZLiBJZiB0aGUgb25seSBwdXJwb3NlIGlzIHRvDQptb25pdG9yIHRoZSBwcm9n
cmVzcyBvZiBhcHBseWluZyB0aGUgaW50ZW5kZWQgc3RhdGUsIHRoaXMgbGV2ZWwgb2YNCmluZm9y
bWF0aW9uIGlzIGdvb2QgZW5vdWdoLCBidXQgSSB3b3VsZCBhcmd1ZSB0aGF0IHRoZXJlIGFyZSBs
ZXNzIGludGVuc2UNCm1lY2hhbmlzbXMgdG8gZG8gc28uDQpJZiB0aGUgY2xpZW50IHRydWx5IG5l
ZWRzIHRvIHJlbHkgb24gdGhlIGluZm9ybWF0aW9uIHJlYWQsIGl0IGhhcyB0byB3YWl0DQpmb3Ig
Y29tcGxldGlvbi4NCj4NCj4+PiBUaGUgZGV2aWNlIHN0YXJ0cyBhcHBseWluZyB0aGUgY2hhbmdl
ICh1c2luZyB0aGUgc3BlY2lmaWVkIGVycm9yDQo+Pj4gaGFuZGxpbmcgc2VtYW50aWNzKQ0KPj4g
T0sNCj4+PiBUaGV5IHJlZ2lzdGVyIGZvciBub3RpZmljYXRpb24gZm9yIGNoYW5nZXMgdG8gYWxs
IGludGVuZGVkL2FwcGxpZWQNCj4+PiBjb25maWcgYW5kIGRlcml2ZWQgc3RhdGUgb24gdGhlIGRl
dmljZSBzbyB0aGF0IHRoZXkgaGF2ZSBhIGZlZWRiYWNrDQo+Pj4gbWVjaGFuaXNtIHRvIGtub3cg
d2hldGhlciB0aGUgY29uZmlndXJhdGlvbiBpcyBiZWluZyBzdWNjZXNzZnVsbHkNCj4+PmFwcGxp
ZWQuDQo+PiBPSywgc28gZnJvbSBub3cgb24gdGhlIGNsaWVudCBrbm93cyB0aGF0IHRoZSBuZXcg
aW50ZW5kZWQgY29uZmlnIGlzDQo+PiBhY3RpdmUuIEl0IGFsc28gbWVhbnMgdGhhdCB0aGUgY2xp
ZW50IGNhbiByZWxpYWJseSByZWFkIGFwcGxpZWQgc3RhdGUuDQo+VGhlIGNoYW5nZXMgdG8gdGhl
IGluZGl2aWR1YWwgbGVhdmVzIGNhbiBiZSBub3RpZmllZCBpbmRlcGVuZGVudGx5IGFzDQo+dGhl
eSBjaGFuZ2Ugc3RhdGUuDQpTZWUgZGlzY3Vzc2lvbiBhYm92ZSBhYm91dCByb2xsYmFjay1vbi1l
cnJvciBldGMuIHJlcXVpcmluZyBhIGNhcmVmdWwNCmRlZmluaXRpb24gb24gd2hlbiB0byBzZW5k
IG5vdGlmaWNhdGlvbnMuDQo+IFRoZSBjbGllbnQgY2FuIHJlbGlhYmx5IHJlYWQgdGhlIGFwcGxp
ZWQgc3RhdGUgYXQNCj5hbnkgdGltZS4NCk5vIGFncmVlbWVudCBoZXJlLiBBcyBkaXNjdXNzZWQg
YWJvdmU6ICJBIGNsaWVudCBjYW4gcmVhZCBhcHBsaWVkIHN0YXRlIGF0DQphbnkgdGltZSwgYnV0
IGl0IGNhbuKAmXQgcmVsaWFibHkgYXNzdW1lIGl0IGJlaW5nIGFwcGxpZWQgYmVmb3JlIGNvbXBs
ZXRpb24NCm9mIGFuIG9uZ29pbmcgY29uZmlndXJhdGlvbuKAnS4NCj4NCj4NCj4+Pj4+IFRoaXMg
ZG9lcyBvcGVuIHRoZSBxdWVzdGlvbiBvZiBob3cgZG8geW91IGV4cHJlc3MgdGhlIGNhc2UgdGhh
dCBubw0KPj4+Pj4gdmFsdWUNCj4+Pj4+IGhhcyBiZWVuIGFwcGxpZWQgcmF0aGVyIHRoYW4gYSBk
aWZmZXJlbnQgdmFsdWUuICBGb3IgdGhlIG9wc3RhdGUNCj4+Pj4+IGVuY29kaW5nIHNvbHV0aW9u
IGRyYWZ0IHRoYXQgSSBwdXQgZm9yd2FyZCAob3IgdXNpbmcgbWV0YS1kYXRhKSwNCj4+Pj4+dGhl
biBJDQo+Pj4+PiB0aGluayB0aGF0IGl0IHdvdWxkIHByb2JhYmx5IGJlIHBvc3NpYmxlIHRvIGV4
dGVuZCB0aGUgZW5jb2RpbmcgdG8NCj4+Pj4+IGV4cGxpY2l0bHkgaW5jbHVkZSB0aGlzIGluZm9y
bWF0aW9uIGlmIHJlcXVpcmVkLg0KPj4+PiBQZXJoYXBzIEkgYW0gbWlzc2luZyBzb21ldGhpbmcg
aGVyZS4gSWYgdGhlIHZhbHVlIHN1cHBvc2VkIHRvIGJlDQo+Pj4+YXBwbGllZA0KPj4+PiBpcyB0
aGUgc2FtZSB0aGF0IGFscmVhZHkgZXhpc3RzLCBqdXN0IHNraXAgaXQgaW4gdGhlIHNlcnZlci4N
Cj4+PiBUaGUgY2FzZSBJIHdhcyBjb25zaWRlcmluZyBpcyB3aGVyZSB0aGUgc2VydmVyIGhhcyBu
byB2YWx1ZSBhcHBsaWVkDQo+Pj4gKGUuZy4gZm9yIGFuIG9wdGlvbmFsIGZlYXR1cmUpIHJhdGhl
ciB0aGFuIHRoZSBkZWZhdWx0IHZhbHVlLg0KPj4gV2hhdGV2ZXIgdmFsdWUgdGhlIHNlcnZlciBh
cHBsaWVkIChub25lIG9yIGRlZmF1bHQpIHNob3VsZG7igJl0IGJlIGFuDQo+Pmlzc3VlDQo+PiB1
bmxlc3MgdGhlIGludGVuZGVkIGNvbmZpZyBpbXBvc2VzIGEgY2VydGFpbiB2YWx1ZS4NCj5JdCBp
cyBhbiBpc3N1ZSBiZWNhdXNlIHRoZSBjbGllbnQgd2FudHMgdG8ga25vdyB3aGF0IGNvbmZpZ3Vy
YXRpb24gYQ0KPmRldmljZSBpcyBhY3R1YWxseSBydW5uaW5nLiAgSWRlYWxseSBpdCB3YW50cyBh
IGdpdmVuIGRldmljZSB0byBleGFjdGx5DQo+aW1wbGVtZW50IHRoZSBjb25maWd1cmF0aW9uIHRo
YXQgdGhleSBhcmUgcmVxdWVzdGluZy4gIFRoZXkgZG9uJ3QgcmVhbGx5DQo+d2FudCBsb3RzIG9m
IHJhbmRvbSBkZXZpY2Ugc3BlY2lmaWMgdmFsdWVzIHRoYXQgd2lsbCByZXF1aXJlIGN1c3RvbQ0K
PmNsaWVudCBjb2RlIHRvIGhhbmRsZS4NCkkgdGhpbmsgd2UgYXJlIGluIGFncmVlbWVudCB0aGF0
IHRoZSBjbGllbnQgKm1heSogY29uZmlndXJlIGRlZmF1bHQgdmFsdWVzDQp0byBhZGRyZXNzIHN1
Y2ggY2FzZXMuDQo+DQo+DQo+PiAgIEkgZ3Vlc3MgeW91IGhhZCBpbg0KPj4gbWluZCBvbiBob3cg
dG8gZGVhbCB3aXRoIHRoZSBvcHN0YXRlIG9mIGEgbm9uLXZhbHVlLiBQdXNoaW5nIHRoZSBvcHN0
YXRlDQo+PiBoaWdoZXIgdXAgdGhlIHRyZWUgd291bGQgcHJvYmFibHkgYWRkcmVzcyB0aGUgaXNz
dWUgKHNlZSBhYm92ZSkuDQo+Pj4+PiBBbHRlcm5hdGl2ZWx5LCBhbmQgZm9yIHRoZSBvdGhlciBw
cm9wb3NlZCBvcHN0YXRlIHNvbHV0aW9ucywgdGhlbiBJDQo+Pj4+PiBleHBlY3QgdGhhdCB0aGUg
bW9zdCBhcHByb3ByaWF0ZSBpZGVhbCBzZW1hbnRpY3MgdG8gaGFuZGxlIHRoaXMNCj4+Pj4+IHNj
ZW5hcmlvDQo+Pj4+PiB3b3VsZCBiZSB0byBkZWxheSBtYXJraW5nIHRoZSBwYXJlbnQgb2JqZWN0
IGFzIGJlaW5nIGFwcGxpZWQgdW50aWwNCj4+Pj4+IGV2ZXJ5DQo+Pj4+PiBkZXNjZW5kZW50IGNo
aWxkIGxlYWYgd2l0aCBhIGRlZmF1bHQgdmFsdWUgc2V0IGhhcyBhIHZhbHVlIGFwcGxpZWQgaW4N
Cj4+Pj4+IHRoZSBzeXN0ZW0sIGVpdGhlciB0byB0aGUgZXhwZWN0ZWQgZGVmYXVsdCB2YWx1ZSAo
aW4gd2hpY2ggY2FzZSB0aGUNCj4+Pj4+IGNoaWxkIGxlYWYgd291bGRuJ3QgbmVlZCB0byBiZSBw
cmVzZW50IGluIHRoZSBhcHBsaWVkIGNvbmZpZyksIG9yDQo+Pj4+PiB0cmFuc2llbnRseSB0byBh
bm90aGVyIHZhbHVlICh3aGljaCB3b3VsZCBiZSBpbiB0aGUgYXBwbGllZCBjb25maWcNCj4+Pj4+
IHVudGlsDQo+Pj4+PiB0aGUgc3lzdGVtIHVwZGF0ZWQgYW5kIHRoZSBjb3JyZWN0IGRlZmF1bHQg
dmFsdWVzIGhhdmUgYWN0dWFsbHkgYmVlbg0KPj4+Pj4gYXBwbGllZCkuICBJbiByZWFsIHN5c3Rl
bXMsIEkgd291bGQgaGF2ZSB0aG91Z2h0IHRoYXQgdGhlIGRlZmF1bHQNCj4+Pj4+IHZhbHVlcw0K
Pj4+Pj4gYXJlIG9mdGVuIGltcGxpY2l0bHkgcHJvZ3JhbW1lZCB3aGVuIHRoZSBwYXJlbnQgY29u
dGFpbmluZyBvYmplY3QgaXMNCj4+Pj4+IGNyZWF0ZWQgYW55d2F5LCBzbyBJIHN1c3BlY3QgdGhh
dCB0aGlzIGJlaGF2aW91ciB3b3VsZG4ndCBhY3R1YWxseSBiZQ0KPj4+Pj4gdGhhdCBvbmVyb3Vz
IHRvIGltcGxlbWVudC4NCj4+Pj4gSXQgYXBwZWFycyB0byBtZSB0aGF0IHdlIHJ1biBpbnRvIHRo
b3NlIGlzc3VlcyBieSByZXF1aXJpbmcgdGhlDQo+Pj4+aW50ZW5kZWQNCj4+Pj4gY29uZmlnIHRv
IGNvbnRhaW4gYWxzbyB0aGUgZGVmYXVsdCB2YWx1ZXMuIFRoYXQgZG9lc27CuXQgc2VlbQ0KPj4+
Pm5lY2Vzc2FyeS4NCj4+Pj4gSQ0KPj4+IEkgY2FuJ3Qgc2VlIGhvdyB5b3UgY2FuIGhhdmUgZGVm
YXVsdCB2YWx1ZXMgYXBwbHkgb25seSB0byB0aGUgYXBwbGllZA0KPj4+IGNvbmZpZ3VyYXRpb24g
YW5kIG5vdCB0aGUgaW50ZW5kZWQgY29uZmlndXJhdGlvbi4gIFRoZSBpbnRlbmRlZA0KPj4+IGNv
bmZpZ3VyYXRpb24gY2Fubm90IGJlIGNvcnJlY3RseSBpbnRlcnByZXRlZCBpZiB5b3UgZG9uJ3Qg
YWxzbw0KPj4+Y29uc2lkZXINCj4+PiB0aGUgZGVmYXVsdCB2YWx1ZXMgc3BlY2lmaWVkIGluIHRo
ZSBzY2hlbWEuDQo+PiBHaXZlbiB0aGF0IHNlcnZlcnMgbm93YWRheXMgY292ZXIgYSBodWdlIGFt
b3VudCBvZiBmdW5jdGlvbmFsaXR5IHdoZXJlDQo+PiBvZnRlbiBvbmx5IGEgc3Vic2V0IGlzIHJl
cXVpcmVkIGJ5IGEgY2xpZW50LCBJIHdvdWxkIGNvbnNpZGVyIHF1aXRlIGENCj4+Yml0DQo+PiBv
ZiBkZWZhdWx0IHZhbHVlcyBpcnJlbGV2YW50IGZvciB0aGUgc2NvcGUgb2YgdGhlIGNsaWVudC4g
SWYgZS5nLiBZb3UNCj4+cGxhbg0KPj4gdG8gdXNlIGEgcm91dGVyIHRoYXQgc3VwcG9ydHMgVlBM
UywgYnV0IHlvdSBkbyBub3QgY2FyZSBzaW5jZSBpdCBpcyBub3QNCj4+IG5lZWRlZCwgdGhvc2Ug
ZGVmYXVsdHMgY2FuIGp1c3QgYmUgbGVmdCB0byB0aGUgc2VydmVyLg0KPllBTkcgYWxyZWFkeSB0
YWtlcyBjYXJlIG9mIHRoaXMsIGFzIHBlciBSRkM2MDIwYmlzIHNlY3Rpb24gNy42LjEsIG9ubHkN
Cj50aGUgZGVmYXVsdHMgdGhhdCBhcmUgaW4gc2NvcGUgZm9yIHlvdXIgY29uZmlndXJhdGlvbiBh
cmUgcmVsZXZhbnQuDQpJbiBvdGhlciB3b3JkcywgYWxsIGRlZmF1bHRzIHRoYXQgYXJlIG5vdCBp
biBzY29wZSByZW1haW4gYXMgc2V0IGJ5IHRoZQ0Kc3VwcGxpZXIgb2YgdGhlIFNlcnZlciBhbmQg
d2lsbCBub3QgYmUgY2hhbmdlZCBieSB0aGUgY2xpZW50LiBMb29rcyB3ZSBhcmUNCmluIGFncmVl
bWVudC4NCj4NCj4+Pj4gd291bGQgYWxzbyBhcmd1ZSB0aGF0IG1hcmtpbmcgdGhlIMWSYXBwbGll
ZD1pbnRlbmRlZMK5IHN0YXRlIHBlciBsZWFmIGlzDQo+Pj4+IGNvdW50ZXItcHJvZHVjdGl2ZS4g
QXNzdW1lIHRoZSBjbGllbnQgc2V0cyBhbiBpbnRlbmRlZCBzdGF0ZSBvZiB0d28NCj4+Pj4gdmFs
dWVzDQo+Pj4gVHJhY2tpbmcgaW50ZW5kZWQgdnMgYXBwbGllZCBvbiBhIHBlciBsZWFmIGJhc2lz
IGlzIHRoZSBlc3NlbmNlIG9mIHRoZQ0KPj4+IG9wc3RhdGUgcmVxdWlyZW1lbnRzLCBwbGVhc2Ug
bGV0cyBub3QgcmVoYXNoIHRoZXNlIGFsbCB5ZXQgYWdhaW4uIDotKQ0KPj4gU2VlIGFib3ZlLCB5
b3UgY2FuIGRvIHRoaXMgYnV0IGl04oCZcyBxdWl0ZSBhIGJpdCBvZiB3b3JrLiBUaGUgcmVxdWly
ZW1lbnQNCj4+IHN0ZW1zIGZyb20gYSB0aW1lIHdoZXJlIGEgY2xpZW50IHdhc27igJl0IGFibGUg
dG8gZmlndXJlIG91dCB3aGV0aGVyIGENCj4+bGVhZg0KPj4gaGFzIGJlZW4gY2hhbmdlZCBhbHJl
YWR5IG9yIHdhcyBhYm91dCB0byBjaGFuZ2UgaW4gZnV0dXJlLiBUbyBtZSBpdA0KPj4gYXBwZWFy
cyBtb3JlIG9mIGFuIGltcGxlbWVudGF0aW9uIGNob2ljZS4NCj5JIGRpc2FncmVlLiAgVGhlIHJl
cXVpcmVtZW50cyBhcmUgZnJvbSB0aGUgcGVyY2VpdmVkIGRlZmljaWVuY2llcyBpbg0KPk5FVENP
TkYvWUFORyB0aGF0IG5lZWQgdG8gYmUgZml4ZWQgZm9yIG9wZXJhdG9ycyB0byB1c2UgWUFORyBl
ZmZlY3RpdmVseS4NCldlIGFncmVlIHRoYXQgIlRyYWNraW5nIGludGVuZGVkIHZzIGFwcGxpZWQg
b24gYSBwZXIgbGVhZiBiYXNpc+KAnSBpcyBhDQpyZXF1aXJlbWVudCwgYnV0IGl0IGFwcGVhcnMg
dG8gbWUgdGhhdCB3ZSBoYXZlIGRpZmZlcmVudCBpZGVhcyBvbiB0aGUNCmludGVycHJldGF0aW9u
IG9mIOKAmGFwcGxpZWQnIGR1cmluZyB0aGUgdHJhbnNpdGlvbiBwZXJpb2QuIEluIGFuDQppbXBs
ZW1lbnRhdGlvbiBkcmFmdCBJIHdvdWxkIGNvbnNpZGVyIHNvbWV0aGluZyBhbG9uZyB0aG9zZSBs
aW5lczoNCg0KSWYgYSBzZXJ2ZXIgY29tcGxldGVkIHRoZSBhcHBsaWNhdGlvbiBvZiBpbnRlbmRl
ZCBjb25maWcgKHdpdGggb3Igd2l0aG91dA0KZXJyb3JzKSwgdGhlIGFwcGxpZWQgY29uZmlnIFNI
QUxMIHJlZmxlY3QgdGhlIGFjdHVhbCBjb25maWd1cmF0aW9uIGluDQpmb3JjZS4gQWxsIGxlYXZl
cyB3aGVyZSB0aGUgdmFsdWUgb2YgaW50ZW5kZWQgPT0gYXBwbGllZCBhcmUgaW4gdGhlIHN0YXRl
DQoiaW50ZW5kZWQgPSBhcHBsaWVk4oCdLiBBbGwgbGVhdmVzIHdpdGggaW50ZW5kZWQgIT0gYXBw
bGllZCBhcmUgaW4gZXJyb3INCih0YmQpDQoNCklmIGEgc2VydmVyIGlzIGluIHRoZSBwcm9jZXNz
IHRvIGFwcGx5IGNvbmZpZ3VyYXRpb24sIHRoZSByZXBvcnRlZCBhcHBsaWVkDQp2YWx1ZSBNQVkg
Tk9UIHJlZmxlY3QgdGhlIGFjdHVhbCBjb25maWd1cmF0aW9uIGluIGZvcmNlLiBUaGVuIHRoZSBm
YWN0DQp0aGF0IHRoZSB2YWx1ZXMgb2YgaW50ZW5kZWQgZXF1YWwgdGhvc2Ugb2YgYXBwbGllZCBT
SE9VTEQgTk9UIGJlIHRha2VuIGFzDQpyZWxpYWJsZSBpbmRpY2F0aW9uIHRoYXQgdGhlIGludGVu
ZGVkIGNvbmZpZ3VyYXRpb24gaXMgYWN0dWFsbHkgaW4gZm9yY2UuDQpMaWtld2lzZSBhIHZhbHVl
IG9mIGludGVuZGVkICE9IGFwcGxpZWQgU0hPVUxEIE5PVCBiZSB0YWtlbiBhcyByZWxpYWJsZQ0K
aW5kaWNhdGlvbiB0aGF0IHRoZSBpbnRlbmRlZCBjb25maWd1cmF0aW9uIGlzIG5vdCBpbiBmb3Jj
ZS4NCg0KTk9URTogd2hldGhlciB0aGUgYXBwbGllZD1pbnRlbmRlZCBzdGF0ZSBuZWVkcyB0byBi
ZSBjb2RlZCBvbiBhDQpwZXItbGVhZi1sZXZlbCBvciBoaWdoZXIgdXAgaW4gdGhlIHRyZWUgaXMg
YSBzZXBhcmF0ZSBpc3N1ZS4NCj4NCj4NCj4+Pj4gKEEsQikgb24gdHdvIGRpZmZlcmVudCBsZWFm
cyB3aXRoIHJvbGxiYWNrLW9uLWVycm9yIHNlbWFudGljLiBJZg0KPj4+PiBhcHBseWluZw0KPj4+
PiBBIHN1Y2NlZWRzIGFuZCB0aGUgY2xpZW50IHJlYWRzIHRoZSBhcHBsaWVkIHN0YXRlIHdoaWxl
IGFwcGx5aW5nIEIgaXMNCj4+Pj4gc3RpbGwgaW4gcHJvZ3Jlc3MsIGEgcm9sbGJhY2sgbWF5IHN0
aWxsIGhhcHBlbi4gVGhhdCB3b3VsZCBpbnZhbGlkYXRlDQo+Pj4+IHRoZQ0KPj4+PiBwcmV2aW91
cyB2YWx1ZSBvZiBBLiBJbiBvdGhlciB3b3JkcyBpdCBpcyB1bndpc2UgdG8gcmVhZCBkYXRhIGZy
b20gYQ0KPj4+PiBzb3VyY2Ugd2hpbGUgaXQgaXMgYWN0dWFsbHkgd3JpdGluZy4NCj4+PiBObywg
dGhpcyBpcyBmaW5lLCBhbmQgaXNuJ3QgYSBwcm9ibGVtLiAgVGhlIHNlcnZlciB3aWxsIGV2ZW50
dWFsbHkNCj4+PiBjb252ZXJnZSBvbiBhIHN0YXRlIGFuZCB0aGUgY2xpZW50IHdpbGwgYmUgbm90
aWZpZWQgb2YgdGhhdCBzdGF0ZS4NCj4+PiBUaGUNCj4+PiBmYWN0IHRoYXQgYSBjbGllbnQgbWln
aHQgdGVtcG9yYXJpbHkgc2VlIGEgdmFsaWQgc3RhdGUgdGhhdCBpcw0KPj4+IHN1YnNlcXVlbnRs
eSB1bmRvbmUgaXNuJ3QgYSBwcm9ibGVtLg0KPj4gSeKAmWQgc2VyaW91c2x5IHF1ZXN0aW9uIHRo
b3NlIHR3byBzdGF0ZW1lbnRzLiBXaGVuIHRoZSBzZXJ2ZXIgaXMgdXBkYXRpbmcNCj4+IGl0cyBh
cHBsaWVkIHN0YXRlIHlvdSBoYXZlIGF0IGJlc3QgYSA1MCUgY2hhbmNlIHRvIHJlYWQgdGhlIGNv
cnJlY3QNCj4+dmFsdWUuDQo+PiBXaGF0IG1lYW5pbmdmdWwgY29uY2x1c2lvbiBpcyB0aGUgY2xp
ZW50IHN1cHBvc2VkIHRvIHRha2UgZnJvbSB0aGF0PyBPdXQNCj4+IG9mIGRlc3BlcmF0aW9uLCBj
dXJyZW50IGltcGxlbWVudGF0aW9ucyB1c2UgdGhhdCDigJh0cmlja+KAmSBieSBwb2xsaW5nDQo+
PiB2YXJpb3VzIGxlYWYgdmFsdWVzIHRvIGZpZ3VyZSBvdXQgd2hldGhlciBhbiBpbnRlbmRlZCBz
dGF0ZSBoYXMgYWxyZWFkeQ0KPj4gYmVlbiBhcHBsaWVkIG9yIG5vdC4gSG93ZXZlciBzdWNoIGlu
dGVuc2l2ZSBwb2xsaW5nIGN5Y2xlcyBhcmUgbm8gbW9yZQ0KPj4gbmVlZGVkIG9uY2UgYSBzZXJ2
ZXIgbm90aWZpZXMgdGhlIGNsaWVudCB1cG9uIGNvbXBsZXRpb24gb2YgaW50ZW5kZWQNCj4+c3Rh
dGUNCj4+IGFwcGxpY2F0aW9uLg0KPj4gSWYgdGhlIGNsaWVudCBjaG9vc2VzIHRvIHJlYWQgYXBw
bGllZCBzdGF0ZSBkdXJpbmcgdGhhdCBwZXJpb2QsIGl0IGlzIGF0DQo+PiBsZWFzdCBhd2FyZSB0
aGF0IHRoZSBzdGF0ZSBpcyBqdXN0IGEgdGVtcG9yYXJ5IHNuYXBzaG90Lg0KPlRoZSBjbGllbnQg
ZG9lc24ndCBwb2xsLiAgSW5zdGVhZCBpdCByZWdpc3RlcnMgZm9yIG5vdGlmaWNhdGlvbiBvZg0K
PmNoYW5nZXMgYW5kIHJlY2VpdmVzIGEgY29udGludW91cyBzdHJlYW0gb2YgdXBkYXRlcy4NCj4N
Cj5BdCBhbnkgcG9pbnQgaW4gdGltZSwgdGhlIHZhbHVlIHJlYWQgYnkgdGhlIGNsaWVudCBpcyBj
b3JyZWN0LCBpdCBqdXN0DQo+aGFwcGVucyB0aGF0IHRoZSBzeXN0ZW0gY2FuIGJlIHRob3VnaHQg
b2YgYmVpbmcgaW4gdGhlIHN0YXRlIG9mIGNvbnN0YW50DQo+Zmx1eC4NCj4NCj5FLmcuIHRoZSBn
bG9iYWwgQkdQIHJvdXRpbmcgdGFibGUgaXMgY29uc3RhbnRseSBjaGFuZ2luZywgYnV0IHRoYXQN
Cj5kb2Vzbid0IG1lYW4gdGhhdCB5b3UgY2FuJ3QgdGFrZSBhIHVzZWZ1bCBzbmFwc2hvdCBvZiBp
dCwgb3IgbW9uaXRvciBob3cNCj5pdCBpcyBjaGFuZ2luZy4NCj4NCj5UaGFua3MsDQo+Um9iDQo+
DQo+DQo+Pg0KPj4+IFRoYW5rcywNCj4+PiBSb2INCj4+Pg0KPj4+DQo+Pj4+PiBUaGFua3MsDQo+
Pj4+PiBSb2INCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4+IExhZGENCj4+Pj4+Pg0KPj4+Pj4+PiAgICAg
ICBsaXN0IGludGVyZmFjZSB7DQo+Pj4+Pj4+ICAgICAgICAgZGVzY3JpcHRpb24tY29uZmlnDQo+
Pj4+Pj4+ICAgICAgICAgICAiVGhlIGxpc3Qgb2YgY29uZmlndXJlZCBpbnRlcmZhY2VzIG9uIHRo
ZSBkZXZpY2UuDQo+Pj4+Pj4+ICAgICAgICAgICAgLi4uIjsNCj4+Pj4+Pj4gICAgICAgICBkZXNj
cmlwdGlvbi1vcGVyDQo+Pj4+Pj4+ICAgICAgICAgICAiVGhlIGxpc3Qgb2YgaW50ZXJmYWNlcyBv
biB0aGUgZGV2aWNlLg0KPj4+Pj4+PiAgICAgICAgICAgIA0KPj4+Pj4+PiAgICAgICAgICAgIFN5
c3RlbS1jb250cm9sbGVkIGludGVyZmFjZXMgY3JlYXRlZCBieSB0aGUgc3lzdGVtIGFyZQ0KPj4+
Pj4+PiAgICAgICAgICAgIGFsd2F5cyBwcmVzZW50IGluIHRoaXMgbGlzdCwgd2hldGhlciB0aGV5
IGFyZQ0KPj4+Pj4+PmNvbmZpZ3VyZWQgb3INCj4+Pj4+Pj4gICAgICAgICAgICBub3QuDQo+Pj4+
Pj4+ICAgICAgICAgICAgLi4uIjsNCj4+Pj4+Pj4gICAgICAgfQ0KPj4+Pj4+Pg0KPj4+Pj4+Pg0K
Pj4+Pj4+PiAvbWFydGluDQo+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KPj4+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4+Pj4gbmV0bW9kQGll
dGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1v
ZA0KPj4+PiAuDQo+Pj4+DQo+DQoNCg==


From nobody Wed Jan 13 03:34:20 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580B81A7025 for ; Wed, 13 Jan 2016 03:34:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnDdp5cEDGo6 for ; Wed, 13 Jan 2016 03:34:17 -0800 (PST)
Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::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 275771A7020 for ; Wed, 13 Jan 2016 03:34:17 -0800 (PST)
Received: by mail-lf0-x233.google.com with SMTP id h129so58159750lfh.3 for ; Wed, 13 Jan 2016 03:34: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:date:message-id:subject:from:to :cc:content-type; bh=JOqq+ljYT/l2BVR8UWiFXIe1CIQjXbpXbXF0MUiE/4Y=; b=aRCeIJ2kujr4QPM+fUwIdfPKtbelLToE1ang8S0iKWei6s7Rmxkdmv64XVM6VdloCk OR4KNgzs7ptUKphVb+/3CbEQdWUThPlRUql4PF6pONW6UZ/9jvUkjrusuknliOWiIcEs wv7Z+R9CDPBKjLNGLQkWIngJYbbLgN5EmOer7vG0yB8DkTyCXniJLaCC0pyRxHIn4Hpk h5k3y+0ONTwVgFItka0GuQ7Fl1/HR3M7+HopWUKMFLHgoB5Li6tkk/EZiw5Da0xVTIoC Ae5+j8ay4TbWNPlsMXQEnAm1U87oTDbroNPouUgWaHC5dlE75FY+s5y51a1UrzZ4Ho29 CNsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JOqq+ljYT/l2BVR8UWiFXIe1CIQjXbpXbXF0MUiE/4Y=; b=aYYoeyMZKJxEP4dRFTXOLuwbXearVQWEciLp3QzxFEo7hGSgE9NpHPwUx/Nu2PQxa+ 5I/vGt8xPCXy0PpY+u3F2SIiHD5CwtjFiR0MEYzeV20KTmxsjOEMl03BihBXebRBiJiy GsL0HCLVUr/5O9muBBhbvYtYkn2W+GgEjvwHZPj62JVlbPAvufNvmd+SPDiZwOQAcnMt szDVsPoJqS4dS/U9N/y0596tCQ/71mizl1k6B44vz+/Cgx9sTNImr1tAADlObtWTvVC2 xiBzdKV1xSuII/4l4I9XSz067B8mkOJ1UFcEGYsFVfonAR6EP+aJwD93kFxgzGoehVgd 213w==
X-Gm-Message-State: ALoCoQk2vSYL2CTLK18YDn6KHB65+IBe0rO5PpuU36f6gaE7/qUjaGA/G0WAcm87cBsuSd9TAWtbP++aZRmbM4rzdCrs6ej3qw==
MIME-Version: 1.0
X-Received: by 10.25.155.194 with SMTP id d185mr521524lfe.8.1452684855198; Wed, 13 Jan 2016 03:34:15 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Wed, 13 Jan 2016 03:34:15 -0800 (PST)
In-Reply-To: <20160113.120725.2066939247728231437.mbj@tail-f.com>
References:  <20160113.113104.343612206142993990.mbj@tail-f.com> <4019146D-CBAA-498A-AB70-2E376807E729@nic.cz> <20160113.120725.2066939247728231437.mbj@tail-f.com>
Date: Wed, 13 Jan 2016 03:34:15 -0800
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=001a113fbdd4c3e5940529358ca9
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] action-stmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Jan 2016 11:34:19 -0000

--001a113fbdd4c3e5940529358ca9
Content-Type: text/plain; charset=UTF-8

On Wed, Jan 13, 2016 at 3:07 AM, Martin Bjorklund  wrote:

> Ladislav Lhotka  wrote:
> >
> > > On 13 Jan 2016, at 11:31, Martin Bjorklund  wrote:
> > >
> > > Ladislav Lhotka  wrote:
> > >> Martin Bjorklund  writes:
> > >>
> > >>> Hi,
> > >>>
> > >>> Andy Bierman  wrote:
> > >>>> Hi,
> > >>>>
> > >>>> The action-stmt example on page 27 is wrong.
> > >>>> The  element is missing.  It is shown correctly
> > >>>> on page 105.
> > >>>> p27
> > >>>>   > >>>>          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> > >>>>       
> > >>>>         eth1
> > >>>>         
> > >>>>           192.0.2.1
> > >>>>         
> > >>>>       
> > >>>>     
> > >>>>
> > >>>>
> > >>>> p105
> > >>>>
> > >>>>      > >>>>          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> > >>>>       
> > >>>>         
> > >>>>           apache-1
> > >>>>           
> > >>>>             2014-07-29T13:42:00Z
> > >>>>           
> > >>>>         
> > >>>>       
> > >>>>     
> > >>>
> > >>> Fixed.
> > >>>
> > >>>> Sec. 7.15  provides few details wrt/ input processing.
> > >>>> Extra input is ignored? (draft is silent about that).
> > >>>> YANG attributes like "insert"or "operation" are ignored? (also
> silent).
> > >>>
> > >>> Right, just as the text for rpcs.  Do you think we need to add some
> > >>> text about this?
> > >>>
> > >>>> Sec 7.15.2, para 2 is not clear whether the XML hierarchy
> > >>>> has to exist in any particular datastore (or opstate).
> > >>>> Since there is no mention of datastores in 7.15, I
> > >>>> assume the text just refers to the input containing
> > >>>> schema-valid XML, which may or may not correspond
> > >>>> to actual data instances somewhere inn the server.
> > >>>
> > >>> Yes.
> > >>
> > >> Hmm, so if I understand in correctly, actions can be attached also to
> > >> state data nodes.
> > >
> > > Correct.  But actually, I think that the data node instance that has
> > > the action must exist at the time the action is applied.
> >
> > OK.
> >
>

I asked about this point and the answer was the instance may or may not
exist.
The current text does not say anything about conceptual instances
that correspond to the ancestors and keys provided in the request.

Why would these rules be different for config vs. opstate?

> >
> > >> But sec. 7.15.2 says: "For lists, all key leafs MUST
> > >> also be included." What if a list in state data has no keys?
> > >
> > > No keys means that "all keys" is the empty set.
> >
> > How does the server then select the list entry to which the action
> > is to be applied?
>
> Sorry, I missed this point.  You are correct.  Invoking an action in a
> descendant node to a list w/o keys is not possible.
>
>
> /martin
>
>
>
>
Andy

--001a113fbdd4c3e5940529358ca9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Wed, Jan 13, 2016 at 3:07 AM, Martin Bjorklund <=
;mbj@tail-f.com>=
 wrote:
Ladislav Lhotka <lhotka@nic.cz> wrote:

>

> > On 13 Jan 2016, at 11:31, Martin Bjorklund <mbj@tail-f.com> wrote:

> >

> > Ladislav Lhotka <lhotka@nic.c=
z> wrote:

> >> Martin Bjorklund <mbj@ta=
il-f.com> writes:

> >>

> >>> Hi,

> >>>

> >>> Andy Bierman <an=
dy@yumaworks.com> wrote:

> >>>> Hi,

> >>>>

> >>>> The action-stmt example on page 27 is wrong.

> >>>> The <action> element is missing.=C2=A0 It is sh=
own correctly

> >>>> on page 105.

> >>>> p27

> >>>>=C2=A0 <rpc message-id=3D"102"

> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns=3D"urn:i=
etf:params:xml:ns:netconf:base:1.0">

> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0<interface xmlns=3D"=
;http://acme.example.com/system">

> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>eth1<=
/name>

> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<ping>

> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<destinati=
on>192.0.2.1</destination>

> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</ping>

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

> >>>>=C2=A0 =C2=A0 =C2=A0</rpc>

> >>>>

> >>>>

> >>>> p105

> >>>>

> >>>>=C2=A0 =C2=A0 =C2=A0<rpc message-id=3D"101&quo=
t;

> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns=3D"urn:i=
etf:params:xml:ns:netconf:base:1.0">

> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0<action xmlns=3D"ur=
n:ietf:params:xml:ns:yang:1">

> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<server xmlns=3D&=
quot;http://example.net/server-farm">

> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>a=
pache-1</name>

> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<reset>=


> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<re=
set-at>2014-07-29T13:42:00Z</reset-at>

> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</reset>=
;

> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</server>

> >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0</action>

> >>>>=C2=A0 =C2=A0 =C2=A0</rpc>

> >>>

> >>> Fixed.

> >>>

> >>>> Sec. 7.15=C2=A0 provides few details wrt/ input proce=
ssing.

> >>>> Extra input is ignored? (draft is silent about that).=


> >>>> YANG attributes like "insert"or "opera=
tion" are ignored? (also silent).

> >>>

> >>> Right, just as the text for rpcs.=C2=A0 Do you think we n=
eed to add some

> >>> text about this?

> >>>

> >>>> Sec 7.15.2, para 2 is not clear whether the XML hiera=
rchy

> >>>> has to exist in any particular datastore (or opstate)=
.

> >>>> Since there is no mention of datastores in 7.15, I
> >>>> assume the text just refers to the input containing
> >>>> schema-valid XML, which may or may not correspond

> >>>> to actual data instances somewhere inn the server.
> >>>

> >>> Yes.

> >>

> >> Hmm, so if I understand in correctly, actions can be attached=
 also to

> >> state data nodes.

> >

> > Correct.=C2=A0 But actually, I think that the data node instance =
that has

> > the action must exist at the time the action is applied.

>

> OK.

>

I asked about this point and the a=
nswer was the instance may or may not exist.
The current text doe=
s not say anything about conceptual instances
that correspond to =
the ancestors and keys provided in the request.

Wh=
y would these rules be different for config vs. opstate?


> >

> >> But sec. 7.15.2 says: "For lists, all key leafs MUST

> >> also be included." What if a list in state data has no k=
eys?

> >

> > No keys means that "all keys" is the empty set.

>

> How does the server then select the list entry to which the action

> is to be applied?



Sorry, I missed this point.=C2=A0 You are correct.=C2=A0 Invoking an action=
 in a

descendant node to a list w/o keys is not possible.





/martin









Andy<=
/div>



--001a113fbdd4c3e5940529358ca9--


From nobody Wed Jan 13 03:40:27 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B3E1A7026 for ; Wed, 13 Jan 2016 03:40:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEAajueSPPOi for ; Wed, 13 Jan 2016 03:40:24 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 64EAF1A702F for ; Wed, 13 Jan 2016 03:40:24 -0800 (PST)
Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id 7E0021AE0A54; Wed, 13 Jan 2016 12:40:23 +0100 (CET)
Date: Wed, 13 Jan 2016 12:40:30 +0100 (CET)
Message-Id: <20160113.124030.1590963955569955531.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund 
In-Reply-To: 
References: <4019146D-CBAA-498A-AB70-2E376807E729@nic.cz> <20160113.120725.2066939247728231437.mbj@tail-f.com> 
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] action-stmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Jan 2016 11:40:26 -0000

Andy Bierman  wrote:
> On Wed, Jan 13, 2016 at 3:07 AM, Martin Bjorklund  wrote:
> 
> > Ladislav Lhotka  wrote:
> > >
> > > > On 13 Jan 2016, at 11:31, Martin Bjorklund  wrote:
> > > >
> > > > Ladislav Lhotka  wrote:
> > > >> Martin Bjorklund  writes:
> > > >>
> > > >>> Hi,
> > > >>>
> > > >>> Andy Bierman  wrote:
> > > >>>> Hi,
> > > >>>>
> > > >>>> The action-stmt example on page 27 is wrong.
> > > >>>> The  element is missing.  It is shown correctly
> > > >>>> on page 105.
> > > >>>> p27
> > > >>>>   > > >>>>          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> > > >>>>       
> > > >>>>         eth1
> > > >>>>         
> > > >>>>           192.0.2.1
> > > >>>>         
> > > >>>>       
> > > >>>>     
> > > >>>>
> > > >>>>
> > > >>>> p105
> > > >>>>
> > > >>>>      > > >>>>          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> > > >>>>       
> > > >>>>         
> > > >>>>           apache-1
> > > >>>>           
> > > >>>>             2014-07-29T13:42:00Z
> > > >>>>           
> > > >>>>         
> > > >>>>       
> > > >>>>     
> > > >>>
> > > >>> Fixed.
> > > >>>
> > > >>>> Sec. 7.15  provides few details wrt/ input processing.
> > > >>>> Extra input is ignored? (draft is silent about that).
> > > >>>> YANG attributes like "insert"or "operation" are ignored? (also
> > silent).
> > > >>>
> > > >>> Right, just as the text for rpcs.  Do you think we need to add some
> > > >>> text about this?
> > > >>>
> > > >>>> Sec 7.15.2, para 2 is not clear whether the XML hierarchy
> > > >>>> has to exist in any particular datastore (or opstate).
> > > >>>> Since there is no mention of datastores in 7.15, I
> > > >>>> assume the text just refers to the input containing
> > > >>>> schema-valid XML, which may or may not correspond
> > > >>>> to actual data instances somewhere inn the server.
> > > >>>
> > > >>> Yes.
> > > >>
> > > >> Hmm, so if I understand in correctly, actions can be attached also to
> > > >> state data nodes.
> > > >
> > > > Correct.  But actually, I think that the data node instance that has
> > > > the action must exist at the time the action is applied.
> > >
> > > OK.
> > >
> >
> 
> I asked about this point and the answer was the instance may or may not
> exist.

I know - my fault, sorry.

> The current text does not say anything about conceptual instances
> that correspond to the ancestors and keys provided in the request.

Right.  Two options:

  1) Keep current text.  When an action is invoked, the parent node
     may or may not exist.

  2) Add text that states that the when an action is invoked, the
     parent node MUST exist.

I prefer 2.


> Why would these rules be different for config vs. opstate?

No, they would be the same.


/martin


From nobody Wed Jan 13 03:44:47 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8A71A86E4 for ; Wed, 13 Jan 2016 03:44:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.652
X-Spam-Level: 
X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yJsPVB6-Nxv for ; Wed, 13 Jan 2016 03:44:44 -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 8A9E41A86E9 for ; Wed, 13 Jan 2016 03:44:42 -0800 (PST)
Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 442E918183B; Wed, 13 Jan 2016 12:44:11 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452685451; bh=XsT/AsIYtPglqM1NlqxmBc3EofVEKCOb1nTUsE3s47Y=; h=From:Date:To; b=TaTUe/V92P+6sj4I4ZsSbNZ/9bez7DCGvyH1bxUen3GV7KS7MeKcqCXBxJyUY5YTj oSWqr44r4YXtMu+ILOWgDniEv1aDLGctZ1E3AP/fq6oNxHg8xuwnCOlOVD04Rh7Yb7 Uk+LMMohyikrhay0Dh0ZF1A/P50Wl//nj8yjsAzk=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Wed, 13 Jan 2016 12:44:11 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <52E2FD78-945C-4CC7-A1F6-8291C697D400@nic.cz>
References:  <20160113.113104.343612206142993990.mbj@tail-f.com> <4019146D-CBAA-498A-AB70-2E376807E729@nic.cz> <20160113.120725.2066939247728231437.mbj@tail-f.com> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] action-stmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Jan 2016 11:44:46 -0000

> On 13 Jan 2016, at 12:34, Andy Bierman  wrote:
>=20
>=20
>=20
> On Wed, Jan 13, 2016 at 3:07 AM, Martin Bjorklund  =
wrote:
> Ladislav Lhotka  wrote:
> >
> > > On 13 Jan 2016, at 11:31, Martin Bjorklund  wrote:
> > >
> > > Ladislav Lhotka  wrote:
> > >> Martin Bjorklund  writes:
> > >>
> > >>> Hi,
> > >>>
> > >>> Andy Bierman  wrote:
> > >>>> Hi,
> > >>>>
> > >>>> The action-stmt example on page 27 is wrong.
> > >>>> The  element is missing.  It is shown correctly
> > >>>> on page 105.
> > >>>> p27
> > >>>>   > >>>>          xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
> > >>>>       
> > >>>>         eth1
> > >>>>         
> > >>>>           192.0.2.1
> > >>>>         
> > >>>>       
> > >>>>     
> > >>>>
> > >>>>
> > >>>> p105
> > >>>>
> > >>>>      > >>>>          xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
> > >>>>       
> > >>>>         
> > >>>>           apache-1
> > >>>>           
> > >>>>             2014-07-29T13:42:00Z
> > >>>>           
> > >>>>         
> > >>>>       
> > >>>>     
> > >>>
> > >>> Fixed.
> > >>>
> > >>>> Sec. 7.15  provides few details wrt/ input processing.
> > >>>> Extra input is ignored? (draft is silent about that).
> > >>>> YANG attributes like "insert"or "operation" are ignored? (also =
silent).
> > >>>
> > >>> Right, just as the text for rpcs.  Do you think we need to add =
some
> > >>> text about this?
> > >>>
> > >>>> Sec 7.15.2, para 2 is not clear whether the XML hierarchy
> > >>>> has to exist in any particular datastore (or opstate).
> > >>>> Since there is no mention of datastores in 7.15, I
> > >>>> assume the text just refers to the input containing
> > >>>> schema-valid XML, which may or may not correspond
> > >>>> to actual data instances somewhere inn the server.
> > >>>
> > >>> Yes.
> > >>
> > >> Hmm, so if I understand in correctly, actions can be attached =
also to
> > >> state data nodes.
> > >
> > > Correct.  But actually, I think that the data node instance that =
has
> > > the action must exist at the time the action is applied.
> >
> > OK.
> >
>=20
> I asked about this point and the answer was the instance may or may =
not exist.

My question is about the opposite situation: there may be multiple =
candidate instances/list entries.

> The current text does not say anything about conceptual instances
> that correspond to the ancestors and keys provided in the request.
>=20
> Why would these rules be different for config vs. opstate?

Because opstate lists needn't have keys.

Lada

>=20
> > >
> > >> But sec. 7.15.2 says: "For lists, all key leafs MUST
> > >> also be included." What if a list in state data has no keys?
> > >
> > > No keys means that "all keys" is the empty set.
> >
> > How does the server then select the list entry to which the action
> > is to be applied?
>=20
> Sorry, I missed this point.  You are correct.  Invoking an action in a
> descendant node to a list w/o keys is not possible.
>=20
>=20
> /martin
>=20
>=20
>=20
>=20
> Andy

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





From nobody Wed Jan 13 06:37:42 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED59E1B2E4E for ; Wed, 13 Jan 2016 06:37:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyGfMtWzgLPV for ; Wed, 13 Jan 2016 06:37:36 -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 C134B1B2E41 for ; Wed, 13 Jan 2016 06:37:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23364; q=dns/txt; s=iport; t=1452695855; x=1453905455; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=j0MvTk4qEir/E6x4AHKPHn1awG/Yqv6JSmnsYSozne4=; b=ksaCjX/rROZ9XdkJeWhJHqRoLXlkxokKFWLRvdWvuo0LqGRJe58ZeZ3/ /vfrdfy7iNfouLZb8IDTrd8pcuKcxNAKdWqLp1qsPZ5fmGwIuIWYPcfRJ 3ZhQYgWrHCgb0b1z8W/UhDyhNitAmGpzsDJ2vhmEwwUvbe9SBLvuOWV2d E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvBABiYJZW/xbLJq1ehAxtiFq1DhgKh?= =?us-ascii?q?SNKAoICAQEBAQEBgQuENAEBAQMBAQEBFwkPAQU2CgEFCwsOAggCAgUWCwICCQM?= =?us-ascii?q?CAQIBFTAGAQwGAgEBFQKICwgOr3aQOgEBAQEBAQEBAQEBAQEBAQEBAQEBARQEg?= =?us-ascii?q?QGFVYN7gQSEMQ2DNoFJAQSHYocThAeEGYVDgnSFI4FehESDByN5hDuDQ4IjhHu?= =?us-ascii?q?Dc2SCERyBXT40hFEBHwSBJwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.22,289,1449532800"; d="scan'208";a="624490634"
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; 13 Jan 2016 14:37:32 +0000
Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u0DEbWbk023800; Wed, 13 Jan 2016 14:37:32 GMT
To: Gert Grammel , "netmod@ietf.org" 
References:  <5693C32E.7020708@cisco.com> <31E9D485-9349-448D-99A3-DD20F5E5AF09@nic.cz> <20160111.211837.377848045119250710.mbj@tail-f.com>  <5694D180.6030300@cisco.com>  <569507FA.1070805@cisco.com>  <569539AB.80007@cisco.com> 
From: Robert Wilton 
Message-ID: <5696612C.1040109@cisco.com>
Date: Wed, 13 Jan 2016 14:37:32 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [netmod] applied configuration and system-controlled entries
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Jan 2016 14:37:41 -0000

Hi Gert,

I'm wondering if all the discussion here would be more appropriate in 
the context of a specific solution draft and hence best deferred until a 
overall solution approach has been chosen?

Otherwise, if there is a specific proposal to change the requirements 
draft then could that be clarified please so that we can focus on that.

Thanks,
Rob


On 13/01/2016 11:33, Gert Grammel wrote:
>
> On 2016-12-01 18:36, "Robert Wilton"  wrote:
>
>>
>> On 12/01/2016 16:02, Gert Grammel wrote:
>>> On 2016-12-01 15:04, "Robert Wilton"  wrote:
>>>
>>>> On 12/01/2016 10:42, Gert Grammel wrote:
>>>>> On 2016-12-01 11:12, "netmod on behalf of Robert Wilton"
>>>>>  wrote:
>>>>>
>>>>>> On 12/01/2016 09:05, Ladislav Lhotka wrote:
>>>>>>> Martin Bjorklund  writes:
>>>>>>>
>>>>>>>> Ladislav Lhotka  wrote:
>>>>>>>>>> On 11 Jan 2016, at 15:58, Robert Wilton 
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 11/01/2016 14:27, Ladislav Lhotka wrote:
>>>>>>>>>>>> On 11 Jan 2016, at 15:11, Juergen Schoenwaelder
>>>>>>>>>>>>  wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Jan 11, 2016 at 02:54:36PM +0100, Martin Bjorklund
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> Ladislav Lhotka  wrote:
>>>>>>>>>>>>>> Hi Gert,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 11 Jan 2016, at 14:25, Gert Grammel
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Lada,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The requirement says:
>>>>>>>>>>>>>>>          D.  When a configuration change for any intended
>>>>>>>>>>>>>>> configuration
>>>>>>>>>>>>>>>              node has been successfully applied to the server
>>>>>>>>>>>>>>> (e.g. not
>>>>>>>>>>>>>>>              failed, nor deferred due to absent hardware)
>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>              existence and value of the corresponding applied
>>>>>>>>>>>>>>>              configuration node must match the intended
>>>>>>>>>>>>>>> configuration
>>>>>>>>>>>>>>>              node.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I don't see that this would limit the case you described
>>>>>>>>>>>>>>> below.
>>>>>>>>>>>>>>> In
>>>>>>>>>>>>>>> your case there is no intended config, hence there is no
>>>>>>>>>>>>>>> "corresponding applied configuration" either.
>>>>>>>>>>>>>> You are right, the requirement can be interpreted this way. I
>>>>>>>>>>>>>> thought
>>>>>>>>>>>>>> that applied configuration was supposed to be identical to
>>>>>>>>>>>>>> intended
>>>>>>>>>>>>>> after some synchronization period.
>>>>>>>>>>>>> This is a very important point to clarify.  Can there ever be
>>>>>>>>>>>>> data in
>>>>>>>>>>>>> "applied" that is not in "intended"?  I think Anees & Rob
>>>>>>>>>>>>> previously
>>>>>>>>>>>>> said "no", but I might be wrong.
>>>>>>>>>>>>>
>>>>>>>>>>>> If there is time delay between editing intended and the applied
>>>>>>>>>>>> config
>>>>>>>>>>>> matching the edits of intended, then I supose this can happen
>>>>>>>>>>>> (I
>>>>>>>>>>>> delete a resource from intended but it is still around until
>>>>>>>>>>>> intended
>>>>>>>>>>>> has been fully synced). I would find it interesting if some
>>>>>>>>>>>> edits
>>>>>>>>>>>> are
>>>>>>>>>>> Using applied config for system-controlled entries would require
>>>>>>>>>>> that
>>>>>>>>>>> such an entry stays (forever) in applied config even after it
>>>>>>>>>>> has
>>>>>>>>>>> been
>>>>>>>>>>> deleted from intended.
>>>>>>>>>> I think that this would make life harder for clients.
>>>>>>>>> Hmm, I would say the opposite. For one, we could simplify the data
>>>>>>>>> models by reducing the duplicities in configuration and state
>>>>>>>>> trees.
>>>>>>>> This is the old idea of having the "operational state" datastore,
>>>>>>>> which would be all config true + all config false nodes.  One issue
>>>>>>>> with this is that the semantics of the node is different in the
>>>>>>>> different data stores, even if the syntax (by definition!) is the
>>>>>>>> same.  In order to handle this properly you need either two
>>>>>>>> different
>>>>>>>> description statements, or two "sections" within the description
>>>>>>>> statement.
>>>>>>> I think this is not much different from default values. Leaves and
>>>>>>> leaf-lists that have them defined in the data model may not be
>>>>>>> present
>>>>>>> in intended config, yet one can consider them to be in applied
>>>>>>> config.
>>>>>> I think that default values are logically just a way to make the
>>>>>> configuration data more concise.  I.e. everywhere you have a default
>>>>>> value then the equivalent configuration could be expressed with a
>>>>>> explicit value set instead.
>>>>> I think default values are just what they are. A set of values on the
>>>>> server that have not been explicitly set by the client via
>>>>> intended-config.
>>>> The default values are determined by the schema and the intended
>>>> configuration.  You need to know both to know what default values the
>>>> server is expected to use.
>>> No disagreement. The only point is whether default values *shall* or
>>> *may*
>>> be provisioned via intended config
>> I meant "May".
> agreed: default values *may* be provisioned via intended config
>
>>>> But in terms of what is actually applied, an intended configuration
>>>> with
>>>> defaults values can be mapped into an equivalent intended configuration
>>>> with all implicit defaults replaced by the equivalent explicit values.
>>>> What gets applied  in the device should be the same in both cases.
>>>>
>>>>
>>>>>     It is certainly possible to set default values in
>>>>> intended-config explicitly, but it is not strictly needed.
>>>> Yes, of course.
>>>>
>>>>>> As such, I think that the default values apply equally to both the
>>>>>> intended and applied configuration.
>>>>> While this is allowed (see above), I would consider default values
>>>>> apply
>>>>> in practice to the applied config
>>>> I think that I disagree on this point.
>>> OK, let’s keep this point for a further discussion.
>>>> The intended configuration is only complete when you consider its
>>>> associated YANG schema and implicit default values.
>>> True, but it doesn’t mean that the client which holds the complete
>>> intended config has to explicitly push everything down to the server.
>>> Again this is the distinction between *may* and *shall* and worth a
>>> discussion.
>> Yes, I think that it is "may".
>>
>>>    
>>>>>> If after a config request it takes time for the system to apply a
>>>>>> default value, then ideally the applied configuration should have an
>>>>>> explicit leaf to show what value is actually in effect until the
>>>>>> default
>>>>>> value has actually been applied in the system.
>>>>> If the client has an indication whether the configuration application
>>>>> is
>>>>> finished (with or without errors), it knows that the applied config is
>>>>> now
>>>>> stable to be read. Reading applied config during an operation should
>>>>> be
>>>>> avoided. Hence I would question the need for a per-leaf state and
>>>>> advocate
>>>>> for a per-server state.
>>>> I think that the whole purpose of the opstate requirements is that the
>>>> operators effectively want to be able to track on a per leaf element
>>>> rather than a per-server element.
>>> The point has been that the client wants to know whether it’s intended
>>> configuration has been applied. This information is missing from the old
>>> asynch model and hence creates uncertainty. Any read attempt of the
>>> client
>>> related to applied configuration may fall into a transition period and
>>> is
>>> only a snapshot of a wobbly state.
>> Yes, and that isn't a problem.
> Whether it is a problem depends on what for the information is used by the
> client. If the client periodically checks values to monitor the progress
> of an intended config application, it wouldn’t be a problem. This is what
> is actually done since there is a lack of information whether the intended
> configuration is fully applied.
> However if the client is collecting leaf information in order to derive an
> action, it has to rely on the state. So here there is information needed
> that can be relied upon.
> We are discussing whether that information should be on a tree or a leaf
> level. My preference goes for a higher level because it is more reliable
> to implement, but as with all preferences there needs to be consensus.
> If one  implements state on a leaf level there are 3 cases to consider:
> A) rollback-on-error: All leafs touched in the config have to remain
> ‘dirty’ (see below for definition) until the last value has been applied
> or the rollback is finished. Then in a second step the dirty flag is
> removed.
> B) stop-on-error: first all leafs supposed to be touched by the intended
> config are marked, then config is applied and the ‘dirty’ flag can
> immediately be removed from the leafs. However if an error occurs the
> dirty flag of all subsequent leafs has to be cleared since there is no
> config in progress anymore
> C) continue on error: mark all affected leafs with the dirty flag and
> clear it after leafs have been configured (successfully or non-sucessfully)
>
> I fear that we’ll eventually end up with something like an orphan control
> daemon in the server to clean up all the forgotten states, rendering the
> fine level of state less useful than it appear.
>
>> The intended config is updated, and then the applied config state
>> converges on the intended config.
>>
>>> Essentially we are discussing where to put a dirty-flag. In my (less
>>> granular) view it is prudent to put the dirty-flag high up in the tree
>>> and
>>> keep it true until the state change completed (irrespective if it was
>>> successful or not). Another way is to keep a very granular view and
>>> stick
>>> the dirty flag on all leafs that are supposed to be touched by the
>>> intended state and cleaning them up after *all* intended config has been
>>> attempted to apply. A bit of more hassle from an implementers point of
>>> view, and I am not sure if it is worth.
>> Having a single dirty flag doesn't really meet the requirements (as
>> stated in the requirements draft).  It means that config reads from the
>> server are unavailable (or stale) whilst a config change is in progress
>> (which could take a long time).
> Sorry, I was using a sloppy term without definition. I meant ‘dirty’ flag
> is a marker indicating that a configuration application is still running.
> Technically such a flag could be sticked at any point in the tree
> including leafs. In other words, a client can read whatever and whenever
> it wants. ‘dirty’ indicates that the attribute value cannot be relied
> upon, since a configuration is ongoing. Hope this clarifies that there is
> no unavailable or stale period for reading as stated in the requirements.
>
>> Instead, the operators requirement is that the tracking is done on a per
>> leaf basis (e.g. like the OpenConfig YANG models on
>> https://github.com/openconfig/public), I believe with the expectation
>> that the server should update the leaves as the configuration is being
>> applied.  I.e. if the server had processed half the configuration from a
>> 1 million entry config then ideally it should be updating the applied
>> configuration leaves as it goes so that the client knows what is
>> currently programmed at that particular point in time.  In the ideal
>> world the server should always be telling the client what configuration
>> is applied at that specific point in time that the request is processed.
>>
>>>    
>>>> I might be wrong, but I think that the design being consider by the
>>>> opstate operators is along the lines of an eventual consistent model.
>>>> E.g. something along the lines of:
>>>>
>>>> At any point in time the operator knows what configuration state they
>>>> would a device to be in (i.e. the intended configuration).
>>> OK
>>>> Whenever the client changes their intended configuration, they push
>>>> down
>>>> the updated intended configuration to the device.
>>> OK, from now on the client is blind about the applied state of the
>>> server
>>> unless it can guess it from e.g. Derived state and so on.
>> No, the client can read the current state from the server at any point
>> in time, and ideally it should reflect the configuration at that point
>> in time (even if it is half way through a config request).
> While we are in agreement that the client can poll the applied state at
> any point in time (see above), it is not obliged to do so given that the
> server sends an indication when the config is applied.
> I also realized that I didn’t explain sufficiently what i meant with
> ‘blind’. Take the case of 2 different implementations of a server applying
> configuration:
> A) first set the new value in the internal database (aka. applied config)
> and then program the HW.
> B) first program the HW and then reflect the state in the internal database
>
> Say the client’s intention is to change a leaf value from X to Y. After
> configuring, the client is reading the leaf value between the first and
> the second write:
> A) will report Y, but still runs with X
> B) will report X, but runs already with Y
>
> After successful application (after step 2), both implementations will
> consistently execute in HW and report the same value in the applied
> config. However the client can’t rely on the information it reads in the
> meantime - that’s what I meant with ‘blind’. If the only purpose is to
> monitor the progress of applying the intended state, this level of
> information is good enough, but I would argue that there are less intense
> mechanisms to do so.
> If the client truly needs to rely on the information read, it has to wait
> for completion.
>>>> The device starts applying the change (using the specified error
>>>> handling semantics)
>>> OK
>>>> They register for notification for changes to all intended/applied
>>>> config and derived state on the device so that they have a feedback
>>>> mechanism to know whether the configuration is being successfully
>>>> applied.
>>> OK, so from now on the client knows that the new intended config is
>>> active. It also means that the client can reliably read applied state.
>> The changes to the individual leaves can be notified independently as
>> they change state.
> See discussion above about rollback-on-error etc. requiring a careful
> definition on when to send notifications.
>> The client can reliably read the applied state at
>> any time.
> No agreement here. As discussed above: "A client can read applied state at
> any time, but it can’t reliably assume it being applied before completion
> of an ongoing configuration”.
>>
>>>>>> This does open the question of how do you express the case that no
>>>>>> value
>>>>>> has been applied rather than a different value.  For the opstate
>>>>>> encoding solution draft that I put forward (or using meta-data),
>>>>>> then I
>>>>>> think that it would probably be possible to extend the encoding to
>>>>>> explicitly include this information if required.
>>>>> Perhaps I am missing something here. If the value supposed to be
>>>>> applied
>>>>> is the same that already exists, just skip it in the server.
>>>> The case I was considering is where the server has no value applied
>>>> (e.g. for an optional feature) rather than the default value.
>>> Whatever value the server applied (none or default) shouldn’t be an
>>> issue
>>> unless the intended config imposes a certain value.
>> It is an issue because the client wants to know what configuration a
>> device is actually running.  Ideally it wants a given device to exactly
>> implement the configuration that they are requesting.  They don't really
>> want lots of random device specific values that will require custom
>> client code to handle.
> I think we are in agreement that the client *may* configure default values
> to address such cases.
>>
>>>    I guess you had in
>>> mind on how to deal with the opstate of a non-value. Pushing the opstate
>>> higher up the tree would probably address the issue (see above).
>>>>>> Alternatively, and for the other proposed opstate solutions, then I
>>>>>> expect that the most appropriate ideal semantics to handle this
>>>>>> scenario
>>>>>> would be to delay marking the parent object as being applied until
>>>>>> every
>>>>>> descendent child leaf with a default value set has a value applied in
>>>>>> the system, either to the expected default value (in which case the
>>>>>> child leaf wouldn't need to be present in the applied config), or
>>>>>> transiently to another value (which would be in the applied config
>>>>>> until
>>>>>> the system updated and the correct default values have actually been
>>>>>> applied).  In real systems, I would have thought that the default
>>>>>> values
>>>>>> are often implicitly programmed when the parent containing object is
>>>>>> created anyway, so I suspect that this behaviour wouldn't actually be
>>>>>> that onerous to implement.
>>>>> It appears to me that we run into those issues by requiring the
>>>>> intended
>>>>> config to contain also the default values. That doesn¹t seem
>>>>> necessary.
>>>>> I
>>>> I can't see how you can have default values apply only to the applied
>>>> configuration and not the intended configuration.  The intended
>>>> configuration cannot be correctly interpreted if you don't also
>>>> consider
>>>> the default values specified in the schema.
>>> Given that servers nowadays cover a huge amount of functionality where
>>> often only a subset is required by a client, I would consider quite a
>>> bit
>>> of default values irrelevant for the scope of the client. If e.g. You
>>> plan
>>> to use a router that supports VPLS, but you do not care since it is not
>>> needed, those defaults can just be left to the server.
>> YANG already takes care of this, as per RFC6020bis section 7.6.1, only
>> the defaults that are in scope for your configuration are relevant.
> In other words, all defaults that are not in scope remain as set by the
> supplier of the Server and will not be changed by the client. Looks we are
> in agreement.
>>>>> would also argue that marking the Œapplied=intended¹ state per leaf is
>>>>> counter-productive. Assume the client sets an intended state of two
>>>>> values
>>>> Tracking intended vs applied on a per leaf basis is the essence of the
>>>> opstate requirements, please lets not rehash these all yet again. :-)
>>> See above, you can do this but it’s quite a bit of work. The requirement
>>> stems from a time where a client wasn’t able to figure out whether a
>>> leaf
>>> has been changed already or was about to change in future. To me it
>>> appears more of an implementation choice.
>> I disagree.  The requirements are from the perceived deficiencies in
>> NETCONF/YANG that need to be fixed for operators to use YANG effectively.
> We agree that "Tracking intended vs applied on a per leaf basis” is a
> requirement, but it appears to me that we have different ideas on the
> interpretation of ‘applied' during the transition period. In an
> implementation draft I would consider something along those lines:
>
> If a server completed the application of intended config (with or without
> errors), the applied config SHALL reflect the actual configuration in
> force. All leaves where the value of intended == applied are in the state
> "intended = applied”. All leaves with intended != applied are in error
> (tbd)
>
> If a server is in the process to apply configuration, the reported applied
> value MAY NOT reflect the actual configuration in force. Then the fact
> that the values of intended equal those of applied SHOULD NOT be taken as
> reliable indication that the intended configuration is actually in force.
> Likewise a value of intended != applied SHOULD NOT be taken as reliable
> indication that the intended configuration is not in force.
>
> NOTE: whether the applied=intended state needs to be coded on a
> per-leaf-level or higher up in the tree is a separate issue.
>>
>>>>> (A,B) on two different leafs with rollback-on-error semantic. If
>>>>> applying
>>>>> A succeeds and the client reads the applied state while applying B is
>>>>> still in progress, a rollback may still happen. That would invalidate
>>>>> the
>>>>> previous value of A. In other words it is unwise to read data from a
>>>>> source while it is actually writing.
>>>> No, this is fine, and isn't a problem.  The server will eventually
>>>> converge on a state and the client will be notified of that state.
>>>> The
>>>> fact that a client might temporarily see a valid state that is
>>>> subsequently undone isn't a problem.
>>> I’d seriously question those two statements. When the server is updating
>>> its applied state you have at best a 50% chance to read the correct
>>> value.
>>> What meaningful conclusion is the client supposed to take from that? Out
>>> of desperation, current implementations use that ‘trick’ by polling
>>> various leaf values to figure out whether an intended state has already
>>> been applied or not. However such intensive polling cycles are no more
>>> needed once a server notifies the client upon completion of intended
>>> state
>>> application.
>>> If the client chooses to read applied state during that period, it is at
>>> least aware that the state is just a temporary snapshot.
>> The client doesn't poll.  Instead it registers for notification of
>> changes and receives a continuous stream of updates.
>>
>> At any point in time, the value read by the client is correct, it just
>> happens that the system can be thought of being in the state of constant
>> flux.
>>
>> E.g. the global BGP routing table is constantly changing, but that
>> doesn't mean that you can't take a useful snapshot of it, or monitor how
>> it is changing.
>>
>> Thanks,
>> Rob
>>
>>
>>>> Thanks,
>>>> Rob
>>>>
>>>>
>>>>>> Thanks,
>>>>>> Rob
>>>>>>
>>>>>>
>>>>>>> Lada
>>>>>>>
>>>>>>>>        list interface {
>>>>>>>>          description-config
>>>>>>>>            "The list of configured interfaces on the device.
>>>>>>>>             ...";
>>>>>>>>          description-oper
>>>>>>>>            "The list of interfaces on the device.
>>>>>>>>             
>>>>>>>>             System-controlled interfaces created by the system are
>>>>>>>>             always present in this list, whether they are
>>>>>>>> configured or
>>>>>>>>             not.
>>>>>>>>             ...";
>>>>>>>>        }
>>>>>>>>
>>>>>>>>
>>>>>>>> /martin
>>>>>> _______________________________________________
>>>>>> netmod mailing list
>>>>>> netmod@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>> .
>>>>>


From nobody Wed Jan 13 07:51:40 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFF91A8AA0 for ; Wed, 13 Jan 2016 07:51:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3WcwbR-9Rtj for ; Wed, 13 Jan 2016 07:51:20 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0782.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::782]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 437F71A8A8B for ; Wed, 13 Jan 2016 07:51:19 -0800 (PST)
Received: from CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) by CY1PR0501MB1610.namprd05.prod.outlook.com (10.161.162.139) with Microsoft SMTP Server (TLS) id 15.1.361.13; Wed, 13 Jan 2016 15:51:01 +0000
Received: from CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) by CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) with mapi id 15.01.0361.006; Wed, 13 Jan 2016 15:51:01 +0000
From: Gert Grammel 
To: Robert Wilton , "netmod@ietf.org" 
Thread-Topic: [netmod] applied configuration and system-controlled entries
Thread-Index: AQHRSTUGxYtkEO44aUCWX59qiQKmfp72U6BggAAN6lSAAASVAIAACKQAgAAKfoCAAE7WgIAA1lGAgAASmgCAABk5AIAAJ7gAgAAxxICAAAl5gIABPXqAgAAiygCAACVIAA==
Date: Wed, 13 Jan 2016 15:51:00 +0000
Message-ID: 
References:  <5693C32E.7020708@cisco.com> <31E9D485-9349-448D-99A3-DD20F5E5AF09@nic.cz> <20160111.211837.377848045119250710.mbj@tail-f.com>  <5694D180.6030300@cisco.com>  <569507FA.1070805@cisco.com>  <569539AB.80007@cisco.com>  <5696612C.1040109@cisco.com>
In-Reply-To: <5696612C.1040109@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.5.9.151119
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [193.110.55.13]
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1610; 5:2s+gsekk4uDUpHQ/YoK1vuB2PEUfsnVAauSm1e3u1asBrddPeOHQBv6CG/oUfYYc47f+zMELgfbaXMWlTd1gwx8AqJSOtkw+N/kshCrm8mFE5x3SQg+5Y0UGuuMLgOpwlJsBojmmLAfcgIZ0//TpZg==; 24:zj/fcDURXSuoWvi7nVcTcWT4Mpup3gOW21BR3IFNY5trin5BLF4j0fBlR+g/ujpqr3+ZdSF/iBWjmW5EVsaIK6DAsG5AXZCSbWEXhl2/Oss=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1610;
x-ms-office365-filtering-correlation-id: 5f840acc-93fc-41c8-49b6-08d31c3155f2
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:CY1PR0501MB1610; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1610; 
x-forefront-prvs: 08200063E9
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(377424004)(52314003)(189002)(24454002)(164054003)(51444003)(199003)(2501003)(86362001)(97736004)(561944003)(40100003)(122556002)(101416001)(93886004)(99286002)(5002640100001)(87936001)(106116001)(106356001)(36756003)(19580405001)(66066001)(105586002)(4001350100001)(5001770100001)(3846002)(92566002)(83506001)(81156007)(586003)(2906002)(19580395003)(4326007)(1096002)(189998001)(5008740100001)(77096005)(102836003)(2900100001)(1220700001)(5001960100002)(11100500001)(2950100001)(6116002)(54356999)(15975445007)(50986999)(76176999)(5004730100002)(10400500002)(94096001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1610; H:CY1PR0501MB1609.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:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <449F2D80DE4B0644BEE64AB3EBA5E442@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2016 15:51:00.7632 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1610
Archived-At: 
Subject: Re: [netmod] applied configuration and system-controlled entries
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Jan 2016 15:51:26 -0000

Um9iLA0KDQpJIHRoaW5rIEtlbiBhbHJlYWR5IGFza2VkIHRoZSBxdWVzdGlvbiBhbmQgd2UgYm90
aCByZXNwb25kZWQgdGhhdCB3ZSBzZWUNCnRoaXMgZGlzY3Vzc2lvbiBpbiB0aGUgc2NvcGUgb2Yg
YSBzb2x1dGlvbnMgZHJhZnQgcmF0aGVyIHRoYW4gcmVsYXRlZCB0bw0KcmVxdWlyZW1lbnRzLiBJ
dCBpcyBzdGlsbCB0aGUgY2FzZSBJIGd1ZXNzLg0KDQpHZXJ0DQoNCk9uIDIwMTYtMTMtMDEgMTU6
MzcsICJSb2JlcnQgV2lsdG9uIiA8cndpbHRvbkBjaXNjby5jb20+IHdyb3RlOg0KDQo+SGkgR2Vy
dCwNCj4NCj5JJ20gd29uZGVyaW5nIGlmIGFsbCB0aGUgZGlzY3Vzc2lvbiBoZXJlIHdvdWxkIGJl
IG1vcmUgYXBwcm9wcmlhdGUgaW4NCj50aGUgY29udGV4dCBvZiBhIHNwZWNpZmljIHNvbHV0aW9u
IGRyYWZ0IGFuZCBoZW5jZSBiZXN0IGRlZmVycmVkIHVudGlsIGENCj5vdmVyYWxsIHNvbHV0aW9u
IGFwcHJvYWNoIGhhcyBiZWVuIGNob3Nlbj8NCj4NCj5PdGhlcndpc2UsIGlmIHRoZXJlIGlzIGEg
c3BlY2lmaWMgcHJvcG9zYWwgdG8gY2hhbmdlIHRoZSByZXF1aXJlbWVudHMNCj5kcmFmdCB0aGVu
IGNvdWxkIHRoYXQgYmUgY2xhcmlmaWVkIHBsZWFzZSBzbyB0aGF0IHdlIGNhbiBmb2N1cyBvbiB0
aGF0Lg0KPg0KPlRoYW5rcywNCj5Sb2INCj4NCj4NCj5PbiAxMy8wMS8yMDE2IDExOjMzLCBHZXJ0
IEdyYW1tZWwgd3JvdGU6DQo+Pg0KPj4gT24gMjAxNi0xMi0wMSAxODozNiwgIlJvYmVydCBXaWx0
b24iIDxyd2lsdG9uQGNpc2NvLmNvbT4gd3JvdGU6DQo+Pg0KPj4+DQo+Pj4gT24gMTIvMDEvMjAx
NiAxNjowMiwgR2VydCBHcmFtbWVsIHdyb3RlOg0KPj4+PiBPbiAyMDE2LTEyLTAxIDE1OjA0LCAi
Um9iZXJ0IFdpbHRvbiIgPHJ3aWx0b25AY2lzY28uY29tPiB3cm90ZToNCj4+Pj4NCj4+Pj4+IE9u
IDEyLzAxLzIwMTYgMTA6NDIsIEdlcnQgR3JhbW1lbCB3cm90ZToNCj4+Pj4+PiBPbiAyMDE2LTEy
LTAxIDExOjEyLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBSb2JlcnQgV2lsdG9uIg0KPj4+Pj4+IDxu
ZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgcndpbHRvbkBjaXNjby5jb20+IHdy
b3RlOg0KPj4+Pj4+DQo+Pj4+Pj4+IE9uIDEyLzAxLzIwMTYgMDk6MDUsIExhZGlzbGF2IExob3Rr
YSB3cm90ZToNCj4+Pj4+Pj4+IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPiB3cml0
ZXM6DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IExhZGlzbGF2IExob3RrYSA8bGhvdGthQG5pYy5jej4g
d3JvdGU6DQo+Pj4+Pj4+Pj4+PiBPbiAxMSBKYW4gMjAxNiwgYXQgMTU6NTgsIFJvYmVydCBXaWx0
b24gPHJ3aWx0b25AY2lzY28uY29tPg0KPj4+Pj4+Pj4+Pj4gd3JvdGU6DQo+Pj4+Pj4+Pj4+Pg0K
Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBPbiAxMS8wMS8yMDE2IDE0OjI3
LCBMYWRpc2xhdiBMaG90a2Egd3JvdGU6DQo+Pj4+Pj4+Pj4+Pj4+IE9uIDExIEphbiAyMDE2LCBh
dCAxNToxMSwgSnVlcmdlbiBTY2hvZW53YWVsZGVyDQo+Pj4+Pj4+Pj4+Pj4+IDxqLnNjaG9lbndh
ZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+
Pj4+Pj4+PiBPbiBNb24sIEphbiAxMSwgMjAxNiBhdCAwMjo1NDozNlBNICswMTAwLCBNYXJ0aW4g
QmpvcmtsdW5kDQo+Pj4+Pj4+Pj4+Pj4+IHdyb3RlOg0KPj4+Pj4+Pj4+Pj4+Pj4gTGFkaXNsYXYg
TGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4+Pj4+Pj4+Pj4+Pj4+PiBIaSBHZXJ0LA0K
Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+IE9uIDExIEphbiAyMDE2LCBhdCAxNDoy
NSwgR2VydCBHcmFtbWVsDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IDxnZ3JhbW1lbEBqdW5pcGVyLm5ldD4N
Cj4+Pj4+Pj4+Pj4+Pj4+Pj4gd3JvdGU6DQo+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+
Pj4+IExhZGEsDQo+Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4+IFRoZSByZXF1aXJl
bWVudCBzYXlzOg0KPj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICBELiAgV2hlbiBhIGNvbmZpZ3Vy
YXRpb24gY2hhbmdlIGZvciBhbnkgaW50ZW5kZWQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gY29uZmlndXJh
dGlvbg0KPj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgbm9kZSBoYXMgYmVlbiBzdWNjZXNz
ZnVsbHkgYXBwbGllZCB0byB0aGUNCj4+Pj4+Pj4+Pj4+Pj4+Pj5zZXJ2ZXINCj4+Pj4+Pj4+Pj4+
Pj4+Pj4gKGUuZy4gbm90DQo+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICBmYWlsZWQsIG5v
ciBkZWZlcnJlZCBkdWUgdG8gYWJzZW50IGhhcmR3YXJlKQ0KPj4+Pj4+Pj4+Pj4+Pj4+PiB0aGVu
DQo+Pj4+Pj4+Pj4+Pj4+Pj4+IHRoZQ0KPj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgICAgZXhp
c3RlbmNlIGFuZCB2YWx1ZSBvZiB0aGUgY29ycmVzcG9uZGluZw0KPj4+Pj4+Pj4+Pj4+Pj4+PmFw
cGxpZWQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgIGNvbmZpZ3VyYXRpb24gbm9kZSBt
dXN0IG1hdGNoIHRoZSBpbnRlbmRlZA0KPj4+Pj4+Pj4+Pj4+Pj4+PiBjb25maWd1cmF0aW9uDQo+
Pj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgICBub2RlLg0KPj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+
Pj4+Pj4+Pj4+Pj4+PiBJIGRvbid0IHNlZSB0aGF0IHRoaXMgd291bGQgbGltaXQgdGhlIGNhc2Ug
eW91IGRlc2NyaWJlZA0KPj4+Pj4+Pj4+Pj4+Pj4+PiBiZWxvdy4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4g
SW4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4geW91ciBjYXNlIHRoZXJlIGlzIG5vIGludGVuZGVkIGNvbmZp
ZywgaGVuY2UgdGhlcmUgaXMgbm8NCj4+Pj4+Pj4+Pj4+Pj4+Pj4gImNvcnJlc3BvbmRpbmcgYXBw
bGllZCBjb25maWd1cmF0aW9uIiBlaXRoZXIuDQo+Pj4+Pj4+Pj4+Pj4+Pj4gWW91IGFyZSByaWdo
dCwgdGhlIHJlcXVpcmVtZW50IGNhbiBiZSBpbnRlcnByZXRlZCB0aGlzDQo+Pj4+Pj4+Pj4+Pj4+
Pj53YXkuIEkNCj4+Pj4+Pj4+Pj4+Pj4+PiB0aG91Z2h0DQo+Pj4+Pj4+Pj4+Pj4+Pj4gdGhhdCBh
cHBsaWVkIGNvbmZpZ3VyYXRpb24gd2FzIHN1cHBvc2VkIHRvIGJlIGlkZW50aWNhbCB0bw0KPj4+
Pj4+Pj4+Pj4+Pj4+IGludGVuZGVkDQo+Pj4+Pj4+Pj4+Pj4+Pj4gYWZ0ZXIgc29tZSBzeW5jaHJv
bml6YXRpb24gcGVyaW9kLg0KPj4+Pj4+Pj4+Pj4+Pj4gVGhpcyBpcyBhIHZlcnkgaW1wb3J0YW50
IHBvaW50IHRvIGNsYXJpZnkuICBDYW4gdGhlcmUgZXZlcg0KPj4+Pj4+Pj4+Pj4+Pj5iZQ0KPj4+
Pj4+Pj4+Pj4+Pj4gZGF0YSBpbg0KPj4+Pj4+Pj4+Pj4+Pj4gImFwcGxpZWQiIHRoYXQgaXMgbm90
IGluICJpbnRlbmRlZCI/ICBJIHRoaW5rIEFuZWVzICYgUm9iDQo+Pj4+Pj4+Pj4+Pj4+PiBwcmV2
aW91c2x5DQo+Pj4+Pj4+Pj4+Pj4+PiBzYWlkICJubyIsIGJ1dCBJIG1pZ2h0IGJlIHdyb25nLg0K
Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4gSWYgdGhlcmUgaXMgdGltZSBkZWxheSBiZXR3
ZWVuIGVkaXRpbmcgaW50ZW5kZWQgYW5kIHRoZQ0KPj4+Pj4+Pj4+Pj4+PmFwcGxpZWQNCj4+Pj4+
Pj4+Pj4+Pj4gY29uZmlnDQo+Pj4+Pj4+Pj4+Pj4+IG1hdGNoaW5nIHRoZSBlZGl0cyBvZiBpbnRl
bmRlZCwgdGhlbiBJIHN1cG9zZSB0aGlzIGNhbiBoYXBwZW4NCj4+Pj4+Pj4+Pj4+Pj4gKEkNCj4+
Pj4+Pj4+Pj4+Pj4gZGVsZXRlIGEgcmVzb3VyY2UgZnJvbSBpbnRlbmRlZCBidXQgaXQgaXMgc3Rp
bGwgYXJvdW5kIHVudGlsDQo+Pj4+Pj4+Pj4+Pj4+IGludGVuZGVkDQo+Pj4+Pj4+Pj4+Pj4+IGhh
cyBiZWVuIGZ1bGx5IHN5bmNlZCkuIEkgd291bGQgZmluZCBpdCBpbnRlcmVzdGluZyBpZiBzb21l
DQo+Pj4+Pj4+Pj4+Pj4+IGVkaXRzDQo+Pj4+Pj4+Pj4+Pj4+IGFyZQ0KPj4+Pj4+Pj4+Pj4+IFVz
aW5nIGFwcGxpZWQgY29uZmlnIGZvciBzeXN0ZW0tY29udHJvbGxlZCBlbnRyaWVzIHdvdWxkDQo+
Pj4+Pj4+Pj4+Pj5yZXF1aXJlDQo+Pj4+Pj4+Pj4+Pj4gdGhhdA0KPj4+Pj4+Pj4+Pj4+IHN1Y2gg
YW4gZW50cnkgc3RheXMgKGZvcmV2ZXIpIGluIGFwcGxpZWQgY29uZmlnIGV2ZW4gYWZ0ZXIgaXQN
Cj4+Pj4+Pj4+Pj4+PiBoYXMNCj4+Pj4+Pj4+Pj4+PiBiZWVuDQo+Pj4+Pj4+Pj4+Pj4gZGVsZXRl
ZCBmcm9tIGludGVuZGVkLg0KPj4+Pj4+Pj4+Pj4gSSB0aGluayB0aGF0IHRoaXMgd291bGQgbWFr
ZSBsaWZlIGhhcmRlciBmb3IgY2xpZW50cy4NCj4+Pj4+Pj4+Pj4gSG1tLCBJIHdvdWxkIHNheSB0
aGUgb3Bwb3NpdGUuIEZvciBvbmUsIHdlIGNvdWxkIHNpbXBsaWZ5IHRoZQ0KPj4+Pj4+Pj4+PmRh
dGENCj4+Pj4+Pj4+Pj4gbW9kZWxzIGJ5IHJlZHVjaW5nIHRoZSBkdXBsaWNpdGllcyBpbiBjb25m
aWd1cmF0aW9uIGFuZCBzdGF0ZQ0KPj4+Pj4+Pj4+PiB0cmVlcy4NCj4+Pj4+Pj4+PiBUaGlzIGlz
IHRoZSBvbGQgaWRlYSBvZiBoYXZpbmcgdGhlICJvcGVyYXRpb25hbCBzdGF0ZSIgZGF0YXN0b3Jl
LA0KPj4+Pj4+Pj4+IHdoaWNoIHdvdWxkIGJlIGFsbCBjb25maWcgdHJ1ZSArIGFsbCBjb25maWcg
ZmFsc2Ugbm9kZXMuICBPbmUNCj4+Pj4+Pj4+Pmlzc3VlDQo+Pj4+Pj4+Pj4gd2l0aCB0aGlzIGlz
IHRoYXQgdGhlIHNlbWFudGljcyBvZiB0aGUgbm9kZSBpcyBkaWZmZXJlbnQgaW4gdGhlDQo+Pj4+
Pj4+Pj4gZGlmZmVyZW50IGRhdGEgc3RvcmVzLCBldmVuIGlmIHRoZSBzeW50YXggKGJ5IGRlZmlu
aXRpb24hKSBpcyB0aGUNCj4+Pj4+Pj4+PiBzYW1lLiAgSW4gb3JkZXIgdG8gaGFuZGxlIHRoaXMg
cHJvcGVybHkgeW91IG5lZWQgZWl0aGVyIHR3bw0KPj4+Pj4+Pj4+IGRpZmZlcmVudA0KPj4+Pj4+
Pj4+IGRlc2NyaXB0aW9uIHN0YXRlbWVudHMsIG9yIHR3byAic2VjdGlvbnMiIHdpdGhpbiB0aGUg
ZGVzY3JpcHRpb24NCj4+Pj4+Pj4+PiBzdGF0ZW1lbnQuDQo+Pj4+Pj4+PiBJIHRoaW5rIHRoaXMg
aXMgbm90IG11Y2ggZGlmZmVyZW50IGZyb20gZGVmYXVsdCB2YWx1ZXMuIExlYXZlcyBhbmQNCj4+
Pj4+Pj4+IGxlYWYtbGlzdHMgdGhhdCBoYXZlIHRoZW0gZGVmaW5lZCBpbiB0aGUgZGF0YSBtb2Rl
bCBtYXkgbm90IGJlDQo+Pj4+Pj4+PiBwcmVzZW50DQo+Pj4+Pj4+PiBpbiBpbnRlbmRlZCBjb25m
aWcsIHlldCBvbmUgY2FuIGNvbnNpZGVyIHRoZW0gdG8gYmUgaW4gYXBwbGllZA0KPj4+Pj4+Pj4g
Y29uZmlnLg0KPj4+Pj4+PiBJIHRoaW5rIHRoYXQgZGVmYXVsdCB2YWx1ZXMgYXJlIGxvZ2ljYWxs
eSBqdXN0IGEgd2F5IHRvIG1ha2UgdGhlDQo+Pj4+Pj4+IGNvbmZpZ3VyYXRpb24gZGF0YSBtb3Jl
IGNvbmNpc2UuICBJLmUuIGV2ZXJ5d2hlcmUgeW91IGhhdmUgYQ0KPj4+Pj4+PmRlZmF1bHQNCj4+
Pj4+Pj4gdmFsdWUgdGhlbiB0aGUgZXF1aXZhbGVudCBjb25maWd1cmF0aW9uIGNvdWxkIGJlIGV4
cHJlc3NlZCB3aXRoIGENCj4+Pj4+Pj4gZXhwbGljaXQgdmFsdWUgc2V0IGluc3RlYWQuDQo+Pj4+
Pj4gSSB0aGluayBkZWZhdWx0IHZhbHVlcyBhcmUganVzdCB3aGF0IHRoZXkgYXJlLiBBIHNldCBv
ZiB2YWx1ZXMgb24NCj4+Pj4+PnRoZQ0KPj4+Pj4+IHNlcnZlciB0aGF0IGhhdmUgbm90IGJlZW4g
ZXhwbGljaXRseSBzZXQgYnkgdGhlIGNsaWVudCB2aWENCj4+Pj4+PiBpbnRlbmRlZC1jb25maWcu
DQo+Pj4+PiBUaGUgZGVmYXVsdCB2YWx1ZXMgYXJlIGRldGVybWluZWQgYnkgdGhlIHNjaGVtYSBh
bmQgdGhlIGludGVuZGVkDQo+Pj4+PiBjb25maWd1cmF0aW9uLiAgWW91IG5lZWQgdG8ga25vdyBi
b3RoIHRvIGtub3cgd2hhdCBkZWZhdWx0IHZhbHVlcyB0aGUNCj4+Pj4+IHNlcnZlciBpcyBleHBl
Y3RlZCB0byB1c2UuDQo+Pj4+IE5vIGRpc2FncmVlbWVudC4gVGhlIG9ubHkgcG9pbnQgaXMgd2hl
dGhlciBkZWZhdWx0IHZhbHVlcyAqc2hhbGwqIG9yDQo+Pj4+ICptYXkqDQo+Pj4+IGJlIHByb3Zp
c2lvbmVkIHZpYSBpbnRlbmRlZCBjb25maWcNCj4+PiBJIG1lYW50ICJNYXkiLg0KPj4gYWdyZWVk
OiBkZWZhdWx0IHZhbHVlcyAqbWF5KiBiZSBwcm92aXNpb25lZCB2aWEgaW50ZW5kZWQgY29uZmln
DQo+Pg0KPj4+Pj4gQnV0IGluIHRlcm1zIG9mIHdoYXQgaXMgYWN0dWFsbHkgYXBwbGllZCwgYW4g
aW50ZW5kZWQgY29uZmlndXJhdGlvbg0KPj4+Pj4gd2l0aA0KPj4+Pj4gZGVmYXVsdHMgdmFsdWVz
IGNhbiBiZSBtYXBwZWQgaW50byBhbiBlcXVpdmFsZW50IGludGVuZGVkDQo+Pj4+PmNvbmZpZ3Vy
YXRpb24NCj4+Pj4+IHdpdGggYWxsIGltcGxpY2l0IGRlZmF1bHRzIHJlcGxhY2VkIGJ5IHRoZSBl
cXVpdmFsZW50IGV4cGxpY2l0DQo+Pj4+PnZhbHVlcy4NCj4+Pj4+IFdoYXQgZ2V0cyBhcHBsaWVk
ICBpbiB0aGUgZGV2aWNlIHNob3VsZCBiZSB0aGUgc2FtZSBpbiBib3RoIGNhc2VzLg0KPj4+Pj4N
Cj4+Pj4+DQo+Pj4+Pj4gICAgIEl0IGlzIGNlcnRhaW5seSBwb3NzaWJsZSB0byBzZXQgZGVmYXVs
dCB2YWx1ZXMgaW4NCj4+Pj4+PiBpbnRlbmRlZC1jb25maWcgZXhwbGljaXRseSwgYnV0IGl0IGlz
IG5vdCBzdHJpY3RseSBuZWVkZWQuDQo+Pj4+PiBZZXMsIG9mIGNvdXJzZS4NCj4+Pj4+DQo+Pj4+
Pj4+IEFzIHN1Y2gsIEkgdGhpbmsgdGhhdCB0aGUgZGVmYXVsdCB2YWx1ZXMgYXBwbHkgZXF1YWxs
eSB0byBib3RoIHRoZQ0KPj4+Pj4+PiBpbnRlbmRlZCBhbmQgYXBwbGllZCBjb25maWd1cmF0aW9u
Lg0KPj4+Pj4+IFdoaWxlIHRoaXMgaXMgYWxsb3dlZCAoc2VlIGFib3ZlKSwgSSB3b3VsZCBjb25z
aWRlciBkZWZhdWx0IHZhbHVlcw0KPj4+Pj4+IGFwcGx5DQo+Pj4+Pj4gaW4gcHJhY3RpY2UgdG8g
dGhlIGFwcGxpZWQgY29uZmlnDQo+Pj4+PiBJIHRoaW5rIHRoYXQgSSBkaXNhZ3JlZSBvbiB0aGlz
IHBvaW50Lg0KPj4+PiBPSywgbGV04oCZcyBrZWVwIHRoaXMgcG9pbnQgZm9yIGEgZnVydGhlciBk
aXNjdXNzaW9uLg0KPj4+Pj4gVGhlIGludGVuZGVkIGNvbmZpZ3VyYXRpb24gaXMgb25seSBjb21w
bGV0ZSB3aGVuIHlvdSBjb25zaWRlciBpdHMNCj4+Pj4+IGFzc29jaWF0ZWQgWUFORyBzY2hlbWEg
YW5kIGltcGxpY2l0IGRlZmF1bHQgdmFsdWVzLg0KPj4+PiBUcnVlLCBidXQgaXQgZG9lc27igJl0
IG1lYW4gdGhhdCB0aGUgY2xpZW50IHdoaWNoIGhvbGRzIHRoZSBjb21wbGV0ZQ0KPj4+PiBpbnRl
bmRlZCBjb25maWcgaGFzIHRvIGV4cGxpY2l0bHkgcHVzaCBldmVyeXRoaW5nIGRvd24gdG8gdGhl
IHNlcnZlci4NCj4+Pj4gQWdhaW4gdGhpcyBpcyB0aGUgZGlzdGluY3Rpb24gYmV0d2VlbiAqbWF5
KiBhbmQgKnNoYWxsKiBhbmQgd29ydGggYQ0KPj4+PiBkaXNjdXNzaW9uLg0KPj4+IFllcywgSSB0
aGluayB0aGF0IGl0IGlzICJtYXkiLg0KPj4+DQo+Pj4+ICAgIA0KPj4+Pj4+PiBJZiBhZnRlciBh
IGNvbmZpZyByZXF1ZXN0IGl0IHRha2VzIHRpbWUgZm9yIHRoZSBzeXN0ZW0gdG8gYXBwbHkgYQ0K
Pj4+Pj4+PiBkZWZhdWx0IHZhbHVlLCB0aGVuIGlkZWFsbHkgdGhlIGFwcGxpZWQgY29uZmlndXJh
dGlvbiBzaG91bGQgaGF2ZQ0KPj4+Pj4+PmFuDQo+Pj4+Pj4+IGV4cGxpY2l0IGxlYWYgdG8gc2hv
dyB3aGF0IHZhbHVlIGlzIGFjdHVhbGx5IGluIGVmZmVjdCB1bnRpbCB0aGUNCj4+Pj4+Pj4gZGVm
YXVsdA0KPj4+Pj4+PiB2YWx1ZSBoYXMgYWN0dWFsbHkgYmVlbiBhcHBsaWVkIGluIHRoZSBzeXN0
ZW0uDQo+Pj4+Pj4gSWYgdGhlIGNsaWVudCBoYXMgYW4gaW5kaWNhdGlvbiB3aGV0aGVyIHRoZSBj
b25maWd1cmF0aW9uDQo+Pj4+Pj5hcHBsaWNhdGlvbg0KPj4+Pj4+IGlzDQo+Pj4+Pj4gZmluaXNo
ZWQgKHdpdGggb3Igd2l0aG91dCBlcnJvcnMpLCBpdCBrbm93cyB0aGF0IHRoZSBhcHBsaWVkIGNv
bmZpZw0KPj4+Pj4+aXMNCj4+Pj4+PiBub3cNCj4+Pj4+PiBzdGFibGUgdG8gYmUgcmVhZC4gUmVh
ZGluZyBhcHBsaWVkIGNvbmZpZyBkdXJpbmcgYW4gb3BlcmF0aW9uIHNob3VsZA0KPj4+Pj4+IGJl
DQo+Pj4+Pj4gYXZvaWRlZC4gSGVuY2UgSSB3b3VsZCBxdWVzdGlvbiB0aGUgbmVlZCBmb3IgYSBw
ZXItbGVhZiBzdGF0ZSBhbmQNCj4+Pj4+PiBhZHZvY2F0ZQ0KPj4+Pj4+IGZvciBhIHBlci1zZXJ2
ZXIgc3RhdGUuDQo+Pj4+PiBJIHRoaW5rIHRoYXQgdGhlIHdob2xlIHB1cnBvc2Ugb2YgdGhlIG9w
c3RhdGUgcmVxdWlyZW1lbnRzIGlzIHRoYXQNCj4+Pj4+dGhlDQo+Pj4+PiBvcGVyYXRvcnMgZWZm
ZWN0aXZlbHkgd2FudCB0byBiZSBhYmxlIHRvIHRyYWNrIG9uIGEgcGVyIGxlYWYgZWxlbWVudA0K
Pj4+Pj4gcmF0aGVyIHRoYW4gYSBwZXItc2VydmVyIGVsZW1lbnQuDQo+Pj4+IFRoZSBwb2ludCBo
YXMgYmVlbiB0aGF0IHRoZSBjbGllbnQgd2FudHMgdG8ga25vdyB3aGV0aGVyIGl04oCZcyBpbnRl
bmRlZA0KPj4+PiBjb25maWd1cmF0aW9uIGhhcyBiZWVuIGFwcGxpZWQuIFRoaXMgaW5mb3JtYXRp
b24gaXMgbWlzc2luZyBmcm9tIHRoZQ0KPj4+Pm9sZA0KPj4+PiBhc3luY2ggbW9kZWwgYW5kIGhl
bmNlIGNyZWF0ZXMgdW5jZXJ0YWludHkuIEFueSByZWFkIGF0dGVtcHQgb2YgdGhlDQo+Pj4+IGNs
aWVudA0KPj4+PiByZWxhdGVkIHRvIGFwcGxpZWQgY29uZmlndXJhdGlvbiBtYXkgZmFsbCBpbnRv
IGEgdHJhbnNpdGlvbiBwZXJpb2QgYW5kDQo+Pj4+IGlzDQo+Pj4+IG9ubHkgYSBzbmFwc2hvdCBv
ZiBhIHdvYmJseSBzdGF0ZS4NCj4+PiBZZXMsIGFuZCB0aGF0IGlzbid0IGEgcHJvYmxlbS4NCj4+
IFdoZXRoZXIgaXQgaXMgYSBwcm9ibGVtIGRlcGVuZHMgb24gd2hhdCBmb3IgdGhlIGluZm9ybWF0
aW9uIGlzIHVzZWQgYnkNCj4+dGhlDQo+PiBjbGllbnQuIElmIHRoZSBjbGllbnQgcGVyaW9kaWNh
bGx5IGNoZWNrcyB2YWx1ZXMgdG8gbW9uaXRvciB0aGUgcHJvZ3Jlc3MNCj4+IG9mIGFuIGludGVu
ZGVkIGNvbmZpZyBhcHBsaWNhdGlvbiwgaXQgd291bGRu4oCZdCBiZSBhIHByb2JsZW0uIFRoaXMg
aXMNCj4+d2hhdA0KPj4gaXMgYWN0dWFsbHkgZG9uZSBzaW5jZSB0aGVyZSBpcyBhIGxhY2sgb2Yg
aW5mb3JtYXRpb24gd2hldGhlciB0aGUNCj4+aW50ZW5kZWQNCj4+IGNvbmZpZ3VyYXRpb24gaXMg
ZnVsbHkgYXBwbGllZC4NCj4+IEhvd2V2ZXIgaWYgdGhlIGNsaWVudCBpcyBjb2xsZWN0aW5nIGxl
YWYgaW5mb3JtYXRpb24gaW4gb3JkZXIgdG8gZGVyaXZlDQo+PmFuDQo+PiBhY3Rpb24sIGl0IGhh
cyB0byByZWx5IG9uIHRoZSBzdGF0ZS4gU28gaGVyZSB0aGVyZSBpcyBpbmZvcm1hdGlvbiBuZWVk
ZWQNCj4+IHRoYXQgY2FuIGJlIHJlbGllZCB1cG9uLg0KPj4gV2UgYXJlIGRpc2N1c3Npbmcgd2hl
dGhlciB0aGF0IGluZm9ybWF0aW9uIHNob3VsZCBiZSBvbiBhIHRyZWUgb3IgYSBsZWFmDQo+PiBs
ZXZlbC4gTXkgcHJlZmVyZW5jZSBnb2VzIGZvciBhIGhpZ2hlciBsZXZlbCBiZWNhdXNlIGl0IGlz
IG1vcmUgcmVsaWFibGUNCj4+IHRvIGltcGxlbWVudCwgYnV0IGFzIHdpdGggYWxsIHByZWZlcmVu
Y2VzIHRoZXJlIG5lZWRzIHRvIGJlIGNvbnNlbnN1cy4NCj4+IElmIG9uZSAgaW1wbGVtZW50cyBz
dGF0ZSBvbiBhIGxlYWYgbGV2ZWwgdGhlcmUgYXJlIDMgY2FzZXMgdG8gY29uc2lkZXI6DQo+PiBB
KSByb2xsYmFjay1vbi1lcnJvcjogQWxsIGxlYWZzIHRvdWNoZWQgaW4gdGhlIGNvbmZpZyBoYXZl
IHRvIHJlbWFpbg0KPj4g4oCYZGlydHnigJkgKHNlZSBiZWxvdyBmb3IgZGVmaW5pdGlvbikgdW50
aWwgdGhlIGxhc3QgdmFsdWUgaGFzIGJlZW4gYXBwbGllZA0KPj4gb3IgdGhlIHJvbGxiYWNrIGlz
IGZpbmlzaGVkLiBUaGVuIGluIGEgc2Vjb25kIHN0ZXAgdGhlIGRpcnR5IGZsYWcgaXMNCj4+IHJl
bW92ZWQuDQo+PiBCKSBzdG9wLW9uLWVycm9yOiBmaXJzdCBhbGwgbGVhZnMgc3VwcG9zZWQgdG8g
YmUgdG91Y2hlZCBieSB0aGUgaW50ZW5kZWQNCj4+IGNvbmZpZyBhcmUgbWFya2VkLCB0aGVuIGNv
bmZpZyBpcyBhcHBsaWVkIGFuZCB0aGUg4oCYZGlydHnigJkgZmxhZyBjYW4NCj4+IGltbWVkaWF0
ZWx5IGJlIHJlbW92ZWQgZnJvbSB0aGUgbGVhZnMuIEhvd2V2ZXIgaWYgYW4gZXJyb3Igb2NjdXJz
IHRoZQ0KPj4gZGlydHkgZmxhZyBvZiBhbGwgc3Vic2VxdWVudCBsZWFmcyBoYXMgdG8gYmUgY2xl
YXJlZCBzaW5jZSB0aGVyZSBpcyBubw0KPj4gY29uZmlnIGluIHByb2dyZXNzIGFueW1vcmUNCj4+
IEMpIGNvbnRpbnVlIG9uIGVycm9yOiBtYXJrIGFsbCBhZmZlY3RlZCBsZWFmcyB3aXRoIHRoZSBk
aXJ0eSBmbGFnIGFuZA0KPj4gY2xlYXIgaXQgYWZ0ZXIgbGVhZnMgaGF2ZSBiZWVuIGNvbmZpZ3Vy
ZWQgKHN1Y2Nlc3NmdWxseSBvcg0KPj5ub24tc3VjZXNzZnVsbHkpDQo+Pg0KPj4gSSBmZWFyIHRo
YXQgd2XigJlsbCBldmVudHVhbGx5IGVuZCB1cCB3aXRoIHNvbWV0aGluZyBsaWtlIGFuIG9ycGhh
bg0KPj5jb250cm9sDQo+PiBkYWVtb24gaW4gdGhlIHNlcnZlciB0byBjbGVhbiB1cCBhbGwgdGhl
IGZvcmdvdHRlbiBzdGF0ZXMsIHJlbmRlcmluZyB0aGUNCj4+IGZpbmUgbGV2ZWwgb2Ygc3RhdGUg
bGVzcyB1c2VmdWwgdGhhbiBpdCBhcHBlYXIuDQo+Pg0KPj4+IFRoZSBpbnRlbmRlZCBjb25maWcg
aXMgdXBkYXRlZCwgYW5kIHRoZW4gdGhlIGFwcGxpZWQgY29uZmlnIHN0YXRlDQo+Pj4gY29udmVy
Z2VzIG9uIHRoZSBpbnRlbmRlZCBjb25maWcuDQo+Pj4NCj4+Pj4gRXNzZW50aWFsbHkgd2UgYXJl
IGRpc2N1c3Npbmcgd2hlcmUgdG8gcHV0IGEgZGlydHktZmxhZy4gSW4gbXkgKGxlc3MNCj4+Pj4g
Z3JhbnVsYXIpIHZpZXcgaXQgaXMgcHJ1ZGVudCB0byBwdXQgdGhlIGRpcnR5LWZsYWcgaGlnaCB1
cCBpbiB0aGUgdHJlZQ0KPj4+PiBhbmQNCj4+Pj4ga2VlcCBpdCB0cnVlIHVudGlsIHRoZSBzdGF0
ZSBjaGFuZ2UgY29tcGxldGVkIChpcnJlc3BlY3RpdmUgaWYgaXQgd2FzDQo+Pj4+IHN1Y2Nlc3Nm
dWwgb3Igbm90KS4gQW5vdGhlciB3YXkgaXMgdG8ga2VlcCBhIHZlcnkgZ3JhbnVsYXIgdmlldyBh
bmQNCj4+Pj4gc3RpY2sNCj4+Pj4gdGhlIGRpcnR5IGZsYWcgb24gYWxsIGxlYWZzIHRoYXQgYXJl
IHN1cHBvc2VkIHRvIGJlIHRvdWNoZWQgYnkgdGhlDQo+Pj4+IGludGVuZGVkIHN0YXRlIGFuZCBj
bGVhbmluZyB0aGVtIHVwIGFmdGVyICphbGwqIGludGVuZGVkIGNvbmZpZyBoYXMNCj4+Pj5iZWVu
DQo+Pj4+IGF0dGVtcHRlZCB0byBhcHBseS4gQSBiaXQgb2YgbW9yZSBoYXNzbGUgZnJvbSBhbiBp
bXBsZW1lbnRlcnMgcG9pbnQgb2YNCj4+Pj4gdmlldywgYW5kIEkgYW0gbm90IHN1cmUgaWYgaXQg
aXMgd29ydGguDQo+Pj4gSGF2aW5nIGEgc2luZ2xlIGRpcnR5IGZsYWcgZG9lc24ndCByZWFsbHkg
bWVldCB0aGUgcmVxdWlyZW1lbnRzIChhcw0KPj4+IHN0YXRlZCBpbiB0aGUgcmVxdWlyZW1lbnRz
IGRyYWZ0KS4gIEl0IG1lYW5zIHRoYXQgY29uZmlnIHJlYWRzIGZyb20gdGhlDQo+Pj4gc2VydmVy
IGFyZSB1bmF2YWlsYWJsZSAob3Igc3RhbGUpIHdoaWxzdCBhIGNvbmZpZyBjaGFuZ2UgaXMgaW4g
cHJvZ3Jlc3MNCj4+PiAod2hpY2ggY291bGQgdGFrZSBhIGxvbmcgdGltZSkuDQo+PiBTb3JyeSwg
SSB3YXMgdXNpbmcgYSBzbG9wcHkgdGVybSB3aXRob3V0IGRlZmluaXRpb24uIEkgbWVhbnQg4oCY
ZGlydHnigJkNCj4+ZmxhZw0KPj4gaXMgYSBtYXJrZXIgaW5kaWNhdGluZyB0aGF0IGEgY29uZmln
dXJhdGlvbiBhcHBsaWNhdGlvbiBpcyBzdGlsbA0KPj5ydW5uaW5nLg0KPj4gVGVjaG5pY2FsbHkg
c3VjaCBhIGZsYWcgY291bGQgYmUgc3RpY2tlZCBhdCBhbnkgcG9pbnQgaW4gdGhlIHRyZWUNCj4+
IGluY2x1ZGluZyBsZWFmcy4gSW4gb3RoZXIgd29yZHMsIGEgY2xpZW50IGNhbiByZWFkIHdoYXRl
dmVyIGFuZCB3aGVuZXZlcg0KPj4gaXQgd2FudHMuIOKAmGRpcnR54oCZIGluZGljYXRlcyB0aGF0
IHRoZSBhdHRyaWJ1dGUgdmFsdWUgY2Fubm90IGJlIHJlbGllZA0KPj4gdXBvbiwgc2luY2UgYSBj
b25maWd1cmF0aW9uIGlzIG9uZ29pbmcuIEhvcGUgdGhpcyBjbGFyaWZpZXMgdGhhdCB0aGVyZQ0K
Pj5pcw0KPj4gbm8gdW5hdmFpbGFibGUgb3Igc3RhbGUgcGVyaW9kIGZvciByZWFkaW5nIGFzIHN0
YXRlZCBpbiB0aGUNCj4+cmVxdWlyZW1lbnRzLg0KPj4NCj4+PiBJbnN0ZWFkLCB0aGUgb3BlcmF0
b3JzIHJlcXVpcmVtZW50IGlzIHRoYXQgdGhlIHRyYWNraW5nIGlzIGRvbmUgb24gYQ0KPj4+cGVy
DQo+Pj4gbGVhZiBiYXNpcyAoZS5nLiBsaWtlIHRoZSBPcGVuQ29uZmlnIFlBTkcgbW9kZWxzIG9u
DQo+Pj4gaHR0cHM6Ly9naXRodWIuY29tL29wZW5jb25maWcvcHVibGljKSwgSSBiZWxpZXZlIHdp
dGggdGhlIGV4cGVjdGF0aW9uDQo+Pj4gdGhhdCB0aGUgc2VydmVyIHNob3VsZCB1cGRhdGUgdGhl
IGxlYXZlcyBhcyB0aGUgY29uZmlndXJhdGlvbiBpcyBiZWluZw0KPj4+IGFwcGxpZWQuICBJLmUu
IGlmIHRoZSBzZXJ2ZXIgaGFkIHByb2Nlc3NlZCBoYWxmIHRoZSBjb25maWd1cmF0aW9uIGZyb20N
Cj4+PmENCj4+PiAxIG1pbGxpb24gZW50cnkgY29uZmlnIHRoZW4gaWRlYWxseSBpdCBzaG91bGQg
YmUgdXBkYXRpbmcgdGhlIGFwcGxpZWQNCj4+PiBjb25maWd1cmF0aW9uIGxlYXZlcyBhcyBpdCBn
b2VzIHNvIHRoYXQgdGhlIGNsaWVudCBrbm93cyB3aGF0IGlzDQo+Pj4gY3VycmVudGx5IHByb2dy
YW1tZWQgYXQgdGhhdCBwYXJ0aWN1bGFyIHBvaW50IGluIHRpbWUuICBJbiB0aGUgaWRlYWwNCj4+
PiB3b3JsZCB0aGUgc2VydmVyIHNob3VsZCBhbHdheXMgYmUgdGVsbGluZyB0aGUgY2xpZW50IHdo
YXQgY29uZmlndXJhdGlvbg0KPj4+IGlzIGFwcGxpZWQgYXQgdGhhdCBzcGVjaWZpYyBwb2ludCBp
biB0aW1lIHRoYXQgdGhlIHJlcXVlc3QgaXMNCj4+PnByb2Nlc3NlZC4NCj4+Pg0KPj4+PiAgICAN
Cj4+Pj4+IEkgbWlnaHQgYmUgd3JvbmcsIGJ1dCBJIHRoaW5rIHRoYXQgdGhlIGRlc2lnbiBiZWlu
ZyBjb25zaWRlciBieSB0aGUNCj4+Pj4+IG9wc3RhdGUgb3BlcmF0b3JzIGlzIGFsb25nIHRoZSBs
aW5lcyBvZiBhbiBldmVudHVhbCBjb25zaXN0ZW50IG1vZGVsLg0KPj4+Pj4gRS5nLiBzb21ldGhp
bmcgYWxvbmcgdGhlIGxpbmVzIG9mOg0KPj4+Pj4NCj4+Pj4+IEF0IGFueSBwb2ludCBpbiB0aW1l
IHRoZSBvcGVyYXRvciBrbm93cyB3aGF0IGNvbmZpZ3VyYXRpb24gc3RhdGUgdGhleQ0KPj4+Pj4g
d291bGQgYSBkZXZpY2UgdG8gYmUgaW4gKGkuZS4gdGhlIGludGVuZGVkIGNvbmZpZ3VyYXRpb24p
Lg0KPj4+PiBPSw0KPj4+Pj4gV2hlbmV2ZXIgdGhlIGNsaWVudCBjaGFuZ2VzIHRoZWlyIGludGVu
ZGVkIGNvbmZpZ3VyYXRpb24sIHRoZXkgcHVzaA0KPj4+Pj4gZG93bg0KPj4+Pj4gdGhlIHVwZGF0
ZWQgaW50ZW5kZWQgY29uZmlndXJhdGlvbiB0byB0aGUgZGV2aWNlLg0KPj4+PiBPSywgZnJvbSBu
b3cgb24gdGhlIGNsaWVudCBpcyBibGluZCBhYm91dCB0aGUgYXBwbGllZCBzdGF0ZSBvZiB0aGUN
Cj4+Pj4gc2VydmVyDQo+Pj4+IHVubGVzcyBpdCBjYW4gZ3Vlc3MgaXQgZnJvbSBlLmcuIERlcml2
ZWQgc3RhdGUgYW5kIHNvIG9uLg0KPj4+IE5vLCB0aGUgY2xpZW50IGNhbiByZWFkIHRoZSBjdXJy
ZW50IHN0YXRlIGZyb20gdGhlIHNlcnZlciBhdCBhbnkgcG9pbnQNCj4+PiBpbiB0aW1lLCBhbmQg
aWRlYWxseSBpdCBzaG91bGQgcmVmbGVjdCB0aGUgY29uZmlndXJhdGlvbiBhdCB0aGF0IHBvaW50
DQo+Pj4gaW4gdGltZSAoZXZlbiBpZiBpdCBpcyBoYWxmIHdheSB0aHJvdWdoIGEgY29uZmlnIHJl
cXVlc3QpLg0KPj4gV2hpbGUgd2UgYXJlIGluIGFncmVlbWVudCB0aGF0IHRoZSBjbGllbnQgY2Fu
IHBvbGwgdGhlIGFwcGxpZWQgc3RhdGUgYXQNCj4+IGFueSBwb2ludCBpbiB0aW1lIChzZWUgYWJv
dmUpLCBpdCBpcyBub3Qgb2JsaWdlZCB0byBkbyBzbyBnaXZlbiB0aGF0IHRoZQ0KPj4gc2VydmVy
IHNlbmRzIGFuIGluZGljYXRpb24gd2hlbiB0aGUgY29uZmlnIGlzIGFwcGxpZWQuDQo+PiBJIGFs
c28gcmVhbGl6ZWQgdGhhdCBJIGRpZG7igJl0IGV4cGxhaW4gc3VmZmljaWVudGx5IHdoYXQgaSBt
ZWFudCB3aXRoDQo+PiDigJhibGluZOKAmS4gVGFrZSB0aGUgY2FzZSBvZiAyIGRpZmZlcmVudCBp
bXBsZW1lbnRhdGlvbnMgb2YgYSBzZXJ2ZXINCj4+YXBwbHlpbmcNCj4+IGNvbmZpZ3VyYXRpb246
DQo+PiBBKSBmaXJzdCBzZXQgdGhlIG5ldyB2YWx1ZSBpbiB0aGUgaW50ZXJuYWwgZGF0YWJhc2Ug
KGFrYS4gYXBwbGllZA0KPj5jb25maWcpDQo+PiBhbmQgdGhlbiBwcm9ncmFtIHRoZSBIVy4NCj4+
IEIpIGZpcnN0IHByb2dyYW0gdGhlIEhXIGFuZCB0aGVuIHJlZmxlY3QgdGhlIHN0YXRlIGluIHRo
ZSBpbnRlcm5hbA0KPj5kYXRhYmFzZQ0KPj4NCj4+IFNheSB0aGUgY2xpZW504oCZcyBpbnRlbnRp
b24gaXMgdG8gY2hhbmdlIGEgbGVhZiB2YWx1ZSBmcm9tIFggdG8gWS4gQWZ0ZXINCj4+IGNvbmZp
Z3VyaW5nLCB0aGUgY2xpZW50IGlzIHJlYWRpbmcgdGhlIGxlYWYgdmFsdWUgYmV0d2VlbiB0aGUg
Zmlyc3QgYW5kDQo+PiB0aGUgc2Vjb25kIHdyaXRlOg0KPj4gQSkgd2lsbCByZXBvcnQgWSwgYnV0
IHN0aWxsIHJ1bnMgd2l0aCBYDQo+PiBCKSB3aWxsIHJlcG9ydCBYLCBidXQgcnVucyBhbHJlYWR5
IHdpdGggWQ0KPj4NCj4+IEFmdGVyIHN1Y2Nlc3NmdWwgYXBwbGljYXRpb24gKGFmdGVyIHN0ZXAg
MiksIGJvdGggaW1wbGVtZW50YXRpb25zIHdpbGwNCj4+IGNvbnNpc3RlbnRseSBleGVjdXRlIGlu
IEhXIGFuZCByZXBvcnQgdGhlIHNhbWUgdmFsdWUgaW4gdGhlIGFwcGxpZWQNCj4+IGNvbmZpZy4g
SG93ZXZlciB0aGUgY2xpZW50IGNhbuKAmXQgcmVseSBvbiB0aGUgaW5mb3JtYXRpb24gaXQgcmVh
ZHMgaW4gdGhlDQo+PiBtZWFudGltZSAtIHRoYXTigJlzIHdoYXQgSSBtZWFudCB3aXRoIOKAmGJs
aW5k4oCZLiBJZiB0aGUgb25seSBwdXJwb3NlIGlzIHRvDQo+PiBtb25pdG9yIHRoZSBwcm9ncmVz
cyBvZiBhcHBseWluZyB0aGUgaW50ZW5kZWQgc3RhdGUsIHRoaXMgbGV2ZWwgb2YNCj4+IGluZm9y
bWF0aW9uIGlzIGdvb2QgZW5vdWdoLCBidXQgSSB3b3VsZCBhcmd1ZSB0aGF0IHRoZXJlIGFyZSBs
ZXNzDQo+PmludGVuc2UNCj4+IG1lY2hhbmlzbXMgdG8gZG8gc28uDQo+PiBJZiB0aGUgY2xpZW50
IHRydWx5IG5lZWRzIHRvIHJlbHkgb24gdGhlIGluZm9ybWF0aW9uIHJlYWQsIGl0IGhhcyB0bw0K
Pj53YWl0DQo+PiBmb3IgY29tcGxldGlvbi4NCj4+Pj4+IFRoZSBkZXZpY2Ugc3RhcnRzIGFwcGx5
aW5nIHRoZSBjaGFuZ2UgKHVzaW5nIHRoZSBzcGVjaWZpZWQgZXJyb3INCj4+Pj4+IGhhbmRsaW5n
IHNlbWFudGljcykNCj4+Pj4gT0sNCj4+Pj4+IFRoZXkgcmVnaXN0ZXIgZm9yIG5vdGlmaWNhdGlv
biBmb3IgY2hhbmdlcyB0byBhbGwgaW50ZW5kZWQvYXBwbGllZA0KPj4+Pj4gY29uZmlnIGFuZCBk
ZXJpdmVkIHN0YXRlIG9uIHRoZSBkZXZpY2Ugc28gdGhhdCB0aGV5IGhhdmUgYSBmZWVkYmFjaw0K
Pj4+Pj4gbWVjaGFuaXNtIHRvIGtub3cgd2hldGhlciB0aGUgY29uZmlndXJhdGlvbiBpcyBiZWlu
ZyBzdWNjZXNzZnVsbHkNCj4+Pj4+IGFwcGxpZWQuDQo+Pj4+IE9LLCBzbyBmcm9tIG5vdyBvbiB0
aGUgY2xpZW50IGtub3dzIHRoYXQgdGhlIG5ldyBpbnRlbmRlZCBjb25maWcgaXMNCj4+Pj4gYWN0
aXZlLiBJdCBhbHNvIG1lYW5zIHRoYXQgdGhlIGNsaWVudCBjYW4gcmVsaWFibHkgcmVhZCBhcHBs
aWVkIHN0YXRlLg0KPj4+IFRoZSBjaGFuZ2VzIHRvIHRoZSBpbmRpdmlkdWFsIGxlYXZlcyBjYW4g
YmUgbm90aWZpZWQgaW5kZXBlbmRlbnRseSBhcw0KPj4+IHRoZXkgY2hhbmdlIHN0YXRlLg0KPj4g
U2VlIGRpc2N1c3Npb24gYWJvdmUgYWJvdXQgcm9sbGJhY2stb24tZXJyb3IgZXRjLiByZXF1aXJp
bmcgYSBjYXJlZnVsDQo+PiBkZWZpbml0aW9uIG9uIHdoZW4gdG8gc2VuZCBub3RpZmljYXRpb25z
Lg0KPj4+IFRoZSBjbGllbnQgY2FuIHJlbGlhYmx5IHJlYWQgdGhlIGFwcGxpZWQgc3RhdGUgYXQN
Cj4+PiBhbnkgdGltZS4NCj4+IE5vIGFncmVlbWVudCBoZXJlLiBBcyBkaXNjdXNzZWQgYWJvdmU6
ICJBIGNsaWVudCBjYW4gcmVhZCBhcHBsaWVkIHN0YXRlDQo+PmF0DQo+PiBhbnkgdGltZSwgYnV0
IGl0IGNhbuKAmXQgcmVsaWFibHkgYXNzdW1lIGl0IGJlaW5nIGFwcGxpZWQgYmVmb3JlDQo+PmNv
bXBsZXRpb24NCj4+IG9mIGFuIG9uZ29pbmcgY29uZmlndXJhdGlvbuKAnS4NCj4+Pg0KPj4+Pj4+
PiBUaGlzIGRvZXMgb3BlbiB0aGUgcXVlc3Rpb24gb2YgaG93IGRvIHlvdSBleHByZXNzIHRoZSBj
YXNlIHRoYXQgbm8NCj4+Pj4+Pj4gdmFsdWUNCj4+Pj4+Pj4gaGFzIGJlZW4gYXBwbGllZCByYXRo
ZXIgdGhhbiBhIGRpZmZlcmVudCB2YWx1ZS4gIEZvciB0aGUgb3BzdGF0ZQ0KPj4+Pj4+PiBlbmNv
ZGluZyBzb2x1dGlvbiBkcmFmdCB0aGF0IEkgcHV0IGZvcndhcmQgKG9yIHVzaW5nIG1ldGEtZGF0
YSksDQo+Pj4+Pj4+IHRoZW4gSQ0KPj4+Pj4+PiB0aGluayB0aGF0IGl0IHdvdWxkIHByb2JhYmx5
IGJlIHBvc3NpYmxlIHRvIGV4dGVuZCB0aGUgZW5jb2RpbmcgdG8NCj4+Pj4+Pj4gZXhwbGljaXRs
eSBpbmNsdWRlIHRoaXMgaW5mb3JtYXRpb24gaWYgcmVxdWlyZWQuDQo+Pj4+Pj4gUGVyaGFwcyBJ
IGFtIG1pc3Npbmcgc29tZXRoaW5nIGhlcmUuIElmIHRoZSB2YWx1ZSBzdXBwb3NlZCB0byBiZQ0K
Pj4+Pj4+IGFwcGxpZWQNCj4+Pj4+PiBpcyB0aGUgc2FtZSB0aGF0IGFscmVhZHkgZXhpc3RzLCBq
dXN0IHNraXAgaXQgaW4gdGhlIHNlcnZlci4NCj4+Pj4+IFRoZSBjYXNlIEkgd2FzIGNvbnNpZGVy
aW5nIGlzIHdoZXJlIHRoZSBzZXJ2ZXIgaGFzIG5vIHZhbHVlIGFwcGxpZWQNCj4+Pj4+IChlLmcu
IGZvciBhbiBvcHRpb25hbCBmZWF0dXJlKSByYXRoZXIgdGhhbiB0aGUgZGVmYXVsdCB2YWx1ZS4N
Cj4+Pj4gV2hhdGV2ZXIgdmFsdWUgdGhlIHNlcnZlciBhcHBsaWVkIChub25lIG9yIGRlZmF1bHQp
IHNob3VsZG7igJl0IGJlIGFuDQo+Pj4+IGlzc3VlDQo+Pj4+IHVubGVzcyB0aGUgaW50ZW5kZWQg
Y29uZmlnIGltcG9zZXMgYSBjZXJ0YWluIHZhbHVlLg0KPj4+IEl0IGlzIGFuIGlzc3VlIGJlY2F1
c2UgdGhlIGNsaWVudCB3YW50cyB0byBrbm93IHdoYXQgY29uZmlndXJhdGlvbiBhDQo+Pj4gZGV2
aWNlIGlzIGFjdHVhbGx5IHJ1bm5pbmcuICBJZGVhbGx5IGl0IHdhbnRzIGEgZ2l2ZW4gZGV2aWNl
IHRvIGV4YWN0bHkNCj4+PiBpbXBsZW1lbnQgdGhlIGNvbmZpZ3VyYXRpb24gdGhhdCB0aGV5IGFy
ZSByZXF1ZXN0aW5nLiAgVGhleSBkb24ndA0KPj4+cmVhbGx5DQo+Pj4gd2FudCBsb3RzIG9mIHJh
bmRvbSBkZXZpY2Ugc3BlY2lmaWMgdmFsdWVzIHRoYXQgd2lsbCByZXF1aXJlIGN1c3RvbQ0KPj4+
IGNsaWVudCBjb2RlIHRvIGhhbmRsZS4NCj4+IEkgdGhpbmsgd2UgYXJlIGluIGFncmVlbWVudCB0
aGF0IHRoZSBjbGllbnQgKm1heSogY29uZmlndXJlIGRlZmF1bHQNCj4+dmFsdWVzDQo+PiB0byBh
ZGRyZXNzIHN1Y2ggY2FzZXMuDQo+Pj4NCj4+Pj4gICAgSSBndWVzcyB5b3UgaGFkIGluDQo+Pj4+
IG1pbmQgb24gaG93IHRvIGRlYWwgd2l0aCB0aGUgb3BzdGF0ZSBvZiBhIG5vbi12YWx1ZS4gUHVz
aGluZyB0aGUNCj4+Pj5vcHN0YXRlDQo+Pj4+IGhpZ2hlciB1cCB0aGUgdHJlZSB3b3VsZCBwcm9i
YWJseSBhZGRyZXNzIHRoZSBpc3N1ZSAoc2VlIGFib3ZlKS4NCj4+Pj4+Pj4gQWx0ZXJuYXRpdmVs
eSwgYW5kIGZvciB0aGUgb3RoZXIgcHJvcG9zZWQgb3BzdGF0ZSBzb2x1dGlvbnMsIHRoZW4gSQ0K
Pj4+Pj4+PiBleHBlY3QgdGhhdCB0aGUgbW9zdCBhcHByb3ByaWF0ZSBpZGVhbCBzZW1hbnRpY3Mg
dG8gaGFuZGxlIHRoaXMNCj4+Pj4+Pj4gc2NlbmFyaW8NCj4+Pj4+Pj4gd291bGQgYmUgdG8gZGVs
YXkgbWFya2luZyB0aGUgcGFyZW50IG9iamVjdCBhcyBiZWluZyBhcHBsaWVkIHVudGlsDQo+Pj4+
Pj4+IGV2ZXJ5DQo+Pj4+Pj4+IGRlc2NlbmRlbnQgY2hpbGQgbGVhZiB3aXRoIGEgZGVmYXVsdCB2
YWx1ZSBzZXQgaGFzIGEgdmFsdWUgYXBwbGllZA0KPj4+Pj4+PmluDQo+Pj4+Pj4+IHRoZSBzeXN0
ZW0sIGVpdGhlciB0byB0aGUgZXhwZWN0ZWQgZGVmYXVsdCB2YWx1ZSAoaW4gd2hpY2ggY2FzZSB0
aGUNCj4+Pj4+Pj4gY2hpbGQgbGVhZiB3b3VsZG4ndCBuZWVkIHRvIGJlIHByZXNlbnQgaW4gdGhl
IGFwcGxpZWQgY29uZmlnKSwgb3INCj4+Pj4+Pj4gdHJhbnNpZW50bHkgdG8gYW5vdGhlciB2YWx1
ZSAod2hpY2ggd291bGQgYmUgaW4gdGhlIGFwcGxpZWQgY29uZmlnDQo+Pj4+Pj4+IHVudGlsDQo+
Pj4+Pj4+IHRoZSBzeXN0ZW0gdXBkYXRlZCBhbmQgdGhlIGNvcnJlY3QgZGVmYXVsdCB2YWx1ZXMg
aGF2ZSBhY3R1YWxseQ0KPj4+Pj4+PmJlZW4NCj4+Pj4+Pj4gYXBwbGllZCkuICBJbiByZWFsIHN5
c3RlbXMsIEkgd291bGQgaGF2ZSB0aG91Z2h0IHRoYXQgdGhlIGRlZmF1bHQNCj4+Pj4+Pj4gdmFs
dWVzDQo+Pj4+Pj4+IGFyZSBvZnRlbiBpbXBsaWNpdGx5IHByb2dyYW1tZWQgd2hlbiB0aGUgcGFy
ZW50IGNvbnRhaW5pbmcgb2JqZWN0DQo+Pj4+Pj4+aXMNCj4+Pj4+Pj4gY3JlYXRlZCBhbnl3YXks
IHNvIEkgc3VzcGVjdCB0aGF0IHRoaXMgYmVoYXZpb3VyIHdvdWxkbid0IGFjdHVhbGx5DQo+Pj4+
Pj4+YmUNCj4+Pj4+Pj4gdGhhdCBvbmVyb3VzIHRvIGltcGxlbWVudC4NCj4+Pj4+PiBJdCBhcHBl
YXJzIHRvIG1lIHRoYXQgd2UgcnVuIGludG8gdGhvc2UgaXNzdWVzIGJ5IHJlcXVpcmluZyB0aGUN
Cj4+Pj4+PiBpbnRlbmRlZA0KPj4+Pj4+IGNvbmZpZyB0byBjb250YWluIGFsc28gdGhlIGRlZmF1
bHQgdmFsdWVzLiBUaGF0IGRvZXNuwrl0IHNlZW0NCj4+Pj4+PiBuZWNlc3NhcnkuDQo+Pj4+Pj4g
SQ0KPj4+Pj4gSSBjYW4ndCBzZWUgaG93IHlvdSBjYW4gaGF2ZSBkZWZhdWx0IHZhbHVlcyBhcHBs
eSBvbmx5IHRvIHRoZSBhcHBsaWVkDQo+Pj4+PiBjb25maWd1cmF0aW9uIGFuZCBub3QgdGhlIGlu
dGVuZGVkIGNvbmZpZ3VyYXRpb24uICBUaGUgaW50ZW5kZWQNCj4+Pj4+IGNvbmZpZ3VyYXRpb24g
Y2Fubm90IGJlIGNvcnJlY3RseSBpbnRlcnByZXRlZCBpZiB5b3UgZG9uJ3QgYWxzbw0KPj4+Pj4g
Y29uc2lkZXINCj4+Pj4+IHRoZSBkZWZhdWx0IHZhbHVlcyBzcGVjaWZpZWQgaW4gdGhlIHNjaGVt
YS4NCj4+Pj4gR2l2ZW4gdGhhdCBzZXJ2ZXJzIG5vd2FkYXlzIGNvdmVyIGEgaHVnZSBhbW91bnQg
b2YgZnVuY3Rpb25hbGl0eSB3aGVyZQ0KPj4+PiBvZnRlbiBvbmx5IGEgc3Vic2V0IGlzIHJlcXVp
cmVkIGJ5IGEgY2xpZW50LCBJIHdvdWxkIGNvbnNpZGVyIHF1aXRlIGENCj4+Pj4gYml0DQo+Pj4+
IG9mIGRlZmF1bHQgdmFsdWVzIGlycmVsZXZhbnQgZm9yIHRoZSBzY29wZSBvZiB0aGUgY2xpZW50
LiBJZiBlLmcuIFlvdQ0KPj4+PiBwbGFuDQo+Pj4+IHRvIHVzZSBhIHJvdXRlciB0aGF0IHN1cHBv
cnRzIFZQTFMsIGJ1dCB5b3UgZG8gbm90IGNhcmUgc2luY2UgaXQgaXMNCj4+Pj5ub3QNCj4+Pj4g
bmVlZGVkLCB0aG9zZSBkZWZhdWx0cyBjYW4ganVzdCBiZSBsZWZ0IHRvIHRoZSBzZXJ2ZXIuDQo+
Pj4gWUFORyBhbHJlYWR5IHRha2VzIGNhcmUgb2YgdGhpcywgYXMgcGVyIFJGQzYwMjBiaXMgc2Vj
dGlvbiA3LjYuMSwgb25seQ0KPj4+IHRoZSBkZWZhdWx0cyB0aGF0IGFyZSBpbiBzY29wZSBmb3Ig
eW91ciBjb25maWd1cmF0aW9uIGFyZSByZWxldmFudC4NCj4+IEluIG90aGVyIHdvcmRzLCBhbGwg
ZGVmYXVsdHMgdGhhdCBhcmUgbm90IGluIHNjb3BlIHJlbWFpbiBhcyBzZXQgYnkgdGhlDQo+PiBz
dXBwbGllciBvZiB0aGUgU2VydmVyIGFuZCB3aWxsIG5vdCBiZSBjaGFuZ2VkIGJ5IHRoZSBjbGll
bnQuIExvb2tzIHdlDQo+PmFyZQ0KPj4gaW4gYWdyZWVtZW50Lg0KPj4+Pj4+IHdvdWxkIGFsc28g
YXJndWUgdGhhdCBtYXJraW5nIHRoZSDFkmFwcGxpZWQ9aW50ZW5kZWTCuSBzdGF0ZSBwZXIgbGVh
Zg0KPj4+Pj4+aXMNCj4+Pj4+PiBjb3VudGVyLXByb2R1Y3RpdmUuIEFzc3VtZSB0aGUgY2xpZW50
IHNldHMgYW4gaW50ZW5kZWQgc3RhdGUgb2YgdHdvDQo+Pj4+Pj4gdmFsdWVzDQo+Pj4+PiBUcmFj
a2luZyBpbnRlbmRlZCB2cyBhcHBsaWVkIG9uIGEgcGVyIGxlYWYgYmFzaXMgaXMgdGhlIGVzc2Vu
Y2Ugb2YNCj4+Pj4+dGhlDQo+Pj4+PiBvcHN0YXRlIHJlcXVpcmVtZW50cywgcGxlYXNlIGxldHMg
bm90IHJlaGFzaCB0aGVzZSBhbGwgeWV0IGFnYWluLiA6LSkNCj4+Pj4gU2VlIGFib3ZlLCB5b3Ug
Y2FuIGRvIHRoaXMgYnV0IGl04oCZcyBxdWl0ZSBhIGJpdCBvZiB3b3JrLiBUaGUNCj4+Pj5yZXF1
aXJlbWVudA0KPj4+PiBzdGVtcyBmcm9tIGEgdGltZSB3aGVyZSBhIGNsaWVudCB3YXNu4oCZdCBh
YmxlIHRvIGZpZ3VyZSBvdXQgd2hldGhlciBhDQo+Pj4+IGxlYWYNCj4+Pj4gaGFzIGJlZW4gY2hh
bmdlZCBhbHJlYWR5IG9yIHdhcyBhYm91dCB0byBjaGFuZ2UgaW4gZnV0dXJlLiBUbyBtZSBpdA0K
Pj4+PiBhcHBlYXJzIG1vcmUgb2YgYW4gaW1wbGVtZW50YXRpb24gY2hvaWNlLg0KPj4+IEkgZGlz
YWdyZWUuICBUaGUgcmVxdWlyZW1lbnRzIGFyZSBmcm9tIHRoZSBwZXJjZWl2ZWQgZGVmaWNpZW5j
aWVzIGluDQo+Pj4gTkVUQ09ORi9ZQU5HIHRoYXQgbmVlZCB0byBiZSBmaXhlZCBmb3Igb3BlcmF0
b3JzIHRvIHVzZSBZQU5HDQo+Pj5lZmZlY3RpdmVseS4NCj4+IFdlIGFncmVlIHRoYXQgIlRyYWNr
aW5nIGludGVuZGVkIHZzIGFwcGxpZWQgb24gYSBwZXIgbGVhZiBiYXNpc+KAnSBpcyBhDQo+PiBy
ZXF1aXJlbWVudCwgYnV0IGl0IGFwcGVhcnMgdG8gbWUgdGhhdCB3ZSBoYXZlIGRpZmZlcmVudCBp
ZGVhcyBvbiB0aGUNCj4+IGludGVycHJldGF0aW9uIG9mIOKAmGFwcGxpZWQnIGR1cmluZyB0aGUg
dHJhbnNpdGlvbiBwZXJpb2QuIEluIGFuDQo+PiBpbXBsZW1lbnRhdGlvbiBkcmFmdCBJIHdvdWxk
IGNvbnNpZGVyIHNvbWV0aGluZyBhbG9uZyB0aG9zZSBsaW5lczoNCj4+DQo+PiBJZiBhIHNlcnZl
ciBjb21wbGV0ZWQgdGhlIGFwcGxpY2F0aW9uIG9mIGludGVuZGVkIGNvbmZpZyAod2l0aCBvcg0K
Pj53aXRob3V0DQo+PiBlcnJvcnMpLCB0aGUgYXBwbGllZCBjb25maWcgU0hBTEwgcmVmbGVjdCB0
aGUgYWN0dWFsIGNvbmZpZ3VyYXRpb24gaW4NCj4+IGZvcmNlLiBBbGwgbGVhdmVzIHdoZXJlIHRo
ZSB2YWx1ZSBvZiBpbnRlbmRlZCA9PSBhcHBsaWVkIGFyZSBpbiB0aGUNCj4+c3RhdGUNCj4+ICJp
bnRlbmRlZCA9IGFwcGxpZWTigJ0uIEFsbCBsZWF2ZXMgd2l0aCBpbnRlbmRlZCAhPSBhcHBsaWVk
IGFyZSBpbiBlcnJvcg0KPj4gKHRiZCkNCj4+DQo+PiBJZiBhIHNlcnZlciBpcyBpbiB0aGUgcHJv
Y2VzcyB0byBhcHBseSBjb25maWd1cmF0aW9uLCB0aGUgcmVwb3J0ZWQNCj4+YXBwbGllZA0KPj4g
dmFsdWUgTUFZIE5PVCByZWZsZWN0IHRoZSBhY3R1YWwgY29uZmlndXJhdGlvbiBpbiBmb3JjZS4g
VGhlbiB0aGUgZmFjdA0KPj4gdGhhdCB0aGUgdmFsdWVzIG9mIGludGVuZGVkIGVxdWFsIHRob3Nl
IG9mIGFwcGxpZWQgU0hPVUxEIE5PVCBiZSB0YWtlbg0KPj5hcw0KPj4gcmVsaWFibGUgaW5kaWNh
dGlvbiB0aGF0IHRoZSBpbnRlbmRlZCBjb25maWd1cmF0aW9uIGlzIGFjdHVhbGx5IGluDQo+PmZv
cmNlLg0KPj4gTGlrZXdpc2UgYSB2YWx1ZSBvZiBpbnRlbmRlZCAhPSBhcHBsaWVkIFNIT1VMRCBO
T1QgYmUgdGFrZW4gYXMgcmVsaWFibGUNCj4+IGluZGljYXRpb24gdGhhdCB0aGUgaW50ZW5kZWQg
Y29uZmlndXJhdGlvbiBpcyBub3QgaW4gZm9yY2UuDQo+Pg0KPj4gTk9URTogd2hldGhlciB0aGUg
YXBwbGllZD1pbnRlbmRlZCBzdGF0ZSBuZWVkcyB0byBiZSBjb2RlZCBvbiBhDQo+PiBwZXItbGVh
Zi1sZXZlbCBvciBoaWdoZXIgdXAgaW4gdGhlIHRyZWUgaXMgYSBzZXBhcmF0ZSBpc3N1ZS4NCj4+
Pg0KPj4+Pj4+IChBLEIpIG9uIHR3byBkaWZmZXJlbnQgbGVhZnMgd2l0aCByb2xsYmFjay1vbi1l
cnJvciBzZW1hbnRpYy4gSWYNCj4+Pj4+PiBhcHBseWluZw0KPj4+Pj4+IEEgc3VjY2VlZHMgYW5k
IHRoZSBjbGllbnQgcmVhZHMgdGhlIGFwcGxpZWQgc3RhdGUgd2hpbGUgYXBwbHlpbmcgQg0KPj4+
Pj4+aXMNCj4+Pj4+PiBzdGlsbCBpbiBwcm9ncmVzcywgYSByb2xsYmFjayBtYXkgc3RpbGwgaGFw
cGVuLiBUaGF0IHdvdWxkDQo+Pj4+Pj5pbnZhbGlkYXRlDQo+Pj4+Pj4gdGhlDQo+Pj4+Pj4gcHJl
dmlvdXMgdmFsdWUgb2YgQS4gSW4gb3RoZXIgd29yZHMgaXQgaXMgdW53aXNlIHRvIHJlYWQgZGF0
YSBmcm9tIGENCj4+Pj4+PiBzb3VyY2Ugd2hpbGUgaXQgaXMgYWN0dWFsbHkgd3JpdGluZy4NCj4+
Pj4+IE5vLCB0aGlzIGlzIGZpbmUsIGFuZCBpc24ndCBhIHByb2JsZW0uICBUaGUgc2VydmVyIHdp
bGwgZXZlbnR1YWxseQ0KPj4+Pj4gY29udmVyZ2Ugb24gYSBzdGF0ZSBhbmQgdGhlIGNsaWVudCB3
aWxsIGJlIG5vdGlmaWVkIG9mIHRoYXQgc3RhdGUuDQo+Pj4+PiBUaGUNCj4+Pj4+IGZhY3QgdGhh
dCBhIGNsaWVudCBtaWdodCB0ZW1wb3JhcmlseSBzZWUgYSB2YWxpZCBzdGF0ZSB0aGF0IGlzDQo+
Pj4+PiBzdWJzZXF1ZW50bHkgdW5kb25lIGlzbid0IGEgcHJvYmxlbS4NCj4+Pj4gSeKAmWQgc2Vy
aW91c2x5IHF1ZXN0aW9uIHRob3NlIHR3byBzdGF0ZW1lbnRzLiBXaGVuIHRoZSBzZXJ2ZXIgaXMN
Cj4+Pj51cGRhdGluZw0KPj4+PiBpdHMgYXBwbGllZCBzdGF0ZSB5b3UgaGF2ZSBhdCBiZXN0IGEg
NTAlIGNoYW5jZSB0byByZWFkIHRoZSBjb3JyZWN0DQo+Pj4+IHZhbHVlLg0KPj4+PiBXaGF0IG1l
YW5pbmdmdWwgY29uY2x1c2lvbiBpcyB0aGUgY2xpZW50IHN1cHBvc2VkIHRvIHRha2UgZnJvbSB0
aGF0Pw0KPj4+Pk91dA0KPj4+PiBvZiBkZXNwZXJhdGlvbiwgY3VycmVudCBpbXBsZW1lbnRhdGlv
bnMgdXNlIHRoYXQg4oCYdHJpY2vigJkgYnkgcG9sbGluZw0KPj4+PiB2YXJpb3VzIGxlYWYgdmFs
dWVzIHRvIGZpZ3VyZSBvdXQgd2hldGhlciBhbiBpbnRlbmRlZCBzdGF0ZSBoYXMNCj4+Pj5hbHJl
YWR5DQo+Pj4+IGJlZW4gYXBwbGllZCBvciBub3QuIEhvd2V2ZXIgc3VjaCBpbnRlbnNpdmUgcG9s
bGluZyBjeWNsZXMgYXJlIG5vIG1vcmUNCj4+Pj4gbmVlZGVkIG9uY2UgYSBzZXJ2ZXIgbm90aWZp
ZXMgdGhlIGNsaWVudCB1cG9uIGNvbXBsZXRpb24gb2YgaW50ZW5kZWQNCj4+Pj4gc3RhdGUNCj4+
Pj4gYXBwbGljYXRpb24uDQo+Pj4+IElmIHRoZSBjbGllbnQgY2hvb3NlcyB0byByZWFkIGFwcGxp
ZWQgc3RhdGUgZHVyaW5nIHRoYXQgcGVyaW9kLCBpdCBpcw0KPj4+PmF0DQo+Pj4+IGxlYXN0IGF3
YXJlIHRoYXQgdGhlIHN0YXRlIGlzIGp1c3QgYSB0ZW1wb3Jhcnkgc25hcHNob3QuDQo+Pj4gVGhl
IGNsaWVudCBkb2Vzbid0IHBvbGwuICBJbnN0ZWFkIGl0IHJlZ2lzdGVycyBmb3Igbm90aWZpY2F0
aW9uIG9mDQo+Pj4gY2hhbmdlcyBhbmQgcmVjZWl2ZXMgYSBjb250aW51b3VzIHN0cmVhbSBvZiB1
cGRhdGVzLg0KPj4+DQo+Pj4gQXQgYW55IHBvaW50IGluIHRpbWUsIHRoZSB2YWx1ZSByZWFkIGJ5
IHRoZSBjbGllbnQgaXMgY29ycmVjdCwgaXQganVzdA0KPj4+IGhhcHBlbnMgdGhhdCB0aGUgc3lz
dGVtIGNhbiBiZSB0aG91Z2h0IG9mIGJlaW5nIGluIHRoZSBzdGF0ZSBvZg0KPj4+Y29uc3RhbnQN
Cj4+PiBmbHV4Lg0KPj4+DQo+Pj4gRS5nLiB0aGUgZ2xvYmFsIEJHUCByb3V0aW5nIHRhYmxlIGlz
IGNvbnN0YW50bHkgY2hhbmdpbmcsIGJ1dCB0aGF0DQo+Pj4gZG9lc24ndCBtZWFuIHRoYXQgeW91
IGNhbid0IHRha2UgYSB1c2VmdWwgc25hcHNob3Qgb2YgaXQsIG9yIG1vbml0b3INCj4+Pmhvdw0K
Pj4+IGl0IGlzIGNoYW5naW5nLg0KPj4+DQo+Pj4gVGhhbmtzLA0KPj4+IFJvYg0KPj4+DQo+Pj4N
Cj4+Pj4+IFRoYW5rcywNCj4+Pj4+IFJvYg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pj4+IFRoYW5rcywN
Cj4+Pj4+Pj4gUm9iDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+PiBMYWRhDQo+Pj4+Pj4+Pg0K
Pj4+Pj4+Pj4+ICAgICAgICBsaXN0IGludGVyZmFjZSB7DQo+Pj4+Pj4+Pj4gICAgICAgICAgZGVz
Y3JpcHRpb24tY29uZmlnDQo+Pj4+Pj4+Pj4gICAgICAgICAgICAiVGhlIGxpc3Qgb2YgY29uZmln
dXJlZCBpbnRlcmZhY2VzIG9uIHRoZSBkZXZpY2UuDQo+Pj4+Pj4+Pj4gICAgICAgICAgICAgLi4u
IjsNCj4+Pj4+Pj4+PiAgICAgICAgICBkZXNjcmlwdGlvbi1vcGVyDQo+Pj4+Pj4+Pj4gICAgICAg
ICAgICAiVGhlIGxpc3Qgb2YgaW50ZXJmYWNlcyBvbiB0aGUgZGV2aWNlLg0KPj4+Pj4+Pj4+ICAg
ICAgICAgIA0KPj4+Pj4+Pj4+ICAgICAgICAgICAgIFN5c3RlbS1jb250cm9sbGVkIGludGVyZmFj
ZXMgY3JlYXRlZCBieSB0aGUgc3lzdGVtDQo+Pj4+Pj4+Pj5hcmUNCj4+Pj4+Pj4+PiAgICAgICAg
ICAgICBhbHdheXMgcHJlc2VudCBpbiB0aGlzIGxpc3QsIHdoZXRoZXIgdGhleSBhcmUNCj4+Pj4+
Pj4+PiBjb25maWd1cmVkIG9yDQo+Pj4+Pj4+Pj4gICAgICAgICAgICAgbm90Lg0KPj4+Pj4+Pj4+
ICAgICAgICAgICAgIC4uLiI7DQo+Pj4+Pj4+Pj4gICAgICAgIH0NCj4+Pj4+Pj4+Pg0KPj4+Pj4+
Pj4+DQo+Pj4+Pj4+Pj4gL21hcnRpbg0KPj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+Pj4+
Pj4+IG5ldG1vZEBpZXRmLm9yZw0KPj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL25ldG1vZA0KPj4+Pj4+IC4NCj4+Pj4+Pg0KPg0KDQo=


From nobody Wed Jan 13 08:45:30 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E7A1B2AD6 for ; Wed, 13 Jan 2016 08:40:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owTXmwyhgicM for ; Wed, 13 Jan 2016 08:40:11 -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 E534C1B2EF1 for ; Wed, 13 Jan 2016 08:40:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6857; q=dns/txt; s=iport; t=1452703210; x=1453912810; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BNGlLMvD0uSDQk7kq9I8+TZ1yGGvRQ9GWXKrapOszdQ=; b=ZWGQqPPfVK33TI4Sqv7UCwrd41RbDd5A0RgvRrsrDo0ZgVuhHj5i8Ujf F4loq+L82zaOWEhSbS7SNkZEjmHkk8Os/D153Z1HtxaaRNWnIf4ODbJQt owwurTHRqBNBaad7gsIhhxMNkCLkOeH+poOJl1P8ydMmzZEq4C7jIEZNm 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAgCzfZZW/49dJa1egm5MgT8GiFSzF?= =?us-ascii?q?AENgWSGDwKBOzgUAQEBAQEBAYEKhDQBAQEEbgYFEAIBCBEDAQIoBzIUCQgCBA4?= =?us-ascii?q?FiC7AVgEBAQEBAQEBAQEBAQEBAQEBAQEBARiGV4R+hCYQAgE+hEYFjXuFF4QDA?= =?us-ascii?q?Y1ZgV6ERIhejlUBIAEBQoQKcoUUgQgBAQE?=
X-IronPort-AV: E=Sophos;i="5.22,290,1449532800";  d="scan'208,217";a="226915293"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jan 2016 16:39:55 +0000
Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u0DGdtnQ011217 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Jan 2016 16:39:55 GMT
Received: from xch-rcd-014.cisco.com (173.37.102.24) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 13 Jan 2016 10:39:54 -0600
Received: from xch-rcd-014.cisco.com ([173.37.102.24]) by XCH-RCD-014.cisco.com ([173.37.102.24]) with mapi id 15.00.1104.009; Wed, 13 Jan 2016 10:39:54 -0600
From: "Kiran Koushik Agrahara Sreenivasa (kkoushik)" 
To: netmod WG 
Thread-Topic: [netmod] IPR Check: draft-ietf-netmod-acl-model-06
Thread-Index: AQHRTiEHPMAQYue0sU+C/cojgv9qEQ==
Date: Wed, 13 Jan 2016 16:39:54 +0000
Message-ID: 
References: <7D3E013C-EAA1-4F85-88BF-054AD13884E5@lucidvision.com>
In-Reply-To: <7D3E013C-EAA1-4F85-88BF-054AD13884E5@lucidvision.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.232.47]
Content-Type: multipart/alternative; boundary="_000_D2BBD987DA21kkoushikciscocom_"
MIME-Version: 1.0
Archived-At: 
X-Mailman-Approved-At: Wed, 13 Jan 2016 08:45:28 -0800
Cc: "draft-bogdanovic-netmod-acl-model@tools.ietf.org" 
Subject: Re: [netmod] IPR Check: draft-ietf-netmod-acl-model-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Jan 2016 16:40:13 -0000

--_000_D2BBD987DA21kkoushikciscocom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

After discussion with Eliot, We've concluded that Cisco does not have any I=
PR that applies directly to draft-ietf-netmod-acl-model

Thanks
Kiran


From: Nadeau Thomas >
Date: Wednesday, December 9, 2015 at 10:29 AM
To: netmod WG >
Cc: >
Subject: [netmod] IPR Check: draft-ietf-netmod-acl-model-06



This mail starts the IPR poll on draft-ietf-netmod-acl-model-06.

Are you aware of any IPR that applies to draft-ietf-netmod-acl-model-06?
If so, has this IPR been disclosed in compliance with IETF IPR rules (see R=
FCs
3979, 4879, 3669 and 5378 for more details)?

If you are listed as a document author or contributor please respond to thi=
s
email explicitly regardless of whether or not you are aware of any relevant=
 IPR.
The response needs to be sent to the NETMOD WG mailing list.  The document
will not advance to the next stage until a response has been received from =
each
author and contributor.

If you are on the NETMOD WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of any IP=
R that
has not yet been disclosed in conformance with IETF rules.

Thank you,

Kent and Tom, NETMOD WG Chairs



--_000_D2BBD987DA21kkoushikciscocom_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







After discussion with Eliot, We’ve concluded that Cisco does not=
 have any IPR that applies directly to draft-ietf-netmod-acl-model







Thanks


Kiran














From: Nadeau Thomas <tnadeau@lucidvision.com>

Date: Wednesday, December 9, 2015 a=
t 10:29 AM

To: netmod WG <netmod@ietf.org>

Cc: <draft-bogdanovic-netmod-acl-model@=
tools.ietf.org>

Subject: [netmod] IPR Check: draft-=
ietf-netmod-acl-model-06


























This mail starts the IPR poll on draft-ietf-netmod-acl-model-06.








Are you aware of any IPR that applies to draft-ietf-netmod-acl-model-06?


If so, has this IPR been disclosed in compliance with IETF IPR rules (see R=
FCs



3979, 4879, 3669 and 5378 for more details)?








If you are listed as a document author or contributor please respond to thi=
s



email explicitly regardless of whether or not you are aware of any relevant=
 IPR.



The response needs to be sent to the NETMOD WG mailing list.  The docu=
ment



will not advance to the next stage until a response has been received from =
each



author and contributor.








If you are on the NETMOD WG email list but are not listed as an author or


contributor, then please explicitly respond only if you are aware of any IP=
R that



has not yet been disclosed in conformance with IETF rules.








Thank you,





Kent and Tom, NETMOD WG Chairs




















--_000_D2BBD987DA21kkoushikciscocom_--


From nobody Thu Jan 14 01:11:56 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15E91B2D61 for ; Thu, 14 Jan 2016 01:11:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vrs6IEugNr98 for ; Thu, 14 Jan 2016 01:11:54 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7210D1B2D62 for ; Thu, 14 Jan 2016 01:11:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12563; q=dns/txt; s=iport; t=1452762714; x=1453972314; h=from:to:cc:subject:date:message-id:mime-version; bh=d9o3R8RbOPl321Jg1+9JSM1u8ldbiZ49p02ogQRcs24=; b=ZqSnEOo9soo/090Z+gDvIjXAzyqA25V+bjnwnXjS+58gdmR8YJskFIo9 n52d6gQZ0+ZeRhSGAX1TWOgNHz1joXz1UcgHb0quCleN0CrgMBDxLEUF1 Aa6Vbp0vtmQz7cnyyKPNTFfM4SUgtZ+AcDaCnzq+UILnlTJpfDgNnkQyM 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAgAjZpdW/51dJa1egm5MgUWFfYJYp?= =?us-ascii?q?EYBBI5KAQ2BZIYPgTw4FAEBAQEBAQF/C4Q3BHkSASk0EBMfCAQOiDPAJgEBAQE?= =?us-ascii?q?BBQEBAQEBAQEclRIFi0OHUIQDARKNSI8BjlgBIAEBQoQKhhuBCAEBAQ?=
X-IronPort-AV: E=Sophos; i="5.22,293,1449532800"; d="scan'208,217"; a="61482293"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jan 2016 09:11:53 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u0E9BrY6026186 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 14 Jan 2016 09:11:53 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 14 Jan 2016 03:11:52 -0600
Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1104.009; Thu, 14 Jan 2016 03:11:52 -0600
From: "Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco)" 
To: "netmod@ietf.org" 
Thread-Topic: one module imported with two different prefixes
Thread-Index: AQHRTqnTo9e7HrFXX0ew4VOBzrJ5Lg==
Date: Thu, 14 Jan 2016 09:11:52 +0000
Message-ID: <1452762715740.50030@cisco.com>
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.61.197.85]
Content-Type: multipart/alternative; boundary="_000_145276271574050030ciscocom_"
MIME-Version: 1.0
Archived-At: 
Cc: "Robert Varga -X \(rovarga - PANTHEON TECHNOLOGIES at Cisco\)" , "Tony Tkacik -X \(ttkacik - PANTHEON TECHNOLOGIES at Cisco\)" , "Peter Kajsa -X \(pkajsa - PANTHEON TECHNOLOGIES at Cisco\)" 
Subject: [netmod] one module imported with two different prefixes
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jan 2016 09:11:55 -0000

--_000_145276271574050030ciscocom_
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

Dear all

We've come across following set of import statements in YANG file:

import  a {
    prefix "a0";
}

import a {
    prefix "a1";
}

So, there is one module imported with 2 different prefixes and used at vari=
ous places.

We're not sure if this is completely valid input for our YANG statement par=
ser.

  Thank you for help.

       Best Regards

            Martin



--_000_145276271574050030ciscocom_
Content-Type: text/html; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable









=
Dear
 all









We've come across following set of import statements in YANG file:











import
  a { 



    prefix
 "a0";



}









import
 a {



    prefix
 "a1";



} 



=






=
So,
 there is one module imported with 2 different prefixes and used =
at various places.



=






=
We're
 not sure if this is completely valid input for our YANG statement parser.<=
/span>



=






=
 
 Thank you for help.



=






=
 
      Best Regards



=






=
 
           Martin











--_000_145276271574050030ciscocom_--


From nobody Thu Jan 14 01:19:14 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B51D1B2D73 for ; Thu, 14 Jan 2016 01:19:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oWDjXjSRxV5 for ; Thu, 14 Jan 2016 01:19:11 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 89B031B2D63 for ; Thu, 14 Jan 2016 01:19:05 -0800 (PST)
Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id D71EA1AE047A; Thu, 14 Jan 2016 10:19:03 +0100 (CET)
Date: Thu, 14 Jan 2016 10:19:06 +0100 (CET)
Message-Id: <20160114.101906.688806090391415335.mbj@tail-f.com>
To: aashaikh@google.com
From: Martin Bjorklund 
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: [netmod] openconfig clarification on applied config
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jan 2016 09:19:13 -0000

Anees,

I am trying to understand (again/still) exactly what your (openconfig)
intention is re applied config.


First, re. pre-configuration.

draft-openconfig-netmod-opstate-01.txt says:

   It is notable that the intended configuration and the applied
   configuration represent exactly the same set of variables (leaves).
   These may have different values based on the current point in time
   (e.g., if the change has not been communicated to an external
   software entity), or due to missing dependencies (e.g., a particular
   linecard not being installed).

So it seems that if hw is missing, the corresponding config is NOT
part of applied.

But in
https://mailarchive.ietf.org/arch/msg/netmod/h-SaTZnCc8deZk2yFDM9Q54OKfw
you wrote:

  Similarly, if an implementation supports pre-configuration of
  interfaces, for example, the intended configuration reflects that
  preconfiguration, while the corresponding state would show that it
  is applied but also that oper-status = 'NOT PRESENT'.

This seems to say that the pre-configured interface would show up both
in intended and applied.

I realize that the email was written some time after the draft was
published.

What is the correct answer?

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

Here's another situation.   Suppose I configure some daemon to listen
to a port that happens to be used on the system (let's say I picked
32768, and it was assigned by the kernel to some process listening to
0 just microseconds before my daemon tried to use it).  It is clear
that intended would contain port 32768, and it is clear that the
derived state would show that some other processes uses this port, but
what would end up in applied?  Specifically, if your answer is that
applied != intended in this case, what exactly would be different?
Just the port, or also the rest of the daemon's config?


/martin


From nobody Thu Jan 14 01:28:09 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAFEF1B2D94 for ; Thu, 14 Jan 2016 01:28:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCITMkq6TQmn for ; Thu, 14 Jan 2016 01:28:07 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E6BF31B2D93 for ; Thu, 14 Jan 2016 01:28:06 -0800 (PST)
Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id D4D561AE047A; Thu, 14 Jan 2016 10:28:05 +0100 (CET)
Date: Thu, 14 Jan 2016 10:28:08 +0100 (CET)
Message-Id: <20160114.102808.1453846140169001471.mbj@tail-f.com>
To: mciglan@cisco.com
From: Martin Bjorklund 
In-Reply-To: <1452762715740.50030@cisco.com>
References: <1452762715740.50030@cisco.com>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: rovarga@cisco.com, ttkacik@cisco.com, pkajsa@cisco.com, netmod@ietf.org
Subject: Re: [netmod] one module imported with two different prefixes
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jan 2016 09:28:08 -0000

"Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco)"  wrote:
> Dear all
> 
> We've come across following set of import statements in YANG file:
> 
> import  a {
>     prefix "a0";
> }
> 
> import a {
>     prefix "a1";
> }
> 
> So, there is one module imported with 2 different prefixes and used at
> various places.
> 
> We're not sure if this is completely valid input for our YANG
> statement parser.

There is no text in RFC 6020 (or 6020bis) that makes this invalid.


/martin


From nobody Thu Jan 14 01:49:27 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445FE1B31A2 for ; Thu, 14 Jan 2016 01:49:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.352
X-Spam-Level: 
X-Spam-Status: No, score=-0.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkDoRkstMhrE for ; Thu, 14 Jan 2016 01:49:24 -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 B12021B31A1 for ; Thu, 14 Jan 2016 01:49:23 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:cd15:5104:e5cd:7f78] (unknown [IPv6:2001:718:1a02:1:cd15:5104:e5cd:7f78]) by mail.nic.cz (Postfix) with ESMTPSA id C2F61181C3A; Thu, 14 Jan 2016 10:49:21 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452764961; bh=NlZOLItCtfbdKmCtCTnThAS17RxlRDNohdaSZAi5CJg=; h=From:Date:To; b=QaFqi9uf/YADhJ5/OKKUUT9QvmXFQX0HSWr8EUDEX90XRW3hI20wWxH/gMC6VUW0D bBjEbTYmef5D1L5JZpOMBz6vQLfnzrNr9CEbfX4ptPL3FrlK+AVWpjuboK0rOTlHXH CkKGSlKGALaBW6Lqz2SEChFQ+yEoPVWO4vldnNSw=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: <20160114.102808.1453846140169001471.mbj@tail-f.com>
Date: Thu, 14 Jan 2016 10:49:22 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <1452762715740.50030@cisco.com> <20160114.102808.1453846140169001471.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: rovarga@cisco.com, ttkacik@cisco.com, mciglan@cisco.com, netmod@ietf.org, pkajsa@cisco.com
Subject: Re: [netmod] one module imported with two different prefixes
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jan 2016 09:49:26 -0000

> On 14 Jan 2016, at 10:28, Martin Bjorklund  wrote:
>=20
> "Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco)" =
 wrote:
>> Dear all
>>=20
>> We've come across following set of import statements in YANG file:
>>=20
>> import  a {
>>    prefix "a0";
>> }
>>=20
>> import a {
>>    prefix "a1";
>> }
>>=20
>> So, there is one module imported with 2 different prefixes and used =
at
>> various places.
>>=20
>> We're not sure if this is completely valid input for our YANG
>> statement parser.
>=20
> There is no text in RFC 6020 (or 6020bis) that makes this invalid.

Yes, and in fact it is possible to import different revisions of the =
same module this way.

Lada

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

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





From nobody Thu Jan 14 01:55:43 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93EA11B2D6D for ; Thu, 14 Jan 2016 01:55:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.453
X-Spam-Level: 
X-Spam-Status: No, score=-0.453 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5av8aESgiAU for ; Thu, 14 Jan 2016 01:55: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 C7BB41B2ED6 for ; Thu, 14 Jan 2016 01:55:40 -0800 (PST)
Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id 888F51AE047A; Thu, 14 Jan 2016 10:55:39 +0100 (CET)
Date: Thu, 14 Jan 2016 10:55:41 +0100 (CET)
Message-Id: <20160114.105541.1121453018162320177.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References: <1452762715740.50030@cisco.com> <20160114.102808.1453846140169001471.mbj@tail-f.com> 
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: rovarga@cisco.com, ttkacik@cisco.com, mciglan@cisco.com, netmod@ietf.org, pkajsa@cisco.com
Subject: Re: [netmod] one module imported with two different prefixes
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jan 2016 09:55:41 -0000

Ladislav Lhotka  wrote:
> 
> > On 14 Jan 2016, at 10:28, Martin Bjorklund  wrote:
> > 
> > "Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco)"
> >  wrote:
> >> Dear all
> >> 
> >> We've come across following set of import statements in YANG file:
> >> 
> >> import  a {
> >>    prefix "a0";
> >> }
> >> 
> >> import a {
> >>    prefix "a1";
> >> }
> >> 
> >> So, there is one module imported with 2 different prefixes and used at
> >> various places.
> >> 
> >> We're not sure if this is completely valid input for our YANG
> >> statement parser.
> > 
> > There is no text in RFC 6020 (or 6020bis) that makes this invalid.
> 
> Yes, and in fact it is possible to import different revisions of the
> same module this way.

Not in YANG 1, but it is allowed in 1.1.

RFC 6020 says:

   Multiple revisions of the same module MUST NOT be imported.


/martin


From nobody Thu Jan 14 02:03:44 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315A31B3279 for ; Thu, 14 Jan 2016 02:03:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTJjCH7M6IG5 for ; Thu, 14 Jan 2016 02:03:41 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5E0F1B31FA for ; Thu, 14 Jan 2016 02:03:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1904; q=dns/txt; s=iport; t=1452765820; x=1453975420; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=dHDP27W/bohn8lbMZ0uSAfXLEECLRYXbO1/f2tF0yHs=; b=CxfuWfcVXx8MooiZvTK9Aitp5L9bLVN1BL1xyK68S+/omISFknShQZDZ kZHAJzPnvcx73jPs7/0c/c9VTggyA2uMkXdrN3h/8sEOKb4cIP7n2BpQa xC2m9glNipDkaXZT0NSVbxQADDvozFq2R756oaZYVUvYMFDUw9hJSoTgM U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAgBQcpdW/5tdJa1egzqBPwaFfYJYp?= =?us-ascii?q?EYBBI5KAQ2BZIYPAoE6OBQBAQEBAQEBgQqENAEBAQR5EAIBCA4KCSUPEBMlAgQ?= =?us-ascii?q?BDQWILsAhAQEBAQEBAQEBAQEBAQEBAQEBAQEZi1WJPQWXFgESjUiBXo0jimaDc?= =?us-ascii?q?gEgAQFChApyhSmBCAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.22,293,1449532800"; d="scan'208";a="225514830"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jan 2016 10:03:40 +0000
Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u0EA3e1Q021392 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Jan 2016 10:03:40 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 14 Jan 2016 04:03:39 -0600
Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1104.009; Thu, 14 Jan 2016 04:03:39 -0600
From: "Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco)" 
To: Martin Bjorklund , Ladislav Lhotka 
Thread-Topic: [netmod] one module imported with two different prefixes
Thread-Index: AQHRTqnTo9e7HrFXX0ew4VOBzrJ5Lp77IwMAgAAF7wCAAAHDgP//nKtL
Date: Thu, 14 Jan 2016 10:03:39 +0000
Message-ID: <1452765824122.96904@cisco.com>
References: <1452762715740.50030@cisco.com> <20160114.102808.1453846140169001471.mbj@tail-f.com> , <20160114.105541.1121453018162320177.mbj@tail-f.com>
In-Reply-To: <20160114.105541.1121453018162320177.mbj@tail-f.com>
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.61.197.85]
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "Robert Varga -X \(rovarga - PANTHEON TECHNOLOGIES at Cisco\)" , "Tony Tkacik -X \(ttkacik - PANTHEON TECHNOLOGIES at Cisco\)" , "netmod@ietf.org" , "Peter Kajsa -X \(pkajsa - PANTHEON TECHNOLOGIES at Cisco\)" 
Subject: Re: [netmod] one module imported with two different prefixes
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jan 2016 10:03:43 -0000

Hi all=0A=
=0A=
Thank you for sharing your knowledge.=0A=
Obviously, we see the point of importing different revisions of very same m=
odule,=0A=
but in our case, revision is only one, so, that's why we've checked with yo=
u. Thanks.=0A=
=0A=
   Best Regards=0A=
=0A=
        Martin=0A=
________________________________________=0A=
Od: Martin Bjorklund =0A=
Odoslan=E9: 14. janu=E1ra 2016 10:55=0A=
Komu: lhotka@nic.cz=0A=
K=F3pia: Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco); Rober=
t Varga -X (rovarga - PANTHEON TECHNOLOGIES at Cisco); Tony Tkacik -X (ttka=
cik - PANTHEON TECHNOLOGIES at Cisco); Peter Kajsa -X (pkajsa - PANTHEON TE=
CHNOLOGIES at Cisco); netmod@ietf.org=0A=
Predmet: Re: [netmod] one module imported with two different prefixes=0A=
=0A=
Ladislav Lhotka  wrote:=0A=
>=0A=
> > On 14 Jan 2016, at 10:28, Martin Bjorklund  wrote:=0A=
> >=0A=
> > "Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES at Cisco)"=0A=
> >  wrote:=0A=
> >> Dear all=0A=
> >>=0A=
> >> We've come across following set of import statements in YANG file:=0A=
> >>=0A=
> >> import  a {=0A=
> >>    prefix "a0";=0A=
> >> }=0A=
> >>=0A=
> >> import a {=0A=
> >>    prefix "a1";=0A=
> >> }=0A=
> >>=0A=
> >> So, there is one module imported with 2 different prefixes and used at=
=0A=
> >> various places.=0A=
> >>=0A=
> >> We're not sure if this is completely valid input for our YANG=0A=
> >> statement parser.=0A=
> >=0A=
> > There is no text in RFC 6020 (or 6020bis) that makes this invalid.=0A=
>=0A=
> Yes, and in fact it is possible to import different revisions of the=0A=
> same module this way.=0A=
=0A=
Not in YANG 1, but it is allowed in 1.1.=0A=
=0A=
RFC 6020 says:=0A=
=0A=
   Multiple revisions of the same module MUST NOT be imported.=0A=
=0A=
=0A=
/martin=0A=


From nobody Thu Jan 14 04:35:44 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDBF41B3404 for ; Thu, 14 Jan 2016 04:35:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.652
X-Spam-Level: 
X-Spam-Status: No, score=-5.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Evj4hasKqN7Q for ; Thu, 14 Jan 2016 04:35: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 71D391B3403 for ; Thu, 14 Jan 2016 04:35:39 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:cd15:5104:e5cd:7f78] (unknown [IPv6:2001:718:1a02:1:cd15:5104:e5cd:7f78]) by mail.nic.cz (Postfix) with ESMTPSA id BB3F4180EC2 for ; Thu, 14 Jan 2016 13:35:37 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452774937; bh=lJiIaDAsT+ACF6T7Iw0EVRP3O0vGWOzSebQP1yG4rzs=; h=From:Date:To; b=Rc16NFv7FIw1fdVhamNk5qLfKzZJjVA6hVHaqPGkbG/k5jUMpYCm7OG++4CWJAbym uNH+99Z/3irW1J5VaVhwKXMh7lYM7sRqNosKA3UqZ5OdAAW1CKAL/a1BVGiTjSuN1b mbn2NL1+A7yHD3abKzaIC2orxbZvfQFlzSQq9XOg=
From: Ladislav Lhotka 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <40ADE207-22A3-4E76-BAF0-E6F1B8A7984E@nic.cz>
Date: Thu, 14 Jan 2016 13:35:38 +0100
To: NETMOD WG 
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: [netmod] multi-instance-identifier
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jan 2016 12:35:42 -0000

Hi,

the module "ietf-netconf-acm" defines its own instance-identifier type =
(node-instance-identifier) in order to be able to refer to multiple =
instances in one rule. This has some drawbacks because generic tools =
cannot recognize it as an instance-identifier, so for example automatic =
translation between XML and JSON doesn't work properly.

So I wonder: is it really important that instance-identifier always =
point to a single node only?

A backward-compatible solution would be to introduce a new statement, =
e.g.

  multi-instance true;

and

  require-instance true;

would mean that at least one instance has to be present.

Lada

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





From nobody Thu Jan 14 09:35:02 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43D2B1A6F7D for ; Thu, 14 Jan 2016 09:35:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkuBF-HxeE5a for ; Thu, 14 Jan 2016 09:34:56 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0095.outbound.protection.outlook.com [104.47.2.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E9C11A6F7C for ; Thu, 14 Jan 2016 09:34:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KZNzocCHWnbPEqzJOuNuM3pbneeRWPcth4yj8bCxy2g=; b=ERTAoMQOEIGUPFG+lyICKzpPOLPdb11LUVocjfUzG7urxIdH/pMdDak/XNKvqgJ3wx9r2ymQYs05040A45bIpkhLwj+CjME/HEe1EynCbNQ1+yApW2AbTpNXlV/68qgZXUhuYhvkybF0n7EbhfkgaFuZxZN7Ti43G2c4CfNbyus=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (86.185.87.133) by DB3PR07MB058.eurprd07.prod.outlook.com (10.242.137.148) with Microsoft SMTP Server (TLS) id 15.1.361.13; Thu, 14 Jan 2016 17:34:51 +0000
Message-ID: <01d301d14ef1$814dcee0$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Juergen Schoenwaelder , Martin Bjorklund 
References: <20160111.101526.1720014765007751699.mbj@tail-f.com> <20160111092831.GA41568@elstar.local> <20160111.112143.1731089672764861015.mbj@tail-f.com> <20160111104855.GA41658@elstar.local>
Date: Thu, 14 Jan 2016 17:32:05 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [86.185.87.133]
X-ClientProxiedBy: AM3PR02CA0017.eurprd02.prod.outlook.com (10.242.240.17) To DB3PR07MB058.eurprd07.prod.outlook.com (10.242.137.148)
X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB058; 2:P1SSXF0WyBVDgecPZdnGbPfcYBXsauvdmqn9KmDSGIoJ3xUpilgoyqNm7ZTxxv3f5XAuJzfDdiU6JJlyGxAVDGchiHwRFy1XOOW4Q9jFp8AvLivbkP5BaVaQWLorWNYlCeRz1jIJdL/e6ytDRQOm+w==; 3:HEkeTPSEtQ2oqNnmsBvV7q8soDbYT7Ww7Bh0vXVFh9JVeUrKlePQm6EcZTJEgrDMwEzyaxJfbN8rlibtCMMpaBJnA9LrLANY7ihRwOqeWzBT3mdzDqMZleN4BcM/GCzx; 25:3UiD24uc158NepNGx2AujFbSiAqM/J1JpPqv/V74cO3Tmu7gggzs1DHfCMt4krUteE7EfNNB6FRzSLAD1ehoxJn7Inm2vNilXFNAOhg17Tw9J1KD4a/ooLGeAKN5EekWP/8ny4FNiK66axJG9tUoYSUW5N/gMYfWa56gLmWAmiM1Q0gJtedtDCIZiRhfZ01AMXzbavTEwCBMSAUA+3grFFzDSzjEy6S9XoQ6GdOcb7neAboVKxz4EoyjvWPjV0G3; 4:MD2DWV4kBjB7894BFbfY25Gvtwl+tN4g/qV+ldrsDsUIuC2oYFcPgMyQObmmzBSX2k/CkzY57jncGHSd8sagdIpGNJvpjOjrwHmjF7mHdcGZmeBqW2KpJ4jpnD/Lck1wIREvb1wcB4afpHvnDRRj+yt7CafV2B2DHo6Cm23LHKkAWyaovdTLdzzMjyBImOsR+iEYk1d9rWHeSz8V1NteDaCJ9ooL+pkJrl+ELXWHh/iJVAz7pR/j6PkOoiGGS63CTYkVDW5mLd5F6+vplVZjXr+2N5CBIxWg5dtFFWaiSDHtccYpILzjHOysGWwdwRPOwQbM0x2ZqDIDKN7mNYIlnmri7oVL8ehP06qE/bgoC/w8L8OzjRO1ALIF0H9ZG/h1
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB058;
X-MS-Office365-Filtering-Correlation-Id: 927c2c2c-9f28-4d8b-8df9-08d31d09026d
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001); SRVR:DB3PR07MB058; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB058; 
X-Forefront-PRVS: 08213D42D3
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(52034003)(199003)(377454003)(51444003)(189002)(61296003)(5001960100002)(50986999)(44736004)(230700001)(122386002)(84392002)(5008740100001)(86362001)(77096005)(1456003)(5001770100001)(189998001)(15975445007)(50226001)(81156007)(97736004)(87976001)(1556002)(81816999)(4326007)(47776003)(76176999)(5004730100002)(62236002)(42186005)(66066001)(44716002)(81686999)(40100003)(1096002)(3846002)(101416001)(92566002)(14496001)(23756003)(50466002)(93886004)(586003)(105586002)(19580395003)(2906002)(106356001)(116806002)(19580405001)(6116002)(33646002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB058; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DB3PR07MB058; 23:Xh5Ek96ACL4U5HH6WaR/fjeK45cfyTGqOkBSmyix?= =?iso-8859-1?Q?9uBhEFiyB9UrGYu6iMEx6rqL12Ah1fLovxcq99lpAr0Ec9xPLma6GE1KE7?= =?iso-8859-1?Q?97naL2/4/lCMHGtUeJ0e6rkEGwNRn17Qm4NmfezYmPpvtFdmxqIY8CbR/3?= =?iso-8859-1?Q?Jdaz2RxbqmTdW6Gl3hLpXcDgC1kGIxCU05Vs41b/kYttPemsq1WwN8s6C8?= =?iso-8859-1?Q?eDxNUmPVE+P+Uxbf/IxngxaHJI9TUdg37/9+H18Vs4CX1yzar8tXcsPn50?= =?iso-8859-1?Q?kKwE/1plTiMMkx+0mI/QQwkDZ3dIyANKgpJVUPxbheejw/4axQKNQJ7I6r?= =?iso-8859-1?Q?QLndbDVskfSQVr8skSZ4E5VU4COMxbFRbWTz8VUkayEgWbmBt2ci0adMYD?= =?iso-8859-1?Q?qMe73cC7oIwIoy9OBeebuiJdefqp17TSIGU57qbUjLdlEt/Owc01/L/aGQ?= =?iso-8859-1?Q?MfzEnvZx+BbkhTIrwDPwBiJLcCaFUo7ccUUZs0RIMCmVXKzJyLIPrE0KSU?= =?iso-8859-1?Q?/8q66mvVdZx7S8O+hRNAirYfndYPkC18EAgADZjj5ThEW8UXEYfSS0Q/oq?= =?iso-8859-1?Q?ay8984N7vrG8vGV05oGTdkSjb0vEt9mayf51G1Q76jkloRKUiW0gsyAd51?= =?iso-8859-1?Q?gBSF/JOu7H63B5zwBWw60eTmEOhhzTHH2+9LiUpuDxzzk70vwM3NAduABA?= =?iso-8859-1?Q?Ck3N98HtV4YwUezFhC702Z8ekiUvvyjcNMGYGFvDYLCU70XUBYg/aC4C28?= =?iso-8859-1?Q?wz252V2DihwW8Cl4P7JwIFKNEBPOVjJ97MR02o99X8gZJrjXpELjVSGOWm?= =?iso-8859-1?Q?KTScvqm1+bTGEpAvCrN246N6suIuTzECATTs+7zunZcXKgRXwOllHYhPTo?= =?iso-8859-1?Q?qG3jlFcaD8vuCAFfu+ac7gLrskGzZ92HmralMRr6mvOblHeJpmEJyYOfFu?= =?iso-8859-1?Q?v/qaTW3GRsEogrThkGd4II7jdhpt+YV/i92m0eKhZPEYZ4dp5RFyWIs4QY?= =?iso-8859-1?Q?QTC9jIa37fL9iMwf1fh74bdrVkIcW9HNlSldgn8un+K5RIeAvLIPjqBYSB?= =?iso-8859-1?Q?VVABc8wXlnMPOjGu7T3FJL15UxxIDpBKgqQViZ2EwB2yrhJoUX9wbq1Y7u?= =?iso-8859-1?Q?ocVWr6ibssM/SgqCaHHAiaDJLIwRHrFX+2r54K3Ukjpcx9LIVqaLZUSBnM?= =?iso-8859-1?Q?ktPlke2XsqzeSG9MpniSdc86+Y7gkBTbQE+Ucg5T6tafHZjrZK7vDu6ovV?= =?iso-8859-1?Q?L1zko6VEWSLEGIxmfvy3b2+QEwZhaFO/R9f8MInHNlnuC95tQOJ44AZTQj?= =?iso-8859-1?Q?IuUE1IZk6nHJY2mj9lFzbELsHEKIoIgt/8c485a6eniRTvm4UuDev941ck?= =?iso-8859-1?Q?B4ltNjo3qZSK6YFVUz/6x14kFWWyEC/TQhazOWQaSafKak5262BKOnKpzP?= =?iso-8859-1?Q?5O7Vh7hC3oj28Mepu0UiiEIDsdrVVn7zeKmWJ607HNoh9SWwiynOh8OQ?= =?iso-8859-1?Q?=3D=3D?=
X-Microsoft-Exchange-Diagnostics: 1; DB3PR07MB058; 5:yYrFx6sFUa5dL2mOvDoLUFKS3hoSqmxZEkqAhD8YWd6UT1i+QXbOO44u8fsFOgK7+flvO+vMddRNRt6AfrR+mqk8vh1R0qDwOhuNpRMTbkUfC9VtJ4wVAEsu6v3ovrlJubjfQ2tp3fijzdmWFNxJJg==; 24:060rRBpGlKYyUcEH7D6Rj93fKd3mkd4DX7IeBNnOXhNW8jVB8ji9/6PBvoXujAA7T+FL765ngsOnrnAlfQxRY56i9Q1l9efQPOaA913i1Uc=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jan 2016 17:34:51.8741 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB058
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] 6087bis namespace recommendations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jan 2016 17:35:00 -0000

----- Original Message -----
From: "Juergen Schoenwaelder" 
To: "Martin Bjorklund" 
Cc: 
Sent: Monday, January 11, 2016 10:48 AM

> On Mon, Jan 11, 2016 at 11:21:43AM +0100, Martin Bjorklund wrote:
> > Juergen Schoenwaelder  wrote:
> > > On Mon, Jan 11, 2016 at 10:15:26AM +0100, Martin Bjorklund wrote:


> > > >   2.  There was some discussion about recommending a different
URN
> > > >       prefix for unpublished modules (i.e., modules in Internet
> > > >       Drafts).
> > > >
> > > >       Should 6087bis recommend some special urn prefix for
drafts,
> > > >       with a note to the RFC editor to change the namespace once
it
> > > >       has been registered with IANA?
> > >
> > > Do we have evidence that having such a rule makes the Internet
work
> > > better?
> >
> > I don't know, but apparently there can be confusion when an
extracted
> > module from a draft is passed around.
> >
> > What can we learn from the SNMP experience where the OID assignement
> > is done by IANA - good or bad?
>
> With MIB modules, the module OID is assigned by IANA and we usually
> have a placeholder (which makes the module not compile). With SNMP, we
> converged to register the majority of modules below mib-2 and hence if
> people pick numbers, they have a high potential for collision. With
> NETCONF namespaces, the collision probability is rather low. The other
> aspect is that an official assignment happens late during the process,
> e.g., as part of the RFC publication process and there might be early
> implementations that use a 'speculative' namespace value. In a perfect
> world, we should likely use a different prefix while the module is
> under development and then let IANA have the final say on the official
> prefix. And if Lada is really concerned about problems caused if I-D
> implementations, we could do lets say a series of
>
>   urn:ietf:params:xml:ns:yang:draft-ietf-netmod-routing-cfg-00
>   ...
>   urn:ietf:params:xml:ns:yang:draft-ietf-netmod-routing-cfg-20
>
> in I-Ds and then the RFC editor finally changes things to
>
>   urn:ietf:params:xml:ns:yang:ietf-routing
>
> if IANA agrees to allocate this URN to the module. Of course, this
> means more work for the editors involved and so far our lax handling
> of this issue seems to have worked. (But so it did for MIB modules
> until problems started to show up.)

I think that, as has already been said, the much larger namespace for
urn compared to mib-2 makes collisions less likely.

I have seen collisions in SMI and they were costly to fix, one
manufacturer or the other had to agree to back off and rework their
product.

What SMI did get superbly right was setting up a branch of the tree
(.private.enterprises.), for organisations that wanted to get involved,
to register for a number, FCFS (and a process that did not involve the
costs of the IEEE equivalent:-) under which they could create their own
modules.  On a typical network box, the amount of data under that branch
would exceed, sometimes by an order of magnitude, the amount of data
under mib-2.

Originally, the intention with SMI was that development would take place
under a different branch and be converted to the allocated number at the
end, but making changes when everything was tested and working was not
too popular so that fell by the wayside.

Finally, the fashion with YANG seems to be to carve up a piece of work
into a number of (sub)modules, so there are a number of related names
which again may reflect the convenience of developers rather than
users; and the relationship may or may not be apparent from the chosen
names.   We could offer guidance here

Tom Petch

> /js
>
> PS: Note that JSON encoding uses the module name and not the namespace
>     and hence even if we do the above, module names in JSON won't
>     signal the difference between I-D and published RFC versions of a
>     module. So to be really fool proof one would have to change the
>     module name also with every posted I-D. The question is at which
>     point in time bureaucracy hampers productivity and perhaps what we
>     do today is not perfect but a reasonable trade-off.
>
> PS: Another option could be a YANG keyword that declares the status of
>     a module, 'draft', 'published', 'experimental', 'example',
>     'obsolete' and then the RFC editor would only have to toggle this
>     value and tools could still distinguish the different kinds of
>     YANG modules.
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Thu Jan 14 09:54:52 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689511A6FDC for ; Thu, 14 Jan 2016 09:54:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.678
X-Spam-Level: 
X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4QXMI_Y6fza for ; Thu, 14 Jan 2016 09:54:47 -0800 (PST)
Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (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 8807D1A6FCA for ; Thu, 14 Jan 2016 09:54:45 -0800 (PST)
Received: by mail-lf0-x22b.google.com with SMTP id m198so120452117lfm.0 for ; Thu, 14 Jan 2016 09:54: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:date:message-id:subject:from:to :cc:content-type; bh=3E9e5VLNWa/xDN0KAbb68h3jKsCbHaNfv06DfmROzCg=; b=I/+CqilAubpyrQODb4TItG1kob+emmTMDDmUoUtPzy2dHE9hefXt4wdMQsSGuzDQNk RM79Wxa8YHm6r65Bjyp8wIAbgTYUlWxPLRGLYs8sKVZyXCuKjOtUcuVxn775pkgFwDuR Nxuv+D6jQ/ZdLloQv5AiHwH3yIDxW1UM0115eK9vUC7Nk1fzG/rV6o1O0UTAheTMexFa wneldS+vmS1IPBTo118JXdHYlqTi/2t1zQVxPcjYv9kajvL96W3ehmPHu0lvoFwTYSDq QdmR1pIxXUFEAIny1njD5kpS19NA+2RJw7w5BeTmtFJQtpNXZ3fwF1WO+KOOR/dQQxPB tU+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3E9e5VLNWa/xDN0KAbb68h3jKsCbHaNfv06DfmROzCg=; b=mKD+OvKPJ+379LAUB8SBAtmWgWU15uwtrmn1F7z56TsVx8IjvzZZklRoKenPYUKUBb 5TL3w2ErTIt7BZ6ZwuVs4I+YgNohqURnMAIExWpVAy1Rh+cp2Npq9lNjIB60D6eIfzcf nlOxYp480sgD77eGjnZqNwB0FFZBptzw7FYWjF8fu73xeryNEftmDE9DqUCDJCc8QNHG NeRkpCDdZeHk1Vr6yI5vhXJYU+6Z70Xi2NqiMj/8nqBO0K6+l2l1mSgg2VzRGVPjZCWA BcC66PwkWfZoLqOptYQ9jt9q4KTURfgdohYsgEJzRyCnjxKRIs5zqxIntYqhzIClrPWB b53A==
X-Gm-Message-State: ALoCoQlb1saTrre82K5rnV8Dpan8trHtZsfLLawhYz+/XnT2sGVlLXXc08YCnmaRxtDWVPLkwacuIiT9QPuZOlsBWDtbYBTLqg==
MIME-Version: 1.0
X-Received: by 10.25.85.20 with SMTP id j20mr1404101lfb.131.1452794083690; Thu, 14 Jan 2016 09:54:43 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Thu, 14 Jan 2016 09:54:43 -0800 (PST)
In-Reply-To: <01d301d14ef1$814dcee0$4001a8c0@gateway.2wire.net>
References: <20160111.101526.1720014765007751699.mbj@tail-f.com> <20160111092831.GA41568@elstar.local> <20160111.112143.1731089672764861015.mbj@tail-f.com> <20160111104855.GA41658@elstar.local> <01d301d14ef1$814dcee0$4001a8c0@gateway.2wire.net>
Date: Thu, 14 Jan 2016 09:54:43 -0800
Message-ID: 
From: Andy Bierman 
To: "t.petch" 
Content-Type: multipart/alternative; boundary=001a1141c5324a66fd05294efb56
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] 6087bis namespace recommendations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Jan 2016 17:54:50 -0000

--001a1141c5324a66fd05294efb56
Content-Type: text/plain; charset=UTF-8

On Thu, Jan 14, 2016 at 9:32 AM, t.petch  wrote:

> ----- Original Message -----
> From: "Juergen Schoenwaelder" 
> To: "Martin Bjorklund" 
> Cc: 
> Sent: Monday, January 11, 2016 10:48 AM
>
> > On Mon, Jan 11, 2016 at 11:21:43AM +0100, Martin Bjorklund wrote:
> > > Juergen Schoenwaelder  wrote:
> > > > On Mon, Jan 11, 2016 at 10:15:26AM +0100, Martin Bjorklund wrote:
>
> 
> > > > >   2.  There was some discussion about recommending a different
> URN
> > > > >       prefix for unpublished modules (i.e., modules in Internet
> > > > >       Drafts).
> > > > >
> > > > >       Should 6087bis recommend some special urn prefix for
> drafts,
> > > > >       with a note to the RFC editor to change the namespace once
> it
> > > > >       has been registered with IANA?
> > > >
> > > > Do we have evidence that having such a rule makes the Internet
> work
> > > > better?
> > >
> > > I don't know, but apparently there can be confusion when an
> extracted
> > > module from a draft is passed around.
> > >
> > > What can we learn from the SNMP experience where the OID assignement
> > > is done by IANA - good or bad?
> >
> > With MIB modules, the module OID is assigned by IANA and we usually
> > have a placeholder (which makes the module not compile). With SNMP, we
> > converged to register the majority of modules below mib-2 and hence if
> > people pick numbers, they have a high potential for collision. With
> > NETCONF namespaces, the collision probability is rather low. The other
> > aspect is that an official assignment happens late during the process,
> > e.g., as part of the RFC publication process and there might be early
> > implementations that use a 'speculative' namespace value. In a perfect
> > world, we should likely use a different prefix while the module is
> > under development and then let IANA have the final say on the official
> > prefix. And if Lada is really concerned about problems caused if I-D
> > implementations, we could do lets say a series of
> >
> >   urn:ietf:params:xml:ns:yang:draft-ietf-netmod-routing-cfg-00
> >   ...
> >   urn:ietf:params:xml:ns:yang:draft-ietf-netmod-routing-cfg-20
> >
> > in I-Ds and then the RFC editor finally changes things to
> >
> >   urn:ietf:params:xml:ns:yang:ietf-routing
> >
> > if IANA agrees to allocate this URN to the module. Of course, this
> > means more work for the editors involved and so far our lax handling
> > of this issue seems to have worked. (But so it did for MIB modules
> > until problems started to show up.)
>
> I think that, as has already been said, the much larger namespace for
> urn compared to mib-2 makes collisions less likely.
>
> I have seen collisions in SMI and they were costly to fix, one
> manufacturer or the other had to agree to back off and rework their
> product.
>
> What SMI did get superbly right was setting up a branch of the tree
> (.private.enterprises.), for organisations that wanted to get involved,
> to register for a number, FCFS (and a process that did not involve the
> costs of the IEEE equivalent:-) under which they could create their own
> modules.  On a typical network box, the amount of data under that branch
> would exceed, sometimes by an order of magnitude, the amount of data
> under mib-2.
>
> Originally, the intention with SMI was that development would take place
> under a different branch and be converted to the allocated number at the
> end, but making changes when everything was tested and working was not
> too popular so that fell by the wayside.
>
> Finally, the fashion with YANG seems to be to carve up a piece of work
> into a number of (sub)modules, so there are a number of related names
> which again may reflect the convenience of developers rather than
> users; and the relationship may or may not be apparent from the chosen
> names.   We could offer guidance here
>
>
I like the idea of adding DRAFT to the end of the namespace identifier
I would prefer not to put revision identifiers in the namespace.

Internet-Draft publication:

    urn:ietf:params:xml:ns:yang:ietf-routing:DRAFT

RFC publication

    urn:ietf:params:xml:ns:yang:ietf-routing




I never liked the SMIv2 practice of putting XXX in the MIB module.
It means that no MIB module extracted from an I-D can be compiled without
editing it. There was never any guidance offered (over 25 years) what number
somebody should pick when changing XXX so the module will compile.
This is what led to all the problems.




Tom Petch
>
>
Andy


> > /js
> >
> > PS: Note that JSON encoding uses the module name and not the namespace
> >     and hence even if we do the above, module names in JSON won't
> >     signal the difference between I-D and published RFC versions of a
> >     module. So to be really fool proof one would have to change the
> >     module name also with every posted I-D. The question is at which
> >     point in time bureaucracy hampers productivity and perhaps what we
> >     do today is not perfect but a reasonable trade-off.
> >
> > PS: Another option could be a YANG keyword that declares the status of
> >     a module, 'draft', 'published', 'experimental', 'example',
> >     'obsolete' and then the RFC editor would only have to toggle this
> >     value and tools could still distinguish the different kinds of
> >     YANG modules.
> >
> > --
> > 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
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

--001a1141c5324a66fd05294efb56
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, Jan 14, 2016 at 9:32 AM, t.petch <ietfc@btconnect.com&g=
t; wrote:
----- Original Message -----

From: "Juergen Schoenwaelder" <j.schoenwaelder@jacobs-university.de>

To: "Martin Bjorklund" <mbj@=
tail-f.com>

Cc: <netmod@ietf.org>

Sent: Monday, January 11, 2016 10:48 AM



> On Mon, Jan 11, 2016 at 11:21:43AM +0100, Martin Bjorklund wrote:

> > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

> > > On Mon, Jan 11, 2016 at 10:15:26AM +0100, Martin Bjorklund w=
rote:



<snip>

> > > >=C2=A0 =C2=A02.=C2=A0 There was some discussion about re=
commending a different

URN

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0prefix for unpublished module=
s (i.e., modules in Internet

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Drafts).

> > > >

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Should 6087bis recommend some=
 special urn prefix for

drafts,

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0with a note to the RFC editor=
 to change the namespace once

it

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0has been registered with IANA=
?

> > >

> > > Do we have evidence that having such a rule makes the Intern=
et

work

> > > better?

> >

> > I don't know, but apparently there can be confusion when an
extracted

> > module from a draft is passed around.

> >

> > What can we learn from the SNMP experience where the OID assignem=
ent

> > is done by IANA - good or bad?

>

> With MIB modules, the module OID is assigned by IANA and we usually
> have a placeholder (which makes the module not compile). With SNMP, we=


> converged to register the majority of modules below mib-2 and hence if=


> people pick numbers, they have a high potential for collision. With
> NETCONF namespaces, the collision probability is rather low. The other=


> aspect is that an official assignment happens late during the process,=


> e.g., as part of the RFC publication process and there might be early<=
br>
> implementations that use a 'speculative' namespace value. In a=
 perfect

> world, we should likely use a different prefix while the module is

> under development and then let IANA have the final say on the official=


> prefix. And if Lada is really concerned about problems caused if I-D
> implementations, we could do lets say a series of

>

>=C2=A0 =C2=A0urn:ietf:params:xml:ns:yang:draft-ietf-netmod-routing-cfg-=
00

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

>=C2=A0 =C2=A0urn:ietf:params:xml:ns:yang:draft-ietf-netmod-routing-cfg-=
20

>

> in I-Ds and then the RFC editor finally changes things to

>

>=C2=A0 =C2=A0urn:ietf:params:xml:ns:yang:ietf-routing

>

> if IANA agrees to allocate this URN to the module. Of course, this

> means more work for the editors involved and so far our lax handling
> of this issue seems to have worked. (But so it did for MIB modules

> until problems started to show up.)



I think that, as has already been said, the much larger namespace for

urn compared to mib-2 makes collisions less likely.



I have seen collisions in SMI and they were costly to fix, one

manufacturer or the other had to agree to back off and rework their

product.



What SMI did get superbly right was setting up a branch of the tree

(.private.enterprises.), for organisations that wanted to get involved,

to register for a number, FCFS (and a process that did not involve the

costs of the IEEE equivalent:-) under which they could create their own

modules.=C2=A0 On a typical network box, the amount of data under that bran=
ch

would exceed, sometimes by an order of magnitude, the amount of data

under mib-2.



Originally, the intention with SMI was that development would take place
under a different branch and be converted to the allocated number at the
end, but making changes when everything was tested and working was not

too popular so that fell by the wayside.



Finally, the fashion with YANG seems to be to carve up a piece of work

into a number of (sub)modules, so there are a number of related names

which again may reflect the convenience of developers rather than

users; and the relationship may or may not be apparent from the chosen

names.=C2=A0 =C2=A0We could offer guidance here



I like the idea of adding DRAFT to the=
 end of the namespace identifier
I would prefer not to put revisi=
on identifiers in the namespace.

Internet-Draf=
t publication:

=C2=A0 =C2=A0 urn:ietf:params:xml:n=
s:yang:ietf-routing:DRAFT

RFC publication

=C2=A0 =C2=A0 urn:ietf:params:xml:ns:yang:ietf-routing=





=
I never liked the SMIv2 practice of putting XXX in the MIB module.
It means that no MIB module extracted from an I-D can be compiled without=

editing it. There was never any guidance offered (over 25 years)=
 what number
somebody should pick when changing XXX so the module=
 will compile.
This is what led to all the problems.




Tom Petch



Andy
=C2=A0

> /js

>

> PS: Note that JSON encoding uses the module name and not the namespace=


>=C2=A0 =C2=A0 =C2=A0and hence even if we do the above, module names in =
JSON won't

>=C2=A0 =C2=A0 =C2=A0signal the difference between I-D and published RFC=
 versions of a

>=C2=A0 =C2=A0 =C2=A0module. So to be really fool proof one would have t=
o change the

>=C2=A0 =C2=A0 =C2=A0module name also with every posted I-D. The questio=
n is at which

>=C2=A0 =C2=A0 =C2=A0point in time bureaucracy hampers productivity and =
perhaps what we

>=C2=A0 =C2=A0 =C2=A0do today is not perfect but a reasonable trade-off.=


>

> PS: Another option could be a YANG keyword that declares the status of=


>=C2=A0 =C2=A0 =C2=A0a module, 'draft', 'published', =
9;experimental', 'example',

>=C2=A0 =C2=A0 =C2=A0'obsolete' and then the RFC editor would on=
ly have to toggle this

>=C2=A0 =C2=A0 =C2=A0value and tools could still distinguish the differe=
nt kinds of

>=C2=A0 =C2=A0 =C2=A0YANG modules.

>

> --

> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs U=
niversity Bremen gGmbH

> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1=
 | 28759 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


_______________________________________________

netmod mailing list

netmod@ietf.org

https://www.ietf.org/mailman/listinfo/netmod





--001a1141c5324a66fd05294efb56--


From nobody Thu Jan 14 22:48:51 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A57B81B2A27 for ; Thu, 14 Jan 2016 22:48:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wy5P2bX_J6YO for ; Thu, 14 Jan 2016 22:48:47 -0800 (PST)
Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::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 043D71B2A29 for ; Thu, 14 Jan 2016 22:48:36 -0800 (PST)
Received: by mail-ig0-x233.google.com with SMTP id z14so5528215igp.1 for ; Thu, 14 Jan 2016 22:48:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tXzvQmeVd+KLmaFM/HhNdCiDkv+XEPvPaud9W1uoSh8=; b=KPUU123HBdVNA7DRCYFFtTqs9Fv0ckdAY34nC4DtAZP2EvhbhR5/ksmHFKZQACJil5 110wmGqtOi/v1os6b6qZiy290uBsCcqL5y/hf2gjs8iY14fdyvJcTecnVxaTGPbzYUGS H63hX0OEdDhnw36Imhun/a4O3k4FGtGHaXCKeZ5CaxHGi06KRE1dPlNxVKResEM2PPRv RKix+gxENorP3uKWdqfnUcxtyFTQ+WJwFm010kK6er2qXCjSP6fqy6Xrp8KA5YX3NXhB hbsk/1nmedMsfWYP9ewmj+uIz6roBYhi9KPPSOUfMG1BGSg+Oow5db4waXOBXa4NTSid kQ/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tXzvQmeVd+KLmaFM/HhNdCiDkv+XEPvPaud9W1uoSh8=; b=PuI3zXy9FMuMBfvP4WtCkNfzew+iYgoa3y9t75YfCHt6quBca8pBROEBiHSH55Ggbn nRddLADRjPhdJN45jvGvx4Lv6RR6CDMFc9MU4RH45Ns4AeC7j4z7BhK1lERTlagAzeIe R4+lA5T61Q+ZwNBu/mhMRQgCQqK7Cxw6Ih7tYEB/t2vZ9UOIG5gejsLK8rgwhcd69ics Vt+J4kuSHosP4ubPgc+LwiBiTPKAG9Sjro5G2G0v0T7N7Nda36C2cvvcFmfSnIoLgfXP ao2eX1ZP843777UR2PsM88jWD/gTAzwaB1XgR0QFQoWyZCKoc0LmX4vXDZn1p7+ksD83 C7aA==
X-Gm-Message-State: AG10YOScEq31muHd5mE6YIDEGR5ybsR9nspiqiUTSSIDDsM2fk/wcm3W8bsHEyltfDqD6CL465byADVcohphFAMC
MIME-Version: 1.0
X-Received: by 10.50.43.228 with SMTP id z4mr1644399igl.43.1452840515293; Thu, 14 Jan 2016 22:48:35 -0800 (PST)
Received: by 10.36.38.133 with HTTP; Thu, 14 Jan 2016 22:48:35 -0800 (PST)
In-Reply-To: <20160114.101906.688806090391415335.mbj@tail-f.com>
References: <20160114.101906.688806090391415335.mbj@tail-f.com>
Date: Thu, 14 Jan 2016 22:48:35 -0800
Message-ID: 
From: Anees Shaikh 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=089e01227e84d4b761052959ca28
Archived-At: 
Cc: NETMOD Working Group 
Subject: Re: [netmod] openconfig clarification on applied config
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2016 06:48:48 -0000

--089e01227e84d4b761052959ca28
Content-Type: text/plain; charset=UTF-8

Hi Martin, thanks for your note -- please see my comments inline.  I'm not
sure they will help given the recent netmod threads on this topic, however.
 :-)


>
> First, re. pre-configuration.
>



>
> What is the correct answer?
>

The expectation here, as described in the last version of the draft, is
that the pre-configuration would only appear as intended configuration, not
applied, since the system cannot apply the configuration until the
corresponding linecard is plugged in, for example.   The NMS could
determine the state using oper-status as you referenced.


>
> -------------------------
>
> Here's another situation.   Suppose I configure some daemon to listen
> to a port that happens to be used on the system (let's say I picked
> 32768, and it was assigned by the kernel to some process listening to
> 0 just microseconds before my daemon tried to use it).  It is clear
> that intended would contain port 32768, and it is clear that the
> derived state would show that some other processes uses this port, but
> what would end up in applied?  Specifically, if your answer is that
> applied != intended in this case, what exactly would be different?
> Just the port, or also the rest of the daemon's config?
>

this is an interesting example ... what we have discussed is that if the
system sets some configuration, that should be reflected in the applied
config (i.e., as part of operational state).

In this case, it might be that the system rejects the configuration because
it can't honor it (as you said, derived state could be used to see that
another process is using that port).   If the system chooses another port
for the daemon, then the applied config could reflect that.

Regarding other parts of the daemon's config, I'd expect only the port to
be different between intended and applied, unless the system rejects the
entire configuration due to the port collision (seems unlikely).   This is
probably dependent on the implementation -- the NMS could at least learn
this by seeing that the applied config is not set for the other
configuration values.

thanks.
-- Anees


>
> /martin
>

--089e01227e84d4b761052959ca28
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Martin, thanks for your note -- please see my comments =
inline.=C2=A0 I'm not sure they will help given the recent netmod threa=
ds on this topic, however. =C2=A0:-)





First, re. pre-configuration.

<snip&=
gt;=C2=A0



What is the correct answer?

The expecta=
tion here, as described in the last version of the draft, is that the pre-c=
onfiguration would only appear as intended configuration, not applied, sinc=
e the system cannot apply the configuration until the corresponding linecar=
d is plugged in, for example. =C2=A0 The NMS could determine the state usin=
g oper-status as you referenced. =C2=A0=C2=A0
=C2=A0



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



Here's another situation.=C2=A0 =C2=A0Suppose I configure some daemon t=
o listen

to a port that happens to be used on the system (let's say I picked

32768, and it was assigned by the kernel to some process listening to

0 just microseconds before my daemon tried to use it).=C2=A0 It is clear
that intended would contain port 32768, and it is clear that the

derived state would show that some other processes uses this port, but

what would end up in applied?=C2=A0 Specifically, if your answer is that
applied !=3D intended in this case, what exactly would be different?

Just the port, or also the rest of the daemon's config?

this is an interesting example ... what we have discus=
sed is that if the system sets some configuration, that should be reflected=
 in the applied config (i.e., as part of operational state).=C2=A0

In this case, it might be that the system rejects the conf=
iguration because it can't honor it (as you said, derived state could b=
e used to see that another process is using that port). =C2=A0 If the syste=
m chooses another port for the daemon, then the applied config could reflec=
t that.

Regarding other parts of the daemon's =
config, I'd expect only the port to be different between intended and a=
pplied, unless the system rejects the entire configuration due to the port =
collision (seems unlikely). =C2=A0 This is probably dependent on the implem=
entation -- the NMS could at least learn this by seeing that the applied co=
nfig is not set for the other configuration values.

thanks.
-- Anees






/martin





--089e01227e84d4b761052959ca28--


From nobody Fri Jan 15 00:59:23 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6A11A8A79 for ; Fri, 15 Jan 2016 00:59:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scaZ6pH4Y9bi for ; Fri, 15 Jan 2016 00:59:20 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A7B191A8A71 for ; Fri, 15 Jan 2016 00:59:20 -0800 (PST)
Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id 5B2271AE03B5; Fri, 15 Jan 2016 09:59:19 +0100 (CET)
Date: Fri, 15 Jan 2016 09:59:21 +0100 (CET)
Message-Id: <20160115.095921.1993691828725957272.mbj@tail-f.com>
To: aashaikh@google.com
From: Martin Bjorklund 
In-Reply-To: 
References: <20160114.101906.688806090391415335.mbj@tail-f.com> 
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] openconfig clarification on applied config
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2016 08:59:22 -0000

Hi Anees,

Anees Shaikh  wrote:
> Hi Martin, thanks for your note -- please see my comments inline.  I'm not
> sure they will help given the recent netmod threads on this topic, however.
>  :-)

Thank you for you reply, I think it helps to clarify some of the
confusion that I see when reading these threads on the ML.

> > First, re. pre-configuration.
> >
> 
> 
> 
> >
> > What is the correct answer?
> >
> 
> The expectation here, as described in the last version of the draft, is
> that the pre-configuration would only appear as intended configuration, not
> applied, since the system cannot apply the configuration until the
> corresponding linecard is plugged in, for example.   The NMS could
> determine the state using oper-status as you referenced.

Ok, thanks.  This is a clear statement.

> > -------------------------
> >
> > Here's another situation.   Suppose I configure some daemon to listen
> > to a port that happens to be used on the system (let's say I picked
> > 32768, and it was assigned by the kernel to some process listening to
> > 0 just microseconds before my daemon tried to use it).  It is clear
> > that intended would contain port 32768, and it is clear that the
> > derived state would show that some other processes uses this port, but
> > what would end up in applied?  Specifically, if your answer is that
> > applied != intended in this case, what exactly would be different?
> > Just the port, or also the rest of the daemon's config?
> >
> 
> this is an interesting example ... what we have discussed is that if the
> system sets some configuration, that should be reflected in the applied
> config (i.e., as part of operational state).
> 
> In this case, it might be that the system rejects the configuration because
> it can't honor it (as you said, derived state could be used to see that
> another process is using that port).

Sure.  But the interesting scenario is that the config is accepted,
and then when the daemon tries to use it, it fails.  Another
situation where this can happen is after a restart.

> If the system chooses another port
> for the daemon, then the applied config could reflect that.

Hmm.  If I configure a specific port, I wouldn't expect the system to
select another port.  However if I specified "0" (use any free port),
I would expect "0" to be reflected in applied, but the real port to be
reflected in derived state, similar to the example of duplex "auto".
Do you agree?

> Regarding other parts of the daemon's config, I'd expect only the port to
> be different between intended and applied, unless the system rejects the
> entire configuration due to the port collision (seems unlikely).   This is
> probably dependent on the implementation -- the NMS could at least learn
> this by seeing that the applied config is not set for the other
> configuration values.

Ok, makes sense!


/martin


From nobody Fri Jan 15 03:39:21 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9BD1B2B78 for ; Fri, 15 Jan 2016 03:39:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYYJkR6eh8jC for ; Fri, 15 Jan 2016 03:39:18 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 641DA1B2B77 for ; Fri, 15 Jan 2016 03:39:17 -0800 (PST)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 065D21CC0147; Fri, 15 Jan 2016 12:39:20 +0100 (CET)
From: Ladislav Lhotka 
To: Andy Bierman , "t.petch" 
In-Reply-To: 
References: <20160111.101526.1720014765007751699.mbj@tail-f.com> <20160111092831.GA41568@elstar.local> <20160111.112143.1731089672764861015.mbj@tail-f.com> <20160111104855.GA41658@elstar.local> <01d301d14ef1$814dcee0$4001a8c0@gateway.2wire.net> 
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Fri, 15 Jan 2016 12:39:16 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] 6087bis namespace recommendations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2016 11:39:21 -0000

Andy Bierman  writes:

> On Thu, Jan 14, 2016 at 9:32 AM, t.petch  wrote:
>
>> ----- Original Message -----
>> From: "Juergen Schoenwaelder" 
>> To: "Martin Bjorklund" 
>> Cc: 
>> Sent: Monday, January 11, 2016 10:48 AM
>>
>> > On Mon, Jan 11, 2016 at 11:21:43AM +0100, Martin Bjorklund wrote:
>> > > Juergen Schoenwaelder  wrote:
>> > > > On Mon, Jan 11, 2016 at 10:15:26AM +0100, Martin Bjorklund wrote:
>>
>> 
>> > > > >   2.  There was some discussion about recommending a different
>> URN
>> > > > >       prefix for unpublished modules (i.e., modules in Internet
>> > > > >       Drafts).
>> > > > >
>> > > > >       Should 6087bis recommend some special urn prefix for
>> drafts,
>> > > > >       with a note to the RFC editor to change the namespace once
>> it
>> > > > >       has been registered with IANA?
>> > > >
>> > > > Do we have evidence that having such a rule makes the Internet
>> work
>> > > > better?
>> > >
>> > > I don't know, but apparently there can be confusion when an
>> extracted
>> > > module from a draft is passed around.
>> > >
>> > > What can we learn from the SNMP experience where the OID assignement
>> > > is done by IANA - good or bad?
>> >
>> > With MIB modules, the module OID is assigned by IANA and we usually
>> > have a placeholder (which makes the module not compile). With SNMP, we
>> > converged to register the majority of modules below mib-2 and hence if
>> > people pick numbers, they have a high potential for collision. With
>> > NETCONF namespaces, the collision probability is rather low. The other
>> > aspect is that an official assignment happens late during the process,
>> > e.g., as part of the RFC publication process and there might be early
>> > implementations that use a 'speculative' namespace value. In a perfect
>> > world, we should likely use a different prefix while the module is
>> > under development and then let IANA have the final say on the official
>> > prefix. And if Lada is really concerned about problems caused if I-D
>> > implementations, we could do lets say a series of
>> >
>> >   urn:ietf:params:xml:ns:yang:draft-ietf-netmod-routing-cfg-00
>> >   ...
>> >   urn:ietf:params:xml:ns:yang:draft-ietf-netmod-routing-cfg-20
>> >
>> > in I-Ds and then the RFC editor finally changes things to
>> >
>> >   urn:ietf:params:xml:ns:yang:ietf-routing
>> >
>> > if IANA agrees to allocate this URN to the module. Of course, this
>> > means more work for the editors involved and so far our lax handling
>> > of this issue seems to have worked. (But so it did for MIB modules
>> > until problems started to show up.)
>>
>> I think that, as has already been said, the much larger namespace for
>> urn compared to mib-2 makes collisions less likely.
>>
>> I have seen collisions in SMI and they were costly to fix, one
>> manufacturer or the other had to agree to back off and rework their
>> product.
>>
>> What SMI did get superbly right was setting up a branch of the tree
>> (.private.enterprises.), for organisations that wanted to get involved,
>> to register for a number, FCFS (and a process that did not involve the
>> costs of the IEEE equivalent:-) under which they could create their own
>> modules.  On a typical network box, the amount of data under that branch
>> would exceed, sometimes by an order of magnitude, the amount of data
>> under mib-2.
>>
>> Originally, the intention with SMI was that development would take place
>> under a different branch and be converted to the allocated number at the
>> end, but making changes when everything was tested and working was not
>> too popular so that fell by the wayside.
>>
>> Finally, the fashion with YANG seems to be to carve up a piece of work
>> into a number of (sub)modules, so there are a number of related names
>> which again may reflect the convenience of developers rather than
>> users; and the relationship may or may not be apparent from the chosen
>> names.   We could offer guidance here
>>
>>
> I like the idea of adding DRAFT to the end of the namespace identifier
> I would prefer not to put revision identifiers in the namespace.
>
> Internet-Draft publication:
>
>     urn:ietf:params:xml:ns:yang:ietf-routing:DRAFT
>
> RFC publication
>
>     urn:ietf:params:xml:ns:yang:ietf-routing
>

Does this solve any practical problem? Modules are imported based on
the module name and revision. On the other hand, it does create new problems:
namespace URIs and their mappings to prefixes may be spread in many
places in the code, and these would have to be manually edited after an
I-D -> RFC transition.

It would IMO be much better to use revision numbers rather than dates,
and adopt a convention, e.g., that modules in the I-D stage have
revisions 0.x that get bumped with each new revision of the I-D.

Lada

>
>
>
> I never liked the SMIv2 practice of putting XXX in the MIB module.
> It means that no MIB module extracted from an I-D can be compiled without
> editing it. There was never any guidance offered (over 25 years) what number
> somebody should pick when changing XXX so the module will compile.
> This is what led to all the problems.
>
>
>
>
> Tom Petch
>>
>>
> Andy
>
>
>> > /js
>> >
>> > PS: Note that JSON encoding uses the module name and not the namespace
>> >     and hence even if we do the above, module names in JSON won't
>> >     signal the difference between I-D and published RFC versions of a
>> >     module. So to be really fool proof one would have to change the
>> >     module name also with every posted I-D. The question is at which
>> >     point in time bureaucracy hampers productivity and perhaps what we
>> >     do today is not perfect but a reasonable trade-off.
>> >
>> > PS: Another option could be a YANG keyword that declares the status of
>> >     a module, 'draft', 'published', 'experimental', 'example',
>> >     'obsolete' and then the RFC editor would only have to toggle this
>> >     value and tools could still distinguish the different kinds of
>> >     YANG modules.
>> >
>> > --
>> > 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
>>
>> _______________________________________________
>> 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: E74E8C0C


From nobody Fri Jan 15 03:49:35 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11E61B2B99 for ; Fri, 15 Jan 2016 03:49:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-xiwDSGrHpL for ; Fri, 15 Jan 2016 03:49:31 -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 AE5081B2B98 for ; Fri, 15 Jan 2016 03:49:31 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D7B0D75D; Fri, 15 Jan 2016 12:49:29 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id f8gG2i0tYnAl; Fri, 15 Jan 2016 12:49:29 +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, 15 Jan 2016 12:49:29 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 215F72002B; Fri, 15 Jan 2016 12:49:29 +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 r59g3M98Q50f; Fri, 15 Jan 2016 12:49:28 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B210320013; Fri, 15 Jan 2016 12:49:26 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 338DB3984922; Fri, 15 Jan 2016 12:49:25 +0100 (CET)
Date: Fri, 15 Jan 2016 12:49:24 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20160115114924.GA12322@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "t. petch" , "netmod@ietf.org" 
References: <20160111.101526.1720014765007751699.mbj@tail-f.com> <20160111092831.GA41568@elstar.local> <20160111.112143.1731089672764861015.mbj@tail-f.com> <20160111104855.GA41658@elstar.local> <01d301d14ef1$814dcee0$4001a8c0@gateway.2wire.net>  
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] 6087bis namespace recommendations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2016 11:49:34 -0000

On Fri, Jan 15, 2016 at 12:39:16PM +0100, Ladislav Lhotka wrote:
> 
> Does this solve any practical problem? Modules are imported based on
> the module name and revision. On the other hand, it does create new problems:
> namespace URIs and their mappings to prefixes may be spread in many
> places in the code, and these would have to be manually edited after an
> I-D -> RFC transition.
> 
> It would IMO be much better to use revision numbers rather than dates,
> and adopt a convention, e.g., that modules in the I-D stage have
> revisions 0.x that get bumped with each new revision of the I-D.
>

Lada, this is not how our current YANG 1.0 versioning and revision
rules work and we are not going to change them in YANG 1.1 either.
The rules we have do make a distinction between published modules and
modules that are unpublished.

/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 15 03:55:38 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1EE61B2BA6 for ; Fri, 15 Jan 2016 03:55:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.352
X-Spam-Level: 
X-Spam-Status: No, score=-5.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tIt4tdOe9Db for ; Fri, 15 Jan 2016 03:55:35 -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 C2B2D1B2BA5 for ; Fri, 15 Jan 2016 03:55:34 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:48b6:50f4:321c:592d] (unknown [IPv6:2001:718:1a02:1:48b6:50f4:321c:592d]) by mail.nic.cz (Postfix) with ESMTPSA id 205F318126D; Fri, 15 Jan 2016 12:55:33 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452858933; bh=jpJWTnmyr6C9P1771LDkiu3Eb48XWO0CZWbYgeVP0aE=; h=From:Date:To; b=i5Azh9qIJ1CALsVEfdEPq3hYhit2IS2/WHT4p6fc6iMdfueMEYCjnzINCLnV9riuR A817qOhwZxb6OuvjAvswjv6enOTqCS6BVBBDrvBLgIpv7j5x5jPsaq0f9Lc+h0rHl9 5zi6zoQEHN5klTDLDosjUlvZbRESQfwdf//gxENI=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: <20160115114924.GA12322@elstar.local>
Date: Fri, 15 Jan 2016 12:55:36 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <301372A9-0333-4D56-B501-207C405C79F3@nic.cz>
References: <20160111.101526.1720014765007751699.mbj@tail-f.com> <20160111092831.GA41568@elstar.local> <20160111.112143.1731089672764861015.mbj@tail-f.com> <20160111104855.GA41658@elstar.local> <01d301d14ef1$814dcee0$4001a8c0@gateway.2wire.net>   <20160115114924.GA12322@elstar.local>
To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] 6087bis namespace recommendations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2016 11:55:36 -0000

> On 15 Jan 2016, at 12:49, Juergen Schoenwaelder =
 wrote:
>=20
> On Fri, Jan 15, 2016 at 12:39:16PM +0100, Ladislav Lhotka wrote:
>>=20
>> Does this solve any practical problem? Modules are imported based on
>> the module name and revision. On the other hand, it does create new =
problems:
>> namespace URIs and their mappings to prefixes may be spread in many
>> places in the code, and these would have to be manually edited after =
an
>> I-D -> RFC transition.
>>=20
>> It would IMO be much better to use revision numbers rather than =
dates,
>> and adopt a convention, e.g., that modules in the I-D stage have
>> revisions 0.x that get bumped with each new revision of the I-D.
>>=20
>=20
> Lada, this is not how our current YANG 1.0 versioning and revision
> rules work and we are not going to change them in YANG 1.1 either.
> The rules we have do make a distinction between published modules and
> modules that are unpublished.

I am not proposing it. The problem I'd like to get solved is proper =
module revisioning already at the I-D stage so that implementations be =
able to distinguish one revision from another. Appending DRAFT to the =
namespace URI doesn't help anything.

Lada=20

>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         

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





From nobody Fri Jan 15 06:10:09 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E60921B2D5B for ; Fri, 15 Jan 2016 06:10:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSHrCXQXPG7Q for ; Fri, 15 Jan 2016 06:10:06 -0800 (PST)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 EC56A1B2D54 for ; Fri, 15 Jan 2016 06:10:05 -0800 (PST)
Received: by mail-lf0-x231.google.com with SMTP id m198so136004218lfm.0 for ; Fri, 15 Jan 2016 06:10: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:date:message-id:subject:from:to :cc:content-type; bh=fUjveHlGgNm/diVV0NMamOqX4Ql3U0cQQBkf82Pas8o=; b=bw/amoFfFzAhSQ1g+G+yN5Ikwg2sGvICZ1vOjU0cV8pmsE4rIriKv7k+BbBYCrDyxT Bm5fnT4BGgjyTSgIPwTOieQn/CYl67ZnJ5XnDorRAlm3UhN13PEkQq4+w4Ie7mohY7nn zISzzVikffup6vGY+60gsAHWorxEkqk917rcXLDQDw7M+mQ1FYbyO40okz90CzL0LHyQ qHA8XC9WkDEpKKsVbWOBicPPV67oOuOT7WdWLMlgu9SL6UGhRBjPHemVqTEepQGEdm3E qkj5L1ldGuAeQiBRvIbzmxW/x5oMb3W7oV+oOFox0on5AcaQof0Byc1YK+K93syhVqv0 UbRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fUjveHlGgNm/diVV0NMamOqX4Ql3U0cQQBkf82Pas8o=; b=K/41rkr7M+OsJvSfxpb+oawXi5G1fO9zCxZq/fF3okiRQv07xfxwjRdchocMlTpIBz dD0DBXacLuokxpZgosQUSdgRRhpiIvOGm1amINzsCkYmwxxyX9Eyt9Od7pQ4G7caNBpR iCY1Ge8BZkS3qthMKwxtOIWQ5RXjjJzuK3c3EtbVrYyEhsbRMOagNyw7Orzs0Olom44L HuE8NBXtQFdbFcYFvsmaUncz4nlvlIPpteU9XuN8eQbY5Ob8CCBI7Y9f7DK6O3ojm3Cf 5JRim98TQ/0RkxMdm/064/P/Tb/z3k1FeHe9H2sEuHwZqbQAXFKqmyR+bTBjtpOHoKox v4cg==
X-Gm-Message-State: ALoCoQnrMTUsJpDmwz8iopsL+6PVz0zSdwedxwHHcVCWzXpKtnvk1o0rKgKcKMbRiMk4mSlaokl5rsQ9mC4Qb2bY0InrLZG/dA==
MIME-Version: 1.0
X-Received: by 10.25.77.203 with SMTP id a194mr3659096lfb.62.1452867004069; Fri, 15 Jan 2016 06:10:04 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Fri, 15 Jan 2016 06:10:03 -0800 (PST)
In-Reply-To: <301372A9-0333-4D56-B501-207C405C79F3@nic.cz>
References: <20160111.101526.1720014765007751699.mbj@tail-f.com> <20160111092831.GA41568@elstar.local> <20160111.112143.1731089672764861015.mbj@tail-f.com> <20160111104855.GA41658@elstar.local> <01d301d14ef1$814dcee0$4001a8c0@gateway.2wire.net>   <20160115114924.GA12322@elstar.local> <301372A9-0333-4D56-B501-207C405C79F3@nic.cz>
Date: Fri, 15 Jan 2016 06:10:03 -0800
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=001a1141f2c4af1b0705295ff5dc
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] 6087bis namespace recommendations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2016 14:10:08 -0000

--001a1141f2c4af1b0705295ff5dc
Content-Type: text/plain; charset=UTF-8

On Fri, Jan 15, 2016 at 3:55 AM, Ladislav Lhotka  wrote:

>
> > On 15 Jan 2016, at 12:49, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> >
> > On Fri, Jan 15, 2016 at 12:39:16PM +0100, Ladislav Lhotka wrote:
> >>
> >> Does this solve any practical problem? Modules are imported based on
> >> the module name and revision. On the other hand, it does create new
> problems:
> >> namespace URIs and their mappings to prefixes may be spread in many
> >> places in the code, and these would have to be manually edited after an
> >> I-D -> RFC transition.
> >>
> >> It would IMO be much better to use revision numbers rather than dates,
> >> and adopt a convention, e.g., that modules in the I-D stage have
> >> revisions 0.x that get bumped with each new revision of the I-D.
> >>
> >
> > Lada, this is not how our current YANG 1.0 versioning and revision
> > rules work and we are not going to change them in YANG 1.1 either.
> > The rules we have do make a distinction between published modules and
> > modules that are unpublished.
>
> I am not proposing it. The problem I'd like to get solved is proper module
> revisioning already at the I-D stage so that implementations be able to
> distinguish one revision from another. Appending DRAFT to the namespace URI
> doesn't help anything.
>
>

Changing the module name constantly does not help.
It would be better to just keep using revision dates.


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: E74E8C0C
>
>
>
>
>

--001a1141f2c4af1b0705295ff5dc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Fri, Jan 15, 2016 at 3:55 AM, Ladislav Lhotka <=
lhotka@nic.cz> wrote:


> On 15 Jan 2016, at 12:49, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<=
/a>> wrote:

>

> On Fri, Jan 15, 2016 at 12:39:16PM +0100, Ladislav Lhotka wrote:

>>

>> Does this solve any practical problem? Modules are imported based =
on

>> the module name and revision. On the other hand, it does create ne=
w problems:

>> namespace URIs and their mappings to prefixes may be spread in man=
y

>> places in the code, and these would have to be manually edited aft=
er an

>> I-D -> RFC transition.

>>

>> It would IMO be much better to use revision numbers rather than da=
tes,

>> and adopt a convention, e.g., that modules in the I-D stage have
>> revisions 0.x that get bumped with each new revision of the I-D.
>>

>

> Lada, this is not how our current YANG 1.0 versioning and revision

> rules work and we are not going to change them in YANG 1.1 either.

> The rules we have do make a distinction between published modules and<=
br>
> modules that are unpublished.



I am not proposing it. The problem I'd like to get solved is proper mod=
ule revisioning already at the I-D stage so that implementations be able to=
 distinguish one revision from another. Appending DRAFT to the namespace UR=
I doesn't help anything.







Lada







--001a1141f2c4af1b0705295ff5dc--


From nobody Fri Jan 15 06:16:09 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2591B2D6C for ; Fri, 15 Jan 2016 06:16:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.678
X-Spam-Level: 
X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RhLxVC4it7W for ; Fri, 15 Jan 2016 06:16:04 -0800 (PST)
Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (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 041991ACE4B for ; Fri, 15 Jan 2016 06:16:04 -0800 (PST)
Received: by mail-lb0-x22b.google.com with SMTP id x4so59044232lbm.0 for ; Fri, 15 Jan 2016 06:16: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:date:message-id:subject:from:to :cc:content-type; bh=KQbVWVDBulpfUxoaz8SbtsA0BSHZv+8Vj74hf8lswug=; b=eroAegVTIQiN3iJGrS9SNn4xIdnLvnCFF/xpWVvMSsDXcw6+1UDFPP43qm1vUlQZ4P s+/+AnbyNYlfDrvPGXhZarhTpcun9uYCrUPVwNWiuIT87E3qvh8U2siFDZDfV22bvdIg LbF1QvLp9iY+Xjca9g6eakdOouEiTJA1H1O3Qq/aDGPxXMYgXJRbT794D8eWkurk1uoM Undan9rJz3D+fkaP6gxbZ/Y2Vb0fVXITi0VatKbzZcGKTaiiYCIGyr/jIosV2C6/0Tpc 0snUMGPKd9O96kEwilDrTLVa3gdWq3DrzIEyLHRfswl9Uvn6YbovEU0KXPq/uOI2iyUC EEAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KQbVWVDBulpfUxoaz8SbtsA0BSHZv+8Vj74hf8lswug=; b=FCg1uQT5nMz80meY3U3MDrpSfNjHo/vqrUDjgpS+VKXWvzRr5Stk65PUlYXf37qI1J qIM7S4fuYcwHSwEWph7mSK+5FzrlSga6ZD3lqnVs80AKsPhCPA4EEbx8UXgPUrIhmsQw 1ID4AgW2rhHq3cjnE64vETYL61bNAJUZ60+zPE59qqfuU7e2UFokgqfzuMi2m7E+cNwt AGk7CGtXfiYT/rqn4HeDq+d6GME+N1PboaCHQ2KweNMXJ2htIaJ8cCFQNqUvDAhk60yL JpYdJFolZ1jYjprkFrXCPtAKGKSkKfTzxX+9VBw7evnaTN7HSZY6fZCSsQpEHzL+RI2X JJcQ==
X-Gm-Message-State: AG10YOQuW4LoWX2yQiDXhbDR2fF0H4Hz8eM954KeH75IPPi63fUk6YDIyfGpskWS2M6LDaFujqzkH5iAP1977A==
MIME-Version: 1.0
X-Received: by 10.112.180.7 with SMTP id dk7mr2795114lbc.65.1452867362156; Fri, 15 Jan 2016 06:16:02 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Fri, 15 Jan 2016 06:16:02 -0800 (PST)
In-Reply-To: 
References: <20160111.101526.1720014765007751699.mbj@tail-f.com> <20160111092831.GA41568@elstar.local> <20160111.112143.1731089672764861015.mbj@tail-f.com> <20160111104855.GA41658@elstar.local> <01d301d14ef1$814dcee0$4001a8c0@gateway.2wire.net>  
Date: Fri, 15 Jan 2016 06:16:02 -0800
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=089e0112cad0070cb10529600b9d
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] 6087bis namespace recommendations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2016 14:16:07 -0000

--089e0112cad0070cb10529600b9d
Content-Type: text/plain; charset=UTF-8

On Fri, Jan 15, 2016 at 3:39 AM, Ladislav Lhotka  wrote:

> Andy Bierman  writes:
>
> > On Thu, Jan 14, 2016 at 9:32 AM, t.petch  wrote:
> >
> >> ----- Original Message -----
> >> From: "Juergen Schoenwaelder" 
> >> To: "Martin Bjorklund" 
> >> Cc: 
> >> Sent: Monday, January 11, 2016 10:48 AM
> >>
> >> > On Mon, Jan 11, 2016 at 11:21:43AM +0100, Martin Bjorklund wrote:
> >> > > Juergen Schoenwaelder  wrote:
> >> > > > On Mon, Jan 11, 2016 at 10:15:26AM +0100, Martin Bjorklund wrote:
> >>
> >> 
> >> > > > >   2.  There was some discussion about recommending a different
> >> URN
> >> > > > >       prefix for unpublished modules (i.e., modules in Internet
> >> > > > >       Drafts).
> >> > > > >
> >> > > > >       Should 6087bis recommend some special urn prefix for
> >> drafts,
> >> > > > >       with a note to the RFC editor to change the namespace once
> >> it
> >> > > > >       has been registered with IANA?
> >> > > >
> >> > > > Do we have evidence that having such a rule makes the Internet
> >> work
> >> > > > better?
> >> > >
> >> > > I don't know, but apparently there can be confusion when an
> >> extracted
> >> > > module from a draft is passed around.
> >> > >
> >> > > What can we learn from the SNMP experience where the OID assignement
> >> > > is done by IANA - good or bad?
> >> >
> >> > With MIB modules, the module OID is assigned by IANA and we usually
> >> > have a placeholder (which makes the module not compile). With SNMP, we
> >> > converged to register the majority of modules below mib-2 and hence if
> >> > people pick numbers, they have a high potential for collision. With
> >> > NETCONF namespaces, the collision probability is rather low. The other
> >> > aspect is that an official assignment happens late during the process,
> >> > e.g., as part of the RFC publication process and there might be early
> >> > implementations that use a 'speculative' namespace value. In a perfect
> >> > world, we should likely use a different prefix while the module is
> >> > under development and then let IANA have the final say on the official
> >> > prefix. And if Lada is really concerned about problems caused if I-D
> >> > implementations, we could do lets say a series of
> >> >
> >> >   urn:ietf:params:xml:ns:yang:draft-ietf-netmod-routing-cfg-00
> >> >   ...
> >> >   urn:ietf:params:xml:ns:yang:draft-ietf-netmod-routing-cfg-20
> >> >
> >> > in I-Ds and then the RFC editor finally changes things to
> >> >
> >> >   urn:ietf:params:xml:ns:yang:ietf-routing
> >> >
> >> > if IANA agrees to allocate this URN to the module. Of course, this
> >> > means more work for the editors involved and so far our lax handling
> >> > of this issue seems to have worked. (But so it did for MIB modules
> >> > until problems started to show up.)
> >>
> >> I think that, as has already been said, the much larger namespace for
> >> urn compared to mib-2 makes collisions less likely.
> >>
> >> I have seen collisions in SMI and they were costly to fix, one
> >> manufacturer or the other had to agree to back off and rework their
> >> product.
> >>
> >> What SMI did get superbly right was setting up a branch of the tree
> >> (.private.enterprises.), for organisations that wanted to get involved,
> >> to register for a number, FCFS (and a process that did not involve the
> >> costs of the IEEE equivalent:-) under which they could create their own
> >> modules.  On a typical network box, the amount of data under that branch
> >> would exceed, sometimes by an order of magnitude, the amount of data
> >> under mib-2.
> >>
> >> Originally, the intention with SMI was that development would take place
> >> under a different branch and be converted to the allocated number at the
> >> end, but making changes when everything was tested and working was not
> >> too popular so that fell by the wayside.
> >>
> >> Finally, the fashion with YANG seems to be to carve up a piece of work
> >> into a number of (sub)modules, so there are a number of related names
> >> which again may reflect the convenience of developers rather than
> >> users; and the relationship may or may not be apparent from the chosen
> >> names.   We could offer guidance here
> >>
> >>
> > I like the idea of adding DRAFT to the end of the namespace identifier
> > I would prefer not to put revision identifiers in the namespace.
> >
> > Internet-Draft publication:
> >
> >     urn:ietf:params:xml:ns:yang:ietf-routing:DRAFT
> >
> > RFC publication
> >
> >     urn:ietf:params:xml:ns:yang:ietf-routing
> >
>
> Does this solve any practical problem? Modules are imported based on
> the module name and revision. On the other hand, it does create new
> problems:
> namespace URIs and their mappings to prefixes may be spread in many
> places in the code, and these would have to be manually edited after an
> I-D -> RFC transition.
>
>

This is an implementation detail.
Our code uses a namespace registry and does not spread out
hard-wired string comparisons in the code.

But it is OK it we do nothing about this issue other than make
sure the RFC version has a different revision date than any of the I-D
versions.


Andy





> It would IMO be much better to use revision numbers rather than dates,
> and adopt a convention, e.g., that modules in the I-D stage have
> revisions 0.x that get bumped with each new revision of the I-D.
>
> Lada
>
> >
> >
> >
> > I never liked the SMIv2 practice of putting XXX in the MIB module.
> > It means that no MIB module extracted from an I-D can be compiled without
> > editing it. There was never any guidance offered (over 25 years) what
> number
> > somebody should pick when changing XXX so the module will compile.
> > This is what led to all the problems.
> >
> >
> >
> >
> > Tom Petch
> >>
> >>
> > Andy
> >
> >
> >> > /js
> >> >
> >> > PS: Note that JSON encoding uses the module name and not the namespace
> >> >     and hence even if we do the above, module names in JSON won't
> >> >     signal the difference between I-D and published RFC versions of a
> >> >     module. So to be really fool proof one would have to change the
> >> >     module name also with every posted I-D. The question is at which
> >> >     point in time bureaucracy hampers productivity and perhaps what we
> >> >     do today is not perfect but a reasonable trade-off.
> >> >
> >> > PS: Another option could be a YANG keyword that declares the status of
> >> >     a module, 'draft', 'published', 'experimental', 'example',
> >> >     'obsolete' and then the RFC editor would only have to toggle this
> >> >     value and tools could still distinguish the different kinds of
> >> >     YANG modules.
> >> >
> >> > --
> >> > 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
> >>
> >> _______________________________________________
> >> 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: E74E8C0C
>

--089e0112cad0070cb10529600b9d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Fri, Jan 15, 2016 at 3:39 AM, Ladislav Lhotka <=
lhotka@nic.cz> wrote:
Andy Bierman <andy@yumaworks.com> writes:



> On Thu, Jan 14, 2016 at 9:32 AM, t.petch <ietfc@btconnect.com> wrote:

>

>> ----- Original Message -----

>> From: "Juergen Schoenwaelder" <j.schoenwaelder@jacobs-university.de&=
gt;

>> To: "Martin Bjorklund" <mbj@tail-f.com>

>> Cc: <netmod@ietf.org>=


>> Sent: Monday, January 11, 2016 10:48 AM

>>

>> > On Mon, Jan 11, 2016 at 11:21:43AM +0100, Martin Bjorklund wr=
ote:

>> > > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrot=
e:

>> > > > On Mon, Jan 11, 2016 at 10:15:26AM +0100, Martin Bj=
orklund wrote:

>>

>> <snip>

>> > > > >=C2=A0 =C2=A02.=C2=A0 There was some discussion=
 about recommending a different

>> URN

>> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0prefix for unpublish=
ed modules (i.e., modules in Internet

>> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Drafts).

>> > > > >

>> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Should 6087bis recom=
mend some special urn prefix for

>> drafts,

>> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0with a note to the R=
FC editor to change the namespace once

>> it

>> > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0has been registered =
with IANA?

>> > > >

>> > > > Do we have evidence that having such a rule makes t=
he Internet

>> work

>> > > > better?

>> > >

>> > > I don't know, but apparently there can be confusion =
when an

>> extracted

>> > > module from a draft is passed around.

>> > >

>> > > What can we learn from the SNMP experience where the OID=
 assignement

>> > > is done by IANA - good or bad?

>> >

>> > With MIB modules, the module OID is assigned by IANA and we u=
sually

>> > have a placeholder (which makes the module not compile). With=
 SNMP, we

>> > converged to register the majority of modules below mib-2 and=
 hence if

>> > people pick numbers, they have a high potential for collision=
. With

>> > NETCONF namespaces, the collision probability is rather low. =
The other

>> > aspect is that an official assignment happens late during the=
 process,

>> > e.g., as part of the RFC publication process and there might =
be early

>> > implementations that use a 'speculative' namespace va=
lue. In a perfect

>> > world, we should likely use a different prefix while the modu=
le is

>> > under development and then let IANA have the final say on the=
 official

>> > prefix. And if Lada is really concerned about problems caused=
 if I-D

>> > implementations, we could do lets say a series of

>> >

>> >=C2=A0 =C2=A0urn:ietf:params:xml:ns:yang:draft-ietf-netmod-rou=
ting-cfg-00

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

>> >=C2=A0 =C2=A0urn:ietf:params:xml:ns:yang:draft-ietf-netmod-rou=
ting-cfg-20

>> >

>> > in I-Ds and then the RFC editor finally changes things to

>> >

>> >=C2=A0 =C2=A0urn:ietf:params:xml:ns:yang:ietf-routing

>> >

>> > if IANA agrees to allocate this URN to the module. Of course,=
 this

>> > means more work for the editors involved and so far our lax h=
andling

>> > of this issue seems to have worked. (But so it did for MIB mo=
dules

>> > until problems started to show up.)

>>

>> I think that, as has already been said, the much larger namespace =
for

>> urn compared to mib-2 makes collisions less likely.

>>

>> I have seen collisions in SMI and they were costly to fix, one

>> manufacturer or the other had to agree to back off and rework thei=
r

>> product.

>>

>> What SMI did get superbly right was setting up a branch of the tre=
e

>> (.private.enterprises.), for organisations that wanted to get invo=
lved,

>> to register for a number, FCFS (and a process that did not involve=
 the

>> costs of the IEEE equivalent:-) under which they could create thei=
r own

>> modules.=C2=A0 On a typical network box, the amount of data under =
that branch

>> would exceed, sometimes by an order of magnitude, the amount of da=
ta

>> under mib-2.

>>

>> Originally, the intention with SMI was that development would take=
 place

>> under a different branch and be converted to the allocated number =
at the

>> end, but making changes when everything was tested and working was=
 not

>> too popular so that fell by the wayside.

>>

>> Finally, the fashion with YANG seems to be to carve up a piece of =
work

>> into a number of (sub)modules, so there are a number of related na=
mes

>> which again may reflect the convenience of developers rather than<=
br>
>> users; and the relationship may or may not be apparent from the ch=
osen

>> names.=C2=A0 =C2=A0We could offer guidance here

>>

>>

> I like the idea of adding DRAFT to the end of the namespace identifier=


> I would prefer not to put revision identifiers in the namespace.

>

> Internet-Draft publication:

>

>=C2=A0 =C2=A0 =C2=A0urn:ietf:params:xml:ns:yang:ietf-routing:DRAFT

>

> RFC publication

>

>=C2=A0 =C2=A0 =C2=A0urn:ietf:params:xml:ns:yang:ietf-routing

>



Does this solve any practical problem? Modules are imported based on

the module name and revision. On the other hand, it does create new problem=
s:

namespace URIs and their mappings to prefixes may be spread in many

places in the code, and these would have to be manually edited after an

I-D -> RFC transition.




This is an implementati=
on detail.
Our code uses a namespace registry and does not spread=
 out
hard-wired string comparisons in the code.

But it is OK it we do nothing about this issue other than make
sure the RFC version has a different revision date than any of the I-=
D versions.


Andy



=C2=A0

It would IMO be much better to use revision numbers rather than dates,

and adopt a convention, e.g., that modules in the I-D stage have

revisions 0.x that get bumped with each new revision of the I-D.



Lada



>

>

>

> I never liked the SMIv2 practice of putting XXX in the MIB module.

> It means that no MIB module extracted from an I-D can be compiled with=
out

> editing it. There was never any guidance offered (over 25 years) what =
number

> somebody should pick when changing XXX so the module will compile.

> This is what led to all the problems.

>

>

>

>

> Tom Petch

>>

>>

> Andy

>

>

>> > /js

>> >

>> > PS: Note that JSON encoding uses the module name and not the =
namespace

>> >=C2=A0 =C2=A0 =C2=A0and hence even if we do the above, module =
names in JSON won't

>> >=C2=A0 =C2=A0 =C2=A0signal the difference between I-D and publ=
ished RFC versions of a

>> >=C2=A0 =C2=A0 =C2=A0module. So to be really fool proof one wou=
ld have to change the

>> >=C2=A0 =C2=A0 =C2=A0module name also with every posted I-D. Th=
e question is at which

>> >=C2=A0 =C2=A0 =C2=A0point in time bureaucracy hampers producti=
vity and perhaps what we

>> >=C2=A0 =C2=A0 =C2=A0do today is not perfect but a reasonable t=
rade-off.

>> >

>> > PS: Another option could be a YANG keyword that declares the =
status of

>> >=C2=A0 =C2=A0 =C2=A0a module, 'draft', 'published&=
#39;, 'experimental', 'example',

>> >=C2=A0 =C2=A0 =C2=A0'obsolete' and then the RFC editor=
 would only have to toggle this

>> >=C2=A0 =C2=A0 =C2=A0value and tools could still distinguish th=
e different kinds of

>> >=C2=A0 =C2=A0 =C2=A0YANG modules.

>> >

>> > --

>> > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0Jacobs University Bremen gGmbH

>> > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Camp=
us Ring 1 | 28759 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/net=
mod

>>

>> _______________________________________________

>> 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: E74E8C0C





--089e0112cad0070cb10529600b9d--


From nobody Fri Jan 15 06:19:08 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91ADD1B2D72 for ; Fri, 15 Jan 2016 06:19:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.652
X-Spam-Level: 
X-Spam-Status: No, score=-5.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIBEK9ypty68 for ; Fri, 15 Jan 2016 06:19:04 -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 6100F1B2D70 for ; Fri, 15 Jan 2016 06:19:04 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:48b6:50f4:321c:592d] (unknown [IPv6:2001:718:1a02:1:48b6:50f4:321c:592d]) by mail.nic.cz (Postfix) with ESMTPSA id 9F473181C58; Fri, 15 Jan 2016 15:19:02 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452867542; bh=muaoezq1xYQwAg8Lv6QIB0bcfakere/MZfBgc6Dk3xA=; h=From:Date:To; b=Ph2RM0TZhKXzySx55Qz5GdjVBYlVdBuXFTLsR+3oF+4hQju53kaiU23FKNegYk6T7 bUdzyK9HgyBsg6PPeuWeasLzfPvPYmvoAygmn+06wT+p6dYR35YwFqDukiwTXIfzWv CzrEdo00b45bsd0E+2NbpKLlSzSNlLWuCI/as7is=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Fri, 15 Jan 2016 15:19:06 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <9DA7DD58-6890-4BC2-A7BE-6D6F15F1B08D@nic.cz>
References: <20160111.101526.1720014765007751699.mbj@tail-f.com> <20160111092831.GA41568@elstar.local> <20160111.112143.1731089672764861015.mbj@tail-f.com> <20160111104855.GA41658@elstar.local> <01d301d14ef1$814dcee0$4001a8c0@gateway.2wire.net>   <20160115114924.GA12322@elstar.local> <301372A9-0333-4D56-B501-207C405C79F3@nic.cz> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] 6087bis namespace recommendations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2016 14:19:06 -0000

> On 15 Jan 2016, at 15:10, Andy Bierman  wrote:
>=20
>=20
>=20
> On Fri, Jan 15, 2016 at 3:55 AM, Ladislav Lhotka  =
wrote:
>=20
> > On 15 Jan 2016, at 12:49, Juergen Schoenwaelder =
 wrote:
> >
> > On Fri, Jan 15, 2016 at 12:39:16PM +0100, Ladislav Lhotka wrote:
> >>
> >> Does this solve any practical problem? Modules are imported based =
on
> >> the module name and revision. On the other hand, it does create new =
problems:
> >> namespace URIs and their mappings to prefixes may be spread in many
> >> places in the code, and these would have to be manually edited =
after an
> >> I-D -> RFC transition.
> >>
> >> It would IMO be much better to use revision numbers rather than =
dates,
> >> and adopt a convention, e.g., that modules in the I-D stage have
> >> revisions 0.x that get bumped with each new revision of the I-D.
> >>
> >
> > Lada, this is not how our current YANG 1.0 versioning and revision
> > rules work and we are not going to change them in YANG 1.1 either.
> > The rules we have do make a distinction between published modules =
and
> > modules that are unpublished.
>=20
> I am not proposing it. The problem I'd like to get solved is proper =
module revisioning already at the I-D stage so that implementations be =
able to distinguish one revision from another. Appending DRAFT to the =
namespace URI doesn't help anything.
>=20
>=20
>=20
> Changing the module name constantly does not help.
> It would be better to just keep using revision dates.

Some I-Ds don't do even that, for example acl-model uses the same =
revision date in subsequent I-D revisions. I checked that this actually =
violates a MUST in RFC 6087.

Lada

>=20
>=20
> Lada
>=20
>=20
>=20
> Andy
> =20
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | =
Germany
> > Fax:   +49 421 200 3103         
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

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





From nobody Fri Jan 15 06:29:41 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E7F1B2D9B for ; Fri, 15 Jan 2016 06:29:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.052
X-Spam-Level: 
X-Spam-Status: No, score=-5.052 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gu-xJdpNJ7Si for ; Fri, 15 Jan 2016 06:29: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 134961B2D9A for ; Fri, 15 Jan 2016 06:29:37 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:48b6:50f4:321c:592d] (unknown [IPv6:2001:718:1a02:1:48b6:50f4:321c:592d]) by mail.nic.cz (Postfix) with ESMTPSA id 918B6181341; Fri, 15 Jan 2016 15:29:35 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452868175; bh=b+SMcaPjdz7Tf6fohUKH5iF8Q9Y1ouosMwLMvZXDHZA=; h=From:Date:To; b=LnTlFq1ky9jkiCxNBtADRXywIvIfha+OHy+i7EQTbnopBidQXd+U9Xwzu/GsoXs5u Xcf3B778hjojl610iauQTuhYh/zKHF8hEwdkZGPtLwcvzsiFSv50Quy89DxihQH9DW vnvzsMqhS08HYCAFQpWQTf6+SWdkJhuxtZYDSQ5Q=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Fri, 15 Jan 2016 15:29:39 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <01B25FAD-0352-41F0-B07F-52873CCC51AA@nic.cz>
References: <20160111.101526.1720014765007751699.mbj@tail-f.com> <20160111092831.GA41568@elstar.local> <20160111.112143.1731089672764861015.mbj@tail-f.com> <20160111104855.GA41658@elstar.local> <01d301d14ef1$814dcee0$4001a8c0@gateway.2wire.net>   
To: Andy Bierman 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] 6087bis namespace recommendations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2016 14:29:39 -0000

> On 15 Jan 2016, at 15:16, Andy Bierman  wrote:
>=20
>=20
>=20
> On Fri, Jan 15, 2016 at 3:39 AM, Ladislav Lhotka  =
wrote:
> Andy Bierman  writes:
>=20
> > On Thu, Jan 14, 2016 at 9:32 AM, t.petch  =
wrote:
> >
> >> ----- Original Message -----
> >> From: "Juergen Schoenwaelder" =

> >> To: "Martin Bjorklund" 
> >> Cc: 
> >> Sent: Monday, January 11, 2016 10:48 AM
> >>
> >> > On Mon, Jan 11, 2016 at 11:21:43AM +0100, Martin Bjorklund wrote:
> >> > > Juergen Schoenwaelder  =
wrote:
> >> > > > On Mon, Jan 11, 2016 at 10:15:26AM +0100, Martin Bjorklund =
wrote:
> >>
> >> 
> >> > > > >   2.  There was some discussion about recommending a =
different
> >> URN
> >> > > > >       prefix for unpublished modules (i.e., modules in =
Internet
> >> > > > >       Drafts).
> >> > > > >
> >> > > > >       Should 6087bis recommend some special urn prefix for
> >> drafts,
> >> > > > >       with a note to the RFC editor to change the namespace =
once
> >> it
> >> > > > >       has been registered with IANA?
> >> > > >
> >> > > > Do we have evidence that having such a rule makes the =
Internet
> >> work
> >> > > > better?
> >> > >
> >> > > I don't know, but apparently there can be confusion when an
> >> extracted
> >> > > module from a draft is passed around.
> >> > >
> >> > > What can we learn from the SNMP experience where the OID =
assignement
> >> > > is done by IANA - good or bad?
> >> >
> >> > With MIB modules, the module OID is assigned by IANA and we =
usually
> >> > have a placeholder (which makes the module not compile). With =
SNMP, we
> >> > converged to register the majority of modules below mib-2 and =
hence if
> >> > people pick numbers, they have a high potential for collision. =
With
> >> > NETCONF namespaces, the collision probability is rather low. The =
other
> >> > aspect is that an official assignment happens late during the =
process,
> >> > e.g., as part of the RFC publication process and there might be =
early
> >> > implementations that use a 'speculative' namespace value. In a =
perfect
> >> > world, we should likely use a different prefix while the module =
is
> >> > under development and then let IANA have the final say on the =
official
> >> > prefix. And if Lada is really concerned about problems caused if =
I-D
> >> > implementations, we could do lets say a series of
> >> >
> >> >   urn:ietf:params:xml:ns:yang:draft-ietf-netmod-routing-cfg-00
> >> >   ...
> >> >   urn:ietf:params:xml:ns:yang:draft-ietf-netmod-routing-cfg-20
> >> >
> >> > in I-Ds and then the RFC editor finally changes things to
> >> >
> >> >   urn:ietf:params:xml:ns:yang:ietf-routing
> >> >
> >> > if IANA agrees to allocate this URN to the module. Of course, =
this
> >> > means more work for the editors involved and so far our lax =
handling
> >> > of this issue seems to have worked. (But so it did for MIB =
modules
> >> > until problems started to show up.)
> >>
> >> I think that, as has already been said, the much larger namespace =
for
> >> urn compared to mib-2 makes collisions less likely.
> >>
> >> I have seen collisions in SMI and they were costly to fix, one
> >> manufacturer or the other had to agree to back off and rework their
> >> product.
> >>
> >> What SMI did get superbly right was setting up a branch of the tree
> >> (.private.enterprises.), for organisations that wanted to get =
involved,
> >> to register for a number, FCFS (and a process that did not involve =
the
> >> costs of the IEEE equivalent:-) under which they could create their =
own
> >> modules.  On a typical network box, the amount of data under that =
branch
> >> would exceed, sometimes by an order of magnitude, the amount of =
data
> >> under mib-2.
> >>
> >> Originally, the intention with SMI was that development would take =
place
> >> under a different branch and be converted to the allocated number =
at the
> >> end, but making changes when everything was tested and working was =
not
> >> too popular so that fell by the wayside.
> >>
> >> Finally, the fashion with YANG seems to be to carve up a piece of =
work
> >> into a number of (sub)modules, so there are a number of related =
names
> >> which again may reflect the convenience of developers rather than
> >> users; and the relationship may or may not be apparent from the =
chosen
> >> names.   We could offer guidance here
> >>
> >>
> > I like the idea of adding DRAFT to the end of the namespace =
identifier
> > I would prefer not to put revision identifiers in the namespace.
> >
> > Internet-Draft publication:
> >
> >     urn:ietf:params:xml:ns:yang:ietf-routing:DRAFT
> >
> > RFC publication
> >
> >     urn:ietf:params:xml:ns:yang:ietf-routing
> >
>=20
> Does this solve any practical problem? Modules are imported based on
> the module name and revision. On the other hand, it does create new =
problems:
> namespace URIs and their mappings to prefixes may be spread in many
> places in the code, and these would have to be manually edited after =
an
> I-D -> RFC transition.
>=20
>=20
>=20
> This is an implementation detail.
> Our code uses a namespace registry and does not spread out
> hard-wired string comparisons in the code.
>=20
> But it is OK it we do nothing about this issue other than make
> sure the RFC version has a different revision date than any of the I-D =
versions.

Agreed, and also each I-D revision should bump the revision date of all =
its modules. If YANG modules are verified as a part of idnits, then this =
should also be checked.

Lada

>=20
>=20
> Andy
>=20
>=20
>=20
> =20
> It would IMO be much better to use revision numbers rather than dates,
> and adopt a convention, e.g., that modules in the I-D stage have
> revisions 0.x that get bumped with each new revision of the I-D.
>=20
> Lada
>=20
> >
> >
> >
> > I never liked the SMIv2 practice of putting XXX in the MIB module.
> > It means that no MIB module extracted from an I-D can be compiled =
without
> > editing it. There was never any guidance offered (over 25 years) =
what number
> > somebody should pick when changing XXX so the module will compile.
> > This is what led to all the problems.
> >
> >
> >
> >
> > Tom Petch
> >>
> >>
> > Andy
> >
> >
> >> > /js
> >> >
> >> > PS: Note that JSON encoding uses the module name and not the =
namespace
> >> >     and hence even if we do the above, module names in JSON won't
> >> >     signal the difference between I-D and published RFC versions =
of a
> >> >     module. So to be really fool proof one would have to change =
the
> >> >     module name also with every posted I-D. The question is at =
which
> >> >     point in time bureaucracy hampers productivity and perhaps =
what we
> >> >     do today is not perfect but a reasonable trade-off.
> >> >
> >> > PS: Another option could be a YANG keyword that declares the =
status of
> >> >     a module, 'draft', 'published', 'experimental', 'example',
> >> >     'obsolete' and then the RFC editor would only have to toggle =
this
> >> >     value and tools could still distinguish the different kinds =
of
> >> >     YANG modules.
> >> >
> >> > --
> >> > 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
> >>
> >> _______________________________________________
> >> 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
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

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





From nobody Fri Jan 15 06:49:24 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8271A1ACE5B for ; Fri, 15 Jan 2016 06:49:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zPYiEHJ01wE for ; Fri, 15 Jan 2016 06:49:22 -0800 (PST)
Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::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 8E5371ACE48 for ; Fri, 15 Jan 2016 06:49:21 -0800 (PST)
Received: by mail-lf0-x232.google.com with SMTP id c192so284190364lfe.2 for ; Fri, 15 Jan 2016 06:49:21 -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:date:message-id:subject:from:to :cc:content-type; bh=FsLlKLol1mfnsiDlvPg9V3tOQlp7ndfS++hLKAzabAg=; b=bv55LLzJyAycjfAHD2X09t60SPlk5oMUJMOquhEerHPktAKFjRMQSgB0W2FclAWWbe LhAIy0DRnYP+AFw08Qx+IRioLD4ASbjinkDTRUB96YnPBiS6EGHixxo8sxsAM3DlfIl1 sjKw8BJg8pn1TURSOMRSFPYh1NdR7bM+N6t0+IIBkzIZkcqNlY3P9VsohFyF1B/W3vgT J1Ckjy61tdAhyi5KtRtbbpiMJ8/6Opx70/MJJWdbAsZ5cUndTqfBYQc4cZrTYnZqcrWR YbIbXHvZXIslJ7dKCxEBXdf0pn8lIJOGOBtekxQobUms1W6uMUKLzuuoJBQ13UMi77Qv 3kdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FsLlKLol1mfnsiDlvPg9V3tOQlp7ndfS++hLKAzabAg=; b=BPBXGF5cMcbiE2GvKZvv2CSu1UKBybQZbLU7a21I2WMFObwLDdLIxNMAlej/bYc289 4r9s8/T7zg85zJumslJNI4Hrmpkw2wDB0FmOwvODbzmplCLFl+8gPx68tuAE0/HuKeab gkecxbg9gXU7waUCX/yy3yr1aKMEdhVrlev7OnCHooZfnUMx8jpgMAz0OvXXRDQbY/CS tXOXHP/d2A4NcoibaYr3M+56+/P1UIO30Fr8ZCaOigNg7kWdgwra9AbEY/q9viWrhFk1 xWNCbXIi+VMV2j0kwQtP8YkUOcuQ1VN3t+xLwHDX2qP5Imgjd3C1+H2Mx/ypJbeURz32 yfxQ==
X-Gm-Message-State: AG10YOSwuLMI5HAankBblCL01zgOZccp3RJsgGEJbndVoJnMzVWt4/J8w621WuJCNtciDjs+3fdCBSHZ2iwNLQ==
MIME-Version: 1.0
X-Received: by 10.25.162.202 with SMTP id l193mr2862618lfe.138.1452869359584;  Fri, 15 Jan 2016 06:49:19 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Fri, 15 Jan 2016 06:49:19 -0800 (PST)
In-Reply-To: <9DA7DD58-6890-4BC2-A7BE-6D6F15F1B08D@nic.cz>
References: <20160111.101526.1720014765007751699.mbj@tail-f.com> <20160111092831.GA41568@elstar.local> <20160111.112143.1731089672764861015.mbj@tail-f.com> <20160111104855.GA41658@elstar.local> <01d301d14ef1$814dcee0$4001a8c0@gateway.2wire.net>   <20160115114924.GA12322@elstar.local> <301372A9-0333-4D56-B501-207C405C79F3@nic.cz>  <9DA7DD58-6890-4BC2-A7BE-6D6F15F1B08D@nic.cz>
Date: Fri, 15 Jan 2016 06:49:19 -0800
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=001a114119ec1563550529608239
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] 6087bis namespace recommendations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2016 14:49:23 -0000

--001a114119ec1563550529608239
Content-Type: text/plain; charset=UTF-8

On Fri, Jan 15, 2016 at 6:19 AM, Ladislav Lhotka  wrote:

>
> > On 15 Jan 2016, at 15:10, Andy Bierman  wrote:
> >
> >
> >
> > On Fri, Jan 15, 2016 at 3:55 AM, Ladislav Lhotka  wrote:
> >
> > > On 15 Jan 2016, at 12:49, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> > >
> > > On Fri, Jan 15, 2016 at 12:39:16PM +0100, Ladislav Lhotka wrote:
> > >>
> > >> Does this solve any practical problem? Modules are imported based on
> > >> the module name and revision. On the other hand, it does create new
> problems:
> > >> namespace URIs and their mappings to prefixes may be spread in many
> > >> places in the code, and these would have to be manually edited after
> an
> > >> I-D -> RFC transition.
> > >>
> > >> It would IMO be much better to use revision numbers rather than dates,
> > >> and adopt a convention, e.g., that modules in the I-D stage have
> > >> revisions 0.x that get bumped with each new revision of the I-D.
> > >>
> > >
> > > Lada, this is not how our current YANG 1.0 versioning and revision
> > > rules work and we are not going to change them in YANG 1.1 either.
> > > The rules we have do make a distinction between published modules and
> > > modules that are unpublished.
> >
> > I am not proposing it. The problem I'd like to get solved is proper
> module revisioning already at the I-D stage so that implementations be able
> to distinguish one revision from another. Appending DRAFT to the namespace
> URI doesn't help anything.
> >
> >
> >
> > Changing the module name constantly does not help.
> > It would be better to just keep using revision dates.
>
> Some I-Ds don't do even that, for example acl-model uses the same revision
> date in subsequent I-D revisions. I checked that this actually violates a
> MUST in RFC 6087.
>
>

If the YANG module does not change from one I-D to the next,
then the revision date does not need to change.



> Lada
>
>
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         
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

--001a114119ec1563550529608239
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Fri, Jan 15, 2016 at 6:19 AM, Ladislav Lhotka <=
lhotka@nic.cz> wrote:


> On 15 Jan 2016, at 15:10, Andy Bierman <andy@yumaworks.com> wrote:

>

>

>

> On Fri, Jan 15, 2016 at 3:55 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

>

> > On 15 Jan 2016, at 12:49, Juergen Schoenwaelder <j.schoenwaelder@jacobs-universit=
y.de> wrote:

> >

> > On Fri, Jan 15, 2016 at 12:39:16PM +0100, Ladislav Lhotka wrote:<=
br>
> >>

> >> Does this solve any practical problem? Modules are imported b=
ased on

> >> the module name and revision. On the other hand, it does crea=
te new problems:

> >> namespace URIs and their mappings to prefixes may be spread i=
n many

> >> places in the code, and these would have to be manually edite=
d after an

> >> I-D -> RFC transition.

> >>

> >> It would IMO be much better to use revision numbers rather th=
an dates,

> >> and adopt a convention, e.g., that modules in the I-D stage h=
ave

> >> revisions 0.x that get bumped with each new revision of the I=
-D.

> >>

> >

> > Lada, this is not how our current YANG 1.0 versioning and revisio=
n

> > rules work and we are not going to change them in YANG 1.1 either=
.

> > The rules we have do make a distinction between published modules=
 and

> > modules that are unpublished.

>

> I am not proposing it. The problem I'd like to get solved is prope=
r module revisioning already at the I-D stage so that implementations be ab=
le to distinguish one revision from another. Appending DRAFT to the namespa=
ce URI doesn't help anything.

>

>

>

> Changing the module name constantly does not help.

> It would be better to just keep using revision dates.



Some I-Ds don't do even that, for example acl-model uses the same revis=
ion date in subsequent I-D revisions. I checked that this actually violates=
 a MUST in RFC 6087.




If the YANG module does=
 not change from one I-D to the next,
then the revision date does=
 not need to change.

=C2=A0

Lada



Andy
=C2=A0

>

>

> Lada

>

>

>

> Andy

>

> >

> > /js

> >

> > --

> > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jac=
obs University Bremen gGmbH

> > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus R=
ing 1 | 28759 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/>

>

> --

> Ladislav Lhotka, CZ.NIC Labs

> PGP Key ID: E74E8C0C



--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C













--001a114119ec1563550529608239--


From nobody Fri Jan 15 07:20:16 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFD41B2F27 for ; Fri, 15 Jan 2016 07:20:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.652
X-Spam-Level: 
X-Spam-Status: No, score=-5.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nub2m0JCs1ZE for ; Fri, 15 Jan 2016 07:20:08 -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 D47451B2DF1 for ; Fri, 15 Jan 2016 07:20:07 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:48b6:50f4:321c:592d] (unknown [IPv6:2001:718:1a02:1:48b6:50f4:321c:592d]) by mail.nic.cz (Postfix) with ESMTPSA id 6C93D181BF0; Fri, 15 Jan 2016 16:20:06 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452871206; bh=g/Gt+l9N2/5/3exUe3Op7ClhchqdHZAMDWG/eefwQXc=; h=From:Date:To; b=OeRepY8sB7M6+CxK4vvI7BVjFhxU0l8qjhg549j+Fs+MtXYi2elChSkuohGHMBfPO EP7CAlOsdlWKkGo0eqjGztlNpCLmSZRgP9LGapCBMkpmgO9jHdi+rx0M9ZLOdZRM1y Vmo4jtSNEJHKx9BSJJKQ21F5ur8jMJwV5HveVJq0=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Fri, 15 Jan 2016 16:20:10 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20160111.101526.1720014765007751699.mbj@tail-f.com> <20160111092831.GA41568@elstar.local> <20160111.112143.1731089672764861015.mbj@tail-f.com> <20160111104855.GA41658@elstar.local> <01d301d14ef1$814dcee0$4001a8c0@gateway.2wire.net>   <20160115114924.GA12322@elstar.local> <301372A9-0333-4D56-B501-207C405C79F3@nic.cz>  <9DA7DD58-6890-4BC2-A7BE-6D6F15F1B08D@nic.cz> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] 6087bis namespace recommendations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2016 15:20:15 -0000

> On 15 Jan 2016, at 15:49, Andy Bierman  wrote:
>=20
>=20
>=20
> On Fri, Jan 15, 2016 at 6:19 AM, Ladislav Lhotka  =
wrote:
>=20
> > On 15 Jan 2016, at 15:10, Andy Bierman  wrote:
> >
> >
> >
> > On Fri, Jan 15, 2016 at 3:55 AM, Ladislav Lhotka  =
wrote:
> >
> > > On 15 Jan 2016, at 12:49, Juergen Schoenwaelder =
 wrote:
> > >
> > > On Fri, Jan 15, 2016 at 12:39:16PM +0100, Ladislav Lhotka wrote:
> > >>
> > >> Does this solve any practical problem? Modules are imported based =
on
> > >> the module name and revision. On the other hand, it does create =
new problems:
> > >> namespace URIs and their mappings to prefixes may be spread in =
many
> > >> places in the code, and these would have to be manually edited =
after an
> > >> I-D -> RFC transition.
> > >>
> > >> It would IMO be much better to use revision numbers rather than =
dates,
> > >> and adopt a convention, e.g., that modules in the I-D stage have
> > >> revisions 0.x that get bumped with each new revision of the I-D.
> > >>
> > >
> > > Lada, this is not how our current YANG 1.0 versioning and revision
> > > rules work and we are not going to change them in YANG 1.1 either.
> > > The rules we have do make a distinction between published modules =
and
> > > modules that are unpublished.
> >
> > I am not proposing it. The problem I'd like to get solved is proper =
module revisioning already at the I-D stage so that implementations be =
able to distinguish one revision from another. Appending DRAFT to the =
namespace URI doesn't help anything.
> >
> >
> >
> > Changing the module name constantly does not help.
> > It would be better to just keep using revision dates.
>=20
> Some I-Ds don't do even that, for example acl-model uses the same =
revision date in subsequent I-D revisions. I checked that this actually =
violates a MUST in RFC 6087.
>=20
>=20
>=20
> If the YANG module does not change from one I-D to the next,
> then the revision date does not need to change.

6087(bis) says:

   It is acceptable to reuse the same revision statement within
   unpublished versions (i.e., Internet-Drafts), but the revision date
   MUST be updated to a higher value each time the Internet-Draft is re-
   posted.

I think it is a good idea.

Lada

>=20
> =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: E74E8C0C
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

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





From nobody Fri Jan 15 07:38:06 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6641B2E03 for ; Fri, 15 Jan 2016 07:38:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBMOKbxn25HG for ; Fri, 15 Jan 2016 07:38:03 -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 CACB01B2E01 for ; Fri, 15 Jan 2016 07:38:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2800; q=dns/txt; s=iport; t=1452872283; x=1454081883; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=V/2J2yDmYhtH8zAVqt+vkOuRErsmpkezZhfq8XlOLqY=; b=OaYLriMBYBUBqgQFAgpnUCYh83zkCwp3PKIDKEw/4jsUFCek7IiKTuP3 iu8par+J0GkXlxWJrAQQXrJYSSP9ywpVSAxGXSkYNFvPOvS24H7biJX8n iLaj+RR0CZRRerbcc/JObAn7VVFgE/WoLuqT1eDgX/LIz0AgdIXGne7RQ w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAQCyEZlW/xbLJq1ehHmIWLMuAQ2BY?= =?us-ascii?q?4YPAoFuFAEBAQEBAQGBCoQ1AQEEJxE8BAEQCxAICRYPCQMCAQIBRQYBDAYCAQG?= =?us-ascii?q?IJcEfAQEBAQEBAQEBAQEBAQEBAQEBARqGVYR/iT0BBI1CiVeNXokqhVeOXSABA?= =?us-ascii?q?UKECj40hjEBAQE?=
X-IronPort-AV: E=Sophos;i="5.22,300,1449532800"; d="scan'208";a="648546998"
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; 15 Jan 2016 15:38:00 +0000
Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u0FFc0CA008649; Fri, 15 Jan 2016 15:38:00 GMT
To: Ladislav Lhotka , Andy Bierman 
References: <20160111.101526.1720014765007751699.mbj@tail-f.com> <20160111092831.GA41568@elstar.local> <20160111.112143.1731089672764861015.mbj@tail-f.com> <20160111104855.GA41658@elstar.local> <01d301d14ef1$814dcee0$4001a8c0@gateway.2wire.net>   <20160115114924.GA12322@elstar.local> <301372A9-0333-4D56-B501-207C405C79F3@nic.cz>  <9DA7DD58-6890-4BC2-A7BE-6D6F15F1B08D@nic.cz>  
From: Robert Wilton 
Message-ID: <56991258.1030204@cisco.com>
Date: Fri, 15 Jan 2016 15:38:00 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] 6087bis namespace recommendations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2016 15:38:05 -0000

On 15/01/2016 15:20, Ladislav Lhotka wrote:
>> On 15 Jan 2016, at 15:49, Andy Bierman  wrote:
>>
>>
>>
>> On Fri, Jan 15, 2016 at 6:19 AM, Ladislav Lhotka  wrote:
>>
>>> On 15 Jan 2016, at 15:10, Andy Bierman  wrote:
>>>
>>>
>>>
>>> On Fri, Jan 15, 2016 at 3:55 AM, Ladislav Lhotka  wrote:
>>>
>>>> On 15 Jan 2016, at 12:49, Juergen Schoenwaelder  wrote:
>>>>
>>>> On Fri, Jan 15, 2016 at 12:39:16PM +0100, Ladislav Lhotka wrote:
>>>>> Does this solve any practical problem? Modules are imported based on
>>>>> the module name and revision. On the other hand, it does create new problems:
>>>>> namespace URIs and their mappings to prefixes may be spread in many
>>>>> places in the code, and these would have to be manually edited after an
>>>>> I-D -> RFC transition.
>>>>>
>>>>> It would IMO be much better to use revision numbers rather than dates,
>>>>> and adopt a convention, e.g., that modules in the I-D stage have
>>>>> revisions 0.x that get bumped with each new revision of the I-D.
>>>>>
>>>> Lada, this is not how our current YANG 1.0 versioning and revision
>>>> rules work and we are not going to change them in YANG 1.1 either.
>>>> The rules we have do make a distinction between published modules and
>>>> modules that are unpublished.
>>> I am not proposing it. The problem I'd like to get solved is proper module revisioning already at the I-D stage so that implementations be able to distinguish one revision from another. Appending DRAFT to the namespace URI doesn't help anything.
>>>
>>>
>>>
>>> Changing the module name constantly does not help.
>>> It would be better to just keep using revision dates.
>> Some I-Ds don't do even that, for example acl-model uses the same revision date in subsequent I-D revisions. I checked that this actually violates a MUST in RFC 6087.
>>
>>
>>
>> If the YANG module does not change from one I-D to the next,
>> then the revision date does not need to change.
> 6087(bis) says:
>
>     It is acceptable to reuse the same revision statement within
>     unpublished versions (i.e., Internet-Drafts), but the revision date
>     MUST be updated to a higher value each time the Internet-Draft is re-
>     posted.
>
> I think it is a good idea.
It also think that it is a good idea.

Since an ID is effectively superseded by any new versions, I think that 
it is useful if a module defined in an ID has a revision date that 
matches the published ID, and also a reference back to the ID version 
that defines it.  At least if someone ends up implementing that module 
they can check its provenance.  Both of these properties would also be 
verifiable by idnits.

Rob


From nobody Fri Jan 15 09:02:00 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25FBF1B3014 for ; Fri, 15 Jan 2016 09:01:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktt9u4pEopzF for ; Fri, 15 Jan 2016 09:01: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 0BE401B3013 for ; Fri, 15 Jan 2016 09:01:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5973; q=dns/txt; s=iport; t=1452877317; x=1454086917; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=4AKT8sZhzByY6RsFuv+aIjH3lC+PVOU4u65apYdUUuU=; b=Kgl1XAQEWE4l5xQY1gLoaFBUae2/09iSDWhj4QL9nv+v7YlaE+CNLK7H Rx4l+flGjZWHYEZL/24OrrP7lHFwgt+MsuyH+wFoeCqhRCrFgcaVyQSKS NPeJeUacAqjpyN9nrogJINL4iH4BWpF14ieH0LSJ87tiCbLWoK421AE8Y A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CrBAC1JJlW/xbLJq1ejU+1HYJfgzACg?= =?us-ascii?q?gQBAQEBAQGBAAuENAEBAQMBIw8BBToGEQsYAgIFFgsCAgkDAgECAUUGDQgBARe?= =?us-ascii?q?HeAiwWpA7AQEBAQEBBAEBAQEBHoEAhVWEf4Q+gzaBSQWXGYskgjqBXhaHNoVXi?= =?us-ascii?q?myDcWSCERyBXT6GZAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.22,300,1449532800"; d="scan'208";a="623529218"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jan 2016 17:01:54 +0000
Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u0FH1spt011873 for ; Fri, 15 Jan 2016 17:01:54 GMT
To: "netmod@ietf.org" 
References:  <20160106063014.GA25143@elstar.local>  <20160107160521.GC28062@elstar.local> <568E9F5D.3030500@cisco.com> <20160108083659.GA29486@elstar.local>   <20160110112122.GA39699@elstar.local> <56938BC6.80707@cisco.com> <20160111112629.GA41791@elstar.local>
From: Robert Wilton 
Message-ID: <56992602.7020700@cisco.com>
Date: Fri, 15 Jan 2016 17:01:54 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <20160111112629.GA41791@elstar.local>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2016 17:01:59 -0000

Hi Juergen,

On 11/01/2016 11:26, Juergen Schoenwaelder wrote:
> On Mon, Jan 11, 2016 at 11:02:30AM +0000, Robert Wilton wrote:
>>
>> On 10/01/2016 11:21, Juergen Schoenwaelder wrote:
>>> On Fri, Jan 08, 2016 at 01:46:44PM +0000, Acee Lindem (acee) wrote:
>>>> The draft is quite succinct and I’m not sure how you and Juergen do not
>>>> agree that there are requirements beyond intended/applied state. Perhaps
>>>> you do not agree with them? Refer to requirements 3.(B & C) and 4.(B & C).
>>>> For your convenience, I’ve excerpted them below:
>>>>
>>>>
>>>>     3.  Separation of the applied configuration and derived state aspects
>>>>         of operational state; ability to retrieve them independently and
>>>>         together
>>>>
>>>>         A.  Be able to retrieve only the applied configuration aspects of
>>>>             operational state
>>>>
>>>>         B.  Be able to retrieve only the derived state aspects of
>>>>             operational state
>>> This is nothing new. See for example section 4.3.3.2 of RFC 6244.
>>>
>>>>         C.  Be able to retrieve both the applied configuration and
>>>>             derived state aspects of operational state together
>>> Did you notice that 3.C talks about 'applied configuration'?
>>>   
>>>>     4.  Ability to relate configuration with its corresponding
>>>>         operational state
>>>>
>>>>         A.  Ability to map intended config nodes to corresponding applied
>>>>             config nodes
>>>>
>>>>         B.  Ability to map intended config nodes to associated derived
>>>>             state nodes
>>>>
>>>>         C.  The mappings needs to be programmatically consumable
>>> I do not agree that 4.B and 4.C require to broaden the title.
>>>
>>> In fact, I wonder why 4.B is useful. If we agree that the applied
>>> config (an extended subset of the intended config) is the configration
>>> that determines what the device is doing, then we likely should have a
>>> mapping of the applied config to associated derived state.
>> Yes, in essence the relationship is intended config => applied config =>
>> derived state.  So I would say that derived state has a transitive
>> association with the intended config.
> Yes. But applied config might include something that is not intended
> config, which would be lost if we map intended config => derived state.
I basically agree.  I also wonder whether it wouldn't be better to use 
the term "relate/relationships" instead of map/mappings because the way 
the text is written at the moment it implies that the binds only need to 
go from config to state, but as I think the relationship is really 
bijective.

This would be rewording this requirement text from:

    4.  Ability to relate configuration with its corresponding
        operational state

        A.  Ability to map intended config nodes to corresponding applied
            config nodes

        B.  Ability to map intended config nodes to associated derived
            state nodes

        C.  The mappings needs to be programmatically consumable


to:

    4.  Ability to relate configuration with its corresponding
        operational state

        A.  Ability to relate intended config nodes with corresponding applied
            config nodes

        B.  Ability to relate applied config nodes with associated derived
            state nodes

        C.  The relationships needs to be programmatically consumable


Are there any other views on whether this requirement text should be 
updated?


>   
>> Personally, I think that the relationship should be expressed in the
>> reverse direction.  I.e. a particular node of derived state should be
>> allowed to refer back to the config (intended/applied) that is derived
>> from.  This is presumably an implementation detail rather than a
>> requirement.
> Yes, I wrote about this earlier - some several weeks ago. What is
> really helpful for a managing system is to know the source of derived
> state, be it applied config, be it a routing protocol daemon, be it a
> dhcp server, be it a piece of tunneling software, be it an I2RS
> agent. So yes, I agree with you that the reverse direction is
> desirable (e.g., have meta data for derived state that explains where
> the state if originating from). What I also explained back then is
> that a standard Linux kernel does not track this context for many
> resources, which makes this somewhat difficult (= expensive) to
> implement. But yes, from a management point perspective, knowing the
> source of derived state is truly helpful in my experience.

There seem to be two separate angles to this:

(1) Allowing the schema to express the relationship between derived 
state and config nodes.  This effectively allows the operator to know 
that if they change a particular config item, which derived state fields 
they may want to check to ensure that the config change has been enacted 
correctly.  My understanding is that this is what the requirements in 
section 4 of the requirements draft are addressing.

(2) Optional meta-data annotations to the derived state that indicates 
for a specific node in the data tree what is/are the sources for that 
nodes existence/value.  I agree that this does seem useful, but my hunch 
is that very few systems would be able to track or provide this 
information today.  My naive impression is that this would be more 
difficult for system vendors to implement than the applied configuration 
nodes.

Thanks,
Rob


>
>> However, I'm not sure that we actually need to change the text, I think
>> that the requirement text is probably sufficiently clear to compare
>> solutions.
> Perhaps. I just wanted to point out in my email that even 4.B involves
> applied config if done right and hence the document really is grounded
> on the distinction of applied config and intended config.
>
> /js
>


From nobody Fri Jan 15 09:24:27 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4CE1B302D for ; Fri, 15 Jan 2016 09:24:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URfK1dVrb-oE for ; Fri, 15 Jan 2016 09:24:24 -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 0E5331B302C for ; Fri, 15 Jan 2016 09:24:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4243; q=dns/txt; s=iport; t=1452878664; x=1454088264; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=sT9q+uZ/qrM3ZxNmxZIz1sWprs0wIpqfORFsd+7YzOk=; b=ffej1QiVKTiXVg9IASz0FP4NVjyNq9Klrb0R8+ck2HG+drjhOdK5BFC9 jcV6n9M3uJCP7GLIoriD2pFT7Ev4aJUMrkbLM+CvwoUovEmoWvp0FlrzT rp5F4Bny2mqu3egVCOTgk7ZNduOYIAE0twHUzdLsCS3fd6VlLVi6EpDyQ I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuBABTKplW/xbLJq1ehAxtiFa1HRgKh?= =?us-ascii?q?SNKAoIEAQEBAQEBgQuENAEBAQMBAQEBIA8BBTYKBgsLDgoCAgUWCwICCQMCAQI?= =?us-ascii?q?BFTAGAQwGAgEBiA8IDrBjkDsBAQEBAQEBAQEBAQEBAQEBAQEBFgSBAIVVhH+EP?= =?us-ascii?q?oM2gUkBBJcZjV6BXodMI4U0jl1khAo+NIYwAQEB?=
X-IronPort-AV: E=Sophos;i="5.22,300,1449532800"; d="scan'208";a="624560751"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jan 2016 17:24:22 +0000
Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u0FHOMqj017238; Fri, 15 Jan 2016 17:24:22 GMT
To: Kent Watsen , "netmod@ietf.org" 
References: <20160109005830.20805.41463.idtracker@ietfa.amsl.com>  <5693E46D.7080707@cisco.com> <3474CCCD-1B8B-40B7-B3BF-C1164C144A8F@juniper.net>
From: Robert Wilton 
Message-ID: <56992B46.6070308@cisco.com>
Date: Fri, 15 Jan 2016 17:24:22 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <3474CCCD-1B8B-40B7-B3BF-C1164C144A8F@juniper.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-03.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2016 17:24:26 -0000

Hi Kent,

On 11/01/2016 20:59, Kent Watsen wrote:
> Hi Benoit,
>
>
>> You use MUST, SHOULD, MAY, and you refer to RFC 2119. Fine.
>> However, it might be beneficial to say something such as in RFC 7698
>>
>>     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>>     document are to be interpreted as described in [RFC2119].
>>
>>     While [RFC2119] describes interpretations of these key words in terms
>>     of protocol specifications and implementations, they are used in this
>>     document to describe design requirements for protocol extensions.
> Is this needed?  Looking at RFC2119, I don’t read it as being very particular about the context it’s terms are used in.
>
> Additionally, other requirements docs use RFC2119 without any such a paragraph (e.g., RFC7698, RFC7497, RFC7449, etc.)...
>
>
>> Btw, I never quite understood what a MAY means for a requirement.
>> See requirement 2B and 2C
> For 2B, would you rather is be a SHOULD?
> For 2C, would you rather this be a “may”?

I think that the text for 2A would be more clear using MUST rather than 
may (in the sense that a compliant server must choose one of the three 
options listed).

Before:

        A.  A server may support only synchronous configuration
            operations, or only asynchronous configuration operations, or
            both synchronous and asynchronous configuration operations on
            a client-specified per-operation basis.


After:

        A.  A server MUST support only synchronous configuration
            operations, or only asynchronous configuration operations, or
            both synchronous and asynchronous configuration operations on
            a client-specified per-operation basis.


For 2B, I agree changing MAY to SHOULD but we should broaden this to 
apply to synchronous servers as well.  Even though a config edit 
operation is synchronous it could still fail to be applied for some 
leaves, and hence the intended and applied leaves could be out of step.  
Hence I propose the following change:

Before:

        B.  Servers that support asynchronous configuration operations
            MAY also provide a verify operation that a client can request
            from the server to return information regarding the
            difference between the intended and applied configurations.


After:

        B.  Servers SHOULD also provide a verify operation that a client
            can request from the server to return information regarding the
            difference between the intended and applied configurations.


For 2C, I think that the "may" should change to "SHOULD", otherwise the 
requirement that "rollback on error" semantics SHOULD be provided 
doesn't seem well grounded.

So, before:

        C.  The configuration protocol MUST specify how configuration
            errors are handled.  Errors MAY be handled by semantics
            similar to NETCONF's error-options for the 
            operation (stop-on-error, continue-on-error, rollback-on-
            error), as described in Section 7.2 in [RFC6241], but
            extended to incorporate both the intended and applied
            configurations.  Support for "rollback on error" semantics
            SHOULD be provided.

After:

        C.  The configuration protocol MUST specify how configuration
            errors are handled.  Errors SHOULD be handled by semantics
            similar to NETCONF's error-options for the 
            operation (stop-on-error, continue-on-error, rollback-on-
            error), as described in Section 7.2 in [RFC6241], but
            extended to incorporate both the intended and applied
            configurations.  Support for "rollback on error" semantics
            SHOULD be provided.


Thanks,
Rob


> FWIW, the other requirements docs listed above also use "MAY" in some of their “requirements"
>
>
> Kent
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Fri Jan 15 09:39:54 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101551A1ABF for ; Fri, 15 Jan 2016 09:39:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QinKqOpkK6MF for ; Fri, 15 Jan 2016 09:39:51 -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 3C6CA1A9128 for ; Fri, 15 Jan 2016 09:39:51 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D10B1857; Fri, 15 Jan 2016 18:39:49 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id zo_D0NQVopDY; Fri, 15 Jan 2016 18:39: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; Fri, 15 Jan 2016 18:39:48 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B07BD2002B; Fri, 15 Jan 2016 18:39:48 +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 PNFJoHVKqmnV; Fri, 15 Jan 2016 18:39:47 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1702620013; Fri, 15 Jan 2016 18:39:47 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id B8DC33984BA5; Fri, 15 Jan 2016 18:39:46 +0100 (CET)
Date: Fri, 15 Jan 2016 18:39:46 +0100
From: Juergen Schoenwaelder 
To: Robert Wilton 
Message-ID: <20160115173946.GA187@elstar.local>
Mail-Followup-To: Robert Wilton , "netmod@ietf.org" 
References:  <20160107160521.GC28062@elstar.local> <568E9F5D.3030500@cisco.com> <20160108083659.GA29486@elstar.local>   <20160110112122.GA39699@elstar.local> <56938BC6.80707@cisco.com> <20160111112629.GA41791@elstar.local> <56992602.7020700@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <56992602.7020700@cisco.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2016 17:39:54 -0000

On Fri, Jan 15, 2016 at 05:01:54PM +0000, Robert Wilton wrote:

[...]
 
> This would be rewording this requirement text from:
> 
>    4.  Ability to relate configuration with its corresponding
>        operational state
> 
>        A.  Ability to map intended config nodes to corresponding applied
>            config nodes
> 
>        B.  Ability to map intended config nodes to associated derived
>            state nodes
> 
>        C.  The mappings needs to be programmatically consumable
> 
> 
> to:
> 
>    4.  Ability to relate configuration with its corresponding
>        operational state
> 
>        A.  Ability to relate intended config nodes with corresponding 
>        applied
>            config nodes
> 
>        B.  Ability to relate applied config nodes with associated derived
>            state nodes
> 
>        C.  The relationships needs to be programmatically consumable
> 
> 
> Are there any other views on whether this requirement text should be 
> updated?
>

I think the new wording is an improvement.

> >  
> >>Personally, I think that the relationship should be expressed in the
> >>reverse direction.  I.e. a particular node of derived state should be
> >>allowed to refer back to the config (intended/applied) that is derived
> >>from.  This is presumably an implementation detail rather than a
> >>requirement.
> >Yes, I wrote about this earlier - some several weeks ago. What is
> >really helpful for a managing system is to know the source of derived
> >state, be it applied config, be it a routing protocol daemon, be it a
> >dhcp server, be it a piece of tunneling software, be it an I2RS
> >agent. So yes, I agree with you that the reverse direction is
> >desirable (e.g., have meta data for derived state that explains where
> >the state if originating from). What I also explained back then is
> >that a standard Linux kernel does not track this context for many
> >resources, which makes this somewhat difficult (= expensive) to
> >implement. But yes, from a management point perspective, knowing the
> >source of derived state is truly helpful in my experience.
> 
> There seem to be two separate angles to this:
> 
> (1) Allowing the schema to express the relationship between derived 
> state and config nodes.  This effectively allows the operator to know 
> that if they change a particular config item, which derived state fields 
> they may want to check to ensure that the config change has been enacted 
> correctly.  My understanding is that this is what the requirements in 
> section 4 of the requirements draft are addressing.

This direction of the relationship might in some cases be a relatively
trivial and predictable 1:1 relationship, in other cases it may be
more complex and in the worst case dynamically changing.

> (2) Optional meta-data annotations to the derived state that indicates 
> for a specific node in the data tree what is/are the sources for that 
> nodes existence/value.  I agree that this does seem useful, but my hunch 
> is that very few systems would be able to track or provide this 
> information today.  My naive impression is that this would be more 
> difficult for system vendors to implement than the applied configuration 
> nodes.

If you can do 'applied config' -> 'associated derived state' then you
should be able to do 'derived state' -> 'applied config' for 'derived
state' associated with 'applied config'.

But yes, I agree that 'derived state' -> 'arbitrary source of derived
state' is unfortunately unrealistic (in the general case).

BTW, do we have a definition of 'associated derived state'? What is
the scope of the _associated_ derived state? My interpretation is that
it is any derived state that is a _direct_ consequence of some applied
config being active but it does not include any state indirectly
associated with some applied config. (For example, if I turn on a VPN
service, then the associated derived state are VPN service counters
etc. but not lets say interfaces dynamically created via the VPN
service operation.)

/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 15 09:51:43 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726DC1B306D for ; Fri, 15 Jan 2016 09:51:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAWvAoHbIiaa for ; Fri, 15 Jan 2016 09:51:38 -0800 (PST)
Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (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 AE2F61A912A for ; Fri, 15 Jan 2016 09:51:37 -0800 (PST)
Received: by mail-lb0-x234.google.com with SMTP id oh2so319551002lbb.3 for ; Fri, 15 Jan 2016 09:51:37 -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:date:message-id:subject:from:to :cc:content-type; bh=S1H8sKLItFXscGxLAYS1Xv+1O0jK3w31RuaBjCAFyNU=; b=uC3bt6q8W31KrXeks/ROzYKGALBlJMHf8nBrWvRYCRDNyp7BKbw85YnWBbhzVYDD2b OYdJsqk5IcBeqDt2apqp2CSIG4JIHUy9CPfDmKuf4h6VdPZ2J5sE53mYpEPKZVVGzxDC rJrqrq0/9l2F0KMvTvkU6iqMid6MxtjShL6iTN4OddqXJRWn7yDPA/wzTJmwX3mPLb9j wwBoFu8BrYbnhRw1jRlAYalwDWPfPG2MKRdLbgw4wqossiTTBjd6tiLWAoivTvuvmf8+ CTFN9iR8LmI73xyaY9EnOLMe0O4GEPglm9fiHKcdLPIxW4Bfq1efmm9GNm9GCIRZCnLE wvMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=S1H8sKLItFXscGxLAYS1Xv+1O0jK3w31RuaBjCAFyNU=; b=e57jQNfT9qOGWAKc8xHmECI/gMRaV1eFeVbNAmPp+IIN/SxYzitInvtbUyZte8CVGW VXeAtuoFB5H8Ioqs+D2iKP1KMsxshqEp1Ca2sCT5iv6HXjM2n3RlTjR5wqU1ZCWLYzWY XxEvr+uozH2fN+34kJf58HyqMZ8WYZOOCkYg8tWu7GPrVe45VuSDgXHN8++eq3hi60/g y+n7s11MK206/ofFOHdKjGg6f7/lCVnO2xlNyqudLJqo/2quGuQCUAvRsw1XnBrEN+M2 8dBl4e7m0f7zSUc6+YHtaz2ycDEPOxMeVrxd5vHFNVeBJycyrLKpVq2+OghKl8YeVKOY QDIA==
X-Gm-Message-State: ALoCoQlAnG7sniRUF0ck5yMYhAWHMbcNxQMK3rHg/mN4aRaEaXUGT8BNcBDYj+skhTWyQYa8abH1b+2Fm6/0yFP5AfxxNsIAKw==
MIME-Version: 1.0
X-Received: by 10.112.146.34 with SMTP id sz2mr3855790lbb.96.1452880295842; Fri, 15 Jan 2016 09:51:35 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Fri, 15 Jan 2016 09:51:35 -0800 (PST)
In-Reply-To: <56991258.1030204@cisco.com>
References: <20160111.101526.1720014765007751699.mbj@tail-f.com> <20160111092831.GA41568@elstar.local> <20160111.112143.1731089672764861015.mbj@tail-f.com> <20160111104855.GA41658@elstar.local> <01d301d14ef1$814dcee0$4001a8c0@gateway.2wire.net>   <20160115114924.GA12322@elstar.local> <301372A9-0333-4D56-B501-207C405C79F3@nic.cz>  <9DA7DD58-6890-4BC2-A7BE-6D6F15F1B08D@nic.cz>   <56991258.1030204@cisco.com>
Date: Fri, 15 Jan 2016 09:51:35 -0800
Message-ID: 
From: Andy Bierman 
To: Robert Wilton 
Content-Type: multipart/alternative; boundary=047d7b3a85c8ef71f20529630db1
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] 6087bis namespace recommendations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2016 17:51:40 -0000

--047d7b3a85c8ef71f20529630db1
Content-Type: text/plain; charset=UTF-8

On Fri, Jan 15, 2016 at 7:38 AM, Robert Wilton  wrote:

>
>
> On 15/01/2016 15:20, Ladislav Lhotka wrote:
>
>> On 15 Jan 2016, at 15:49, Andy Bierman  wrote:
>>>
>>>
>>>
>>> On Fri, Jan 15, 2016 at 6:19 AM, Ladislav Lhotka  wrote:
>>>
>>> On 15 Jan 2016, at 15:10, Andy Bierman  wrote:
>>>>
>>>>
>>>>
>>>> On Fri, Jan 15, 2016 at 3:55 AM, Ladislav Lhotka  wrote:
>>>>
>>>> On 15 Jan 2016, at 12:49, Juergen Schoenwaelder <
>>>>> j.schoenwaelder@jacobs-university.de> wrote:
>>>>>
>>>>> On Fri, Jan 15, 2016 at 12:39:16PM +0100, Ladislav Lhotka wrote:
>>>>>
>>>>>> Does this solve any practical problem? Modules are imported based on
>>>>>> the module name and revision. On the other hand, it does create new
>>>>>> problems:
>>>>>> namespace URIs and their mappings to prefixes may be spread in many
>>>>>> places in the code, and these would have to be manually edited after
>>>>>> an
>>>>>> I-D -> RFC transition.
>>>>>>
>>>>>> It would IMO be much better to use revision numbers rather than dates,
>>>>>> and adopt a convention, e.g., that modules in the I-D stage have
>>>>>> revisions 0.x that get bumped with each new revision of the I-D.
>>>>>>
>>>>>> Lada, this is not how our current YANG 1.0 versioning and revision
>>>>> rules work and we are not going to change them in YANG 1.1 either.
>>>>> The rules we have do make a distinction between published modules and
>>>>> modules that are unpublished.
>>>>>
>>>> I am not proposing it. The problem I'd like to get solved is proper
>>>> module revisioning already at the I-D stage so that implementations be able
>>>> to distinguish one revision from another. Appending DRAFT to the namespace
>>>> URI doesn't help anything.
>>>>
>>>>
>>>>
>>>> Changing the module name constantly does not help.
>>>> It would be better to just keep using revision dates.
>>>>
>>> Some I-Ds don't do even that, for example acl-model uses the same
>>> revision date in subsequent I-D revisions. I checked that this actually
>>> violates a MUST in RFC 6087.
>>>
>>>
>>>
>>> If the YANG module does not change from one I-D to the next,
>>> then the revision date does not need to change.
>>>
>> 6087(bis) says:
>>
>>     It is acceptable to reuse the same revision statement within
>>     unpublished versions (i.e., Internet-Drafts), but the revision date
>>     MUST be updated to a higher value each time the Internet-Draft is re-
>>     posted.
>>
>> I think it is a good idea.
>>
> It also think that it is a good idea.
>
> Since an ID is effectively superseded by any new versions, I think that it
> is useful if a module defined in an ID has a revision date that matches the
> published ID, and also a reference back to the ID version that defines it.
> At least if someone ends up implementing that module they can check its
> provenance.  Both of these properties would also be verifiable by idnits.
>
>
this seems like a good idea.


Rob
>
>
Andy

--047d7b3a85c8ef71f20529630db1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Fri, Jan 15, 2016 at 7:38 AM, Robert Wilton <rwilton@cisco.com&=
gt; wrote:




On 15/01/2016 15:20, Ladislav Lhotka wrote:



On 15 Jan 2016, at 15:49, Andy Bierman <andy@yumaworks.com> wrote:







On Fri, Jan 15, 2016 at 6:19 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:





On 15 Jan 2016, at 15:10, Andy Bierman <andy@yumaworks.com> wrote:







On Fri, Jan 15, 2016 at 3:55 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:





On 15 Jan 2016, at 12:49, Juergen Schoenwaelder <j.schoenwaelder@jacobs-u=
niversity.de> wrote:



On Fri, Jan 15, 2016 at 12:39:16PM +0100, Ladislav Lhotka wrote:



Does this solve any practical problem? Modules are imported based on

the module name and revision. On the other hand, it does create new problem=
s:

namespace URIs and their mappings to prefixes may be spread in many

places in the code, and these would have to be manually edited after an

I-D -> RFC transition.



It would IMO be much better to use revision numbers rather than dates,

and adopt a convention, e.g., that modules in the I-D stage have

revisions 0.x that get bumped with each new revision of the I-D.





Lada, this is not how our current YANG 1.0 versioning and revision

rules work and we are not going to change them in YANG 1.1 either.

The rules we have do make a distinction between published modules and

modules that are unpublished.



I am not proposing it. The problem I'd like to get solved is proper mod=
ule revisioning already at the I-D stage so that implementations be able to=
 distinguish one revision from another. Appending DRAFT to the namespace UR=
I doesn't help anything.







Changing the module name constantly does not help.

It would be better to just keep using revision dates.



Some I-Ds don't do even that, for example acl-model uses the same revis=
ion date in subsequent I-D revisions. I checked that this actually violates=
 a MUST in RFC 6087.







If the YANG module does not change from one I-D to the next,

then the revision date does not need to change.



6087(bis) says:



=C2=A0 =C2=A0 It is acceptable to reuse the same revision statement within<=
br>
=C2=A0 =C2=A0 unpublished versions (i.e., Internet-Drafts), but the revisio=
n date

=C2=A0 =C2=A0 MUST be updated to a higher value each time the Internet-Draf=
t is re-

=C2=A0 =C2=A0 posted.



I think it is a good idea.



It also think that it is a good idea.



Since an ID is effectively superseded by any new versions, I think that it =
is useful if a module defined in an ID has a revision date that matches the=
 published ID, and also a reference back to the ID version that defines it.=
=C2=A0 At least if someone ends up implementing that module they can check =
its provenance.=C2=A0 Both of these properties would also be verifiable by =
idnits.



this seems like a good idea.



Rob





Andy



--047d7b3a85c8ef71f20529630db1--


From nobody Fri Jan 15 10:02:24 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB0C1B3097 for ; Fri, 15 Jan 2016 10:02:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zXDmUTi_4eC for ; Fri, 15 Jan 2016 10:02:21 -0800 (PST)
Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::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 7E0001B308A for ; Fri, 15 Jan 2016 10:02:20 -0800 (PST)
Received: by mail-lb0-x22a.google.com with SMTP id x4so62654150lbm.0 for ; Fri, 15 Jan 2016 10:02:20 -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:date:message-id:subject:from:to :cc:content-type; bh=LLI5RjHTyo3X0GyUZGOIce9vtuPceb5R+oHbR6DH44c=; b=YncU0gxpSuVt4RTLlHB6qDJSXDi9adBZV8QpW4eNWXVfeH1/IvCIsZF5Mo1i+x5iyd UhPu5lVLg7NSOkNJiLwju93dqVJQNjlXkbZPV68I1T7WuZtom9H34ypIH/58ykY4pZzp /W/+6nSrhyzee6Tod5uox3MQxP3zBdQZ15DhL9BiCsebAOkHXp+zqLMfNxyp4SY4MmDo 5rhUhGHn47PyucLk1NAhpt07ScgXe1J7rfaUBo7613X3SWZ0yonSj6lHmhcg3fsnKiTL zkBY4nEVPHxfDGrAzbeRrjJA0yCaRu/1eMlrQRTXEcuzgHaaCClMf+bHbiVoyO5VjNSV V/Sg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LLI5RjHTyo3X0GyUZGOIce9vtuPceb5R+oHbR6DH44c=; b=HxiSCh2THFaPDMoSKVY8KxsqFl8ZHfqoJ1mSMV5UGXLWp4wmvBZjXF/xhQxaPlgB+W PvBt6A8FgSHD78pB1/IXA1ume/EY5RJ3KAkjR2AToA5g+5+FKTITXmJRe15X3eZyJpJw 88Lhw/99XIHcCJzrMktqsrTgll9BKAGuKBAeLtmSkcaxc19UN54o4edzOCQUQNZRc1tL DDHZSGJGNjujsAQkaSngAT361SEj5xUkMmweFdZe7zs+wr5GUyvPI/pN0BIOYyOEOMU0 Os+H3JvBds6j56I4DMqUFZxKLnr3wZNs622PoU5DgSNuykLRw8o7anfu3x7p7MO9fMhQ EbAg==
X-Gm-Message-State: ALoCoQlrF3in6qNz13Xt1xAgBiKlNBRmDOXhugXu49lSj20K0O2ZsKlNgO89aTfQzIBwxamP0EYueSWNQtEO50QMtCBjwYD1Aw==
MIME-Version: 1.0
X-Received: by 10.112.141.70 with SMTP id rm6mr3273304lbb.94.1452880938634; Fri, 15 Jan 2016 10:02:18 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Fri, 15 Jan 2016 10:02:18 -0800 (PST)
In-Reply-To: <56992B46.6070308@cisco.com>
References: <20160109005830.20805.41463.idtracker@ietfa.amsl.com>  <5693E46D.7080707@cisco.com> <3474CCCD-1B8B-40B7-B3BF-C1164C144A8F@juniper.net> <56992B46.6070308@cisco.com>
Date: Fri, 15 Jan 2016 10:02:18 -0800
Message-ID: 
From: Andy Bierman 
To: Robert Wilton 
Content-Type: multipart/alternative; boundary=001a11c3819c3fa80005296334b8
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-03.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2016 18:02:23 -0000

--001a11c3819c3fa80005296334b8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 15, 2016 at 9:24 AM, Robert Wilton  wrote:

> Hi Kent,
>
> On 11/01/2016 20:59, Kent Watsen wrote:
>
>> Hi Benoit,
>>
>>
>> You use MUST, SHOULD, MAY, and you refer to RFC 2119. Fine.
>>> However, it might be beneficial to say something such as in RFC 7698
>>>
>>>     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>>     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in thi=
s
>>>     document are to be interpreted as described in [RFC2119].
>>>
>>>     While [RFC2119] describes interpretations of these key words in ter=
ms
>>>     of protocol specifications and implementations, they are used in th=
is
>>>     document to describe design requirements for protocol extensions.
>>>
>> Is this needed?  Looking at RFC2119, I don=E2=80=99t read it as being ve=
ry
>> particular about the context it=E2=80=99s terms are used in.
>>
>> Additionally, other requirements docs use RFC2119 without any such a
>> paragraph (e.g., RFC7698, RFC7497, RFC7449, etc.)...
>>
>>
>> Btw, I never quite understood what a MAY means for a requirement.
>>> See requirement 2B and 2C
>>>
>> For 2B, would you rather is be a SHOULD?
>> For 2C, would you rather this be a =E2=80=9Cmay=E2=80=9D?
>>
>
> I think that the text for 2A would be more clear using MUST rather than
> may (in the sense that a compliant server must choose one of the three
> options listed).
>
> Before:
>
>        A.  A server may support only synchronous configuration
>            operations, or only asynchronous configuration operations, or
>            both synchronous and asynchronous configuration operations on
>            a client-specified per-operation basis.
>
>
> After:
>
>        A.  A server MUST support only synchronous configuration
>            operations, or only asynchronous configuration operations, or
>            both synchronous and asynchronous configuration operations on
>            a client-specified per-operation basis.
>
>


IMO it would be a mistake to assume that the server implementation is
uniform
in its ability to provide this feature to a client.  This requires all
instrumentation
to be updated at once, which is just not realistic.  It would be much more
robust
to allow for the possibility that some subtrees cannot report "applied
yet?",
rather than force the server to lie about the applied status, or even
worse, not be able to provide this feature at all because the standard
insists on all-or-none.

Since updating instrumentation is time-consuming and labor-intensive,
a vendor might start with routing instrumentation or whatever subtrees
customers have experienced long convergence times.


Andy


> For 2B, I agree changing MAY to SHOULD but we should broaden this to appl=
y
> to synchronous servers as well.  Even though a config edit operation is
> synchronous it could still fail to be applied for some leaves, and hence
> the intended and applied leaves could be out of step.  Hence I propose th=
e
> following change:
>
> Before:
>
>        B.  Servers that support asynchronous configuration operations
>            MAY also provide a verify operation that a client can request
>            from the server to return information regarding the
>            difference between the intended and applied configurations.
>
>
> After:
>
>        B.  Servers SHOULD also provide a verify operation that a client
>            can request from the server to return information regarding th=
e
>            difference between the intended and applied configurations.
>
>
> For 2C, I think that the "may" should change to "SHOULD", otherwise the
> requirement that "rollback on error" semantics SHOULD be provided doesn't
> seem well grounded.
>
> So, before:
>
>        C.  The configuration protocol MUST specify how configuration
>            errors are handled.  Errors MAY be handled by semantics
>            similar to NETCONF's error-options for the 
>            operation (stop-on-error, continue-on-error, rollback-on-
>            error), as described in Section 7.2 in [RFC6241], but
>            extended to incorporate both the intended and applied
>            configurations.  Support for "rollback on error" semantics
>            SHOULD be provided.
>
> After:
>
>        C.  The configuration protocol MUST specify how configuration
>            errors are handled.  Errors SHOULD be handled by semantics
>            similar to NETCONF's error-options for the 
>            operation (stop-on-error, continue-on-error, rollback-on-
>            error), as described in Section 7.2 in [RFC6241], but
>            extended to incorporate both the intended and applied
>            configurations.  Support for "rollback on error" semantics
>            SHOULD be provided.
>
>
> Thanks,
> Rob
>
>
> FWIW, the other requirements docs listed above also use "MAY" in some of
>> their =E2=80=9Crequirements"
>>
>>
>> Kent
>>
>>
>> _______________________________________________
>> 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
>

--001a11c3819c3fa80005296334b8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Fri, Jan 15, 2016 at 9:24 AM, Robert Wilton <rwilton@cisco.com&=
gt; wrote:
Hi Kent,



On 11/01/2016 20:59, Kent Watsen wrote:



Hi Benoit,







You use MUST, SHOULD, MAY, and you refer to RFC 2119. Fine.

However, it might be beneficial to say something such as in RFC 7698



=C2=A0 =C2=A0 The key words "MUST", "MUST NOT", "R=
EQUIRED", "SHALL", "SHALL NOT",

=C2=A0 =C2=A0 "SHOULD", "SHOULD NOT", "RECOMMENDED=
", "MAY", and "OPTIONAL" in this

=C2=A0 =C2=A0 document are to be interpreted as described in [RFC2119].



=C2=A0 =C2=A0 While [RFC2119] describes interpretations of these key words =
in terms

=C2=A0 =C2=A0 of protocol specifications and implementations, they are used=
 in this

=C2=A0 =C2=A0 document to describe design requirements for protocol extensi=
ons.



Is this needed?=C2=A0 Looking at RFC2119, I don=E2=80=99t read it as being =
very particular about the context it=E2=80=99s terms are used in.



Additionally, other requirements docs use RFC2119 without any such a paragr=
aph (e.g., RFC7698, RFC7497, RFC7449, etc.)...







Btw, I never quite understood what a MAY means for a requirement.

See requirement 2B and 2C



For 2B, would you rather is be a SHOULD?

For 2C, would you rather this be a =E2=80=9Cmay=E2=80=9D?





I think that the text for 2A would be more clear using MUST rather than may=
 (in the sense that a compliant server must choose one of the three options=
 listed).



Before:



=C2=A0 =C2=A0 =C2=A0 =C2=A0A.=C2=A0 A server may support only synchronous c=
onfiguration

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0operations, or only asynchronous c=
onfiguration operations, or

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0both synchronous and asynchronous =
configuration operations on

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a client-specified per-operation b=
asis.





After:



=C2=A0 =C2=A0 =C2=A0 =C2=A0A.=C2=A0 A server MUST support only synchronous =
configuration

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0operations, or only asynchronous c=
onfiguration operations, or

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0both synchronous and asynchronous =
configuration operations on

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a client-specified per-operation b=
asis.





IMO it w=
ould be a mistake to assume that the server implementation is uniform
=

in its ability to provide this feature to a client.=C2=A0 This require=
s all instrumentation
to be updated at once, which is just not re=
alistic.=C2=A0 It would be much more robust
to allow for the poss=
ibility that some subtrees cannot report "applied yet?",
rather than force the server to lie about the applied status, or even
worse, not be able to provide this feature at all because the standa=
rd insists on all-or-none.

Since updating instrume=
ntation is time-consuming and labor-intensive,
a vendor might sta=
rt with routing instrumentation or whatever subtrees
customers ha=
ve experienced long convergence times.


<=
div>Andy




For 2B, I agree changing MAY to SHOULD but we should broaden this to apply =
to synchronous servers as well.=C2=A0 Even though a config edit operation i=
s synchronous it could still fail to be applied for some leaves, and hence =
the intended and applied leaves could be out of step.=C2=A0 Hence I propose=
 the following change:



Before:



=C2=A0 =C2=A0 =C2=A0 =C2=A0B.=C2=A0 Servers that support asynchronous confi=
guration operations

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MAY also provide a verify operatio=
n that a client can request

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0from the server to return informat=
ion regarding the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0difference between the intended an=
d applied configurations.





After:



=C2=A0 =C2=A0 =C2=A0 =C2=A0B.=C2=A0 Servers SHOULD also provide a verify op=
eration that a client

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0can request from the server to ret=
urn information regarding the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0difference between the intended an=
d applied configurations.





For 2C, I think that the "may" should change to "SHOULD"=
;, otherwise the requirement that "rollback on error" semantics S=
HOULD be provided doesn't seem well grounded.



So, before:



=C2=A0 =C2=A0 =C2=A0 =C2=A0C.=C2=A0 The configuration protocol MUST specify=
 how configuration

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0errors are handled.=C2=A0 Errors M=
AY be handled by semantics

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0similar to NETCONF's error-opt=
ions for the <edit-config>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0operation (stop-on-error, continue=
-on-error, rollback-on-

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0error), as described in Section 7.=
2 in [RFC6241], but

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0extended to incorporate both the i=
ntended and applied

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configurations.=C2=A0 Support for =
"rollback on error" semantics

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SHOULD be provided.



After:



=C2=A0 =C2=A0 =C2=A0 =C2=A0C.=C2=A0 The configuration protocol MUST specify=
 how configuration

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0errors are handled.=C2=A0 Errors S=
HOULD be handled by semantics

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0similar to NETCONF's error-opt=
ions for the <edit-config>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0operation (stop-on-error, continue=
-on-error, rollback-on-

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0error), as described in Section 7.=
2 in [RFC6241], but

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0extended to incorporate both the i=
ntended and applied

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configurations.=C2=A0 Support for =
"rollback on error" semantics

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SHOULD be provided.





Thanks,

Rob







FWIW, the other requirements docs listed above also use "MAY" in =
some of their =E2=80=9Crequirements"





Kent





_______________________________________________

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





--001a11c3819c3fa80005296334b8--


From nobody Fri Jan 15 10:21:53 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 577E61B30CF for ; Fri, 15 Jan 2016 10:21:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AuPAlCpwyUQ for ; Fri, 15 Jan 2016 10:21:49 -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 7D1BD1B30D0 for ; Fri, 15 Jan 2016 10:21:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3812; q=dns/txt; s=iport; t=1452882108; x=1454091708; h=from:subject:to:message-id:date:mime-version: content-transfer-encoding; bh=rW+aXtKZaNjKTB+0Sl2i0EctHP0R7vE/GaELxU5sMXk=; b=NGkLTU/hdcta9P129HnzSVIfEpo8AnUXMg9hB2FdcGSo5HqkTojn9Nnn d4zSp7OwSUc3HrM8oJdASKUxs/v6Gbgycv9/BFWH2nZlEbCNw1GMp5VCq +W/RKur7Sn9TLe4LbJyXyK4LnQPdiQrRrNxrcY7DiF/eWL9CaYO45dbCP Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CnBACfN5lW/xbLJq1ejU+1HYgVAQEBA?= =?us-ascii?q?QEBgQALhF4VOgY2AgUWCwILAwIBAgFLDQgBAReIAKEDj2+QRwEBAQcCASCBAIV?= =?us-ascii?q?ViT2DNoFJBZcZgRKMTIkqhVeOXWSECj6GZAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.22,300,1449532800"; d="scan'208";a="623531132"
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; 15 Jan 2016 18:21:46 +0000
Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u0FILk7Y018282 for ; Fri, 15 Jan 2016 18:21:46 GMT
From: Robert Wilton 
To: "netmod@ietf.org" 
Message-ID: <569938BB.1080705@cisco.com>
Date: Fri, 15 Jan 2016 18:21:47 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [netmod] Summary of "applied configuration and system-controlled entries" discussions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2016 18:21:51 -0000

Hi,

Over the last week or so there has been quite a lot of discussion and 
longs threads regarding applied configuration and system-controlled entries.

To try and bring that thread to an explicit conclusion I have tried to 
summarize (at least from my POV) where I think these discussions have 
reached, hopefully get feedback from others, and make any updates to the 
requirement draft that may be required.

I think that there were broadly three different threads to the discussions:


1) Lada requested that the requirement text in requirement 1D be 
loosened so that the applied configuration schema doesn't have to be a 
subset of the intended configuration schema.  The aim of the loosening 
of this text is to allow system-controlled entities (such as interfaces 
that always exist) to be put in the applied configuration.

Personally, I'm opposed to this change, since the relationship between 
intended and applied was explicitly discussed and it was confirmed that 
the schema for the two was expected to be the same so that they can be 
easily compared.

Is there any other support for loosening the requirement text as per 
Lada's suggestion?



However, there is still a related corner case that hasn't been raised 
yet, but may be useful to consider, which is where a systems default 
setting differs from the one defined in an associated YANG module.

To take an example, a YANG module for LLDP might use a global 
P-container to indicate whether the LLDP protocol is enabled on the 
device.  However, for a particular vendors device, the default behaviour 
for LLDP may be that is enabled globally.

If a operator is configuring the device via YANG and pushes down their 
initial config (using a config replace semantics to replace the entire 
existing configuration of the device), and the config that is pushed 
down doesn't include the P-container to explicitly enable LLDP then I 
think the expectation is that the device should disable LLDP when 
processing the config request (even though it the device's default).  
Further, all the time that the device doesn't match the implicit 
intended p-container node state (of non-existence), it should report an 
applied p-container node to indicate that LLDP is actually enabled on 
the device even though the intended behaviour is that it be disabled.

In essence I'm saying that the intended configuration includes all 
explicit data nodes, any default node values in scope, and also any 
nodes in scope that have an implicit schema default value of 
non-existence (i.e. the feature is not enabled).

Do others agree with my interpretation of intended configuration for 
this scenario?



2) Separately, there has been a suggestion from Lada (also supported by 
Gert?) such that the applied configuration always explicitly reports 
default values (e.g. like the report-all option in RFC 6243).

I generally support this suggestion because I think it solves the 
problem that a server can't indicate a difference between a leaf not 
being configured at all and leaf that is configured with the default 
value.  However, I would see it that the YANG schema for both intended 
and applied configuration is still the same, and hence I don't see any 
direct need to modify the requirements draft.  I think that all three 
proposed solutions are able to support this, and hence this issue can 
probably be deferred until a general solution approach has been agreed.

Is anyone against deferring this discussion until a general solution 
approach has been agreed?



3) Finally, there has been some proposals on the exact semantics of how 
the config handling should work, but this has been agreed to be deferred 
until the basis for a solution has been chosen.

Rob


From nobody Fri Jan 15 10:55:49 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E80F71B313B for ; Fri, 15 Jan 2016 10:55:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R_v2Xuc5jK9E for ; Fri, 15 Jan 2016 10:55:47 -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 6D9921B3135 for ; Fri, 15 Jan 2016 10:55:47 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E4AB28DA; Fri, 15 Jan 2016 19:55:45 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id e0NQKaHCf608; Fri, 15 Jan 2016 19:55:45 +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, 15 Jan 2016 19:55:45 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 440D42002C; Fri, 15 Jan 2016 19:55:45 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id DIhy-zOKqS00; Fri, 15 Jan 2016 19:55:44 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5556A20013; Fri, 15 Jan 2016 19:55:43 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 233413984CB2; Fri, 15 Jan 2016 19:55:43 +0100 (CET)
Date: Fri, 15 Jan 2016 19:55:43 +0100
From: Juergen Schoenwaelder 
To: Robert Wilton 
Message-ID: <20160115185543.GA298@elstar.local>
Mail-Followup-To: Robert Wilton , "netmod@ietf.org" 
References: <569938BB.1080705@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <569938BB.1080705@cisco.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Summary of "applied configuration and system-controlled entries" discussions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2016 18:55:49 -0000

On Fri, Jan 15, 2016 at 06:21:47PM +0000, Robert Wilton wrote:
> 
> 2) Separately, there has been a suggestion from Lada (also supported by 
> Gert?) such that the applied configuration always explicitly reports 
> default values (e.g. like the report-all option in RFC 6243).
> 
> I generally support this suggestion because I think it solves the 
> problem that a server can't indicate a difference between a leaf not 
> being configured at all and leaf that is configured with the default 
> value.

You may want to read about the 'explicit' mode defined in RFC 6243.

/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 15 12:36:44 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E621B3254 for ; Fri, 15 Jan 2016 12:36:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrpaUpXBaUG6 for ; Fri, 15 Jan 2016 12:36:40 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0120.outbound.protection.outlook.com [207.46.100.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 B254E1B324A for ; Fri, 15 Jan 2016 12:36:40 -0800 (PST)
Received: from CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) by CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) with Microsoft SMTP Server (TLS) id 15.1.361.13; Fri, 15 Jan 2016 20:36:38 +0000
Received: from CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) by CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) with mapi id 15.01.0361.006; Fri, 15 Jan 2016 20:36:38 +0000
From: Gert Grammel 
To: Robert Wilton , "netmod@ietf.org" 
Thread-Topic: [netmod] Summary of "applied configuration and system-controlled entries" discussions
Thread-Index: AQHRT8GeWGHtsIJ3CUKyMCrMF3EzRJ79GhsA
Date: Fri, 15 Jan 2016 20:36:38 +0000
Message-ID: 
References: <569938BB.1080705@cisco.com>
In-Reply-To: <569938BB.1080705@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.6.0.151221
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [193.110.55.12]
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1609; 5:WEXrGGbtgHxox+6FB9SKKBzekwFTS4VuDW9jRoCnDtkJRGt53nY/nyDkDF8wJEZn8m40ppbWXAmIVyiNGCVv5fatSQUEwmxs64eCAOuscI7fybpN9rxbNSJ20EKgbcRNpN8pYtWCW2Z1gawjEXARaQ==; 24:qzHaxhNU1OPuXgBUZFmHb5JMUOTG7psMES6WeAN7VtQXb8J7JoPdWyIJrfrtRcab5sG9lsy4r/hi7dx1G8RmHCWXf3SMENHYRfy45G3W42k=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1609;
x-ms-office365-filtering-correlation-id: ac17f1a2-b13f-4749-412f-08d31deb918d
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:CY1PR0501MB1609; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1609; 
x-forefront-prvs: 08220FA8D6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(51444003)(377424004)(24454002)(189998001)(2950100001)(586003)(11100500001)(15975445007)(3846002)(40100003)(1220700001)(4001350100001)(102836003)(6116002)(5008740100001)(107886002)(101416001)(1096002)(2900100001)(97736004)(81156007)(2906002)(5001770100001)(92566002)(77096005)(5004730100002)(5002640100001)(36756003)(106356001)(105586002)(99286002)(19580395003)(5001960100002)(122556002)(10400500002)(83506001)(86362001)(19580405001)(2501003)(87936001)(66066001)(50986999)(76176999)(54356999)(106116001)(94096001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1609; H:CY1PR0501MB1609.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:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <4A79DF10F66BC64CB56E966CB8B32FC7@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2016 20:36:38.3345 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1609
Archived-At: 
Subject: Re: [netmod] Summary of "applied configuration and system-controlled entries" discussions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2016 20:36:43 -0000

Rob,

Thank you for the effort, it=B9s really useful.

Gert

On 2016-15-01 19:21, "netmod on behalf of Robert Wilton"
 wrote:

>Hi,
>
>Over the last week or so there has been quite a lot of discussion and
>longs threads regarding applied configuration and system-controlled
>entries.
>
>To try and bring that thread to an explicit conclusion I have tried to
>summarize (at least from my POV) where I think these discussions have
>reached, hopefully get feedback from others, and make any updates to the
>requirement draft that may be required.
>
>I think that there were broadly three different threads to the
>discussions:
>
>
>1) Lada requested that the requirement text in requirement 1D be
>loosened so that the applied configuration schema doesn't have to be a
>subset of the intended configuration schema.  The aim of the loosening
>of this text is to allow system-controlled entities (such as interfaces
>that always exist) to be put in the applied configuration.
>
>Personally, I'm opposed to this change, since the relationship between
>intended and applied was explicitly discussed and it was confirmed that
>the schema for the two was expected to be the same so that they can be
>easily compared.
>
>Is there any other support for loosening the requirement text as per
>Lada's suggestion?
Gert> (1) In my response to Lada, I expressed the view the text in 1D
allowed the use case he had in mind. In his case there is no intended
config pushed to the server, hence there is no "corresponding applied
configuration=B2. That said I don=B9t see the need to change the wording bu=
t
would argue that Lada=B9s use case is covered by the current text (see also
(2)).
=20

>
>
>However, there is still a related corner case that hasn't been raised
>yet, but may be useful to consider, which is where a systems default
>setting differs from the one defined in an associated YANG module.
>
>To take an example, a YANG module for LLDP might use a global
>P-container to indicate whether the LLDP protocol is enabled on the
>device.  However, for a particular vendors device, the default behaviour
>for LLDP may be that is enabled globally.
Gert> indeed a valid scenario
>
>If a operator is configuring the device via YANG and pushes down their
>initial config (using a config replace semantics to replace the entire
>existing configuration of the device), and the config that is pushed
>down doesn't include the P-container to explicitly enable LLDP then I
>think the expectation is that the device should disable LLDP when
>processing the config request (even though it the device's default).
>Further, all the time that the device doesn't match the implicit
>intended p-container node state (of non-existence), it should report an
>applied p-container node to indicate that LLDP is actually enabled on
>the device even though the intended behaviour is that it be disabled.
>
>In essence I'm saying that the intended configuration includes all
>explicit data nodes, any default node values in scope, and also any
>nodes in scope that have an implicit schema default value of
>non-existence (i.e. the feature is not enabled).
>
>Do others agree with my interpretation of intended configuration for
>this scenario?
Gert> (2) Perhaps we should to distinguish the modelling aspect from the
usage aspect:
-modeling: Whatever the model contains as applied state should also
modelled as intended state and should also include default values (guess
this is in line with your understanding)
-usage: A client may not make full use of intended configuration for a
given server and could rely upon default values in the applied config. In
that case the intended config (in use) covers a subset of the applied
config (see (1)).=20
>
>
>
>2) Separately, there has been a suggestion from Lada (also supported by
>Gert?) such that the applied configuration always explicitly reports
>default values (e.g. like the report-all option in RFC 6243).
>
>I generally support this suggestion because I think it solves the
>problem that a server can't indicate a difference between a leaf not
>being configured at all and leaf that is configured with the default
>value.  However, I would see it that the YANG schema for both intended
>and applied configuration is still the same, and hence I don't see any
>direct need to modify the requirements draft.  I think that all three
>proposed solutions are able to support this, and hence this issue can
>probably be deferred until a general solution approach has been agreed.
>
>Is anyone against deferring this discussion until a general solution
>approach has been agreed?
Gert> too many negations in this phrase to answer with a simple yes or no
:-). I am in favour of deferring
>
>
>
>3) Finally, there has been some proposals on the exact semantics of how
>the config handling should work, but this has been agreed to be deferred
>until the basis for a solution has been chosen.
Gert> also here I am in favour of deferring
>
>Rob
>
>_______________________________________________
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod


From nobody Fri Jan 15 12:50:36 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1297D1B326D for ; Fri, 15 Jan 2016 12:50:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5XEQtclbIlE for ; Fri, 15 Jan 2016 12:50:27 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0743.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::743]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21B341B3210 for ; Fri, 15 Jan 2016 12:50:26 -0800 (PST)
Received: from CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) by CY1PR0501MB1451.namprd05.prod.outlook.com (10.160.149.12) with Microsoft SMTP Server (TLS) id 15.1.361.13; Fri, 15 Jan 2016 20:50:05 +0000
Received: from CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) by CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) with mapi id 15.01.0361.006; Fri, 15 Jan 2016 20:50:05 +0000
From: Gert Grammel 
To: Robert Wilton , Kent Watsen , "netmod@ietf.org" 
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-03.txt
Thread-Index: AQHRSnjh/C3IIgV88k2FiJpLeFg++Z7yXVcAgAQ2hoCAAD0qAIAGDSwAgABKO4A=
Date: Fri, 15 Jan 2016 20:50:05 +0000
Message-ID: 
References: <20160109005830.20805.41463.idtracker@ietfa.amsl.com>  <5693E46D.7080707@cisco.com> <3474CCCD-1B8B-40B7-B3BF-C1164C144A8F@juniper.net> <56992B46.6070308@cisco.com>
In-Reply-To: <56992B46.6070308@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.6.0.151221
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [193.110.55.12]
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1451; 5:qhOIgJ/1YJ7rd+FOZ66ikL6JrFH3prtwo6BGYDaWcSV1yQca0Pl4hjaMWsyg2ifWKterP1ZZGXIcTQg2xv75ekZ4cv+azyvYsqvya//8ZP23EXWekf7vBPnQRt5/Un1yiKnx9DctfPd77Oweeu/30A==; 24:U/nGm+7Vw2soIXAfqw2x0KCpbPSU074N2Oos8/XxSeMAGRS5sqJOlx/z2FPZTgsTtUCMV/lFVExwRzZY+VNeP3W8f62B4pkjQ6Gfn5XxE3E=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1451;
x-ms-office365-filtering-correlation-id: 8e5fb519-eb44-42bd-dfd3-08d31ded7262
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:CY1PR0501MB1451; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1451; 
x-forefront-prvs: 08220FA8D6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(51444003)(377424004)(479174004)(199003)(24454002)(189002)(101416001)(87936001)(2501003)(189998001)(83506001)(1941001)(10400500002)(86362001)(11100500001)(106356001)(5002640100001)(99286002)(106116001)(105586002)(5004730100002)(92566002)(2950100001)(5001770100001)(76176999)(15975445007)(97736004)(1096002)(19580395003)(122556002)(19580405001)(81156007)(4001350100001)(6116002)(40100003)(54356999)(5008740100001)(3846002)(93886004)(1220700001)(2900100001)(50986999)(107886002)(77096005)(102836003)(230783001)(5001960100002)(2906002)(66066001)(36756003)(586003)(94096001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1451; H:CY1PR0501MB1609.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)
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <81E69528F995814BBF29F3950742A8DF@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2016 20:50:05.1190 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1451
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-03.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2016 20:50:35 -0000

See below ..

On 2016-15-01 18:24, "netmod on behalf of Robert Wilton"
 wrote:

>Hi Kent,
>
>On 11/01/2016 20:59, Kent Watsen wrote:
>> Hi Benoit,
>>
>>
>>> You use MUST, SHOULD, MAY, and you refer to RFC 2119. Fine.
>>> However, it might be beneficial to say something such as in RFC 7698
>>>
>>>     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>>     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
>>>this
>>>     document are to be interpreted as described in [RFC2119].
>>>
>>>     While [RFC2119] describes interpretations of these key words in
>>>terms
>>>     of protocol specifications and implementations, they are used in
>>>this
>>>     document to describe design requirements for protocol extensions.
>> Is this needed?  Looking at RFC2119, I don=B9t read it as being very
>>particular about the context it=B9s terms are used in.
>>
>> Additionally, other requirements docs use RFC2119 without any such a
>>paragraph (e.g., RFC7698, RFC7497, RFC7449, etc.)...
>>
>>
>>> Btw, I never quite understood what a MAY means for a requirement.
>>> See requirement 2B and 2C
>> For 2B, would you rather is be a SHOULD?
>> For 2C, would you rather this be a =B3may=B2?
>
>I think that the text for 2A would be more clear using MUST rather than
>may (in the sense that a compliant server must choose one of the three
>options listed).
>
>Before:
>
>        A.  A server may support only synchronous configuration
>            operations, or only asynchronous configuration operations, or
>            both synchronous and asynchronous configuration operations on
>            a client-specified per-operation basis.
>
>
>After:
>
>        A.  A server MUST support only synchronous configuration
>            operations, or only asynchronous configuration operations, or
>            both synchronous and asynchronous configuration operations on
>            a client-specified per-operation basis.
Gert> support
>
>
>For 2B, I agree changing MAY to SHOULD but we should broaden this to
>apply to synchronous servers as well.  Even though a config edit
>operation is synchronous it could still fail to be applied for some
>leaves, and hence the intended and applied leaves could be out of step.
>Hence I propose the following change:

>
>Before:
>
>        B.  Servers that support asynchronous configuration operations
>            MAY also provide a verify operation that a client can request
>            from the server to return information regarding the
>            difference between the intended and applied configurations.
Gert> as per definition of synchronous, the confirmation has to indicate
that the intended config has been applied or has been failed. I therefore
like to keep the current text suggesting to change the existing text
slightly (SHOULD instead of MAY):

B.  Servers that support asynchronous configuration operations
SHOULD also provide a verify operation that a client can request
            from the server to return information regarding the
            difference between the intended and applied configurations.


>
>
>After:
>
>        B.  Servers SHOULD also provide a verify operation that a client
>            can request from the server to return information regarding
>the
>            difference between the intended and applied configurations.
>
>
>For 2C, I think that the "may" should change to "SHOULD", otherwise the
>requirement that "rollback on error" semantics SHOULD be provided
>doesn't seem well grounded.
>
>So, before:
>
>        C.  The configuration protocol MUST specify how configuration
>            errors are handled.  Errors MAY be handled by semantics
>            similar to NETCONF's error-options for the 
>            operation (stop-on-error, continue-on-error, rollback-on-
>            error), as described in Section 7.2 in [RFC6241], but
>            extended to incorporate both the intended and applied
>            configurations.  Support for "rollback on error" semantics
>            SHOULD be provided.
>
>After:
>
>        C.  The configuration protocol MUST specify how configuration
>            errors are handled.  Errors SHOULD be handled by semantics
>            similar to NETCONF's error-options for the 
>            operation (stop-on-error, continue-on-error, rollback-on-
>            error), as described in Section 7.2 in [RFC6241], but
>            extended to incorporate both the intended and applied
>            configurations.  Support for "rollback on error" semantics
>            SHOULD be provided.
Gert> support
>
>
>Thanks,
>Rob
>
>
>> FWIW, the other requirements docs listed above also use "MAY" in some
>>of their =B3requirements"
>>
>>
>> Kent
>>
>>
>> _______________________________________________
>> 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


From nobody Fri Jan 15 14:40:59 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31651B3350 for ; Fri, 15 Jan 2016 14:40:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWfxLqGV8cPD for ; Fri, 15 Jan 2016 14:40:56 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0135.outbound.protection.outlook.com [65.55.169.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA0CF1B334D for ; Fri, 15 Jan 2016 14:40:55 -0800 (PST)
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1603.namprd05.prod.outlook.com (10.161.217.20) with Microsoft SMTP Server (TLS) id 15.1.365.19; Fri, 15 Jan 2016 22:40:53 +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.0365.023; Fri, 15 Jan 2016 22:40:53 +0000
From: Kent Watsen 
To: Gert Grammel , Robert Wilton , "netmod@ietf.org" 
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-03.txt
Thread-Index: AQHRSnjhPwhlEKSCNkWPsuBEQbmSJJ7yCYMAgASKWoD//+lYgIAGYP4AgAA5eoD//8sgAA==
Date: Fri, 15 Jan 2016 22:40:53 +0000
Message-ID: <0481BD8D-EDB1-41DD-99E7-42BCBD777655@juniper.net>
References: <20160109005830.20805.41463.idtracker@ietfa.amsl.com>  <5693E46D.7080707@cisco.com> <3474CCCD-1B8B-40B7-B3BF-C1164C144A8F@juniper.net> <56992B46.6070308@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/0.0.0.151105
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.13]
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1603; 5:czVACtvDfiECzl1u0Vou6TT7sZiOu0wlyi/WNpDK5NE3PobjK0qK0Ti+1JcI/HBGL7qoBvoMHCDurMyEP4yAH03QQ2pDwoMc26Bsci0Z2YupouYsPoj8BGeOu02lkwA6RChKT4rAs1ZiNHX10O1ChA==; 24:oTqMiCfQGod0GhV/8tJm3bn610S1kxhYb+MTHn3SF3bvwxGO1wvMENxefQJtv3FoMoRXbShm+K9vtQkLJuUov19ntkMWNQXhYnKL4SpbjQs=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1603;
x-ms-office365-filtering-correlation-id: 08236f68-4912-4f4d-6ae2-08d31dfced4c
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:BN3PR0501MB1603; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1603; 
x-forefront-prvs: 08220FA8D6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(51444003)(164054003)(199003)(51914003)(101416001)(83506001)(97736004)(105586002)(2950100001)(122556002)(4001350100001)(40100003)(106356001)(92566002)(99286002)(81156007)(2906002)(2900100001)(106116001)(76176999)(77096005)(93886004)(586003)(1941001)(5004730100002)(230783001)(50986999)(5001770100001)(11100500001)(83716003)(82746002)(5002640100001)(5008740100001)(2501003)(10400500002)(3846002)(102836003)(1096002)(87936001)(6116002)(66066001)(86362001)(107886002)(36756003)(5001960100002)(1220700001)(33656002)(54356999)(189998001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1603; 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)
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: 15 Jan 2016 22:40:53.8138 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1603
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-03.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2016 22:40:58 -0000

DQpbQXMgYSBjb250cmlidXRvcl0NCg0KDQpBbmQganVzdCB3aGVuIEkgdGhvdWdodCB3ZSB3ZXJl
IGRvbmUgd2l0aCB0aGlzIGRyYWZ0ICA7KQ0KDQoNCg0KDQoNCg0KDQo+PkkgdGhpbmsgdGhhdCB0
aGUgdGV4dCBmb3IgMkEgd291bGQgYmUgbW9yZSBjbGVhciB1c2luZyBNVVNUIHJhdGhlciB0aGFu
DQo+Pm1heSAoaW4gdGhlIHNlbnNlIHRoYXQgYSBjb21wbGlhbnQgc2VydmVyIG11c3QgY2hvb3Nl
IG9uZSBvZiB0aGUgdGhyZWUNCj4+b3B0aW9ucyBsaXN0ZWQpLg0KPj4NCj4+QmVmb3JlOg0KPj4N
Cj4+ICAgICAgICBBLiAgQSBzZXJ2ZXIgbWF5IHN1cHBvcnQgb25seSBzeW5jaHJvbm91cyBjb25m
aWd1cmF0aW9uDQo+PiAgICAgICAgICAgIG9wZXJhdGlvbnMsIG9yIG9ubHkgYXN5bmNocm9ub3Vz
IGNvbmZpZ3VyYXRpb24gb3BlcmF0aW9ucywgb3INCj4+ICAgICAgICAgICAgYm90aCBzeW5jaHJv
bm91cyBhbmQgYXN5bmNocm9ub3VzIGNvbmZpZ3VyYXRpb24gb3BlcmF0aW9ucyBvbg0KPj4gICAg
ICAgICAgICBhIGNsaWVudC1zcGVjaWZpZWQgcGVyLW9wZXJhdGlvbiBiYXNpcy4NCj4+DQo+Pg0K
Pj5BZnRlcjoNCj4+DQo+PiAgICAgICAgQS4gIEEgc2VydmVyIE1VU1Qgc3VwcG9ydCBvbmx5IHN5
bmNocm9ub3VzIGNvbmZpZ3VyYXRpb24NCj4+ICAgICAgICAgICAgb3BlcmF0aW9ucywgb3Igb25s
eSBhc3luY2hyb25vdXMgY29uZmlndXJhdGlvbiBvcGVyYXRpb25zLCBvcg0KPj4gICAgICAgICAg
ICBib3RoIHN5bmNocm9ub3VzIGFuZCBhc3luY2hyb25vdXMgY29uZmlndXJhdGlvbiBvcGVyYXRp
b25zIG9uDQo+PiAgICAgICAgICAgIGEgY2xpZW50LXNwZWNpZmllZCBwZXItb3BlcmF0aW9uIGJh
c2lzLg0KPkdlcnQ+IHN1cHBvcnQNCg0KVGhpcyBkb2VzIHNlZW0gYmV0dGVyLCB0aGFua3MgZm9y
IHRoZSBzdWdnZXN0aW9uLiAgSSB2aWV3IHRoaXMgYXMgYW4gZWRpdG9yaWFsIGZpeC4NCg0KDQoN
Cg0KPj5Gb3IgMkIsIEkgYWdyZWUgY2hhbmdpbmcgTUFZIHRvIFNIT1VMRCBidXQgd2Ugc2hvdWxk
IGJyb2FkZW4gdGhpcyB0bw0KPj5hcHBseSB0byBzeW5jaHJvbm91cyBzZXJ2ZXJzIGFzIHdlbGwu
ICBFdmVuIHRob3VnaCBhIGNvbmZpZyBlZGl0DQo+Pm9wZXJhdGlvbiBpcyBzeW5jaHJvbm91cyBp
dCBjb3VsZCBzdGlsbCBmYWlsIHRvIGJlIGFwcGxpZWQgZm9yIHNvbWUNCj4+bGVhdmVzLCBhbmQg
aGVuY2UgdGhlIGludGVuZGVkIGFuZCBhcHBsaWVkIGxlYXZlcyBjb3VsZCBiZSBvdXQgb2Ygc3Rl
cC4NCj4+SGVuY2UgSSBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgY2hhbmdlOg0KPj4NCj4+QmVmb3Jl
Og0KPj4NCj4+ICAgICAgICBCLiAgU2VydmVycyB0aGF0IHN1cHBvcnQgYXN5bmNocm9ub3VzIGNv
bmZpZ3VyYXRpb24gb3BlcmF0aW9ucw0KPj4gICAgICAgICAgICBNQVkgYWxzbyBwcm92aWRlIGEg
dmVyaWZ5IG9wZXJhdGlvbiB0aGF0IGEgY2xpZW50IGNhbiByZXF1ZXN0DQo+PiAgICAgICAgICAg
IGZyb20gdGhlIHNlcnZlciB0byByZXR1cm4gaW5mb3JtYXRpb24gcmVnYXJkaW5nIHRoZQ0KPj4g
ICAgICAgICAgICBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIGludGVuZGVkIGFuZCBhcHBsaWVkIGNv
bmZpZ3VyYXRpb25zLg0KPkdlcnQ+IGFzIHBlciBkZWZpbml0aW9uIG9mIHN5bmNocm9ub3VzLCB0
aGUgY29uZmlybWF0aW9uIGhhcyB0byBpbmRpY2F0ZQ0KPnRoYXQgdGhlIGludGVuZGVkIGNvbmZp
ZyBoYXMgYmVlbiBhcHBsaWVkIG9yIGhhcyBiZWVuIGZhaWxlZC4gSSB0aGVyZWZvcmUNCj5saWtl
IHRvIGtlZXAgdGhlIGN1cnJlbnQgdGV4dCBzdWdnZXN0aW5nIHRvIGNoYW5nZSB0aGUgZXhpc3Rp
bmcgdGV4dA0KPnNsaWdodGx5IChTSE9VTEQgaW5zdGVhZCBvZiBNQVkpOg0KPg0KPkIuICBTZXJ2
ZXJzIHRoYXQgc3VwcG9ydCBhc3luY2hyb25vdXMgY29uZmlndXJhdGlvbiBvcGVyYXRpb25zDQo+
U0hPVUxEIGFsc28gcHJvdmlkZSBhIHZlcmlmeSBvcGVyYXRpb24gdGhhdCBhIGNsaWVudCBjYW4g
cmVxdWVzdA0KPiAgICAgICAgICAgIGZyb20gdGhlIHNlcnZlciB0byByZXR1cm4gaW5mb3JtYXRp
b24gcmVnYXJkaW5nIHRoZQ0KPiAgICAgICAgICAgIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgaW50
ZW5kZWQgYW5kIGFwcGxpZWQgY29uZmlndXJhdGlvbnMuDQo+Pg0KPj4NCj4+QWZ0ZXI6DQo+Pg0K
Pj4gICAgICAgIEIuICBTZXJ2ZXJzIFNIT1VMRCBhbHNvIHByb3ZpZGUgYSB2ZXJpZnkgb3BlcmF0
aW9uIHRoYXQgYSBjbGllbnQNCj4+ICAgICAgICAgICAgY2FuIHJlcXVlc3QgZnJvbSB0aGUgc2Vy
dmVyIHRvIHJldHVybiBpbmZvcm1hdGlvbiByZWdhcmRpbmcNCj4+dGhlDQo+PiAgICAgICAgICAg
IGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgaW50ZW5kZWQgYW5kIGFwcGxpZWQgY29uZmlndXJhdGlv
bnMuDQoNCg0KSSBhZ3JlZSB3aXRoIEdlcnQgb24gdGhpcyBvbmUgLSBhbmQgaXQgaXMgd2hhdCBJ
IHRvbGQgQmVub2l0IEkgd291bGQgZG8uLi4NCg0KTXkgb2JzZXJ2YXRpb24gdGhhdCB0aGUg4oCc
ZGlmZmVyZW5jZeKAnSBjb3VsZCBiZSBhcyBzaW1wbGUgYXMgYSBmbGFnIG9yIGFzIGNvbXBsZXgg
YXMgYW4gYWN0dWFsIGRpZmYuICAgV2hlbiBjb25zaWRlcmluZyB0aGUgZm9ybWVyLCB0aGVyZSBp
cyBubyBuZWVkIGZvciBhbiBhZGRpdGlvbiB2ZXJpZnkgb3B0aW9uIHdoZW4gYSBzeW5jaHJvbm91
cyBjYWxsIGlzIG1hZGUsIHdoZXJlYXMgYSB2ZXJpZnkgb3B0aW9uICp3b3VsZCogYmUgdXNlZnVs
IHdoZW4gYW4gYXN5bmNocm9ub3VzIGNhbGwgaXMgbWFkZS4gICBUaGF0IHNhaWQsIHdoZW4gY29u
c2lkZXJpbmcgdGhlIGxhdHRlciwgaXQgc2VlbXMgdGhhdCBhIHZlcmlmeSBvcHRpb24gd291bGQg
YWx3YXlzIGJlIHVzZWZ1bC4NCg0KQmVpbmcgY29uc2VydmF0aXZlLCBJIGNob29zZSB0byBiZWxp
ZXZlIHRoYXQg4oCcZGlmZmVyZW5jZSIgaGFzIHRoZSBzaW1wbGVzdCBtZWFuaW5nIGFuZCBoZW5j
ZSBjb25jbHVkZSB0aGF0IHRoZSBTSE9VTEQgb25seSBhcHBsaWVzIHRvIHNlcnZlcnMgdGhhdCBz
dXBwb3J0IGFzeW5jaHJvbm91cyBjb25maWd1cmF0aW9uIG9wZXJhdGlvbnMuICBUaGlzIGRvZXNu
4oCZdCBtZWFuIHRoYXQgYSBzb2x1dGlvbiBjYW4gYWx3YXlzIHByb3ZpZGUgYSB2ZXJpZnkgb3Bl
cmF0aW9uLCBvZiBjb3Vyc2UsIGFuZCBpZiB0aGUgcmVzdWx0IGluY2x1ZGVzIGFuIGFjdHVhbCBk
aWZmLCBpdOKAmXMgdmFsdWUgd2lsbCBiZSB1bmRlcnN0b29kIGFzIGJlaW5nIGdlbmVyYWxseSB1
c2VmdWwuICBNYWtlcyBzZW5zZT8NCg0KDQo+PkZvciAyQywgSSB0aGluayB0aGF0IHRoZSAibWF5
IiBzaG91bGQgY2hhbmdlIHRvICJTSE9VTEQiLCBvdGhlcndpc2UgdGhlDQo+PnJlcXVpcmVtZW50
IHRoYXQgInJvbGxiYWNrIG9uIGVycm9yIiBzZW1hbnRpY3MgU0hPVUxEIGJlIHByb3ZpZGVkDQo+
PmRvZXNuJ3Qgc2VlbSB3ZWxsIGdyb3VuZGVkLg0KPj4NCj4+U28sIGJlZm9yZToNCj4+DQo+PiAg
ICAgICAgQy4gIFRoZSBjb25maWd1cmF0aW9uIHByb3RvY29sIE1VU1Qgc3BlY2lmeSBob3cgY29u
ZmlndXJhdGlvbg0KPj4gICAgICAgICAgICBlcnJvcnMgYXJlIGhhbmRsZWQuICBFcnJvcnMgTUFZ
IGJlIGhhbmRsZWQgYnkgc2VtYW50aWNzDQo+PiAgICAgICAgICAgIHNpbWlsYXIgdG8gTkVUQ09O
RidzIGVycm9yLW9wdGlvbnMgZm9yIHRoZSA8ZWRpdC1jb25maWc+DQo+PiAgICAgICAgICAgIG9w
ZXJhdGlvbiAoc3RvcC1vbi1lcnJvciwgY29udGludWUtb24tZXJyb3IsIHJvbGxiYWNrLW9uLQ0K
Pj4gICAgICAgICAgICBlcnJvciksIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDcuMiBpbiBbUkZD
NjI0MV0sIGJ1dA0KPj4gICAgICAgICAgICBleHRlbmRlZCB0byBpbmNvcnBvcmF0ZSBib3RoIHRo
ZSBpbnRlbmRlZCBhbmQgYXBwbGllZA0KPj4gICAgICAgICAgICBjb25maWd1cmF0aW9ucy4gIFN1
cHBvcnQgZm9yICJyb2xsYmFjayBvbiBlcnJvciIgc2VtYW50aWNzDQo+PiAgICAgICAgICAgIFNI
T1VMRCBiZSBwcm92aWRlZC4NCj4+DQo+PkFmdGVyOg0KPj4NCj4+ICAgICAgICBDLiAgVGhlIGNv
bmZpZ3VyYXRpb24gcHJvdG9jb2wgTVVTVCBzcGVjaWZ5IGhvdyBjb25maWd1cmF0aW9uDQo+PiAg
ICAgICAgICAgIGVycm9ycyBhcmUgaGFuZGxlZC4gIEVycm9ycyBTSE9VTEQgYmUgaGFuZGxlZCBi
eSBzZW1hbnRpY3MNCj4+ICAgICAgICAgICAgc2ltaWxhciB0byBORVRDT05GJ3MgZXJyb3Itb3B0
aW9ucyBmb3IgdGhlIDxlZGl0LWNvbmZpZz4NCj4+ICAgICAgICAgICAgb3BlcmF0aW9uIChzdG9w
LW9uLWVycm9yLCBjb250aW51ZS1vbi1lcnJvciwgcm9sbGJhY2stb24tDQo+PiAgICAgICAgICAg
IGVycm9yKSwgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNy4yIGluIFtSRkM2MjQxXSwgYnV0DQo+
PiAgICAgICAgICAgIGV4dGVuZGVkIHRvIGluY29ycG9yYXRlIGJvdGggdGhlIGludGVuZGVkIGFu
ZCBhcHBsaWVkDQo+PiAgICAgICAgICAgIGNvbmZpZ3VyYXRpb25zLiAgU3VwcG9ydCBmb3IgInJv
bGxiYWNrIG9uIGVycm9yIiBzZW1hbnRpY3MNCj4+ICAgICAgICAgICAgU0hPVUxEIGJlIHByb3Zp
ZGVkLg0KPkdlcnQ+IHN1cHBvcnQNCg0KVGhpcyBkb2VzIHNlZW0gYmV0dGVyIHRoYW4gdGhlIHMv
TUFZL21heS8gSSBwcm9wb3NlZCB0byBCZW5vaXQuICANCg0KVGhlIGltcG9ydGFudCB0aGluZyB0
byBtZSBpcyB0aGF0IHRoZXJlIGlzIHN0aWxsIGEgbG90IG9mIGxlZXdheSBpbiB0aGUgImhhbmRs
ZWQgYnkgc2VtYW50aWNzIHNpbWlsYXIgdG/igJ0gY2xhdXNlLiAgSXTigJlzIGp1c3Qgc2F5aW5n
IHRoYXQgdGhlIGNsaWVudCBTSE9VTEQgaGF2ZSBzb21lIGNvbnRyb2wgb3ZlciBlcnJvciBoYW5k
bGluZywgd2hpY2ggSSB0aGluayBpcyBzdGlsbCBpbiBrZWVwaW5nIHdpdGggdGhlIG9yaWdpbmFs
IHBocmFzaW5nIG9mIHRoZSByZXF1aXJlbWVudC4gICBTbyBJIHZpZXcgdGhpcyBhcyBhbm90aGVy
IGVkaXRvcmlhbCBmaXguDQoNClRoYW5rcywNCg0KS2VudA0KDQo=


From nobody Fri Jan 15 14:52:27 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E80491B336D for ; Fri, 15 Jan 2016 14:52:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level: 
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2_RdhC-osya for ; Fri, 15 Jan 2016 14:52:23 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 5B4881B336C for ; Fri, 15 Jan 2016 14:52:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1452898342; bh=yUQRj93VdPjHNYdO6O0ZInJxzBtSchnRfdXzeRpTJ+Y=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=Jp+nMH8Tn5jvIhq11lNYNV1/GG6m55QdbMgmDZrOyZgkOakJXmuxzmGxpoW/JybrJ tuOkWZ+GqKSh1nVGJABKQhzeAnr1MjmyZOuU+mfE4NsFiPj+dSHkXd+RBj298z7EO0 WuWlkjj6F3NUl2ceTN3eQx/Yy5CMov24pGUnySlI=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Nadeau Thomas 
In-Reply-To: <0481BD8D-EDB1-41DD-99E7-42BCBD777655@juniper.net>
Date: Fri, 15 Jan 2016 17:52:20 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <64D41963-BE45-4EA6-9E46-4A1068B0E0E4@lucidvision.com>
References: <20160109005830.20805.41463.idtracker@ietfa.amsl.com>  <5693E46D.7080707@cisco.com> <3474CCCD-1B8B-40B7-B3BF-C1164C144A8F@juniper.net> <56992B46.6070308@cisco.com>  <0481BD8D-EDB1-41DD-99E7-42BCBD777655@juniper.net>
To: Kent Watsen 
X-Mailer: Apple Mail (2.3112)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=6 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 246, in=3066, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-03.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2016 22:52:26 -0000

> On Jan 15, 2016:5:40 PM, at 5:40 PM, Kent Watsen  =
wrote:
>=20
>=20
> [As a contributor]
>=20
>=20
> And just when I thought we were done with this draft  ;)
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>>> I think that the text for 2A would be more clear using MUST rather =
than
>>> may (in the sense that a compliant server must choose one of the =
three
>>> options listed).
>>>=20
>>> Before:
>>>=20
>>>       A.  A server may support only synchronous configuration
>>>           operations, or only asynchronous configuration operations, =
or
>>>           both synchronous and asynchronous configuration operations =
on
>>>           a client-specified per-operation basis.
>>>=20
>>>=20
>>> After:
>>>=20
>>>       A.  A server MUST support only synchronous configuration
>>>           operations, or only asynchronous configuration operations, =
or
>>>           both synchronous and asynchronous configuration operations =
on
>>>           a client-specified per-operation basis.
>> Gert> support
>=20
> This does seem better, thanks for the suggestion.  I view this as an =
editorial fix.

	That seems reasonable. I agree its editorial.

	=E2=80=94Tom


>=20
>=20
>=20
>=20
>>> For 2B, I agree changing MAY to SHOULD but we should broaden this to
>>> apply to synchronous servers as well.  Even though a config edit
>>> operation is synchronous it could still fail to be applied for some
>>> leaves, and hence the intended and applied leaves could be out of =
step.
>>> Hence I propose the following change:
>>>=20
>>> Before:
>>>=20
>>>       B.  Servers that support asynchronous configuration operations
>>>           MAY also provide a verify operation that a client can =
request
>>>           from the server to return information regarding the
>>>           difference between the intended and applied =
configurations.
>> Gert> as per definition of synchronous, the confirmation has to =
indicate
>> that the intended config has been applied or has been failed. I =
therefore
>> like to keep the current text suggesting to change the existing text
>> slightly (SHOULD instead of MAY):
>>=20
>> B.  Servers that support asynchronous configuration operations
>> SHOULD also provide a verify operation that a client can request
>>           from the server to return information regarding the
>>           difference between the intended and applied configurations.
>>>=20
>>>=20
>>> After:
>>>=20
>>>       B.  Servers SHOULD also provide a verify operation that a =
client
>>>           can request from the server to return information =
regarding
>>> the
>>>           difference between the intended and applied =
configurations.
>=20
>=20
> I agree with Gert on this one - and it is what I told Benoit I would =
do...
>=20
> My observation that the =E2=80=9Cdifference=E2=80=9D could be as =
simple as a flag or as complex as an actual diff.   When considering the =
former, there is no need for an addition verify option when a =
synchronous call is made, whereas a verify option *would* be useful when =
an asynchronous call is made.   That said, when considering the latter, =
it seems that a verify option would always be useful.
>=20
> Being conservative, I choose to believe that =E2=80=9Cdifference" has =
the simplest meaning and hence conclude that the SHOULD only applies to =
servers that support asynchronous configuration operations.  This =
doesn=E2=80=99t mean that a solution can always provide a verify =
operation, of course, and if the result includes an actual diff, it=E2=80=99=
s value will be understood as being generally useful.  Makes sense?
>=20
>=20
>>> For 2C, I think that the "may" should change to "SHOULD", otherwise =
the
>>> requirement that "rollback on error" semantics SHOULD be provided
>>> doesn't seem well grounded.
>>>=20
>>> So, before:
>>>=20
>>>       C.  The configuration protocol MUST specify how configuration
>>>           errors are handled.  Errors MAY be handled by semantics
>>>           similar to NETCONF's error-options for the 
>>>           operation (stop-on-error, continue-on-error, rollback-on-
>>>           error), as described in Section 7.2 in [RFC6241], but
>>>           extended to incorporate both the intended and applied
>>>           configurations.  Support for "rollback on error" semantics
>>>           SHOULD be provided.
>>>=20
>>> After:
>>>=20
>>>       C.  The configuration protocol MUST specify how configuration
>>>           errors are handled.  Errors SHOULD be handled by semantics
>>>           similar to NETCONF's error-options for the 
>>>           operation (stop-on-error, continue-on-error, rollback-on-
>>>           error), as described in Section 7.2 in [RFC6241], but
>>>           extended to incorporate both the intended and applied
>>>           configurations.  Support for "rollback on error" semantics
>>>           SHOULD be provided.
>> Gert> support
>=20
> This does seem better than the s/MAY/may/ I proposed to Benoit. =20
>=20
> The important thing to me is that there is still a lot of leeway in =
the "handled by semantics similar to=E2=80=9D clause.  It=E2=80=99s just =
saying that the client SHOULD have some control over error handling, =
which I think is still in keeping with the original phrasing of the =
requirement.   So I view this as another editorial fix.
>=20
> Thanks,
>=20
> Kent
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Fri Jan 15 14:57:02 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678D81B3379 for ; Fri, 15 Jan 2016 14:57:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnRs6Vbrgecx for ; Fri, 15 Jan 2016 14:56:59 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0109.outbound.protection.outlook.com [207.46.100.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 569FA1B3376 for ; Fri, 15 Jan 2016 14:56:59 -0800 (PST)
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1604.namprd05.prod.outlook.com (10.161.217.21) with Microsoft SMTP Server (TLS) id 15.1.365.19; Fri, 15 Jan 2016 22:56:57 +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.0365.023; Fri, 15 Jan 2016 22:56:57 +0000
From: Kent Watsen 
To: Gert Grammel , Robert Wilton , "netmod@ietf.org" 
Thread-Topic: [netmod] Summary of "applied configuration and system-controlled entries" discussions
Thread-Index: AQHRT8GeOWwlSDjLp0W0iiXnlnJEFJ79CVoA///TXwA=
Date: Fri, 15 Jan 2016 22:56:57 +0000
Message-ID: 
References: <569938BB.1080705@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/0.0.0.151105
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.13]
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1604; 5:u7nf5v2fkO5xEagwKmI8WdKAYutKqCIddK60dJ737aTzzqCM0gwxFg0gDqRlgUZ1BIc6zXKGn2vct7TkH4e9jshUadyAlNHjnc1CGvLoFLC+1OkJKT7Id7671M1fE8zLl2fCx29anrj7m3HVmWINkQ==; 24:t04lKkUZd57PSCH4Q6cOHbpI88bz374tYz4W8QWasr8NIiA966kToXQa5aFlEwISG+adOJAFcDRuEt/dECVeIdWhRwOOPwswEYWYvJgmLsk=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1604;
x-ms-office365-filtering-correlation-id: 085656d6-aba0-4440-b083-08d31dff2bb7
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(10201501046)(3002001); SRVR:BN3PR0501MB1604; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1604; 
x-forefront-prvs: 08220FA8D6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(479174004)(377454003)(377424004)(43784003)(51444003)(24454002)(97736004)(3846002)(99286002)(5001770100001)(19580395003)(36756003)(5001960100002)(106356001)(107886002)(83506001)(105586002)(189998001)(106116001)(77096005)(4001350100001)(82746002)(81156007)(11100500001)(5002640100001)(2906002)(102836003)(5004730100002)(6116002)(101416001)(87936001)(1096002)(10400500002)(1220700001)(92566002)(5008740100001)(586003)(86362001)(83716003)(66066001)(1941001)(122556002)(40100003)(2950100001)(76176999)(54356999)(19580405001)(33656002)(50986999)(2501003)(2900100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1604; 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)
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: 15 Jan 2016 22:56:57.3571 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1604
Archived-At: 
Subject: Re: [netmod] Summary of "applied configuration and system-controlled entries" discussions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2016 22:57:01 -0000

DQoNClBsZWFzZSBzZWUgaW5saW5lIGJlbG93Lg0KDQpLZW50IC8vIGFzIGEgY29udHJpYnV0b3IN
Cg0KDQoNCg0KDQoNCg0KT24gMS8xNS8xNiwgMzozNiBQTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2Yg
R2VydCBHcmFtbWVsIiA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGdncmFt
bWVsQGp1bmlwZXIubmV0PiB3cm90ZToNCg0KPlJvYiwNCj4NCj5UaGFuayB5b3UgZm9yIHRoZSBl
ZmZvcnQsIGl0wrlzIHJlYWxseSB1c2VmdWwuDQo+DQo+R2VydA0KPg0KPk9uIDIwMTYtMTUtMDEg
MTk6MjEsICJuZXRtb2Qgb24gYmVoYWxmIG9mIFJvYmVydCBXaWx0b24iDQo+PG5ldG1vZC1ib3Vu
Y2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiByd2lsdG9uQGNpc2NvLmNvbT4gd3JvdGU6DQo+DQo+
PkhpLA0KPj4NCj4+T3ZlciB0aGUgbGFzdCB3ZWVrIG9yIHNvIHRoZXJlIGhhcyBiZWVuIHF1aXRl
IGEgbG90IG9mIGRpc2N1c3Npb24gYW5kDQo+PmxvbmdzIHRocmVhZHMgcmVnYXJkaW5nIGFwcGxp
ZWQgY29uZmlndXJhdGlvbiBhbmQgc3lzdGVtLWNvbnRyb2xsZWQNCj4+ZW50cmllcy4NCj4+DQo+
PlRvIHRyeSBhbmQgYnJpbmcgdGhhdCB0aHJlYWQgdG8gYW4gZXhwbGljaXQgY29uY2x1c2lvbiBJ
IGhhdmUgdHJpZWQgdG8NCj4+c3VtbWFyaXplIChhdCBsZWFzdCBmcm9tIG15IFBPVikgd2hlcmUg
SSB0aGluayB0aGVzZSBkaXNjdXNzaW9ucyBoYXZlDQo+PnJlYWNoZWQsIGhvcGVmdWxseSBnZXQg
ZmVlZGJhY2sgZnJvbSBvdGhlcnMsIGFuZCBtYWtlIGFueSB1cGRhdGVzIHRvIHRoZQ0KPj5yZXF1
aXJlbWVudCBkcmFmdCB0aGF0IG1heSBiZSByZXF1aXJlZC4NCj4+DQo+PkkgdGhpbmsgdGhhdCB0
aGVyZSB3ZXJlIGJyb2FkbHkgdGhyZWUgZGlmZmVyZW50IHRocmVhZHMgdG8gdGhlDQo+PmRpc2N1
c3Npb25zOg0KPj4NCj4+DQo+PjEpIExhZGEgcmVxdWVzdGVkIHRoYXQgdGhlIHJlcXVpcmVtZW50
IHRleHQgaW4gcmVxdWlyZW1lbnQgMUQgYmUNCj4+bG9vc2VuZWQgc28gdGhhdCB0aGUgYXBwbGll
ZCBjb25maWd1cmF0aW9uIHNjaGVtYSBkb2Vzbid0IGhhdmUgdG8gYmUgYQ0KPj5zdWJzZXQgb2Yg
dGhlIGludGVuZGVkIGNvbmZpZ3VyYXRpb24gc2NoZW1hLiAgVGhlIGFpbSBvZiB0aGUgbG9vc2Vu
aW5nDQo+Pm9mIHRoaXMgdGV4dCBpcyB0byBhbGxvdyBzeXN0ZW0tY29udHJvbGxlZCBlbnRpdGll
cyAoc3VjaCBhcyBpbnRlcmZhY2VzDQo+PnRoYXQgYWx3YXlzIGV4aXN0KSB0byBiZSBwdXQgaW4g
dGhlIGFwcGxpZWQgY29uZmlndXJhdGlvbi4NCj4+DQo+PlBlcnNvbmFsbHksIEknbSBvcHBvc2Vk
IHRvIHRoaXMgY2hhbmdlLCBzaW5jZSB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4NCj4+aW50ZW5k
ZWQgYW5kIGFwcGxpZWQgd2FzIGV4cGxpY2l0bHkgZGlzY3Vzc2VkIGFuZCBpdCB3YXMgY29uZmly
bWVkIHRoYXQNCj4+dGhlIHNjaGVtYSBmb3IgdGhlIHR3byB3YXMgZXhwZWN0ZWQgdG8gYmUgdGhl
IHNhbWUgc28gdGhhdCB0aGV5IGNhbiBiZQ0KPj5lYXNpbHkgY29tcGFyZWQuDQo+Pg0KPj5JcyB0
aGVyZSBhbnkgb3RoZXIgc3VwcG9ydCBmb3IgbG9vc2VuaW5nIHRoZSByZXF1aXJlbWVudCB0ZXh0
IGFzIHBlcg0KPj5MYWRhJ3Mgc3VnZ2VzdGlvbj8NCj5HZXJ0PiAoMSkgSW4gbXkgcmVzcG9uc2Ug
dG8gTGFkYSwgSSBleHByZXNzZWQgdGhlIHZpZXcgdGhlIHRleHQgaW4gMUQNCj5hbGxvd2VkIHRo
ZSB1c2UgY2FzZSBoZSBoYWQgaW4gbWluZC4gSW4gaGlzIGNhc2UgdGhlcmUgaXMgbm8gaW50ZW5k
ZWQNCj5jb25maWcgcHVzaGVkIHRvIHRoZSBzZXJ2ZXIsIGhlbmNlIHRoZXJlIGlzIG5vICJjb3Jy
ZXNwb25kaW5nIGFwcGxpZWQNCj5jb25maWd1cmF0aW9uwrIuIFRoYXQgc2FpZCBJIGRvbsK5dCBz
ZWUgdGhlIG5lZWQgdG8gY2hhbmdlIHRoZSB3b3JkaW5nIGJ1dA0KPndvdWxkIGFyZ3VlIHRoYXQg
TGFkYcK5cyB1c2UgY2FzZSBpcyBjb3ZlcmVkIGJ5IHRoZSBjdXJyZW50IHRleHQgKHNlZSBhbHNv
DQo+KDIpKS4NCg0KS2VudD4gQWdyZWVkLCBzbyBsZXTigJlzIGNvbmNsdWRlIHRoaXMgaXNzdWUg
YXMgREVBRC4NCg0KDQoNCj4+SG93ZXZlciwgdGhlcmUgaXMgc3RpbGwgYSByZWxhdGVkIGNvcm5l
ciBjYXNlIHRoYXQgaGFzbid0IGJlZW4gcmFpc2VkDQo+PnlldCwgYnV0IG1heSBiZSB1c2VmdWwg
dG8gY29uc2lkZXIsIHdoaWNoIGlzIHdoZXJlIGEgc3lzdGVtcyBkZWZhdWx0DQo+PnNldHRpbmcg
ZGlmZmVycyBmcm9tIHRoZSBvbmUgZGVmaW5lZCBpbiBhbiBhc3NvY2lhdGVkIFlBTkcgbW9kdWxl
Lg0KPj4NCj4+VG8gdGFrZSBhbiBleGFtcGxlLCBhIFlBTkcgbW9kdWxlIGZvciBMTERQIG1pZ2h0
IHVzZSBhIGdsb2JhbA0KPj5QLWNvbnRhaW5lciB0byBpbmRpY2F0ZSB3aGV0aGVyIHRoZSBMTERQ
IHByb3RvY29sIGlzIGVuYWJsZWQgb24gdGhlDQo+PmRldmljZS4gIEhvd2V2ZXIsIGZvciBhIHBh
cnRpY3VsYXIgdmVuZG9ycyBkZXZpY2UsIHRoZSBkZWZhdWx0IGJlaGF2aW91cg0KPj5mb3IgTExE
UCBtYXkgYmUgdGhhdCBpcyBlbmFibGVkIGdsb2JhbGx5Lg0KPkdlcnQ+IGluZGVlZCBhIHZhbGlk
IHNjZW5hcmlvDQoNCktlbnQ+IFNlZW1zIGxpa2UgYSBidWcgZWl0aGVyIGluIHRoZSBtb2R1bGUg
b3IgdGhlIHZlbmRvcuKAmXMgaW1wbGVtZW50YXRpb24gb2YgdGhlIG1vZHVsZS4NCg0KDQo+Pklm
IGEgb3BlcmF0b3IgaXMgY29uZmlndXJpbmcgdGhlIGRldmljZSB2aWEgWUFORyBhbmQgcHVzaGVz
IGRvd24gdGhlaXINCj4+aW5pdGlhbCBjb25maWcgKHVzaW5nIGEgY29uZmlnIHJlcGxhY2Ugc2Vt
YW50aWNzIHRvIHJlcGxhY2UgdGhlIGVudGlyZQ0KPj5leGlzdGluZyBjb25maWd1cmF0aW9uIG9m
IHRoZSBkZXZpY2UpLCBhbmQgdGhlIGNvbmZpZyB0aGF0IGlzIHB1c2hlZA0KPj5kb3duIGRvZXNu
J3QgaW5jbHVkZSB0aGUgUC1jb250YWluZXIgdG8gZXhwbGljaXRseSBlbmFibGUgTExEUCB0aGVu
IEkNCj4+dGhpbmsgdGhlIGV4cGVjdGF0aW9uIGlzIHRoYXQgdGhlIGRldmljZSBzaG91bGQgZGlz
YWJsZSBMTERQIHdoZW4NCj4+cHJvY2Vzc2luZyB0aGUgY29uZmlnIHJlcXVlc3QgKGV2ZW4gdGhv
dWdoIGl0IHRoZSBkZXZpY2UncyBkZWZhdWx0KS4NCj4+RnVydGhlciwgYWxsIHRoZSB0aW1lIHRo
YXQgdGhlIGRldmljZSBkb2Vzbid0IG1hdGNoIHRoZSBpbXBsaWNpdA0KPj5pbnRlbmRlZCBwLWNv
bnRhaW5lciBub2RlIHN0YXRlIChvZiBub24tZXhpc3RlbmNlKSwgaXQgc2hvdWxkIHJlcG9ydCBh
bg0KPj5hcHBsaWVkIHAtY29udGFpbmVyIG5vZGUgdG8gaW5kaWNhdGUgdGhhdCBMTERQIGlzIGFj
dHVhbGx5IGVuYWJsZWQgb24NCj4+dGhlIGRldmljZSBldmVuIHRob3VnaCB0aGUgaW50ZW5kZWQg
YmVoYXZpb3VyIGlzIHRoYXQgaXQgYmUgZGlzYWJsZWQuDQo+Pg0KPj5JbiBlc3NlbmNlIEknbSBz
YXlpbmcgdGhhdCB0aGUgaW50ZW5kZWQgY29uZmlndXJhdGlvbiBpbmNsdWRlcyBhbGwNCj4+ZXhw
bGljaXQgZGF0YSBub2RlcywgYW55IGRlZmF1bHQgbm9kZSB2YWx1ZXMgaW4gc2NvcGUsIGFuZCBh
bHNvIGFueQ0KPj5ub2RlcyBpbiBzY29wZSB0aGF0IGhhdmUgYW4gaW1wbGljaXQgc2NoZW1hIGRl
ZmF1bHQgdmFsdWUgb2YNCj4+bm9uLWV4aXN0ZW5jZSAoaS5lLiB0aGUgZmVhdHVyZSBpcyBub3Qg
ZW5hYmxlZCkuDQo+Pg0KPj5EbyBvdGhlcnMgYWdyZWUgd2l0aCBteSBpbnRlcnByZXRhdGlvbiBv
ZiBpbnRlbmRlZCBjb25maWd1cmF0aW9uIGZvcg0KPj50aGlzIHNjZW5hcmlvPw0KPkdlcnQ+ICgy
KSBQZXJoYXBzIHdlIHNob3VsZCB0byBkaXN0aW5ndWlzaCB0aGUgbW9kZWxsaW5nIGFzcGVjdCBm
cm9tIHRoZQ0KPnVzYWdlIGFzcGVjdDoNCj4tbW9kZWxpbmc6IFdoYXRldmVyIHRoZSBtb2RlbCBj
b250YWlucyBhcyBhcHBsaWVkIHN0YXRlIHNob3VsZCBhbHNvDQo+bW9kZWxsZWQgYXMgaW50ZW5k
ZWQgc3RhdGUgYW5kIHNob3VsZCBhbHNvIGluY2x1ZGUgZGVmYXVsdCB2YWx1ZXMgKGd1ZXNzDQo+
dGhpcyBpcyBpbiBsaW5lIHdpdGggeW91ciB1bmRlcnN0YW5kaW5nKQ0KPi11c2FnZTogQSBjbGll
bnQgbWF5IG5vdCBtYWtlIGZ1bGwgdXNlIG9mIGludGVuZGVkIGNvbmZpZ3VyYXRpb24gZm9yIGEN
Cj5naXZlbiBzZXJ2ZXIgYW5kIGNvdWxkIHJlbHkgdXBvbiBkZWZhdWx0IHZhbHVlcyBpbiB0aGUg
YXBwbGllZCBjb25maWcuIEluDQo+dGhhdCBjYXNlIHRoZSBpbnRlbmRlZCBjb25maWcgKGluIHVz
ZSkgY292ZXJzIGEgc3Vic2V0IG9mIHRoZSBhcHBsaWVkDQo+Y29uZmlnIChzZWUgKDEpKS4NCg0K
SeKAmW0gbm90IGNvbnZpbmNlIHRoaXMgbmVlZHMgdG8gc29sdmVkIChzZWUgYWJvdmUpDQoNCg0K
DQo+PjIpIFNlcGFyYXRlbHksIHRoZXJlIGhhcyBiZWVuIGEgc3VnZ2VzdGlvbiBmcm9tIExhZGEg
KGFsc28gc3VwcG9ydGVkIGJ5DQo+PkdlcnQ/KSBzdWNoIHRoYXQgdGhlIGFwcGxpZWQgY29uZmln
dXJhdGlvbiBhbHdheXMgZXhwbGljaXRseSByZXBvcnRzDQo+PmRlZmF1bHQgdmFsdWVzIChlLmcu
IGxpa2UgdGhlIHJlcG9ydC1hbGwgb3B0aW9uIGluIFJGQyA2MjQzKS4NCj4+DQo+PkkgZ2VuZXJh
bGx5IHN1cHBvcnQgdGhpcyBzdWdnZXN0aW9uIGJlY2F1c2UgSSB0aGluayBpdCBzb2x2ZXMgdGhl
DQo+PnByb2JsZW0gdGhhdCBhIHNlcnZlciBjYW4ndCBpbmRpY2F0ZSBhIGRpZmZlcmVuY2UgYmV0
d2VlbiBhIGxlYWYgbm90DQo+PmJlaW5nIGNvbmZpZ3VyZWQgYXQgYWxsIGFuZCBsZWFmIHRoYXQg
aXMgY29uZmlndXJlZCB3aXRoIHRoZSBkZWZhdWx0DQo+PnZhbHVlLiAgSG93ZXZlciwgSSB3b3Vs
ZCBzZWUgaXQgdGhhdCB0aGUgWUFORyBzY2hlbWEgZm9yIGJvdGggaW50ZW5kZWQNCj4+YW5kIGFw
cGxpZWQgY29uZmlndXJhdGlvbiBpcyBzdGlsbCB0aGUgc2FtZSwgYW5kIGhlbmNlIEkgZG9uJ3Qg
c2VlIGFueQ0KPj5kaXJlY3QgbmVlZCB0byBtb2RpZnkgdGhlIHJlcXVpcmVtZW50cyBkcmFmdC4g
IEkgdGhpbmsgdGhhdCBhbGwgdGhyZWUNCj4+cHJvcG9zZWQgc29sdXRpb25zIGFyZSBhYmxlIHRv
IHN1cHBvcnQgdGhpcywgYW5kIGhlbmNlIHRoaXMgaXNzdWUgY2FuDQo+PnByb2JhYmx5IGJlIGRl
ZmVycmVkIHVudGlsIGEgZ2VuZXJhbCBzb2x1dGlvbiBhcHByb2FjaCBoYXMgYmVlbiBhZ3JlZWQu
DQo+Pg0KPj5JcyBhbnlvbmUgYWdhaW5zdCBkZWZlcnJpbmcgdGhpcyBkaXNjdXNzaW9uIHVudGls
IGEgZ2VuZXJhbCBzb2x1dGlvbg0KPj5hcHByb2FjaCBoYXMgYmVlbiBhZ3JlZWQ/DQo+R2VydD4g
dG9vIG1hbnkgbmVnYXRpb25zIGluIHRoaXMgcGhyYXNlIHRvIGFuc3dlciB3aXRoIGEgc2ltcGxl
IHllcyBvciBubw0KPjotKS4gSSBhbSBpbiBmYXZvdXIgb2YgZGVmZXJyaW5nDQoNCkFzIEp1ZXJn
ZW4gcG9pbnRzIG91dCwgdGhlIHdpdGgtZGVmYXVsdHMgY292ZXJzIHRoaXMuDQoNCg0KDQo+PjMp
IEZpbmFsbHksIHRoZXJlIGhhcyBiZWVuIHNvbWUgcHJvcG9zYWxzIG9uIHRoZSBleGFjdCBzZW1h
bnRpY3Mgb2YgaG93DQo+PnRoZSBjb25maWcgaGFuZGxpbmcgc2hvdWxkIHdvcmssIGJ1dCB0aGlz
IGhhcyBiZWVuIGFncmVlZCB0byBiZSBkZWZlcnJlZA0KPj51bnRpbCB0aGUgYmFzaXMgZm9yIGEg
c29sdXRpb24gaGFzIGJlZW4gY2hvc2VuLg0KPkdlcnQ+IGFsc28gaGVyZSBJIGFtIGluIGZhdm91
ciBvZiBkZWZlcnJpbmcNCg0KQWdyZWVkLg0KDQoNCg0KVGhlIG5ldC1uZXQgYXMgSSAoZWRpdG9y
KSBzZWUgaXQsIGlzIHRoYXQgbm8gY2hhbmdlIHRvIHRoZSByZXF1aXJlbWVudHMgZHJhZnQgaXMg
ZXhwZWN0ZWQgdG8gcmVmbGVjdCBhbnkgb2YgdGhlIGFib3ZlLg0KDQoNCg0KDQpUaGFua3MgYWdh
aW4sDQpLZW50DQoNCg==


From nobody Fri Jan 15 15:15:55 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC8D1B33A2 for ; Fri, 15 Jan 2016 15:15:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EL3gFSHQW8f3 for ; Fri, 15 Jan 2016 15:15:51 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0142.outbound.protection.outlook.com [65.55.169.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62FAB1B33A1 for ; Fri, 15 Jan 2016 15:15:49 -0800 (PST)
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 (TLS) id 15.1.365.19; Fri, 15 Jan 2016 23:15:46 +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.0365.023; Fri, 15 Jan 2016 23:15:47 +0000
From: Kent Watsen 
To: Juergen Schoenwaelder , "Robert Wilton" 
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt
Thread-Index: AQHRRz2lEErWj+iSeUCXhpFM5+aasZ7rnI4AgAG85wCAAAG/gIAArbcAgAByIgCAAcDigIAAFjCAgAD+4QCAAEX4AIAAEJIAgAL8DACAAY0PAIAABrUAgAanCQCAAAqUAIAACg6A
Date: Fri, 15 Jan 2016 23:15:47 +0000
Message-ID: 
References:  <20160107160521.GC28062@elstar.local> <568E9F5D.3030500@cisco.com> <20160108083659.GA29486@elstar.local>   <20160110112122.GA39699@elstar.local> <56938BC6.80707@cisco.com> <20160111112629.GA41791@elstar.local> <56992602.7020700@cisco.com> <20160115173946.GA187@elstar.local>
In-Reply-To: <20160115173946.GA187@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.151105
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.13]
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 5:uECjqjjJx/bA57L8rhqL031X64MkEj4z1sxmqEq4sR3gmMYHz7EuZgzaktsz5xgd2kuKQJ2y38XTOFIQDLdRsR+Q49Lk5mXbW27GTjCZSo3brYvWpCBF90qQdaCNaPpeCpmwPkHbDdEQsZMiK2wBzA==; 24:/ltTqDc7ABjJMl+VssG8SyC51zh4b9v13W0kyyE52R7R/O3erVd2DcL3iXvobfr5zLVD73ochGhZkmHIj5ISmzkE71lPI9owHX052rbJVg8=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1443;
x-ms-office365-filtering-correlation-id: d186e1fb-ec97-414c-2c99-08d31e01cd23
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001)(10201501046); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; 
x-forefront-prvs: 08220FA8D6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(164054003)(51444003)(199003)(57704003)(40100003)(93886004)(54356999)(4326007)(36756003)(76176999)(586003)(2906002)(122556002)(10400500002)(189998001)(5001960100002)(50986999)(2950100001)(33656002)(1096002)(1220700001)(106356001)(97736004)(230783001)(106116001)(87936001)(81156007)(86362001)(5002640100001)(105586002)(5001770100001)(83506001)(6116002)(102836003)(5008740100001)(5004730100002)(92566002)(82746002)(83716003)(4001350100001)(3846002)(66066001)(77096005)(99286002)(101416001)(2900100001)(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:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <6EECBF603E303141A86A6F78426E0269@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2016 23:15:47.1994 (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: "netmod@ietf.org" 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2016 23:15:54 -0000

DQoNCg0KDQoNCj4+dG86DQo+PiANCj4+ICAgIDQuICBBYmlsaXR5IHRvIHJlbGF0ZSBjb25maWd1
cmF0aW9uIHdpdGggaXRzIGNvcnJlc3BvbmRpbmcNCj4+ICAgICAgICBvcGVyYXRpb25hbCBzdGF0
ZQ0KPj4gDQo+PiAgICAgICAgQS4gIEFiaWxpdHkgdG8gcmVsYXRlIGludGVuZGVkIGNvbmZpZyBu
b2RlcyB3aXRoIGNvcnJlc3BvbmRpbmcgDQo+PiAgICAgICAgYXBwbGllZA0KPj4gICAgICAgICAg
ICBjb25maWcgbm9kZXMNCj4+IA0KPj4gICAgICAgIEIuICBBYmlsaXR5IHRvIHJlbGF0ZSBhcHBs
aWVkIGNvbmZpZyBub2RlcyB3aXRoIGFzc29jaWF0ZWQgZGVyaXZlZA0KPj4gICAgICAgICAgICBz
dGF0ZSBub2Rlcw0KPj4gDQo+PiAgICAgICAgQy4gIFRoZSByZWxhdGlvbnNoaXBzIG5lZWRzIHRv
IGJlIHByb2dyYW1tYXRpY2FsbHkgY29uc3VtYWJsZQ0KPj4gDQo+PiANCj4+IEFyZSB0aGVyZSBh
bnkgb3RoZXIgdmlld3Mgb24gd2hldGhlciB0aGlzIHJlcXVpcmVtZW50IHRleHQgc2hvdWxkIGJl
IA0KPj4gdXBkYXRlZD8NCj4+DQo+DQo+SSB0aGluayB0aGUgbmV3IHdvcmRpbmcgaXMgYW4gaW1w
cm92ZW1lbnQuDQoNCkkgYWdyZWUgYW5kIHZpZXcgdGhpcyBhcyBhbiBlZGl0b3JpYWwgZml4Lg0K
DQoNCiAgDQo+PiA+PlBlcnNvbmFsbHksIEkgdGhpbmsgdGhhdCB0aGUgcmVsYXRpb25zaGlwIHNo
b3VsZCBiZSBleHByZXNzZWQgaW4gdGhlDQo+PiA+PnJldmVyc2UgZGlyZWN0aW9uLiAgSS5lLiBh
IHBhcnRpY3VsYXIgbm9kZSBvZiBkZXJpdmVkIHN0YXRlIHNob3VsZCBiZQ0KPj4gPj5hbGxvd2Vk
IHRvIHJlZmVyIGJhY2sgdG8gdGhlIGNvbmZpZyAoaW50ZW5kZWQvYXBwbGllZCkgdGhhdCBpcyBk
ZXJpdmVkDQo+PiA+PmZyb20uICBUaGlzIGlzIHByZXN1bWFibHkgYW4gaW1wbGVtZW50YXRpb24g
ZGV0YWlsIHJhdGhlciB0aGFuIGENCj4+ID4+cmVxdWlyZW1lbnQuDQo+PiA+WWVzLCBJIHdyb3Rl
IGFib3V0IHRoaXMgZWFybGllciAtIHNvbWUgc2V2ZXJhbCB3ZWVrcyBhZ28uIFdoYXQgaXMNCj4+
ID5yZWFsbHkgaGVscGZ1bCBmb3IgYSBtYW5hZ2luZyBzeXN0ZW0gaXMgdG8ga25vdyB0aGUgc291
cmNlIG9mIGRlcml2ZWQNCj4+ID5zdGF0ZSwgYmUgaXQgYXBwbGllZCBjb25maWcsIGJlIGl0IGEg
cm91dGluZyBwcm90b2NvbCBkYWVtb24sIGJlIGl0IGENCj4+ID5kaGNwIHNlcnZlciwgYmUgaXQg
YSBwaWVjZSBvZiB0dW5uZWxpbmcgc29mdHdhcmUsIGJlIGl0IGFuIEkyUlMNCj4+ID5hZ2VudC4g
U28geWVzLCBJIGFncmVlIHdpdGggeW91IHRoYXQgdGhlIHJldmVyc2UgZGlyZWN0aW9uIGlzDQo+
PiA+ZGVzaXJhYmxlIChlLmcuLCBoYXZlIG1ldGEgZGF0YSBmb3IgZGVyaXZlZCBzdGF0ZSB0aGF0
IGV4cGxhaW5zIHdoZXJlDQo+PiA+dGhlIHN0YXRlIGlmIG9yaWdpbmF0aW5nIGZyb20pLiBXaGF0
IEkgYWxzbyBleHBsYWluZWQgYmFjayB0aGVuIGlzDQo+PiA+dGhhdCBhIHN0YW5kYXJkIExpbnV4
IGtlcm5lbCBkb2VzIG5vdCB0cmFjayB0aGlzIGNvbnRleHQgZm9yIG1hbnkNCj4+ID5yZXNvdXJj
ZXMsIHdoaWNoIG1ha2VzIHRoaXMgc29tZXdoYXQgZGlmZmljdWx0ICg9IGV4cGVuc2l2ZSkgdG8N
Cj4+ID5pbXBsZW1lbnQuIEJ1dCB5ZXMsIGZyb20gYSBtYW5hZ2VtZW50IHBvaW50IHBlcnNwZWN0
aXZlLCBrbm93aW5nIHRoZQ0KPj4gPnNvdXJjZSBvZiBkZXJpdmVkIHN0YXRlIGlzIHRydWx5IGhl
bHBmdWwgaW4gbXkgZXhwZXJpZW5jZS4NCj4+IA0KPj4gVGhlcmUgc2VlbSB0byBiZSB0d28gc2Vw
YXJhdGUgYW5nbGVzIHRvIHRoaXM6DQo+PiANCj4+ICgxKSBBbGxvd2luZyB0aGUgc2NoZW1hIHRv
IGV4cHJlc3MgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIGRlcml2ZWQgDQo+PiBzdGF0ZSBhbmQg
Y29uZmlnIG5vZGVzLiAgVGhpcyBlZmZlY3RpdmVseSBhbGxvd3MgdGhlIG9wZXJhdG9yIHRvIGtu
b3cgDQo+PiB0aGF0IGlmIHRoZXkgY2hhbmdlIGEgcGFydGljdWxhciBjb25maWcgaXRlbSwgd2hp
Y2ggZGVyaXZlZCBzdGF0ZSBmaWVsZHMgDQo+PiB0aGV5IG1heSB3YW50IHRvIGNoZWNrIHRvIGVu
c3VyZSB0aGF0IHRoZSBjb25maWcgY2hhbmdlIGhhcyBiZWVuIGVuYWN0ZWQgDQo+PiBjb3JyZWN0
bHkuICBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhpcyBpcyB3aGF0IHRoZSByZXF1aXJlbWVu
dHMgaW4gDQo+PiBzZWN0aW9uIDQgb2YgdGhlIHJlcXVpcmVtZW50cyBkcmFmdCBhcmUgYWRkcmVz
c2luZy4NCj4NCj5UaGlzIGRpcmVjdGlvbiBvZiB0aGUgcmVsYXRpb25zaGlwIG1pZ2h0IGluIHNv
bWUgY2FzZXMgYmUgYSByZWxhdGl2ZWx5DQo+dHJpdmlhbCBhbmQgcHJlZGljdGFibGUgMToxIHJl
bGF0aW9uc2hpcCwgaW4gb3RoZXIgY2FzZXMgaXQgbWF5IGJlDQo+bW9yZSBjb21wbGV4IGFuZCBp
biB0aGUgd29yc3QgY2FzZSBkeW5hbWljYWxseSBjaGFuZ2luZy4NCg0KSXQgWUFORyBtb2R1bGUg
Y291bGQgc3VwcG9ydCAxOk4gYnkgaGF2aW5nIGEgbGlzdCBvZiBhc3NvY2lhdGVkIGRlcml2ZWQg
c3RhdGUgcmVsYXRpb25zaGlwcy4gIEkgZG9u4oCZdCBnZXQgdGhlIGR5bmFtaWNhbGx5IGNoYW5n
aW5nIHBhcnQsIGFyZSB5b3Ugc2F5aW5nIHRoZSBkZXJpdmVkIHN0YXRlIGNhbiByYW5kb21seSBh
cHBlYXIgYW55d2hlcmU/DQoNCg0KDQoNCj4+ICgyKSBPcHRpb25hbCBtZXRhLWRhdGEgYW5ub3Rh
dGlvbnMgdG8gdGhlIGRlcml2ZWQgc3RhdGUgdGhhdCBpbmRpY2F0ZXMgDQo+PiBmb3IgYSBzcGVj
aWZpYyBub2RlIGluIHRoZSBkYXRhIHRyZWUgd2hhdCBpcy9hcmUgdGhlIHNvdXJjZXMgZm9yIHRo
YXQgDQo+PiBub2RlcyBleGlzdGVuY2UvdmFsdWUuICBJIGFncmVlIHRoYXQgdGhpcyBkb2VzIHNl
ZW0gdXNlZnVsLCBidXQgbXkgaHVuY2ggDQo+PiBpcyB0aGF0IHZlcnkgZmV3IHN5c3RlbXMgd291
bGQgYmUgYWJsZSB0byB0cmFjayBvciBwcm92aWRlIHRoaXMgDQo+PiBpbmZvcm1hdGlvbiB0b2Rh
eS4gIE15IG5haXZlIGltcHJlc3Npb24gaXMgdGhhdCB0aGlzIHdvdWxkIGJlIG1vcmUgDQo+PiBk
aWZmaWN1bHQgZm9yIHN5c3RlbSB2ZW5kb3JzIHRvIGltcGxlbWVudCB0aGFuIHRoZSBhcHBsaWVk
IGNvbmZpZ3VyYXRpb24gDQo+PiBub2Rlcy4NCj4NCj5JZiB5b3UgY2FuIGRvICdhcHBsaWVkIGNv
bmZpZycgLT4gJ2Fzc29jaWF0ZWQgZGVyaXZlZCBzdGF0ZScgdGhlbiB5b3UNCj5zaG91bGQgYmUg
YWJsZSB0byBkbyAnZGVyaXZlZCBzdGF0ZScgLT4gJ2FwcGxpZWQgY29uZmlnJyBmb3IgJ2Rlcml2
ZWQNCj5zdGF0ZScgYXNzb2NpYXRlZCB3aXRoICdhcHBsaWVkIGNvbmZpZycuDQoNCkkgbWFkZSB0
aGlzIHBvaW50IGJlZm9yZSBhcyB3ZWxsLiAgIEdpdmVuIHRoZSBmb3J3YXJkIG1hcHBpbmcsIGEg
c3lzdGVtIGNvdWxkIGNhbGN1bGF0ZSB0aGUgcmV2ZXJzZSBtYXBwaW5nLi4uDQoNCg0KPkJ1dCB5
ZXMsIEkgYWdyZWUgdGhhdCAnZGVyaXZlZCBzdGF0ZScgLT4gJ2FyYml0cmFyeSBzb3VyY2Ugb2Yg
ZGVyaXZlZA0KPnN0YXRlJyBpcyB1bmZvcnR1bmF0ZWx5IHVucmVhbGlzdGljIChpbiB0aGUgZ2Vu
ZXJhbCBjYXNlKS4NCj4NCj5CVFcsIGRvIHdlIGhhdmUgYSBkZWZpbml0aW9uIG9mICdhc3NvY2lh
dGVkIGRlcml2ZWQgc3RhdGUnPyBXaGF0IGlzDQo+dGhlIHNjb3BlIG9mIHRoZSBfYXNzb2NpYXRl
ZF8gZGVyaXZlZCBzdGF0ZT8gTXkgaW50ZXJwcmV0YXRpb24gaXMgdGhhdA0KPml0IGlzIGFueSBk
ZXJpdmVkIHN0YXRlIHRoYXQgaXMgYSBfZGlyZWN0XyBjb25zZXF1ZW5jZSBvZiBzb21lIGFwcGxp
ZWQNCj5jb25maWcgYmVpbmcgYWN0aXZlIGJ1dCBpdCBkb2VzIG5vdCBpbmNsdWRlIGFueSBzdGF0
ZSBpbmRpcmVjdGx5DQo+YXNzb2NpYXRlZCB3aXRoIHNvbWUgYXBwbGllZCBjb25maWcuIChGb3Ig
ZXhhbXBsZSwgaWYgSSB0dXJuIG9uIGEgVlBODQo+c2VydmljZSwgdGhlbiB0aGUgYXNzb2NpYXRl
ZCBkZXJpdmVkIHN0YXRlIGFyZSBWUE4gc2VydmljZSBjb3VudGVycw0KPmV0Yy4gYnV0IG5vdCBs
ZXRzIHNheSBpbnRlcmZhY2VzIGR5bmFtaWNhbGx5IGNyZWF0ZWQgdmlhIHRoZSBWUE4NCj5zZXJ2
aWNlIG9wZXJhdGlvbi4pDQoNCkkgdGhpbmsgeW91ciBpbnRlcnByZXRhdGlvbiBpcyBhY2NlcHRh
YmxlLCBidXQgZG8gd2UgbmVlZCB0byBkZWZpbmUgYSB0ZXJtIG90aGVyIHRoYW4g4oCcZGVyaXZl
ZCBzdGF0ZeKAnT8NCg0KICAgRGVyaXZlZCBTdGF0ZTogIFRoaXMgZGF0YSByZXByZXNlbnRzIGlu
Zm9ybWF0aW9uIHdoaWNoIGlzIGdlbmVyYXRlZA0KICAgICAgIGFzIHBhcnQgb2YgdGhlIHNlcnZl
cidzIG93biBpbnRlcmFjdGlvbnMuICBGb3IgZXhhbXBsZSwgZGVyaXZlZA0KICAgICAgIHN0YXRl
IG1heSBjb25zaXN0IG9mIHRoZSByZXN1bHRzIG9mIHByb3RvY29sIGludGVyYWN0aW9ucyAodGhl
DQogICAgICAgbmVnb3RpYXRlZCBkdXBsZXggc3RhdGUgb2YgYW4gRXRoZXJuZXQgbGluayksIHN0
YXRpc3RpY3MgKHN1Y2ggYXMNCiAgICAgICBtZXNzYWdlIHF1ZXVlIGRlcHRoKSwgb3IgY291bnRl
cnMgKHN1Y2ggYXMgcGFja2V0IGlucHV0IG9yIG91dHB1dA0KICAgICAgIGJ5dGVzKS4NCg0KDQoN
ClNlcGFyYXRlbHksIHRoZSB0ZXJtIOKAnGRlcml2ZWQgc3RhdGXigJ0gc2VlbXMgcG9vcmx5IG5h
bWVkLiAgSSBrbm93IHRoYXQgaXQgaXMgd2hhdCB0aGUgT3BlbkNvbmZpZyBkcmFmdCBjYWxsZWQg
aXQsIGJ1dCBpdCBiZWdzIHRoZSBxdWVzdGlvbiBhcyB0byB3aGF0IHRoZSBzdGF0ZSBpcyBkZXJp
dmVkIGZyb20uICBUaG91Z2h0cyBvbiBhIGJldHRlciBuYW1lPw0KDQoNClRoYW5rcywNCktlbnQN
Cg0K


From nobody Fri Jan 15 15:36:45 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E181B33C6 for ; Fri, 15 Jan 2016 15:36: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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VKyWDAU67Qi for ; Fri, 15 Jan 2016 15:36:42 -0800 (PST)
Received: from auth-4.ukservers.net (auth-4.ukservers.net [217.10.138.158]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 650971B33C4 for ; Fri, 15 Jan 2016 15:36:42 -0800 (PST)
Received: from [192.168.0.33] (cpc13-heme10-2-0-cust400.9-1.cable.virginm.net [81.111.149.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by auth-4.ukservers.net (Postfix smtp) with ESMTPSA id 32B063762DE2; Fri, 15 Jan 2016 23:36:40 +0000 (GMT)
To: Gert Grammel , Kent Watsen , "netmod@ietf.org" 
References: <20160109005830.20805.41463.idtracker@ietfa.amsl.com>  <5693E46D.7080707@cisco.com> <3474CCCD-1B8B-40B7-B3BF-C1164C144A8F@juniper.net> <56992B46.6070308@cisco.com> 
From: Robert Wilton 
Message-ID: <56998297.70102@wilton.org.uk>
Date: Fri, 15 Jan 2016 23:36:55 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-03.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Jan 2016 23:36:44 -0000

On 15/01/2016 20:50, Gert Grammel wrote:
>
>>
>> For 2B, I agree changing MAY to SHOULD but we should broaden this to
>> apply to synchronous servers as well.  Even though a config edit
>> operation is synchronous it could still fail to be applied for some
>> leaves, and hence the intended and applied leaves could be out of step.
>> Hence I propose the following change:
>> Before:
>>
>>         B.  Servers that support asynchronous configuration operations
>>             MAY also provide a verify operation that a client can request
>>             from the server to return information regarding the
>>             difference between the intended and applied configurations.
> Gert> as per definition of synchronous, the confirmation has to indicate
> that the intended config has been applied or has been failed. I therefore
> like to keep the current text suggesting to change the existing text
> slightly (SHOULD instead of MAY):
As well as rollback-on-error, synchronous operations can still be 
continue-on-error or stop-on-error.

Under both of these semantics it is possible for the system to be left 
in a state where some of the applied config leaves do not match the 
intended config leaves. The "verify operation" is useful in this 
scenario, hence why I still think that it would be better to remove the 
condition tying the requirement to only asynchronous operations.  It is 
just a generally useful operation for opstate compliant devices.


Rob


From nobody Sat Jan 16 00:28:39 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5157D1A1AB3 for ; Sat, 16 Jan 2016 00:28:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6k5eAoGS2Tzy for ; Sat, 16 Jan 2016 00:28:36 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id AAA981A1AB1 for ; Sat, 16 Jan 2016 00:28:35 -0800 (PST)
Received: from localhost (unknown [172.29.2.201]) by trail.lhotka.name (Postfix) with ESMTPSA id 43D521CC006B; Sat, 16 Jan 2016 09:28:41 +0100 (CET)
From: Ladislav Lhotka 
To: Robert Wilton , "netmod\@ietf.org" 
In-Reply-To: <569938BB.1080705@cisco.com>
References: <569938BB.1080705@cisco.com>
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Sat, 16 Jan 2016 09:28:33 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] Summary of "applied configuration and system-controlled entries" discussions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jan 2016 08:28:38 -0000

Hi Rob,

thanks for the summary, I think it is really useful. Comments inline.

Robert Wilton  writes:

> Hi,
>
> Over the last week or so there has been quite a lot of discussion and 
> longs threads regarding applied configuration and system-controlled entries.
>
> To try and bring that thread to an explicit conclusion I have tried to 
> summarize (at least from my POV) where I think these discussions have 
> reached, hopefully get feedback from others, and make any updates to the 
> requirement draft that may be required.
>
> I think that there were broadly three different threads to the discussions:
>
>
> 1) Lada requested that the requirement text in requirement 1D be 
> loosened so that the applied configuration schema doesn't have to be a 
> subset of the intended configuration schema.  The aim of the loosening 
> of this text is to allow system-controlled entities (such as interfaces 
> that always exist) to be put in the applied configuration.
>
> Personally, I'm opposed to this change, since the relationship between 
> intended and applied was explicitly discussed and it was confirmed that 
> the schema for the two was expected to be the same so that they can be 
> easily compared.
>
> Is there any other support for loosening the requirement text as per 
> Lada's suggestion?
>

As Gert writes in his reply, 1D seems to cover the case where applied
config contains stuff that's not present in intended. That's why I
didn't propose any change.

>
>
> However, there is still a related corner case that hasn't been raised 
> yet, but may be useful to consider, which is where a systems default 
> setting differs from the one defined in an associated YANG module.
>
> To take an example, a YANG module for LLDP might use a global 
> P-container to indicate whether the LLDP protocol is enabled on the 
> device.  However, for a particular vendors device, the default behaviour 
> for LLDP may be that is enabled globally.
>
> If a operator is configuring the device via YANG and pushes down their 
> initial config (using a config replace semantics to replace the entire 
> existing configuration of the device), and the config that is pushed 
> down doesn't include the P-container to explicitly enable LLDP then I 
> think the expectation is that the device should disable LLDP when 
> processing the config request (even though it the device's default).  
> Further, all the time that the device doesn't match the implicit 
> intended p-container node state (of non-existence), it should report an 
> applied p-container node to indicate that LLDP is actually enabled on 
> the device even though the intended behaviour is that it be disabled.
>
> In essence I'm saying that the intended configuration includes all 
> explicit data nodes, any default node values in scope, and also any 
> nodes in scope that have an implicit schema default value of 
> non-existence (i.e. the feature is not enabled).
>
> Do others agree with my interpretation of intended configuration for 
> this scenario?

Yes, I think this is a relevant scenario. Yet another variation is that
the vendor might want to turn LLDP via that P-container right away after
an interface card has been plugged in. Then applied config is IMO the
right place where the P-container should appear, but then the
system-controlled interface has to be there in the first place.

Lada

>
>
>
> 2) Separately, there has been a suggestion from Lada (also supported by 
> Gert?) such that the applied configuration always explicitly reports 
> default values (e.g. like the report-all option in RFC 6243).
>
> I generally support this suggestion because I think it solves the 
> problem that a server can't indicate a difference between a leaf not 
> being configured at all and leaf that is configured with the default 
> value.  However, I would see it that the YANG schema for both intended 
> and applied configuration is still the same, and hence I don't see any 
> direct need to modify the requirements draft.  I think that all three 
> proposed solutions are able to support this, and hence this issue can 
> probably be deferred until a general solution approach has been agreed.
>
> Is anyone against deferring this discussion until a general solution 
> approach has been agreed?
>
>
>
> 3) Finally, there has been some proposals on the exact semantics of how 
> the config handling should work, but this has been agreed to be deferred 
> until the basis for a solution has been chosen.
>
> Rob
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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


From nobody Sat Jan 16 00:53:53 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1481A1B83 for ; Sat, 16 Jan 2016 00:53:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvIyxwqHXsww for ; Sat, 16 Jan 2016 00:53:50 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD1D1A1B7F for ; Sat, 16 Jan 2016 00:53:50 -0800 (PST)
Received: from localhost (unknown [172.29.2.201]) by trail.lhotka.name (Postfix) with ESMTPSA id 65D1B1CC006B; Sat, 16 Jan 2016 09:53:57 +0100 (CET)
From: Ladislav Lhotka 
To: Kent Watsen , Gert Grammel , Robert Wilton , "netmod\@ietf.org" 
In-Reply-To: 
References: <569938BB.1080705@cisco.com>  
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Sat, 16 Jan 2016 09:53:48 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] Summary of "applied configuration and system-controlled entries" discussions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jan 2016 08:53:51 -0000

Kent Watsen  writes:
>
>>>2) Separately, there has been a suggestion from Lada (also supported by
>>>Gert?) such that the applied configuration always explicitly reports
>>>default values (e.g. like the report-all option in RFC 6243).
>>>
>>>I generally support this suggestion because I think it solves the
>>>problem that a server can't indicate a difference between a leaf not
>>>being configured at all and leaf that is configured with the default
>>>value.  However, I would see it that the YANG schema for both intended
>>>and applied configuration is still the same, and hence I don't see any
>>>direct need to modify the requirements draft.  I think that all three
>>>proposed solutions are able to support this, and hence this issue can
>>>probably be deferred until a general solution approach has been agreed.
>>>
>>>Is anyone against deferring this discussion until a general solution
>>>approach has been agreed?
>>Gert> too many negations in this phrase to answer with a simple yes or no
>>:-). I am in favour of deferring
>
> As Juergen points out, the with-defaults covers this.

The with-defaults capability is quite complex, mainly because devices
deal with defaults in different ways. I think the intended-applied combo
could remove most of this complexity and provide a nice model for the
semantics of defaults: essentially, applied would work in report-all
mode, and intended in explicit mode. So the convenience of suppressed
defaults would be retained in intended configuration, but at the same
time the operator would be able to get all parameter values the device
is using from applied configuration.

Moreover, this could also cover vendor- or device-specific defaults that
are not specified in the data model (and currently can be learnt only
from documentation).

Lada

>
>
>
>>>3) Finally, there has been some proposals on the exact semantics of how
>>>the config handling should work, but this has been agreed to be deferred
>>>until the basis for a solution has been chosen.
>>Gert> also here I am in favour of deferring
>
> Agreed.
>
>
>
> The net-net as I (editor) see it, is that no change to the requirements draft is expected to reflect any of the above.
>
>
>
>
> Thanks again,
> Kent
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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


From nobody Sat Jan 16 01:15:56 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD791A1BDA for ; Sat, 16 Jan 2016 01:15:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQXc9NQebLBS for ; Sat, 16 Jan 2016 01:15:51 -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 732DE1A1BD7 for ; Sat, 16 Jan 2016 01:15:51 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9D36578A; Sat, 16 Jan 2016 10:15:49 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id rK3sEIOIEewu; Sat, 16 Jan 2016 10:15:49 +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; Sat, 16 Jan 2016 10:15:49 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 009D72002B; Sat, 16 Jan 2016 10:15:49 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 97QSYx4wyo6H; Sat, 16 Jan 2016 10:15:48 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C1AB920013; Sat, 16 Jan 2016 10:15:47 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id B8378399AAB5; Sat, 16 Jan 2016 10:15:47 +0100 (CET)
Date: Sat, 16 Jan 2016 10:15:47 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20160116091547.GB85460@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Kent Watsen , Gert Grammel , Robert Wilton , "netmod@ietf.org" 
References: <569938BB.1080705@cisco.com>   
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Summary of "applied configuration and system-controlled entries" discussions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jan 2016 09:15:54 -0000

On Sat, Jan 16, 2016 at 09:53:48AM +0100, Ladislav Lhotka wrote:
> 
> The with-defaults capability is quite complex, mainly because devices
> deal with defaults in different ways. I think the intended-applied combo
> could remove most of this complexity and provide a nice model for the
> semantics of defaults: essentially, applied would work in report-all
> mode, and intended in explicit mode. So the convenience of suppressed
> defaults would be retained in intended configuration, but at the same
> time the operator would be able to get all parameter values the device
> is using from applied configuration.
>

Some implementations do not remember whether a default value was
explicitely set not and this makes it hard to implement explicit mode
everywhere. I do not think this implementation constraint changes by
introducing applied.

With RFC 6243, the client has control, why is hardcoding the behaviour
instead an improvement? For example, if I want to diff intended and
applied, I prefer to have control over the defaults.

/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 Sat Jan 16 01:34:47 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89CB71A0019 for ; Sat, 16 Jan 2016 01:34:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.352
X-Spam-Level: 
X-Spam-Status: No, score=-5.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-WVYMy53y4v for ; Sat, 16 Jan 2016 01:34: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 5022E1A21A4 for ; Sat, 16 Jan 2016 01:34:44 -0800 (PST)
Received: from [IPv6:2a01:5e0:29:ffff:9ce6:20ed:28b6:bd08] (unknown [IPv6:2a01:5e0:29:ffff:9ce6:20ed:28b6:bd08]) by mail.nic.cz (Postfix) with ESMTPSA id 9740B181850; Sat, 16 Jan 2016 10:34:41 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1452936881; bh=aFqen5rM5Z9fS+E68tdAVkU/mir0S9t+AZdWFKGgYrU=; h=From:Date:To; b=rbOgnVl8aZqsU75BD2SneuTNarCbPUuKgRI8YET5x+JaPlVoO+7ECaiw3EnLCVQwn +VoSi4/FhfqgjMc/SBRcSXTahg3s1S86Xxv9f/5H7lRR4ersfPfPRa9CVpTy+mQR8V QE+plGaF154hg8jgA0GlPfh2syZZ/j46ZHxVfVJY=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: <20160116091547.GB85460@elstar.local>
Date: Sat, 16 Jan 2016 10:34:41 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <569938BB.1080705@cisco.com>    <20160116091547.GB85460@elstar.local>
To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Summary of "applied configuration and system-controlled entries" discussions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jan 2016 09:34:46 -0000

> On 16 Jan 2016, at 10:15, Juergen Schoenwaelder =
 wrote:
>=20
> On Sat, Jan 16, 2016 at 09:53:48AM +0100, Ladislav Lhotka wrote:
>>=20
>> The with-defaults capability is quite complex, mainly because devices
>> deal with defaults in different ways. I think the intended-applied =
combo
>> could remove most of this complexity and provide a nice model for the
>> semantics of defaults: essentially, applied would work in report-all
>> mode, and intended in explicit mode. So the convenience of suppressed
>> defaults would be retained in intended configuration, but at the same
>> time the operator would be able to get all parameter values the =
device
>> is using from applied configuration.
>>=20
>=20
> Some implementations do not remember whether a default value was
> explicitely set not and this makes it hard to implement explicit mode
> everywhere. I do not think this implementation constraint changes by
> introducing applied.

Right. I still think that some devices will not implement applied =
configuration, so this wouldn't send with-defaults into oblivion.

>=20
> With RFC 6243, the client has control, why is hardcoding the behaviour
> instead an improvement? For example, if I want to diff intended and
> applied, I prefer to have control over the defaults.

An application producing such a diff could easily filter out the =
defaults. Control over defaults is IMO important if the operator has to =
choose between readability of the configuration and ability to learn the =
values in use. Here we would have both, so why the extra complexity?

Lada

>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         

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





From nobody Sat Jan 16 02:40:05 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09C51A6FB5 for ; Sat, 16 Jan 2016 02:40:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QdTMBNNnezj for ; Sat, 16 Jan 2016 02: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 A3ED51A6FB4 for ; Sat, 16 Jan 2016 02:40:01 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6CFA9A31; Sat, 16 Jan 2016 11:40:00 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id vZSbq_GeF0yZ; Sat, 16 Jan 2016 11:39: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; Sat, 16 Jan 2016 11:39:59 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 176882002B; Sat, 16 Jan 2016 11:39:59 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Y2uqOtyDtzyM; Sat, 16 Jan 2016 11:39:57 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BDDA220013; Sat, 16 Jan 2016 11:39:56 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id B40A8399ABCB; Sat, 16 Jan 2016 11:39:56 +0100 (CET)
Date: Sat, 16 Jan 2016 11:39:56 +0100
From: Juergen Schoenwaelder 
To: Kent Watsen 
Message-ID: <20160116103956.GC85460@elstar.local>
Mail-Followup-To: Kent Watsen , Robert Wilton , "netmod@ietf.org" 
References: <568E9F5D.3030500@cisco.com> <20160108083659.GA29486@elstar.local>   <20160110112122.GA39699@elstar.local> <56938BC6.80707@cisco.com> <20160111112629.GA41791@elstar.local> <56992602.7020700@cisco.com> <20160115173946.GA187@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.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Jan 2016 10:40:03 -0000

On Fri, Jan 15, 2016 at 11:15:47PM +0000, Kent Watsen wrote:
> 
> >
> >This direction of the relationship might in some cases be a relatively
> >trivial and predictable 1:1 relationship, in other cases it may be
> >more complex and in the worst case dynamically changing.
> 
> It YANG module could support 1:N by having a list of associated derived state relationships.  I don’t get the dynamically changing part, are you saying the derived state can randomly appear anywhere?
> 

It all boils down to the definition of 'associated derived state'...

> >BTW, do we have a definition of 'associated derived state'? What is
> >the scope of the _associated_ derived state? My interpretation is that
> >it is any derived state that is a _direct_ consequence of some applied
> >config being active but it does not include any state indirectly
> >associated with some applied config. (For example, if I turn on a VPN
> >service, then the associated derived state are VPN service counters
> >etc. but not lets say interfaces dynamically created via the VPN
> >service operation.)
> 
> I think your interpretation is acceptable, but do we need to define a term other than “derived state”?
> 
>    Derived State:  This data represents information which is generated
>        as part of the server's own interactions.  For example, derived
>        state may consist of the results of protocol interactions (the
>        negotiated duplex state of an Ethernet link), statistics (such as
>        message queue depth), or counters (such as packet input or output
>        bytes).
> 
> Separately, the term “derived state” seems poorly named.  I know that it is what the OpenConfig draft called it, but it begs the question as to what the state is derived from.  Thoughts on a better name?
>

The way I personally think about the various things and terms right
now is roughly as follows (warning ascii art):

     +-----------------+
     | intended config |
     +--------v--------+
              |
  +-----------|-----------------------------------------------+
  |           | (1)                         operational state |
  |           v                                               |
  |  +-------------------------------------------+            |
  |  | applied config (static operational state) |            |
  |  +---------------v---------------------------+            |
  |                  |                                        |
  |  +---------------|------------------------------------+   |
  |  |               | (2)      dynamic operational state |   |
  |  |               v                                    |   |
  |  |  - directly derived from applied config            |   |
  |  |                                                    |   |
  |  |  - provided by the system (system controlled)      |   |
  |  |                                                    |   |
  |  |  - obtained internally from system operation       |   |
  |  |                                                    |   |
  |  |  - obtained from interactions with other systems   |   |
  |  |                                                    |   |
  |  +----------------------------------------------------+   |
  +-----------------------------------------------------------+

It is difficult to find good and crisp terms for all of these little
different elements of dynamic operational state.

I think the scope of requirement 4.B should be limited to (2) in the
figure above.  For me, it does not make sense to tag stuff only
indirectly related to a config object as derived from it since this
would quickly get huge and then start to defeat its purpose.

Conerning requirement 4, I would be very happy if I could get metadata
telling me

- this dynamic operational state has been directly derived from
  that part of applied config (e.g, this state interface exists
  because it was configured over there)

- this dynamic operational state has been provided by the system and
  is system controlled (e.g., an interface not yet configured put
  part of the system's hardware)

- this dynamic operational state has been obtained by system operation
  (e.g., interface counters, certain interface parameters discovered
  via auto-negotiation via cable or signal properties)

- this dynamic operational state has been obtained from protocol
  interactions with other systems (e.g., IP addresses obtained via
  SLAAC or DHCP, interfaces created from a VPN service, ...), ideally
  with an indication which mechanism was used

There are still borderline cases where the above classification may be
debatable (and this is likely unavoidable). The guiding principle I
would use to take a decision is the question: "What is directly
responsible for the dynamic operational state to exist?"

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Sun Jan 17 01:52:21 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64511B2EF8 for ; Sun, 17 Jan 2016 01:52:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2m6ItyGRIwsg for ; Sun, 17 Jan 2016 01:52: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 3517E1B2EFA for ; Sun, 17 Jan 2016 01:52:16 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 692D28FF; Sun, 17 Jan 2016 10:52:14 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id U7G7d8yudE5b; Sun, 17 Jan 2016 10:52: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; Sun, 17 Jan 2016 10:52:13 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B24D32002C; Sun, 17 Jan 2016 10:52:13 +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 ot5vqrj-BfKO; Sun, 17 Jan 2016 10:52:12 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC2DE20013; Sun, 17 Jan 2016 10:52:10 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 7BFCC399B0CC; Sun, 17 Jan 2016 10:52:10 +0100 (CET)
Date: Sun, 17 Jan 2016 10:52:10 +0100
From: Juergen Schoenwaelder 
To: Robert Wilton 
Message-ID: <20160117095210.GA87004@elstar.local>
Mail-Followup-To: Robert Wilton , Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" 
References: <01d301d14ef1$814dcee0$4001a8c0@gateway.2wire.net>   <20160115114924.GA12322@elstar.local> <301372A9-0333-4D56-B501-207C405C79F3@nic.cz>  <9DA7DD58-6890-4BC2-A7BE-6D6F15F1B08D@nic.cz>   <56991258.1030204@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <56991258.1030204@cisco.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] 6087bis namespace recommendations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Jan 2016 09:52:19 -0000

On Fri, Jan 15, 2016 at 03:38:00PM +0000, Robert Wilton wrote:
> 
> Since an ID is effectively superseded by any new versions, I think that 
> it is useful if a module defined in an ID has a revision date that 
> matches the published ID, and also a reference back to the ID version 
> that defines it.  At least if someone ends up implementing that module 
> they can check its provenance.  Both of these properties would also be 
> verifiable by idnits.
>

Right now, we seem in the "hey lets invent more rules mode" and
tomorrow I am sure we are again in the "hey the IETF is way to
complicated to work in" mode.

If you have a unique revision date, why is google and the like not
sufficient to find the matching I-D? Sure, the proposed rule itself
does not hurt, but an increasingly large collection of rules may start
to hurt. So please, lets try to find the minimum number of rules where
we have evidence that they avoid big problems.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Sun Jan 17 14:04:33 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 035411A8AC9 for ; Sun, 17 Jan 2016 14:04:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.2
X-Spam-Level: 
X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIByavC2Tm9P for ; Sun, 17 Jan 2016 14:04:31 -0800 (PST)
Received: from auth-4.ukservers.net (auth-4.ukservers.net [217.10.138.158]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D32B1A8AC8 for ; Sun, 17 Jan 2016 14:04:31 -0800 (PST)
Received: from [192.168.0.33] (cpc13-heme10-2-0-cust400.9-1.cable.virginm.net [81.111.149.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by auth-4.ukservers.net (Postfix smtp) with ESMTPSA id 8DA553762DA7; Sun, 17 Jan 2016 22:04:26 +0000 (GMT)
To: Ladislav Lhotka , Kent Watsen , Gert Grammel , Robert Wilton , "netmod@ietf.org" 
References: <569938BB.1080705@cisco.com>   
From: Robert Wilton 
Message-ID: <569C0FFB.8040508@wilton.org.uk>
Date: Sun, 17 Jan 2016 22:04:43 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Summary of "applied configuration and system-controlled entries" discussions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Jan 2016 22:04:33 -0000

On 16/01/2016 08:53, Ladislav Lhotka wrote:
> Kent Watsen  writes:
>>>> 2) Separately, there has been a suggestion from Lada (also supported by
>>>> Gert?) such that the applied configuration always explicitly reports
>>>> default values (e.g. like the report-all option in RFC 6243).
>>>>
>>>> I generally support this suggestion because I think it solves the
>>>> problem that a server can't indicate a difference between a leaf not
>>>> being configured at all and leaf that is configured with the default
>>>> value.  However, I would see it that the YANG schema for both intended
>>>> and applied configuration is still the same, and hence I don't see any
>>>> direct need to modify the requirements draft.  I think that all three
>>>> proposed solutions are able to support this, and hence this issue can
>>>> probably be deferred until a general solution approach has been agreed.
>>>>
>>>> Is anyone against deferring this discussion until a general solution
>>>> approach has been agreed?
>>> Gert> too many negations in this phrase to answer with a simple yes or no
>>> :-). I am in favour of deferring
>> As Juergen points out, the with-defaults covers this.
> The with-defaults capability is quite complex, mainly because devices
> deal with defaults in different ways. I think the intended-applied combo
> could remove most of this complexity and provide a nice model for the
> semantics of defaults: essentially, applied would work in report-all
> mode, and intended in explicit mode. So the convenience of suppressed
> defaults would be retained in intended configuration, but at the same
> time the operator would be able to get all parameter values the device
> is using from applied configuration.
>
> Moreover, this could also cover vendor- or device-specific defaults that
> are not specified in the data model (and currently can be learnt only
> from documentation).
Yes, I like what is being proposed by Lada.

It would be interesting to get an operators view on this.

I.e. given a choice of the applied data would they prefer:
(i) for it to be concise but have ambiguous values (default netconf 
semantics),
(ii) explicitly correct but a bit more verbose (but surely the data node 
set would be much smaller than derived state) (as proposed above).
(iii) flexible (e.g. by using something like the with-defaults extension)

Rob


From nobody Sun Jan 17 14:20:36 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1C01A8BC4 for ; Sun, 17 Jan 2016 14:20:35 -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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmV0_jC8mqRN for ; Sun, 17 Jan 2016 14:20:31 -0800 (PST)
Received: from auth-4.ukservers.net (auth-4.ukservers.net [217.10.138.158]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FC5A1A8BC3 for ; Sun, 17 Jan 2016 14:20:31 -0800 (PST)
Received: from [192.168.0.33] (cpc13-heme10-2-0-cust400.9-1.cable.virginm.net [81.111.149.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by auth-4.ukservers.net (Postfix smtp) with ESMTPSA id 8FCBF37637B1; Sun, 17 Jan 2016 22:20:27 +0000 (GMT)
To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" 
References: <01d301d14ef1$814dcee0$4001a8c0@gateway.2wire.net>   <20160115114924.GA12322@elstar.local> <301372A9-0333-4D56-B501-207C405C79F3@nic.cz>  <9DA7DD58-6890-4BC2-A7BE-6D6F15F1B08D@nic.cz>   <56991258.1030204@cisco.com> <20160117095210.GA87004@elstar.local>
From: Robert Wilton 
Message-ID: <569C13BC.6040507@wilton.org.uk>
Date: Sun, 17 Jan 2016 22:20:44 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <20160117095210.GA87004@elstar.local>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] 6087bis namespace recommendations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Jan 2016 22:20:35 -0000

On 17/01/2016 09:52, Juergen Schoenwaelder wrote:
> On Fri, Jan 15, 2016 at 03:38:00PM +0000, Robert Wilton wrote:
>> Since an ID is effectively superseded by any new versions, I think that
>> it is useful if a module defined in an ID has a revision date that
>> matches the published ID, and also a reference back to the ID version
>> that defines it.  At least if someone ends up implementing that module
>> they can check its provenance.  Both of these properties would also be
>> verifiable by idnits.
>>
> Right now, we seem in the "hey lets invent more rules mode" and
> tomorrow I am sure we are again in the "hey the IETF is way to
> complicated to work in" mode.
This was the approach that I followed when posting and updating the 
drafts that I was working on, perhaps mis-understanding the statement 
"The revision statement MUST have a reference substatement. It MUST 
identify the published document that contains the module." for which I 
presumed that the "published document" also includes the version number.


>
> If you have a unique revision date, why is google and the like not
> sufficient to find the matching I-D? Sure, the proposed rule itself
> does not hurt, but an increasingly large collection of rules may start
> to hurt. So please, lets try to find the minimum number of rules where
> we have evidence that they avoid big problems.
I'm also against having too many rules to follow, it starts to make the 
process too laborious.

My assumption is that given the relatively slow pace that standards 
models are being formally standardized that vendors/operators are likely 
to want/need to temporarily ship with pre-standard versions of the 
models.  Hence, in this case I personally feel that the additional 
clarity that is gained by explicitly referencing both date and full 
document name outweighs the slight hassle in updating it when a new 
version of the draft is posted.

Rob

>
> /js
>


From nobody Mon Jan 18 01:47:38 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835641B3378 for ; Mon, 18 Jan 2016 01:47:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKCor3e-1qY4 for ; Mon, 18 Jan 2016 01:47:35 -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 2D0301B337B for ; Mon, 18 Jan 2016 01:47:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7197; q=dns/txt; s=iport; t=1453110455; x=1454320055; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=TzfkhLFeTQgL1KHtx2dfu4M3es678tCMjjjgJFnfK0M=; b=dcbXnE2ELo0GfLardgWP6VI1FUKwX6wSKxoVIFUw+JWS1YLMzA7sxXZ7 8+yqzLGREI7KKmFcUQu7mbCQ7DKdWuCzjKGTFdpQrkogLRDrQ4pVX+Qmj qE0I4hdXOUlXwbFvV+uDkjNWMxB39r2i1fsrlTp+m5v9iTEtZkzunUmlL Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAQBXtJxW/xbLJq1djU+zPwENgWOGD?= =?us-ascii?q?wKBZBQBAQEBAQEBgQqENAEBAQMBIw8BBToGBgsLDgoCAgUWCwICCQMCAQIBRQY?= =?us-ascii?q?BDAgBAReHeAiuUo91AQEBAQEBAQMBAQEBAQEBARuBAIVVhH+EMA6DNoFJAQSHY?= =?us-ascii?q?wOFXIE0iCSNX4Feh0yFV4psg3EgAQFCgg8IF4FdPoYIgUsBAQE?=
X-IronPort-AV: E=Sophos;i="5.22,312,1449532800"; d="scan'208";a="648591091"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2016 09:47:31 +0000
Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u0I9lUTm001425; Mon, 18 Jan 2016 09:47:31 GMT
To: Kent Watsen , "netmod@ietf.org" 
References: <568E9F5D.3030500@cisco.com> <20160108083659.GA29486@elstar.local>   <20160110112122.GA39699@elstar.local> <56938BC6.80707@cisco.com> <20160111112629.GA41791@elstar.local> <56992602.7020700@cisco.com> <20160115173946.GA187@elstar.local>  <20160116103956.GC85460@elstar.local>
From: Robert Wilton 
Message-ID: <569CB4B3.3040308@cisco.com>
Date: Mon, 18 Jan 2016 09:47:31 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <20160116103956.GC85460@elstar.local>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2016 09:47:37 -0000

On 16/01/2016 10:39, Juergen Schoenwaelder wrote:
> On Fri, Jan 15, 2016 at 11:15:47PM +0000, Kent Watsen wrote:
>>> This direction of the relationship might in some cases be a relatively
>>> trivial and predictable 1:1 relationship, in other cases it may be
>>> more complex and in the worst case dynamically changing.
>> It YANG module could support 1:N by having a list of associated derived state relationships.  I don’t get the dynamically changing part, are you saying the derived state can randomly appear anywhere?
>>
> It all boils down to the definition of 'associated derived state'...
>
>>> BTW, do we have a definition of 'associated derived state'? What is
>>> the scope of the _associated_ derived state? My interpretation is that
>>> it is any derived state that is a _direct_ consequence of some applied
>>> config being active but it does not include any state indirectly
>>> associated with some applied config. (For example, if I turn on a VPN
>>> service, then the associated derived state are VPN service counters
>>> etc. but not lets say interfaces dynamically created via the VPN
>>> service operation.)
>> I think your interpretation is acceptable, but do we need to define a term other than “derived state”?
>>
>>     Derived State:  This data represents information which is generated
>>         as part of the server's own interactions.  For example, derived
>>         state may consist of the results of protocol interactions (the
>>         negotiated duplex state of an Ethernet link), statistics (such as
>>         message queue depth), or counters (such as packet input or output
>>         bytes).
>>
>> Separately, the term “derived state” seems poorly named.  I know that it is what the OpenConfig draft called it, but it begs the question as to what the state is derived from.  Thoughts on a better name?
I think that it is meant to be state derived from particular 
configuration nodes.


> The way I personally think about the various things and terms right
> now is roughly as follows (warning ascii art):
>
>       +-----------------+
>       | intended config |
>       +--------v--------+
>                |
>    +-----------|-----------------------------------------------+
>    |           | (1)                         operational state |
>    |           v                                               |
>    |  +-------------------------------------------+            |
>    |  | applied config (static operational state) |            |
>    |  +---------------v---------------------------+            |
>    |                  |                                        |
>    |  +---------------|------------------------------------+   |
>    |  |               | (2)      dynamic operational state |   |
>    |  |               v                                    |   |
>    |  |  - directly derived from applied config            |   |
>    |  |                                                    |   |
>    |  |  - provided by the system (system controlled)      |   |
>    |  |                                                    |   |
>    |  |  - obtained internally from system operation       |   |
>    |  |                                                    |   |
>    |  |  - obtained from interactions with other systems   |   |
>    |  |                                                    |   |
>    |  +----------------------------------------------------+   |
>    +-----------------------------------------------------------+
>
> It is difficult to find good and crisp terms for all of these little
> different elements of dynamic operational state.
I broadly agree with your diagram.  I don't think that applied config is 
truly static through, it could still change if say a linecard was pulled 
out (or failed).

> I think the scope of requirement 4.B should be limited to (2) in the
> figure above.  For me, it does not make sense to tag stuff only
> indirectly related to a config object as derived from it since this
> would quickly get huge and then start to defeat its purpose.

Yes, I think that this is probably right.


>
> Conerning requirement 4, I would be very happy if I could get metadata
> telling me
>
> - this dynamic operational state has been directly derived from
>    that part of applied config (e.g, this state interface exists
>    because it was configured over there)
>
> - this dynamic operational state has been provided by the system and
>    is system controlled (e.g., an interface not yet configured put
>    part of the system's hardware)
>
> - this dynamic operational state has been obtained by system operation
>    (e.g., interface counters, certain interface parameters discovered
>    via auto-negotiation via cable or signal properties)
>
> - this dynamic operational state has been obtained from protocol
>    interactions with other systems (e.g., IP addresses obtained via
>    SLAAC or DHCP, interfaces created from a VPN service, ...), ideally
>    with an indication which mechanism was used
>
> There are still borderline cases where the above classification may be
> debatable (and this is likely unavoidable). The guiding principle I
> would use to take a decision is the question: "What is directly
> responsible for the dynamic operational state to exist?"

As I understand it, what you are proposing here is not what the section 
4 requirements were intended to express.

The section 4 requirements are meant to be at the YANG schema level, 
i.e. illustrating possible relationships between YANG schema nodes. E.g. 
for a particular interface IP address they wouldn't be able to indicate 
whether it was actually configured by explicit IP address configuration 
or due to DHCP.  They would only be able to tell which configurations 
nodes could influence a particular derived state node.

I think that there are a couple of cases where this relationship is useful:
(1) If you modify a config node, it allows the client to know (in 
advance) which derived state nodes may be affected and hence should be 
retrieved to confirm the change.
(2) Conversely, if a derived state note has an unexpected value, it 
allows a client to know which configuration nodes it should retrieve to 
try and infer what the cause of the value is.


If I understand your proposal, then what you are proposing is meta-data 
annotations of the derived state nodes in the data tree. I.e. the 
annotations would allow you to tell you whether a particular interface 
IP address had that value due to explicit IP address configuration or 
because it was allocated by DHCP.  I agree that this is useful, but I 
think that it is very hard to implement (on the systems that I'm 
familiar with) and is also beyond the requirement as originally stated 
by the opstate requirements draft.

As such, I think that we should restrict the scope of the requirements 
draft (and proposed solutions) to YANG schema level annotations that are 
easier to solve.  If you agree, then do we need to tweak the text of 
requirement 4 to make this explicit?

Rob


> /js
>


From nobody Mon Jan 18 03:32:24 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BF91B350D for ; Mon, 18 Jan 2016 03:32:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fey0AhRdFW8 for ; Mon, 18 Jan 2016 03:32:19 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0105.outbound.protection.outlook.com [207.46.100.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48D8B1B350C for ; Mon, 18 Jan 2016 03:32:19 -0800 (PST)
Received: from BY1PR0501MB1605.namprd05.prod.outlook.com (10.160.203.154) by BY1PR0501MB1445.namprd05.prod.outlook.com (10.160.107.155) with Microsoft SMTP Server (TLS) id 15.1.365.19; Mon, 18 Jan 2016 11:32:16 +0000
Received: from BY1PR0501MB1605.namprd05.prod.outlook.com ([10.160.203.154]) by BY1PR0501MB1605.namprd05.prod.outlook.com ([10.160.203.154]) with mapi id 15.01.0365.023; Mon, 18 Jan 2016 11:32:16 +0000
From: Gert Grammel 
To: Robert Wilton , Kent Watsen , "netmod@ietf.org" 
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt
Thread-Index: AQHRRz2kTeoMieM3Mk+wOmX5u/maDZ7r8GIAgAFpEwCAAAG/gIAArbcAgADF9gCAAW0OgIAAFjCAgAD+4QCAAEX4AIAAEJIAgAL8DACAAY0PAIAABrUAgAanCQCABD2vZIAALfcA
Date: Mon, 18 Jan 2016 11:32:16 +0000
Message-ID: 
References: <568E9F5D.3030500@cisco.com> <20160108083659.GA29486@elstar.local>   <20160110112122.GA39699@elstar.local> <56938BC6.80707@cisco.com> <20160111112629.GA41791@elstar.local> <56992602.7020700@cisco.com> <20160115173946.GA187@elstar.local>  <20160116103956.GC85460@elstar.local> <569CB4B3.3040308@cisco.com>
In-Reply-To: <569CB4B3.3040308@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.6.0.151221
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [193.110.55.10]
x-microsoft-exchange-diagnostics: 1; BY1PR0501MB1445; 5:MYUT0qZiMd71z0PjWaFExWCdeF02G4Y4qBYzb4kKv6GInPsZH/r/qMa1YHGyjFO20xidW7YHMyM5RZuxY0qp9QBkFiw+r93NMr9rzYl5ndUzPw6/q6CuJQWsaHNBGNp+u6eTIdnuy5HjjDIlhuPGNA==; 24:GRdrbyNexcGsXh9tJ6AipEySEEbn9mZEE0A1jKG0S0ZaCL1Y77FBkqD4dBv0wz9472rrYcAyqsK0WFkWlK7nbR4vC/f43aOc9P1vUviUdIM=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1445;
x-ms-office365-filtering-correlation-id: fe78857e-8b63-44b6-734a-08d31ffb04cc
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:BY1PR0501MB1445; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1445; 
x-forefront-prvs: 08252193F3
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(57704003)(479174004)(51444003)(24454002)(377424004)(199003)(189002)(1096002)(102836003)(87936001)(107886002)(77096005)(92566002)(5001770100001)(2906002)(4001350100001)(2950100001)(11100500001)(40100003)(5008740100001)(586003)(93886004)(122556002)(2900100001)(1220700001)(5004730100002)(561944003)(15975445007)(97736004)(54356999)(10400500002)(5001960100002)(3846002)(66066001)(1941001)(50986999)(86362001)(101416001)(105586002)(81156007)(5002640100001)(230783001)(6116002)(83506001)(189998001)(99286002)(106116001)(19580405001)(19580395003)(76176999)(106356001)(36756003)(2501003)(94096001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1445; H:BY1PR0501MB1605.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)
Content-Type: text/plain; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2016 11:32:16.5725 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1445
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2016 11:32:22 -0000

On 2016-18-01 10:47, "netmod on behalf of Robert Wilton"
 wrote:

>
>
>On 16/01/2016 10:39, Juergen Schoenwaelder wrote:
>> On Fri, Jan 15, 2016 at 11:15:47PM +0000, Kent Watsen wrote:
>>>> This direction of the relationship might in some cases be a relatively
>>>> trivial and predictable 1:1 relationship, in other cases it may be
>>>> more complex and in the worst case dynamically changing.
>>> It YANG module could support 1:N by having a list of associated
>>>derived state relationships.  I don=B9t get the dynamically changing
>>>part, are you saying the derived state can randomly appear anywhere?
>>>
>> It all boils down to the definition of 'associated derived state'...
>>
>>>> BTW, do we have a definition of 'associated derived state'? What is
>>>> the scope of the _associated_ derived state? My interpretation is that
>>>> it is any derived state that is a _direct_ consequence of some applied
>>>> config being active but it does not include any state indirectly
>>>> associated with some applied config. (For example, if I turn on a VPN
>>>> service, then the associated derived state are VPN service counters
>>>> etc. but not lets say interfaces dynamically created via the VPN
>>>> service operation.)
>>> I think your interpretation is acceptable, but do we need to define a
>>>term other than =B3derived state=B2?
>>>
>>>     Derived State:  This data represents information which is generated
>>>         as part of the server's own interactions.  For example, derived
>>>         state may consist of the results of protocol interactions (the
>>>         negotiated duplex state of an Ethernet link), statistics (such
>>>as
>>>         message queue depth), or counters (such as packet input or
>>>output
>>>         bytes).
>>>
>>> Separately, the term =B3derived state=B2 seems poorly named.  I know th=
at
>>>it is what the OpenConfig draft called it, but it begs the question as
>>>to what the state is derived from.  Thoughts on a better name?
>I think that it is meant to be state derived from particular
>configuration nodes.
To me the term =8Cderived state=B9 looks good enough as it makes it clear t=
hat
the state is captured (derived) from a set of sources where applied config
is only one of them. If it comes to =B9associated derived state=B9 the exam=
ple
above could provide clarity to the reader. Tagging from where state is
derived appears a bit impractical to me, as there are often many sources
and even sequences determining dynamic state.

>
>
>> The way I personally think about the various things and terms right
>> now is roughly as follows (warning ascii art):
>>
>>       +-----------------+
>>       | intended config |
>>       +--------v--------+
>>                |
>>    +-----------|-----------------------------------------------+
>>    |           | (1)                         operational state |
>>    |           v                                               |
>>    |  +-------------------------------------------+            |
>>    |  | applied config (static operational state) |            |
>>    |  +---------------v---------------------------+            |
>>    |                  |                                        |
>>    |  +---------------|------------------------------------+   |
>>    |  |               | (2)      dynamic operational state |   |
>>    |  |               v                                    |   |
>>    |  |  - directly derived from applied config            |   |
>>    |  |                                                    |   |
>>    |  |  - provided by the system (system controlled)      |   |
>>    |  |                                                    |   |
>>    |  |  - obtained internally from system operation       |   |
>>    |  |                                                    |   |
>>    |  |  - obtained from interactions with other systems   |   |
>>    |  |                                                    |   |
>>    |  +----------------------------------------------------+   |
>>    +-----------------------------------------------------------+
>>
>> It is difficult to find good and crisp terms for all of these little
>> different elements of dynamic operational state.
>I broadly agree with your diagram.  I don't think that applied config is
>truly static through, it could still change if say a linecard was pulled
>out (or failed).
To me the diagram looks good. As discussed in other emails, an exchange of
HW would have to be reflected in applied config, as it describes the
static state of the server and HW is certainly =8Capplied=B9.


>
>> I think the scope of requirement 4.B should be limited to (2) in the
>> figure above.  For me, it does not make sense to tag stuff only
>> indirectly related to a config object as derived from it since this
>> would quickly get huge and then start to defeat its purpose.
>
>Yes, I think that this is probably right.
+1
>
>
>>
>> Conerning requirement 4, I would be very happy if I could get metadata
>> telling me
>>
>> - this dynamic operational state has been directly derived from
>>    that part of applied config (e.g, this state interface exists
>>    because it was configured over there)
>>
>> - this dynamic operational state has been provided by the system and
>>    is system controlled (e.g., an interface not yet configured put
>>    part of the system's hardware)
>>
>> - this dynamic operational state has been obtained by system operation
>>    (e.g., interface counters, certain interface parameters discovered
>>    via auto-negotiation via cable or signal properties)
>>
>> - this dynamic operational state has been obtained from protocol
>>    interactions with other systems (e.g., IP addresses obtained via
>>    SLAAC or DHCP, interfaces created from a VPN service, ...), ideally
>>    with an indication which mechanism was used
>>
>> There are still borderline cases where the above classification may be
>> debatable (and this is likely unavoidable). The guiding principle I
>> would use to take a decision is the question: "What is directly
>> responsible for the dynamic operational state to exist?"
>
>As I understand it, what you are proposing here is not what the section
>4 requirements were intended to express.
>
>The section 4 requirements are meant to be at the YANG schema level,
>i.e. illustrating possible relationships between YANG schema nodes. E.g.
>for a particular interface IP address they wouldn't be able to indicate
>whether it was actually configured by explicit IP address configuration
>or due to DHCP.  They would only be able to tell which configurations
>nodes could influence a particular derived state node.
>
>I think that there are a couple of cases where this relationship is
>useful:
>(1) If you modify a config node, it allows the client to know (in
>advance) which derived state nodes may be affected and hence should be
>retrieved to confirm the change.
>(2) Conversely, if a derived state note has an unexpected value, it
>allows a client to know which configuration nodes it should retrieve to
>try and infer what the cause of the value is.
>
>
>If I understand your proposal, then what you are proposing is meta-data
>annotations of the derived state nodes in the data tree. I.e. the
>annotations would allow you to tell you whether a particular interface
>IP address had that value due to explicit IP address configuration or
>because it was allocated by DHCP.  I agree that this is useful, but I
>think that it is very hard to implement (on the systems that I'm
>familiar with) and is also beyond the requirement as originally stated
>by the opstate requirements draft.
>
>As such, I think that we should restrict the scope of the requirements
>draft (and proposed solutions) to YANG schema level annotations that are
>easier to solve.  If you agree, then do we need to tweak the text of
>requirement 4 to make this explicit?
I have doubts on both options discussed.
What Juergen proposes appears to be useful for debugging purposes. Today
that state change information is usually found in log files. It=B9s
certainly not a perfect implementation given the zillion of entries and
accelerated wrapping of ring buffers, but something is there. That said,
it appears to me that pulling it into the YANG schema will burden the
implementation, certainly the performance of operations quite a bit. I
would be inclined to accept such a proposal as an optional extension, but
not so much as a requirement. (and agree with Rob that it is not so easy
to implement).

On the other hand, trying to identify derived state that is *possibly*
affected by a config appears to me a quite ambitious.
1) If for example a line card is supposed to be put into a state =8Cdown=B9=
,
there is probably a ton of derived state to be affected. What would a
client do with all that data other than concluding it is traffic affecting?
2) The second issue is the completeness of that information. Depending on
other state information, state change of e.g. a HW item on a server may
either bring the whole server down, or just parts of it. Always indicating
the worst case would probably render lots of actions "potentially
catastrophic=B2 and the amount of data to link to operational state will
grow quite big. It doesn=B9t appear to me that a client can do a lot to
digest this data other than picking few parameters and trying to monitor
them. Whether this is an adequate method to monitor the progress of a
complex state change is anyones guess.
3) When limiting relationship information to what usually is affected, it
would require some very educated guess, by whoever implements the schema
over what a client may see as important. Over time, everyone wants to be
on the safe side and we'll end up in 2)

On that ground I would prefer stay with requirement 4 as it is now,
without narrowing down a certain solution.
=20
>
>Rob
>
>
>> /js
>>
>
>_______________________________________________
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod


From nobody Mon Jan 18 05:56:27 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F461B373F for ; Mon, 18 Jan 2016 05:56:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhRUtukJ1WwW for ; Mon, 18 Jan 2016 05:56:24 -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 7661A1B3712 for ; Mon, 18 Jan 2016 05:56:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6640; q=dns/txt; s=iport; t=1453125383; x=1454334983; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=G9G9iiL7V1nFWvvtGpR0d2hIsLxqm8v1asDzt8gePik=; b=TuGD+W7y2NIpmL9NTmUJnfGAqDoBUVDMOAvreJLvr/xKAx2wc5Osch+1 8bTQHw4SXUPE2Ml488TLQLo/+wSkjLmyyUzDk1qv5ZSfutNo9iJnjLbka YzrT6cQJ7cmR6VKs7mQ9Z9gR051T7jXRk/XTRtzXdBvHKDPfQ+5/clxCi w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoBADW7ZxW/xbLJq1UCo1Ps1GBY4YPA?= =?us-ascii?q?oFqEwEBAQEBAQGBCoQ1AQEEMgEFOgYRCw4KCRYPCQMCAQIBRQYBDAgBAReIAL5?= =?us-ascii?q?fAQEBAQEBAQMBAQEBAQEdhlWEf4QsEoR/AQSXGo1fgV6HTIVXimyDcSQBP4ISB?= =?us-ascii?q?ReBXT6HcAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.22,312,1449532800"; d="scan'208";a="631724691"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2016 13:56:19 +0000
Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u0IDuJRF010949; Mon, 18 Jan 2016 13:56:19 GMT
To: Gert Grammel , Kent Watsen , "netmod@ietf.org" 
References: <568E9F5D.3030500@cisco.com> <20160108083659.GA29486@elstar.local>   <20160110112122.GA39699@elstar.local> <56938BC6.80707@cisco.com> <20160111112629.GA41791@elstar.local> <56992602.7020700@cisco.com> <20160115173946.GA187@elstar.local>  <20160116103956.GC85460@elstar.local> <569CB4B3.3040308@cisco.com> 
From: Robert Wilton 
Message-ID: <569CEF03.1040209@cisco.com>
Date: Mon, 18 Jan 2016 13:56:19 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2016 13:56:25 -0000

On 18/01/2016 11:32, Gert Grammel wrote:
>
>
>>> Conerning requirement 4, I would be very happy if I could get metadata
>>> telling me
>>>
>>> - this dynamic operational state has been directly derived from
>>>     that part of applied config (e.g, this state interface exists
>>>     because it was configured over there)
>>>
>>> - this dynamic operational state has been provided by the system and
>>>     is system controlled (e.g., an interface not yet configured put
>>>     part of the system's hardware)
>>>
>>> - this dynamic operational state has been obtained by system operation
>>>     (e.g., interface counters, certain interface parameters discovered
>>>     via auto-negotiation via cable or signal properties)
>>>
>>> - this dynamic operational state has been obtained from protocol
>>>     interactions with other systems (e.g., IP addresses obtained via
>>>     SLAAC or DHCP, interfaces created from a VPN service, ...), ideally
>>>     with an indication which mechanism was used
>>>
>>> There are still borderline cases where the above classification may be
>>> debatable (and this is likely unavoidable). The guiding principle I
>>> would use to take a decision is the question: "What is directly
>>> responsible for the dynamic operational state to exist?"
>> As I understand it, what you are proposing here is not what the section
>> 4 requirements were intended to express.
>>
>> The section 4 requirements are meant to be at the YANG schema level,
>> i.e. illustrating possible relationships between YANG schema nodes. E.g.
>> for a particular interface IP address they wouldn't be able to indicate
>> whether it was actually configured by explicit IP address configuration
>> or due to DHCP.  They would only be able to tell which configurations
>> nodes could influence a particular derived state node.
>>
>> I think that there are a couple of cases where this relationship is
>> useful:
>> (1) If you modify a config node, it allows the client to know (in
>> advance) which derived state nodes may be affected and hence should be
>> retrieved to confirm the change.
>> (2) Conversely, if a derived state note has an unexpected value, it
>> allows a client to know which configuration nodes it should retrieve to
>> try and infer what the cause of the value is.
>>
>>
>> If I understand your proposal, then what you are proposing is meta-data
>> annotations of the derived state nodes in the data tree. I.e. the
>> annotations would allow you to tell you whether a particular interface
>> IP address had that value due to explicit IP address configuration or
>> because it was allocated by DHCP.  I agree that this is useful, but I
>> think that it is very hard to implement (on the systems that I'm
>> familiar with) and is also beyond the requirement as originally stated
>> by the opstate requirements draft.
>>
>> As such, I think that we should restrict the scope of the requirements
>> draft (and proposed solutions) to YANG schema level annotations that are
>> easier to solve.  If you agree, then do we need to tweak the text of
>> requirement 4 to make this explicit?
> I have doubts on both options discussed.
> What Juergen proposes appears to be useful for debugging purposes. Today
> that state change information is usually found in log files. Its
> certainly not a perfect implementation given the zillion of entries and
> accelerated wrapping of ring buffers, but something is there. That said,
> it appears to me that pulling it into the YANG schema will burden the
> implementation, certainly the performance of operations quite a bit. I
> would be inclined to accept such a proposal as an optional extension, but
> not so much as a requirement. (and agree with Rob that it is not so easy
> to implement).
>
> On the other hand, trying to identify derived state that is *possibly*
> affected by a config appears to me a quite ambitious.
> 1) If for example a line card is supposed to be put into a state down,
> there is probably a ton of derived state to be affected. What would a
> client do with all that data other than concluding it is traffic affecting?
> 2) The second issue is the completeness of that information. Depending on
> other state information, state change of e.g. a HW item on a server may
> either bring the whole server down, or just parts of it. Always indicating
> the worst case would probably render lots of actions "potentially
> catastrophic and the amount of data to link to operational state will
> grow quite big. It doesnt appear to me that a client can do a lot to
> digest this data other than picking few parameters and trying to monitor
> them. Whether this is an adequate method to monitor the progress of a
> complex state change is anyones guess.
> 3) When limiting relationship information to what usually is affected, it
> would require some very educated guess, by whoever implements the schema
> over what a client may see as important. Over time, everyone wants to be
> on the safe side and we'll end up in 2)
>
> On that ground I would prefer stay with requirement 4 as it is now,
> without narrowing down a certain solution.
I'm not trying to propose solutions here, only the requirements, and I'm 
not trying to narrow or broaden the scope of the requirements at all.

I'm just trying to ensure that the understanding of requirement 4 
accurately reflects the operators actual requirement.  My understanding 
is that their requirements only concern relating nodes in the YANG 
schema, not relating data nodes in the YANG datastore.

Given that this doesn't appear to be clear to all, then it might be a 
good idea for the requirement text to be clarified to make this point 
explicit to avoid any confusion:

I.e. old:

    4.  Ability to relate configuration with its corresponding
        operational state

        A.  Ability to relate intended config nodes with corresponding
        applied config nodes

        B.  Ability to relate applied config nodes with associated derived
            state nodes

        C.  The relationships needs to be programmatically consumable


Proposed new:

    4.  Ability to relate configuration with its corresponding
        operational state

        A.  Ability to relate intended config nodes with corresponding
        applied config nodes in the YANG schema.

        B.  Ability to relate applied config nodes with associated derived
            state nodes in the YANG schema.

        C.  The relationships needs to be programmatically consumable


Rob


From nobody Mon Jan 18 09:35:01 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002B61B3B00 for ; Mon, 18 Jan 2016 09:35:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExzMd_NK72rk for ; Mon, 18 Jan 2016 09:34:58 -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 E710D1B3AFE for ; Mon, 18 Jan 2016 09:34:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3641; q=dns/txt; s=iport; t=1453138498; x=1454348098; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=tpaui/kgkjSOArRH9s2po7OQi3YDPQadfwCcmNuaprY=; b=lVqlmsY9zxB9DUeTNq3vi/NvzAnGfm89YyAhW8hF07YaMVji2//4sqP9 LoX9+P7I2UTvJ1sQ4yh+nwMwrwvWn3jfaNQDfUKGhJ3gBnCqFHdwU9fVW /aZA0UkoDNOP8e2UxMy0oOfrR0kCV2PD3ROk2XpbqyX7T3bFZxG8SSIFn U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAQDIIZ1W/xbLJq1ehHmIVrNEAQ2BY?= =?us-ascii?q?4YPAoFuFAEBAQEBAQGBCoQ1AQEEOEEQCw4CCAklDwJGBgEMBgIBARWIAr8fAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBARqGVYR/hDENhH8BBIdjhxOIJIg8hSOBXodMhVeKb?= =?us-ascii?q?INxIAEBQoISHIFdPjSFcoFKAQEB?=
X-IronPort-AV: E=Sophos;i="5.22,313,1449532800"; d="scan'208";a="631728157"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2016 17:34:55 +0000
Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u0IHYtGo021498; Mon, 18 Jan 2016 17:34:55 GMT
To: Martin Bjorklund , lhotka@nic.cz
References:  <5693C32E.7020708@cisco.com> <31E9D485-9349-448D-99A3-DD20F5E5AF09@nic.cz> <20160111.211837.377848045119250710.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: <569D223F.70209@cisco.com>
Date: Mon, 18 Jan 2016 17:34:55 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <20160111.211837.377848045119250710.mbj@tail-f.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] applied configuration and system-controlled entries
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Jan 2016 17:35:00 -0000

On 11/01/2016 20:18, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
>>> On 11 Jan 2016, at 15:58, Robert Wilton  wrote:
>>>
>>>
>>>
>>> On 11/01/2016 14:27, Ladislav Lhotka wrote:
>>>>> On 11 Jan 2016, at 15:11, Juergen Schoenwaelder
>>>>>  wrote:
>>>>>
>>>>> On Mon, Jan 11, 2016 at 02:54:36PM +0100, Martin Bjorklund wrote:
>>>>>> Ladislav Lhotka  wrote:
>>>>>>> Hi Gert,
>>>>>>>
>>>>>>>> On 11 Jan 2016, at 14:25, Gert Grammel  wrote:
>>>>>>>>
>>>>>>>> Lada,
>>>>>>>>
>>>>>>>> The requirement says:
>>>>>>>>       D.  When a configuration change for any intended configuration
>>>>>>>>           node has been successfully applied to the server (e.g. not
>>>>>>>>           failed, nor deferred due to absent hardware) then the
>>>>>>>>           existence and value of the corresponding applied
>>>>>>>>           configuration node must match the intended configuration
>>>>>>>>           node.
>>>>>>>>
>>>>>>>> I don't see that this would limit the case you described below. In
>>>>>>>> your case there is no intended config, hence there is no
>>>>>>>> "corresponding applied configuration" either.
>>>>>>> You are right, the requirement can be interpreted this way. I thought
>>>>>>> that applied configuration was supposed to be identical to intended
>>>>>>> after some synchronization period.
>>>>>> This is a very important point to clarify.  Can there ever be data in
>>>>>> "applied" that is not in "intended"?  I think Anees & Rob previously
>>>>>> said "no", but I might be wrong.
>>>>>>
>>>>> If there is time delay between editing intended and the applied config
>>>>> matching the edits of intended, then I supose this can happen (I
>>>>> delete a resource from intended but it is still around until intended
>>>>> has been fully synced). I would find it interesting if some edits are
>>>> Using applied config for system-controlled entries would require that
>>>> such an entry stays (forever) in applied config even after it has been
>>>> deleted from intended.
>>> I think that this would make life harder for clients.
>> Hmm, I would say the opposite. For one, we could simplify the data
>> models by reducing the duplicities in configuration and state trees.
> This is the old idea of having the "operational state" datastore,
> which would be all config true + all config false nodes.  One issue
> with this is that the semantics of the node is different in the
> different data stores, even if the syntax (by definition!) is the
> same.  In order to handle this properly you need either two different
> description statements, or two "sections" within the description
> statement.
>
>     list interface {
>       description-config
>         "The list of configured interfaces on the device.
>          ...";
>       description-oper
>         "The list of interfaces on the device.
>          
>          System-controlled interfaces created by the system are
>          always present in this list, whether they are configured or
>          not.
>          ...";
>     }
Having two description statements doesn't seem to be the end of the 
world.  Am I also right in presuming that the description-oper statement 
would only be need in a few areas (i.e. for system-controlled nodes)?

If we were able to align the interface config and state trees that would 
probably be a fairly significant step towards unifying the YANG models 
developed by OpenConfig and those being developed in IETF.

Rob

>
>
> /martin
> .
>


From nobody Tue Jan 19 07:12:00 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D081B303B; Tue, 19 Jan 2016 07:11:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level: 
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6Bibd-Yr6A3; Tue, 19 Jan 2016 07:11:55 -0800 (PST)
Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (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 7723D1B302D; Tue, 19 Jan 2016 07:11:55 -0800 (PST)
Received: by mail-pa0-x22b.google.com with SMTP id cy9so453016051pac.0; Tue, 19 Jan 2016 07:11:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8jTk0PzP/H0o0fTzEPZaNdQhpTEN/9K4IQu72qwQnaQ=; b=JeAVLluYkuDhiCxHzvELS2jroqTCbH0lpvTxWfedGXSbp5Kg71vjX40QN44UdQaEvO x47n9MzJNvNaS6ovDg0jDP6x6jwG0cj0r/oPe6mSpDrvmw7bEKHzc9j7siED1HLXpeSI ggNIPhmJ+47prdkEFCw+xZgubcOjVkfOnwroI0BYyHCYZyu1KbJCLGfJoyKnFNtNNxnm giNZNywfRGjE/SzIWJSaOsQM2ylINLpmlxgZ1VgeXe2dvQdlasOloHVgqNfeG6SCgtNh 6hITaMSRzizIhurAztZEWvad7BG8JlS+/WQ1mkIKKtCvJSrkVxcteogzsC/j2SruTJSb ejdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=8jTk0PzP/H0o0fTzEPZaNdQhpTEN/9K4IQu72qwQnaQ=; b=T+AAbMxpBMsX1tcwDVsJ3aR289cBQgsv/ktsST5ts+Lnn5tLXM+wq5frGPiJby1DDK MsraBPBKAspcAvlKFq3ZFZrWX3rXwqF9VfB0ik+1y2ZHcPrQYJAVrGHHXRufAFeXb04I 4oP2VRvK4YnjS2X5wbma2IfJNlfIhaIiuzFiiJ4h/BA5tFc7M5AVdzSfVzPLZOO0W/Z/ t5iLXbiR9q0tJypaiXTKNQaZ3I3gRLEtLVdrwtnlYn412vnvE/X3YZUoXrjwj4OnrtpY 90GcXu8kI4UB9VZbVirwiCo7xKmcJPCGC+8NGnxhqoKKoEawG1Dp3BT9Gdrs0HeZO76w jybQ==
X-Gm-Message-State: ALoCoQlIH2HjLrj2DGl97JNpQtc1B4bEoFo5t9NhUn21Y77MF49hOFK0xOCmlyl5IDHl0UAi3L22+xJUPwQ2d5Pu/QUcug88GQ==
X-Received: by 10.66.102.73 with SMTP id fm9mr45252342pab.32.1453216315075; Tue, 19 Jan 2016 07:11:55 -0800 (PST)
Received: from [10.0.70.127] ([209.92.66.180]) by smtp.gmail.com with ESMTPSA id m86sm42265991pfi.27.2016.01.19.07.11.53 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 19 Jan 2016 07:11:54 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Dean Bogdanovic 
In-Reply-To: <20160111183053.GA565@elstar.local>
Date: Tue, 19 Jan 2016 07:11:52 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <20151211113156.GA43862@elstar.local> <2059AD77-5375-4DB0-A1BF-432835F11A9F@gmail.com> <20151221153312.GA43316@elstar.local> <2BAA2B26-EE40-4707-BBDB-C84E5653CF23@gmail.com> <20160111183053.GA565@elstar.local>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: RTG YANG Design Team , netmod WG , Benoit Claise 
Subject: Re: [netmod] [Rtg-dt-yang-arch] [yang-doctors] Working group Last Call: draft-ietf-netmod-acl-model-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2016 15:11:59 -0000

> On Jan 11, 2016, at 7:30 PM, Juergen Schoenwaelder =
 wrote:
>=20
> On Mon, Jan 11, 2016 at 05:58:52PM +0100, Dean Bogdanovic wrote:
>>=20
>>>=20
>>> For the sake of clarity, I personally would prefer to have a single
>>> term. I think Linux packet filters call things rules. I think BSD
>>> packet filtering calls things rules. Wikipedia seem say that packet
>>> filters consist of filtering rules... So I guess I have a preference
>>> but I will not get a sleepless night over this.
>>=20
>> Authors are Cisco/Juniper people, so were using that terminology and =
I believe that CSCO and JNPR are more used in networking then Linux :)
>>=20
>=20
> If I were to have the time, I would even challenge you on
> that. Clearly, when you consider # of devices connected to the
> Internet, I am sure CISCO and JNPR will loose. But even in enterprise
> networks, there are tons of Linux and BSD firewalls. Consider all the
> home routers running openWRT and packet filters. So yes, if I would
> have time, I would challenge you on that argument.

I would definitely take you on this one. As OpenWRT is domain of =
hobbyist. If I may ask you, what device your ISP is sending you as =
access point? :)

>=20
> In some Junos documentation (Junos 14.2), I have seen the terms
> 'filter' and 'term'. But I might be proven wrong=E2=80=A6

Juniper is using filter and term, that is correct, from day one. OTH, =
Cisco is using Access Control List (ACL) and ACL Entries (ACE) and =
several other vendors (Brocade, Huawei, ALu, Ericsson Redback) are using =
those terms too. ACL is well established in the industry.=20
>=20
>>>>> - Should there be features for ace-eth and ace-ipv4 and ace-ipv6 =
or do
>>>>> we expect that all implementations will always support all three?
>>>>> Another option would be to have the generic model completely =
without
>>>>> any protocol specific elements and to have separate models to
>>>>> augment in ipv4, ipv6, and ethernet specific ace types. I actually
>>>>> think this would make much more sense since you would not have a
>>>>> module 'packet fields' but instead a clear extension of the
>>>>> ietf-access-control-list module. You could also drop the examples
>>>>> how to extend the core model since the ip and ethernet extensions
>>>>> would already serve the purpose. You also would not need features
>>>>> since an implementation advertises the extension modules.
>>>>=20
>>>> We started early with such design, but then the WG feedback moved =
us to the current  design.
>>>=20
>>> Can you provide pointers to minutes etc? I think the routing model
>>> also has a core model where even unicast routing is augmented in. =
This
>>> seems to make the boundary between the generic infrastructure and =
the
>>> addins very clear.
>>=20
>> I haven=E2=80=99t seen a network device with filters without =
supporting L2 and L3 types. This is how we started originally, but then =
comments came in on the mailing list and wanted exact typing. Please see =
the thread
>>=20
>> http://www.ietf.org/mail-archive/web/netmod/current/msg12144.html
>>=20
>> Model was changed for IETF 94 and at the WG meeting nobody raised the =
issue.
>=20
> I am talking about the modularity of the base model, I do not see how
> the cited thread relates to this.

Among the vendors, ace-eth, ace-ipv4 and ace-ipv6 are always supported. =
I appreciate your input, but we did this design choice as design team =
and went forward with it. Also, the YANG models are not set in stone. I =
definitely see models evolving.

>=20
>>>>> - The 'uses packet-fields:metadata' resolves to a leaf
>>>>> 'input-interface' which is of type string. Is this the only =
metadata
>>>>> field we ever envision to be there? If so, why not make it part of
>>>>> the base model? If not, what is the extensibility model here? =20
>>>>=20
>>>> It can be used for route filtering
>>>=20
>>> Yeah, but the questions were:
>>>=20
>>> - Is this the only metadata field we ever envision to be there?
>> No, it can be timestamp, RIB, VRF, etc.
>>=20
>>> - If so, why not make it part of the base model?
>>=20
>> We are early in the modeling and people were asking to remove time =
range from the base model and create separate draft, as many other =
features are using time-range.
>=20
> I agree that the decision is kind of tough to make. One option is to
> make the base model pretty much content free and to add pretty much
> everything in a modular way via extensions of the base model.
>=20
>>> - If not, what is the extensibility model here?
>=20
> Question remains open.
>=20
>>>>> And
>>>>> should the interface reference not use a more specific type than
>>>>> 'string=E2=80=99?
>>>>=20
>>>> Interface references can be many things, from standard naming we =
are familiar, e.g. ge-1/0/0.1 to a numerical value like 13276. Leaving =
it as string gives us most flexibility in that regards.
>>>=20
>>> I disagree that the goal here is most flexibility. We do have an
>>> interfaces data model in the IETF. Why are we avoiding to refer to =
it
>>> here?
>>=20
>> There is discussion in separate thread on this. And it seems we are =
in agreement to move this model to YANG 1.1 and use Martin B proposed =
solution.
>=20
> OK
>=20
>>>>> - Some implementations support the action to jump or goto other
>>>>> acls. Is this not common enough to include it as a base action,
>>>>> perhaps protected by a feature?
>>>>=20
>>>> Yes among vendors, but it can be very specific. Example, in Juniper =
implementation there are two types of filters, classical and Fast Update =
Filters (FUF). Classic filters support (on specific HW platforms) filter =
as action, but FUF does not. Not all terms and not all actions are =
supported on FUFs. So you have to see what filter type and what platform =
it is, in order to such a specific action.
>=20
> This is why getting the modularity right is very important here.
>=20
>>> What speaks against making jump and/or call actions a feature?
>>=20
>> jump is not supported on all platforms and all types of filters.
>=20
> A feature does not have to be supported by everyone.
>=20
>>>>> - In the example in section 4.3, does the CLI shown really help =
much?
>>>>> The syntax is pretty system specific.
>>>>=20
>>>> OTH, it is widely understood and self explanatory.
>>>=20
>>> The question was whether it is needed to show system specific CLI.
>>> BTW, I note that the textual description says "deny ... from
>>> _leaving_".  How is the 'from leaving' translated into the XML? Is
>>> there any distinction between input and output filters (or =
forwarding
>>> filters or whatever your engine supports)?
>>=20
>> We can improve the text description. Why not show system specific =
CLI? It is something widely understood and it is an example.=20
>>=20
>> This is what is being translated into XML
>>               access-list ip sample-ip-acl
>>               deny tcp host 10.10.10.1 host 10.10.10.255
>>=20
>> And usually people understand real example better, then just text =
description.
>=20
> May please CISCO people, others likely less. But so be it.
>=20
>>>>> In the XML shown, can you not
>>>>> leave out all the fields that are not set? This would remove a lot
>>>>> of noise. I do not understand what having both actions deny and
>>>>> permit at the same time means. Did you validate the example =
against
>>>>> the data model? (I also find the keys at the end somewhat strange
>>>>> and not that NETCONF XML serialization actually requires the keys =
to
>>>>> be sent first.)
>>>=20
>>>> We used pyang sample xml skeleton to create the xml example.
>>>=20
>>> Whatever, the noise does not really help and the example might even
>>> mislead people to believe they have to write down all unused leafs.
>>=20
>> We could edit the empty fields out, but from personal experience =
working with customers, I was getting questions that the compiler output =
and the examples are not matching (it was vendor data modeling =
language).
>=20
> Which compiler's output? I find it very distracting to list unused
> leafs. I assume most NETCONF implementations suppress unused leafs as
> well. (I might be proven wrong but I would have a preference to not
> use one that sends me tons of useless empty leafs.)=20

There is a vendor that had data modeling language and compiler shipping =
in their SDK. It is private DM language and it is not used outside of =
that vendor and customers.
>=20
>>>> Leaving both actions in the document is my fault. In the model, =
action is a choice, and it was a bad copy paste job. Didn=E2=80=99t =
choose :)
>>>>>=20
>>>>> - The clarification whether the boundary port numbers are included =
in
>>>>> a port range should be in the YANG model. The YANG model should =
also
>>>>> say what it means if one of the ranges is not present. We should =
not
>>>>> define the semantics by examples.
>>>> I=E2=80=99m loosing you here. We are stating in the model if the =
boundary port numbers are included in a port rang.
>>>=20
>>> Ack, I found it in the description of container source-port-range =
(and
>>> previously I looked at lower-port and upper-port).
>>>=20
>>>>>=20
>>>>> - I do not understand section 5. It shows some nftables syntax but
>>>>> does not really shed a light on what the example shown does or how
>>>>> that maps to the YANG data model. So I am left somewhat clueless.
>>>>=20
>>>> Just wanted to point out that the basic structure of iptables is =
similar to ACL yang model, so a translation from one to the other should =
be a  simple process. If someone wants to make it compliant.
>>>=20
>>> It escapes me how the iptables fragment shown in page 18 maps to the
>>> YANG model. What is the substance behind the statement "It should be
>>> fairly easy to do translation between ACL YANG model described in =
this
>>> draft and Linux nftables."? Has someone done a mapping? It is not
>>> obvious to me how this works.
>>=20
>> No, the mapping between nftables and ACL YANG model  has not been =
finished.=20
>=20
> OK
>=20
>>>>> - Can I trigger multiple actions from an ace? Or do I have to
>>>>> replicate the ace to do that? In general, there is extension of
>>>>> a choice (means one of several) and there are extension of a
>>>>> choice already present.
>>>> Again, this is very platform dependent, so didn=E2=80=99t want to =
include it in the base model.
>>>>=20
>>>=20
>>> So what would I do if I want to 'log' and 'deny'? Even if the base
>>> model does not do that, how can I augment this in? The base model =
must
>>> provide the necessary extensibility hooks.
>>=20
>> Logging/counting and another action (permit/deny) is possible with =
most vendors, but other multiple actions are not by most vendors, =
example to jump to another ACE or ACL. You have to replicate the ACE to =
do that. So to make it simple, this was the choice we made.
>=20
> So what about counting logging? Can we make the base simple yet
> powerful enough via features to match what common open source software
> implementations can do?

We made a different design choice.=20
>=20
>>> I believe it will help a lot to have prototype implementations of =
this
>>> data model in order to make sure the model does actually work and
>>> provides the extensibility hooks that are necessary. In particular, =
I
>>> would feel much more convinced if it would be clear (as a proof of
>>> concept) how the model maps to say Linux packet filters. I would
>>> actually not mind if mapping examples from the data model to various
>>> filtering engines would be in the appendix. This would give evidence
>>> that people have actually worked through a couple of concrete
>>> examples.
>>=20
>> In this case, I can=E2=80=99t help at the moment, as have left the =
previous company where I was working on an implementation.
>=20
> Perhaps there are others here with sufficient interested to work out
> (at least) how the model maps back and forth to the implementation(s)
> they are familiar with?

I did it for Juniper and it is working well for Junos, but didn=E2=80=99t =
finish it. I can=E2=80=99t speak for Cisco people, but they are =
co-authors on the draft and were fine with the model.=20
>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         


From nobody Tue Jan 19 08:48:50 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6001B3235; Tue, 19 Jan 2016 08:48:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6vjBK8E1W1A; Tue, 19 Jan 2016 08:48:41 -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 C875C1B3249; Tue, 19 Jan 2016 08:48:35 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D4CF6727; Tue, 19 Jan 2016 17:48:32 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id gJ3GlBtIE1b2; Tue, 19 Jan 2016 17:48:32 +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, 19 Jan 2016 17:48:32 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E98862002C; Tue, 19 Jan 2016 17:48:31 +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 AKAPnhaQ-pPa; Tue, 19 Jan 2016 17:48:31 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 61ACC2002B; Tue, 19 Jan 2016 17:48:30 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 55C68399C094; Tue, 19 Jan 2016 17:48:30 +0100 (CET)
Date: Tue, 19 Jan 2016 17:48:30 +0100
From: Juergen Schoenwaelder 
To: Dean Bogdanovic 
Message-ID: <20160119164830.GB90880@elstar.local>
Mail-Followup-To: Dean Bogdanovic , Nadeau Thomas , Benoit Claise , RTG YANG Design Team , netmod WG 
References:  <20151211113156.GA43862@elstar.local> <2059AD77-5375-4DB0-A1BF-432835F11A9F@gmail.com> <20151221153312.GA43316@elstar.local> <2BAA2B26-EE40-4707-BBDB-C84E5653CF23@gmail.com> <20160111183053.GA565@elstar.local> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: RTG YANG Design Team , netmod WG , Benoit Claise 
Subject: Re: [netmod] [Rtg-dt-yang-arch] [yang-doctors] Working group Last Call: draft-ietf-netmod-acl-model-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2016 16:48:44 -0000

On Tue, Jan 19, 2016 at 07:11:52AM -0800, Dean Bogdanovic wrote:
> 
> > If I were to have the time, I would even challenge you on
> > that. Clearly, when you consider # of devices connected to the
> > Internet, I am sure CISCO and JNPR will loose. But even in enterprise
> > networks, there are tons of Linux and BSD firewalls. Consider all the
> > home routers running openWRT and packet filters. So yes, if I would
> > have time, I would challenge you on that argument.
> 
> I would definitely take you on this one. As OpenWRT is domain of
> hobbyist. If I may ask you, what device your ISP is sending you as
> access point? :)

Which ISP is sending their customers a Cisco or Juniper device? The
big players in the German market all sell something that is based that
the very end on Linux or BSD. Isn't FritzBox for example Linux based?
Are the cheap Asian home routers not all at the end Linux based? I
guess this debate does not really belong here and we should take is
elsewhere (but I am sure I will win this easily).

> Juniper is using filter and term, that is correct, from day
> one. OTH, Cisco is using Access Control List (ACL) and ACL Entries
> (ACE) and several other vendors (Brocade, Huawei, ALu, Ericsson
> Redback) are using those terms too. ACL is well established in the
> industry.

While we can have a lengthy debate about terminology, I think more
important is to get functionality right.

> > I am talking about the modularity of the base model, I do not see how
> > the cited thread relates to this.
> 
> Among the vendors, ace-eth, ace-ipv4 and ace-ipv6 are always supported. I appreciate your input, but we did this design choice as design team and went forward with it. Also, the YANG models are not set in stone. I definitely see models evolving.

My main concern is that we need to get the extensibility of the model
right. One way to make sure we achieved this goal is to actually treat
everything as an extension of the core model (this forces us to get
the extensibility right). This is essentially what we did with the
routing data model and the interfaces data model.

/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 19 09:16:59 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41B61B32DF; Tue, 19 Jan 2016 09:16:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7_HnncZNAGr; Tue, 19 Jan 2016 09:16:52 -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 BDA551B32D5; Tue, 19 Jan 2016 09:16:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2606; q=dns/txt; s=iport; t=1453223812; x=1454433412; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=6CMXVi5CTBgihHVJt0JmroYlB2RqPzjZLj8ByKfHQsE=; b=LVQ7+OCm9ireIV1F6dOPmn1K9+ieiNQGYkkPGus8fy+8jtg/9J3wPNNc wdtelw5BDa0cL2RjPJ/px+PQtdZF94HjIccMA4aLxqHJR8RFZrJuLc2LR JCHm7mvpmS4hnNkWVmkw3d4xjpZTxTT6YIrGJzYh2nNoHJEM1V2403g8u I=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoBABzbp5W/xbLJq1ejU+0YIYPAoILA?= =?us-ascii?q?QEBAQEBgQuENQEBAwEjVQYLCw4TFgQHAgIJAwIBAgFFBgEMCAEBiA8Irz+PUQE?= =?us-ascii?q?BAQEBAQEDAQEBAQEBAREIiy6Ha4FJAQSXGoJ4gWaJAYFehESDCIVXimyDcGSCE?= =?us-ascii?q?RsdgUE9hyIBAQE?=
X-IronPort-AV: E=Sophos;i="5.22,318,1449532800";  d="asc'?scan'208";a="624630725"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jan 2016 17:16:48 +0000
Received: from [10.61.193.184] ([10.61.193.184]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u0JHGlsw008355; Tue, 19 Jan 2016 17:16:47 GMT
To: Dean Bogdanovic , Nadeau Thomas , Benoit Claise , RTG YANG Design Team , netmod WG 
References:  <20151211113156.GA43862@elstar.local> <2059AD77-5375-4DB0-A1BF-432835F11A9F@gmail.com> <20151221153312.GA43316@elstar.local> <2BAA2B26-EE40-4707-BBDB-C84E5653CF23@gmail.com> <20160111183053.GA565@elstar.local>  <20160119164830.GB90880@elstar.local>
From: Eliot Lear 
X-Enigmail-Draft-Status: N1110
Message-ID: <569E6F7F.1010901@cisco.com>
Date: Tue, 19 Jan 2016 18:16:47 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <20160119164830.GB90880@elstar.local>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="o56PK1FRds3es8kQAMB2df0BhJTODAciR"
Archived-At: 
Subject: Re: [netmod] [Rtg-dt-yang-arch] [yang-doctors] Working group Last Call: draft-ietf-netmod-acl-model-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2016 17:16:54 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--o56PK1FRds3es8kQAMB2df0BhJTODAciR
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Juergen,

Skipping down...

On 1/19/16 5:48 PM, Juergen Schoenwaelder wrote:

> While we can have a lengthy debate about terminology, I think more
> important is to get functionality right.=20

Agree.  We are arguing over labels that aren't generally meant for
humans ANYWAY.

>>> I am talking about the modularity of the base model, I do not see how=

>>> the cited thread relates to this.
>> Among the vendors, ace-eth, ace-ipv4 and ace-ipv6 are always supported=
=2E I appreciate your input, but we did this design choice as design team=
 and went forward with it. Also, the YANG models are not set in stone. I =
definitely see models evolving.
> My main concern is that we need to get the extensibility of the model
> right. One way to make sure we achieved this goal is to actually treat
> everything as an extension of the core model (this forces us to get
> the extensibility right). This is essentially what we did with the
> routing data model and the interfaces data model.
>
>
While I agree I am also becoming concerned that we may be going down a
rat hole from which we may not return.  The above thread snippets have
lost so much context that one cannot divine what it is we are arguing
over.  While a design team certainly does not represent consensus, can
we please at least argue over what it is we are supposed to be arguing
over?  With regard to this model, I could imagine innumerable ways to
represent an access list.  The deference due the people who wrote this
stuff out is at least to recognize that.  If you are going to propose an
alternative at this point, please do it the old fashion way: send text.

Eliot


--o56PK1FRds3es8kQAMB2df0BhJTODAciR
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2

iQEcBAEBCAAGBQJWnm9/AAoJEIe2a0bZ0nozh2oIAIn1IMrRFq++9KaN5qbbPDn5
y+oidbZMQKxSQqx9Rftc3hsPabcnAUheYpyF90EAeRYAsmhQA7X82BsW6Lwl/6SB
Xi/N6PNpI4OJv0M58KE+hCeN525hymRMgbyIw9brJ2wo/SI4mKVkmq9ucdMzx0t1
7n257Ph8bh4N8qhHrh+d3g/B89TLY2lXOyZ+QFueCDOinCfrxO3abFaCJHY3kBzy
9U+2lsPgQIeOfZQIbt/NB6LKQs0wBJTQXJFquVS81k09c45HEmg9NodQCSnrbtEl
8YyyV+Vy8u3AW2E1WT7geOIi3AhwOsHt4kprebxzUDOu4Fu4/pid5gHMgELjKMo=
=GSYi
-----END PGP SIGNATURE-----

--o56PK1FRds3es8kQAMB2df0BhJTODAciR--


From nobody Tue Jan 19 10:18:49 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D2B1B33F2; Tue, 19 Jan 2016 10:18:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8G4l91ld4TYC; Tue, 19 Jan 2016 10:18:44 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0726.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::726]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 921D71B33F0; Tue, 19 Jan 2016 10:18:43 -0800 (PST)
Received: from BLUPR05MB069.namprd05.prod.outlook.com (10.255.214.14) by BLUPR05MB071.namprd05.prod.outlook.com (10.255.214.24) with Microsoft SMTP Server (TLS) id 15.1.365.19; Tue, 19 Jan 2016 18:18:25 +0000
Received: from BLUPR05MB069.namprd05.prod.outlook.com ([169.254.9.131]) by BLUPR05MB069.namprd05.prod.outlook.com ([169.254.9.45]) with mapi id 15.01.0365.023; Tue, 19 Jan 2016 18:18:24 +0000
From: "Lisa (Yi) Huang" 
To: Eliot Lear , Dean Bogdanovic , "Nadeau Thomas" , Benoit Claise ,  "RTG YANG Design Team" , netmod WG 
Thread-Topic: [netmod] [Rtg-dt-yang-arch] [yang-doctors] Working group Last Call: draft-ietf-netmod-acl-model-06
Thread-Index: AQHROlvwsrxxZzFGi0KEr26iJ5PILZ7VlRaAgBYwQQCAAo+zAIAAhZyAgAD6CgCAAAnlgIAS8ieA
Date: Tue, 19 Jan 2016 18:18:24 +0000
Message-ID: 
References:  <20151211113156.GA43862@elstar.local> <2059AD77-5375-4DB0-A1BF-432835F11A9F@gmail.com> <20151221153312.GA43316@elstar.local> <568AB8AA.8070404@cisco.com> <20160106093026.GB25431@elstar.local> <509C88A7-5F33-4CF2-BE5B-284F180F0FEC@gmail.com> <20160107082336.GA27362@elstar.local> <568E28D5.6070109@cisco.com>
In-Reply-To: <568E28D5.6070109@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.5.5.150821
authentication-results: spf=none (sender IP is ) smtp.mailfrom=lyihuang@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.14]
x-microsoft-exchange-diagnostics: 1; BLUPR05MB071; 5:K8i7/BS6Oi+ON+5jrn108RnIop0/1aOBe15ruypyPtuAibPjUWgFx5Hr7LZ2KVzEE0Uk5epYDRM5scoSc9j7NFrHhl4emDOTVazbsRgSeVbRwB0QlYc/HCh9bZRVg5lKurLV3sEWDrsKG6iyBMDMTw==; 24:0Ej9b6XAaysK8ySgChgwqdr+7woN6yRQ648hd6Mne2HMF4VToV1ea77d+44BoPWmocR5SvZ+l45nND9y+XcAEwxsMpivp3JMEvrRocTCo78=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB071;
x-ms-office365-filtering-correlation-id: 76bd7987-90b4-4247-061f-08d320fceb9f
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:BLUPR05MB071; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB071; 
x-forefront-prvs: 0826B2F01B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(24454002)(479174004)(164054003)(377454003)(189998001)(19580405001)(66066001)(81156007)(40100003)(102836003)(54356999)(86362001)(5004730100002)(122556002)(1096002)(107886002)(106356001)(19580395003)(92566002)(3846002)(99286002)(586003)(105586002)(6116002)(87936001)(5002640100001)(4001350100001)(5001770100001)(2906002)(5008740100001)(10400500002)(36756003)(101416001)(83506001)(93886004)(50986999)(230783001)(5001960100002)(1220700001)(2950100001)(106116001)(2900100001)(97736004)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB071; H:BLUPR05MB069.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:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <45F177A05ADF1F46BEC3A8C677A07968@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2016 18:18:24.5506 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB071
Archived-At: 
Subject: Re: [netmod] [Rtg-dt-yang-arch] [yang-doctors] Working group Last Call: draft-ietf-netmod-acl-model-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2016 18:18:45 -0000

In current devices, access lists could be configured before interface
available as part of provisioning configuration. Using interface-ref would
loose this flexibility. Also, in the 1st draft of =B3Yang Data Model for
Stateless Packet Filter Configuration=B2, the community doesn=B9t like
interface-ref because of lacking of flexibility. In YANG 1.1, the new
require-instance statement might help this situation. We would discuss it
in authors to figure out whether to adapt YANG 1.1 in this I-D or not.

Thanks,
Lisa

On 1/7/16, 12:59 AM, "netmod on behalf of Eliot Lear"
 wrote:

>
>
>On 1/7/16 9:23 AM, Juergen Schoenwaelder wrote:
>> This does not answer why input-interface is of type string...
>
>To be perfectly clear you seek that type string be replaced with
>interface-ref?
>
>Eliot
>


From nobody Tue Jan 19 10:53:39 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECF31B3454; Tue, 19 Jan 2016 10:53:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qgz1wKsF1kla; Tue, 19 Jan 2016 10:53:36 -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 22EEF1B3456; Tue, 19 Jan 2016 10:53:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1429; q=dns/txt; s=iport; t=1453229616; x=1454439216; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GcO/zFGiGxtObMg/jZ27aQUACib9Fx68WGppMS6FeW4=; b=SnKWqvAOzKxY5W02SIdQvM4ZN0YxmYPs+LRwKEjJzuha+WCj2da+C4AD I0sHbCEKTCHYGwuNxh1F+vDbUQt2omScBplgV0rMneBNDb3aPNMrvY2Fm BjNYBKH9/ujjI+vpfds9eMToJjNAGJacyZ1BaAEsvDKaqsAxJU+BLunMU E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQAyhZ5W/5NdJa1bA4M6Um0GiFCyb?= =?us-ascii?q?wENgWMYCoVtAoFAOBQBAQEBAQEBgQqENQEBAwEBAQE3NAsOAgIBCA4CJhAbDAs?= =?us-ascii?q?lAgQBDQWIEwgOvzkBAQEBAQEBAQEBAQEBAQEBAQEBAQEVBIY3hHOEciaEHAWXG?= =?us-ascii?q?gGNXoFejSOKbINvASABAUKCERsdgUByhWaBCAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.22,318,1449532800"; d="scan'208";a="63095087"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jan 2016 18:53:35 +0000
Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u0JIrZED010780 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Jan 2016 18:53:35 GMT
Received: from xch-rcd-014.cisco.com (173.37.102.24) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 19 Jan 2016 12:53:34 -0600
Received: from xch-rcd-014.cisco.com ([173.37.102.24]) by XCH-RCD-014.cisco.com ([173.37.102.24]) with mapi id 15.00.1104.009; Tue, 19 Jan 2016 12:53:33 -0600
From: "Kiran Koushik Agrahara Sreenivasa (kkoushik)" 
To: Juergen Schoenwaelder , "Dean Bogdanovic" 
Thread-Topic: [yang-doctors] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06
Thread-Index: AQHROlv2bvJxiUpB3kOrMbT8P+B9Xp7V+ayAgCEY4wCAABm2gIAMWwsAgAAbAAD//75bgA==
Date: Tue, 19 Jan 2016 18:53:33 +0000
Message-ID: 
References:  <20151211113156.GA43862@elstar.local> <2059AD77-5375-4DB0-A1BF-432835F11A9F@gmail.com> <20151221153312.GA43316@elstar.local> <2BAA2B26-EE40-4707-BBDB-C84E5653CF23@gmail.com> <20160111183053.GA565@elstar.local>  <20160119164830.GB90880@elstar.local>
In-Reply-To: <20160119164830.GB90880@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.234.48]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: Benoit Claise , RTG YANG Design Team , netmod WG 
Subject: Re: [netmod] [yang-doctors] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Jan 2016 18:53:38 -0000

Hi Juergen,

>> > I am talking about the modularity of the base model, I do not see how
>> > the cited thread relates to this.
>>=20
>> Among the vendors, ace-eth, ace-ipv4 and ace-ipv6 are always supported.
>>I appreciate your input, but we did this design choice as design team
>>and went forward with it. Also, the YANG models are not set in stone. I
>>definitely see models evolving.
>
>My main concern is that we need to get the extensibility of the model
>right. One way to make sure we achieved this goal is to actually treat
>everything as an extension of the core model (this forces us to get
>the extensibility right). This is essentially what we did with the
>routing data model and the interfaces data model.


While I agree that your approach worked with the routing and interfaces
data models, we as a design team decided to include what we thought was
core functionality and then also allow extensibility on top of it. At
least folks in Cisco and Brocade liked this approach better.


Thanks
Kiran


>
>/js
>
>--=20
>Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>Fax:   +49 421 200 3103         
>
>_______________________________________________
>yang-doctors mailing list
>yang-doctors@ietf.org
>https://www.ietf.org/mailman/listinfo/yang-doctors


From nobody Wed Jan 20 06:43:24 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 179871A8A48 for ; Wed, 20 Jan 2016 06:43:22 -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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiIAGS51ERRf for ; Wed, 20 Jan 2016 06:43:20 -0800 (PST)
Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1900:3001:11::28]) by ietfa.amsl.com (Postfix) with ESMTP id 3419D1A8A3A for ; Wed, 20 Jan 2016 06:43:20 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 2E0E31E5A3A; Wed, 20 Jan 2016 06:42:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id b_eNo9g9Lbcb; Wed, 20 Jan 2016 06:42:40 -0800 (PST)
Received: from [192.168.1.129] (host86-133-254-101.range86-133.btcentralplus.com [86.133.254.101]) by c8a.amsl.com (Postfix) with ESMTPSA id 5002F1E5A35; Wed, 20 Jan 2016 06:42:39 -0800 (PST)
From: William Lupton 
Content-Type: multipart/alternative; boundary="Apple-Mail=_3B539B28-9C5E-4D1B-828E-3FD9265DA9D1"
Date: Wed, 20 Jan 2016 14:43:17 +0000
To: netmod@ietf.org
Message-Id: 
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Subject: [netmod] Validation question
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2016 14:43:22 -0000

--Apple-Mail=_3B539B28-9C5E-4D1B-828E-3FD9265DA9D1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

All,

We have been experimenting with validating XML instances along the lines =
explained in the tutorials at =
http://www.yang-central.org/twiki/bin/view/Main/DSDLMappingTutorial =
 =
and https://github.com/mbj4668/pyang/wiki/InstanceValidation =
 and we have =
hit a problem with identities in XPath expressions.

This is illustrated by the YANG module shown below, which is inspired by =
an example in RFC 6020bis, and the XML instance shown below the YANG. =
Note that:
The second "when" statement doesn't use a prefix on the interface type.
Shouldn't be a problem because the interface type is defined in the =
current module and so doesn't need a prefix?
The XML uses a prefix name of "exaug" rather than "mymod" which is used =
in the YANG.
Shouldn't be a problem because prefixes should be local?

Validating this instance gives the following two errors (which go away =
if the prefix "mymod" is used in all "when" statements and in the XML).

=3D=3D Validating semantic constraints ...
--- Validity error at "/nc:data/if:interfaces/if:interface":
    Found nodes that are valid only when "if:type =3D =
'mymod:some-new-iftype'"
--- Validity error at "/nc:data/if:interfaces-state/if:interface":
    Found nodes that are valid only when "if:type =3D 'some-new-iftype'"

Are we doing something wrong here, or is there a problem with how =
identities in XPath expressions are translated (per RFC 6110)? On the =
face of it it seems that identities are being treated as literal strings =
(but we haven't investigated this assertion).

Thanks,
William Lupton

--------

YANG:
module example-augment {
  namespace "http://example.com/augment";
  prefix mymod;
 =20
  import ietf-interfaces {
    prefix if;
  }
 =20
  identity some-new-iftype {
    base if:interface-type;
  }
 =20
  augment "/if:interfaces/if:interface" {
    when "if:type =3D 'mymod:some-new-iftype'";

    container some-new-container {
    }
  }

  augment "/if:interfaces-state/if:interface" {
    when "if:type =3D 'some-new-iftype'";

    container some-new-container {
    }
  }
}

XML:


  
    
      
      
      exaug:some-new-iftype
      true
      enabled
      
      
    
  
  =

    
      
      exaug:some-new-iftype
      up
      up
      1
      
        2016-01-15T12:55:00Z
      
      
      
    
  




--Apple-Mail=_3B539B28-9C5E-4D1B-828E-3FD9265DA9D1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

All,

We =
have been experimenting with validating XML instances along the lines =
explained in the tutorials at http://www.yang-central.org/twiki/bin/view/Main/DSDLMappingTuto=
rial and https://github.com/mbj4668/pyang/wiki/InstanceValidation&nb=
sp;and we have hit a problem with identities in XPath =
expressions.

This is illustrated by the YANG module shown below, which is =
inspired by an example in RFC 6020bis, and the XML instance shown below =
the YANG. Note that:
  • The second "when" statement doesn't use a prefix on the =
interface type.
    • Shouldn't be a problem =
because the interface type is defined in the current module and so =
doesn't need a prefix?
  • The XML uses a prefix =
name of "exaug" rather than "mymod" which is used in the YANG.
    • Shouldn't be a problem because prefixes should =
be local?

Validating this instance gives the following two errors =
(which go away if the prefix "mymod" is used in all "when" statements =
and in the XML).

=3D=3D =
Validating semantic constraints ...
--- Validity error at =
"/nc:data/if:interfaces/if:interface":
    Found nodes that are valid only =
when "if:type =3D 'mymod:some-new-iftype'"
--- Validity error at =
"/nc:data/if:interfaces-state/if:interface":
    Found nodes that are valid =
only when "if:type =3D 'some-new-iftype'"

Are we doing something wrong here, or =
is there a problem with how identities in XPath expressions are =
translated (per RFC 6110)? On the face of it it seems that identities =
are being treated as literal strings (but we haven't investigated this =
assertion).

Thanks,
William Lupton

--------

YANG:
module =
example-augment {
  prefix mymod;
  
  import =
ietf-interfaces {
    prefix if;
  }
  
  identity some-new-iftype {
    base =
if:interface-type;
  }
  
  augment "/if:interfaces/if:interface" =
{
    =
when "if:type =3D 'mymod:some-new-iftype'";

  =
  container some-new-container {
    }
  }

  augment =
"/if:interfaces-state/if:interface" {
    when "if:type =3D =
'some-new-iftype'";

    container =
some-new-container {
    }
  }
}

XML:
<?xml version=3D"1.0" =
encoding=3D"UTF-8"?>
<data =
xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"
  xmlns:exaug=3D"http://example.com/augment">
  <interfaces =
xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-interfaces">
    =
<interface>
      <name/>
      =
<description/>
      =
<type>exaug:some-new-iftype</type>
      =
<enabled>true</enabled>
      =
<link-up-down-trap-enable>enabled</link-up-down-trap-enable>
    =
  <some-new-container xmlns=3D"http://example.com/augment">
      =
</some-new-container>
    </interface>
  </interfaces>
  =
<interfaces-state =
xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-interfaces">
    =
<interface>
      <name/>
      =
<type>exaug:some-new-iftype</type>
      =
<admin-status>up</admin-status>
      =
<oper-status>up</oper-status>
      =
<if-index>1</if-index>
      <statistics>
      =
  =
<discontinuity-time>2016-01-15T12:55:00Z</discontinuity-time><=
/div>
    =
  </statistics>
      <some-new-container xmlns=3D"http://example.com/augment">
      =
</some-new-container>
    </interface>
  =
</interfaces-state>
</data>


=

--Apple-Mail=_3B539B28-9C5E-4D1B-828E-3FD9265DA9D1--


From nobody Wed Jan 20 06:45:38 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D27781A8A4C for ; Wed, 20 Jan 2016 06:45:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTHfcD8JKrKO for ; Wed, 20 Jan 2016 06:45:36 -0800 (PST)
Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2001A8A4E for ; Wed, 20 Jan 2016 06:45:36 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 746A11E5A3E; Wed, 20 Jan 2016 06:44:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4k6Okr_eetLB; Wed, 20 Jan 2016 06:44:56 -0800 (PST)
Received: from [192.168.1.129] (host86-133-254-101.range86-133.btcentralplus.com [86.133.254.101]) by c8a.amsl.com (Postfix) with ESMTPSA id E4D5D1E5A3D; Wed, 20 Jan 2016 06:44:55 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: William Lupton 
In-Reply-To: <2431FE7A-9CC9-48A6-92FF-AE383DB71394@broadband-forum.org>
Date: Wed, 20 Jan 2016 14:45:34 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <2431FE7A-9CC9-48A6-92FF-AE383DB71394@broadband-forum.org>
To: netmod@ietf.org
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Subject: Re: [netmod] Broadband Forum questions on RFC 6087bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Jan 2016 14:45:38 -0000

All,

I didn't see any follow-up to these questions / comments. Any thoughts?=20=


Thanks,
William

> On 11 Dec 2015, at 12:54, William Lupton  =
wrote:
>=20
> All,
>=20
> Here are some questions / comments from the Broadband Forum on RFC =
6087bis-05.
>=20
> Thanks,
> William
>=20
> --------
>=20
> 1. Potentially confusing use of the term "prefix"
>=20
> Section 5.1 (Module Naming Conventions) talks about prefixes but in =
this context means "strings at the beginning of module names" rather =
than YANG prefixes that are the topic of Section 5.2. This could (and =
did!) cause confusion.
>=20
>=20
> 2. Rules re changing submodule names
>=20
> Section 5.7 (Lifecycle Management) says that "The [...] submodule name =
MUST NOT be changed, once the document containing the module or =
submodule is published" but this might contradict RFC 6020 Section 11, =
which says "A module may be split into a set of submodules, or a =
submodule may be removed...".
>=20
> More specifically, 6020 doesn't mention renaming a submodule (so =
presumably that's not permitted), but the mention of both splitting =
modules into submodules AND removing submodules suggests that arbitrary =
module/submodule refactoring is permitted. And if I'm being pedantic, =
revision #1 could have submodule A1, revision #2 could remove it, and =
revision #3 could reintroduce it as submodule A2, so that's effectively =
a rename!
>=20
>=20
> 3. References to RPCs need also to mention actions
>=20
> In most (or all?) places that RPCs are mentioned, presumably actions =
need to be mentioned?
>=20
>=20
> 4. Implications of adding defaults
>=20
> Section 5.12 (Reusable Type Definitions) says that "If an appropriate =
default value can be associated with the desired semantics, then a =
default statement SHOULD be present". Is it correct that adding a =
default effectively adds a MANDATORY requirement for a server to support =
the default value for that node, and therefore to support the concept =
modelled by the node (albeit only with the default behaviour)? Whereas =
if there were no default then there would be no requirement at all to =
support the concept modelled by that node? If so, then adding a default =
seems like something that shouldn't be done lightly... or am I making =
too much of this?
>=20
>=20
> 5. Guidance re YANG features
>=20
> 6087 doesn't always refer to features consistently. For example =
Section 5.5 (Conditional Statements) says "If a data definition is =
optional, depending on server support for a NETCONF protocol capability, =
then a YANG 'feature' statement SHOULD be defined" (which seems to tie =
the "feature" concept to NETCONF protocol capabilities), whereas Section =
5.17 (Feature Definitions) says "The YANG "feature" statement is used to =
define a label for a set of optional functionality within a module". The =
latter description seems more in keeping with the spirit of 6020, so =
perhaps the former text could be adjusted to align with it?
>=20
>=20
> 6. Guidance re YANG deviations
>=20
> The 6020 discussion of deviations is mostly about implementing LESS =
rather than MORE. Obviously the deviate statement's "add" argument is =
described (and there is an example) but there seems to be no discussion =
that use of deviate with "add" might be a GOOD thing.
>=20
> The 6087 discussion of deviations says that they can be useful for =
documenting server capabilities but again the emphasis seems to be on =
documenting implementing LESS rather than MORE.
>=20
> The result seems to be that deviations have a bad name. If indeed =
there are accepted good uses of deviations then it would be good if this =
was made clearer, both in 6020 and in 6087.


From nobody Wed Jan 20 23:45:49 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355A31A01A4 for ; Wed, 20 Jan 2016 23:45:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dpjNo6Cw4rZ for ; Wed, 20 Jan 2016 23:45:46 -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 BA66F1A01A3 for ; Wed, 20 Jan 2016 23:45:45 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHE40644; Thu, 21 Jan 2016 07:45:41 +0000 (GMT)
Received: from LHREML707-CAH.china.huawei.com (10.201.5.199) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 21 Jan 2016 07:45:40 +0000
Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 21 Jan 2016 07:45:33 +0000
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.112]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0235.001; Thu, 21 Jan 2016 15:45:28 +0800
From: Qin Wu 
To: netmod WG 
Thread-Topic: [netmod] Working group Last Call: draft-ietf-netmod-acl-model-06
Thread-Index: AQHRVB+yKAhP4KNU+U6QlHaAhxe9Jw==
Date: Thu, 21 Jan 2016 07:45:28 +0000
Message-ID: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.136.78.208]
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.0A020203.56A08CA6.001C, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.1.112, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: eea717351629a8c02450c7ac7babe79d
Archived-At: 
Subject: [netmod]  Working group Last Call: draft-ietf-netmod-acl-model-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2016 07:45:48 -0000

SGksIGFsbDoNClNvcnJ5IGZvciBsYXRlIHJlc3BvbnNlIHRvIHRoaXMgY2FsbC4NCkkgaGF2ZSB0
YWtlbiBzb21lIHRpbWUgdG9kYXkgdG8gcmUtcmVhZCB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgZHJh
ZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLTA2IGFuZCBoYXZlIHR3byBjb21tZW50czoNCjEuIFRo
aXMgZHJhZnQgZGVmaW5lcyB0d28gbW9kdWxlLCBvbmUgaXMgSUVURi1QQUNLRVQtRklFTERTLCB0
aGUgb3RoZXIgaXMgaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0IG1vZHVsZSwNCkkgYW0gd29uZGVy
aW5nIHdoZXRoZXIgaWV0Zi1wYWNrZXQtZmllbGRzIG1vZHVsZSBjYW4gYmUgZGVmaW5lZCBpbiBt
b3JlIGdlbmVyaWMgd2F5IHRoYXQgY2FuIGJlIGFwcGxpZWQgdG8gb3RoZXIgbW9kdWxlcyBkZWZp
bmVkIHNvbWV3aGVyZSBlbHNlPw0KZS5nLiwgaW4gaWV0Zi1wYWNrZXQtZmllbGRzIG1vZHVsZSwg
YWNsLWlwLWhlYWRlci1maWVsZHMgZ3JvdXBpbmcgaXMgZGVmaW5lZCwgSSBhbSB3b25kZXJpbmcg
d2hldGhlciBwcmVmaXggImFjbC0iIGNhbiBiZSByZW1vdmVkIHRvIG1ha2UgaXQgbW9yZSBnZW5l
cmljPw0KDQoyLiBUaGlzIGRyYWZ0IGJyaWVmbHkgZGlzY3VzcyBMaW51eCBuZnRhYmxlcyB3aGlj
aCBpcyBpbnRlcmVzdGluZywgSSBhbSB3b25kZXJpbmcgaG93IHRoaXMgbmZ0YWJsZSBpcyBkaWZm
ZXJlbnQgZnJvbSByaWIgZGlzY3Vzc2VkIGluIEkyUlMsIGlzIHRoZXJlIGFueSBkZXBlbmRlbmN5
DQpiZXR3ZWVuIG1vZGVsIHByb3Bvc2VkIGluIHRoaXMgZHJhZnQgYW5kIHRoZSBtb2RlbCBwcm9w
b3NlZCBpbiBJMlJTPyBJZiB0aGlzIGhhcyBiZWVuIGRpc2N1c3NlZCBhbHJlYWR5LCBwbGVhc2Ug
aWdub3JlIHRoaXMgY29tbWVudC4NCg0KQmVzaWRlcyB0aGVzZSB0d28gY29tbWVudHMsIEkgdGhp
bmsgdGhpcyBkcmFmdCBpcyBnb29kIGVub3VnaCB0byBtb3ZlIGZvcndhcmQuIFRoYW5rcyENCg0K
LVFpbg0KPiBPbiAxMi85LzE1IDU6MjcgUE0sIE5hZGVhdSBUaG9tYXMgd3JvdGU6DQo+PiAJVGhp
cyBlbWFpbCBpbml0aWF0ZXMgYSBORVRNT0QgV0cgTGFzdCBjYWxsIGZvciBkcmFmdC1pZXRmLW5l
dG1vZC1hY2wtbW9kZWwtMDYuIA0KPj4gUGxlYXNlIHJldmlldyB0aGUgZHJhZnQgYW5kIG1ha2Ug
YW55IGNvbW1lbnRzIHRvIHRoZSBsaXN0IGJ5IA0KPj4gV2VkbmVzZGF5LCAxNiBEZWNlbWJlciwg
MjAxNSBieSA4QU0gRVNULg0KPj4gDQo+PiAJVG9tIGFuZCBLZW50IChhcyBORVRNT0QgQ28tY2hh
aXJzKQ0KPj4gDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQo+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+PiBuZXRtb2RAaWV0Zi5vcmcNCj4+
IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo=


From nobody Thu Jan 21 03:51:44 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3176A1A9145 for ; Thu, 21 Jan 2016 03:51:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNMqLUoSFoDb for ; Thu, 21 Jan 2016 03:51:40 -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 54B631A9142 for ; Thu, 21 Jan 2016 03:51:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3420; q=dns/txt; s=iport; t=1453377100; x=1454586700; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=38iKF6qGLeQ7HCPkSp/R4xSU2KECU45LEHvkRlTrO0U=; b=hFSIApl9B5xMT8MQfvbl1hije1TjmjOWyKRMCDZ03VmkNanOqB7a7eB/ aJnW05xiWaikeGzS2LhcoEO0JR60xiOFB+YZPwOLpBJAp2OZGzeeHzmty Uspo7kYxCYhjyGD8IcP9qiqdy4Xl+rC18DtB88n75g5iqDS/7LCmAWMD5 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CmBABtxaBW/xbLJq1ejVCyJIFjgl+FH?= =?us-ascii?q?RIBAQEBAQEBgQqESRUVLRM2AgUWCwILAwIBAgFLAQwIAQEXiACtPo9BAQEBAQE?= =?us-ascii?q?FAQEBARx7hT6JFBEBgx+BOgWWfoESjEeBXoREgwaFVI5AJwI5g2Y8hhCBMAEBA?= =?us-ascii?q?Q?=
X-IronPort-AV: E=Sophos;i="5.22,325,1449532800"; d="scan'208";a="648676591"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jan 2016 11:51:37 +0000
Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u0LBpb2S011087; Thu, 21 Jan 2016 11:51:37 GMT
To: "netmod@ietf.org" , Martin Bjorklund , Ladislav Lhotka 
From: Robert Wilton 
Message-ID: <56A0C64A.3090506@cisco.com>
Date: Thu, 21 Jan 2016 11:51:38 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [netmod] Comparison of structural-mount and ysdl drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2016 11:51:42 -0000

Hi Lada, Martin,

I've reviewed both draft-bjorklund-netmod-structural-mount-00 and 
draft-lhotka-netmod-ysdl-00.

In comparing these two drafts, the main differences that I perceive are:

1) structural-mount allows the mounted data model to publish its 
supported schema at the mount point, but ysdl requires the mounting 
device to know and publish the schema for all mounted data models.
2) A corollary of (1) is that structural-mount also allows different 
schema data models to be published at the mount point (e.g. under a 
list), but ysdl does not.
3) structural-mount has a mount node embedded directly in the schema, 
where as for ysdl, the equivalent mount points are only specified in the 
ysdl meta-schema.
4) ysdl is extensible to cover other non mount related use-cases (such 
as anydata) where being able to dynamically make available the schema is 
useful.
5) structural-mount also covers RPCs and Notifications, whereas these 
appear to be outside the scope of ysdl.
6) The ysdl meta-data language appears to be more flexible, and hence 
also more complex, than the equivalent "mount-points" schema defined in 
structural-mount.
7) For structural-mount the "mount-points" table is returned as a normal 
oper data YANG module in the mounting device, whereas for ysdl, protocol 
extensions would be required to NETCONF/RESTCONF to access the schema 
meta-data.

Considering these differences:

For points (1) and (2), I can think of scenarios where having a mounted 
device being able to provide its schema via yang-library and for that 
schema to differ for different mounted devices is probably a requirement 
for some plausible mount scenarios.  E.g. one that I can think of is the 
case that you have a YANG controller that is exposing an aggregated YANG 
model for a set of devices, it seems that you would need to be 
accommodate mounted devices that are made by different vendors and 
running different software versions which would imply that their schema 
may also be different.

For point (3), this is a matter of preference, I like that fact that the 
mount point is explicit in the schema in structural-mount.  The ysdl 
meta-schema appears to be more flexible because it can in effect put 
mount points anywhere, but even with structural mount this same 
flexibility could presumably still be achieved by augmenting with a 
mount point.

For point (4), I think that this is useful functionality, and perhaps if 
structural-mount is to be used as the base draft going forward it might 
be worth considering whether the solution could be able to cover, or be 
cleanly extended, to this use case.

For point (5), I definitely think that it is beneficial that 
structural-mount has an intuitive solution for RPCs and Notifications.

For points (6) and (7) my gut instinct is that the structural-mount 
would be easier to standardize and also less work to implement.


Some of my points above may be incorrect, and that might swing the 
balance between the two solutions, so please correct me if I have got 
anything wrong.  Otherwise, just considering the written drafts as they 
stand now, my personal preference is that I would favour using 
structural-mount as a starting point for a solution.

Martin, I also have some comments/questions on the structural-mount 
draft, I'll put these into a separate email.

Thanks,
Rob


From nobody Thu Jan 21 06:56:20 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79401B3190 for ; Thu, 21 Jan 2016 06:56:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsLdKI2ENnsn for ; Thu, 21 Jan 2016 06:56:16 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 966DE1AC40B for ; Thu, 21 Jan 2016 06:56:16 -0800 (PST)
X-AuditID: c1b4fb2d-f79456d000001332-94-56a0f18dff67
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 7E.8B.04914.D81F0A65; Thu, 21 Jan 2016 15:56:14 +0100 (CET)
Received: from [159.107.197.206] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.3.248.2; Thu, 21 Jan 2016 15:56:13 +0100
To: "netmod@ietf.org" 
From: Balazs Lengyel 
Message-ID: <56A0F18D.4030505@ericsson.com>
Date: Thu, 21 Jan 2016 15:56:13 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprILMWRmVeSWpSXmKPExsUyM2K7q27fxwVhBs91LeZfbGR1YPRYsuQn UwBjFJdNSmpOZllqkb5dAlfGzp0bGAv+clQsvrWatYHxHlsXIyeHhICJxOE7S9ghbDGJC/fW A8W5OIQEDjNKXGo+wwySEBJYyygxZ6ckiC0ioC4xc+d6sGY2ASOJqf3nWUBsYQEtiZ+/3oDV 8wpoS5z+94QVxGYRUJX4f+UtWI2oQIzExc4jTBA1ghInZz4BizMLWEjMnH+eEcKWl9j+dg7U Xg2Jhxf+sk5g5JuFpGUWkpZZSFoWMDKvYhQtTi0uzk03MtZLLcpMLi7Oz9PLSy3ZxAgMqINb fuvuYFz92vEQowAHoxIPr8HN+WFCrIllxZW5hxglOJiVRHjD7y8IE+JNSaysSi3Kjy8qzUkt PsQozcGiJM6bLNMYJiSQnliSmp2aWpBaBJNl4uCUamDsU1mRvkz/0zGhf6JvNhccPyCp3/1c Z4/mJ9cpty+3X9h45nR96H6LrjCJ2tt+tdKLJXkl9c9/Fly1aZXglyOc2W3vrYou2nTrbDUX erjcTKexV+HkDbXb5ZvO9z5aPUM5Sff0jkWBETU3fl12XMCzr0z15PpV1pINu/u7Wi3i7dJE PLQE9PSUWIozEg21mIuKEwHityM4JAIAAA==
Archived-At: 
Subject: [netmod] Constraining instance-identifiers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2016 14:56:19 -0000

Hello,
We have some instance identifiers in our model but we want to contrain 
what they can point at. What is the best method for that?
- the referenced object can be in 3 different locations in the tree
- the referenced object is contained by lists, so we must be able to 
match any key values (e.g. need a wildcard)
- designers don't want to use leafrefs for internal reasons, and because 
we need the full XPath pointing to the object in the reference leaf

I wanted to do:

leaf pointer-to-thing {
     type instance-identifier {
         require-instance false;
     }
     must match (current(), regular-expression)
}


Some issues:
- instance-identifiers don't have a canonical format, so what is their 
value in an XPath expression?
- I didn't find a way to evaluate a regexp in XPath 1.0. Is there a way?
- if I have all the needed namespace prefixes in imports, can I just use 
them?

Any ideas? Thanks for any help.

regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com


From nobody Thu Jan 21 07:17:43 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4EB1B31D5 for ; Thu, 21 Jan 2016 07:17:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oy6knRGiJ4E5 for ; Thu, 21 Jan 2016 07:17: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 796431B31C9 for ; Thu, 21 Jan 2016 07:17:32 -0800 (PST)
Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id E0D8D1AE0386; Thu, 21 Jan 2016 16:17:30 +0100 (CET)
Date: Thu, 21 Jan 2016 16:17:33 +0100 (CET)
Message-Id: <20160121.161733.727143885958810312.mbj@tail-f.com>
To: balazs.lengyel@ericsson.com
From: Martin Bjorklund 
In-Reply-To: <56A0F18D.4030505@ericsson.com>
References: <56A0F18D.4030505@ericsson.com>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Constraining instance-identifiers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2016 15:17:35 -0000

Balazs Lengyel  wrote:
> Hello,
> We have some instance identifiers in our model but we want to
> contrain what they can point at. What is the best method for that?

Unfortunately, there is no standard way of doing this.  (There are
vendor extensions available...)

[...]

> Some issues:
> - instance-identifiers don't have a canonical format, so what is
> their value in an XPath expression?

This is not defined.

> - I didn't find a way to evaluate a regexp in XPath 1.0. Is there a way?

In YANG 1.1, there is a function re-match() for this purpose.  For
your use case, it *may* work to match just the local names of all
nodes, i.e., using wildcards for the prefixes.  It is not a generic
solution though.

> - if I have all the needed namespace prefixes in imports, can I just
>   use them?

No, these prefixes are local to the module that is doing the import,
and they may or may not match the prefixes used by the implementation
when it construct the instance-identifier value.



/martin


From nobody Thu Jan 21 08:51:17 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA87C1B32E3 for ; Thu, 21 Jan 2016 08:51:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8ybT39ufALP for ; Thu, 21 Jan 2016 08:51:09 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13A211B32E6 for ; Thu, 21 Jan 2016 08:51:07 -0800 (PST)
X-AuditID: c1b4fb3a-f79df6d0000013b1-af-56a10c7952d5
Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C8.69.05041.97C01A65; Thu, 21 Jan 2016 17:51:06 +0100 (CET)
Received: from [159.107.197.206] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.248.2; Thu, 21 Jan 2016 17:51:05 +0100
To: Martin Bjorklund 
References: <56A0F18D.4030505@ericsson.com> <20160121.161733.727143885958810312.mbj@tail-f.com>
From: Balazs Lengyel 
Message-ID: <56A10C79.1010601@ericsson.com>
Date: Thu, 21 Jan 2016 17:51:05 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <20160121.161733.727143885958810312.mbj@tail-f.com>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM2J7lG4Vz8Iwgwe3OCy6u5+xW8y/2Mjq wOSxZMlPJo+NvxazBDBFcdmkpOZklqUW6dslcGU8en+IpeAYT8WH9d4NjLc4uxg5OSQETCTO Hz7DBGGLSVy4t56ti5GLQ0jgMKPE36Z1TBDOWkaJa3dWMoJUCQuYS3z7s4UdxBYRUJV4snMt C4gtJJAo8evLArBJzAKiEusvXgKz2QSMJKb2nwer4RXQluhfvY8VxGYB6m37eRMsLioQI3Gx 8wgTRI2gxMmZT8DinAIOEr1fPwPFOYBm2ks82FoGMV5eYvvbOcwQazUkHl74yzqBUXAWku5Z CB2zkHQsYGRexShanFpcnJtuZKSXWpSZXFycn6eXl1qyiREYqge3/LbawXjwueMhRgEORiUe XoOb88OEWBPLiitzDzFKcDArifDmMi4ME+JNSaysSi3Kjy8qzUktPsQozcGiJM6bJNMYJiSQ nliSmp2aWpBaBJNl4uCUamBkuvzE99jVRh+xvLs7FdcaS83X7+75mB2o35e38+ivc4Isz+8Z 8c87bcfuZSPGyDWzb5+5cdxxzQW/pyyK8rXueCjBeMzi32+Fi2yaF/4sXcJx5LeE4M5Ttxu6 XxVP3ZIwd+rVksycZ5NvGMZb/v76sCt18d896x/0Pai88k5U8wCfXavmnN8blFiKMxINtZiL ihMBOGVyhVECAAA=
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Constraining instance-identifiers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2016 16:51:16 -0000

Hello Martin,
If the RFC would define that in XPath expressions an instance identifier 
MUST be evaluated to a string that complies to the lexical format, using 
the rematch function, we could do everything we need. In real life 
prefix clashes are a rare problem.
regards Balazs

On 2016-01-21 16:17, Martin Bjorklund wrote:
> Balazs Lengyel  wrote:
>> Hello,
>> We have some instance identifiers in our model but we want to
>> contrain what they can point at. What is the best method for that?
> Unfortunately, there is no standard way of doing this.  (There are
> vendor extensions available...)
>
> [...]
>
>> Some issues:
>> - instance-identifiers don't have a canonical format, so what is
>> their value in an XPath expression?
> This is not defined.
>
>> - I didn't find a way to evaluate a regexp in XPath 1.0. Is there a way?
> In YANG 1.1, there is a function re-match() for this purpose.  For
> your use case, it *may* work to match just the local names of all
> nodes, i.e., using wildcards for the prefixes.  It is not a generic
> solution though.
>
>> - if I have all the needed namespace prefixes in imports, can I just
>>    use them?
> No, these prefixes are local to the module that is doing the import,
> and they may or may not match the prefixes used by the implementation
> when it construct the instance-identifier value.
>
>
>
> /martin
>

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com


From nobody Thu Jan 21 09:53:21 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2EA81A88D0 for ; Thu, 21 Jan 2016 09:53:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tl-INWfIptRt for ; Thu, 21 Jan 2016 09:53:19 -0800 (PST)
Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::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 EE6701A88C8 for ; Thu, 21 Jan 2016 09:53:18 -0800 (PST)
Received: by mail-lb0-x22d.google.com with SMTP id cl12so27703774lbc.1 for ; Thu, 21 Jan 2016 09:53:18 -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:date:message-id:subject:from:to :cc:content-type; bh=a2BpOFv9/VQYOUvA+68xDyyUVTZWiZcqs+pwY0I5Oyg=; b=wOsy9jnpgPuzfEYfCyyqmqI9jJU0qajSS3KM0yZ7m6HLoZJBTT0kX613HaTyIVp1P1 UruwgMic8EG8EwyJRUtewzUNNT3Z1VlPq3ZOzVgdBwlCqxqQSCZtjV99CcRAz+cJeKFY zRRpFPb4Itdr/PuXcdFoJueJ4vUtacJ3W+1bYe/UXjfu6E84mT7ZZngv+DZuDXhizhg7 fc61mwww4PQMwsDQdqn5U3qjbdldoEJdsxVE229YF2SsU6I+vrgMEA0Vbt1BKumxlt/s Vl6xLG/XK2JRz4xenX2xTQ5YXOkea9Ugjjeb1H4kA7x9DvczU/gXGm1cvSz94zD6qTOq sb5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=a2BpOFv9/VQYOUvA+68xDyyUVTZWiZcqs+pwY0I5Oyg=; b=kpU0E6dap+nNQOGKfCb4CitX1k60hS4PuTIvYmFPAEfNcvUao6TNp8p839PI6BtSh0 Ez5TUrkIF2ErQ2RfGN2k7c9bM3Z55uO6QJRIn1l9+PHom2kRy0TfDNfxXE5uOfx2hwso 9HawzPEIqAl36ebcWY62jxnWzjicstJdLE9JSY5/AsiFhP+Kbe1DwKvHvHF7sc5I8lmD +uFoFRH5wcThJKacP2XEnQ+9BYIUY0/ffM2zumDQW05q8oUnyKEBQbSAMBfF0E97X+Us UoNuBUIx+DnO4MMwSpmsQ69bwad4voKODm9vbk8Cv8Bs8mM7cmUa1HMQ/HcGXUIPISbp 76Qw==
X-Gm-Message-State: AG10YOQaWiP8ZSBSd8GTALd5WLf10/0tpDjrKNWzs9PFkWSV79nCHc7nPY4fWB1YkwEcheUCsU2/xtg3sCV1mg==
MIME-Version: 1.0
X-Received: by 10.112.180.7 with SMTP id dk7mr15376432lbc.65.1453398797058; Thu, 21 Jan 2016 09:53:17 -0800 (PST)
Received: by 10.112.200.167 with HTTP; Thu, 21 Jan 2016 09:53:17 -0800 (PST)
In-Reply-To: <56A10C79.1010601@ericsson.com>
References: <56A0F18D.4030505@ericsson.com> <20160121.161733.727143885958810312.mbj@tail-f.com> <56A10C79.1010601@ericsson.com>
Date: Thu, 21 Jan 2016 09:53:17 -0800
Message-ID: 
From: Andy Bierman 
To: Balazs Lengyel 
Content-Type: multipart/alternative; boundary=089e0112cad00419410529dbc759
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Constraining instance-identifiers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2016 17:53:21 -0000

--089e0112cad00419410529dbc759
Content-Type: text/plain; charset=UTF-8

Hi,

There is no need to change the XML encoding or YANG encoding
of an instance-identifier.  The prefixes are completely different
in each.  Prefixes clashes do happen, especially since
there is no expectation that they are unique.  They are short strings
with no naming conventions at all.  E.g., I have seen "if" for
interfaces in multiple modules.

Andy


On Thu, Jan 21, 2016 at 8:51 AM, Balazs Lengyel  wrote:

> Hello Martin,
> If the RFC would define that in XPath expressions an instance identifier
> MUST be evaluated to a string that complies to the lexical format, using
> the rematch function, we could do everything we need. In real life prefix
> clashes are a rare problem.
> regards Balazs
>
> On 2016-01-21 16:17, Martin Bjorklund wrote:
>
>> Balazs Lengyel  wrote:
>>
>>> Hello,
>>> We have some instance identifiers in our model but we want to
>>> contrain what they can point at. What is the best method for that?
>>>
>> Unfortunately, there is no standard way of doing this.  (There are
>> vendor extensions available...)
>>
>> [...]
>>
>> Some issues:
>>> - instance-identifiers don't have a canonical format, so what is
>>> their value in an XPath expression?
>>>
>> This is not defined.
>>
>> - I didn't find a way to evaluate a regexp in XPath 1.0. Is there a way?
>>>
>> In YANG 1.1, there is a function re-match() for this purpose.  For
>> your use case, it *may* work to match just the local names of all
>> nodes, i.e., using wildcards for the prefixes.  It is not a generic
>> solution though.
>>
>> - if I have all the needed namespace prefixes in imports, can I just
>>>    use them?
>>>
>> No, these prefixes are local to the module that is doing the import,
>> and they may or may not match the prefixes used by the implementation
>> when it construct the instance-identifier value.
>>
>>
>>
>> /martin
>>
>>
> --
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> ECN: 831 7320
> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

--089e0112cad00419410529dbc759
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

There is no need to change the XML =
encoding or YANG encoding
of an instance-identifier.=C2=A0 The pr=
efixes are completely different
in each.=C2=A0 Prefixes clashes d=
o happen, especially since
there is no expectation that they are =
unique.=C2=A0 They are short strings
with no naming conventions a=
t all.=C2=A0 E.g., I have seen "if" for
interfaces in m=
ultiple modules.

Andy


On Thu, Jan 21, 2016=
 at 8:51 AM, Balazs Lengyel <balazs.lengyel@ericsson.com>=
 wrote:
Hello Martin,

If the RFC would define that in XPath expressions an instance identifier MU=
ST be evaluated to a string that complies to the lexical format, using the =
rematch function, we could do everything we need. In real life prefix clash=
es are a rare problem.

regards Balazs



On 2016-01-21 16:17, Martin Bjorklund wrote:



Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:



Hello,

We have some instance identifiers in our model but we want to

contrain what they can point at. What is the best method for that?



Unfortunately, there is no standard way of doing this.=C2=A0 (There are

vendor extensions available...)



[...]





Some issues:

- instance-identifiers don't have a canonical format, so what is

their value in an XPath expression?



This is not defined.





- I didn't find a way to evaluate a regexp in XPath 1.0. Is there a way=
?



In YANG 1.1, there is a function re-match() for this purpose.=C2=A0 For

your use case, it *may* work to match just the local names of all

nodes, i.e., using wildcards for the prefixes.=C2=A0 It is not a generic
solution though.





- if I have all the needed namespace prefixes in imports, can I just

=C2=A0 =C2=A0use them?



No, these prefixes are local to the module that is doing the import,

and they may or may not match the prefixes used by the implementation

when it construct the instance-identifier value.







/martin







-- 

Balazs Lengyel=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0Ericsson Hungary Ltd.

Senior Specialist

ECN: 831 7320

Mobile: +36-70-330-7909=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ema=
il: Balazs=
.Lengyel@ericsson.com



_______________________________________________

netmod mailing list

netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod





--089e0112cad00419410529dbc759--


From nobody Thu Jan 21 14:03:34 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E43D1B33D8 for ; Thu, 21 Jan 2016 14:03:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.096
X-Spam-Level: 
X-Spam-Status: No, score=-0.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TC6SOBtE0lNP for ; Thu, 21 Jan 2016 14:03:33 -0800 (PST)
Received: from mail.hq.sk (hq.sk [81.89.59.181]) by ietfa.amsl.com (Postfix) with ESMTP id D10881B33D0 for ; Thu, 21 Jan 2016 14:03:32 -0800 (PST)
Received: from [172.16.0.179] (188-167-8-120.dynamic.chello.sk [188.167.8.120]) by mail.hq.sk (Postfix) with ESMTPSA id 1836B242020; Thu, 21 Jan 2016 23:03:32 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1453413812; bh=bKw136DCo3/zstDmKoRs5NvmxSTGUO+yzKg5hNIUwzQ=; h=Subject:To:References:From:Date:In-Reply-To; b=BJvB7SauxXG5gnKP8sq5T2m4P9t9isw6f649MZzOFoyBGH2AVP+jH2Q9M4UvZQ4M3 sMlaWGRyDTCmdRV0D4LQeQnhh96HAoA9wngcoJgfQbdUi40XAYISi4F+BH4+ZF612q OWKssXR9qJRAWFTo36aF2tGjddEjC1C+gUumGb6w=
To: Martin Bjorklund , netmod@ietf.org
References: <20151218.092341.1370454568296215965.mbj@tail-f.com>
From: Robert Varga 
Message-ID: <56A155B3.2090506@hq.sk>
Date: Thu, 21 Jan 2016 23:03:31 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <20151218.092341.1370454568296215965.mbj@tail-f.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-structural-mount-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2016 22:03:33 -0000

On 2015-12-18 09:23, Martin Bjorklund wrote:
> Hi,
>
> This draft proposes a mechanism for mounting YANG models in other
> models.  It focuses on the *schema* only, not on the underlying
> mechanism to implement the data (like "peer mount").

Hello Martin,

one question on containment: is if fair to assume the mechanism can be 
implemented in a recursive way, e.g. nested mount points would be 
exposed in /mount-points within the mountpoint itself, not in the global 
one?

Thanks,
Robert


From nobody Thu Jan 21 16:18:41 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C421B3551 for ; Thu, 21 Jan 2016 16:18:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxDvmu7YhVUs for ; Thu, 21 Jan 2016 16:18:37 -0800 (PST)
Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 2582F1B354D for ; Thu, 21 Jan 2016 16:18:36 -0800 (PST)
Received: by mail-lf0-x229.google.com with SMTP id c192so37208679lfe.2 for ; Thu, 21 Jan 2016 16:18:36 -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:date:message-id:subject:from:to :cc:content-type; bh=1tJ9dslHJLXffIT3OoAJEkrxCxNaAVi0gUBj89mUYE4=; b=uTuoEfsFTzZgTgZ90f+PT97zVgynjnuHVbzF1AdhLJiTJ7ZUdLF8Qpj9dO8HNDARU3 8xBfWWTXtgiKo7OyQAreVMi1YJklcm4DVIC9Erf6fv5O2qIpWzmDuzmRue3JheK7DBMg umU1o925kSHf9vJw0yX3reYpehQX9mAB75W+toXkMcin+Lzp/N8DQL6PElZoMm2DnUCO giTqJqMjzY7dORowT89pGRTj4YBEuAbXonLm9SL0b/QLUoKZrU+v61z/67bRlCowLnDi y/2hU/E4o71JwPiCVdZGbMZG53Xz7dEjTlKz1SkwTzzH2Y8lxKfzdAlaXY+fWfzo3265 CPug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1tJ9dslHJLXffIT3OoAJEkrxCxNaAVi0gUBj89mUYE4=; b=k73dLSij5AMNETqFk36WGw/u8KePDt/sYOoTAKd9q4oYDw+KYeCB0OFCi8faprmnQJ jmkpDq41CdAznRQF/4qJeiBF1cYcvvchj7F3P7RUS+8/79AvzU6/jIFwAIlk5nQtOtQD Np46lX3XRlDXP82rdCu2wDRkah8yHFc4mqVI0Ay35vRoywqVNqH4+M2tTXCdMJD44jbD TXh/nHWSN2zv+yXLvWLn77mTtfKbG9fXo2mLDKk7TIKihbFsYgdUKxs89mwDLO6Sy0nD +egWCXMBqWoP3V4W+B9fwK1r79PXc5omS8iLFFZ4u5y6g3mCcz8oVQMhd7pf7FH+R9PR Vmow==
X-Gm-Message-State: AG10YOQVK1dSsKeL/1+Kg0KaSbRFxkejXM8fqBYP+1jmrWIjAk6jMlg22KL+HGNm+DXjczUmEjn8zXHiMENwxQ==
MIME-Version: 1.0
X-Received: by 10.25.77.203 with SMTP id a194mr63507lfb.62.1453421915247; Thu, 21 Jan 2016 16:18:35 -0800 (PST)
Received: by 10.112.200.167 with HTTP; Thu, 21 Jan 2016 16:18:35 -0800 (PST)
In-Reply-To: 
References: <2431FE7A-9CC9-48A6-92FF-AE383DB71394@broadband-forum.org> 
Date: Thu, 21 Jan 2016 16:18:35 -0800
Message-ID: 
From: Andy Bierman 
To: William Lupton 
Content-Type: multipart/alternative; boundary=001a1141f2c4f7aedd0529e1285d
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Broadband Forum questions on RFC 6087bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 00:18:40 -0000

--001a1141f2c4f7aedd0529e1285d
Content-Type: text/plain; charset=UTF-8

On Wed, Jan 20, 2016 at 6:45 AM, William Lupton  wrote:

> All,
>
> I didn't see any follow-up to these questions / comments. Any thoughts?
>
> Thanks,
> William
>
> > On 11 Dec 2015, at 12:54, William Lupton 
> wrote:
> >
> > All,
> >
> > Here are some questions / comments from the Broadband Forum on RFC
> 6087bis-05.
> >
> > Thanks,
> > William
> >
> > --------
> >
> > 1. Potentially confusing use of the term "prefix"
> >
> > Section 5.1 (Module Naming Conventions) talks about prefixes but in this
> context means "strings at the beginning of module names" rather than YANG
> prefixes that are the topic of Section 5.2. This could (and did!) cause
> confusion.
> >
>

I will change the text so the term prefix is not used



> >
> > 2. Rules re changing submodule names
> >
> > Section 5.7 (Lifecycle Management) says that "The [...] submodule name
> MUST NOT be changed, once the document containing the module or submodule
> is published" but this might contradict RFC 6020 Section 11, which says "A
> module may be split into a set of submodules, or a submodule may be
> removed...".
> >
> > More specifically, 6020 doesn't mention renaming a submodule (so
> presumably that's not permitted), but the mention of both splitting modules
> into submodules AND removing submodules suggests that arbitrary
> module/submodule refactoring is permitted. And if I'm being pedantic,
> revision #1 could have submodule A1, revision #2 could remove it, and
> revision #3 could reintroduce it as submodule A2, so that's effectively a
> rename!
> >
>


I do not see any issue here.
Moving an object does not change the submodule name.

The main module is required in YANG 1.1  to include all its submodules to
emphasize
that they are not hierarchical and they do not have any sort
of "sub-namespace" property.



> >
> > 3. References to RPCs need also to mention actions
> >
> > In most (or all?) places that RPCs are mentioned, presumably actions
> need to be mentioned?
> >
>

I will check that



> >
> > 4. Implications of adding defaults
> >
> > Section 5.12 (Reusable Type Definitions) says that "If an appropriate
> default value can be associated with the desired semantics, then a default
> statement SHOULD be present". Is it correct that adding a default
> effectively adds a MANDATORY requirement for a server to support the
> default value for that node, and therefore to support the concept modelled
> by the node (albeit only with the default behaviour)? Whereas if there were
> no default then there would be no requirement at all to support the concept
> modelled by that node? If so, then adding a default seems like something
> that shouldn't be done lightly... or am I making too much of this?
> >
>


Yes it adds a mandatory implementation requirement for the new revision.
This is no different than any change to a module, like restricting the
range of an integer.



> >
> > 5. Guidance re YANG features
> >
> > 6087 doesn't always refer to features consistently. For example Section
> 5.5 (Conditional Statements) says "If a data definition is optional,
> depending on server support for a NETCONF protocol capability, then a YANG
> 'feature' statement SHOULD be defined" (which seems to tie the "feature"
> concept to NETCONF protocol capabilities), whereas Section 5.17 (Feature
> Definitions) says "The YANG "feature" statement is used to define a label
> for a set of optional functionality within a module". The latter
> description seems more in keeping with the spirit of 6020, so perhaps the
> former text could be adjusted to align with it?
>

OK -- the SHOULD text will be removed



> >
> >
> > 6. Guidance re YANG deviations
> >
> > The 6020 discussion of deviations is mostly about implementing LESS
> rather than MORE. Obviously the deviate statement's "add" argument is
> described (and there is an example) but there seems to be no discussion
> that use of deviate with "add" might be a GOOD thing.
> >
> > The 6087 discussion of deviations says that they can be useful for
> documenting server capabilities but again the emphasis seems to be on
> documenting implementing LESS rather than MORE.
> >
> > The result seems to be that deviations have a bad name. If indeed there
> are accepted good uses of deviations then it would be good if this was made
> clearer, both in 6020 and in 6087.
>
>

I don't agree this is a good idea.
Adding sub-statements can damage interoperability just the same as
taking things away.  E.g., add a must-stmt to a leaf that the client doesn't
know about.


Andy


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

--001a1141f2c4f7aedd0529e1285d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Wed, Jan 20, 2016 at 6:45 AM, William Lupton <<=
a href=3D"mailto:wlupton@broadband-forum.org" target=3D"_blank">wlupton@bro=
adband-forum.org> wrote:
Al=
l,



I didn't see any follow-up to these questions / comments. Any thoughts?=




Thanks,

William



> On 11 Dec 2015, at 12:54, William Lupton <wlupton@broadband-forum.org> wrote:

>

> All,

>

> Here are some questions / comments from the Broadband Forum on RFC 608=
7bis-05.

>

> Thanks,

> William

>

> --------

>

> 1. Potentially confusing use of the term "prefix"

>

> Section 5.1 (Module Naming Conventions) talks about prefixes but in th=
is context means "strings at the beginning of module names" rathe=
r than YANG prefixes that are the topic of Section 5.2. This could (and did=
!) cause confusion.

>

I will change the text so the term=
 prefix is not used

=C2=A0

>

> 2. Rules re changing submodule names

>

> Section 5.7 (Lifecycle Management) says that "The [...] submodule=
 name MUST NOT be changed, once the document containing the module or submo=
dule is published" but this might contradict RFC 6020 Section 11, whic=
h says "A module may be split into a set of submodules, or a submodule=
 may be removed...".

>

> More specifically, 6020 doesn't mention renaming a submodule (so p=
resumably that's not permitted), but the mention of both splitting modu=
les into submodules AND removing submodules suggests that arbitrary module/=
submodule refactoring is permitted. And if I'm being pedantic, revision=
 #1 could have submodule A1, revision #2 could remove it, and revision #3 c=
ould reintroduce it as submodule A2, so that's effectively a rename!
>


I do not see any is=
sue here.
Moving an object does not change the submodule name.

The main module is required in YANG 1.1 =C2=A0to inc=
lude all its submodules to emphasize
that they are not hierarchic=
al and they do not have any sort
of "sub-namespace" pro=
perty.

=C2=A0

>

> 3. References to RPCs need also to mention actions

>

> In most (or all?) places that RPCs are mentioned, presumably actions n=
eed to be mentioned?

>

I will check that

=C2=A0

>

> 4. Implications of adding defaults

>

> Section 5.12 (Reusable Type Definitions) says that "If an appropr=
iate default value can be associated with the desired semantics, then a def=
ault statement SHOULD be present". Is it correct that adding a default=
 effectively adds a MANDATORY requirement for a server to support the defau=
lt value for that node, and therefore to support the concept modelled by th=
e node (albeit only with the default behaviour)? Whereas if there were no d=
efault then there would be no requirement at all to support the concept mod=
elled by that node? If so, then adding a default seems like something that =
shouldn't be done lightly... or am I making too much of this?

>


Yes it adds a manda=
tory implementation requirement for the new revision.
This is no =
different than any change to a module, like restricting the range of an int=
eger.

=C2=A0

>

> 5. Guidance re YANG features

>

> 6087 doesn't always refer to features consistently. For example Se=
ction 5.5 (Conditional Statements) says "If a data definition is optio=
nal, depending on server support for a NETCONF protocol capability, then a =
YANG 'feature' statement SHOULD be defined" (which seems to ti=
e the "feature" concept to NETCONF protocol capabilities), wherea=
s Section 5.17 (Feature Definitions) says "The YANG "feature"=
; statement is used to define a label for a set of optional functionality w=
ithin a module". The latter description seems more in keeping with the=
 spirit of 6020, so perhaps the former text could be adjusted to align with=
 it?

OK -- the SHOULD text will be remo=
ved

=C2=A0

>

>

> 6. Guidance re YANG deviations

>

> The 6020 discussion of deviations is mostly about implementing LESS ra=
ther than MORE. Obviously the deviate statement's "add" argum=
ent is described (and there is an example) but there seems to be no discuss=
ion that use of deviate with "add" might be a GOOD thing.

>

> The 6087 discussion of deviations says that they can be useful for doc=
umenting server capabilities but again the emphasis seems to be on document=
ing implementing LESS rather than MORE.

>

> The result seems to be that deviations have a bad name. If indeed ther=
e are accepted good uses of deviations then it would be good if this was ma=
de clearer, both in 6020 and in 6087.




I don't agree this =
is a good idea.
Adding sub-statements can damage interoperability=
 just the same as
taking things away.=C2=A0 E.g., add a must-stmt=
 to a leaf that the client doesn't
know about.

=


Andy
=C2=A0

_______________________________________________

netmod mailing list

netmod@ietf.org

https://www.ietf.org/mailman/listinfo/netmod





--001a1141f2c4f7aedd0529e1285d--


From nobody Thu Jan 21 21:37:27 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC7E01B3890; Thu, 21 Jan 2016 21:37:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvwSa_8qv3VQ; Thu, 21 Jan 2016 21:37:22 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0107.outbound.protection.outlook.com [65.55.169.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 DF2A41B388E; Thu, 21 Jan 2016 21:37:21 -0800 (PST)
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=exa@juniper.net; 
Received: from [172.29.100.39] (66.129.239.14) by BN3PR0501MB1154.namprd05.prod.outlook.com (10.160.113.151) with Microsoft SMTP Server (TLS) id 15.1.365.19; Fri, 22 Jan 2016 05:37:18 +0000
To: Dean Bogdanovic , Juergen Schoenwaelder 
References:  <20151211113156.GA43862@elstar.local> <2059AD77-5375-4DB0-A1BF-432835F11A9F@gmail.com> <20151221153312.GA43316@elstar.local> <2BAA2B26-EE40-4707-BBDB-C84E5653CF23@gmail.com> <20160111183053.GA565@elstar.local> 
From: Ebben Aries 
X-Enigmail-Draft-Status: N1110
Message-ID: <56A1C007.7050607@juniper.net>
Date: Thu, 21 Jan 2016 22:37:11 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [66.129.239.14]
X-ClientProxiedBy: BLUPR0201CA0027.namprd02.prod.outlook.com (25.163.116.37) To BN3PR0501MB1154.namprd05.prod.outlook.com (25.160.113.151)
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1154; 2:4eOJH6H6NzvjeEy2m0VpbO6Tpo3zlBf7BRMfe8pKJr6i21auL7gLd2G792ueBsrUqadel7aYAv5LtwD9yHvEWqvb0lNHih5v3Jd/A5IqypFciqHc3WTliTyMOH2rg75N5Id0d8jKmmLRKkkDycQw0w==; 3:YRN0ozwm+S8JfQsLCasZF8QldRPH9W4CfboORr2fVhnjzBYJHyNcGctkbg/uDorlDl2uAHeQpis6Vwm+FgUqYwGtx3Bc6bAZjkFE7DzIaWl6WDHZ9H4wxpx/0yc90HAT; 25:IKMOJ37EvOCVG860TpM/Jry+Dy1maHl+lQjClkDrGCAoYzs5CmUVQpfNYvBk/YgRMYLRJcgeaB9mjCrfJOqc6QeZrJYVlvNO+r9uKSzuwyPKKedLwLwkR/1hPJKdNW20xiRffGgZk3a6tB3ZQzw6auGOvz+S1DnwzfHK6qLsa2IR9v1IVkYjcDF2pGlG5T+2VVddS9jfMLTduXFpUrSQtChjZRFNPxgRZ3ICYe/L1Z0kNSi/hwlc1wqGIdsgl9pa
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1154;
X-MS-Office365-Filtering-Correlation-Id: 83b0b6a1-3121-412e-7d2b-08d322ee18aa
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1154; 20:L9FOf2ZoBNWB3+Tski+ptANAzvu5eH3fh1oCdqR9X7W5lmbMvZzOXL/b52w8v7q0Brxh/7Hpb0Gcxgd2odV42MVDs+7qPpSKylMFv9Olr78NuEqD4ia9QKTgq6nD/3KEzUQM/Od0kaygui0HXsk+wm8XjtcwSBYMIqBxZT1B1chTa9qK3wRdl1HmDwAHp1vNhPTvZQbPfQ0fplGa21JPxS50vswNPz+BCplUTNcx8t89aN7q/jeQ2JK8CyT7UvLsRhM+7UB2thodu5KXlAptJAs8O4nKuoUkdCswL7qN0HrGYVm1la/eUHhOq3igaHJWEd/8iyFFEZM1QF8yWiK8P1xFfqJ67POURF/j+E31N6yWqE19LuL8IVuPgmNRXH2PwKx/S96WlxplIkGYGMKJeTE26xVLCbTuBZUujeS+5Snn27BXgj3t1JamCjKg2JfbcyI4YBybj09UUmnY+U3p84Wtzmvk2Lq6ydH1EF7N6ULi+WV/d8qgfJICREA52RzJ; 4:OxGR4LvefIJPW6r62Z3Dg7/B7NZ+BFrti/zfcS6Kico3IuhehLqTNJnd5/is2pSjss5YHSABsYYwhLBTL3pKHOz7xrCe/sD0XSTRwvS2ozCPrWjnzq0+2AhbDWi9uLoI/TpfC8nCWasIlXw5L+Jl1GOw3+7L1/sEGE1ACPZvVr0ZqTohXRY6fyJ7NdAAxB0yc0yRbAfrL/6Yj5a9EbTQarilyCmy6D4AwMcXGCZEJH9hV+vZpiV63v7LgV1yANNxNPXaFJDnrAeQcenbFdlvt2kd2TTnSNPMuaUtD3KFr1GdVVtZy0DbLv2BgYRaXSiUa42gy4HjkQLeyBbdq8z5MIStZukNSJT6UKj1qWDU8mZ2J8Amuvl8xu+QJwu+BR40
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001)(10201501046); SRVR:BN3PR0501MB1154; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1154; 
X-Forefront-PRVS: 08296C9B35
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(189002)(377454003)(479174004)(199003)(24454002)(5001960100002)(65806001)(2906002)(50986999)(76176999)(4001350100001)(5001770100001)(97736004)(81156007)(5008740100001)(87266999)(101416001)(189998001)(86362001)(92566002)(59896002)(230783001)(93886004)(65816999)(54356999)(5004730100002)(83506001)(40100003)(122386002)(23676002)(230700001)(77096005)(65956001)(106356001)(2950100001)(47776003)(6116002)(87976001)(33656002)(1096002)(64126003)(586003)(80316001)(50466002)(4326007)(36756003)(3846002)(105586002)(42186005)(66066001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1154; H:[172.29.100.39]; 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)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjNQUjA1MDFNQjExNTQ7MjM6TTFqYVNVTW9NT3YzWTNxNkJSV0RUVktE?= =?utf-8?B?SXQ4MGFybkdIcjFubDRjRnp6RXk1WWcxWGZVMGJPRXYwditaVXE3Qy9MS0Zu?= =?utf-8?B?ZGxJK2Mzd2N5Z2RPQ3Z0Y0U0ay9SMmp4Sjlia1BOOVZtcU5WeTVDVUowZVNy?= =?utf-8?B?cEo0KzlsYStyTlNsSHp2bDNac2dUaWlnRU1pcnIwMHVFbGl0WkRwK0RuSjJm?= =?utf-8?B?THBTbGpBRkZ6R25ydFRvRWJPZ0w0Z1F4UGFIdGdnSUkrcXNtVzVnemtRcWFw?= =?utf-8?B?THpxVktFU2RFRUpBL0tYK2pLWVhyVW1ML2t1dGxkM1ZpZnZseWhKNnRuNXlX?= =?utf-8?B?bHhhaC9Pc0NlY3VteVBYNFJuVldNenowdS84WFM3MCtJR1l3UGtpK1g4WTV3?= =?utf-8?B?cndPRys4L1ZGTnJEVUJKdDQzcy9vZFFvOGlXcGdCR09iOVJ1QlNjT0lnTTZJ?= =?utf-8?B?K0hqdGtUeTBNN3Ivc1J3czl0eXpBRXVHeTgyRGFNYkw3ajdHYkVRclNWVGpW?= =?utf-8?B?U1JIVnArTTlWUXpkUmt3WTAxUnF0RUtqTWxhejljL014Z2FMSmR2azd1YnFn?= =?utf-8?B?aXF6dVhhNE1KSmdzZ0FGdXA4YkErZWVZcXYxWHpGS2t5Tmo5Y2hWVENKUCtw?= =?utf-8?B?TmVxUEVHZWVGcENvaXNiSDJmSGlScVEwSDhoNktzeWRwcGNDY3BiWlN0L1Ay?= =?utf-8?B?TUxnS002Y2F5TGh0L1gvM0kwMElwUGlPcU02YVhlVmQxaUFGY0ZNdnNEaS9G?= =?utf-8?B?dk9oaUZzUWhzQ3AxMzNkNzB2SGUxTTA2T1QyV0JrcnJBOVN1SjE2REJ1bVZX?= =?utf-8?B?ei9Damo1ZUhkYy9iRzZsejYwUGYwcFpHc0pRTkNVbmN4d1JmTnFXeDN4SWtH?= =?utf-8?B?QkhMVTVLTnFHN25KbmJjdnlsbU4rY05ocE9Mak80UktaRml2OFMvWFRrTHpN?= =?utf-8?B?TnZXWU1ZdEViTDFHcGRlQnMxMm9XVVRtd1VPZm85QnBGTFgzMWx1Smlsam9W?= =?utf-8?B?RHJ1V0FYZUxOZ2RlajdDWC9yM01ZUCszTlRSQXJybGRPRHpxL3NMM05VVjdU?= =?utf-8?B?RklwYS8xZ0I2aDRFMGx5K0M3RGlra2lmMUYzMHNYV2pDR3JXTVZGSm00bGhk?= =?utf-8?B?TTEwaFhwNUsrZTZRTzBickt2VFFoQk41Yk1Nc2Y3SXc1WGNUd0hXVUMvR1Bh?= =?utf-8?B?MEtScEc2TVFGNlFRa2p0KzByL29rVHp0ME5UZ2lDQlN0aDNtaGpQOVIwM2g4?= =?utf-8?B?cXZIdGkyOXlPbG5lVitESjBWamZsU2V6bElQd28zNEljaUN6bmNjZGdBL1cw?= =?utf-8?B?cW1tc2xTeDN5VjZSOUdNWWJkNlBxcFlDUlZDNmRRYjBNaitCQ0pGQU9scUZP?= =?utf-8?B?bVpTa1orVDY3d0orN1FBY3NlMjVvdy8zTExjVW9lMVhMbFFpVSs5STgzd1Ir?= =?utf-8?B?ajNNTGNBTXN2ZDJHUGs5VmlCQTc1QjlaMTNRK2VrKzVPYXU3RVdXOVdOQm5N?= =?utf-8?B?Ums2ZW1tR2swU1ZQZzdQMDY2djlBdC9zb3Q2Q3pkbVowb0VFTVBwdDQ5VjJo?= =?utf-8?B?d3BkMnhqYzBkMXpKT3N4bjJkWkF6KzlOY1dnZ0dseUNId0xtOCt6VlhWazJ2?= =?utf-8?B?b0JraVZLU2RjUGVOejBSelNodzk0SnBiKytGejlOdHZ5Uk9KbENkZ09jT2RP?= =?utf-8?B?QlNGR21hdUdSemNrRDhZMStDTzFSK09PNGE3cE9MR0E1Q3hiM0NYY1loazRj?= =?utf-8?B?L1pHeHVKNHZUKzZnN0Y1WmREdVJGZUdPRlppVENYbTdpNEg3RC9HbWhRSzhy?= =?utf-8?Q?pI5duZk5dxtLAXf?=
X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1154; 5:2nN13hprXWaOg+mJuQjPYJlImIfM4ULV/yOPZLMkY8CGBL7MLH4IsJxl0eob+9ngeHJ7B/YnRi77Ippk5pw4vPKTN68E/s6aREM0jTGIuU+Tpf7oANW4zziEspOMDg0EbfQV9ow0fV3UmJ6um1Bkmw==; 24:R34jfK+MYmcsz51wFog5AN8DyuL26F5y37YDAKHKuhKfUJhEgkHEIcaAV/SQto1BYktSQEhfYc0UJh8Q6z1ISUSbliDwsxTAPGNQy//BaTo=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2016 05:37:18.7321 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1154
Archived-At: 
Cc: Benoit Claise , RTG YANG Design Team , netmod WG 
Subject: Re: [netmod] [Rtg-dt-yang-arch] [yang-doctors] Working group Last Call: draft-ietf-netmod-acl-model-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 05:37:26 -0000

On 01/19/2016 08:11 AM, Dean Bogdanovic wrote:
>>> >> Authors are Cisco/Juniper people, so were using that terminology and I believe that CSCO and JNPR are more used in networking then Linux :)
>>> >> 
>> > 
>> > If I were to have the time, I would even challenge you on
>> > that. Clearly, when you consider # of devices connected to the
>> > Internet, I am sure CISCO and JNPR will loose. But even in enterprise
>> > networks, there are tons of Linux and BSD firewalls. Consider all the
>> > home routers running openWRT and packet filters. So yes, if I would
>> > have time, I would challenge you on that argument.
> I would definitely take you on this one. As OpenWRT is domain of hobbyist. If I may ask you, what device your ISP is sending you as access point? :)
> 

Consider all of the massive content/DC server farms which may run on
every host.  Between this, home routers and other Linux/BSD based
network connected devices, I'd say nftables, iptables, pf, etc.. are
nothing to discount here as 1st class citizens

/ebben


From nobody Thu Jan 21 21:52:10 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3E71B38C2; Thu, 21 Jan 2016 21:52:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CrqlTvodCzH; Thu, 21 Jan 2016 21:52:08 -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 2B7F31B38B9; Thu, 21 Jan 2016 21:52:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1418; q=dns/txt; s=iport; t=1453441928; x=1454651528; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=EKW2ApFs49pjMt/pNL9IIu+kravsszNSOMpZL7X9ym8=; b=HuQNrmnzJn3llXbixVixgoPbZp7FnShMMBhPqh9PkgcDE/P2O9hSLuWa BBrDnmvhz4fWlV8tXgRbHKvZf1NUvR1QAXSt4YE8djE60U9U913x865Um nqJz6dirPSb3Uo4Jxei27h73sYPuvtjEfFemk8TwEVT+gHm9xbx4JOxLn Y=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BzBwCkwqFW/xbLJq1ejVC0EIYPAoISA?= =?us-ascii?q?QEBAQEBgQtBEAGDcAEBBCNWEAsOCgkaBwICDwJGBgEMCAEBiBeuc489AQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQ8IiyeEM4MZgToFlneCeYFjiHqBXoREgwSFU44+YoIxg?= =?us-ascii?q?TY7hVOBfgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.22,329,1449532800";  d="asc'?scan'208";a="624713603"
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; 22 Jan 2016 05:52:05 +0000
Received: from [10.61.200.145] ([10.61.200.145]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u0M5q5lj023476; Fri, 22 Jan 2016 05:52:05 GMT
To: Ebben Aries , Dean Bogdanovic , Juergen Schoenwaelder 
References:  <20151211113156.GA43862@elstar.local> <2059AD77-5375-4DB0-A1BF-432835F11A9F@gmail.com> <20151221153312.GA43316@elstar.local> <2BAA2B26-EE40-4707-BBDB-C84E5653CF23@gmail.com> <20160111183053.GA565@elstar.local>  <56A1C007.7050607@juniper.net>
From: Eliot Lear 
Message-ID: <56A1C384.10000@cisco.com>
Date: Fri, 22 Jan 2016 06:52:04 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56A1C007.7050607@juniper.net>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PlUjwsaW4w6Qeta6jOHwGXfNPCmPquUsF"
Archived-At: 
Cc: Benoit Claise , RTG YANG Design Team , netmod WG 
Subject: Re: [netmod] [Rtg-dt-yang-arch] [yang-doctors] Working group Last Call: draft-ietf-netmod-acl-model-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 05:52:10 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--PlUjwsaW4w6Qeta6jOHwGXfNPCmPquUsF
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi,

On 1/22/16 6:37 AM, Ebben Aries wrote:
> Consider all of the massive content/DC server farms which may run on
> every host.  Between this, home routers and other Linux/BSD based
> network connected devices, I'd say nftables, iptables, pf, etc.. are
> nothing to discount here as 1st class citizens
>

We are talking about labels and not the concept, where there the
conceptual approach doesn't vary that much.  Pick SnaggableFarb and
let's move on, please?

Eliot




--PlUjwsaW4w6Qeta6jOHwGXfNPCmPquUsF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2

iQEcBAEBCAAGBQJWocOEAAoJEIe2a0bZ0nozer4H/3WcUYREiYsXUdzSBJhuVxYC
bOy6HMCqea9HLXWqBUJmdpYtttr06mXRRG8+V1eKjStr/DhnUDQwi2sC59HjUDK/
wX6sm4j4xOSK1qcz3hdtpA3WAkLNof7uusBNshe6gOHJqrnT4hrhjHJuIj5kMLjS
NPXOebBY18+LLiVKPFjE3usHDcjvsHNt7N9Vpy56KzV1Avy0QGXSUFPQlE0Ircnv
NOUoNdByriIO7K1zhV7O+mUQuChGVAdZ2OOCxzuYYhICZ+Juh3hMXG3+B+QXsID4
lNuCB71hr18WfRUTfJ359xp4aoRkQc7hIZvING+3K7sHeUE4apQocc+334tEnzU=
=lfK8
-----END PGP SIGNATURE-----

--PlUjwsaW4w6Qeta6jOHwGXfNPCmPquUsF--


From nobody Thu Jan 21 21:56:44 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D41411B38EA for ; Thu, 21 Jan 2016 21:56:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WU_H4wBLtkhX for ; Thu, 21 Jan 2016 21:56:41 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0755.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::755]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94C001B38DD for ; Thu, 21 Jan 2016 21:56:40 -0800 (PST)
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=exa@juniper.net; 
Received: from [172.29.100.39] (66.129.239.14) by DM2PR0501MB1167.namprd05.prod.outlook.com (10.160.245.16) with Microsoft SMTP Server (TLS) id 15.1.390.13; Fri, 22 Jan 2016 05:56:23 +0000
To: Qin Wu , netmod WG 
References: 
From: Ebben Aries 
X-Enigmail-Draft-Status: N1110
Message-ID: <56A1C480.7000509@juniper.net>
Date: Thu, 21 Jan 2016 22:56:16 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [66.129.239.14]
X-ClientProxiedBy: BLUPR0201CA0024.namprd02.prod.outlook.com (25.163.116.34) To DM2PR0501MB1167.namprd05.prod.outlook.com (25.160.245.16)
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1167; 2:/PJLpcIH2jQOiYteTB8fVx2/lCS906mzOBKlflsZCl/WWFbaky7ttbEYwkIerKYiMqGyMHt6NOhw5G3GURcjQhNuFFZvwxyI5FzOFMfprY5cClCc1627zsTkxG43VDYDFDY8utyC3hFThwwpV8teTw==; 3:lHMgySnAsQPbL6GnpAcF84eQrQut2TxbwttWW9QuGLYnBGrgvdbQ3V/vSmqZ9eB+k6fFvXswYprZkwU1ZVqznEI+rZCAihScukdiLuR5asIol/7Rn+V66+A5RZSaUTfh; 25:NMlBXXFXcLrues5oaWDzErZ+MZZFX/v8rEFbaRaDeoTSlmDyjoQiQyca4uxXQ9RNm3vd2CFN5IZ1lX3vIG/YS8VfzTnKIB4MRYbgHqe67lyFpOzTiX41A7OGOhDMq6fdVa2+L9z0lZ0G8QsKnN6mmyliH2GHjZ3N0O0wjwDe3v3bWmxVxav56TFa4ZH3tKuiYJUpOt4Wk1mEk7/N/vErKpZD+649s0q+PwkTMnBuEtLaUPA5vOOnfiOUf8qwaeJU
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1167;
X-MS-Office365-Filtering-Correlation-Id: 8faffc01-214f-4d17-04e7-08d322f0c2c6
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1167; 20:fbuviTi9j7B5EVaIxSlJuPzwkY/eht8N1oZKvA6fV1dNB7IxEAeV2a09e3BL+JDNIAUfryYxakAlWg67AFeBoAhoDxJUtHiqw55TDzuDdwz8jgdx6MCO7wsgCNEgGRh0OTyTMrqixnd52x6XwI965er3lUqv4lJDKLpT0py4imDX2BYhfUc8o1bTLqE2yruafyuovUu0xSjywPxui4mG+VQM4m0WTqEVytPYjQzgSiSqibN7ip8+RYYUcOuRBz92d64wGT8SQTEboxiUjfYNBI2jvxzHoEMchQhhqeyxRsZv/oMl/7l/dUC10sv8SL/T2pFx5yJZ3HgVsZkinklkq1qAmpDCA2rm5gBBxlMbvqz4gMJcwDjvUKcjX+Bayoam+IxCoqEA+5AN45cHY4C3/0Of+2Z3X8MnGKLCkwCc+8RDZ49OKVEp8dV8Ed9DGqAwdqOW9N56aFQaRT4ybl6A/q9GcLKBwDbqplz7b1d238E26BfhuuPuhvEAGJb7HqTa; 4:1pbtdt61UIeaoTxfQ9Z6uHMys41Skjg4wlrbHcG2Sdsfb9qUff/TW6BBW+L7PrNTzgFzRk/GgzG9WHpxNGTUCpBE/Ai7Xsk8iHERnSyw5GSa79qdvjJAwPt5CiQf7tqbf7o2Z0e7YKbdtlbgI3mVhc3wbu6X0SRmYq5GYt/VmfsN9sRyUH0qE4vCl9QSKVfPCvbvOLGVayKLkMmWXY+i/ZBKAfTH9xrep++WqWHkMt6TWpDi7rJYMcYU8dKCLzqJmG6uWqk7xHUrNXUeuvrgjtoffEB3U0pfc3QzpdLvDEBEUk8LlC3NyA0EEyJDDPUbP06y2RJzSnIiSZICa8lheNUqJa7Up0fcWR1KQxWe6iNlYJd6Wg5/ITC42TURmtl/HzhssMNlK/Jf+S3DinSrFg==
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(123027)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:DM2PR0501MB1167; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB1167; 
X-Forefront-PRVS: 08296C9B35
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(377454003)(24454002)(199003)(189002)(479174004)(64126003)(230783001)(5001770100001)(40100003)(59896002)(92566002)(65816999)(87976001)(33656002)(54356999)(87266999)(83506001)(101416001)(122386002)(66066001)(47776003)(65956001)(23746002)(50986999)(65806001)(2906002)(5004730100002)(189998001)(81156007)(97736004)(50466002)(77096005)(76176999)(5001960100002)(3846002)(2950100001)(4001350100001)(36756003)(107886002)(586003)(230700001)(105586002)(1096002)(80316001)(106356001)(86362001)(5008740100001)(42186005)(6116002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1167; H:[172.29.100.39]; 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)
X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; DM2PR0501MB1167; 23:CI/Wre2Pfj04FkuS3vDwX7k8X3mItqWVqb5?= =?Windows-1252?Q?YNMtQhCLC2BDps/9IzRBHFqpeT5+9reoLXN4UdL+QoyDzXg3YpaVtymU?= =?Windows-1252?Q?XvfSqsf2cA2RoMN+8E97mASaGvNdRHsND1lUguNOUxwfTvzIY/9sF2aY?= =?Windows-1252?Q?fFLsszTRQ2ojw37i0c9sfNpOc5PLgncMGZYAKgNKoTFWE8R+vgSFOPF7?= =?Windows-1252?Q?pZe1BpgrGB8if67kNwXlTPWfD0NTDiMuH+mWTFppg1lRp0Igo15rhbxQ?= =?Windows-1252?Q?o2S9eiw4gmLO4fs196OUL7lqOpM6K+xhcnqizgxdUAl3MWMI8w9kguR9?= =?Windows-1252?Q?zIrc8MWTD7/vsyzJpbb9oNBcCDWyqtlOgl9Q9qeTYI4txB6pWt4nvt7h?= =?Windows-1252?Q?tsS3zH4NPNtnTXvWNW3wDChVPaHQmXJ/XD7ivn8dSDPZ5kYqomrPbkj8?= =?Windows-1252?Q?moIpCvFM4lxdJ6lwyTF/CbZnx3sB4BHGrkF7ungixxbKHTJZ5l9Kkqcc?= =?Windows-1252?Q?Vmi84I3P/dDCKx/f/Xk+3wbR1AGuS+WSccbztj+4cKMJfgekNN4oo6JQ?= =?Windows-1252?Q?qv0YwCMX59m9HhKjwol3c6757HI0PEBuv+rjxcijGYGQp3x0VRMFtwv5?= =?Windows-1252?Q?qy1tqJ8ufyEeAcDdb9XoNm3N1rBnuO6IA+tuO44l8RwKHAXfDxP52QPY?= =?Windows-1252?Q?OpzaEigxnvvl87UXGS3r0e+z/2V1J2AG53aLurNn1Wotk0EMfQ2tBe1I?= =?Windows-1252?Q?X8cPtUBwY2A/aodYtGwZn5QBMbldi6WC+cNy0Xz8QigsVmrQsvnv9jf9?= =?Windows-1252?Q?sF+u2pqviEJDpLFMSC9rkhTJ+JqaCgk8PN8Q9XVrXMycE1IvL0MruuCL?= =?Windows-1252?Q?+xjxKtEj1GhztD4/XimInLPyF0Hccy1fNIiWzC50Ub9AAC1s9xlKll9C?= =?Windows-1252?Q?irDWImF79mXrW24Og9RH/RkpJFU6AXaUUFkjv3WbxjyoME8cVoqgquDD?= =?Windows-1252?Q?OAzWqqLt4DlhjqEZuzeEjMEuQNM9ZfvMnz8vZPsOwvqFPeTAYAH7CxGS?= =?Windows-1252?Q?ZAl0K1uecujUq1xPmKd02T/dcu0EuRB8unIEL06pW6dpG2Nagwkq3f9p?= =?Windows-1252?Q?MSYjnq2fqJyT2zNnNbG6sQOqGNim44n6zHNQ+V8NZCLf0GYbx/Nbnxt8?= =?Windows-1252?Q?zDBhdEQzzkI+OKcC5ycI8aDHNPVZahrIPofp4mKTRwEFQNGki18PuWbA?= =?Windows-1252?Q?X/lnZBj368n936u51tvxqNGYzGJGrOV2qxHauLuj9mG1IBLM9OCV38Ny?= =?Windows-1252?Q?xJFr+d/mBxMkSSfewcF+/8M4XHbrDl8RUWOcl6i3//cssDAUINIAP981?= =?Windows-1252?Q?kbsyqvdgxWigVS7bfJCYAO6jXNXRUIBeNchdIO7CZVK25OOjYuqo8VGD?= =?Windows-1252?Q?RgqULyyxG7pQji48OTzdG?=
X-Microsoft-Exchange-Diagnostics: 1; DM2PR0501MB1167; 5:hLDKjgroHttE5p7GDB/y55XRPgAQLxnVGGSxKdtwEQnbYoIW9UopKDEJ00YF82V3k8HffVLEpoTyGp0fmho8+s7nxG5uHRH4WAbOlP69k6/knbLR97skIy/XMCg4tsic8iBODgh7U3h65M6MmBUWxA==; 24:37Vr7q3fqZ1N9eBANUGsQ6Z/UkmGmqcLzVtFcG+n9Kw1pCmtxb80dMu5s9+vXSoGPYc81LYzwk0pITzmUcihPNWvJHyZ8KDyrn5bz/da1Fo=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2016 05:56:23.6655 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1167
Archived-At: 
Subject: Re: [netmod] Working group Last Call: draft-ietf-netmod-acl-model-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 05:56:43 -0000

On 01/21/2016 12:45 AM, Qin Wu wrote:
> 1. This draft defines two module, one is IETF-PACKET-FIELDS, the other is ietf-access-control-list module,
> I am wondering whether ietf-packet-fields module can be defined in more generic way that can be applied to other modules defined somewhere else?
> e.g., in ietf-packet-fields module, acl-ip-header-fields grouping is defined, I am wondering whether prefix "acl-" can be removed to make it more generic?

What you'll likely run into here is that the header fields defined in
acl-*-header-fields are more or less the lowest common denominators for
the application of "acl" - Not all header fields are defined here.

I suppose an approach could be to define generic groupings of all header
fields and create per application groupings, referencing what is
supported with appropriate constraints, etc...  Not sure what that buys
here since you're likely to have overlap but not complete parity between
the different consumers of these packet fields.

/ebben


From nobody Thu Jan 21 22:15:34 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2D2A1A037C; Thu, 21 Jan 2016 22:15:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fjwJawb2IYj; Thu, 21 Jan 2016 22:15:16 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0723.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::723]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27D071A036D; Thu, 21 Jan 2016 22:15:15 -0800 (PST)
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=exa@juniper.net; 
Received: from [172.29.100.39] (66.129.239.14) by BY1PR0501MB1160.namprd05.prod.outlook.com (10.160.104.12) with Microsoft SMTP Server (TLS) id 15.1.365.19; Fri, 22 Jan 2016 06:14:56 +0000
To: Dean Bogdanovic , Nadeau Thomas , Benoit Claise , RTG YANG Design Team , netmod WG 
References:  <20151211113156.GA43862@elstar.local> <2059AD77-5375-4DB0-A1BF-432835F11A9F@gmail.com> <20151221153312.GA43316@elstar.local> <2BAA2B26-EE40-4707-BBDB-C84E5653CF23@gmail.com> <20160111183053.GA565@elstar.local>
From: Ebben Aries 
X-Enigmail-Draft-Status: N1110
Message-ID: <56A1C8DA.4030709@juniper.net>
Date: Thu, 21 Jan 2016 23:14:50 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <20160111183053.GA565@elstar.local>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [66.129.239.14]
X-ClientProxiedBy: CO2PR20CA0034.namprd20.prod.outlook.com (25.163.96.44) To BY1PR0501MB1160.namprd05.prod.outlook.com (25.160.104.12)
X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1160; 2:vu3tHdDMtCQ3qHj5FRvg3o4fDLp0XuwM59g52Ybr4nKGBlm/OWNThHlKNDw3b9vF6+TP7vyYIktsBKMwvgSOLqRhkvtLdXmPZUQ5mkrIt20GNBtVoAMBDLJJztbJhPAsREopCt+7Pec7K871IXrI0Q==; 3:oBOq8lkY75ZTVApaDGUrrh/ROLKqirCxPsRaTNEchSiWekGA1tMv+wmkdpiu06eobIUeetDPbVx1PfVaq7WDA6lpjXF9RfOUZSZmclm6WH4IvKHo+1oU2bRbuvwktpne; 25:Yf9sz9ambrEHeebQxqJsylrcU8vyggAdChhIVuWPwRNaXZmzV0SuLdDY/89h7aEOTC6AyxZGP3f4rZAgQxAb/s3+QJWm2q5zNZkpLnjyo1B84545NaN98IFKWrQzN9wBol6MimuEe/b2YiDKd9cmwGWajvjnk1Pa2Bo93XwMujbOk0X1SD2TYEozNwIzGB/UWwe965Qhrt2I4ooSfpqkuMJj/+9v5L/BQDqqnFAynAbXGTqM96jx3rna0gHa2Bv5
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1160;
X-MS-Office365-Filtering-Correlation-Id: 128a68e9-9f91-4db9-bc59-08d322f359dc
X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1160; 20:kkcXZGO223fnM0k1lrBh5gPx65MXqj/x2dSD+TpJxdmT0cQ3RBXNUReP8EygjL+y/O5rvH92lRjaQvF/O/4O44nykFDN2V6o/8nLHKGOzDDvr2ntCt+jqm05mmaEIIkmRsoRZyee+UvpUrofHEtZ6gzvQ3QqxU8Yb65qcX+XbGUjy2kWcUq2ISUKpMErQ5RlzCU2FIxZHxNnJOERfHsVJ0fx58c0JJjc11eNPgAloJ9YxfWlpCXTlhO/fXvyPrbBPUvq1ET40UCA76OtRZCthENyAIVQJF50pKbGye2RRd68CX6/fPFcIwfb6NI2iHv3CuvJNx0A/OvTt9u6RMJGy+SMo1F647XvjKH6t95YmYt4pWR9BCovdV6HpC4VjzMyhSvtBfv/VVayMmAvhi3dgGwiELSgyivLBCnCeUCitF7FbKHgMwGHgOTwKZ+G4qQ5DnWOBmm4vz97mXNIzkg1eS6VoGY1+THLLgeCbhBhbFnzTAETMGNxdb6BmeXwIyMw; 4:YkZYAK/9N6XccuLwXS0dyJElRMT23XLu3hyZQWOm5Zq9hNvl8ZTEWnCluzfoPfpvcD4ylkhQJW8nUNvFqRJEE6tobUsWPQQuk3+oEuUhebkwFBIPNaIAjNwupD2Pj4tNkfpz6BLJjXPIpKdElx8eAqMy7Y2fWmfNU91fZszQDXDdTvmDM/Daw1kWJ8RuYzfJ9jOfIAGd0WYlVVKRc0z2Z85YenlxTc8zg6ew0jmPXVN5ldIYSGg4Y/VBcyssacxYxJPnNuzmlSIB+t/yXCX1w9YP6UIjcMP7UFOW8bCeRonjeZgYBUcxUgxsxgFZ2DDNc+xshBclbElTAx7JxPIWH5B8+ir8kRkwP2hwJXIcrccqiVTY04OnWu4D36SSIBQa
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001)(10201501046); SRVR:BY1PR0501MB1160; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1160; 
X-Forefront-PRVS: 08296C9B35
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(479174004)(377454003)(199003)(24454002)(189002)(50466002)(33656002)(97736004)(5004730100002)(3846002)(40100003)(87266999)(81156007)(50986999)(77096005)(4001350100001)(76176999)(122386002)(59896002)(54356999)(7520500002)(5001770100001)(101416001)(42186005)(64126003)(80316001)(230783001)(93886004)(230700001)(36756003)(6116002)(189998001)(86362001)(586003)(83506001)(5001960100002)(87976001)(65956001)(105586002)(65806001)(47776003)(2950100001)(92566002)(65816999)(23676002)(1096002)(107886002)(2906002)(5008740100001)(106356001)(66066001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1160; H:[172.29.100.39]; 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)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWTFQUjA1MDFNQjExNjA7MjM6T05OalJvTWZEQ0pEMWNIUjU4VjlnK1hD?= =?utf-8?B?eWxvTFBvT1JVMjZZWmIwa2EyMEdyL0FwenZZczRLalpLOFBSNEF1eXQxRFRM?= =?utf-8?B?bGtyR3RmaUtRZVkySjdqb2pBN3QxUCtuU2tla2N2dnYwQjFWSWpaY0J3SERD?= =?utf-8?B?dTBGY25pSXBMNG4rSW1YcGtodHN6RUJaVGR6Qkw0TGZONEIyTkd3V0tIMXl1?= =?utf-8?B?VWJPU3pIVFpDWEFIWUhkcnMreUR4cHBJem82enk0QVVkR3Z2c0NQaW1HMDVC?= =?utf-8?B?VStacHpnMmY0TXVvY3FCYXBPMnIra1k2MTJNcnRRZXpadkZNeGtPSlk0RlpM?= =?utf-8?B?ZERwdTR4a3pyRG04MFpRVm9LV3V1UjZzMWZyTGNFZFpPWUdWbk1uMUxmTnlJ?= =?utf-8?B?R2tBdG9RclNBK1l6T21uWGdEcWoyTlErekFFaGJzY3ZFUTNldzJuSVBNbFAx?= =?utf-8?B?Nm96NU52eXo5eitGNmxnYWs2K3ZOdzdJSlEyVVIyRG9WVGdySkdHVWN1QTlB?= =?utf-8?B?MmhJcG1IT1NIejdERUFuRmpiWnUwUFk5NVJFVzcyb2IvSys1MlZhSDdldkFs?= =?utf-8?B?YlRORW9qUVVHSFhaczZWN3BqMHUwVm4vU1d6VDJKUFhmUkVKZS9iNHF3OU5z?= =?utf-8?B?SW56Vit5aDczUGJzK2Q3YTQ0TWl5SlBXYmV2ZHVmcmFielFMZEdRaC9ka2hk?= =?utf-8?B?Ty80My9WL0E5TE9MZ0orWE4vSUVIS3NRNHBhNU1BZmtDbnJ5c29zZGlPV2xS?= =?utf-8?B?TVJ6b0hiTWdRNTJ0akhuRkpnRTJROWh3c1RkYmdUcDVEdnpaTEpCckh1amJT?= =?utf-8?B?VEw2Uk54WEpIdzRSWENmYmc1bWd1NDJXQ1JVQ0paYlo5Z08wWFlMUG9uVU54?= =?utf-8?B?MGs3Z0tGaWhaSkM2YUd1RWd0QlQ0N3FoY0RiR2tMSndoazFLS0t4RlFJQ2xK?= =?utf-8?B?UjhJZjNoT2NFN3dUWWlmY3R4WWVSTTBtUFM3SmxuVS9hUEMxVk93R2VrSG1K?= =?utf-8?B?U3B4RG5qNVJiZ2U0YmtCbk1mTHR1UHdHbHZjYjYrc3NZRkZXVVBRbXNmcmtL?= =?utf-8?B?UUxkM043em9zUHZzV3V5OUVOMTg0bXFKR1g2SU5BSVVEWjlzeWJHTWFUS21j?= =?utf-8?B?alAzaG9wMU9Ic014RDJQYUZJR040SjhsVFhrWHJYTHlGMmtoY0lJaEh0RmJt?= =?utf-8?B?SWlDVmZ5b2FMN2I3dEFZZE1OSkV2cTZSOU9hS29WVFh4U1VqUWN5L0IyZ255?= =?utf-8?B?WnpaTktoazBXVkorUENsMmtkejFucVJLbWxEZElaR0dKNHpCL0Y1VGhBRFpI?= =?utf-8?B?dHJ5ZkhJOGsreXlsMFlaSkNUZnJ6THBlT2VCaDViQTNSdXU1dzRkWG40ZkpH?= =?utf-8?B?TU5uRVRNMCtYb3ErTHNySm9Oa0JvdTRvTVZDdWZ1MXhiYTZHd2FYaTJ1T1l4?= =?utf-8?B?cWVJejhWbW1mNDNoZ2tuclN5S0tVVlFTRnQ3MGdaeXJldlIrQkVYQVp0L2k4?= =?utf-8?B?QUJDdFI5MHhZZlh0bFpoTnRGOWU1UVJtdE9ha0hyTGNNempQMlJiYWpHYTdw?= =?utf-8?B?eEcwRkM4VVF1c0V3eWlVeGIzSDdBaDFhMkRTdllLN2s3Zjk0V1B0bmdUWkxI?= =?utf-8?B?NWg0YlZvRktRM1lFbG1sYUpMWGw1NVp6YUFhM2pScjRwUkU1Y0Uxb2VNY0k4?= =?utf-8?B?MDZMcHFTRzdvbnFmLzNNN2dNYkhQS0t1MWg2UXZWalArbTlxU3lqVDFGR3c4?= =?utf-8?B?ZDBMUVo5WVhZZzI3c3hGOGVQVG44dEdZVkdGMThyYzkweGVMSnhDUnVaa21l?= =?utf-8?B?SWt0djczS09sMlNhWnVneFNPTDgwUUxGbzFmek5iOTc3dnkxQTN3a2RWaXc5?= =?utf-8?Q?Yff3xbINMT0Ms=3D?=
X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1160; 5:EpmpIPzc+IadsCYi/S3eIEJsz2eYAu+uYlDw9EE/iCx3S8/zV1397xMB5cGSzbu4wUwRIRGGTOnquePcnpsAAE4WyHTQkG/8aB8g8HOO2UTbM8xbjr6GvzHKx2ii8QsF7NKbRCD3qZ/+mFNRgHw7HA==; 24:sZUkEWBylQ85C7go6oJorUoHK4kaVl2qyajUvX+x6iXTlDEMHps4K83Wk6NjmOjX4x6cMRqkj270zM2EiJsY1ftFqJ1zfjjXORPwFcNP5uk=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jan 2016 06:14:56.2219 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1160
Archived-At: 
Subject: Re: [netmod] [Rtg-dt-yang-arch] [yang-doctors] Working group Last Call: draft-ietf-netmod-acl-model-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 06:15:20 -0000

On 01/11/2016 11:30 AM, Juergen Schoenwaelder wrote:
>>>>> In the XML shown, can you not
>>>>> > >>> leave out all the fields that are not set? This would remove a lot
>>>>> > >>> of noise. I do not understand what having both actions deny and
>>>>> > >>> permit at the same time means. Did you validate the example against
>>>>> > >>> the data model? (I also find the keys at the end somewhat strange
>>>>> > >>> and not that NETCONF XML serialization actually requires the keys to
>>>>> > >>> be sent first.)
>>> > > 
>>>> > >> We used pyang sample xml skeleton to create the xml example.
>>> > > 
>>> > > Whatever, the noise does not really help and the example might even
>>> > > mislead people to believe they have to write down all unused leafs.
>> > 
>> > We could edit the empty fields out, but from personal experience working with customers, I was getting questions that the compiler output and the examples are not matching (it was vendor data modeling language).
> Which compiler's output? I find it very distracting to list unused
> leafs. I assume most NETCONF implementations suppress unused leafs as
> well. (I might be proven wrong but I would have a preference to not
> use one that sends me tons of useless empty leafs.)
> 

I agree, the goal of this XML example is to match an RPC with the CLI
example above it.  No reason to include all possible leafs.

Another state of confusion is an acl-type of 'ipv4-acl' with references
to both ace-ipv6 and ace-ipv6 leafs


From nobody Thu Jan 21 22:16:12 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375191A038A for ; Thu, 21 Jan 2016 22:16:11 -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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTh5VDoC0bR4 for ; Thu, 21 Jan 2016 22:16:09 -0800 (PST)
Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::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 714AE1A037F for ; Thu, 21 Jan 2016 22:16:09 -0800 (PST)
Received: by mail-qg0-x22d.google.com with SMTP id 6so50430314qgy.1 for ; Thu, 21 Jan 2016 22:16:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QNfkAZRyIYYWZE3R4wu9jh7dGeM4xkw+PMa20M5Dat8=; b=cH2mCzJrLQSCqmMdPD15gdcVi5SGNrGFRUWYHWXxxXZgenrum7/8sCv6dSbNe3/AKF vEhDle8rIHRJoPmN9hwaPaTHO5qIpX01DVa1X3S+nGscxqseN/eEU8v+CwhuaY13eZUG QFNJeditZvUiuVvCQMhSU4Nz9jGyB1Dc0g7cU0RcfQg1Zoh971buC26yO7rvWtNP5UBf znJ+fAW1l4j/SaHC6DxBtWaw8446zMq7aZBY2vllce2bnEhWYHygjo+vynneV/rZz7pv eVbbdOc1IjN9VgSZZrG3o3Fqqvn8YK1A7YNShSH9XyOQSNXSTbSEz77CnBli4Upi1W45 6yEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=QNfkAZRyIYYWZE3R4wu9jh7dGeM4xkw+PMa20M5Dat8=; b=V5FVcGj8fcJBLEvclf7STFsCL+/ipdm/SFQ3cw1wuif/ZNk1U/gdF+DDrsiTZaxwuJ LkzUnYM6xOvdbU/Iuh8vjlwaNkvq1LiDPXs5MW4F0qd3PCrsC+W/eXbjrb1Exc+Eh7Ke ftOAZkrjvhsj+A+YcROsn0v8I0ju1QpsVaZa400UrEztvYz4qSFEGmhjq7jZE59c5McI RHtOwz1CzkBXtYSGtdW7NpFvWifjDHXjOsHTamL7SriO7k0iVCj5eiaTKu5/wR6/zeln FLkzGRNzNdTvDH7Ckb3lPxtkrX00ecpN8W1+DKwNXxy1+uS937+fLX8fwYlTQenY1PNa Rm6g==
X-Gm-Message-State: AG10YOSppOXm54BnczSyRarN2DCnckEk6WdksuGGpCSxbslAhAQPD/NfIR/xtLWBf0INgg==
X-Received: by 10.140.104.100 with SMTP id z91mr1538766qge.26.1453443368496; Thu, 21 Jan 2016 22:16:08 -0800 (PST)
Received: from [10.0.70.127] ([209.92.66.180]) by smtp.gmail.com with ESMTPSA id l77sm2185169qkh.11.2016.01.21.22.16.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Jan 2016 22:16:07 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Dean Bogdanovic 
In-Reply-To: <56A1C480.7000509@juniper.net>
Date: Thu, 21 Jan 2016 22:16:00 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <97FE6046-9B68-4586-A950-0981B2B7F3CB@gmail.com>
References:  <56A1C480.7000509@juniper.net>
To: Ebben Aries 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] Working group Last Call: draft-ietf-netmod-acl-model-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 06:16:11 -0000

> On Jan 21, 2016, at 9:56 PM, Ebben Aries  wrote:
>=20
>=20
> On 01/21/2016 12:45 AM, Qin Wu wrote:
>> 1. This draft defines two module, one is IETF-PACKET-FIELDS, the =
other is ietf-access-control-list module,
>> I am wondering whether ietf-packet-fields module can be defined in =
more generic way that can be applied to other modules defined somewhere =
else?
>> e.g., in ietf-packet-fields module, acl-ip-header-fields grouping is =
defined, I am wondering whether prefix "acl-" can be removed to make it =
more generic?
>=20
> What you'll likely run into here is that the header fields defined in
> acl-*-header-fields are more or less the lowest common denominators =
for
> the application of "acl" - Not all header fields are defined here.

Correct, it was lowest common denominator.
>=20
> I suppose an approach could be to define generic groupings of all =
header
> fields and create per application groupings, referencing what is
> supported with appropriate constraints, etc=E2=80=A6
>  Not sure what that buys
> here since you're likely to have overlap but not complete parity =
between
> the different consumers of these packet fields.

The ietf-packet-fields could be reused in QoS for matching and in some =
vendors case, they are using access list for matching. So it is =
consistent naming for match conditions. The QoS design team mapped out =
there own match conditions.=20
>=20
> /ebben
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Thu Jan 21 23:07:14 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D45C1A90EB; Thu, 21 Jan 2016 23:07:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvz1DJx2CY3u; Thu, 21 Jan 2016 23:07:12 -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 418D71A90B6; Thu, 21 Jan 2016 23:07:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2587; q=dns/txt; s=iport; t=1453446431; x=1454656031; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=sbNgTvgMwoFhQd/hitRlNvNI8T3S+fxyflf3sLci5Eo=; b=DNTpuJvzABxsCdgtWlIunf8mY6k21kYbzglMTfhbHCzvogFgp2oky+xg /HeBcKtY4KmcHd5jApvNqt0cn1ZdVp/ENR8R83m22Oq9sPOsD0W8N+SLh 3cmLbYlcE0lx3aMLDvuhckv36nLQ1Lr2BiJr/GdIiZa2FKi/RyEQQerrc E=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoBAD106FW/xbLJq1ejVCzb4YPAoF6E?= =?us-ascii?q?QEBAQEBAQGBCoRBAQEBAwEjVRELDgoJFgQHAgIJAwIBAgFFBgEMCAEBiA8Irl2?= =?us-ascii?q?PPAEBAQEBAQEDAQEBAQEBAREIiyeHTIE6AQSWd4J5gWOIeokmhVOOPjYsgX4YG?= =?us-ascii?q?4E2O4YaJYESAQEB?=
X-IronPort-AV: E=Sophos;i="5.22,329,1449532800";  d="asc'?scan'208";a="648703839"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jan 2016 07:07:08 +0000
Received: from [10.61.200.145] ([10.61.200.145]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u0M778fg022486; Fri, 22 Jan 2016 07:07:08 GMT
To: Ebben Aries , Dean Bogdanovic , Nadeau Thomas , Benoit Claise , RTG YANG Design Team , netmod WG 
References:  <20151211113156.GA43862@elstar.local> <2059AD77-5375-4DB0-A1BF-432835F11A9F@gmail.com> <20151221153312.GA43316@elstar.local> <2BAA2B26-EE40-4707-BBDB-C84E5653CF23@gmail.com> <20160111183053.GA565@elstar.local> <56A1C8DA.4030709@juniper.net>
From: Eliot Lear 
Message-ID: <56A1D51B.4060801@cisco.com>
Date: Fri, 22 Jan 2016 08:07:07 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56A1C8DA.4030709@juniper.net>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ENC24OWWgiEaJSw6OBXbOapMJnOCTOCaM"
Archived-At: 
Subject: Re: [netmod] [Rtg-dt-yang-arch] [yang-doctors] Working group Last Call: draft-ietf-netmod-acl-model-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 07:07:13 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--ENC24OWWgiEaJSw6OBXbOapMJnOCTOCaM
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 1/22/16 7:14 AM, Ebben Aries wrote:
> On 01/11/2016 11:30 AM, Juergen Schoenwaelder wrote:
>>>>>> In the XML shown, can you not
>>>>>>>>>> leave out all the fields that are not set? This would remove a=
 lot
>>>>>>>>>> of noise. I do not understand what having both actions deny an=
d
>>>>>>>>>> permit at the same time means. Did you validate the example ag=
ainst
>>>>>>>>>> the data model? (I also find the keys at the end somewhat stra=
nge
>>>>>>>>>> and not that NETCONF XML serialization actually requires the k=
eys to
>>>>>>>>>> be sent first.)
>>>>>>>> We used pyang sample xml skeleton to create the xml example.
>>>>>> Whatever, the noise does not really help and the example might eve=
n
>>>>>> mislead people to believe they have to write down all unused leafs=
=2E
>>>> We could edit the empty fields out, but from personal experience wor=
king with customers, I was getting questions that the compiler output and=
 the examples are not matching (it was vendor data modeling language).
>> Which compiler's output? I find it very distracting to list unused
>> leafs. I assume most NETCONF implementations suppress unused leafs as
>> well. (I might be proven wrong but I would have a preference to not
>> use one that sends me tons of useless empty leafs.)
>>
> I agree, the goal of this XML example is to match an RPC with the CLI
> example above it.  No reason to include all possible leafs.

+1.

>
> Another state of confusion is an acl-type of 'ipv4-acl' with references=

> to both ace-ipv6 and ace-ipv6 leafs
>
>

Yes, not to mention both  and  in the same ACE.

Eliot


--ENC24OWWgiEaJSw6OBXbOapMJnOCTOCaM
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2

iQEcBAEBCAAGBQJWodUcAAoJEIe2a0bZ0noz2QgH/iY+BeeDRB83KP8oANK7C3Td
/Dp147bu5tW2on2WaGUnL4tbzbg3JsoEgh0agMIJBxBJ8IF60IsJD3ahvIvVgv30
pYiT5KQNDKw9O6o/S7bMdXDVS/ceOcJOC0rhIqgKtkKZIL/092C/F7ut+XBXj8l1
rWj/3fUT8L/hJ2bHq0Mi2J15HwH1fcNI81RwwwH83YYOAwn2DGE9z9lX18WFPtgs
yWLKqdwADc6OkXcVO3cjqdS4VRrvrnhVvd9gJGWsVm89iVGxu673TnGzQGjdvrow
x+uXs8FDES2cJ27r87bPBidXU79oXDU+d9MzHeUrkgKgLmHH3WpWseu6R4HJ/pQ=
=jIvn
-----END PGP SIGNATURE-----

--ENC24OWWgiEaJSw6OBXbOapMJnOCTOCaM--


From nobody Fri Jan 22 00:23:59 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB93A1ACD53 for ; Fri, 22 Jan 2016 00:23:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxhmvzScMko7 for ; Fri, 22 Jan 2016 00:23:56 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2491ACD52 for ; Fri, 22 Jan 2016 00:23:56 -0800 (PST)
Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id 868451AE035C; Fri, 22 Jan 2016 09:23:54 +0100 (CET)
Date: Fri, 22 Jan 2016 09:23:57 +0100 (CET)
Message-Id: <20160122.092357.337480878995362688.mbj@tail-f.com>
To: nite@hq.sk
From: Martin Bjorklund 
In-Reply-To: <56A155B3.2090506@hq.sk>
References: <20151218.092341.1370454568296215965.mbj@tail-f.com> <56A155B3.2090506@hq.sk>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-structural-mount-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 08:23:58 -0000

Hi,

Robert Varga  wrote:
> On 2015-12-18 09:23, Martin Bjorklund wrote:
> > Hi,
> >
> > This draft proposes a mechanism for mounting YANG models in other
> > models.  It focuses on the *schema* only, not on the underlying
> > mechanism to implement the data (like "peer mount").
> 
> Hello Martin,
> 
> one question on containment: is if fair to assume the mechanism can be
> implemented in a recursive way, e.g. nested mount points would be
> exposed in /mount-points within the mountpoint itself, not in the
> global one?

I think this should work.  In such a case, the server must mount
ietf-yang-structural-mount, which will contain info about the
recursive mounts, and so on.


/martin


From nobody Fri Jan 22 00:27:11 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F14A1ACD6B for ; Fri, 22 Jan 2016 00:27:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.477
X-Spam-Level: 
X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaaxGwSjb7GA for ; Fri, 22 Jan 2016 00:27:07 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BC901ACD6A for ; Fri, 22 Jan 2016 00:27:06 -0800 (PST)
X-AuditID: c1b4fb30-f79a76d000000a93-c2-56a1e7d85213
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 07.92.02707.8D7E1A65; Fri, 22 Jan 2016 09:27:05 +0100 (CET)
Received: from [159.107.197.143] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.3.248.2; Fri, 22 Jan 2016 09:27:04 +0100
To: Andy Bierman 
References: <56A0F18D.4030505@ericsson.com> <20160121.161733.727143885958810312.mbj@tail-f.com> <56A10C79.1010601@ericsson.com> 
From: Balazs Lengyel 
Message-ID: <56A1E7D8.8030902@ericsson.com>
Date: Fri, 22 Jan 2016 09:27:04 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM2K7k+7N5wvDDKZ1c1o8ODKL3aK7+xm7 xfyLjawOzB5Llvxk8tj4azGLR0v/RZYA5igum5TUnMyy1CJ9uwSujPOz5Ap22FU8PPCWpYHx tVoXIyeHhICJxJULK9khbDGJC/fWs3UxcnEICRxmlNj/7TMThLOWUWL6wV5mkCphAXOJb3+2 gHWICKhKXJg7kRmi6BSjxJvNp8CKmAW8JE5M28EKYrMJGElM7T/PAmLzCmhLPNrXBtbMAtTc 8/s1WL2oQIzExc4jTBA1ghInZz4Bq+cUCJRYNnU2O8RMDYnWOXOhbHmJ5q2zwXqFgOIPL/xl ncAoOAtJ+ywkLbOQtCxgZF7FKFqcWpyUm25kpJdalJlcXJyfp5eXWrKJERjEB7f8NtjB+PK5 4yFGAQ5GJR7eD0kLw4RYE8uKK3MPMUpwMCuJ8DJcBQrxpiRWVqUW5ccXleakFh9ilOZgURLn TZJpDBMSSE8sSc1OTS1ILYLJMnFwSjUwapV6GstZdn+s5vcpuPT7RG3U8XLfRfxlKzJY3vOH 6vybwxW3QG3NF6O3zTLaVouy7JRePppra9L4dI0dd2MPb/+b200fH8wTqepOj5pVu45RTi5R Pextov/F4y+O6RQeWcvNvYj/kP/LsJ9G/MfyX9hMKT3w5NvJqRdClXouTj+bYuh3nMddiaU4 I9FQi7moOBEAAUX5sF4CAAA=
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Constraining instance-identifiers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 08:27:09 -0000


  
    
  
  
    Hello,

    I agree we don't need to change the encoding, but we need to define
    how that encoding is visible/available when evaluating Xpath
    expressions. Today the draft says:

    - instance-identifier does not have a canonical format

    - XPath uses the canonical format

    The two together make it impossible to use it in Xpath, even though
    there are people that would like to do that.

    - Martin mentioned a proprietary extension

    - we would like it.

    

    So I would propose to 

    ---- change to 9.1

    
Old: In particular, any XPath expression evaluations are done using the canonical form.

    New:  In particular, whenever a canonical form exists, any XPath
    expression evaluations are done using the canonical form.
    

    

    --- add to 9.13.2

    
For instance-identifiers XPath expression evaluations are done using the lexical form.

    

    regards Balazs

    

    

    
On 2016-01-21 18:53, Andy Bierman
      wrote:

    

    

      
      
Hi,
        


        

        
There is no need to change the XML encoding or YANG
          encoding

        
of an instance-identifier.  The prefixes are completely
          different

        
in each.  Prefixes clashes do happen, especially since

        
there is no expectation that they are unique.  They are
          short strings

        
with no naming conventions at all.  E.g., I have seen "if"
          for

        
interfaces in multiple modules.

        


        

        
Andy

        


        

        

          


            
On Thu, Jan 21, 2016 at 8:51 AM,
              Balazs Lengyel <balazs.lengyel@ericsson.com>
              wrote:

              
Hello
                Martin,

                If the RFC would define that in XPath expressions an
                instance identifier MUST be evaluated to a string that
                complies to the lexical format, using the rematch
                function, we could do everything we need. In real life
                prefix clashes are a rare problem.

                regards Balazs

                

                On 2016-01-21 16:17, Martin Bjorklund wrote:

                

                  Balazs Lengyel <balazs.lengyel@ericsson.com>
                  wrote:

                  

                    Hello,

                    We have some instance identifiers in our model but
                    we want to

                    contrain what they can point at. What is the best
                    method for that?

                  

                  Unfortunately, there is no standard way of doing
                  this.  (There are

                  vendor extensions available...)

                  

                  [...]

                  

                  

                    Some issues:

                    - instance-identifiers don't have a canonical
                    format, so what is

                    their value in an XPath expression?

                  

                  This is not defined.

                  

                  

                    - I didn't find a way to evaluate a regexp in XPath
                    1.0. Is there a way?

                  

                  In YANG 1.1, there is a function re-match() for this
                  purpose.  For

                  your use case, it *may* work to match just the local
                  names of all

                  nodes, i.e., using wildcards for the prefixes.  It is
                  not a generic

                  solution though.

                  

                  

                    - if I have all the needed namespace prefixes in
                    imports, can I just

                       use them?

                  

                  No, these prefixes are local to the module that is
                  doing the import,

                  and they may or may not match the prefixes used by the
                  implementation

                  when it construct the instance-identifier value.

                  

                  

                  

                  /martin

                  

                  
                    

                
                    

                    -- 

                    Balazs Lengyel                       Ericsson
                    Hungary Ltd.

                    Senior Specialist

                    ECN: 831 7320

                    Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com

                    

                    _______________________________________________

                    netmod mailing list

                    netmod@ietf.org

                    https://www.ietf.org/mailman/listinfo/netmod

                  

            

            

          

        

      

    

    

    
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com 


  



From nobody Fri Jan 22 00:56:48 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 109251ACDD9 for ; Fri, 22 Jan 2016 00:56:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ai9TXvzJa1r0 for ; Fri, 22 Jan 2016 00:56: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 397371ACDD7 for ; Fri, 22 Jan 2016 00:56:45 -0800 (PST)
Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id AF7271AE035C; Fri, 22 Jan 2016 09:56:43 +0100 (CET)
Date: Fri, 22 Jan 2016 09:56:46 +0100 (CET)
Message-Id: <20160122.095646.1511106812922905933.mbj@tail-f.com>
To: balazs.lengyel@ericsson.com
From: Martin Bjorklund 
In-Reply-To: <56A1E7D8.8030902@ericsson.com>
References: <56A10C79.1010601@ericsson.com>  <56A1E7D8.8030902@ericsson.com>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Constraining instance-identifiers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 08:56:47 -0000

Balazs Lengyel  wrote:
> Hello,
> I agree we don't need to change the encoding, but we need to define h=
ow that
> encoding is visible/available when evaluating Xpath expressions. Toda=
y the draft
> says:
> - instance-identifier does not have a canonical format
>   XPath uses the canonical format
> The two together make it impossible to use it in Xpath, even though t=
here are
> people that would like to do that.
> - Martin mentioned a proprietary extension
>   we would like it.
> =

> So I would propose to
> ---- change to 9.1
> =

> Old: In particular, any XPath expression evaluations are done using
> the canonical form. =

> =

> New:=A0 In particular, whenever a canonical form exists, any XPath ex=
pression
> evaluations are done using the canonical form.

How about:

NEW:

  In particular, any XPath expression evaluations are done using the
  canonical form, if the data type has a canonical form.  If the data
  type does not have a canonical form, the format of the value MUST
  match the data type's lexical representation, but the exact format
  is implementation dependent.


/martin

> =

> --- add to 9.13.2
> =

> For instance-identifiers XPath expression evaluations are done using =
the lexical form.
> =

> regards Balazs
> =

> On 2016-01-21 18:53, Andy Bierman wrote:
> =

> > =

> =

> > =

> Hi,
> > =

> =

> > =

> =

> > =

> There is no need to change the XML encoding or YANG
> > encoding
> =

> > =

> of an instance-identifier.=A0 The prefixes are completely
> > different
> =

> > =

> in each.=A0 Prefixes clashes do happen, especially since
> =

> > =

> there is no expectation that they are unique.=A0 They are
> > short strings
> =

> > =

> with no naming conventions at all.=A0 E.g., I have seen "if"
> > for
> =

> > =

> interfaces in multiple modules.
> =

> > =

> =

> > =

> =

> > =

> Andy
> =

> > =

> =

> > =

> =

> > =

> =

> > =

> =

> > =

> On Thu, Jan 21, 2016 at 8:51 AM,
> > Balazs Lengyel 
> > wrote:
> =

> >> Hello
> >> Martin,
> =

> >> If the RFC would define that in XPath expressions an
> >> instance identifier MUST be evaluated to a string that
> >> complies to the lexical format, using the rematch
> >> function, we could do everything we need. In real life
> >> prefix clashes are a rare problem.
> =

> >> regards Balazs
> =

> >> On 2016-01-21 16:17, Martin Bjorklund wrote:
> =

> >>> Balazs Lengyel 
> >>> wrote:
> =

> >>>> Hello,
> =

> >>>> We have some instance identifiers in our model but
> >>>> we want to
> =

> >>>> contrain what they can point at. What is the best
> >>>> method for that?
> =

> >>> Unfortunately, there is no standard way of doing
> >>> this.=A0 (There are
> =

> >>> vendor extensions available...)
> =

> >>> [...]
> =

> >>>> Some issues:
> =

> >>>> - instance-identifiers don't have a canonical
> >>>> format, so what is
> =

> >>>> their value in an XPath expression?
> =

> >>> This is not defined.
> =

> >>>> - I didn't find a way to evaluate a regexp in XPath
> >>>> 1.0. Is there a way?
> =

> >>> In YANG 1.1, there is a function re-match() for this
> >>> purpose.=A0 For
> =

> >>> your use case, it *may* work to match just the local
> >>> names of all
> =

> >>> nodes, i.e., using wildcards for the prefixes.=A0 It is
> >>> not a generic
> =

> >>> solution though.
> =

> >>>> - if I have all the needed namespace prefixes in
> >>>> imports, can I just
> =

> >>>> =A0 =A0use them?
> =

> >>> No, these prefixes are local to the module that is
> >>> doing the import,
> =

> >>> and they may or may not match the prefixes used by the
> >>> implementation
> =

> >>> when it construct the instance-identifier value.
> =

> >>> /martin
> =

> >>> =

> >>> =

> >> =

> =

> >> --
> =

> >> Balazs Lengyel=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Erics=
son
> >> Hungary Ltd.
> =

> >> Senior Specialist
> =

> >> ECN: 831 7320
> =

> >> Mobile: +36-70-330-7909=A0 =A0 =A0 =A0 =A0 =A0 =A0 email: Balazs.L=
engyel@ericsson.com
> =

> >> _______________________________________________
> =

> >> netmod mailing list
> =

> >> netmod@ietf.org
> =

> >> https://www.ietf.org/mailman/listinfo/netmod
> =

> >> =

> > =

> =

> > =

> =

> > =

> =

> > =

> =

> -- =

> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> ECN: 831 7320                        =

> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.c=
om =


From nobody Fri Jan 22 01:32:18 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD811ACE49 for ; Fri, 22 Jan 2016 01:32:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5S2ZWYt0i6z for ; Fri, 22 Jan 2016 01:32:14 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id E37DA1AC3E9 for ; Fri, 22 Jan 2016 01:32:13 -0800 (PST)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 8FB801CC01AB; Fri, 22 Jan 2016 10:32:22 +0100 (CET)
From: Ladislav Lhotka 
To: William Lupton , netmod@ietf.org
In-Reply-To: 
References: 
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Fri, 22 Jan 2016 10:32:09 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] Validation question
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 09:32:16 -0000

Hi William,

YANG uses XPath 1.0, and so the equality tests mean *string
equality*. That's why 6087bis recommends in sec. 5.6.4:

   XPath expressions that contain a literal value representing a YANG
   identity SHOULD always include the declared prefix of the module
   where the identity is defined.

In YANG 1.1, the new XPath functions derived-from() and
derived-from-or-self() will alleviate this problem.

Lada

William Lupton  writes:

> All,
>
> We have been experimenting with validating XML instances along the lines explained in the tutorials at http://www.yang-central.org/twiki/bin/view/Main/DSDLMappingTutorial  and https://github.com/mbj4668/pyang/wiki/InstanceValidation  and we have hit a problem with identities in XPath expressions.
>
> This is illustrated by the YANG module shown below, which is inspired by an example in RFC 6020bis, and the XML instance shown below the YANG. Note that:
> The second "when" statement doesn't use a prefix on the interface type.
> Shouldn't be a problem because the interface type is defined in the current module and so doesn't need a prefix?
> The XML uses a prefix name of "exaug" rather than "mymod" which is used in the YANG.
> Shouldn't be a problem because prefixes should be local?
>
> Validating this instance gives the following two errors (which go away if the prefix "mymod" is used in all "when" statements and in the XML).
>
> == Validating semantic constraints ...
> --- Validity error at "/nc:data/if:interfaces/if:interface":
>     Found nodes that are valid only when "if:type = 'mymod:some-new-iftype'"
> --- Validity error at "/nc:data/if:interfaces-state/if:interface":
>     Found nodes that are valid only when "if:type = 'some-new-iftype'"
>
> Are we doing something wrong here, or is there a problem with how identities in XPath expressions are translated (per RFC 6110)? On the face of it it seems that identities are being treated as literal strings (but we haven't investigated this assertion).
>
> Thanks,
> William Lupton
>
> --------
>
> YANG:
> module example-augment {
>   namespace "http://example.com/augment";
>   prefix mymod;
>   
>   import ietf-interfaces {
>     prefix if;
>   }
>   
>   identity some-new-iftype {
>     base if:interface-type;
>   }
>   
>   augment "/if:interfaces/if:interface" {
>     when "if:type = 'mymod:some-new-iftype'";
>
>     container some-new-container {
>     }
>   }
>
>   augment "/if:interfaces-state/if:interface" {
>     when "if:type = 'some-new-iftype'";
>
>     container some-new-container {
>     }
>   }
> }
>
> XML:
> 
>    xmlns:exaug="http://example.com/augment">
>   
>     
>       
>       
>       exaug:some-new-iftype
>       true
>       enabled
>       
>       
>     
>   
>   
>     
>       
>       exaug:some-new-iftype
>       up
>       up
>       1
>       
>         2016-01-15T12:55:00Z
>       
>       
>       
>     
>   
> 
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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


From nobody Fri Jan 22 02:29:56 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0681A0137 for ; Fri, 22 Jan 2016 02:29:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfchnU4AyBHp for ; Fri, 22 Jan 2016 02:29:55 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E50901A0130 for ; Fri, 22 Jan 2016 02:29:54 -0800 (PST)
X-AuditID: c1b4fb30-f79a76d000000a93-d6-56a204a059dd
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id E9.0C.02707.0A402A65; Fri, 22 Jan 2016 11:29:53 +0100 (CET)
Received: from [159.107.197.143] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.3.248.2; Fri, 22 Jan 2016 11:29:52 +0100
To: Martin Bjorklund 
References: <56A10C79.1010601@ericsson.com>  <56A1E7D8.8030902@ericsson.com> <20160122.095646.1511106812922905933.mbj@tail-f.com>
From: Balazs Lengyel 
Message-ID: <56A204A0.2070201@ericsson.com>
Date: Fri, 22 Jan 2016 11:29:52 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <20160122.095646.1511106812922905933.mbj@tail-f.com>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM2K7pe5ClkVhBu/uslo8ODKL3aK7+xm7 xfyLjawOzB5Llvxk8tj4azGLR0v/RZYA5igum5TUnMyy1CJ9uwSujM+PZjEW/Gat+L7yDFMD 43aWLkZODgkBE4m503+xQthiEhfurWfrYuTiEBI4zCgx//9fJpCEkMBaRomzVwRBbGEBc4lv f7awg9giAqoST3auZYFoOM0o0bZ7CViCWUBbYvmPE2BT2QSMJKb2nwfbxgsU3/FuAZjNAtS8 aPMfsAWiAjESFzuPMEHUCEqcnPkErIZTwFGi5/cSIJsDaKa9xIOtZRDj5SW2v53DDHGbhsTD C39ZJzAKzkLSPQuhYxaSjgWMzKsYRYtTi5Ny042M9FKLMpOLi/Pz9PJSSzYxAgP44JbfBjsY Xz53PMQowMGoxMP7IWlhmBBrYllxZe4hRgkOZiUR3vD/QCHelMTKqtSi/Pii0pzU4kOM0hws SuK8STKNYUIC6YklqdmpqQWpRTBZJg5OqQZGvrPRZ85m5Hy8Uur9cOr2Kb/ufl3mF+W8djG7 pPWbkAupSj8SEt3THr28kGh6Z5t5sFjdug/llwNm6hh/eKKRUnx7qaXkzUsShxtu+RxPzfr3 7kW47g3DKUJ1Ks85TiizVKwT1j+UmLrB9tLp5m4J7kyREL68SZHz65weJ7PusNz0g8uiIfyU EktxRqKhFnNRcSIA5p5hdVwCAAA=
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Constraining instance-identifiers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 10:29:56 -0000

Good for me. I agree.

Practically it allows me to use rematch() to control the name of the 
lists/containers/leafs appearing in an instance identifier.
Balazs


On 2016-01-22 09:56, Martin Bjorklund wrote:
> How about:
>
> NEW:
>
>    In particular, any XPath expression evaluations are done using the
>    canonical form, if the data type has a canonical form.  If the data
>    type does not have a canonical form, the format of the value MUST
>    match the data type's lexical representation, but the exact format
>    is implementation dependent.
>
>
> /martin

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com


From nobody Fri Jan 22 04:14:43 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B22861A1AB3 for ; Fri, 22 Jan 2016 04:14:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UJLX0QTSdcX for ; Fri, 22 Jan 2016 04:14:39 -0800 (PST)
Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::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 049B41A1A7D for ; Fri, 22 Jan 2016 04:14:39 -0800 (PST)
Received: by mail-lb0-x231.google.com with SMTP id cl12so40011106lbc.1 for ; Fri, 22 Jan 2016 04:14:38 -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:date:message-id:subject:from:to :cc:content-type; bh=ZC1zKBdKUl9TonJtD842vmWn2+I/NZE9M6N2HJ7iXW4=; b=XnvhM7m7LY4ywpxtmv2ZD6ADJo4//Y5c7sw6tyiQewRB9derxlS0MQfni7h2r0j1nB JqLiT/xu11iP+mh7xGzuEXQ4ngQJPcAaoqTxL7coL5L1a5HDRWce8VZV63wX9kXYLQ2u Qe5Ny8dIYMsmesnrQtf1e+LjjvF3Au0vVMxlz4p8EKFhzJjq6n4FSx+74boEOUHIPBsE 3iSoIEvVumyKiDh5wr3mmSfF65mQ7QorR5wZ5G+ZAMsxZMBJfCM7oj/ltuSCnvDLWtYm P9UZfqD8Dch1eOv7pahROYhwjwBgqXF1NHw5IepnESvHxcji/s+NWdLKo9EgL3ALted7 wQtg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZC1zKBdKUl9TonJtD842vmWn2+I/NZE9M6N2HJ7iXW4=; b=DEBhyfDzc6vZBWmhzcFYgOKwHFB81Ivou89O5FuScriDf82K285Vs0y53Wfb87/2Om 82Te+Cw/04g+WHw5LOR4bmyMDmxELr/0vts8NKsr9Vl33Bx1xeWaUAD+lmU965S76WlN Bib0HI3xUHVjtIqU0p8vjonqEEFs+nDw0YnKnlHqombkotgLJqqtJ9t8fjba/H4qADOI gMfW4eLxJCYCXLwHye4y/bLPRUt17FzCQwVOdJYBfo4BKwgox1y7A9jA3wcZ7u6NPvFk 1bWzvpAzFCKc1fn6jx8FJvTbABzuUWJOvOP/reCzKRKvI6rbVyAYswH8b1EuFSdlVrO0 X4ig==
X-Gm-Message-State: AG10YOQFFfzrGHD6frgRs2sU2BSZiPWPRb3SeURDPNq1ukvKdYuQ6QHVjM9w+JL9gHMQQ59HT+dl+d5QYyFNHw==
MIME-Version: 1.0
X-Received: by 10.112.147.1 with SMTP id tg1mr890534lbb.119.1453464877239; Fri, 22 Jan 2016 04:14:37 -0800 (PST)
Received: by 10.112.200.167 with HTTP; Fri, 22 Jan 2016 04:14:37 -0800 (PST)
In-Reply-To: <56A1E7D8.8030902@ericsson.com>
References: <56A0F18D.4030505@ericsson.com> <20160121.161733.727143885958810312.mbj@tail-f.com> <56A10C79.1010601@ericsson.com>  <56A1E7D8.8030902@ericsson.com>
Date: Fri, 22 Jan 2016 04:14:37 -0800
Message-ID: 
From: Andy Bierman 
To: Balazs Lengyel 
Content-Type: multipart/alternative; boundary=047d7b3a7f5cb3ad000529eb2949
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Constraining instance-identifiers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 12:14:41 -0000

--047d7b3a7f5cb3ad000529eb2949
Content-Type: text/plain; charset=UTF-8

Hi,

I am strongly against adding more features to YANG 1.1 at this time.
The deadline for new features has long passed.


Andy


On Fri, Jan 22, 2016 at 12:27 AM, Balazs Lengyel <
balazs.lengyel@ericsson.com> wrote:

> Hello,
> I agree we don't need to change the encoding, but we need to define how
> that encoding is visible/available when evaluating Xpath expressions. Today
> the draft says:
> - instance-identifier does not have a canonical format
> - XPath uses the canonical format
> The two together make it impossible to use it in Xpath, even though there
> are people that would like to do that.
> - Martin mentioned a proprietary extension
> - we would like it.
>
> So I would propose to
> ---- change to 9.1
>
> Old: In particular, any XPath expression evaluations are done using the canonical form.
>
> New:  In particular, whenever a canonical form exists, any XPath
> expression evaluations are done using the canonical form.
>
> --- add to 9.13.2
>
> For instance-identifiers XPath expression evaluations are done using the lexical form.
>
>
> regards Balazs
>
>
> On 2016-01-21 18:53, Andy Bierman wrote:
>
> Hi,
>
> There is no need to change the XML encoding or YANG encoding
> of an instance-identifier.  The prefixes are completely different
> in each.  Prefixes clashes do happen, especially since
> there is no expectation that they are unique.  They are short strings
> with no naming conventions at all.  E.g., I have seen "if" for
> interfaces in multiple modules.
>
> Andy
>
>
> On Thu, Jan 21, 2016 at 8:51 AM, Balazs Lengyel <
> balazs.lengyel@ericsson.com> wrote:
>
>> Hello Martin,
>> If the RFC would define that in XPath expressions an instance identifier
>> MUST be evaluated to a string that complies to the lexical format, using
>> the rematch function, we could do everything we need. In real life prefix
>> clashes are a rare problem.
>> regards Balazs
>>
>> On 2016-01-21 16:17, Martin Bjorklund wrote:
>>
>>> Balazs Lengyel  wrote:
>>>
>>>> Hello,
>>>> We have some instance identifiers in our model but we want to
>>>> contrain what they can point at. What is the best method for that?
>>>>
>>> Unfortunately, there is no standard way of doing this.  (There are
>>> vendor extensions available...)
>>>
>>> [...]
>>>
>>> Some issues:
>>>> - instance-identifiers don't have a canonical format, so what is
>>>> their value in an XPath expression?
>>>>
>>> This is not defined.
>>>
>>> - I didn't find a way to evaluate a regexp in XPath 1.0. Is there a way?
>>>>
>>> In YANG 1.1, there is a function re-match() for this purpose.  For
>>> your use case, it *may* work to match just the local names of all
>>> nodes, i.e., using wildcards for the prefixes.  It is not a generic
>>> solution though.
>>>
>>> - if I have all the needed namespace prefixes in imports, can I just
>>>>    use them?
>>>>
>>> No, these prefixes are local to the module that is doing the import,
>>> and they may or may not match the prefixes used by the implementation
>>> when it construct the instance-identifier value.
>>>
>>>
>>>
>>> /martin
>>>
>>>
>> --
>> Balazs Lengyel                       Ericsson Hungary Ltd.
>> Senior Specialist
>> ECN: 831 7320
>> Mobile: +36-70-330-7909              email: 
>> Balazs.Lengyel@ericsson.com
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>
> --
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> ECN: 831 7320
> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
>
>

--047d7b3a7f5cb3ad000529eb2949
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

I am strongly against adding more f=
eatures to YANG 1.1 at this time.
The deadline for new features h=
as long passed.


Andy

=


On Fr=
i, Jan 22, 2016 at 12:27 AM, Balazs Lengyel <balazs.lengyel@er=
icsson.com> wrote:

 =20
   =20
 =20
  

    Hello,

    I agree we don't need to change the encoding, but we need to define
    how that encoding is visible/available when evaluating Xpath
    expressions. Today the draft says:

    - instance-identifier does not have a canonical format

    - XPath uses the canonical format

    The two together make it impossible to use it in Xpath, even though
    there are people that would like to do that.

    - Martin mentioned a proprietary extension

    - we would like it.

    

    So I would propose to 

    ---- change to 9.1

    
Old: In particular, any XPath expression evaluations are done usin=
g the canonical form.

    New:=C2=A0 In particular, whenever a canonical form exists, any XPath
    expression evaluations are done using the canonical form.
    

    

    --- add to 9.13.2

    
For instance-identifiers XPath expression evaluations are done usi=
ng the lexical form.

    

    regards Balazs

    

    

    
On 2016-01-21 18:53, Andy Bierman
      wrote:

    

    

     =20
      
Hi,
        


        

        
There is no need to change the XML encoding or YANG
          encoding

        
of an instance-identifier.=C2=A0 The prefixes are completely
          different

        
in each.=C2=A0 Prefixes clashes do happen, especially since
        
there is no expectation that they are unique.=C2=A0 They are
          short strings

        
with no naming conventions at all.=C2=A0 E.g., I have seen &qu=
ot;if"
          for

        
interfaces in multiple modules.

        


        

        
Andy

        


        

        

          


            
On Thu, Jan 21, 2016 at 8:51 AM,
              Balazs Lengyel <balazs.lengyel@ericsson.com>
              wrote:

              
Hello
                Martin,

                If the RFC would define that in XPath expressions an
                instance identifier MUST be evaluated to a string that
                complies to the lexical format, using the rematch
                function, we could do everything we need. In real life
                prefix clashes are a rare problem.

                regards Balazs

                

                On 2016-01-21 16:17, Martin Bjorklund wrote:

                

                  Balazs Lengyel <balazs.lengyel@ericsson.com>
                  wrote:

                  

                    Hello,

                    We have some instance identifiers in our model but
                    we want to

                    contrain what they can point at. What is the best
                    method for that?

                  

                  Unfortunately, there is no standard way of doing
                  this.=C2=A0 (There are

                  vendor extensions available...)

                  

                  [...]

                  

                  

                    Some issues:

                    - instance-identifiers don't have a canonical
                    format, so what is

                    their value in an XPath expression?

                  

                  This is not defined.

                  

                  

                    - I didn't find a way to evaluate a regexp in XPath
                    1.0. Is there a way?

                  

                  In YANG 1.1, there is a function re-match() for this
                  purpose.=C2=A0 For

                  your use case, it *may* work to match just the local
                  names of all

                  nodes, i.e., using wildcards for the prefixes.=C2=A0 It i=
s
                  not a generic

                  solution though.

                  

                  

                    - if I have all the needed namespace prefixes in
                    imports, can I just

                    =C2=A0 =C2=A0use them?

                  

                  No, these prefixes are local to the module that is
                  doing the import,

                  and they may or may not match the prefixes used by the
                  implementation

                  when it construct the instance-identifier value.

                  

                  

                  

                  /martin

                  

                  
                    

                
                    

                    -- 

                    Balazs Lengyel=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ericsson
                    Hungary Ltd.

                    Senior Specialist

                    ECN: 831 7320

                    Mobile: +36-70-330-7909=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 email: Balazs.Lengyel@ericsson.com

                    

                    _______________________________________________

                    netmod mailing list

                    ne=
tmod@ietf.org

                    https://www.ietf.org/mailman/listinf=
o/netmod

                  

            

            

          

        

      

    

    

    
--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                       =20
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com=20


  






--047d7b3a7f5cb3ad000529eb2949--


From nobody Fri Jan 22 04:33:43 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453831A1B53 for ; Fri, 22 Jan 2016 04:33:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.477
X-Spam-Level: 
X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-xUSJaet4EX for ; Fri, 22 Jan 2016 04:33:40 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B12C1A1B64 for ; Fri, 22 Jan 2016 04:33:39 -0800 (PST)
X-AuditID: c1b4fb25-f797e6d000007600-da-56a221a11233
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E7.95.30208.1A122A65; Fri, 22 Jan 2016 13:33:37 +0100 (CET)
Received: from [159.107.197.143] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.3.248.2; Fri, 22 Jan 2016 13:33:36 +0100
To: Andy Bierman 
References: <56A0F18D.4030505@ericsson.com> <20160121.161733.727143885958810312.mbj@tail-f.com> <56A10C79.1010601@ericsson.com>  <56A1E7D8.8030902@ericsson.com> 
From: Balazs Lengyel 
Message-ID: <56A221A0.2040306@ericsson.com>
Date: Fri, 22 Jan 2016 13:33:36 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM2K7n+5CxUVhBpu/ilo8ODKL3aK7+xm7 xfyLjawOzB5Llvxk8tj4azGLR0v/RZYA5igum5TUnMyy1CJ9uwSujDuXu1kKFsRU3P2t2MC4 xaiLkZNDQsBEoufTH1YIW0ziwr31bCC2kMBhRok1m5S7GLmA7LWMEs+vN7CAJIQFzCW+/dnC DmKLCKhKXJg7kRmiaDOTxLdZ08ESzAJeEiem7QCbyiZgJDG1/zxYM6+AtkTHywmMIDYLUPOx v9fA4qICMRIXO48wQdQISpyc+QQozsHBKRAo0bVEGGKkhkTrnLlQ4+UlmrfOZoY4VEPi4YW/ rBMYBWch6Z6FpGUWkpYFjMyrGEWLU4uTctONjPVSizKTi4vz8/TyUks2MQID+OCW36o7GC+/ cTzEKMDBqMTD+yFpYZgQa2JZcWXuIUYJDmYlEV5FoUVhQrwpiZVVqUX58UWlOanFhxilOViU xHkP8gOlBNITS1KzU1MLUotgskwcnFINjFN3zet28mLf+1zvscEyy0XK5x4eevZ0r+UM/zon 6/yyv/NqL0bZX/himtAqLZaW0rlX+3T+9SIBWau9OXMj1JyOG3I5CNy5d49p5+ljhlfypqs9 1S/qsDhXsbLOoEIsJeb4a6uWXdzB7/eI7bkQH+vYIBpyP93bYiNX1L61xxQdRc4LzNrxVoml OCPRUIu5qDgRAHtcIOJcAgAA
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Constraining instance-identifiers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 12:33:42 -0000


  
    
  
  
    Hello,

    This is a clarification not a new feature. I am 100%  sure all
    implementations already support the lexical representation of
    instance-identifiers, otherwise they would not be able to read and
    write them.

    For new features I agree it is too late.

    regards Balazs

    

    
On 2016-01-22 13:14, Andy Bierman
      wrote:

    

    

      
      
Hi,
        


        

        
I am strongly against adding more features to YANG 1.1 at
          this time.

        
The deadline for new features has long passed.

        


        

        


        

        
Andy

        


        

      

      


        
On Fri, Jan 22, 2016 at 12:27 AM,
          Balazs Lengyel <balazs.lengyel@ericsson.com>
          wrote:

          

            
 Hello,

              I agree we don't need to change the encoding, but we need
              to define how that encoding is visible/available when
              evaluating Xpath expressions. Today the draft says:

              - instance-identifier does not have a canonical format

              - XPath uses the canonical format

              The two together make it impossible to use it in Xpath,
              even though there are people that would like to do that.

              - Martin mentioned a proprietary extension

              - we would like it.

              

              So I would propose to 

              ---- change to 9.1

              
Old: In particular, any XPath expression evaluations are done using the canonical form.

              New:  In particular, whenever a canonical form exists, any
              XPath expression evaluations are done using the canonical
              form. 

              

              --- add to 9.13.2

              
For instance-identifiers XPath expression evaluations are done using the lexical form.

              

              regards Balazs

              

              

              
On 2016-01-21 18:53, Andy Bierman wrote:

              

              

                
Hi,
                  


                  

                  
There is no need to change the XML encoding or
                    YANG encoding

                  
of an instance-identifier.  The prefixes are
                    completely different

                  
in each.  Prefixes clashes do happen, especially
                    since

                  
there is no expectation that they are unique. 
                    They are short strings

                  
with no naming conventions at all.  E.g., I have
                    seen "if" for

                  
interfaces in multiple modules.

                  


                  

                  
Andy

                  


                  

                  

                    


                      
On Thu, Jan 21, 2016 at
                        8:51 AM, Balazs Lengyel <balazs.lengyel@ericsson.com>
                        wrote:

                        
Hello Martin,

                          If the RFC would define that in XPath
                          expressions an instance identifier MUST be
                          evaluated to a string that complies to the
                          lexical format, using the rematch function, we
                          could do everything we need. In real life
                          prefix clashes are a rare problem.

                          regards Balazs

                          

                          On 2016-01-21 16:17, Martin Bjorklund wrote:

                          
 Balazs Lengyel
                            <balazs.lengyel@ericsson.com>

                            wrote:

                            
 Hello,

                              We have some instance identifiers in our
                              model but we want to

                              contrain what they can point at. What is
                              the best method for that?

                            

                            Unfortunately, there is no standard way of
                            doing this.  (There are

                            vendor extensions available...)

                            

                            [...]

                            

                            
 Some issues:

                              - instance-identifiers don't have a
                              canonical format, so what is

                              their value in an XPath expression?

                            

                            This is not defined.

                            

                            
 - I didn't
                              find a way to evaluate a regexp in XPath
                              1.0. Is there a way?

                            

                            In YANG 1.1, there is a function re-match()
                            for this purpose.  For

                            your use case, it *may* work to match just
                            the local names of all

                            nodes, i.e., using wildcards for the
                            prefixes.  It is not a generic

                            solution though.

                            

                            
 - if I have
                              all the needed namespace prefixes in
                              imports, can I just

                                 use them?

                            

                            No, these prefixes are local to the module
                            that is doing the import,

                            and they may or may not match the prefixes
                            used by the implementation

                            when it construct the instance-identifier
                            value.

                            

                            

                            

                            /martin

                            

                            
                                 

                            

                                  -- 

                                  Balazs Lengyel                     
                                   Ericsson Hungary Ltd.

                                  Senior Specialist

                                  ECN: 831 7320

                                  Mobile: +36-70-330-7909             
                                  email: Balazs.Lengyel@ericsson.com

                                  

_______________________________________________

                                  netmod mailing list

                                  netmod@ietf.org

                                  https://www.ietf.org/mailman/listinfo/netmod

                                

                         

                       

                        

                     

                   

                 

               

                  
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com 


                

          

        

        

      

    

    

    
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com 


  



From nobody Fri Jan 22 04:40:51 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 219161A1BB3 for ; Fri, 22 Jan 2016 04:40:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQ3-YPmn03IL for ; Fri, 22 Jan 2016 04:40:47 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A12A51A1BA5 for ; Fri, 22 Jan 2016 04:40:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2284; q=dns/txt; s=iport; t=1453466447; x=1454676047; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=A0C2K/bfAEMNeqMVa8PH0o4Mx3MXfoQCQ28UsFfQKeo=; b=RWonNlcoOl6/XQoupttRcu0PnAAEWdkLHUHpd74zXW0ORBwCBJaJnHIx UfFUNMyssD6+gCu62cDiE+KbmqKejQjR1dLXsVFfspij3LvVqioLXDyRL HG66UZDIT4X+183u2AJwy7hGv/e1lsSvNM6kZUACNOzifETxucMb4pfAh A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAgBEIqJW/4QNJK1egzpSbQaIUbIGA?= =?us-ascii?q?Q2BYhgKhSNKAhyBIzgUAQEBAQEBAYEKhEIBAQQBAQEgETobAgEIDgoCAiYCAgI?= =?us-ascii?q?lCxUQAgQBEh+HfA6ud49BAQEBAQEBAQEBAQEBAQEBAQEBAQESBHuKJIRhgmuBO?= =?us-ascii?q?gWNKolMAY1VjnmOPgEeAQFCg2Zqhid8AQEB?=
X-IronPort-AV: E=Sophos;i="5.22,331,1449532800"; d="scan'208";a="66103911"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Jan 2016 12:40:46 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u0MCek8q019864 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Jan 2016 12:40:46 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 22 Jan 2016 07:40:45 -0500
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Fri, 22 Jan 2016 07:40:45 -0500
From: "Acee Lindem (acee)" 
To: Ebben Aries , Qin Wu , netmod WG 
Thread-Topic: [netmod] Working group Last Call: draft-ietf-netmod-acl-model-06
Thread-Index: AQHRVNmwd5Cl3bCeR0uxnmZjTenc4J8HeoIA
Date: Fri, 22 Jan 2016 12:40:45 +0000
Message-ID: 
References:  <56A1C480.7000509@juniper.net>
In-Reply-To: <56A1C480.7000509@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.205]
Content-Type: text/plain; charset="utf-8"
Content-ID: <493CDCC8732D9B45BF3BF9958E3D60DA@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] Working group Last Call: draft-ietf-netmod-acl-model-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 12:40:49 -0000

DQoNCk9uIDEvMjIvMTYsIDEyOjU2IEFNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBFYmJlbiBBcmll
cyINCjxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgZXhhQGp1bmlwZXIubmV0
PiB3cm90ZToNCg0KPg0KPk9uIDAxLzIxLzIwMTYgMTI6NDUgQU0sIFFpbiBXdSB3cm90ZToNCj4+
IDEuIFRoaXMgZHJhZnQgZGVmaW5lcyB0d28gbW9kdWxlLCBvbmUgaXMgSUVURi1QQUNLRVQtRklF
TERTLCB0aGUgb3RoZXINCj4+aXMgaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0IG1vZHVsZSwNCj4+
IEkgYW0gd29uZGVyaW5nIHdoZXRoZXIgaWV0Zi1wYWNrZXQtZmllbGRzIG1vZHVsZSBjYW4gYmUg
ZGVmaW5lZCBpbiBtb3JlDQo+PmdlbmVyaWMgd2F5IHRoYXQgY2FuIGJlIGFwcGxpZWQgdG8gb3Ro
ZXIgbW9kdWxlcyBkZWZpbmVkIHNvbWV3aGVyZSBlbHNlPw0KPj4gZS5nLiwgaW4gaWV0Zi1wYWNr
ZXQtZmllbGRzIG1vZHVsZSwgYWNsLWlwLWhlYWRlci1maWVsZHMgZ3JvdXBpbmcgaXMNCj4+ZGVm
aW5lZCwgSSBhbSB3b25kZXJpbmcgd2hldGhlciBwcmVmaXggImFjbC0iIGNhbiBiZSByZW1vdmVk
IHRvIG1ha2UgaXQNCj4+bW9yZSBnZW5lcmljPw0KPg0KPldoYXQgeW91J2xsIGxpa2VseSBydW4g
aW50byBoZXJlIGlzIHRoYXQgdGhlIGhlYWRlciBmaWVsZHMgZGVmaW5lZCBpbg0KPmFjbC0qLWhl
YWRlci1maWVsZHMgYXJlIG1vcmUgb3IgbGVzcyB0aGUgbG93ZXN0IGNvbW1vbiBkZW5vbWluYXRv
cnMgZm9yDQo+dGhlIGFwcGxpY2F0aW9uIG9mICJhY2wiIC0gTm90IGFsbCBoZWFkZXIgZmllbGRz
IGFyZSBkZWZpbmVkIGhlcmUuDQo+DQo+SSBzdXBwb3NlIGFuIGFwcHJvYWNoIGNvdWxkIGJlIHRv
IGRlZmluZSBnZW5lcmljIGdyb3VwaW5ncyBvZiBhbGwgaGVhZGVyDQo+ZmllbGRzIGFuZCBjcmVh
dGUgcGVyIGFwcGxpY2F0aW9uIGdyb3VwaW5ncywgcmVmZXJlbmNpbmcgd2hhdCBpcw0KPnN1cHBv
cnRlZCB3aXRoIGFwcHJvcHJpYXRlIGNvbnN0cmFpbnRzLCBldGMuLi4gIE5vdCBzdXJlIHdoYXQg
dGhhdCBidXlzDQo+aGVyZSBzaW5jZSB5b3UncmUgbGlrZWx5IHRvIGhhdmUgb3ZlcmxhcCBidXQg
bm90IGNvbXBsZXRlIHBhcml0eSBiZXR3ZWVuDQo+dGhlIGRpZmZlcmVudCBjb25zdW1lcnMgb2Yg
dGhlc2UgcGFja2V0IGZpZWxkcy4NCg0KRnVydGhlcm1vcmUsIHRoaXMgaXMgbm90IGEgZ2VuZXJp
YyBJUCBwYWNrZXQgZmllbGRzIFlBTkcgbW9kdWxlLiBJdCBpcyBhDQptb2R1bGUgZm9yIG1hdGNo
aW5nIElQIHBhY2tldCBmaWVsZHMgdXNpbmcgdHJhZGl0aW9uYWwgQUNMIHNlbWFudGljcy4NCkhl
bmNlLCBjaGFuZ2luZyB0aGUgY29udGFpbmVyIG5hbWUgd29u4oCZdCBjaGFuZ2UgdGhlIGNvbnRl
bnQgb3Igc2VtYW50aWNzLg0KSWYgYW55dGhpbmcsIHRoZSBtb2R1bGUgbmFtZSBzaG91bGQgYmUg
Y2hhbmdlZCB0byBpbmNsdWRlIOKAnGFjbC3igJwgYW5kIG5vdA0KaW1wbHkgdGhhdCBpdCBpcyBn
ZW5lcmljLg0KDQpUaGFua3MsDQpBY2VlDQoNCg0KDQo+DQo+L2ViYmVuDQo+DQo+X19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5uZXRtb2QgbWFpbGluZyBs
aXN0DQo+bmV0bW9kQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9uZXRtb2QNCg0K


From nobody Fri Jan 22 04:42:05 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22EF81A1BC6 for ; Fri, 22 Jan 2016 04:42:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYCEuhpJq4y0 for ; Fri, 22 Jan 2016 04:42:00 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 703E61A1BB3 for ; Fri, 22 Jan 2016 04:42:00 -0800 (PST)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id C7C5D1CC01AB; Fri, 22 Jan 2016 13:42:10 +0100 (CET)
From: Ladislav Lhotka 
To: Robert Wilton , "netmod\@ietf.org" , Martin Bjorklund 
In-Reply-To: <56A0C64A.3090506@cisco.com>
References: <56A0C64A.3090506@cisco.com>
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Fri, 22 Jan 2016 13:41:56 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] Comparison of structural-mount and ysdl drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 12:42:03 -0000

Robert Wilton  writes:

> Hi Lada, Martin,
>
> I've reviewed both draft-bjorklund-netmod-structural-mount-00 and 
> draft-lhotka-netmod-ysdl-00.
>
> In comparing these two drafts, the main differences that I perceive are:
>
> 1) structural-mount allows the mounted data model to publish its 
> supported schema at the mount point, but ysdl requires the mounting 
> device to know and publish the schema for all mounted data models.

I am not sure what you mean by "publish" but I think really the only
difference is that structural-mount provides schema information as
regular state data and YSDL as meta-data.

In my view, the definition of a data model schema is really
meta-data. The module "ietf-yang-structural-mount" and its data would
require special treatment anyway - for example, it has to be found in a
well-known location, so it cannot itself be mounted.

> 2) A corollary of (1) is that structural-mount also allows different 
> schema data models to be published at the mount point (e.g. under a 
> list), but ysdl does not.

True, but it can be easily emulated by using either a choice (or a
"dynamic choice" using "when") and defining different sub-schemas as
different cases. I'd argue this is a more robust approach.

> 3) structural-mount has a mount node embedded directly in the schema, 
> where as for ysdl, the equivalent mount points are only specified in the 
> ysdl meta-schema.
> 4) ysdl is extensible to cover other non mount related use-cases (such 
> as anydata) where being able to dynamically make available the schema is 
> useful.
> 5) structural-mount also covers RPCs and Notifications, whereas these 
> appear to be outside the scope of ysdl.

This is just an omission on the part of YSDL. The approach proposed for
structural-mount can be used as well.

> 6) The ysdl meta-data language appears to be more flexible, and hence 
> also more complex, than the equivalent "mount-points" schema defined in 
> structural-mount.
> 7) For structural-mount the "mount-points" table is returned as a normal 
> oper data YANG module in the mounting device, whereas for ysdl, protocol 
> extensions would be required to NETCONF/RESTCONF to access the schema 
> meta-data.

First, structural-mount uses an extension that has to be considered
mandatory because otherwise no interoperability can take place. So I
don't think that it seamlessly integrates into NETCONF/RESTCONF.

And second, I actually considered to simply extend yang-library with the
YSDL data, but I decided to keep it separate in order to avoid
additional delays for the yang-library spec.

>
> Considering these differences:
>
> For points (1) and (2), I can think of scenarios where having a mounted 
> device being able to provide its schema via yang-library and for that 
> schema to differ for different mounted devices is probably a requirement 
> for some plausible mount scenarios.  E.g. one that I can think of is the 
> case that you have a YANG controller that is exposing an aggregated YANG 
> model for a set of devices, it seems that you would need to be 
> accommodate mounted devices that are made by different vendors and 
> running different software versions which would imply that their schema 
> may also be different.

Right, you would use a (dynamic) choice in this case.

>
> For point (3), this is a matter of preference, I like that fact that the 
> mount point is explicit in the schema in structural-mount.  The ysdl

But this means using a YANG extension with all the problems regarding
conformance. And this extension is quite far-reaching.

Lada

> meta-schema appears to be more flexible because it can in effect put 
> mount points anywhere, but even with structural mount this same 
> flexibility could presumably still be achieved by augmenting with a 
> mount point.
>
> For point (4), I think that this is useful functionality, and perhaps if 
> structural-mount is to be used as the base draft going forward it might 
> be worth considering whether the solution could be able to cover, or be 
> cleanly extended, to this use case.
>
> For point (5), I definitely think that it is beneficial that 
> structural-mount has an intuitive solution for RPCs and Notifications.
>
> For points (6) and (7) my gut instinct is that the structural-mount 
> would be easier to standardize and also less work to implement.
>
>
> Some of my points above may be incorrect, and that might swing the 
> balance between the two solutions, so please correct me if I have got 
> anything wrong.  Otherwise, just considering the written drafts as they 
> stand now, my personal preference is that I would favour using 
> structural-mount as a starting point for a solution.
>
> Martin, I also have some comments/questions on the structural-mount 
> draft, I'll put these into a separate email.
>
> Thanks,
> Rob

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


From nobody Fri Jan 22 05:00:12 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F37C1A1EFA for ; Fri, 22 Jan 2016 05:00:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhtLeL83RajS for ; Fri, 22 Jan 2016 05:00: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 F23961A1BAF for ; Fri, 22 Jan 2016 05:00:08 -0800 (PST)
Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id B3B351AE035C; Fri, 22 Jan 2016 14:00:07 +0100 (CET)
Date: Fri, 22 Jan 2016 14:00:10 +0100 (CET)
Message-Id: <20160122.140010.639464305373019422.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund 
In-Reply-To: 
References:  <56A1E7D8.8030902@ericsson.com> 
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Constraining instance-identifiers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 13:00:11 -0000

Hi,

Andy Bierman  wrote:
> Hi,
> 
> I am strongly against adding more features to YANG 1.1 at this time.

Do you refer to the proprietary extension to restrict i-is?  If so, I
agree (and Balazs just did in a separate email as well) that this is
out of scope.


/martin


> The deadline for new features has long passed.
> 
> 
> Andy
> 
> 
> On Fri, Jan 22, 2016 at 12:27 AM, Balazs Lengyel <
> balazs.lengyel@ericsson.com> wrote:
> 
> > Hello,
> > I agree we don't need to change the encoding, but we need to define how
> > that encoding is visible/available when evaluating Xpath expressions. Today
> > the draft says:
> > - instance-identifier does not have a canonical format
> > - XPath uses the canonical format
> > The two together make it impossible to use it in Xpath, even though there
> > are people that would like to do that.
> > - Martin mentioned a proprietary extension
> > - we would like it.
> >
> > So I would propose to
> > ---- change to 9.1
> >
> > Old: In particular, any XPath expression evaluations are done using the canonical form.
> >
> > New:  In particular, whenever a canonical form exists, any XPath
> > expression evaluations are done using the canonical form.
> >
> > --- add to 9.13.2
> >
> > For instance-identifiers XPath expression evaluations are done using the lexical form.
> >
> >
> > regards Balazs
> >
> >
> > On 2016-01-21 18:53, Andy Bierman wrote:
> >
> > Hi,
> >
> > There is no need to change the XML encoding or YANG encoding
> > of an instance-identifier.  The prefixes are completely different
> > in each.  Prefixes clashes do happen, especially since
> > there is no expectation that they are unique.  They are short strings
> > with no naming conventions at all.  E.g., I have seen "if" for
> > interfaces in multiple modules.
> >
> > Andy
> >
> >
> > On Thu, Jan 21, 2016 at 8:51 AM, Balazs Lengyel <
> > balazs.lengyel@ericsson.com> wrote:
> >
> >> Hello Martin,
> >> If the RFC would define that in XPath expressions an instance identifier
> >> MUST be evaluated to a string that complies to the lexical format, using
> >> the rematch function, we could do everything we need. In real life prefix
> >> clashes are a rare problem.
> >> regards Balazs
> >>
> >> On 2016-01-21 16:17, Martin Bjorklund wrote:
> >>
> >>> Balazs Lengyel  wrote:
> >>>
> >>>> Hello,
> >>>> We have some instance identifiers in our model but we want to
> >>>> contrain what they can point at. What is the best method for that?
> >>>>
> >>> Unfortunately, there is no standard way of doing this.  (There are
> >>> vendor extensions available...)
> >>>
> >>> [...]
> >>>
> >>> Some issues:
> >>>> - instance-identifiers don't have a canonical format, so what is
> >>>> their value in an XPath expression?
> >>>>
> >>> This is not defined.
> >>>
> >>> - I didn't find a way to evaluate a regexp in XPath 1.0. Is there a way?
> >>>>
> >>> In YANG 1.1, there is a function re-match() for this purpose.  For
> >>> your use case, it *may* work to match just the local names of all
> >>> nodes, i.e., using wildcards for the prefixes.  It is not a generic
> >>> solution though.
> >>>
> >>> - if I have all the needed namespace prefixes in imports, can I just
> >>>>    use them?
> >>>>
> >>> No, these prefixes are local to the module that is doing the import,
> >>> and they may or may not match the prefixes used by the implementation
> >>> when it construct the instance-identifier value.
> >>>
> >>>
> >>>
> >>> /martin
> >>>
> >>>
> >> --
> >> Balazs Lengyel                       Ericsson Hungary Ltd.
> >> Senior Specialist
> >> ECN: 831 7320
> >> Mobile: +36-70-330-7909              email: 
> >> Balazs.Lengyel@ericsson.com
> >>
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >>
> >
> >
> > --
> > Balazs Lengyel                       Ericsson Hungary Ltd.
> > Senior Specialist
> > ECN: 831 7320
> > Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
> >
> >


From nobody Fri Jan 22 05:28:22 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E011A6F34 for ; Fri, 22 Jan 2016 05:28:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPORF9pbKUff for ; Fri, 22 Jan 2016 05:28:18 -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 C6A1E1A6F33 for ; Fri, 22 Jan 2016 05:28:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6880; q=dns/txt; s=iport; t=1453469298; x=1454678898; h=subject:to:references:from:cc:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=q9qwezUwxyQWwrGYMRZ4nW3U+7M/R1geRsMfY0r5ubE=; b=hex1sOZATwTuyKOT1043tMjqKSvoWbGg/NfYDBGEqs+x2KsW/bJ+ZfvH gwuOLXiZkFh6wRg+OEReQx7eTP0DivnlVwvy5QwbSRdvj7/VKpeRnG26s AUfccooLfIGtG9e/4xHnzgj1ESsmVfysGt07qjZw5+5BpO5GpQF/7nQ9x s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqBABELaJW/xbLJq1ehHmIV7N2gl+DM?= =?us-ascii?q?AKBdhEBAQEBAQEBgQqEQQEBAQMBDiotEwEQCxgJFg8JAwIBAgFFBgEMBgIBARe?= =?us-ascii?q?HeAi+NwEBAQEBAQEBAQEBAQEBAQEBARiGMoRthBsRAYRZAQSWdog3hR+BXoREg?= =?us-ascii?q?wSFU44/NiyDZjwuhXOBMAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.22,331,1449532800"; d="scan'208";a="648712934"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jan 2016 13:28:15 +0000
Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u0MDSEPw025921; Fri, 22 Jan 2016 13:28:14 GMT
To: Ladislav Lhotka , "netmod@ietf.org" 
References: <56A0C64A.3090506@cisco.com> 
From: Robert Wilton 
Message-ID: <56A22E6E.1040109@cisco.com>
Date: Fri, 22 Jan 2016 13:28:14 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Comparison of structural-mount and ysdl drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 13:28:20 -0000

Hi Lada,

Please see inline ...

On 22/01/2016 12:41, Ladislav Lhotka wrote:
> Robert Wilton  writes:
>
>> Hi Lada, Martin,
>>
>> I've reviewed both draft-bjorklund-netmod-structural-mount-00 and
>> draft-lhotka-netmod-ysdl-00.
>>
>> In comparing these two drafts, the main differences that I perceive are:
>>
>> 1) structural-mount allows the mounted data model to publish its
>> supported schema at the mount point, but ysdl requires the mounting
>> device to know and publish the schema for all mounted data models.
> I am not sure what you mean by "publish" but I think really the only
> difference is that structural-mount provides schema information as
> regular state data and YSDL as meta-data.
I was really referring to the inline-yang-library option in structural 
mount that allows the actual YANG schema to be deferred to the mounted 
device implementing yang-library (and which is available at the mount 
point).  This is the option that I would anticipate would be used in the 
LNE model.

>
> In my view, the definition of a data model schema is really
> meta-data. The module "ietf-yang-structural-mount" and its data would
> require special treatment anyway - for example, it has to be found in a
> well-known location, so it cannot itself be mounted.
Yes, I can see how it is meta-data, but I'm not sure that it is 
significantly different from the information provided in yang-library 
which is represented a s regular YANG operational module.

For structural-mount: A mounted model should be able to make the 
mount-points structure available at the mount point if required. I.e. 
the solution is able to naturally recurse (as Martin confirmed in reply 
to Robert Varga's email).

>
>> 2) A corollary of (1) is that structural-mount also allows different
>> schema data models to be published at the mount point (e.g. under a
>> list), but ysdl does not.
> True, but it can be easily emulated by using either a choice (or a
> "dynamic choice" using "when") and defining different sub-schemas as
> different cases. I'd argue this is a more robust approach.
I don't think that emulating this with a choice is going to be 
particularly clean.  In addition, the device that is doing the mounting 
doesn't necessarily know what models the mounted device actual 
implements.  For ysdl to work for this scenario, the mounting device 
would probably need to query the yang-library (and/or ysdl 
meta-information to allow the solution to recurse) for each mounted 
device to construct the meta-data for it.  At this point I would argue 
that it is easier to just provide direct access to the yang-library for 
the mounted device (as structural-mount solution proposes).

>
>> 3) structural-mount has a mount node embedded directly in the schema,
>> where as for ysdl, the equivalent mount points are only specified in the
>> ysdl meta-schema.
>> 4) ysdl is extensible to cover other non mount related use-cases (such
>> as anydata) where being able to dynamically make available the schema is
>> useful.
>> 5) structural-mount also covers RPCs and Notifications, whereas these
>> appear to be outside the scope of ysdl.
> This is just an omission on the part of YSDL. The approach proposed for
> structural-mount can be used as well.
OK.

>
>> 6) The ysdl meta-data language appears to be more flexible, and hence
>> also more complex, than the equivalent "mount-points" schema defined in
>> structural-mount.
>> 7) For structural-mount the "mount-points" table is returned as a normal
>> oper data YANG module in the mounting device, whereas for ysdl, protocol
>> extensions would be required to NETCONF/RESTCONF to access the schema
>> meta-data.
> First, structural-mount uses an extension that has to be considered
> mandatory because otherwise no interoperability can take place. So I
> don't think that it seamlessly integrates into NETCONF/RESTCONF.
I think that only clients and devices that need to mount other models 
would need to support it.  Whether this means it becomes mandatory would 
presumable depend on how widely the mount node used in standard YANG models.

>
> And second, I actually considered to simply extend yang-library with the
> YSDL data, but I decided to keep it separate in order to avoid
> additional delays for the yang-library spec.
>
>> Considering these differences:
>>
>> For points (1) and (2), I can think of scenarios where having a mounted
>> device being able to provide its schema via yang-library and for that
>> schema to differ for different mounted devices is probably a requirement
>> for some plausible mount scenarios.  E.g. one that I can think of is the
>> case that you have a YANG controller that is exposing an aggregated YANG
>> model for a set of devices, it seems that you would need to be
>> accommodate mounted devices that are made by different vendors and
>> running different software versions which would imply that their schema
>> may also be different.
> Right, you would use a (dynamic) choice in this case.
As per above, I'm not really convinced that this works as a solution.

>
>> For point (3), this is a matter of preference, I like that fact that the
>> mount point is explicit in the schema in structural-mount.  The ysdl
> But this means using a YANG extension with all the problems regarding
> conformance. And this extension is quite far-reaching.
I would think that depends on how many models end up needing to mount 
other models.

Thanks,
Rob


>
> Lada
>
>> meta-schema appears to be more flexible because it can in effect put
>> mount points anywhere, but even with structural mount this same
>> flexibility could presumably still be achieved by augmenting with a
>> mount point.
>>
>> For point (4), I think that this is useful functionality, and perhaps if
>> structural-mount is to be used as the base draft going forward it might
>> be worth considering whether the solution could be able to cover, or be
>> cleanly extended, to this use case.
>>
>> For point (5), I definitely think that it is beneficial that
>> structural-mount has an intuitive solution for RPCs and Notifications.
>>
>> For points (6) and (7) my gut instinct is that the structural-mount
>> would be easier to standardize and also less work to implement.
>>
>>
>> Some of my points above may be incorrect, and that might swing the
>> balance between the two solutions, so please correct me if I have got
>> anything wrong.  Otherwise, just considering the written drafts as they
>> stand now, my personal preference is that I would favour using
>> structural-mount as a starting point for a solution.
>>
>> Martin, I also have some comments/questions on the structural-mount
>> draft, I'll put these into a separate email.
>>
>> Thanks,
>> Rob


From nobody Fri Jan 22 06:33:42 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47AA21A90B3 for ; Fri, 22 Jan 2016 06:33:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mAL6gPSLsKM for ; Fri, 22 Jan 2016 06:33:39 -0800 (PST)
Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1900:3001:11::28]) by ietfa.amsl.com (Postfix) with ESMTP id B695C1A908E for ; Fri, 22 Jan 2016 06:33:34 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id B43B41E5A2F; Fri, 22 Jan 2016 06:32:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id dtdhiOvLgQlK; Fri, 22 Jan 2016 06:32:46 -0800 (PST)
Received: from [192.168.1.129] (host86-133-254-101.range86-133.btcentralplus.com [86.133.254.101]) by c8a.amsl.com (Postfix) with ESMTPSA id 06E8A1E5A2B; Fri, 22 Jan 2016 06:32:45 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_A9C39FC7-756B-4587-AD9C-1F4DEACE4F8F"
From: William Lupton 
In-Reply-To: 
Date: Fri, 22 Jan 2016 14:33:32 +0000
Message-Id: <8B543BAE-B439-4A64-8FA1-DE24EB1FDB46@broadband-forum.org>
References: <2431FE7A-9CC9-48A6-92FF-AE383DB71394@broadband-forum.org>  
To: Andy Bierman 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Broadband Forum questions on RFC 6087bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 14:33:40 -0000

--Apple-Mail=_A9C39FC7-756B-4587-AD9C-1F4DEACE4F8F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Thanks for the responses. One clarification below on what is definitely =
a minor point!

> On 22 Jan 2016, at 00:18, Andy Bierman  wrote:
> On Wed, Jan 20, 2016 at 6:45 AM, William Lupton =
> =
wrote:
> > 2. Rules re changing submodule names
> >
> > Section 5.7 (Lifecycle Management) says that "The [...] submodule =
name MUST NOT be changed, once the document containing the module or =
submodule is published" but this might contradict RFC 6020 Section 11, =
which says "A module may be split into a set of submodules, or a =
submodule may be removed...".
> >
> > More specifically, 6020 doesn't mention renaming a submodule (so =
presumably that's not permitted), but the mention of both splitting =
modules into submodules AND removing submodules suggests that arbitrary =
module/submodule refactoring is permitted. And if I'm being pedantic, =
revision #1 could have submodule A1, revision #2 could remove it, and =
revision #3 could reintroduce it as submodule A2, so that's effectively =
a rename!
>=20
> I do not see any issue here.
> Moving an object does not change the submodule name.

My point was to question why renaming submodules is forbidden when in =
fact it seems that submodule rename can be achieved via other means. =
It's not that I actually want to do it, just that 6087 and 6020 don't =
seem quite consistent on this topic.

William=

--Apple-Mail=_A9C39FC7-756B-4587-AD9C-1F4DEACE4F8F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Thanks for the responses. One clarification below on what is =
definitely a minor point!

On 22 Jan 2016, at 00:18, Andy =
Bierman <andy@yumaworks.com> wrote:
On Wed, Jan 20, 2016 at 6:45 AM, William Lupton =
<wlupton@broadband-forum.org> wrote:

> 2. Rules re changing submodule names

>

> Section 5.7 (Lifecycle Management) says that "The [...] submodule =
name MUST NOT be changed, once the document containing the module or =
submodule is published" but this might contradict RFC 6020 Section 11, =
which says "A module may be split into a set of submodules, or a =
submodule may be removed...".

>

> More specifically, 6020 doesn't mention renaming a submodule (so =
presumably that's not permitted), but the mention of both splitting =
modules into submodules AND removing submodules suggests that arbitrary =
module/submodule refactoring is permitted. And if I'm being pedantic, =
revision #1 could have submodule A1, revision #2 could remove it, and =
revision #3 could reintroduce it as submodule A2, so that's effectively =
a rename!

I do not see any issue here.
Moving an object does not change the submodule =
name.

My point was to question why renaming submodules =
is forbidden when in fact it seems that submodule rename can be achieved =
via other means. It's not that I actually want to do it, just that 6087 =
and 6020 don't seem quite consistent on this topic.

William
=

--Apple-Mail=_A9C39FC7-756B-4587-AD9C-1F4DEACE4F8F--


From nobody Fri Jan 22 06:59:59 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBE91A8734 for ; Fri, 22 Jan 2016 06:59:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.652
X-Spam-Level: 
X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bnKOLRUahnd for ; Fri, 22 Jan 2016 06:59:56 -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 D0ACE1A6EFC for ; Fri, 22 Jan 2016 06:59:55 -0800 (PST)
Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 460071819EF; Fri, 22 Jan 2016 15:59:53 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1453474793; bh=dXJ3m2o7Jvph5Xw9nDwCI4bk6XyxNfRrFCOTbzXgbv0=; h=From:Date:To; b=KMlD9b5jVP8iJ4kgWTMrkdraIl1xQyq1WJSxBYhitHnJHH4hiV5WLZbbwnx/KzmMG V4QN5hTF56N2j3SBoOLa8A5G25IChUzMQ0rcGjKWf8fUBdQ1ttTcWYGfhxPtY8afK2 LKD9N5wJevT9oxN3pkREwPaqfmNW0U5Q09f2mg3c=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: <56A22E6E.1040109@cisco.com>
Date: Fri, 22 Jan 2016 15:59:52 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <097158EE-01CF-421E-AB35-E2FBFA6E3F3B@nic.cz>
References: <56A0C64A.3090506@cisco.com>  <56A22E6E.1040109@cisco.com>
To: Robert Wilton 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Comparison of structural-mount and ysdl drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 14:59:58 -0000

> On 22 Jan 2016, at 14:28, Robert Wilton  wrote:
>=20
> Hi Lada,
>=20
> Please see inline ...
>=20
> On 22/01/2016 12:41, Ladislav Lhotka wrote:
>> Robert Wilton  writes:
>>=20
>>> Hi Lada, Martin,
>>>=20
>>> I've reviewed both draft-bjorklund-netmod-structural-mount-00 and
>>> draft-lhotka-netmod-ysdl-00.
>>>=20
>>> In comparing these two drafts, the main differences that I perceive =
are:
>>>=20
>>> 1) structural-mount allows the mounted data model to publish its
>>> supported schema at the mount point, but ysdl requires the mounting
>>> device to know and publish the schema for all mounted data models.
>> I am not sure what you mean by "publish" but I think really the only
>> difference is that structural-mount provides schema information as
>> regular state data and YSDL as meta-data.
> I was really referring to the inline-yang-library option in structural =
mount that allows the actual YANG schema to be deferred to the mounted =
device implementing yang-library (and which is available at the mount =
point).  This is the option that I would anticipate would be used in the =
LNE model.

YSDL doesn't address any kind of remote mounts. It just adds a =
pull-style method for the schema construction but everything is local to =
the device. I think that mounting data from other devices is a different =
matter with specific problems (access) that don't exist in YSDL.

>=20
>>=20
>> In my view, the definition of a data model schema is really
>> meta-data. The module "ietf-yang-structural-mount" and its data would
>> require special treatment anyway - for example, it has to be found in =
a
>> well-known location, so it cannot itself be mounted.
> Yes, I can see how it is meta-data, but I'm not sure that it is =
significantly different from the information provided in yang-library =
which is represented a s regular YANG operational module.

It doesn't really matter how the schema info is retrieved, as long as it =
is state data available at a well-known location. As I wrote, YSDL could =
be just an augmentation of yang-library.

Lada

>=20
> For structural-mount: A mounted model should be able to make the =
mount-points structure available at the mount point if required. I.e. =
the solution is able to naturally recurse (as Martin confirmed in reply =
to Robert Varga's email).
>=20
>>=20
>>> 2) A corollary of (1) is that structural-mount also allows different
>>> schema data models to be published at the mount point (e.g. under a
>>> list), but ysdl does not.
>> True, but it can be easily emulated by using either a choice (or a
>> "dynamic choice" using "when") and defining different sub-schemas as
>> different cases. I'd argue this is a more robust approach.
> I don't think that emulating this with a choice is going to be =
particularly clean.  In addition, the device that is doing the mounting =
doesn't necessarily know what models the mounted device actual =
implements.  For ysdl to work for this scenario, the mounting device =
would probably need to query the yang-library (and/or ysdl =
meta-information to allow the solution to recurse) for each mounted =
device to construct the meta-data for it. At this point I would argue =
that it is easier to just provide direct access to the yang-library for =
the mounted device (as structural-mount solution proposes).
>=20
>>=20
>>> 3) structural-mount has a mount node embedded directly in the =
schema,
>>> where as for ysdl, the equivalent mount points are only specified in =
the
>>> ysdl meta-schema.
>>> 4) ysdl is extensible to cover other non mount related use-cases =
(such
>>> as anydata) where being able to dynamically make available the =
schema is
>>> useful.
>>> 5) structural-mount also covers RPCs and Notifications, whereas =
these
>>> appear to be outside the scope of ysdl.
>> This is just an omission on the part of YSDL. The approach proposed =
for
>> structural-mount can be used as well.
> OK.
>=20
>>=20
>>> 6) The ysdl meta-data language appears to be more flexible, and =
hence
>>> also more complex, than the equivalent "mount-points" schema defined =
in
>>> structural-mount.
>>> 7) For structural-mount the "mount-points" table is returned as a =
normal
>>> oper data YANG module in the mounting device, whereas for ysdl, =
protocol
>>> extensions would be required to NETCONF/RESTCONF to access the =
schema
>>> meta-data.
>> First, structural-mount uses an extension that has to be considered
>> mandatory because otherwise no interoperability can take place. So I
>> don't think that it seamlessly integrates into NETCONF/RESTCONF.
> I think that only clients and devices that need to mount other models =
would need to support it.  Whether this means it becomes mandatory would =
presumable depend on how widely the mount node used in standard YANG =
models.
>=20
>>=20
>> And second, I actually considered to simply extend yang-library with =
the
>> YSDL data, but I decided to keep it separate in order to avoid
>> additional delays for the yang-library spec.
>>=20
>>> Considering these differences:
>>>=20
>>> For points (1) and (2), I can think of scenarios where having a =
mounted
>>> device being able to provide its schema via yang-library and for =
that
>>> schema to differ for different mounted devices is probably a =
requirement
>>> for some plausible mount scenarios.  E.g. one that I can think of is =
the
>>> case that you have a YANG controller that is exposing an aggregated =
YANG
>>> model for a set of devices, it seems that you would need to be
>>> accommodate mounted devices that are made by different vendors and
>>> running different software versions which would imply that their =
schema
>>> may also be different.
>> Right, you would use a (dynamic) choice in this case.
> As per above, I'm not really convinced that this works as a solution.
>=20
>>=20
>>> For point (3), this is a matter of preference, I like that fact that =
the
>>> mount point is explicit in the schema in structural-mount.  The ysdl
>> But this means using a YANG extension with all the problems regarding
>> conformance. And this extension is quite far-reaching.
> I would think that depends on how many models end up needing to mount =
other models.
>=20
> Thanks,
> Rob
>=20
>=20
>>=20
>> Lada
>>=20
>>> meta-schema appears to be more flexible because it can in effect put
>>> mount points anywhere, but even with structural mount this same
>>> flexibility could presumably still be achieved by augmenting with a
>>> mount point.
>>>=20
>>> For point (4), I think that this is useful functionality, and =
perhaps if
>>> structural-mount is to be used as the base draft going forward it =
might
>>> be worth considering whether the solution could be able to cover, or =
be
>>> cleanly extended, to this use case.
>>>=20
>>> For point (5), I definitely think that it is beneficial that
>>> structural-mount has an intuitive solution for RPCs and =
Notifications.
>>>=20
>>> For points (6) and (7) my gut instinct is that the structural-mount
>>> would be easier to standardize and also less work to implement.
>>>=20
>>>=20
>>> Some of my points above may be incorrect, and that might swing the
>>> balance between the two solutions, so please correct me if I have =
got
>>> anything wrong.  Otherwise, just considering the written drafts as =
they
>>> stand now, my personal preference is that I would favour using
>>> structural-mount as a starting point for a solution.
>>>=20
>>> Martin, I also have some comments/questions on the structural-mount
>>> draft, I'll put these into a separate email.
>>>=20
>>> Thanks,
>>> Rob

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





From nobody Fri Jan 22 08:35:47 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F88B1B29AC for ; Fri, 22 Jan 2016 08:35:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXIaHoZcmsf9 for ; Fri, 22 Jan 2016 08:35:44 -0800 (PST)
Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::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 9AC121B29AA for ; Fri, 22 Jan 2016 08:35:43 -0800 (PST)
Received: by mail-lb0-x233.google.com with SMTP id x4so44601641lbm.0 for ; Fri, 22 Jan 2016 08:35: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:date:message-id:subject:from:to :cc:content-type; bh=Jmq79/uyPV0SJp1dhfPTmDiu6BRdEIa3/BChQGjM4po=; b=HkYZlfEDIYOtz2IYNhTQ96keOpylOocWA8ofEg1guJHQ9tqgwsztcQHUxSn1YBnowk 2dDpywncdKbYNyrXW1Mp22vCf3eLTKJF1xNqZb1J+eJQq0Josr/pjUZwQf/MY8+JNSXM xoUzKcXzqHjX+LqXGbkMju1F0M2Jhzr2ellZBaVHvIa8zhc4ppDyte2Rx4Bsli2xjewF 30MrR03gwx2xCdTimu6TTc3SWHQmpshU0vJPQnNX5gFQEJwRLPbTvVQgFeLTufW4vEFR iGtg0QP8U+o47wk7hiOPPmL7QXyb3FkiNMO89vl8Gqp+KqlUNR7j8sktPlfFORj79S4t +6Xw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Jmq79/uyPV0SJp1dhfPTmDiu6BRdEIa3/BChQGjM4po=; b=DHAOCXRiZkOV1OUvqynexrWvz8MYsCGyaPK5MaheRnvBvLtYN/2IqoGqEphv9bWeIa QynkPwS9RCQZ5l1EgdzKPSW/NRrXHSWfe0xvY0WM1SLW87aDS6jgJBKiuys9Oa+SGnMi 3RpzJW4NCvV96Isq//ZbyzGbOFj3vjw2arjRpXQ3zR2W3S8BFRi9kO6ezbmCcl6VSOsI DdrpkQkJwbDNQEdDbD+qWpyb4Ry6A+2StfCPepp/Owt11zLGmS7wmPMrzdT1XrPNp6pl R3FvfBdBYyg9WSVZXFyX0ln1tBJqurVIWEdYxxUBD8c5MQWfSH30q2P0Frf4JDNpZs6Q Pomg==
X-Gm-Message-State: AG10YOS9gVJM2Ry4gX/mc5D2Yoyr8boxKhpqVc9PWXhWftfQG0kh/b2l3Bd7AhQYaVbe65TC5whPywjSTHu7Qw==
MIME-Version: 1.0
X-Received: by 10.112.12.2 with SMTP id u2mr1603059lbb.145.1453480541887; Fri, 22 Jan 2016 08:35:41 -0800 (PST)
Received: by 10.112.200.167 with HTTP; Fri, 22 Jan 2016 08:35:41 -0800 (PST)
In-Reply-To: <20160122.140010.639464305373019422.mbj@tail-f.com>
References:  <56A1E7D8.8030902@ericsson.com>  <20160122.140010.639464305373019422.mbj@tail-f.com>
Date: Fri, 22 Jan 2016 08:35:41 -0800
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=001a11c3f184633fde0529eecf19
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Constraining instance-identifiers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 16:35:46 -0000

--001a11c3f184633fde0529eecf19
Content-Type: text/plain; charset=UTF-8

On Fri, Jan 22, 2016 at 5:00 AM, Martin Bjorklund  wrote:

> Hi,
>
> Andy Bierman  wrote:
> > Hi,
> >
> > I am strongly against adding more features to YANG 1.1 at this time.
>
> Do you refer to the proprietary extension to restrict i-is?  If so, I
> agree (and Balazs just did in a separate email as well) that this is
> out of scope.
>
>
How would such an extension work, given that a tool MAY ignore
this extension? A plain client thinks the instance-identifier can
hold any valid instance, and is surprised that valid values are rejected by
the server (which don't match the magic extension rules)

Use XPath to further restrict the instance, so a plain client can see it.



>
> /martin
>


Andy


>
>
> > The deadline for new features has long passed.
> >
> >
> > Andy
> >
> >
> > On Fri, Jan 22, 2016 at 12:27 AM, Balazs Lengyel <
> > balazs.lengyel@ericsson.com> wrote:
> >
> > > Hello,
> > > I agree we don't need to change the encoding, but we need to define how
> > > that encoding is visible/available when evaluating Xpath expressions.
> Today
> > > the draft says:
> > > - instance-identifier does not have a canonical format
> > > - XPath uses the canonical format
> > > The two together make it impossible to use it in Xpath, even though
> there
> > > are people that would like to do that.
> > > - Martin mentioned a proprietary extension
> > > - we would like it.
> > >
> > > So I would propose to
> > > ---- change to 9.1
> > >
> > > Old: In particular, any XPath expression evaluations are done using
> the canonical form.
> > >
> > > New:  In particular, whenever a canonical form exists, any XPath
> > > expression evaluations are done using the canonical form.
> > >
> > > --- add to 9.13.2
> > >
> > > For instance-identifiers XPath expression evaluations are done using
> the lexical form.
> > >
> > >
> > > regards Balazs
> > >
> > >
> > > On 2016-01-21 18:53, Andy Bierman wrote:
> > >
> > > Hi,
> > >
> > > There is no need to change the XML encoding or YANG encoding
> > > of an instance-identifier.  The prefixes are completely different
> > > in each.  Prefixes clashes do happen, especially since
> > > there is no expectation that they are unique.  They are short strings
> > > with no naming conventions at all.  E.g., I have seen "if" for
> > > interfaces in multiple modules.
> > >
> > > Andy
> > >
> > >
> > > On Thu, Jan 21, 2016 at 8:51 AM, Balazs Lengyel <
> > > balazs.lengyel@ericsson.com> wrote:
> > >
> > >> Hello Martin,
> > >> If the RFC would define that in XPath expressions an instance
> identifier
> > >> MUST be evaluated to a string that complies to the lexical format,
> using
> > >> the rematch function, we could do everything we need. In real life
> prefix
> > >> clashes are a rare problem.
> > >> regards Balazs
> > >>
> > >> On 2016-01-21 16:17, Martin Bjorklund wrote:
> > >>
> > >>> Balazs Lengyel  wrote:
> > >>>
> > >>>> Hello,
> > >>>> We have some instance identifiers in our model but we want to
> > >>>> contrain what they can point at. What is the best method for that?
> > >>>>
> > >>> Unfortunately, there is no standard way of doing this.  (There are
> > >>> vendor extensions available...)
> > >>>
> > >>> [...]
> > >>>
> > >>> Some issues:
> > >>>> - instance-identifiers don't have a canonical format, so what is
> > >>>> their value in an XPath expression?
> > >>>>
> > >>> This is not defined.
> > >>>
> > >>> - I didn't find a way to evaluate a regexp in XPath 1.0. Is there a
> way?
> > >>>>
> > >>> In YANG 1.1, there is a function re-match() for this purpose.  For
> > >>> your use case, it *may* work to match just the local names of all
> > >>> nodes, i.e., using wildcards for the prefixes.  It is not a generic
> > >>> solution though.
> > >>>
> > >>> - if I have all the needed namespace prefixes in imports, can I just
> > >>>>    use them?
> > >>>>
> > >>> No, these prefixes are local to the module that is doing the import,
> > >>> and they may or may not match the prefixes used by the implementation
> > >>> when it construct the instance-identifier value.
> > >>>
> > >>>
> > >>>
> > >>> /martin
> > >>>
> > >>>
> > >> --
> > >> Balazs Lengyel                       Ericsson Hungary Ltd.
> > >> Senior Specialist
> > >> ECN: 831 7320
> > >> Mobile: +36-70-330-7909              email: <
> Balazs.Lengyel@ericsson.com>
> > >> Balazs.Lengyel@ericsson.com
> > >>
> > >> _______________________________________________
> > >> netmod mailing list
> > >> netmod@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/netmod
> > >>
> > >
> > >
> > > --
> > > Balazs Lengyel                       Ericsson Hungary Ltd.
> > > Senior Specialist
> > > ECN: 831 7320
> > > Mobile: +36-70-330-7909              email:
> Balazs.Lengyel@ericsson.com
> > >
> > >
>

--001a11c3f184633fde0529eecf19
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Fri, Jan 22, 2016 at 5:00 AM, Martin Bjorklund <=
;mbj@tail-f.com>=
 wrote:
Hi,



Andy Bierman <andy@yumaworks.com> wrote:

> Hi,

>

> I am strongly against adding more features to YANG 1.1 at this time.


Do you refer to the proprietary extension to restrict i-is?=C2=A0 If so, I<=
br>
agree (and Balazs just did in a separate email as well) that this is

out of scope.





=C2=A0



/martin


Andy
=
=C2=A0





> The deadline for new features has long passed.

>

>

> Andy

>

>

> On Fri, Jan 22, 2016 at 12:27 AM, Balazs Lengyel <

> balazs.lengyel@ericsson=
.com> wrote:

>

> > Hello,

> > I agree we don't need to change the encoding, but we need to =
define how

> > that encoding is visible/available when evaluating Xpath expressi=
ons. Today

> > the draft says:

> > - instance-identifier does not have a canonical format

> > - XPath uses the canonical format

> > The two together make it impossible to use it in Xpath, even thou=
gh there

> > are people that would like to do that.

> > - Martin mentioned a proprietary extension

> > - we would like it.

> >

> > So I would propose to

> > ---- change to 9.1

> >

> > Old: In particular, any XPath expression evaluations are done usi=
ng the canonical form.

> >

> > New:=C2=A0 In particular, whenever a canonical form exists, any X=
Path

> > expression evaluations are done using the canonical form.

> >

> > --- add to 9.13.2

> >

> > For instance-identifiers XPath expression evaluations are done us=
ing the lexical form.

> >

> >

> > regards Balazs

> >

> >

> > On 2016-01-21 18:53, Andy Bierman wrote:

> >

> > Hi,

> >

> > There is no need to change the XML encoding or YANG encoding

> > of an instance-identifier.=C2=A0 The prefixes are completely diff=
erent

> > in each.=C2=A0 Prefixes clashes do happen, especially since

> > there is no expectation that they are unique.=C2=A0 They are shor=
t strings

> > with no naming conventions at all.=C2=A0 E.g., I have seen "=
if" for

> > interfaces in multiple modules.

> >

> > Andy

> >

> >

> > On Thu, Jan 21, 2016 at 8:51 AM, Balazs Lengyel <

> > <balazs.lengyel=
@ericsson.com>balazs.=
lengyel@ericsson.com> wrote:

> >

> >> Hello Martin,

> >> If the RFC would define that in XPath expressions an instance=
 identifier

> >> MUST be evaluated to a string that complies to the lexical fo=
rmat, using

> >> the rematch function, we could do everything we need. In real=
 life prefix

> >> clashes are a rare problem.

> >> regards Balazs

> >>

> >> On 2016-01-21 16:17, Martin Bjorklund wrote:

> >>

> >>> Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:

> >>>

> >>>> Hello,

> >>>> We have some instance identifiers in our model but we=
 want to

> >>>> contrain what they can point at. What is the best met=
hod for that?

> >>>>

> >>> Unfortunately, there is no standard way of doing this.=C2=
=A0 (There are

> >>> vendor extensions available...)

> >>>

> >>> [...]

> >>>

> >>> Some issues:

> >>>> - instance-identifiers don't have a canonical for=
mat, so what is

> >>>> their value in an XPath expression?

> >>>>

> >>> This is not defined.

> >>>

> >>> - I didn't find a way to evaluate a regexp in XPath 1=
.0. Is there a way?

> >>>>

> >>> In YANG 1.1, there is a function re-match() for this purp=
ose.=C2=A0 For

> >>> your use case, it *may* work to match just the local name=
s of all

> >>> nodes, i.e., using wildcards for the prefixes.=C2=A0 It i=
s not a generic

> >>> solution though.

> >>>

> >>> - if I have all the needed namespace prefixes in imports,=
 can I just

> >>>>=C2=A0 =C2=A0 use them?

> >>>>

> >>> No, these prefixes are local to the module that is doing =
the import,

> >>> and they may or may not match the prefixes used by the im=
plementation

> >>> when it construct the instance-identifier value.

> >>>

> >>>

> >>>

> >>> /martin

> >>>

> >>>

> >> --

> >> Balazs Lengyel=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ericsson Hungary Ltd.

> >> Senior Specialist

> >> ECN: 831 7320

> >> Mobile: +36-70-330-7909=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 email: <Balazs=
.Lengyel@ericsson.com>

> >> Balazs.Lengyel=
@ericsson.com

> >>

> >> _______________________________________________

> >> netmod mailing list

> >> netmod@ietf.org

> >> https://www.ietf.org/mailman/listinfo/net=
mod

> >>

> >

> >

> > --

> > Balazs Lengyel=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ericsson Hungary Ltd.

> > Senior Specialist

> > ECN: 831 7320

> > Mobile: +36-70-330-7909=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 email: Balazs.Lengyel=
@ericsson.com

> >

> >





--001a11c3f184633fde0529eecf19--


From nobody Fri Jan 22 08:38:12 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20FE41B29B5 for ; Fri, 22 Jan 2016 08:38:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSOsuM53lD0P for ; Fri, 22 Jan 2016 08:38:11 -0800 (PST)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 635A31B29B3 for ; Fri, 22 Jan 2016 08:38:10 -0800 (PST)
Received: by mail-lf0-x22d.google.com with SMTP id 17so50498141lfz.1 for ; Fri, 22 Jan 2016 08:38: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:date:message-id:subject:from:to :cc:content-type; bh=exOhB9ljpdkUF8U0g2tx/5qt66RENZGdolMKxJpzEPs=; b=SJ9NH696QzSTtJjXwZuhvF+ZhGgGjGOQLp8xHD8CIkwXmF2o6FfMxDKLCbhYVdzmu0 2/7j0lFSsDJjjMiaXw17lJ36SS/wVRdCgr38qO4/yC/h8z/aXSvVVRx9FcIv535LDehp 0/8BVjW8p/zpUJjHkrGzM+9+gO3sk79c3grAW9P4qbrj5Qwqm3ChMjYVsBGjJVrxoKpB 6c6TTVWrdii0Z7Lo9lkJtYfyWbE5ObjOwrFURTskbnhTR40gHQqUDuI8Czl53ef4OwD4 IZ5iAKmbIrVk/q2N5cwB7kbhBOMaQxzPXhYFwWIjD/030GBg3x8GjzMOAWTiaKULhkLH E86g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=exOhB9ljpdkUF8U0g2tx/5qt66RENZGdolMKxJpzEPs=; b=WNyvIiPN5E2ymOiKemItYleEAT0z5eRJ4lOriyohfBkj0Zfa1OibJxEFvrnCQLfxI+ YiOs8qyVUWacThuYRkGhcDsdLoXVSTs25zZk9W9vjaAkOvMLatkvS6bL3UIoBkcGyWw/ pjfmPYcxmMV3TWPRnzoYUu8lH6gsyn+rT6u4YTZdWdn0S49LQgVEyov9NbAhZwjxcPZv QESyBAARBQhCjookiVaZgBs73o+4OVHaalAqfflsdlO28BDKQ3DhwmJEisiT4W05iy5S 3hdirdWv0ZCNoQhxMfnhsE5RvK3KY15E+x1b8gfvDh/4nNS6+Kd2IuyXFDLSkrKbXnLI wlGQ==
X-Gm-Message-State: AG10YOT1B9U1g2OKftX3j6R1EW6zGf1Mjlk82DhwSS1BGFyxRcUbHVia3ZFg5Pn08N/ttQgkmhMqaeJT/XSgQQ==
MIME-Version: 1.0
X-Received: by 10.25.39.134 with SMTP id n128mr1709941lfn.54.1453480688666; Fri, 22 Jan 2016 08:38:08 -0800 (PST)
Received: by 10.112.200.167 with HTTP; Fri, 22 Jan 2016 08:38:08 -0800 (PST)
In-Reply-To: <8B543BAE-B439-4A64-8FA1-DE24EB1FDB46@broadband-forum.org>
References: <2431FE7A-9CC9-48A6-92FF-AE383DB71394@broadband-forum.org>   <8B543BAE-B439-4A64-8FA1-DE24EB1FDB46@broadband-forum.org>
Date: Fri, 22 Jan 2016 08:38:08 -0800
Message-ID: 
From: Andy Bierman 
To: William Lupton 
Content-Type: multipart/alternative; boundary=001a1141047022e91e0529eed833
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Broadband Forum questions on RFC 6087bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 16:38:12 -0000

--001a1141047022e91e0529eed833
Content-Type: text/plain; charset=UTF-8

Hi,

The changed submodule name looks like
a new name and the old submodule was deleted.
How does a tool determine it is some old submodule
but the name was changed?

Andy




On Fri, Jan 22, 2016 at 6:33 AM, William Lupton  wrote:

> Thanks for the responses. One clarification below on what is definitely a
> minor point!
>
> On 22 Jan 2016, at 00:18, Andy Bierman  wrote:
> On Wed, Jan 20, 2016 at 6:45 AM, William Lupton <
> wlupton@broadband-forum.org> wrote:
>>
>> > 2. Rules re changing submodule names
>> >
>> > Section 5.7 (Lifecycle Management) says that "The [...] submodule name
>> MUST NOT be changed, once the document containing the module or submodule
>> is published" but this might contradict RFC 6020 Section 11, which says "A
>> module may be split into a set of submodules, or a submodule may be
>> removed...".
>> >
>> > More specifically, 6020 doesn't mention renaming a submodule (so
>> presumably that's not permitted), but the mention of both splitting modules
>> into submodules AND removing submodules suggests that arbitrary
>> module/submodule refactoring is permitted. And if I'm being pedantic,
>> revision #1 could have submodule A1, revision #2 could remove it, and
>> revision #3 could reintroduce it as submodule A2, so that's effectively a
>> rename!
>>
>
> I do not see any issue here.
> Moving an object does not change the submodule name.
>
>
> My point was to question why renaming submodules is forbidden when in fact
> it seems that submodule rename can be achieved via other means. It's not
> that I actually want to do it, just that 6087 and 6020 don't seem quite
> consistent on this topic.
>
> William
>

--001a1141047022e91e0529eed833
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

The changed submodule name looks li=
ke
a new name and the old submodule was deleted.
How do=
es a tool determine it is some old submodule
but the name was cha=
nged?

Andy




=
On Fri, Jan 22, 2016 at 6:33 AM, William Lupton <wlupton@broadba=
nd-forum.org> wrote:
Thanks for the responses. One clarification b=
elow on what is definitely a minor point!

On 22 Jan 2016, at 00:18, Andy Bierman <andy@yumaworks.com> wrote:
<=
div>
=
On Wed, Jan 20, 2016 at 6:45 AM, William Lupton <wlupton@broadba=
nd-forum.org> wrote:

> 2. Rules re changing submodule names

>

> Section 5.7 (Lifecycle Management) says that "The [...] submodule=
 name MUST NOT be changed, once the document containing the module or submo=
dule is published" but this might contradict RFC 6020 Section 11, whic=
h says "A module may be split into a set of submodules, or a submodule=
 may be removed...".

>

> More specifically, 6020 doesn't mention renaming a submodule (so p=
resumably that's not permitted), but the mention of both splitting modu=
les into submodules AND removing submodules suggests that arbitrary module/=
submodule refactoring is permitted. And if I'm being pedantic, revision=
 #1 could have submodule A1, revision #2 could remove it, and revision #3 c=
ould reintroduce it as submodule A2, so that's effectively a rename!

I do not see any issue here.
Mo=
ving an object does not change the submodule name.
<=
/div>

My point was to question why renaming=
 submodules is forbidden when in fact it seems that submodule rename can be=
 achieved via other means. It's not that I actually want to do it, just=
 that 6087 and 6020 don't seem quite consistent on this topic.

William



--001a1141047022e91e0529eed833--


From nobody Fri Jan 22 09:16:33 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8BD1B2A73 for ; Fri, 22 Jan 2016 09:16:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZO300Yqs_nGv for ; Fri, 22 Jan 2016 09:16:23 -0800 (PST)
Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id 47C891B2A61 for ; Fri, 22 Jan 2016 09:16:23 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id CC1BB1E5A36; Fri, 22 Jan 2016 09:15:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id hUW9PnKxyunz; Fri, 22 Jan 2016 09:15:34 -0800 (PST)
Received: from [192.168.1.129] (host86-133-254-101.range86-133.btcentralplus.com [86.133.254.101]) by c8a.amsl.com (Postfix) with ESMTPSA id F11AB1E5A30; Fri, 22 Jan 2016 09:15:33 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_41118CA7-B8CA-4250-A765-451F61371819"
From: William Lupton 
In-Reply-To: 
Date: Fri, 22 Jan 2016 17:16:20 +0000
Message-Id: <76D4240B-8D84-47A2-B10E-FBFD82B9F964@broadband-forum.org>
References: <2431FE7A-9CC9-48A6-92FF-AE383DB71394@broadband-forum.org>   <8B543BAE-B439-4A64-8FA1-DE24EB1FDB46@broadband-forum.org> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Broadband Forum questions on RFC 6087bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 17:16:25 -0000

--Apple-Mail=_41118CA7-B8CA-4250-A765-451F61371819
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

It probably wouldn't (unless the tool implements an algorithm similar to =
the Git algorithm that detects "move" rather than "delete" + "add"). But =
given that you could delete it in one revision and then add it back with =
a different name in a subsequent revision should it really be forbidden? =
As I said... a minor point! W.

> On 22 Jan 2016, at 16:38, Andy Bierman  wrote:
>=20
> Hi,
>=20
> The changed submodule name looks like
> a new name and the old submodule was deleted.
> How does a tool determine it is some old submodule
> but the name was changed?
>=20
> Andy
>=20
>=20
>=20
>=20
> On Fri, Jan 22, 2016 at 6:33 AM, William Lupton =
> =
wrote:
> Thanks for the responses. One clarification below on what is =
definitely a minor point!
>=20
>> On 22 Jan 2016, at 00:18, Andy Bierman > wrote:
>> On Wed, Jan 20, 2016 at 6:45 AM, William Lupton =
> =
wrote:
>> > 2. Rules re changing submodule names
>> >
>> > Section 5.7 (Lifecycle Management) says that "The [...] submodule =
name MUST NOT be changed, once the document containing the module or =
submodule is published" but this might contradict RFC 6020 Section 11, =
which says "A module may be split into a set of submodules, or a =
submodule may be removed...".
>> >
>> > More specifically, 6020 doesn't mention renaming a submodule (so =
presumably that's not permitted), but the mention of both splitting =
modules into submodules AND removing submodules suggests that arbitrary =
module/submodule refactoring is permitted. And if I'm being pedantic, =
revision #1 could have submodule A1, revision #2 could remove it, and =
revision #3 could reintroduce it as submodule A2, so that's effectively =
a rename!
>>=20
>> I do not see any issue here.
>> Moving an object does not change the submodule name.
>=20
> My point was to question why renaming submodules is forbidden when in =
fact it seems that submodule rename can be achieved via other means. =
It's not that I actually want to do it, just that 6087 and 6020 don't =
seem quite consistent on this topic.
>=20
> William
>=20


--Apple-Mail=_41118CA7-B8CA-4250-A765-451F61371819
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

It probably wouldn't (unless the tool implements an algorithm =
similar to the Git algorithm that detects "move" rather than "delete" + =
"add"). But given that you could delete it in one revision and then add =
it back with a different name in a subsequent revision should it really =
be forbidden? As I said... a minor point! W.

On =
22 Jan 2016, at 16:38, Andy Bierman <andy@yumaworks.com> =
wrote:

Hi,

The changed submodule name looks like
a =
new name and the old submodule was deleted.
How =
does a tool determine it is some old submodule
but =
the name was changed?

Andy




On Fri, Jan 22, 2016 at 6:33 AM, William Lupton =
<wlupton@broadband-forum.org> wrote:
Thanks for the responses. One =
clarification below on what is definitely a minor point!

On 22 Jan 2016, at 00:18, Andy Bierman <andy@yumaworks.com> wrote:
On Wed, Jan 20, 2016 at 6:45 AM, William Lupton =
<wlupton@broadband-forum.org> wrote:

> 2. Rules re changing submodule names

>

> Section 5.7 (Lifecycle Management) says that "The [...] submodule =
name MUST NOT be changed, once the document containing the module or =
submodule is published" but this might contradict RFC 6020 Section 11, =
which says "A module may be split into a set of submodules, or a =
submodule may be removed...".

>

> More specifically, 6020 doesn't mention renaming a submodule (so =
presumably that's not permitted), but the mention of both splitting =
modules into submodules AND removing submodules suggests that arbitrary =
module/submodule refactoring is permitted. And if I'm being pedantic, =
revision #1 could have submodule A1, revision #2 could remove it, and =
revision #3 could reintroduce it as submodule A2, so that's effectively =
a rename!

I do not see any issue here.
Moving an object does not change the submodule =
name.

My point was to question why renaming =
submodules is forbidden when in fact it seems that submodule rename can =
be achieved via other means. It's not that I actually want to do it, =
just that 6087 and 6020 don't seem quite consistent on this =
topic.

William




=

--Apple-Mail=_41118CA7-B8CA-4250-A765-451F61371819--


From nobody Fri Jan 22 09:18:46 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D231B2A81 for ; Fri, 22 Jan 2016 09:18:45 -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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PazIfH3d0v1z for ; Fri, 22 Jan 2016 09:18:41 -0800 (PST)
Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1900:3001:11::28]) by ietfa.amsl.com (Postfix) with ESMTP id A98A41B2A79 for ; Fri, 22 Jan 2016 09:18:41 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 3784A1E5A36; Fri, 22 Jan 2016 09:17:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Kw1Gk7sOb5rm; Fri, 22 Jan 2016 09:17:53 -0800 (PST)
Received: from [192.168.1.129] (host86-133-254-101.range86-133.btcentralplus.com [86.133.254.101]) by c8a.amsl.com (Postfix) with ESMTPSA id 32B7A1E5A30; Fri, 22 Jan 2016 09:17:52 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_3B6C4EDB-058A-4D5B-B5D9-E119728EED22"
From: William Lupton 
In-Reply-To: 
Date: Fri, 22 Jan 2016 17:18:38 +0000
Message-Id: <8112CC17-AA20-43CB-9870-1902F26BCC7E@broadband-forum.org>
References:  
To: Ladislav Lhotka 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Validation question
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 17:18:45 -0000

--Apple-Mail=_3B6C4EDB-058A-4D5B-B5D9-E119728EED22
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Lada,

Thanks for drawing my attention to this section. I hadn't noticed this =
advice.

Perhaps corresponding things need to be said about the XML?
Always use a prefix on identity values, even if the default namespace =
(YANG module) is the module that defined the identity.
When importing a namespace (YANG module) that contains identities that =
are referenced in the XML, always use the same prefix that was used =
within the imported module.

The need for the first of the above XML-related statements wasn't =
illustrated by the YANG and XML in my first message but it's illustrated =
by the fragments shown below.

I guess the point about derived-from() and derived-from-or-self() is =
that, although they still specify the identities as strings, the strings =
are known to be identities, so prefixes can be processed (applying =
defaults etc)?

Finally, I think perhaps this is a separate point (because not related =
to string values), but seems to be necessary to use the same prefixes =
for imported modules as were used within those modules. For example, if =
(in my example) I change the ietf-interfaces prefix from if to ifx, =
validation fails with an "undefined namespace prefix" error.

Cheers,
William

YANG fragment:
  identity sub-type;

  identity sub-type-a {
    base sub-type;
  }

  augment "/if:interfaces/if:interface" {
    when "if:type =3D 'mymod:some-new-iftype'";

    container some-new-container {
      leaf sub-type {
        type identityref {
          base sub-type;
        }
      }
      container sub-container {
        when "../mymod:sub-type =3D 'mymod:sub-type-a'";
      }
    }
  }

XML fragment (mymod prefix is necessary in order for XML to validate):
      
	mymod:sub-type-a
	
      

> On 22 Jan 2016, at 09:32, Ladislav Lhotka  wrote:
>=20
> Hi William,
>=20
> YANG uses XPath 1.0, and so the equality tests mean *string
> equality*. That's why 6087bis recommends in sec. 5.6.4:
>=20
>   XPath expressions that contain a literal value representing a YANG
>   identity SHOULD always include the declared prefix of the module
>   where the identity is defined.
>=20
> In YANG 1.1, the new XPath functions derived-from() and
> derived-from-or-self() will alleviate this problem.
>=20
> Lada
>=20
> William Lupton  writes:
>=20
>> All,
>>=20
>> We have been experimenting with validating XML instances along the =
lines explained in the tutorials at =
http://www.yang-central.org/twiki/bin/view/Main/DSDLMappingTutorial =
 =
and https://github.com/mbj4668/pyang/wiki/InstanceValidation =
 and we have =
hit a problem with identities in XPath expressions.
>>=20
>> This is illustrated by the YANG module shown below, which is inspired =
by an example in RFC 6020bis, and the XML instance shown below the YANG. =
Note that:
>> The second "when" statement doesn't use a prefix on the interface =
type.
>> Shouldn't be a problem because the interface type is defined in the =
current module and so doesn't need a prefix?
>> The XML uses a prefix name of "exaug" rather than "mymod" which is =
used in the YANG.
>> Shouldn't be a problem because prefixes should be local?
>>=20
>> Validating this instance gives the following two errors (which go =
away if the prefix "mymod" is used in all "when" statements and in the =
XML).
>>=20
>> =3D=3D Validating semantic constraints ...
>> --- Validity error at "/nc:data/if:interfaces/if:interface":
>>    Found nodes that are valid only when "if:type =3D =
'mymod:some-new-iftype'"
>> --- Validity error at "/nc:data/if:interfaces-state/if:interface":
>>    Found nodes that are valid only when "if:type =3D =
'some-new-iftype'"
>>=20
>> Are we doing something wrong here, or is there a problem with how =
identities in XPath expressions are translated (per RFC 6110)? On the =
face of it it seems that identities are being treated as literal strings =
(but we haven't investigated this assertion).
>>=20
>> Thanks,
>> William Lupton
>>=20
>> --------
>>=20
>> YANG:
>> module example-augment {
>>  namespace "http://example.com/augment";
>>  prefix mymod;
>>=20
>>  import ietf-interfaces {
>>    prefix if;
>>  }
>>=20
>>  identity some-new-iftype {
>>    base if:interface-type;
>>  }
>>=20
>>  augment "/if:interfaces/if:interface" {
>>    when "if:type =3D 'mymod:some-new-iftype'";
>>=20
>>    container some-new-container {
>>    }
>>  }
>>=20
>>  augment "/if:interfaces-state/if:interface" {
>>    when "if:type =3D 'some-new-iftype'";
>>=20
>>    container some-new-container {
>>    }
>>  }
>> }
>>=20
>> XML:
>> 
>> >  xmlns:exaug=3D"http://example.com/augment">
>>  
>>    
>>      
>>      
>>      exaug:some-new-iftype
>>      true
>>      enabled
>>      
>>      
>>    
>>  
>>  
>>    
>>      
>>      exaug:some-new-iftype
>>      up
>>      up
>>      1
>>      
>>        2016-01-15T12:55:00Z
>>      
>>      
>>      
>>    
>>  
>> 
>>=20
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>=20
> --=20
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20


--Apple-Mail=_3B6C4EDB-058A-4D5B-B5D9-E119728EED22
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Lada,

Thanks for drawing my =
attention to this section. I hadn't noticed this advice.

Perhaps corresponding =
things need to be said about the XML?
  • Always use a prefix on identity =
values, even if the default namespace (YANG module) is the module that =
defined the identity.
  • When importing a namespace =
(YANG module) that contains identities that are referenced in the XML, =
always use the same prefix that was used within the imported =
module.

The need for the first of the above XML-related statements =
wasn't illustrated by the YANG and XML in my first message but it's =
illustrated by the fragments shown below.

I guess the point about derived-from() =
and derived-from-or-self() is that, although they still specify the =
identities as strings, the strings are known to be identities, so =
prefixes can be processed (applying defaults etc)?

Finally, I think perhaps =
this is a separate point (because not related to string values), but =
seems to be necessary to use the same prefixes for imported modules as =
were used within those modules. For example, if (in my example) I change =
the ietf-interfaces prefix from if to ifx, validation fails with an =
"undefined namespace prefix" error.

Cheers,
William

YANG fragment:
  identity sub-type;

  =
identity sub-type-a {
    base sub-type;
  }

  augment =
"/if:interfaces/if:interface" {
    when "if:type =3D =
'mymod:some-new-iftype'";

    container =
some-new-container {
      leaf sub-type {
        type =
identityref {
          base sub-type;
      =
  }
  =
    }
      container sub-container {
      =
  when "../mymod:sub-type =3D 'mymod:sub-type-a'";
      =
}
    =
}
  =
}

XML =
fragment (mymod prefix is necessary in order for XML to =
validate):
      <some-new-container xmlns=3D"http://example.com/augment">
	=
<sub-type>mymod:sub-type-a</sub-type>
	=
<sub-container/>
      =
</some-new-container>

On 22 Jan 2016, at =
09:32, Ladislav Lhotka <lhotka@nic.cz> wrote:

Hi =
William,

YANG uses XPath 1.0, and so the =
equality tests mean *string
equality*. That's why 6087bis =
recommends in sec. 5.6.4:

  XPath =
expressions that contain a literal value representing a YANG
  identity SHOULD always include the declared prefix of =
the module
  where the identity is defined.

In YANG 1.1, the new XPath functions =
derived-from() and
derived-from-or-self() will alleviate =
this problem.

Lada

William Lupton <wlupton@broadband-forum.org> writes:

All,

We have been experimenting with validating XML instances =
along the lines explained in the tutorials at http://www.yang-central.org/twiki/bin/view/Main/DSDLMappingTutorial =
<http://www.yang-central.org/twiki/bin/view/Main/DSDLMappingTuto=
rial> and https://github.com/mbj4668/pyang/wiki/InstanceValidation =
<https://github.com/mbj4668/pyang/wiki/InstanceValidation>=
; and we have hit a problem with identities in =
XPath expressions.

This is illustrated =
by the YANG module shown below, which is inspired by an example in RFC =
6020bis, and the XML instance shown below the YANG. Note that:
The second "when" statement doesn't use a prefix on the =
interface type.
Shouldn't be a problem because the =
interface type is defined in the current module and so doesn't need a =
prefix?
The XML uses a prefix name of "exaug" rather than =
"mymod" which is used in the YANG.
Shouldn't be a problem =
because prefixes should be local?

Validating =
this instance gives the following two errors (which go away if the =
prefix "mymod" is used in all "when" statements and in the XML).

=3D=3D Validating semantic constraints ...
--- Validity error at =
"/nc:data/if:interfaces/if:interface":
   Found =
nodes that are valid only when "if:type =3D 'mymod:some-new-iftype'"
--- Validity error at =
"/nc:data/if:interfaces-state/if:interface":
  =
 Found nodes that are valid only when "if:type =3D =
'some-new-iftype'"

Are we doing something =
wrong here, or is there a problem with how identities in XPath =
expressions are translated (per RFC 6110)? On the face of it it seems =
that identities are being treated as literal strings (but we =
haven't investigated this assertion).

Thanks,
William Lupton

--------

YANG:
module example-augment {
 namespace "http://example.com/augment";
 prefix =
mymod;

 import ietf-interfaces {
   prefix if;
 }
 identity some-new-iftype {
  =
 base if:interface-type;
 }

 augment "/if:interfaces/if:interface" {
   when "if:type =3D 'mymod:some-new-iftype'";

   container some-new-container {
   }
 }

 augment "/if:interfaces-state/if:interface" {
   when "if:type =3D 'some-new-iftype'";

   container some-new-container {
   }
 }
}

XML:
<?xml version=3D"1.0" =
encoding=3D"UTF-8"?>
<data =
xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"
 xmlns:exaug=3D"http://example.com/augment">
 <interfaces =
xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-interfaces">
   <interface>
    =
 <name/>
    =
 <description/>
    =
 <type>exaug:some-new-iftype</type>
  =
   <enabled>true</enabled>
  =
  =
 <link-up-down-trap-enable>enabled</link-up-down-trap-enable=
>
     <some-new-container xmlns=3D"http://example.com/augment">
  =
   </some-new-container>
  =
 </interface>
 </interfaces>
 <interfaces-state =
xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-interfaces">
   <interface>
    =
 <name/>
    =
 <type>exaug:some-new-iftype</type>
  =
   <admin-status>up</admin-status>
    =
 <oper-status>up</oper-status>
  =
   <if-index>1</if-index>
  =
   <statistics>
      =
 <discontinuity-time>2016-01-15T12:55:00Z</discontinuity-tim=
e>
     </statistics>
     <some-new-container xmlns=3D"http://example.com/augment">
  =
   </some-new-container>
  =
 </interface>
 </interfaces-state>
</data>


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

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


=

--Apple-Mail=_3B6C4EDB-058A-4D5B-B5D9-E119728EED22--


From nobody Fri Jan 22 09:39:25 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A066B1B2AE2 for ; Fri, 22 Jan 2016 09:39:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8jst3SQzef1 for ; Fri, 22 Jan 2016 09:39:21 -0800 (PST)
Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::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 488161B2AE3 for ; Fri, 22 Jan 2016 09:39:21 -0800 (PST)
Received: by mail-lb0-x22f.google.com with SMTP id x4so45605521lbm.0 for ; Fri, 22 Jan 2016 09:39:21 -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:date:message-id:subject:from:to :cc:content-type; bh=Ww69D3ymiETn2XEx6NPUOCma1qiTHzLZJftxxLY4n1k=; b=mksU9MGtc86Xxyh5OuiC5HAt626GtL1UX8PssIcyFSEQ/2KcLbOpS/xWWUtSlS74pW Cc21ZFFWqmGIriPkX7wSiYNyaKN7UPrfhVtA5Seb3OEKY77WtlXHxvBIruoN5hFKQKhw yMzs6C4f5pr1auBFI9pYKxdo92d+UQyZOOh6wQP6G2FUpTqMS7Ul8qjIbKsEAA/qnVX1 E4o/ZfzTA/+ALNvLuqstmIW6QI3t5m5RvA4s1PoBG28CPLs6RJkc4+McWkwmaV9vbhjG rvdAXfuhfyJ+O7sK5QIeLM4GCCktUjytLZ23eKpAgRBb9jh+ibTtZuSjg1iLgWUgrR/F 1Gjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ww69D3ymiETn2XEx6NPUOCma1qiTHzLZJftxxLY4n1k=; b=eHlHn7HJZjXji2FNu+6UINyh2c9Mc8ESEJ/0/4eh5Wa/uq4/Qe2YXVoM9X6mlkpLdk MpzdiVzJwsTDo5uQhdiMhc+N2/lU9t6CrteIMfab07t14BX+9Ouza3xfEaFuKKEZT8ja DW8RDpzuJA+RqyWY3d+CkBw/F5C5wZlIgKHflLLYk+/7CyfQyjTc+nrH0r1ApIkiSufR fZPAYR+PwqVOVP8iypHTw579VOspR/VAUtLX0M40tNb74ZhsYuSsvoVWdaR7KZjFlJ+B L9zBroAJojqSNDfeNdJm4XVjtf6ASiP+PODseqw09O42vuvILbzEuSex2WPL3tM7znLq apKg==
X-Gm-Message-State: AG10YOSHT0quAp4SGiLfoOgHfoyqo+h6XE8jBXz72SnsYSUGDtZ2+oN5gnubdgJDzfXRO3fHB41D125GCSwktA==
MIME-Version: 1.0
X-Received: by 10.112.130.133 with SMTP id oe5mr1417701lbb.94.1453484359481; Fri, 22 Jan 2016 09:39:19 -0800 (PST)
Received: by 10.112.200.167 with HTTP; Fri, 22 Jan 2016 09:39:19 -0800 (PST)
In-Reply-To: <76D4240B-8D84-47A2-B10E-FBFD82B9F964@broadband-forum.org>
References: <2431FE7A-9CC9-48A6-92FF-AE383DB71394@broadband-forum.org>   <8B543BAE-B439-4A64-8FA1-DE24EB1FDB46@broadband-forum.org>  <76D4240B-8D84-47A2-B10E-FBFD82B9F964@broadband-forum.org>
Date: Fri, 22 Jan 2016 09:39:19 -0800
Message-ID: 
From: Andy Bierman 
To: William Lupton 
Content-Type: multipart/alternative; boundary=047d7b3a8838ef17650529efb277
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Broadband Forum questions on RFC 6087bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 17:39:23 -0000

--047d7b3a8838ef17650529efb277
Content-Type: text/plain; charset=UTF-8

Hi,

I never liked submodules. IMO just more IETF over-engineering.
They have always confused customers into thinking they
are just modules within modules. Wrong.  They merely partition YANG
modules into multiple syntactic bundles.  There is only 1 module namespace.

Actually I think it doesn't matter if the submodule name changes, so I
should
remove the text in question.  One can remove all the submodules from
rev N to N+1 if they want, and add different names back (as you pointed
out).
If it doesn't change the module namespace contents it's OK.


Andy



On Fri, Jan 22, 2016 at 9:16 AM, William Lupton  wrote:

> It probably wouldn't (unless the tool implements an algorithm similar to
> the Git algorithm that detects "move" rather than "delete" + "add"). But
> given that you could delete it in one revision and then add it back with a
> different name in a subsequent revision should it really be forbidden? As I
> said... a minor point! W.
>
> On 22 Jan 2016, at 16:38, Andy Bierman  wrote:
>
> Hi,
>
> The changed submodule name looks like
> a new name and the old submodule was deleted.
> How does a tool determine it is some old submodule
> but the name was changed?
>
> Andy
>
>
>
>
> On Fri, Jan 22, 2016 at 6:33 AM, William Lupton <
> wlupton@broadband-forum.org> wrote:
>
>> Thanks for the responses. One clarification below on what is definitely a
>> minor point!
>>
>> On 22 Jan 2016, at 00:18, Andy Bierman  wrote:
>> On Wed, Jan 20, 2016 at 6:45 AM, William Lupton <
>> wlupton@broadband-forum.org> wrote:
>>>
>>> > 2. Rules re changing submodule names
>>> >
>>> > Section 5.7 (Lifecycle Management) says that "The [...] submodule name
>>> MUST NOT be changed, once the document containing the module or submodule
>>> is published" but this might contradict RFC 6020 Section 11, which says "A
>>> module may be split into a set of submodules, or a submodule may be
>>> removed...".
>>> >
>>> > More specifically, 6020 doesn't mention renaming a submodule (so
>>> presumably that's not permitted), but the mention of both splitting modules
>>> into submodules AND removing submodules suggests that arbitrary
>>> module/submodule refactoring is permitted. And if I'm being pedantic,
>>> revision #1 could have submodule A1, revision #2 could remove it, and
>>> revision #3 could reintroduce it as submodule A2, so that's effectively a
>>> rename!
>>>
>>
>> I do not see any issue here.
>> Moving an object does not change the submodule name.
>>
>>
>> My point was to question why renaming submodules is forbidden when in
>> fact it seems that submodule rename can be achieved via other means. It's
>> not that I actually want to do it, just that 6087 and 6020 don't seem quite
>> consistent on this topic.
>>
>> William
>>
>
>
>

--047d7b3a8838ef17650529efb277
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

I never liked submodules. IMO just =
more IETF over-engineering.
They have always confused customers i=
nto thinking they
are just modules within modules. Wrong.=C2=A0 T=
hey merely partition YANG
modules into multiple syntactic bundles=
.=C2=A0 There is only 1 module namespace.

Actually=
 I think it doesn't matter if the submodule name changes, so I should
remove the text in question.=C2=A0 One can remove all the submodul=
es from
rev N to N+1 if they want, and add different names back (=
as you pointed out).
If it doesn't change the module namespac=
e contents it's OK.


Andy
<=
div>


On Fri, Jan 22, 2016 at 9:16 AM, William Lupton <wlupton@broadband-forum.org> wrote:
It probably wouldn't =
(unless the tool implements an algorithm similar to the Git algorithm that =
detects "move" rather than "delete" + "add").=
 But given that you could delete it in one revision and then add it back wi=
th a different name in a subsequent revision should it really be forbidden?=
 As I said... a minor point! W.

On 22 Jan 2016, at 16:38, Andy Bierman <andy@yumaworks.com> wrote:

Hi,

The changed submodule name looks like=

a new name and the old submodule was deleted.
How does=
 a tool determine it is some old submodule
but the name was chang=
ed?

Andy


<=
br>

On=
 Fri, Jan 22, 2016 at 6:33 AM, William Lupton <wlupton@broadband=
-forum.org> wrote:
Thanks for the responses. One clarification bel=
ow on what is definitely a minor point!

On 22 Jan 2016, at 00:18, Andy Bierman <andy@yumaworks.com> wrote:
On=
 Wed, Jan 20, 2016 at 6:45 AM, William Lupton <wlupton@broadband=
-forum.org> wrote:

> 2. Rules re changing submodule names

>

> Section 5.7 (Lifecycle Management) says that "The [...] submodule=
 name MUST NOT be changed, once the document containing the module or submo=
dule is published" but this might contradict RFC 6020 Section 11, whic=
h says "A module may be split into a set of submodules, or a submodule=
 may be removed...".

>

> More specifically, 6020 doesn't mention renaming a submodule (so p=
resumably that's not permitted), but the mention of both splitting modu=
les into submodules AND removing submodules suggests that arbitrary module/=
submodule refactoring is permitted. And if I'm being pedantic, revision=
 #1 could have submodule A1, revision #2 could remove it, and revision #3 c=
ould reintroduce it as submodule A2, so that's effectively a rename!

I do not see any issue here.
Mo=
ving an object does not change the submodule name.
<=
/div>

My point was to question why renaming=
 submodules is forbidden when in fact it seems that submodule rename can be=
 achieved via other means. It's not that I actually want to do it, just=
 that 6087 and 6020 don't seem quite consistent on this topic.

William
<=
/div>







--047d7b3a8838ef17650529efb277--


From nobody Fri Jan 22 10:41:04 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15BA31B2BCB for ; Fri, 22 Jan 2016 10:41:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuZ3lgmMhvPZ for ; Fri, 22 Jan 2016 10:41:01 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 649CC1B2BC4 for ; Fri, 22 Jan 2016 10:41:01 -0800 (PST)
Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id 204A71AE035C; Fri, 22 Jan 2016 19:41:00 +0100 (CET)
Date: Fri, 22 Jan 2016 19:42:07 +0100 (CET)
Message-Id: <20160122.194207.1831371690150287740.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund 
In-Reply-To: 
References:  <20160122.140010.639464305373019422.mbj@tail-f.com> 
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Constraining instance-identifiers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 18:41:03 -0000

Andy Bierman  wrote:
> On Fri, Jan 22, 2016 at 5:00 AM, Martin Bjorklund  wrote:
> 
> > Hi,
> >
> > Andy Bierman  wrote:
> > > Hi,
> > >
> > > I am strongly against adding more features to YANG 1.1 at this time.
> >
> > Do you refer to the proprietary extension to restrict i-is?  If so, I
> > agree (and Balazs just did in a separate email as well) that this is
> > out of scope.
> >
> >
> How would such an extension work, given that a tool MAY ignore
> this extension? A plain client thinks the instance-identifier can
> hold any valid instance, and is surprised that valid values are rejected by
> the server (which don't match the magic extension rules)

The additional validation rule is (hopefully) specified in the
description.  The extension just tells the implementation to do the
validation automatically; the alternative is for the user to write
custom code.

> Use XPath to further restrict the instance, so a plain client can see it.

How?  (note how Balazs' "hack" uses a normal "must" statement).


/martin


From nobody Fri Jan 22 11:18:27 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D451B2C76 for ; Fri, 22 Jan 2016 11:18:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voSua5gHDnNH for ; Fri, 22 Jan 2016 11:18:25 -0800 (PST)
Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::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 A116C1B2C60 for ; Fri, 22 Jan 2016 11:18:24 -0800 (PST)
Received: by mail-lb0-x232.google.com with SMTP id oh2so46480226lbb.3 for ; Fri, 22 Jan 2016 11:18: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:date:message-id:subject:from:to :cc:content-type; bh=iRUygvcqqmsH+yODuAyrFIvtLCoUgh9Bxkm+CM1uOCQ=; b=q1vjjviwf2a3TfIbFDnmDaNCRmGYtqUr2/8Rum71o9UoiQ0TGbms2qJ9dOaJSWHfuA CEW52jcV2uEjjpygeQrfQ8JjVR856S16AQuT1AmEIgRmRtwTeYbm+CtYjnsZXrFyB2cS CNPvkXMTO9vh2+m9EULnh4LH78MkHhOzdDFwLqqitvS67YuZQY8lyCq69ZBKO2oEeZEy d6N9kIkGxlcPEFz6nn8tugZHWYhpSYX/3JYMppsWjFslCyWFj7xq6zwDqmlDJ9nXb43b 6DlFXlEOcCUrGFZ0JlkKXCK+2YefTCETuMmbkipFeUyK5/djw5FlPXHKeRkt/9tnfZZ2 xg/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=iRUygvcqqmsH+yODuAyrFIvtLCoUgh9Bxkm+CM1uOCQ=; b=Lief4UX8wHswczGjRKMiDTcZpG71gIV2dVJlGzbG8tgSZRI0Zg3I1K9f5lFTFzJ5np b/6vph8MFNVqmI9EqKziCufLrsLzlVkzUQsP26G48EsrCQYEfJF52ZtEMX9GYJDnuQdF WhMVrrJ9PAr0WtPKrhzkgFz9iIKT4xmMXe5G67JfFO0g8ZFikKZn/mxsZNINLdU49Nwe /VeSZznXZgkrztZz3gthpetFBzcDoK1j7sZUXDCXaYIbETDR49mwUgTJ0yajFwPgUa3g i4yIUeSxnf/S7aWXe2wcWEkn7a8dRm36YgOVDX4jlTgIOGA6GHLshfDXkQt/ua1cYEVA 4jEQ==
X-Gm-Message-State: AG10YORlonChSNs2v+DShEP9K8eU3Te5KHfNPBiZITDZm0Y9De0yyFQhmrzCE/pp/2eUnQvvFn//WE625A8hBg==
MIME-Version: 1.0
X-Received: by 10.112.180.7 with SMTP id dk7mr1874075lbc.65.1453490302815; Fri, 22 Jan 2016 11:18:22 -0800 (PST)
Received: by 10.112.200.167 with HTTP; Fri, 22 Jan 2016 11:18:22 -0800 (PST)
In-Reply-To: <20160122.194207.1831371690150287740.mbj@tail-f.com>
References:  <20160122.140010.639464305373019422.mbj@tail-f.com>  <20160122.194207.1831371690150287740.mbj@tail-f.com>
Date: Fri, 22 Jan 2016 11:18:22 -0800
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=089e0112cad02f2b840529f11511
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Constraining instance-identifiers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 19:18:26 -0000

--089e0112cad02f2b840529f11511
Content-Type: text/plain; charset=UTF-8

Hi,

The description-stmt is good enough.
Let's stop the feature-creep and get YANG 1.1 done.
Just keep using your proprietary extensions that tells
your proprietary tools how to special process the i-i value.


Andy


On Fri, Jan 22, 2016 at 10:42 AM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > On Fri, Jan 22, 2016 at 5:00 AM, Martin Bjorklund 
> wrote:
> >
> > > Hi,
> > >
> > > Andy Bierman  wrote:
> > > > Hi,
> > > >
> > > > I am strongly against adding more features to YANG 1.1 at this time.
> > >
> > > Do you refer to the proprietary extension to restrict i-is?  If so, I
> > > agree (and Balazs just did in a separate email as well) that this is
> > > out of scope.
> > >
> > >
> > How would such an extension work, given that a tool MAY ignore
> > this extension? A plain client thinks the instance-identifier can
> > hold any valid instance, and is surprised that valid values are rejected
> by
> > the server (which don't match the magic extension rules)
>
> The additional validation rule is (hopefully) specified in the
> description.  The extension just tells the implementation to do the
> validation automatically; the alternative is for the user to write
> custom code.
>
> > Use XPath to further restrict the instance, so a plain client can see it.
>
> How?  (note how Balazs' "hack" uses a normal "must" statement).
>
>
> /martin
>

--089e0112cad02f2b840529f11511
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

The description-stmt is good enough=
.
Let's stop the feature-creep and get YANG 1.1 done.
Just keep using your proprietary extensions that tells
your pr=
oprietary tools how to special process the i-i value.

<=
div>
Andy


On Fri, Jan 22, 2016 at 10:42 AM, Martin B=
jorklund <mbj@tail-f.com> wrote:
Andy Bierman <andy@yumaworks.c=
om> wrote:

> On Fri, Jan 22, 2016 at 5:00 AM, Martin Bjorklund <mbj@tail-f.com> wrote:

>

> > Hi,

> >

> > Andy Bierman <andy@yumaw=
orks.com> wrote:

> > > Hi,

> > >

> > > I am strongly against adding more features to YANG 1.1 at th=
is time.

> >

> > Do you refer to the proprietary extension to restrict i-is?=C2=A0=
 If so, I

> > agree (and Balazs just did in a separate email as well) that this=
 is

> > out of scope.

> >

> >

> How would such an extension work, given that a tool MAY ignore

> this extension? A plain client thinks the instance-identifier can

> hold any valid instance, and is surprised that valid values are reject=
ed by

> the server (which don't match the magic extension rules)



The additional validation rule is (hopefully) specified in the

description.=C2=A0 The extension just tells the implementation to do the
validation automatically; the alternative is for the user to write

custom code.



> Use XPath to further restrict the instance, so a plain client can see =
it.



How?=C2=A0 (note how Balazs' "hack" uses a normal "must&=
quot; statement).





/martin





--089e0112cad02f2b840529f11511--


From nobody Fri Jan 22 12:46:33 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C331A8851 for ; Fri, 22 Jan 2016 12:46:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6InC0TBqCElE for ; Fri, 22 Jan 2016 12:46:30 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0105.outbound.protection.outlook.com [65.55.169.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D6071A8846 for ; Fri, 22 Jan 2016 12:46:29 -0800 (PST)
Received: from BLUPR05MB069.namprd05.prod.outlook.com (10.255.214.14) by BY1PR0501MB1159.namprd05.prod.outlook.com (10.160.104.11) with Microsoft SMTP Server (TLS) id 15.1.365.19; Fri, 22 Jan 2016 20:46:24 +0000
Received: from BLUPR05MB069.namprd05.prod.outlook.com ([169.254.9.45]) by BLUPR05MB069.namprd05.prod.outlook.com ([169.254.9.195]) with mapi id 15.01.0365.024; Fri, 22 Jan 2016 20:46:23 +0000
From: "Lisa (Yi) Huang" 
To: "Acee Lindem (acee)" , Ebben Aries , "Qin Wu" , netmod WG 
Thread-Topic: [netmod] Working group Last Call: draft-ietf-netmod-acl-model-06
Thread-Index: AQHRVNmwJ+quB7aDkEWkj3gyAoioF58HeoaAgAABkQA=
Date: Fri, 22 Jan 2016 20:46:23 +0000
Message-ID: 
References:  <56A1C480.7000509@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/14.5.5.150821
authentication-results: spf=none (sender IP is ) smtp.mailfrom=lyihuang@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.239.13]
x-microsoft-exchange-diagnostics: 1; BY1PR0501MB1159; 5:0oDJPKtXaNXfsVgC5ILLPyLYbGaJLmJo4XgbU4T0sqBpLpyvrEzhTpK6ThlB2crkmWljPE3Bp8ZeEY0YGvF/+Tbip4FWK0AnHECjzMD59kp/8MaOarmgcFkfyx8hNqt/cVBHZJMzFW6KcWCg3qPsbw==; 24:BT6Yq1aiL0gg5ZtgskdjRxgut/d7fTS6ox0kDiPEwlBVF+cHompR1wVXPd93jSKl8vqfJDYJmvdtek+M49m0iR+tMvzdFYFVnO9g7ChvDy8=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1159;
x-ms-office365-filtering-correlation-id: 7e602743-e1f4-46a5-e4cf-08d3236d1734
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001); SRVR:BY1PR0501MB1159; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1159; 
x-forefront-prvs: 08296C9B35
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(199003)(189002)(164054003)(377454003)(479174004)(586003)(1096002)(102836003)(76176999)(230783001)(5001770100001)(97736004)(54356999)(1220700001)(36756003)(4001350100001)(2906002)(50986999)(6116002)(86362001)(5008740100001)(189998001)(101416001)(106116001)(15975445007)(83506001)(2900100001)(92566002)(99286002)(122556002)(2950100001)(19580395003)(40100003)(81156007)(107886002)(19580405001)(66066001)(5004730100002)(5002640100001)(3846002)(1941001)(87936001)(10400500002)(5001960100002)(105586002)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1159; H:BLUPR05MB069.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)
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <57FC8F88F51608489ACC91A292D65966@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2016 20:46:23.6029 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1159
Archived-At: 
Subject: Re: [netmod] Working group Last Call: draft-ietf-netmod-acl-model-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 20:46:31 -0000

On 1/22/16, 4:40 AM, "netmod on behalf of Acee Lindem (acee)"
 wrote:

>
>
>On 1/22/16, 12:56 AM, "netmod on behalf of Ebben Aries"
> wrote:
>
>>
>>On 01/21/2016 12:45 AM, Qin Wu wrote:
>>> 1. This draft defines two module, one is IETF-PACKET-FIELDS, the other
>>>is ietf-access-control-list module,
>>> I am wondering whether ietf-packet-fields module can be defined in more
>>>generic way that can be applied to other modules defined somewhere else?
>>> e.g., in ietf-packet-fields module, acl-ip-header-fields grouping is
>>>defined, I am wondering whether prefix "acl-" can be removed to make it
>>>more generic?
>>
>>What you'll likely run into here is that the header fields defined in
>>acl-*-header-fields are more or less the lowest common denominators for
>>the application of "acl" - Not all header fields are defined here.
>>
>>I suppose an approach could be to define generic groupings of all header
>>fields and create per application groupings, referencing what is
>>supported with appropriate constraints, etc...  Not sure what that buys
>>here since you're likely to have overlap but not complete parity between
>>the different consumers of these packet fields.
>
>Furthermore, this is not a generic IP packet fields YANG module. It is a
>module for matching IP packet fields using traditional ACL semantics.
>Hence, changing the container name won=B9t change the content or semantics=
.
>If anything, the module name should be changed to include =B3acl-=B3 and n=
ot
>imply that it is generic.
>Thanks,
>Acee

There is no intention to include all packet fields in this module but QoS
could reuse this module.

Thanks,
Lisa


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


From nobody Fri Jan 22 13:05:04 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77941A8896 for ; Fri, 22 Jan 2016 13:05:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lx3058u0PgLK for ; Fri, 22 Jan 2016 13:05:00 -0800 (PST)
Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::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 A6AF51A888D for ; Fri, 22 Jan 2016 13:05:00 -0800 (PST)
Received: by mail-pa0-x230.google.com with SMTP id uo6so48264250pac.1 for ; Fri, 22 Jan 2016 13:05:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=4yD/lGPcjM6FRhaXlFLBhlvtp3Rj8Gf97M+UgVUNq+w=; b=gHv2rcByI3bt9FqULAL8MDnZNKrYutppmLmeX4RxbsO1th1nN6sye/0AKBBdWkZAaZ cFdgWe6ALP6Ycosibaz7v02Em6O6WMe9bzCeEdupQipcEFXDAXIkY+tP/M3zce9v9wYg MqqcRA6/60qnGivcZd3lUMe3I7Oct4YrBVKm/HybaoEpEUIMYh17NH5LSpGYMTergmvE CVQ5QhCuc83pjs1vDSDotwNc7gIjCSM1x5xwQtpsxVvWyisxuCrJyVVcIZHxPcOirBBS geAsZy+c/8at/sBFaFJezWc/qsiDn+Owe/1wQMs/9YF23vQvFi8tBXLhqK3CSCz4UzM2 CljA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=4yD/lGPcjM6FRhaXlFLBhlvtp3Rj8Gf97M+UgVUNq+w=; b=M29bPmWDxbhXxAD3o/dyK1Sd4lAVWnt0b24A0RY+nsIuHXc9inEcbvP/NVKfOJ8oQo yFtAAUQYEevJc+rMtB5fXV25JEQWykQjkRcPQbV3q5a6UguEzw31qdMMsQqPfNjt7xKX RSYlj6ISwTtyUrppoy7YEERcdjJgY04oxlL4mkEX+ZB5s3R7yI+9BRuDgnHsrJimTdBa AuXpren42MOaKaoWjPKD64JYv4c2UO5UnWA3KQ27qTIog9RyhqECDd/KtcL+B/ay/0XZ 15bOJ1SQtBXsOOSqARwwwTt0BqwN+5noPn1v+nTPHA+eb7nB3MWZXEzKdE4tLLFqz+9M W4lw==
X-Gm-Message-State: AG10YOTY6qvmsLjq41hiIte32sEnFjI5GS6JTXIeq7yXlGaR0pFMo4rCRfGFy+tCkx8Lfg==
X-Received: by 10.66.235.162 with SMTP id un2mr7403535pac.17.1453496700070; Fri, 22 Jan 2016 13:05:00 -0800 (PST)
Received: from ?IPv6:2001:420:c0c8:1004::3e8? ([2001:420:c0c8:1004::3e8]) by smtp.gmail.com with ESMTPSA id c90sm11741262pfd.31.2016.01.22.13.04.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 22 Jan 2016 13:04:58 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_FA19ED33-513A-4D94-9ABD-CD1EC9897DAD"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Mahesh Jethanandani 
In-Reply-To: 
Date: Fri, 22 Jan 2016 13:04:56 -0800
Message-Id: <5B325F51-FEEE-479B-A26D-92A38008DDA7@gmail.com>
References:  <56A1C480.7000509@juniper.net>  
To: "Lisa (Yi) Huang" 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] Working group Last Call: draft-ietf-netmod-acl-model-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 21:05:03 -0000

--Apple-Mail=_FA19ED33-513A-4D94-9ABD-CD1EC9897DAD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Jan 22, 2016, at 12:46 PM, Lisa (Yi) Huang  =
wrote:
>=20
>=20
>=20
> On 1/22/16, 4:40 AM, "netmod on behalf of Acee Lindem (acee)"
>  on behalf of =
acee@cisco.com > wrote:
>=20
>>=20
>>=20
>> On 1/22/16, 12:56 AM, "netmod on behalf of Ebben Aries"
>>  wrote:
>>=20
>>>=20
>>> On 01/21/2016 12:45 AM, Qin Wu wrote:
>>>> 1. This draft defines two module, one is IETF-PACKET-FIELDS, the =
other
>>>> is ietf-access-control-list module,
>>>> I am wondering whether ietf-packet-fields module can be defined in =
more
>>>> generic way that can be applied to other modules defined somewhere =
else?
>>>> e.g., in ietf-packet-fields module, acl-ip-header-fields grouping =
is
>>>> defined, I am wondering whether prefix "acl-" can be removed to =
make it
>>>> more generic?
>>>=20
>>> What you'll likely run into here is that the header fields defined =
in
>>> acl-*-header-fields are more or less the lowest common denominators =
for
>>> the application of "acl" - Not all header fields are defined here.
>>>=20
>>> I suppose an approach could be to define generic groupings of all =
header
>>> fields and create per application groupings, referencing what is
>>> supported with appropriate constraints, etc...  Not sure what that =
buys
>>> here since you're likely to have overlap but not complete parity =
between
>>> the different consumers of these packet fields.
>>=20
>> Furthermore, this is not a generic IP packet fields YANG module. It =
is a
>> module for matching IP packet fields using traditional ACL semantics.
>> Hence, changing the container name won=C4=85t change the content or =
semantics.
>> If anything, the module name should be changed to include =C5=82acl-=C5=
=82 and not
>> imply that it is generic.
>> Thanks,
>> Acee
>=20
> There is no intention to include all packet fields in this module but =
QoS
> could reuse this module.

The QoS module has defined its own set of fields that packets could get =
classified on, and has no plans to use the ACL packet field definitions.

>=20
> Thanks,
> Lisa
>=20
>=20
>>=20
>>=20
>>>=20
>>> /ebben
>>>=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 =

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

Mahesh Jethanandani
mjethanandani@gmail.com






--Apple-Mail=_FA19ED33-513A-4D94-9ABD-CD1EC9897DAD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On Jan 22, 2016, at 12:46 PM, Lisa (Yi) Huang <lyihuang@juniper.net> wrote:



On 1/22/16, 4:40 AM, "netmod on behalf of Acee =
Lindem (acee)"
<netmod-bounces@ietf.org on behalf of acee@cisco.com> wrote:



On 1/22/16, 12:56 AM, "netmod on behalf of Ebben Aries"
<netmod-bounces@ietf.org on behalf of exa@juniper.net> =
wrote:


On 01/21/2016 12:45 AM, Qin Wu wrote:
1. This draft defines =
two module, one is IETF-PACKET-FIELDS, the other
is =
ietf-access-control-list module,
I am wondering whether =
ietf-packet-fields module can be defined in more
generic =
way that can be applied to other modules defined somewhere else?
e.g., in ietf-packet-fields module, acl-ip-header-fields =
grouping is
defined, I am wondering whether prefix "acl-" =
can be removed to make it
more generic?

What you'll likely run into here =
is that the header fields defined in
acl-*-header-fields =
are more or less the lowest common denominators for
the =
application of "acl" - Not all header fields are defined here.

I suppose an approach could be to define =
generic groupings of all header
fields and create per =
application groupings, referencing what is
supported with =
appropriate constraints, etc...  Not sure what that buys
here since you're likely to have overlap but not complete =
parity between
the different consumers of these packet =
fields.

Furthermore, this is =
not a generic IP packet fields YANG module. It is a
module =
for matching IP packet fields using traditional ACL semantics.
Hence, changing the container name won=C4=85t change the =
content or semantics.
If anything, the module name should =
be changed to include =C5=82acl-=C5=82 and not
imply that =
it is generic.
Thanks,
Acee

There is no intention to =
include all packet fields in this module but QoS
could reuse this module.

The QoS module =
has defined its own set of fields that packets could get classified on, =
and has no plans to use the ACL packet field definitions.


Thanks,
Lisa





/ebben

_______________________________________________
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

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



Mahesh Jethanandani
mjethanandani@gmail.com








=

--Apple-Mail=_FA19ED33-513A-4D94-9ABD-CD1EC9897DAD--


From nobody Fri Jan 22 17:29:51 2016
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF27C1B2E9F; Fri, 22 Jan 2016 17:29:47 -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.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160123012947.2367.17244.idtracker@ietfa.amsl.com>
Date: Fri, 22 Jan 2016 17:29:47 -0800
Archived-At: 
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-04.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Jan 2016 01:29:47 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF.

        Title           : Terminology and Requirements for Enhanced Handling of Operational State
        Authors         : Kent Watsen
                          Thomas Nadeau
	Filename        : draft-ietf-netmod-opstate-reqs-04.txt
	Pages           : 6
	Date            : 2016-01-22

Abstract:
   This document primarily regards the difference between the intended
   configuration and the applied configuration of a device and how
   intended and applied configuration relate to the operational state of
   a device.  This document defines requirements for the applied
   configuration's data model and its values, as well as for enabling a
   client to know when a configuration has been fully applied or not,
   how to access operational state, and how to relate intended
   configuration nodes to applied configuration and derived state nodes.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-opstate-reqs-04


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

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


From nobody Fri Jan 22 17:37:25 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691F11B2EB3 for ; Fri, 22 Jan 2016 17:37:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjmqL52TcAZm for ; Fri, 22 Jan 2016 17:37:19 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0129.outbound.protection.outlook.com [65.55.169.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 AC3251B2EB0 for ; Fri, 22 Jan 2016 17:37:19 -0800 (PST)
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 (TLS) id 15.1.365.19; Sat, 23 Jan 2016 01:37:17 +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.0365.024; Sat, 23 Jan 2016 01:37:17 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-04.txt
Thread-Index: AQHRVX2W+MwWjAvgekCJGWCjtbGlrJ8H/mEA
Date: Sat, 23 Jan 2016 01:37:17 +0000
Message-ID: <05DD4741-BE90-41E9-A9D0-1D51864F75A8@juniper.net>
References: <20160123012947.2367.17244.idtracker@ietfa.amsl.com>
In-Reply-To: <20160123012947.2367.17244.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.151105
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.13]
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 5:jCa0Bnd3s97PlImb0jPWpJcl9iKNjiEBrh+UHgerOlJM2Ahzg2CcNkFAbbOB0khI/u0z/GX29MbQ1a1cYEi/YzTCGA5Jl7VBNcmIPfxc2lV6uJOJK3d8nCGE9uUX7y08n9dIGhkgTWVkWoRDidhnbg==; 24:Mo34GJPVkHK1hx2Y/Ybld7zjEtRrJfLgEPcpLP8JE6xMv1NP2KHnofyAKeY/suHRxO9Y5se+ESnvt613rFm5qzWNGGwHsYW+lXxQb+WRBSw=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1443;
x-ms-office365-filtering-correlation-id: 50be47ed-7dff-4a28-083c-08d32395bab7
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; 
x-forefront-prvs: 0830866D19
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(479174004)(164054003)(189002)(377424004)(199003)(24454002)(106356001)(83716003)(230783001)(81156007)(36756003)(86362001)(4001350100001)(5002640100001)(2351001)(76176999)(110136002)(107886002)(87936001)(54356999)(1730700002)(6116002)(189998001)(99286002)(97736004)(5001960100002)(105586002)(3846002)(66066001)(83506001)(33656002)(2900100001)(1220700001)(19580405001)(15975445007)(82746002)(1096002)(11100500001)(101416001)(40100003)(2950100001)(2501003)(106116001)(5004730100002)(10400500002)(450100001)(122556002)(77096005)(92566002)(50986999)(19580395003)(102836003)(586003)(5008740100001)(2906002)(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:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <27563A5548B8CC45930668A2AA5FC7A7@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2016 01:37:17.6528 (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: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-04.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Jan 2016 01:37:23 -0000

DQpbQXMgYSBjb250cmlidXRvcl0NCg0KVGhpcyB1cGRhdGUgY29udGFpbnMgdGhlIGZvbGxvd2lu
ZyBjaGFuZ2VzOg0KDQoNCjEpIHJlbW92ZWQg4oCcKHNlZSB0ZXJtKeKAnSB0aHJvdWdob3V0DQoN
CjIpIG1vdmVkIDJuZC1oYWxmIG9mIHRoZSBBc3luY2hyb25vdXMgQ29uZmlndXJhdGlvbiBPcGVy
YXRpb24gdGVybSB0byBuZXcgcmVxdWlyZW1lbnQgMi1CDQoNCjMpIG1vdmVkIHRoZSBCYWNrd2Fy
ZHMgQ29tcGF0aWJpbGl0eSB0byBuZXcgcmVxdWlyZW1lbnQgNQ0KDQo0KSBtYWRlIHNvbWUgbWF5
L01BWS9TSE9VTEQvTVVTVCBjaGFuZ2VzIChhcyBkaXNjdXNzZWQgb24gbGlzdCkNCg0KNSkgcmVw
bGFjZWQgbWFwL21hcHBpbmcgd2l0aCByZWxhdGUvcmVsYXRpb25zaGlwcw0KDQoNClBsZWFzZSBz
ZWUgdGhlIGRpZmYgZm9yIGRldGFpbHMuDQoNClRoYW5rcywNCktlbnQNCg0KDQoNCg0KDQpPbiAx
LzIyLzE2LCA4OjI5IFBNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0
Zi5vcmciIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgaW50ZXJuZXQtZHJh
ZnRzQGlldGYub3JnPiB3cm90ZToNCg0KPg0KPkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWls
YWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4gVGhp
cyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgTkVUQ09ORiBEYXRhIE1vZGVsaW5nIExhbmd1
YWdlIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+DQo+ICAgICAgICBUaXRsZSAgICAgICAg
ICAgOiBUZXJtaW5vbG9neSBhbmQgUmVxdWlyZW1lbnRzIGZvciBFbmhhbmNlZCBIYW5kbGluZyBv
ZiBPcGVyYXRpb25hbCBTdGF0ZQ0KPiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogS2VudCBXYXRz
ZW4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgIFRob21hcyBOYWRlYXUNCj4JRmlsZW5hbWUg
ICAgICAgIDogZHJhZnQtaWV0Zi1uZXRtb2Qtb3BzdGF0ZS1yZXFzLTA0LnR4dA0KPglQYWdlcyAg
ICAgICAgICAgOiA2DQo+CURhdGUgICAgICAgICAgICA6IDIwMTYtMDEtMjINCj4NCj5BYnN0cmFj
dDoNCj4gICBUaGlzIGRvY3VtZW50IHByaW1hcmlseSByZWdhcmRzIHRoZSBkaWZmZXJlbmNlIGJl
dHdlZW4gdGhlIGludGVuZGVkDQo+ICAgY29uZmlndXJhdGlvbiBhbmQgdGhlIGFwcGxpZWQgY29u
ZmlndXJhdGlvbiBvZiBhIGRldmljZSBhbmQgaG93DQo+ICAgaW50ZW5kZWQgYW5kIGFwcGxpZWQg
Y29uZmlndXJhdGlvbiByZWxhdGUgdG8gdGhlIG9wZXJhdGlvbmFsIHN0YXRlIG9mDQo+ICAgYSBk
ZXZpY2UuICBUaGlzIGRvY3VtZW50IGRlZmluZXMgcmVxdWlyZW1lbnRzIGZvciB0aGUgYXBwbGll
ZA0KPiAgIGNvbmZpZ3VyYXRpb24ncyBkYXRhIG1vZGVsIGFuZCBpdHMgdmFsdWVzLCBhcyB3ZWxs
IGFzIGZvciBlbmFibGluZyBhDQo+ICAgY2xpZW50IHRvIGtub3cgd2hlbiBhIGNvbmZpZ3VyYXRp
b24gaGFzIGJlZW4gZnVsbHkgYXBwbGllZCBvciBub3QsDQo+ICAgaG93IHRvIGFjY2VzcyBvcGVy
YXRpb25hbCBzdGF0ZSwgYW5kIGhvdyB0byByZWxhdGUgaW50ZW5kZWQNCj4gICBjb25maWd1cmF0
aW9uIG5vZGVzIHRvIGFwcGxpZWQgY29uZmlndXJhdGlvbiBhbmQgZGVyaXZlZCBzdGF0ZSBub2Rl
cy4NCj4NCj4NCj5UaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFm
dCBpczoNCj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldG1v
ZC1vcHN0YXRlLXJlcXMvDQo+DQo+VGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFp
bGFibGUgYXQ6DQo+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0bW9k
LW9wc3RhdGUtcmVxcy0wNA0KPg0KPkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlz
IGF2YWlsYWJsZSBhdDoNCj5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt
aWV0Zi1uZXRtb2Qtb3BzdGF0ZS1yZXFzLTA0DQo+DQo+DQo+UGxlYXNlIG5vdGUgdGhhdCBpdCBt
YXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0K
PnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9v
bHMuaWV0Zi5vcmcuDQo+DQo+SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBh
bm9ueW1vdXMgRlRQIGF0Og0KPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+
DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5uZXRt
b2QgbWFpbGluZyBsaXN0DQo+bmV0bW9kQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg==


From nobody Sat Jan 23 17:26:14 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0391B3A4C; Sat, 23 Jan 2016 17:26:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvcsnODSWGW9; Sat, 23 Jan 2016 17:26:03 -0800 (PST)
Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::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 AC5751B3A4A; Sat, 23 Jan 2016 17:26:03 -0800 (PST)
Received: by mail-pf0-x22e.google.com with SMTP id n128so62351046pfn.3; Sat, 23 Jan 2016 17:26:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Q+IfsrppBWQvv4ZIQD0/3YnGq4UM6LM1092YysDtK0U=; b=ZOw1YVN1QkDqhgVk+kWFoipOXVkRdqGJnxhSEsCyr+DjeoZ9+FeKWriJch+a7uF6K4 fWVwJj6Gmjvvlm0Wp+GmCgxyiON1qgpUGyKGsI+thoQiiZqt72+9NjaycTbRzHltHvzI 4hkSRRaUv1OmQUCJnpP1FHCaMo8lKGGDI7cMZJQjHNq67Cs9CGkQt9pQT7hI/cRNtnYK 8jPHE5wmQhKW7yrvEH0EqNHFcOQ2jP2HOIgwjk9R0siAKZICJX8WLLq2XoOkUSTNkNnU NCJqSSp6PyMHPYAMtFhfrplQk4m4i2Au8x4bcGU59Vyg2WkhLL91N2wHBIRPqn7EaZ8b A5TA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Q+IfsrppBWQvv4ZIQD0/3YnGq4UM6LM1092YysDtK0U=; b=i0Q8Hs7Pvs4PBAvSA6j9qaN7w7bGdDjruuMxSKBDwq6l15UR+SUG+6X5UEpPRu1TOa n5PhFJNZcB2oEAeFYfSht2lQnXr92Rv3mMXLb+JCotqzc26ydw6Bdx7stXVOtDBFjlV+ 9YIsJ2mL/f7p24yz4YnRtAlxVmo6YluS5cEF4QCbwRjVxSlfQ5wg2JDJpFDYQeBFj8pj pPXUSr+nSZ1L8U3az2Pm3ktOyEm2gJEFAa4XdwNLcGat5YGXK8HnFKamekneI6XMwwUo B0xbMN2wvMUw8NkcGIwxiByIphtbXK4DNaRnKEHzvjOtQHKVGapx+JWSwIXzXcNBdvEt dTcA==
X-Gm-Message-State: AG10YOQGo6EbEfN6FHv/yNcL68/+fEzrYdTxeDPyZnApSRP650eKVMy38BOA0wgUpc1I+Q==
X-Received: by 10.98.70.151 with SMTP id o23mr15450815pfi.124.1453598763215; Sat, 23 Jan 2016 17:26:03 -0800 (PST)
Received: from [10.24.22.192] ([128.107.241.181]) by smtp.gmail.com with ESMTPSA id 68sm18820675pfa.78.2016.01.23.17.26.01 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 23 Jan 2016 17:26:01 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_7112B9A0-15BD-4442-A187-939EC9E880FC"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Mahesh Jethanandani 
In-Reply-To: 
Date: Sat, 23 Jan 2016 18:25:59 -0700
Message-Id: 
References: 
To: NETCONF 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: i2rs@ietf.org, 6tisch@ietf.org, core@ietf.org, "netmod@ietf.org" , 6lo@ietf.org
Subject: Re: [netmod] WG Last Call for draft-ietf-netconf-restconf-09, draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 Jan 2016 01:26:06 -0000

--Apple-Mail=_7112B9A0-15BD-4442-A187-939EC9E880FC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

The Last Call period for the above three drafts closed yesterday. Thanks =
to everyone who provided comments on the three drafts.

The authors will update the documents based on the comments received and =
post an updated version of the draft(s).

Mahesh & Mehmet.

> On Dec 15, 2015, at 2:09 PM, Ersue, Mehmet (Nokia - DE/Munich) =
 wrote:
>=20
> FYI and attention.
> =20
> Please provide your comments to NETCONF WG maillist.
> =20
> Mehmet
> =20
> From: Ersue, Mehmet (Nokia - DE/Munich)=20
> Sent: Tuesday, December 15, 2015 9:59 PM
> To: netconf@ietf.org 
> Cc: 'core@ietf.org ' >; 'i2rs@ietf.org ' =
>; '6lo@ietf.org =
' <6lo@ietf.org >; =
'6tisch@ietf.org ' <6tisch@ietf.org =
>
> Subject: WG Last Call for draft-ietf-netconf-restconf-09, =
draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03
> =20
> Dear NETCONF WG,
> =20
> we hereby issue a WG Last Call for the drafts below:
> =20
> http://tools.ietf.org/html/draft-ietf-netconf-restconf-09.txt =

> http://tools.ietf.org/html/draft-ietf-netconf-yang-patch-07.txt =

> http://tools.ietf.org/html/draft-ietf-netconf-yang-library-03.txt =

> =20
> Please review and send your comments to the NETCONF WG mailing list by =
January 22, 2015 EOB PT.
> =20
> The drafts on RESTCONF, YANG patch and YANG library are planned to =
publish as standard track documents.
> =20
> As RESTCONF is a major protocol we seek a detailed and thorough review =
within NETCONF WG but also by the related WGs before publishing.
> Therefore the WGLC is planned to finalize on January 22th (covering =
the holiday time in between) and APP, INT and RTG area ADs will be =
informed as well as Core, I2RS, 6lo, and 6tisch WGs are invited to =
review.
> =20
> Please take your time to review the documents and send your comments =
to the NETCONF maillist by the deadline.
> Please state on NETCONF maillist also explicitly, whether you have =
read/reviewed and whether you support the publication.
> Furthermore please indicate if you plan to implement or have already =
implementations for RESTCONF and its supplementary drafts.
> =20
> Thank you for your review and kind help getting RESTCONF =
specifications stable.
> =20
> Best Regards,
> Mehmet and Mahesh






--Apple-Mail=_7112B9A0-15BD-4442-A187-939EC9E880FC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

The Last Call period for the above three drafts closed =
yesterday. Thanks to everyone who provided comments on the three =
drafts.

The authors =
will update the documents based on the comments received and post an =
updated version of the draft(s).

Mahesh & Mehmet.

On Dec 15, 2015, at 2:09 PM, Ersue, Mehmet (Nokia - =
DE/Munich) <mehmet.ersue@nokia.com> wrote:

FYI and attention.
 
Please provide your =
comments to NETCONF WG maillist.
 
Mehmet
 
From: Ersue, =
Mehmet (Nokia - DE/Munich) 
Sent: Tuesday, December 15, 2015 =
9:59 PM
To: netconf@ietf.org
Cc: 'core@ietf.org' <core@ietf.org>; 'i2rs@ietf.org' <i2rs@ietf.org>; '6lo@ietf.org' <6lo@ietf.org>; '6tisch@ietf.org' <6tisch@ietf.org>
Subject: WG Last Call for =
draft-ietf-netconf-restconf-09, draft-ietf-netconf-yang-patch-07 and =
draft-ietf-netconf-yang-library-03
 
Dear NETCONF WG,
 
we hereby issue a WG Last =
Call for the drafts below:
 
http://tools.ietf.org/html/draft-ietf-netconf-restconf-09.txt
 
Please review and send =
your comments to the NETCONF WG mailing list by January 22, 2015 EOB =
PT.
 
The =
drafts on RESTCONF, YANG patch and YANG library are planned to publish =
as standard track documents.
 
As RESTCONF is a major protocol we seek a =
detailed and thorough review within NETCONF WG but also by the related =
WGs before publishing.
Therefore the WGLC is planned to finalize on January 22th =
(covering the holiday time in between) and APP, INT and RTG area ADs =
will be informed as well as Core, I2RS, 6lo, and 6tisch WGs are invited =
to review.
 
Please take your time to review the documents and send your =
comments to the NETCONF maillist by the deadline.
Please state on NETCONF maillist also =
explicitly, whether you have read/reviewed and whether you support the =
publication.
Furthermore please =
indicate if you plan to implement or have already =
implementations for RESTCONF and its supplementary =
drafts.
 
Thank=
 you for your review and kind help getting RESTCONF specifications =
stable.
 
Best =
Regards,
Mehmet and =
Mahesh








=

--Apple-Mail=_7112B9A0-15BD-4442-A187-939EC9E880FC--


From nobody Mon Jan 25 06:01:22 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3C71AC398 for ; Mon, 25 Jan 2016 06:01:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level: 
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mt4pXCtCo98d for ; Mon, 25 Jan 2016 06:01:17 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id D7D7E1ABD3D for ; Mon, 25 Jan 2016 06:01:16 -0800 (PST)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 63B6D1CC0144; Mon, 25 Jan 2016 15:01:15 +0100 (CET)
From: Ladislav Lhotka 
To: William Lupton 
In-Reply-To: <8112CC17-AA20-43CB-9870-1902F26BCC7E@broadband-forum.org>
References:   <8112CC17-AA20-43CB-9870-1902F26BCC7E@broadband-forum.org>
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Mon, 25 Jan 2016 15:01:15 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Validation question
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2016 14:01:21 -0000

William Lupton  writes:

> Lada,
>
> Thanks for drawing my attention to this section. I hadn't noticed this advice.
>
> Perhaps corresponding things need to be said about the XML?

Yes, for YANG 1.0. In YANG 1.1 the string comparison of identity values
should be avoided in favour of the new XPath functions that work for any
properly qualified identity names. 

> Always use a prefix on identity values, even if the default namespace (YANG module) is the module that defined the identity.
> When importing a namespace (YANG module) that contains identities that are referenced in the XML, always use the same prefix that was used within the imported module.
>
> The need for the first of the above XML-related statements wasn't illustrated by the YANG and XML in my first message but it's illustrated by the fragments shown below.
>
> I guess the point about derived-from() and derived-from-or-self() is
> that, although they still specify the identities as strings, the
> strings are known to be identities, so prefixes can be processed
> (applying defaults etc)?

Right. In terms of XML/XPath they are treated as qualified names (QNames).

>
> Finally, I think perhaps this is a separate point (because not related
> to string values), but seems to be necessary to use the same prefixes
> for imported modules as were used within those modules. For example,
> if (in my example) I change the ietf-interfaces prefix from if to ifx,
> validation fails with an "undefined namespace prefix" error.

Apart from string comparisons in XPath, this should never be a
problem. Can you send me (off list) your data that fail to validate?

Lada

>
> Cheers,
> William
>
> YANG fragment:
>   identity sub-type;
>
>   identity sub-type-a {
>     base sub-type;
>   }
>
>   augment "/if:interfaces/if:interface" {
>     when "if:type = 'mymod:some-new-iftype'";
>
>     container some-new-container {
>       leaf sub-type {
>         type identityref {
>           base sub-type;
>         }
>       }
>       container sub-container {
>         when "../mymod:sub-type = 'mymod:sub-type-a'";
>       }
>     }
>   }
>
> XML fragment (mymod prefix is necessary in order for XML to validate):
>       
> 	mymod:sub-type-a
> 	
>       
>
>> On 22 Jan 2016, at 09:32, Ladislav Lhotka  wrote:
>> 
>> Hi William,
>> 
>> YANG uses XPath 1.0, and so the equality tests mean *string
>> equality*. That's why 6087bis recommends in sec. 5.6.4:
>> 
>>   XPath expressions that contain a literal value representing a YANG
>>   identity SHOULD always include the declared prefix of the module
>>   where the identity is defined.
>> 
>> In YANG 1.1, the new XPath functions derived-from() and
>> derived-from-or-self() will alleviate this problem.
>> 
>> Lada
>> 
>> William Lupton  writes:
>> 
>>> All,
>>> 
>>> We have been experimenting with validating XML instances along the lines explained in the tutorials at http://www.yang-central.org/twiki/bin/view/Main/DSDLMappingTutorial  and https://github.com/mbj4668/pyang/wiki/InstanceValidation  and we have hit a problem with identities in XPath expressions.
>>> 
>>> This is illustrated by the YANG module shown below, which is inspired by an example in RFC 6020bis, and the XML instance shown below the YANG. Note that:
>>> The second "when" statement doesn't use a prefix on the interface type.
>>> Shouldn't be a problem because the interface type is defined in the current module and so doesn't need a prefix?
>>> The XML uses a prefix name of "exaug" rather than "mymod" which is used in the YANG.
>>> Shouldn't be a problem because prefixes should be local?
>>> 
>>> Validating this instance gives the following two errors (which go away if the prefix "mymod" is used in all "when" statements and in the XML).
>>> 
>>> == Validating semantic constraints ...
>>> --- Validity error at "/nc:data/if:interfaces/if:interface":
>>>    Found nodes that are valid only when "if:type = 'mymod:some-new-iftype'"
>>> --- Validity error at "/nc:data/if:interfaces-state/if:interface":
>>>    Found nodes that are valid only when "if:type = 'some-new-iftype'"
>>> 
>>> Are we doing something wrong here, or is there a problem with how identities in XPath expressions are translated (per RFC 6110)? On the face of it it seems that identities are being treated as literal strings (but we haven't investigated this assertion).
>>> 
>>> Thanks,
>>> William Lupton
>>> 
>>> --------
>>> 
>>> YANG:
>>> module example-augment {
>>>  namespace "http://example.com/augment";
>>>  prefix mymod;
>>> 
>>>  import ietf-interfaces {
>>>    prefix if;
>>>  }
>>> 
>>>  identity some-new-iftype {
>>>    base if:interface-type;
>>>  }
>>> 
>>>  augment "/if:interfaces/if:interface" {
>>>    when "if:type = 'mymod:some-new-iftype'";
>>> 
>>>    container some-new-container {
>>>    }
>>>  }
>>> 
>>>  augment "/if:interfaces-state/if:interface" {
>>>    when "if:type = 'some-new-iftype'";
>>> 
>>>    container some-new-container {
>>>    }
>>>  }
>>> }
>>> 
>>> XML:
>>> 
>>> >>  xmlns:exaug="http://example.com/augment">
>>>  
>>>    
>>>      
>>>      
>>>      exaug:some-new-iftype
>>>      true
>>>      enabled
>>>      
>>>      
>>>    
>>>  
>>>  
>>>    
>>>      
>>>      exaug:some-new-iftype
>>>      up
>>>      up
>>>      1
>>>      
>>>        2016-01-15T12:55:00Z
>>>      
>>>      
>>>      
>>>    
>>>  
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> 
>> -- 
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>> 
>

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


From nobody Mon Jan 25 07:48:10 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573A41B2C6D for ; Mon, 25 Jan 2016 07:48:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOAtL4uLpyST for ; Mon, 25 Jan 2016 07:48:08 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 157B01B2C62 for ; Mon, 25 Jan 2016 07:48:07 -0800 (PST)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id AD4CD1CC0144; Mon, 25 Jan 2016 16:48:06 +0100 (CET)
From: Ladislav Lhotka 
To: Andy Bierman , Balazs Lengyel 
In-Reply-To: 
References: <56A0F18D.4030505@ericsson.com> <20160121.161733.727143885958810312.mbj@tail-f.com> <56A10C79.1010601@ericsson.com> 
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Mon, 25 Jan 2016 16:48:04 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Constraining instance-identifiers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2016 15:48:10 -0000

Andy Bierman  writes:

> Hi,
>
> There is no need to change the XML encoding or YANG encoding
> of an instance-identifier.  The prefixes are completely different
> in each.  Prefixes clashes do happen, especially since
> there is no expectation that they are unique.  They are short strings
> with no naming conventions at all.  E.g., I have seen "if" for
> interfaces in multiple modules.

I agree. We should make clear that prefixes should NEVER be hardcoded.

Lada

>
> Andy
>
>
> On Thu, Jan 21, 2016 at 8:51 AM, Balazs Lengyel > wrote:
>
>> Hello Martin,
>> If the RFC would define that in XPath expressions an instance identifier
>> MUST be evaluated to a string that complies to the lexical format, using
>> the rematch function, we could do everything we need. In real life prefix
>> clashes are a rare problem.
>> regards Balazs
>>
>> On 2016-01-21 16:17, Martin Bjorklund wrote:
>>
>>> Balazs Lengyel  wrote:
>>>
>>>> Hello,
>>>> We have some instance identifiers in our model but we want to
>>>> contrain what they can point at. What is the best method for that?
>>>>
>>> Unfortunately, there is no standard way of doing this.  (There are
>>> vendor extensions available...)
>>>
>>> [...]
>>>
>>> Some issues:
>>>> - instance-identifiers don't have a canonical format, so what is
>>>> their value in an XPath expression?
>>>>
>>> This is not defined.
>>>
>>> - I didn't find a way to evaluate a regexp in XPath 1.0. Is there a way?
>>>>
>>> In YANG 1.1, there is a function re-match() for this purpose.  For
>>> your use case, it *may* work to match just the local names of all
>>> nodes, i.e., using wildcards for the prefixes.  It is not a generic
>>> solution though.
>>>
>>> - if I have all the needed namespace prefixes in imports, can I just
>>>>    use them?
>>>>
>>> No, these prefixes are local to the module that is doing the import,
>>> and they may or may not match the prefixes used by the implementation
>>> when it construct the instance-identifier value.
>>>
>>>
>>>
>>> /martin
>>>
>>>
>> --
>> Balazs Lengyel                       Ericsson Hungary Ltd.
>> Senior Specialist
>> ECN: 831 7320
>> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
>>
>> _______________________________________________
>> 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: E74E8C0C


From nobody Mon Jan 25 14:53:06 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1401A1B87 for ; Mon, 25 Jan 2016 14:53:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkYE3Jks9ocb for ; Mon, 25 Jan 2016 14:53:03 -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 D0B061A1B83 for ; Mon, 25 Jan 2016 14:53:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8869; q=dns/txt; s=iport; t=1453762382; x=1454971982; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=faV/6ICNyvxkPbjXNKMQP1wW2hufWQYsmu8g+vJ1ngc=; b=jI0qWGr7IRqQfxCn5bmqkOsRVCfOoA0QBo6UBosWmfvZ0kwXVQUt3/Zp 7LW3mhrX+DNdS3zwAsb2IommVEF2y3HV7cXK5oE13dIyq3hZM2ooIqSRE mmibobbBmPsXUeg/GNLwv16y6OrXzaRd3G+ShYESVJNQAOgKu6GFVljh2 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A1AgBtpqZW/4cNJK1egzpSbQaEJYQss?= =?us-ascii?q?hQBDYFjGAqCPYJmSgKBRjgUAQEBAQEBAYEKhEEBAQEEAQEBCywrCQsMBAIBCBE?= =?us-ascii?q?EAQEBHgkHJwsUCQgCBA4FCBOIAA6+QwEBAQEBAQEBAQEBAQEBAQEBAQEBAREEh?= =?us-ascii?q?jKEbYQbCgcBhFkFlnYBiDaFGIFlhESIV44+AR4BAUKDaWqGAwkXHXwBAQE?=
X-IronPort-AV: E=Sophos;i="5.22,346,1449532800"; d="scan'208";a="69778987"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Jan 2016 22:53:01 +0000
Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u0PMr1S8017859 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 25 Jan 2016 22:53:01 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 25 Jan 2016 17:53:00 -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.1104.009; Mon, 25 Jan 2016 17:53:00 -0500
From: "Eric Voit (evoit)" 
To: Ladislav Lhotka , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" 
Thread-Topic: [netmod] Comparison of structural-mount and ysdl drafts
Thread-Index: AQHRVSWLfmMu15gC6EudMeiiRL2Xh58My3Pg
Date: Mon, 25 Jan 2016 22:53:00 +0000
Message-ID: <78b237493c4447dca8cca676972a971e@XCH-RTP-013.cisco.com>
References: <56A0C64A.3090506@cisco.com>  <56A22E6E.1040109@cisco.com> <097158EE-01CF-421E-AB35-E2FBFA6E3F3B@nic.cz>
In-Reply-To: <097158EE-01CF-421E-AB35-E2FBFA6E3F3B@nic.cz>
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.230]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Comparison of structural-mount and ysdl drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2016 22:53:05 -0000

Robert,

Per (1) below, if you are looking to mount yang from one device to another,=
 the drafts to look at are:
   draft-clemm-netmod-mount-03
   draft-voit-netmod-peer-mount-requirements-03

At this point NETMOD as a whole has not attempted to address whether any co=
mmon syntax or requirements should bind this aggregate set of four drafts.

Eric


> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotk=
a
> Sent: Friday, January 22, 2016 10:00 AM
> To: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Comparison of structural-mount and ysdl drafts
>=20
>=20
> > On 22 Jan 2016, at 14:28, Robert Wilton  wrote:
> >
> > Hi Lada,
> >
> > Please see inline ...
> >
> > On 22/01/2016 12:41, Ladislav Lhotka wrote:
> >> Robert Wilton  writes:
> >>
> >>> Hi Lada, Martin,
> >>>
> >>> I've reviewed both draft-bjorklund-netmod-structural-mount-00 and
> >>> draft-lhotka-netmod-ysdl-00.
> >>>
> >>> In comparing these two drafts, the main differences that I perceive a=
re:
> >>>
> >>> 1) structural-mount allows the mounted data model to publish its
> >>> supported schema at the mount point, but ysdl requires the mounting
> >>> device to know and publish the schema for all mounted data models.
> >> I am not sure what you mean by "publish" but I think really the only
> >> difference is that structural-mount provides schema information as
> >> regular state data and YSDL as meta-data.
> > I was really referring to the inline-yang-library option in structural =
mount that
> allows the actual YANG schema to be deferred to the mounted device
> implementing yang-library (and which is available at the mount point).  T=
his is
> the option that I would anticipate would be used in the LNE model.
>=20
> YSDL doesn't address any kind of remote mounts. It just adds a pull-style=
 method
> for the schema construction but everything is local to the device. I thin=
k that
> mounting data from other devices is a different matter with specific prob=
lems
> (access) that don't exist in YSDL.
>=20
> >
> >>
> >> In my view, the definition of a data model schema is really
> >> meta-data. The module "ietf-yang-structural-mount" and its data would
> >> require special treatment anyway - for example, it has to be found in
> >> a well-known location, so it cannot itself be mounted.
> > Yes, I can see how it is meta-data, but I'm not sure that it is signifi=
cantly
> different from the information provided in yang-library which is represen=
ted a s
> regular YANG operational module.
>=20
> It doesn't really matter how the schema info is retrieved, as long as it =
is state
> data available at a well-known location. As I wrote, YSDL could be just a=
n
> augmentation of yang-library.
>=20
> Lada
>=20
> >
> > For structural-mount: A mounted model should be able to make the mount-
> points structure available at the mount point if required. I.e. the solut=
ion is able
> to naturally recurse (as Martin confirmed in reply to Robert Varga's emai=
l).
> >
> >>
> >>> 2) A corollary of (1) is that structural-mount also allows different
> >>> schema data models to be published at the mount point (e.g. under a
> >>> list), but ysdl does not.
> >> True, but it can be easily emulated by using either a choice (or a
> >> "dynamic choice" using "when") and defining different sub-schemas as
> >> different cases. I'd argue this is a more robust approach.
> > I don't think that emulating this with a choice is going to be particul=
arly clean.
> In addition, the device that is doing the mounting doesn't necessarily kn=
ow what
> models the mounted device actual implements.  For ysdl to work for this
> scenario, the mounting device would probably need to query the yang-libra=
ry
> (and/or ysdl meta-information to allow the solution to recurse) for each
> mounted device to construct the meta-data for it. At this point I would a=
rgue
> that it is easier to just provide direct access to the yang-library for t=
he mounted
> device (as structural-mount solution proposes).
> >
> >>
> >>> 3) structural-mount has a mount node embedded directly in the
> >>> schema, where as for ysdl, the equivalent mount points are only
> >>> specified in the ysdl meta-schema.
> >>> 4) ysdl is extensible to cover other non mount related use-cases
> >>> (such as anydata) where being able to dynamically make available the
> >>> schema is useful.
> >>> 5) structural-mount also covers RPCs and Notifications, whereas
> >>> these appear to be outside the scope of ysdl.
> >> This is just an omission on the part of YSDL. The approach proposed
> >> for structural-mount can be used as well.
> > OK.
> >
> >>
> >>> 6) The ysdl meta-data language appears to be more flexible, and
> >>> hence also more complex, than the equivalent "mount-points" schema
> >>> defined in structural-mount.
> >>> 7) For structural-mount the "mount-points" table is returned as a
> >>> normal oper data YANG module in the mounting device, whereas for
> >>> ysdl, protocol extensions would be required to NETCONF/RESTCONF to
> >>> access the schema meta-data.
> >> First, structural-mount uses an extension that has to be considered
> >> mandatory because otherwise no interoperability can take place. So I
> >> don't think that it seamlessly integrates into NETCONF/RESTCONF.
> > I think that only clients and devices that need to mount other models w=
ould
> need to support it.  Whether this means it becomes mandatory would
> presumable depend on how widely the mount node used in standard YANG
> models.
> >
> >>
> >> And second, I actually considered to simply extend yang-library with
> >> the YSDL data, but I decided to keep it separate in order to avoid
> >> additional delays for the yang-library spec.
> >>
> >>> Considering these differences:
> >>>
> >>> For points (1) and (2), I can think of scenarios where having a
> >>> mounted device being able to provide its schema via yang-library and
> >>> for that schema to differ for different mounted devices is probably
> >>> a requirement for some plausible mount scenarios.  E.g. one that I
> >>> can think of is the case that you have a YANG controller that is
> >>> exposing an aggregated YANG model for a set of devices, it seems
> >>> that you would need to be accommodate mounted devices that are made
> >>> by different vendors and running different software versions which
> >>> would imply that their schema may also be different.
> >> Right, you would use a (dynamic) choice in this case.
> > As per above, I'm not really convinced that this works as a solution.
> >
> >>
> >>> For point (3), this is a matter of preference, I like that fact that
> >>> the mount point is explicit in the schema in structural-mount.  The
> >>> ysdl
> >> But this means using a YANG extension with all the problems regarding
> >> conformance. And this extension is quite far-reaching.
> > I would think that depends on how many models end up needing to mount
> other models.
> >
> > Thanks,
> > Rob
> >
> >
> >>
> >> Lada
> >>
> >>> meta-schema appears to be more flexible because it can in effect put
> >>> mount points anywhere, but even with structural mount this same
> >>> flexibility could presumably still be achieved by augmenting with a
> >>> mount point.
> >>>
> >>> For point (4), I think that this is useful functionality, and
> >>> perhaps if structural-mount is to be used as the base draft going
> >>> forward it might be worth considering whether the solution could be
> >>> able to cover, or be cleanly extended, to this use case.
> >>>
> >>> For point (5), I definitely think that it is beneficial that
> >>> structural-mount has an intuitive solution for RPCs and Notifications=
.
> >>>
> >>> For points (6) and (7) my gut instinct is that the structural-mount
> >>> would be easier to standardize and also less work to implement.
> >>>
> >>>
> >>> Some of my points above may be incorrect, and that might swing the
> >>> balance between the two solutions, so please correct me if I have
> >>> got anything wrong.  Otherwise, just considering the written drafts
> >>> as they stand now, my personal preference is that I would favour
> >>> using structural-mount as a starting point for a solution.
> >>>
> >>> Martin, I also have some comments/questions on the structural-mount
> >>> draft, I'll put these into a separate email.
> >>>
> >>> Thanks,
> >>> Rob
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Mon Jan 25 17:38:55 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC111ACD50; Mon, 25 Jan 2016 17:38:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level: 
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sStxC4O1uQtY; Mon, 25 Jan 2016 17:38:51 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 16D7D1ACD4F; Mon, 25 Jan 2016 17:38:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1453772322; bh=qvm1ZJ//6obVopGuhkzO+eX9jGMHFA2OKKw7wi21ajg=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=yc9apL4+I2LZxMEvkfmNGz2ExZH4SRDDx67CayO0/SFXPVL/K//GMkZOhFRtiUXVx tqI9+rsX+no8Tnk/JN9v3J/f3QesOuUc6izG5ROH2BKE1Gynuag6b2Z6dKIA1MD/Yr /BLF1HDjTZYWp+evJLFyEcM9TfO5/X5QO5TPjaHE=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Nadeau Thomas 
In-Reply-To: <05DD4741-BE90-41E9-A9D0-1D51864F75A8@juniper.net>
Date: Mon, 25 Jan 2016 20:38:46 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <750193B4-777F-4AFD-9259-88E8F2C33B6A@lucidvision.com>
References: <20160123012947.2367.17244.idtracker@ietfa.amsl.com> <05DD4741-BE90-41E9-A9D0-1D51864F75A8@juniper.net>
To: "netmod@ietf.org" 
X-Mailer: Apple Mail (2.3112)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=17 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 256, in=3127, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: Benoit Claise 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-04.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 01:38:52 -0000

[Speaking as co-chair]

	Benoit,

	I believe the document is now ready for your AD review.

	=E2=80=94Tom



> On Jan 22, 2016:8:37 PM, at 8:37 PM, Kent Watsen  =
wrote:
>=20
>=20
> [As a contributor]
>=20
> This update contains the following changes:
>=20
>=20
> 1) removed =E2=80=9C(see term)=E2=80=9D throughout
>=20
> 2) moved 2nd-half of the Asynchronous Configuration Operation term to =
new requirement 2-B
>=20
> 3) moved the Backwards Compatibility to new requirement 5
>=20
> 4) made some may/MAY/SHOULD/MUST changes (as discussed on list)
>=20
> 5) replaced map/mapping with relate/relationships
>=20
>=20
> Please see the diff for details.
>=20
> Thanks,
> Kent
>=20
>=20
>=20
>=20
>=20
> On 1/22/16, 8:29 PM, "netmod on behalf of internet-drafts@ietf.org" =
 wrote:
>=20
>>=20
>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>> This draft is a work item of the NETCONF Data Modeling Language =
Working Group of the IETF.
>>=20
>>       Title           : Terminology and Requirements for Enhanced =
Handling of Operational State
>>       Authors         : Kent Watsen
>>                         Thomas Nadeau
>> 	Filename        : draft-ietf-netmod-opstate-reqs-04.txt
>> 	Pages           : 6
>> 	Date            : 2016-01-22
>>=20
>> Abstract:
>>  This document primarily regards the difference between the intended
>>  configuration and the applied configuration of a device and how
>>  intended and applied configuration relate to the operational state =
of
>>  a device.  This document defines requirements for the applied
>>  configuration's data model and its values, as well as for enabling a
>>  client to know when a configuration has been fully applied or not,
>>  how to access operational state, and how to relate intended
>>  configuration nodes to applied configuration and derived state =
nodes.
>>=20
>>=20
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/
>>=20
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-04
>>=20
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-opstate-reqs-04
>>=20
>>=20
>> Please note that it may take a couple of minutes from the time of =
submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> _______________________________________________
>> 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


From nobody Tue Jan 26 02:19:33 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D7B1A90D7; Tue, 26 Jan 2016 02:19:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEC2HaNGPnu2; Tue, 26 Jan 2016 02:19:26 -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 45B701A90A4; Tue, 26 Jan 2016 02:19:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3229; q=dns/txt; s=iport; t=1453803565; x=1455013165; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Cs9fcHs2vFcRkmxVJ48DyZxO2K4uizE4mK+uX5Z3Pfc=; b=jiGChuY0fCqLFfbBwEoi9pw3IxS0vVaqJMkRqAyH0Sc6xWapm+kVIWu4 96Z8BfKw1sp/5egdV4Bpvjun0dCjNvt2Vwd/yMpL9M+HJ0YBOoaYWRxlr xlEInO/O4uqq/MuhLZ3rDwuffX4XfOFqsCCeoMVuBVgCuNLqePoyD1SBU o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQCYR6dW/xbLJq1ehAxtiFeyGQENg?= =?us-ascii?q?WMYCoUjSgKBfRQBAQEBAQEBgQqEQgEBBAEBASAPAQU2BAYBEAsOCgICBRYLAgI?= =?us-ascii?q?JAwIBAgEVMAYBDAYCAQGIFw6vJY8iAQEBAQEBAQEBAQEBAQEBAQEBAQEBFXuFN?= =?us-ascii?q?4Rth0yBOgEElnmFRogQgV5Kg3qDBIVThXKEfoNTHgEBQoNqOy6IRAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.22,349,1449532800"; d="scan'208";a="648783031"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jan 2016 10:19:23 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u0QAJMcw001482; Tue, 26 Jan 2016 10:19:23 GMT
To: Nadeau Thomas , "netmod@ietf.org" 
References: <20160123012947.2367.17244.idtracker@ietfa.amsl.com> <05DD4741-BE90-41E9-A9D0-1D51864F75A8@juniper.net> <750193B4-777F-4AFD-9259-88E8F2C33B6A@lucidvision.com>
From: Benoit Claise 
Message-ID: <56A7482A.3060304@cisco.com>
Date: Tue, 26 Jan 2016 11:19:22 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <750193B4-777F-4AFD-9259-88E8F2C33B6A@lucidvision.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: Benoit Claise 
Subject: Re: [netmod] [yang-doctors] I-D Action: draft-ietf-netmod-opstate-reqs-04.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 10:19:31 -0000

Thanks Tom,

I believe the draft is good to go to IETF LC.
Once I have the write-up, I will progress it.

Regards, Benoit
> [Speaking as co-chair]
>
> 	Benoit,
>
> 	I believe the document is now ready for your AD review.
>
> 	—Tom
>
>
>
>> On Jan 22, 2016:8:37 PM, at 8:37 PM, Kent Watsen  wrote:
>>
>>
>> [As a contributor]
>>
>> This update contains the following changes:
>>
>>
>> 1) removed “(see term)” throughout
>>
>> 2) moved 2nd-half of the Asynchronous Configuration Operation term to new requirement 2-B
>>
>> 3) moved the Backwards Compatibility to new requirement 5
>>
>> 4) made some may/MAY/SHOULD/MUST changes (as discussed on list)
>>
>> 5) replaced map/mapping with relate/relationships
>>
>>
>> Please see the diff for details.
>>
>> Thanks,
>> Kent
>>
>>
>>
>>
>>
>> On 1/22/16, 8:29 PM, "netmod on behalf of internet-drafts@ietf.org"  wrote:
>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>> This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF.
>>>
>>>        Title           : Terminology and Requirements for Enhanced Handling of Operational State
>>>        Authors         : Kent Watsen
>>>                          Thomas Nadeau
>>> 	Filename        : draft-ietf-netmod-opstate-reqs-04.txt
>>> 	Pages           : 6
>>> 	Date            : 2016-01-22
>>>
>>> Abstract:
>>>   This document primarily regards the difference between the intended
>>>   configuration and the applied configuration of a device and how
>>>   intended and applied configuration relate to the operational state of
>>>   a device.  This document defines requirements for the applied
>>>   configuration's data model and its values, as well as for enabling a
>>>   client to know when a configuration has been fully applied or not,
>>>   how to access operational state, and how to relate intended
>>>   configuration nodes to applied configuration and derived state nodes.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/
>>>
>>> There's also a htmlized version available at:
>>> https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-04
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-opstate-reqs-04
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> 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
> _______________________________________________
> yang-doctors mailing list
> yang-doctors@ietf.org
> https://www.ietf.org/mailman/listinfo/yang-doctors


From nobody Tue Jan 26 04:33:01 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28D31B2FDD for ; Tue, 26 Jan 2016 04:33:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id td9En3JMLe_r for ; Tue, 26 Jan 2016 04:32:58 -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 2480D1B2FDC for ; Tue, 26 Jan 2016 04:32:58 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9A36F8DC; Tue, 26 Jan 2016 13:32:56 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id pTqJF5T2t-Bg; Tue, 26 Jan 2016 13:32:55 +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, 26 Jan 2016 13:32:55 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8F5E020033; Tue, 26 Jan 2016 13:32:55 +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 OsA41cqrWTr8; Tue, 26 Jan 2016 13:32: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 9AA162002C; Tue, 26 Jan 2016 13:32:53 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 166DC39B9AE5; Tue, 26 Jan 2016 13:32:51 +0100 (CET)
Date: Tue, 26 Jan 2016 13:32:51 +0100
From: Juergen Schoenwaelder 
To: Robert Wilton 
Message-ID: <20160126123249.GA52489@elstar.local>
Mail-Followup-To: Robert Wilton , Kent Watsen , "netmod@ietf.org" 
References:   <20160110112122.GA39699@elstar.local> <56938BC6.80707@cisco.com> <20160111112629.GA41791@elstar.local> <56992602.7020700@cisco.com> <20160115173946.GA187@elstar.local>  <20160116103956.GC85460@elstar.local> <569CB4B3.3040308@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <569CB4B3.3040308@cisco.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 12:33:00 -0000

On Mon, Jan 18, 2016 at 09:47:31AM +0000, Robert Wilton wrote:
> 
> 
> As I understand it, what you are proposing here is not what the section 
> 4 requirements were intended to express.
> 
> The section 4 requirements are meant to be at the YANG schema level, 
> i.e. illustrating possible relationships between YANG schema nodes. E.g. 
> for a particular interface IP address they wouldn't be able to indicate 
> whether it was actually configured by explicit IP address configuration 
> or due to DHCP.  They would only be able to tell which configurations 
> nodes could influence a particular derived state node.

I am confused and I may not understand your example. My point is that
an operationally used IP address can be there for a variety of reasons
and the reasons depend on runtime state not on schema structure.

> I think that there are a couple of cases where this relationship is useful:
> (1) If you modify a config node, it allows the client to know (in 
> advance) which derived state nodes may be affected and hence should be 
> retrieved to confirm the change.
> (2) Conversely, if a derived state note has an unexpected value, it 
> allows a client to know which configuration nodes it should retrieve to 
> try and infer what the cause of the value is.
> 
> If I understand your proposal, then what you are proposing is meta-data 
> annotations of the derived state nodes in the data tree. I.e. the 
> annotations would allow you to tell you whether a particular interface 
> IP address had that value due to explicit IP address configuration or 
> because it was allocated by DHCP.  I agree that this is useful, but I 
> think that it is very hard to implement (on the systems that I'm 
> familiar with) and is also beyond the requirement as originally stated 
> by the opstate requirements draft.

I agree its hard to implement in general but I am not sure why the
other proposal would be any simpler to implement. Your instrumentation
is either able to keep track of 'why something has a certain value' or
it is not.

> As such, I think that we should restrict the scope of the requirements 
> draft (and proposed solutions) to YANG schema level annotations that are 
> easier to solve.  If you agree, then do we need to tweak the text of 
> requirement 4 to make this explicit?

But this approach requires to partition things artificially. For
example, I can't have a simple list of IP addresses used by the
interface anymore but instead I need to have a list of IP address
coming from static config, a list of IP addresses coming from DHCP, a
list of IP addresses coming from SLAAC and so on. I seriously can't
imagine that debugging network configurations becomes simpler if we
spread around the information one needs to look at in several branches
of the data model. [I hope I completely misunderstand requirement 4.]

/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 26 06:19:08 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AECF1B29EA for ; Tue, 26 Jan 2016 06:19:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vk1-ChKCY3IO for ; Tue, 26 Jan 2016 06:19:05 -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 D1F2F1B29DB for ; Tue, 26 Jan 2016 06:19:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5346; q=dns/txt; s=iport; t=1453817945; x=1455027545; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=vtaDZqNckk8U0krNQIhhU6KFiIjv9KGopyEaWHhGIvo=; b=l+hGg4q/ggB/cvsMhfXQ0slDvJn2SkXUa1vqOJ7wLDkBlRarPKwKWzps zYhEupKU7zXjDhXGBo97KgVXHXdLoD/ihnMAUT5nyw2Y0QS24UVAOEyyN 9kowhfQOKSZDeCDjppCNrXMX1PCDgkwu97EiLXXeXOVr81cJYkj6c9piI c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CsBAB4f6dW/xbLJq1ehAxtiFe0CySFI?= =?us-ascii?q?UoCghEBAQEBAQGBC4RBAQEBAwE4OgYRCw4KCRYPCQMCAQIBRQYBDAgBAReHeAg?= =?us-ascii?q?OvlwBAQEBAQEBAQEBAQEBAQEBAQEBARIEhjKEbYkGAQSWeYVGiBCBXodIhVOKc?= =?us-ascii?q?INTYoNpPC6IRAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.22,350,1449532800"; d="scan'208";a="623768585"
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; 26 Jan 2016 14:19:02 +0000
Received: from [10.63.23.112] (dhcp-ensft1-uk-vla370-10-63-23-112.cisco.com [10.63.23.112]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u0QEJ2A1031455; Tue, 26 Jan 2016 14:19:02 GMT
To: Kent Watsen , "netmod@ietf.org" 
References:   <20160110112122.GA39699@elstar.local> <56938BC6.80707@cisco.com> <20160111112629.GA41791@elstar.local> <56992602.7020700@cisco.com> <20160115173946.GA187@elstar.local>  <20160116103956.GC85460@elstar.local> <569CB4B3.3040308@cisco.com> <20160126123249.GA52489@elstar.local>
From: Robert Wilton 
Message-ID: <56A78054.1010904@cisco.com>
Date: Tue, 26 Jan 2016 14:19:00 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <20160126123249.GA52489@elstar.local>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 14:19:07 -0000

Hi Juergen,

Hopefully my explanations below help clarify.

On 26/01/2016 12:32, Juergen Schoenwaelder wrote:
> On Mon, Jan 18, 2016 at 09:47:31AM +0000, Robert Wilton wrote:
>>
>> As I understand it, what you are proposing here is not what the section
>> 4 requirements were intended to express.
>>
>> The section 4 requirements are meant to be at the YANG schema level,
>> i.e. illustrating possible relationships between YANG schema nodes. E.g.
>> for a particular interface IP address they wouldn't be able to indicate
>> whether it was actually configured by explicit IP address configuration
>> or due to DHCP.  They would only be able to tell which configurations
>> nodes could influence a particular derived state node.
> I am confused and I may not understand your example. My point is that
> an operationally used IP address can be there for a variety of reasons
> and the reasons depend on runtime state not on schema structure.
Yes, exactly.

But this requirements draft is based on the improvements that the 
operators would like to see to YANG/NETCONF/etc to make it easier for 
them to use/deploy.

For this section 4 requirements, my understanding is that they are not 
asking to know why a particular operation node has a particular value, 
they are only asking for an indication of which configuration leaves 
could influence its value.  Solving the latter is easier and can be 
implemented at the schema level.

To support my interpretation I recall that Rob Shakir, at the first 
Netmod WG meeting IETF 94, indicated that their proposed opstate 
solution draft (e.g. draft-openconfig-netmod-opstate-01) met all the 
opstate requirements.  Their draft doesn't have any mechanism to 
indicate why a particular state leaf has a particular value, but it does 
provide a schema level relationship between the configuration and 
operation state nodes - i.e. the co-located config and state containers 
that they consistently use throughout the OpenConfig schema.

>
>> I think that there are a couple of cases where this relationship is useful:
>> (1) If you modify a config node, it allows the client to know (in
>> advance) which derived state nodes may be affected and hence should be
>> retrieved to confirm the change.
>> (2) Conversely, if a derived state note has an unexpected value, it
>> allows a client to know which configuration nodes it should retrieve to
>> try and infer what the cause of the value is.
>>
>> If I understand your proposal, then what you are proposing is meta-data
>> annotations of the derived state nodes in the data tree. I.e. the
>> annotations would allow you to tell you whether a particular interface
>> IP address had that value due to explicit IP address configuration or
>> because it was allocated by DHCP.  I agree that this is useful, but I
>> think that it is very hard to implement (on the systems that I'm
>> familiar with) and is also beyond the requirement as originally stated
>> by the opstate requirements draft.
> I agree its hard to implement in general but I am not sure why the
> other proposal would be any simpler to implement. Your instrumentation
> is either able to keep track of 'why something has a certain value' or
> it is not.
I'm saying that there is no requirement (at least from the opstate 
draft) to generally track "why something has a certain value" at all.


>
>> As such, I think that we should restrict the scope of the requirements
>> draft (and proposed solutions) to YANG schema level annotations that are
>> easier to solve.  If you agree, then do we need to tweak the text of
>> requirement 4 to make this explicit?
> But this approach requires to partition things artificially. For
> example, I can't have a simple list of IP addresses used by the
> interface anymore but instead I need to have a list of IP address
> coming from static config, a list of IP addresses coming from DHCP, a
> list of IP addresses coming from SLAAC and so on. I seriously can't
> imagine that debugging network configurations becomes simpler if we
> spread around the information one needs to look at in several branches
> of the data model. [I hope I completely misunderstand requirement 4.]

I don't think that they are asking/suggesting separate lists of 
operational IP addresses.

Taking the OpenConfig IP YANG model as an example 
(https://github.com/openconfig/public/blob/master/release/models/interfaces/openconfig-if-ip.yang):

They have a list of IP addresses.  Each entry contains:
  - the configured IP address (if any),
  - the operational IP address,
  - an enum indicating the source of the operational IP address value 
(static, dhcp, link_layer, random or other).

Their schema doesn't completely follow the opstate draft requirements.  
In particular, they should have separate leaves for the applied 
configuration value vs the operational state value.  I presume that this 
will be fixed at some point.

In summary, I think that knowing the source of a piece of operational 
data is valuable in some circumstances (e.g. IP addresses), but probably 
isn't actually required for most operational values, and at least from 
an opstate perspective isn't a general requirement that needs to be 
solved with a generic solution.

Rob


>
> /js
>


From nobody Tue Jan 26 06:31:46 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77DA41B2A36 for ; Tue, 26 Jan 2016 06:31:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RCDLjNi_pux for ; Tue, 26 Jan 2016 06:31:43 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7521B2A37 for ; Tue, 26 Jan 2016 06:31:43 -0800 (PST)
Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id 8DEC51AE00B6; Tue, 26 Jan 2016 15:31:41 +0100 (CET)
Date: Tue, 26 Jan 2016 15:33:25 +0100 (CET)
Message-Id: <20160126.153325.1208871148784919958.mbj@tail-f.com>
To: rwilton@cisco.com
From: Martin Bjorklund 
In-Reply-To: <56A78054.1010904@cisco.com>
References: <569CB4B3.3040308@cisco.com> <20160126123249.GA52489@elstar.local> <56A78054.1010904@cisco.com>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 14:31:45 -0000

Robert Wilton  wrote:
> Hi Juergen,
> 
> Hopefully my explanations below help clarify.
> 
> On 26/01/2016 12:32, Juergen Schoenwaelder wrote:
> > On Mon, Jan 18, 2016 at 09:47:31AM +0000, Robert Wilton wrote:
> >>
> >> As I understand it, what you are proposing here is not what the
> >> section
> >> 4 requirements were intended to express.
> >>
> >> The section 4 requirements are meant to be at the YANG schema level,
> >> i.e. illustrating possible relationships between YANG schema
> >> nodes. E.g.
> >> for a particular interface IP address they wouldn't be able to
> >> indicate
> >> whether it was actually configured by explicit IP address
> >> configuration
> >> or due to DHCP.  They would only be able to tell which configurations
> >> nodes could influence a particular derived state node.
> > I am confused and I may not understand your example. My point is that
> > an operationally used IP address can be there for a variety of reasons
> > and the reasons depend on runtime state not on schema structure.
> Yes, exactly.
> 
> But this requirements draft is based on the improvements that the
> operators would like to see to YANG/NETCONF/etc to make it easier for
> them to use/deploy.
> 
> For this section 4 requirements, my understanding is that they are not
> asking to know why a particular operation node has a particular value,
> they are only asking for an indication of which configuration leaves
> could influence its value.  Solving the latter is easier and can be
> implemented at the schema level.
> 
> To support my interpretation I recall that Rob Shakir, at the first
> Netmod WG meeting IETF 94, indicated that their proposed opstate
> solution draft (e.g. draft-openconfig-netmod-opstate-01) met all the
> opstate requirements.  Their draft doesn't have any mechanism to
> indicate why a particular state leaf has a particular value, but it
> does provide a schema level relationship between the configuration and
> operation state nodes - i.e. the co-located config and state
> containers that they consistently use throughout the OpenConfig
> schema.
> 
> >
> >> I think that there are a couple of cases where this relationship is
> >> useful:
> >> (1) If you modify a config node, it allows the client to know (in
> >> advance) which derived state nodes may be affected and hence should be
> >> retrieved to confirm the change.
> >> (2) Conversely, if a derived state note has an unexpected value, it
> >> allows a client to know which configuration nodes it should retrieve
> >> to
> >> try and infer what the cause of the value is.
> >>
> >> If I understand your proposal, then what you are proposing is
> >> meta-data
> >> annotations of the derived state nodes in the data tree. I.e. the
> >> annotations would allow you to tell you whether a particular interface
> >> IP address had that value due to explicit IP address configuration or
> >> because it was allocated by DHCP.  I agree that this is useful, but I
> >> think that it is very hard to implement (on the systems that I'm
> >> familiar with) and is also beyond the requirement as originally stated
> >> by the opstate requirements draft.
> > I agree its hard to implement in general but I am not sure why the
> > other proposal would be any simpler to implement. Your instrumentation
> > is either able to keep track of 'why something has a certain value' or
> > it is not.
> I'm saying that there is no requirement (at least from the opstate
> draft) to generally track "why something has a certain value" at all.
> 
> 
> >
> >> As such, I think that we should restrict the scope of the requirements
> >> draft (and proposed solutions) to YANG schema level annotations that
> >> are
> >> easier to solve.  If you agree, then do we need to tweak the text of
> >> requirement 4 to make this explicit?
> > But this approach requires to partition things artificially. For
> > example, I can't have a simple list of IP addresses used by the
> > interface anymore but instead I need to have a list of IP address
> > coming from static config, a list of IP addresses coming from DHCP, a
> > list of IP addresses coming from SLAAC and so on. I seriously can't
> > imagine that debugging network configurations becomes simpler if we
> > spread around the information one needs to look at in several branches
> > of the data model. [I hope I completely misunderstand requirement 4.]
> 
> I don't think that they are asking/suggesting separate lists of
> operational IP addresses.
> 
> Taking the OpenConfig IP YANG model as an example
> (https://github.com/openconfig/public/blob/master/release/models/interfaces/openconfig-if-ip.yang):
> 
> They have a list of IP addresses.  Each entry contains:
>  - the configured IP address (if any),
>  - the operational IP address,
>  - an enum indicating the source of the operational IP address value
>  - (static, dhcp, link_layer, random or other).

I assume you refer to this list:

      list address {
        key ip;
        description
         "The list of configured IPv4 addresses on the interface.";

        leaf ip {
          type leafref {
            path "../ocip:config/ocip:ip";
          }
          description "References the configured IP address";
        }

        container config {
          description "Configuration data for each configured IPv4
          address on the interface";

          uses ipv4-config-address;
        }

        container state {

          config false;
          description "Operational state data for each IPv4 address
          configured on the interface";

          uses ipv4-config-address;
          uses ipv4-state-address;
        }

      }



Note how the key contains the "configured IP address" (and it is a
config true list).   So this list cannot contain addresses that are
not configured.


/martin


> Their schema doesn't completely follow the opstate draft requirements.
> In particular, they should have separate leaves for the applied
> configuration value vs the operational state value.  I presume that
> this will be fixed at some point.
> 
> In summary, I think that knowing the source of a piece of operational
> data is valuable in some circumstances (e.g. IP addresses), but
> probably isn't actually required for most operational values, and at
> least from an opstate perspective isn't a general requirement that
> needs to be solved with a generic solution.
> 
> Rob
> 
> 
> >
> > /js
> >
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Tue Jan 26 06:50:47 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3588B1B2A7D for ; Tue, 26 Jan 2016 06:50:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.652
X-Spam-Level: 
X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOMGV45VFccq for ; Tue, 26 Jan 2016 06:50:44 -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 D6F171B2A60 for ; Tue, 26 Jan 2016 06:50:43 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:a8b8:32fe:2ff0:5b4c] (unknown [IPv6:2001:718:1a02:1:a8b8:32fe:2ff0:5b4c]) by mail.nic.cz (Postfix) with ESMTPSA id 99D4A1810CF; Tue, 26 Jan 2016 15:50:41 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1453819841; bh=8RpbeGgh84plEzDUz55BBJMM1tU6vSYiNC4qADg9IyY=; h=From:Date:To; b=w2CSliC5IQ2oenU1FIX3I60d8tuvZVAycvZe0XE0MuUp2HkU6AsSYVzn/fRWpCLsp vHLgjetiLI2T9gXqcKPqLYQsSa/yKMz+eGUW24EG9K76/4fRRNUjZc1RcE3lDsMWdT zE0m2pwYdBXAw7uZNmaxZspMH+0fvauB8G0zjsII=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: <56A78054.1010904@cisco.com>
Date: Tue, 26 Jan 2016 15:50:43 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <20160110112122.GA39699@elstar.local> <56938BC6.80707@cisco.com> <20160111112629.GA41791@elstar.local> <56992602.7020700@cisco.com> <20160115173946.GA187@elstar.local>  <20160116103956.GC85460@elstar.local> <569CB4B3.3040308@cisco.com> <20160126123249.GA52489@elstar.local> <56A78054.1010904@cisco.com>
To: Robert Wilton 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 14:50:46 -0000

> On 26 Jan 2016, at 15:19, Robert Wilton  wrote:
>=20
> Hi Juergen,
>=20
> Hopefully my explanations below help clarify.
>=20
> On 26/01/2016 12:32, Juergen Schoenwaelder wrote:
>> On Mon, Jan 18, 2016 at 09:47:31AM +0000, Robert Wilton wrote:
>>>=20
>>> As I understand it, what you are proposing here is not what the =
section
>>> 4 requirements were intended to express.
>>>=20
>>> The section 4 requirements are meant to be at the YANG schema level,
>>> i.e. illustrating possible relationships between YANG schema nodes. =
E.g.
>>> for a particular interface IP address they wouldn't be able to =
indicate
>>> whether it was actually configured by explicit IP address =
configuration
>>> or due to DHCP.  They would only be able to tell which =
configurations
>>> nodes could influence a particular derived state node.
>> I am confused and I may not understand your example. My point is that
>> an operationally used IP address can be there for a variety of =
reasons
>> and the reasons depend on runtime state not on schema structure.
> Yes, exactly.
>=20
> But this requirements draft is based on the improvements that the =
operators would like to see to YANG/NETCONF/etc to make it easier for =
them to use/deploy.
>=20
> For this section 4 requirements, my understanding is that they are not =
asking to know why a particular operation node has a particular value, =
they are only asking for an indication of which configuration leaves =
could influence its value.  Solving the latter is easier and can be =
implemented at the schema level.
>=20
> To support my interpretation I recall that Rob Shakir, at the first =
Netmod WG meeting IETF 94, indicated that their proposed opstate =
solution draft (e.g. draft-openconfig-netmod-opstate-01) met all the =
opstate requirements.  Their draft doesn't have any mechanism to =
indicate why a particular state leaf has a particular value, but it does =
provide a schema level relationship between the configuration and =
operation state nodes - i.e. the co-located config and state containers =
that they consistently use throughout the OpenConfig schema.

This can IMO work only if the schemas of configuration and state data =
are identical or very similar. As an example, take RIBs (state data) and =
a list of static routes (configuration). There is a certain relationship =
between them, but the exact outcome depends on a number of other =
factors. I don't see how they can be co-located, or how the relationship =
can otherwise be formally expressed.

Lada

>=20
>>=20
>>> I think that there are a couple of cases where this relationship is =
useful:
>>> (1) If you modify a config node, it allows the client to know (in
>>> advance) which derived state nodes may be affected and hence should =
be
>>> retrieved to confirm the change.
>>> (2) Conversely, if a derived state note has an unexpected value, it
>>> allows a client to know which configuration nodes it should retrieve =
to
>>> try and infer what the cause of the value is.
>>>=20
>>> If I understand your proposal, then what you are proposing is =
meta-data
>>> annotations of the derived state nodes in the data tree. I.e. the
>>> annotations would allow you to tell you whether a particular =
interface
>>> IP address had that value due to explicit IP address configuration =
or
>>> because it was allocated by DHCP.  I agree that this is useful, but =
I
>>> think that it is very hard to implement (on the systems that I'm
>>> familiar with) and is also beyond the requirement as originally =
stated
>>> by the opstate requirements draft.
>> I agree its hard to implement in general but I am not sure why the
>> other proposal would be any simpler to implement. Your =
instrumentation
>> is either able to keep track of 'why something has a certain value' =
or
>> it is not.
> I'm saying that there is no requirement (at least from the opstate =
draft) to generally track "why something has a certain value" at all.
>=20
>=20
>>=20
>>> As such, I think that we should restrict the scope of the =
requirements
>>> draft (and proposed solutions) to YANG schema level annotations that =
are
>>> easier to solve.  If you agree, then do we need to tweak the text of
>>> requirement 4 to make this explicit?
>> But this approach requires to partition things artificially. For
>> example, I can't have a simple list of IP addresses used by the
>> interface anymore but instead I need to have a list of IP address
>> coming from static config, a list of IP addresses coming from DHCP, a
>> list of IP addresses coming from SLAAC and so on. I seriously can't
>> imagine that debugging network configurations becomes simpler if we
>> spread around the information one needs to look at in several =
branches
>> of the data model. [I hope I completely misunderstand requirement 4.]
>=20
> I don't think that they are asking/suggesting separate lists of =
operational IP addresses.
>=20
> Taking the OpenConfig IP YANG model as an example =
(https://github.com/openconfig/public/blob/master/release/models/interface=
s/openconfig-if-ip.yang):
>=20
> They have a list of IP addresses.  Each entry contains:
> - the configured IP address (if any),
> - the operational IP address,
> - an enum indicating the source of the operational IP address value =
(static, dhcp, link_layer, random or other).
>=20
> Their schema doesn't completely follow the opstate draft requirements. =
 In particular, they should have separate leaves for the applied =
configuration value vs the operational state value.  I presume that this =
will be fixed at some point.
>=20
> In summary, I think that knowing the source of a piece of operational =
data is valuable in some circumstances (e.g. IP addresses), but probably =
isn't actually required for most operational values, and at least from =
an opstate perspective isn't a general requirement that needs to be =
solved with a generic solution.
>=20
> Rob
>=20
>=20
>>=20
>> /js
>>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





From nobody Tue Jan 26 06:52:40 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA411B2A81 for ; Tue, 26 Jan 2016 06:52:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ma0VZoN5za4y for ; Tue, 26 Jan 2016 06:52:36 -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 E3C9C1B2A66 for ; Tue, 26 Jan 2016 06:52:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10087; q=dns/txt; s=iport; t=1453819956; x=1455029556; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=46V+XcKcdkYmYzImZOK5mMJhF+XwrQmi6wV65/8I4pY=; b=BSyAS14YbEUwHJAlWBgH4sXMOXCJh+qusntHkXMp1Bc7xdQNM7pn4Pp8 R+f8ATxm/aIZzH8tqiqZ8iLALr0+3n4MIt9oq/UvVUI7n6SfE5l76AfkP we5EO3UhOyQ+6kUCvgoqt3MTGAPdWZm9GuQCJvFIUGw/dw+sh4+irz9PX k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQAZh6dW/xbLJq1ehAxtiFeyGgENg?= =?us-ascii?q?WMYDIUhSgKBfxQBAQEBAQEBgQqEQQEBAQMBAQEBNTYEBgEQCw4KCRYPCQMCAQI?= =?us-ascii?q?BFTAGDQYCAQEXh3gIDr5jAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGMoRtiQYBB?= =?us-ascii?q?I0tiUyFRogQgV6HSIVTinCDUx4BAUKDaTwuAYhDAQEB?=
X-IronPort-AV: E=Sophos;i="5.22,350,1449532800"; d="scan'208";a="648789424"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jan 2016 14:52:33 +0000
Received: from [10.63.23.112] (dhcp-ensft1-uk-vla370-10-63-23-112.cisco.com [10.63.23.112]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u0QEqX91021520; Tue, 26 Jan 2016 14:52:33 GMT
To: Martin Bjorklund 
References: <569CB4B3.3040308@cisco.com> <20160126123249.GA52489@elstar.local> <56A78054.1010904@cisco.com> <20160126.153325.1208871148784919958.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: <56A7882F.3090308@cisco.com>
Date: Tue, 26 Jan 2016 14:52:31 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <20160126.153325.1208871148784919958.mbj@tail-f.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 14:52:39 -0000

Hi Martin,

On 26/01/2016 14:33, Martin Bjorklund wrote:
> Robert Wilton  wrote:
>> Hi Juergen,
>>
>> Hopefully my explanations below help clarify.
>>
>> On 26/01/2016 12:32, Juergen Schoenwaelder wrote:
>>> On Mon, Jan 18, 2016 at 09:47:31AM +0000, Robert Wilton wrote:
>>>> As I understand it, what you are proposing here is not what the
>>>> section
>>>> 4 requirements were intended to express.
>>>>
>>>> The section 4 requirements are meant to be at the YANG schema level,
>>>> i.e. illustrating possible relationships between YANG schema
>>>> nodes. E.g.
>>>> for a particular interface IP address they wouldn't be able to
>>>> indicate
>>>> whether it was actually configured by explicit IP address
>>>> configuration
>>>> or due to DHCP.  They would only be able to tell which configurations
>>>> nodes could influence a particular derived state node.
>>> I am confused and I may not understand your example. My point is that
>>> an operationally used IP address can be there for a variety of reasons
>>> and the reasons depend on runtime state not on schema structure.
>> Yes, exactly.
>>
>> But this requirements draft is based on the improvements that the
>> operators would like to see to YANG/NETCONF/etc to make it easier for
>> them to use/deploy.
>>
>> For this section 4 requirements, my understanding is that they are not
>> asking to know why a particular operation node has a particular value,
>> they are only asking for an indication of which configuration leaves
>> could influence its value.  Solving the latter is easier and can be
>> implemented at the schema level.
>>
>> To support my interpretation I recall that Rob Shakir, at the first
>> Netmod WG meeting IETF 94, indicated that their proposed opstate
>> solution draft (e.g. draft-openconfig-netmod-opstate-01) met all the
>> opstate requirements.  Their draft doesn't have any mechanism to
>> indicate why a particular state leaf has a particular value, but it
>> does provide a schema level relationship between the configuration and
>> operation state nodes - i.e. the co-located config and state
>> containers that they consistently use throughout the OpenConfig
>> schema.
>>
>>>> I think that there are a couple of cases where this relationship is
>>>> useful:
>>>> (1) If you modify a config node, it allows the client to know (in
>>>> advance) which derived state nodes may be affected and hence should be
>>>> retrieved to confirm the change.
>>>> (2) Conversely, if a derived state note has an unexpected value, it
>>>> allows a client to know which configuration nodes it should retrieve
>>>> to
>>>> try and infer what the cause of the value is.
>>>>
>>>> If I understand your proposal, then what you are proposing is
>>>> meta-data
>>>> annotations of the derived state nodes in the data tree. I.e. the
>>>> annotations would allow you to tell you whether a particular interface
>>>> IP address had that value due to explicit IP address configuration or
>>>> because it was allocated by DHCP.  I agree that this is useful, but I
>>>> think that it is very hard to implement (on the systems that I'm
>>>> familiar with) and is also beyond the requirement as originally stated
>>>> by the opstate requirements draft.
>>> I agree its hard to implement in general but I am not sure why the
>>> other proposal would be any simpler to implement. Your instrumentation
>>> is either able to keep track of 'why something has a certain value' or
>>> it is not.
>> I'm saying that there is no requirement (at least from the opstate
>> draft) to generally track "why something has a certain value" at all.
>>
>>
>>>> As such, I think that we should restrict the scope of the requirements
>>>> draft (and proposed solutions) to YANG schema level annotations that
>>>> are
>>>> easier to solve.  If you agree, then do we need to tweak the text of
>>>> requirement 4 to make this explicit?
>>> But this approach requires to partition things artificially. For
>>> example, I can't have a simple list of IP addresses used by the
>>> interface anymore but instead I need to have a list of IP address
>>> coming from static config, a list of IP addresses coming from DHCP, a
>>> list of IP addresses coming from SLAAC and so on. I seriously can't
>>> imagine that debugging network configurations becomes simpler if we
>>> spread around the information one needs to look at in several branches
>>> of the data model. [I hope I completely misunderstand requirement 4.]
>> I don't think that they are asking/suggesting separate lists of
>> operational IP addresses.
>>
>> Taking the OpenConfig IP YANG model as an example
>> (https://github.com/openconfig/public/blob/master/release/models/interfaces/openconfig-if-ip.yang):
>>
>> They have a list of IP addresses.  Each entry contains:
>>   - the configured IP address (if any),
>>   - the operational IP address,
>>   - an enum indicating the source of the operational IP address value
>>   - (static, dhcp, link_layer, random or other).
> I assume you refer to this list:
Yes.

>
>        list address {
>          key ip;
>          description
>           "The list of configured IPv4 addresses on the interface.";
>
>          leaf ip {
>            type leafref {
>              path "../ocip:config/ocip:ip";
>            }
>            description "References the configured IP address";
>          }
>
>          container config {
>            description "Configuration data for each configured IPv4
>            address on the interface";
>
>            uses ipv4-config-address;
>          }
>
>          container state {
>
>            config false;
>            description "Operational state data for each IPv4 address
>            configured on the interface";
>
>            uses ipv4-config-address;
>            uses ipv4-state-address;
>          }
>
>        }
>
>
>
> Note how the key contains the "configured IP address" (and it is a
> config true list).   So this list cannot contain addresses that are
> not configured.
OK, yes.  I had missed that.

I presume that they would ideally like this list to contain all IP 
addresses on an interface whether configured or operational. Otherwise 
if it contains just the list of configured addresses then the "origin" 
leaf in the ipv4-state-address grouping seems pretty pointless since the 
only sane value that it could hold is STATIC :-)

I suspect that this issue ties back to sections 8.1.2 and 9.2 of 
https://www.ietf.org/archive/id/draft-openconfig-netmod-opstate-01.txt 
(text reproduced below) where they would like the YANG schema to have a 
combined list of configured and state entries.

8.1.2.  Handling lists

    In YANG 1.0, lists have requirements that complicate the creation of
    the parallel configuration and state data structures.  First, keys
    must be children of the list; they cannot be further down the data
    hierarchy within a subsequent container.  For example, the
    'interface' list cannot be keyed by /interfaces/interface/config/
    name.  Second, YANG requires that the list key is part of the
    configuration or state data in each list member.

    We consider two possible approaches for lists:

    1.  list keys appear only at the top level of the list, i.e., not
        duplicated under the 'config' or 'state' containers within the
        list

    2.  the data represented by the list key appears in the config and
        state containers, and a key with type leafref is used in the top
        level of the list pointing to the corresponding data node in the
        config (or state) container.

    Option 1 has the advantage of not duplicating data, but treats the
    data item (or items) that are keys as special cases, i.e., not
    included in the config or state containers.  Option 2 is appealing in
    that configurable data always appears in the config container, but
    requires an arguably unnecessary key pointing to the data from the
    top level of the list.

    Appendix C shows a simple example of both options.


9.2.  YANG lists as maps

    YANG has two list constructs, the 'leaf-list' which is similar to a
    list of scalars (arrays) in other programming languages, and the
    'list' which allows a keyed list of complex structures, where the key
    is also part of the data values.  As described in Section 8.1.2, the
    current requirements on YANG list keys require either duplication of
    data, or treating some data (i.e., those that comprise list keys) as
    a special case.  One solution is to generalize lists to be more like
    map data structures found in most modern programming languages, where
    each list member has a key that is not required to part of the
    configuration or state data, and also not subject to existing
    "config-under-state limitations.  This allows list keys to be
    arbitrarily defined by the user if desired, or based on values of
    data nodes.  In the latter case, the specification of which data
    nodes are used in constructing the list key could be indicated in the
    meta-data associated with the key.


Rob


>
>
> /martin
>
>
>> Their schema doesn't completely follow the opstate draft requirements.
>> In particular, they should have separate leaves for the applied
>> configuration value vs the operational state value.  I presume that
>> this will be fixed at some point.
>>
>> In summary, I think that knowing the source of a piece of operational
>> data is valuable in some circumstances (e.g. IP addresses), but
>> probably isn't actually required for most operational values, and at
>> least from an opstate perspective isn't a general requirement that
>> needs to be solved with a generic solution.
>>
>> Rob
>>
>>
>>> /js
>>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
> .
>


From nobody Tue Jan 26 07:14:29 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B229C1B2AE9 for ; Tue, 26 Jan 2016 07:14:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3_BkWGBfCwA for ; Tue, 26 Jan 2016 07:14:26 -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 EC88F1B2AE5 for ; Tue, 26 Jan 2016 07:14:25 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B9D768DA; Tue, 26 Jan 2016 16:14:24 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id LZPpJx2v9Paj; Tue, 26 Jan 2016 16:14: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; Tue, 26 Jan 2016 16:14:23 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3A84D20033; Tue, 26 Jan 2016 16:14:23 +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 MO_Bb78I5GHH; Tue, 26 Jan 2016 16:14:21 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0F0082002C; Tue, 26 Jan 2016 16:14:21 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id F41FF39C2388; Tue, 26 Jan 2016 16:14:20 +0100 (CET)
Date: Tue, 26 Jan 2016 16:14:20 +0100
From: Juergen Schoenwaelder 
To: Robert Wilton 
Message-ID: <20160126151420.GD53158@elstar.local>
Mail-Followup-To: Robert Wilton , Kent Watsen , "netmod@ietf.org" 
References: <20160110112122.GA39699@elstar.local> <56938BC6.80707@cisco.com> <20160111112629.GA41791@elstar.local> <56992602.7020700@cisco.com> <20160115173946.GA187@elstar.local>  <20160116103956.GC85460@elstar.local> <569CB4B3.3040308@cisco.com> <20160126123249.GA52489@elstar.local> <56A78054.1010904@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <56A78054.1010904@cisco.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 15:14:28 -0000

On Tue, Jan 26, 2016 at 02:19:00PM +0000, Robert Wilton wrote:
> Hi Juergen,
> 
> Hopefully my explanations below help clarify.
> 
> On 26/01/2016 12:32, Juergen Schoenwaelder wrote:
> >On Mon, Jan 18, 2016 at 09:47:31AM +0000, Robert Wilton wrote:
> >>
> >>As I understand it, what you are proposing here is not what the section
> >>4 requirements were intended to express.
> >>
> >>The section 4 requirements are meant to be at the YANG schema level,
> >>i.e. illustrating possible relationships between YANG schema nodes. E.g.
> >>for a particular interface IP address they wouldn't be able to indicate
> >>whether it was actually configured by explicit IP address configuration
> >>or due to DHCP.  They would only be able to tell which configurations
> >>nodes could influence a particular derived state node.
> >I am confused and I may not understand your example. My point is that
> >an operationally used IP address can be there for a variety of reasons
> >and the reasons depend on runtime state not on schema structure.
> Yes, exactly.
> 
> But this requirements draft is based on the improvements that the 
> operators would like to see to YANG/NETCONF/etc to make it easier for 
> them to use/deploy.
> 
> For this section 4 requirements, my understanding is that they are not 
> asking to know why a particular operation node has a particular value, 
> they are only asking for an indication of which configuration leaves 
> could influence its value.  Solving the latter is easier and can be 
> implemented at the schema level.
> 
> To support my interpretation I recall that Rob Shakir, at the first 
> Netmod WG meeting IETF 94, indicated that their proposed opstate 
> solution draft (e.g. draft-openconfig-netmod-opstate-01) met all the 
> opstate requirements.  Their draft doesn't have any mechanism to 
> indicate why a particular state leaf has a particular value, but it does 
> provide a schema level relationship between the configuration and 
> operation state nodes - i.e. the co-located config and state containers 
> that they consistently use throughout the OpenConfig schema.
> 
> >
> >>I think that there are a couple of cases where this relationship is 
> >>useful:
> >>(1) If you modify a config node, it allows the client to know (in
> >>advance) which derived state nodes may be affected and hence should be
> >>retrieved to confirm the change.
> >>(2) Conversely, if a derived state note has an unexpected value, it
> >>allows a client to know which configuration nodes it should retrieve to
> >>try and infer what the cause of the value is.
> >>
> >>If I understand your proposal, then what you are proposing is meta-data
> >>annotations of the derived state nodes in the data tree. I.e. the
> >>annotations would allow you to tell you whether a particular interface
> >>IP address had that value due to explicit IP address configuration or
> >>because it was allocated by DHCP.  I agree that this is useful, but I
> >>think that it is very hard to implement (on the systems that I'm
> >>familiar with) and is also beyond the requirement as originally stated
> >>by the opstate requirements draft.
> >I agree its hard to implement in general but I am not sure why the
> >other proposal would be any simpler to implement. Your instrumentation
> >is either able to keep track of 'why something has a certain value' or
> >it is not.
> I'm saying that there is no requirement (at least from the opstate 
> draft) to generally track "why something has a certain value" at all.
> 
> 
> >
> >>As such, I think that we should restrict the scope of the requirements
> >>draft (and proposed solutions) to YANG schema level annotations that are
> >>easier to solve.  If you agree, then do we need to tweak the text of
> >>requirement 4 to make this explicit?
> >But this approach requires to partition things artificially. For
> >example, I can't have a simple list of IP addresses used by the
> >interface anymore but instead I need to have a list of IP address
> >coming from static config, a list of IP addresses coming from DHCP, a
> >list of IP addresses coming from SLAAC and so on. I seriously can't
> >imagine that debugging network configurations becomes simpler if we
> >spread around the information one needs to look at in several branches
> >of the data model. [I hope I completely misunderstand requirement 4.]
> 
> I don't think that they are asking/suggesting separate lists of 
> operational IP addresses.
> 
> Taking the OpenConfig IP YANG model as an example 
> (https://github.com/openconfig/public/blob/master/release/models/interfaces/openconfig-if-ip.yang):
> 
> They have a list of IP addresses.  Each entry contains:
>  - the configured IP address (if any),
>  - the operational IP address,
>  - an enum indicating the source of the operational IP address value 
> (static, dhcp, link_layer, random or other).

But this ip-address-origin thing is exactly what I have been talking
about.  Now I am even more confused.
 
> In summary, I think that knowing the source of a piece of operational 
> data is valuable in some circumstances (e.g. IP addresses), but probably 
> isn't actually required for most operational values, and at least from 
> an opstate perspective isn't a general requirement that needs to be 
> solved with a generic solution.

See ip-address-origin.

/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 26 07:21:20 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6155A1B2B08 for ; Tue, 26 Jan 2016 07:21:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m06hRSRLlIqY for ; Tue, 26 Jan 2016 07:21:18 -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 62B5B1B2B0B for ; Tue, 26 Jan 2016 07:21: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 2F438948; Tue, 26 Jan 2016 16:21:16 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 2gYNEfoyaZfA; Tue, 26 Jan 2016 16:21:15 +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, 26 Jan 2016 16:21:15 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3C93120035; Tue, 26 Jan 2016 16:21:15 +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 1SCRcOfsJ0Hk; Tue, 26 Jan 2016 16:21:12 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2C63F2002C; Tue, 26 Jan 2016 16:21:11 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 1BE7739C23D5; Tue, 26 Jan 2016 16:21:11 +0100 (CET)
Date: Tue, 26 Jan 2016 16:21:11 +0100
From: Juergen Schoenwaelder 
To: Robert Wilton , Kent Watsen , "netmod@ietf.org" 
Message-ID: <20160126152110.GE53158@elstar.local>
Mail-Followup-To: Robert Wilton , Kent Watsen , "netmod@ietf.org" 
References: <56938BC6.80707@cisco.com> <20160111112629.GA41791@elstar.local> <56992602.7020700@cisco.com> <20160115173946.GA187@elstar.local>  <20160116103956.GC85460@elstar.local> <569CB4B3.3040308@cisco.com> <20160126123249.GA52489@elstar.local> <56A78054.1010904@cisco.com> <20160126151420.GD53158@elstar.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160126151420.GD53158@elstar.local>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 15:21:19 -0000

On Tue, Jan 26, 2016 at 04:14:20PM +0100, Juergen Schoenwaelder wrote:
> > 
> > They have a list of IP addresses.  Each entry contains:
> >  - the configured IP address (if any),
> >  - the operational IP address,
> >  - an enum indicating the source of the operational IP address value 
> > (static, dhcp, link_layer, random or other).
> 
> But this ip-address-origin thing is exactly what I have been talking
> about.  Now I am even more confused.
>  
> > In summary, I think that knowing the source of a piece of operational 
> > data is valuable in some circumstances (e.g. IP addresses), but probably 
> > isn't actually required for most operational values, and at least from 
> > an opstate perspective isn't a general requirement that needs to be 
> > solved with a generic solution.
> 
> See ip-address-origin.
>

Frankly, you either list all IP addresses of an interface in one place
and then you need additional information to indicate where they are
coming from (e.g., which config tweaks them) or you distribute the all
IP addresses of an interface into multiple places of the schema (which
I doubt operational people really want).

To track the origin, you can create ip-address-origin, ip-route-origin,
ip-foo-origin objects and stick them at appropriate places or you make
this metadata which you do not have to define everywhere.

This is my rather simple view of the world.

/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 26 07:25:40 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 936FC1B2AAE for ; Tue, 26 Jan 2016 07:25:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xa0MMG4Ayozi for ; Tue, 26 Jan 2016 07:25: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 1AE8D1B2A7F for ; Tue, 26 Jan 2016 07:25:37 -0800 (PST)
Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id 2EBB71AE00B6; Tue, 26 Jan 2016 16:25:36 +0100 (CET)
Date: Tue, 26 Jan 2016 16:27:20 +0100 (CET)
Message-Id: <20160126.162720.2251520034087493102.mbj@tail-f.com>
To: rwilton@cisco.com
From: Martin Bjorklund 
In-Reply-To: <56A7882F.3090308@cisco.com>
References: <56A78054.1010904@cisco.com> <20160126.153325.1208871148784919958.mbj@tail-f.com> <56A7882F.3090308@cisco.com>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 15:25:39 -0000

Robert Wilton  wrote:
> Hi Martin,
> 
> On 26/01/2016 14:33, Martin Bjorklund wrote:
> > Robert Wilton  wrote:
> >> Hi Juergen,
> >>
> >> Hopefully my explanations below help clarify.
> >>
> >> On 26/01/2016 12:32, Juergen Schoenwaelder wrote:
> >>> On Mon, Jan 18, 2016 at 09:47:31AM +0000, Robert Wilton wrote:
> >>>> As I understand it, what you are proposing here is not what the
> >>>> section
> >>>> 4 requirements were intended to express.
> >>>>
> >>>> The section 4 requirements are meant to be at the YANG schema level,
> >>>> i.e. illustrating possible relationships between YANG schema
> >>>> nodes. E.g.
> >>>> for a particular interface IP address they wouldn't be able to
> >>>> indicate
> >>>> whether it was actually configured by explicit IP address
> >>>> configuration
> >>>> or due to DHCP.  They would only be able to tell which configurations
> >>>> nodes could influence a particular derived state node.
> >>> I am confused and I may not understand your example. My point is that
> >>> an operationally used IP address can be there for a variety of reasons
> >>> and the reasons depend on runtime state not on schema structure.
> >> Yes, exactly.
> >>
> >> But this requirements draft is based on the improvements that the
> >> operators would like to see to YANG/NETCONF/etc to make it easier for
> >> them to use/deploy.
> >>
> >> For this section 4 requirements, my understanding is that they are not
> >> asking to know why a particular operation node has a particular value,
> >> they are only asking for an indication of which configuration leaves
> >> could influence its value.  Solving the latter is easier and can be
> >> implemented at the schema level.
> >>
> >> To support my interpretation I recall that Rob Shakir, at the first
> >> Netmod WG meeting IETF 94, indicated that their proposed opstate
> >> solution draft (e.g. draft-openconfig-netmod-opstate-01) met all the
> >> opstate requirements.  Their draft doesn't have any mechanism to
> >> indicate why a particular state leaf has a particular value, but it
> >> does provide a schema level relationship between the configuration and
> >> operation state nodes - i.e. the co-located config and state
> >> containers that they consistently use throughout the OpenConfig
> >> schema.
> >>
> >>>> I think that there are a couple of cases where this relationship is
> >>>> useful:
> >>>> (1) If you modify a config node, it allows the client to know (in
> >>>> advance) which derived state nodes may be affected and hence should be
> >>>> retrieved to confirm the change.
> >>>> (2) Conversely, if a derived state note has an unexpected value, it
> >>>> allows a client to know which configuration nodes it should retrieve
> >>>> to
> >>>> try and infer what the cause of the value is.
> >>>>
> >>>> If I understand your proposal, then what you are proposing is
> >>>> meta-data
> >>>> annotations of the derived state nodes in the data tree. I.e. the
> >>>> annotations would allow you to tell you whether a particular interface
> >>>> IP address had that value due to explicit IP address configuration or
> >>>> because it was allocated by DHCP.  I agree that this is useful, but I
> >>>> think that it is very hard to implement (on the systems that I'm
> >>>> familiar with) and is also beyond the requirement as originally stated
> >>>> by the opstate requirements draft.
> >>> I agree its hard to implement in general but I am not sure why the
> >>> other proposal would be any simpler to implement. Your instrumentation
> >>> is either able to keep track of 'why something has a certain value' or
> >>> it is not.
> >> I'm saying that there is no requirement (at least from the opstate
> >> draft) to generally track "why something has a certain value" at all.
> >>
> >>
> >>>> As such, I think that we should restrict the scope of the requirements
> >>>> draft (and proposed solutions) to YANG schema level annotations that
> >>>> are
> >>>> easier to solve.  If you agree, then do we need to tweak the text of
> >>>> requirement 4 to make this explicit?
> >>> But this approach requires to partition things artificially. For
> >>> example, I can't have a simple list of IP addresses used by the
> >>> interface anymore but instead I need to have a list of IP address
> >>> coming from static config, a list of IP addresses coming from DHCP, a
> >>> list of IP addresses coming from SLAAC and so on. I seriously can't
> >>> imagine that debugging network configurations becomes simpler if we
> >>> spread around the information one needs to look at in several branches
> >>> of the data model. [I hope I completely misunderstand requirement 4.]
> >> I don't think that they are asking/suggesting separate lists of
> >> operational IP addresses.
> >>
> >> Taking the OpenConfig IP YANG model as an example
> >> (https://github.com/openconfig/public/blob/master/release/models/interfaces/openconfig-if-ip.yang):
> >>
> >> They have a list of IP addresses.  Each entry contains:
> >>   - the configured IP address (if any),
> >>   - the operational IP address,
> >>   - an enum indicating the source of the operational IP address value
> >>   - (static, dhcp, link_layer, random or other).
> > I assume you refer to this list:
> Yes.
> 
> >
> >        list address {
> >          key ip;
> >          description
> >           "The list of configured IPv4 addresses on the interface.";
> >
> >          leaf ip {
> >            type leafref {
> >              path "../ocip:config/ocip:ip";
> >            }
> >            description "References the configured IP address";
> >          }
> >
> >          container config {
> >            description "Configuration data for each configured IPv4
> >            address on the interface";
> >
> >            uses ipv4-config-address;
> >          }
> >
> >          container state {
> >
> >            config false;
> >            description "Operational state data for each IPv4 address
> >            configured on the interface";
> >
> >            uses ipv4-config-address;
> >            uses ipv4-state-address;
> >          }
> >
> >        }
> >
> >
> >
> > Note how the key contains the "configured IP address" (and it is a
> > config true list).   So this list cannot contain addresses that are
> > not configured.
> OK, yes.  I had missed that.
> 
> I presume that they would ideally like this list to contain all IP
> addresses on an interface whether configured or operational. Otherwise
> if it contains just the list of configured addresses then the "origin"
> leaf in the ipv4-state-address grouping seems pretty pointless since
> the only sane value that it could hold is STATIC :-)

Exactly.  This is the core of the problem with their models, imo.

> I suspect that this issue ties back to sections 8.1.2 and 9.2 of
> https://www.ietf.org/archive/id/draft-openconfig-netmod-opstate-01.txt
> (text reproduced below) where they would like the YANG schema to have
> a combined list of configured and state entries.

Like SNMP tables...

> 8.1.2.  Handling lists
> 
>    In YANG 1.0, lists have requirements that complicate the creation of
>    the parallel configuration and state data structures.  First, keys
>    must be children of the list; they cannot be further down the data
>    hierarchy within a subsequent container.  For example, the
>    'interface' list cannot be keyed by /interfaces/interface/config/
>    name.  Second, YANG requires that the list key is part of the
>    configuration or state data in each list member.
> 
>    We consider two possible approaches for lists:
> 
>    1.  list keys appear only at the top level of the list, i.e., not
>        duplicated under the 'config' or 'state' containers within the
>        list
> 
>    2.  the data represented by the list key appears in the config and
>        state containers, and a key with type leafref is used in the top
>        level of the list pointing to the corresponding data node in the
>        config (or state) container.

This doesn't solve the problem; it just creates a more complex model.

>    Option 1 has the advantage of not duplicating data, but treats the
>    data item (or items) that are keys as special cases, i.e., not
>    included in the config or state containers.  Option 2 is appealing in
>    that configurable data always appears in the config container, but
>    requires an arguably unnecessary key pointing to the data from the
>    top level of the list.
> 
>    Appendix C shows a simple example of both options.
> 
> 
> 9.2.  YANG lists as maps
> 
>    YANG has two list constructs, the 'leaf-list' which is similar to a
>    list of scalars (arrays) in other programming languages, and the
>    'list' which allows a keyed list of complex structures, where the key
>    is also part of the data values.  As described in Section 8.1.2, the
>    current requirements on YANG list keys require either duplication of
>    data, or treating some data (i.e., those that comprise list keys) as
>    a special case.  One solution is to generalize lists to be more like
>    map data structures found in most modern programming languages, where
>    each list member has a key that is not required to part of the
>    configuration or state data, and also not subject to existing
>    "config-under-state limitations.  This allows list keys to be
>    arbitrarily defined by the user if desired, or based on values of
>    data nodes.  In the latter case, the specification of which data
>    nodes are used in constructing the list key could be indicated in the
>    meta-data associated with the key.

I don't understand how this would solve the problem either, but in any
case, I don't think this idea has been presented in greater detail, so
I am not sure how it would actually work.


/martin


From nobody Tue Jan 26 07:26:19 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49F01B2B09 for ; Tue, 26 Jan 2016 07:26:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBYjrzdNM6Lr for ; Tue, 26 Jan 2016 07:26:16 -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 19B6F1B2ACD for ; Tue, 26 Jan 2016 07:26:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1117; q=dns/txt; s=iport; t=1453821976; x=1455031576; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=8xR2q+nGvQ63Cgdob+yKFlTeNDszyr4QVDwUI+fJT0g=; b=ZyDs++Zye5WQVCvDv5QSiKXD5ep2fgiRwOTTFpoMRZ9swWLoQFx1sn61 EZxs+0c9BhKBik6P0Ux0WuUFnEqYoyMgVoBMmJ5CPbJFOeUrKrfgz5A9v KmyQI5i7B/bKjwVepKGRJG1yW+SfJRoxWgSfsZG29eDzXKmGM3wrmCY25 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQDWjqdW/xbLJq1ehAxtiFeyGgENg?= =?us-ascii?q?WMYCoUjSgKBfBQBAQEBAQEBgQqEQgEBBAEBATU2BgQBEAsOExYPCQMCAQIBFTA?= =?us-ascii?q?GAQwGAgEBiBcOvlEBAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYyhG2EGxACAYRYA?= =?us-ascii?q?QSWeY1WgV6ERIMEhVOOQx4BAUKDajsuiEQBAQE?=
X-IronPort-AV: E=Sophos;i="5.22,350,1449532800"; d="scan'208";a="631913865"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jan 2016 15:26:14 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u0QFQDXW031309; Tue, 26 Jan 2016 15:26:14 GMT
To: Nadeau Thomas , netmod WG 
References: 
From: Benoit Claise 
Message-ID: <56A79015.4040105@cisco.com>
Date: Tue, 26 Jan 2016 16:26:13 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod-chairs@tools.ietf.org
Subject: Re: [netmod] IPR Check: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 15:26:18 -0000

I'm not aware of any IPR.

Regards, Benoit
> This mail starts the IPR poll on draft-ietf-netmod-opstate-reqs-01.
>
> Are you aware of any IPR that applies to draft-ietf-netmod-opstate-reqs-01?
> If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs
> 3979, 4879, 3669 and 5378 for more details)?
>
> If you are listed as a document author or contributor please respond to this
> email explicitly regardless of whether or not you are aware of any relevant IPR.
> The response needs to be sent to the NETMOD WG mailing list.  The document
> will not advance to the next stage until a response has been received from each
> author and contributor.
>
> If you are on the NETMOD WG email list but are not listed as an author or
> contributor, then please explicitly respond only if you are aware of any IPR that
> has not yet been disclosed in conformance with IETF rules.
>
> Thank you,
>
> Kent and Tom, NETMOD WG Chairs
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


From nobody Tue Jan 26 07:36:25 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A1E1B2B30 for ; Tue, 26 Jan 2016 07:36:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgkevRlfKxnk for ; Tue, 26 Jan 2016 07:36: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 04A0B1B2A93 for ; Tue, 26 Jan 2016 07:36:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2102; q=dns/txt; s=iport; t=1453822582; x=1455032182; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=Bw7gTocRf7ZFhHjuzDy/igGiTHo9QAOb3bY3U9tx+SY=; b=mQL1EG478Jucy93R4MJ1+/awZ7wB8L73vxoG6gt0KmzUNr2X0m4lwF1/ UdlQm+jOFOD+PNMGb1eRcQfFvuEfg/tRb/XqYxrbOFHakbyu7xfJNf292 ZBkaBZOCo+VqCd322t8W74n58tP39cvcrsdclz9nFIDgrTux3ArdtYrLS 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoBABqkadW/xbLJq1ejVC0C4YPAoISA?= =?us-ascii?q?QEBAQEBgQuEQgEBBDhAEQsOCgkWDwkDAgECAUUGAQwIAQEXiAC+XwEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEahjKEbYkGAQSWeY1WiSaFU45DYoNpPIhyAQEB?=
X-IronPort-AV: E=Sophos;i="5.22,350,1449532800"; d="scan'208";a="624802520"
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; 26 Jan 2016 15:36:19 +0000
Received: from [10.63.23.112] (dhcp-ensft1-uk-vla370-10-63-23-112.cisco.com [10.63.23.112]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u0QFaJVe020551; Tue, 26 Jan 2016 15:36:19 GMT
To: Kent Watsen , "netmod@ietf.org" 
References: <56938BC6.80707@cisco.com> <20160111112629.GA41791@elstar.local> <56992602.7020700@cisco.com> <20160115173946.GA187@elstar.local>  <20160116103956.GC85460@elstar.local> <569CB4B3.3040308@cisco.com> <20160126123249.GA52489@elstar.local> <56A78054.1010904@cisco.com> <20160126151420.GD53158@elstar.local> <20160126152110.GE53158@elstar.local>
From: Robert Wilton 
Message-ID: <56A79271.8030304@cisco.com>
Date: Tue, 26 Jan 2016 15:36:17 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <20160126152110.GE53158@elstar.local>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 15:36:24 -0000

On 26/01/2016 15:21, Juergen Schoenwaelder wrote:
> On Tue, Jan 26, 2016 at 04:14:20PM +0100, Juergen Schoenwaelder wrote:
>>> They have a list of IP addresses.  Each entry contains:
>>>   - the configured IP address (if any),
>>>   - the operational IP address,
>>>   - an enum indicating the source of the operational IP address value
>>> (static, dhcp, link_layer, random or other).
>> But this ip-address-origin thing is exactly what I have been talking
>> about.  Now I am even more confused.
>>   
>>> In summary, I think that knowing the source of a piece of operational
>>> data is valuable in some circumstances (e.g. IP addresses), but probably
>>> isn't actually required for most operational values, and at least from
>>> an opstate perspective isn't a general requirement that needs to be
>>> solved with a generic solution.
>> See ip-address-origin.
>>
> Frankly, you either list all IP addresses of an interface in one place
> and then you need additional information to indicate where they are
> coming from (e.g., which config tweaks them) or you distribute the all
> IP addresses of an interface into multiple places of the schema (which
> I doubt operational people really want).
>
> To track the origin, you can create ip-address-origin, ip-route-origin,
> ip-foo-origin objects and stick them at appropriate places or you make
> this metadata which you do not have to define everywhere.
>
> This is my rather simple view of the world.
I'm not disagreeing with any of this other than to point out that the 
opstate requirements drafts (either draft-ietf-netmod-opstate-reqs-04 or 
draft-openconfig-netmod-opstate-01 that it was based on) are not asking 
for a solution to this specific problem.  They are asking for a solution 
to relate the configuration and operational state nodes in the YANG schema.

Specifying a common way to track these "origin" objects using meta-data 
may well be worthwhile, but I think that it would be better achieved 
outside the discussions related to the opstate requirements/solutions.

Rob

>
> /js
>


From nobody Tue Jan 26 07:45:30 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607521B3013 for ; Tue, 26 Jan 2016 07:45:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6yxnfu_8GGk for ; Tue, 26 Jan 2016 07:45: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 C93A21B300F for ; Tue, 26 Jan 2016 07:45:26 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 96BE7899; Tue, 26 Jan 2016 16:45:25 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id YCIhW1xl-vy9; Tue, 26 Jan 2016 16:45:24 +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, 26 Jan 2016 16:45:24 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id DAED620033; Tue, 26 Jan 2016 16:45:24 +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 FhSa70ol6YdB; Tue, 26 Jan 2016 16:45:23 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5BE3F2002C; Tue, 26 Jan 2016 16:45:22 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 7D96239C262E; Tue, 26 Jan 2016 16:45:21 +0100 (CET)
Date: Tue, 26 Jan 2016 16:45:20 +0100
From: Juergen Schoenwaelder 
To: Robert Wilton 
Message-ID: <20160126154520.GA53340@elstar.local>
Mail-Followup-To: Robert Wilton , Kent Watsen , "netmod@ietf.org" 
References: <56992602.7020700@cisco.com> <20160115173946.GA187@elstar.local>  <20160116103956.GC85460@elstar.local> <569CB4B3.3040308@cisco.com> <20160126123249.GA52489@elstar.local> <56A78054.1010904@cisco.com> <20160126151420.GD53158@elstar.local> <20160126152110.GE53158@elstar.local> <56A79271.8030304@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <56A79271.8030304@cisco.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 15:45:29 -0000

On Tue, Jan 26, 2016 at 03:36:17PM +0000, Robert Wilton wrote:
> 
> >>
> >Frankly, you either list all IP addresses of an interface in one place
> >and then you need additional information to indicate where they are
> >coming from (e.g., which config tweaks them) or you distribute the all
> >IP addresses of an interface into multiple places of the schema (which
> >I doubt operational people really want).
> >
> >To track the origin, you can create ip-address-origin, ip-route-origin,
> >ip-foo-origin objects and stick them at appropriate places or you make
> >this metadata which you do not have to define everywhere.
> >
> >This is my rather simple view of the world.
> I'm not disagreeing with any of this other than to point out that the 
> opstate requirements drafts (either draft-ietf-netmod-opstate-reqs-04 or 
> draft-openconfig-netmod-opstate-01 that it was based on) are not asking 
> for a solution to this specific problem.  They are asking for a solution 
> to relate the configuration and operational state nodes in the YANG schema.
> 
> Specifying a common way to track these "origin" objects using meta-data 
> may well be worthwhile, but I think that it would be better achieved 
> outside the discussions related to the opstate requirements/solutions.
>

All fine. I am just still confused what "relate the configuration and
operational state nodes in the YANG schema" actually means. Does it
mean that an IP address coming via DHCP should be reported next to the
DHCP config? I guess not. So I am left puzzled.

/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 26 07:57:23 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 131121B3038 for ; Tue, 26 Jan 2016 07:57:22 -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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2Vtf1c9PxkL for ; Tue, 26 Jan 2016 07:57:19 -0800 (PST)
Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::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 AE17C1B3037 for ; Tue, 26 Jan 2016 07:57:19 -0800 (PST)
Received: by mail-pf0-x22f.google.com with SMTP id e65so101252311pfe.0 for ; Tue, 26 Jan 2016 07:57:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1hl8CGb3cR4/PSg/vB6WgCVX7/HuhujVeffgMFO24iU=; b=M5f+2De4ld8gkbN1qZibbTJGnG8vp/0MFEYcU21LZljP9hPpRgpecVPSYxLt9gXiP1 tcgTz9xnoaHiKevjgwxYvYGxDh4PHY51DxIbdmB/n0rtW1d6Y4a698GpVL4kFTgGiPcp QZ1aciG11EyZ5G+w7bSXvCrmLMvM9gCyp5YhjEhqM94UJQjNix0RM208poWna1q3C1+b Zj2vCkOk8fgwgb44mWZbbf7w/b/F4sErh7DcQAs2K7IbxdKznw3HvNmnO5o8JEEdJvQ1 5pYLf+7l5Vuw5U+lk7PyU7eUEmKqfPe8jCF4AeKi+k42mLPCo75ZktEfsA7zi1wXkFKs My7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=1hl8CGb3cR4/PSg/vB6WgCVX7/HuhujVeffgMFO24iU=; b=CH0dONETtrRrjR2k0n2rByT5oyG6bBi23/+bGYofiNrH7m/iuJ8FVg1rxwF38XKqdZ 9JsoEGG8RKjFDFngShOl3sazGge/qe8EYOgcFgtbCDxGijsWn7rpmheO2SA2oO8rCuWz R7QKlwWD5JWKmYNWkS5Fv7jpb5LSHYYLPYu7JXNduN/hqBtMdCQMm+FA8y/D3Ahye98w 5+BA3UuSz3xSk+sKs3sJB/WipJsZdsVa5HoCR0sc7Xqb5P73km7tU9e8L8Oo32cPj6yc A9DfPnqmWRKRQQ5WtZo+BLVVn7R0Tyr/J063oGbP92eSed3TD7iQ9H6B+Xw+NqiB5raV ORAg==
X-Gm-Message-State: AG10YOSIl62B7dktnsnSqaj/lXe9+Cnadb7ZYZNEl7VptzOqSDu3hrC9jMBIMyhYEmIkDQ==
X-Received: by 10.98.86.67 with SMTP id k64mr35406183pfb.50.1453823839256; Tue, 26 Jan 2016 07:57:19 -0800 (PST)
Received: from [10.24.20.214] ([128.107.241.175]) by smtp.gmail.com with ESMTPSA id yl1sm2715514pac.35.2016.01.26.07.57.17 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 26 Jan 2016 07:57:18 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Mahesh Jethanandani 
In-Reply-To: 
Date: Tue, 26 Jan 2016 08:57:17 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <48EC26A2-E442-41EF-AA14-BE40CD39F8F5@gmail.com>
References: 
To: Nadeau Thomas 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: netmod-chairs@tools.ietf.org, netmod WG 
Subject: Re: [netmod] IPR Check: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 15:57:22 -0000

I am not aware of any IPR.

> On Dec 16, 2015, at 6:13 AM, Nadeau Thomas  =
wrote:
>=20
> This mail starts the IPR poll on draft-ietf-netmod-opstate-reqs-01.
>=20
> Are you aware of any IPR that applies to =
draft-ietf-netmod-opstate-reqs-01?
> If so, has this IPR been disclosed in compliance with IETF IPR rules =
(see RFCs
> 3979, 4879, 3669 and 5378 for more details)?
>=20
> If you are listed as a document author or contributor please respond =
to this
> email explicitly regardless of whether or not you are aware of any =
relevant IPR.
> The response needs to be sent to the NETMOD WG mailing list.  The =
document
> will not advance to the next stage until a response has been received =
from each
> author and contributor.
>=20
> If you are on the NETMOD WG email list but are not listed as an author =
or
> contributor, then please explicitly respond only if you are aware of =
any IPR that
> has not yet been disclosed in conformance with IETF rules.
>=20
> Thank you,
>=20
> Kent and Tom, NETMOD WG Chairs
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanandani@gmail.com




From nobody Tue Jan 26 08:31:58 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38BEA1B30A0 for ; Tue, 26 Jan 2016 08:31:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rz35KV1H5nC for ; Tue, 26 Jan 2016 08:31:56 -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 E66C31B309C for ; Tue, 26 Jan 2016 08:31:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2340; q=dns/txt; s=iport; t=1453825916; x=1455035516; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ZA5bS/MLg2uPRgQCnrIG+dcMC+53F33RZiumtM2VN98=; b=CeyVPaJmlK7SWW4fyeAINp890aDYAOBCY4UzTPAXWbjU7IDGYlcK7gRq f/nDCF9JFP4+Jcj/rW4rb/TFX0qogJnVy60WCzoav+2+8m+7TfUvPtgJi Y4dlRqWLgMA9DsvqKIQ7qqI5b1hv+DayRK+Hw1dIahRrWhXmNY01e63C7 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQD7nqdW/51dJa1egzpSbQaIUbIaA?= =?us-ascii?q?Q2BYhgKhSNKAhyBLzgUAQEBAQEBAYEKhEIBAQQBAQEgEToGBRACAQgODAImAgI?= =?us-ascii?q?CHwYLFRACBA4FiAYDEg6vO4sIDYQQAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQR7i?= =?us-ascii?q?iSCSYFSEAIBM4JrgToFlnkBi12BeIFehESIV4cBh0EBHgEBQoNpaodIfAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.22,350,1449532800"; d="scan'208";a="230771517"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jan 2016 16:31:54 +0000
Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u0QGVsa2012039 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Jan 2016 16:31:54 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 26 Jan 2016 11:31:53 -0500
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Tue, 26 Jan 2016 11:31:53 -0500
From: "Acee Lindem (acee)" 
To: Nadeau Thomas 
Thread-Topic: [netmod] IPR Check: draft-ietf-netmod-opstate-reqs-01
Thread-Index: AQHRWFI6xub+hC5RqUe+i7aL8bGLFJ8N/XgA
Date: Tue, 26 Jan 2016 16:31:53 +0000
Message-ID: 
References:  <48EC26A2-E442-41EF-AA14-BE40CD39F8F5@gmail.com>
In-Reply-To: <48EC26A2-E442-41EF-AA14-BE40CD39F8F5@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.205]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: "netmod-chairs@tools.ietf.org" , netmod WG 
Subject: Re: [netmod] IPR Check: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 16:31:57 -0000

QXMgYSBjb250cmlidXRvciB0byB0aGUgTkVUTU9EIE9wZXJhdGlvbmFsIFN0YXRlIHJlcXVpcmVt
ZW50cyBkcmFmdA0KZGlzY3Vzc2lvbiwgSSBhbSBub3QgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQ
Ui4NClRoYW5rcywNCkFjZWUgDQoNCk9uIDEvMjYvMTYsIDEwOjU3IEFNLCAibmV0bW9kIG9uIGJl
aGFsZiBvZiBNYWhlc2ggSmV0aGFuYW5kYW5pIg0KPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9u
IGJlaGFsZiBvZiBtamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4gd3JvdGU6DQoNCj5JIGFtIG5vdCBh
d2FyZSBvZiBhbnkgSVBSLg0KPg0KPj4gT24gRGVjIDE2LCAyMDE1LCBhdCA2OjEzIEFNLCBOYWRl
YXUgVGhvbWFzIDx0bmFkZWF1QGx1Y2lkdmlzaW9uLmNvbT4NCj4+d3JvdGU6DQo+PiANCj4+IFRo
aXMgbWFpbCBzdGFydHMgdGhlIElQUiBwb2xsIG9uIGRyYWZ0LWlldGYtbmV0bW9kLW9wc3RhdGUt
cmVxcy0wMS4NCj4+IA0KPj4gQXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0
bw0KPj5kcmFmdC1pZXRmLW5ldG1vZC1vcHN0YXRlLXJlcXMtMDE/DQo+PiBJZiBzbywgaGFzIHRo
aXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcw0K
Pj4oc2VlIFJGQ3MNCj4+IDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWls
cyk/DQo+PiANCj4+IElmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNv
bnRyaWJ1dG9yIHBsZWFzZSByZXNwb25kIHRvDQo+PnRoaXMNCj4+IGVtYWlsIGV4cGxpY2l0bHkg
cmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueQ0KPj5yZWxl
dmFudCBJUFIuDQo+PiBUaGUgcmVzcG9uc2UgbmVlZHMgdG8gYmUgc2VudCB0byB0aGUgTkVUTU9E
IFdHIG1haWxpbmcgbGlzdC4gIFRoZQ0KPj5kb2N1bWVudA0KPj4gd2lsbCBub3QgYWR2YW5jZSB0
byB0aGUgbmV4dCBzdGFnZSB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkDQo+PmZy
b20gZWFjaA0KPj4gYXV0aG9yIGFuZCBjb250cmlidXRvci4NCj4+IA0KPj4gSWYgeW91IGFyZSBv
biB0aGUgTkVUTU9EIFdHIGVtYWlsIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhv
cg0KPj5vcg0KPj4gY29udHJpYnV0b3IsIHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkgcmVzcG9uZCBv
bmx5IGlmIHlvdSBhcmUgYXdhcmUgb2YNCj4+YW55IElQUiB0aGF0DQo+PiBoYXMgbm90IHlldCBi
ZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVsZXMuDQo+PiANCj4+IFRo
YW5rIHlvdSwNCj4+IA0KPj4gS2VudCBhbmQgVG9tLCBORVRNT0QgV0cgQ2hhaXJzDQo+PiANCj4+
IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBuZXRt
b2QgbWFpbGluZyBsaXN0DQo+PiBuZXRtb2RAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+DQo+TWFoZXNoIEpldGhhbmFuZGFuaQ0KPm1q
ZXRoYW5hbmRhbmlAZ21haWwuY29tDQo+DQo+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCj5uZXRtb2QgbWFpbGluZyBsaXN0DQo+bmV0bW9kQGll
dGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0K


From nobody Tue Jan 26 09:48:01 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA0E1A9128 for ; Tue, 26 Jan 2016 09:47:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXAFB5_tw1ol for ; Tue, 26 Jan 2016 09:47:57 -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 D1F791A9104 for ; Tue, 26 Jan 2016 09:47:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1468; q=dns/txt; s=iport; t=1453830476; x=1455040076; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=5OAmaqd/80IaOH7XxXA++Nepey6H5YtaBPqNNqAd/2k=; b=H861BNgc1x4PZ5u3osrZJFhjS7xcVD4Bwpqh4Vm57RjHfknrHUxeL+dj doy0ev/eGs1V54WOAwN3K9TtLRdgzTX5UhaWtLVbq6zmI8p6FvwM8VTU9 Ow43Q23j6I98HA4Sh21vr6SeMgOMOETJC21kT0C7BX3htsJAHUl8RzMWA Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQA3sKdW/5ldJa1egzpSbQaIUbIeA?= =?us-ascii?q?Q2BYhgKhSNKAoFOOBQBAQEBAQEBgQqEQQEBAQMBAQEBNzQGCgsCAQgOCh4QJws?= =?us-ascii?q?lAgQBEogTCA6+YwEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhjKCBIJphBsQAgEbg?= =?us-ascii?q?y6BDwWSdYQEAY1VBoFYhESIV45CAR4BAUKDaWqHSHwBAQE?=
X-IronPort-AV: E=Sophos;i="5.22,350,1449532800"; d="scan'208";a="67149264"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jan 2016 17:47:55 +0000
Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u0QHlt0w002740 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Jan 2016 17:47:56 GMT
Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 26 Jan 2016 11:47:54 -0600
Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.009; Tue, 26 Jan 2016 11:47:54 -0600
From: "Carl Moberg (camoberg)" 
To: Nadeau Thomas , NETMOD Working Group , netmod WG 
Thread-Topic: [netmod] IPR Check: draft-ietf-netmod-opstate-reqs-01
Thread-Index: AQHRWE3semQtNR9UvECYVvpC2gobbZ8Od1OA
Date: Tue, 26 Jan 2016 17:47:54 +0000
Message-ID: 
References:  <56A79015.4040105@cisco.com>
In-Reply-To: <56A79015.4040105@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.245.105]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] IPR Check: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 17:47:59 -0000

 I am not aware of any IPR.

> On Jan 26, 2016, at 4:26 PM, Benoit Claise (bclaise)  =
wrote:
>=20
> I'm not aware of any IPR.
>=20
> Regards, Benoit
>> This mail starts the IPR poll on draft-ietf-netmod-opstate-reqs-01.
>>=20
>> Are you aware of any IPR that applies to draft-ietf-netmod-opstate-reqs-=
01?
>> If so, has this IPR been disclosed in compliance with IETF IPR rules (se=
e RFCs
>> 3979, 4879, 3669 and 5378 for more details)?
>>=20
>> If you are listed as a document author or contributor please respond to =
this
>> email explicitly regardless of whether or not you are aware of any relev=
ant IPR.
>> The response needs to be sent to the NETMOD WG mailing list.  The docume=
nt
>> will not advance to the next stage until a response has been received fr=
om each
>> author and contributor.
>>=20
>> If you are on the NETMOD WG email list but are not listed as an author o=
r
>> contributor, then please explicitly respond only if you are aware of any=
 IPR that
>> has not yet been disclosed in conformance with IETF rules.
>>=20
>> Thank you,
>>=20
>> Kent and Tom, NETMOD WG Chairs
>>=20
>> _______________________________________________
>> 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


From nobody Tue Jan 26 10:42:59 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2431F1B2B6C for ; Tue, 26 Jan 2016 10:42:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbFQ2fGOPCjj for ; Tue, 26 Jan 2016 10:42:51 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0105.outbound.protection.outlook.com [207.46.100.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF5001B2B6A for ; Tue, 26 Jan 2016 10:42:50 -0800 (PST)
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 (TLS) id 15.1.365.19; Tue, 26 Jan 2016 18:42:49 +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.0365.024; Tue, 26 Jan 2016 18:42:49 +0000
From: Kent Watsen 
To: Juergen Schoenwaelder , "Robert Wilton" 
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt
Thread-Index: AQHRRz2lEErWj+iSeUCXhpFM5+aasZ7rnI4AgAG85wCAAAG/gIAArbcAgAByIgCAAcDigIAAFjCAgAD+4QCAAEX4AIAAEJIAgAL8DACAAY0PAIAABrUAgAanCQCAAAqUAIAACg6AgAES+gCAAxYFgIAMwNiAgAAdqACAAA92AIAAAeqAgAAEOICAAAKHAP//3cQA
Date: Tue, 26 Jan 2016 18:42:49 +0000
Message-ID: 
References: <56992602.7020700@cisco.com> <20160115173946.GA187@elstar.local>  <20160116103956.GC85460@elstar.local> <569CB4B3.3040308@cisco.com> <20160126123249.GA52489@elstar.local> <56A78054.1010904@cisco.com> <20160126151420.GD53158@elstar.local> <20160126152110.GE53158@elstar.local> <56A79271.8030304@cisco.com> <20160126154520.GA53340@elstar.local>
In-Reply-To: <20160126154520.GA53340@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.151105
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-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 5:nvmUczc6PB2OHG/OhJEqv/QnETZMdu/QCvrdx3tc/JB367waRP1tWpA0j5BDI3TZ+xnWiqFkGBhwiD2o/3iifmioxmuC9G0rL8QM/WVBIyOWpcTLu+xn6j+nzmANFWIsoa5Zf08mAxRAtm+gR8BIWw==; 24:KQBW4qPt87Wei9j15TttPm2fYR4in4cTNwomPUuhUGJKUA7YdFVT0AqgIKRYV6uH4MjmcUUbul/eOp5L1VlCNuS52A30z/K+dEGZYfKYw4I=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1442;
x-ms-office365-filtering-correlation-id: bdfbb785-7c45-4103-aa10-08d326807daf
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; 
x-forefront-prvs: 08331F819E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(5001960100002)(2950100001)(3846002)(54356999)(1220700001)(1096002)(77096005)(2900100001)(102836003)(11100500001)(105586002)(106356001)(189998001)(106116001)(586003)(50986999)(97736004)(83716003)(5008740100001)(5002640100001)(101416001)(4001350100001)(66066001)(33656002)(81156007)(6116002)(5001770100001)(99286002)(82746002)(76176999)(2906002)(122556002)(87936001)(83506001)(10400500002)(4326007)(36756003)(230783001)(5004730100002)(93886004)(86362001)(40100003)(92566002)(3280700002)(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:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <5CE2B717CF1B5345B27CB6EDEE6BB49D@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2016 18:42:49.4455 (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: "netmod@ietf.org" 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 18:42:55 -0000

DQoNCg0KPkFsbCBmaW5lLiANCg0KT2theSwgc28gbm8gZGVzaXJlIHRvIGNoYW5nZSAtMDQgICh3
aGljaCBpcyBnb29kLCBhcyAtMDQgaXMgYmVpbmcgcHJlcGFyZWQgZm9yIEFEIGhhbmRvZmYpDQoN
Cg0KDQo+SSBhbSBqdXN0IHN0aWxsIGNvbmZ1c2VkIHdoYXQgInJlbGF0ZSB0aGUgY29uZmlndXJh
dGlvbiBhbmQNCj5vcGVyYXRpb25hbCBzdGF0ZSBub2RlcyBpbiB0aGUgWUFORyBzY2hlbWEiIGFj
dHVhbGx5IG1lYW5zLiBEb2VzIGl0DQo+bWVhbiB0aGF0IGFuIElQIGFkZHJlc3MgY29taW5nIHZp
YSBESENQIHNob3VsZCBiZSByZXBvcnRlZCBuZXh0IHRvIHRoZQ0KPkRIQ1AgY29uZmlnPyBJIGd1
ZXNzIG5vdC4gU28gSSBhbSBsZWZ0IHB1enpsZWQuDQoNCg0KRm9yIHdoYXQgaXTigJlzIHdvcnRo
LCBvcHN0YXRlLXJlcXMtMDQgZG9lc27igJl0IHNheSDigJxpbiBZQU5HIHNjaGVtYeKAnS4gIEkg
YmVsaWV2ZSB0aGUgc29sdXRpb24gY291bGQgYWxzbyBiZSB2aWEgbWV0YWRhdGEgb3IgZXZlbiBv
dGhlciBzY2hlbWEsIHNvIGxvbmcgYXMgdGhlIHNvbHV0aW9uIGlzIHByb2dyYW1tYXRpY2FsbHkg
Y29uc3VtYWJsZS4gIA0KDQpBbHNvLCBteSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhlcmUgYXJl
IG5vIHNlbWFudGljcyB0aWVkIHRvIHdoYXQgdGhlIHJlbGF0aW9uc2hpcCByZWdhcmRzLiAgSXQg
bW9zdCBsaWtlbHkgcmVnYXJkcyBvcmlnaW4sIGJ1dCBpdCBkb2VzbuKAmXQgaGF2ZSB0by4gSSBh
c2tlZCBhYm91dCB1dGlsaXR5IG9mIHRoZSByZWxhdGlvbnNoaXAgd2l0aG91dCBzZW1hbnRpYyBh
IGxvbmcgdGltZSBiYWNrIGFuZCB0aGUgcmVzcG9uc2UgZnJvbSBSb2IgUy4gKEkgdGhpbmspIHdh
cyBiZWNhdXNlIGl0IHdvdWxkIGFsbG93IGxvd2VyIHNvZnR3YXJlIGNvbXBvbmVudCBsYXllcnMg
d2l0aGluIHRoZWlyIGNsaWVudC9jb250cm9sbGVyIGFwcCB0byBnZW5lcmljYWxseSBmZXRjaCBk
YXRhIHRvIHBhc3MgdG8gaGlnaGVyIGxheWVycyB0aGF0IGhhdmUgc2VtYW50aWMgYXdhcmVuZXNz
LiAgSSB0YWtlIGl0IHRoYXQgdGhleSB3YW50IHRvIHNlcGFyYXRlIHRoZSBjb2xsZWN0aW9uIGFu
ZCBhbmFseXRpY3Mgb2YgdGhlIGRhdGEgZm9yIHNjYWxhYmlsaXR5IHJlYXNvbnMuDQoNCktlbnQg
IC8vIGFzIGEgY29udHJpYnV0b3INCg==


From nobody Tue Jan 26 10:52:38 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E0F1B2B86 for ; Tue, 26 Jan 2016 10:52:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Btfig2mNUtLb for ; Tue, 26 Jan 2016 10:52:35 -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 900A01B2B83 for ; Tue, 26 Jan 2016 10:52:35 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DCC428D7; Tue, 26 Jan 2016 19:52:33 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id wnpycpZ3aExI; Tue, 26 Jan 2016 19:52:33 +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, 26 Jan 2016 19:52:33 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3F1382002C; Tue, 26 Jan 2016 19:52:33 +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 JR4cskyHLAvp; Tue, 26 Jan 2016 19:52:32 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1808720033; Tue, 26 Jan 2016 19:52:32 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id EB69D39C2A62; Tue, 26 Jan 2016 19:52:30 +0100 (CET)
Date: Tue, 26 Jan 2016 19:52:30 +0100
From: Juergen Schoenwaelder 
To: Kent Watsen 
Message-ID: <20160126185228.GA54031@elstar.local>
Mail-Followup-To: Kent Watsen , Robert Wilton , "netmod@ietf.org" 
References:  <20160116103956.GC85460@elstar.local> <569CB4B3.3040308@cisco.com> <20160126123249.GA52489@elstar.local> <56A78054.1010904@cisco.com> <20160126151420.GD53158@elstar.local> <20160126152110.GE53158@elstar.local> <56A79271.8030304@cisco.com> <20160126154520.GA53340@elstar.local> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 18:52:37 -0000

On Tue, Jan 26, 2016 at 06:42:49PM +0000, Kent Watsen wrote:
> 
> >All fine. 
> 
> Okay, so no desire to change -04  (which is good, as -04 is being prepared for AD handoff)
>

I do not understand all requirements but I have given up on it. It
might be my own stupidity. That said, some parties involved in this
effort do not seem to be responsive to questions and we often end up
collectively reading between lines, grabbing stuff out of some git
repositories etc. in order to gain hints for possible answers to our
questions. This all makes me curious how the work on solutions
addressing these requirements will work.

So, publish this document, I doubt it will get any better.

/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 26 11:15:43 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9DF41B2BC5 for ; Tue, 26 Jan 2016 11:15:41 -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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcX6mLoLPLRu for ; Tue, 26 Jan 2016 11:15:40 -0800 (PST)
Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id EB0081A1A99 for ; Tue, 26 Jan 2016 11:15:39 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=NQ3QNL8ReWsGzjlWjMoGdgaKW+wLaBWn16X5B9sCzO+0rWgmNodRY3O8wP+SFCGj; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.35] (helo=elwamui-huard.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1aO95N-0001OV-OV for netmod@ietf.org; Tue, 26 Jan 2016 14:15:29 -0500
Received: from 76.254.49.194 by webmail.earthlink.net with HTTP; Tue, 26 Jan 2016 14:15:29 -0500
Message-ID: <31027003.1453835729394.JavaMail.root@elwamui-huard.atl.sa.earthlink.net>
Date: Tue, 26 Jan 2016 11:15:29 -0800 (GMT-08:00)
From: Randy Presuhn 
To: netmod@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888857e9f10d2205ddc753d03e2f658e3dd9179bf10955c6f6c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.35
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 19:15:42 -0000

Hi -

>From: Ladislav Lhotka 
>Sent: Jan 26, 2016 6:50 AM
>To: Robert Wilton 
>Cc: "netmod@ietf.org" 
>Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt
>...
>This can IMO work only if the schemas of configuration and
>state data are identical or very similar. As an example,
>take RIBs (state data) and a list of static routes (configuration).
>There is a certain relationship between them, but the exact outcome
>depends on a number of other factors. I don't see how they can be
>co-located, or how the relationship can otherwise be formally expressed.
...

This is not a new problem.  An approach was standardized almost
two decades ago.  That particular approach has a steep learning
curve, but that doesn't mean that the concept should be discarded.
In fairness, that specification tries to boil a larger ocean than
the one surveyed here.

See ITU-T Rec. X.722 Amendment 3 (aka ISO/IEC 10165-4/AMD3) on
"Guidelines for the use of Z in formalizing the behaviour of managed
objects."  https://www.itu.int/rec/T-REC-X.722-199708-I!Amd3/en

I think the real problem is the operational complexity of the
devices being managed.  This is a direct consequence of how the
IETF has defined the operational characteristics (and options!)
of the protocols in question, and of vendors' drive for market
differentiation.  If a gizmo is designed to be complicated, it
should not surprise us when modeling its behaviour is also
complicated.

Randy


From nobody Wed Jan 27 06:45:41 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 933B81B2EF1 for ; Wed, 27 Jan 2016 06:45:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63_QNGpk4V9C for ; Wed, 27 Jan 2016 06:45:38 -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 C66D21B2EF4 for ; Wed, 27 Jan 2016 06:45:37 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9690B8FC; Wed, 27 Jan 2016 15:45:36 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Ko83Kj9i0VSE; Wed, 27 Jan 2016 15:45:35 +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, 27 Jan 2016 15:45:35 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A8B9020031; Wed, 27 Jan 2016 15:45:35 +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 K-888YCrjWYo; Wed, 27 Jan 2016 15:45:33 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D045F2002C; Wed, 27 Jan 2016 15:45:32 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 8822639C3F04; Wed, 27 Jan 2016 15:45:32 +0100 (CET)
Date: Wed, 27 Jan 2016 15:45:32 +0100
From: Juergen Schoenwaelder 
To: Eliot Lear 
Message-ID: <20160127144532.GA191@elstar.local>
Mail-Followup-To: Eliot Lear , netmod WG 
References:  <20151211113156.GA43862@elstar.local> <2059AD77-5375-4DB0-A1BF-432835F11A9F@gmail.com> <20151221153312.GA43316@elstar.local> <2BAA2B26-EE40-4707-BBDB-C84E5653CF23@gmail.com> <20160111183053.GA565@elstar.local>  <20160119164830.GB90880@elstar.local> <569E6F7F.1010901@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <569E6F7F.1010901@cisco.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] [Rtg-dt-yang-arch] [yang-doctors] Working group Last Call: draft-ietf-netmod-acl-model-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2016 14:45:39 -0000

Eliot,

I posted a technical review of the ACL draft on December 11th to the
list since the document was send to WG last call. I believe the I-D
has technical issues that need to be resolved. I am not going to
repeat my technical comments.

Note I have been one of the _few_ who actually read the I-D when it
was sent to WG last call. And yes, I believe a standard in this area
needs to be highly extensible (so we better get this right) and I
believe it needs to be resonably match widely deployed open source
packet filters and not just Juniper and Cisco gear.

/js

PS: I reduced the CC: list to the NETMOD WG since this is where the
    work is supposed to take place.

On Tue, Jan 19, 2016 at 06:16:47PM +0100, Eliot Lear wrote:
> Hi Juergen,
> 
> Skipping down...
> 
> On 1/19/16 5:48 PM, Juergen Schoenwaelder wrote:
> 
> > While we can have a lengthy debate about terminology, I think more
> > important is to get functionality right. 
> 
> Agree.  We are arguing over labels that aren't generally meant for
> humans ANYWAY.
> 
> >>> I am talking about the modularity of the base model, I do not see how
> >>> the cited thread relates to this.
> >> Among the vendors, ace-eth, ace-ipv4 and ace-ipv6 are always supported. I appreciate your input, but we did this design choice as design team and went forward with it. Also, the YANG models are not set in stone. I definitely see models evolving.
> > My main concern is that we need to get the extensibility of the model
> > right. One way to make sure we achieved this goal is to actually treat
> > everything as an extension of the core model (this forces us to get
> > the extensibility right). This is essentially what we did with the
> > routing data model and the interfaces data model.
> >
> >
> While I agree I am also becoming concerned that we may be going down a
> rat hole from which we may not return.  The above thread snippets have
> lost so much context that one cannot divine what it is we are arguing
> over.  While a design team certainly does not represent consensus, can
> we please at least argue over what it is we are supposed to be arguing
> over?  With regard to this model, I could imagine innumerable ways to
> represent an access list.  The deference due the people who wrote this
> stuff out is at least to recognize that.  If you are going to propose an
> alternative at this point, please do it the old fashion way: send text.
> 
> Eliot
> 



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


-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Wed Jan 27 07:48:40 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216B21A1BB4 for ; Wed, 27 Jan 2016 07:48:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5u9IuAr9Gw5 for ; Wed, 27 Jan 2016 07:48:34 -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 5599A1A21A1 for ; Wed, 27 Jan 2016 07:48:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5050; q=dns/txt; s=iport; t=1453909711; x=1455119311; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DHyPvm5wsKFoWwYgirV/B8lo2Qv8ndntCYnSEtvje7E=; b=eHdYLeVZgEYvga3CIiJrGHKDaPkUgmcFMQPMK71RrN8R+mvJa73Cf76k S4uxUBepjn6r9SFCnPMLv+itUbsGir87FBes1RzqC04u+p+BPa58NugpE c74/PSEF2Y7HtFsSS49VQwB7MxgXGboaZrmXQ5W3CNWp7c2zQy5I+l1f3 A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CwBABq5qhW/xbLJq1bA4QMbQaIUbMvG?= =?us-ascii?q?AqFI0oCHIF+AQEBAQEBgQuEQQEBAQMBAQEBIBE6CwUJAgIBCA4CCAICHwcCAgI?= =?us-ascii?q?ZDAsVEAIEAQ0FGYd6CA6uWY8tAQEBAQEBAQEBAQEBAQEBAQEBAQEBFQR3iVCEN?= =?us-ascii?q?xgLJoI6gToFlnsBjVWBX4REgyeFMIpxg1EBYoIDGRuBNWqHSH0BAQE?=
X-IronPort-AV: E=Sophos;i="5.22,355,1449532800"; d="scan'208";a="624837737"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jan 2016 15:48:29 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u0RFmSAO008394 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 27 Jan 2016 15:48:29 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 27 Jan 2016 10:48:26 -0500
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Wed, 27 Jan 2016 10:48:27 -0500
From: "Acee Lindem (acee)" 
To: Juergen Schoenwaelder , Eliot Lear 
Thread-Topic: [netmod] [Rtg-dt-yang-arch] [yang-doctors] Working group Last Call: draft-ietf-netmod-acl-model-06
Thread-Index: AQHRWRFpB4/julKHh0K0AIylS4D9B58PgioA
Date: Wed, 27 Jan 2016 15:48:27 +0000
Message-ID: 
References:  <20151211113156.GA43862@elstar.local> <2059AD77-5375-4DB0-A1BF-432835F11A9F@gmail.com> <20151221153312.GA43316@elstar.local> <2BAA2B26-EE40-4707-BBDB-C84E5653CF23@gmail.com> <20160111183053.GA565@elstar.local>  <20160119164830.GB90880@elstar.local> <569E6F7F.1010901@cisco.com> <20160127144532.GA191@elstar.local>
In-Reply-To: <20160127144532.GA191@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.205]
Content-Type: text/plain; charset="utf-8"
Content-ID: <2902DEA3B720A348942E64C0547841A9@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] [Rtg-dt-yang-arch] [yang-doctors] Working group Last Call: draft-ietf-netmod-acl-model-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2016 15:48:39 -0000

QWxsLA0KDQpPbiAxLzI3LzE2LCA5OjQ1IEFNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBKdWVyZ2Vu
IFNjaG9lbndhZWxkZXIiDQo8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mDQpq
LnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0KDQo+RWxpb3QsDQo+
DQo+SSBwb3N0ZWQgYSB0ZWNobmljYWwgcmV2aWV3IG9mIHRoZSBBQ0wgZHJhZnQgb24gRGVjZW1i
ZXIgMTF0aCB0byB0aGUNCj5saXN0IHNpbmNlIHRoZSBkb2N1bWVudCB3YXMgc2VuZCB0byBXRyBs
YXN0IGNhbGwuIEkgYmVsaWV2ZSB0aGUgSS1EDQo+aGFzIHRlY2huaWNhbCBpc3N1ZXMgdGhhdCBu
ZWVkIHRvIGJlIHJlc29sdmVkLiBJIGFtIG5vdCBnb2luZyB0bw0KPnJlcGVhdCBteSB0ZWNobmlj
YWwgY29tbWVudHMuDQo+DQo+Tm90ZSBJIGhhdmUgYmVlbiBvbmUgb2YgdGhlIF9mZXdfIHdobyBh
Y3R1YWxseSByZWFkIHRoZSBJLUQgd2hlbiBpdA0KPndhcyBzZW50IHRvIFdHIGxhc3QgY2FsbC4N
Cg0KRldJVywgSSBhbHNvIHJlYWQgdGhlIGRvY3VtZW50IGJvdGggYWZ0ZXIgaXQgd2FzIGFjY2Vw
dGVkIGFzIGEgV0cgZG9jdW1lbnQNCmFuZCBkdXJpbmcgV0cgbGFzdCBjYWxsLiBUaGVyZSBoYXZl
IGJlZW4gc29tZSBwb2ludHMgb2YgZGlzY3Vzc2lvbiBkdXJpbmcNCnRoZSBkb2N1bWVudOKAmXMg
bGlmZSB0aGF0IHdlcmUgZGlzY3Vzc2VkIG9uIHRoZSBORVRNT0QgbGlzdCBvciBkdXJpbmcNCk5F
VE1PRCBvcGVuIG1lZXRpbmdzLiBUaGVyZSBhcmUgc29tZSBZQU5HIG5vZGVzIHRoYXQgSSBwcm9i
YWJseSB3b3VsZCBoYXZlDQpuYW1lZCBkaWZmZXJlbnRseSBhcyB3ZWxsLiBIb3dldmVyLCBJIGJl
bGlldmUgV0cgbGFzdCBjYWxsIGlzIGEgYml0IGxhdGUNCmFuZCB3b3VsZCBub3QgbGV0IG15IHBl
cnNvbmFsIGJpYXNlcyBkZWxheSBkb2N1bWVudCBwdWJsaWNhdGlvbi4NCg0KVGhhbmtzLA0KQWNl
ZSANCg0KDQo+IEFuZCB5ZXMsIEkgYmVsaWV2ZSBhIHN0YW5kYXJkIGluIHRoaXMgYXJlYQ0KPm5l
ZWRzIHRvIGJlIGhpZ2hseSBleHRlbnNpYmxlIChzbyB3ZSBiZXR0ZXIgZ2V0IHRoaXMgcmlnaHQp
IGFuZCBJDQo+YmVsaWV2ZSBpdCBuZWVkcyB0byBiZSByZXNvbmFibHkgbWF0Y2ggd2lkZWx5IGRl
cGxveWVkIG9wZW4gc291cmNlDQo+cGFja2V0IGZpbHRlcnMgYW5kIG5vdCBqdXN0IEp1bmlwZXIg
YW5kIENpc2NvIGdlYXIuDQo+DQo+L2pzDQo+DQo+UFM6IEkgcmVkdWNlZCB0aGUgQ0M6IGxpc3Qg
dG8gdGhlIE5FVE1PRCBXRyBzaW5jZSB0aGlzIGlzIHdoZXJlIHRoZQ0KPiAgICB3b3JrIGlzIHN1
cHBvc2VkIHRvIHRha2UgcGxhY2UuDQo+DQo+T24gVHVlLCBKYW4gMTksIDIwMTYgYXQgMDY6MTY6
NDdQTSArMDEwMCwgRWxpb3QgTGVhciB3cm90ZToNCj4+IEhpIEp1ZXJnZW4sDQo+PiANCj4+IFNr
aXBwaW5nIGRvd24uLi4NCj4+IA0KPj4gT24gMS8xOS8xNiA1OjQ4IFBNLCBKdWVyZ2VuIFNjaG9l
bndhZWxkZXIgd3JvdGU6DQo+PiANCj4+ID4gV2hpbGUgd2UgY2FuIGhhdmUgYSBsZW5ndGh5IGRl
YmF0ZSBhYm91dCB0ZXJtaW5vbG9neSwgSSB0aGluayBtb3JlDQo+PiA+IGltcG9ydGFudCBpcyB0
byBnZXQgZnVuY3Rpb25hbGl0eSByaWdodC4NCj4+IA0KPj4gQWdyZWUuICBXZSBhcmUgYXJndWlu
ZyBvdmVyIGxhYmVscyB0aGF0IGFyZW4ndCBnZW5lcmFsbHkgbWVhbnQgZm9yDQo+PiBodW1hbnMg
QU5ZV0FZLg0KPj4gDQo+PiA+Pj4gSSBhbSB0YWxraW5nIGFib3V0IHRoZSBtb2R1bGFyaXR5IG9m
IHRoZSBiYXNlIG1vZGVsLCBJIGRvIG5vdCBzZWUNCj4+aG93DQo+PiA+Pj4gdGhlIGNpdGVkIHRo
cmVhZCByZWxhdGVzIHRvIHRoaXMuDQo+PiA+PiBBbW9uZyB0aGUgdmVuZG9ycywgYWNlLWV0aCwg
YWNlLWlwdjQgYW5kIGFjZS1pcHY2IGFyZSBhbHdheXMNCj4+c3VwcG9ydGVkLiBJIGFwcHJlY2lh
dGUgeW91ciBpbnB1dCwgYnV0IHdlIGRpZCB0aGlzIGRlc2lnbiBjaG9pY2UgYXMNCj4+ZGVzaWdu
IHRlYW0gYW5kIHdlbnQgZm9yd2FyZCB3aXRoIGl0LiBBbHNvLCB0aGUgWUFORyBtb2RlbHMgYXJl
IG5vdCBzZXQNCj4+aW4gc3RvbmUuIEkgZGVmaW5pdGVseSBzZWUgbW9kZWxzIGV2b2x2aW5nLg0K
Pj4gPiBNeSBtYWluIGNvbmNlcm4gaXMgdGhhdCB3ZSBuZWVkIHRvIGdldCB0aGUgZXh0ZW5zaWJp
bGl0eSBvZiB0aGUgbW9kZWwNCj4+ID4gcmlnaHQuIE9uZSB3YXkgdG8gbWFrZSBzdXJlIHdlIGFj
aGlldmVkIHRoaXMgZ29hbCBpcyB0byBhY3R1YWxseSB0cmVhdA0KPj4gPiBldmVyeXRoaW5nIGFz
IGFuIGV4dGVuc2lvbiBvZiB0aGUgY29yZSBtb2RlbCAodGhpcyBmb3JjZXMgdXMgdG8gZ2V0DQo+
PiA+IHRoZSBleHRlbnNpYmlsaXR5IHJpZ2h0KS4gVGhpcyBpcyBlc3NlbnRpYWxseSB3aGF0IHdl
IGRpZCB3aXRoIHRoZQ0KPj4gPiByb3V0aW5nIGRhdGEgbW9kZWwgYW5kIHRoZSBpbnRlcmZhY2Vz
IGRhdGEgbW9kZWwuDQo+PiA+DQo+PiA+DQo+PiBXaGlsZSBJIGFncmVlIEkgYW0gYWxzbyBiZWNv
bWluZyBjb25jZXJuZWQgdGhhdCB3ZSBtYXkgYmUgZ29pbmcgZG93biBhDQo+PiByYXQgaG9sZSBm
cm9tIHdoaWNoIHdlIG1heSBub3QgcmV0dXJuLiAgVGhlIGFib3ZlIHRocmVhZCBzbmlwcGV0cyBo
YXZlDQo+PiBsb3N0IHNvIG11Y2ggY29udGV4dCB0aGF0IG9uZSBjYW5ub3QgZGl2aW5lIHdoYXQg
aXQgaXMgd2UgYXJlIGFyZ3VpbmcNCj4+IG92ZXIuICBXaGlsZSBhIGRlc2lnbiB0ZWFtIGNlcnRh
aW5seSBkb2VzIG5vdCByZXByZXNlbnQgY29uc2Vuc3VzLCBjYW4NCj4+IHdlIHBsZWFzZSBhdCBs
ZWFzdCBhcmd1ZSBvdmVyIHdoYXQgaXQgaXMgd2UgYXJlIHN1cHBvc2VkIHRvIGJlIGFyZ3VpbmcN
Cj4+IG92ZXI/ICBXaXRoIHJlZ2FyZCB0byB0aGlzIG1vZGVsLCBJIGNvdWxkIGltYWdpbmUgaW5u
dW1lcmFibGUgd2F5cyB0bw0KPj4gcmVwcmVzZW50IGFuIGFjY2VzcyBsaXN0LiAgVGhlIGRlZmVy
ZW5jZSBkdWUgdGhlIHBlb3BsZSB3aG8gd3JvdGUgdGhpcw0KPj4gc3R1ZmYgb3V0IGlzIGF0IGxl
YXN0IHRvIHJlY29nbml6ZSB0aGF0LiAgSWYgeW91IGFyZSBnb2luZyB0byBwcm9wb3NlIGFuDQo+
PiBhbHRlcm5hdGl2ZSBhdCB0aGlzIHBvaW50LCBwbGVhc2UgZG8gaXQgdGhlIG9sZCBmYXNoaW9u
IHdheTogc2VuZCB0ZXh0Lg0KPj4gDQo+PiBFbGlvdA0KPj4gDQo+DQo+DQo+DQo+PiBfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gbmV0bW9kIG1haWxp
bmcgbGlzdA0KPj4gbmV0bW9kQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL25ldG1vZA0KPg0KPg0KPi0tIA0KPkp1ZXJnZW4gU2Nob2Vud2FlbGRlciAg
ICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+UGhvbmU6ICs0OSA0MjEg
MjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0K
PkZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZl
cnNpdHkuZGUvPg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQo+bmV0bW9kIG1haWxpbmcgbGlzdA0KPm5ldG1vZEBpZXRmLm9yZw0KPmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg==


From yong.zhu@ericsson.com  Wed Jan 27 15:08:38 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236611B3108 for ; Wed, 27 Jan 2016 15:08:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KHLnVVG5vQ1 for ; Wed, 27 Jan 2016 15:08:36 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30E381B3105 for ; Wed, 27 Jan 2016 15:08:35 -0800 (PST)
X-AuditID: c1b4fb25-f797e6d000007600-7e-56a94def2285
Received: from ESGSCHC006.ericsson.se (Unknown_Domain [146.11.116.83]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 25.70.30208.0FD49A65; Thu, 28 Jan 2016 00:08:33 +0100 (CET)
Received: from ESGSCMB103.ericsson.se ([169.254.3.24]) by ESGSCHC006.ericsson.se ([146.11.116.83]) with mapi id 14.03.0248.002; Thu, 28 Jan 2016 07:08:31 +0800
From: Yong Zhu 
To: "netmod@ietf.org" 
Thread-Topic: What is the output of rpc-reply for  operation?
Thread-Index: AdFZVBGx1R4lM/+7QZ2CAxZt5MN8IQ==
Date: Wed, 27 Jan 2016 23:08:31 +0000
Message-ID: <31BFEF67CF6AC44BBEDE1890158D737738895A4A@ESGSCMB103.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [146.11.116.128]
Content-Type: multipart/alternative; boundary="_000_31BFEF67CF6AC44BBEDE1890158D737738895A4AESGSCMB103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyibskWPej78owgytLJC3mX2xkdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRt+eduaCOWcYK64t521gfLaesYuRk0NCwETizsb5bBC2mMSF e+uBbC4OIYHDjBK3Wt+xQDiLGSUa/vxnBqliE1CTOHF5KwuILSKgLjFz53qwbmEBW4lvU64x QsSdJA7f/MraxcgBZOtJnH0IVs4ioCpx4cl0MJtXwFei50YXmM0ItPj7qTVMIDazgLjErSfz mSAOEpBYsuc8M4QtKvHy8T9WCFtJovHVNqj6fImXv58wQcwUlDg58wnLBEahWUhGzUJSNgtJ GURcR2LB7k9sELa2xLKFr5lh7DMHHjMhiy9gZF/FKFqcWpyUm25krJdalJlcXJyfp5eXWrKJ ERgVB7f8Vt3BePmN4yFGAQ5GJR5eg0PLw4RYE8uKK3MPMUpwMCuJ8G52WhkmxJuSWFmVWpQf X1Sak1p8iFGag0VJnPcg/6IwIYH0xJLU7NTUgtQimCwTB6dUA6OH/EnR1tw7z1hmS2/0nf40 7UhUmPm5B0tNVzjdq19m1vpzXWIC+/Ub9tfLU5ZG7vvNL7Fqi3GgiwBr5qeH9ycKielFL6z6 vVYgz+jLmTWJm3+sqBE9J1ozV+JtQ7N5+OuNG36kLgoNPn931d2TLX1uq099uShqMllpRcu3 n7U84tqM4nuEz0xSYinOSDTUYi4qTgQAQ6t/IoYCAAA=
Archived-At: 
Subject: [netmod] What is the output of rpc-reply for  operation?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2016 23:10:01 -0000

--_000_31BFEF67CF6AC44BBEDE1890158D737738895A4AESGSCMB103erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

We got some question regarding netconf  operation's rpc-reply output.
For example, we have draft model as follows (list AAA contains list BBB whi=
ch contains list CCC):
                        list AAA {
                                                key "aaa_name";
                                                config false;
                                                leaf aaa_name {
                                                                        typ=
e string;
                                                }
                                                leaf aaa_leaf1 {
                                                                        typ=
e int32;
                                                }

                                                list BBB {
                                                                        key=
 "bbb_name";
                                                                        con=
fig false;
                                                                        lea=
f bbb_name {
                                                                           =
                     type string;
                                                                        }
                                                                    leaf bb=
b_leaf1 {
                                                                           =
 type uint32;
                                                }

                                                                        lis=
t CCC {
                                                                           =
                     key "ccc_name";
                                                                           =
                     config false;
                                                                           =
                     leaf ccc_name {
                                                                           =
                                             type string;
                                                                           =
                     }
                                                                           =
                     leaf ccc_leaf1 {
                                                                           =
                                             type uint32;
                                                                           =
                     }
                                                                        } /=
/list CCC
                                                } //list BBB
                        } //list AAA
The netconf  request is the following:

  

  
    
        
         
           
    


  


What is the expected ? More specifically, will CCC's key (leaf <=
ccc_name>) be included in rpc-reply? Will AAA/BBB's key (leaf  / =
) be included in rpc-reply?

The following is what I am thinking now. Please comment.

  

  my AAA name //???
  
    my BBB name //???
    
      my CCC name //???
      my ccc leaf1 name
    
  

  


Thanks
/Yong

--_000_31BFEF67CF6AC44BBEDE1890158D737738895A4AESGSCMB103erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


 


We got some question regarding netconf <get> o=
peration’s rpc-reply output.


For example, we have draft model as follows (list AA=
A contains list BBB which contains list CCC):


   &n=
bsp;            =
;        list AAA {

   &n=
bsp;            =
;            &n=
bsp;            =
;       key "aaa_name";<=
/span>


   &n=
bsp;            =
;            &n=
bsp;            =
;       config false;


   &n=
bsp;            =
;            &n=
bsp;            =
;       leaf aaa_name {


   &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;      type string;


   &n=
bsp;            =
;            &n=
bsp;            =
;       }


   &n=
bsp;            =
;            &n=
bsp;            =
;       leaf aaa_leaf1 {

   &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;      type int32;


   &n=
bsp;            =
;            &n=
bsp;            =
;       }


   &n=
bsp;            =
;            &n=
bsp;            =
;      



   &n=
bsp;            =
;            &n=
bsp;            =
;       list BBB {



   &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;      key "bbb_name";=



   &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;      config false;


   &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;      leaf bbb_name {


   &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;     type string;


   &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;      }


   &n=
bsp;            =
;            &n=
bsp;            =
;              =
            &nb=
sp;leaf bbb_leaf1 {


   &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;          type uint32;<=
/span>


   &n=
bsp;            =
;             &=
nbsp;           &nbs=
p;      }


 


   &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;      list CCC {


   &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;     key "ccc_name";


   &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;     config false;


   &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;     leaf ccc_name {


   &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;    type string;    



   &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;     }


   &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;     leaf ccc_leaf1 {


   &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;    type uint32;   



   &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;     }


   &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            =
;      } //list CCC


   &n=
bsp;            =
;            &n=
bsp;            =
;       } //list BBB


   &n=
bsp;            =
;        } //list AAA<=
/p>

The netconf <get> request is the following:


<rpc>


  <get>


<filter type=3D"subtree">


  <AAA>


    <BBB>


        <CCC>


         <ccc_leaf1/>=



   &n=
bsp;       </CCC>


    </BBB>


</AAA>


</filter>


  </get><=
o:p>


</rpc>


 


What is the expected <rpc-reply>? More specifi=
cally, will CCC’s key (leaf <ccc_name>) be included in rpc-repl=
y? Will AAA/BBB’s key (leaf <aaa_name> / <bbb_name>) be i=
ncluded in rpc-reply?


 


The following is what I am thinking now. Please comm=
ent.


<rpc-reply>


  <data>


<AAA>

  <aaa_name&g=
t;my AAA name</aaa_name> //???


  <BBB><=
/o:p>


    &l=
t;bbb_name>my BBB name</bbb_name> //???


    <C=
CC>


   &nb=
sp;  <ccc_name>my CCC name</ccc_name> //???=



    =
  <ccc_leaf1>my ccc leaf1 name</ccc_ leaf1>


    </=
CCC>


  </BBB>=



<AAA>

  </data>


</rpc-reply>


 


Thanks


/Yong






--_000_31BFEF67CF6AC44BBEDE1890158D737738895A4AESGSCMB103erics_--


From nobody Thu Jan 28 05:21:15 2016
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 648FF1A1B7D; Thu, 28 Jan 2016 05:21:13 -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.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160128132113.2459.1639.idtracker@ietfa.amsl.com>
Date: Thu, 28 Jan 2016 05:21:13 -0800
Archived-At: 
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-yang-json-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2016 13:21:13 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF.

        Title           : JSON Encoding of Data Modeled with YANG
        Author          : Ladislav Lhotka
	Filename        : draft-ietf-netmod-yang-json-07.txt
	Pages           : 20
	Date            : 2016-01-28

Abstract:
   This document defines encoding rules for representing configuration,
   state data, RPC operation or action input and output parameters, and
   notifications defined using YANG as JavaScript Object Notation (JSON)
   text.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-json/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-yang-json-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-json-07


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 28 05:22:42 2016
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E9CDA1A1BD7; Thu, 28 Jan 2016 05:22:40 -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.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160128132240.5043.49894.idtracker@ietfa.amsl.com>
Date: Thu, 28 Jan 2016 05:22:40 -0800
Archived-At: 
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-yang-metadata-03.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2016 13:22:41 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF.

        Title           : Defining and Using Metadata with YANG
        Author          : Ladislav Lhotka
	Filename        : draft-ietf-netmod-yang-metadata-03.txt
	Pages           : 20
	Date            : 2016-01-28

Abstract:
   This document defines a YANG extension statement that allows for
   defining metadata annotations in YANG modules.  The document also
   specifies XML and JSON encoding of annotations and other rules for
   annotating instances of YANG data nodes.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-metadata/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-metadata-03


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

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


From nobody Thu Jan 28 05:32:51 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38DDF1A6F41 for ; Thu, 28 Jan 2016 05:32:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.652
X-Spam-Level: 
X-Spam-Status: No, score=-5.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8QypdI3f-U1 for ; Thu, 28 Jan 2016 05:32: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 408071A6F47 for ; Thu, 28 Jan 2016 05:32:45 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:7976:8e4b:7868:48fb] (unknown [IPv6:2001:718:1a02:1:7976:8e4b:7868:48fb]) by mail.nic.cz (Postfix) with ESMTPSA id CD106181B12 for ; Thu, 28 Jan 2016 14:32:43 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1453987963; bh=s2TeAdbeS9BOOsvPjSFDmURuHZNQutYFu16LZEls8TA=; h=From:Date:To; b=XWp/dUTHwNtD9o+HaE7ttgZWUJ7mieRvEIEoRgI54XB85rH6Q1ALmvsfXOjmMiQB8 X+DZlEBaO/UtzcRXOefXreYBzKgCwaQ3nJhxHNDC591GuYWczMe5LMxoqwtE5Cglwh tZZJBqLVEL5fJ0WA1cwWEHPX9ZHf77p8m9fIvYys=
From: Ladislav Lhotka 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <852A0172-CA83-4EEE-93FB-533FAACDB6C8@nic.cz>
Date: Thu, 28 Jan 2016 14:32:44 +0100
To: NETMOD WG 
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: [netmod] new revisions of yang-json and yang-metadata
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2016 13:32:50 -0000

Hi,

I posted new revisions of the two drafts

* https://tools.ietf.org/html/draft-ietf-netmod-yang-json-07

* https://tools.ietf.org/html/draft-ietf-netmod-yang-metadata-03

The only technical change actually affects both: yang-json now generally =
permits special JSON object members whose names start with the '@' =
character. Consequently, all implementations of this draft have to be =
prepared to receive such members, and yang-metadata needn't care about =
syntactic problems.

Otherwise, I hope I corrected all typos and applied all formulation =
changes that were suggested in WGLC reviews and personal communication.

Lada

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





From nobody Thu Jan 28 07:51:51 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2BAD1A1BDF for ; Thu, 28 Jan 2016 07:51:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iH2jf3wH2Z5m for ; Thu, 28 Jan 2016 07:51:49 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5CF61A21A3 for ; Thu, 28 Jan 2016 07:51:48 -0800 (PST)
X-AuditID: c1b4fb2d-f78fe6d00000163a-3f-56aa3911a74f
Received: from ESGSCHC008.ericsson.se (Unknown_Domain [146.11.116.89]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 1B.D5.05690.2193AA65; Thu, 28 Jan 2016 16:51:46 +0100 (CET)
Received: from ESGSCMB103.ericsson.se ([169.254.3.24]) by ESGSCHC008.ericsson.se ([146.11.116.89]) with mapi id 14.03.0248.002; Thu, 28 Jan 2016 23:51:44 +0800
From: Yong Zhu 
To: "netmod@ietf.org" , Yong Zhu 
Thread-Topic: Question on the output of  rpc-reply for operational model?
Thread-Index: AdFZ48kcOvp7bh+2R8iuBpFNNttMwQ==
Date: Thu, 28 Jan 2016 15:51:43 +0000
Message-ID: <3v59h8lold2gd73ek5c1jb48.1453996301788@email.android.com>
References: 8:2363
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_3v59h8lold2gd73ek5c1jb481453996301788emailandroidcom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyibskUlfIclWYwd9TmhbzLzayOjB6LFny kymAMYrLJiU1J7MstUjfLoEr48qJp6wFp14xVixYpdbAuPEJYxcjJ4eEgInEjYttTBC2mMSF e+vZuhi5OIQEDjNKrNy0CspZzChxZs5+NpAqNgE1iROXt7KA2CICnhKff+0FiwsD2W82rmeE iAdINPzZygZh60m8+/INLM4ioCrxdXYzK4jNK+AmcaB7B9hmIQEhiZbVS8BsRqArvp9aA2Yz C4hL3HoyH+o6AYkle84zQ9iiEi8f/2OFqMmR6Pm9CWqmoMTJmU9YJjAKzULSPgtJ2SwkZbMY OYDimhLrd+lDlChKTOl+yA5ha0i0zpkLZVtLtM1ZzIqsZgEjxypG0eLU4uLcdCNjvdSizOTi 4vw8vbzUkk2MwGg5uOW37g7G1a8dDzEKcDAq8fAatKwME2JNLCuuzD3EKMHBrCTCO8toVZgQ b0piZVVqUX58UWlOavEhRmkOFiVx3oP8i8KEBNITS1KzU1MLUotgskwcnFINjBom0eHxp+Ni 5h/umLHWdkVanJhNlOAbd9YdMv8rflm2amm0nGjM+y+/enmf+d6Lkw5GhYfLVh4s+tKQ5nuh 2T1d79r5DdPn+9VH/mi6N0Gt8tavmaY/4u7uWG+3ZkHDv+7oq+8kVurNNu35vD255IbmSj+3 9P6iwxWThWs2Hz7Z9CB3+fvrX5RYijMSDbWYi4oTAb1ZfWuSAgAA
Archived-At: 
Subject: [netmod] Question on the output of  rpc-reply for operational model?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2016 15:51:51 -0000

--_000_3v59h8lold2gd73ek5c1jb481453996301788emailandroidcom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQoNCkhpIFdvcmsgZ3JvdXAsDQoNCg0KV2UgZ290IHNvbWUgcXVlc3Rpb24gcmVnYXJkaW5nIG5l
dGNvbmYgb3BlcmF0aW9u4oCZcyBycGMtcmVwbHkgb3V0cHV0Lg0KDQpGb3IgZXhhbXBsZSwgd2Ug
aGF2ZSBkcmFmdCBvcGVyYXRpb25hbCBtb2RlbCBhcyBmb2xsb3dzIChsaXN0IEFBQSBjb250YWlu
cyBsaXN0IEJCQiB3aGljaCBjb250YWlucyBsaXN0IENDQyk6DQoNCiAgICAgICAgICAgICAgICAg
ICAgICAgIGxpc3QgQUFBIHsNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAga2V5ICJhYWFfbmFtZSI7DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIGNvbmZpZyBmYWxzZTsNCg0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbGVhZiBhYWFfbmFtZSB7DQoNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHR5cGUgc3RyaW5nOw0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGxlYWYgYWFhX2xlYWYxIHsNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdHlwZSBpbnQzMjsN
Cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfQ0KDQoN
Cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbGlzdCBC
QkIgew0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBrZXkgImJiYl9uYW1lIjsNCg0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Y29uZmlnIGZhbHNlOw0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsZWFmIGJiYl9uYW1lIHsNCg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdHlwZSBzdHJpbmc7DQoNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIH0NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBsZWFmIGJiYl9sZWFmMSB7DQoNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICB0eXBlIHVpbnQzMjsNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgfQ0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbGlzdCBDQ0Mgew0KDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBrZXkgImNjY19uYW1lIjsNCg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uZmlnIGZhbHNlOw0KDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsZWFmIGNjY19uYW1lIHsNCg0KICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
dHlwZSBzdHJpbmc7DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH0N
Cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbGVhZiBjY2NfbGVhZjEg
ew0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICB0eXBlIHVpbnQzMjsNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB9IC8vbGlzdCBDQ0MNCg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfSAvL2xpc3QgQkJCDQoNCiAgICAg
ICAgICAgICAgICAgICAgICAgIH0gLy9saXN0IEFBQQ0KDQpUaGUgbmV0Y29uZiByZXF1ZXN0IGlz
IHRoZSBmb2xsb3dpbmc6DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K
DQoNCg0KDQoNCg0KDQoNCg0KV2hhdCBpcyB0aGUgZXhwZWN0ZWQgPyBNb3JlIHNwZWNpZmljYWxs
eSwgd2lsbCBDQ0PigJlzIGtleSAobGVhZiApIGJlIGluY2x1ZGVkIGluIHJwYy1yZXBseT8gV2ls
bCBBQUEvQkJC4oCZcyBrZXkgKGxlYWYgLyApIGJlIGluY2x1ZGVkIGluIHJwYy1yZXBseT8NCg0K
DQoNClRoZSBmb2xsb3dpbmcgaXMgd2hhdCBJIGFtIHRoaW5raW5nIG5vdy4gUGxlYXNlIGNvbW1l
bnQuDQoNCg0KDQoNCg0KDQoNCiAgbXkgQUFBIG5hbWUgLy8/Pz8NCg0KDQoNCiAgICBteSBCQkIg
bmFtZSAvLz8/Pw0KDQoNCg0KICAgICAgbXkgQ0NDIG5hbWUgLy8/Pz8NCg0KICAgICAgbXkgY2Nj
IGxlYWYxIG5hbWUNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KVGhhbmtzDQoNCi9Zb25nDQoN
Cg==

--_000_3v59h8lold2gd73ek5c1jb481453996301788emailandroidcom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBkaXI9Imx0
ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJs
dHIiPkhpIFdvcmsgZ3JvdXAsPGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rp
dj4NCjxkaXYgZGlyPSJsdHIiPiZuYnNwOzxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+V2Ug
Z290IHNvbWUgcXVlc3Rpb24gcmVnYXJkaW5nIG5ldGNvbmYgb3BlcmF0aW9u4oCZcyBycGMtcmVw
bHkgb3V0cHV0Ljxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2
IGRpcj0ibHRyIj5Gb3IgZXhhbXBsZSwgd2UgaGF2ZSBkcmFmdCBvcGVyYXRpb25hbCBtb2RlbCBh
cyBmb2xsb3dzIChsaXN0IEFBQSBjb250YWlucyBsaXN0IEJCQiB3aGljaCBjb250YWlucyBsaXN0
IENDQyk6PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGly
PSJsdHIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsaXN0IEFBQSB7PGJyPg0KPC9kaXY+DQo8
ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBrZXkgJnF1b3Q7YWFhX25h
bWUmcXVvdDs7PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYg
ZGlyPSJsdHIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyBjb25maWcgZmFsc2U7PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8
L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyBsZWFmIGFhYV9uYW1lIHs8YnI+DQo8L2Rpdj4NCjxkaXYgZGly
PSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IHR5cGUgc3RyaW5nOzxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9k
aXY+DQo8ZGl2IGRpcj0ibHRyIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgfTxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9k
aXY+DQo8ZGl2IGRpcj0ibHRyIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgbGVhZiBhYWFfbGVhZjEgezxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9
Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgdHlwZSBpbnQzMjs8YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2
Pg0KPGRpdiBkaXI9Imx0ciI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IH08YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2
Pg0KPGRpdiBkaXI9Imx0ciI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IDxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+
DQo8ZGl2IGRpcj0ibHRyIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgbGlzdCBCQkIgeyA8YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxi
cj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGtl
eSAmcXVvdDtiYmJfbmFtZSZxdW90Ozs8YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4N
CjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbmZp
ZyBmYWxzZTs8YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBk
aXI9Imx0ciI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxlYWYgYmJiX25hbWUgezxicj4N
CjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHlw
ZSBzdHJpbmc7PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYg
ZGlyPSJsdHIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PGJyPg0KPC9kaXY+DQo8ZGl2
IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsg
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bGVhZiBiYmJfbGVhZjEgezxi
cj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGUgdWludDMy
Ozxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRy
Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyB9PGJyPg0KPC9k
aXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPiZuYnNwOzxi
cj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbGlzdCBDQ0Mgezxicj4NCjwvZGl2Pg0KPGRpdiBk
aXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsga2V5ICZxdW90O2NjY19uYW1l
JnF1b3Q7Ozxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRp
cj0ibHRyIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgY29uZmlnIGZhbHNlOzxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0K
PC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbGVhZiBjY2NfbmFtZSB7PGJyPg0KPC9kaXY+DQo8ZGl2
IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyB0eXBlIHN0cmluZzsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjxicj4N
CjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTxi
cj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
bGVhZiBjY2NfbGVhZjEgezxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+
DQo8ZGl2IGRpcj0ibHRyIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHlwZSB1aW50
MzI7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4N
CjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxi
cj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH0g
Ly9saXN0IENDQzxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2
IGRpcj0ibHRyIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgfSAvL2xpc3QgQkJCPGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8
L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9IC8vbGlzdCBB
QUE8YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0
ciI+VGhlIG5ldGNvbmYgcmVxdWVzdCBpcyB0aGUgZm9sbG93aW5nOjxicj4NCjwvZGl2Pg0KPGRp
diBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxk
aXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+Jm5ic3A7IDxicj4NCjwv
ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8
L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+Jm5ic3A7
IDxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRy
Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxi
cj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOzxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8
ZGl2IGRpcj0ibHRyIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7
Jm5ic3A7PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGly
PSJsdHIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyA8YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRp
diBkaXI9Imx0ciI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0
ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJs
dHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0i
bHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPiZuYnNwOyA8YnI+DQo8L2Rpdj4NCjxk
aXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8
ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPiZuYnNwOzxicj4NCjwv
ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj5XaGF0IGlz
IHRoZSBleHBlY3RlZCA/IE1vcmUgc3BlY2lmaWNhbGx5LCB3aWxsIENDQ+KAmXMga2V5IChsZWFm
ICkgYmUgaW5jbHVkZWQgaW4gcnBjLXJlcGx5PyBXaWxsIEFBQS9CQkLigJlzIGtleSAobGVhZiAv
ICkgYmUgaW5jbHVkZWQgaW4gcnBjLXJlcGx5Pzxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+
PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj4mbmJzcDs8YnI+DQo8L2Rpdj4NCjxkaXYgZGly
PSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+VGhlIGZvbGxvd2luZyBpcyB3aGF0
IEkgYW0gdGhpbmtpbmcgbm93LiBQbGVhc2UgY29tbWVudC48YnI+DQo8L2Rpdj4NCjxkaXYgZGly
PSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRp
cj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPiZuYnNwOyA8YnI+DQo8L2Rpdj4N
CjxkaXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+
DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxiPiZuYnNwOyBt
eSBBQUEgbmFtZSAvLz8/PzwvYj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjwv
ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+Jm5ic3A7IDxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+
PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48Yj4mbmJzcDsmbmJzcDsmbmJzcDsgbXkgQkJC
IG5hbWUgLy8/Pz88L2I+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4N
CjxkaXYgZGlyPSJsdHIiPiZuYnNwOyZuYnNwOyZuYnNwOyA8YnI+DQo8L2Rpdj4NCjxkaXYgZGly
PSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IG15IENDQyBuYW1lIC8vPz8/PC9iPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9
Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgbXkgY2NjIGxlYWYxIG5hbWU8YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxi
cj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxicj4NCjwvZGl2
Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj4mbmJzcDsgPGJy
Pg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxi
cj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj4m
bmJzcDsgPGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGly
PSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRp
cj0ibHRyIj4mbmJzcDs8YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0K
PGRpdiBkaXI9Imx0ciI+VGhhbmtzPGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8
L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPi9Zb25nPGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48
YnI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_3v59h8lold2gd73ek5c1jb481453996301788emailandroidcom_--


From nobody Thu Jan 28 07:52:56 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC001A3B9B for ; Thu, 28 Jan 2016 07:52:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level: 
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJHUX10SDBea for ; Thu, 28 Jan 2016 07:52:54 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 1378D1A21A3 for ; Thu, 28 Jan 2016 07:52:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1453996363; bh=XBgN2KeMxEiGP3DRN3ajwlxGpiCzFPDN8fuPjocrhJQ=; h=From:Subject:Date:Cc:To; b=kEBsxT/VBBM5bawy/nzbyEWC0iIp4QBUCyEDFfnnKXBH9SomOxTweg1zGniejdJct 0QC3KMkiJ2Zg1PcmDRokYnTquMUuxgL8ZMWis/PUm02moKnsM5cFeD3dYBF3mgaJV8 d5ULrhyP9cwhTu9+VKXIo+bULsGLjmAbT1n0Clrs=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
From: Nadeau Thomas 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Thu, 28 Jan 2016 10:52:47 -0500
Message-Id: <603AAAB0-10B6-4AE0-AD04-55FF1565A1B6@lucidvision.com>
To: netmod WG 
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
X-Mailer: Apple Mail (2.3112)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=10 Stars=0 Good=0 Friend=4 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 258, in=3161, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: netmod-chairs@tools.ietf.org
Subject: [netmod] Mini WG Last Call: draft-ietf-netmod-yang-metadata-03
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2016 15:52:55 -0000

=09

This message is to officially begin a mini WG last call on =
draft-ietf-netmod-yang-metadata-03   Lada had to make a number of =
changes to the document based on feedback from the last call, and so the =
co-chairs felt that it was prudent to put this before the WG for a short =
LC period. I=E2=80=99d like this period to end on Monday, February 1 at =
9AM EST. Please post comments to the list so that they can be recorded =
if any are needed.

Thank you,

=E2=80=94Tom (speaking as co-chair)



From nobody Thu Jan 28 07:52:57 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCBC61A21A3 for ; Thu, 28 Jan 2016 07:52:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level: 
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T90UNF7qlcg5 for ; Thu, 28 Jan 2016 07:52:55 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 EA7FF1A1BDF for ; Thu, 28 Jan 2016 07:52:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1453996364; bh=U0AcHV9iejPqxMdcsF0Js4fD2vLbAc8vpV+HAbqKdgk=; h=From:Subject:Date:Cc:To; b=MfAnG3GbQ1THinhrlhcCyFGILj0yJHgSy4qZqNgmk/5CK5+wEKYLx9VBkiGlbG2nf ALySELIb0FQKo+6Sw0DWK9SUAb18sda8xUddGIkOdEVICMFzutiCKL2RkQbZnc69s4 gyNBVgC0wnsYILwezOrO/mEtDMZvaAq46/tdFMnA=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
From: Nadeau Thomas 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Thu, 28 Jan 2016 10:52:53 -0500
Message-Id: <811E1525-03C8-4118-A91E-2663AB484C78@lucidvision.com>
To: netmod WG 
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
X-Mailer: Apple Mail (2.3112)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=11 Stars=0 Good=0 Friend=4 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 258, in=3162, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: netmod-chairs@tools.ietf.org
Subject: [netmod] Mini WG Last Call draft-ietf-netmod-yang-json-07
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2016 15:52:56 -0000

	This message is to officially begin a mini WG last call on =
draft-ietf-netmod-yang-json-07.  Lada had to make a number of changes to =
the document based on feedback from the last call, and so the co-chairs =
felt that it was prudent to put this before the WG for a short LC =
period. I=E2=80=99d like this period to end on Monday, February 1 at 9AM =
EST. Please post comments to the list so that they can be recorded if =
any are needed.

	Thank you,

	=E2=80=94Tom (speaking as co-chair)



From nobody Thu Jan 28 08:25:02 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 271711B2D73 for ; Thu, 28 Jan 2016 08:24:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ox6M8HYfryvN for ; Thu, 28 Jan 2016 08:24:56 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0127.outbound.protection.outlook.com [207.46.100.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 475491B2D78 for ; Thu, 28 Jan 2016 08:24:50 -0800 (PST)
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1444.namprd05.prod.outlook.com (10.160.117.153) with Microsoft SMTP Server (TLS) id 15.1.365.19; Thu, 28 Jan 2016 16:24:49 +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.0396.015; Thu, 28 Jan 2016 16:24:49 +0000
From: Kent Watsen 
To: Yong Zhu , "netmod@ietf.org" 
Thread-Topic: [netmod] Question on the output of  rpc-reply for operational model?
Thread-Index: AQHRWehodv67n4cQeEmNjsLDsGYVlg==
Date: Thu, 28 Jan 2016 16:24:49 +0000
Message-ID: <36FA9C7D-6AC0-4B05-80A3-F60294999FD1@juniper.net>
References: <8:2363> <3v59h8lold2gd73ek5c1jb48.1453996301788@email.android.com>
In-Reply-To: <3v59h8lold2gd73ek5c1jb48.1453996301788@email.android.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.151105
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-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 5:EiXCsZFBEiV7J2BfNHapALsq0yvZ71mnw+q2CdKWx0vjJZx8ql31op+Y7msOqSyvzJ8zxfQTaHQpEkP9Q8aj0W4zAQPhNYs496EXaAfg5ASImGQJcMBALh9djtw/HJFDm2V00vVk2xC0MSKyMDuThg==; 24:f2FahoOpmwZLcQEharb5InoU+XhnTZ4U1pw+VzurXnsNRyV5bByXocRG8M7aoeNwNBO3u0MNP8j1woYravMAB/bCNObrLehe15fw99iusXE=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1444;
x-ms-office365-filtering-correlation-id: fb434aab-85dc-4e7b-7ae8-08d327ff8b15
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; 
x-forefront-prvs: 083526BF8A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(189002)(164054003)(199003)(19580405001)(87936001)(10400500002)(122556002)(3660700001)(40100003)(83506001)(92566002)(2906002)(86362001)(5001770100001)(2501003)(5004730100002)(1096002)(102836003)(82746002)(36756003)(16236675004)(107886002)(97736004)(2900100001)(77096005)(11100500001)(1220700001)(54356999)(5001960100002)(15975445007)(2950100001)(3846002)(106356001)(81156007)(83716003)(19580395003)(101416001)(76176999)(3470700001)(586003)(33656002)(5008740100001)(105586002)(3280700002)(189998001)(99286002)(66066001)(4001350100001)(5002640100001)(106116001)(50986999)(6116002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; 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:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_36FA9C7D6AC04B0580A3F60294999FD1junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2016 16:24:49.1237 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1444
Archived-At: 
Subject: Re: [netmod] Question on the output of  rpc-reply for operational model?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2016 16:24:59 -0000

--_000_36FA9C7D6AC04B0580A3F60294999FD1junipernet_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQpIaSBZb25nLA0KDQpUaGUgZm9ybWF0dGluZyBvbiB5b3VyIG1lc3NhZ2UgbWFrZXMgaXQgZGlm
ZmljdWx0IHRvIHJlYWQgLSBwbGVhc2UgY29uc2lkZXIgc2VuZGluZyB0byB0aGUgbGlzdCB1c2lu
ZyBwbGFpbiB0ZXh0Lg0KDQpPdGhlcndpc2UsIHNlZSBiZWxvdyBmb3IgY29tbWVudHMgLSBsb29r
IGZvciBbS0VOVF0uLi4NCg0KVGhhbmtzLA0KS2VudA0KDQoNCkZyb206IG5ldG1vZCA8bmV0bW9k
LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVo
YWxmIG9mIFlvbmcgWmh1IDx5b25nLnpodUBlcmljc3Nvbi5jb208bWFpbHRvOnlvbmcuemh1QGVy
aWNzc29uLmNvbT4+DQpEYXRlOiBUaHVyc2RheSwgSmFudWFyeSAyOCwgMjAxNiBhdCAxMDo1MSBB
TQ0KVG86ICJuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4iIDxuZXRtb2RA
aWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4+LCBZb25nIFpodSA8eW9uZy56aHVAZXJp
Y3Nzb24uY29tPG1haWx0bzp5b25nLnpodUBlcmljc3Nvbi5jb20+Pg0KU3ViamVjdDogW25ldG1v
ZF0gUXVlc3Rpb24gb24gdGhlIG91dHB1dCBvZiA8Z2V0PiBycGMtcmVwbHkgZm9yIG9wZXJhdGlv
bmFsIG1vZGVsPw0KDQoNCg0KSGkgV29yayBncm91cCwNCg0KDQpXZSBnb3Qgc29tZSBxdWVzdGlv
biByZWdhcmRpbmcgbmV0Y29uZiBvcGVyYXRpb27igJlzIHJwYy1yZXBseSBvdXRwdXQuDQoNCkZv
ciBleGFtcGxlLCB3ZSBoYXZlIGRyYWZ0IG9wZXJhdGlvbmFsIG1vZGVsIGFzIGZvbGxvd3MgKGxp
c3QgQUFBIGNvbnRhaW5zIGxpc3QgQkJCIHdoaWNoIGNvbnRhaW5zIGxpc3QgQ0NDKToNCg0KICAg
ICAgICAgICAgICAgICAgICAgICAgbGlzdCBBQUEgew0KDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBrZXkgImFhYV9uYW1lIjsNCg0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uZmlnIGZhbHNlOw0KDQogICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsZWFmIGFhYV9uYW1l
IHsNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgdHlwZSBzdHJpbmc7DQoNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgbGVhZiBhYWFfbGVhZjEgew0KDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB0eXBlIGludDMyOw0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB9DQoNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBsaXN0IEJCQiB7DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGtleSAiYmJiX25hbWUiOw0KDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBjb25maWcgZmFsc2U7DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxlYWYgYmJiX25h
bWUgew0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0eXBlIHN0cmlu
ZzsNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxlYWYgYmJiX2xlYWYxIHsNCg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHR5cGUgdWludDMyOw0KDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICB9DQoNCg0KDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsaXN0IEND
QyB7DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGtleSAiY2NjX25h
bWUiOw0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjb25maWcgZmFs
c2U7DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxlYWYgY2NjX25h
bWUgew0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICB0eXBlIHN0cmluZzsNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBs
ZWFmIGNjY19sZWFmMSB7DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHR5cGUgdWludDMyOw0KDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH0gLy9saXN0IENDQw0K
DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB9IC8vbGlz
dCBCQkINCg0KICAgICAgICAgICAgICAgICAgICAgICAgfSAvL2xpc3QgQUFBDQoNClRoZSBuZXRj
b25mIHJlcXVlc3QgaXMgdGhlIGZvbGxvd2luZzoNCg0KDQpbS0VOVF0gdGhlIHJlcXVlc3Qgc2Vl
bXMgdG8gYmUgbWlzc2luZyBoZXJlDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K
DQoNCg0KDQoNCg0KDQoNCg0KDQpXaGF0IGlzIHRoZSBleHBlY3RlZCA/DQoNCltLRU5UXSB0aGlz
IGRlcGVuZHMgb24gd2hhdCBkYXRhIGlzIGNvbmZpZ3VyZWQgb24gdGhlIHNlcnZlcg0KDQoNCk1v
cmUgc3BlY2lmaWNhbGx5LCB3aWxsIENDQ+KAmXMga2V5IChsZWFmICkgYmUgaW5jbHVkZWQgaW4g
cnBjLXJlcGx5PyBXaWxsIEFBQS9CQkLigJlzIGtleSAobGVhZiAvICkgYmUgaW5jbHVkZWQgaW4g
cnBjLXJlcGx5Pw0KDQpbS0VOVF0gZ2VuZXJhbGx5LCBsaXN0IGtleXMgYXJlIHJldHVybmVkIChl
LmcuLCAiYWFhX25hbWXigJ0pLiAgVGhlIHVzYWdlIGV4YW1wbGUgaGVyZSBzaG93cyBob3cgYSBs
aXN0IGlzIGVuY29kZWQgaW4gWE1MOiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt
aWV0Zi1uZXRtb2QtcmZjNjAyMGJpcy0wOSNzZWN0aW9uLTcuOC4zLjENCg0KDQoNClRoZSBmb2xs
b3dpbmcgaXMgd2hhdCBJIGFtIHRoaW5raW5nIG5vdy4gUGxlYXNlIGNvbW1lbnQuDQoNCg0KDQoN
Cg0KDQoNCiAgbXkgQUFBIG5hbWUgLy8/Pz8NCg0KDQoNCiAgICBteSBCQkIgbmFtZSAvLz8/Pw0K
DQoNCg0KICAgICAgbXkgQ0NDIG5hbWUgLy8/Pz8NCg0KICAgICAgbXkgY2NjIGxlYWYxIG5hbWUN
Cg0KDQoNCltLRU5UXSBJIGRvbuKAmXQgdW5kZXJzdGFuZCB0aGlzIGF0IGFsbC4NCg0KDQoNCg0K
DQoNCg0KDQoNClRoYW5rcw0KDQovWW9uZw0KDQo=

--_000_36FA9C7D6AC04B0580A3F60294999FD1junipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: <6647673538C30B48A4E9770B9CA14E0E@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5IaSBZb25nLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N
CjxkaXY+VGhlIGZvcm1hdHRpbmcgb24geW91ciBtZXNzYWdlIG1ha2VzIGl0IGRpZmZpY3VsdCB0
byByZWFkIC0gcGxlYXNlIGNvbnNpZGVyIHNlbmRpbmcgdG8gdGhlIGxpc3QgdXNpbmcgcGxhaW4g
dGV4dC4gJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5PdGhlcndpc2UsIHNl
ZSBiZWxvdyBmb3IgY29tbWVudHMgLSBsb29rIGZvciBbS0VOVF0uLi48L2Rpdj4NCjxkaXY+PGJy
Pg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+S2VudDwvZGl2Pg0KPGRpdj48YnI+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtf
U1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250
LXNpemU6MTJwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTog
bWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBp
bjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1
YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAz
cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5uZXRtb2Qg
Jmx0OzxhIGhyZWY9Im1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyI+bmV0bW9kLWJvdW5j
ZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgWW9uZyBaaHUgJmx0OzxhIGhyZWY9Im1h
aWx0bzp5b25nLnpodUBlcmljc3Nvbi5jb20iPnlvbmcuemh1QGVyaWNzc29uLmNvbTwvYT4mZ3Q7
PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5UaHVyc2Rh
eSwgSmFudWFyeSAyOCwgMjAxNiBhdCAxMDo1MSBBTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdl
aWdodDpib2xkIj5UbzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5v
cmciPm5ldG1vZEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRtb2RA
aWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT4mZ3Q7LCBZb25nIFpodSAmbHQ7PGEgaHJlZj0i
bWFpbHRvOnlvbmcuemh1QGVyaWNzc29uLmNvbSI+eW9uZy56aHVAZXJpY3Nzb24uY29tPC9hPiZn
dDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPltu
ZXRtb2RdIFF1ZXN0aW9uIG9uIHRoZSBvdXRwdXQgb2YgJmx0O2dldCZndDsgcnBjLXJlcGx5IGZv
ciBvcGVyYXRpb25hbCBtb2RlbD88YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJy
Pg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj5IaSBXb3JrIGdyb3VwLDxicj4NCjwvZGl2Pg0KPGRp
diBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj4mbmJzcDs8YnI+DQo8L2Rp
dj4NCjxkaXYgZGlyPSJsdHIiPldlIGdvdCBzb21lIHF1ZXN0aW9uIHJlZ2FyZGluZyBuZXRjb25m
IG9wZXJhdGlvbuKAmXMgcnBjLXJlcGx5IG91dHB1dC48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJs
dHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+Rm9yIGV4YW1wbGUsIHdlIGhhdmUgZHJh
ZnQgb3BlcmF0aW9uYWwgbW9kZWwgYXMgZm9sbG93cyAobGlzdCBBQUEgY29udGFpbnMgbGlzdCBC
QkIgd2hpY2ggY29udGFpbnMgbGlzdCBDQ0MpOjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+
PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbGlz
dCBBQUEgezxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRp
cj0ibHRyIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsga2V5ICZxdW90O2FhYV9uYW1lJnF1b3Q7Ozxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0
ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29uZmlnIGZhbHNlOzxicj4NCjwvZGl2Pg0K
PGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbGVhZiBhYWFfbmFtZSB7
PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIi
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0eXBlIHN0cmluZzs8YnI+DQo8L2Rpdj4NCjxk
aXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08YnI+DQo8L2Rpdj4NCjxk
aXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxlYWYgYWFhX2xlYWYxIHs8
YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGUgaW50MzI7PGJyPg0KPC9kaXY+DQo8ZGl2
IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PGJyPg0KPC9kaXY+DQo8ZGl2
IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YnI+DQo8L2Rpdj4NCjxkaXYg
ZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxpc3QgQkJCIHsgPGJyPg0KPC9k
aXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyBrZXkgJnF1b3Q7YmJiX25hbWUmcXVvdDs7PGJyPg0KPC9kaXY+
DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyBjb25maWcgZmFsc2U7PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRy
Ij48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyBsZWFmIGJiYl9uYW1lIHs8YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2
Pg0KPGRpdiBkaXI9Imx0ciI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGUgc3RyaW5nOzxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0
ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgfTxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0i
bHRyIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwO2xlYWYgYmJiX2xlYWYxIHs8YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjwv
ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZu
YnNwOyZuYnNwOyB0eXBlIHVpbnQzMjs8YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4N
CjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm
bmJzcDsmbmJzcDsgfTxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8
ZGl2IGRpcj0ibHRyIj4mbmJzcDs8YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjwv
ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxpc3QgQ0ND
IHs8YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0
ciI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IGtleSAmcXVvdDtjY2NfbmFtZSZxdW90Ozs8YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIi
Pjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbmZpZyBmYWxzZTs8YnI+DQo8L2Rpdj4N
CjxkaXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxlYWYgY2NjX25h
bWUgezxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0i
bHRyIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHlwZSBzdHJpbmc7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7DQo8YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2
Pg0KPGRpdiBkaXI9Imx0ciI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjwv
ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxlYWYgY2NjX2xlYWYxIHs8YnI+DQo8L2Rpdj4NCjxkaXYg
ZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IHR5cGUgdWludDMyOyZuYnNwOyZuYnNwOyZuYnNwOw0KPGJyPg0KPC9kaXY+
DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PGJyPg0KPC9k
aXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyB9IC8vbGlzdCBDQ0M8YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJs
dHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH0gLy9saXN0IEJCQjxicj4NCjwvZGl2Pg0K
PGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgfSAvL2xpc3QgQUFBPGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+
DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPlRoZSBuZXRjb25mIHJlcXVlc3QgaXMgdGhlIGZvbGxv
d2luZzo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwv
ZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
diBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj5bS0VOVF0gdGhlIHJlcXVl
c3Qgc2VlbXMgdG8gYmUgbWlzc2luZyBoZXJlPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8
L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPiZuYnNwOyA8YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIi
Pjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRy
Ij48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPiZuYnNwOyA8YnI+DQo8L2Rpdj4NCjxkaXYg
ZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGly
PSJsdHIiPiZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YnI+DQo8
L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOzxicj4NCjwvZGl2Pg0K
PGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGJyPg0KPC9k
aXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPiZuYnNwOyZu
YnNwOyZuYnNwOyA8YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRp
diBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxk
aXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8
ZGl2IGRpcj0ibHRyIj4mbmJzcDsgPGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8
L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0K
PC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj4mbmJzcDs8YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIi
Pjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+V2hhdCBpcyB0aGUgZXhwZWN0ZWQgPyA8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5bS0VO
VF0gdGhpcyBkZXBlbmRzIG9uIHdoYXQgZGF0YSBpcyBjb25maWd1cmVkIG9uIHRoZSBzZXJ2ZXI8
L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9M
S19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+TW9yZSBz
cGVjaWZpY2FsbHksIHdpbGwgQ0ND4oCZcyBrZXkgKGxlYWYgKSBiZSBpbmNsdWRlZCBpbiBycGMt
cmVwbHk/IFdpbGwgQUFBL0JCQuKAmXMga2V5IChsZWFmIC8gKSBiZSBpbmNsdWRlZCBpbiBycGMt
cmVwbHk/PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGly
PSJsdHIiPltLRU5UXSBnZW5lcmFsbHksIGxpc3Qga2V5cyBhcmUgcmV0dXJuZWQgKGUuZy4sICZx
dW90O2FhYV9uYW1l4oCdKS4gJm5ic3A7VGhlIHVzYWdlIGV4YW1wbGUgaGVyZSBzaG93cyBob3cg
YSBsaXN0IGlzIGVuY29kZWQgaW4gWE1MOiZuYnNwO2h0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9kcmFmdC1pZXRmLW5ldG1vZC1yZmM2MDIwYmlzLTA5I3NlY3Rpb24tNy44LjMuMTwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwv
ZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
diBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj5UaGUgZm9sbG93aW5nIGlz
IHdoYXQgSSBhbSB0aGlua2luZyBub3cuIFBsZWFzZSBjb21tZW50Ljxicj4NCjwvZGl2Pg0KPGRp
diBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxk
aXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+Jm5ic3A7IDxicj4NCjwv
ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8
L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGI+Jm5i
c3A7IG15IEFBQSBuYW1lIC8vPz8/PC9iPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJy
Pg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj4mbmJzcDsgPGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0i
bHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxiPiZuYnNwOyZuYnNwOyZuYnNwOyBt
eSBCQkIgbmFtZSAvLz8/PzwvYj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjwv
ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxicj4NCjwvZGl2Pg0KPGRp
diBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48Yj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgbXkgQ0NDIG5hbWUgLy8/Pz88L2I+PGJyPg0KPC9kaXY+DQo8ZGl2
IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyBteSBjY2MgbGVhZjEgbmFtZTxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0
ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj4mbmJzcDsmbmJzcDsmbmJzcDsgPGJyPg0K
PC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPltLRU5U
XSBJIGRvbuKAmXQgdW5kZXJzdGFuZCB0aGlzIGF0IGFsbC4gJm5ic3A7PGJyPg0KPC9kaXY+DQo8
ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0K
PGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj4mbmJzcDsgPGJyPg0K
PC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4N
CjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj4mbmJz
cDs8YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0
ciI+VGhhbmtzPGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4NCjxkaXYg
ZGlyPSJsdHIiPi9Zb25nPGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_36FA9C7D6AC04B0580A3F60294999FD1junipernet_--


From nobody Thu Jan 28 09:39:14 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A439B1A8F3C for ; Thu, 28 Jan 2016 09:39:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tA27gqaqUzCs for ; Thu, 28 Jan 2016 09:39:10 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D55C1A8F39 for ; Thu, 28 Jan 2016 09:39:09 -0800 (PST)
X-AuditID: c1b4fb30-f79a76d000000a93-29-56aa523ad749
Received: from ESGSCHC006.ericsson.se (Unknown_Domain [146.11.116.83]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id A6.3E.02707.A325AA65; Thu, 28 Jan 2016 18:39:07 +0100 (CET)
Received: from ESGSCMB103.ericsson.se ([169.254.3.24]) by ESGSCHC006.ericsson.se ([146.11.116.83]) with mapi id 14.03.0248.002; Fri, 29 Jan 2016 01:39:05 +0800
From: Yong Zhu 
To: Kent Watsen , "netmod@ietf.org" 
Thread-Topic: [netmod] Question on the output of  rpc-reply for operational model?
Thread-Index: AdFZ48kcOvp7bh+2R8iuBpFNNttMwf//gyKA//9o51A=
Date: Thu, 28 Jan 2016 17:39:04 +0000
Message-ID: <31BFEF67CF6AC44BBEDE1890158D737738896310@ESGSCMB103.ericsson.se>
References: <8:2363> <3v59h8lold2gd73ek5c1jb48.1453996301788@email.android.com> <36FA9C7D-6AC0-4B05-80A3-F60294999FD1@juniper.net>
In-Reply-To: <36FA9C7D-6AC0-4B05-80A3-F60294999FD1@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [146.11.116.7]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyibskWNc6aFWYwZwuSYsDc9gt5l9sZHVg 8liy5CeTx/Wmq+wBTFFcNimpOZllqUX6dglcGR0rNrAWzIqouPNvEUsD44/QLkZODgkBE4nu V7NYIWwxiQv31rN1MXJxCAkcZpTYvfESE4SzmFFi9aZZ7CBVbAJqEicub2UBsUUEvCQ2bP3M CGILC0RI9J7dwAgRj5RYefg6M4RtJfF5802wDSwCqhKzfn0Bsjk4eAV8JS5d1AAJCwm0MUq0 7Q4BsTkF7CVOb5nLBmIzAh30/dQaJhCbWUBc4taT+UwQhwpILNlznhnCFpV4+fgf1AMKEnP/ PWUGGc8soCmxfpc+RKuixJTuh2DX8woISpyc+YRlAqPoLCRTZyF0zELSMQtJxwJGllWMosWp xUm56UZGeqlFmcnFxfl5enmpJZsYgRFycMtvgx2ML587HmIU4GBU4uE1aFkZJsSaWFZcmXuI UYKDWUmEd7bVqjAh3pTEyqrUovz4otKc1OJDjNIcLErivAf5F4UJCaQnlqRmp6YWpBbBZJk4 OKUaGJPP/9f3mK1mecQx2dpsW2nTpsXPhZTni+bNKtfgPVx49MNaKUWvL3ySGwUuR85JXvZd paX0AceLdrm37/cLpfh3pLDtrjtbXljh0T/njkVOgnRaSM1chg3i+VeuvtMpMPn3bYqUfJzK K8U39ktU9gQxaX2sPCEXxP+RYWvsnI//fM1+PLjmqMRSnJFoqMVcVJwIABXXMieMAgAA
Archived-At: 
Subject: Re: [netmod] Question on the output of  rpc-reply for operational model?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2016 17:39:12 -0000

SGkgS2VudCBhbmQgV29ya2dyb3VwLA0KDQpUaGFuayBmb3IgeW91ciByZW1pbmRlci4gSSBjb252
ZXJ0IHRvIHBsYWluLXR4dCAobXkgb2xkIGZvcm1hdCBpcyB0ZXJyaWJsZS4gSikgUGxlYXNlIHNo
YXJlIHlvdXIgdGhvdWdodC4NCldlIGdvdCBzb21lIHF1ZXN0aW9uIHJlZ2FyZGluZyBuZXRjb25m
IG9wZXJhdGlvbuKAmXMgcnBjLXJlcGx5IG91dHB1dC4NCkZvciBleGFtcGxlLCB3ZSBoYXZlIGRy
YWZ0IG9wZXJhdGlvbmFsIG1vZGVsIGFzIGZvbGxvd3MgKGxpc3QgQUFBIGNvbnRhaW5zIGxpc3Qg
QkJCIHdoaWNoIGNvbnRhaW5zIGxpc3QgQ0NDKToNCmxpc3QgQUFBIHsNCiAga2V5ICJhYWFfbmFt
ZSI7DQogIGNvbmZpZyBmYWxzZTsNCiAgbGVhZiBhYWFfbmFtZSB7DQogICAgdHlwZSBzdHJpbmc7
DQogIH0NCiAgbGVhZiBhYWFfbGVhZjEgew0KICAgIHR5cGUgaW50MzI7DQogICB9DQogICBsaXN0
IEJCQiB7IA0KICAgICBrZXkgImJiYl9uYW1lIjsNCiAgICAgY29uZmlnIGZhbHNlOw0KICAgICBs
ZWFmIGJiYl9uYW1lIHsNCiAgICAgICB0eXBlIHN0cmluZzsNCiAgICAgfQ0KICAgICBsZWFmIGJi
Yl9sZWFmMSB7DQogICAgICAgdHlwZSB1aW50MzI7DQogICAgIH0NCiAgICAgbGlzdCBDQ0Mgew0K
ICAgICAgIGtleSAiY2NjX25hbWUiOw0KICAgICAgIGNvbmZpZyBmYWxzZTsNCiAgICAgICBsZWFm
IGNjY19uYW1lIHsNCiAgICAgICAgIHR5cGUgc3RyaW5nOyAgICAgDQogICAgICAgfQ0KICAgICAg
IGxlYWYgY2NjX2xlYWYxIHsNCiAgICAgICAgIHR5cGUgdWludDMyDQogICAgICAgfQ0KICAgICB9
IC8vbGlzdCBDQ0MNCiAgfSAvL2xpc3QgQkJCDQp9IC8vbGlzdCBBQUENCg0KVGhlIG5ldGNvbmYg
PHJwYz4gcmVxdWVzdCBpcyB0aGUgZm9sbG93aW5nOg0KPHJwYz4NCiAgPGdldD4NCiAgICA8Zmls
dGVyIHR5cGU9InN1YnRyZWUiPg0KICAgICAgPEFBQT4NCiAgICAgICA8QkJCPg0KICAgICAgICA8
Q0NDPg0KICAgICAgICAgIDxjY2NfbGVhZjEvPiAgLy9xdWVyeSBvbiBjY2MgbGVhZiBub2RlDQog
ICAgICAgIDwvQ0NDPg0KICAgICAgIDwvQkJCPg0KICAgICAgPC9BQUE+DQogICA8L2ZpbHRlcj4N
CiAgPC9nZXQ+DQo8L3JwYz4NCg0KV2hhdCBpcyB0aGUgZXhwZWN0ZWQgPyBNb3JlIHNwZWNpZmlj
YWxseSwgd2lsbCBDQ0PigJlzIGtleSAobGVhZiApIGJlIGluY2x1ZGVkIGluIHJwYy1yZXBseT8g
V2lsbCBBQUEvQkJC4oCZcyBrZXkgKGxlYWYgLyApIGJlIGluY2x1ZGVkIGluIHJwYy1yZXBseT8N
ClRoZSBmb2xsb3dpbmcgaXMgd2hhdCBJIGFtIHRoaW5raW5nIG5vdy4gUGxlYXNlIGNvbW1lbnQu
DQo8cnBjLXJlcGx5Pg0KPGRhdGE+DQogIDxBQUE+DQogICAgPGFhYV9uYW1lPm15IGFhYSBuYW1l
PC9hYWFfbmFtZT4NCiAgICA8QkJCPg0KICAgICAgPGJiYl9uYW1lPm15IGJiYiBuYW1lPC9iYmJf
bmFtZT4NCiAgICAgIDxDQ0M+DQogICAgICAgPGNjY19uYW1lPm15IGNjYyBuYW1lPC9jY2NfbmFt
ZT4NCiAgICAgICA8Y2NjX2xlYWYxPm15IGNjYyBsZWFmMTwvY2NjX2xlYWYxPg0KICAgICAgPC9D
Q0M+DQogICAgPC9CQkI+DQogIDwvQUFBPg0KPC9kYXRhPg0KPC9ycGMtcmVwbHk+DQoNClRoYW5r
cw0KL1lvbmcNCg0KRnJvbTogS2VudCBXYXRzZW4gW21haWx0bzprd2F0c2VuQGp1bmlwZXIubmV0
XSANClNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDI4LCAyMDE2IDg6MjUgQU0NClRvOiBZb25nIFpo
dTsgbmV0bW9kQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW25ldG1vZF0gUXVlc3Rpb24gb24gdGhl
IG91dHB1dCBvZiA8Z2V0PiBycGMtcmVwbHkgZm9yIG9wZXJhdGlvbmFsIG1vZGVsPw0KDQoNCkhp
IFlvbmcsDQoNClRoZSBmb3JtYXR0aW5nIG9uIHlvdXIgbWVzc2FnZSBtYWtlcyBpdCBkaWZmaWN1
bHQgdG8gcmVhZCAtIHBsZWFzZSBjb25zaWRlciBzZW5kaW5nIHRvIHRoZSBsaXN0IHVzaW5nIHBs
YWluIHRleHQuIMKgDQoNCk90aGVyd2lzZSwgc2VlIGJlbG93IGZvciBjb21tZW50cyAtIGxvb2sg
Zm9yIFtLRU5UXS4uLg0KDQpUaGFua3MsDQpLZW50DQoNCg0KRnJvbTogbmV0bW9kIDxuZXRtb2Qt
Ym91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIFlvbmcgWmh1IDx5b25nLnpodUBlcmljc3Nv
bi5jb20+DQpEYXRlOiBUaHVyc2RheSwgSmFudWFyeSAyOCwgMjAxNiBhdCAxMDo1MSBBTQ0KVG86
ICJuZXRtb2RAaWV0Zi5vcmciIDxuZXRtb2RAaWV0Zi5vcmc+LCBZb25nIFpodSA8eW9uZy56aHVA
ZXJpY3Nzb24uY29tPg0KU3ViamVjdDogW25ldG1vZF0gUXVlc3Rpb24gb24gdGhlIG91dHB1dCBv
ZiA8Z2V0PiBycGMtcmVwbHkgZm9yIG9wZXJhdGlvbmFsIG1vZGVsPw0KDQoNCg0KSGkgV29yayBn
cm91cCwNCg0KwqANCldlIGdvdCBzb21lIHF1ZXN0aW9uIHJlZ2FyZGluZyBuZXRjb25mIG9wZXJh
dGlvbuKAmXMgcnBjLXJlcGx5IG91dHB1dC4NCg0KRm9yIGV4YW1wbGUsIHdlIGhhdmUgZHJhZnQg
b3BlcmF0aW9uYWwgbW9kZWwgYXMgZm9sbG93cyAobGlzdCBBQUEgY29udGFpbnMgbGlzdCBCQkIg
d2hpY2ggY29udGFpbnMgbGlzdCBDQ0MpOg0KDQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgIGxpc3QgQUFBIHsNCg0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoCBrZXkgImFhYV9uYW1lIjsNCg0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoCBjb25maWcgZmFsc2U7DQoNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqAgbGVhZiBhYWFfbmFtZSB7DQoNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqAgdHlwZSBzdHJpbmc7DQoNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg
fQ0KDQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGxlYWYgYWFhX2xlYWYx
IHsNCg0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB0eXBlIGludDMyOw0KDQrCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIH0NCg0KwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoCANCg0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oCBsaXN0IEJCQiB7IA0KDQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGtleSAiYmJiX25h
bWUiOw0KDQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGNvbmZpZyBmYWxzZTsNCg0KwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBsZWFmIGJiYl9uYW1lIHsNCg0KwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoCB0eXBlIHN0cmluZzsNCg0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB9DQoN
CsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgwqDCoMKgIMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgbGVhZiBiYmJfbGVhZjEgew0KDQrCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgIMKgwqDCoCB0eXBlIHVpbnQzMjsNCg0KwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgIMKgwqAgfQ0KDQrCoA0KDQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGxp
c3QgQ0NDIHsNCg0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBrZXkgImNjY19uYW1lIjsNCg0KwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoCBjb25maWcgZmFsc2U7DQoNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgbGVhZiBj
Y2NfbmFtZSB7DQoNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgdHlwZSBzdHJpbmc7wqDCoMKgwqAgDQoNCsKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqAgfQ0KDQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGxlYWYgY2NjX2xlYWYxIHsNCg0K
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoCB0eXBlIHVpbnQzMjvCoMKgwqAgDQoNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfQ0K
DQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIH0gLy9saXN0IENDQw0KDQrCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIH0gLy9saXN0IEJCQg0KDQrCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIH0gLy9saXN0IEFBQQ0KDQpUaGUgbmV0
Y29uZiByZXF1ZXN0IGlzIHRoZSBmb2xsb3dpbmc6DQoNCg0KW0tFTlRdIHRoZSByZXF1ZXN0IHNl
ZW1zIHRvIGJlIG1pc3NpbmcgaGVyZQ0KDQrCoCANCg0KDQoNCsKgIA0KDQrCoMKgwqDCoA0KDQrC
oCDCoMKgwqDCoMKgwqANCg0KwqDCoMKgwqDCoMKgIMKgwqANCg0KwqDCoMKgwqDCoMKgwqDCoMKg
wqAgDQoNCsKgwqDCoCANCg0KDQoNCg0KDQrCoCANCg0KDQoNCsKgDQoNCldoYXQgaXMgdGhlIGV4
cGVjdGVkID8gDQoNCltLRU5UXSB0aGlzIGRlcGVuZHMgb24gd2hhdCBkYXRhIGlzIGNvbmZpZ3Vy
ZWQgb24gdGhlIHNlcnZlcg0KDQoNCk1vcmUgc3BlY2lmaWNhbGx5LCB3aWxsIENDQ+KAmXMga2V5
IChsZWFmICkgYmUgaW5jbHVkZWQgaW4gcnBjLXJlcGx5PyBXaWxsIEFBQS9CQkLigJlzIGtleSAo
bGVhZiAvICkgYmUgaW5jbHVkZWQgaW4gcnBjLXJlcGx5Pw0KDQpbS0VOVF0gZ2VuZXJhbGx5LCBs
aXN0IGtleXMgYXJlIHJldHVybmVkIChlLmcuLCAiYWFhX25hbWXigJ0pLiDCoFRoZSB1c2FnZSBl
eGFtcGxlIGhlcmUgc2hvd3MgaG93IGEgbGlzdCBpcyBlbmNvZGVkIGluIFhNTDrCoGh0dHBzOi8v
dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldG1vZC1yZmM2MDIwYmlzLTA5I3NlY3Rp
b24tNy44LjMuMQ0KDQoNCg0KVGhlIGZvbGxvd2luZyBpcyB3aGF0IEkgYW0gdGhpbmtpbmcgbm93
LiBQbGVhc2UgY29tbWVudC4NCg0KDQoNCsKgIA0KDQoNCg0KwqAgbXkgQUFBIG5hbWUgLy8/Pz8N
Cg0KwqAgDQoNCsKgwqDCoCBteSBCQkIgbmFtZSAvLz8/Pw0KDQrCoMKgwqAgDQoNCsKgwqDCoMKg
wqAgbXkgQ0NDIG5hbWUgLy8/Pz8NCg0KwqDCoMKgwqDCoCBteSBjY2MgbGVhZjEgbmFtZQ0KDQrC
oMKgwqAgDQoNCltLRU5UXSBJIGRvbuKAmXQgdW5kZXJzdGFuZCB0aGlzIGF0IGFsbC4gwqANCg0K
DQoNCsKgIA0KDQoNCg0KwqANCg0KVGhhbmtzDQoNCi9Zb25nDQoNCg==


From nobody Thu Jan 28 10:03:34 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9321B2E36 for ; Thu, 28 Jan 2016 10:03:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuR5JO9s-9Up for ; Thu, 28 Jan 2016 10:03:30 -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 096211AD370 for ; Thu, 28 Jan 2016 10:03:30 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B1C4F6D7; Thu, 28 Jan 2016 19:03:28 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id OLeWGa-dlDI4; Thu, 28 Jan 2016 19:03:27 +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, 28 Jan 2016 19:03:27 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E0CB620031; Thu, 28 Jan 2016 19:03:26 +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 T5gwMoUdvrav; Thu, 28 Jan 2016 19:03:24 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 109342002C; Thu, 28 Jan 2016 19:03:24 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id E30A139C591B; Thu, 28 Jan 2016 19:03:23 +0100 (CET)
Date: Thu, 28 Jan 2016 19:03:23 +0100
From: Juergen Schoenwaelder 
To: Yong Zhu 
Message-ID: <20160128180323.GB3516@elstar.local>
Mail-Followup-To: Yong Zhu , Kent Watsen , "netmod@ietf.org" 
References: <3v59h8lold2gd73ek5c1jb48.1453996301788@email.android.com> <36FA9C7D-6AC0-4B05-80A3-F60294999FD1@juniper.net> <31BFEF67CF6AC44BBEDE1890158D737738896310@ESGSCMB103.ericsson.se>
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: <31BFEF67CF6AC44BBEDE1890158D737738896310@ESGSCMB103.ericsson.se>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Question on the output of  rpc-reply for operational model?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2016 18:03:33 -0000

Hi,

your question is mainly a protocol question and not so much a YANG
question so it probably belongs to NETCONF more than NETMOD. RFC 6241
in the section describing subtree filtering says:

   o  If any sibling nodes of the selection node are instance identifier
      components for a conceptual data structure (e.g., list key leaf),
      then they MAY also be included in the filter output.

I would expect that sensible implementations implement the MAY and
include sibling key leafs (and that they would do this recursively).

/js

On Thu, Jan 28, 2016 at 05:39:04PM +0000, Yong Zhu wrote:
> Hi Kent and Workgroup,
> 
> Thank for your reminder. I convert to plain-txt (my old format is terrible. J) Please share your thought.
> We got some question regarding netconf operation’s rpc-reply output.
> For example, we have draft operational model as follows (list AAA contains list BBB which contains list CCC):
> list AAA {
>   key "aaa_name";
>   config false;
>   leaf aaa_name {
>     type string;
>   }
>   leaf aaa_leaf1 {
>     type int32;
>    }
>    list BBB { 
>      key "bbb_name";
>      config false;
>      leaf bbb_name {
>        type string;
>      }
>      leaf bbb_leaf1 {
>        type uint32;
>      }
>      list CCC {
>        key "ccc_name";
>        config false;
>        leaf ccc_name {
>          type string;     
>        }
>        leaf ccc_leaf1 {
>          type uint32
>        }
>      } //list CCC
>   } //list BBB
> } //list AAA
> 
> The netconf  request is the following:
> 
>   
>     
>       
>        
>         
>             //query on ccc leaf node
>         
>        
>       
>    
>   
> 
> 
> What is the expected ? More specifically, will CCC’s key (leaf ) be included in rpc-reply? Will AAA/BBB’s key (leaf / ) be included in rpc-reply?
> The following is what I am thinking now. Please comment.
> 
> 
>   
>     my aaa name
>     
>       my bbb name
>       
>        my ccc name
>        my ccc leaf1
>       
>     
>   
> 
> 
> 
> Thanks
> /Yong
> 
> From: Kent Watsen [mailto:kwatsen@juniper.net] 
> Sent: Thursday, January 28, 2016 8:25 AM
> To: Yong Zhu; netmod@ietf.org
> Subject: Re: [netmod] Question on the output of  rpc-reply for operational model?
> 
> 
> Hi Yong,
> 
> The formatting on your message makes it difficult to read - please consider sending to the list using plain text.  
> 
> Otherwise, see below for comments - look for [KENT]...
> 
> Thanks,
> Kent
> 
> 
> From: netmod  on behalf of Yong Zhu 
> Date: Thursday, January 28, 2016 at 10:51 AM
> To: "netmod@ietf.org" , Yong Zhu 
> Subject: [netmod] Question on the output of  rpc-reply for operational model?
> 
> 
> 
> Hi Work group,
> 
>  
> We got some question regarding netconf operation’s rpc-reply output.
> 
> For example, we have draft operational model as follows (list AAA contains list BBB which contains list CCC):
> 
>                         list AAA {
> 
>                                                 key "aaa_name";
> 
>                                                 config false;
> 
>                                                 leaf aaa_name {
> 
>                                                                         type string;
> 
>                                                 }
> 
>                                                 leaf aaa_leaf1 {
> 
>                                                                         type int32;
> 
>                                                 }
> 
>                                                 
> 
>                                                 list BBB { 
> 
>                                                                         key "bbb_name";
> 
>                                                                         config false;
> 
>                                                                         leaf bbb_name {
> 
>                                                                                                 type string;
> 
>                                                                         }
> 
>                                                                     leaf bbb_leaf1 {
> 
>                                                                             type uint32;
> 
>                                                 }
> 
>  
> 
>                                                                         list CCC {
> 
>                                                                                                 key "ccc_name";
> 
>                                                                                                 config false;
> 
>                                                                                                 leaf ccc_name {
> 
>                                                                                                                         type string;     
> 
>                                                                                                 }
> 
>                                                                                                 leaf ccc_leaf1 {
> 
>                                                                                                                         type uint32;    
> 
>                                                                                                 }
> 
>                                                                         } //list CCC
> 
>                                                 } //list BBB
> 
>                         } //list AAA
> 
> The netconf request is the following:
> 
> 
> [KENT] the request seems to be missing here
> 
>   
> 
> 
> 
>   
> 
>     
> 
>         
> 
>          
> 
>            
> 
>     
> 
> 
> 
> 
> 
>   
> 
> 
> 
>  
> 
> What is the expected ? 
> 
> [KENT] this depends on what data is configured on the server
> 
> 
> More specifically, will CCC’s key (leaf ) be included in rpc-reply? Will AAA/BBB’s key (leaf / ) be included in rpc-reply?
> 
> [KENT] generally, list keys are returned (e.g., "aaa_name”).  The usage example here shows how a list is encoded in XML: https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-09#section-7.8.3.1
> 
> 
> 
> The following is what I am thinking now. Please comment.
> 
> 
> 
>   
> 
> 
> 
>   my AAA name //???
> 
>   
> 
>     my BBB name //???
> 
>     
> 
>       my CCC name //???
> 
>       my ccc leaf1 name
> 
>     
> 
> [KENT] I don’t understand this at all.  
> 
> 
> 
>   
> 
> 
> 
>  
> 
> Thanks
> 
> /Yong
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Thu Jan 28 10:57:44 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA14D1B2F88 for ; Thu, 28 Jan 2016 10:57:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.803
X-Spam-Level: 
X-Spam-Status: No, score=-0.803 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFtfvA6xNI3O for ; Thu, 28 Jan 2016 10:57:40 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D24F31ACDA6 for ; Thu, 28 Jan 2016 10:57:40 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id C0CE724E0E8 for ; Thu, 28 Jan 2016 10:57:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1454007460; bh=KrxTycPlH6rlF/HhqHNSrumsWONmwAvQfetz0nd3pUM=; h=To:From:Subject:Date:From; b=ZaHq719NrqBnV+KCapc3aLbFgMZ8JDhVRTW8sRQ5pFLtutp7NmR/+ehNU6QxvV2G3 P2hoPfkaUHSfrFVin9sn5+Jo84Km2yGb19vBtrrEyk2SFxhiCsQBLAATSyLhw4fnll OxS7JZxRK8PbPzXXCyArHbRcTwpRAGnTEhjMadao=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 7C1FA246737 for ; Thu, 28 Jan 2016 10:57:40 -0800 (PST)
To: NETMOD Working Group 
From: "Joel M. Halpern" 
Message-ID: <56AA6492.7090802@joelhalpern.com>
Date: Thu, 28 Jan 2016 13:57:22 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [netmod] minor question - YANG Document Guidelines: Imports
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2016 18:57:42 -0000

I ran into something while reading a YANG internet-draft recently, and I 
wonder if a bit of advice in the YANG Document Guidelines (rfc6087bis) 
would be reasonable.

Section 4.8 of the guidelines states that any imported modules must also 
have a reference in the references section.  Which is good.  But there 
is no obvious way for a human reader to relate the two.

Would it be sensible to recommend in this document (I don't know if it 
would be 4.8 or a new section later in the document) that import 
statements have a comment with them either naming the internet draft / 
RFC they are importing from, or pointing to the reference which names it?

Thank you,
Joel


From nobody Thu Jan 28 11:01:44 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 592DD1B352C for ; Thu, 28 Jan 2016 11:01:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level: 
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYveiCeSFU6s for ; Thu, 28 Jan 2016 11:01:41 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 16C001B352D for ; Thu, 28 Jan 2016 11:01:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1454007690; bh=b7wcrMME8qAy9IGa7kUdZ/B2hVRPSuGnPIHac5UF0B0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=ek7TzbigF3d9iZNombJZMQevn8N3mdsAgj50hU1t36H+eG8VzNWjce8l45gCnPCXW 20w79MY16OFw6aefrL/zZZP9C9qQh+YGq1LLlMZn0bO+WXrHsVEuq1lRCTqIxp9fK0 VS49B2bDRgpZTnylLUquh3JG8qj7/PLmYgH8U3Ac=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=107.107.58.9; 
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: thomas nadeau 
X-Mailer: iPhone Mail (13D15)
In-Reply-To: <56AA6492.7090802@joelhalpern.com>
Date: Thu, 28 Jan 2016 14:00:52 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <56AA6492.7090802@joelhalpern.com>
To: "Joel M. Halpern" 
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-MyRbl: Color=Unknown ip=107.107.58.9
X-IP-stats: No info recorded yet Known=true ip=107.107.58.9
Archived-At: 
Cc: NETMOD Working Group 
Subject: Re: [netmod] minor question - YANG Document Guidelines: Imports
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2016 19:01:43 -0000

Thats a great idea. I ran into the same thing yesterday and had to fish arou=
nd to find the actual RFC it came from.

tom


> On Jan 28, 2016, at 1:57 PM, Joel M. Halpern  wrote:
>=20
> I ran into something while reading a YANG internet-draft recently, and I w=
onder if a bit of advice in the YANG Document Guidelines (rfc6087bis) would b=
e reasonable.
>=20
> Section 4.8 of the guidelines states that any imported modules must also h=
ave a reference in the references section.  Which is good.  But there is no o=
bvious way for a human reader to relate the two.
>=20
> Would it be sensible to recommend in this document (I don't know if it wou=
ld be 4.8 or a new section later in the document) that import statements hav=
e a comment with them either naming the internet draft / RFC they are import=
ing from, or pointing to the reference which names it?
>=20
> Thank you,
> Joel
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Thu Jan 28 11:02:06 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 716331B3531 for ; Thu, 28 Jan 2016 11:02:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level: 
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62DD80rWrPXI for ; Thu, 28 Jan 2016 11:02:04 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 4AA8B1B352D for ; Thu, 28 Jan 2016 11:02:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1454007713; bh=b7wcrMME8qAy9IGa7kUdZ/B2hVRPSuGnPIHac5UF0B0=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=X9p2GPND3aKGnuTPgrvJWMxi9JOUeeKwVa42m5i/AkKmkNa4zc3H931Z8706vBfJi npn9C/f9yH4JhCP7okQYmqSUOQvcwzyoiH2LMIuVGFzVSWhuLeG1BrKa+Her+Y4nOX p2BxhjqfCWiVEnl3NAkbSgO6DMFuxXQA9hH9d3u4=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=107.107.58.9; 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
From: thomas nadeau 
Mime-Version: 1.0 (1.0)
Date: Thu, 28 Jan 2016 14:00:52 -0500
Message-Id: 
References: <56AA6492.7090802@joelhalpern.com>
In-Reply-To: <56AA6492.7090802@joelhalpern.com>
To: "Joel M. Halpern" 
X-Mailer: iPhone Mail (13D15)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=1 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=107.107.58.9
X-IP-stats: Notspam Incoming Last 0, First 0, in=1, out=0, spam=0 Known=true ip=107.107.58.9
Archived-At: 
Cc: NETMOD Working Group 
Subject: Re: [netmod] minor question - YANG Document Guidelines: Imports
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2016 19:02:05 -0000

Thats a great idea. I ran into the same thing yesterday and had to fish arou=
nd to find the actual RFC it came from.

tom


> On Jan 28, 2016, at 1:57 PM, Joel M. Halpern  wrote:
>=20
> I ran into something while reading a YANG internet-draft recently, and I w=
onder if a bit of advice in the YANG Document Guidelines (rfc6087bis) would b=
e reasonable.
>=20
> Section 4.8 of the guidelines states that any imported modules must also h=
ave a reference in the references section.  Which is good.  But there is no o=
bvious way for a human reader to relate the two.
>=20
> Would it be sensible to recommend in this document (I don't know if it wou=
ld be 4.8 or a new section later in the document) that import statements hav=
e a comment with them either naming the internet draft / RFC they are import=
ing from, or pointing to the reference which names it?
>=20
> Thank you,
> Joel
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Thu Jan 28 12:02:23 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B441ACDB2 for ; Thu, 28 Jan 2016 12:02:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ymov5bPrtvUJ for ; Thu, 28 Jan 2016 12:02: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 C1B4C1ACDE1 for ; Thu, 28 Jan 2016 12:01: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 739E96DE; Thu, 28 Jan 2016 21:01:43 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id jArXenYZlCjp; Thu, 28 Jan 2016 21:01: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; Thu, 28 Jan 2016 21:01:42 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id AE3BA20031; Thu, 28 Jan 2016 21:01: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 veAIsNJCA0EJ; Thu, 28 Jan 2016 21:01:42 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8FB432002C; Thu, 28 Jan 2016 21:01:41 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id A1C7139C59E2; Thu, 28 Jan 2016 21:01:40 +0100 (CET)
Date: Thu, 28 Jan 2016 21:01:39 +0100
From: Juergen Schoenwaelder 
To: "Joel M. Halpern" 
Message-ID: <20160128200139.GA3747@elstar.local>
Mail-Followup-To: "Joel M. Halpern" , NETMOD Working Group 
References: <56AA6492.7090802@joelhalpern.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <56AA6492.7090802@joelhalpern.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: NETMOD Working Group 
Subject: Re: [netmod] minor question - YANG Document Guidelines: Imports
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2016 20:02:23 -0000

On Thu, Jan 28, 2016 at 01:57:22PM -0500, Joel M. Halpern wrote:
> I ran into something while reading a YANG internet-draft recently, and I 
> wonder if a bit of advice in the YANG Document Guidelines (rfc6087bis) 
> would be reasonable.
> 
> Section 4.8 of the guidelines states that any imported modules must also 
> have a reference in the references section.  Which is good.  But there 
> is no obvious way for a human reader to relate the two.
> 
> Would it be sensible to recommend in this document (I don't know if it 
> would be 4.8 or a new section later in the document) that import 
> statements have a comment with them either naming the internet draft / 
> RFC they are importing from, or pointing to the reference which names it?
>

Perhaps RFC 6087bis can give additional guidelines. The common way to
get the references into the enclosing document is to include a
statement before the definitions that says something like:

   This module imports  from the  defined in
   [RFCXYZ] and  form the  defined in [RFCABC].

To help readers that have the module and who do not want to bother
looking up the document, including comments may help. It is kind of
funny that YANG does not allow reference statements on imports...

/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 29 00:47:56 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646FB1A1AB2 for ; Fri, 29 Jan 2016 00:47:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIL7ggNrFB7a for ; Fri, 29 Jan 2016 00:47:53 -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 981671A1AAA for ; Fri, 29 Jan 2016 00:47:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1716; q=dns/txt; s=iport; t=1454057272; x=1455266872; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=j7mtiptd6sssNZzsPUscoLJiI6fOt3+jirR9GWf1CgU=; b=ECj2VDsBH9lx99Nc5MhPPOlBh+5Bm0d3GpsoolIcdIwVTLFR5R3hB6kk M/GpH6bGNNlVe1LEej3uyUYtF9vjyyPqyRDPyaU57euu2rdCh0PyXPwV1 7+1jBzBppwl2uOZQn9DVLeH0J8N5WE3bZLIQLcEhRjkysivqJ/FCGjAgR I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpBABmJqtW/xbLJq1ejVGvJoQDhg8Cg?= =?us-ascii?q?X4BAQEBAQGBC4RCAQEEOEARCxgJFg8JAwIBAgFFBg0IAQEXiAC/XQEBAQEBAQE?= =?us-ascii?q?DAQEBAQEbhg2EN4hsAQSWbo1LiR+FUo49YoNsPIkrAQEB?=
X-IronPort-AV: E=Sophos;i="5.22,363,1449532800"; d="scan'208";a="625388923"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jan 2016 08:47:50 +0000
Received: from [10.61.87.11] (ams3-vpn-dhcp5900.cisco.com [10.61.87.11]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u0T8lopH006161 for ; Fri, 29 Jan 2016 08:47:50 GMT
To: NETMOD Working Group 
References: <56AA6492.7090802@joelhalpern.com> <20160128200139.GA3747@elstar.local>
From: Robert Wilton 
Message-ID: <56AB2736.3020701@cisco.com>
Date: Fri, 29 Jan 2016 08:47:50 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <20160128200139.GA3747@elstar.local>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] minor question - YANG Document Guidelines: Imports
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jan 2016 08:47:54 -0000

On 28/01/2016 20:01, Juergen Schoenwaelder wrote:
> On Thu, Jan 28, 2016 at 01:57:22PM -0500, Joel M. Halpern wrote:
>> I ran into something while reading a YANG internet-draft recently, and I
>> wonder if a bit of advice in the YANG Document Guidelines (rfc6087bis)
>> would be reasonable.
>>
>> Section 4.8 of the guidelines states that any imported modules must also
>> have a reference in the references section.  Which is good.  But there
>> is no obvious way for a human reader to relate the two.
>>
>> Would it be sensible to recommend in this document (I don't know if it
>> would be 4.8 or a new section later in the document) that import
>> statements have a comment with them either naming the internet draft /
>> RFC they are importing from, or pointing to the reference which names it?
>>
> Perhaps RFC 6087bis can give additional guidelines. The common way to
> get the references into the enclosing document is to include a
> statement before the definitions that says something like:
>
>     This module imports  from the  defined in
>     [RFCXYZ] and  form the  defined in [RFCABC].
>
> To help readers that have the module and who do not want to bother
> looking up the document, including comments may help. It is kind of
> funny that YANG does not allow reference statements on imports...
It is too late to add this to Yang 1.1?

That would seem to be the cleanest solution.

I was under the, possibly mistaken, assumption that various YANG tools 
effectively ignore/strip out the comments and hence comments are better 
embedded directly in the model as either reference or description 
statements.

Rob


>
> /js
>


From nobody Fri Jan 29 00:58:56 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5371A1B3C for ; Fri, 29 Jan 2016 00:58:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.352
X-Spam-Level: 
X-Spam-Status: No, score=-5.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdKHJDNSelDL for ; Fri, 29 Jan 2016 00:58:51 -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 966341A1B2A for ; Fri, 29 Jan 2016 00:58:51 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:1d38:3318:92de:1701] (unknown [IPv6:2001:718:1a02:1:1d38:3318:92de:1701]) by mail.nic.cz (Postfix) with ESMTPSA id 200AB1809FF; Fri, 29 Jan 2016 09:58:50 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1454057930; bh=F2YftWF+71edqh/fdphKfs1jVZW8IM6aYhDNC9SsVS4=; h=From:Date:To; b=bUR7guZlcduXssDxRNQRp6SmkEjYCnjZAhwPWQVhCsgcok7Wi+ddOwSPDapJWu/X2 RP+b5cBPi6WSdxhJ8232ul5ruj911I57VtybRAO5x/IdA4Q8mGYwCmBbbO9shpuOGP wVl7MuytJQgLPe413e8O6CMk8UqDfBUD0W4UN5Xk=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: <20160128200139.GA3747@elstar.local>
Date: Fri, 29 Jan 2016 09:58:54 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <56AA6492.7090802@joelhalpern.com> <20160128200139.GA3747@elstar.local>
To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: NETMOD Working Group 
Subject: Re: [netmod] minor question - YANG Document Guidelines: Imports
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jan 2016 08:58:54 -0000

> On 28 Jan 2016, at 21:01, Juergen Schoenwaelder =
 wrote:
>=20
> On Thu, Jan 28, 2016 at 01:57:22PM -0500, Joel M. Halpern wrote:
>> I ran into something while reading a YANG internet-draft recently, =
and I=20
>> wonder if a bit of advice in the YANG Document Guidelines =
(rfc6087bis)=20
>> would be reasonable.
>>=20
>> Section 4.8 of the guidelines states that any imported modules must =
also=20
>> have a reference in the references section.  Which is good.  But =
there=20
>> is no obvious way for a human reader to relate the two.
>>=20
>> Would it be sensible to recommend in this document (I don't know if =
it=20
>> would be 4.8 or a new section later in the document) that import=20
>> statements have a comment with them either naming the internet draft =
/=20
>> RFC they are importing from, or pointing to the reference which names =
it?
>>=20
>=20
> Perhaps RFC 6087bis can give additional guidelines. The common way to
> get the references into the enclosing document is to include a
> statement before the definitions that says something like:
>=20
>   This module imports  from the  defined in
>   [RFCXYZ] and  form the  defined in [RFCABC].

I am usually including a table like here:

https://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-20#section-2.3

This not only binds modules with their documents but also shows prefixes =
that are used in the present document when referring to entities in =
those modules.

Lada

>=20
> To help readers that have the module and who do not want to bother
> looking up the document, including comments may help. It is kind of
> funny that YANG does not allow reference statements on imports...
>=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: E74E8C0C





From nobody Fri Jan 29 02:13:00 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 009BB1B2B42 for ; Fri, 29 Jan 2016 02:12:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.652
X-Spam-Level: 
X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sLH_7P4xfud for ; Fri, 29 Jan 2016 02:12:57 -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 9BE411B29D0 for ; Fri, 29 Jan 2016 02:12:57 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:1d38:3318:92de:1701] (unknown [IPv6:2001:718:1a02:1:1d38:3318:92de:1701]) by mail.nic.cz (Postfix) with ESMTPSA id 015021810F7 for ; Fri, 29 Jan 2016 11:12:54 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1454062375; bh=e58ggMb1mf6aTQi217NlaaR4MWCRAH8iZRT/kuE6aV4=; h=From:Date:To; b=NOJV+CoxyyNpEQYWQB2EJuT5dUSmBYLsNKmABiR0SW105m85OAPasG+x7sBKE4+Va Z0r8RG0xiot+lhkd4dRprGX0apecrpwbykjLB7EBYlGIfy+rVFKWmeKShM5cjbipaU bZTdrx87XwoYYJ4+s8W/z/lDbLMgt3V+AihMx/KM=
From: Ladislav Lhotka 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <2EDAE04F-61EA-45DC-9E62-4C08A705CBCD@nic.cz>
Date: Fri, 29 Jan 2016 11:12:59 +0100
To: NETMOD WG 
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: [netmod] chars that require quoting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jan 2016 10:12:59 -0000

Hi,

I think the following change to sec. 6.1.3 of 6020bis is needed:

OLD
   If a string contains any space or tab characters, a semicolon (";"),
   braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then
   it MUST be enclosed within double or single quotes.

NEW
   If a string contains any space, tab or newline characters, a =
semicolon (";"),
   braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then
   it MUST be enclosed within double or single quotes.

And what about the CR character and single or double quotes? This seems =
to be legal and results in a description argument of length 5 (in pyang =
at least):

description \"hi";

I am not sure it is a good idea to permit this though.

Lada

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





From nobody Fri Jan 29 03:47:27 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 917161A1BA5 for ; Fri, 29 Jan 2016 03:47:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGTvmiatLhkW for ; Fri, 29 Jan 2016 03:47:23 -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 79A0F1A1B9C for ; Fri, 29 Jan 2016 03:47:23 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHQ51803; Fri, 29 Jan 2016 11:47:20 +0000 (GMT)
Received: from LHREML702-CAH.china.huawei.com (10.201.5.99) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 29 Jan 2016 11:47:19 +0000
Received: from SZXEML422-HUB.china.huawei.com (10.82.67.152) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 29 Jan 2016 11:47:19 +0000
Received: from szxeml561-mbs.china.huawei.com ([169.254.6.28]) by szxeml422-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.03.0235.001; Fri, 29 Jan 2016 19:46:44 +0800
From: Rohit pobbathi 
To: "netmod@ietf.org" 
Thread-Topic: [Netmod] Query on YANG RPC statement
Thread-Index: AdFairkrIodAeXkgQKOGXH3LYOgc5A==
Importance: high
X-Priority: 1
Date: Fri, 29 Jan 2016 11:46:44 +0000
Message-ID: <2730B0D5F3302249A30EBF0DAE96D4CB44BFF2FA@SZXEML561-MBS.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.210.230]
Content-Type: multipart/alternative; boundary="_000_2730B0D5F3302249A30EBF0DAE96D4CB44BFF2FASZXEML561MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.56AB5148.00A5, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.6.28, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 191cad54795028dc12251bf5984ce530
Archived-At: 
Subject: [netmod] [Netmod] Query on YANG RPC statement
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jan 2016 11:47:26 -0000

--_000_2730B0D5F3302249A30EBF0DAE96D4CB44BFF2FASZXEML561MBSchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

I have a query regarding RFC 6020 (YANG 1.0) section 7.13 rpc statement.

The "rpc" statement may contain optional "input" and/or "output" substateme=
nts.

Whether a PARAMETER can appear in both  "input" and "output" ?
i.e. same PARAMETER exist in input & output of the rpc.

Is there any restriction about this point ?

Rgds,
Rohit Pobbathi

--_000_2730B0D5F3302249A30EBF0DAE96D4CB44BFF2FASZXEML561MBSchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


 


I have a query regarding RFC 6020 (YANG 1.0) section=
 7.13 rpc statement.


 


The “rpc” statement may contain optional=
 “input” and/or “output” substatements.<=
/p>

 


Whether a PARAMETER can appear in both  “=
input” and “output” ?


i.e. same PARAMETER exist in input & output of t=
he rpc.


 


Is there any restriction about this point ?


 


Rgds,


Rohit Pobbathi






--_000_2730B0D5F3302249A30EBF0DAE96D4CB44BFF2FASZXEML561MBSchi_--


From nobody Fri Jan 29 03:50:42 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8024A1A1BA9 for ; Fri, 29 Jan 2016 03:50:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.003
X-Spam-Level: 
X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lC5xiNcbZpY for ; Fri, 29 Jan 2016 03:50: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 30FCE1A1B9C for ; Fri, 29 Jan 2016 03:50:38 -0800 (PST)
Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id 0C8A11AE00B6; Fri, 29 Jan 2016 12:50:36 +0100 (CET)
Date: Fri, 29 Jan 2016 12:50:40 +0100 (CET)
Message-Id: <20160129.125040.1699204582082963464.mbj@tail-f.com>
To: rohit.pobbathi@huawei.com
From: Martin Bjorklund 
In-Reply-To: <2730B0D5F3302249A30EBF0DAE96D4CB44BFF2FA@SZXEML561-MBS.china.huawei.com>
References: <2730B0D5F3302249A30EBF0DAE96D4CB44BFF2FA@SZXEML561-MBS.china.huawei.com>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] [Netmod] Query on YANG RPC statement
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jan 2016 11:50:39 -0000

Rohit pobbathi  wrote:
> Hi,
> 
> I have a query regarding RFC 6020 (YANG 1.0) section 7.13 rpc statement.
> 
> The "rpc" statement may contain optional "input" and/or "output" substatements.
> 
> Whether a PARAMETER can appear in both  "input" and "output" ?
> i.e. same PARAMETER exist in input & output of the rpc.

Yes, this is possible.


/martin



> 
> Is there any restriction about this point ?
> 
> Rgds,
> Rohit Pobbathi


From nobody Fri Jan 29 03:55:07 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B11E91A1BBC for ; Fri, 29 Jan 2016 03:55:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYeSV1txLpuN for ; Fri, 29 Jan 2016 03:55:02 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9A51A1BB8 for ; Fri, 29 Jan 2016 03:55:02 -0800 (PST)
Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id 70C2F1AE00B6; Fri, 29 Jan 2016 12:55:01 +0100 (CET)
Date: Fri, 29 Jan 2016 12:55:04 +0100 (CET)
Message-Id: <20160129.125504.2260438949482559492.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: <2EDAE04F-61EA-45DC-9E62-4C08A705CBCD@nic.cz>
References: <2EDAE04F-61EA-45DC-9E62-4C08A705CBCD@nic.cz>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] chars that require quoting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jan 2016 11:55:05 -0000

Ladislav Lhotka  wrote:
> Hi,
> 
> I think the following change to sec. 6.1.3 of 6020bis is needed:
> 
> OLD
>    If a string contains any space or tab characters, a semicolon (";"),
>    braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then
>    it MUST be enclosed within double or single quotes.
> 
> NEW
>    If a string contains any space, tab or newline characters, a semicolon
>    (";"),
>    braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then
>    it MUST be enclosed within double or single quotes.

I agree.

> And what about the CR character and single or double quotes? This
> seems to be legal and results in a description argument of length 5
> (in pyang at least):
> 
> description \"hi";

I don't understand what you mean.


/martin


From nobody Fri Jan 29 04:14:28 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 668761A212A for ; Fri, 29 Jan 2016 04:14:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.352
X-Spam-Level: 
X-Spam-Status: No, score=-5.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHE18m6RNdja for ; Fri, 29 Jan 2016 04:14:25 -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 C0BA71A1F20 for ; Fri, 29 Jan 2016 04:14:24 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:1d38:3318:92de:1701] (unknown [IPv6:2001:718:1a02:1:1d38:3318:92de:1701]) by mail.nic.cz (Postfix) with ESMTPSA id 55065181B6B; Fri, 29 Jan 2016 13:14:23 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1454069663; bh=QTE9AjBZMs06MYGx2C808etefo5XTgMsYwzkES3vWUc=; h=From:Date:To; b=NDK6XDjU9tcT5+Y6mLO3aP2jpaHKfAJgqqBx10zu1hMBttDJRMstxhs1x93+6Xjaj gVGZuxLGAIv5JlEmgyv2TKXUq1ey6l155qP95wludxkYigLauZxkRgw7qr99RxOTWR Sp5yDBBPeT/idANH+Sg99mck5tdnE9zPtXvJ+eEc=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: <20160129.125504.2260438949482559492.mbj@tail-f.com>
Date: Fri, 29 Jan 2016 13:14:27 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <4AAFF7B9-3776-4C26-BDF2-A32CF9105C45@nic.cz>
References: <2EDAE04F-61EA-45DC-9E62-4C08A705CBCD@nic.cz> <20160129.125504.2260438949482559492.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] chars that require quoting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jan 2016 12:14:26 -0000

> On 29 Jan 2016, at 12:55, Martin Bjorklund  wrote:
>=20
> Ladislav Lhotka  wrote:
>> Hi,
>>=20
>> I think the following change to sec. 6.1.3 of 6020bis is needed:
>>=20
>> OLD
>>   If a string contains any space or tab characters, a semicolon =
(";"),
>>   braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), =
then
>>   it MUST be enclosed within double or single quotes.
>>=20
>> NEW
>>   If a string contains any space, tab or newline characters, a =
semicolon
>>   (";"),
>>   braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), =
then
>>   it MUST be enclosed within double or single quotes.
>=20
> I agree.
>=20
>> And what about the CR character and single or double quotes? This
>> seems to be legal and results in a description argument of length 5
>> (in pyang at least):
>>=20
>> description \"hi";
>=20
> I don't understand what you mean.

If an argument starts as unquoted, then double quotes appearing inside =
it (or at the end) are accepted as literals. Backslash can appear =
anywhere in an unquoted argument, but it is less of a problem. So the =
above statement rewritten with a double-quoted argument is this:

description "\\\"hi\"";

I think that single and double quotes (and perhaps also backslashes) =
shouldn't be allowed in an unquoted argument.

Lada

>=20
>=20
> /martin

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





From nobody Fri Jan 29 06:48:39 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3721A6FA6 for ; Fri, 29 Jan 2016 06:48:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0rnsxkxtDES for ; Fri, 29 Jan 2016 06:48: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 052481A6FA3 for ; Fri, 29 Jan 2016 06:48:35 -0800 (PST)
Received: from localhost (unknown [173.38.220.59]) by mail.tail-f.com (Postfix) with ESMTPSA id C23951AE00B6; Fri, 29 Jan 2016 15:48:33 +0100 (CET)
Date: Fri, 29 Jan 2016 15:48:36 +0100 (CET)
Message-Id: <20160129.154836.1250045488182328568.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: <4AAFF7B9-3776-4C26-BDF2-A32CF9105C45@nic.cz>
References: <2EDAE04F-61EA-45DC-9E62-4C08A705CBCD@nic.cz> <20160129.125504.2260438949482559492.mbj@tail-f.com> <4AAFF7B9-3776-4C26-BDF2-A32CF9105C45@nic.cz>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] chars that require quoting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jan 2016 14:48:37 -0000

Ladislav Lhotka  wrote:
> 
> > On 29 Jan 2016, at 12:55, Martin Bjorklund  wrote:
> > 
> > Ladislav Lhotka  wrote:
> >> Hi,
> >> 
> >> I think the following change to sec. 6.1.3 of 6020bis is needed:
> >> 
> >> OLD
> >>   If a string contains any space or tab characters, a semicolon (";"),
> >>   braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then
> >>   it MUST be enclosed within double or single quotes.
> >> 
> >> NEW
> >>   If a string contains any space, tab or newline characters, a semicolon
> >>   (";"),
> >>   braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then
> >>   it MUST be enclosed within double or single quotes.
> > 
> > I agree.
> > 
> >> And what about the CR character and single or double quotes? This
> >> seems to be legal and results in a description argument of length 5
> >> (in pyang at least):
> >> 
> >> description \"hi";
> > 
> > I don't understand what you mean.
> 
> If an argument starts as unquoted, then double quotes appearing inside
> it (or at the end) are accepted as literals. Backslash can appear
> anywhere in an unquoted argument, but it is less of a problem. So the
> above statement rewritten with a double-quoted argument is this:
> 
> description "\\\"hi\"";
> 
> I think that single and double quotes (and perhaps also backslashes)
> shouldn't be allowed in an unquoted argument.

Maybe, but this is a pretty big change, and the current rules "work",
and we're just about to publish a version can be sent to the IESG, so
I'd say that it is too late for this change.


/martin


From nobody Fri Jan 29 06:58:29 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C20B1A6FD4 for ; Fri, 29 Jan 2016 06:58:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.248
X-Spam-Level: 
X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_74=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhlyPtZsgGGp for ; Fri, 29 Jan 2016 06:58:26 -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 DB1451A6FCF for ; Fri, 29 Jan 2016 06:58:25 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:1d38:3318:92de:1701] (unknown [IPv6:2001:718:1a02:1:1d38:3318:92de:1701]) by mail.nic.cz (Postfix) with ESMTPSA id EE717181713; Fri, 29 Jan 2016 15:58:22 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1454079503; bh=JaiLfFscO1u/lR6mwb24zc1bzjdyp1iizw4MfVW9wsw=; h=From:Date:To; b=TC+UpObMewnaxJOz1LnhqBlhlZtqImHK2hv0H3UeUHWuodOV6LmYzOTddOGmbC64j 4j9WbRNwYUOuerylO53vX8II00drMJCl21vtGTYJipEHc8LW9yF74BVzx6BGkV5aOf l+lUkvQzNJ4fIIF5rN+9x6ZiPNCeTFevhMDVXq7g=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: <20160129.154836.1250045488182328568.mbj@tail-f.com>
Date: Fri, 29 Jan 2016 15:58:26 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <2EDAE04F-61EA-45DC-9E62-4C08A705CBCD@nic.cz> <20160129.125504.2260438949482559492.mbj@tail-f.com> <4AAFF7B9-3776-4C26-BDF2-A32CF9105C45@nic.cz> <20160129.154836.1250045488182328568.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] chars that require quoting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jan 2016 14:58:27 -0000

> On 29 Jan 2016, at 15:48, Martin Bjorklund  wrote:
>=20
> Ladislav Lhotka  wrote:
>>=20
>>> On 29 Jan 2016, at 12:55, Martin Bjorklund  wrote:
>>>=20
>>> Ladislav Lhotka  wrote:
>>>> Hi,
>>>>=20
>>>> I think the following change to sec. 6.1.3 of 6020bis is needed:
>>>>=20
>>>> OLD
>>>>  If a string contains any space or tab characters, a semicolon =
(";"),
>>>>  braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), =
then
>>>>  it MUST be enclosed within double or single quotes.
>>>>=20
>>>> NEW
>>>>  If a string contains any space, tab or newline characters, a =
semicolon
>>>>  (";"),
>>>>  braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), =
then
>>>>  it MUST be enclosed within double or single quotes.
>>>=20
>>> I agree.
>>>=20
>>>> And what about the CR character and single or double quotes? This
>>>> seems to be legal and results in a description argument of length 5
>>>> (in pyang at least):
>>>>=20
>>>> description \"hi";
>>>=20
>>> I don't understand what you mean.
>>=20
>> If an argument starts as unquoted, then double quotes appearing =
inside
>> it (or at the end) are accepted as literals. Backslash can appear
>> anywhere in an unquoted argument, but it is less of a problem. So the
>> above statement rewritten with a double-quoted argument is this:
>>=20
>> description "\\\"hi\"";
>>=20
>> I think that single and double quotes (and perhaps also backslashes)
>> shouldn't be allowed in an unquoted argument.
>=20
> Maybe, but this is a pretty big change, and the current rules "work",
> and we're just about to publish a version can be sent to the IESG, so
> I'd say that it is too late for this change.

I know, but it opens space for nasty tricks like this:

$ cat quoting.yang=20
module quoting {
  namespace "http://example.com/quoting";
  prefix qq;
  leaf foo {
    type string;
    default =E2=80=8B"hi";
  }
}
$ pyang -f yang quoting.yang
module quoting {
  namespace "http://example.com/quoting";
  prefix qq;

  leaf foo {
    type string;
    default "=E2=80=8B\"hi\"";
  }
}

Weird, isn't it? It is because "ZERO WIDTH SPACE" (U+200B) immediately =
precedes the first double quote in the argument of "default". =
Consequently, the argument is parsed as unquoted, and both double quotes =
become part of it.

Lada

>=20
>=20
> /martin

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





From nobody Sat Jan 30 13:41:08 2016
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C4A1ACD4C for ; Sat, 30 Jan 2016 13:41:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.422
X-Spam-Level: *
X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dy_0JGe8fXZ4 for ; Sat, 30 Jan 2016 13:41:07 -0800 (PST)
Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::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 AE4BB1ACD4A for ; Sat, 30 Jan 2016 13:41:06 -0800 (PST)
Received: by mail-lb0-x22f.google.com with SMTP id dx2so57313881lbd.3 for ; Sat, 30 Jan 2016 13:41:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=DhvsJDBkXpBGrQdkZKlymv0X9Bnl2PyfAzPdhb91UPQ=; b=KuULOoCmZEM2qdeuWkRJ1N7wTcUdh5Nmk3BzRWeqscqwnzlJ/upG1C3VUB6VS0fPmk ytayOHojaJY+W2MpJM8wr0JpG/rUeCG7XN1Ty9gcm5bRvgg/aFZisoFHTChzu3VnDxqs +LOqCAcNAU8rN3TQ6JwYY+coGdnQYbLx4MBWKQmtxtcOV8d9+igkmxXxQpN8l7fvZaZZ w6+QfUd8t/6q1FR98/R/WqjKyru+879Rlj4AY39XsiN058fAGB55v+fV6d36YjT800h5 HIgbgrEywzye1aEmq3B14WNobeQJ2FuSbk9uZkZ5ydxyw0H8SZQgjS6KxrkPBaLF6lIh P33g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=DhvsJDBkXpBGrQdkZKlymv0X9Bnl2PyfAzPdhb91UPQ=; b=guykkKGcjd8Ev/M3FRoh2Hr0UIO7VCp+1Ir8pY4efEcDR+EouAMrlEgp8P72GcW5gB mf22dXObNuhfyGJPHhUUnvW9hZOsZEzvAv+zDIHp9zq+VlhNkNBmKzw9dBV1BKlmxgHq F0JGvr53rbAlOkBDrB7DynFJC2wGwYLba2HX6N2xLB3FskbnHBAljOnLgno0273wtFyY Z61vWQ/jeLkrwhHcvW+sh3/dw/dpCTtHmcXO23bIvhmjvzJaEbXpay36RcEL1sxwulWc 2Yxq7ByfcPnDf+zCO13VqGG0g/u4RVAaueEpmZNTSENHA2ICxWeU6ytj2EFv9Rh4XFQh 2JXQ==
X-Gm-Message-State: AG10YOQk2UjJBgtriu3+GTALqW481v27rI07hhlBWUzB2b3/gXU7xB0+zLb8PPCvQ3mpDjlb8+bBRqdf1fcFYQ==
MIME-Version: 1.0
X-Received: by 10.112.147.1 with SMTP id tg1mr4612173lbb.119.1454190064779; Sat, 30 Jan 2016 13:41:04 -0800 (PST)
Received: by 10.112.200.167 with HTTP; Sat, 30 Jan 2016 13:41:04 -0800 (PST)
Date: Sat, 30 Jan 2016 13:41:04 -0800
Message-ID: 
From: Andy Bierman 
To: "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary=047d7b3a7f5c3f60a6052a9402d7
Archived-At: 
Subject: [netmod] 2 YANG 1.1 questions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 Jan 2016 21:41:08 -0000

--047d7b3a7f5c3f60a6052a9402d7
Content-Type: text/plain; charset=UTF-8

Hi,


1) leafref with a default-stmt

  list int {
    key "name type";
    leaf name { type string; }
    leaf type { type string; }
    leaf enabled { type boolean; }
  }

  typedef lref1 {
    type leafref { path "/int/name"; }
    default "t0";
  }

This has the save effect as top-level mandatory nodes.
The require-instance is 'true' so the YANG validation will fail
at boot-time unless a list 'int' entry name is 't0'.

I plan to add a YANG usage guide not to give configuration
leafref nodes a default value. Any objections or another plan?


2) instance-identifier encoding for key type 'empty'.

  list int2 {
    key "test test2";
    leaf test { type empty; }
    leaf test2 { type empty; }
    leaf type { type string; }
  }

Now that the empty type is allowed for a key leaf,
the  and any instance-identifier type needs to
have encoding rules defined. (e.g. an instance of /int2/type)


Andy

--047d7b3a7f5c3f60a6052a9402d7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,


1) leafref with a de=
fault-stmt

=C2=A0 list int {
=C2=A0=
 =C2=A0 key "name type";
=C2=A0 =C2=A0 leaf name { type=
 string; }
=C2=A0 =C2=A0 leaf type { type string; }
=C2=
=A0 =C2=A0 leaf enabled { type boolean; }
=C2=A0 }

=

=C2=A0 typedef lref1 {
=C2=A0 =C2=A0 type leafref { pa=
th "/int/name"; }
=C2=A0 =C2=A0 default "t0";=

=C2=A0 }

This has the save effect=
 as top-level mandatory nodes.
The require-instance is 'true&=
#39; so the YANG validation will fail
at boot-time unless a list =
'int' entry name is 't0'.

I plan t=
o add a YANG usage guide not to give configuration
leafref no=
des a default value. Any objections or another plan?


2) instance-identifier encoding for key type 'empty&#=
39;.

=C2=A0 list int2 {
=C2=A0 =C2=
=A0 key "test test2";
=C2=A0 =C2=A0 leaf test { type em=
pty; }
=C2=A0 =C2=A0 leaf test2 { type empty; }
=C2=A0 =
=C2=A0 leaf type { type string; }
=C2=A0 }

Now that the empty type is allowed for a key leaf,
the &=
lt;error-path> and any instance-identifier type needs to
have =
encoding rules defined. (e.g. an instance of /int2/type)


Andy
=C2=A0



--047d7b3a7f5c3f60a6052a9402d7--