From nobody Mon Aug 1 01:55:54 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D23112D5A4 for ; Mon, 1 Aug 2016 01:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZd4Ah8pRLwP for ; Mon, 1 Aug 2016 01:55:42 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 3EE9512D590 for ; Mon, 1 Aug 2016 01:55:41 -0700 (PDT) X-AuditID: c1b4fb30-ad3ff700000009f9-e1-579f0e8a4ccb Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id 0F.BF.02553.A8E0F975; Mon, 1 Aug 2016 10:55:39 +0200 (CEST) Received: from [159.107.197.181] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.301.0; Mon, 1 Aug 2016 10:55:38 +0200 To: Andy Bierman , Mahesh Jethanandani References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com> <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com> <57892746.5020903@seguesoft.com> <57893742.6040903@seguesoft.com> <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com> <001c01d1e299$e057a910$a106fb30$@seguesoft.com> <6e416198-13bd-81e3-545e-35e8bfc61536@ericsson.com> From: Balazs Lengyel Message-ID: Date: Mon, 1 Aug 2016 10:55:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM2K7lm433/xwg1PTVC0eHJnFbnH6zTo2 i6mbbrM6MHvsnHWX3WPJkp9MHi39F1kCmKO4bFJSczLLUov07RK4MjafecpScPcCc8WCWTvZ GxiXdDN2MXJySAiYSBzevArI5uIQEljPKNE6czEbhLOGUeLv1fMsIFXCAuESb5+uYQOxRQTC JLbNOQBVdJhdYse6m2CjmAXkJBb/6GECsdkEjCSm9kM08wrYS+zoeMEOYrMIqEicOXANyObg EBWIkVjflwBRIihxcuYTsHJOgUCJzRe2Qo3UkGidM5cdwpaXaN46mxnEFgKKP7zwl3UCo8As JO2zkLTMQtKygJF5FaNocWpxUm66kZFealFmcnFxfp5eXmrJJkZgwB7c8ttgB+PL546HGAU4 GJV4eBNY5oULsSaWFVfmHmKU4GBWEuGt5pkfLsSbklhZlVqUH19UmpNafIhRmoNFSZzX/6Vi uJBAemJJanZqakFqEUyWiYNTqoFxs2GbbHFG/3Rlm5TtHLc3TKxytzqtJ+CpmbXmlyCH4ivJ ORFhG9j17dv+XFshlTVN/MGtMnGZcunfTmFbk+ct2aaWcCkvWmjNIoP4Q/uKDnTP/vlmOdu3 m08LGftLZHhdH75RMBd1OxWV9yneM57n5G/pprovR0zrQy10OhkjNNcoX8o8y6zEUpyRaKjF XFScCAAvWzgyVAIAAA== Archived-At: Cc: Netconf Subject: Re: [Netconf] What should a server response be? - depending on NP-containers X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 08:55:52 -0000

Hello,

As I see it:

- The main problem is we don't agree whether or when NP containers exist. Some people think they should exist (or not) just as any other data node. (me, Andy, RFC6241) while others believe the existence of the NP containers  is not even a valid question (tailf). As we have such basic differences, I propose to focus just on the specific protocol cases that are problematic.

- IMHO this problem means that the following 3 cases are not properly defined and we need to clarify them. Saying the client should just not use major parts of the protocol for NP-containers is wrong.

1) what happens if default-operation=none meets a non-existing NP container
2) what happens if you create an NP-container and that already exists e.g. you issue create twice
3) what happens if you delete an NP-container that does not exists e.g. issue the delete twice

IMHO saying that from the 6 operation values 3 are undefined for NP-container is not acceptable.
As we have protocol operations defined in RC6020 we need to define them properly.
regards Balazs

On 2016-08-01 02:23, Andy Bierman wrote:


On Sun, Jul 31, 2016 at 10:45 AM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

On Jul 30, 2016, at 5:31 PM, Andy Bierman <andy@yumaworks.com> wrote:



On Sat, Jul 30, 2016 at 5:21 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
Andy,

The thread started because the RFC does not say anything about a create of a NP container. It only talked about delete. Can we make the (re-)create of the NP container unconditional to whether a delete was performed on it. So a tweak to your proposal would be:


The only reason that example did not work is because the server deleted the NP containers
after the client created them.  If the server does not delete the containers then
the 2nd RPC will not fail.

I think this argument of whether server should or should not create/delete NP containers is distracting from the main point of when NP containers should exist. In my mind, the NP container existence depends on whether child nodes exist or not. In the end, if child nodes exist, NP containers should exist (created), if they do not exist, the NP container should be removed.

Can we agree on that? 


No.

"should be removed" is an implementation choice.
It started as MAY be removed.  It needs to stay that way.

As I have pointed out 100 times,  the protocol has merge and replace
for the situation where the client is not exactly aware of how ceration and
deletion will be handled on the server.

There is no reason to force implementations to change.
If you magically delete containers, then magically recreate them.
If you don't then the nodes will be as the client expects, so no problem.


Andy
 

P.s The errata will be much easier to craft if we can agree on this.


This can also be completely avoided by using the default (merge).
Since the client has to explicitly pick default-operation=none,
it better know what it is doing. 
This is the same issue as a default leaf
and the create operation.  Nothing special about NP containers.

The <edit-config> for "create" will fail if the leaf already exists
and the "delete" will fail if the value is not there (just a default).
The work-around?  Use merge and remove, not create and delete.
IMO the same logic applies here.


Andy




OLD:

   If a container does not have a "presence" statement and the last
   child node is deleted, the NETCONF server MAY delete the container.

NEW:

   If a container does not have a "presence" statement and the container instance
   does not have any child node instances, the NETCONF server MAY delete the
   container. It MUST create the container instance if a client <edit-config> request 
   attempts to create a child node instance within this container.


On Jul 30, 2016, at 11:52 AM, Andy Bierman <andy@yumaworks.com> wrote:

Hi,

I strongly object to changing a vague MAY about deleting an NP container
after the last child has been deleted into several MUST requirements.

I propose this text instead:

OLD:


   If a container does not have a "presence" statement and the last
   child node is deleted, the NETCONF server MAY delete the container.


NEW:


   If a container does not have a "presence" statement and the container instance
   does not have any child node instances, the NETCONF server MAY delete the
   container. If the server does delete a container instance in this case, it MUST
   re-create the container instance if a client <edit-config> request attempts to create
   a child node instance within this container.




Andy


On Fri, Jul 22, 2016 at 3:13 AM, Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:

Hello,

We seem to have fundamental differences whether NP-containers exist/don't exist or if this question is even valid.  I hope we can agree that as NP-containers are meaningless themselves they MUST NOT influence Netconf operations or model validation. (Which is a slight violation of Netconf-6241, which we should accept.)

So I propose the following errata to rfc6020bis.

As for non-presence containers the presence of the container node with no child nodes is
semantically equivalent to the absence of the container node, configuration operations or
model validation should never fail due to the existence or non-existence of a non-presence containers. Specifically:

- an <edit-config>  create operation for a non-presence container MUST succeed even if the container already exists.
- an <edit-config>  delete operation for a non-presence container MUST succeed even if the container does not exist. 
- an <edit-config>  operation with default-operation=none MUST succeed even if one or more  non-presence containers do not exist.

Separately
- a must statement defined as direct substatement of a non-presence container SHALL be evaluated as part of model validation if and only if one or more child data nodes exist in the instance data or if there is a leaf or leaf-list child with a default value. As non-presence containers are only used for organizing the hierarchy they SHOULD NOT have any must substatements.

IMO the above rules remove ambiguity and follow the current philosophy of  RFC6020bis.
If we have a basic agreement I can formulate the text correctly.

I don't know whether similar updates are needed for RestConf.
regards Balazs

PS. I still believe introducing NP containers was a mistake, however they are here to stay. 

On 2016-07-21 09:17, Jan Lindblad wrote:
Xiang,

Are you saying that since a NP-container is merely a structure node, not config in any way, so creating/deleting it explicitly (and repeatedly) is equivalent to a “no-op” that will always succeed because doing so has no effect on the server’s config in any way? 

That's correct. "Creating" an object with zero bits of information is a no-op.

If the sever has the following example config:
<mycontainer>
     <child  ... bla..bla…configs>
</mycontainer>
 
 
If a client issues an edit-config with:
< mycontainer operation="delete">
 
The server returns “ok”,
 
If then again  the client attempts:
 
< mycontainer operation="delete">
 
The server should still return  “ok”?

Yes, that's correct in my opinion. It's a consequence of the NP container nature as defined in the current RFC6020/YANG 1.0 and bis.
 
If so I think this is confusing. I think it would make more sense in the latter case if the server returns “"data-missing” error.

This is logical if you think of NP containers as path prefixes, and not as objects with information content. If you accept that an NP container has zero bits of information, how would the server even know whether the container exists or not? Not by looking in a database, for sure.

P containers have a single bit of information, so they can be created, and the creation event/existence remembered by the server. Not so for NP-containers.

I understand we may advise a client not do so, but since  RFC6020bis does not forbid this, and it is also a perfectly valid <edit-config>, so I am sure people will try it.

Yes. And it works today and is harmless.

It's unfortunate that the YANG 1.0 and 1.1 specs aren't crystal clear on the subject, but I believe the interpretation I and others have of NP container behavior in RFC 6020 is consistent, implementable and highly useful.

/jan


-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com

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


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

Mahesh Jethanandani








-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
From nobody Mon Aug 1 02:02:51 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9AE12D550 for ; Mon, 1 Aug 2016 02:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUureYaEuNwk for ; Mon, 1 Aug 2016 02:02:48 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 0DBDD12D549 for ; Mon, 1 Aug 2016 02:02:47 -0700 (PDT) X-AuditID: c1b4fb2d-bbfff70000000190-33-579f10362fa2 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by (Symantec Mail Security) with SMTP id 23.C8.00400.6301F975; Mon, 1 Aug 2016 11:02:46 +0200 (CEST) Received: from [159.107.197.181] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.3.301.0; Mon, 1 Aug 2016 11:02:45 +0200 To: Mahesh Jethanandani , Andy Bierman References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com> <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com> <57892746.5020903@seguesoft.com> <57893742.6040903@seguesoft.com> <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com> <001c01d1e299$e057a910$a106fb30$@seguesoft.com> <6e416198-13bd-81e3-545e-35e8bfc61536@ericsson.com> From: Balazs Lengyel Message-ID: <1eb7f574-2f1e-a0c1-1ca5-0d3333bdbeba@ericsson.com> Date: Mon, 1 Aug 2016 11:02:45 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM2K7oq6ZwPxwg/MnJCweHJnFbnH6zTo2 i6mbbrM6MHvsnHWX3WPJkp9MHi39F1kCmKO4bFJSczLLUov07RK4Mg48uclY8Iy/ouP3L9YG xpPcXYycHBICJhKvN+9nBbGFBNYzSiz9x97FyAVkr2GU2PyvkQkkISwQLvH26Ro2EFtEIEzi /+f/UEWH2SXOPNzCApJgFpCTWPyjB6yBTcBIYmr/ebA4r4C9xKVDi8E2sAioSDTdXczYxcjB ISoQI7G+LwGiRFDi5MwnYOWcArYSU6cvZoIYqSHROmcuO4QtL9G8dTYzxKEaEg8v/GWdwCgw C0n7LCQts5C0LGBkXsUoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokRGKoHt/zW3cG4+rXjIUYB DkYlHt4ElnnhQqyJZcWVuYcYJTiYlUR4q3nmhwvxpiRWVqUW5ccXleakFh9ilOZgURLn9X+p GC4kkJ5YkpqdmlqQWgSTZeLglGpgTA0t/ByZP/u9+QJFnQ87qrcc/Mw/2STecYVAW+LDgnsn cyOe7jl595OGi/oZuUuGTXfPLdY4cXB3pJOQv1a3C/dxvVLRk2yH8lJXXDHca9A+e8p7fj29 rWJhuZEafPtlv0rYdd6I2uJeXl4W80Jg62w/JiO9OB2uJs9JiwtrNd9+K5KJ+SKmxFKckWio xVxUnAgAfWj1/lECAAA= Archived-At: Cc: Netconf Subject: Re: [Netconf] What should a server response be? - depending on NP-containers X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 09:02:49 -0000

Hello,

IMHO I feel it will be difficult to agree on the existence of NP-Containers. Can we agree at least that protocol operations shall not fail because of the existence/non-existence of NP-Containers?

The RFC contains:

  • "non-presence container: A container that has no meaning of its  own"
  • "the presence of the container node with no child nodes is semantically equivalent to the absence of the container node.  YANG calls this style a non-presence container."

Semantically equivalent to me means the result of an operation MUST not depend on the NP-container.

Balazs


On 2016-07-31 19:45, Mahesh Jethanandani wrote:

I think this argument of whether server should or should not create/delete NP containers is distracting from the main point of when NP containers should exist. In my mind, the NP container existence depends on whether child nodes exist or not. In the end, if child nodes exist, NP containers should exist (created), if they do not exist, the NP container should be removed.

Can we agree on that? 


-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
From nobody Mon Aug 1 02:50:45 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25EE12D5CF for ; Mon, 1 Aug 2016 02:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGOP9bE-_nJ2 for ; Mon, 1 Aug 2016 02:50:41 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40130.outbound.protection.outlook.com [40.107.4.130]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F7B312D5BF for ; Mon, 1 Aug 2016 02:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jWxkSDcBBa5leI8KKd2qnZvFXj6PJVZpGAMtLI84jHk=; b=HWYFmI46L2WNudCTby+hhXrxOiFdK+pw41pe71rUrWV+HMeU3tvWX5zorb3ncf1RxnI+z0vb6xw+bPd91Mb83FWDrRdj2kBuIgfmAz7dodGc1OTLNF1J/CDtQM2DKeh+GlCy+kVwPir3mt/7ianifD/L7ik4aqw8NW2cM6O3XHY= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (31.50.86.164) by DB5PR07MB1622.eurprd07.prod.outlook.com (10.166.12.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Mon, 1 Aug 2016 09:50:37 +0000 Message-ID: <016801d1ebd9$cb9c3e20$4001a8c0@gateway.2wire.net> From: t.petch To: Andy Bierman , Mahesh Jethanandani References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com> <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com> <57892746.5020903@seguesoft.com> <57893742.6040903@seguesoft.com> <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com> <001c01d1e299$e057a910$a106fb30$@seguesoft.com> <6e416198-13bd-81e3-545e-35e8bfc61536@ericsson.com> Date: Mon, 1 Aug 2016 10:47:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit 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: [31.50.86.164] X-ClientProxiedBy: DB3PR05CA0070.eurprd05.prod.outlook.com (10.163.44.38) To DB5PR07MB1622.eurprd07.prod.outlook.com (10.166.12.149) X-MS-Office365-Filtering-Correlation-Id: 17d5a085-199f-468b-e0a8-08d3b9f14aa0 X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 2:6SuDOeegpj8TMR1bsKSiemLcbB4OevatQdTXEudjKePkX4LclluVwz1mDB/H17K40Lqqt+63zPIqLRIVZjgYpbSbOxbb8kAjwrK+QXfenkmLdRlfR2TWXe+vt0L0HnxTgDA0vL2gBFDKKF9mbz96Fy1TuMi5WorzDwgvawa7Iblu22JRW3lBEUxzhmwv0aw+; 3:vJwbMkwIy8EllN28v3jPpyzPVkDBBy4Ia63VcDPea5D9sFkLgdQV2fUi70SBiI2rIOxBfKTuD2wBW75o7dWbEKrW2NlskJiRFuD+1fBTgoLB9J5wvsMiXXqcRNAU8Te4 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR07MB1622; X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 25:oNooyqas6JjNlaQga17RD+c6ZzX6+HF1NEaTcv9bMhiG+OKc1ZucuF/62PYUR3dQqz4eHJrgH0wlC5vanOdHvP+l25yeyKIOliz6BlsKfoaEDTzD4afeVdWE6njX4FkFnk92Fel5EU6Nn9pzaF5sz0Nc+KvMbTFxPJqCueAufm1OD3UEP9a5brWQzTc6+nRy76tVCh2lL9kD/naj6d/fxa7INyCnOoGXvxamVpZcW396PgnL5C/jEOo0eClyW0cMlOqiLOScUtuty6HLrKtTpcksVc7cJMic+1kQR793oLyBf6/kC6CS9sQzA2FjhtgpD2uSci94X+vI65HfKhUPd/BYgxwXx2mC+w2NVA4S/0EZfvfbGTGw8XDpKiSPNqEai2Vw1EgGcHkfLzfMXAVB+8dLt7HaUNr7cS2OB4EsjQxzsWnPrkykSscGJMKgAHpSeMlnv4Gj81EgnoezE5Bw7kvebSIPE9paS//1ZFgQUtNf3JwEVaKsjKXcZKsWusMoK0NC9gq0iFBT9pa+43BuguLl1XQAeh/QXdihVCX1dRNVBcs3paHb+I7FU/EXLKP/Y6o2L6JcpZZ2izOwqjH/Dfb6/JAoUoAqnI+dXgu5rQDsHhq6PN2hC2AwIXWBg5wTsubTTDXUcB3EWXtbr3+J33SZyhauyYbJ7OhkjqwDtZEhwmGThvHdR/mkz+cmSfkMP9dU7GPuG/zwmWEnvDJbwHS717gfD8qGkv/rzmbFSxWWt/UP1oIR5psAs3yUwDVtvo3aiavFFl3KPxdbpDFzM/xdlmrorbbyoPz+4tcgp/+U07YzUmMkk10vGiWc7Z2r X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 31:eHiUSs8UYznYKAx3TIHj2x9qf9Mrmn5zLYNaopBxZ/t+37XpCaWmj/NDDKdNXeNENSW4mS0IX7cTheNLHYZdWPR4zjlTLEos50M24WnmS3lPK6yxdyQH75KYs2GHokvU/tFfNvguT05w2Lz5HuH8bhY5X0zvE3+Wem7GSxGCSTTXk4/uEm8hwwxjKKCiQFu3h4oeLn+0bIJXjE3htNnxyQ==; 4:WXOQyMsWW72Ji0v0awnYFTf2DgzA+dpHBbG3a3kYvi9aOOcykXBEcCq6YICrOMVTpwX4tks86rRpIlRq18BDyEfsLRBpfnohBezDn6dCgoycJH0k0F6MEwo+xmpTt3lXr1bcsayM08CFq0Nrjsp63JUwa8oYgKIrqAyZ8BnVA6XnZhINWQznXK/pVDuXwlcjGI7bQZqlQIUI0XFbdk/aosbmNlShX44IM+6ZwOHNwaSfgrKh7Y5shuSCqxArGRKf1arDsAFmGtIOYQdkK2jhOwhDuF4czR04AxUnMkDXfIDPEJQK62whBWWFTgz453DJvyfjdHKP71zJxyPdXibygpSecfG9hiCuPDMDBBFGnLy6yjf3EoHz09Wry+fOdBjH6BXAQ83RIIXLLQO7fx494RN4XxdRozHIDaGzhzxAHL3Jtd37nMYgjp3z1v95YtaARBtThnpORZ4GcTIwAZW97FomZxT+cSEEb92V17ADbfM= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(158342451672863)(788757137089); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:DB5PR07MB1622; BCL:0; PCL:0; RULEID:; SRVR:DB5PR07MB1622; X-Forefront-PRVS: 0021920B5A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(13464003)(24454002)(51444003)(252514010)(377454003)(189002)(377424004)(199003)(97736004)(92566002)(5820100001)(76176999)(81686999)(47776003)(8676002)(101416001)(42186005)(81156014)(81166006)(23676002)(44736004)(305945005)(189998001)(50466002)(6116002)(2870700001)(3846002)(5001770100001)(84392002)(62236002)(81816999)(44716002)(4326007)(66066001)(586003)(93886004)(116806002)(68736007)(1556002)(14496001)(2906002)(1456003)(77096005)(50226002)(9686002)(86362001)(33646002)(15975445007)(106356001)(50986999)(61296003)(19580405001)(19580395003)(105586002)(7846002)(7736002)(561944003)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1622; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjVQUjA3TUIxNjIyOzIzOnRGU2JMcEZXNWdSK05PYlBsbDhmK2pCeEdM?= =?utf-8?B?RVIwenhVRXVFMld3UFhKbGp5aSsxbkVZSEJvNUFoalduNnRKT09OYnhSTzhG?= =?utf-8?B?dENGcHJjbWVGS0lyY3ZHSkl3R1lPNGw1TVB1NzBuNURKVUJlVzhjUWhNVlcx?= =?utf-8?B?K29rWUwyL2VIK3BGY1h6OEplb2ZTam1mUmVya1Z1VFJxOXVScVpFTDZyekd3?= =?utf-8?B?VU13eFRzek96b21PMUFaSzYyM2hSSFZ4SytOTlRtYkhTWWE0VGNzM0gxOUNO?= =?utf-8?B?anBNaVZQYU9SSWlCQVZkT2FPR2pqM3V2T2IvaTBVZnZMNFpIZDZJQjNEOGk3?= =?utf-8?B?eVNiSksrY2p2Sks1dWJKaHVuMmJHN20rQ0JRZlYyN2hEY01hUzZJK0lJc0xG?= =?utf-8?B?VUppN3pUeEtXQ2YxdzFHYlVMUk0wdWVNSFhvdkxwaDFsM0pwUkkvbGhEY2Qy?= =?utf-8?B?M0toY2tvVTBaUkRrTkpFQlVFRlJGd2EremdHM0FDQjFwQ2xLMENOMCs2dSs4?= =?utf-8?B?T20zaUJTVStGL0syaEFmbEpmdlgxRXV3Mlpxa2hNVU9PRUlNNGxVaUZMbloy?= =?utf-8?B?a0FMdWdwQmNWNXA5Vm1uM1ExVzJvSkg3ZDFSUUNOTGNqcnpEUHdGeU9kS1V4?= =?utf-8?B?SkxKRU81NlUzcS9WUWdTQUZGOWtJaEZvejJkdzVFZVlrb1B2VURpMmlnOWd2?= =?utf-8?B?UFZiRkE3NWQ0SExFRTJHaHZrenN4cnVubnp4dVFZWEJqSDAvOUVXcnVFRHRa?= =?utf-8?B?ZjN5ZG9hVFp2ZWtVSTV4dzhOb2VpM2ZxSDRWaThmdnViMHNrajhXNkpQbHZY?= =?utf-8?B?dXpGWVBjZGc1VWhBVDNKS21WdFVNQzYxWG8waGI0OGZsMWhpMUVwMVJHS2FV?= =?utf-8?B?U3JmUmlZb3FHZjY5OEVVaGZGdkpwVXdXY283Z2lWdjNBU2ZoWUVTQ1NIbzYz?= =?utf-8?B?QW1VaFA0d3ljcDlhN0ZtVGpuRXhOTmttOFI2bGRjVGFkN0I1c2Fwa1pVTDAv?= =?utf-8?B?eDJEckk5Qis2bm9WbHF3Wmhlc3Y3WWlDeHFnSWtia3J5N1hJZWt4cU5sNWZG?= =?utf-8?B?SEpPRW9zY2ZLY1VmQmNVVDZyQmdlWGxmaHZpTThMaTlHK1lXLzZOTGNiQ1Vy?= =?utf-8?B?OEN1UUJZOHIwUEwyV0NXN3QvK0d6MXpEUUhuOTZaY1N3S3NTVEEvNUxOZjVq?= =?utf-8?B?ckVZaEVROWlDMjNZMndUQWswb2oyalpQZDZLOTA3azA0N29lR2dBb0pKeE5W?= =?utf-8?B?U3pZWkpBUUx4aTU3aU5RZmMvRTAyK1U4NkgycGRWUW9FSERYWStUSWJHcVNC?= =?utf-8?B?WGJYWmUzN0tRaXNSalljUTVCR3FnUDNlcDBObmEzY2xqS0poeU1jNDl5dTd1?= =?utf-8?B?cE9TcG9laDVrYXJWeTZKaDQxWURqOWhyTXN5cGczbVhyWFNNN3A1cDZiMFA3?= =?utf-8?B?L2k3cHBpS093eGx5dnk4Vmpna0M4czNud1J4a0FOd0FSbk80bm5NZU5DQlhL?= =?utf-8?B?YVhwUlE0aG10ZTQrWElodlY3ak96eFZoQSt5bSt5aDFtSXdTalVjNVhOMWsr?= =?utf-8?B?Q25oc1JVZURsVlN6Q1FkMjl5cStBT2tiaHZZVnJZZ283NmsrVzZYRFVENm5h?= =?utf-8?B?UFBoa2lUV0Z6NkpuVS9ZOHNDc1M4bnhKVEVHNGdGZ01iUEhZUFFkSlNrSXg3?= =?utf-8?B?VGE0Ym81c1lvUWdGbkY0Umw3OTE4L05Kc2FsRlpQTysvMlNiVXpWcGI0Y0Ur?= =?utf-8?B?VmlnRjR5bURwNWYvSXZKcGR0bUU1NlVsckpHRHRsNVpVUitRejN2OUVFSGdT?= =?utf-8?B?dnc2YmpCTTY1UGwvcUwvRi9qWDY1N3NIQ2xxaTRZaWRKc2c2QWh6RGNSemN2?= =?utf-8?B?aGlRaDQwakxYQkIza3Bqb3B1b1hZNVN6OW12QnFPa0Q0WVM1VlVacjJES2Ux?= =?utf-8?B?M2FQWmFHb1JSVDZ6ZmZ4Nkx3cDhxc1B3aytCVnR4YmU1QWZZdGNYems5UU5i?= =?utf-8?B?c1dzVWtZekdESG1QR0kyZVhqTkE0NjAwU254eWc4WTNhTGZCc1lKRW0vSG8v?= =?utf-8?Q?zH0pru3F2ap2MiAIXXH/71/oK?= X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 6:x0r/RnrCg3vqaz3RyPGpgEgSpapl2v1wQ/w9YHYk2TW73Fl8q5f8hE1XFaoA1WNklCuGSVf2SugPSrDgPHAprHiS2AxkPObtN8Er/AgLF5mqJwAwyYheP2sD6pQPINkcUoCbhg+RUsAvtIFqD8jKaBbG8rXxIDl4V501srOL9kOsyggcuwmKhhv+tKRgr2ZJKnq/DWS83rYC3Sfoq/notHUGtXOwLBIK+4ADksOMIyw7a4ZjAdo5OQ4PO14/x3dz8RBM9gI3qydTyuCLExejcbC0RklbVhI3ts0o1B1Y2Ao=; 5:nTyWpt9JCqtpn+8LP40If7avlKjT01rV/oCIr9n3DiUs06Z/aOmcvBHmaGUrt9ajCkIZRti/Fbqj4pJJtaqxI7j1V1/n8YwKApoaFLAnxf2Q97lFZi6LRhlUQGSn5bx1mJ9yvZCZNrQdPqovcha1sA==; 24:3z6cDBznLweMN7piV7a5n21ka8PgS7xNbgNmwEKVMh7t5cxVbxobmTMLwTRdmuEE5vJ70ruXRXQxhq7DiimQwAxF92pEv9cslagdtW0uYFo=; 7:eIxGcGW2ImmVuPlnpR3dMquvHwT2hOB6mnPzvt4ML/Hdvr2tFDpxpGri0mwiwNTGKPts2A4SM0Nc/rRqmXm2EMpLqU9Z9ruUZ1Q2Y9MhEjrk8aMMydp2qePOCcSdZtcuha0IAoIXck444qWye59oU2lkP5va9qMcLdd+CoR4iMNp4tYJ/UK2gUdmjsF3T696dRCRAh3sqm93QG3XL0iNqmZsQiYhqIUu3CWWTWiCKGviiRvf+P2dutwVBmvKRi6m SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Aug 2016 09:50:37.6363 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1622 Archived-At: Cc: Netconf Subject: Re: [Netconf] What should a server response be? - depending on NP-containers X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 09:50:45 -0000 > ---- Original Message ----- From: "Andy Bierman" Sent: Monday, August 01, 2016 1:23 AM On Sun, Jul 31, 2016 at 10:45 AM, Mahesh Jethanandani < mjethanandani@gmail.com> wrote: > On Jul 30, 2016, at 5:31 PM, Andy Bierman wrote: > On Sat, Jul 30, 2016 at 5:21 PM, Mahesh Jethanandani < > mjethanandani@gmail.com> wrote: > >> Andy, >> >> The thread started because the RFC does not say anything about a create >> of a NP container. It only talked about delete. Can we make the (re-)create >> of the NP container unconditional to whether a delete was performed on it. >> So a tweak to your proposal would be: >> > The only reason that example did not work is because the server deleted > the NP containers > after the client created them. If the server does not delete the > containers then > the 2nd RPC will not fail. > > I think this argument of whether server should or should not create/delete > NP containers is distracting from the main point of when NP containers > should exist. In my mind, the NP container existence depends on whether > child nodes exist or not. In the end, if child nodes exist, NP containers > should exist (created), if they do not exist, the NP container should be > removed. > > Can we agree on that? No. "should be removed" is an implementation choice. It started as MAY be removed. It needs to stay that way. As I have pointed out 100 times, the protocol has merge and replace for the situation where the client is not exactly aware of how ceration and deletion will be handled on the server. I think that Andy is spot on. We currently have a simple, clear rule in NETCONF: - delete, does not exist, error - create, does exist, error. Introducing corner cases that blur the rules, that allow users to be imprecise, whether by Standards Track RFC or an Erratum, I think a mistake An Erratum that points out that since a server may silently delete a Non-Presence Container with no children, a user can never know whether or not such a Container exists and so cannot know whether a delete or create to be an error or not, yes, that is fine. Going beyond that is a protocol change (which I would resist even in an RFC). Tom Petch There is no reason to force implementations to change. If you magically delete containers, then magically recreate them. If you don't then the nodes will be as the client expects, so no problem. Andy > > P.s The errata will be much easier to craft if we can agree on this. > > > This can also be completely avoided by using the default (merge). > Since the client has to explicitly pick default-operation=none, > it better know what it is doing. > > This is the same issue as a default leaf > and the create operation. Nothing special about NP containers. > > The for "create" will fail if the leaf already exists > and the "delete" will fail if the value is not there (just a default). > The work-around? Use merge and remove, not create and delete. > IMO the same logic applies here. > > > Andy > > > > > OLD: >> >> If a container does not have a "presence" statement and the last >> child node is deleted, the NETCONF server MAY delete the container. >> >> NEW: >> >> If a container does not have a "presence" statement and the container >> instance >> does not have any child node instances, the NETCONF server MAY delete >> the >> container. It MUST create the container instance if a client >> request >> attempts to create a child node instance within this container. >> >> >> On Jul 30, 2016, at 11:52 AM, Andy Bierman wrote: >> >> Hi, >> >> I strongly object to changing a vague MAY about deleting an NP container >> after the last child has been deleted into several MUST requirements. >> >> I propose this text instead: >> >> OLD: >> >> >> If a container does not have a "presence" statement and the last >> child node is deleted, the NETCONF server MAY delete the container. >> >> >> NEW: >> >> >> If a container does not have a "presence" statement and the container >> instance >> does not have any child node instances, the NETCONF server MAY delete >> the >> container. If the server does delete a container instance in this >> case, it MUST >> re-create the container instance if a client request >> attempts to create >> a child node instance within this container. >> >> >> >> >> Andy >> >> >> On Fri, Jul 22, 2016 at 3:13 AM, Balazs Lengyel < >> balazs.lengyel@ericsson.com> wrote: >> >>> Hello, >>> >>> We seem to have fundamental differences whether NP-containers >>> exist/don't exist or if this question is even valid. I hope we can agree >>> that as NP-containers are meaningless themselves they MUST NOT influence >>> Netconf operations or model validation. (Which is a slight violation of >>> Netconf-6241, which we should accept.) >>> >>> So I propose the following errata to rfc6020bis. >>> >>> As for non-presence containers the presence of the container node with >>> no child nodes is >>> semantically equivalent to the absence of the container node, >>> configuration operations or >>> model validation should never fail due to the existence or non-existence >>> of a non-presence containers. Specifically: >>> >>> - an create operation for a non-presence container MUST >>> succeed even if the container already exists. >>> - an delete operation for a non-presence container MUST >>> succeed even if the container does not exist. >>> - an operation with default-operation=none MUST succeed >>> even if one or more non-presence containers do not exist. >>> >>> Separately >>> - a must statement defined as direct substatement of a non-presence >>> container SHALL be evaluated as part of model validation if and only if one >>> or more child data nodes exist in the instance data or if there is a leaf >>> or leaf-list child with a default value. As non-presence containers are >>> only used for organizing the hierarchy they SHOULD NOT have any must >>> substatements. >>> IMO the above rules remove ambiguity and follow the current philosophy >>> of RFC6020bis. >>> If we have a basic agreement I can formulate the text correctly. >>> >>> I don't know whether similar updates are needed for RestConf. >>> regards Balazs >>> >>> PS. I still believe introducing NP containers was a mistake, however >>> they are here to stay. >>> >>> On 2016-07-21 09:17, Jan Lindblad wrote: >>> >>> Xiang, >>> >>> Are you saying that since a NP-container is merely a structure node, not >>> config in any way, so creating/deleting it explicitly (and repeatedly) is >>> equivalent to a “no-op” that will always succeed because doing so has no >>> effect on the server’s config in any way? >>> >>> >>> That's correct. "Creating" an object with zero bits of information is a >>> no-op. >>> >>> If the sever has the following example config: >>> >>> >>> >>> >>> >>> If a client issues an edit-config with: >>> < mycontainer operation="delete"> >>> >>> The server returns “ok”, >>> >>> If then again the client attempts: >>> >>> < mycontainer operation="delete"> >>> >>> The server should still return “ok”? >>> >>> >>> Yes, that's correct in my opinion. It's a consequence of the NP >>> container nature as defined in the current RFC6020/YANG 1.0 and bis. >>> >>> >>> If so I think this is confusing. I think it would make more sense in the >>> latter case if the server returns “"data-missing” error. >>> >>> >>> This is logical if you think of NP containers as path prefixes, and not >>> as objects with information content. If you accept that an NP container has >>> zero bits of information, how would the server even know whether the >>> container exists or not? Not by looking in a database, for sure. >>> >>> P containers have a single bit of information, so they can be created, >>> and the creation event/existence remembered by the server. Not so for >>> NP-containers. >>> >>> I understand we may advise a client not do so, but since RFC6020bis >>> does not forbid this, and it is also a perfectly valid , so I >>> am sure people will try it. >>> >>> >>> Yes. And it works today and is harmless. >>> >>> It's unfortunate that the YANG 1.0 and 1.1 specs aren't crystal clear on >>> the subject, but I believe the interpretation I and others have of NP >>> container behavior in RFC 6020 is consistent, implementable and highly >>> useful. >>> >>> /jan >>> >>> >>> -- >>> Balazs Lengyel Ericsson Hungary Ltd. >>> Senior Specialist >>> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com >>> >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>> >>> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> >> >> Mahesh Jethanandani >> mjethanandani@gmail.com >> >> >> >> >> >> > ------------------------------------------------------------------------ -------- > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Mon Aug 1 03:20:03 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8F012D605 for ; Mon, 1 Aug 2016 03:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYsppcjzu1Ga for ; Mon, 1 Aug 2016 03:19:59 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 58B6212D5F6 for ; Mon, 1 Aug 2016 03:19:59 -0700 (PDT) X-AuditID: c1b4fb3a-c7bff700000009bd-97-579f224cc14c Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by (Symantec Mail Security) with SMTP id 0D.63.02493.C422F975; Mon, 1 Aug 2016 12:19:57 +0200 (CEST) Received: from [159.107.197.181] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.3.301.0; Mon, 1 Aug 2016 12:19:56 +0200 To: t.petch , Andy Bierman , Mahesh Jethanandani References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com> <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com> <57892746.5020903@seguesoft.com> <57893742.6040903@seguesoft.com> <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com> <001c01d1e299$e057a910$a106fb30$@seguesoft.com> <6e416198-13bd-81e3-545e-35e8bfc61536@ericsson.com> <016801d1ebd9$cb9c3e20$4001a8c0@gateway.2wire.net> From: Balazs Lengyel Message-ID: Date: Mon, 1 Aug 2016 12:19:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <016801d1ebd9$cb9c3e20$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsUyM2K7oq6v0vxwg+cblCweHJnFbnHt0X0W i9Nv1rFZTN10m9WBxWPX0R/sHjtn3WX3WLLkJ5NHS/9FlgCWKC6blNSczLLUIn27BK6MY1f+ MRXs46iYdTS4gXEHWxcjJ4eEgInEw47jYLaQwHpGibvb7CHsNYwSf7dxgtjCAuESb5+uAasR ESiVmN/8nb2LkQuo5ge7xJ+Pd1lAEswCchKLf/QwgdhsAkYSU/vPg8V5BewlXh+9wNzFyMHB IqAi0XbAEMQUFYiRWN+XAFEhKHFy5hOwak6g6kkf1jJDTLSQmDn/PCOELS+x/e0cZojTNCQe XvjLOoFRYBaS9llIWmYhaVnAyLyKUbQ4tbg4N93ISC+1KDO5uDg/Ty8vtWQTIzBwD275bbWD 8eBzx0OMAhyMSjy8CSzzwoVYE8uKK3MPMUpwMCuJ8DoozA8X4k1JrKxKLcqPLyrNSS0+xCjN waIkzuv/UjFcSCA9sSQ1OzW1ILUIJsvEwSnVwBi1c5rYKvWJcouPPdM15d7dr5Y1pehE387m TU4/wgQyzvfHz/i7VC38N/8V2bZ9jOx+3zxqZNY1+3sdbuxQ/KGukr5Y9b/9fAH9ZUtn7tl7 L4ih3r/GX+nTyY//YrJDrtzbdcNHwHrmrweXilZ/u1A9J6E5WYyFW591ndy5t5q/+o9pcEf8 OqTEUpyRaKjFXFScCABXdumaWAIAAA== Archived-At: Cc: Netconf Subject: Re: [Netconf] What should a server response be? - depending on NP-containers X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 10:20:01 -0000 IMHO not defining what happens is the worst solution. Any solution is better. If we can't agree, we should follow the Postel principle: be liberal in what you accept. regards Balazs On 2016-08-01 11:47, t.petch wrote: > > > I think that Andy is spot on. We currently have a simple, clear rule in > NETCONF: > - delete, does not exist, error > - create, does exist, error. > > Introducing corner cases that blur the rules, that allow users to be > imprecise, whether by Standards Track RFC or an Erratum, > I think a mistake > > An Erratum that points out that since a server may silently delete a > Non-Presence Container with no children, a user can never know whether > or not such a Container exists and so cannot know whether a delete or > create to be an error or not, yes, that is fine. Going beyond that is a > protocol change (which I would resist even in an RFC). > > Tom Petch -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Mon Aug 1 03:28:17 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906D812D150 for ; Mon, 1 Aug 2016 03:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSklFcSiphO2 for ; Mon, 1 Aug 2016 03:28:14 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3BCB12D606 for ; Mon, 1 Aug 2016 03:23:02 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7A666A53; Mon, 1 Aug 2016 12:23:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Ii1h8wjr44tg; Mon, 1 Aug 2016 12:23:00 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 1 Aug 2016 12:23:00 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8C54E20077; Mon, 1 Aug 2016 12:23:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id euPMFYvYMGBi; Mon, 1 Aug 2016 12:22:59 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C975920075; Mon, 1 Aug 2016 12:22:58 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 21E763BFDDEB; Mon, 1 Aug 2016 12:22:55 +0200 (CEST) Date: Mon, 1 Aug 2016 12:22:55 +0200 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20160801102255.GB7476@elstar.local> Mail-Followup-To: Balazs Lengyel , "t.petch" , Andy Bierman , Mahesh Jethanandani , Netconf References: <001c01d1e299$e057a910$a106fb30$@seguesoft.com> <6e416198-13bd-81e3-545e-35e8bfc61536@ericsson.com> <016801d1ebd9$cb9c3e20$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.6.0 (2016-04-01) Archived-At: Cc: Netconf Subject: Re: [Netconf] What should a server response be? - depending on NP-containers X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 10:28:15 -0000 I agree with Tom and the 'solution' is IMHO to encourage clients to use 'merge' instead of assuming a certain behavior here. /js On Mon, Aug 01, 2016 at 12:19:55PM +0200, Balazs Lengyel wrote: > IMHO not defining what happens is the worst solution. Any solution is > better. If we can't agree, we should follow the Postel principle: be liberal > in what you accept. > > regards Balazs > > > On 2016-08-01 11:47, t.petch wrote: > > > > > > I think that Andy is spot on. We currently have a simple, clear rule in > > NETCONF: > > - delete, does not exist, error > > - create, does exist, error. > > > > Introducing corner cases that blur the rules, that allow users to be > > imprecise, whether by Standards Track RFC or an Erratum, > > I think a mistake > > > > An Erratum that points out that since a server may silently delete a > > Non-Presence Container with no children, a user can never know whether > > or not such a Container exists and so cannot know whether a delete or > > create to be an error or not, yes, that is fine. Going beyond that is a > > protocol change (which I would resist even in an RFC). > > > > Tom Petch > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Aug 1 03:34:58 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E07012D128 for ; Mon, 1 Aug 2016 03:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjuQfYuRp6RM for ; Mon, 1 Aug 2016 03:34:54 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 6708912B063 for ; Mon, 1 Aug 2016 03:34:54 -0700 (PDT) X-AuditID: c1b4fb2d-bbfff70000000190-c4-579f25cb027d Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id 28.CC.00400.BC52F975; Mon, 1 Aug 2016 12:34:52 +0200 (CEST) Received: from [159.107.197.181] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.301.0; Mon, 1 Aug 2016 12:34:51 +0200 To: t.petch , Andy Bierman , Mahesh Jethanandani , Netconf References: <001c01d1e299$e057a910$a106fb30$@seguesoft.com> <6e416198-13bd-81e3-545e-35e8bfc61536@ericsson.com> <016801d1ebd9$cb9c3e20$4001a8c0@gateway.2wire.net> <20160801102255.GB7476@elstar.local> From: Balazs Lengyel Message-ID: <6c21a938-2fe1-8f67-69a7-6a3be053253d@ericsson.com> Date: Mon, 1 Aug 2016 12:34:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160801102255.GB7476@elstar.local> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNLMWRmVeSWpSXmKPExsUyM2K7lu4Z1fnhBuu2KFg8ODKL3eLao/ss FqffrGOzmLrpNqsDi8euoz/YPXbOusvusWTJTyaPlv6LLAEsUVw2Kak5mWWpRfp2CVwZv4+/ ZyyYKFAx46BjA+NRni5GTg4JAROJrYs62bsYuTiEBNYzSszb9BTKWcMosefEUmaQKmGBcIm3 T9ewgSREBCYySqw+t58ZouoTi8SiY8dYQarYBIwkpvafZwGxeQXsJR7fncYGYrMIqEgc2XYe qIaDQ1QgRmJ9XwJEiaDEyZlPwMo5BQwl/v9sZwQpYQZqfbC1DCTMLCAvsf3tHLAbhAQ0JB5e +Ms6gZF/FpLuWQgds5B0LGBkXsUoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokRGKQHt/zW3cG4 +rXjIUYBDkYlHt4ElnnhQqyJZcWVuYcYJTiYlUR4OVXmhwvxpiRWVqUW5ccXleakFh9ilOZg URLn9X+pGC4kkJ5YkpqdmlqQWgSTZeLglGpgdKx8tO7XlkfRW/2DK/O0PryeWl8y6dqE6WdX zZjPovfiqErPLPNdrz7tOrpU5J559NWiaJnzlf7Blx/er0vN3HLttvih5G3Hj+cdrbvFaLy3 zX/RMhWu3lNcj/4KfLh1Ml9lubyz9rbzUW4qnJOmL/u/w041+OW6uMwpSc9XMq/ichR/nWia LK3EUpyRaKjFXFScCADl0zWvTgIAAA== Archived-At: Subject: Re: [Netconf] What should a server response be? - depending on NP-containers X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 10:34:56 -0000 This uncertainity makes default-operation=none fully unusable, and make create and delete unusable for NP-containers. That means 3 out of 6 operations for Netconf 1.1 and 3 out of 5 for Netconf 1.0 are not properly defined. This is a BUG. We want to use create because with merge you can accidently create data-nodes. Balazs On 2016-08-01 12:22, Juergen Schoenwaelder wrote: > I agree with Tom and the 'solution' is IMHO to encourage clients to > use 'merge' instead of assuming a certain behavior here. > > /js > > On Mon, Aug 01, 2016 at 12:19:55PM +0200, Balazs Lengyel wrote: >> IMHO not defining what happens is the worst solution. Any solution is >> better. If we can't agree, we should follow the Postel principle: be liberal >> in what you accept. >> >> regards Balazs >> >> >> On 2016-08-01 11:47, t.petch wrote: >>> >>> >>> I think that Andy is spot on. We currently have a simple, clear rule in >>> NETCONF: >>> - delete, does not exist, error >>> - create, does exist, error. >>> >>> Introducing corner cases that blur the rules, that allow users to be >>> imprecise, whether by Standards Track RFC or an Erratum, >>> I think a mistake >>> >>> An Erratum that points out that since a server may silently delete a >>> Non-Presence Container with no children, a user can never know whether >>> or not such a Container exists and so cannot know whether a delete or >>> create to be an error or not, yes, that is fine. Going beyond that is a >>> protocol change (which I would resist even in an RFC). >>> >>> Tom Petch >> -- >> Balazs Lengyel Ericsson Hungary Ltd. >> Senior Specialist >> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Mon Aug 1 04:14:04 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B8012D732 for ; Mon, 1 Aug 2016 04:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKwbcQp7hFb4 for ; Mon, 1 Aug 2016 04:14:00 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50104.outbound.protection.outlook.com [40.107.5.104]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 079A812D692 for ; Mon, 1 Aug 2016 04:13:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ySihsyv51M79X5KOi82f2Yfo4nq/gfrG0rSZQe3NmB4=; b=h1PLTeTi2iXnQ6LhSlSUbVLQ4OOolK3xMC1bK05LiX0akb8rkOkd1+RVyySB/KBiEOdBAHPulEIHZJcjgU7cyt5jbfYPt2a7hzsdI74fluireMvdOud9CM5YtSeVwlNaD+xnrUB3gukp9xPF28ZTNr76Vyihtz2ETvGKPQ/tPOE= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (31.50.86.164) by VI1PR07MB1631.eurprd07.prod.outlook.com (10.166.142.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Mon, 1 Aug 2016 11:13:55 +0000 Message-ID: <005a01d1ebe5$6ee080e0$4001a8c0@gateway.2wire.net> From: t.petch To: Andy Bierman , Mahesh Jethanandani , Balazs Lengyel References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com> <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com> <57892746.5020903@seguesoft.com> <57893742.6040903@seguesoft.com> <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com> <001c01d1e299$e057a910$a106fb30$@seguesoft.com> <6e416198-13bd-81e3-545e-35e8bfc61536@ericsson.com> Date: Mon, 1 Aug 2016 12:10:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 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: [31.50.86.164] X-ClientProxiedBy: HE1PR08CA0030.eurprd08.prod.outlook.com (10.161.112.40) To VI1PR07MB1631.eurprd07.prod.outlook.com (10.166.142.149) X-MS-Office365-Filtering-Correlation-Id: a2e819bf-e151-4bfe-0151-08d3b9fcedb0 X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1631; 2:d0cwl99NMTDz6n+on0yZTENkWuRGGbOT1BOFiq8abuPC6L2WoYz8vHR7CDRlypo3Oju6k2hE5mfMiuKzYeVSBd/mNUYrj2+ghYZvPCKAPJWB+xE9yZya8+xrPp26ThN6dcOO1w0WX3yFgzQ2p4/ZgnihYeLPgihu6dwfhvaMreUGeOBw/8GGGpGLHrwOns8F; 3:FTEkMLh1rWYlwXHg3YcahajYItkMlscUwd5WnleFqDilpZ9MKiVYFnd9AYCOZtlV3bUEpuQZ9jUBxceNUggWyrUlN+e/08e80KHkKtb5EiClGC05Bgq19gKyDQhTYN7U X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1631; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1631; 25:rLhfE03c9L0OfQudKbiSk3lqTYjG4OQJUrHZ6v3Do7NAmateF86Q8aaKIt5LXxaGOX4jH4+NntA8cKKxKvJ5pSsfcMyu6sxFxr5ScxX1ot4ieK66TsVBJksj3cmsLeo46F0YV01qPsuaj1SxOtaUDx6YE94XWUu3On25KL+XxjyQVzi8wUh8SUjqKI0NlwTStwa97zYr/o2EH535q+tE8JGhD0WfRuMaKuRe6BZpPYj1gFc5ABHsy9eBzAL8xSgHoK0+ko83uE8vTSLzAeG4+w9CjHo3PLgxIxsSqnAUmxPQErgC4yJzVscYnFl1dAUe2YkS7pbrKI7mTdb16ghIxJ/sFIROjqDhYX5bmVXns4uWxZ/e//D9pjkjCiMNIyhpG2ScziCQIfkD1BKlN/cfw9GswNlPonB1nLOAcJHJxCQdUqj9XzVrm5RXzWEe5UnsFbC+NhNdHyGD88CaC1JT/iY4u8bEotYvFo6SYJTn8sBA0SDG02aJBflx1SmCiU9jsbwmbwO+ndNiJJFdblGMXcgyFeWEgCNuClCGiyvjXQv/BPS/FKD1vXAxlQHEBp241ZlHONuiYIIpuCKy0I4Eq+5pItjkpER8Brv6JeIm561EO827U/3pfP9GMP259eqwGMhzy4iPPePR+AnnpzN7AwHvyE7Hrhzlz8UwMrswjTAMPWuu0M9HOivezlCr2kz3C1P+BgGmoKEnYjg/p3E68YNSwJd54JvAk1D0k2cDHnLbtUQ3jYvVaowgdXopBn3TGcoVngop14sKMZ5MCVTf1i5c4s3XrKhLKBOISJlwD8Ma9ISNDj4/SQLoGqfCoKffnGPlaS4evkw8rUyoCAk5zQ== X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1631; 31:e/mqiqjYVq6Hwq85ksbBhhqh9ta+FswqWXTp3lldj9FWV00Fr4lMeZAPe+mY3VgPMBaJ/XUh+nar56yRd5qv3On7aTMUwT/x+c3XGMWfFZ/+l9//R3X7NMDj5RYgm8OeO+gxC2CAhCR5EFlf6MPMw4a66LS9C+4iKHeZXRF8l4n8vW1hwqkvB4Dha85cvdemvQb2MA1l0XvaNQjNNOfKig==; 4:3GxushklOEVfuLvUMqy6bJqX5NPOQG7cBXcCRYo0YncxY45lTXQ28qT/GwvOONFjGCfRCN1qw/rpH0ZgMsw84ZT588o8CP/fgPvgSyD+wI1HW6zcWK1dIRA/m1Z800YeMVpUvQPbC3EFSQU3zt61ZBlNvQ5+GVJhWhj2977/ibDjrCVzwten2ptNNgtM5CqXbYCEAh8kWYNHqvXoBCVe65qREVTNvsJWmI11L92gU/+Fu8oy6SWCd/fMXQYE2mmz1zUs5uWjkxy5uR5/dpABV5TaCmCDXzNU/igkGV2OrFWcfOxQs7802D2WooteHA4X3jvrBJ+bU8VB20Mlvdf/ziU18jceYoAZ7SceyKyTwi+7MKqDAZtrTnixCGX9P2q1u/vHfsgspX6tQ9CHoj7JLDEN0NT2mP09Ty1Hl1UWvKk6VQU/QciLgLbwNdn8OKpoy4qTkdjNkgGJ4fZQFAZQEyYQ29SfYpQfBSh0TM9a0jc51p72SFRtizZwk/AVlT7El9PrgF8Hf/8g4Y9wDMMsgQ== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(158342451672863)(131327999870524)(788757137089); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:VI1PR07MB1631; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1631; X-Forefront-PRVS: 0021920B5A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(252514010)(377424004)(199003)(377454003)(24454002)(13464003)(189002)(77096005)(15975445007)(97736004)(23676002)(189998001)(561944003)(50986999)(1456003)(81686999)(5001770100001)(62236002)(19580395003)(1556002)(19580405001)(44716002)(33646002)(81816999)(76176999)(86362001)(2906002)(101416001)(93886004)(4326007)(84392002)(116806002)(7736002)(7846002)(305945005)(106356001)(105586002)(50466002)(47776003)(14496001)(586003)(61296003)(44736004)(81166006)(50226002)(42186005)(8676002)(68736007)(9686002)(81156014)(66066001)(92566002)(3846002)(2870700001)(6116002)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1631; 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: =?utf-8?B?MTtWSTFQUjA3TUIxNjMxOzIzOjZRbHNGWm82SlZVUWpPZGJISXRQWXp2Zi9F?= =?utf-8?B?VUxFVmlnU0Q4dExtVGRnb3kwMitFK1NKd3NpRWNBNTMxcForRUIxNlR1SGhF?= =?utf-8?B?SWcrZGhCajJkbmp4QlNxQzQvVk5heXk1cy9MZVFiVTdLMFQ3N1ViVDVrNmUv?= =?utf-8?B?a1Q0dUw2cFpoOFlzbGVHd0RsYWVzUGZiRHlUVmNVZklWQUNTNEJubUZCUEpr?= =?utf-8?B?K2lpbUp0bm9jeHorTUhXWUhWcUVwb24vNE0xUmtEc1VwQjUrRk56ZUxKUW5O?= =?utf-8?B?U2t5T1RZd0V5QmxZUkFlcldXTTFCUmVxaDZaYXorTDM5ZnZjZElBbCtlN2h5?= =?utf-8?B?N01CQlp3OXpwSjZob1BwbE9jY2VNZ0xLbXZoUyszNEh1djZobW1BR2R6aHJ2?= =?utf-8?B?Y1kzeTNrNHdQaHI1YjZ3UUZITzVXakxhRFdRTjQ4REt2UUtoaFhCM0JFaXVo?= =?utf-8?B?YVFvZHNiemtvcFhXUWJQRlMyTVBVRVJMbE01akNpS3FXdkhsdkJ4azJ2QjVa?= =?utf-8?B?SVhJeVoxY1B6a2VwS2JJYlRHVEltQXV4SU1WWFpXcVpTZGJWNzIxSDNYRXdN?= =?utf-8?B?VEdLUkpSVXpxMGM5ODFXejRpd1BhdHJoeFNsMnRLdUYzV1VrWFBrZURoNUVy?= =?utf-8?B?d3NpS21maEd2SzRreFJqTE5wWVRodFB0b3ZOa3JCVm5TaDhlM0Z5SXRkNHJ1?= =?utf-8?B?clhveTd6eEFnRE54ZjF4N0h2aVRZeittdFRveG9WZ2NnOHNLU29wTWp2dE04?= =?utf-8?B?dUdsTGJOblJYQzFDcFRNV0R3ZGZVRWhHMVhFOExZMzNZdlhvaVA2S1UwOVR5?= =?utf-8?B?UGhpcWRuaGg1L1U2MHJxeCt3TkNUdDg3YnkrOFlBK0dsbGYrY0YwazlKSzJC?= =?utf-8?B?QXpzOGJxNmhiVmEzNWpHenZERXd5c2xIQnExdnlEMzc4eWd1OHpPR0FFVGVw?= =?utf-8?B?RkdKdGZxcTlQemJHMzBVZ1BkcHlpWXhHeXBlSzU0dmNGMVdmekc5Vk1RSWhJ?= =?utf-8?B?dnNOUkpkemZ5bkZzMHpLb1JYalpiVXUwOExhR0tBYkY4bU1BelY5TGJXb1Fz?= =?utf-8?B?cVhIRWEvVDdEZmxBVDM4MmdMT2svM3E0MGZoZTVCM1BUa3BudUFIVlNQY1lW?= =?utf-8?B?NGtYeTlXTlNuRy92UWJpWE1aYkdzRC85MHhhNEtGb2JlRlRFUlNqNkFSWXlH?= =?utf-8?B?K3h1cXRqTGF1UHZnbkJrb3BlaDRDM3BLYmxMUzZUTVA4eFpLNGxHM0doVURN?= =?utf-8?B?QkZHeXEvUld5TjhGaitGa0lQN09DTElBQ3lJZklpWlpmcXRnWTc1U0NvZldC?= =?utf-8?B?dEpMSHBYbUd6YVZ4dGlNNXByV3pDSW5KdGhYUmJ3WkFVazhwRFg3cFc1OEF5?= =?utf-8?B?RkVoWVpCZVVBelozUXFkQU1USWFZdU9kOWh2Rzl0TE5KcmVZTEJEZ1NwOGdu?= =?utf-8?B?cmZPNUo0MmljWExidEpYSnJEdjZmL1M4OHg1TGZBZVVLM0FMc1BaM3Q1bUto?= =?utf-8?B?SjVCd2xuZE9rYlhMeUR6SDhBQ2hXMWo0QTFpaGhiTWlXVGg5RGFEVWFCU1U5?= =?utf-8?B?WXozRHgyQXdVUEFWZjZxQk1DbVJwYlVIV0d3WEVONlZ5N0JmV0Z3Sm5pd1hq?= =?utf-8?B?bDdPVnVGTEVmNU9yTFdacVF5cDZCc0ZSVGhESmZSQjNaWFhTWXlLTVBGTXFr?= =?utf-8?B?M1F1MjNkWHdSY1VheXlQMTlyVzJ2cU11UzlSd3NGUkFwVmxEeEZxdXQ2bWll?= =?utf-8?B?SmRjYjBWTVNON053WkI2YnBQT0dOaTRPRkM5ck5PbGRTQm5OQWJaMXFkZHIy?= =?utf-8?B?WjNXaWl6dHNiSDYvNHJxajNJWHd6RkdkQTdzK2FieFl3S2JPU3lRc3BVUEsy?= =?utf-8?B?WlV0NStUdjVMWHE1aC93dkdjSlROUEVURWJFcGw5QVV2dXluNlpkckdEYkVt?= =?utf-8?B?SWF6MTRCNFl1b3VTZjFib2Q1Wk50SHFwY1RiSjUzRndGYmZYcTJrRXhmZi9w?= =?utf-8?B?cVRJZ2VjU2hSVWFJem9xR0V0RzdiajNWT1gzdz09?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1631; 6:6kXYqplnYlAO2kbax6HmhHVHIRJ/uxNYwGZoeHJjNXTLCCAlXcnO8ZR1dXvMpbb6C5IoOdEYI3aNJKBEvgYnrerVRFdzbD+WJDTbzCuiogcgDVeTA9NXuMwF/lVLJAu9jkpB1qHXMDgri1swB9qo45XcG3nuE7/5e+5vri/zM/zg4bEc3RdKwnPBmM2mVzVrZsVCPtsHHS3LLn+Zy8oN6S+J4Dz/cmg9n6/nyf1Rf8XKXmA/JPpQw1Jqa7C+wvt0s5un9eEWjVZ1Nvb4iSUoxLSIbcuzb6rxQGHU7POyoW0=; 5:/qkpaWzAD7hexpT6J7fD7PtkPM0+dssONqh2pFSbvmf7+Xgw6Z+cXbo+JH1b5qvPhKFa2YEL1Kq7yOtoqjSmiLmAzyFGD+BMCUbimOgOk/4J5z9FC5Di4VofpHBnPetwZwtieQPMqk2deqro43bn+g==; 24:CbXZ3+aSB1WPIxI2EMrOyeHtcDRU3SsPDK88ZUzGzdEl4TCZI0UZkALlVsfYT3ym6Cib+n5SNqcexyz68VwBo3ygm/kre1y1R/LBxLKc2AM=; 7:dsazyChdpTlivim1ddLhz3KlAWa/K05yTIl4mmNtD6pM5YZwqPc4kv8zZTN6h1b0+4EZemDY7mJ+PyIhqrIeObVrjiASpS3NBFr4nA7BMtpde1T6F8oXOrMo35oIJA4ujX6h2PYx5h8t5CZFQjQeOe8WnnXwd+DxBl2DPy1jqfezoF8Gg8I1WfqoVG5zK4t3oi4fzpcY9oh5MtOQvuUNmvBH2p3Am0DNe3hX+sMDmnO+DVH6HGv0fa5sQhf1Xi2M SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Aug 2016 11:13:55.2457 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1631 Archived-At: Cc: Netconf Subject: Re: [Netconf] What should a server response be? - depending on NP-containers X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 11:14:03 -0000 ----- Original Message ----- From: "Balazs Lengyel" Sent: Monday, August 01, 2016 9:55 AM > Hello, > > As I see it: > > - The main problem is we don't agree whether or when NP containers exist. Some people think they should exist (or not) just as any other data node. (me, Andy, RFC6241) while others believe the existence of the NP containers is not even a valid question (tailf). As we have such basic differences, I propose to focus just on the specific protocol cases that are problematic. Balazs As a practical engineer, it is obvious to me that they exist. A response to a NETCONF 'get' may, or may not, contain them so it affects the XML I receive, so they exist, period. When I read that they do not convey any information, I surmise that this is a statement from Information Theory for some meaning of the word Information which likely I do not understand. But so what? The specification of Yang says I may see them so when I do, I know that they exist. The specification is also very clear that I cannot rely on seeing them (if no child node exists); such imprecision may or may not be a good thing in a Standard but the text is very clear and unambiguous on this point. As ever, how a server achieves this is up to the server; what matters is the appearance presented to the rest of the world, imprecise as it may be. Looking back, I read 'A distinct container should be used when encoding lists with multiple instances ...' 'Some containers exist in the 'real world' and some are only modelling artefacts.' 'Use of container elements allows simpler manipulation of lists and list members.' which, for me, is the rationale for the two types of containers we have. A Non-Presence Container makes life simpler for the data modeller and the user of the data model. Tom Petch > - IMHO this problem means that the following 3 cases are not properly defined and we need to clarify them. Saying the client should just not use major parts of the protocol for NP-containers is wrong. > > 1) what happens if default-operation=none meets a non-existing NP container > 2) what happens if you create an NP-container and that already exists e.g. you issue create twice > 3) what happens if you delete an NP-container that does not exists e.g. issue the delete twice > > IMHO saying that from the 6 operation values 3 are undefined for NP-container is not acceptable. > As we have protocol operations defined in RC6020 we need to define them properly. > regards Balazs > > > On 2016-08-01 02:23, Andy Bierman wrote: > > > > > > On Sun, Jul 31, 2016 at 10:45 AM, Mahesh Jethanandani wrote: > > > > On Jul 30, 2016, at 5:31 PM, Andy Bierman wrote: > > > > > > > On Sat, Jul 30, 2016 at 5:21 PM, Mahesh Jethanandani wrote: > > Andy, > > > The thread started because the RFC does not say anything about a create of a NP container. It only talked about delete. Can we make the (re-)create of the NP container unconditional to whether a delete was performed on it. So a tweak to your proposal would be: > > > > > The only reason that example did not work is because the server deleted the NP containers > after the client created them. If the server does not delete the containers then > the 2nd RPC will not fail. > > > I think this argument of whether server should or should not create/delete NP containers is distracting from the main point of when NP containers should exist. In my mind, the NP container existence depends on whether child nodes exist or not. In the end, if child nodes exist, NP containers should exist (created), if they do not exist, the NP container should be removed. > > > Can we agree on that? > > > > > No. > > > "should be removed" is an implementation choice. > It started as MAY be removed. It needs to stay that way. > > > As I have pointed out 100 times, the protocol has merge and replace > for the situation where the client is not exactly aware of how ceration and > deletion will be handled on the server. > > > There is no reason to force implementations to change. > If you magically delete containers, then magically recreate them. > If you don't then the nodes will be as the client expects, so no problem. > > > > > Andy > > > > > P.s The errata will be much easier to craft if we can agree on this. > > > > > This can also be completely avoided by using the default (merge). > Since the client has to explicitly pick default-operation=none, > it better know what it is doing. > This is the same issue as a default leaf > and the create operation. Nothing special about NP containers. > > > The for "create" will fail if the leaf already exists > and the "delete" will fail if the value is not there (just a default). > The work-around? Use merge and remove, not create and delete. > IMO the same logic applies here. > > > > > Andy > > > > > > > > > OLD: > > > If a container does not have a "presence" statement and the last > child node is deleted, the NETCONF server MAY delete the container. > > > NEW: > > > If a container does not have a "presence" statement and the container instance > does not have any child node instances, the NETCONF server MAY delete the > container. It MUST create the container instance if a client request > attempts to create a child node instance within this container. > > > > > On Jul 30, 2016, at 11:52 AM, Andy Bierman wrote: > > > Hi, > > > I strongly object to changing a vague MAY about deleting an NP container > after the last child has been deleted into several MUST requirements. > > > I propose this text instead: > > > OLD: > > > > > If a container does not have a "presence" statement and the last > child node is deleted, the NETCONF server MAY delete the container. > > > > > NEW: > > > > > If a container does not have a "presence" statement and the container instance > does not have any child node instances, the NETCONF server MAY delete the > container. If the server does delete a container instance in this case, it MUST > re-create the container instance if a client request attempts to create > a child node instance within this container. > > > > > > > > > Andy > > > > > On Fri, Jul 22, 2016 at 3:13 AM, Balazs Lengyel wrote: > > Hello, > > > We seem to have fundamental differences whether NP-containers exist/don't exist or if this question is even valid. I hope we can agree that as NP-containers are meaningless themselves they MUST NOT influence Netconf operations or model validation. (Which is a slight violation of Netconf-6241, which we should accept.) > > > So I propose the following errata to rfc6020bis. > > As for non-presence containers the presence of the container node with no child nodes is > semantically equivalent to the absence of the container node, configuration operations or > model validation should never fail due to the existence or non-existence of a non-presence containers. Specifically: > > - an create operation for a non-presence container MUST succeed even if the container already exists. > - an delete operation for a non-presence container MUST succeed even if the container does not exist. > - an operation with default-operation=none MUST succeed even if one or more non-presence containers do not exist. > > > Separately > - a must statement defined as direct substatement of a non-presence container SHALL be evaluated as part of model validation if and only if one or more child data nodes exist in the instance data or if there is a leaf or leaf-list child with a default value. As non-presence containers are only used for organizing the hierarchy they SHOULD NOT have any must substatements. > > IMO the above rules remove ambiguity and follow the current philosophy of RFC6020bis. > If we have a basic agreement I can formulate the text correctly. > > I don't know whether similar updates are needed for RestConf. > regards Balazs > > PS. I still believe introducing NP containers was a mistake, however they are here to stay. > > > On 2016-07-21 09:17, Jan Lindblad wrote: > > Xiang, > > > Are you saying that since a NP-container is merely a structure node, not config in any way, so creating/deleting it explicitly (and repeatedly) is equivalent to a “no-op” that will always succeed because doing so has no effect on the server’s config in any way? > > > That's correct. "Creating" an object with zero bits of information is a no-op. > > > If the sever has the following example config: > > > > > > If a client issues an edit-config with: > < mycontainer operation="delete"> > > The server returns “ok”, > > If then again the client attempts: > > < mycontainer operation="delete"> > > The server should still return “ok”? > > > Yes, that's correct in my opinion. It's a consequence of the NP container nature as defined in the current RFC6020/YANG 1.0 and bis. > > If so I think this is confusing. I think it would make more sense in the latter case if the server returns “"data-missing” error. > > > This is logical if you think of NP containers as path prefixes, and not as objects with information content. If you accept that an NP container has zero bits of information, how would the server even know whether the container exists or not? Not by looking in a database, for sure. > > > P containers have a single bit of information, so they can be created, and the creation event/existence remembered by the server. Not so for NP-containers. > > > I understand we may advise a client not do so, but since RFC6020bis does not forbid this, and it is also a perfectly valid , so I am sure people will try it. > > > Yes. And it works today and is harmless. > > > It's unfortunate that the YANG 1.0 and 1.1 specs aren't crystal clear on the subject, but I believe the interpretation I and others have of NP container behavior in RFC 6020 is consistent, implementable and highly useful. > > > /jan > > > > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > > Mahesh Jethanandani > mjethanandani@gmail.com > > > > > > > > > > > > > > > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > ------------------------------------------------------------------------ -------- > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Mon Aug 1 04:41:56 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFE112D778 for ; Mon, 1 Aug 2016 04:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ikb9iqsvYivf for ; Mon, 1 Aug 2016 04:41:53 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::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 76A6B12D774 for ; Mon, 1 Aug 2016 04:41:53 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id h186so54608705pfg.3 for ; Mon, 01 Aug 2016 04:41:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PYtprdMIVvcHZHZv66gB+SBcmOIbbacN1Q8ncDrvTP8=; b=QBQWPcl1SDFbs/mQEm9wvt9V7rQrKfZ/G5AcfSrZqS/BCfZ2qvtp5p6Nvt4hMVxifO D4cFbx5KVzdMFeoE2abPGjUMlE7Dqos2G0pcs46dJ3YV/c/a6WUD7thYjr/hDXGVJdE6 4z13M9NZbAQpyiIQ0mF+393YoAbCkspcvOPVkEeRVGg/TvL35DRTginxHEGrsHxsXMQw MqzBGRtHq6DWQDiff7kGNUQc3HmwWDhP+qstaGu+g7OToTZVRpZhORagZxtPpNK1eufF 3pD5FsLxbUBRf2Dms+ej/KI000FON/jnetVtaexuwF1s2kCPGF022FGdqKt432qT1bCA uR7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PYtprdMIVvcHZHZv66gB+SBcmOIbbacN1Q8ncDrvTP8=; b=IDCkFdWjT2UFlIHycwRMeHvnd0P8iOBaCdY7JeVj+aD/8t9/pUUVGgTk/tpVN/VIl8 2lwLQ4Q8daTSVYU/jUgX/kvXB34sOzYP4rYjJazyuRafHSOciabtrJe4ibkDL48jzrKk pv0oiDVFg5RrzbPsQYHpBTOg3hkpTu4dUO160OiDj223w7OdnM44QWu5TjmMBwQBpQHf WPqmsl1wYTtahA5fYoRM9BF5WmoGp05wv47nemEkQImTLlX8Xb2tWen5J6gFsblPpDMW rp2MnEVZw3jh2G2kse9cAji0mK71dg24SCz5zIuXFutkR8YDP742Q+/A8AnP/xhtNnay hK2Q== X-Gm-Message-State: AEkooutZ7cZCjwWkV4h2cEhPWLER8Q860ng9XlVBDiyI4GZ4GYqqp8mDfJgPBQaF/LnZdQ== X-Received: by 10.98.149.131 with SMTP id c3mr96166395pfk.73.1470051712896; Mon, 01 Aug 2016 04:41:52 -0700 (PDT) Received: from [10.24.3.210] ([128.107.241.176]) by smtp.gmail.com with ESMTPSA id c66sm45084424pfd.24.2016.08.01.04.41.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 01 Aug 2016 04:41:51 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: <20160801102255.GB7476@elstar.local> Date: Mon, 1 Aug 2016 07:41:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <30B6D9D0-1E0D-4848-99C2-ACCCC27237AC@gmail.com> References: <001c01d1e299$e057a910$a106fb30$@seguesoft.com> <6e416198-13bd-81e3-545e-35e8bfc61536@ericsson.com> <016801d1ebd9$cb9c3e20$4001a8c0@gateway.2wire.net> <20160801102255.GB7476@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Netconf Subject: Re: [Netconf] What should a server response be? - depending on NP-containers X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 11:41:55 -0000 > On Aug 1, 2016, at 6:22 AM, Juergen Schoenwaelder = wrote: >=20 > I agree with Tom and the 'solution' is IMHO to encourage clients to > use 'merge' instead of assuming a certain behavior here. Agree.=20 How do we articulate that in the RFC? >=20 > /js >=20 > On Mon, Aug 01, 2016 at 12:19:55PM +0200, Balazs Lengyel wrote: >> IMHO not defining what happens is the worst solution. Any solution is >> better. If we can't agree, we should follow the Postel principle: be = liberal >> in what you accept. >>=20 >> regards Balazs >>=20 >>=20 >> On 2016-08-01 11:47, t.petch wrote: >>> >>>=20 >>> I think that Andy is spot on. We currently have a simple, clear = rule in >>> NETCONF: >>> - delete, does not exist, error >>> - create, does exist, error. >>>=20 >>> Introducing corner cases that blur the rules, that allow users to be >>> imprecise, whether by Standards Track RFC or an Erratum, >>> I think a mistake >>>=20 >>> An Erratum that points out that since a server may silently delete a >>> Non-Presence Container with no children, a user can never know = whether >>> or not such a Container exists and so cannot know whether a delete = or >>> create to be an error or not, yes, that is fine. Going beyond that = is a >>> protocol change (which I would resist even in an RFC). >>>=20 >>> Tom Petch >>=20 >> --=20 >> Balazs Lengyel Ericsson Hungary Ltd. >> Senior Specialist >> Mobile: +36-70-330-7909 email: = Balazs.Lengyel@ericsson.com >>=20 >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 Mahesh Jethanandani mjethanandani@gmail.com From nobody Mon Aug 1 05:25:45 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F242112DA77 for ; Mon, 1 Aug 2016 05:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smv3dbwom_2k for ; Mon, 1 Aug 2016 05:25:39 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C814312D955 for ; Mon, 1 Aug 2016 05:18:16 -0700 (PDT) Received: from syd-vpn-client-255-1.cisco.com (unknown [64.104.248.207]) by mail.tail-f.com (Postfix) with ESMTPSA id 2F2CE1AE0385; Mon, 1 Aug 2016 14:17:46 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_B6CC6AC1-42E3-477D-90E1-2EE7CA2ADE71"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Jan Lindblad X-Priority: 3 In-Reply-To: <005a01d1ebe5$6ee080e0$4001a8c0@gateway.2wire.net> Date: Mon, 1 Aug 2016 14:17:41 +0200 Message-Id: <6117E871-202F-4D40-BB83-7CB0FFE55708@tail-f.com> References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <99D7FCB6-C9A9-4A44-B488-CE4D1C582D66@tail-f.com> <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com> <57892746.5020903@seguesoft.com> <57893742.6040903@seguesoft.com> <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com> <001c01d1e299$e057a910$a106fb30$@seguesoft.com> <6e416198-13bd-81e3-545e-35e8bfc61536@ericsson.com> <005a01d1ebe5$ 6ee080e0$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Netconf Subject: Re: [Netconf] What should a server response be? - depending on NP-containers X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 12:25:44 -0000 --Apple-Mail=_B6CC6AC1-42E3-477D-90E1-2EE7CA2ADE71 Content-Type: multipart/alternative; boundary="Apple-Mail=_08E1BDFE-08B8-4D38-96FF-9339C30234E6" --Apple-Mail=_08E1BDFE-08B8-4D38-96FF-9339C30234E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Certainly unfortunate that even us experts have a hard time interpreting = the old text. Disregarding the text for a moment, what behavior would = make sense; what would be useful? Having two kinds of containers with = different names that behave the same doesn't seem very useful to me. I = know some of you might not agree completely, but it seems I and a lot of = (IETF) modelers are finding containers that just groups things together = logically, but have no information contents in themselves, are useful. = If you look at the IETF models, NP containers are very common. A couple of examples: ietf-interfaces.yang: container interfaces { description "Interface configuration parameters."; ietf-system.yang: container clock { description "Configuration of the system date and time properties."; ietf-ip.yanf: container autoconf { description "Parameters to control the autoconfiguration of IPv6 addresses, as described in RFC 4862."; If we had wanted the "creation" of these containers to really make a = difference, we could have/would have made them P containers, right? I = know the old text may have made it unnecessarily hard to see, but = tracking the creation and deletion of the objects above wouldn't really = get us anything. Provides no value. The existence of these containers = truly has no meaning. This notion is completely natural in the user = interface part of the world (e.g. CLI). You don't put all menu choices = in the same menu or same CLI submode, even though strictly speaking = there is no functional difference where they are located. It's just = makes it easier for people to find the right item without linear search = through everything. This makes NP containers essential when modeling = existing CLI behavior. /jan > On 1 aug. 2016, at 13:10, t.petch wrote: >=20 > ----- Original Message ----- > From: "Balazs Lengyel" > > Sent: Monday, August 01, 2016 9:55 AM >=20 >> Hello, >>=20 >> As I see it: >>=20 >> - The main problem is we don't agree whether or when NP containers > exist. Some people think they should exist (or not) just as any other > data node. (me, Andy, RFC6241) while others believe the existence of = the > NP containers is not even a valid question (tailf). As we have such > basic differences, I propose to focus just on the specific protocol > cases that are problematic. >=20 > Balazs >=20 > As a practical engineer, it is obvious to me that they exist. A > response to a NETCONF 'get' may, or may not, contain them so it = affects > the XML I receive, so they exist, period. When I read that they do = not > convey any information, I surmise that this is a statement from > Information Theory for some meaning of the word Information which = likely > I do not understand. But so what? The specification of Yang says I = may > see them so when I do, I know that they exist. The specification is > also very clear that I cannot rely on seeing them (if no child node > exists); such imprecision may or may not be a good thing in a Standard > but the text is very clear and unambiguous on this point. As ever, = how > a server achieves this is up to the server; what matters is the > appearance presented to the rest of the world, imprecise as it may be. >=20 > Looking back, I read >=20 > 'A distinct container should be used when encoding lists with multiple > instances ...' > 'Some containers exist in the 'real world' and some are only modelling > artefacts.' > 'Use of container elements allows simpler manipulation of lists and = list > members.' >=20 > which, for me, is the rationale for the two types of containers we = have. > A Non-Presence Container makes life simpler for the data modeller and > the user of the data model. >=20 > Tom Petch >=20 >> - IMHO this problem means that the following 3 cases are not properly > defined and we need to clarify them. Saying the client should just not > use major parts of the protocol for NP-containers is wrong. >>=20 >> 1) what happens if default-operation=3Dnone meets a non-existing NP > container >> 2) what happens if you create an NP-container and that already exists > e.g. you issue create twice >> 3) what happens if you delete an NP-container that does not exists > e.g. issue the delete twice >>=20 >> IMHO saying that from the 6 operation values 3 are undefined for > NP-container is not acceptable. >> As we have protocol operations defined in RC6020 we need to define > them properly. >> regards Balazs >>=20 >>=20 >> On 2016-08-01 02:23, Andy Bierman wrote: >>=20 >>=20 >>=20 >>=20 >>=20 >> On Sun, Jul 31, 2016 at 10:45 AM, Mahesh Jethanandani > wrote: >>=20 >>=20 >>=20 >> On Jul 30, 2016, at 5:31 PM, Andy Bierman > wrote: >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On Sat, Jul 30, 2016 at 5:21 PM, Mahesh Jethanandani > wrote: >>=20 >> Andy, >>=20 >>=20 >> The thread started because the RFC does not say anything about > a create of a NP container. It only talked about delete. Can we make = the > (re-)create of the NP container unconditional to whether a delete was > performed on it. So a tweak to your proposal would be: >>=20 >>=20 >>=20 >>=20 >> The only reason that example did not work is because the server > deleted the NP containers >> after the client created them. If the server does not delete > the containers then >> the 2nd RPC will not fail. >>=20 >>=20 >> I think this argument of whether server should or should not > create/delete NP containers is distracting from the main point of when > NP containers should exist. In my mind, the NP container existence > depends on whether child nodes exist or not. In the end, if child = nodes > exist, NP containers should exist (created), if they do not exist, the > NP container should be removed. >>=20 >>=20 >> Can we agree on that? >>=20 >>=20 >>=20 >>=20 >> No. >>=20 >>=20 >> "should be removed" is an implementation choice. >> It started as MAY be removed. It needs to stay that way. >>=20 >>=20 >> As I have pointed out 100 times, the protocol has merge and replace >> for the situation where the client is not exactly aware of how > ceration and >> deletion will be handled on the server. >>=20 >>=20 >> There is no reason to force implementations to change. >> If you magically delete containers, then magically recreate them. >> If you don't then the nodes will be as the client expects, so no > problem. >>=20 >>=20 >>=20 >>=20 >> Andy >>=20 >>=20 >>=20 >>=20 >> P.s The errata will be much easier to craft if we can agree on > this. >>=20 >>=20 >>=20 >>=20 >> This can also be completely avoided by using the default > (merge). >> Since the client has to explicitly pick default-operation=3Dnone, >> it better know what it is doing. >> This is the same issue as a default leaf >> and the create operation. Nothing special about NP containers. >>=20 >>=20 >> The for "create" will fail if the leaf already > exists >> and the "delete" will fail if the value is not there (just a > default). >> The work-around? Use merge and remove, not create and delete. >> IMO the same logic applies here. >>=20 >>=20 >>=20 >>=20 >> Andy >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> OLD: >>=20 >>=20 >> If a container does not have a "presence" statement and the > last >> child node is deleted, the NETCONF server MAY delete the > container. >>=20 >>=20 >> NEW: >>=20 >>=20 >> If a container does not have a "presence" statement and the > container instance >> does not have any child node instances, the NETCONF server > MAY delete the >> container. It MUST create the container instance if a > client request >> attempts to create a child node instance within this > container. >>=20 >>=20 >>=20 >>=20 >> On Jul 30, 2016, at 11:52 AM, Andy Bierman > wrote: >>=20 >>=20 >> Hi, >>=20 >>=20 >> I strongly object to changing a vague MAY about deleting an > NP container >> after the last child has been deleted into several MUST > requirements. >>=20 >>=20 >> I propose this text instead: >>=20 >>=20 >> OLD: >>=20 >>=20 >>=20 >>=20 >> If a container does not have a "presence" statement and > the last >> child node is deleted, the NETCONF server MAY delete the > container. >>=20 >>=20 >>=20 >>=20 >> NEW: >>=20 >>=20 >>=20 >>=20 >> If a container does not have a "presence" statement and > the container instance >> does not have any child node instances, the NETCONF > server MAY delete the >> container. If the server does delete a container instance > in this case, it MUST >> re-create the container instance if a client > request attempts to create >> a child node instance within this container. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Andy >>=20 >>=20 >>=20 >>=20 >> On Fri, Jul 22, 2016 at 3:13 AM, Balazs Lengyel > wrote: >>=20 >> Hello, >>=20 >>=20 >> We seem to have fundamental differences whether > NP-containers exist/don't exist or if this question is even valid. I > hope we can agree that as NP-containers are meaningless themselves = they > MUST NOT influence Netconf operations or model validation. (Which is a > slight violation of Netconf-6241, which we should accept.) >>=20 >>=20 >> So I propose the following errata to rfc6020bis. >>=20 >> As for non-presence containers the presence of the > container node with no child nodes is >> semantically equivalent to the absence of the container > node, configuration operations or >> model validation should never fail due to the existence or > non-existence of a non-presence containers. Specifically: >>=20 >> - an create operation for a non-presence > container MUST succeed even if the container already exists. >> - an delete operation for a non-presence > container MUST succeed even if the container does not exist. >> - an operation with default-operation=3Dnone > MUST succeed even if one or more non-presence containers do not = exist. >>=20 >>=20 >> Separately >> - a must statement defined as direct substatement of a > non-presence container SHALL be evaluated as part of model validation = if > and only if one or more child data nodes exist in the instance data or > if there is a leaf or leaf-list child with a default value. As > non-presence containers are only used for organizing the hierarchy = they > SHOULD NOT have any must substatements. >>=20 >> IMO the above rules remove ambiguity and follow the > current philosophy of RFC6020bis. >> If we have a basic agreement I can formulate the text > correctly. >>=20 >> I don't know whether similar updates are needed for > RestConf. >> regards Balazs >>=20 >> PS. I still believe introducing NP containers was a > mistake, however they are here to stay. >>=20 >>=20 >> On 2016-07-21 09:17, Jan Lindblad wrote: >>=20 >> Xiang, >>=20 >>=20 >> Are you saying that since a NP-container is merely a > structure node, not config in any way, so creating/deleting it > explicitly (and repeatedly) is equivalent to a =C3=A2=E2=82=AC=C5=93no-o= p=C3=A2=E2=82=AC=C2=9D that will > always succeed because doing so has no effect on the server=C3=A2=E2=82=AC= =E2=84=A2s config > in any way? >>=20 >>=20 >> That's correct. "Creating" an object with zero bits of > information is a no-op. >>=20 >>=20 >> If the sever has the following example config: >> >> >> >>=20 >>=20 >> If a client issues an edit-config with: >> < mycontainer operation=3D"delete"> >>=20 >> The server returns =C3=A2=E2=82=AC=C5=93ok=C3=A2=E2=82=AC= =C2=9D, >>=20 >> If then again the client attempts: >>=20 >> < mycontainer operation=3D"delete"> >>=20 >> The server should still return =C3=A2=E2=82=AC=C5=93ok=C3= =A2=E2=82=AC=C2=9D? >>=20 >>=20 >> Yes, that's correct in my opinion. It's a consequence of > the NP container nature as defined in the current RFC6020/YANG 1.0 and > bis. >>=20 >> If so I think this is confusing. I think it would make > more sense in the latter case if the server returns = =C3=A2=E2=82=AC=C5=93"data-missing=C3=A2=E2=82=AC=C2=9D > error. >>=20 >>=20 >> This is logical if you think of NP containers as path > prefixes, and not as objects with information content. If you accept > that an NP container has zero bits of information, how would the = server > even know whether the container exists or not? Not by looking in a > database, for sure. >>=20 >>=20 >> P containers have a single bit of information, so they > can be created, and the creation event/existence remembered by the > server. Not so for NP-containers. >>=20 >>=20 >> I understand we may advise a client not do so, but > since RFC6020bis does not forbid this, and it is also a perfectly = valid > , so I am sure people will try it. >>=20 >>=20 >> Yes. And it works today and is harmless. >>=20 >>=20 >> It's unfortunate that the YANG 1.0 and 1.1 specs aren't > crystal clear on the subject, but I believe the interpretation I and > others have of NP container behavior in RFC 6020 is consistent, > implementable and highly useful. >>=20 >>=20 >> /jan >>=20 >>=20 >>=20 >>=20 >> -- >> Balazs Lengyel Ericsson Hungary Ltd. >> Senior Specialist >> Mobile: +36-70-330-7909 email: > Balazs.Lengyel@ericsson.com >>=20 >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >>=20 >>=20 >>=20 >> Mahesh Jethanandani >> mjethanandani@gmail.com >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> -- >> Balazs Lengyel Ericsson Hungary Ltd. >> Senior Specialist >> Mobile: +36-70-330-7909 email: > Balazs.Lengyel@ericsson.com >>=20 >=20 >=20 > = ------------------------------------------------------------------------ > -------- >=20 >=20 >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf = >>=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf = --Apple-Mail=_08E1BDFE-08B8-4D38-96FF-9339C30234E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Certainly unfortunate that even us experts = have a hard time interpreting the old text. Disregarding the text for a = moment, what behavior would make sense; what would be useful? Having two = kinds of containers with different names that behave the same doesn't = seem very useful to me. I know some of you might not agree completely, = but it seems I and a lot of (IETF) modelers are finding containers that = just groups things together logically, but have no information contents = in themselves, are useful. If you look at the IETF models, NP containers = are very common.

A couple of examples:

ietf-interfaces.yang:
  container interfaces {
  =   description
    =   "Interface configuration parameters.";

ietf-system.yang:
    container clock {
  =     description
      =   "Configuration of the system date and time properties.";

ietf-ip.yanf:
     container autoconf {
       description
  =        "Parameters to control the autoconfiguration = of IPv6
          addresses, = as described in RFC 4862.";

If we had wanted the "creation" of these containers to really = make a difference, we could have/would have made them P containers, = right? I know the old text may have made it unnecessarily hard to see, = but tracking the creation and deletion of the objects above wouldn't = really get us anything. Provides no value. The existence of these = containers truly has no meaning. This notion is completely natural in = the user interface part of the world (e.g. CLI). You don't put all menu = choices in the same menu or same CLI submode, even though strictly = speaking there is no functional difference where they are located. It's = just makes it easier for people to find the right item without linear = search through everything. This makes NP containers essential when = modeling existing CLI behavior.

/jan



On 1 aug. 2016, at 13:10, t.petch <ietfc@btconnect.com>= wrote:

----- Original Message -----
From: "Balazs Lengyel" <balazs.lengyel@ericsson.com>
Sent: Monday, August 01, 2016 9:55 AM

Hello,

As I see it:

- The main problem = is we don't agree whether or when NP containers
exist. Some people think = they should exist (or not) just as any other
data node. (me, Andy, RFC6241) while others = believe the existence of the
NP containers  is not even a valid question = (tailf). As we have such
basic differences, I propose to focus just on = the specific protocol
cases that are = problematic.

Balazs

As a practical engineer, it is obvious to me = that they exist.   A
response to a NETCONF 'get' may, or may not, = contain them so it affects
the XML I receive, so they exist, period. =  When I read that they do not
convey any information, I surmise that this is a = statement from
Information Theory for some = meaning of the word Information which likely
I do not understand.  But so what? The = specification of Yang says I may
see them so when I do, I know that they exist. =  The specification is
also very clear that I cannot rely on seeing = them (if no child node
exists); such imprecision may or may not be a = good thing in a Standard
but the text is very clear and unambiguous on = this point.  As ever, how
a server achieves this is up to the server; what = matters is the
appearance presented to the rest = of the world, imprecise as it may be.

Looking back, I read

'A distinct container should be used when = encoding lists with multiple
instances ...'
'Some containers exist in the 'real world' and = some are only modelling
artefacts.'
'Use of container elements allows simpler = manipulation of lists and list
members.'

which, for me, is the rationale for the two = types of containers we have.
A Non-Presence Container makes life simpler for = the data modeller and
the user of the data = model.

Tom Petch

- IMHO this problem = means that the following 3 cases are not properly
defined and we need to = clarify them. Saying the client should just not
use major parts of the protocol for = NP-containers is wrong.

1) what = happens if default-operation=3Dnone meets a non-existing NP
container
2) what happens if you = create an NP-container and that already exists
e.g. you issue create = twice
3) what happens if you = delete an NP-container that does not exists
e.g. issue the delete = twice

IMHO saying = that from the 6 operation values 3 are undefined for
NP-container is not = acceptable.
As we have protocol = operations defined in RC6020 we need to define
them properly.
regards Balazs


On 2016-08-01 02:23, Andy = Bierman wrote:





 On Sun, Jul 31, 2016 at = 10:45 AM, Mahesh Jethanandani
<mjethanandani@gmail.com> wrote:



   On Jul 30, 2016, at 5:31 PM, = Andy Bierman <andy@yumaworks.com>
wrote:






     On Sat, Jul 30, 2016 at 5:21 = PM, Mahesh Jethanandani
<mjethanandani@gmail.com> wrote:

       Andy,


       The thread started = because the RFC does not say anything about
a create of a NP = container. It only talked about delete. Can we make the
(re-)create of the NP container unconditional to = whether a delete was
performed on it. So a tweak to = your proposal would be:




     The= only reason that example did not work is because the server
deleted the NP = containers
     after the client created them. =  If the server does not delete
the containers then
     the 2nd RPC will not fail.


   I think this = argument of whether server should or should not
create/delete NP = containers is distracting from the main point of when
NP containers should exist. In my mind, the NP = container existence
depends on whether child nodes = exist or not. In the end, if child nodes
exist, NP containers should exist (created), if = they do not exist, the
NP container should be removed.


   Can we agree on that?




 No.


 "should be removed" is an = implementation choice.
 It started as MAY be removed. =  It needs to stay that way.


 As I have pointed out 100 times,  the protocol has = merge and replace
 for the situation where the client = is not exactly aware of how
ceration and
 deletion will be = handled on the server.


 There is no reason to force implementations to = change.
 If you magically delete containers, then = magically recreate them.
 If you don't then the nodes = will be as the client expects, so no
problem.




 Andy




   P.s The errata will be much easier to craft = if we can agree on
this.




     This can also be completely = avoided by using the default
(merge).
     Since the client has to = explicitly pick default-operation=3Dnone,
     it better know what it is = doing.
     This is the same = issue as a default leaf
     and = the create operation.  Nothing special about NP containers.


     The= <edit-config> for "create" will fail if the leaf already
exists
     and the "delete" will fail if = the value is not there (just a
default).
     The work-around?  Use = merge and remove, not create and delete.
     IMO the same logic applies = here.




     Andy







       OLD:


          If = a container does not have a "presence" statement and the
last
          chi= ld node is deleted, the NETCONF server MAY delete the
container.


       NEW:


          If = a container does not have a "presence" statement and the
container = instance
          doe= s not have any child node instances, the NETCONF server
MAY delete the
          con= tainer. It MUST create the container instance if a
client <edit-config> = request
          att= empts to create a child node instance within this
container.




         On Jul = 30, 2016, at 11:52 AM, Andy Bierman
<andy@yumaworks.com> wrote:


         Hi,


         I = strongly object to changing a vague MAY about deleting an
NP container
         after = the last child has been deleted into several MUST
requirements.


         I = propose this text instead:


         OLD:




          &nb= sp; If a container does not have a "presence" statement and
the last
          &nb= sp; child node is deleted, the NETCONF server MAY delete the
container.




         NEW:




          &nb= sp; If a container does not have a "presence" statement and
the container = instance
          &nb= sp; does not have any child node instances, the NETCONF
server MAY delete = the
          &nb= sp; container. If the server does delete a container instance
in this case, it = MUST
          &nb= sp; re-create the container instance if a client
<edit-config> = request attempts to create
          &nb= sp; a child node instance within this container.







         Andy




         On Fri, = Jul 22, 2016 at 3:13 AM, Balazs Lengyel
<balazs.lengyel@ericsson.com> wrote:

          &nb= sp;Hello,


          &nb= sp;We seem to have fundamental differences whether
NP-containers exist/don't = exist or if this question is even valid.  I
hope we can agree that as NP-containers are = meaningless themselves they
MUST NOT influence Netconf operations or model = validation. (Which is a
slight violation of Netconf-6241, which we = should accept.)


          &nb= sp;So I propose the following errata to rfc6020bis.

          &nb= sp;As for non-presence containers the presence of the
container node with no = child nodes is
          &nb= sp;semantically equivalent to the absence of the container
node, configuration = operations or
          &nb= sp;model validation should never fail due to the existence or
non-existence of a = non-presence containers. Specifically:

          &nb= sp;- an <edit-config>  create operation for a non-presence
container MUST succeed = even if the container already exists.
          &nb= sp;- an <edit-config>  delete operation for a non-presence
container MUST succeed = even if the container does not exist.
          &nb= sp;- an <edit-config>  operation with = default-operation=3Dnone
MUST succeed even if one or more =  non-presence containers do not exist.


          &nb= sp;Separately
          &nb= sp;- a must statement defined as direct substatement of a
non-presence container = SHALL be evaluated as part of model validation if
and only if one or more child data nodes exist = in the instance data or
if there is a leaf or leaf-list child with a = default value. As
non-presence containers are only = used for organizing the hierarchy they
SHOULD NOT have any must = substatements.

          &nb= sp;IMO the above rules remove ambiguity and follow the
current philosophy of =  RFC6020bis.
          &nb= sp;If we have a basic agreement I can formulate the text
correctly.

          &nb= sp;I don't know whether similar updates are needed for
RestConf.
          &nb= sp;regards Balazs

          &nb= sp;PS. I still believe introducing NP containers was a
mistake, however they are = here to stay.


          &nb= sp;On 2016-07-21 09:17, Jan Lindblad wrote:

          &nb= sp;  Xiang,


          &nb= sp;    Are you saying that since a NP-container is = merely a
structure node, not config in any way, so = creating/deleting it
explicitly (and repeatedly) is = equivalent to a =C3=A2=E2=82=AC=C5=93no-op=C3=A2=E2=82=AC=C2=9D that = will
always succeed because doing so has no effect on = the server=C3=A2=E2=82=AC=E2=84=A2s config
in any way?


          &nb= sp;  That's correct. "Creating" an object with zero bits of
information is a = no-op.


          &nb= sp;    If the sever has the following example = config:
          &nb= sp;    <mycontainer>
          &nb= sp;         <child =  ... bla..bla=C3=A2=E2=82=AC=C2=A6configs>
          &nb= sp;    </mycontainer>


          &nb= sp;    If a client issues an edit-config with:
          &nb= sp;    < mycontainer operation=3D"delete">

          &nb= sp;    The server returns =C3=A2=E2=82=AC=C5=93ok=C3=A2= =E2=82=AC=C2=9D,

          &nb= sp;    If then again  the client attempts:

          &nb= sp;    < mycontainer operation=3D"delete">

          &nb= sp;    The server should still return =  =C3=A2=E2=82=AC=C5=93ok=C3=A2=E2=82=AC=C2=9D?


          &nb= sp;  Yes, that's correct in my opinion. It's a consequence = of
the NP container nature as defined in the = current RFC6020/YANG 1.0 and
bis.

          &nb= sp;    If so I think this is confusing. I think it = would make
more sense in the latter case if the server = returns =C3=A2=E2=82=AC=C5=93"data-missing=C3=A2=E2=82=AC=C2=9D
error.


          &nb= sp;  This is logical if you think of NP containers as path
prefixes, and not as = objects with information content. If you accept
that an NP container has zero bits of = information, how would the server
even know whether the container exists or not? = Not by looking in a
database, for sure.


          &nb= sp;  P containers have a single bit of information, so they
can be created, and the = creation event/existence remembered by the
server. Not so for NP-containers.


          &nb= sp;    I understand we may advise a client not do = so, but
since  RFC6020bis does not forbid this, and = it is also a perfectly valid
<edit-config>, so I am sure people will = try it.


          &nb= sp;  Yes. And it works today and is harmless.


          &nb= sp;  It's unfortunate that the YANG 1.0 and 1.1 specs = aren't
crystal clear on the subject, but I believe the = interpretation I and
others have of NP container = behavior in RFC 6020 is consistent,
implementable and highly useful.


          &nb= sp;  /jan




--
Balazs Lengyel =             &n= bsp;         Ericsson = Hungary Ltd.
Senior Specialist
Mobile: = +36-70-330-7909 =             &n= bsp;email:
Balazs.Lengyel@ericsson.com

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




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



       Mahesh = Jethanandani
       mjethanandani@gmail.com














--
Balazs Lengyel =             &n= bsp;         Ericsson = Hungary Ltd.
Senior Specialist
Mobile: = +36-70-330-7909 =             &n= bsp;email:
Balazs.Lengyel@ericsson.com



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


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


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

= --Apple-Mail=_08E1BDFE-08B8-4D38-96FF-9339C30234E6-- --Apple-Mail=_B6CC6AC1-42E3-477D-90E1-2EE7CA2ADE71 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXnz3lAAoJEBSCnbqufIisj1MH/ioHHfAiPcWb+G0+ujx5Myn6 dKT36k7JK44AuVSAnjbN9a0xHBWHN2R7Xtk4gCOm2tlriKJgczHYKoTUXpaUS8wi 3t2PxobxKqlxA/Lst2HKXhBytGoJlELipJkWlZYYhVhcJ0PTK+vyq/8SW/QWISQQ wxfjNVw938g64lJCGL+0N0HsuBePaoDAwzHt+6TF7rbUUBSp2nHKTa3RkvA/ou1n XHvOG8ICdJ/fydWbvHkSw12TZ40q1d8QzPs3apkk3ts2+/o/PvuauTYqNWYyzqIy eTdlyPu6Z265/Fr2OqA4Pj30svDGprwFpUVAk6kFbltwKX6rDrEA7pxXBEx+/O8= =g2FY -----END PGP SIGNATURE----- --Apple-Mail=_B6CC6AC1-42E3-477D-90E1-2EE7CA2ADE71-- From nobody Mon Aug 1 06:42:19 2016 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E735812DC8B for ; Mon, 1 Aug 2016 06:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.788 X-Spam-Level: X-Spam-Status: No, score=-15.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eTXb2xkLdE4 for ; Mon, 1 Aug 2016 06:42:12 -0700 (PDT) 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 BE80612DCD6 for ; Mon, 1 Aug 2016 06:31:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36984; q=dns/txt; s=iport; t=1470058274; x=1471267874; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=Rst0LzMLpYvTuU1g95Ig1xq2yEIcYtR2ruplTGJwKro=; b=Iqcdi2l5uVcVXPBTvlwCbe5p45PRv3ngUvt7dECgejbQ9qDdo0rYDdNU lC0Gt0wDY+MpPhoInKspkBgwiPknTqP4Z6jHCGnx7Y3bNgtK3+4iTchz3 clV8X41rUbyO4YUtsPQaj06fgWELcxhO8lXxYVZDM+IYLGJfDzgyRMO/Y I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C3CAB0Tp9X/xbLJq1dhBsqA0+sb4wkg?= =?us-ascii?q?X0mhS1KAoFlFAEBAQEBAQFdJ0EOAYQOAQEFAQEYCUsXBAkCFQECIAEJAgIhBjA?= =?us-ascii?q?GAQwGAgEBFQKFd4IFAxcOkzOdIIs+DYQUAQEBAQEBAQEBAQEBAQEBAQEBAQEBF?= =?us-ascii?q?wWGKoF4CIJNgkOBTQIRAQaDF4JaBYgki0yFDzSGGIYygjWBa4doI4VJiCs9g0i?= =?us-ascii?q?Ddx42ghIcgU07MgEBhBGCPQINFweBGAEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,455,1464652800"; d="scan'208,217";a="680399644" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Aug 2016 13:31:12 +0000 Received: from [10.63.23.91] (dhcp-ensft1-uk-vla370-10-63-23-91.cisco.com [10.63.23.91]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u71DVBjl003185; Mon, 1 Aug 2016 13:31:11 GMT To: "t.petch" , Andy Bierman , Mahesh Jethanandani , Balazs Lengyel , Netconf References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com> <57892746.5020903@seguesoft.com> <57893742.6040903@seguesoft.com> <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com> <001c01d1e299$e057a910$a106fb30$@seguesoft.com> <6e416198-13bd-81e3-545e-35e8bfc61536@ericsson.com> <005a01d1ebe5$6ee080e0$4001a8c0@gateway.2wire.net> From: Robert Wilton Message-ID: Date: Mon, 1 Aug 2016 14:31:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <005a01d1ebe5$6ee080e0$4001a8c0@gateway.2wire.net> Content-Type: multipart/alternative; boundary="------------09F3BA9F50AE118DA7123D2D" Archived-At: Subject: Re: [Netconf] What should a server response be? - depending on NP-containers X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 13:42:17 -0000 This is a multi-part message in MIME format. --------------09F3BA9F50AE118DA7123D2D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, My interpretation is that NP containers only exist to give structure to any nodes that exist below them and their existence is not intended to impart any meaning beyond this. The solution I would like to see is to maximize interoperability between NETCONF client and server implementations. So suggest that: 1) We clarify the text for "rfc6020bis-14#section-7.5.8 " to make it clear that a server may delete an empty NP container at any time (rather than explicitly only when the last child element is deleted). I.e. I propose the following change to 6020bis: OLD: "If a container does not have a "presence" statement and the last child node is deleted, the NETCONF server MAY delete the container." NEW: "If a container does not have a "presence" statement and has no child nodes, then the NETCONF server MAY delete the container." 2) An errata to rfc6241 that, for the purpose of maximizing interoperability, recommends: (i) Clients should use merge/replace/remove operations for np container nodes. (ii) Servers should avoid erroring on a create/delete/none operation on an np container node. Thanks, Rob On 01/08/2016 12:10, t.petch wrote: > ----- Original Message ----- > From: "Balazs Lengyel" > Sent: Monday, August 01, 2016 9:55 AM > >> Hello, >> >> As I see it: >> >> - The main problem is we don't agree whether or when NP containers > exist. Some people think they should exist (or not) just as any other > data node. (me, Andy, RFC6241) while others believe the existence of the > NP containers is not even a valid question (tailf). As we have such > basic differences, I propose to focus just on the specific protocol > cases that are problematic. > > Balazs > > As a practical engineer, it is obvious to me that they exist. A > response to a NETCONF 'get' may, or may not, contain them so it affects > the XML I receive, so they exist, period. When I read that they do not > convey any information, I surmise that this is a statement from > Information Theory for some meaning of the word Information which likely > I do not understand. But so what? The specification of Yang says I may > see them so when I do, I know that they exist. The specification is > also very clear that I cannot rely on seeing them (if no child node > exists); such imprecision may or may not be a good thing in a Standard > but the text is very clear and unambiguous on this point. As ever, how > a server achieves this is up to the server; what matters is the > appearance presented to the rest of the world, imprecise as it may be. > > Looking back, I read > > 'A distinct container should be used when encoding lists with multiple > instances ...' > 'Some containers exist in the 'real world' and some are only modelling > artefacts.' > 'Use of container elements allows simpler manipulation of lists and list > members.' > > which, for me, is the rationale for the two types of containers we have. > A Non-Presence Container makes life simpler for the data modeller and > the user of the data model. > > Tom Petch > >> - IMHO this problem means that the following 3 cases are not properly > defined and we need to clarify them. Saying the client should just not > use major parts of the protocol for NP-containers is wrong. >> 1) what happens if default-operation=none meets a non-existing NP > container >> 2) what happens if you create an NP-container and that already exists > e.g. you issue create twice >> 3) what happens if you delete an NP-container that does not exists > e.g. issue the delete twice >> IMHO saying that from the 6 operation values 3 are undefined for > NP-container is not acceptable. >> As we have protocol operations defined in RC6020 we need to define > them properly. >> regards Balazs >> >> >> On 2016-08-01 02:23, Andy Bierman wrote: >> >> >> >> >> >> On Sun, Jul 31, 2016 at 10:45 AM, Mahesh Jethanandani > wrote: >> >> >> On Jul 30, 2016, at 5:31 PM, Andy Bierman > wrote: >> >> >> >> >> >> On Sat, Jul 30, 2016 at 5:21 PM, Mahesh Jethanandani > wrote: >> Andy, >> >> >> The thread started because the RFC does not say anything about > a create of a NP container. It only talked about delete. Can we make the > (re-)create of the NP container unconditional to whether a delete was > performed on it. So a tweak to your proposal would be: >> >> >> >> The only reason that example did not work is because the server > deleted the NP containers >> after the client created them. If the server does not delete > the containers then >> the 2nd RPC will not fail. >> >> >> I think this argument of whether server should or should not > create/delete NP containers is distracting from the main point of when > NP containers should exist. In my mind, the NP container existence > depends on whether child nodes exist or not. In the end, if child nodes > exist, NP containers should exist (created), if they do not exist, the > NP container should be removed. >> >> Can we agree on that? >> >> >> >> >> No. >> >> >> "should be removed" is an implementation choice. >> It started as MAY be removed. It needs to stay that way. >> >> >> As I have pointed out 100 times, the protocol has merge and replace >> for the situation where the client is not exactly aware of how > ceration and >> deletion will be handled on the server. >> >> >> There is no reason to force implementations to change. >> If you magically delete containers, then magically recreate them. >> If you don't then the nodes will be as the client expects, so no > problem. >> >> >> >> Andy >> >> >> >> >> P.s The errata will be much easier to craft if we can agree on > this. >> >> >> >> This can also be completely avoided by using the default > (merge). >> Since the client has to explicitly pick default-operation=none, >> it better know what it is doing. >> This is the same issue as a default leaf >> and the create operation. Nothing special about NP containers. >> >> >> The for "create" will fail if the leaf already > exists >> and the "delete" will fail if the value is not there (just a > default). >> The work-around? Use merge and remove, not create and delete. >> IMO the same logic applies here. >> >> >> >> >> Andy >> >> >> >> >> >> >> >> >> OLD: >> >> >> If a container does not have a "presence" statement and the > last >> child node is deleted, the NETCONF server MAY delete the > container. >> >> NEW: >> >> >> If a container does not have a "presence" statement and the > container instance >> does not have any child node instances, the NETCONF server > MAY delete the >> container. It MUST create the container instance if a > client request >> attempts to create a child node instance within this > container. >> >> >> >> On Jul 30, 2016, at 11:52 AM, Andy Bierman > wrote: >> >> Hi, >> >> >> I strongly object to changing a vague MAY about deleting an > NP container >> after the last child has been deleted into several MUST > requirements. >> >> I propose this text instead: >> >> >> OLD: >> >> >> >> >> If a container does not have a "presence" statement and > the last >> child node is deleted, the NETCONF server MAY delete the > container. >> >> >> >> NEW: >> >> >> >> >> If a container does not have a "presence" statement and > the container instance >> does not have any child node instances, the NETCONF > server MAY delete the >> container. If the server does delete a container instance > in this case, it MUST >> re-create the container instance if a client > request attempts to create >> a child node instance within this container. >> >> >> >> >> >> >> >> >> Andy >> >> >> >> >> On Fri, Jul 22, 2016 at 3:13 AM, Balazs Lengyel > wrote: >> Hello, >> >> >> We seem to have fundamental differences whether > NP-containers exist/don't exist or if this question is even valid. I > hope we can agree that as NP-containers are meaningless themselves they > MUST NOT influence Netconf operations or model validation. (Which is a > slight violation of Netconf-6241, which we should accept.) >> >> So I propose the following errata to rfc6020bis. >> >> As for non-presence containers the presence of the > container node with no child nodes is >> semantically equivalent to the absence of the container > node, configuration operations or >> model validation should never fail due to the existence or > non-existence of a non-presence containers. Specifically: >> - an create operation for a non-presence > container MUST succeed even if the container already exists. >> - an delete operation for a non-presence > container MUST succeed even if the container does not exist. >> - an operation with default-operation=none > MUST succeed even if one or more non-presence containers do not exist. >> >> Separately >> - a must statement defined as direct substatement of a > non-presence container SHALL be evaluated as part of model validation if > and only if one or more child data nodes exist in the instance data or > if there is a leaf or leaf-list child with a default value. As > non-presence containers are only used for organizing the hierarchy they > SHOULD NOT have any must substatements. >> IMO the above rules remove ambiguity and follow the > current philosophy of RFC6020bis. >> If we have a basic agreement I can formulate the text > correctly. >> I don't know whether similar updates are needed for > RestConf. >> regards Balazs >> >> PS. I still believe introducing NP containers was a > mistake, however they are here to stay. >> >> On 2016-07-21 09:17, Jan Lindblad wrote: >> >> Xiang, >> >> >> Are you saying that since a NP-container is merely a > structure node, not config in any way, so creating/deleting it > explicitly (and repeatedly) is equivalent to a “no-op” that will > always succeed because doing so has no effect on the server’s config > in any way? >> >> That's correct. "Creating" an object with zero bits of > information is a no-op. >> >> If the sever has the following example config: >> >> >> >> >> >> If a client issues an edit-config with: >> < mycontainer operation="delete"> >> >> The server returns “ok”, >> >> If then again the client attempts: >> >> < mycontainer operation="delete"> >> >> The server should still return “ok”? >> >> >> Yes, that's correct in my opinion. It's a consequence of > the NP container nature as defined in the current RFC6020/YANG 1.0 and > bis. >> If so I think this is confusing. I think it would make > more sense in the latter case if the server returns “"data-missing” > error. >> >> This is logical if you think of NP containers as path > prefixes, and not as objects with information content. If you accept > that an NP container has zero bits of information, how would the server > even know whether the container exists or not? Not by looking in a > database, for sure. >> >> P containers have a single bit of information, so they > can be created, and the creation event/existence remembered by the > server. Not so for NP-containers. >> >> I understand we may advise a client not do so, but > since RFC6020bis does not forbid this, and it is also a perfectly valid > , so I am sure people will try it. >> >> Yes. And it works today and is harmless. >> >> >> It's unfortunate that the YANG 1.0 and 1.1 specs aren't > crystal clear on the subject, but I believe the interpretation I and > others have of NP container behavior in RFC 6020 is consistent, > implementable and highly useful. >> >> /jan >> >> >> >> >> -- >> Balazs Lengyel Ericsson Hungary Ltd. >> Senior Specialist >> Mobile: +36-70-330-7909 email: > Balazs.Lengyel@ericsson.com >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> >> >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> >> >> >> Mahesh Jethanandani >> mjethanandani@gmail.com >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> Balazs Lengyel Ericsson Hungary Ltd. >> Senior Specialist >> Mobile: +36-70-330-7909 email: > Balazs.Lengyel@ericsson.com > > ------------------------------------------------------------------------ > -------- > > >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --------------09F3BA9F50AE118DA7123D2D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi,

My interpretation is that NP containers only exist to give structure to any nodes that exist below them and their existence is not intended to impart any meaning beyond this.

The solution I would like to see is to maximize interoperability between NETCONF client and server implementations.  So suggest that:

1) We clarify the text for "rfc6020bis-14#section-7.5.8" to make it clear that a server may delete an empty NP container at any time (rather than explicitly only when the last child element is deleted).  I.e. I propose the following change to 6020bis:

OLD:
"If a container does not have a "presence" statement and the last
   child node is deleted, the NETCONF server MAY delete the container."

NEW:
"If a container does not have a "presence" statement and has no
  child nodes, then the NETCONF server MAY delete the container."

2) An errata to rfc6241 that, for the purpose of maximizing interoperability, recommends:
 (i) Clients should use merge/replace/remove operations for np container nodes.
 (ii) Servers should avoid erroring on a create/delete/none operation on an np container node.

Thanks,
Rob


On 01/08/2016 12:10, t.petch wrote:
----- Original Message -----
From: "Balazs Lengyel" <balazs.lengyel@ericsson.com>
Sent: Monday, August 01, 2016 9:55 AM


Hello,

As I see it:

- The main problem is we don't agree whether or when NP containers

exist. Some people think they should exist (or not) just as any other
data node. (me, Andy, RFC6241) while others believe the existence of the
NP containers  is not even a valid question (tailf). As we have such
basic differences, I propose to focus just on the specific protocol
cases that are problematic.

Balazs

As a practical engineer, it is obvious to me that they exist.   A
response to a NETCONF 'get' may, or may not, contain them so it affects
the XML I receive, so they exist, period.  When I read that they do not
convey any information, I surmise that this is a statement from
Information Theory for some meaning of the word Information which likely
I do not understand.  But so what? The specification of Yang says I may
see them so when I do, I know that they exist.  The specification is
also very clear that I cannot rely on seeing them (if no child node
exists); such imprecision may or may not be a good thing in a Standard
but the text is very clear and unambiguous on this point.  As ever, how
a server achieves this is up to the server; what matters is the
appearance presented to the rest of the world, imprecise as it may be.

Looking back, I read

'A distinct container should be used when encoding lists with multiple
instances ...'
'Some containers exist in the 'real world' and some are only modelling
artefacts.'
'Use of container elements allows simpler manipulation of lists and list
members.'

which, for me, is the rationale for the two types of containers we have.
A Non-Presence Container makes life simpler for the data modeller and
the user of the data model.

Tom Petch


- IMHO this problem means that the following 3 cases are not properly

defined and we need to clarify them. Saying the client should just not
use major parts of the protocol for NP-containers is wrong.

1) what happens if default-operation=none meets a non-existing NP

container

2) what happens if you create an NP-container and that already exists

e.g. you issue create twice

3) what happens if you delete an NP-container that does not exists

e.g. issue the delete twice

IMHO saying that from the 6 operation values 3 are undefined for

NP-container is not acceptable.

As we have protocol operations defined in RC6020 we need to define

them properly.

regards Balazs


On 2016-08-01 02:23, Andy Bierman wrote:





  On Sun, Jul 31, 2016 at 10:45 AM, Mahesh Jethanandani

<mjethanandani@gmail.com> wrote:



    On Jul 30, 2016, at 5:31 PM, Andy Bierman <andy@yumaworks.com>

wrote:






      On Sat, Jul 30, 2016 at 5:21 PM, Mahesh Jethanandani

<mjethanandani@gmail.com> wrote:

        Andy,


        The thread started because the RFC does not say anything about

a create of a NP container. It only talked about delete. Can we make the
(re-)create of the NP container unconditional to whether a delete was
performed on it. So a tweak to your proposal would be:




      The only reason that example did not work is because the server

deleted the NP containers

      after the client created them.  If the server does not delete

the containers then

      the 2nd RPC will not fail.


    I think this argument of whether server should or should not

create/delete NP containers is distracting from the main point of when
NP containers should exist. In my mind, the NP container existence
depends on whether child nodes exist or not. In the end, if child nodes
exist, NP containers should exist (created), if they do not exist, the
NP container should be removed.


    Can we agree on that?




  No.


  "should be removed" is an implementation choice.
  It started as MAY be removed.  It needs to stay that way.


  As I have pointed out 100 times,  the protocol has merge and replace
  for the situation where the client is not exactly aware of how

ceration and

  deletion will be handled on the server.


  There is no reason to force implementations to change.
  If you magically delete containers, then magically recreate them.
  If you don't then the nodes will be as the client expects, so no

problem.




  Andy




    P.s The errata will be much easier to craft if we can agree on

this.




      This can also be completely avoided by using the default

(merge).

      Since the client has to explicitly pick default-operation=none,
      it better know what it is doing.
      This is the same issue as a default leaf
      and the create operation.  Nothing special about NP containers.


      The <edit-config> for "create" will fail if the leaf already

exists

      and the "delete" will fail if the value is not there (just a

default).

      The work-around?  Use merge and remove, not create and delete.
      IMO the same logic applies here.




      Andy








        OLD:


           If a container does not have a "presence" statement and the

last

           child node is deleted, the NETCONF server MAY delete the

container.


        NEW:


           If a container does not have a "presence" statement and the

container instance

           does not have any child node instances, the NETCONF server

MAY delete the

           container. It MUST create the container instance if a

client <edit-config> request

           attempts to create a child node instance within this

container.




          On Jul 30, 2016, at 11:52 AM, Andy Bierman

<andy@yumaworks.com> wrote:


          Hi,


          I strongly object to changing a vague MAY about deleting an

NP container

          after the last child has been deleted into several MUST

requirements.


          I propose this text instead:


          OLD:




             If a container does not have a "presence" statement and

the last

             child node is deleted, the NETCONF server MAY delete the

container.




          NEW:




             If a container does not have a "presence" statement and

the container instance

             does not have any child node instances, the NETCONF

server MAY delete the

             container. If the server does delete a container instance

in this case, it MUST

             re-create the container instance if a client

<edit-config> request attempts to create

             a child node instance within this container.








          Andy




          On Fri, Jul 22, 2016 at 3:13 AM, Balazs Lengyel

<balazs.lengyel@ericsson.com> wrote:

            Hello,


            We seem to have fundamental differences whether

NP-containers exist/don't exist or if this question is even valid.  I
hope we can agree that as NP-containers are meaningless themselves they
MUST NOT influence Netconf operations or model validation. (Which is a
slight violation of Netconf-6241, which we should accept.)


            So I propose the following errata to rfc6020bis.

            As for non-presence containers the presence of the

container node with no child nodes is

            semantically equivalent to the absence of the container

node, configuration operations or

            model validation should never fail due to the existence or

non-existence of a non-presence containers. Specifically:

            - an <edit-config>  create operation for a non-presence

container MUST succeed even if the container already exists.

            - an <edit-config>  delete operation for a non-presence

container MUST succeed even if the container does not exist.

            - an <edit-config>  operation with default-operation=none

MUST succeed even if one or more  non-presence containers do not exist.


            Separately
            - a must statement defined as direct substatement of a

non-presence container SHALL be evaluated as part of model validation if
and only if one or more child data nodes exist in the instance data or
if there is a leaf or leaf-list child with a default value. As
non-presence containers are only used for organizing the hierarchy they
SHOULD NOT have any must substatements.

            IMO the above rules remove ambiguity and follow the

current philosophy of  RFC6020bis.

            If we have a basic agreement I can formulate the text

correctly.

            I don't know whether similar updates are needed for

RestConf.

            regards Balazs

            PS. I still believe introducing NP containers was a

mistake, however they are here to stay.


            On 2016-07-21 09:17, Jan Lindblad wrote:

              Xiang,


                Are you saying that since a NP-container is merely a

structure node, not config in any way, so creating/deleting it
explicitly (and repeatedly) is equivalent to a “no-op” that will
always succeed because doing so has no effect on the server’s config
in any way?


              That's correct. "Creating" an object with zero bits of

information is a no-op.


                If the sever has the following example config:
                <mycontainer>
                     <child  ... bla..bla…configs>
                </mycontainer>


                If a client issues an edit-config with:
                < mycontainer operation="delete">

                The server returns “ok”,

                If then again  the client attempts:

                < mycontainer operation="delete">

                The server should still return  “ok”?


              Yes, that's correct in my opinion. It's a consequence of

the NP container nature as defined in the current RFC6020/YANG 1.0 and
bis.

                If so I think this is confusing. I think it would make

more sense in the latter case if the server returns “"data-missing”
error.


              This is logical if you think of NP containers as path

prefixes, and not as objects with information content. If you accept
that an NP container has zero bits of information, how would the server
even know whether the container exists or not? Not by looking in a
database, for sure.


              P containers have a single bit of information, so they

can be created, and the creation event/existence remembered by the
server. Not so for NP-containers.


                I understand we may advise a client not do so, but

since  RFC6020bis does not forbid this, and it is also a perfectly valid
<edit-config>, so I am sure people will try it.


              Yes. And it works today and is harmless.


              It's unfortunate that the YANG 1.0 and 1.1 specs aren't

crystal clear on the subject, but I believe the interpretation I and
others have of NP container behavior in RFC 6020 is consistent,
implementable and highly useful.


              /jan




--
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email:

Balazs.Lengyel@ericsson.com

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




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



        Mahesh Jethanandani
        mjethanandani@gmail.com















--
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email:

Balazs.Lengyel@ericsson.com


      

      

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




      

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



      

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


    

    

  


--------------09F3BA9F50AE118DA7123D2D--


From nobody Mon Aug  1 07:02:58 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8F112DBD3 for ; Mon,  1 Aug 2016 07:02:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.361
X-Spam-Level: 
X-Spam-Status: No, score=-1.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=hansfords.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEuCV53sPNa6 for ; Mon,  1 Aug 2016 07:02:51 -0700 (PDT)
Received: from server.myfast.site (server.myfast.site [212.113.130.90]) (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 1AAF812D9C9 for ; Mon,  1 Aug 2016 06:58:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hansfords.net; s=default; h=Content-Type:References:In-Reply-To:Date: Subject:From:To:MIME-Version:Sender:Reply-To:Message-ID:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=59Ar3AyfZx+L+e+Ec94MUvBtwiOlN09k3yw/PUicqp8=; b=ZMGjERmpbh9t6LaqB1yqY/6j3 TpTFuH/E3nSyutKAvYnbELeGWJwecGC+o3qAlS4NElGWezUA/XEJpK751F8kZ8AEJMLnIC1liAI7L BfmScXsLAYzJJixeMqjM/Woy5505eFmpqkYOwTTpxLwsRd9pb0Oz/+MZSWEWzBAFaBex/gCmkCZsF LLIPDpBLMrddxOpSQuMpEGavAofqazLMlSOgrv7If/0z0BM3t5Cp0LA+FxHZjqaAVtnDScTMRsO4c iK0Z2/LSnRlbL6dptotPtc+vGk8w8lEM/ICuYf9gWTEyYcilgQ8sS0XS0anD+PSDTwAnAf5xhcNpC awv6WyEyQ==;
Received: from host-92-19-235-91.static.as13285.net ([92.19.235.91]:61407 helo=[IPv6:::ffff:192.168.1.187]) by server.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1bUDji-002jwR-El; Mon, 01 Aug 2016 14:58:31 +0100
MIME-Version: 1.0
To: Robert Wilton , t.petch ,  Andy Bierman ,  Mahesh Jethanandani ,  Balazs Lengyel , Netconf 
From: Jonathan Hansford 
Date: Mon, 1 Aug 2016 14:58:45 +0100
Importance: normal
X-Priority: 3
In-Reply-To: 
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com>  <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com> <57892746.5020903@seguesoft.com>  <57893742.6040903@seguesoft.com> <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com>  <001c01d1e299$e057a910$a106fb30$@seguesoft.com>  <6e416198-13bd-81e3-545e-35e8bfc61536@ericsson.com>       <005a01d1ebe5$6ee080e0$4001a8c0@gateway.2wire.net> 
Content-Type: multipart/alternative; boundary="_E43B0848-1357-414B-A6E7-3F8DA276508F_"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.myfast.site
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - hansfords.net
X-Get-Message-Sender-Via: server.myfast.site: authenticated_id: jonathan@hansfords.net
X-Authenticated-Sender: server.myfast.site: jonathan@hansfords.net
Message-Id: <20160801135834.1AAF812D9C9@ietfa.amsl.com>
Archived-At: 
Subject: Re: [Netconf] What should a server response be? - depending onNP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 Aug 2016 14:02:55 -0000

--_E43B0848-1357-414B-A6E7-3F8DA276508F_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

Should 2(ii) not state =E2=80=9CServers should avoid erroring on a create/d=
elete/none operation on an np container node that has no child nodes=E2=80=
=9D?


Jonathan

From: Robert Wilton=

--_E43B0848-1357-414B-A6E7-3F8DA276508F_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"


Should 2(ii) not state =E2=80=9CServ=
ers should avoid erroring on a create/delete/none operation on an np contai=
ner node that has no child nodes=E2=80=9D?
 

Jonathan
 
From: Robert Wilton
Sent: 01 August 2016 14:4=
2
To: t.petch; Andy Bierman; Mahesh Jethanandani; Balazs Lengyel; Netco=
nf
Subject: Re: [Netconf] What should a server response be? -=
 depending onNP-containers
 =

Hi,

My interpretat=
ion is that NP containers only exist to give structure to any nodes that ex=
ist below them and their existence is not intended to impart any meaning be=
yond this.

The solution I would like to see is to maximize interoper=
ability between NETCONF client and server implementations.  So suggest=
 that:

1) We clarify the text for "rfc6020bis-14#sec=
tion-7.5.8" to make it clear that a server may delete an empty NP =
container at any time (rather than explicitly only when the last child elem=
ent is deleted).  I.e. I propose the following change to 6020bis:
<=
br>OLD:
"If a container does not have a "presence" statem=
ent and the last
   child node is deleted, the NETCONF server =
MAY delete the container." 

NEW:
"If a container does n=
ot have a "presence" statement and has no
  child nodes, =
then the NETCONF server MAY delete the container." 

2) An errat=
a to rfc6241 that, for the purpose of maximizing interoperability, recommen=
ds:
 (i) Clients should use merge/replace/remove operations for np =
container nodes.
 (ii) Servers should avoid erroring on a create/de=
lete/none operation on an np container node.

Thanks,
Rob

<=
/span>=

On 01/08/2016 12:10, t.petch wrot=
e:
----- Original Message -----
From: "Balaz=
s Lengyel" <balazs.l=
engyel@ericsson.com>
Sent: Monday, August 01, 2016 9:55 AM=

 
Hello,
 
As I se=
e it:
 
- The main problem is we don't =
agree whether or when NP containers
exist=
. Some people think they should exist (or not) just as any other
=
data node. (me, Andy, RFC6241) while others believe the existence of the
NP containers=C2=A0 is not even a valid question (tailf). As we hav=
e such
basic differences, I propose to focus just on the specific=
 protocol
cases that are problematic.
 =

Balazs
 
As a practical engi=
neer, it is obvious to me that they exist.=C2=A0=C2=A0 A
response=
 to a NETCONF 'get' may, or may not, contain them so it affects
t=
he XML I receive, so they exist, period.=C2=A0 When I read that they do not=

convey any information, I surmise that this is a statement from<=
/pre>
Information Theory for some meaning of the word Information which=
 likely
I do not understand.=C2=A0 But so what? The specification=
 of Yang says I may
see them so when I do, I know that they exist=
.=C2=A0 The specification is
also very clear that I cannot rely o=
n seeing them (if no child node
exists); such imprecision may or =
may not be a good thing in a Standard
but the text is very clear =
and unambiguous on this point.=C2=A0 As ever, how
a server achiev=
es this is up to the server; what matters is the
appearance prese=
nted to the rest of the world, imprecise as it may be.
 =
;
Looking back, I read
 
'A distinct container should be used when encoding lists with multiple
instances ...'
'Some containers exist in the 'real world'=
 and some are only modelling
artefacts.'
'Use of contai=
ner elements allows simpler manipulation of lists and list
member=
s.'
 
which, for me, is the rationale f=
or the two types of containers we have.
A Non-Presence Container =
makes life simpler for the data modeller and
the user of the data=
 model.
 
Tom Petch
&nbs=
p;
- IMHO this problem means that the following 3 cases are not properly
defined and we need to clarify them. Saying=
 the client should just not
use major parts of the protocol for N=
P-containers is wrong.
 
1) what happens if =
default-operation=3Dnone meets a non-existing NP
container
2) what happens if you create an NP-container and th=
at already exists
e.g. you issue create t=
wice
3) what happens if you delete an NP-container that does not exist=
s
e.g. issue the delete twice<=
/pre>
&=
nbsp;
IMHO saying that from the 6 operation values 3 are un=
defined for
NP-container is not acceptabl=
e.
As we have protocol operations defined in RC6020 we need to define<=
o:p>
them properly.
regards Balazs
<=
pre> 
 
On 2016-08-01 0=
2:23, Andy Bierman wrote:
 
 =

 
 
 
=C2=A0 On Sun, Jul 31, 2016 at 10:45 AM, Mahesh J=
ethanandani
<mjethanandani@gmail.com> wrote:
 
 
 
=C2=
=A0=C2=A0=C2=A0 On Jul 30, 2016, at 5:31 PM, Andy Bierman <andy@yumaworks.com>
wrote:
 
 
<=
pre> 
 
 
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 On =
Sat, Jul 30, 2016 at 5:21 PM, Mahesh Jethanandani
<mjethanandani@gmail=
.com> wrote:
 
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 Andy,
 
&nbs=
p;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The thread st=
arted because the RFC does not say anything about
a create of a NP container. It only talked about delete. Can we ma=
ke the
(re-)create of the NP container unconditional to whether a=
 delete was
performed on it. So a tweak to your proposal would be=
:
 
 
 <=
/o:p>
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
The only reason that example did not work is because the server<=
/pre>
deleted the NP containers
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 after the client created them.=C2=A0 If the server does not delet=
e
the containers then
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 the 2nd RPC will not fail.
 
 
=C2=A0=C2=A0=C2=A0 I think this argume=
nt of whether server should or should not
create/delete NP containers is distracting from the main point of when
NP containers should exist. In my mind, the NP container existence
depends on whether child nodes exist or not. In the end, if child =
nodes
exist, NP containers should exist (created), if they do not=
 exist, the
NP container should be removed.
 
 
=C2=A0=C2=A0=C2=A0 Can we agree on =
that?
 
 
 
 
=C2=A0 No.
<=
o:p> 
 
=C2=A0 "should =
be removed" is an implementation choice.
=C2=A0 It started a=
s MAY be removed.=C2=A0 It needs to stay that way.
 
 
=C2=A0 As I have pointed out 100 =
times,=C2=A0 the protocol has merge and replace
=C2=A0 for the si=
tuation where the client is not exactly aware of how
ceration and
=C2=A0 deletion will be handled on the server=
.
 
 
=C2=A0 =
There is no reason to force implementations to change.
=C2=A0 If =
you magically delete containers, then magically recreate them.
=
=C2=A0 If you don't then the nodes will be as the client expects, so no
problem.
 
=
 
 
 
=C2=A0 Andy
 
 
 
 
=C2=A0=
=C2=A0=C2=A0 P.s The errata will be much easier to craft if we can agree on=

this.
 
=
 
 
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This can also be completely avoided=
 by using the default
(merge).=

=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 Since the client has to explicitly pick default=
-operation=3Dnone,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 it better know =
what it is doing.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This is the same=
 issue as a default leaf
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and the c=
reate operation.=C2=A0 Nothing special about NP containers.
=
 
 
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 The <edit-config> for "create" will fail if the leaf=
 already
exists
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 and the "delete" will fail if the value is not there=
 (just a
default).
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 The work-around?=C2=A0 Use merge and remove, not create and=
 delete.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 IMO the same logic applie=
s here.
 
 
<=
o:p> 
 
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 Andy
 
 
 
 
 =
;
 
 
<=
o:p> 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OLD:<=
/pre>
 
 
=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If a container does not=
 have a "presence" statement and the
last
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 child node is deleted, the NETCONF server MAY delete the
container.
 
 =

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 NEW:
=
 
 
=C2=A0=C2=A0=C2=A0=
=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0If a container does not have a &=
quot;presence" statement and the
con=
tainer instance
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 does not have any child node instances, the NETCONF server
MAY delete the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 container. It MUST create the container i=
nstance if a
client <edit-config> r=
equest
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 at=
tempts to create a child node instance within this
container.
 
 
 
 
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 On Jul 30, 2016, at 11:52 AM, An=
dy Bierman
<andy@yumaworks.com> wrote:
 
<=
pre> 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 Hi,
 
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I strongly o=
bject to changing a vague MAY about deleting an
NP container
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 after the last child has been deleted into several MUST
requirements.
 
&=
nbsp;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 I propose this text instead:
 
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 OLD:
 
 
=
 
 
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If a container does =
not have a "presence" statement and
=

the last
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 child node is deleted, the NETCONF server MAY delete the=

container.
 
<=
pre> 
 
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 NEW:
 
 
 =

 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If a container does not have a &=
quot;presence" statement and
the con=
tainer instance
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 does not have any child node instances, the NETCONF=

server MAY delete the
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 container. If the se=
rver does delete a container instance
in =
this case, it MUST
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 re-create the container instance if a client
<edit-config> request attempts to create
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 a child node instance within this container.
 
 
 
 =
;
 
 
<=
o:p> 
 
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Andy
 
=

 
 
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 On Fri=
, Jul 22, 2016 at 3:13 AM, Balazs Lengyel
<balazs.lengyel@ericsson=
.com> wrote:
 
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Hello,
 <=
/o:p>
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 We seem to have fundamental difference=
s whether
NP-containers exist/don't exist=
 or if this question is even valid.=C2=A0 I
hope we can agree tha=
t as NP-containers are meaningless themselves they
MUST NOT influ=
ence Netconf operations or model validation. (Which is a
slight v=
iolation of Netconf-6241, which we should accept.)
 
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 So I propose the following errata to rfc6020=
bis.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 As for non-presence containers the pre=
sence of the
container node with no child=
 nodes is
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0semantically equivalent to the absence of the container=

node, configuration operations or
<=
blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 model validation sho=
uld never fail due to the existence or
no=
n-existence of a non-presence containers. Specifically:
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 - an <edit-config>=C2=A0 create operation for a non-presence
container MUST succeed even if the contain=
er already exists.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 - an <edit-config>=C2=A0 delete operation for a non-p=
resence
container MUST succeed even if th=
e container does not exist.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 - an <edit-config>=C2=A0 operation with defa=
ult-operation=3Dnone
MUST succeed even if=
 one or more=C2=A0 non-presence containers do not exist.
 
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Separately
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - a must statement defi=
ned as direct substatement of a
non-prese=
nce container SHALL be evaluated as part of model validation if
a=
nd only if one or more child data nodes exist in the instance data or
=

if there is a leaf or leaf-list child with a default value. As
non-presence containers are only used for organizing the hierarchy they<=
/pre>
SHOULD NOT have any must substatements.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
IMO the above rules remove ambiguity and follow the
current philosophy of=C2=A0 RFC6020bis.
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If we have a basic agreeme=
nt I can formulate the text
correctly.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 I don't know whether similar updates are needed fo=
r
RestConf.
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 regards Balazs
&n=
bsp;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 PS. I still believe introducing NP containers was a=

mistake, however they are here to stay.<=
/pre>
&=
nbsp;
 
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 On 2016-07-21 09:17, Jan Lindbla=
d wrote:
 
=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=A0Xiang,
&=
nbsp;
 
=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 Are you =
saying that since a NP-container is merely a
<=
pre>structure node, not config in any way, so creating/deleting it
explicitly (and repeatedly) is equivalent to a =C3=A2=E2=82=AC=C5=93no-op=
=C3=A2=E2=82=AC=C2=9D that will
always succeed because doing so h=
as no effect on the server=C3=A2=E2=82=AC=E2=84=A2s config
in any=
 way?
 
 
=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 Th=
at's correct. "Creating" an object with zero bits of
information is a no-op.
 
<=
pre> 
=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 If the sever has the follo=
wing example config:
=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 <mycontainer>
<=
pre>=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 <child=C2=A0 ... bla=
..bla=C3=A2=E2=82=AC=C2=A6configs>
=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 </mycont=
ainer>
 
 
=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 If a client issues an edit-config with:
=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 < mycontainer operation=3D"delete">
 
=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 The server returns =C3=A2=E2=82=
=AC=C5=93ok=C3=A2=E2=82=AC=C2=9D,
 
=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 If then again=C2=A0 the client attempts:
 =

=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 < mycontainer operation=3D"delete=
">
 
=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 The serv=
er should still return=C2=A0 =C3=A2=E2=82=AC=C5=93ok=C3=A2=E2=82=AC=C2=9D?<=
/pre>
 
 
=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 Yes, =
that's correct in my opinion. It's a consequence of
the NP container nature as defined in the current RFC6020/YANG 1=
.0 and
bis.
 
=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 If=
 so I think this is confusing. I think it would make
more sense in the latter case if the server returns =C3=A2=E2=
=82=AC=C5=93"data-missing=C3=A2=E2=82=AC=C2=9D
error.
<=
o:p> 
 
=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 This is logica=
l if you think of NP containers as path
p=
refixes, and not as objects with information content. If you accept
that an NP container has zero bits of information, how would the server<=
/pre>
even know whether the container exists or not? Not by looking in =
a
database, for sure.
 
 =
;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 P containers have a single bit of information, so the=
y
can be created, and the creation event/=
existence remembered by the
server. Not so for NP-containers.
 
 
=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=
 I understand we may advise a client not do so, but
since=C2=A0 RFC6020bis does not forbid this, and it is also a pe=
rfectly valid
<edit-config>, so I am sure people will try i=
t.
 
 
=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yes. =
And it works today and is harmless.
 
<=
o:p> 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 It's unfortunate that the YANG 1.0 and 1.1 s=
pecs aren't
crystal clear on the subject,=
 but I believe the interpretation I and
others have of NP contain=
er behavior in RFC 6020 is consistent,
implementable and highly u=
seful.
 
 
=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 /j=
an
 
 
&=
nbsp;
 
--
Balazs Lengy=
el=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 Ericsson Hunga=
ry Ltd.
Senior Specialist
Mobile: +36-70-330-7909=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=A0em=
ail:
Balazs.Lengyel@ericsson.com
 
=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 Netconf mailing list
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Netconf@ietf.org
=C2=A0=C2=A0=C2=
=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/mailman/listinfo/ne=
tconf
 
 
 
 
=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 =
Netconf mailing list
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 Netconf@ietf.org
=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org/mailman/lis=
tinfo/netconf
 
 
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 Mahesh Jethanandani
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 mjethanandani@gmail.com
 
 
&=
nbsp;
 
 
 
 
 
 
 
&n=
bsp;
 
 
 
 
--
Bala=
zs Lengyel=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 Erics=
son Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7=
909=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 email:
Balazs.Lengyel@ericsson.com
 <=
/pre>
 
 
<=
pre>-----------------------------------------------------------------------=
-
--------
 
 
____=
___________________________________________
Netconf mailing list<=
/pre>
Netconf@ietf.org
https://www.iet=
f.org/mailman/listinfo/netconf
 
 
____________________________________=
___________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf
 
 
=

--_E43B0848-1357-414B-A6E7-3F8DA276508F_--



From nobody Mon Aug  1 07:08:53 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F01B12D0D1 for ; Mon,  1 Aug 2016 07:08:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Azzbmqeb1Qx for ; Mon,  1 Aug 2016 07:08:48 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00123.outbound.protection.outlook.com [40.107.0.123]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1AF212D694 for ; Mon,  1 Aug 2016 07:06:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dxuMCOViqbJaDONz14W8OYVH1F1+4KR0ozQat0f68CY=; b=EJeHoxfTd6xqOpQCEUY1+W3N7b/eqYfcELdMo7uKYlxMmrm2IFfUI9peBC+f903esEL0ZXkepxUUyMV9Kg8iB6wF5XvmhfkeeplfOz4kjA9yJgVsHJ8e0AiUeOangNerFScSiXrDy9lBz56ywK9gs4JsrnNCw3RUlme56r8N088=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (31.50.86.164) by VI1PR07MB1632.eurprd07.prod.outlook.com (10.166.142.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Mon, 1 Aug 2016 14:06:10 +0000
Message-ID: <002401d1ebfd$7ee2c8a0$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Mahesh Jethanandani , Juergen Schoenwaelder 
References: <001c01d1e299$e057a910$a106fb30$@seguesoft.com>  <6e416198-13bd-81e3-545e-35e8bfc61536@ericsson.com>      <016801d1ebd9$cb9c3e20$4001a8c0@gateway.2wire.net>  <20160801102255.GB7476@elstar.local> <30B6D9D0-1E0D-4848-99C2-ACCCC27237AC@gmail.com>
Date: Mon, 1 Aug 2016 15:02:51 +0100
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: [31.50.86.164]
X-ClientProxiedBy: AM4PR0101CA0004.eurprd01.prod.exchangelabs.com (10.167.254.14) To VI1PR07MB1632.eurprd07.prod.outlook.com (10.166.142.150)
X-MS-Office365-Filtering-Correlation-Id: cce08d1e-2686-4572-23b2-08d3ba14fdf1
X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1632; 2:moQDob+hHome81jfT0xxmaHQFgiFUDxjXr91HqX5+hPSD+Moa+Ue9eo6c9GGM6yhDKaG3EunkdA2Vc9s8oOcXWDxpht4Q30xVITszHI9Y4Q4bptUkxUj01W6o0wICVkQP8beUf99RIFF2hRUYtJ66Y0MV7TFDjjpKEd8JG9UK+S0ZZ1BLw/d+syF0YSFPmO+; 3:eXkcqrQ1nWZiHmZ8NoVh6VT3/rYGjyz1zTsr42ZyO6smwl5H9HgOxu6TeNDQrGFWhvq+TUfz7o1Ttb+RZQTH90lNPyK0fTfJmqELutwarP0MRaNY1cFs2aNLleL1oWkx; 25:OmGnuEF6PqdelrXtuu6s61Wcjt8S9gLfSWCN192F8E+kIFd9gFzO2a9MhbkbKLJJnOdsP9oTiqeG/v0yLVh8tH8Q70tx9z5o6zJxrrTIU/2b4h64iHdbmMqvm1sIaIzRmNmdpfrcpDdBtP+ohX7M1ZmftXu0OlAOCLWixLnXbc6NfefYKys8rST1kVULQ4QEkTuZcOXxfwR93koYLdTSnU2beUBHBSi/CLsHBmLK9SLd1eMOBY85a1BZ+zdjt4PXM01Tv0Sk4NRdyvrCXESh3Fwt/XX1excQKULRdLb0Ja9p/zH2/+3q5bs7XinpOUBRLRhu8tSRg/YyjirxTgtxJpLOKQRrZfsZitgenEWPdyUSuCbM12uG6K2hINXu1Dt2afatt+Gm5LTjbJBzVTuKxH9uBbPDNGGKpz7a7QQG0mg=; 31:SmEJPJi8mAqk4e+dCIWKOJtXjVcQ7g8GPUuzmAzlZ/aeQOx1LpZwOUG2jabUWhsW7rcippVqcwyy91oDS5+kKSrTGzBIaB4cvveMu+KO1EWAGM7x2lORsN4ZIyGLUa1mza7EwEQUaAEY++eeNkDOdfC5jcXnN3JeXfrAcr8AIUqvDvq8b4Vk7+R+5Hx5IzHyt409fiV4nR+wuyZb2ETANA==
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1632;
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(158342451672863)(788757137089); 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:VI1PR07MB1632; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1632; 
X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1632; 4:ThIMoYN4FuKOGZrUu/iE4C160rUWQMV/GdiCXYEF4otennVhHc+sW7/h7nz8yGid/iNRE3rgw91LzgOC8Os0m+yVMPn8k9sE+jBj7dkiz+Ew5CFwlGJw7vhj9La3kGHG/MGPZJ75LxfX9VdV1DRXpP+l1YNGA3qWHBqcxFpnhvG61DCxVmk8cGoBXOZrMIggXUOQqXriHF8JefoQXm1I7cn0UkKDO03XQEA0ZI3vzy3jMGSxVsc86akTh1Hnq9NzeaoC4NmUV7+cFV+wNeWN4pi8UfXV1gBpViBmF4g8nm6y4W5vV6PeVPlPRkSzF5kwCmKgXE6/Mwlbo2rGK75VXQSdWpn2pFXXBLNJRW4mZB7Ayzn3gzDT8J+PXTZnhSMhLzAEBxoOzFkJ890U9BWxlF+7Apr1CxQg/v9LzaYzweJZwXSNvngSozMgGurPwL+C7CJEuSlxhxUXkfizOKJ9Gj/0+WiIVdVx+c2ceT2Met8=
X-Forefront-PRVS: 0021920B5A
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(24454002)(13464003)(199003)(189002)(51444003)(252514010)(377454003)(377424004)(66066001)(19580405001)(62236002)(92566002)(47776003)(19580395003)(86362001)(189998001)(44736004)(23756003)(14496001)(5001770100001)(97736004)(106356001)(93886004)(230700001)(33646002)(116806002)(77096005)(586003)(1456003)(105586002)(44716002)(3846002)(76176999)(6116002)(15975445007)(50986999)(4326007)(84392002)(2906002)(50226002)(50466002)(7736002)(68736007)(9686002)(7846002)(305945005)(101416001)(81816999)(81166006)(42186005)(81686999)(61296003)(1556002)(81156014)(8676002)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1632; 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; VI1PR07MB1632; 23:4Bpy/hSElBdEwATL4DxOdK+tD+/o8H8GBR14Nkt?= =?iso-8859-1?Q?jwv1mZJrmC2ahYgas3M1XYZothSIYvV5KdsAUvkbwvylXjR2J5wGTsXMqG?= =?iso-8859-1?Q?BRk0ggiZW8bweMJXRC3kDZmqok0/QsrIrMgc2htvhQnRTaLerQOY9fDZIh?= =?iso-8859-1?Q?g+a+GhmCIa/SUUIvswhtaqqf551vrJzFlSn87LSMrMcrrDHoTpn+Kckpgq?= =?iso-8859-1?Q?I0t/Cm93YzqOQcAhm+c8hkENyVFldcrAv6eN+HU0ZxcfiLjETCJ2kDWIPB?= =?iso-8859-1?Q?SMywXUE86BmFEfcKT2RCCCTXj9KQ2L+i+IunexHCGKtV1mGu/C9tTmUNQI?= =?iso-8859-1?Q?C3Ib1wxXxt4bjg4hUiUifig1YQ8xjqRsYK3rEG6M73TF3ZXBPbg5M8bUlO?= =?iso-8859-1?Q?00+Nyhpv7ijXAtgP7dM8dyRGxvJeJZGVpF2bt5yjvn6810veQvmrQdz7u7?= =?iso-8859-1?Q?r1GJG0IHenGHwYeF+hsDzLW26DoXX8z2OecB00LY8mPysv1VGWkwKAVU2i?= =?iso-8859-1?Q?Irxr3aANxDp+5bbFQ41a5xl3nIP118q4SUu7umgorNs8fTyYVgYibC03w5?= =?iso-8859-1?Q?dgR14lL4oqeVpDghzrHQ4V7t92ZdIyUUtILdtOZvi0WrTGuY/OPA4HZPZD?= =?iso-8859-1?Q?iRm9Aa822Nti5oTml7uzfQTBsRd1npE0tlAK5BL35cRKyLexhCfODFiwBK?= =?iso-8859-1?Q?7LaF2rR0yHIRhNVnzQ2zI0c+SC2qNZQP5Syk024lvk2HKPUqjC571Bso2s?= =?iso-8859-1?Q?/VfyTYUd4XQoGTVhRprlQww7rt+IzUh3RkVj+DAfUmtgQlzzGkypOW7XXS?= =?iso-8859-1?Q?AWkGml2CCDAACgKmue8zPv9nw0PZpG+N5IKzcXz1HZGE9TsoC0L10MoCzn?= =?iso-8859-1?Q?38aYcFzzxhBHeOw+bajA2Vq/m30c/YzhQmnAhiT7v0H+WYVZbNsg21zHZf?= =?iso-8859-1?Q?hKyfySPuXKqaWm0/0OC9tHC4F0/8hGx6f7bNODVEucmrdwRoDUfXZ71q95?= =?iso-8859-1?Q?+WMdDWhTE6Sh372qh/fmEysnaA6qImM8+znfCuUOGDwYMVFLd4ehxvrDUV?= =?iso-8859-1?Q?dgaq4xfi6rdSiyZn5zN09o3Oa92k8wu3hAV3R/7TcseaEzQyfRCN2INcjP?= =?iso-8859-1?Q?eOTw9/HtX73Z2cfwTqzXyAV6Y3EoQiDXu0+Y14T7+vlfWng96j6rlx+Ct+?= =?iso-8859-1?Q?di4eFHW3iQjrPPMY+KDOXs2WT9tUWmTO4lLJAJWZd/Wm8ftCxUiS14DN2J?= =?iso-8859-1?Q?hQca3b+a5N5MMaJGcUvVFDZEP1SNrIBQNNAIC0Jg6WQTBQ9iNbLwDdNC+5?= =?iso-8859-1?Q?Ilkf7JWa1tcYvEhfbAkEBMozJXCgNzpjjZsdLUlcwsQMfkNhCEV3Gdoz9G?= =?iso-8859-1?Q?BvX0mKGFxs9cgkSF//JCeiO+U6ltnVE+DZ8gYpAVZYuNM3o1SiYj48uI20?= =?iso-8859-1?Q?qewcYjJOClf+VlIYbryCvZqs9dDrS5fnDXj9ZNci/pcwCVGwmQMEb6EsUB?= =?iso-8859-1?Q?8PVgF4TGD2HDfAT2wEIA6zaX29QQ58eZdZOAdZCwPe6zFPqk0+h6qibvWM?= =?iso-8859-1?Q?8DL3Q=3D=3D?=
X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1632; 6:L5neIGCQUCsLbyEFZx+bD+utzDrZcSPxupECtWpMHQuoxa9Arf+sCGmtD8AOzxeD8CPl/VuRl5o1JY51Jb4Dh+H5b+br4Si8IPQTU/AsJZYVioUyPK5fBbaJS1vwO/MFv24HL597H1axYWACKJ3FFlDm33MtoM6V48EAvPXTXdG3ZnVT++fm4qJyRutdmfAhzrLwTYUflC6Dqkdfz/J6kbN8lX10Ne4pURoaLrNJg/VJKUAq/a1aRFG3bmHZqlnBWzqO0b/0PWvKPOaePWp0466qG1SVtDx7Cv0h5WmLyJY=; 5:5nGyLfI3jw/hXLq2hS36AvPR4DrT0H5UWxgF9W/wNvCfcuJy2aVu/GAfZPFHls6D5F/pIPpTN1XmBnpm+FU274NpmDRYabarSw4tSWBvCn3OVJ/wmlvWOk+UsdbTrPKw7mceeewUAY9nWrJMArVcqw==; 24:FZjSEOvhPoLNXoExyprCfAUyBtdLJ2rmeU0OYBRBto6cpXS3GRB5c8sug7SlKrYEuvpHmlJKBJkYwpujVI1+P7DlmwPmFlc8GiG3iVnH9qI=; 7:cK2fBEvVwvkT5GnqM5JLQRgnxCvT1S59X+ylxv/JTzwZYJKUJLAWu1uX0Xr7Xu/P69KHvaRkJs6NbksWJ1x3k82xgyzA2D10BC6rWa/TSi4q1e1giBdWuDLPDDgPNJ3L/tBqJMF2nyOAOwaAUZwlEqb0MgBshRjeK9b7nO2wDGzGeo5kHxRR1g/2mQcw3HC2iwqkok8uIHaQKOsiN09pSTFAGuwodOQ1k0cSAEeGDSUIJ8LuQtXccYq3vwSndiRY
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Aug 2016 14:06:10.7069 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1632
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 Aug 2016 14:08:52 -0000

----- Original Message -----
From: "Mahesh Jethanandani" 
Sent: Monday, August 01, 2016 12:41 PM

> On Aug 1, 2016, at 6:22 AM, Juergen Schoenwaelder
 wrote:
>
> I agree with Tom and the 'solution' is IMHO to encourage clients to
> use 'merge' instead of assuming a certain behavior here.

Agree.

How do we articulate that in the RFC?



s.7.5.8.end

A client cannot know whether or not a server has deleted a Non-Presence
Container when the last child node has been deleted and so cannot know
whether a "create" or "delete" will succeed or return an error.  The
client should use "merge" or "replace" instead of "create".

Tom Petch

> /js
>
> On Mon, Aug 01, 2016 at 12:19:55PM +0200, Balazs Lengyel wrote:
>> IMHO not defining what happens is the worst solution. Any solution is
>> better. If we can't agree, we should follow the Postel principle: be
liberal
>> in what you accept.
>>
>> regards Balazs
>>
>>
>> On 2016-08-01 11:47, t.petch wrote:
>>> 
>>>
>>> I think that Andy is spot on.  We currently have a simple, clear
rule in
>>> NETCONF:
>>> - delete, does not exist, error
>>> - create, does exist, error.
>>>
>>> Introducing corner cases that blur the rules, that allow users to be
>>> imprecise, whether by Standards Track RFC or an Erratum,
>>> I think a mistake
>>>
>>> An Erratum that points out that since a server may silently delete a
>>> Non-Presence Container with no children, a user can never know
whether
>>> or not such a Container exists and so cannot know whether a delete
or
>>> create to be an error or not, yes, that is fine.  Going beyond that
is a
>>> protocol change (which I would resist even in an RFC).
>>>
>>> Tom Petch
>>
>> --
>> Balazs Lengyel                       Ericsson Hungary Ltd.
>> Senior Specialist
>> Mobile: +36-70-330-7909              email:
Balazs.Lengyel@ericsson.com
>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         

Mahesh Jethanandani
mjethanandani@gmail.com




From nobody Mon Aug  1 07:13:18 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B9912D10C for ; Mon,  1 Aug 2016 07:13:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vrk011UxeDji for ; Mon,  1 Aug 2016 07:13:13 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8262412D737 for ; Mon,  1 Aug 2016 07:13:10 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 773661CC00A1; Mon,  1 Aug 2016 16:13:17 +0200 (CEST)
From: Ladislav Lhotka 
To: Andy Bierman , "Dale R. Worley" 
In-Reply-To: 
References:  <87vazljnps.fsf@hobgoblin.ariadne.com> 
User-Agent: Notmuch/0.22.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Mon, 01 Aug 2016 16:13:14 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 Aug 2016 14:13:17 -0000

Andy Bierman  writes:

> Hi,
>
> YANG 1.1 has been changed so the XPath is not really backward-compatible
> with YANG 1.0.  In YANG 1.1 NP-containers always exist if the non-NP parent
> is
> instantiated.

My mental model regarding NP-containers is that they are part of
the default contents of a datastore. If an NP-container is "in use"
(according to the same rules as specified in sec. 7.6.1 of 6020bis for
default leaves), then

- creating a child of this container succeeds,

- "must" expressions defined on this container apply.

Lada

>
> NETCONF and RESTCONF do not say anything about the server ignoring
> the rules for operation="create", operation="delete" and
> default-operation="none".
> IMO itr would be a really bad idea to continue spreading little protocol
> details
> in the YANG RFC.  People might read the protocol spec and (correctly) assume
> that the protocol does not trat NP containers special at all.
>
> If anything, the sentence about MAY delete needs to be removed because
> it is inconsistent with the XPath (always exists).
>
>
> Andy
>
>
> On Sun, Jul 31, 2016 at 6:13 PM, Dale R. Worley  wrote:
>
>> Mahesh Jethanandani  writes:
>> > I think this argument of whether server should or should not
>> > create/delete NP containers is distracting from the main point of when
>> > NP containers should exist. In my mind, the NP container existence
>> > depends on whether child nodes exist or not. In the end, if child
>> > nodes exist, NP containers should exist (created), if they do not
>> > exist, the NP container should be removed.
>> >
>> > Can we agree on that?
>>
>> If the concept of a "non-presence container" makes any sense, then the
>> existence of an empty container must have exactly the same significance
>> as the non-extence of the container.
>>
>> Given that, we have to make sure the protocol is consistent with that
>> principle.  E.g., if you ask to create an element of a non-existing NP
>> container, it must succeed, because asking to create an element of an
>> existing but empty NP container succeeds.
>>
>> I don't see what all the consequences of this principle are, but if we
>> can't make the protocol consistent with it, then we can't properly
>> implement the concept of NP containers.
>>
>> Dale
>>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

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


From nobody Mon Aug  1 07:22:18 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4FA612D691 for ; Mon,  1 Aug 2016 07:22:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.787
X-Spam-Level: 
X-Spam-Status: No, score=-15.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tk_9Xfuzt6Rq for ; Mon,  1 Aug 2016 07:22:11 -0700 (PDT)
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 9557F12D10C for ; Mon,  1 Aug 2016 07:22:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=57482; q=dns/txt; s=iport; t=1470061330; x=1471270930; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=6Av9GEfGRu14pIA1V4nNovweZf4tiwDYxSb/aYeSCM4=; b=Nc+uHcDmx9jcc9l6MHaF/biT6roDi3xYkIO48VcvhZ/FuYGJfowlARTh ulH3tB7HGQ13ScKwdU7KEIl8T8hzXfnQnQcOgUQORJMwhR1a8hrsPsM87 io3Pxzr3ab+AowxS6yNmtUqiuEZXmrV676J6c5La0p8hHEetqScBTT+73 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DiDgBeWp9X/xbLJq1dgneBJCoDT6xvj?= =?us-ascii?q?iEmhS1KAoF4AQEBAQEBXieEXgEBBQEBGAlLFwQJAhEEAQEBIAEGAwICIQYfCQg?= =?us-ascii?q?GAQwGAgEBFQKFd4IFAxcOkzedIItCDYQUAQEBAQEBAQEBAQEBAQEBAQEBAQEBF?= =?us-ascii?q?wWGKoF4glWCQ4FNAhEBBkyCS4JaBYgki0yFDzSGGIYygjWBa4doI4VJiCs9g0i?= =?us-ascii?q?Dd1SCEhyBTTsyAQGGTgINFweBGAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.28,455,1464652800";  d="scan'208,217";a="638875398"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Aug 2016 14:22:07 +0000
Received: from [10.63.23.91] (dhcp-ensft1-uk-vla370-10-63-23-91.cisco.com [10.63.23.91]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u71EM7RC018106; Mon, 1 Aug 2016 14:22:07 GMT
To: Jonathan Hansford , "t.petch" , Andy Bierman , Mahesh Jethanandani , Balazs Lengyel , Netconf 
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <57892746.5020903@seguesoft.com>  <57893742.6040903@seguesoft.com> <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com>  <001c01d1e299$e057a910$a106fb30$@seguesoft.com>  <6e416198-13bd-81e3-545e-35e8bfc61536@ericsson.com>       <005a01d1ebe5$6ee080e0$4001a8c0@gateway.2wire.net>  <201608011358.u71DwcdK009359@rcdn-core-3.cisco.com>
From: Robert Wilton 
Message-ID: <0a405f34-0e5c-e941-55f0-bb2a0e1f1307@cisco.com>
Date: Mon, 1 Aug 2016 15:22:07 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <201608011358.u71DwcdK009359@rcdn-core-3.cisco.com>
Content-Type: multipart/alternative; boundary="------------FCA889EF9D399EFE6888304C"
Archived-At: 
Subject: Re: [Netconf] What should a server response be? - depending onNP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 Aug 2016 14:22:16 -0000

This is a multi-part message in MIME format.
--------------FCA889EF9D399EFE6888304C
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Yes.

Thanks for the clarification,
Rob


On 01/08/2016 14:58, Jonathan Hansford wrote:
>
> Should 2(ii) not state “Servers should avoid erroring on a 
> create/delete/none operation on an np container node that has no child 
> nodes”?
>
>
> Jonathan
>
> *From: *Robert Wilton 
> *Sent: *01 August 2016 14:42
> *To: *t.petch ; Andy Bierman 
> ; Mahesh Jethanandani 
> ; Balazs Lengyel 
> ; Netconf 
> *Subject: *Re: [Netconf] What should a server response be? - depending 
> onNP-containers
>
> Hi,
>
> My interpretation is that NP containers only exist to give structure 
> to any nodes that exist below them and their existence is not intended 
> to impart any meaning beyond this.
>
> The solution I would like to see is to maximize interoperability 
> between NETCONF client and server implementations.  So suggest that:
>
> 1) We clarify the text for "rfc6020bis-14#section-7.5.8 
> " 
> to make it clear that a server may delete an empty NP container at any 
> time (rather than explicitly only when the last child element is 
> deleted).  I.e. I propose the following change to 6020bis:
>
> OLD:
> "If a container does not have a "presence" statement and the last
>    child node is deleted, the NETCONF server MAY delete the container."
>
> NEW:
> "If a container does not have a "presence" statement and has no
>   child nodes, then the NETCONF server MAY delete the container."
>
> 2) An errata to rfc6241 that, for the purpose of maximizing 
> interoperability, recommends:
>  (i) Clients should use merge/replace/remove operations for np 
> container nodes.
>  (ii) Servers should avoid erroring on a create/delete/none operation 
> on an np container node.
>
> Thanks,
> Rob
>
> On 01/08/2016 12:10, t.petch wrote:
>
>     ----- Original Message -----
>
>     From: "Balazs Lengyel" 
>
>     Sent: Monday, August 01, 2016 9:55 AM
>
>         Hello,
>
>         As I see it:
>
>         - The main problem is we don't agree whether or when NP containers
>
>     exist. Some people think they should exist (or not) just as any other
>
>     data node. (me, Andy, RFC6241) while others believe the existence of the
>
>     NP containers  is not even a valid question (tailf). As we have such
>
>     basic differences, I propose to focus just on the specific protocol
>
>     cases that are problematic.
>
>     Balazs
>
>     As a practical engineer, it is obvious to me that they exist.   A
>
>     response to a NETCONF 'get' may, or may not, contain them so it affects
>
>     the XML I receive, so they exist, period.  When I read that they do not
>
>     convey any information, I surmise that this is a statement from
>
>     Information Theory for some meaning of the word Information which likely
>
>     I do not understand.  But so what? The specification of Yang says I may
>
>     see them so when I do, I know that they exist.  The specification is
>
>     also very clear that I cannot rely on seeing them (if no child node
>
>     exists); such imprecision may or may not be a good thing in a Standard
>
>     but the text is very clear and unambiguous on this point.  As ever, how
>
>     a server achieves this is up to the server; what matters is the
>
>     appearance presented to the rest of the world, imprecise as it may be.
>
>     Looking back, I read
>
>     'A distinct container should be used when encoding lists with multiple
>
>     instances ...'
>
>     'Some containers exist in the 'real world' and some are only modelling
>
>     artefacts.'
>
>     'Use of container elements allows simpler manipulation of lists and list
>
>     members.'
>
>     which, for me, is the rationale for the two types of containers we have.
>
>     A Non-Presence Container makes life simpler for the data modeller and
>
>     the user of the data model.
>
>     Tom Petch
>
>         - IMHO this problem means that the following 3 cases are not properly
>
>     defined and we need to clarify them. Saying the client should just not
>
>     use major parts of the protocol for NP-containers is wrong.
>
>         1) what happens if default-operation=none meets a non-existing NP
>
>     container
>
>         2) what happens if you create an NP-container and that already exists
>
>     e.g. you issue create twice
>
>         3) what happens if you delete an NP-container that does not exists
>
>     e.g. issue the delete twice
>
>         IMHO saying that from the 6 operation values 3 are undefined for
>
>     NP-container is not acceptable.
>
>         As we have protocol operations defined in RC6020 we need to define
>
>     them properly.
>
>         regards Balazs
>
>         On 2016-08-01 02:23, Andy Bierman wrote:
>
>            On Sun, Jul 31, 2016 at 10:45 AM, Mahesh Jethanandani
>
>        wrote:
>
>              On Jul 30, 2016, at 5:31 PM, Andy Bierman 
>
>     wrote:
>
>                On Sat, Jul 30, 2016 at 5:21 PM, Mahesh Jethanandani
>
>        wrote:
>
>                  Andy,
>
>                  The thread started because the RFC does not say anything about
>
>     a create of a NP container. It only talked about delete. Can we make the
>
>     (re-)create of the NP container unconditional to whether a delete was
>
>     performed on it. So a tweak to your proposal would be:
>
>                The only reason that example did not work is because the server
>
>     deleted the NP containers
>
>                after the client created them.  If the server does not delete
>
>     the containers then
>
>                the 2nd RPC will not fail.
>
>              I think this argument of whether server should or should not
>
>     create/delete NP containers is distracting from the main point of when
>
>     NP containers should exist. In my mind, the NP container existence
>
>     depends on whether child nodes exist or not. In the end, if child nodes
>
>     exist, NP containers should exist (created), if they do not exist, the
>
>     NP container should be removed.
>
>              Can we agree on that?
>
>            No.
>
>            "should be removed" is an implementation choice.
>
>            It started as MAY be removed.  It needs to stay that way.
>
>            As I have pointed out 100 times,  the protocol has merge and replace
>
>            for the situation where the client is not exactly aware of how
>
>     ceration and
>
>            deletion will be handled on the server.
>
>            There is no reason to force implementations to change.
>
>            If you magically delete containers, then magically recreate them.
>
>            If you don't then the nodes will be as the client expects, so no
>
>     problem.
>
>            Andy
>
>              P.s The errata will be much easier to craft if we can agree on
>
>     this.
>
>                This can also be completely avoided by using the default
>
>     (merge).
>
>                Since the client has to explicitly pick default-operation=none,
>
>                it better know what it is doing.
>
>                This is the same issue as a default leaf
>
>                and the create operation.  Nothing special about NP containers.
>
>                The  for "create" will fail if the leaf already
>
>     exists
>
>                and the "delete" will fail if the value is not there (just a
>
>     default).
>
>                The work-around?  Use merge and remove, not create and delete.
>
>                IMO the same logic applies here.
>
>                Andy
>
>                  OLD:
>
>                     If a container does not have a "presence" statement and the
>
>     last
>
>                     child node is deleted, the NETCONF server MAY delete the
>
>     container.
>
>                  NEW:
>
>                     If a container does not have a "presence" statement and the
>
>     container instance
>
>                     does not have any child node instances, the NETCONF server
>
>     MAY delete the
>
>                     container. It MUST create the container instance if a
>
>     client  request
>
>                     attempts to create a child node instance within this
>
>     container.
>
>                    On Jul 30, 2016, at 11:52 AM, Andy Bierman
>
>        wrote:
>
>                    Hi,
>
>                    I strongly object to changing a vague MAY about deleting an
>
>     NP container
>
>                    after the last child has been deleted into several MUST
>
>     requirements.
>
>                    I propose this text instead:
>
>                    OLD:
>
>                       If a container does not have a "presence" statement and
>
>     the last
>
>                       child node is deleted, the NETCONF server MAY delete the
>
>     container.
>
>                    NEW:
>
>                       If a container does not have a "presence" statement and
>
>     the container instance
>
>                       does not have any child node instances, the NETCONF
>
>     server MAY delete the
>
>                       container. If the server does delete a container instance
>
>     in this case, it MUST
>
>                       re-create the container instance if a client
>
>      request attempts to create
>
>                       a child node instance within this container.
>
>                    Andy
>
>                    On Fri, Jul 22, 2016 at 3:13 AM, Balazs Lengyel
>
>        wrote:
>
>                      Hello,
>
>                      We seem to have fundamental differences whether
>
>     NP-containers exist/don't exist or if this question is even valid.  I
>
>     hope we can agree that as NP-containers are meaningless themselves they
>
>     MUST NOT influence Netconf operations or model validation. (Which is a
>
>     slight violation of Netconf-6241, which we should accept.)
>
>                      So I propose the following errata to rfc6020bis.
>
>                      As for non-presence containers the presence of the
>
>     container node with no child nodes is
>
>                      semantically equivalent to the absence of the container
>
>     node, configuration operations or
>
>                      model validation should never fail due to the existence or
>
>     non-existence of a non-presence containers. Specifically:
>
>                      - an   create operation for a non-presence
>
>     container MUST succeed even if the container already exists.
>
>                      - an   delete operation for a non-presence
>
>     container MUST succeed even if the container does not exist.
>
>                      - an   operation with default-operation=none
>
>     MUST succeed even if one or more  non-presence containers do not exist.
>
>                      Separately
>
>                      - a must statement defined as direct substatement of a
>
>     non-presence container SHALL be evaluated as part of model validation if
>
>     and only if one or more child data nodes exist in the instance data or
>
>     if there is a leaf or leaf-list child with a default value. As
>
>     non-presence containers are only used for organizing the hierarchy they
>
>     SHOULD NOT have any must substatements.
>
>                      IMO the above rules remove ambiguity and follow the
>
>     current philosophy of  RFC6020bis.
>
>                      If we have a basic agreement I can formulate the text
>
>     correctly.
>
>                      I don't know whether similar updates are needed for
>
>     RestConf.
>
>                      regards Balazs
>
>                      PS. I still believe introducing NP containers was a
>
>     mistake, however they are here to stay.
>
>                      On 2016-07-21 09:17, Jan Lindblad wrote:
>
>                        Xiang,
>
>                          Are you saying that since a NP-container is merely a
>
>     structure node, not config in any way, so creating/deleting it
>
>     explicitly (and repeatedly) is equivalent to a “no-op” that will
>
>     always succeed because doing so has no effect on the server’s config
>
>     in any way?
>
>                        That's correct. "Creating" an object with zero bits of
>
>     information is a no-op.
>
>                          If the sever has the following example config:
>
>                          
>
>                               
>
>                          
>
>                          If a client issues an edit-config with:
>
>                          < mycontainer operation="delete">
>
>                          The server returns “ok”,
>
>                          If then again  the client attempts:
>
>                          < mycontainer operation="delete">
>
>                          The server should still return  “ok”?
>
>                        Yes, that's correct in my opinion. It's a consequence of
>
>     the NP container nature as defined in the current RFC6020/YANG 1.0 and
>
>     bis.
>
>                          If so I think this is confusing. I think it would make
>
>     more sense in the latter case if the server returns “"data-missing”
>
>     error.
>
>                        This is logical if you think of NP containers as path
>
>     prefixes, and not as objects with information content. If you accept
>
>     that an NP container has zero bits of information, how would the server
>
>     even know whether the container exists or not? Not by looking in a
>
>     database, for sure.
>
>                        P containers have a single bit of information, so they
>
>     can be created, and the creation event/existence remembered by the
>
>     server. Not so for NP-containers.
>
>                          I understand we may advise a client not do so, but
>
>     since  RFC6020bis does not forbid this, and it is also a perfectly valid
>
>     , so I am sure people will try it.
>
>                        Yes. And it works today and is harmless.
>
>                        It's unfortunate that the YANG 1.0 and 1.1 specs aren't
>
>     crystal clear on the subject, but I believe the interpretation I and
>
>     others have of NP container behavior in RFC 6020 is consistent,
>
>     implementable and highly useful.
>
>                        /jan
>
>         --
>
>         Balazs Lengyel                       Ericsson Hungary Ltd.
>
>         Senior Specialist
>
>         Mobile: +36-70-330-7909              email:
>
>     Balazs.Lengyel@ericsson.com 
>
>                      _______________________________________________
>
>                      Netconf mailing list
>
>                      Netconf@ietf.org 
>
>                      https://www.ietf.org/mailman/listinfo/netconf
>
>                    _______________________________________________
>
>                    Netconf mailing list
>
>                    Netconf@ietf.org 
>
>                    https://www.ietf.org/mailman/listinfo/netconf
>
>                  Mahesh Jethanandani
>
>                  mjethanandani@gmail.com 
>
>         --
>
>         Balazs Lengyel                       Ericsson Hungary Ltd.
>
>         Senior Specialist
>
>         Mobile: +36-70-330-7909              email:
>
>     Balazs.Lengyel@ericsson.com 
>
>     ------------------------------------------------------------------------
>
>     --------
>
>         _______________________________________________
>
>         Netconf mailing list
>
>         Netconf@ietf.org 
>
>         https://www.ietf.org/mailman/listinfo/netconf
>
>     _______________________________________________
>
>     Netconf mailing list
>
>     Netconf@ietf.org 
>
>     https://www.ietf.org/mailman/listinfo/netconf
>


--------------FCA889EF9D399EFE6888304C
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Yes.

    
Thanks for the clarification,

      Rob

    

    

    
On 01/08/2016 14:58, Jonathan Hansford
      wrote:

    

    

      
      
      
      

        
Should 2(ii) not state “Servers should
          avoid erroring on a create/delete/none operation on an np
          container node that has no child nodes”?

        
 

        


          Jonathan

        
 

        

          
From:
            Robert Wilton

            Sent: 01 August 2016 14:42

            To: t.petch; Andy
              Bierman; Mahesh Jethanandani;
            Balazs Lengyel;
            Netconf

            Subject: Re: [Netconf] What should a server response
            be? - depending onNP-containers

        

        
 

        
Hi,

            

            My interpretation is that NP containers only exist to give
            structure to any nodes that exist below them and their
            existence is not intended to impart any meaning beyond this.

            

            The solution I would like to see is to maximize
            interoperability between NETCONF client and server
            implementations.  So suggest that:

            

            1) We clarify the text for "rfc6020bis-14#section-7.5.8"
            to make it clear that a server may delete an empty NP
            container at any time (rather than explicitly only when the
            last child element is deleted).  I.e. I propose the
            following change to 6020bis:

            

            OLD:

            "If a container does not have a "presence" statement and the
            last

               child node is deleted, the NETCONF server MAY delete the
            container." 

            

            NEW:

            "If a container does not have a "presence" statement and has
            no

              child nodes, then the NETCONF server MAY delete the
            container." 

            

            2) An errata to rfc6241 that, for the purpose of maximizing
            interoperability, recommends:

             (i) Clients should use merge/replace/remove operations for
            np container nodes.

             (ii) Servers should avoid erroring on a create/delete/none
            operation on an np container node.

            

            Thanks,

            Rob

            

          

        

          
On 01/08/2016 12:10, t.petch wrote:

        

        

          
----- Original Message -----

          
From: "Balazs Lengyel" <balazs.lengyel@ericsson.com>

          
Sent: Monday, August 01, 2016 9:55 AM

          
 

          

            
Hello,

            
 

            
As I see it:

            
 

            
- The main problem is we don't agree whether or when NP containers

          

          
exist. Some people think they should exist (or not) just as any other

          
data node. (me, Andy, RFC6241) while others believe the existence of the

          
NP containers  is not even a valid question (tailf). As we have such

          
basic differences, I propose to focus just on the specific protocol

          
cases that are problematic.

          
 

          
Balazs

          
 

          
As a practical engineer, it is obvious to me that they exist.   A

          
response to a NETCONF 'get' may, or may not, contain them so it affects

          
the XML I receive, so they exist, period.  When I read that they do not

          
convey any information, I surmise that this is a statement from

          
Information Theory for some meaning of the word Information which likely

          
I do not understand.  But so what? The specification of Yang says I may

          
see them so when I do, I know that they exist.  The specification is

          
also very clear that I cannot rely on seeing them (if no child node

          
exists); such imprecision may or may not be a good thing in a Standard

          
but the text is very clear and unambiguous on this point.  As ever, how

          
a server achieves this is up to the server; what matters is the

          
appearance presented to the rest of the world, imprecise as it may be.

          
 

          
Looking back, I read

          
 

          
'A distinct container should be used when encoding lists with multiple

          
instances ...'

          
'Some containers exist in the 'real world' and some are only modelling

          
artefacts.'

          
'Use of container elements allows simpler manipulation of lists and list

          
members.'

          
 

          
which, for me, is the rationale for the two types of containers we have.

          
A Non-Presence Container makes life simpler for the data modeller and

          
the user of the data model.

          
 

          
Tom Petch

          
 

          

            
- IMHO this problem means that the following 3 cases are not properly

          

          
defined and we need to clarify them. Saying the client should just not

          
use major parts of the protocol for NP-containers is wrong.

          

            
 

            
1) what happens if default-operation=none meets a non-existing NP

          

          
container

          

            
2) what happens if you create an NP-container and that already exists

          

          
e.g. you issue create twice

          

            
3) what happens if you delete an NP-container that does not exists

          

          
e.g. issue the delete twice

          

            
 

            
IMHO saying that from the 6 operation values 3 are undefined for

          

          
NP-container is not acceptable.

          

            
As we have protocol operations defined in RC6020 we need to define

          

          
them properly.

          

            
regards Balazs

            
 

            
 

            
On 2016-08-01 02:23, Andy Bierman wrote:

            
 

            
 

            
 

            
 

            
 

            
  On Sun, Jul 31, 2016 at 10:45 AM, Mahesh Jethanandani

          

          
<mjethanandani@gmail.com> wrote:

          

            
 

            
 

            
 

            
    On Jul 30, 2016, at 5:31 PM, Andy Bierman <andy@yumaworks.com>

          

          
wrote:

          

            
 

            
 

            
 

            
 

            
 

            
 

            
      On Sat, Jul 30, 2016 at 5:21 PM, Mahesh Jethanandani

          

          
<mjethanandani@gmail.com> wrote:

          

            
 

            
        Andy,

            
 

            
 

            
        The thread started because the RFC does not say anything about

          

          
a create of a NP container. It only talked about delete. Can we make the

          
(re-)create of the NP container unconditional to whether a delete was

          
performed on it. So a tweak to your proposal would be:

          

            
 

            
 

            
 

            
 

            
      The only reason that example did not work is because the server

          

          
deleted the NP containers

          

            
      after the client created them.  If the server does not delete

          

          
the containers then

          

            
      the 2nd RPC will not fail.

            
 

            
 

            
    I think this argument of whether server should or should not

          

          
create/delete NP containers is distracting from the main point of when

          
NP containers should exist. In my mind, the NP container existence

          
depends on whether child nodes exist or not. In the end, if child nodes

          
exist, NP containers should exist (created), if they do not exist, the

          
NP container should be removed.

          

            
 

            
 

            
    Can we agree on that?

            
 

            
 

            
 

            
 

            
  No.

            
 

            
 

            
  "should be removed" is an implementation choice.

            
  It started as MAY be removed.  It needs to stay that way.

            
 

            
 

            
  As I have pointed out 100 times,  the protocol has merge and replace

            
  for the situation where the client is not exactly aware of how

          

          
ceration and

          

            
  deletion will be handled on the server.

            
 

            
 

            
  There is no reason to force implementations to change.

            
  If you magically delete containers, then magically recreate them.

            
  If you don't then the nodes will be as the client expects, so no

          

          
problem.

          

            
 

            
 

            
 

            
 

            
  Andy

            
 

            
 

            
 

            
 

            
    P.s The errata will be much easier to craft if we can agree on

          

          
this.

          

            
 

            
 

            
 

            
 

            
      This can also be completely avoided by using the default

          

          
(merge).

          

            
      Since the client has to explicitly pick default-operation=none,

            
      it better know what it is doing.

            
      This is the same issue as a default leaf

            
      and the create operation.  Nothing special about NP containers.

            
 

            
 

            
      The <edit-config> for "create" will fail if the leaf already

          

          
exists

          

            
      and the "delete" will fail if the value is not there (just a

          

          
default).

          

            
      The work-around?  Use merge and remove, not create and delete.

            
      IMO the same logic applies here.

            
 

            
 

            
 

            
 

            
      Andy

            
 

            
 

            
 

            
 

            
 

            
 

            
 

            
 

            
        OLD:

            
 

            
 

            
           If a container does not have a "presence" statement and the

          

          
last

          

            
           child node is deleted, the NETCONF server MAY delete the

          

          
container.

          

            
 

            
 

            
        NEW:

            
 

            
 

            
           If a container does not have a "presence" statement and the

          

          
container instance

          

            
           does not have any child node instances, the NETCONF server

          

          
MAY delete the

          

            
           container. It MUST create the container instance if a

          

          
client <edit-config> request

          

            
           attempts to create a child node instance within this

          

          
container.

          

            
 

            
 

            
 

            
 

            
          On Jul 30, 2016, at 11:52 AM, Andy Bierman

          

          
<andy@yumaworks.com> wrote:

          

            
 

            
 

            
          Hi,

            
 

            
 

            
          I strongly object to changing a vague MAY about deleting an

          

          
NP container

          

            
          after the last child has been deleted into several MUST

          

          
requirements.

          

            
 

            
 

            
          I propose this text instead:

            
 

            
 

            
          OLD:

            
 

            
 

            
 

            
 

            
             If a container does not have a "presence" statement and

          

          
the last

          

            
             child node is deleted, the NETCONF server MAY delete the

          

          
container.

          

            
 

            
 

            
 

            
 

            
          NEW:

            
 

            
 

            
 

            
 

            
             If a container does not have a "presence" statement and

          

          
the container instance

          

            
             does not have any child node instances, the NETCONF

          

          
server MAY delete the

          

            
             container. If the server does delete a container instance

          

          
in this case, it MUST

          

            
             re-create the container instance if a client

          

          
<edit-config> request attempts to create

          

            
             a child node instance within this container.

            
 

            
 

            
 

            
 

            
 

            
 

            
 

            
 

            
          Andy

            
 

            
 

            
 

            
 

            
          On Fri, Jul 22, 2016 at 3:13 AM, Balazs Lengyel

          

          
<balazs.lengyel@ericsson.com> wrote:

          

            
 

            
            Hello,

            
 

            
 

            
            We seem to have fundamental differences whether

          

          
NP-containers exist/don't exist or if this question is even valid.  I

          
hope we can agree that as NP-containers are meaningless themselves they

          
MUST NOT influence Netconf operations or model validation. (Which is a

          
slight violation of Netconf-6241, which we should accept.)

          

            
 

            
 

            
            So I propose the following errata to rfc6020bis.

            
 

            
            As for non-presence containers the presence of the

          

          
container node with no child nodes is

          

            
            semantically equivalent to the absence of the container

          

          
node, configuration operations or

          

            
            model validation should never fail due to the existence or

          

          
non-existence of a non-presence containers. Specifically:

          

            
 

            
            - an <edit-config>  create operation for a non-presence

          

          
container MUST succeed even if the container already exists.

          

            
            - an <edit-config>  delete operation for a non-presence

          

          
container MUST succeed even if the container does not exist.

          

            
            - an <edit-config>  operation with default-operation=none

          

          
MUST succeed even if one or more  non-presence containers do not exist.

          

            
 

            
 

            
            Separately

            
            - a must statement defined as direct substatement of a

          

          
non-presence container SHALL be evaluated as part of model validation if

          
and only if one or more child data nodes exist in the instance data or

          
if there is a leaf or leaf-list child with a default value. As

          
non-presence containers are only used for organizing the hierarchy they

          
SHOULD NOT have any must substatements.

          

            
 

            
            IMO the above rules remove ambiguity and follow the

          

          
current philosophy of  RFC6020bis.

          

            
            If we have a basic agreement I can formulate the text

          

          
correctly.

          

            
 

            
            I don't know whether similar updates are needed for

          

          
RestConf.

          

            
            regards Balazs

            
 

            
            PS. I still believe introducing NP containers was a

          

          
mistake, however they are here to stay.

          

            
 

            
 

            
            On 2016-07-21 09:17, Jan Lindblad wrote:

            
 

            
              Xiang,

            
 

            
 

            
                Are you saying that since a NP-container is merely a

          

          
structure node, not config in any way, so creating/deleting it

          
explicitly (and repeatedly) is equivalent to a “no-op” that will

          
always succeed because doing so has no effect on the server’s config

          
in any way?

          

            
 

            
 

            
              That's correct. "Creating" an object with zero bits of

          

          
information is a no-op.

          

            
 

            
 

            
                If the sever has the following example config:

            
                <mycontainer>

            
                     <child  ... bla..bla…configs>

            
                </mycontainer>

            
 

            
 

            
                If a client issues an edit-config with:

            
                < mycontainer operation="delete">

            
 

            
                The server returns “ok”,

            
 

            
                If then again  the client attempts:

            
 

            
                < mycontainer operation="delete">

            
 

            
                The server should still return  “ok”?

            
 

            
 

            
              Yes, that's correct in my opinion. It's a consequence of

          

          
the NP container nature as defined in the current RFC6020/YANG 1.0 and

          
bis.

          

            
 

            
                If so I think this is confusing. I think it would make

          

          
more sense in the latter case if the server returns “"data-missing”

          
error.

          

            
 

            
 

            
              This is logical if you think of NP containers as path

          

          
prefixes, and not as objects with information content. If you accept

          
that an NP container has zero bits of information, how would the server

          
even know whether the container exists or not? Not by looking in a

          
database, for sure.

          

            
 

            
 

            
              P containers have a single bit of information, so they

          

          
can be created, and the creation event/existence remembered by the

          
server. Not so for NP-containers.

          

            
 

            
 

            
                I understand we may advise a client not do so, but

          

          
since  RFC6020bis does not forbid this, and it is also a perfectly valid

          
<edit-config>, so I am sure people will try it.

          

            
 

            
 

            
              Yes. And it works today and is harmless.

            
 

            
 

            
              It's unfortunate that the YANG 1.0 and 1.1 specs aren't

          

          
crystal clear on the subject, but I believe the interpretation I and

          
others have of NP container behavior in RFC 6020 is consistent,

          
implementable and highly useful.

          

            
 

            
 

            
              /jan

            
 

            
 

            
 

            
 

            
--

            
Balazs Lengyel                       Ericsson Hungary Ltd.

            
Senior Specialist

            
Mobile: +36-70-330-7909              email:

          

          
Balazs.Lengyel@ericsson.com

          

            
 

            
            _______________________________________________

            
            Netconf mailing list

            
            Netconf@ietf.org

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

            
 

            
 

            
 

            
 

            
          _______________________________________________

            
          Netconf mailing list

            
          Netconf@ietf.org

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

            
 

            
 

            
 

            
        Mahesh Jethanandani

            
        mjethanandani@gmail.com

            
 

            
 

            
 

            
 

            
 

            
 

            
 

            
 

            
 

            
 

            
 

            
 

            
 

            
 

            
 

            
--

            
Balazs Lengyel                       Ericsson Hungary Ltd.

            
Senior Specialist

            
Mobile: +36-70-330-7909              email:

          

          
Balazs.Lengyel@ericsson.com

          

            
 

          

          
 

          
 

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

          
--------

          
 

          
 

          

            
_______________________________________________

            
Netconf mailing list

            
Netconf@ietf.org

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

            
 

          

          
 

          
_______________________________________________

          
Netconf mailing list

          
Netconf@ietf.org

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

        

        
 

        
 

      

    

    

  


--------------FCA889EF9D399EFE6888304C--


From nobody Mon Aug  1 07:23:27 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEA8E12D69A for ; Mon,  1 Aug 2016 07:23:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sEaK_7AL_-W for ; Mon,  1 Aug 2016 07:23:21 -0700 (PDT)
Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 5D16112D10C for ; Mon,  1 Aug 2016 07:23:21 -0700 (PDT)
Received: by mail-ua0-x22d.google.com with SMTP id j59so107147317uaj.3 for ; Mon, 01 Aug 2016 07:23:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bVeJujAvRzxCQFIp+EIVDhGeR3fh6/LDSjSXG01vwgM=; b=Yufe/vyRUbtEfkABXQN37NKYBlSqVkV65EWpHkJIycQ93+y968JfYIT4fT0V0JeVti nYDEyFdR2ytX/S3MVzMCPUTJTJNSncciVYfIQteE3N47d1gnLoQoCM/ThfHZEpogpAft b7f9ttDYOHVSu+DtFEppjmwhgXO8l749xSw30/eRoBLwRbPON2SdVMFUpxvq7q/Nm9ti ll1MscQ7mU09+OvsS8g/il3efGa54Aksd8CTEPad7K6NT2kXdT4jiQ2pFtjAZ6z9n75I DLTSqR9+huS2pGvH/DC63Mmy5tG5ZM5kTv5pQIme4XxfCX1sr9xaBgJGeQOneblHdmuM mC5Q==
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:from:date :message-id:subject:to:cc; bh=bVeJujAvRzxCQFIp+EIVDhGeR3fh6/LDSjSXG01vwgM=; b=dG8LtqnSc30/ib3jNmzRR2lHaLz3AyG9R76GrugfO6R7F+vgtanyBmBWApxkhXpMIH dnx/EUSYy5YEzp8DnVb41mQrvSP0H0R+MEbu2rqIMSNMs1PMfuqPz7PRy1Y6Z1cpYoo+ PfTU7/Pl6KXz4B5pwjXI8Ko7Eze+26OC0sBubib2GUJGEfT3/fcWmyDe305qmDzqvB5m huQDFh8/U9dOXirRDPg9TQx/pV8Vj30bsvSuqo4xYhegXidQTnJDWP28HYKzo9r9UjDE zg/qv1r8FBrcetSSE4lM0vf8xezYS5pWCpRf06At+rP0tTrEUNOuEDBkivCVh4nohrdF G1dQ==
X-Gm-Message-State: AEkoouunaFk1PhKTgGg9A3RAEkpq4XwqvAwMDDgzOnowAPfjxtQfKW1M6XrYrVW0tWq5olb11s7C6ZadfIWkTw==
X-Received: by 10.176.67.4 with SMTP id k4mr26254550uak.47.1470061400499; Mon, 01 Aug 2016 07:23:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Mon, 1 Aug 2016 07:23:19 -0700 (PDT)
In-Reply-To: 
References:  <87vazljnps.fsf@hobgoblin.ariadne.com>  
From: Andy Bierman 
Date: Mon, 1 Aug 2016 07:23:19 -0700
Message-ID: 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=94eb2c09507a933f470539035744
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 Aug 2016 14:23:26 -0000

--94eb2c09507a933f470539035744
Content-Type: text/plain; charset=UTF-8

On Mon, Aug 1, 2016 at 7:13 AM, Ladislav Lhotka  wrote:

> Andy Bierman  writes:
>
> > Hi,
> >
> > YANG 1.1 has been changed so the XPath is not really backward-compatible
> > with YANG 1.0.  In YANG 1.1 NP-containers always exist if the non-NP
> parent
> > is
> > instantiated.
>
> My mental model regarding NP-containers is that they are part of
> the default contents of a datastore. If an NP-container is "in use"
> (according to the same rules as specified in sec. 7.6.1 of 6020bis for
> default leaves), then
>
> - creating a child of this container succeeds,
>
> - "must" expressions defined on this container apply.
>
>

NP containers were not always present in YANG 1.0.
The must-stmt only applied if they actually are present,
which is an implementation choice.

I don't understand all this special wording about "do not error if..."

NETCONF has explicit support for this exact use-case, called "merge".
This was done precisely to support these "don't error if..." cases.
So use "merge" if you want this functionality.



> Lada
>

Andy


>
> >
> > NETCONF and RESTCONF do not say anything about the server ignoring
> > the rules for operation="create", operation="delete" and
> > default-operation="none".
> > IMO itr would be a really bad idea to continue spreading little protocol
> > details
> > in the YANG RFC.  People might read the protocol spec and (correctly)
> assume
> > that the protocol does not trat NP containers special at all.
> >
> > If anything, the sentence about MAY delete needs to be removed because
> > it is inconsistent with the XPath (always exists).
> >
> >
> > Andy
> >
> >
> > On Sun, Jul 31, 2016 at 6:13 PM, Dale R. Worley 
> wrote:
> >
> >> Mahesh Jethanandani  writes:
> >> > I think this argument of whether server should or should not
> >> > create/delete NP containers is distracting from the main point of when
> >> > NP containers should exist. In my mind, the NP container existence
> >> > depends on whether child nodes exist or not. In the end, if child
> >> > nodes exist, NP containers should exist (created), if they do not
> >> > exist, the NP container should be removed.
> >> >
> >> > Can we agree on that?
> >>
> >> If the concept of a "non-presence container" makes any sense, then the
> >> existence of an empty container must have exactly the same significance
> >> as the non-extence of the container.
> >>
> >> Given that, we have to make sure the protocol is consistent with that
> >> principle.  E.g., if you ask to create an element of a non-existing NP
> >> container, it must succeed, because asking to create an element of an
> >> existing but empty NP container succeeds.
> >>
> >> I don't see what all the consequences of this principle are, but if we
> >> can't make the protocol consistent with it, then we can't properly
> >> implement the concept of NP containers.
> >>
> >> Dale
> >>
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>

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




On Mon, Aug 1, 2016 at 7:13 AM, Ladislav Lhotka <<=
a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz> wrote:
Andy Bierman <andy@yumaworks.com> writes:



> Hi,

>

> YANG 1.1 has been changed so the XPath is not really backward-compatib=
le

> with YANG 1.0.=C2=A0 In YANG 1.1 NP-containers always exist if the non=
-NP parent

> is

> instantiated.



My mental model regarding NP-containers is that they are part of

the default contents of a datastore. If an NP-container is "in use&quo=
t;

(according to the same rules as specified in sec. 7.6.1 of 6020bis for

default leaves), then



- creating a child of this container succeeds,



- "must" expressions defined on this container apply.




NP containers were not =
always present in YANG 1.0.
The must-stmt only applied if they ac=
tually are present,
which is an implementation choice.
=

I don't understand all this special wording about "=
do not error if..."

NETCONF has explicit supp=
ort for this exact use-case, called "merge".
This was d=
one precisely to support these "don't error if..." cases.
So use "merge" if you want this functionality.=C2=A0
=


=C2=A0

Lada

Andy
=C2=A0



>

> NETCONF and RESTCONF do not say anything about the server ignoring

> the rules for operation=3D"create", operation=3D"delete=
" and

> default-operation=3D"none".

> IMO itr would be a really bad idea to continue spreading little protoc=
ol

> details

> in the YANG RFC.=C2=A0 People might read the protocol spec and (correc=
tly) assume

> that the protocol does not trat NP containers special at all.

>

> If anything, the sentence about MAY delete needs to be removed because=


> it is inconsistent with the XPath (always exists).

>

>

> Andy

>

>

> On Sun, Jul 31, 2016 at 6:13 PM, Dale R. Worley <worley@ariadne.com> wrote:

>

>> Mahesh Jethanandani <mjethanandani@gmail.com> writes:

>> > I think this argument of whether server should or should not<=
br>
>> > create/delete NP containers is distracting from the main poin=
t of when

>> > NP containers should exist. In my mind, the NP container exis=
tence

>> > depends on whether child nodes exist or not. In the end, if c=
hild

>> > nodes exist, NP containers should exist (created), if they do=
 not

>> > exist, the NP container should be removed.

>> >

>> > Can we agree on that?

>>

>> If the concept of a "non-presence container" makes any s=
ense, then the

>> existence of an empty container must have exactly the same signifi=
cance

>> as the non-extence of the container.

>>

>> Given that, we have to make sure the protocol is consistent with t=
hat

>> principle.=C2=A0 E.g., if you ask to create an element of a non-ex=
isting NP

>> container, it must succeed, because asking to create an element of=
 an

>> existing but empty NP container succeeds.

>>

>> I don't see what all the consequences of this principle are, b=
ut if we

>> can't make the protocol consistent with it, then we can't =
properly

>> implement the concept of NP containers.

>>

>> Dale

>>

> _______________________________________________

> Netconf mailing list

> Netconf@ietf.org

> https://www.ietf.org/mailman/listinfo/netconf<=
br>


--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C





--94eb2c09507a933f470539035744--


From nobody Mon Aug  1 07:30:21 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06B812D195 for ; Mon,  1 Aug 2016 07:30:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtHtX9qD46dQ for ; Mon,  1 Aug 2016 07:30:17 -0700 (PDT)
Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B20CC12D1AC for ; Mon,  1 Aug 2016 07:30:13 -0700 (PDT)
Received: by mail-oi0-x235.google.com with SMTP id w18so194719130oiw.3 for ; Mon, 01 Aug 2016 07:30:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=f1c2kqwuL+4mWcbVn9PK5GMUJZm2wiXWzD43j49q3rY=; b=0u6NHMEr7hcM/jGeybZIaGv4weBaR7qyQCaRErjw9Y+0KGhw+TLw1DyaOsonSwkYm1 IWtDHmR1jDSCs8k8Ewy0dduBd5X5qxXrPZCWrWjEvfychAvSpH0VrscxTF5m7Y7lTbKZ PrdWm+GKSm5DzP0F/+zHVK6uwBLFAR64/EejJechDMKAmNVoR8RYS1SObFdwmjBhz+X2 DTTbShqDCXs71aSFFloYtgbAOoQZDr824B0IxAAeTl/ex/NJLEB7DEb+3eVisOh4+NrN rPGF7oxzFsObqhOUohThT5ubKMGWyLeeRlklByqM67IM4o473VZa//vgIipJtTu21qZk yd6A==
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:from:date :message-id:subject:to:cc; bh=f1c2kqwuL+4mWcbVn9PK5GMUJZm2wiXWzD43j49q3rY=; b=C7w+X6ph9OQIAqOVuT/tRhhNmOsFUFhvjJyOGNaSsxbfL2CifAl608Nm9gCLAQvWgY 7BXv6KRqa0nrRGVja/xYAxtkdfnzy0tt9KoSaAK34HbfEdc1y9aRRFAGVCZbL5FJzRwc kQ34QwhOF+JCgUio9PYrNmyuruBlnISV7gKiQUx/igD+ERHxeybGzuudNfYPpsTmLpQk /S+QPx3M3Eqhtf+z7uiVS8NmcLfrUhSH5b+8q3kN7b+jzxM6qfrv3j0W0BZ/iugjlWeG bPwwFMHizXb90lddg3ztMWCXU0zMTDkaq1WzxjFekAte2hAXne+b6TI9ad0F8YrDtwEO golg==
X-Gm-Message-State: AEkoouuriDbRBBajC3A4f6IJzBMl81sQNL1SPv7RImvsPyferfPsBRYs7kUQGlhOesxOQKnGscbz3GdLNJyyNw==
X-Received: by 10.202.213.72 with SMTP id m69mr33871204oig.87.1470061812970; Mon, 01 Aug 2016 07:30:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.73.19 with HTTP; Mon, 1 Aug 2016 07:30:11 -0700 (PDT)
In-Reply-To: <002401d1ebfd$7ee2c8a0$4001a8c0@gateway.2wire.net>
References: <001c01d1e299$e057a910$a106fb30$@seguesoft.com>  <6e416198-13bd-81e3-545e-35e8bfc61536@ericsson.com>      <016801d1ebd9$cb9c3e20$4001a8c0@gateway.2wire.net>  <20160801102255.GB7476@elstar.local> <30B6D9D0-1E0D-4848-99C2-ACCCC27237AC@gmail.com> <002401d1ebfd$7ee2c8a0$4001a8c0@gateway.2wire.net>
From: Andy Bierman 
Date: Mon, 1 Aug 2016 07:30:11 -0700
Message-ID: 
To: "t.petch" 
Content-Type: multipart/alternative; boundary=001a113de40a290c7b05390370bd
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 Aug 2016 14:30:20 -0000

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

On Mon, Aug 1, 2016 at 7:02 AM, t.petch  wrote:

> ----- Original Message -----
> From: "Mahesh Jethanandani" 
> Sent: Monday, August 01, 2016 12:41 PM
>
> > On Aug 1, 2016, at 6:22 AM, Juergen Schoenwaelder
>  wrote:
> >
> > I agree with Tom and the 'solution' is IMHO to encourage clients to
> > use 'merge' instead of assuming a certain behavior here.
>
> Agree.
>
> How do we articulate that in the RFC?
>
>

There are many ways the client can prevent this issue:

 1) use default-operation=merge
 2) use an explicit nc:operation="merge" attribute in the NP-container node
 3) make sure to create a child node of the NP-container (or know the
     server is going to create child operational  nodes)

IMO the server SHOULD NOT delete client-created NP containers
because YANG 1.1 XPath says they are there even if they get deleted.



>
>

Andy


> s.7.5.8.end
>
> A client cannot know whether or not a server has deleted a Non-Presence
> Container when the last child node has been deleted and so cannot know
> whether a "create" or "delete" will succeed or return an error.  The
> client should use "merge" or "replace" instead of "create".
>
> Tom Petch
>
> > /js
> >
> > On Mon, Aug 01, 2016 at 12:19:55PM +0200, Balazs Lengyel wrote:
> >> IMHO not defining what happens is the worst solution. Any solution is
> >> better. If we can't agree, we should follow the Postel principle: be
> liberal
> >> in what you accept.
> >>
> >> regards Balazs
> >>
> >>
> >> On 2016-08-01 11:47, t.petch wrote:
> >>> 
> >>>
> >>> I think that Andy is spot on.  We currently have a simple, clear
> rule in
> >>> NETCONF:
> >>> - delete, does not exist, error
> >>> - create, does exist, error.
> >>>
> >>> Introducing corner cases that blur the rules, that allow users to be
> >>> imprecise, whether by Standards Track RFC or an Erratum,
> >>> I think a mistake
> >>>
> >>> An Erratum that points out that since a server may silently delete a
> >>> Non-Presence Container with no children, a user can never know
> whether
> >>> or not such a Container exists and so cannot know whether a delete
> or
> >>> create to be an error or not, yes, that is fine.  Going beyond that
> is a
> >>> protocol change (which I would resist even in an RFC).
> >>>
> >>> Tom Petch
> >>
> >> --
> >> Balazs Lengyel                       Ericsson Hungary Ltd.
> >> Senior Specialist
> >> Mobile: +36-70-330-7909              email:
> Balazs.Lengyel@ericsson.com
> >>
> >> _______________________________________________
> >> Netconf mailing list
> >> Netconf@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netconf
> >
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103         
>
> Mahesh Jethanandani
> mjethanandani@gmail.com
>
>
>
>

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




On Mon, Aug 1, 2016 at 7:02 AM, t.petch <ietfc@btconnect.com&g=
t; wrote:
----- Original Message -=
----

From: "Mahesh Jethanandani" <mjethanandani@gmail.com>

Sent: Monday, August 01, 2016 12:41 PM



> On Aug 1, 2016, at 6:22 AM, Juergen Schoenwaelder

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

>

> I agree with Tom and the 'solution' is IMHO to encourage clien=
ts to

> use 'merge' instead of assuming a certain behavior here.



Agree.



How do we articulate that in the RFC?




There are many ways the=
 client can prevent this issue:

=C2=A01) use defau=
lt-operation=3Dmerge
=C2=A02) use an explicit nc:operation=3D&quo=
t;merge" attribute in the NP-container node
=C2=A03) make su=
re to create a child node of the NP-container (or know the
=C2=A0=
 =C2=A0 =C2=A0server is going to create child operational =C2=A0nodes)

IMO the server SHOULD NOT delete client-created NP con=
tainers
because YANG 1.1 XPath says they are there even if they g=
et deleted.



<tp>




Andy
=C2=A0

s.7.5.8.end



A client cannot know whether or not a server has deleted a Non-Presence

Container when the last child node has been deleted and so cannot know

whether a "create" or "delete" will succeed or return a=
n error.=C2=A0 The

client should use "merge" or "replace" instead of "=
;create".



Tom Petch



> /js

>

> On Mon, Aug 01, 2016 at 12:19:55PM +0200, Balazs Lengyel wrote:

>> IMHO not defining what happens is the worst solution. Any solution=
 is

>> better. If we can't agree, we should follow the Postel princip=
le: be

liberal

>> in what you accept.

>>

>> regards Balazs

>>

>>

>> On 2016-08-01 11:47, t.petch wrote:

>>> <tp>

>>>

>>> I think that Andy is spot on.=C2=A0 We currently have a simple=
, clear

rule in

>>> NETCONF:

>>> - delete, does not exist, error

>>> - create, does exist, error.

>>>

>>> Introducing corner cases that blur the rules, that allow users=
 to be

>>> imprecise, whether by Standards Track RFC or an Erratum,

>>> I think a mistake

>>>

>>> An Erratum that points out that since a server may silently de=
lete a

>>> Non-Presence Container with no children, a user can never know=


whether

>>> or not such a Container exists and so cannot know whether a de=
lete

or

>>> create to be an error or not, yes, that is fine.=C2=A0 Going b=
eyond that

is a

>>> protocol change (which I would resist even in an RFC).

>>>

>>> Tom Petch

>>

>> --

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

>> Mobile: +36-70-330-7909=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 email:

Balazs.Lengyel@ericsson.com<=
/a>

>>

>> _______________________________________________

>> Netconf mailing list

>> Netconf@ietf.org

>> https://www.ietf.org/mailman/listinfo/netconf<=
/a>

>

> --

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



Mahesh Jethanandani

mjethanandani@gmail.com











--001a113de40a290c7b05390370bd--


From nobody Mon Aug  1 07:32:11 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7FA12D195 for ; Mon,  1 Aug 2016 07:32:10 -0700 (PDT)
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 autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYPV-QH0HKxR for ; Mon,  1 Aug 2016 07:32:06 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 BF0BB12D672 for ; Mon,  1 Aug 2016 07:32:05 -0700 (PDT)
X-AuditID: c1b4fb3a-0618b980000009bd-5e-579f5d63971f
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by  (Symantec Mail Security) with SMTP id 1B.A3.02493.36D5F975; Mon,  1 Aug 2016 16:32:03 +0200 (CEST)
Received: from [159.107.197.181] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.301.0; Mon, 1 Aug 2016 16:32:02 +0200
To: Robert Wilton , t.petch , Andy Bierman , Mahesh Jethanandani , Netconf 
References: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com> <7DE2E560-FBB4-463C-9E94-C91B7DBDA60C@tail-f.com> <57892746.5020903@seguesoft.com>  <57893742.6040903@seguesoft.com> <652B16E7-D5E4-4CDE-8AD9-291C6937EE6B@tail-f.com>  <001c01d1e299$e057a910$a106fb30$@seguesoft.com>  <6e416198-13bd-81e3-545e-35e8bfc61536@ericsson.com>       <005a01d1ebe5$6ee080e0$4001a8c0@gateway.2wire.net> 
From: Balazs Lengyel 
Message-ID: 
Date: Mon, 1 Aug 2016 16:32:02 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM2K7rm5y7PxwgzMTDC0eHJnFbnHt0X0W i9Nv1rFZTN10m9XixLk+ZgdWj11Hf7B7TPm9kdVj56y77B5Llvxk8mjpv8gSwBrFZZOSmpNZ llqkb5fAlfHw0DnGgqY9jBVzn29mbGDsa2PsYuTgkBAwkXj7jb+LkYtDSGA9o8STrpdsXYyc QM4aRonzP8BsYYFwibdP17CBFIkIbGOUONJ3nQmi4xm7xM331xhBqtgEjCSm9p9nAbF5Bewl zj7aBdbNIqAicav9DCvINlGBGIn1fQkQJYISJ2c+ASvnFLCVWLpkCZjNLKAh0TpnLjuELS/R vHU2M8RBGhIPL/xlncDIPwtJ+ywkLbOQtCxgZF7FKFqcWlycm25kpJdalJlcXJyfp5eXWrKJ ERi+B7f8ttrBePC54yFGAQ5GJR7eBJZ54UKsiWXFlbmHGCU4mJVEeN8FzQ8X4k1JrKxKLcqP LyrNSS0+xCjNwaIkzuv/UjFcSCA9sSQ1OzW1ILUIJsvEwSnVwDixXTKmKeDaf3PJX4e/Cuqz Ns+5/6yjoPLD0hdvvvgF+Ol3+l6XvrS+S+fpzUd8PFp/pl+QbJwbzqz1/c+VV6JsC34anWBo sz+Z0zcjvbBOT+uahLHgZ+c1bEsl6m/FWc4vF3JtT4j2TWRcXxm7qF5QaErPMn7ra3PC99zK uDTD4Jn6GvXQIiWW4oxEQy3mouJEAG0GDC9bAgAA
Archived-At: 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 Aug 2016 14:32:10 -0000


  
    
  
  
    
2i) Telling the client: you better not use parts of the RFC
      (none/create/delete) because they are not defined in an
      interoperable way is strange

    
2ii) Using the term SHOULD instead of MUST still means the
      operation is equally justified to send back OK or ERROR. IMHO it
      we should use MUST/SHALL not SHOULD. It is better than nothing
      thought.

    

    
Balazs

    

    

    
On 2016-08-01 15:31, Robert Wilton
      wrote:

    

    

      
      Hi,

      

      My interpretation is that NP containers only exist to give
      structure to any nodes that exist below them and their existence
      is not intended to impart any meaning beyond this.

      

      The solution I would like to see is to maximize interoperability
      between NETCONF client and server implementations.  So suggest
      that:

      

      1) We clarify the text for "rfc6020bis-14#section-7.5.8"
      to make it clear that a server may delete an empty NP container at
      any time (rather than explicitly only when the last child element
      is deleted).  I.e. I propose the following change to 6020bis:

      

      OLD:

      "If a container does not have a "presence" statement and the last

         child node is deleted, the NETCONF server MAY delete the
      container." 

      

      NEW:

      "If a container does not have a "presence" statement and has no

        child nodes, then the NETCONF server MAY delete the container."
      

      

      2) An errata to rfc6241 that, for the purpose of maximizing
      interoperability, recommends:

       (i) Clients should use merge/replace/remove operations for np
      container nodes.

       (ii) Servers should avoid erroring on a create/delete/none
      operation on an np container node.

      

      Thanks,

      Rob

      

      

      
On 01/08/2016 12:10, t.petch wrote:

      

      

        
----- Original Message -----
From: "Balazs Lengyel" <balazs.lengyel@ericsson.com>
Sent: Monday, August 01, 2016 9:55 AM



        

          
Hello,

As I see it:

- The main problem is we don't agree whether or when NP containers


        

        
exist. Some people think they should exist (or not) just as any other
data node. (me, Andy, RFC6241) while others believe the existence of the
NP containers  is not even a valid question (tailf). As we have such
basic differences, I propose to focus just on the specific protocol
cases that are problematic.

Balazs

As a practical engineer, it is obvious to me that they exist.   A
response to a NETCONF 'get' may, or may not, contain them so it affects
the XML I receive, so they exist, period.  When I read that they do not
convey any information, I surmise that this is a statement from
Information Theory for some meaning of the word Information which likely
I do not understand.  But so what? The specification of Yang says I may
see them so when I do, I know that they exist.  The specification is
also very clear that I cannot rely on seeing them (if no child node
exists); such imprecision may or may not be a good thing in a Standard
but the text is very clear and unambiguous on this point.  As ever, how
a server achieves this is up to the server; what matters is the
appearance presented to the rest of the world, imprecise as it may be.

Looking back, I read

'A distinct container should be used when encoding lists with multiple
instances ...'
'Some containers exist in the 'real world' and some are only modelling
artefacts.'
'Use of container elements allows simpler manipulation of lists and list
members.'

which, for me, is the rationale for the two types of containers we have.
A Non-Presence Container makes life simpler for the data modeller and
the user of the data model.

Tom Petch



        

          
- IMHO this problem means that the following 3 cases are not properly


        

        
defined and we need to clarify them. Saying the client should just not
use major parts of the protocol for NP-containers is wrong.


        

          
1) what happens if default-operation=none meets a non-existing NP


        

        
container


        

          
2) what happens if you create an NP-container and that already exists


        

        
e.g. you issue create twice


        

          
3) what happens if you delete an NP-container that does not exists


        

        
e.g. issue the delete twice


        

          
IMHO saying that from the 6 operation values 3 are undefined for


        

        
NP-container is not acceptable.


        

          
As we have protocol operations defined in RC6020 we need to define


        

        
them properly.


        

          
regards Balazs


On 2016-08-01 02:23, Andy Bierman wrote:





  On Sun, Jul 31, 2016 at 10:45 AM, Mahesh Jethanandani


        

        
<mjethanandani@gmail.com> wrote:


        

          

    On Jul 30, 2016, at 5:31 PM, Andy Bierman <andy@yumaworks.com>


        

        
wrote:


        

          




      On Sat, Jul 30, 2016 at 5:21 PM, Mahesh Jethanandani


        

        
<mjethanandani@gmail.com> wrote:


        

          
        Andy,


        The thread started because the RFC does not say anything about


        

        
a create of a NP container. It only talked about delete. Can we make the
(re-)create of the NP container unconditional to whether a delete was
performed on it. So a tweak to your proposal would be:


        

          


      The only reason that example did not work is because the server


        

        
deleted the NP containers


        

          
      after the client created them.  If the server does not delete


        

        
the containers then


        

          
      the 2nd RPC will not fail.


    I think this argument of whether server should or should not


        

        
create/delete NP containers is distracting from the main point of when
NP containers should exist. In my mind, the NP container existence
depends on whether child nodes exist or not. In the end, if child nodes
exist, NP containers should exist (created), if they do not exist, the
NP container should be removed.


        

          
    Can we agree on that?




  No.


  "should be removed" is an implementation choice.
  It started as MAY be removed.  It needs to stay that way.


  As I have pointed out 100 times,  the protocol has merge and replace
  for the situation where the client is not exactly aware of how


        

        
ceration and


        

          
  deletion will be handled on the server.


  There is no reason to force implementations to change.
  If you magically delete containers, then magically recreate them.
  If you don't then the nodes will be as the client expects, so no


        

        
problem.


        

          


  Andy




    P.s The errata will be much easier to craft if we can agree on


        

        
this.


        

          


      This can also be completely avoided by using the default


        

        
(merge).


        

          
      Since the client has to explicitly pick default-operation=none,
      it better know what it is doing.
      This is the same issue as a default leaf
      and the create operation.  Nothing special about NP containers.


      The <edit-config> for "create" will fail if the leaf already


        

        
exists


        

          
      and the "delete" will fail if the value is not there (just a


        

        
default).


        

          
      The work-around?  Use merge and remove, not create and delete.
      IMO the same logic applies here.




      Andy








        OLD:


           If a container does not have a "presence" statement and the


        

        
last


        

          
           child node is deleted, the NETCONF server MAY delete the


        

        
container.


        

          
        NEW:


           If a container does not have a "presence" statement and the


        

        
container instance


        

          
           does not have any child node instances, the NETCONF server


        

        
MAY delete the


        

          
           container. It MUST create the container instance if a


        

        
client <edit-config> request


        

          
           attempts to create a child node instance within this


        

        
container.


        

          


          On Jul 30, 2016, at 11:52 AM, Andy Bierman


        

        
<andy@yumaworks.com> wrote:


        

          
          Hi,


          I strongly object to changing a vague MAY about deleting an


        

        
NP container


        

          
          after the last child has been deleted into several MUST


        

        
requirements.


        

          
          I propose this text instead:


          OLD:




             If a container does not have a "presence" statement and


        

        
the last


        

          
             child node is deleted, the NETCONF server MAY delete the


        

        
container.


        

          


          NEW:




             If a container does not have a "presence" statement and


        

        
the container instance


        

          
             does not have any child node instances, the NETCONF


        

        
server MAY delete the


        

          
             container. If the server does delete a container instance


        

        
in this case, it MUST


        

          
             re-create the container instance if a client


        

        
<edit-config> request attempts to create


        

          
             a child node instance within this container.








          Andy




          On Fri, Jul 22, 2016 at 3:13 AM, Balazs Lengyel


        

        
<balazs.lengyel@ericsson.com> wrote:


        

          
            Hello,


            We seem to have fundamental differences whether


        

        
NP-containers exist/don't exist or if this question is even valid.  I
hope we can agree that as NP-containers are meaningless themselves they
MUST NOT influence Netconf operations or model validation. (Which is a
slight violation of Netconf-6241, which we should accept.)


        

          
            So I propose the following errata to rfc6020bis.

            As for non-presence containers the presence of the


        

        
container node with no child nodes is


        

          
            semantically equivalent to the absence of the container


        

        
node, configuration operations or


        

          
            model validation should never fail due to the existence or


        

        
non-existence of a non-presence containers. Specifically:


        

          
            - an <edit-config>  create operation for a non-presence


        

        
container MUST succeed even if the container already exists.


        

          
            - an <edit-config>  delete operation for a non-presence


        

        
container MUST succeed even if the container does not exist.


        

          
            - an <edit-config>  operation with default-operation=none


        

        
MUST succeed even if one or more  non-presence containers do not exist.


        

          
            Separately
            - a must statement defined as direct substatement of a


        

        
non-presence container SHALL be evaluated as part of model validation if
and only if one or more child data nodes exist in the instance data or
if there is a leaf or leaf-list child with a default value. As
non-presence containers are only used for organizing the hierarchy they
SHOULD NOT have any must substatements.


        

          
            IMO the above rules remove ambiguity and follow the


        

        
current philosophy of  RFC6020bis.


        

          
            If we have a basic agreement I can formulate the text


        

        
correctly.


        

          
            I don't know whether similar updates are needed for


        

        
RestConf.


        

          
            regards Balazs

            PS. I still believe introducing NP containers was a


        

        
mistake, however they are here to stay.


        

          
            On 2016-07-21 09:17, Jan Lindblad wrote:

              Xiang,


                Are you saying that since a NP-container is merely a


        

        
structure node, not config in any way, so creating/deleting it
explicitly (and repeatedly) is equivalent to a “no-op” that will
always succeed because doing so has no effect on the server’s config
in any way?


        

          
              That's correct. "Creating" an object with zero bits of


        

        
information is a no-op.


        

          
                If the sever has the following example config:
                <mycontainer>
                     <child  ... bla..bla…configs>
                </mycontainer>


                If a client issues an edit-config with:
                < mycontainer operation="delete">

                The server returns “ok”,

                If then again  the client attempts:

                < mycontainer operation="delete">

                The server should still return  “ok”?


              Yes, that's correct in my opinion. It's a consequence of


        

        
the NP container nature as defined in the current RFC6020/YANG 1.0 and
bis.


        

          
                If so I think this is confusing. I think it would make


        

        
more sense in the latter case if the server returns “"data-missing”
error.


        

          
              This is logical if you think of NP containers as path


        

        
prefixes, and not as objects with information content. If you accept
that an NP container has zero bits of information, how would the server
even know whether the container exists or not? Not by looking in a
database, for sure.


        

          
              P containers have a single bit of information, so they


        

        
can be created, and the creation event/existence remembered by the
server. Not so for NP-containers.


        

          
                I understand we may advise a client not do so, but


        

        
since  RFC6020bis does not forbid this, and it is also a perfectly valid
<edit-config>, so I am sure people will try it.


        

          
              Yes. And it works today and is harmless.


              It's unfortunate that the YANG 1.0 and 1.1 specs aren't


        

        
crystal clear on the subject, but I believe the interpretation I and
others have of NP container behavior in RFC 6020 is consistent,
implementable and highly useful.


        

          
              /jan




--
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email:


        

        
Balazs.Lengyel@ericsson.com


        

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




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



        Mahesh Jethanandani
        mjethanandani@gmail.com















--
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email:


        

        
Balazs.Lengyel@ericsson.com


        
 

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




        

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



        

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


      

      

    

    

    
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com 


  



From nobody Mon Aug  1 07:38:03 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6BC12D782 for ; Mon,  1 Aug 2016 07:38:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDfGcTD5t-y9 for ; Mon,  1 Aug 2016 07:37:57 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 F3B3512D195 for ; Mon,  1 Aug 2016 07:37:56 -0700 (PDT)
X-AuditID: c1b4fb3a-c91fe700000009bd-88-579f5ec21c80
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by  (Symantec Mail Security) with SMTP id E2.94.02493.2CE5F975; Mon,  1 Aug 2016 16:37:55 +0200 (CEST)
Received: from [159.107.197.181] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.3.301.0; Mon, 1 Aug 2016 16:37:48 +0200
To: Andy Bierman , t.petch 
References: <001c01d1e299$e057a910$a106fb30$@seguesoft.com>  <6e416198-13bd-81e3-545e-35e8bfc61536@ericsson.com>      <016801d1ebd9$cb9c3e20$4001a8c0@gateway.2wire.net>  <20160801102255.GB7476@elstar.local> <30B6D9D0-1E0D-4848-99C2-ACCCC27237AC@gmail.com> <002401d1ebfd$7ee2c8a0$4001a8c0@gateway.2wire.net> 
From: Balazs Lengyel 
Message-ID: 
Date: Mon, 1 Aug 2016 16:37:48 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyM2K7q+7huPnhBjemi1s8ODKL3eLao/ss Flc3/mS0OP1mHZvF1E23WR1YPXYd/cHusXPWXXaPJUt+MnlsOODp0dJ/kSWANYrLJiU1J7Ms tUjfLoErY+qTm8wFL5kr5q47ydLA+Japi5GDQ0LARGLp/PAuRi4OIYH1jBKHnhxmgnDWMEqc n/6BvYuRk0NYIFzi7dM1bCC2iICLxJ3zH9ggihaySbzvOc4C4jAL9DJKHHj9hQmkik3ASGJq /3kWEJtXwF5i+sw7YJNYBFQkfi5dwgayWlQgRmJ9XwJEiaDEyZlPwMo5BQIldp66BraMWcBC Yub884wQtrzE9rdzmEFsIQENiYcX/rJOYBSYhaR9FpKWWUhaFjAyr2IULU4tLs5NNzLSSy3K TC4uzs/Ty0st2cQIDOmDW35b7WA8+NzxEKMAB6MSD28Cy7xwIdbEsuLK3EOMEhzMSiK80rHz w4V4UxIrq1KL8uOLSnNSiw8xSnOwKInz+r9UDBcSSE8sSc1OTS1ILYLJMnFwSjUwBhhrvneq T3n9qMyzrmLGabbF11+bP3x2sO/88bSLxkvLfhxkOGDqpBvzWKg45MQsv49XOdwUzGosrh+z 9/nGNr/r81099y8TpnlMm7f7bnqF4U+r42o5qxhWlU9bPefQhAkH2p7O1DhptvuV6oxyzgoD ZqeUlxMXHFupu0S+7dFK1gkXnnlcKFViKc5INNRiLipOBABCa6CLZQIAAA==
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 Aug 2016 14:38:02 -0000

+1

IMHO removing empty NP-containers is a presentation issue and should not 
impact the protocol or the _conceptual_ database.

Balazs


On 2016-08-01 16:30, Andy Bierman wrote:
> IMO the server SHOULD NOT delete client-created NP containers
> because YANG 1.1 XPath says they are there even if they get deleted.
>

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com


From nobody Mon Aug  1 07:51:36 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB6C12D9C4 for ; Mon,  1 Aug 2016 07:51:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.089
X-Spam-Level: 
X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygis9HyPLP7M for ; Mon,  1 Aug 2016 07:51:26 -0700 (PDT)
Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (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 6977912DA69 for ; Mon,  1 Aug 2016 07:51:26 -0700 (PDT)
Received: from pps.filterd (m0000700.ppops.net [127.0.0.1]) by m0000700.ppops.net (8.16.0.11/8.16.0.11) with SMTP id u71EnCLi025110; Mon, 1 Aug 2016 07:51:23 -0700
Received: from brmwp-exmb11.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 24gsv25ny1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 01 Aug 2016 07:51:23 -0700
Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by BRMWP-EXMB11.corp.brocade.com (172.16.59.77) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Mon, 1 Aug 2016 08:51:21 -0600
Received: from EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) by EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Mon, 1 Aug 2016 16:51:20 +0200
Received: from EMEAWP-EXMB11.corp.brocade.com ([fe80::85ea:b7da:48dd:1640]) by EMEAWP-EXMB11.corp.brocade.com ([fe80::85ea:b7da:48dd:1640%21]) with mapi id 15.00.1156.000; Mon, 1 Aug 2016 16:51:20 +0200
From: William Ivory 
To: Andy Bierman , Ladislav Lhotka , "janl@tail-f.com" 
Thread-Topic: [Netconf] What should a server response be? - depending on NP-containers
Thread-Index: AQHR65HjCKulpI0Pc0iHx2JTqSf796AzNTEAgADP0wCAAALRgIAAJAdA
Date: Mon, 1 Aug 2016 14:51:05 +0000
Deferred-Delivery: Mon, 1 Aug 2016 14:50:08 +0000
Message-ID: <13a7626442c34f499392b67bcf29ea53@EMEAWP-EXMB11.corp.brocade.com>
References:  <87vazljnps.fsf@hobgoblin.ariadne.com>   
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.27.212.49]
Content-Type: multipart/alternative; boundary="_000_13a7626442c34f499392b67bcf29ea53EMEAWPEXMB11corpbrocade_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-01_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 impostorscore=0 lowpriorityscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608010147
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 Aug 2016 14:51:30 -0000

--_000_13a7626442c34f499392b67bcf29ea53EMEAWPEXMB11corpbrocade_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGksDQoNCkNvdWxkIHNvbWVvbmUgY29uZmlybSB0aGVuIHRoYXQgbXVzdCBzdGF0ZW1lbnRzIG9u
IGEgbm9uLXByZXNlbmNlIGNvbnRhaW5lciBpbiBZQU5HIDEuMCBhcmUgb25seSB0byBiZSBldmFs
dWF0ZWQgaWYgdGhlIG5vbi1wcmVzZW5jZSBjb250YWluZXIgaGFzIGNvbmZpZ3VyZWQgY2hpbGRy
ZW4g4oCmIG9yIGlzIGl0IGFsc28gaWYgKHJlYWRpbmcgTGFkYeKAmXMgbWFpbCkgdGhlIGltcGxl
bWVudGF0aW9uIGNob29zZXMgdG8gaW1wbGVtZW50IHRoZW0gd2hlbiB0aGVyZSBhcmUgbm8gY2hp
bGRyZW4gcHJlc2VudD8NCg0KSSBoYWQgYXNzdW1lZCB0aGF0IHRoZSB0ZXh0IGluIFlBTkcgMS4x
IHdhcyBjbGFyaWZ5aW5nIFlBTkcgMS4wIHJhdGhlciB0aGFuIG5ldyBmdW5jdGlvbmFsaXR5IGhl
cmUgYnV0IEnigJltIGEgbGl0dGxlIGNvbmZ1c2VkIG5vdywgZXNwZWNpYWxseSBnaXZlbiB0aGUg
Y29tbWVudCBieSBKYW4gTGluZGJsYWQgcmVnYXJkaW5nIHRoaXMgWUFORyBzbmlwcGV0IGFzIHRo
ZSBmaWxlIGRvZXMgbm90IGNvbnRhaW4g4oCYeWFuZy12ZXJzaW9uIDEuMeKAmSBhbmQgd291bGQg
c3VyZWx5IHRoZXJlZm9yZSBiZSB2ZXJzaW9uIDEuMD8NCg0KICAgICAgY29udGFpbmVyIG93bmVy
c2hpcC12b3VjaGVyIHsNCiAgICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAiVGhpcyBjb250
YWluZXIgY29udGFpbnMgdGhlIE93bmVyc2hpcCBWb3VjaGVyIHRoYXQgdGhlDQogICAgICAgICAg
IGRldmljZSB1c2VzIHRvIGFzY2VydGFpbiB0aGUgaWRlbnRpdHkgb2YgaXRzIHJpZ2h0ZnVsDQog
ICAgICAgICAgIG93bmVyLCBhcyBjZXJ0aWZpZWQgYnkgaXRzIFZlbmRvci4iOw0KDQogICAgICAg
IHdoZW4gIi4uL3JlZGlyZWN0LWluZm9ybWF0aW9uL3NpZ25hdHVyZSBvciAuLi9ib290c3RyYXAt
aW5mb3JtYXRpb24vKi9zaWduYXR1cmUiOw0KICAgICAgICBtdXN0ICIuLi9vd25lci1jZXJ0aWZp
Y2F0ZSI7DQoNCiAgICAgICAgdXNlcyBvd25lcnNoaXAtdm91Y2hlci1ncm91cGluZzsNCiAgICAg
IH0NCg0KDQpodHRwczovL2dpdGh1Yi5jb20vWWFuZ01vZGVscy95YW5nL2Jsb2IvbWFzdGVyL3N0
YW5kYXJkL2lldGYvRFJBRlQvaWV0Zi16ZXJvdG91Y2gtYm9vdHN0cmFwLXNlcnZlci55YW5nDQoN
CkphbuKAmXMgY29tbWVudCBvbiB0aGlzIFlBTkcgKGFzc3VtaW5nIGl04oCZcyAxLjApIGFuZCBM
YWRh4oCZcyBhc3NlcnRpb24gKHBhc3RlZCBiZWxvdykgYXBwZWFyIGNvbnRyYWRpY3RvcnkgdG8g
bWUuDQoNCuKAmE5QIGNvbnRhaW5lcnMgd2VyZSBub3QgYWx3YXlzIHByZXNlbnQgaW4gWUFORyAx
LjAuDQpUaGUgbXVzdC1zdG10IG9ubHkgYXBwbGllZCBpZiB0aGV5IGFjdHVhbGx5IGFyZSBwcmVz
ZW50LA0Kd2hpY2ggaXMgYW4gaW1wbGVtZW50YXRpb24gY2hvaWNlLg0K4oCYDQoNCknigJltIGFs
c28gdGhpbmtpbmcgdGhhdCBhbnkgbXVzdCBzdGF0ZW1lbnQgb24gYSBub24tcHJlc2VuY2UgY29u
dGFpbmVyIGluIFlBTkcgMS4wIG1vZGVscyBtaWdodCBzZW5zaWJseSBiZSAocmUpd3JpdHRlbiBh
cyDigJhub3QoY3VycmVudCgpIG9yIDxyZXF1aXJlZF94cGF0aF9leHByZXNzaW9uPuKAmSB0byBt
YWtlIGl0IGZ1dHVyZS1wcm9vZiBpZiB0aGVzZSBub2RlcyBkbyBub3QgZXhpc3QgaW4gMS4wIHcv
byBjaGlsZHJlbiBidXQgZG8gaW4gWUFORyAxLjEuICBUaGF0IHdvdWxkIGFsbG93IGZvciBlYXNp
ZXIgbW9kZWwgbWlncmF0aW9uLg0KDQpSZWdhcmRzLA0KDQpXaWxsaWFtDQoNCkZyb206IE5ldGNv
bmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbmR5IEJp
ZXJtYW4NClNlbnQ6IDAxIEF1Z3VzdCAyMDE2IDE1OjIzDQpUbzogTGFkaXNsYXYgTGhvdGthIDxs
aG90a2FAbmljLmN6Pg0KQ2M6IE5ldGNvbmYgPG5ldGNvbmZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS
ZTogW05ldGNvbmZdIFdoYXQgc2hvdWxkIGEgc2VydmVyIHJlc3BvbnNlIGJlPyAtIGRlcGVuZGlu
ZyBvbiBOUC1jb250YWluZXJzDQoNCg0KDQpPbiBNb24sIEF1ZyAxLCAyMDE2IGF0IDc6MTMgQU0s
IExhZGlzbGF2IExob3RrYSA8bGhvdGthQG5pYy5jejxtYWlsdG86bGhvdGthQG5pYy5jej4+IHdy
b3RlOg0KQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVtYXdv
cmtzLmNvbT4+IHdyaXRlczoNCg0KPiBIaSwNCj4NCj4gWUFORyAxLjEgaGFzIGJlZW4gY2hhbmdl
ZCBzbyB0aGUgWFBhdGggaXMgbm90IHJlYWxseSBiYWNrd2FyZC1jb21wYXRpYmxlDQo+IHdpdGgg
WUFORyAxLjAuICBJbiBZQU5HIDEuMSBOUC1jb250YWluZXJzIGFsd2F5cyBleGlzdCBpZiB0aGUg
bm9uLU5QIHBhcmVudA0KPiBpcw0KPiBpbnN0YW50aWF0ZWQuDQoNCk15IG1lbnRhbCBtb2RlbCBy
ZWdhcmRpbmcgTlAtY29udGFpbmVycyBpcyB0aGF0IHRoZXkgYXJlIHBhcnQgb2YNCnRoZSBkZWZh
dWx0IGNvbnRlbnRzIG9mIGEgZGF0YXN0b3JlLiBJZiBhbiBOUC1jb250YWluZXIgaXMgImluIHVz
ZSINCihhY2NvcmRpbmcgdG8gdGhlIHNhbWUgcnVsZXMgYXMgc3BlY2lmaWVkIGluIHNlYy4gNy42
LjEgb2YgNjAyMGJpcyBmb3INCmRlZmF1bHQgbGVhdmVzKSwgdGhlbg0KDQotIGNyZWF0aW5nIGEg
Y2hpbGQgb2YgdGhpcyBjb250YWluZXIgc3VjY2VlZHMsDQoNCi0gIm11c3QiIGV4cHJlc3Npb25z
IGRlZmluZWQgb24gdGhpcyBjb250YWluZXIgYXBwbHkuDQoNCg0KTlAgY29udGFpbmVycyB3ZXJl
IG5vdCBhbHdheXMgcHJlc2VudCBpbiBZQU5HIDEuMC4NClRoZSBtdXN0LXN0bXQgb25seSBhcHBs
aWVkIGlmIHRoZXkgYWN0dWFsbHkgYXJlIHByZXNlbnQsDQp3aGljaCBpcyBhbiBpbXBsZW1lbnRh
dGlvbiBjaG9pY2UuDQoNCkkgZG9uJ3QgdW5kZXJzdGFuZCBhbGwgdGhpcyBzcGVjaWFsIHdvcmRp
bmcgYWJvdXQgImRvIG5vdCBlcnJvciBpZi4uLiINCg0KTkVUQ09ORiBoYXMgZXhwbGljaXQgc3Vw
cG9ydCBmb3IgdGhpcyBleGFjdCB1c2UtY2FzZSwgY2FsbGVkICJtZXJnZSIuDQpUaGlzIHdhcyBk
b25lIHByZWNpc2VseSB0byBzdXBwb3J0IHRoZXNlICJkb24ndCBlcnJvciBpZi4uLiIgY2FzZXMu
DQpTbyB1c2UgIm1lcmdlIiBpZiB5b3Ugd2FudCB0aGlzIGZ1bmN0aW9uYWxpdHkuDQoNCg0KTGFk
YQ0KDQpBbmR5DQoNCg0KPg0KPiBORVRDT05GIGFuZCBSRVNUQ09ORiBkbyBub3Qgc2F5IGFueXRo
aW5nIGFib3V0IHRoZSBzZXJ2ZXIgaWdub3JpbmcNCj4gdGhlIHJ1bGVzIGZvciBvcGVyYXRpb249
ImNyZWF0ZSIsIG9wZXJhdGlvbj0iZGVsZXRlIiBhbmQNCj4gZGVmYXVsdC1vcGVyYXRpb249Im5v
bmUiLg0KPiBJTU8gaXRyIHdvdWxkIGJlIGEgcmVhbGx5IGJhZCBpZGVhIHRvIGNvbnRpbnVlIHNw
cmVhZGluZyBsaXR0bGUgcHJvdG9jb2wNCj4gZGV0YWlscw0KPiBpbiB0aGUgWUFORyBSRkMuICBQ
ZW9wbGUgbWlnaHQgcmVhZCB0aGUgcHJvdG9jb2wgc3BlYyBhbmQgKGNvcnJlY3RseSkgYXNzdW1l
DQo+IHRoYXQgdGhlIHByb3RvY29sIGRvZXMgbm90IHRyYXQgTlAgY29udGFpbmVycyBzcGVjaWFs
IGF0IGFsbC4NCj4NCj4gSWYgYW55dGhpbmcsIHRoZSBzZW50ZW5jZSBhYm91dCBNQVkgZGVsZXRl
IG5lZWRzIHRvIGJlIHJlbW92ZWQgYmVjYXVzZQ0KPiBpdCBpcyBpbmNvbnNpc3RlbnQgd2l0aCB0
aGUgWFBhdGggKGFsd2F5cyBleGlzdHMpLg0KPg0KPg0KPiBBbmR5DQo+DQo+DQo+IE9uIFN1biwg
SnVsIDMxLCAyMDE2IGF0IDY6MTMgUE0sIERhbGUgUi4gV29ybGV5IDx3b3JsZXlAYXJpYWRuZS5j
b208bWFpbHRvOndvcmxleUBhcmlhZG5lLmNvbT4+IHdyb3RlOg0KPg0KPj4gTWFoZXNoIEpldGhh
bmFuZGFuaSA8bWpldGhhbmFuZGFuaUBnbWFpbC5jb208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21h
aWwuY29tPj4gd3JpdGVzOg0KPj4gPiBJIHRoaW5rIHRoaXMgYXJndW1lbnQgb2Ygd2hldGhlciBz
ZXJ2ZXIgc2hvdWxkIG9yIHNob3VsZCBub3QNCj4+ID4gY3JlYXRlL2RlbGV0ZSBOUCBjb250YWlu
ZXJzIGlzIGRpc3RyYWN0aW5nIGZyb20gdGhlIG1haW4gcG9pbnQgb2Ygd2hlbg0KPj4gPiBOUCBj
b250YWluZXJzIHNob3VsZCBleGlzdC4gSW4gbXkgbWluZCwgdGhlIE5QIGNvbnRhaW5lciBleGlz
dGVuY2UNCj4+ID4gZGVwZW5kcyBvbiB3aGV0aGVyIGNoaWxkIG5vZGVzIGV4aXN0IG9yIG5vdC4g
SW4gdGhlIGVuZCwgaWYgY2hpbGQNCj4+ID4gbm9kZXMgZXhpc3QsIE5QIGNvbnRhaW5lcnMgc2hv
dWxkIGV4aXN0IChjcmVhdGVkKSwgaWYgdGhleSBkbyBub3QNCj4+ID4gZXhpc3QsIHRoZSBOUCBj
b250YWluZXIgc2hvdWxkIGJlIHJlbW92ZWQuDQo+PiA+DQo+PiA+IENhbiB3ZSBhZ3JlZSBvbiB0
aGF0Pw0KPj4NCj4+IElmIHRoZSBjb25jZXB0IG9mIGEgIm5vbi1wcmVzZW5jZSBjb250YWluZXIi
IG1ha2VzIGFueSBzZW5zZSwgdGhlbiB0aGUNCj4+IGV4aXN0ZW5jZSBvZiBhbiBlbXB0eSBjb250
YWluZXIgbXVzdCBoYXZlIGV4YWN0bHkgdGhlIHNhbWUgc2lnbmlmaWNhbmNlDQo+PiBhcyB0aGUg
bm9uLWV4dGVuY2Ugb2YgdGhlIGNvbnRhaW5lci4NCj4+DQo+PiBHaXZlbiB0aGF0LCB3ZSBoYXZl
IHRvIG1ha2Ugc3VyZSB0aGUgcHJvdG9jb2wgaXMgY29uc2lzdGVudCB3aXRoIHRoYXQNCj4+IHBy
aW5jaXBsZS4gIEUuZy4sIGlmIHlvdSBhc2sgdG8gY3JlYXRlIGFuIGVsZW1lbnQgb2YgYSBub24t
ZXhpc3RpbmcgTlANCj4+IGNvbnRhaW5lciwgaXQgbXVzdCBzdWNjZWVkLCBiZWNhdXNlIGFza2lu
ZyB0byBjcmVhdGUgYW4gZWxlbWVudCBvZiBhbg0KPj4gZXhpc3RpbmcgYnV0IGVtcHR5IE5QIGNv
bnRhaW5lciBzdWNjZWVkcy4NCj4+DQo+PiBJIGRvbid0IHNlZSB3aGF0IGFsbCB0aGUgY29uc2Vx
dWVuY2VzIG9mIHRoaXMgcHJpbmNpcGxlIGFyZSwgYnV0IGlmIHdlDQo+PiBjYW4ndCBtYWtlIHRo
ZSBwcm90b2NvbCBjb25zaXN0ZW50IHdpdGggaXQsIHRoZW4gd2UgY2FuJ3QgcHJvcGVybHkNCj4+
IGltcGxlbWVudCB0aGUgY29uY2VwdCBvZiBOUCBjb250YWluZXJzLg0KPj4NCj4+IERhbGUNCj4+
DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE5l
dGNvbmYgbWFpbGluZyBsaXN0DQo+IE5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOk5ldGNvbmZAaWV0
Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjxo
dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5p
ZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldGNvbmYmZD1Dd01GYVEmYz1JTF9YcVFXT2p1Ymdm
cUlOaTJqVHpnJnI9R0J5TGVnOWpadk92X0FsZ0JvOXV2ZERyeGl6bE9SN2xfU25UWG93eUpVOCZt
PTVEeEdjMThpZ0xMYXpvd0VKUnFmbEwyVnprQy1IVmNQeFh1ejdsdGdHVGcmcz1sS1FNN0s2WWFO
VC1reXVYc1BScWx1WjdsUFdrODRabGFzTm1IMjg4SXowJmU9Pg0KDQotLQ0KTGFkaXNsYXYgTGhv
dGthLCBDWi5OSUMgTGFicw0KUEdQIEtleSBJRDogRTc0RThDMEMNCg0K

--_000_13a7626442c34f499392b67bcf29ea53EMEAWPEXMB11corpbrocade_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmhvZW56Yg0KCXttc28t
c3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6
cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s
b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s
eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5n
dWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7
DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x
DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4
bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94
bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2
OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw
ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBs
aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy
ZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu
Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl
OkVOLVVTIj5Db3VsZCBzb21lb25lIGNvbmZpcm0gdGhlbiB0aGF0IG11c3Qgc3RhdGVtZW50cyBv
biBhIG5vbi1wcmVzZW5jZSBjb250YWluZXIgaW4gWUFORyAxLjAgYXJlIG9ubHkgdG8gYmUgZXZh
bHVhdGVkIGlmIHRoZSBub24tcHJlc2VuY2UNCiBjb250YWluZXIgaGFzIGNvbmZpZ3VyZWQgY2hp
bGRyZW4g4oCmIG9yIGlzIGl0IGFsc28gaWYgKHJlYWRpbmcgTGFkYeKAmXMgbWFpbCkgdGhlIGlt
cGxlbWVudGF0aW9uIGNob29zZXMgdG8gaW1wbGVtZW50IHRoZW0gd2hlbiB0aGVyZSBhcmUgbm8g
Y2hpbGRyZW4gcHJlc2VudD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF
Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi
PkkgaGFkIGFzc3VtZWQgdGhhdCB0aGUgdGV4dCBpbiBZQU5HIDEuMSB3YXMgY2xhcmlmeWluZyBZ
QU5HIDEuMCByYXRoZXIgdGhhbiBuZXcgZnVuY3Rpb25hbGl0eSBoZXJlIGJ1dCBJ4oCZbSBhIGxp
dHRsZSBjb25mdXNlZCBub3csIGVzcGVjaWFsbHkNCiBnaXZlbiB0aGUgY29tbWVudCBieSBKYW4g
TGluZGJsYWQgcmVnYXJkaW5nIHRoaXMgWUFORyBzbmlwcGV0IGFzIHRoZSBmaWxlIGRvZXMgbm90
IGNvbnRhaW4g4oCYeWFuZy12ZXJzaW9uIDEuMeKAmSBhbmQgd291bGQgc3VyZWx5IHRoZXJlZm9y
ZSBiZSB2ZXJzaW9uIDEuMD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF
Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDtjb250YWluZXIgb3duZXJzaGlwLXZvdWNoZXIgezxi
cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwO2Rlc2NyaXB0aW9uPGJyPg0KJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyZxdW90O1RoaXMgY29udGFpbmVy
IGNvbnRhaW5zIHRoZSBPd25lcnNoaXAgVm91Y2hlciB0aGF0IHRoZTxicj4NCiZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZGV2aWNlIHVzZXMgdG8gYXNjZXJ0YWluIHRo
ZSBpZGVudGl0eSBvZiBpdHMgcmlnaHRmdWw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwO293bmVyLCBhcyBjZXJ0aWZpZWQgYnkgaXRzIFZlbmRvci4mcXVvdDs7
PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7d2hlbiAmcXVvdDsu
Li9yZWRpcmVjdC1pbmZvcm1hdGlvbi9zaWduYXR1cmUgb3IgLi4vYm9vdHN0cmFwLWluZm9ybWF0
aW9uLyovc2lnbmF0dXJlJnF1b3Q7Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZu
YnNwO211c3QgJnF1b3Q7Li4vb3duZXItY2VydGlmaWNhdGUmcXVvdDs7PGJyPg0KPGJyPg0KJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7dXNlcyBvd25lcnNoaXAtdm91Y2hlci1ncm91
cGluZzs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsg
Jm5ic3A7IH08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0
aHViLmNvbS9ZYW5nTW9kZWxzL3lhbmcvYmxvYi9tYXN0ZXIvc3RhbmRhcmQvaWV0Zi9EUkFGVC9p
ZXRmLXplcm90b3VjaC1ib290c3RyYXAtc2VydmVyLnlhbmciPmh0dHBzOi8vZ2l0aHViLmNvbS9Z
YW5nTW9kZWxzL3lhbmcvYmxvYi9tYXN0ZXIvc3RhbmRhcmQvaWV0Zi9EUkFGVC9pZXRmLXplcm90
b3VjaC1ib290c3RyYXAtc2VydmVyLnlhbmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh
c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh
bmd1YWdlOkVOLVVTIj5KYW7igJlzIGNvbW1lbnQgb24gdGhpcyBZQU5HIChhc3N1bWluZyBpdOKA
mXMgMS4wKSBhbmQgTGFkYeKAmXMgYXNzZXJ0aW9uIChwYXN0ZWQgYmVsb3cpIGFwcGVhciBjb250
cmFkaWN0b3J5IHRvIG1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO
LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+
4oCYPC9zcGFuPk5QIGNvbnRhaW5lcnMgd2VyZSBub3QgYWx3YXlzIHByZXNlbnQgaW4gWUFORyAx
LjAuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgbXVzdC1zdG10IG9u
bHkgYXBwbGllZCBpZiB0aGV5IGFjdHVhbGx5IGFyZSBwcmVzZW50LDxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+d2hpY2ggaXMgYW4gaW1wbGVtZW50YXRpb24gY2hvaWNlLjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPuKAmDxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE
O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t
ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SeKAmW0gYWxzbyB0aGlua2luZyB0aGF0IGFueSBtdXN0
IHN0YXRlbWVudCBvbiBhIG5vbi1wcmVzZW5jZSBjb250YWluZXIgaW4gWUFORyAxLjAgbW9kZWxz
IG1pZ2h0IHNlbnNpYmx5IGJlIChyZSl3cml0dGVuIGFzIOKAmG5vdChjdXJyZW50KCkNCiBvciAm
bHQ7cmVxdWlyZWRfeHBhdGhfZXhwcmVzc2lvbiZndDvigJkgdG8gbWFrZSBpdCBmdXR1cmUtcHJv
b2YgaWYgdGhlc2Ugbm9kZXMgZG8gbm90IGV4aXN0IGluIDEuMCB3L28gY2hpbGRyZW4gYnV0IGRv
IGluIFlBTkcgMS4xLiZuYnNwOyBUaGF0IHdvdWxkIGFsbG93IGZvciBlYXNpZXIgbW9kZWwgbWln
cmF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPldpbGxpYW08bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBOZXRj
b25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwv
Yj5BbmR5IEJpZXJtYW48YnI+DQo8Yj5TZW50OjwvYj4gMDEgQXVndXN0IDIwMTYgMTU6MjM8YnI+
DQo8Yj5Ubzo8L2I+IExhZGlzbGF2IExob3RrYSAmbHQ7bGhvdGthQG5pYy5jeiZndDs8YnI+DQo8
Yj5DYzo8L2I+IE5ldGNvbmYgJmx0O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVj
dDo8L2I+IFJlOiBbTmV0Y29uZl0gV2hhdCBzaG91bGQgYSBzZXJ2ZXIgcmVzcG9uc2UgYmU/IC0g
ZGVwZW5kaW5nIG9uIE5QLWNvbnRhaW5lcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBN
b24sIEF1ZyAxLCAyMDE2IGF0IDc6MTMgQU0sIExhZGlzbGF2IExob3RrYSAmbHQ7PGEgaHJlZj0i
bWFpbHRvOmxob3RrYUBuaWMuY3oiIHRhcmdldD0iX2JsYW5rIj5saG90a2FAbmljLmN6PC9hPiZn
dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7
Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0
O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5BbmR5IEJpZXJtYW4gJmx0OzxhIGhyZWY9
Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20iPmFuZHlAeXVtYXdvcmtzLmNvbTwvYT4mZ3Q7IHdy
aXRlczo8YnI+DQo8YnI+DQomZ3Q7IEhpLDxicj4NCiZndDs8YnI+DQomZ3Q7IFlBTkcgMS4xIGhh
cyBiZWVuIGNoYW5nZWQgc28gdGhlIFhQYXRoIGlzIG5vdCByZWFsbHkgYmFja3dhcmQtY29tcGF0
aWJsZTxicj4NCiZndDsgd2l0aCBZQU5HIDEuMC4mbmJzcDsgSW4gWUFORyAxLjEgTlAtY29udGFp
bmVycyBhbHdheXMgZXhpc3QgaWYgdGhlIG5vbi1OUCBwYXJlbnQ8YnI+DQomZ3Q7IGlzPGJyPg0K
Jmd0OyBpbnN0YW50aWF0ZWQuPGJyPg0KPGJyPg0KTXkgbWVudGFsIG1vZGVsIHJlZ2FyZGluZyBO
UC1jb250YWluZXJzIGlzIHRoYXQgdGhleSBhcmUgcGFydCBvZjxicj4NCnRoZSBkZWZhdWx0IGNv
bnRlbnRzIG9mIGEgZGF0YXN0b3JlLiBJZiBhbiBOUC1jb250YWluZXIgaXMgJnF1b3Q7aW4gdXNl
JnF1b3Q7PGJyPg0KKGFjY29yZGluZyB0byB0aGUgc2FtZSBydWxlcyBhcyBzcGVjaWZpZWQgaW4g
c2VjLiA3LjYuMSBvZiA2MDIwYmlzIGZvcjxicj4NCmRlZmF1bHQgbGVhdmVzKSwgdGhlbjxicj4N
Cjxicj4NCi0gY3JlYXRpbmcgYSBjaGlsZCBvZiB0aGlzIGNvbnRhaW5lciBzdWNjZWVkcyw8YnI+
DQo8YnI+DQotICZxdW90O211c3QmcXVvdDsgZXhwcmVzc2lvbnMgZGVmaW5lZCBvbiB0aGlzIGNv
bnRhaW5lciBhcHBseS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+TlAgY29udGFpbmVycyB3ZXJlIG5vdCBhbHdheXMgcHJlc2Vu
dCBpbiBZQU5HIDEuMC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPlRoZSBtdXN0LXN0bXQgb25seSBhcHBsaWVkIGlmIHRoZXkgYWN0dWFsbHkgYXJl
IHByZXNlbnQsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj53aGljaCBpcyBhbiBpbXBsZW1lbnRhdGlvbiBjaG9pY2UuPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3QgdW5kZXJzdGFuZCBh
bGwgdGhpcyBzcGVjaWFsIHdvcmRpbmcgYWJvdXQgJnF1b3Q7ZG8gbm90IGVycm9yIGlmLi4uJnF1
b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pk5FVENPTkYgaGFzIGV4cGxpY2l0IHN1cHBvcnQgZm9yIHRoaXMgZXhhY3QgdXNlLWNhc2UsIGNh
bGxlZCAmcXVvdDttZXJnZSZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgd2FzIGRvbmUgcHJlY2lzZWx5IHRvIHN1cHBvcnQgdGhl
c2UgJnF1b3Q7ZG9uJ3QgZXJyb3IgaWYuLi4mcXVvdDsgY2FzZXMuPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyB1c2UgJnF1b3Q7bWVyZ2UmcXVv
dDsgaWYgeW91IHdhbnQgdGhpcyBmdW5jdGlvbmFsaXR5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv
bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0
LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxhZGE8bzpwPjwv
bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFu
ZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v
bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYu
MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PGJyPg0KJmd0Ozxicj4NCiZndDsgTkVUQ09ORiBhbmQgUkVTVENPTkYgZG8gbm90IHNh
eSBhbnl0aGluZyBhYm91dCB0aGUgc2VydmVyIGlnbm9yaW5nPGJyPg0KJmd0OyB0aGUgcnVsZXMg
Zm9yIG9wZXJhdGlvbj0mcXVvdDtjcmVhdGUmcXVvdDssIG9wZXJhdGlvbj0mcXVvdDtkZWxldGUm
cXVvdDsgYW5kPGJyPg0KJmd0OyBkZWZhdWx0LW9wZXJhdGlvbj0mcXVvdDtub25lJnF1b3Q7Ljxi
cj4NCiZndDsgSU1PIGl0ciB3b3VsZCBiZSBhIHJlYWxseSBiYWQgaWRlYSB0byBjb250aW51ZSBz
cHJlYWRpbmcgbGl0dGxlIHByb3RvY29sPGJyPg0KJmd0OyBkZXRhaWxzPGJyPg0KJmd0OyBpbiB0
aGUgWUFORyBSRkMuJm5ic3A7IFBlb3BsZSBtaWdodCByZWFkIHRoZSBwcm90b2NvbCBzcGVjIGFu
ZCAoY29ycmVjdGx5KSBhc3N1bWU8YnI+DQomZ3Q7IHRoYXQgdGhlIHByb3RvY29sIGRvZXMgbm90
IHRyYXQgTlAgY29udGFpbmVycyBzcGVjaWFsIGF0IGFsbC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJ
ZiBhbnl0aGluZywgdGhlIHNlbnRlbmNlIGFib3V0IE1BWSBkZWxldGUgbmVlZHMgdG8gYmUgcmVt
b3ZlZCBiZWNhdXNlPGJyPg0KJmd0OyBpdCBpcyBpbmNvbnNpc3RlbnQgd2l0aCB0aGUgWFBhdGgg
KGFsd2F5cyBleGlzdHMpLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBBbmR5PGJyPg0K
Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIFN1biwgSnVsIDMxLCAyMDE2IGF0IDY6MTMgUE0s
IERhbGUgUi4gV29ybGV5ICZsdDs8YSBocmVmPSJtYWlsdG86d29ybGV5QGFyaWFkbmUuY29tIj53
b3JsZXlAYXJpYWRuZS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsg
TWFoZXNoIEpldGhhbmFuZGFuaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21h
aWwuY29tIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyaXRlczo8YnI+DQomZ3Q7
Jmd0OyAmZ3Q7IEkgdGhpbmsgdGhpcyBhcmd1bWVudCBvZiB3aGV0aGVyIHNlcnZlciBzaG91bGQg
b3Igc2hvdWxkIG5vdDxicj4NCiZndDsmZ3Q7ICZndDsgY3JlYXRlL2RlbGV0ZSBOUCBjb250YWlu
ZXJzIGlzIGRpc3RyYWN0aW5nIGZyb20gdGhlIG1haW4gcG9pbnQgb2Ygd2hlbjxicj4NCiZndDsm
Z3Q7ICZndDsgTlAgY29udGFpbmVycyBzaG91bGQgZXhpc3QuIEluIG15IG1pbmQsIHRoZSBOUCBj
b250YWluZXIgZXhpc3RlbmNlPGJyPg0KJmd0OyZndDsgJmd0OyBkZXBlbmRzIG9uIHdoZXRoZXIg
Y2hpbGQgbm9kZXMgZXhpc3Qgb3Igbm90LiBJbiB0aGUgZW5kLCBpZiBjaGlsZDxicj4NCiZndDsm
Z3Q7ICZndDsgbm9kZXMgZXhpc3QsIE5QIGNvbnRhaW5lcnMgc2hvdWxkIGV4aXN0IChjcmVhdGVk
KSwgaWYgdGhleSBkbyBub3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IGV4aXN0LCB0aGUgTlAgY29udGFp
bmVyIHNob3VsZCBiZSByZW1vdmVkLjxicj4NCiZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAm
Z3Q7IENhbiB3ZSBhZ3JlZSBvbiB0aGF0Pzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSWYg
dGhlIGNvbmNlcHQgb2YgYSAmcXVvdDtub24tcHJlc2VuY2UgY29udGFpbmVyJnF1b3Q7IG1ha2Vz
IGFueSBzZW5zZSwgdGhlbiB0aGU8YnI+DQomZ3Q7Jmd0OyBleGlzdGVuY2Ugb2YgYW4gZW1wdHkg
Y29udGFpbmVyIG11c3QgaGF2ZSBleGFjdGx5IHRoZSBzYW1lIHNpZ25pZmljYW5jZTxicj4NCiZn
dDsmZ3Q7IGFzIHRoZSBub24tZXh0ZW5jZSBvZiB0aGUgY29udGFpbmVyLjxicj4NCiZndDsmZ3Q7
PGJyPg0KJmd0OyZndDsgR2l2ZW4gdGhhdCwgd2UgaGF2ZSB0byBtYWtlIHN1cmUgdGhlIHByb3Rv
Y29sIGlzIGNvbnNpc3RlbnQgd2l0aCB0aGF0PGJyPg0KJmd0OyZndDsgcHJpbmNpcGxlLiZuYnNw
OyBFLmcuLCBpZiB5b3UgYXNrIHRvIGNyZWF0ZSBhbiBlbGVtZW50IG9mIGEgbm9uLWV4aXN0aW5n
IE5QPGJyPg0KJmd0OyZndDsgY29udGFpbmVyLCBpdCBtdXN0IHN1Y2NlZWQsIGJlY2F1c2UgYXNr
aW5nIHRvIGNyZWF0ZSBhbiBlbGVtZW50IG9mIGFuPGJyPg0KJmd0OyZndDsgZXhpc3RpbmcgYnV0
IGVtcHR5IE5QIGNvbnRhaW5lciBzdWNjZWVkcy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7
IEkgZG9uJ3Qgc2VlIHdoYXQgYWxsIHRoZSBjb25zZXF1ZW5jZXMgb2YgdGhpcyBwcmluY2lwbGUg
YXJlLCBidXQgaWYgd2U8YnI+DQomZ3Q7Jmd0OyBjYW4ndCBtYWtlIHRoZSBwcm90b2NvbCBjb25z
aXN0ZW50IHdpdGggaXQsIHRoZW4gd2UgY2FuJ3QgcHJvcGVybHk8YnI+DQomZ3Q7Jmd0OyBpbXBs
ZW1lbnQgdGhlIGNvbmNlcHQgb2YgTlAgY29udGFpbmVycy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn
dDsmZ3Q7IERhbGU8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IE5ldGNvbmYgbWFpbGluZyBsaXN0
PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86TmV0Y29uZkBpZXRmLm9yZyI+TmV0Y29uZkBpZXRm
Lm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50
LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fbmV0
Y29uZiZhbXA7ZD1Dd01GYVEmYW1wO2M9SUxfWHFRV09qdWJnZnFJTmkyalR6ZyZhbXA7cj1HQnlM
ZWc5alp2T3ZfQWxnQm85dXZkRHJ4aXpsT1I3bF9TblRYb3d5SlU4JmFtcDttPTVEeEdjMThpZ0xM
YXpvd0VKUnFmbEwyVnprQy1IVmNQeFh1ejdsdGdHVGcmYW1wO3M9bEtRTTdLNllhTlQta3l1WHNQ
UnFsdVo3bFBXazg0Wmxhc05tSDI4OEl6MCZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvYT48YnI+DQo8c3BhbiBz
dHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+LS08L3NwYW4+
PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+TGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFiczwv
c3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj5QR1AgS2V5IElEOiBFNzRFOEMwQzwvc3Bh
bj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_13a7626442c34f499392b67bcf29ea53EMEAWPEXMB11corpbrocade_--


From nobody Mon Aug  1 08:03:14 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D29912DAAF for ; Mon,  1 Aug 2016 08:03:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.089
X-Spam-Level: 
X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3wg71lw1GO8 for ; Mon,  1 Aug 2016 08:03:09 -0700 (PDT)
Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 CEBF712DAD9 for ; Mon,  1 Aug 2016 08:03:07 -0700 (PDT)
Received: by mail-ua0-x22d.google.com with SMTP id l32so108154929ual.2 for ; Mon, 01 Aug 2016 08:03:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kz+0dopkrVubApJTHVZC3NyQ0VP/2I2G8O79nX6tY0s=; b=MRrxkOhGzJGAvTBoiduaI9VbEMllMJTp+3n3GKI3h502VZ5SwzzTL0ZZ/oGQS5A3k5 n1dL6CxlTN836JJjejj5NE+WDL0YA4kCeOHnOJEAtInxzg3nyIksU22ZrqjvRa5Y9M2i QTsG4iy2Kc+N1zsvSvME7n/1wl2IhJlEBFmQIHdKlxD1F1kJb1R6w/bz+5K2QDKCDDLW SlpUUSK/IQSIV9QR12dj/SlY26X8y8OYvY4Uv+BI+Mc9hV/Xt3I7EvGRhO3Uuv9nxenO hWoj7VMeJnCrjFSNn9xslebDwb3YZAz6YTsMD6KGZC9wmQbuCD88rIezJ3eytYQNsB90 NuSw==
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:from:date :message-id:subject:to:cc; bh=kz+0dopkrVubApJTHVZC3NyQ0VP/2I2G8O79nX6tY0s=; b=TDAW/fltBU5JRbuOjFW1h24nbLUNanJabbsn5OsseWfOOFlH9v95fah8l8Pfpt6vso l4GdAfwFlcI+PbcCmb8FM3U+GfHYU6N02wGB2AzR6Cf0D2liwcmnF+hOBfoNxdrSUlFI K00LEPtGwokAoAaKnpVppNvxJo4w+yTrFypKWe15o5NnERL3W0YzXl7RLyhQrnIaqQtn 1TSwHkSNzxVRTFxqT3IDpD34FpQrYkd9d2SIbP0ollrVHuwBZmcja02cjgyFzi48X6WD s6zOTwhnOkUHuPHXZhzdkkWAC6dOkDiWMnWRqIdUbxTQVMmEUMnH04bcGSW38cagck/8 fEfw==
X-Gm-Message-State: AEkoousKrWBoykwFogAuREZfEZ93s0WtAx4PgP/gUcwOAvpoNEN4J/gGCXbfxNrOnWC56E0zg962xCV7zJyuug==
X-Received: by 10.159.35.112 with SMTP id 103mr26238052uae.55.1470063786844; Mon, 01 Aug 2016 08:03:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Mon, 1 Aug 2016 08:03:05 -0700 (PDT)
In-Reply-To: <13a7626442c34f499392b67bcf29ea53@EMEAWP-EXMB11.corp.brocade.com>
References:  <87vazljnps.fsf@hobgoblin.ariadne.com>    <13a7626442c34f499392b67bcf29ea53@EMEAWP-EXMB11.corp.brocade.com>
From: Andy Bierman 
Date: Mon, 1 Aug 2016 08:03:05 -0700
Message-ID: 
To: William Ivory 
Content-Type: multipart/alternative; boundary=001a113ab81ad012a8053903e55a
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 Aug 2016 15:03:13 -0000

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

Hi,

I think I made that comment.
In YANG 1.0, only default leafs were considered always present.
In YANG 1.1 NP containers were added to the set of accessible nodes

In YANG 1.0, sec. 7.5.3

   o  The accessible tree is made up of all nodes in the data tree, and
      all leafs with default values in use (see Section 7.6.1).

This was changed in YANG 1.1

sec 7.5.3:

   When a datastore is validated, all "must" constraints are
   conceptually evaluated once for each node in the accessible tree (see
   Section 6.4.1).

Sec. 6.4.1

      If a node that exists in the accessible tree has a non-presence
      container as a child, then the non-presence container also exists in
      the tree.


Andy




On Mon, Aug 1, 2016 at 7:51 AM, William Ivory  wrote:

> Hi,
>
>
>
> Could someone confirm then that must statements on a non-presence
> container in YANG 1.0 are only to be evaluated if the non-presence
> container has configured children =E2=80=A6 or is it also if (reading Lad=
a=E2=80=99s mail)
> the implementation chooses to implement them when there are no children
> present?
>
>
>
> I had assumed that the text in YANG 1.1 was clarifying YANG 1.0 rather
> than new functionality here but I=E2=80=99m a little confused now, especi=
ally given
> the comment by Jan Lindblad regarding this YANG snippet as the file does
> not contain =E2=80=98yang-version 1.1=E2=80=99 and would surely therefore=
 be version 1.0?
>
>
>
>       container ownership-voucher {
>         description
>           "This container contains the Ownership Voucher that the
>            device uses to ascertain the identity of its rightful
>            owner, as certified by its Vendor.";
>
>         when "../redirect-information/signature or
> ../bootstrap-information/*/signature";
>         must "../owner-certificate";
>
>         uses ownership-voucher-grouping;
>
>       }
>
>
>
>
>
>
> https://github.com/YangModels/yang/blob/master/standard/ietf/DRAFT/ietf-z=
erotouch-bootstrap-server.yang
>
>
>
> Jan=E2=80=99s comment on this YANG (assuming it=E2=80=99s 1.0) and Lada=
=E2=80=99s assertion
> (pasted below) appear contradictory to me.
>
>
>
> =E2=80=98NP containers were not always present in YANG 1.0.
>
> The must-stmt only applied if they actually are present,
>
> which is an implementation choice.
>
> =E2=80=98
>
>
>
> I=E2=80=99m also thinking that any must statement on a non-presence conta=
iner in
> YANG 1.0 models might sensibly be (re)written as =E2=80=98not(current() o=
r
> =E2=80=99 to make it future-proof if these nod=
es do not
> exist in 1.0 w/o children but do in YANG 1.1.  That would allow for easie=
r
> model migration.
>
>
>
> Regards,
>
>
>
> William
>
>
>
> *From:* Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Andy
> Bierman
> *Sent:* 01 August 2016 15:23
> *To:* Ladislav Lhotka 
> *Cc:* Netconf 
> *Subject:* Re: [Netconf] What should a server response be? - depending on
> NP-containers
>
>
>
>
>
>
>
> On Mon, Aug 1, 2016 at 7:13 AM, Ladislav Lhotka  wrote:
>
> Andy Bierman  writes:
>
> > Hi,
> >
> > YANG 1.1 has been changed so the XPath is not really backward-compatibl=
e
> > with YANG 1.0.  In YANG 1.1 NP-containers always exist if the non-NP
> parent
> > is
> > instantiated.
>
> My mental model regarding NP-containers is that they are part of
> the default contents of a datastore. If an NP-container is "in use"
> (according to the same rules as specified in sec. 7.6.1 of 6020bis for
> default leaves), then
>
> - creating a child of this container succeeds,
>
> - "must" expressions defined on this container apply.
>
>
>
>
>
> NP containers were not always present in YANG 1.0.
>
> The must-stmt only applied if they actually are present,
>
> which is an implementation choice.
>
>
>
> I don't understand all this special wording about "do not error if..."
>
>
>
> NETCONF has explicit support for this exact use-case, called "merge".
>
> This was done precisely to support these "don't error if..." cases.
>
> So use "merge" if you want this functionality.
>
>
>
>
>
> Lada
>
>
>
> Andy
>
>
>
>
> >
> > NETCONF and RESTCONF do not say anything about the server ignoring
> > the rules for operation=3D"create", operation=3D"delete" and
> > default-operation=3D"none".
> > IMO itr would be a really bad idea to continue spreading little protoco=
l
> > details
> > in the YANG RFC.  People might read the protocol spec and (correctly)
> assume
> > that the protocol does not trat NP containers special at all.
> >
> > If anything, the sentence about MAY delete needs to be removed because
> > it is inconsistent with the XPath (always exists).
> >
> >
> > Andy
> >
> >
> > On Sun, Jul 31, 2016 at 6:13 PM, Dale R. Worley 
> wrote:
> >
> >> Mahesh Jethanandani  writes:
> >> > I think this argument of whether server should or should not
> >> > create/delete NP containers is distracting from the main point of wh=
en
> >> > NP containers should exist. In my mind, the NP container existence
> >> > depends on whether child nodes exist or not. In the end, if child
> >> > nodes exist, NP containers should exist (created), if they do not
> >> > exist, the NP container should be removed.
> >> >
> >> > Can we agree on that?
> >>
> >> If the concept of a "non-presence container" makes any sense, then the
> >> existence of an empty container must have exactly the same significanc=
e
> >> as the non-extence of the container.
> >>
> >> Given that, we have to make sure the protocol is consistent with that
> >> principle.  E.g., if you ask to create an element of a non-existing NP
> >> container, it must succeed, because asking to create an element of an
> >> existing but empty NP container succeeds.
> >>
> >> I don't see what all the consequences of this principle are, but if we
> >> can't make the protocol consistent with it, then we can't properly
> >> implement the concept of NP containers.
> >>
> >> Dale
> >>
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> 
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>

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


Hi,

I think I made that comment.
<=
div>In YANG 1.0, only default leafs were considered always present.
In YANG 1.1 NP containers were added to the set of accessible nodes

In YANG 1.0, sec. 7.5.3

   o  The accessible tree is made up of all nodes in the data tre=
e, and
      all leafs with default values in use (see Section 7.6.1).


This was changed in YANG 1.1

sec 7.5.3:
<=
pre style=3D"word-wrap:break-word">   When a datastore is validated, all "must"=
 constraints are
   conceptually evaluated once for each node in the accessible tree (see
   Section 6.4.1).

Sec. 6.4.1

=C2=A0 =C2=
=A0 =C2=A0 If a node that exists in the accessible tree has a non-presence<=
/div>
=C2=A0 =C2=A0 =C2=A0 container as a child, then the non-presence =
container also exists in
=C2=A0 =C2=A0 =C2=A0 the tree.


Andy




On Mon, Aug 1, 2016 at 7:51 AM, William Ivory <<=
a href=3D"mailto:wivory@brocade.com" target=3D"_blank">wivory@brocade.com> wrote:











Hi,


=C2=A0


Could someone confirm then that must =
statements on a non-presence container in YANG 1.0 are only to be evaluated=
 if the non-presence
 container has configured children =E2=80=A6 or is it also if (reading Lada=
=E2=80=99s mail) the implementation chooses to implement them when there ar=
e no children present?


=C2=A0


I had assumed that the text in YANG 1=
.1 was clarifying YANG 1.0 rather than new functionality here but I=E2=80=
=99m a little confused now, especially
 given the comment by Jan Lindblad regarding this YANG snippet as the file =
does not contain =E2=80=98yang-version 1.1=E2=80=99 and would surely theref=
ore be version 1.0?


=C2=A0


=C2=A0 =C2=A0 =C2=A0=C2=A0container ownership-vouche=
r {

=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0description

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0"This container contains the O=
wnership Voucher that the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0device uses to ascertain the ident=
ity of its rightful

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0owner, as certified by its Vendor.=
";



=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0when "../redirect-information/signatu=
re or ../bootstrap-information/*/signature";

=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0must "../owner-certificate";



=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0uses ownership-voucher-grouping;=



=C2=A0 =C2=A0 =C2=A0 }


=C2=A0


=C2=A0


https://github.com/YangModels/yang/blob/master/standa=
rd/ietf/DRAFT/ietf-zerotouch-bootstrap-server.yang=



=C2=A0


Jan=E2=80=99s comment on this YANG (a=
ssuming it=E2=80=99s 1.0) and Lada=E2=80=99s assertion (pasted below) appea=
r contradictory to me.


=C2=A0


=E2=80=98NP containers were no=
t always present in YANG 1.0.


The must-stmt only applied if they actually are pres=
ent,


which is an implementation choice.


=E2=80=98


=C2=A0


I=E2=80=99m also thinking that any mu=
st statement on a non-presence container in YANG 1.0 models might sensibly =
be (re)written as =E2=80=98not(current()
 or <required_xpath_expression>=E2=80=99 to make it future-proof if t=
hese nodes do not exist in 1.0 w/o children but do in YANG 1.1.=C2=A0 That =
would allow for easier model migration.


=C2=A0


Regards,


=C2=A0


William


=C2=A0


From: =
Netconf [mailto:netconf-bounces@ietf.org]
On Behalf Of Andy Bierman

Sent: 01 August 2016 15:23

To: Ladislav Lhotka <lhotka@nic.cz>

Cc: Netconf <netconf@ietf.org>

Subject: Re: [Netconf] What should a server response be? - depending=
 on NP-containers


=C2=A0




=C2=A0




=C2=A0




On Mon, Aug 1, 2016 at 7:13 AM, Ladislav Lhotka <=
lhotka@nic.cz> wr=
ote:




Andy Bierman <andy@yumaworks.com&=
gt; writes:



> Hi,

>

> YANG 1.1 has been changed so the XPath is not really backward-compatib=
le

> with YANG 1.0.=C2=A0 In YANG 1.1 NP-containers always exist if the non=
-NP parent

> is

> instantiated.



My mental model regarding NP-containers is that they are part of

the default contents of a datastore. If an NP-container is "in use&quo=
t;

(according to the same rules as specified in sec. 7.6.1 of 6020bis for

default leaves), then



- creating a child of this container succeeds,



- "must" expressions defined on this container apply.






=C2=A0






=C2=A0






NP containers were not always present in YANG 1.0.






The must-stmt only applied if they actually are pres=
ent,






which is an implementation choice.






=C2=A0






I don't understand all this special wording abou=
t "do not error if..."






=C2=A0






NETCONF has explicit support for this exact use-case=
, called "merge".






This was done precisely to support these "don&#=
39;t error if..." cases.






So use "merge" if you want this functional=
ity.=C2=A0






=C2=A0






=C2=A0






Lada






=C2=A0






Andy






=C2=A0








>

> NETCONF and RESTCONF do not say anything about the server ignoring

> the rules for operation=3D"create", operation=3D"delete=
" and

> default-operation=3D"none".

> IMO itr would be a really bad idea to continue spreading little protoc=
ol

> details

> in the YANG RFC.=C2=A0 People might read the protocol spec and (correc=
tly) assume

> that the protocol does not trat NP containers special at all.

>

> If anything, the sentence about MAY delete needs to be removed because=


> it is inconsistent with the XPath (always exists).

>

>

> Andy

>

>

> On Sun, Jul 31, 2016 at 6:13 PM, Dale R. Worley <worley@ariadne.com> wrote:

>

>> Mahesh Jethanandani <mjethanandani@gmail.com> writes:

>> > I think this argument of whether server should or should not<=
br>
>> > create/delete NP containers is distracting from the main poin=
t of when

>> > NP containers should exist. In my mind, the NP container exis=
tence

>> > depends on whether child nodes exist or not. In the end, if c=
hild

>> > nodes exist, NP containers should exist (created), if they do=
 not

>> > exist, the NP container should be removed.

>> >

>> > Can we agree on that?

>>

>> If the concept of a "non-presence container" makes any s=
ense, then the

>> existence of an empty container must have exactly the same signifi=
cance

>> as the non-extence of the container.

>>

>> Given that, we have to make sure the protocol is consistent with t=
hat

>> principle.=C2=A0 E.g., if you ask to create an element of a non-ex=
isting NP

>> container, it must succeed, because asking to create an element of=
 an

>> existing but empty NP container succeeds.

>>

>> I don't see what all the consequences of this principle are, b=
ut if we

>> can't make the protocol consistent with it, then we can't =
properly

>> implement the concept of NP containers.

>>

>> Dale

>>

> _______________________________________________

> Netconf mailing list

> Netconf@ietf.org=


> 
https://www.ietf.org/mailman/listinfo/netconf



--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C






=C2=A0














--001a113ab81ad012a8053903e55a--


From nobody Mon Aug  1 08:10:46 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC89712DC4F for ; Mon,  1 Aug 2016 08:10:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.089
X-Spam-Level: 
X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSSZnXYsPkAr for ; Mon,  1 Aug 2016 08:10:42 -0700 (PDT)
Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (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 6B84D12DC1A for ; Mon,  1 Aug 2016 08:10:42 -0700 (PDT)
Received: from pps.filterd (m0048193.ppops.net [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u71F6qdj024720; Mon, 1 Aug 2016 08:10:41 -0700
Received: from brmwp-exmb11.corp.brocade.com ([208.47.132.227]) by mx0a-000f0801.pphosted.com with ESMTP id 24gtyb5y9m-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 01 Aug 2016 08:10:41 -0700
Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by BRMWP-EXMB11.corp.brocade.com (172.16.59.77) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Mon, 1 Aug 2016 09:10:21 -0600
Received: from EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) by EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Mon, 1 Aug 2016 17:10:20 +0200
Received: from EMEAWP-EXMB11.corp.brocade.com ([fe80::85ea:b7da:48dd:1640]) by EMEAWP-EXMB11.corp.brocade.com ([fe80::85ea:b7da:48dd:1640%21]) with mapi id 15.00.1156.000; Mon, 1 Aug 2016 17:10:20 +0200
From: William Ivory 
To: Andy Bierman 
Thread-Topic: [Netconf] What should a server response be? - depending on NP-containers
Thread-Index: AQHR65HjCKulpI0Pc0iHx2JTqSf796AzNTEAgADP0wCAAALRgIAAJAdA///nFYCAACJxEA==
Date: Mon, 1 Aug 2016 15:10:08 +0000
Deferred-Delivery: Mon, 1 Aug 2016 15:09:59 +0000
Message-ID: <78c52bbab4d44b938e1dcf191d95b42a@EMEAWP-EXMB11.corp.brocade.com>
References:  <87vazljnps.fsf@hobgoblin.ariadne.com>    <13a7626442c34f499392b67bcf29ea53@EMEAWP-EXMB11.corp.brocade.com> 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.27.212.49]
Content-Type: multipart/alternative; boundary="_000_78c52bbab4d44b938e1dcf191d95b42aEMEAWPEXMB11corpbrocade_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-01_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 impostorscore=0 lowpriorityscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608010158
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 Aug 2016 15:10:45 -0000

--_000_78c52bbab4d44b938e1dcf191d95b42aEMEAWPEXMB11corpbrocade_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgQW5keSwNCg0KVGhhbmtzIOKAkyBpbiBpc29sYXRpb24gdGhhdCBpcyBjbGVhciwgYnV0IEkg
d291bGQgYmUgaW50ZXJlc3RlZCBpbiBKYW7igJlzIHRob3VnaHRzIGdpdmVuIHRoYXQgdGhlIGdp
dmVuIG93bmVyc2hpcC12b3VjaGVyIGV4YW1wbGUgd291bGQgYXBwZWFyIHRvIGJlIFlBTkcgMS4w
ICphbmQqIGFzc3VtZSBtdXN0IHN0YXRlbWVudHMgYXJlIGV2YWx1YXRlZCBvbiBub24tcHJlc2Vu
Y2UgY29udGFpbmVycyBpZiB0aGUgcGFyZW50IG5vZGUgZXhpc3RzLg0KDQpSZWdhcmRzLA0KDQpX
aWxsaWFtDQoNCkZyb206IEFuZHkgQmllcm1hbiBbbWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbV0N
ClNlbnQ6IDAxIEF1Z3VzdCAyMDE2IDE2OjAzDQpUbzogV2lsbGlhbSBJdm9yeSA8d2l2b3J5QEJy
b2NhZGUuY29tPg0KQ2M6IExhZGlzbGF2IExob3RrYSA8bGhvdGthQG5pYy5jej47IGphbmxAdGFp
bC1mLmNvbTsgTmV0Y29uZiA8bmV0Y29uZkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbTmV0Y29u
Zl0gV2hhdCBzaG91bGQgYSBzZXJ2ZXIgcmVzcG9uc2UgYmU/IC0gZGVwZW5kaW5nIG9uIE5QLWNv
bnRhaW5lcnMNCg0KSGksDQoNCkkgdGhpbmsgSSBtYWRlIHRoYXQgY29tbWVudC4NCkluIFlBTkcg
MS4wLCBvbmx5IGRlZmF1bHQgbGVhZnMgd2VyZSBjb25zaWRlcmVkIGFsd2F5cyBwcmVzZW50Lg0K
SW4gWUFORyAxLjEgTlAgY29udGFpbmVycyB3ZXJlIGFkZGVkIHRvIHRoZSBzZXQgb2YgYWNjZXNz
aWJsZSBub2Rlcw0KDQpJbiBZQU5HIDEuMCwgc2VjLiA3LjUuMw0KDQoNCiAgIG8gIFRoZSBhY2Nl
c3NpYmxlIHRyZWUgaXMgbWFkZSB1cCBvZiBhbGwgbm9kZXMgaW4gdGhlIGRhdGEgdHJlZSwgYW5k
DQoNCiAgICAgIGFsbCBsZWFmcyB3aXRoIGRlZmF1bHQgdmFsdWVzIGluIHVzZSAoc2VlIFNlY3Rp
b24gNy42LjEpLg0KDQoNClRoaXMgd2FzIGNoYW5nZWQgaW4gWUFORyAxLjENCg0Kc2VjIDcuNS4z
Og0KDQoNCiAgIFdoZW4gYSBkYXRhc3RvcmUgaXMgdmFsaWRhdGVkLCBhbGwgIm11c3QiIGNvbnN0
cmFpbnRzIGFyZQ0KDQogICBjb25jZXB0dWFsbHkgZXZhbHVhdGVkIG9uY2UgZm9yIGVhY2ggbm9k
ZSBpbiB0aGUgYWNjZXNzaWJsZSB0cmVlIChzZWUNCg0KICAgU2VjdGlvbiA2LjQuMSkuDQpTZWMu
IDYuNC4xDQoNCiAgICAgIElmIGEgbm9kZSB0aGF0IGV4aXN0cyBpbiB0aGUgYWNjZXNzaWJsZSB0
cmVlIGhhcyBhIG5vbi1wcmVzZW5jZQ0KICAgICAgY29udGFpbmVyIGFzIGEgY2hpbGQsIHRoZW4g
dGhlIG5vbi1wcmVzZW5jZSBjb250YWluZXIgYWxzbyBleGlzdHMgaW4NCiAgICAgIHRoZSB0cmVl
Lg0KDQoNCkFuZHkNCg0KDQoNCg0KT24gTW9uLCBBdWcgMSwgMjAxNiBhdCA3OjUxIEFNLCBXaWxs
aWFtIEl2b3J5IDx3aXZvcnlAYnJvY2FkZS5jb208bWFpbHRvOndpdm9yeUBicm9jYWRlLmNvbT4+
IHdyb3RlOg0KSGksDQoNCkNvdWxkIHNvbWVvbmUgY29uZmlybSB0aGVuIHRoYXQgbXVzdCBzdGF0
ZW1lbnRzIG9uIGEgbm9uLXByZXNlbmNlIGNvbnRhaW5lciBpbiBZQU5HIDEuMCBhcmUgb25seSB0
byBiZSBldmFsdWF0ZWQgaWYgdGhlIG5vbi1wcmVzZW5jZSBjb250YWluZXIgaGFzIGNvbmZpZ3Vy
ZWQgY2hpbGRyZW4g4oCmIG9yIGlzIGl0IGFsc28gaWYgKHJlYWRpbmcgTGFkYeKAmXMgbWFpbCkg
dGhlIGltcGxlbWVudGF0aW9uIGNob29zZXMgdG8gaW1wbGVtZW50IHRoZW0gd2hlbiB0aGVyZSBh
cmUgbm8gY2hpbGRyZW4gcHJlc2VudD8NCg0KSSBoYWQgYXNzdW1lZCB0aGF0IHRoZSB0ZXh0IGlu
IFlBTkcgMS4xIHdhcyBjbGFyaWZ5aW5nIFlBTkcgMS4wIHJhdGhlciB0aGFuIG5ldyBmdW5jdGlv
bmFsaXR5IGhlcmUgYnV0IEnigJltIGEgbGl0dGxlIGNvbmZ1c2VkIG5vdywgZXNwZWNpYWxseSBn
aXZlbiB0aGUgY29tbWVudCBieSBKYW4gTGluZGJsYWQgcmVnYXJkaW5nIHRoaXMgWUFORyBzbmlw
cGV0IGFzIHRoZSBmaWxlIGRvZXMgbm90IGNvbnRhaW4g4oCYeWFuZy12ZXJzaW9uIDEuMeKAmSBh
bmQgd291bGQgc3VyZWx5IHRoZXJlZm9yZSBiZSB2ZXJzaW9uIDEuMD8NCg0KICAgICAgY29udGFp
bmVyIG93bmVyc2hpcC12b3VjaGVyIHsNCiAgICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAi
VGhpcyBjb250YWluZXIgY29udGFpbnMgdGhlIE93bmVyc2hpcCBWb3VjaGVyIHRoYXQgdGhlDQog
ICAgICAgICAgIGRldmljZSB1c2VzIHRvIGFzY2VydGFpbiB0aGUgaWRlbnRpdHkgb2YgaXRzIHJp
Z2h0ZnVsDQogICAgICAgICAgIG93bmVyLCBhcyBjZXJ0aWZpZWQgYnkgaXRzIFZlbmRvci4iOw0K
DQogICAgICAgIHdoZW4gIi4uL3JlZGlyZWN0LWluZm9ybWF0aW9uL3NpZ25hdHVyZSBvciAuLi9i
b290c3RyYXAtaW5mb3JtYXRpb24vKi9zaWduYXR1cmUiOw0KICAgICAgICBtdXN0ICIuLi9vd25l
ci1jZXJ0aWZpY2F0ZSI7DQoNCiAgICAgICAgdXNlcyBvd25lcnNoaXAtdm91Y2hlci1ncm91cGlu
ZzsNCiAgICAgIH0NCg0KDQpodHRwczovL2dpdGh1Yi5jb20vWWFuZ01vZGVscy95YW5nL2Jsb2Iv
bWFzdGVyL3N0YW5kYXJkL2lldGYvRFJBRlQvaWV0Zi16ZXJvdG91Y2gtYm9vdHN0cmFwLXNlcnZl
ci55YW5nPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z
QV9fZ2l0aHViLmNvbV9ZYW5nTW9kZWxzX3lhbmdfYmxvYl9tYXN0ZXJfc3RhbmRhcmRfaWV0Zl9E
UkFGVF9pZXRmLTJEemVyb3RvdWNoLTJEYm9vdHN0cmFwLTJEc2VydmVyLnlhbmcmZD1Dd01GYVEm
Yz1JTF9YcVFXT2p1YmdmcUlOaTJqVHpnJnI9R0J5TGVnOWpadk92X0FsZ0JvOXV2ZERyeGl6bE9S
N2xfU25UWG93eUpVOCZtPVVfcW10X1YzMElwNzMwZ20wWkwwZzlWT0N0U0dlWEhIVXdqcmdYRlVX
RVEmcz12TTNqREt6bV9xLUlCelFkbmVDVWtNWTcxMFQxa1otTzJoaF9WaFNNZEJvJmU9Pg0KDQpK
YW7igJlzIGNvbW1lbnQgb24gdGhpcyBZQU5HIChhc3N1bWluZyBpdOKAmXMgMS4wKSBhbmQgTGFk
YeKAmXMgYXNzZXJ0aW9uIChwYXN0ZWQgYmVsb3cpIGFwcGVhciBjb250cmFkaWN0b3J5IHRvIG1l
Lg0KDQrigJhOUCBjb250YWluZXJzIHdlcmUgbm90IGFsd2F5cyBwcmVzZW50IGluIFlBTkcgMS4w
Lg0KVGhlIG11c3Qtc3RtdCBvbmx5IGFwcGxpZWQgaWYgdGhleSBhY3R1YWxseSBhcmUgcHJlc2Vu
dCwNCndoaWNoIGlzIGFuIGltcGxlbWVudGF0aW9uIGNob2ljZS4NCuKAmA0KDQpJ4oCZbSBhbHNv
IHRoaW5raW5nIHRoYXQgYW55IG11c3Qgc3RhdGVtZW50IG9uIGEgbm9uLXByZXNlbmNlIGNvbnRh
aW5lciBpbiBZQU5HIDEuMCBtb2RlbHMgbWlnaHQgc2Vuc2libHkgYmUgKHJlKXdyaXR0ZW4gYXMg
4oCYbm90KGN1cnJlbnQoKSBvciA8cmVxdWlyZWRfeHBhdGhfZXhwcmVzc2lvbj7igJkgdG8gbWFr
ZSBpdCBmdXR1cmUtcHJvb2YgaWYgdGhlc2Ugbm9kZXMgZG8gbm90IGV4aXN0IGluIDEuMCB3L28g
Y2hpbGRyZW4gYnV0IGRvIGluIFlBTkcgMS4xLiAgVGhhdCB3b3VsZCBhbGxvdyBmb3IgZWFzaWVy
IG1vZGVsIG1pZ3JhdGlvbi4NCg0KUmVnYXJkcywNCg0KV2lsbGlhbQ0KDQpGcm9tOiBOZXRjb25m
IFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRjb25mLWJvdW5jZXNA
aWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgQW5keSBCaWVybWFuDQpTZW50OiAwMSBBdWd1c3QgMjAx
NiAxNToyMw0KVG86IExhZGlzbGF2IExob3RrYSA8bGhvdGthQG5pYy5jejxtYWlsdG86bGhvdGth
QG5pYy5jej4+DQpDYzogTmV0Y29uZiA8bmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBp
ZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW05ldGNvbmZdIFdoYXQgc2hvdWxkIGEgc2VydmVyIHJl
c3BvbnNlIGJlPyAtIGRlcGVuZGluZyBvbiBOUC1jb250YWluZXJzDQoNCg0KDQpPbiBNb24sIEF1
ZyAxLCAyMDE2IGF0IDc6MTMgQU0sIExhZGlzbGF2IExob3RrYSA8bGhvdGthQG5pYy5jejxtYWls
dG86bGhvdGthQG5pYy5jej4+IHdyb3RlOg0KQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5j
b208bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4+IHdyaXRlczoNCg0KPiBIaSwNCj4NCj4gWUFO
RyAxLjEgaGFzIGJlZW4gY2hhbmdlZCBzbyB0aGUgWFBhdGggaXMgbm90IHJlYWxseSBiYWNrd2Fy
ZC1jb21wYXRpYmxlDQo+IHdpdGggWUFORyAxLjAuICBJbiBZQU5HIDEuMSBOUC1jb250YWluZXJz
IGFsd2F5cyBleGlzdCBpZiB0aGUgbm9uLU5QIHBhcmVudA0KPiBpcw0KPiBpbnN0YW50aWF0ZWQu
DQoNCk15IG1lbnRhbCBtb2RlbCByZWdhcmRpbmcgTlAtY29udGFpbmVycyBpcyB0aGF0IHRoZXkg
YXJlIHBhcnQgb2YNCnRoZSBkZWZhdWx0IGNvbnRlbnRzIG9mIGEgZGF0YXN0b3JlLiBJZiBhbiBO
UC1jb250YWluZXIgaXMgImluIHVzZSINCihhY2NvcmRpbmcgdG8gdGhlIHNhbWUgcnVsZXMgYXMg
c3BlY2lmaWVkIGluIHNlYy4gNy42LjEgb2YgNjAyMGJpcyBmb3INCmRlZmF1bHQgbGVhdmVzKSwg
dGhlbg0KDQotIGNyZWF0aW5nIGEgY2hpbGQgb2YgdGhpcyBjb250YWluZXIgc3VjY2VlZHMsDQoN
Ci0gIm11c3QiIGV4cHJlc3Npb25zIGRlZmluZWQgb24gdGhpcyBjb250YWluZXIgYXBwbHkuDQoN
Cg0KTlAgY29udGFpbmVycyB3ZXJlIG5vdCBhbHdheXMgcHJlc2VudCBpbiBZQU5HIDEuMC4NClRo
ZSBtdXN0LXN0bXQgb25seSBhcHBsaWVkIGlmIHRoZXkgYWN0dWFsbHkgYXJlIHByZXNlbnQsDQp3
aGljaCBpcyBhbiBpbXBsZW1lbnRhdGlvbiBjaG9pY2UuDQoNCkkgZG9uJ3QgdW5kZXJzdGFuZCBh
bGwgdGhpcyBzcGVjaWFsIHdvcmRpbmcgYWJvdXQgImRvIG5vdCBlcnJvciBpZi4uLiINCg0KTkVU
Q09ORiBoYXMgZXhwbGljaXQgc3VwcG9ydCBmb3IgdGhpcyBleGFjdCB1c2UtY2FzZSwgY2FsbGVk
ICJtZXJnZSIuDQpUaGlzIHdhcyBkb25lIHByZWNpc2VseSB0byBzdXBwb3J0IHRoZXNlICJkb24n
dCBlcnJvciBpZi4uLiIgY2FzZXMuDQpTbyB1c2UgIm1lcmdlIiBpZiB5b3Ugd2FudCB0aGlzIGZ1
bmN0aW9uYWxpdHkuDQoNCg0KTGFkYQ0KDQpBbmR5DQoNCg0KPg0KPiBORVRDT05GIGFuZCBSRVNU
Q09ORiBkbyBub3Qgc2F5IGFueXRoaW5nIGFib3V0IHRoZSBzZXJ2ZXIgaWdub3JpbmcNCj4gdGhl
IHJ1bGVzIGZvciBvcGVyYXRpb249ImNyZWF0ZSIsIG9wZXJhdGlvbj0iZGVsZXRlIiBhbmQNCj4g
ZGVmYXVsdC1vcGVyYXRpb249Im5vbmUiLg0KPiBJTU8gaXRyIHdvdWxkIGJlIGEgcmVhbGx5IGJh
ZCBpZGVhIHRvIGNvbnRpbnVlIHNwcmVhZGluZyBsaXR0bGUgcHJvdG9jb2wNCj4gZGV0YWlscw0K
PiBpbiB0aGUgWUFORyBSRkMuICBQZW9wbGUgbWlnaHQgcmVhZCB0aGUgcHJvdG9jb2wgc3BlYyBh
bmQgKGNvcnJlY3RseSkgYXNzdW1lDQo+IHRoYXQgdGhlIHByb3RvY29sIGRvZXMgbm90IHRyYXQg
TlAgY29udGFpbmVycyBzcGVjaWFsIGF0IGFsbC4NCj4NCj4gSWYgYW55dGhpbmcsIHRoZSBzZW50
ZW5jZSBhYm91dCBNQVkgZGVsZXRlIG5lZWRzIHRvIGJlIHJlbW92ZWQgYmVjYXVzZQ0KPiBpdCBp
cyBpbmNvbnNpc3RlbnQgd2l0aCB0aGUgWFBhdGggKGFsd2F5cyBleGlzdHMpLg0KPg0KPg0KPiBB
bmR5DQo+DQo+DQo+IE9uIFN1biwgSnVsIDMxLCAyMDE2IGF0IDY6MTMgUE0sIERhbGUgUi4gV29y
bGV5IDx3b3JsZXlAYXJpYWRuZS5jb208bWFpbHRvOndvcmxleUBhcmlhZG5lLmNvbT4+IHdyb3Rl
Og0KPg0KPj4gTWFoZXNoIEpldGhhbmFuZGFuaSA8bWpldGhhbmFuZGFuaUBnbWFpbC5jb208bWFp
bHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPj4gd3JpdGVzOg0KPj4gPiBJIHRoaW5rIHRoaXMg
YXJndW1lbnQgb2Ygd2hldGhlciBzZXJ2ZXIgc2hvdWxkIG9yIHNob3VsZCBub3QNCj4+ID4gY3Jl
YXRlL2RlbGV0ZSBOUCBjb250YWluZXJzIGlzIGRpc3RyYWN0aW5nIGZyb20gdGhlIG1haW4gcG9p
bnQgb2Ygd2hlbg0KPj4gPiBOUCBjb250YWluZXJzIHNob3VsZCBleGlzdC4gSW4gbXkgbWluZCwg
dGhlIE5QIGNvbnRhaW5lciBleGlzdGVuY2UNCj4+ID4gZGVwZW5kcyBvbiB3aGV0aGVyIGNoaWxk
IG5vZGVzIGV4aXN0IG9yIG5vdC4gSW4gdGhlIGVuZCwgaWYgY2hpbGQNCj4+ID4gbm9kZXMgZXhp
c3QsIE5QIGNvbnRhaW5lcnMgc2hvdWxkIGV4aXN0IChjcmVhdGVkKSwgaWYgdGhleSBkbyBub3QN
Cj4+ID4gZXhpc3QsIHRoZSBOUCBjb250YWluZXIgc2hvdWxkIGJlIHJlbW92ZWQuDQo+PiA+DQo+
PiA+IENhbiB3ZSBhZ3JlZSBvbiB0aGF0Pw0KPj4NCj4+IElmIHRoZSBjb25jZXB0IG9mIGEgIm5v
bi1wcmVzZW5jZSBjb250YWluZXIiIG1ha2VzIGFueSBzZW5zZSwgdGhlbiB0aGUNCj4+IGV4aXN0
ZW5jZSBvZiBhbiBlbXB0eSBjb250YWluZXIgbXVzdCBoYXZlIGV4YWN0bHkgdGhlIHNhbWUgc2ln
bmlmaWNhbmNlDQo+PiBhcyB0aGUgbm9uLWV4dGVuY2Ugb2YgdGhlIGNvbnRhaW5lci4NCj4+DQo+
PiBHaXZlbiB0aGF0LCB3ZSBoYXZlIHRvIG1ha2Ugc3VyZSB0aGUgcHJvdG9jb2wgaXMgY29uc2lz
dGVudCB3aXRoIHRoYXQNCj4+IHByaW5jaXBsZS4gIEUuZy4sIGlmIHlvdSBhc2sgdG8gY3JlYXRl
IGFuIGVsZW1lbnQgb2YgYSBub24tZXhpc3RpbmcgTlANCj4+IGNvbnRhaW5lciwgaXQgbXVzdCBz
dWNjZWVkLCBiZWNhdXNlIGFza2luZyB0byBjcmVhdGUgYW4gZWxlbWVudCBvZiBhbg0KPj4gZXhp
c3RpbmcgYnV0IGVtcHR5IE5QIGNvbnRhaW5lciBzdWNjZWVkcy4NCj4+DQo+PiBJIGRvbid0IHNl
ZSB3aGF0IGFsbCB0aGUgY29uc2VxdWVuY2VzIG9mIHRoaXMgcHJpbmNpcGxlIGFyZSwgYnV0IGlm
IHdlDQo+PiBjYW4ndCBtYWtlIHRoZSBwcm90b2NvbCBjb25zaXN0ZW50IHdpdGggaXQsIHRoZW4g
d2UgY2FuJ3QgcHJvcGVybHkNCj4+IGltcGxlbWVudCB0aGUgY29uY2VwdCBvZiBOUCBjb250YWlu
ZXJzLg0KPj4NCj4+IERhbGUNCj4+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQo+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+IE5ldGNvbmZAaWV0Zi5v
cmc8bWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vbmV0Y29uZjxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv
dXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldGNvbmYmZD1D
d01GYVEmYz1JTF9YcVFXT2p1YmdmcUlOaTJqVHpnJnI9R0J5TGVnOWpadk92X0FsZ0JvOXV2ZERy
eGl6bE9SN2xfU25UWG93eUpVOCZtPTVEeEdjMThpZ0xMYXpvd0VKUnFmbEwyVnprQy1IVmNQeFh1
ejdsdGdHVGcmcz1sS1FNN0s2WWFOVC1reXVYc1BScWx1WjdsUFdrODRabGFzTm1IMjg4SXowJmU9
Pg0KDQotLQ0KTGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KUEdQIEtleSBJRDogRTc0RThD
MEMNCg0KDQo=

--_000_78c52bbab4d44b938e1dcf191d95b42aEMEAWPEXMB11corpbrocade_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0
dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt
c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVm
b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN
Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0
dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1H
Qjt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0
eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh
bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt
c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z
ZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN
Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy
LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5
bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0
IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld
Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp
dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh
ZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg
Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkgQW5keSw8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5rcyDigJMgaW4gaXNvbGF0
aW9uIHRoYXQgaXMgY2xlYXIsIGJ1dCBJIHdvdWxkIGJlIGludGVyZXN0ZWQgaW4gSmFu4oCZcyB0
aG91Z2h0cyBnaXZlbiB0aGF0IHRoZSBnaXZlbiBvd25lcnNoaXAtdm91Y2hlciBleGFtcGxlIHdv
dWxkDQogYXBwZWFyIHRvIGJlIFlBTkcgMS4wICo8Yj5hbmQ8L2I+KiBhc3N1bWUgbXVzdCBzdGF0
ZW1lbnRzIGFyZSBldmFsdWF0ZWQgb24gbm9uLXByZXNlbmNlIGNvbnRhaW5lcnMgaWYgdGhlIHBh
cmVudCBub2RlIGV4aXN0cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF
Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi
PlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5XaWxsaWFt
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmIj4gQW5keSBCaWVybWFuIFttYWlsdG86YW5keUB5dW1hd29ya3MuY29tXQ0KPGJyPg0KPGI+
U2VudDo8L2I+IDAxIEF1Z3VzdCAyMDE2IDE2OjAzPGJyPg0KPGI+VG86PC9iPiBXaWxsaWFtIEl2
b3J5ICZsdDt3aXZvcnlAQnJvY2FkZS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBMYWRpc2xhdiBM
aG90a2EgJmx0O2xob3RrYUBuaWMuY3omZ3Q7OyBqYW5sQHRhaWwtZi5jb207IE5ldGNvbmYgJmx0
O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTmV0Y29uZl0g
V2hhdCBzaG91bGQgYSBzZXJ2ZXIgcmVzcG9uc2UgYmU/IC0gZGVwZW5kaW5nIG9uIE5QLWNvbnRh
aW5lcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpw
PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgSSBtYWRlIHRoYXQg
Y29tbWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkluIFlBTkcgMS4wLCBvbmx5IGRlZmF1bHQgbGVhZnMgd2VyZSBjb25zaWRlcmVkIGFsd2F5
cyBwcmVzZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+SW4gWUFORyAxLjEgTlAgY29udGFpbmVycyB3ZXJlIGFkZGVkIHRvIHRoZSBzZXQgb2Yg
YWNjZXNzaWJsZSBub2RlczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5JbiBZQU5HIDEuMCwgc2VjLiA3LjUuMzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+PHNwYW4gc3R5
bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgbyZuYnNwOyBUaGUgYWNjZXNzaWJsZSB0cmVl
IGlzIG1hZGUgdXAgb2YgYWxsIG5vZGVzIGluIHRoZSBkYXRhIHRyZWUsIGFuZDxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyBhbGwgbGVhZnMgd2l0aCBkZWZhdWx0IHZhbHVlcyBpbiB1c2Ug
KHNlZSBTZWN0aW9uIDcuNi4xKS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PG86cD4m
bmJzcDs8L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgd2FzIGNoYW5nZWQg
aW4gWUFORyAxLjE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+c2VjIDcuNS4zOjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT48c3Bh
biBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBXaGVuIGEgZGF0YXN0b3JlIGlzIHZh
bGlkYXRlZCwgYWxsICZxdW90O211c3QmcXVvdDsgY29uc3RyYWludHMgYXJlPG86cD48L286cD48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7
IGNvbmNlcHR1YWxseSBldmFsdWF0ZWQgb25jZSBmb3IgZWFjaCBub2RlIGluIHRoZSBhY2Nlc3Np
YmxlIHRyZWUgKHNlZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBTZWN0aW9uIDYuNC4xKS48bzpwPjwvbzpwPjwvc3Bh
bj48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlYy4gNi40LjE8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IElmIGEgbm9kZSB0aGF0IGV4aXN0cyBpbiB0aGUgYWNj
ZXNzaWJsZSB0cmVlIGhhcyBhIG5vbi1wcmVzZW5jZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgY29udGFpbmVy
IGFzIGEgY2hpbGQsIHRoZW4gdGhlIG5vbi1wcmVzZW5jZSBjb250YWluZXIgYWxzbyBleGlzdHMg
aW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu
YnNwOyAmbmJzcDsgJm5ic3A7IHRoZSB0cmVlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEF1ZyAx
LCAyMDE2IGF0IDc6NTEgQU0sIFdpbGxpYW0gSXZvcnkgJmx0OzxhIGhyZWY9Im1haWx0bzp3aXZv
cnlAYnJvY2FkZS5jb20iIHRhcmdldD0iX2JsYW5rIj53aXZvcnlAYnJvY2FkZS5jb208L2E+Jmd0
OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti
b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7
bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpLDwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNvdWxkIHNvbWVvbmUg
Y29uZmlybSB0aGVuIHRoYXQgbXVzdCBzdGF0ZW1lbnRzIG9uIGEgbm9uLXByZXNlbmNlIGNvbnRh
aW5lciBpbiBZQU5HIDEuMCBhcmUgb25seSB0bw0KIGJlIGV2YWx1YXRlZCBpZiB0aGUgbm9uLXBy
ZXNlbmNlIGNvbnRhaW5lciBoYXMgY29uZmlndXJlZCBjaGlsZHJlbiDigKYgb3IgaXMgaXQgYWxz
byBpZiAocmVhZGluZyBMYWRh4oCZcyBtYWlsKSB0aGUgaW1wbGVtZW50YXRpb24gY2hvb3NlcyB0
byBpbXBsZW1lbnQgdGhlbSB3aGVuIHRoZXJlIGFyZSBubyBjaGlsZHJlbiBwcmVzZW50Pzwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgaGFkIGFzc3VtZWQg
dGhhdCB0aGUgdGV4dCBpbiBZQU5HIDEuMSB3YXMgY2xhcmlmeWluZyBZQU5HIDEuMCByYXRoZXIg
dGhhbiBuZXcgZnVuY3Rpb25hbGl0eSBoZXJlDQogYnV0IEnigJltIGEgbGl0dGxlIGNvbmZ1c2Vk
IG5vdywgZXNwZWNpYWxseSBnaXZlbiB0aGUgY29tbWVudCBieSBKYW4gTGluZGJsYWQgcmVnYXJk
aW5nIHRoaXMgWUFORyBzbmlwcGV0IGFzIHRoZSBmaWxlIGRvZXMgbm90IGNvbnRhaW4g4oCYeWFu
Zy12ZXJzaW9uIDEuMeKAmSBhbmQgd291bGQgc3VyZWx5IHRoZXJlZm9yZSBiZSB2ZXJzaW9uIDEu
MD88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7Y29udGFpbmVyIG93
bmVyc2hpcC12b3VjaGVyIHs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDtk
ZXNjcmlwdGlvbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsm
cXVvdDtUaGlzIGNvbnRhaW5lciBjb250YWlucyB0aGUgT3duZXJzaGlwIFZvdWNoZXIgdGhhdCB0
aGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RldmljZSB1
c2VzIHRvIGFzY2VydGFpbiB0aGUgaWRlbnRpdHkgb2YgaXRzIHJpZ2h0ZnVsPGJyPg0KJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtvd25lciwgYXMgY2VydGlmaWVkIGJ5
IGl0cyBWZW5kb3IuJnF1b3Q7Ozxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyZuYnNwO3doZW4gJnF1b3Q7Li4vcmVkaXJlY3QtaW5mb3JtYXRpb24vc2lnbmF0dXJlIG9yIC4u
L2Jvb3RzdHJhcC1pbmZvcm1hdGlvbi8qL3NpZ25hdHVyZSZxdW90Ozs8YnI+DQombmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsmbmJzcDttdXN0ICZxdW90Oy4uL293bmVyLWNlcnRpZmljYXRlJnF1
b3Q7Ozxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwO3VzZXMgb3du
ZXJzaGlwLXZvdWNoZXItZ3JvdXBpbmc7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPiZuYnNwOyAmbmJzcDsgJm5ic3A7IH08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHBzOi8v
dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZ2l0aHViLmNvbV9Z
YW5nTW9kZWxzX3lhbmdfYmxvYl9tYXN0ZXJfc3RhbmRhcmRfaWV0Zl9EUkFGVF9pZXRmLTJEemVy
b3RvdWNoLTJEYm9vdHN0cmFwLTJEc2VydmVyLnlhbmcmYW1wO2Q9Q3dNRmFRJmFtcDtjPUlMX1hx
UVdPanViZ2ZxSU5pMmpUemcmYW1wO3I9R0J5TGVnOWpadk92X0FsZ0JvOXV2ZERyeGl6bE9SN2xf
U25UWG93eUpVOCZhbXA7bT1VX3FtdF9WMzBJcDczMGdtMFpMMGc5Vk9DdFNHZVhISFV3anJnWEZV
V0VRJmFtcDtzPXZNM2pES3ptX3EtSUJ6UWRuZUNVa01ZNzEwVDFrWi1PMmhoX1ZoU01kQm8mYW1w
O2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9naXRodWIuY29tL1lhbmdNb2RlbHMveWFuZy9i
bG9iL21hc3Rlci9zdGFuZGFyZC9pZXRmL0RSQUZUL2lldGYtemVyb3RvdWNoLWJvb3RzdHJhcC1z
ZXJ2ZXIueWFuZzwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0
OTdEIj5KYW7igJlzIGNvbW1lbnQgb24gdGhpcyBZQU5HIChhc3N1bWluZyBpdOKAmXMgMS4wKSBh
bmQgTGFkYeKAmXMgYXNzZXJ0aW9uIChwYXN0ZWQgYmVsb3cpIGFwcGVhciBjb250cmFkaWN0b3J5
DQogdG8gbWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+
4oCYPC9zcGFuPk5QIGNvbnRhaW5lcnMgd2VyZSBub3QgYWx3YXlzIHByZXNlbnQgaW4gWUFORyAx
LjAuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBtdXN0LXN0bXQg
b25seSBhcHBsaWVkIGlmIHRoZXkgYWN0dWFsbHkgYXJlIHByZXNlbnQsPG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPndoaWNoIGlzIGFuIGltcGxlbWVudGF0aW9uIGNob2lj
ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0QiPuKAmDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMxRjQ5N0QiPknigJltIGFsc28gdGhpbmtpbmcgdGhhdCBhbnkgbXVzdCBzdGF0ZW1lbnQgb24g
YSBub24tcHJlc2VuY2UgY29udGFpbmVyIGluIFlBTkcgMS4wIG1vZGVscyBtaWdodCBzZW5zaWJs
eQ0KIGJlIChyZSl3cml0dGVuIGFzIOKAmG5vdChjdXJyZW50KCkgb3IgJmx0O3JlcXVpcmVkX3hw
YXRoX2V4cHJlc3Npb24mZ3Q74oCZIHRvIG1ha2UgaXQgZnV0dXJlLXByb29mIGlmIHRoZXNlIG5v
ZGVzIGRvIG5vdCBleGlzdCBpbiAxLjAgdy9vIGNoaWxkcmVuIGJ1dCBkbyBpbiBZQU5HIDEuMS4m
bmJzcDsgVGhhdCB3b3VsZCBhbGxvdyBmb3IgZWFzaWVyIG1vZGVsIG1pZ3JhdGlvbi48L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldpbGxpYW08L3NwYW4+PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gTmV0Y29uZg0KIFttYWlsdG86PGEgaHJlZj0i
bWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldGNvbmYt
Ym91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFuZHkgQmllcm1hbjxi
cj4NCjxiPlNlbnQ6PC9iPiAwMSBBdWd1c3QgMjAxNiAxNToyMzxicj4NCjxiPlRvOjwvYj4gTGFk
aXNsYXYgTGhvdGthICZsdDs8YSBocmVmPSJtYWlsdG86bGhvdGthQG5pYy5jeiIgdGFyZ2V0PSJf
YmxhbmsiPmxob3RrYUBuaWMuY3o8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gTmV0Y29uZiAmbHQ7
PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uZXRjb25m
QGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtOZXRjb25mXSBXaGF0
IHNob3VsZCBhIHNlcnZlciByZXNwb25zZSBiZT8gLSBkZXBlbmRpbmcgb24gTlAtY29udGFpbmVy
czwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gTW9uLCBBdWcgMSwgMjAxNiBh
dCA3OjEzIEFNLCBMYWRpc2xhdiBMaG90a2EgJmx0OzxhIGhyZWY9Im1haWx0bzpsaG90a2FAbmlj
LmN6IiB0YXJnZXQ9Il9ibGFuayI+bGhvdGthQG5pYy5jejwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v
OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk
ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw
dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFy
Z2luLWJvdHRvbToxMi4wcHQiPkFuZHkgQmllcm1hbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFuZHlA
eXVtYXdvcmtzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFuZHlAeXVtYXdvcmtzLmNvbTwvYT4mZ3Q7
IHdyaXRlczo8YnI+DQo8YnI+DQomZ3Q7IEhpLDxicj4NCiZndDs8YnI+DQomZ3Q7IFlBTkcgMS4x
IGhhcyBiZWVuIGNoYW5nZWQgc28gdGhlIFhQYXRoIGlzIG5vdCByZWFsbHkgYmFja3dhcmQtY29t
cGF0aWJsZTxicj4NCiZndDsgd2l0aCBZQU5HIDEuMC4mbmJzcDsgSW4gWUFORyAxLjEgTlAtY29u
dGFpbmVycyBhbHdheXMgZXhpc3QgaWYgdGhlIG5vbi1OUCBwYXJlbnQ8YnI+DQomZ3Q7IGlzPGJy
Pg0KJmd0OyBpbnN0YW50aWF0ZWQuPGJyPg0KPGJyPg0KTXkgbWVudGFsIG1vZGVsIHJlZ2FyZGlu
ZyBOUC1jb250YWluZXJzIGlzIHRoYXQgdGhleSBhcmUgcGFydCBvZjxicj4NCnRoZSBkZWZhdWx0
IGNvbnRlbnRzIG9mIGEgZGF0YXN0b3JlLiBJZiBhbiBOUC1jb250YWluZXIgaXMgJnF1b3Q7aW4g
dXNlJnF1b3Q7PGJyPg0KKGFjY29yZGluZyB0byB0aGUgc2FtZSBydWxlcyBhcyBzcGVjaWZpZWQg
aW4gc2VjLiA3LjYuMSBvZiA2MDIwYmlzIGZvcjxicj4NCmRlZmF1bHQgbGVhdmVzKSwgdGhlbjxi
cj4NCjxicj4NCi0gY3JlYXRpbmcgYSBjaGlsZCBvZiB0aGlzIGNvbnRhaW5lciBzdWNjZWVkcyw8
YnI+DQo8YnI+DQotICZxdW90O211c3QmcXVvdDsgZXhwcmVzc2lvbnMgZGVmaW5lZCBvbiB0aGlz
IGNvbnRhaW5lciBhcHBseS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TlAgY29udGFpbmVycyB3ZXJlIG5vdCBhbHdh
eXMgcHJlc2VudCBpbiBZQU5HIDEuMC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIG11c3Qtc3RtdCBvbmx5IGFwcGxpZWQgaWYgdGhleSBh
Y3R1YWxseSBhcmUgcHJlc2VudCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+d2hpY2ggaXMgYW4gaW1wbGVtZW50YXRpb24gY2hvaWNlLjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBk
b24ndCB1bmRlcnN0YW5kIGFsbCB0aGlzIHNwZWNpYWwgd29yZGluZyBhYm91dCAmcXVvdDtkbyBu
b3QgZXJyb3IgaWYuLi4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPk5FVENPTkYgaGFzIGV4cGxpY2l0IHN1cHBvcnQgZm9yIHRo
aXMgZXhhY3QgdXNlLWNhc2UsIGNhbGxlZCAmcXVvdDttZXJnZSZxdW90Oy48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhpcyB3YXMgZG9uZSBw
cmVjaXNlbHkgdG8gc3VwcG9ydCB0aGVzZSAmcXVvdDtkb24ndCBlcnJvciBpZi4uLiZxdW90OyBj
YXNlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+U28gdXNlICZxdW90O21lcmdlJnF1b3Q7IGlmIHlvdSB3YW50IHRoaXMgZnVuY3Rpb25hbGl0
eS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj
bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
TGFkYTxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp
bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt
YXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48YnI+DQomZ3Q7PGJyPg0KJmd0OyBORVRDT05GIGFuZCBSRVNUQ09ORiBkbyBub3Qgc2F5
IGFueXRoaW5nIGFib3V0IHRoZSBzZXJ2ZXIgaWdub3Jpbmc8YnI+DQomZ3Q7IHRoZSBydWxlcyBm
b3Igb3BlcmF0aW9uPSZxdW90O2NyZWF0ZSZxdW90Oywgb3BlcmF0aW9uPSZxdW90O2RlbGV0ZSZx
dW90OyBhbmQ8YnI+DQomZ3Q7IGRlZmF1bHQtb3BlcmF0aW9uPSZxdW90O25vbmUmcXVvdDsuPGJy
Pg0KJmd0OyBJTU8gaXRyIHdvdWxkIGJlIGEgcmVhbGx5IGJhZCBpZGVhIHRvIGNvbnRpbnVlIHNw
cmVhZGluZyBsaXR0bGUgcHJvdG9jb2w8YnI+DQomZ3Q7IGRldGFpbHM8YnI+DQomZ3Q7IGluIHRo
ZSBZQU5HIFJGQy4mbmJzcDsgUGVvcGxlIG1pZ2h0IHJlYWQgdGhlIHByb3RvY29sIHNwZWMgYW5k
IChjb3JyZWN0bHkpIGFzc3VtZTxicj4NCiZndDsgdGhhdCB0aGUgcHJvdG9jb2wgZG9lcyBub3Qg
dHJhdCBOUCBjb250YWluZXJzIHNwZWNpYWwgYXQgYWxsLjxicj4NCiZndDs8YnI+DQomZ3Q7IElm
IGFueXRoaW5nLCB0aGUgc2VudGVuY2UgYWJvdXQgTUFZIGRlbGV0ZSBuZWVkcyB0byBiZSByZW1v
dmVkIGJlY2F1c2U8YnI+DQomZ3Q7IGl0IGlzIGluY29uc2lzdGVudCB3aXRoIHRoZSBYUGF0aCAo
YWx3YXlzIGV4aXN0cykuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEFuZHk8YnI+DQom
Z3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgT24gU3VuLCBKdWwgMzEsIDIwMTYgYXQgNjoxMyBQTSwg
RGFsZSBSLiBXb3JsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp3b3JsZXlAYXJpYWRuZS5jb20iIHRh
cmdldD0iX2JsYW5rIj53b3JsZXlAYXJpYWRuZS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7
PGJyPg0KJmd0OyZndDsgTWFoZXNoIEpldGhhbmFuZGFuaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1q
ZXRoYW5hbmRhbmlAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWpldGhhbmFuZGFuaUBnbWFp
bC5jb208L2E+Jmd0OyB3cml0ZXM6PGJyPg0KJmd0OyZndDsgJmd0OyBJIHRoaW5rIHRoaXMgYXJn
dW1lbnQgb2Ygd2hldGhlciBzZXJ2ZXIgc2hvdWxkIG9yIHNob3VsZCBub3Q8YnI+DQomZ3Q7Jmd0
OyAmZ3Q7IGNyZWF0ZS9kZWxldGUgTlAgY29udGFpbmVycyBpcyBkaXN0cmFjdGluZyBmcm9tIHRo
ZSBtYWluIHBvaW50IG9mIHdoZW48YnI+DQomZ3Q7Jmd0OyAmZ3Q7IE5QIGNvbnRhaW5lcnMgc2hv
dWxkIGV4aXN0LiBJbiBteSBtaW5kLCB0aGUgTlAgY29udGFpbmVyIGV4aXN0ZW5jZTxicj4NCiZn
dDsmZ3Q7ICZndDsgZGVwZW5kcyBvbiB3aGV0aGVyIGNoaWxkIG5vZGVzIGV4aXN0IG9yIG5vdC4g
SW4gdGhlIGVuZCwgaWYgY2hpbGQ8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IG5vZGVzIGV4aXN0LCBOUCBj
b250YWluZXJzIHNob3VsZCBleGlzdCAoY3JlYXRlZCksIGlmIHRoZXkgZG8gbm90PGJyPg0KJmd0
OyZndDsgJmd0OyBleGlzdCwgdGhlIE5QIGNvbnRhaW5lciBzaG91bGQgYmUgcmVtb3ZlZC48YnI+
DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBDYW4gd2UgYWdyZWUgb24gdGhhdD88
YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IElmIHRoZSBjb25jZXB0IG9mIGEgJnF1b3Q7bm9u
LXByZXNlbmNlIGNvbnRhaW5lciZxdW90OyBtYWtlcyBhbnkgc2Vuc2UsIHRoZW4gdGhlPGJyPg0K
Jmd0OyZndDsgZXhpc3RlbmNlIG9mIGFuIGVtcHR5IGNvbnRhaW5lciBtdXN0IGhhdmUgZXhhY3Rs
eSB0aGUgc2FtZSBzaWduaWZpY2FuY2U8YnI+DQomZ3Q7Jmd0OyBhcyB0aGUgbm9uLWV4dGVuY2Ug
b2YgdGhlIGNvbnRhaW5lci48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEdpdmVuIHRoYXQs
IHdlIGhhdmUgdG8gbWFrZSBzdXJlIHRoZSBwcm90b2NvbCBpcyBjb25zaXN0ZW50IHdpdGggdGhh
dDxicj4NCiZndDsmZ3Q7IHByaW5jaXBsZS4mbmJzcDsgRS5nLiwgaWYgeW91IGFzayB0byBjcmVh
dGUgYW4gZWxlbWVudCBvZiBhIG5vbi1leGlzdGluZyBOUDxicj4NCiZndDsmZ3Q7IGNvbnRhaW5l
ciwgaXQgbXVzdCBzdWNjZWVkLCBiZWNhdXNlIGFza2luZyB0byBjcmVhdGUgYW4gZWxlbWVudCBv
ZiBhbjxicj4NCiZndDsmZ3Q7IGV4aXN0aW5nIGJ1dCBlbXB0eSBOUCBjb250YWluZXIgc3VjY2Vl
ZHMuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJIGRvbid0IHNlZSB3aGF0IGFsbCB0aGUg
Y29uc2VxdWVuY2VzIG9mIHRoaXMgcHJpbmNpcGxlIGFyZSwgYnV0IGlmIHdlPGJyPg0KJmd0OyZn
dDsgY2FuJ3QgbWFrZSB0aGUgcHJvdG9jb2wgY29uc2lzdGVudCB3aXRoIGl0LCB0aGVuIHdlIGNh
bid0IHByb3Blcmx5PGJyPg0KJmd0OyZndDsgaW1wbGVtZW50IHRoZSBjb25jZXB0IG9mIE5QIGNv
bnRhaW5lcnMuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBEYWxlPGJyPg0KJmd0OyZndDs8
YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
PGJyPg0KJmd0OyBOZXRjb25mIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRv
Ok5ldGNvbmZAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5OZXRjb25mQGlldGYub3JnPC9hPjxi
cj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy
bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19uZXRjb25mJmFtcDtk
PUN3TUZhUSZhbXA7Yz1JTF9YcVFXT2p1YmdmcUlOaTJqVHpnJmFtcDtyPUdCeUxlZzlqWnZPdl9B
bGdCbzl1dmREcnhpemxPUjdsX1NuVFhvd3lKVTgmYW1wO209NUR4R2MxOGlnTExhem93RUpScWZs
TDJWemtDLUhWY1B4WHV6N2x0Z0dUZyZhbXA7cz1sS1FNN0s2WWFOVC1reXVYc1BScWx1WjdsUFdr
ODRabGFzTm1IMjg4SXowJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mPC9hPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4
ODg4Ij48YnI+DQo8YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj4tLTwvc3Bhbj48YnI+DQo8c3Bh
biBjbGFzcz0iaG9lbnpiIj5MYWRpc2xhdiBMaG90a2EsIENaLk5JQyBMYWJzPC9zcGFuPjxicj4N
CjxzcGFuIGNsYXNzPSJob2VuemIiPlBHUCBLZXkgSUQ6IEU3NEU4QzBDPC9zcGFuPjwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_78c52bbab4d44b938e1dcf191d95b42aEMEAWPEXMB11corpbrocade_--


From nobody Mon Aug  1 08:14:16 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0F212DC22 for ; Mon,  1 Aug 2016 08:14:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.611
X-Spam-Level: 
X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qrkk6LgfmrxE for ; Mon,  1 Aug 2016 08:14:10 -0700 (PDT)
Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c: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 CB0A912DC08 for ; Mon,  1 Aug 2016 08:14:09 -0700 (PDT)
Received: by mail-vk0-x233.google.com with SMTP id n129so101036403vke.3 for ; Mon, 01 Aug 2016 08:14:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=isYrROOqB0r0WmbRMbkR5eAY1u1MEORbIrXSrH7vAv4=; b=cv8v59x7Eo4Xe3TEcc9JKxgIywn+JKWOfp9SnVLnRU9P3G25KMuXsYFgdFsyJiY4O2 z35eGpiSrVYqpLLHqqWyBcVhC/KhRRipB0okdCgl7mxR1Fdwf3y7C/WInXvST1wwVX/m EP59qVw0aNdvcqawrAlonJNZXvRake5urNQN86ZSoiHiDTGhjr/dNTskJHluq4Y8TFuh otvLx0ZcsxHzY9sacaiQxuQ2au5kYWgMUg9Zr7LTqy5sUnUrz9wPlK1GDIVMFvPo5S9e bAMPqaly96WIW1UIRi/1t09FdRkgkISrQmudUW3wkJQAeujhcFKF+vcZiG/6tblKEQlX Qffg==
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:from:date :message-id:subject:to:cc; bh=isYrROOqB0r0WmbRMbkR5eAY1u1MEORbIrXSrH7vAv4=; b=ZIsfkM4LxGo54BrRGBxMzbQfjVFq6OeRL0VtBTCKjMw5ESYaAHRZ5863bJffpYXTyF +o09MH7rab4DXkFhZrP83I2gvLebpYggGPaPe2WupiKqhvA+P4kdc1P0p9C3sKYZ6waU c1K/yXjk7Qr1vmaUTI8dc+AwHlz+cTeNJ5j5o6HyY9aQ2O8Znmye1lxzb5hchHjedaMp yH3xrCLMnNzXMiuv+VWzyj+jFkPGXKXkyxoCujSBKR0VfGycrrQTcbgF4IxkXyPE3Ei1 z/I5j0KAXQn4qTe4STIS3eZyJ2Tt2+UNPvNGrULkLyd9neWxp8VObdKYkA2YM8nKem8Q uECw==
X-Gm-Message-State: AEkoouv8VGkpTWzYm5nXcMgHOUfnFTX0ZkAGkrV6RiXZPfVQaLgPdxFEzKYCWoClSUM8ouRUvk6rjPqC1bs0Yg==
X-Received: by 10.31.252.203 with SMTP id a194mr22878932vki.44.1470064447644;  Mon, 01 Aug 2016 08:14:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Mon, 1 Aug 2016 08:14:06 -0700 (PDT)
In-Reply-To: <78c52bbab4d44b938e1dcf191d95b42a@EMEAWP-EXMB11.corp.brocade.com>
References:  <87vazljnps.fsf@hobgoblin.ariadne.com>    <13a7626442c34f499392b67bcf29ea53@EMEAWP-EXMB11.corp.brocade.com>  <78c52bbab4d44b938e1dcf191d95b42a@EMEAWP-EXMB11.corp.brocade.com>
From: Andy Bierman 
Date: Mon, 1 Aug 2016 08:14:06 -0700
Message-ID: 
To: William Ivory 
Content-Type: multipart/alternative; boundary=94eb2c149bd43306350539040d04
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 Aug 2016 15:14:13 -0000

--94eb2c149bd43306350539040d04
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 1, 2016 at 8:10 AM, William Ivory  wrote:

> Hi Andy,
>
>
>
> Thanks =E2=80=93 in isolation that is clear, but I would be interested in=
 Jan=E2=80=99s
> thoughts given that the given ownership-voucher example would appear to b=
e
> YANG 1.0 **and** assume must statements are evaluated on non-presence
> containers if the parent node exists.
>
>
>

In YANG 1.0, must statements are clearly NOT evaluated for NP containers
just because
their parent exists.  That was the part that was added in YANG 1.1.


> Regards,
>
>
>
> William
>


Andy


>
>
> *From:* Andy Bierman [mailto:andy@yumaworks.com]
> *Sent:* 01 August 2016 16:03
> *To:* William Ivory 
> *Cc:* Ladislav Lhotka ; janl@tail-f.com; Netconf <
> netconf@ietf.org>
> *Subject:* Re: [Netconf] What should a server response be? - depending on
> NP-containers
>
>
>
> Hi,
>
>
>
> I think I made that comment.
>
> In YANG 1.0, only default leafs were considered always present.
>
> In YANG 1.1 NP containers were added to the set of accessible nodes
>
>
>
> In YANG 1.0, sec. 7.5.3
>
>
>
>    o  The accessible tree is made up of all nodes in the data tree, and
>
>       all leafs with default values in use (see Section 7.6.1).
>
>
>
> This was changed in YANG 1.1
>
>
>
> sec 7.5.3:
>
>    When a datastore is validated, all "must" constraints are
>
>    conceptually evaluated once for each node in the accessible tree (see
>
>    Section 6.4.1).
>
> Sec. 6.4.1
>
>
>
>       If a node that exists in the accessible tree has a non-presence
>
>       container as a child, then the non-presence container also exists i=
n
>
>       the tree.
>
>
>
>
>
> Andy
>
>
>
>
>
>
>
>
>
> On Mon, Aug 1, 2016 at 7:51 AM, William Ivory  wrote:
>
> Hi,
>
>
>
> Could someone confirm then that must statements on a non-presence
> container in YANG 1.0 are only to be evaluated if the non-presence
> container has configured children =E2=80=A6 or is it also if (reading Lad=
a=E2=80=99s mail)
> the implementation chooses to implement them when there are no children
> present?
>
>
>
> I had assumed that the text in YANG 1.1 was clarifying YANG 1.0 rather
> than new functionality here but I=E2=80=99m a little confused now, especi=
ally given
> the comment by Jan Lindblad regarding this YANG snippet as the file does
> not contain =E2=80=98yang-version 1.1=E2=80=99 and would surely therefore=
 be version 1.0?
>
>
>
>       container ownership-voucher {
>         description
>           "This container contains the Ownership Voucher that the
>            device uses to ascertain the identity of its rightful
>            owner, as certified by its Vendor.";
>
>         when "../redirect-information/signature or
> ../bootstrap-information/*/signature";
>         must "../owner-certificate";
>
>         uses ownership-voucher-grouping;
>
>       }
>
>
>
>
>
>
> https://github.com/YangModels/yang/blob/master/standard/ietf/DRAFT/ietf-z=
erotouch-bootstrap-server.yang
> 
>
>
>
> Jan=E2=80=99s comment on this YANG (assuming it=E2=80=99s 1.0) and Lada=
=E2=80=99s assertion
> (pasted below) appear contradictory to me.
>
>
>
> =E2=80=98NP containers were not always present in YANG 1.0.
>
> The must-stmt only applied if they actually are present,
>
> which is an implementation choice.
>
> =E2=80=98
>
>
>
> I=E2=80=99m also thinking that any must statement on a non-presence conta=
iner in
> YANG 1.0 models might sensibly be (re)written as =E2=80=98not(current() o=
r
> =E2=80=99 to make it future-proof if these nod=
es do not
> exist in 1.0 w/o children but do in YANG 1.1.  That would allow for easie=
r
> model migration.
>
>
>
> Regards,
>
>
>
> William
>
>
>
> *From:* Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Andy
> Bierman
> *Sent:* 01 August 2016 15:23
> *To:* Ladislav Lhotka 
> *Cc:* Netconf 
> *Subject:* Re: [Netconf] What should a server response be? - depending on
> NP-containers
>
>
>
>
>
>
>
> On Mon, Aug 1, 2016 at 7:13 AM, Ladislav Lhotka  wrote:
>
> Andy Bierman  writes:
>
> > Hi,
> >
> > YANG 1.1 has been changed so the XPath is not really backward-compatibl=
e
> > with YANG 1.0.  In YANG 1.1 NP-containers always exist if the non-NP
> parent
> > is
> > instantiated.
>
> My mental model regarding NP-containers is that they are part of
> the default contents of a datastore. If an NP-container is "in use"
> (according to the same rules as specified in sec. 7.6.1 of 6020bis for
> default leaves), then
>
> - creating a child of this container succeeds,
>
> - "must" expressions defined on this container apply.
>
>
>
>
>
> NP containers were not always present in YANG 1.0.
>
> The must-stmt only applied if they actually are present,
>
> which is an implementation choice.
>
>
>
> I don't understand all this special wording about "do not error if..."
>
>
>
> NETCONF has explicit support for this exact use-case, called "merge".
>
> This was done precisely to support these "don't error if..." cases.
>
> So use "merge" if you want this functionality.
>
>
>
>
>
> Lada
>
>
>
> Andy
>
>
>
>
> >
> > NETCONF and RESTCONF do not say anything about the server ignoring
> > the rules for operation=3D"create", operation=3D"delete" and
> > default-operation=3D"none".
> > IMO itr would be a really bad idea to continue spreading little protoco=
l
> > details
> > in the YANG RFC.  People might read the protocol spec and (correctly)
> assume
> > that the protocol does not trat NP containers special at all.
> >
> > If anything, the sentence about MAY delete needs to be removed because
> > it is inconsistent with the XPath (always exists).
> >
> >
> > Andy
> >
> >
> > On Sun, Jul 31, 2016 at 6:13 PM, Dale R. Worley 
> wrote:
> >
> >> Mahesh Jethanandani  writes:
> >> > I think this argument of whether server should or should not
> >> > create/delete NP containers is distracting from the main point of wh=
en
> >> > NP containers should exist. In my mind, the NP container existence
> >> > depends on whether child nodes exist or not. In the end, if child
> >> > nodes exist, NP containers should exist (created), if they do not
> >> > exist, the NP container should be removed.
> >> >
> >> > Can we agree on that?
> >>
> >> If the concept of a "non-presence container" makes any sense, then the
> >> existence of an empty container must have exactly the same significanc=
e
> >> as the non-extence of the container.
> >>
> >> Given that, we have to make sure the protocol is consistent with that
> >> principle.  E.g., if you ask to create an element of a non-existing NP
> >> container, it must succeed, because asking to create an element of an
> >> existing but empty NP container succeeds.
> >>
> >> I don't see what all the consequences of this principle are, but if we
> >> can't make the protocol consistent with it, then we can't properly
> >> implement the concept of NP containers.
> >>
> >> Dale
> >>
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> 
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

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




On Mon, Aug 1, 2016 at 8:10 AM, William Ivory <wivory@brocade.com=
> wrote:











Hi Andy,


=C2=A0


Thanks =E2=80=93 in isolation that is=
 clear, but I would be interested in Jan=E2=80=99s thoughts given that the =
given ownership-voucher example would
 appear to be YANG 1.0 *and* assume must statements are evaluated on=
 non-presence containers if the parent node exists.

=C2=A0
<=
/blockquote>

In YANG 1.0, must statements are clearly NO=
T evaluated for NP containers just because
their parent exists.=
=C2=A0 That was the part that was added in YANG 1.1.
=C2=A0
=



Regards,


=C2=A0


William


Andy
=C2=A0
=



=C2=A0


From: =
Andy Bierman [mailto:andy@yumaworks.com]


Sent: 01 August 2016 16:03

To: William Ivory <wivory@Brocade.com>

Cc: Ladislav Lhotka <lhotka@nic.cz>; janl@tail-f.com; Netconf <netconf@ietf.org>

Subject: Re: [Netconf] What should a server response be? - depending=
 on NP-containers


=C2=A0




Hi,




=C2=A0






I think I made that comment.






In YANG 1.0, only default leafs were considered alwa=
ys present.






In YANG 1.1 NP containers were added to the set of a=
ccessible nodes






=C2=A0






In YANG 1.0, sec. 7.5.3






=C2=A0






=C2=A0=C2=
=A0 o=C2=A0 The accessible tree is made up of all nodes in the data tree, a=
nd


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 all leafs w=
ith default values in use (see Section 7.6.1).


=C2=A0


This was changed in YANG 1.1






=C2=A0






sec 7.5.3:






=C2=A0=C2=A0 When a datastore is validated=
, all "must" constraints are


=C2=A0=C2=A0 conceptually evaluated once f=
or each node in the accessible tree (see


=C2=A0=C2=A0 Section 6.4.1).=







Sec. 6.4.1






=C2=A0








=C2=A0 =C2=A0 =C2=A0 If a node that exists in the ac=
cessible tree has a non-presence






=C2=A0 =C2=A0 =C2=A0 container as a child, then the =
non-presence container also exists in






=C2=A0 =C2=A0 =C2=A0 the tree.






=C2=A0








=C2=A0






Andy






=C2=A0






=C2=A0






=C2=A0








=C2=A0




On Mon, Aug 1, 2016 at 7:51 AM, William Ivory <wivory@brocade.com> wrote:








Hi,


=C2=A0


Could someone confirm then that must =
statements on a non-presence container in YANG 1.0 are only to
 be evaluated if the non-presence container has configured children =E2=80=
=A6 or is it also if (reading Lada=E2=80=99s mail) the implementation choos=
es to implement them when there are no children present?


=C2=A0


I had assumed that the text in YANG 1=
.1 was clarifying YANG 1.0 rather than new functionality here
 but I=E2=80=99m a little confused now, especially given the comment by Jan=
 Lindblad regarding this YANG snippet as the file does not contain =E2=80=
=98yang-version 1.1=E2=80=99 and would surely therefore be version 1.0?


=C2=A0


=C2=A0 =C2=A0 =C2=A0=C2=A0container ownership-vouche=
r {

=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0description

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0"This container contains the O=
wnership Voucher that the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0device uses to ascertain the ident=
ity of its rightful

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0owner, as certified by its Vendor.=
";



=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0when "../redirect-information/signatu=
re or ../bootstrap-information/*/signature";

=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0must "../owner-certificate";



=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0uses ownership-voucher-grouping;=



=C2=A0 =C2=A0 =C2=A0 }


=C2=A0


=C2=A0


https://github=
.com/YangModels/yang/blob/master/standard/ietf/DRAFT/ietf-zerotouch-bootstr=
ap-server.yang


=C2=A0


Jan=E2=80=99s comment on this YANG (a=
ssuming it=E2=80=99s 1.0) and Lada=E2=80=99s assertion (pasted below) appea=
r contradictory
 to me.


=C2=A0


=E2=80=98NP containers were no=
t always present in YANG 1.0.


The must-stmt only applied if they actually are pres=
ent,


which is an implementation choice.


=E2=80=98


=C2=A0


I=E2=80=99m also thinking that any mu=
st statement on a non-presence container in YANG 1.0 models might sensibly
 be (re)written as =E2=80=98not(current() or <required_xpath_expression&=
gt;=E2=80=99 to make it future-proof if these nodes do not exist in 1.0 w/o=
 children but do in YANG 1.1.=C2=A0 That would allow for easier model migra=
tion.


=C2=A0


Regards,


=C2=A0


William


=C2=A0


From: =
Netconf
 [mailto:netc=
onf-bounces@ietf.org]
On Behalf Of Andy Bierman

Sent: 01 August 2016 15:23

To: Ladislav Lhotka <lhotka@nic.cz>

Cc: Netconf <netconf@ietf.org>

Subject: Re: [Netconf] What should a server response be? - depending=
 on NP-containers


=C2=A0




=C2=A0




=C2=A0




On Mon, Aug 1, 2016 at 7:13 AM, Ladislav Lhotka <=
lhotka@nic.cz> wr=
ote:




Andy Bierman <andy@yumaworks.com&=
gt; writes:



> Hi,

>

> YANG 1.1 has been changed so the XPath is not really backward-compatib=
le

> with YANG 1.0.=C2=A0 In YANG 1.1 NP-containers always exist if the non=
-NP parent

> is

> instantiated.



My mental model regarding NP-containers is that they are part of

the default contents of a datastore. If an NP-container is "in use&quo=
t;

(according to the same rules as specified in sec. 7.6.1 of 6020bis for

default leaves), then



- creating a child of this container succeeds,



- "must" expressions defined on this container apply.






=C2=A0






=C2=A0






NP containers were not always present in YANG 1.0.






The must-stmt only applied if they actually are pres=
ent,






which is an implementation choice.






=C2=A0






I don't understand all this special wording abou=
t "do not error if..."






=C2=A0






NETCONF has explicit support for this exact use-case=
, called "merge".






This was done precisely to support these "don&#=
39;t error if..." cases.






So use "merge" if you want this functional=
ity.=C2=A0






=C2=A0






=C2=A0






Lada






=C2=A0






Andy






=C2=A0








>

> NETCONF and RESTCONF do not say anything about the server ignoring

> the rules for operation=3D"create", operation=3D"delete=
" and

> default-operation=3D"none".

> IMO itr would be a really bad idea to continue spreading little protoc=
ol

> details

> in the YANG RFC.=C2=A0 People might read the protocol spec and (correc=
tly) assume

> that the protocol does not trat NP containers special at all.

>

> If anything, the sentence about MAY delete needs to be removed because=


> it is inconsistent with the XPath (always exists).

>

>

> Andy

>

>

> On Sun, Jul 31, 2016 at 6:13 PM, Dale R. Worley <worley@ariadne.com> wrote:

>

>> Mahesh Jethanandani <mjethanandani@gmail.com> writes:

>> > I think this argument of whether server should or should not<=
br>
>> > create/delete NP containers is distracting from the main poin=
t of when

>> > NP containers should exist. In my mind, the NP container exis=
tence

>> > depends on whether child nodes exist or not. In the end, if c=
hild

>> > nodes exist, NP containers should exist (created), if they do=
 not

>> > exist, the NP container should be removed.

>> >

>> > Can we agree on that?

>>

>> If the concept of a "non-presence container" makes any s=
ense, then the

>> existence of an empty container must have exactly the same signifi=
cance

>> as the non-extence of the container.

>>

>> Given that, we have to make sure the protocol is consistent with t=
hat

>> principle.=C2=A0 E.g., if you ask to create an element of a non-ex=
isting NP

>> container, it must succeed, because asking to create an element of=
 an

>> existing but empty NP container succeeds.

>>

>> I don't see what all the consequences of this principle are, b=
ut if we

>> can't make the protocol consistent with it, then we can't =
properly

>> implement the concept of NP containers.

>>

>> Dale

>>

> _______________________________________________

> Netconf mailing list

> Netconf@ietf.org=


> 
https://www.ietf.org/mailman/listinfo/netconf



--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C






=C2=A0














=C2=A0












--94eb2c149bd43306350539040d04--


From nobody Mon Aug  1 08:24:06 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F0212DC62 for ; Mon,  1 Aug 2016 08:23:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.287
X-Spam-Level: 
X-Spam-Status: No, score=-8.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSycO7-gBDLS for ; Mon,  1 Aug 2016 08:23:57 -0700 (PDT)
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 4390012DC53 for ; Mon,  1 Aug 2016 08:23:57 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:79c5:7fa1:2e8:dedb] (unknown [IPv6:2001:718:1a02:1:79c5:7fa1:2e8:dedb]) by mail.nic.cz (Postfix) with ESMTPSA id C19EC600B4; Mon,  1 Aug 2016 17:23:55 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1470065035; bh=08bFKDRVSHoyw54dbPKCF0F0GuTjGsHMBAQDstuBl4k=; h=From:Date:To; b=r5sso85LBnKkt1FDeHbFmUkXvY6XOl5j/26GyLZvt4uCHnAR9jKC051sTgon/FTM6 ctYJlzVtOlhsYtRLcbJ4rI4x0KyCL35rzejP4lIn6F0k94d5QoQaIbKtS7Lb7AB0Us dzr3PYTbR3gXMC9vD/ziz/JlCkYSNcrMmCVTC39o=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Mon, 1 Aug 2016 17:24:02 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <046F200B-9D4F-45DF-815F-2782F027C987@nic.cz>
References:  <87vazljnps.fsf@hobgoblin.ariadne.com>   
To: Andy Bierman 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 Aug 2016 15:23:59 -0000

> On 01 Aug 2016, at 16:23, Andy Bierman  wrote:
>=20
>=20
>=20
> On Mon, Aug 1, 2016 at 7:13 AM, Ladislav Lhotka  wrote:
> Andy Bierman  writes:
>=20
> > Hi,
> >
> > YANG 1.1 has been changed so the XPath is not really =
backward-compatible
> > with YANG 1.0.  In YANG 1.1 NP-containers always exist if the non-NP =
parent
> > is
> > instantiated.
>=20
> My mental model regarding NP-containers is that they are part of
> the default contents of a datastore. If an NP-container is "in use"
> (according to the same rules as specified in sec. 7.6.1 of 6020bis for
> default leaves), then
>=20
> - creating a child of this container succeeds,
>=20
> - "must" expressions defined on this container apply.
>=20
>=20
>=20
> NP containers were not always present in YANG 1.0.
> The must-stmt only applied if they actually are present,
> which is an implementation choice.

Hence ambiguous. I think that validity of a datastore must not depend on =
implementation choices.
This has been clarified in YANG 1.1, which is IMO good.=20

>=20
> I don't understand all this special wording about "do not error if..."
>=20
> NETCONF has explicit support for this exact use-case, called "merge".
> This was done precisely to support these "don't error if..." cases.
> So use "merge" if you want this functionality.

What about RESTCONF? I don't see any reason why a PUT on a NP-container =
"in use" should fail.

Lada

> =20
>=20
> =20
> Lada
>=20
> Andy
> =20
>=20
> >
> > NETCONF and RESTCONF do not say anything about the server ignoring
> > the rules for operation=3D"create", operation=3D"delete" and
> > default-operation=3D"none".
> > IMO itr would be a really bad idea to continue spreading little =
protocol
> > details
> > in the YANG RFC.  People might read the protocol spec and =
(correctly) assume
> > that the protocol does not trat NP containers special at all.
> >
> > If anything, the sentence about MAY delete needs to be removed =
because
> > it is inconsistent with the XPath (always exists).
> >
> >
> > Andy
> >
> >
> > On Sun, Jul 31, 2016 at 6:13 PM, Dale R. Worley  =
wrote:
> >
> >> Mahesh Jethanandani  writes:
> >> > I think this argument of whether server should or should not
> >> > create/delete NP containers is distracting from the main point of =
when
> >> > NP containers should exist. In my mind, the NP container =
existence
> >> > depends on whether child nodes exist or not. In the end, if child
> >> > nodes exist, NP containers should exist (created), if they do not
> >> > exist, the NP container should be removed.
> >> >
> >> > Can we agree on that?
> >>
> >> If the concept of a "non-presence container" makes any sense, then =
the
> >> existence of an empty container must have exactly the same =
significance
> >> as the non-extence of the container.
> >>
> >> Given that, we have to make sure the protocol is consistent with =
that
> >> principle.  E.g., if you ask to create an element of a non-existing =
NP
> >> container, it must succeed, because asking to create an element of =
an
> >> existing but empty NP container succeeds.
> >>
> >> I don't see what all the consequences of this principle are, but if =
we
> >> can't make the protocol consistent with it, then we can't properly
> >> implement the concept of NP containers.
> >>
> >> Dale
> >>
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

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





From nobody Mon Aug  1 10:57:11 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102F912D755; Mon,  1 Aug 2016 10:57:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Level: 
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMNf0-tj0-PW; Mon,  1 Aug 2016 10:57:07 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 65E3312B018; Mon,  1 Aug 2016 10:57:06 -0700 (PDT)
Received: from unnumerable.local ([173.57.161.14]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u71Hv0AL049518 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Mon, 1 Aug 2016 12:57:00 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [173.57.161.14] claimed to be unnumerable.local
To: "t.petch" , Andy Bierman 
References: <5c5a0c28-7cb3-da17-53dc-ec6401be9d1c@nostrum.com>   <00bc01d1ea57$e7889f80$4001a8c0@gateway.2wire.net>
From: Robert Sparks 
Message-ID: 
Date: Mon, 1 Aug 2016 12:57:00 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <00bc01d1ea57$e7889f80$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: General Area Review Team , draft-ietf-netconf-restconf.all@ietf.org, ietf@ietf.org, Netconf 
Subject: Re: [Netconf] Gen-art LC review: draft-ietf-netconf-restconf-15
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 Aug 2016 17:57:10 -0000

On 7/30/16 6:45 AM, t.petch wrote:
> Robert
>
> Picking up on the point about terminating the connection when a
> certificate validation fails,  this is a straight lift from 'Netconf
> over TLS', RFC7589, where the reference is also in Section 4 which makes
> it clear (to me:-) that the reference is to how the connection is
> terminated, as per RFC5246 s.7.2.1, and nothing to do with the
> certificate validation, which is as per RFC5280.
Perhaps having the s.7.2.1 reference in the text in this document (that 
part wasn't
included in the lift from 7589)  would have let me to interpret the 
sentence that way,
after following the reference. I suggest a light touch to the sentence 
to make it clear
that you are talking about "how to terminate the connection" 
not"terminating the
connection because the cert check failed" with the reference.

(And this should be moved to a nit since it's an editorial clarification).

>
> Tom Petch
>
> ----- Original Message -----
> From: "Robert Sparks" 
> To: "Andy Bierman" 
> Cc: "General Area Review Team" ;
> ; ; "Netconf"
> 
> Sent: Friday, July 29, 2016 9:47 PM
> Subject: Re: [Netconf] Gen-art LC review: draft-ietf-netconf-restconf-15
>
>
>>
>> On 7/29/16 3:36 PM, Andy Bierman wrote:
>>> Hi,
>>>
>>> I will add this review to the list.
>>> A new version in in progress.
>>> Some comments inline
>>>
>>>
>>> On Fri, Jul 29, 2016 at 1:11 PM, Robert Sparks >> > wrote:
>>>
>>>      I am the assigned Gen-ART reviewer for this draft. The General
> Area
>>>      Review Team (Gen-ART) reviews all IETF documents being processed
>>>      by the IESG for the IETF Chair.  Please treat these comments
> just
>>>      like any other last call comments.
>>>
>>>      For more information, please see the FAQ at
>>>
>>>      .
>>>
>>>      Document: draft-ietf-netconf-restconf-15
>>>      Reviewer: Robert Sparks
>>>      Review Date: 28Jul2016
>>>      IETF LC End Date: 3Aug2016
>>>      IESG Telechat date: not yet scheduled
>>>
>>>      Summary:
>>>
>>>      Major issues:
>>>
>>>      * I am not finding any discussion in the Security Considerations
>>>      or in the text around what a server's options are if a client is
>>>      asking it to keep more state than it is willing or capable of
>>>      holding. The possible values of the "depth" query parameter
>>>      (particularly "unbounded") points out that a misconfigured or
>>>      compromised client might start creating arbitrarily deep trees.
>>>      Should a server have the ability to say no?
>>>
>>>
>>>
>>> I guess we need more text somewhere explaining the "depth" parameter
> is
>>> a retrieval filter.
>> I got that. It's existence, however, caused me to think about the fact
>> that what is stored at the server can be arbitrarily deep. Clients
> using
>> POST can build trees that are arbitrarily deep, with bits at the node
>> that are arbitrarily large (subject to the constraints the YANG models
>> put on the node). There should be some discussion acknowledging that
>> this can happen, and discussion of what the server can do if some
> client
>> starts asking it to store more than it is willing to store.
>>> It is not used to create anything in the server.
>>> The server does not maintain any state except during the processing
> of
>>> the retrieval request
>>>
>>>
>>>      * The third paragraph of 3.7 paraphrases to "SHOULD NOT delete
>>>      more than one instance unless a proprietary query parameter says
>>>      it's ok". This isn't really helpful in a specification.
>>>      Proprietary things are proprietary. The SHOULD NOT already
> allows
>>>      proprietary things to do something different without
> trainwrecking
>>>      the protocol. Please just delete the 2nd and 3rd sentence from
> the
>>>      paragraph.
>>>
>>>
>>> OK
>>>
>>>
>>>      * Section 2.3 says "If X.509 certificate path validation fails
> and
>>>      the presented X.509 certificate does not match a locally
>>>      configured certificate fingerprint, the connection MUST be
>>>      terminated as defined in [RFC5246]." RFC5246 doesn't really talk
>>>      about certificate validation, and it certainly doesn't say "the
>>>      connection MUST be terminated" when certificates fail to
> validate.
>>>      What are you trying to point to in RFC5246 here? Should you be
>>>      pointing somewhere else? (It's perfectly reasonable for the
>>>      document to reference RFC5246, and it does so elsewhere without
>>>      problem).
>>>
>>>
>>>
>>> Please suggest replacement text if we are citing the wrong RFC.
>>> I will ask Kent to look into this issue
>>>
>>>
>>>      Minor issues:
>>>
>>>      * "A server MUST support XML or JSON encoding." is ambiguous.
> (2nd
>>>      paragraph of 5.2). Did you mean the server MUST support at least
>>>      one of XML or JSON but not necessarily both? I think you really
>>>      intended that the server support BOTH types of encoding.
>>>
>>>
>>> No -- it will be clarified that the server must support at least 1
> of
>>> the 2
>>>
>>>
>>>      * I _think_ I can infer that PUT can't be used with datastore
>>>      resources. Section 3.4 only speaks of POST and PATCH. Section
> 4.5
>>>      speaks about "target data resource" and is silent about
> datastore
>>>      resources. If I've understood the intent, please be explicit
> about
>>>      datastore resources in 4.5. If I've misunderstood then more
>>>      clarity is needed in both 3.4 and 4.5.
>>>
>>>
>>> The  next draft will be clarified to allow PUT on a datastore
> resource
>> Hrmm - that makes me less comfortable that you are actually aligned
> with
>> 7231. It may just be that you need to be more precise with your
>> description, but per 7231, PUT never creates resources - it can create
>> or replace the state of a resource.
>>>      * In 3.5.3.1 you restrict identifiers with "MUST NOT start with
>>>      'xml' (or any case variant of that string). Please call out why
>>>      (or point to an existing document that explains why).
>>>
>>>
>>> OK
>>>
>>>
>>>      * The text in 5.3 about access control interacting with caching
>>>      (added based on my early review I think) doesn't mesh well with
>>>      paragraph 3 of section 5.5. There you tell the client to use
> Etag
>>>      and Last-Modified, but in 5.3 you say it won't work reliably
> when
>>>      access permissions change. At the very least 5.5 should point
> back
>>>      into the paragraph in 5.3.
>>>
>>>      Nits/editorial comments:
>>>
>>>      * Introduction, 4th paragraph - please change "MAY provide" to
>>>      "provides". Section 3.6 explains the cases where there is choice
>>>      in what to provide.
>>>
>>>
>>>      * Section 2.3 paragraphs 1 and 2. There is edit-itis here left
> (I
>>>      suspect) from working in matching fingerprints. Consider
> combining
>>>      and simplifying these two paragraphs after improving the
> reference
>>>      issue called out above.
>>>
>>>      * Section 4 says "Access control mechanisms MUST be used to
>>>      limit..." This is not a good use of a 2119 MUST. I suggest
>>>      replacing "MUST be" with "are". The subsequent text already
>>>      captures the actual normative requirements on the server.
>>>
>>>      * Section 12 says "this protocol SHOULD be implemented
> carefully".
>>>      That is not a good use of a 2119 SHOULD. It is not a protocol
>>>      requirement. I suggest reformulating this into something like
>>>      "There are many patterns of attack that have been observed
> through
>>>      operational practice with existing management interfaces. It
> would
>>>      be wise for implementers to research them, and take them into
>>>      account when implementing this protocol." It would be far better
>>>      to provide a pointer to where the implementer should start this
>>>      research.
>>>
>>>      * (micronit) Lots of examples are internally inconsistent wrt
>>>      dates. For instance, look at the 200 OK in section 3.3.3 - it
> says
>>>      that back in 2012, a server returned something talking about a
>>>      library versioned in 2016.
>>>
>>>
>>>
>>> Andy
>>>
>>
>
> ------------------------------------------------------------------------
> --------
>
>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>>


From nobody Mon Aug  1 14:18:12 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F01712D662; Mon,  1 Aug 2016 14:18:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level: 
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B94CHNXm3ue1; Mon,  1 Aug 2016 14:17:59 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0136.outbound.protection.outlook.com [104.47.36.136]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 078DE12D100; Mon,  1 Aug 2016 14:17:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RubuWv+/RVTiraIqRzvWBr1qnGY3+J2V4B3824mbQQE=; b=J7JGa4aFWAY3NFcZoWcxK6U0o3kNm/nE/01UHnfadIBN9S4Ht+4rfno5V8/xczvXKi15caIaaXV7B3279VStJPsYg01t1E1FktgQqqXFRWDltqrtWCyjR6OjMWk3mR5u5B9KiscRBe2ALkdGOa6+ifr7hN0OAx6XRBi1/eRHzHs=
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 (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.8; Mon, 1 Aug 2016 21:17:55 +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.0557.009; Mon, 1 Aug 2016 21:17:56 +0000
From: Kent Watsen 
To: Robert Sparks , t.petch , "Andy Bierman" 
Thread-Topic: [Netconf] Gen-art LC review: draft-ietf-netconf-restconf-15
Thread-Index: AQHR6dVxorbmwyhHuEuzEzm1dmaNxaAv3jcAgAAC9ACAAPu7QoADi6MA///1FIA=
Date: Mon, 1 Aug 2016 21:17:55 +0000
Message-ID: <43B5D3C7-C488-4B64-9DBC-714483717CD6@juniper.net>
References: <5c5a0c28-7cb3-da17-53dc-ec6401be9d1c@nostrum.com>   <00bc01d1ea57$e7889f80$4001a8c0@gateway.2wire.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.18.0.160709
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-ms-office365-filtering-correlation-id: 774488cb-ed9d-4ca1-04c7-08d3ba514e8d
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1451; 6:3H7TM33LdDFW9M2IeNHbbqHyZ/lrjRknRAn/sspHWGIpFAz3VpFM6yunCwaLdknmbbF5NGVT1hPbboN3BQYnoqLVQbzEHTIpiR7gV0fjXy+2/gUhP5AONJsbQnTsrIe4mc3QS0e4/MPpql2SjZ5/GPIGa4zkmEafifzipKUbkXX5rlGh3hIjMe6hkmcWfxuQDDPn3hXF+hYjAsxfXjHP6VwWqIq+3fikdBM7cYfpgJ70mqoQtlhN+Ha26eFZD+iDIsBzKZprEPPF7q7tlEZhS08AenhWK9zD9htSL2D1FhOSI6CLvFDb9Cr99PIq911jYu0HeI4wDXu0xHCqq+NT6Q==; 5:gG9yAZeoIhy5Q738hYBETDnWYz5M62VwBTJ/OFmdXckLUU2VMyIAC21RNwPA5XCtpa3FQWXfAMCbVvW6bw9uS70aprd6Ai37OQQUFoG/4I0uuypFZmG+NpYLANnUpxnfKTw9d7HczeDuKNRpQCtGSw==; 24:LAu3WpUFoheVBrXv2QvvO6m08jQUH/h4p21P0LM9fFWUgaJnpS9Dz64MPERjRY3ECJQmtzOrWHopDObKWoD0md+JPw6FV73fwX/jtxbCTgM=; 7:Lo8NBnVjKwHkUap3i2kHe+dSwS+5z5Jdn6jL6SFZvQFHFH3a7Ui6jILuY05ip+//mhoMYiwdRfLYayXfhULCJ6iwn1oLBtAl1fs+BWeE4UDdR1p83VnKU7YvZfY/kqMziNwG1IhaZUyrTRFm2nyAX9t4b78A8vE5QeJP2FZM5hqGmoUai3rM90cNEM/iX/wN0SDIU4tb8/jXNwal+nev35mlNLRuuL5E6m3+T0jGzr5geEYTlgTr60U5TKvQVpq7
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1451;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(788757137089); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026);  SRVR:CY1PR0501MB1451; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1451; 
x-forefront-prvs: 0021920B5A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(24454002)(377454003)(13464003)(199003)(2906002)(54356999)(101416001)(76176999)(3846002)(102836003)(8666005)(6116002)(83716003)(83506001)(50986999)(86362001)(8936002)(19580405001)(15975445007)(19580395003)(7846002)(2950100001)(3280700002)(33656002)(2900100001)(81166006)(8676002)(66066001)(68736007)(81156014)(3660700001)(82746002)(4326007)(77096005)(7736002)(5002640100001)(5001770100001)(99286002)(97736004)(93886004)(4001350100001)(92566002)(189998001)(87936001)(105586002)(36756003)(586003)(106116001)(305945005)(230783001)(122556002)(106356001)(10400500002)(7059030)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1451; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <47CD3B394334E948AAAE8895D1DBE1ED@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Aug 2016 21:17:55.9891 (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: 
Cc: General Area Review Team , "draft-ietf-netconf-restconf.all@ietf.org" , "ietf@ietf.org" , Netconf 
Subject: Re: [Netconf] Gen-art LC review: draft-ietf-netconf-restconf-15
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 Aug 2016 21:18:02 -0000

DQpUbyBhZGRyZXNzIHRoZSBHZW4tQXJ0IGNvbW1lbnQsIGJlbG93IEkgcmVwbGFjZWQg4oCcYXMg
ZGVmaW5lZCBpbiBbUkZDNTI0Nl3igJ0gd2l0aCDigJwsIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9u
IDcuMi4xIG9mIFtSRkM1MjQ2XeKAnS4gICBHb29kIG5vdz8NCg0KQWRkaXRpb25hbGx5LCB3aGls
ZSBsb29raW5nIGF0IFNlY3Rpb24gMi4zLCBJIHJlYWxpemVkIGFuIG9wcG9ydHVuaXR5IHRvIGZp
eCBhIGNvdXBsZSBtb3JlIHRoaW5ncy4gIEZpcnN0LCB3aGVuIGxvb2tpbmcgYXQgUkZDIDc1ODks
IFNlY3Rpb24gNSwgSSBzZWUgdGhlIGxhbmd1YWdlIOKAnGNlcnRpZmljYXRlIG9idGFpbmVkIGJ5
IGEgdHJ1c3RlZCBtZWNoYW5pc23igJ0sIHdoaWNoIEkgdGhpbmsgaXMgYmV0dGVyIHRoYW4gc2F5
aW5nIGl0IGhhcyB0byBtYXRjaCBhIGxvY2FsbHkgY29uZmlndXJlZCBmaW5nZXJwcmludC4gIFNl
Y29uZCwgSSBmb3VuZCBhIHJlZHVuZGFudCBzZW50ZW5jZSB3aGljaCBzZWVtZWQgbWlzbGVhZGlu
Zy4gIEZpbmFsbHksIEkgY29sbGFwc2VkIHRoZSB0d28gcGFyYWdyYXBocyBpbnRvIG9uZSBzaW5j
ZSB0aGV54oCZcmUgbW9yZSBjb25uZWN0ZWQgdGhhbiBub3QuICBUaGUgbmV0IHJlc3VsdCBmb2xs
b3dzOg0KDQpORVcNCg0KICAgMi4zLiAgQ2VydGlmaWNhdGUgVmFsaWRhdGlvbg0KDQogICBUaGUg
UkVTVENPTkYgY2xpZW50IE1VU1QgZWl0aGVyIHVzZSBYLjUwOSBjZXJ0aWZpY2F0ZSBwYXRoIHZh
bGlkYXRpb24NCiAgIFtSRkM1MjgwXSB0byB2ZXJpZnkgdGhlIGludGVncml0eSBvZiB0aGUgUkVT
VENPTkYgc2VydmVyJ3MgVExTDQogICBjZXJ0aWZpY2F0ZSwgb3IgbWF0Y2ggdGhlIHNlcnZlcuKA
mXMgVExTIGNlcnRpZmljYXRlIHdpdGggYSBjZXJ0aWZpY2F0ZQ0KICAgb2J0YWluZWQgYnkgYSB0
cnVzdGVkIG1lY2hhbmlzbSAoZS5nLiBhIHBpbm5lZCBjZXJ0aWZpY2F0ZSkuICAgSWYgWC41MDkN
CiAgIGNlcnRpZmljYXRlIHBhdGggdmFsaWRhdGlvbiBmYWlscywgYW5kIHRoZSBwcmVzZW50ZWQg
WC41MDkgY2VydGlmaWNhdGUNCiAgIGRvZXMgbm90IG1hdGNoIGEgY2VydGlmaWNhdGUgb2J0YWlu
ZWQgYnkgYSB0cnVzdGVkIG1lY2hhbmlzbSwgdGhlDQogICBjb25uZWN0aW9uIE1VU1QgYmUgdGVy
bWluYXRlZCwgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNy4yLjEgb2YgDQogICBbUkZDNTI0Nl0u
DQoNCg0KT0xEOg0KDQogICAyLjMuICBDZXJ0aWZpY2F0ZSBWYWxpZGF0aW9uDQoNCiAgIFRoZSBS
RVNUQ09ORiBjbGllbnQgTVVTVCBlaXRoZXIgdXNlIFguNTA5IGNlcnRpZmljYXRlIHBhdGggdmFs
aWRhdGlvbg0KICAgW1JGQzUyODBdIHRvIHZlcmlmeSB0aGUgaW50ZWdyaXR5IG9mIHRoZSBSRVNU
Q09ORiBzZXJ2ZXIncyBUTFMNCiAgIGNlcnRpZmljYXRlLCBvciBtYXRjaCB0aGUgcHJlc2VudGVk
IFguNTA5IGNlcnRpZmljYXRlIHdpdGggbG9jYWxseQ0KICAgY29uZmlndXJlZCBjZXJ0aWZpY2F0
ZSBmaW5nZXJwcmludHMuDQoNCiAgIFRoZSBwcmVzZW50ZWQgWC41MDkgY2VydGlmaWNhdGUgTVVT
VCBhbHNvIGJlIGNvbnNpZGVyZWQgdmFsaWQgaWYgaXQNCiAgIG1hdGNoZXMgYSBsb2NhbGx5IGNv
bmZpZ3VyZWQgY2VydGlmaWNhdGUgZmluZ2VycHJpbnQuICBJZiBYLjUwOQ0KICAgY2VydGlmaWNh
dGUgcGF0aCB2YWxpZGF0aW9uIGZhaWxzIGFuZCB0aGUgcHJlc2VudGVkIFguNTA5IGNlcnRpZmlj
YXRlDQogICBkb2VzIG5vdCBtYXRjaCBhIGxvY2FsbHkgY29uZmlndXJlZCBjZXJ0aWZpY2F0ZSBm
aW5nZXJwcmludCwgdGhlDQogICBjb25uZWN0aW9uIE1VU1QgYmUgdGVybWluYXRlZCBhcyBkZWZp
bmVkIGluIFtSRkM1MjQ2XS4NCg0KDQpUaGlzIGNoYW5nZSB3aWxsIGJlIG1hZGUgaW4gYSBmZXcg
ZGF5cyBpZiBubyBvYmplY3Rpb24gaXMgcmFpc2VkIGJ5IHRoZW4uDQoNClRoYW5rcywNCktlbnQN
Cg0KDQpPbiA4LzEvMTYsIDE6NTcgUE0sICJOZXRjb25mIG9uIGJlaGFsZiBvZiBSb2JlcnQgU3Bh
cmtzIiA8bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiByanNwYXJrc0Bub3N0
cnVtLmNvbT4gd3JvdGU6DQoNCiAgICANCiAgICANCiAgICBPbiA3LzMwLzE2IDY6NDUgQU0sIHQu
cGV0Y2ggd3JvdGU6DQogICAgPiBSb2JlcnQNCiAgICA+DQogICAgPiBQaWNraW5nIHVwIG9uIHRo
ZSBwb2ludCBhYm91dCB0ZXJtaW5hdGluZyB0aGUgY29ubmVjdGlvbiB3aGVuIGENCiAgICA+IGNl
cnRpZmljYXRlIHZhbGlkYXRpb24gZmFpbHMsICB0aGlzIGlzIGEgc3RyYWlnaHQgbGlmdCBmcm9t
ICdOZXRjb25mDQogICAgPiBvdmVyIFRMUycsIFJGQzc1ODksIHdoZXJlIHRoZSByZWZlcmVuY2Ug
aXMgYWxzbyBpbiBTZWN0aW9uIDQgd2hpY2ggbWFrZXMNCiAgICA+IGl0IGNsZWFyICh0byBtZTot
KSB0aGF0IHRoZSByZWZlcmVuY2UgaXMgdG8gaG93IHRoZSBjb25uZWN0aW9uIGlzDQogICAgPiB0
ZXJtaW5hdGVkLCBhcyBwZXIgUkZDNTI0NiBzLjcuMi4xLCBhbmQgbm90aGluZyB0byBkbyB3aXRo
IHRoZQ0KICAgID4gY2VydGlmaWNhdGUgdmFsaWRhdGlvbiwgd2hpY2ggaXMgYXMgcGVyIFJGQzUy
ODAuDQogICAgUGVyaGFwcyBoYXZpbmcgdGhlIHMuNy4yLjEgcmVmZXJlbmNlIGluIHRoZSB0ZXh0
IGluIHRoaXMgZG9jdW1lbnQgKHRoYXQgDQogICAgcGFydCB3YXNuJ3QNCiAgICBpbmNsdWRlZCBp
biB0aGUgbGlmdCBmcm9tIDc1ODkpICB3b3VsZCBoYXZlIGxldCBtZSB0byBpbnRlcnByZXQgdGhl
IA0KICAgIHNlbnRlbmNlIHRoYXQgd2F5LA0KICAgIGFmdGVyIGZvbGxvd2luZyB0aGUgcmVmZXJl
bmNlLiBJIHN1Z2dlc3QgYSBsaWdodCB0b3VjaCB0byB0aGUgc2VudGVuY2UgDQogICAgdG8gbWFr
ZSBpdCBjbGVhcg0KICAgIHRoYXQgeW91IGFyZSB0YWxraW5nIGFib3V0ICJob3cgdG8gdGVybWlu
YXRlIHRoZSBjb25uZWN0aW9uIiANCiAgICBub3QidGVybWluYXRpbmcgdGhlDQogICAgY29ubmVj
dGlvbiBiZWNhdXNlIHRoZSBjZXJ0IGNoZWNrIGZhaWxlZCIgd2l0aCB0aGUgcmVmZXJlbmNlLg0K
ICAgIA0KICAgIChBbmQgdGhpcyBzaG91bGQgYmUgbW92ZWQgdG8gYSBuaXQgc2luY2UgaXQncyBh
biBlZGl0b3JpYWwgY2xhcmlmaWNhdGlvbikuDQogICAgDQogICAgPg0KICAgID4gVG9tIFBldGNo
DQogICAgPg0KICAgID4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KICAgID4gRnJvbTog
IlJvYmVydCBTcGFya3MiIDxyanNwYXJrc0Bub3N0cnVtLmNvbT4NCiAgICA+IFRvOiAiQW5keSBC
aWVybWFuIiA8YW5keUB5dW1hd29ya3MuY29tPg0KICAgID4gQ2M6ICJHZW5lcmFsIEFyZWEgUmV2
aWV3IFRlYW0iIDxnZW4tYXJ0QGlldGYub3JnPjsNCiAgICA+IDxkcmFmdC1pZXRmLW5ldGNvbmYt
cmVzdGNvbmYuYWxsQGlldGYub3JnPjsgPGlldGZAaWV0Zi5vcmc+OyAiTmV0Y29uZiINCiAgICA+
IDxuZXRjb25mQGlldGYub3JnPg0KICAgID4gU2VudDogRnJpZGF5LCBKdWx5IDI5LCAyMDE2IDk6
NDcgUE0NCiAgICA+IFN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gR2VuLWFydCBMQyByZXZpZXc6IGRy
YWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi0xNQ0KICAgID4NCiAgICA+DQogICAgPj4NCiAgICA+
PiBPbiA3LzI5LzE2IDM6MzYgUE0sIEFuZHkgQmllcm1hbiB3cm90ZToNCiAgICA+Pj4gSGksDQog
ICAgPj4+DQogICAgPj4+IEkgd2lsbCBhZGQgdGhpcyByZXZpZXcgdG8gdGhlIGxpc3QuDQogICAg
Pj4+IEEgbmV3IHZlcnNpb24gaW4gaW4gcHJvZ3Jlc3MuDQogICAgPj4+IFNvbWUgY29tbWVudHMg
aW5saW5lDQogICAgPj4+DQogICAgPj4+DQogICAgPj4+IE9uIEZyaSwgSnVsIDI5LCAyMDE2IGF0
IDE6MTEgUE0sIFJvYmVydCBTcGFya3MgPHJqc3BhcmtzQG5vc3RydW0uY29tDQogICAgPj4+IDxt
YWlsdG86cmpzcGFya3NAbm9zdHJ1bS5jb20+PiB3cm90ZToNCiAgICA+Pj4NCiAgICA+Pj4gICAg
ICBJIGFtIHRoZSBhc3NpZ25lZCBHZW4tQVJUIHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUg
R2VuZXJhbA0KICAgID4gQXJlYQ0KICAgID4+PiAgICAgIFJldmlldyBUZWFtIChHZW4tQVJUKSBy
ZXZpZXdzIGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQNCiAgICA+Pj4gICAgICBi
eSB0aGUgSUVTRyBmb3IgdGhlIElFVEYgQ2hhaXIuICBQbGVhc2UgdHJlYXQgdGhlc2UgY29tbWVu
dHMNCiAgICA+IGp1c3QNCiAgICA+Pj4gICAgICBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29t
bWVudHMuDQogICAgPj4+DQogICAgPj4+ICAgICAgRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFz
ZSBzZWUgdGhlIEZBUSBhdA0KICAgID4+Pg0KICAgID4+PiAgICAgIDxodHRwOi8vd2lraS50b29s
cy5pZXRmLm9yZy9hcmVhL2dlbi90cmFjL3dpa2kvR2VuQXJ0ZmFxPi4NCiAgICA+Pj4NCiAgICA+
Pj4gICAgICBEb2N1bWVudDogZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25mLTE1DQogICAgPj4+
ICAgICAgUmV2aWV3ZXI6IFJvYmVydCBTcGFya3MNCiAgICA+Pj4gICAgICBSZXZpZXcgRGF0ZTog
MjhKdWwyMDE2DQogICAgPj4+ICAgICAgSUVURiBMQyBFbmQgRGF0ZTogM0F1ZzIwMTYNCiAgICA+
Pj4gICAgICBJRVNHIFRlbGVjaGF0IGRhdGU6IG5vdCB5ZXQgc2NoZWR1bGVkDQogICAgPj4+DQog
ICAgPj4+ICAgICAgU3VtbWFyeToNCiAgICA+Pj4NCiAgICA+Pj4gICAgICBNYWpvciBpc3N1ZXM6
DQogICAgPj4+DQogICAgPj4+ICAgICAgKiBJIGFtIG5vdCBmaW5kaW5nIGFueSBkaXNjdXNzaW9u
IGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KICAgID4+PiAgICAgIG9yIGluIHRoZSB0
ZXh0IGFyb3VuZCB3aGF0IGEgc2VydmVyJ3Mgb3B0aW9ucyBhcmUgaWYgYSBjbGllbnQgaXMNCiAg
ICA+Pj4gICAgICBhc2tpbmcgaXQgdG8ga2VlcCBtb3JlIHN0YXRlIHRoYW4gaXQgaXMgd2lsbGlu
ZyBvciBjYXBhYmxlIG9mDQogICAgPj4+ICAgICAgaG9sZGluZy4gVGhlIHBvc3NpYmxlIHZhbHVl
cyBvZiB0aGUgImRlcHRoIiBxdWVyeSBwYXJhbWV0ZXINCiAgICA+Pj4gICAgICAocGFydGljdWxh
cmx5ICJ1bmJvdW5kZWQiKSBwb2ludHMgb3V0IHRoYXQgYSBtaXNjb25maWd1cmVkIG9yDQogICAg
Pj4+ICAgICAgY29tcHJvbWlzZWQgY2xpZW50IG1pZ2h0IHN0YXJ0IGNyZWF0aW5nIGFyYml0cmFy
aWx5IGRlZXAgdHJlZXMuDQogICAgPj4+ICAgICAgU2hvdWxkIGEgc2VydmVyIGhhdmUgdGhlIGFi
aWxpdHkgdG8gc2F5IG5vPw0KICAgID4+Pg0KICAgID4+Pg0KICAgID4+Pg0KICAgID4+PiBJIGd1
ZXNzIHdlIG5lZWQgbW9yZSB0ZXh0IHNvbWV3aGVyZSBleHBsYWluaW5nIHRoZSAiZGVwdGgiIHBh
cmFtZXRlcg0KICAgID4gaXMNCiAgICA+Pj4gYSByZXRyaWV2YWwgZmlsdGVyLg0KICAgID4+IEkg
Z290IHRoYXQuIEl0J3MgZXhpc3RlbmNlLCBob3dldmVyLCBjYXVzZWQgbWUgdG8gdGhpbmsgYWJv
dXQgdGhlIGZhY3QNCiAgICA+PiB0aGF0IHdoYXQgaXMgc3RvcmVkIGF0IHRoZSBzZXJ2ZXIgY2Fu
IGJlIGFyYml0cmFyaWx5IGRlZXAuIENsaWVudHMNCiAgICA+IHVzaW5nDQogICAgPj4gUE9TVCBj
YW4gYnVpbGQgdHJlZXMgdGhhdCBhcmUgYXJiaXRyYXJpbHkgZGVlcCwgd2l0aCBiaXRzIGF0IHRo
ZSBub2RlDQogICAgPj4gdGhhdCBhcmUgYXJiaXRyYXJpbHkgbGFyZ2UgKHN1YmplY3QgdG8gdGhl
IGNvbnN0cmFpbnRzIHRoZSBZQU5HIG1vZGVscw0KICAgID4+IHB1dCBvbiB0aGUgbm9kZSkuIFRo
ZXJlIHNob3VsZCBiZSBzb21lIGRpc2N1c3Npb24gYWNrbm93bGVkZ2luZyB0aGF0DQogICAgPj4g
dGhpcyBjYW4gaGFwcGVuLCBhbmQgZGlzY3Vzc2lvbiBvZiB3aGF0IHRoZSBzZXJ2ZXIgY2FuIGRv
IGlmIHNvbWUNCiAgICA+IGNsaWVudA0KICAgID4+IHN0YXJ0cyBhc2tpbmcgaXQgdG8gc3RvcmUg
bW9yZSB0aGFuIGl0IGlzIHdpbGxpbmcgdG8gc3RvcmUuDQogICAgPj4+IEl0IGlzIG5vdCB1c2Vk
IHRvIGNyZWF0ZSBhbnl0aGluZyBpbiB0aGUgc2VydmVyLg0KICAgID4+PiBUaGUgc2VydmVyIGRv
ZXMgbm90IG1haW50YWluIGFueSBzdGF0ZSBleGNlcHQgZHVyaW5nIHRoZSBwcm9jZXNzaW5nDQog
ICAgPiBvZg0KICAgID4+PiB0aGUgcmV0cmlldmFsIHJlcXVlc3QNCiAgICA+Pj4NCiAgICA+Pj4N
CiAgICA+Pj4gICAgICAqIFRoZSB0aGlyZCBwYXJhZ3JhcGggb2YgMy43IHBhcmFwaHJhc2VzIHRv
ICJTSE9VTEQgTk9UIGRlbGV0ZQ0KICAgID4+PiAgICAgIG1vcmUgdGhhbiBvbmUgaW5zdGFuY2Ug
dW5sZXNzIGEgcHJvcHJpZXRhcnkgcXVlcnkgcGFyYW1ldGVyIHNheXMNCiAgICA+Pj4gICAgICBp
dCdzIG9rIi4gVGhpcyBpc24ndCByZWFsbHkgaGVscGZ1bCBpbiBhIHNwZWNpZmljYXRpb24uDQog
ICAgPj4+ICAgICAgUHJvcHJpZXRhcnkgdGhpbmdzIGFyZSBwcm9wcmlldGFyeS4gVGhlIFNIT1VM
RCBOT1QgYWxyZWFkeQ0KICAgID4gYWxsb3dzDQogICAgPj4+ICAgICAgcHJvcHJpZXRhcnkgdGhp
bmdzIHRvIGRvIHNvbWV0aGluZyBkaWZmZXJlbnQgd2l0aG91dA0KICAgID4gdHJhaW53cmVja2lu
Zw0KICAgID4+PiAgICAgIHRoZSBwcm90b2NvbC4gUGxlYXNlIGp1c3QgZGVsZXRlIHRoZSAybmQg
YW5kIDNyZCBzZW50ZW5jZSBmcm9tDQogICAgPiB0aGUNCiAgICA+Pj4gICAgICBwYXJhZ3JhcGgu
DQogICAgPj4+DQogICAgPj4+DQogICAgPj4+IE9LDQogICAgPj4+DQogICAgPj4+DQogICAgPj4+
ICAgICAgKiBTZWN0aW9uIDIuMyBzYXlzICJJZiBYLjUwOSBjZXJ0aWZpY2F0ZSBwYXRoIHZhbGlk
YXRpb24gZmFpbHMNCiAgICA+IGFuZA0KICAgID4+PiAgICAgIHRoZSBwcmVzZW50ZWQgWC41MDkg
Y2VydGlmaWNhdGUgZG9lcyBub3QgbWF0Y2ggYSBsb2NhbGx5DQogICAgPj4+ICAgICAgY29uZmln
dXJlZCBjZXJ0aWZpY2F0ZSBmaW5nZXJwcmludCwgdGhlIGNvbm5lY3Rpb24gTVVTVCBiZQ0KICAg
ID4+PiAgICAgIHRlcm1pbmF0ZWQgYXMgZGVmaW5lZCBpbiBbUkZDNTI0Nl0uIiBSRkM1MjQ2IGRv
ZXNuJ3QgcmVhbGx5IHRhbGsNCiAgICA+Pj4gICAgICBhYm91dCBjZXJ0aWZpY2F0ZSB2YWxpZGF0
aW9uLCBhbmQgaXQgY2VydGFpbmx5IGRvZXNuJ3Qgc2F5ICJ0aGUNCiAgICA+Pj4gICAgICBjb25u
ZWN0aW9uIE1VU1QgYmUgdGVybWluYXRlZCIgd2hlbiBjZXJ0aWZpY2F0ZXMgZmFpbCB0bw0KICAg
ID4gdmFsaWRhdGUuDQogICAgPj4+ICAgICAgV2hhdCBhcmUgeW91IHRyeWluZyB0byBwb2ludCB0
byBpbiBSRkM1MjQ2IGhlcmU/IFNob3VsZCB5b3UgYmUNCiAgICA+Pj4gICAgICBwb2ludGluZyBz
b21ld2hlcmUgZWxzZT8gKEl0J3MgcGVyZmVjdGx5IHJlYXNvbmFibGUgZm9yIHRoZQ0KICAgID4+
PiAgICAgIGRvY3VtZW50IHRvIHJlZmVyZW5jZSBSRkM1MjQ2LCBhbmQgaXQgZG9lcyBzbyBlbHNl
d2hlcmUgd2l0aG91dA0KICAgID4+PiAgICAgIHByb2JsZW0pLg0KICAgID4+Pg0KICAgID4+Pg0K
ICAgID4+Pg0KICAgID4+PiBQbGVhc2Ugc3VnZ2VzdCByZXBsYWNlbWVudCB0ZXh0IGlmIHdlIGFy
ZSBjaXRpbmcgdGhlIHdyb25nIFJGQy4NCiAgICA+Pj4gSSB3aWxsIGFzayBLZW50IHRvIGxvb2sg
aW50byB0aGlzIGlzc3VlDQogICAgPj4+DQogICAgPj4+DQogICAgPj4+ICAgICAgTWlub3IgaXNz
dWVzOg0KICAgID4+Pg0KICAgID4+PiAgICAgICogIkEgc2VydmVyIE1VU1Qgc3VwcG9ydCBYTUwg
b3IgSlNPTiBlbmNvZGluZy4iIGlzIGFtYmlndW91cy4NCiAgICA+ICgybmQNCiAgICA+Pj4gICAg
ICBwYXJhZ3JhcGggb2YgNS4yKS4gRGlkIHlvdSBtZWFuIHRoZSBzZXJ2ZXIgTVVTVCBzdXBwb3J0
IGF0IGxlYXN0DQogICAgPj4+ICAgICAgb25lIG9mIFhNTCBvciBKU09OIGJ1dCBub3QgbmVjZXNz
YXJpbHkgYm90aD8gSSB0aGluayB5b3UgcmVhbGx5DQogICAgPj4+ICAgICAgaW50ZW5kZWQgdGhh
dCB0aGUgc2VydmVyIHN1cHBvcnQgQk9USCB0eXBlcyBvZiBlbmNvZGluZy4NCiAgICA+Pj4NCiAg
ICA+Pj4NCiAgICA+Pj4gTm8gLS0gaXQgd2lsbCBiZSBjbGFyaWZpZWQgdGhhdCB0aGUgc2VydmVy
IG11c3Qgc3VwcG9ydCBhdCBsZWFzdCAxDQogICAgPiBvZg0KICAgID4+PiB0aGUgMg0KICAgID4+
Pg0KICAgID4+Pg0KICAgID4+PiAgICAgICogSSBfdGhpbmtfIEkgY2FuIGluZmVyIHRoYXQgUFVU
IGNhbid0IGJlIHVzZWQgd2l0aCBkYXRhc3RvcmUNCiAgICA+Pj4gICAgICByZXNvdXJjZXMuIFNl
Y3Rpb24gMy40IG9ubHkgc3BlYWtzIG9mIFBPU1QgYW5kIFBBVENILiBTZWN0aW9uDQogICAgPiA0
LjUNCiAgICA+Pj4gICAgICBzcGVha3MgYWJvdXQgInRhcmdldCBkYXRhIHJlc291cmNlIiBhbmQg
aXMgc2lsZW50IGFib3V0DQogICAgPiBkYXRhc3RvcmUNCiAgICA+Pj4gICAgICByZXNvdXJjZXMu
IElmIEkndmUgdW5kZXJzdG9vZCB0aGUgaW50ZW50LCBwbGVhc2UgYmUgZXhwbGljaXQNCiAgICA+
IGFib3V0DQogICAgPj4+ICAgICAgZGF0YXN0b3JlIHJlc291cmNlcyBpbiA0LjUuIElmIEkndmUg
bWlzdW5kZXJzdG9vZCB0aGVuIG1vcmUNCiAgICA+Pj4gICAgICBjbGFyaXR5IGlzIG5lZWRlZCBp
biBib3RoIDMuNCBhbmQgNC41Lg0KICAgID4+Pg0KICAgID4+Pg0KICAgID4+PiBUaGUgIG5leHQg
ZHJhZnQgd2lsbCBiZSBjbGFyaWZpZWQgdG8gYWxsb3cgUFVUIG9uIGEgZGF0YXN0b3JlDQogICAg
PiByZXNvdXJjZQ0KICAgID4+IEhybW0gLSB0aGF0IG1ha2VzIG1lIGxlc3MgY29tZm9ydGFibGUg
dGhhdCB5b3UgYXJlIGFjdHVhbGx5IGFsaWduZWQNCiAgICA+IHdpdGgNCiAgICA+PiA3MjMxLiBJ
dCBtYXkganVzdCBiZSB0aGF0IHlvdSBuZWVkIHRvIGJlIG1vcmUgcHJlY2lzZSB3aXRoIHlvdXIN
CiAgICA+PiBkZXNjcmlwdGlvbiwgYnV0IHBlciA3MjMxLCBQVVQgbmV2ZXIgY3JlYXRlcyByZXNv
dXJjZXMgLSBpdCBjYW4gY3JlYXRlDQogICAgPj4gb3IgcmVwbGFjZSB0aGUgc3RhdGUgb2YgYSBy
ZXNvdXJjZS4NCiAgICA+Pj4gICAgICAqIEluIDMuNS4zLjEgeW91IHJlc3RyaWN0IGlkZW50aWZp
ZXJzIHdpdGggIk1VU1QgTk9UIHN0YXJ0IHdpdGgNCiAgICA+Pj4gICAgICAneG1sJyAob3IgYW55
IGNhc2UgdmFyaWFudCBvZiB0aGF0IHN0cmluZykuIFBsZWFzZSBjYWxsIG91dCB3aHkNCiAgICA+
Pj4gICAgICAob3IgcG9pbnQgdG8gYW4gZXhpc3RpbmcgZG9jdW1lbnQgdGhhdCBleHBsYWlucyB3
aHkpLg0KICAgID4+Pg0KICAgID4+Pg0KICAgID4+PiBPSw0KICAgID4+Pg0KICAgID4+Pg0KICAg
ID4+PiAgICAgICogVGhlIHRleHQgaW4gNS4zIGFib3V0IGFjY2VzcyBjb250cm9sIGludGVyYWN0
aW5nIHdpdGggY2FjaGluZw0KICAgID4+PiAgICAgIChhZGRlZCBiYXNlZCBvbiBteSBlYXJseSBy
ZXZpZXcgSSB0aGluaykgZG9lc24ndCBtZXNoIHdlbGwgd2l0aA0KICAgID4+PiAgICAgIHBhcmFn
cmFwaCAzIG9mIHNlY3Rpb24gNS41LiBUaGVyZSB5b3UgdGVsbCB0aGUgY2xpZW50IHRvIHVzZQ0K
ICAgID4gRXRhZw0KICAgID4+PiAgICAgIGFuZCBMYXN0LU1vZGlmaWVkLCBidXQgaW4gNS4zIHlv
dSBzYXkgaXQgd29uJ3Qgd29yayByZWxpYWJseQ0KICAgID4gd2hlbg0KICAgID4+PiAgICAgIGFj
Y2VzcyBwZXJtaXNzaW9ucyBjaGFuZ2UuIEF0IHRoZSB2ZXJ5IGxlYXN0IDUuNSBzaG91bGQgcG9p
bnQNCiAgICA+IGJhY2sNCiAgICA+Pj4gICAgICBpbnRvIHRoZSBwYXJhZ3JhcGggaW4gNS4zLg0K
ICAgID4+Pg0KICAgID4+PiAgICAgIE5pdHMvZWRpdG9yaWFsIGNvbW1lbnRzOg0KICAgID4+Pg0K
ICAgID4+PiAgICAgICogSW50cm9kdWN0aW9uLCA0dGggcGFyYWdyYXBoIC0gcGxlYXNlIGNoYW5n
ZSAiTUFZIHByb3ZpZGUiIHRvDQogICAgPj4+ICAgICAgInByb3ZpZGVzIi4gU2VjdGlvbiAzLjYg
ZXhwbGFpbnMgdGhlIGNhc2VzIHdoZXJlIHRoZXJlIGlzIGNob2ljZQ0KICAgID4+PiAgICAgIGlu
IHdoYXQgdG8gcHJvdmlkZS4NCiAgICA+Pj4NCiAgICA+Pj4NCiAgICA+Pj4gICAgICAqIFNlY3Rp
b24gMi4zIHBhcmFncmFwaHMgMSBhbmQgMi4gVGhlcmUgaXMgZWRpdC1pdGlzIGhlcmUgbGVmdA0K
ICAgID4gKEkNCiAgICA+Pj4gICAgICBzdXNwZWN0KSBmcm9tIHdvcmtpbmcgaW4gbWF0Y2hpbmcg
ZmluZ2VycHJpbnRzLiBDb25zaWRlcg0KICAgID4gY29tYmluaW5nDQogICAgPj4+ICAgICAgYW5k
IHNpbXBsaWZ5aW5nIHRoZXNlIHR3byBwYXJhZ3JhcGhzIGFmdGVyIGltcHJvdmluZyB0aGUNCiAg
ICA+IHJlZmVyZW5jZQ0KICAgID4+PiAgICAgIGlzc3VlIGNhbGxlZCBvdXQgYWJvdmUuDQogICAg
Pj4+DQogICAgPj4+ICAgICAgKiBTZWN0aW9uIDQgc2F5cyAiQWNjZXNzIGNvbnRyb2wgbWVjaGFu
aXNtcyBNVVNUIGJlIHVzZWQgdG8NCiAgICA+Pj4gICAgICBsaW1pdC4uLiIgVGhpcyBpcyBub3Qg
YSBnb29kIHVzZSBvZiBhIDIxMTkgTVVTVC4gSSBzdWdnZXN0DQogICAgPj4+ICAgICAgcmVwbGFj
aW5nICJNVVNUIGJlIiB3aXRoICJhcmUiLiBUaGUgc3Vic2VxdWVudCB0ZXh0IGFscmVhZHkNCiAg
ICA+Pj4gICAgICBjYXB0dXJlcyB0aGUgYWN0dWFsIG5vcm1hdGl2ZSByZXF1aXJlbWVudHMgb24g
dGhlIHNlcnZlci4NCiAgICA+Pj4NCiAgICA+Pj4gICAgICAqIFNlY3Rpb24gMTIgc2F5cyAidGhp
cyBwcm90b2NvbCBTSE9VTEQgYmUgaW1wbGVtZW50ZWQNCiAgICA+IGNhcmVmdWxseSIuDQogICAg
Pj4+ICAgICAgVGhhdCBpcyBub3QgYSBnb29kIHVzZSBvZiBhIDIxMTkgU0hPVUxELiBJdCBpcyBu
b3QgYSBwcm90b2NvbA0KICAgID4+PiAgICAgIHJlcXVpcmVtZW50LiBJIHN1Z2dlc3QgcmVmb3Jt
dWxhdGluZyB0aGlzIGludG8gc29tZXRoaW5nIGxpa2UNCiAgICA+Pj4gICAgICAiVGhlcmUgYXJl
IG1hbnkgcGF0dGVybnMgb2YgYXR0YWNrIHRoYXQgaGF2ZSBiZWVuIG9ic2VydmVkDQogICAgPiB0
aHJvdWdoDQogICAgPj4+ICAgICAgb3BlcmF0aW9uYWwgcHJhY3RpY2Ugd2l0aCBleGlzdGluZyBt
YW5hZ2VtZW50IGludGVyZmFjZXMuIEl0DQogICAgPiB3b3VsZA0KICAgID4+PiAgICAgIGJlIHdp
c2UgZm9yIGltcGxlbWVudGVycyB0byByZXNlYXJjaCB0aGVtLCBhbmQgdGFrZSB0aGVtIGludG8N
CiAgICA+Pj4gICAgICBhY2NvdW50IHdoZW4gaW1wbGVtZW50aW5nIHRoaXMgcHJvdG9jb2wuIiBJ
dCB3b3VsZCBiZSBmYXIgYmV0dGVyDQogICAgPj4+ICAgICAgdG8gcHJvdmlkZSBhIHBvaW50ZXIg
dG8gd2hlcmUgdGhlIGltcGxlbWVudGVyIHNob3VsZCBzdGFydCB0aGlzDQogICAgPj4+ICAgICAg
cmVzZWFyY2guDQogICAgPj4+DQogICAgPj4+ICAgICAgKiAobWljcm9uaXQpIExvdHMgb2YgZXhh
bXBsZXMgYXJlIGludGVybmFsbHkgaW5jb25zaXN0ZW50IHdydA0KICAgID4+PiAgICAgIGRhdGVz
LiBGb3IgaW5zdGFuY2UsIGxvb2sgYXQgdGhlIDIwMCBPSyBpbiBzZWN0aW9uIDMuMy4zIC0gaXQN
CiAgICA+IHNheXMNCiAgICA+Pj4gICAgICB0aGF0IGJhY2sgaW4gMjAxMiwgYSBzZXJ2ZXIgcmV0
dXJuZWQgc29tZXRoaW5nIHRhbGtpbmcgYWJvdXQgYQ0KICAgID4+PiAgICAgIGxpYnJhcnkgdmVy
c2lvbmVkIGluIDIwMTYuDQogICAgPj4+DQogICAgPj4+DQogICAgPj4+DQogICAgPj4+IEFuZHkN
CiAgICA+Pj4NCiAgICA+Pg0KICAgID4NCiAgICA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgID4gLS0t
LS0tLS0NCiAgICA+DQogICAgPg0KICAgID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQogICAgPj4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCiAgICA+PiBO
ZXRjb25mQGlldGYub3JnDQogICAgPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9uZXRjb25mDQogICAgPj4NCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KICAgIE5ldGNvbmYgbWFpbGluZyBsaXN0DQogICAgTmV0
Y29uZkBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
bmV0Y29uZg0KICAgIA0KDQo=


From nobody Tue Aug  2 02:00:06 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE4E112D106; Tue,  2 Aug 2016 02:00:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wICjQphEKx7k; Tue,  2 Aug 2016 01:59:58 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0091.outbound.protection.outlook.com [104.47.0.91]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C55B5128E19; Tue,  2 Aug 2016 01:59:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TDNoQzFmr0USwJ5o9kS4XKCHfHQDbNe+tQbJcBUk+VM=; b=On6j4j03nm5Kms99YgDJBavyf4ZTgBAqbR+R5EpVTtsXsBlAaFD67hQE5ERCS0pkiVXpBDrZkojArodPZ6s5Sgo/lxXbVx1LNj/CI6uNNSNmtFdPriBOtN1Cb7YIis3yb0FeBK+UTGXEZSmniqA+EDzVxIipC92db7awleBwils=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (31.50.86.164) by DB5PR07MB1622.eurprd07.prod.outlook.com (10.166.12.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Tue, 2 Aug 2016 08:59:53 +0000
Message-ID: <007e01d1ec9b$dea81b20$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Kent Watsen , Robert Sparks , Andy Bierman 
References: <5c5a0c28-7cb3-da17-53dc-ec6401be9d1c@nostrum.com>   <00bc01d1ea57$e7889f80$4001a8c0@gateway.2wire.net>  <43B5D3C7-C488-4B64-9DBC-714483717CD6@juniper.net>
Date: Tue, 2 Aug 2016 09:49:49 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
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: [31.50.86.164]
X-ClientProxiedBy: DB4PR05CA0010.eurprd05.prod.outlook.com (10.160.40.20) To DB5PR07MB1622.eurprd07.prod.outlook.com (10.166.12.149)
X-MS-Office365-Filtering-Correlation-Id: caaddcc7-b4d8-4e9c-0b35-08d3bab35e7b
X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 2:T5xwz4+2Ijt+fHfRAW0QQSxNVieGoVecuL3ToyFqaPQmOaD8V11kWDaDua5tqYnhNH8+vNoowXjzjqx176rwmpRKjpfl2rDWzTZLenxagBvJceTgvynHgfeAYcxXnb8HNBQYt+eGr1zq84mD6PuGeffg8EDnTDacLO7XXcexBhCvOEc0y+Rtf1epXQpzcBGD; 3:RSine+zeUgtsWjlBD2Zw2YrtZUyS3qWiHFeKAaFSWgrR1Iyef3dYepq2k8nSw+rmrGYQ88gPo9eiOQIF97vXSPg/BSPyVgv/qMqujBafTDxfQFqs6scGdjI2PqHoyVT1; 25:ejEFUMuJWFqZIgbCgnczRYHJWwVVH4eXJ8F7Ho3QEkBgS4UuCZVNbdmhQKLOda7r4E3mVi3UV/tafGgOYTECp/n7EQD5KT39SKqUx/HvcM6I8tIQXl6px7MziA/yzaD1Xfpe9v8FjIY0RHt8qRGnwco0kDUoBmYLSB7VDQV/5vmJPggOWE/VsMlvzJIv46Ii9/CfRr4y7wris+lksvY1ND5BkTj3ZOul91d3TzNVlhDJgeALy/i/JDSDW5d8hA++Aq2r8rgRc0Oe4D0IaJeR5I1Sn8DY54GF1+0tG+/apaHK2Xcsu5yolzJodr360Qa/r8YyX75vmaZhbVEoGVTdeULDi4FBFdliuE3UoFD4lHtKllBdseRphZfSB8vrEjah1as62d4dztthemlaW6fVp7PgDlRj6+Hj9kNBVLLn4sA=
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR07MB1622;
X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 31:ugxMPlIUvzrQpyqLthf4uT2kgtPMMNjKJOOXVFx+tA2TSm2O1CD78ecqRh8RwezIJgYSZDOwQU8zUQqI8bfw49IJkxx4LdO8Kotsw5b+QWJz2mioc/rrm3lTE7WEcPNEU8yG5LAvTGZGvAOYVvYDyTSpFoaw5C7TytmWV3em2w1Hgvar4NoNvySfebqKDad0eTvDZah4ws6wSzHUpS3WElHr71ATH3FnqHHO00gOlUU=; 4:CD/1ReCak2m7HkNmhgmUg3CgMS8MLxDcwN8WZ4/qTBDRyeW2A3OP15vhDaijvEMq9TJp3wbVUhPswtakahTdosCLC0jVzr0gNnAtYI7PQHZJMCd5vufjBZaRhgrY+p1dsY0uhUZtHuMqgr84IDKL4Aq1015WM1jT5gfF9c2Lkx6Y90nqSs6O1Z0pBxXfKWJccBsvpwRgAlNui1A8PawxU9dUZdNNskaCrdEloJR5j5Le3k/VISRhv5B5ibWIHO+/0I7EPuFZYxIpVBBhef5acbY0i45bc7Zw9+hPv2xhICSeMUnJcZwPD2moBbDGndljQLAMTWl5/SpL6rG5ZPThOpQQBTISUbCbJzFwoBYPGV+tPVPwGocsbnFkebrURF4IrVbcBbqNM6VSw7eTYwBuK0WIH/OmJ/PobNpzG76Q9GICDhwWNoMefsFe6nQRVJOmpE6mYjJfAvp/9kQ7hKpft78mBq13B02Ii5w6tlKdyN55Fl03s/qd6UehlaO2JjBrlpQdd0b+duowDMAOSlpmXQ==
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(192374486261705)(138986009662008)(788757137089); 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:DB5PR07MB1622; BCL:0; PCL:0; RULEID:; SRVR:DB5PR07MB1622; 
X-Forefront-PRVS: 0022134A87
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(13464003)(24454002)(199003)(377454003)(189002)(97736004)(81686999)(47776003)(23676002)(8676002)(101416001)(42186005)(92566002)(81156014)(76176999)(189998001)(230783001)(3846002)(6116002)(4326007)(81166006)(81816999)(2870700001)(50466002)(305945005)(5001770100001)(84392002)(62236002)(44736004)(44716002)(93886004)(586003)(1556002)(14496001)(116806002)(2906002)(7736002)(68736007)(86362001)(33646002)(9686002)(15975445007)(1456003)(50226002)(77096005)(106356001)(8666005)(1941001)(50986999)(19580405001)(19580395003)(61296003)(7846002)(105586002)(66066001)(7059030)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1622; 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: =?utf-8?B?MTtEQjVQUjA3TUIxNjIyOzIzOm9VYnZibXlRSjYzRFpYa1Buc2xFczZtZldh?= =?utf-8?B?TUo0bWZNajRaRlNMVFhsUWdhWHFyUjZZTWxhT29nYVJRS1lhcjdObEZEb2tj?= =?utf-8?B?eXVKVDNVMHdDRnE4UjE0dlY4ME9TOE1ZWXFlOURMcVhQMHdwR2VDRWhheFhH?= =?utf-8?B?K2kxeXFyS0E2SHVyR3lucDlRclhUMWVYRzdTWEpHbG9PZ2w1TFlpNHdLWVZB?= =?utf-8?B?SUZSSFNZT1R5eGwrY0JQanVhRHA3VUJVWWYvSURhTHlYN2ZEUTZaUzFoVTJX?= =?utf-8?B?N3c3cHpRSUdlR2lzYzR1NDVRN3V2UitJckg0RWZ3b2lkaHkzOFprQ3NEZFVZ?= =?utf-8?B?ZlVISldYNGxPdUQrL1BRVklEMzdXSWxTUmRJdmhQczkyRk9hdmQ4dDVQMDhV?= =?utf-8?B?ZUF5SHdlcHhjTzZOR05yNS9TZFZDT2Z6NVljZ2orL3BzY1lMU0l0VVJhVk9Q?= =?utf-8?B?RExZNEJRamw4U002UmRjNHhoYjB2YjJiU3lpRDVyWUszbnhwSjBCazNad1pZ?= =?utf-8?B?dkRnbGhkWmFiMnJUSjkrc0VWajl6T2xXdVFRUkhyZzhYZlkxaldIRTQvTTNw?= =?utf-8?B?ZWlSSUFBY0Y0WkVUVlZhYU93WnA5MHpENmt3WVg1T3RRcG9HbDdEck1KNXBH?= =?utf-8?B?MzVhVERxR3JKeTdiNFFObmNQYWt4VGg5cXFQVnRpVWp2M1VyR3BFQ2RQbDBG?= =?utf-8?B?UG5CbGcyRWtIOVh0V0QzOXlQbVYwaGZOU2lGOGUweStzV2lyNzFBYjI3NFNI?= =?utf-8?B?TEFleXdLWEpKcE1QdGhTYngwOEo2TXNEdFNqMld2NlBmRk16ZUQ5Z2N4VHVT?= =?utf-8?B?UDdwcUwveHk4OXJOR29FeXRtTUZ2VEFyT25IUnJNTEc5NEhodGN4VHhubG4r?= =?utf-8?B?S1AxaGxGTzVkTmxNVWNpM1JENnQzT2pYZ2FQVUdFNlV2WXhJa1dyUW5pT3dV?= =?utf-8?B?djUxaDFmenNFNTQyeU1GWjRzZS9pSEFVdkZTWUg4bGdGSEpZUmx6WDhGNS9p?= =?utf-8?B?VnY5MEh2bTgzOWpSczg2aXVxUDNBenE3OTlnVGkzaHVKQ21oWHhjcWNXbENV?= =?utf-8?B?QnRya3RYc1o1Y0FiMlpobVQ0ZmhkZmltWDhqSjJabjZOc0h1YnVqa1JtbGl5?= =?utf-8?B?SzZNcGoxaEZkYXh6SjRjRWdNWHVJMm9BQ1NEVE15UFlqeEw5c0xQSGVtenov?= =?utf-8?B?cjA4MTRDTk1Ud1BIUUJqWlJFa2lEbm9RaHhOVGEzcVN3Um1nSGY4Y2RPL1RG?= =?utf-8?B?dnNIUFRrS1ZiMzNRM29DZ1hvQTJtMzB0b3FuMlB5V0ZDVERTa2R1U3BrUk53?= =?utf-8?B?RWJqZmU3Mi9mTWkzY1NTR2hwUHEwcWNjYzhtM3BSM1dNMVNyQUU1NlZ0TUgw?= =?utf-8?B?Rjd0cG5yYVVRVzYza0xYV0xkaVZxNEt1ampXdDYzam5sbjZQbXZyZkd1dUZ2?= =?utf-8?B?aUNGa3Vwa1RXZTZhVHVNcHVXVjMrNzNhK0F0WDhyaVBocDE5SC9MNXAxVFFR?= =?utf-8?B?ZWhTVGFaV0VtNHo1dWlVVklXZ1JiRkV5U1I0WG5oZGt5dzlDK1IxQ05MZ1BO?= =?utf-8?B?MUNPRkZpUnQwYTNjWmJrTnorQkk2aUsvMG5KTmRIRW8wdTlTb0ZaSGlHUStX?= =?utf-8?B?SVM5QzRIZGd3V0NYYUxFSmdxOENYY1U3RVdLY0hOdi9oVUhLWTAyZWRoRFQ1?= =?utf-8?B?bjNHMllNUnhSTlNSa0NMSkdCd3FDVzlzT2txOGQvK2RCQnNId2p4YjBxRFlj?= =?utf-8?B?TnQyRkwxUlcrL1FJZzNtYjFvVzNuMTB0VHI5WS8vSi9OcWJ1Vkc0eE91eVNS?= =?utf-8?B?VFU3N2VzMGlwUVFmL3VSV25NeDYzaUd1R3JkMU1EYmc4OWdXc2ZkaEFIYUc0?= =?utf-8?B?c3dRR0VFcjAwdjBPTjhXUVZKZnYrWDUvOU9oZ05uQXNHanBwU1hkbCtlRGFs?= =?utf-8?B?VytaVnpENmpRMGRHUTRPZ2FITjRUQkUvYk1Wdk9rWnZkUWczSWVTclFNVmhr?= =?utf-8?B?WWFkOUl5NWVsWmx2cW53MzRiczBPbmlEdEwyQT09?=
X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 6:uknAITccpuNW5bOgo9Zl4tTkPacMVzfm6TxGbJZSl9eAjnd/swWL29Qaa32W+TYDVe/nNnCEWfe02NmvI0XiNmZRAtaIbHbgVK8SeEYe4+ENpeFzkxFmh0ag5PjeEENuYXZcs1T0xW6Q3PB6NuDceHCvQy8YkDfv9mjI+QCEhWP5OU9lVy566a5CnTfFry9EjY+Q82rGWQCLm33jNz3mOEdqO4Idz1eBq1XL1yyzTiSIZD0By926c7ZzQv0UUKs+Lds/xWY3NuRRGBjpVz06dJeVG2IxEVv9TC1yAPmF0h4=; 5:zGIpydRyb+XwR0mIrCE+qGDOOZnuSRDyEbQLk9JaU/y0kd0543LoOp4I6FMvHAtIm8/oVBcapwEj/h9UcB9fNM52B4m9R/DuzO+OyXT/RfRdnRH6icAf/JorladBaqfi+WJzi6QTwoMyxdaZIBO/lA==; 24:zeahVFLq9FGI8W1ix8R+A1dPUhFFNGrz3My0ZK4Obi8owkbncYPPLJJqyZ5hx/0TN9RewlrSDcX9QZbcBidxwhS7DGrAWtYLBlMWpSZG0wM=; 7:9MZ4fj+eFPzh5uMyCYBvHkde9KRLHfefC7xNt+C8j/qmjCY1HJcM6uWzAK+cRyWIku9nzNYkRhkTmYqL9SeJizgyAl4HPmZgqQLaex8c2MSfEC5TgQPg90EGLeT+Gi1BX/kU2Top3dNSwTGUzlugJekzlddVFeNXhrHcWgTBB4Wb5pPNXuR2FSo2pBifdV0hJoXXNpPXn3PjRoWohSQiAENs3TjxH7i8v3djT8SuaOK9lSC5Jjq2pzdObR2Jnrtk
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Aug 2016 08:59:53.0711 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1622
Archived-At: 
Cc: General Area Review Team , draft-ietf-netconf-restconf.all@ietf.org, Netconf 
Subject: Re: [Netconf] Gen-art LC review: draft-ietf-netconf-restconf-15
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 02 Aug 2016 09:00:02 -0000

Kent

Yes, good now,

Tom Petch

----- Original Message -----
From: "Kent Watsen" 
Sent: Monday, August 01, 2016 10:17 PM


>
> To address the Gen-Art comment, below I replaced “as defined in
[RFC5246]” with “, as described in Section 7.2.1 of [RFC5246]”.   Good
now?
>
> Additionally, while looking at Section 2.3, I realized an opportunity
to fix a couple more things.  First, when looking at RFC 7589, Section
5, I see the language “certificate obtained by a trusted mechanism”,
which I think is better than saying it has to match a locally configured
fingerprint.  Second, I found a redundant sentence which seemed
misleading.  Finally, I collapsed the two paragraphs into one since they
’re more connected than not.  The net result follows:
>
> NEW
>
>    2.3.  Certificate Validation
>
>    The RESTCONF client MUST either use X.509 certificate path
validation
>    [RFC5280] to verify the integrity of the RESTCONF server's TLS
>    certificate, or match the server’s TLS certificate with a
certificate
>    obtained by a trusted mechanism (e.g. a pinned certificate).   If
X.509
>    certificate path validation fails, and the presented X.509
certificate
>    does not match a certificate obtained by a trusted mechanism, the
>    connection MUST be terminated, as described in Section 7.2.1 of
>    [RFC5246].
>
>
> OLD:
>
>    2.3.  Certificate Validation
>
>    The RESTCONF client MUST either use X.509 certificate path
validation
>    [RFC5280] to verify the integrity of the RESTCONF server's TLS
>    certificate, or match the presented X.509 certificate with locally
>    configured certificate fingerprints.
>
>    The presented X.509 certificate MUST also be considered valid if it
>    matches a locally configured certificate fingerprint.  If X.509
>    certificate path validation fails and the presented X.509
certificate
>    does not match a locally configured certificate fingerprint, the
>    connection MUST be terminated as defined in [RFC5246].
>
>
> This change will be made in a few days if no objection is raised by
then.
>
> Thanks,
> Kent
>
>
> On 8/1/16, 1:57 PM, "Netconf on behalf of Robert Sparks"
 wrote:
>
>
>
>     On 7/30/16 6:45 AM, t.petch wrote:
>     > Robert
>     >
>     > Picking up on the point about terminating the connection when a
>     > certificate validation fails,  this is a straight lift from
'Netconf
>     > over TLS', RFC7589, where the reference is also in Section 4
which makes
>     > it clear (to me:-) that the reference is to how the connection
is
>     > terminated, as per RFC5246 s.7.2.1, and nothing to do with the
>     > certificate validation, which is as per RFC5280.
>     Perhaps having the s.7.2.1 reference in the text in this document
(that
>     part wasn't
>     included in the lift from 7589)  would have let me to interpret
the
>     sentence that way,
>     after following the reference. I suggest a light touch to the
sentence
>     to make it clear
>     that you are talking about "how to terminate the connection"
>     not"terminating the
>     connection because the cert check failed" with the reference.
>
>     (And this should be moved to a nit since it's an editorial
clarification).
>
>     >
>     > Tom Petch
>     >
>     > ----- Original Message -----
>     > From: "Robert Sparks" 
>     > To: "Andy Bierman" 
>     > Cc: "General Area Review Team" ;
>     > ; ;
"Netconf"
>     > 
>     > Sent: Friday, July 29, 2016 9:47 PM
>     > Subject: Re: [Netconf] Gen-art LC review:
draft-ietf-netconf-restconf-15
>     >
>     >
>     >>
>     >> On 7/29/16 3:36 PM, Andy Bierman wrote:
>     >>> Hi,
>     >>>
>     >>> I will add this review to the list.
>     >>> A new version in in progress.
>     >>> Some comments inline
>     >>>
>     >>>
>     >>> On Fri, Jul 29, 2016 at 1:11 PM, Robert Sparks
     >>> > wrote:
>     >>>
>     >>>      I am the assigned Gen-ART reviewer for this draft. The
General
>     > Area
>     >>>      Review Team (Gen-ART) reviews all IETF documents being
processed
>     >>>      by the IESG for the IETF Chair.  Please treat these
comments
>     > just
>     >>>      like any other last call comments.
>     >>>
>     >>>      For more information, please see the FAQ at
>     >>>
>     >>>
.
>     >>>
>     >>>      Document: draft-ietf-netconf-restconf-15
>     >>>      Reviewer: Robert Sparks
>     >>>      Review Date: 28Jul2016
>     >>>      IETF LC End Date: 3Aug2016
>     >>>      IESG Telechat date: not yet scheduled
>     >>>
>     >>>      Summary:
>     >>>
>     >>>      Major issues:
>     >>>
>     >>>      * I am not finding any discussion in the Security
Considerations
>     >>>      or in the text around what a server's options are if a
client is
>     >>>      asking it to keep more state than it is willing or
capable of
>     >>>      holding. The possible values of the "depth" query
parameter
>     >>>      (particularly "unbounded") points out that a
misconfigured or
>     >>>      compromised client might start creating arbitrarily deep
trees.
>     >>>      Should a server have the ability to say no?
>     >>>
>     >>>
>     >>>
>     >>> I guess we need more text somewhere explaining the "depth"
parameter
>     > is
>     >>> a retrieval filter.
>     >> I got that. It's existence, however, caused me to think about
the fact
>     >> that what is stored at the server can be arbitrarily deep.
Clients
>     > using
>     >> POST can build trees that are arbitrarily deep, with bits at
the node
>     >> that are arbitrarily large (subject to the constraints the YANG
models
>     >> put on the node). There should be some discussion acknowledging
that
>     >> this can happen, and discussion of what the server can do if
some
>     > client
>     >> starts asking it to store more than it is willing to store.
>     >>> It is not used to create anything in the server.
>     >>> The server does not maintain any state except during the
processing
>     > of
>     >>> the retrieval request
>     >>>
>     >>>
>     >>>      * The third paragraph of 3.7 paraphrases to "SHOULD NOT
delete
>     >>>      more than one instance unless a proprietary query
parameter says
>     >>>      it's ok". This isn't really helpful in a specification.
>     >>>      Proprietary things are proprietary. The SHOULD NOT
already
>     > allows
>     >>>      proprietary things to do something different without
>     > trainwrecking
>     >>>      the protocol. Please just delete the 2nd and 3rd sentence
from
>     > the
>     >>>      paragraph.
>     >>>
>     >>>
>     >>> OK
>     >>>
>     >>>
>     >>>      * Section 2.3 says "If X.509 certificate path validation
fails
>     > and
>     >>>      the presented X.509 certificate does not match a locally
>     >>>      configured certificate fingerprint, the connection MUST
be
>     >>>      terminated as defined in [RFC5246]." RFC5246 doesn't
really talk
>     >>>      about certificate validation, and it certainly doesn't
say "the
>     >>>      connection MUST be terminated" when certificates fail to
>     > validate.
>     >>>      What are you trying to point to in RFC5246 here? Should
you be
>     >>>      pointing somewhere else? (It's perfectly reasonable for
the
>     >>>      document to reference RFC5246, and it does so elsewhere
without
>     >>>      problem).
>     >>>
>     >>>
>     >>>
>     >>> Please suggest replacement text if we are citing the wrong
RFC.
>     >>> I will ask Kent to look into this issue
>     >>>
>     >>>
>     >>>      Minor issues:
>     >>>
>     >>>      * "A server MUST support XML or JSON encoding." is
ambiguous.
>     > (2nd
>     >>>      paragraph of 5.2). Did you mean the server MUST support
at least
>     >>>      one of XML or JSON but not necessarily both? I think you
really
>     >>>      intended that the server support BOTH types of encoding.
>     >>>
>     >>>
>     >>> No -- it will be clarified that the server must support at
least 1
>     > of
>     >>> the 2
>     >>>
>     >>>
>     >>>      * I _think_ I can infer that PUT can't be used with
datastore
>     >>>      resources. Section 3.4 only speaks of POST and PATCH.
Section
>     > 4.5
>     >>>      speaks about "target data resource" and is silent about
>     > datastore
>     >>>      resources. If I've understood the intent, please be
explicit
>     > about
>     >>>      datastore resources in 4.5. If I've misunderstood then
more
>     >>>      clarity is needed in both 3.4 and 4.5.
>     >>>
>     >>>
>     >>> The  next draft will be clarified to allow PUT on a datastore
>     > resource
>     >> Hrmm - that makes me less comfortable that you are actually
aligned
>     > with
>     >> 7231. It may just be that you need to be more precise with your
>     >> description, but per 7231, PUT never creates resources - it can
create
>     >> or replace the state of a resource.
>     >>>      * In 3.5.3.1 you restrict identifiers with "MUST NOT
start with
>     >>>      'xml' (or any case variant of that string). Please call
out why
>     >>>      (or point to an existing document that explains why).
>     >>>
>     >>>
>     >>> OK
>     >>>
>     >>>
>     >>>      * The text in 5.3 about access control interacting with
caching
>     >>>      (added based on my early review I think) doesn't mesh
well with
>     >>>      paragraph 3 of section 5.5. There you tell the client to
use
>     > Etag
>     >>>      and Last-Modified, but in 5.3 you say it won't work
reliably
>     > when
>     >>>      access permissions change. At the very least 5.5 should
point
>     > back
>     >>>      into the paragraph in 5.3.
>     >>>
>     >>>      Nits/editorial comments:
>     >>>
>     >>>      * Introduction, 4th paragraph - please change "MAY
provide" to
>     >>>      "provides". Section 3.6 explains the cases where there is
choice
>     >>>      in what to provide.
>     >>>
>     >>>
>     >>>      * Section 2.3 paragraphs 1 and 2. There is edit-itis here
left
>     > (I
>     >>>      suspect) from working in matching fingerprints. Consider
>     > combining
>     >>>      and simplifying these two paragraphs after improving the
>     > reference
>     >>>      issue called out above.
>     >>>
>     >>>      * Section 4 says "Access control mechanisms MUST be used
to
>     >>>      limit..." This is not a good use of a 2119 MUST. I
suggest
>     >>>      replacing "MUST be" with "are". The subsequent text
already
>     >>>      captures the actual normative requirements on the server.
>     >>>
>     >>>      * Section 12 says "this protocol SHOULD be implemented
>     > carefully".
>     >>>      That is not a good use of a 2119 SHOULD. It is not a
protocol
>     >>>      requirement. I suggest reformulating this into something
like
>     >>>      "There are many patterns of attack that have been
observed
>     > through
>     >>>      operational practice with existing management interfaces.
It
>     > would
>     >>>      be wise for implementers to research them, and take them
into
>     >>>      account when implementing this protocol." It would be far
better
>     >>>      to provide a pointer to where the implementer should
start this
>     >>>      research.
>     >>>
>     >>>      * (micronit) Lots of examples are internally inconsistent
wrt
>     >>>      dates. For instance, look at the 200 OK in section
3.3.3 - it
>     > says
>     >>>      that back in 2012, a server returned something talking
about a
>     >>>      library versioned in 2016.
>     >>>
>     >>>
>     >>>
>     >>> Andy
>     >>>
>     >>
>     >
>




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


From nobody Tue Aug  2 05:12:56 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80FB12D563 for ; Tue,  2 Aug 2016 05:12:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.198
X-Spam-Level: 
X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjSIpaEXV9n6 for ; Tue,  2 Aug 2016 05:12:51 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8B812D54C for ; Tue,  2 Aug 2016 05:12:51 -0700 (PDT)
Received: from syd-vpn-client-246-27.cisco.com (unknown [64.104.248.199]) by mail.tail-f.com (Postfix) with ESMTPSA id 2DE401AE034E; Tue,  2 Aug 2016 14:12:38 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_DC7C04C2-D30E-42E1-9192-83DA83AF2121"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail
From: Jan Lindblad 
In-Reply-To: <78c52bbab4d44b938e1dcf191d95b42a@EMEAWP-EXMB11.corp.brocade.com>
Date: Tue, 2 Aug 2016 14:12:32 +0200
Message-Id: 
References:  <87vazljnps.fsf@hobgoblin.ariadne.com>    <13a7626442c34f499392b67bcf29ea53@EMEAWP-EXMB11.corp.brocade.com>  <78c52bbab4d44b938e1dcf191d95b42a@EMEAWP-EXMB11.corp.brocade.com>
To: William Ivory , Andy Bierman 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 02 Aug 2016 12:12:55 -0000

--Apple-Mail=_DC7C04C2-D30E-42E1-9192-83DA83AF2121
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_E93AA720-E102-4A49-81DB-343D7F753197"


--Apple-Mail=_E93AA720-E102-4A49-81DB-343D7F753197
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Those of us who believe the presence statement in YANG 1.0 specifies =
some behavioral difference between P and NP containers tend to think of =
the YANG 1.1 specification edits below as clarifications rather than =
functional changes.

This should come as no surprise to anyone who has had the strength to =
follow the full length of the thread, but since my opinion was =
requested, I thought I'd clarify anyway.

As SDO our main goal should be to get clear specs describing useful =
functionality. NP containers, as defined in YANG 1.1 and (less clearly) =
in YANG 1.0 are very useful IMO. I would prefer to describe NP =
containers as always existing if the parent exists, but may be =
suppressed in get-config when empty. I proposed some specific language =
earlier. I find this more natural than language around spontaneous =
creation and deletion by the server, even if the net result may be the =
same. The voucher example is indeed YANG 1.0.

/jan

> On 1 aug. 2016, at 17:10, William Ivory  wrote:
>=20
> Hi Andy,
>=20
> Thanks =E2=80=93 in isolation that is clear, but I would be interested =
in Jan=E2=80=99s thoughts given that the given ownership-voucher example =
would appear to be YANG 1.0 *and* assume must statements are evaluated =
on non-presence containers if the parent node exists.
>=20
> Regards,
>=20
> William
>=20
> From: Andy Bierman [mailto:andy@yumaworks.com]
> Sent: 01 August 2016 16:03
> To: William Ivory 
> Cc: Ladislav Lhotka ; janl@tail-f.com; Netconf =

> Subject: Re: [Netconf] What should a server response be? - depending =
on NP-containers
>=20
> Hi,
>=20
> I think I made that comment.
> In YANG 1.0, only default leafs were considered always present.
> In YANG 1.1 NP containers were added to the set of accessible nodes
>=20
> In YANG 1.0, sec. 7.5.3
>=20
>    o  The accessible tree is made up of all nodes in the data tree, =
and
>       all leafs with default values in use (see Section 7.6.1).
>=20
> This was changed in YANG 1.1
>=20
> sec 7.5.3:
>=20
>    When a datastore is validated, all "must" constraints are
>    conceptually evaluated once for each node in the accessible tree =
(see
>    Section 6.4.1).
> Sec. 6.4.1
>=20
>       If a node that exists in the accessible tree has a non-presence
>       container as a child, then the non-presence container also =
exists in
>       the tree.
>=20
>=20
> Andy
>=20
>=20
>=20
>=20
> On Mon, Aug 1, 2016 at 7:51 AM, William Ivory > wrote:
> Hi,
>=20
> Could someone confirm then that must statements on a non-presence =
container in YANG 1.0 are only to be evaluated if the non-presence =
container has configured children =E2=80=A6 or is it also if (reading =
Lada=E2=80=99s mail) the implementation chooses to implement them when =
there are no children present?
>=20
> I had assumed that the text in YANG 1.1 was clarifying YANG 1.0 rather =
than new functionality here but I=E2=80=99m a little confused now, =
especially given the comment by Jan Lindblad regarding this YANG snippet =
as the file does not contain =E2=80=98yang-version 1.1=E2=80=99 and =
would surely therefore be version 1.0?
>=20
>       container ownership-voucher {
>         description
>           "This container contains the Ownership Voucher that the
>            device uses to ascertain the identity of its rightful
>            owner, as certified by its Vendor.";
>=20
>         when "../redirect-information/signature or =
../bootstrap-information/*/signature";
>         must "../owner-certificate";
>=20
>         uses ownership-voucher-grouping;
>       }
>=20
>=20
> =
https://github.com/YangModels/yang/blob/master/standard/ietf/DRAFT/ietf-ze=
rotouch-bootstrap-server.yang =

>=20
> Jan=E2=80=99s comment on this YANG (assuming it=E2=80=99s 1.0) and =
Lada=E2=80=99s assertion (pasted below) appear contradictory to me.
>=20
> =E2=80=98NP containers were not always present in YANG 1.0.
> The must-stmt only applied if they actually are present,
> which is an implementation choice.
> =E2=80=98
>=20
> I=E2=80=99m also thinking that any must statement on a non-presence =
container in YANG 1.0 models might sensibly be (re)written as =
=E2=80=98not(current() or =E2=80=99 to make =
it future-proof if these nodes do not exist in 1.0 w/o children but do =
in YANG 1.1.  That would allow for easier model migration.
>=20
> Regards,
>=20
> William
>=20
> From: Netconf [mailto:netconf-bounces@ietf.org =
] On Behalf Of Andy Bierman
> Sent: 01 August 2016 15:23
> To: Ladislav Lhotka >
> Cc: Netconf >
> Subject: Re: [Netconf] What should a server response be? - depending =
on NP-containers
>=20
>=20
>=20
> On Mon, Aug 1, 2016 at 7:13 AM, Ladislav Lhotka > wrote:
> Andy Bierman > writes:
>=20
> > Hi,
> >
> > YANG 1.1 has been changed so the XPath is not really =
backward-compatible
> > with YANG 1.0.  In YANG 1.1 NP-containers always exist if the non-NP =
parent
> > is
> > instantiated.
>=20
> My mental model regarding NP-containers is that they are part of
> the default contents of a datastore. If an NP-container is "in use"
> (according to the same rules as specified in sec. 7.6.1 of 6020bis for
> default leaves), then
>=20
> - creating a child of this container succeeds,
>=20
> - "must" expressions defined on this container apply.
>=20
>=20
>=20
> NP containers were not always present in YANG 1.0.
> The must-stmt only applied if they actually are present,
> which is an implementation choice.
>=20
> I don't understand all this special wording about "do not error if..."
>=20
> NETCONF has explicit support for this exact use-case, called "merge".
> This was done precisely to support these "don't error if..." cases.
> So use "merge" if you want this functionality.
>=20
>=20
> Lada
>=20
> Andy
>=20
>=20
> >
> > NETCONF and RESTCONF do not say anything about the server ignoring
> > the rules for operation=3D"create", operation=3D"delete" and
> > default-operation=3D"none".
> > IMO itr would be a really bad idea to continue spreading little =
protocol
> > details
> > in the YANG RFC.  People might read the protocol spec and =
(correctly) assume
> > that the protocol does not trat NP containers special at all.
> >
> > If anything, the sentence about MAY delete needs to be removed =
because
> > it is inconsistent with the XPath (always exists).
> >
> >
> > Andy
> >
> >
> > On Sun, Jul 31, 2016 at 6:13 PM, Dale R. Worley > wrote:
> >
> >> Mahesh Jethanandani > writes:
> >> > I think this argument of whether server should or should not
> >> > create/delete NP containers is distracting from the main point of =
when
> >> > NP containers should exist. In my mind, the NP container =
existence
> >> > depends on whether child nodes exist or not. In the end, if child
> >> > nodes exist, NP containers should exist (created), if they do not
> >> > exist, the NP container should be removed.
> >> >
> >> > Can we agree on that?
> >>
> >> If the concept of a "non-presence container" makes any sense, then =
the
> >> existence of an empty container must have exactly the same =
significance
> >> as the non-extence of the container.
> >>
> >> Given that, we have to make sure the protocol is consistent with =
that
> >> principle.  E.g., if you ask to create an element of a non-existing =
NP
> >> container, it must succeed, because asking to create an element of =
an
> >> existing but empty NP container succeeds.
> >>
> >> I don't see what all the consequences of this principle are, but if =
we
> >> can't make the protocol consistent with it, then we can't properly
> >> implement the concept of NP containers.
> >>
> >> Dale
> >>
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org 
> > https://www.ietf.org/mailman/listinfo/netconf =

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


--Apple-Mail=_E93AA720-E102-4A49-81DB-343D7F753197
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Those of us who believe the presence statement in YANG 1.0 =
specifies some behavioral difference between P and NP containers tend to =
think of the YANG 1.1 specification edits below as clarifications rather =
than functional changes. 

This should come as no surprise to =
anyone who has had the strength to follow the full length of the thread, =
but since my opinion was requested, I thought I'd clarify =
anyway.

As SDO =
our main goal should be to get clear specs describing useful =
functionality. NP containers, as defined in YANG 1.1 and (less clearly) =
in YANG 1.0 are very useful IMO. I would prefer to describe NP =
containers as always existing if the parent exists, but may be =
suppressed in get-config when empty. I proposed some specific language =
earlier. I find this more natural than language around spontaneous =
creation and deletion by the server, even if the net result may be the =
same. The voucher example is indeed YANG 1.0.

/jan

On 1 aug. 2016, at 17:10, William Ivory <wivory@Brocade.com> =
wrote:

Hi Andy,
 
Thanks =E2=80=93 in =
isolation that is clear, but I would be interested in Jan=E2=80=99s =
thoughts given that the given ownership-voucher example would appear to =
be YANG 1.0 *and* assume must statements are evaluated =
on non-presence containers if the parent node exists.
 
Regards,
 
William
 
From: Andy Bierman [mailto:andy@yumaworks.com] 
Sent: 01 =
August 2016 16:03
To: William Ivory <wivory@Brocade.com>
Cc: Ladislav Lhotka <lhotka@nic.cz>; janl@tail-f.com; Netconf =
<netconf@ietf.org>
Subject: Re: [Netconf] What should a =
server response be? - depending on NP-containers
 
Hi,
 
I think I made that comment.
In YANG 1.0, only default leafs were considered always =
present.
In YANG 1.1 NP containers were added to =
the set of accessible nodes
 
In YANG 1.0, sec. 7.5.3
 
   o  The accessible tree is made up of all =
nodes in the data tree, and
      all leafs with default values =
in use (see Section 7.6.1).
 
This was changed in YANG 1.1
 
sec 7.5.3:

   When a datastore is validated, all =
"must" constraints are
   =
conceptually evaluated once for each node in the accessible tree =
(see
   Section 6.4.1).
Sec. 6.4.1
 
      If a node that =
exists in the accessible tree has a non-presence
      container as a child, then the =
non-presence container also exists in
      the tree.
 
 
Andy
 
 
 
 
On Mon, Aug 1, 2016 =
at 7:51 AM, William Ivory <wivory@brocade.com> wrote:
Hi,
 
Could someone confirm then that must =
statements on a non-presence container in YANG 1.0 are only to be =
evaluated if the non-presence container has configured children =E2=80=A6 =
or is it also if (reading Lada=E2=80=99s mail) the implementation =
chooses to implement them when there are no children present?
 
I had assumed that the text in YANG 1.1 =
was clarifying YANG 1.0 rather than new functionality here but I=E2=80=99m=
 a little confused now, especially given the comment by Jan Lindblad =
regarding this YANG snippet as the file does not contain =E2=80=98yang-ver=
sion 1.1=E2=80=99 and would surely therefore be version 1.0?
 
 =
     container ownership-voucher {
  =
      description
      =
    "This container contains the Ownership Voucher that =
the
           device uses =
to ascertain the identity of its rightful
    =
       owner, as certified by its Vendor.";

        when =
"../redirect-information/signature or =
../bootstrap-information/*/signature";
    =
    must "../owner-certificate";

        uses =
ownership-voucher-grouping;
      }
 
 
https://github.com/YangModels/yang/blob/master/standard/ietf/DR=
AFT/ietf-zerotouch-bootstrap-server.yang
 
Jan=E2=80=99s comment on this YANG =
(assuming it=E2=80=99s 1.0) and Lada=E2=80=99s assertion (pasted below) =
appear contradictory to me.
 
=E2=80=98NP =
containers were not always present in YANG 1.0.
The =
must-stmt only applied if they actually are present,
which =
is an implementation choice.
=E2=80=98
 
I=E2=80=99m also =
thinking that any must statement on a non-presence container in YANG 1.0 =
models might sensibly be (re)written as =E2=80=98not(current() or =
<required_xpath_expression>=E2=80=99 to make it future-proof if =
these nodes do not exist in 1.0 w/o children but do in YANG 1.1.  =
That would allow for easier model migration.
 
Regards,
 
William
 
From: Netconf =
[mailto:netconf-bounces@ietf.org] On Behalf =
Of Andy Bierman
Sent: 01 August 2016 15:23
To: Ladislav Lhotka <lhotka@nic.cz>
Cc: Netconf <netconf@ietf.org>
Subject: Re: [Netconf] What should a =
server response be? - depending on NP-containers
 
 
 
On Mon, Aug 1, 2016 at 7:13 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
Andy Bierman <andy@yumaworks.com>=
 writes:

> Hi,
>
> YANG 1.1 has been changed so the XPath is not really =
backward-compatible
> with YANG 1.0.  In YANG 1.1 =
NP-containers always exist if the non-NP parent
> is
> instantiated.

My mental =
model regarding NP-containers is that they are part of
the =
default contents of a datastore. If an NP-container is "in use"
(according to the same rules as specified in sec. 7.6.1 of =
6020bis for
default leaves), then

- creating a child of this container succeeds,

- "must" expressions defined on this container =
apply.
 
 
NP containers were not always present in =
YANG 1.0.
The must-stmt only applied if they =
actually are present,
which is an =
implementation choice.
 
I don't understand all this special wording about "do not =
error if..."
 
NETCONF has explicit support for this exact use-case, called =
"merge".
This was done precisely to support these =
"don't error if..." cases.
So use "merge" if you =
want this functionality. 
 
 
Lada
 
Andy
 

>
> NETCONF and RESTCONF do not say =
anything about the server ignoring
> the rules for =
operation=3D"create", operation=3D"delete" and
> =
default-operation=3D"none".
> IMO itr would be a really =
bad idea to continue spreading little protocol
> =
details
> in the YANG RFC.  People might read the =
protocol spec and (correctly) assume
> that the =
protocol does not trat NP containers special at all.
>> If anything, the sentence about MAY delete needs to be =
removed because
> it is inconsistent with the XPath =
(always exists).
>
>
> =
Andy
>
>
> On Sun, =
Jul 31, 2016 at 6:13 PM, Dale R. Worley <worley@ariadne.com>=
 wrote:
>
>> Mahesh Jethanandani =
<mjethanandani@gmail.com> writes:
>> =
> I think this argument of whether server should or should not
>> > create/delete NP containers is distracting from =
the main point of when
>> > NP containers should =
exist. In my mind, the NP container existence
>> =
> depends on whether child nodes exist or not. In the end, if =
child
>> > nodes exist, NP containers should =
exist (created), if they do not
>> > exist, the =
NP container should be removed.
>> >
>> > Can we agree on that?
>>
>> If the concept of a "non-presence container" makes =
any sense, then the
>> existence of an empty =
container must have exactly the same significance
>> =
as the non-extence of the container.
>>
>> Given that, we have to make sure the protocol is =
consistent with that
>> principle.  E.g., if =
you ask to create an element of a non-existing NP
>> =
container, it must succeed, because asking to create an element of an
>> existing but empty NP container succeeds.
>>
>> I don't see what all the =
consequences of this principle are, but if we
>> =
can't make the protocol consistent with it, then we can't properly
>> implement the concept of NP containers.
>>
>> Dale
>>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

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

=

--Apple-Mail=_E93AA720-E102-4A49-81DB-343D7F753197--

--Apple-Mail=_DC7C04C2-D30E-42E1-9192-83DA83AF2121
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJXoI4xAAoJEBSCnbqufIisoNIH/ijEuiQ8GOvWeDobMu0URqmA
YseoYr+erdkAhzLBdl7sCYYu5NSzkD0OCu9BMxOTUa7v0CPCL6SB/pdmLvNrBV+o
p6fSfipmx63WCxl9VH2hvw8/3RN4IBnssMP7A9TKjGsEDuAxOZdHXXM8CCZ4wjdh
GP0jV8GDuIce5LO/YxXZSW6jM3A1Ohz3rkIsKKPHs4rt2P0gag10pbJwE8e2ZMRK
NSyecoLvA39us9oaFJSwt+JisWJIHbeoQJVemP/tfVrlUry8tZ0kIpDBXR/5VxhU
b3w1IFcSOLCgzcTRAwyZfCGrw8GysjAnWyAseg8ePVdBF+3mjw4RamGZ9mZmVP4=
=sTCC
-----END PGP SIGNATURE-----

--Apple-Mail=_DC7C04C2-D30E-42E1-9192-83DA83AF2121--


From nobody Tue Aug  2 05:41:14 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40DB812D5A1 for ; Tue,  2 Aug 2016 05:41:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.089
X-Spam-Level: 
X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id db4H-Y34iypP for ; Tue,  2 Aug 2016 05:41:09 -0700 (PDT)
Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (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 6A00F12B026 for ; Tue,  2 Aug 2016 05:41:09 -0700 (PDT)
Received: from pps.filterd (m0000700.ppops.net [127.0.0.1]) by m0000700.ppops.net (8.16.0.11/8.16.0.11) with SMTP id u72CZHgE011839; Tue, 2 Aug 2016 05:41:08 -0700
Received: from brmwp-exmb11.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 24gsv299eb-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 02 Aug 2016 05:41:08 -0700
Received: from EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) by BRMWP-EXMB11.corp.brocade.com (172.16.59.77) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Tue, 2 Aug 2016 06:41:06 -0600
Received: from EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) by EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Tue, 2 Aug 2016 14:41:04 +0200
Received: from EMEAWP-EXMB11.corp.brocade.com ([fe80::85ea:b7da:48dd:1640]) by EMEAWP-EXMB11.corp.brocade.com ([fe80::85ea:b7da:48dd:1640%21]) with mapi id 15.00.1156.000; Tue, 2 Aug 2016 14:41:04 +0200
From: William Ivory 
To: Jan Lindblad , Andy Bierman 
Thread-Topic: [Netconf] What should a server response be? - depending on NP-containers
Thread-Index: AQHR65HjCKulpI0Pc0iHx2JTqSf796AzNTEAgADP0wCAAALRgIAAJAdA///nFYCAACJxEIABQD0AgAAjShA=
Date: Tue, 2 Aug 2016 12:40:34 +0000
Deferred-Delivery: Tue, 2 Aug 2016 12:40:14 +0000
Message-ID: 
References:  <87vazljnps.fsf@hobgoblin.ariadne.com>    <13a7626442c34f499392b67bcf29ea53@EMEAWP-EXMB11.corp.brocade.com>  <78c52bbab4d44b938e1dcf191d95b42a@EMEAWP-EXMB11.corp.brocade.com> 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.27.212.49]
Content-Type: multipart/alternative; boundary="_000_db811e7b4b2a4da9b445d66be869009eEMEAWPEXMB11corpbrocade_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-02_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 impostorscore=0 lowpriorityscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608020121
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 02 Aug 2016 12:41:13 -0000

--_000_db811e7b4b2a4da9b445d66be869009eEMEAWPEXMB11corpbrocade_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

U28gaWYgSSB3ZXJlIHRvIGltcGxlbWVudCB0aGUgZGVjaXNpb24gb24gd2hldGhlciB0byBldmFs
dWF0ZSBtdXN0cyBvbiBOUCBjb250YWluZXJzIHRoYXQgaGF2ZSBubyBjaGlsZHJlbiB1c2luZyBy
YW5kb20oKSwgdGhhdCB3b3VsZCBtZWV0IHRoZSBzcGVjPyAoLToNCg0KRnJvbSB0aGUgcGVyc3Bl
Y3RpdmUgb2Ygd3JpdGluZyBvdXIgWUFORyAxLjAgbW9kZWxzLCB3ZSBjYW4gYWRkIOKAmG5vdCBj
dXJyZW50KCkgb3Ig4oCm4oCZIG9uIHRoZSBmcm9udCBvZiBhbnkgbXVzdCBzdGF0ZW1lbnQgb24g
YSBOUCBjb250YWluZXIgaWYgd2Ugb25seSB3YW50IGl0IHRvIGJlIGV2YWx1YXRlZCB3aGVuIHRo
ZSBOUCBjb250YWluZXIgaGFzIGNoaWxkIG5vZGUocykuICBUaGF0IGF0IGxlYXN0IHJlbGF4ZXMg
cmVzdHJpY3Rpb25zIChzbyBtZWV0cyBSRkMgNjAyMCBzZWN0aW9uIDEwIGJhY2t3YXJkcy1jb21w
YXRpYmlsaXR5IHJlcXVpcmVtZW50cykgYW5kIHJlZHVjZXMgdGhlIG51bWJlciBvZiBOUCBjb250
YWluZXJzIHdoZXJlIGV2YWx1YXRpb24gb2YgbXVzdCBzdGF0ZW1lbnRzIHdvdWxkIGFwcGVhciB0
byBiZSBpbXBsZW1lbnRhdGlvbi1zcGVjaWZpYyBmb3IgWUFORyAxLjAuDQoNCkZyb20gSmFu4oCZ
cyBwZXJzcGVjdGl2ZSBJIGNhbiBzZWUgdGhhdCBub3QgZXZhbHVhdGluZyBtdXN0IHN0YXRlbWVu
dHMgb24gTlAgY29udGFpbmVycyB3aXRoIG5vIGNoaWxkIG5vZGVzIHdvdWxkIGludmFsaWRhdGUg
aGlzIFlBTkcgbW9kZWwsIGJ1dCBlcXVhbGx5IGFueSBOUCBjb250YWluZXIgd2l0aCB0aGUgbGlr
ZXMgb2Yg4oCYbXVzdCDigJxub3QoLi4vZm9vKeKAnTvigJkgd291bGQgbWFrZSBjb25maWd1cmF0
aW9uIG9mIOKAmGZvb+KAmSBpbXBvc3NpYmxlIGlmIHdlIHRha2UgdGhlIDEuMSBjbGFyaWZpY2F0
aW9uIGFuZCBhcHBseSBpdCB0byAxLjAuICBVbmxlc3MgdGhlcmUgaXMgZXhpc3RpbmcgY2xlYXIg
Z3VpZGFuY2UgdGhhdCB0aGUgbGF0dGVyIGZvcm0gb2YgbXVzdCBzdGF0ZW1lbnQgc2hvdWxkICht
dXN0PykgYmUgYXZvaWRlZCwgdGhlbiBJIGRvbuKAmXQgc2VlIGFueSBvdmVycG93ZXJpbmcgYXJn
dW1lbnQgaW4gZWl0aGVyIGRpcmVjdGlvbi4gIEl0IGNvbWVzIGRvd24gcGVyaGFwcyB0byB3aGV0
aGVyIHdlIHByZWZlciB0byBhbGxvdyBzb21lIGNvbmZpZ3VyYXRpb25zIHRoYXQgd2VyZW7igJl0
IGludGVuZGVkIHRvIGJlIGFsbG93ZWQgKG5vdCBldmFsdWF0aW5nIG11c3RzIHRoYXQgd2VyZSBp
bnRlbmRlZCB0byBiZSBldmFsdWF0ZWQpIG9yIHdlIHBvdGVudGlhbGx5IGJsb2NrIHZhbGlkIGNv
bmZpZ3VyYXRpb25zIChldmFsdWF0aW5nIG11c3RzIHRoYXQgd2VyZW7igJl0IGludGVuZGVkIHRv
IGFsd2F5cyBiZSBldmFsdWF0ZWQpLg0KDQpGcm9tIGEgcHJhZ21hdGljIHBlcnNwZWN0aXZlLCB0
aGUgUG9zdGVsIHByaW5jaXBsZSBvZiBiZWluZyBsaWJlcmFsIGluIHdoYXQgeW91IGFjY2VwdCAo
YXQgbGVhc3QgaW4gWUFORykgd291bGQgc2VlbSBtb3JlIGZsZXhpYmxlIGluIHRoYXQgb25jZSBj
b25maWcgaXMgcmVqZWN0ZWQsIHRoZXJl4oCZcyBubyBhbHRlcm5hdGl2ZSwgd2hlcmVhcyB5b3Ug
Y2FuIGFsd2F5cyBhZHZpc2UgdGhhdCBjb25maWd1cmF0aW9uIGlzIGFjY2VwdGVkIGJ1dCDigJh1
bndpc2XigJkuDQoNCknigJltIG5vdCBmYW1pbGlhciBlbm91Z2ggd2l0aCBJRVRGIHByb2NlZHVy
ZXMgdG8ga25vdyBob3cgdGhpcyBzaG91bGQgYmUgcmVzb2x2ZWQgc28gd291bGQgYXBwcmVjaWF0
ZSBhZHZpY2UhDQoNClRoYW5rcywNCg0KV2lsbGlhbQ0KDQpGcm9tOiBKYW4gTGluZGJsYWQgW21h
aWx0bzpqYW5sQHRhaWwtZi5jb21dDQpTZW50OiAwMiBBdWd1c3QgMjAxNiAxMzoxMw0KVG86IFdp
bGxpYW0gSXZvcnkgPHdpdm9yeUBCcm9jYWRlLmNvbT47IEFuZHkgQmllcm1hbiA8YW5keUB5dW1h
d29ya3MuY29tPg0KQ2M6IExhZGlzbGF2IExob3RrYSA8bGhvdGthQG5pYy5jej47IE5ldGNvbmYg
PG5ldGNvbmZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW05ldGNvbmZdIFdoYXQgc2hvdWxkIGEg
c2VydmVyIHJlc3BvbnNlIGJlPyAtIGRlcGVuZGluZyBvbiBOUC1jb250YWluZXJzDQoNClRob3Nl
IG9mIHVzIHdobyBiZWxpZXZlIHRoZSBwcmVzZW5jZSBzdGF0ZW1lbnQgaW4gWUFORyAxLjAgc3Bl
Y2lmaWVzIHNvbWUgYmVoYXZpb3JhbCBkaWZmZXJlbmNlIGJldHdlZW4gUCBhbmQgTlAgY29udGFp
bmVycyB0ZW5kIHRvIHRoaW5rIG9mIHRoZSBZQU5HIDEuMSBzcGVjaWZpY2F0aW9uIGVkaXRzIGJl
bG93IGFzIGNsYXJpZmljYXRpb25zIHJhdGhlciB0aGFuIGZ1bmN0aW9uYWwgY2hhbmdlcy4NCg0K
VGhpcyBzaG91bGQgY29tZSBhcyBubyBzdXJwcmlzZSB0byBhbnlvbmUgd2hvIGhhcyBoYWQgdGhl
IHN0cmVuZ3RoIHRvIGZvbGxvdyB0aGUgZnVsbCBsZW5ndGggb2YgdGhlIHRocmVhZCwgYnV0IHNp
bmNlIG15IG9waW5pb24gd2FzIHJlcXVlc3RlZCwgSSB0aG91Z2h0IEknZCBjbGFyaWZ5IGFueXdh
eS4NCg0KQXMgU0RPIG91ciBtYWluIGdvYWwgc2hvdWxkIGJlIHRvIGdldCBjbGVhciBzcGVjcyBk
ZXNjcmliaW5nIHVzZWZ1bCBmdW5jdGlvbmFsaXR5LiBOUCBjb250YWluZXJzLCBhcyBkZWZpbmVk
IGluIFlBTkcgMS4xIGFuZCAobGVzcyBjbGVhcmx5KSBpbiBZQU5HIDEuMCBhcmUgdmVyeSB1c2Vm
dWwgSU1PLiBJIHdvdWxkIHByZWZlciB0byBkZXNjcmliZSBOUCBjb250YWluZXJzIGFzIGFsd2F5
cyBleGlzdGluZyBpZiB0aGUgcGFyZW50IGV4aXN0cywgYnV0IG1heSBiZSBzdXBwcmVzc2VkIGlu
IGdldC1jb25maWcgd2hlbiBlbXB0eS4gSSBwcm9wb3NlZCBzb21lIHNwZWNpZmljIGxhbmd1YWdl
IGVhcmxpZXIuIEkgZmluZCB0aGlzIG1vcmUgbmF0dXJhbCB0aGFuIGxhbmd1YWdlIGFyb3VuZCBz
cG9udGFuZW91cyBjcmVhdGlvbiBhbmQgZGVsZXRpb24gYnkgdGhlIHNlcnZlciwgZXZlbiBpZiB0
aGUgbmV0IHJlc3VsdCBtYXkgYmUgdGhlIHNhbWUuIFRoZSB2b3VjaGVyIGV4YW1wbGUgaXMgaW5k
ZWVkIFlBTkcgMS4wLg0KDQovamFuDQoNCk9uIDEgYXVnLiAyMDE2LCBhdCAxNzoxMCwgV2lsbGlh
bSBJdm9yeSA8d2l2b3J5QEJyb2NhZGUuY29tPG1haWx0bzp3aXZvcnlAYnJvY2FkZS5jb20+PiB3
cm90ZToNCg0KSGkgQW5keSwNCg0KVGhhbmtzIOKAkyBpbiBpc29sYXRpb24gdGhhdCBpcyBjbGVh
ciwgYnV0IEkgd291bGQgYmUgaW50ZXJlc3RlZCBpbiBKYW7igJlzIHRob3VnaHRzIGdpdmVuIHRo
YXQgdGhlIGdpdmVuIG93bmVyc2hpcC12b3VjaGVyIGV4YW1wbGUgd291bGQgYXBwZWFyIHRvIGJl
IFlBTkcgMS4wICphbmQqIGFzc3VtZSBtdXN0IHN0YXRlbWVudHMgYXJlIGV2YWx1YXRlZCBvbiBu
b24tcHJlc2VuY2UgY29udGFpbmVycyBpZiB0aGUgcGFyZW50IG5vZGUgZXhpc3RzLg0KDQpSZWdh
cmRzLA0KDQpXaWxsaWFtDQoNCkZyb206IEFuZHkgQmllcm1hbiBbbWFpbHRvOmFuZHlAeXVtYXdv
cmtzLmNvbV0NClNlbnQ6IDAxIEF1Z3VzdCAyMDE2IDE2OjAzDQpUbzogV2lsbGlhbSBJdm9yeSA8
d2l2b3J5QEJyb2NhZGUuY29tPG1haWx0bzp3aXZvcnlAYnJvY2FkZS5jb20+Pg0KQ2M6IExhZGlz
bGF2IExob3RrYSA8bGhvdGthQG5pYy5jejxtYWlsdG86bGhvdGthQG5pYy5jej4+OyBqYW5sQHRh
aWwtZi5jb208bWFpbHRvOmphbmxAdGFpbC1mLmNvbT47IE5ldGNvbmYgPG5ldGNvbmZAaWV0Zi5v
cmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtOZXRjb25mXSBXaGF0
IHNob3VsZCBhIHNlcnZlciByZXNwb25zZSBiZT8gLSBkZXBlbmRpbmcgb24gTlAtY29udGFpbmVy
cw0KDQpIaSwNCg0KSSB0aGluayBJIG1hZGUgdGhhdCBjb21tZW50Lg0KSW4gWUFORyAxLjAsIG9u
bHkgZGVmYXVsdCBsZWFmcyB3ZXJlIGNvbnNpZGVyZWQgYWx3YXlzIHByZXNlbnQuDQpJbiBZQU5H
IDEuMSBOUCBjb250YWluZXJzIHdlcmUgYWRkZWQgdG8gdGhlIHNldCBvZiBhY2Nlc3NpYmxlIG5v
ZGVzDQoNCkluIFlBTkcgMS4wLCBzZWMuIDcuNS4zDQoNCg0KICAgbyAgVGhlIGFjY2Vzc2libGUg
dHJlZSBpcyBtYWRlIHVwIG9mIGFsbCBub2RlcyBpbiB0aGUgZGF0YSB0cmVlLCBhbmQNCg0KICAg
ICAgYWxsIGxlYWZzIHdpdGggZGVmYXVsdCB2YWx1ZXMgaW4gdXNlIChzZWUgU2VjdGlvbiA3LjYu
MSkuDQoNCg0KVGhpcyB3YXMgY2hhbmdlZCBpbiBZQU5HIDEuMQ0KDQpzZWMgNy41LjM6DQoNCg0K
DQogICBXaGVuIGEgZGF0YXN0b3JlIGlzIHZhbGlkYXRlZCwgYWxsICJtdXN0IiBjb25zdHJhaW50
cyBhcmUNCg0KICAgY29uY2VwdHVhbGx5IGV2YWx1YXRlZCBvbmNlIGZvciBlYWNoIG5vZGUgaW4g
dGhlIGFjY2Vzc2libGUgdHJlZSAoc2VlDQoNCiAgIFNlY3Rpb24gNi40LjEpLg0KU2VjLiA2LjQu
MQ0KDQogICAgICBJZiBhIG5vZGUgdGhhdCBleGlzdHMgaW4gdGhlIGFjY2Vzc2libGUgdHJlZSBo
YXMgYSBub24tcHJlc2VuY2UNCiAgICAgIGNvbnRhaW5lciBhcyBhIGNoaWxkLCB0aGVuIHRoZSBu
b24tcHJlc2VuY2UgY29udGFpbmVyIGFsc28gZXhpc3RzIGluDQogICAgICB0aGUgdHJlZS4NCg0K
DQpBbmR5DQoNCg0KDQoNCk9uIE1vbiwgQXVnIDEsIDIwMTYgYXQgNzo1MSBBTSwgV2lsbGlhbSBJ
dm9yeSA8d2l2b3J5QGJyb2NhZGUuY29tPG1haWx0bzp3aXZvcnlAYnJvY2FkZS5jb20+PiB3cm90
ZToNCkhpLA0KDQpDb3VsZCBzb21lb25lIGNvbmZpcm0gdGhlbiB0aGF0IG11c3Qgc3RhdGVtZW50
cyBvbiBhIG5vbi1wcmVzZW5jZSBjb250YWluZXIgaW4gWUFORyAxLjAgYXJlIG9ubHkgdG8gYmUg
ZXZhbHVhdGVkIGlmIHRoZSBub24tcHJlc2VuY2UgY29udGFpbmVyIGhhcyBjb25maWd1cmVkIGNo
aWxkcmVuIOKApiBvciBpcyBpdCBhbHNvIGlmIChyZWFkaW5nIExhZGHigJlzIG1haWwpIHRoZSBp
bXBsZW1lbnRhdGlvbiBjaG9vc2VzIHRvIGltcGxlbWVudCB0aGVtIHdoZW4gdGhlcmUgYXJlIG5v
IGNoaWxkcmVuIHByZXNlbnQ/DQoNCkkgaGFkIGFzc3VtZWQgdGhhdCB0aGUgdGV4dCBpbiBZQU5H
IDEuMSB3YXMgY2xhcmlmeWluZyBZQU5HIDEuMCByYXRoZXIgdGhhbiBuZXcgZnVuY3Rpb25hbGl0
eSBoZXJlIGJ1dCBJ4oCZbSBhIGxpdHRsZSBjb25mdXNlZCBub3csIGVzcGVjaWFsbHkgZ2l2ZW4g
dGhlIGNvbW1lbnQgYnkgSmFuIExpbmRibGFkIHJlZ2FyZGluZyB0aGlzIFlBTkcgc25pcHBldCBh
cyB0aGUgZmlsZSBkb2VzIG5vdCBjb250YWluIOKAmHlhbmctdmVyc2lvbiAxLjHigJkgYW5kIHdv
dWxkIHN1cmVseSB0aGVyZWZvcmUgYmUgdmVyc2lvbiAxLjA/DQoNCiAgICAgIGNvbnRhaW5lciBv
d25lcnNoaXAtdm91Y2hlciB7DQogICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAgIlRoaXMg
Y29udGFpbmVyIGNvbnRhaW5zIHRoZSBPd25lcnNoaXAgVm91Y2hlciB0aGF0IHRoZQ0KICAgICAg
ICAgICBkZXZpY2UgdXNlcyB0byBhc2NlcnRhaW4gdGhlIGlkZW50aXR5IG9mIGl0cyByaWdodGZ1
bA0KICAgICAgICAgICBvd25lciwgYXMgY2VydGlmaWVkIGJ5IGl0cyBWZW5kb3IuIjsNCg0KICAg
ICAgICB3aGVuICIuLi9yZWRpcmVjdC1pbmZvcm1hdGlvbi9zaWduYXR1cmUgb3IgLi4vYm9vdHN0
cmFwLWluZm9ybWF0aW9uLyovc2lnbmF0dXJlIjsNCiAgICAgICAgbXVzdCAiLi4vb3duZXItY2Vy
dGlmaWNhdGUiOw0KDQogICAgICAgIHVzZXMgb3duZXJzaGlwLXZvdWNoZXItZ3JvdXBpbmc7DQog
ICAgICB9DQoNCg0KaHR0cHM6Ly9naXRodWIuY29tL1lhbmdNb2RlbHMveWFuZy9ibG9iL21hc3Rl
ci9zdGFuZGFyZC9pZXRmL0RSQUZUL2lldGYtemVyb3RvdWNoLWJvb3RzdHJhcC1zZXJ2ZXIueWFu
ZzxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2dp
dGh1Yi5jb21fWWFuZ01vZGVsc195YW5nX2Jsb2JfbWFzdGVyX3N0YW5kYXJkX2lldGZfRFJBRlRf
aWV0Zi0yRHplcm90b3VjaC0yRGJvb3RzdHJhcC0yRHNlcnZlci55YW5nJmQ9Q3dNRmFRJmM9SUxf
WHFRV09qdWJnZnFJTmkyalR6ZyZyPUdCeUxlZzlqWnZPdl9BbGdCbzl1dmREcnhpemxPUjdsX1Nu
VFhvd3lKVTgmbT1VX3FtdF9WMzBJcDczMGdtMFpMMGc5Vk9DdFNHZVhISFV3anJnWEZVV0VRJnM9
dk0zakRLem1fcS1JQnpRZG5lQ1VrTVk3MTBUMWtaLU8yaGhfVmhTTWRCbyZlPT4NCg0KSmFu4oCZ
cyBjb21tZW50IG9uIHRoaXMgWUFORyAoYXNzdW1pbmcgaXTigJlzIDEuMCkgYW5kIExhZGHigJlz
IGFzc2VydGlvbiAocGFzdGVkIGJlbG93KSBhcHBlYXIgY29udHJhZGljdG9yeSB0byBtZS4NCg0K
4oCYTlAgY29udGFpbmVycyB3ZXJlIG5vdCBhbHdheXMgcHJlc2VudCBpbiBZQU5HIDEuMC4NClRo
ZSBtdXN0LXN0bXQgb25seSBhcHBsaWVkIGlmIHRoZXkgYWN0dWFsbHkgYXJlIHByZXNlbnQsDQp3
aGljaCBpcyBhbiBpbXBsZW1lbnRhdGlvbiBjaG9pY2UuDQrigJgNCg0KSeKAmW0gYWxzbyB0aGlu
a2luZyB0aGF0IGFueSBtdXN0IHN0YXRlbWVudCBvbiBhIG5vbi1wcmVzZW5jZSBjb250YWluZXIg
aW4gWUFORyAxLjAgbW9kZWxzIG1pZ2h0IHNlbnNpYmx5IGJlIChyZSl3cml0dGVuIGFzIOKAmG5v
dChjdXJyZW50KCkgb3IgPHJlcXVpcmVkX3hwYXRoX2V4cHJlc3Npb24+4oCZIHRvIG1ha2UgaXQg
ZnV0dXJlLXByb29mIGlmIHRoZXNlIG5vZGVzIGRvIG5vdCBleGlzdCBpbiAxLjAgdy9vIGNoaWxk
cmVuIGJ1dCBkbyBpbiBZQU5HIDEuMS4gIFRoYXQgd291bGQgYWxsb3cgZm9yIGVhc2llciBtb2Rl
bCBtaWdyYXRpb24uDQoNClJlZ2FyZHMsDQoNCldpbGxpYW0NCg0KRnJvbTogTmV0Y29uZiBbbWFp
bHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYu
b3JnPl0gT24gQmVoYWxmIE9mIEFuZHkgQmllcm1hbg0KU2VudDogMDEgQXVndXN0IDIwMTYgMTU6
MjMNClRvOiBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBuaWMuY3o8bWFpbHRvOmxob3RrYUBuaWMu
Y3o+Pg0KQ2M6IE5ldGNvbmYgPG5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5v
cmc+Pg0KU3ViamVjdDogUmU6IFtOZXRjb25mXSBXaGF0IHNob3VsZCBhIHNlcnZlciByZXNwb25z
ZSBiZT8gLSBkZXBlbmRpbmcgb24gTlAtY29udGFpbmVycw0KDQoNCg0KT24gTW9uLCBBdWcgMSwg
MjAxNiBhdCA3OjEzIEFNLCBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBuaWMuY3o8bWFpbHRvOmxo
b3RrYUBuaWMuY3o+PiB3cm90ZToNCkFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPG1h
aWx0bzphbmR5QHl1bWF3b3Jrcy5jb20+PiB3cml0ZXM6DQoNCj4gSGksDQo+DQo+IFlBTkcgMS4x
IGhhcyBiZWVuIGNoYW5nZWQgc28gdGhlIFhQYXRoIGlzIG5vdCByZWFsbHkgYmFja3dhcmQtY29t
cGF0aWJsZQ0KPiB3aXRoIFlBTkcgMS4wLiAgSW4gWUFORyAxLjEgTlAtY29udGFpbmVycyBhbHdh
eXMgZXhpc3QgaWYgdGhlIG5vbi1OUCBwYXJlbnQNCj4gaXMNCj4gaW5zdGFudGlhdGVkLg0KDQpN
eSBtZW50YWwgbW9kZWwgcmVnYXJkaW5nIE5QLWNvbnRhaW5lcnMgaXMgdGhhdCB0aGV5IGFyZSBw
YXJ0IG9mDQp0aGUgZGVmYXVsdCBjb250ZW50cyBvZiBhIGRhdGFzdG9yZS4gSWYgYW4gTlAtY29u
dGFpbmVyIGlzICJpbiB1c2UiDQooYWNjb3JkaW5nIHRvIHRoZSBzYW1lIHJ1bGVzIGFzIHNwZWNp
ZmllZCBpbiBzZWMuIDcuNi4xIG9mIDYwMjBiaXMgZm9yDQpkZWZhdWx0IGxlYXZlcyksIHRoZW4N
Cg0KLSBjcmVhdGluZyBhIGNoaWxkIG9mIHRoaXMgY29udGFpbmVyIHN1Y2NlZWRzLA0KDQotICJt
dXN0IiBleHByZXNzaW9ucyBkZWZpbmVkIG9uIHRoaXMgY29udGFpbmVyIGFwcGx5Lg0KDQoNCk5Q
IGNvbnRhaW5lcnMgd2VyZSBub3QgYWx3YXlzIHByZXNlbnQgaW4gWUFORyAxLjAuDQpUaGUgbXVz
dC1zdG10IG9ubHkgYXBwbGllZCBpZiB0aGV5IGFjdHVhbGx5IGFyZSBwcmVzZW50LA0Kd2hpY2gg
aXMgYW4gaW1wbGVtZW50YXRpb24gY2hvaWNlLg0KDQpJIGRvbid0IHVuZGVyc3RhbmQgYWxsIHRo
aXMgc3BlY2lhbCB3b3JkaW5nIGFib3V0ICJkbyBub3QgZXJyb3IgaWYuLi4iDQoNCk5FVENPTkYg
aGFzIGV4cGxpY2l0IHN1cHBvcnQgZm9yIHRoaXMgZXhhY3QgdXNlLWNhc2UsIGNhbGxlZCAibWVy
Z2UiLg0KVGhpcyB3YXMgZG9uZSBwcmVjaXNlbHkgdG8gc3VwcG9ydCB0aGVzZSAiZG9uJ3QgZXJy
b3IgaWYuLi4iIGNhc2VzLg0KU28gdXNlICJtZXJnZSIgaWYgeW91IHdhbnQgdGhpcyBmdW5jdGlv
bmFsaXR5Lg0KDQoNCkxhZGENCg0KQW5keQ0KDQoNCj4NCj4gTkVUQ09ORiBhbmQgUkVTVENPTkYg
ZG8gbm90IHNheSBhbnl0aGluZyBhYm91dCB0aGUgc2VydmVyIGlnbm9yaW5nDQo+IHRoZSBydWxl
cyBmb3Igb3BlcmF0aW9uPSJjcmVhdGUiLCBvcGVyYXRpb249ImRlbGV0ZSIgYW5kDQo+IGRlZmF1
bHQtb3BlcmF0aW9uPSJub25lIi4NCj4gSU1PIGl0ciB3b3VsZCBiZSBhIHJlYWxseSBiYWQgaWRl
YSB0byBjb250aW51ZSBzcHJlYWRpbmcgbGl0dGxlIHByb3RvY29sDQo+IGRldGFpbHMNCj4gaW4g
dGhlIFlBTkcgUkZDLiAgUGVvcGxlIG1pZ2h0IHJlYWQgdGhlIHByb3RvY29sIHNwZWMgYW5kIChj
b3JyZWN0bHkpIGFzc3VtZQ0KPiB0aGF0IHRoZSBwcm90b2NvbCBkb2VzIG5vdCB0cmF0IE5QIGNv
bnRhaW5lcnMgc3BlY2lhbCBhdCBhbGwuDQo+DQo+IElmIGFueXRoaW5nLCB0aGUgc2VudGVuY2Ug
YWJvdXQgTUFZIGRlbGV0ZSBuZWVkcyB0byBiZSByZW1vdmVkIGJlY2F1c2UNCj4gaXQgaXMgaW5j
b25zaXN0ZW50IHdpdGggdGhlIFhQYXRoIChhbHdheXMgZXhpc3RzKS4NCj4NCj4NCj4gQW5keQ0K
Pg0KPg0KPiBPbiBTdW4sIEp1bCAzMSwgMjAxNiBhdCA2OjEzIFBNLCBEYWxlIFIuIFdvcmxleSA8
d29ybGV5QGFyaWFkbmUuY29tPG1haWx0bzp3b3JsZXlAYXJpYWRuZS5jb20+PiB3cm90ZToNCj4N
Cj4+IE1haGVzaCBKZXRoYW5hbmRhbmkgPG1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0bzpt
amV0aGFuYW5kYW5pQGdtYWlsLmNvbT4+IHdyaXRlczoNCj4+ID4gSSB0aGluayB0aGlzIGFyZ3Vt
ZW50IG9mIHdoZXRoZXIgc2VydmVyIHNob3VsZCBvciBzaG91bGQgbm90DQo+PiA+IGNyZWF0ZS9k
ZWxldGUgTlAgY29udGFpbmVycyBpcyBkaXN0cmFjdGluZyBmcm9tIHRoZSBtYWluIHBvaW50IG9m
IHdoZW4NCj4+ID4gTlAgY29udGFpbmVycyBzaG91bGQgZXhpc3QuIEluIG15IG1pbmQsIHRoZSBO
UCBjb250YWluZXIgZXhpc3RlbmNlDQo+PiA+IGRlcGVuZHMgb24gd2hldGhlciBjaGlsZCBub2Rl
cyBleGlzdCBvciBub3QuIEluIHRoZSBlbmQsIGlmIGNoaWxkDQo+PiA+IG5vZGVzIGV4aXN0LCBO
UCBjb250YWluZXJzIHNob3VsZCBleGlzdCAoY3JlYXRlZCksIGlmIHRoZXkgZG8gbm90DQo+PiA+
IGV4aXN0LCB0aGUgTlAgY29udGFpbmVyIHNob3VsZCBiZSByZW1vdmVkLg0KPj4gPg0KPj4gPiBD
YW4gd2UgYWdyZWUgb24gdGhhdD8NCj4+DQo+PiBJZiB0aGUgY29uY2VwdCBvZiBhICJub24tcHJl
c2VuY2UgY29udGFpbmVyIiBtYWtlcyBhbnkgc2Vuc2UsIHRoZW4gdGhlDQo+PiBleGlzdGVuY2Ug
b2YgYW4gZW1wdHkgY29udGFpbmVyIG11c3QgaGF2ZSBleGFjdGx5IHRoZSBzYW1lIHNpZ25pZmlj
YW5jZQ0KPj4gYXMgdGhlIG5vbi1leHRlbmNlIG9mIHRoZSBjb250YWluZXIuDQo+Pg0KPj4gR2l2
ZW4gdGhhdCwgd2UgaGF2ZSB0byBtYWtlIHN1cmUgdGhlIHByb3RvY29sIGlzIGNvbnNpc3RlbnQg
d2l0aCB0aGF0DQo+PiBwcmluY2lwbGUuICBFLmcuLCBpZiB5b3UgYXNrIHRvIGNyZWF0ZSBhbiBl
bGVtZW50IG9mIGEgbm9uLWV4aXN0aW5nIE5QDQo+PiBjb250YWluZXIsIGl0IG11c3Qgc3VjY2Vl
ZCwgYmVjYXVzZSBhc2tpbmcgdG8gY3JlYXRlIGFuIGVsZW1lbnQgb2YgYW4NCj4+IGV4aXN0aW5n
IGJ1dCBlbXB0eSBOUCBjb250YWluZXIgc3VjY2VlZHMuDQo+Pg0KPj4gSSBkb24ndCBzZWUgd2hh
dCBhbGwgdGhlIGNvbnNlcXVlbmNlcyBvZiB0aGlzIHByaW5jaXBsZSBhcmUsIGJ1dCBpZiB3ZQ0K
Pj4gY2FuJ3QgbWFrZSB0aGUgcHJvdG9jb2wgY29uc2lzdGVudCB3aXRoIGl0LCB0aGVuIHdlIGNh
bid0IHByb3Blcmx5DQo+PiBpbXBsZW1lbnQgdGhlIGNvbmNlcHQgb2YgTlAgY29udGFpbmVycy4N
Cj4+DQo+PiBEYWxlDQo+Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KPiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPiBOZXRjb25mQGlldGYub3JnPG1h
aWx0bzpOZXRjb25mQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL25ldGNvbmY8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91
PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19uZXRjb25mJmQ9Q3dNRmFR
JmM9SUxfWHFRV09qdWJnZnFJTmkyalR6ZyZyPUdCeUxlZzlqWnZPdl9BbGdCbzl1dmREcnhpemxP
UjdsX1NuVFhvd3lKVTgmbT01RHhHYzE4aWdMTGF6b3dFSlJxZmxMMlZ6a0MtSFZjUHhYdXo3bHRn
R1RnJnM9bEtRTTdLNllhTlQta3l1WHNQUnFsdVo3bFBXazg0Wmxhc05tSDI4OEl6MCZlPT4NCg0K
LS0NCkxhZGlzbGF2IExob3RrYSwgQ1ouTklDIExhYnMNClBHUCBLZXkgSUQ6IEU3NEU4QzBDDQoN
Cg==

--_000_db811e7b4b2a4da9b445d66be869009eEMEAWPEXMB11corpbrocade_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0
dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt
c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLmFwcGxlLWNv
bnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0K
c3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3Jt
YXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI
VE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5ob2VuemIN
Cgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHls
ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm
Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw
b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6
ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9
DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt
LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk
bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+
DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0
YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi
b2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9
IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+U28gaWYgSSB3ZXJlIHRvIGlt
cGxlbWVudCB0aGUgZGVjaXNpb24gb24gd2hldGhlciB0byBldmFsdWF0ZSBtdXN0cyBvbiBOUCBj
b250YWluZXJzIHRoYXQgaGF2ZSBubyBjaGlsZHJlbiB1c2luZyByYW5kb20oKSwgdGhhdCB3b3Vs
ZA0KIG1lZXQgdGhlIHNwZWM/ICgtOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1
YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF
Ti1VUyI+RnJvbSB0aGUgcGVyc3BlY3RpdmUgb2Ygd3JpdGluZyBvdXIgWUFORyAxLjAgbW9kZWxz
LCB3ZSBjYW4gYWRkIOKAmG5vdCBjdXJyZW50KCkgb3Ig4oCm4oCZIG9uIHRoZSBmcm9udCBvZiBh
bnkgbXVzdCBzdGF0ZW1lbnQgb24gYSBOUCBjb250YWluZXINCiBpZiB3ZSBvbmx5IHdhbnQgaXQg
dG8gYmUgZXZhbHVhdGVkIHdoZW4gdGhlIE5QIGNvbnRhaW5lciBoYXMgY2hpbGQgbm9kZShzKS4m
bmJzcDsgVGhhdCBhdCBsZWFzdCByZWxheGVzIHJlc3RyaWN0aW9ucyAoc28gbWVldHMgUkZDIDYw
MjAgc2VjdGlvbiAxMCBiYWNrd2FyZHMtY29tcGF0aWJpbGl0eSByZXF1aXJlbWVudHMpIGFuZCBy
ZWR1Y2VzIHRoZSBudW1iZXIgb2YgTlAgY29udGFpbmVycyB3aGVyZSBldmFsdWF0aW9uIG9mIG11
c3Qgc3RhdGVtZW50cw0KIHdvdWxkIGFwcGVhciB0byBiZSBpbXBsZW1lbnRhdGlvbi1zcGVjaWZp
YyBmb3IgWUFORyAxLjAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t
VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5G
cm9tIEphbuKAmXMgcGVyc3BlY3RpdmUgSSBjYW4gc2VlIHRoYXQgbm90IGV2YWx1YXRpbmcgbXVz
dCBzdGF0ZW1lbnRzIG9uIE5QIGNvbnRhaW5lcnMgd2l0aCBubyBjaGlsZCBub2RlcyB3b3VsZCBp
bnZhbGlkYXRlIGhpcyBZQU5HDQogbW9kZWwsIGJ1dCBlcXVhbGx5IGFueSBOUCBjb250YWluZXIg
d2l0aCB0aGUgbGlrZXMgb2Yg4oCYbXVzdCDigJxub3QoLi4vZm9vKeKAnTvigJkgd291bGQgbWFr
ZSBjb25maWd1cmF0aW9uIG9mIOKAmGZvb+KAmSBpbXBvc3NpYmxlIGlmIHdlIHRha2UgdGhlIDEu
MSBjbGFyaWZpY2F0aW9uIGFuZCBhcHBseSBpdCB0byAxLjAuJm5ic3A7IFVubGVzcyB0aGVyZSBp
cyBleGlzdGluZyBjbGVhciBndWlkYW5jZSB0aGF0IHRoZSBsYXR0ZXIgZm9ybSBvZiBtdXN0IHN0
YXRlbWVudCBzaG91bGQNCiAobXVzdD8pIGJlIGF2b2lkZWQsIHRoZW4gSSBkb27igJl0IHNlZSBh
bnkgb3ZlcnBvd2VyaW5nIGFyZ3VtZW50IGluIGVpdGhlciBkaXJlY3Rpb24uJm5ic3A7IEl0IGNv
bWVzIGRvd24gcGVyaGFwcyB0byB3aGV0aGVyIHdlIHByZWZlciB0byBhbGxvdyBzb21lIGNvbmZp
Z3VyYXRpb25zIHRoYXQgd2VyZW7igJl0IGludGVuZGVkIHRvIGJlIGFsbG93ZWQgKG5vdCBldmFs
dWF0aW5nIG11c3RzIHRoYXQgd2VyZSBpbnRlbmRlZCB0byBiZSBldmFsdWF0ZWQpIG9yIHdlDQog
cG90ZW50aWFsbHkgYmxvY2sgdmFsaWQgY29uZmlndXJhdGlvbnMgKGV2YWx1YXRpbmcgbXVzdHMg
dGhhdCB3ZXJlbuKAmXQgaW50ZW5kZWQgdG8gYWx3YXlzIGJlIGV2YWx1YXRlZCkuPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0
OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Gcm9tIGEgcHJhZ21hdGljIHBlcnNwZWN0
aXZlLCB0aGUgUG9zdGVsIHByaW5jaXBsZSBvZiBiZWluZyBsaWJlcmFsIGluIHdoYXQgeW91IGFj
Y2VwdCAoYXQgbGVhc3QgaW4gWUFORykgd291bGQgc2VlbSBtb3JlIGZsZXhpYmxlDQogaW4gdGhh
dCBvbmNlIGNvbmZpZyBpcyByZWplY3RlZCwgdGhlcmXigJlzIG5vIGFsdGVybmF0aXZlLCB3aGVy
ZWFzIHlvdSBjYW4gYWx3YXlzIGFkdmlzZSB0aGF0IGNvbmZpZ3VyYXRpb24gaXMgYWNjZXB0ZWQg
YnV0IOKAmHVud2lzZeKAmS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF
Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi
PknigJltIG5vdCBmYW1pbGlhciBlbm91Z2ggd2l0aCBJRVRGIHByb2NlZHVyZXMgdG8ga25vdyBo
b3cgdGhpcyBzaG91bGQgYmUgcmVzb2x2ZWQgc28gd291bGQgYXBwcmVjaWF0ZSBhZHZpY2UhPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFua3MsPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE
O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5XaWxsaWFtPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv
LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk
aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w
cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZiI+IEphbiBMaW5kYmxhZCBbbWFpbHRvOmphbmxAdGFpbC1mLmNvbV0N
Cjxicj4NCjxiPlNlbnQ6PC9iPiAwMiBBdWd1c3QgMjAxNiAxMzoxMzxicj4NCjxiPlRvOjwvYj4g
V2lsbGlhbSBJdm9yeSAmbHQ7d2l2b3J5QEJyb2NhZGUuY29tJmd0OzsgQW5keSBCaWVybWFuICZs
dDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBMYWRpc2xhdiBMaG90a2Eg
Jmx0O2xob3RrYUBuaWMuY3omZ3Q7OyBOZXRjb25mICZsdDtuZXRjb25mQGlldGYub3JnJmd0Ozxi
cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW05ldGNvbmZdIFdoYXQgc2hvdWxkIGEgc2VydmVyIHJl
c3BvbnNlIGJlPyAtIGRlcGVuZGluZyBvbiBOUC1jb250YWluZXJzPG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhvc2Ugb2YgdXMgd2hvIGJlbGlldmUgdGhl
IHByZXNlbmNlIHN0YXRlbWVudCBpbiBZQU5HIDEuMCBzcGVjaWZpZXMgc29tZSBiZWhhdmlvcmFs
IGRpZmZlcmVuY2UgYmV0d2VlbiBQIGFuZCBOUCBjb250YWluZXJzIHRlbmQgdG8gdGhpbmsgb2Yg
dGhlIFlBTkcgMS4xIHNwZWNpZmljYXRpb24gZWRpdHMgYmVsb3cgYXMgY2xhcmlmaWNhdGlvbnMg
cmF0aGVyIHRoYW4gZnVuY3Rpb25hbCBjaGFuZ2VzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgc2hvdWxkIGNvbWUgYXMgbm8g
c3VycHJpc2UgdG8gYW55b25lIHdobyBoYXMgaGFkIHRoZSBzdHJlbmd0aCB0byBmb2xsb3cgdGhl
IGZ1bGwgbGVuZ3RoIG9mIHRoZSB0aHJlYWQsIGJ1dCBzaW5jZSBteSBvcGluaW9uIHdhcyByZXF1
ZXN0ZWQsIEkgdGhvdWdodCBJJ2QgY2xhcmlmeSBhbnl3YXkuPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIFNETyBvdXIgbWFpbiBnb2FsIHNo
b3VsZCBiZSB0byBnZXQgY2xlYXIgc3BlY3MgZGVzY3JpYmluZyB1c2VmdWwgZnVuY3Rpb25hbGl0
eS4gTlAgY29udGFpbmVycywgYXMgZGVmaW5lZCBpbiBZQU5HIDEuMSBhbmQgKGxlc3MgY2xlYXJs
eSkgaW4gWUFORyAxLjAgYXJlIHZlcnkgdXNlZnVsIElNTy4gSSB3b3VsZCBwcmVmZXIgdG8gZGVz
Y3JpYmUgTlAgY29udGFpbmVycyBhcyBhbHdheXMgZXhpc3RpbmcgaWYNCiB0aGUgcGFyZW50IGV4
aXN0cywgYnV0IG1heSBiZSBzdXBwcmVzc2VkIGluIGdldC1jb25maWcgd2hlbiBlbXB0eS4gSSBw
cm9wb3NlZCBzb21lIHNwZWNpZmljIGxhbmd1YWdlIGVhcmxpZXIuIEkgZmluZCB0aGlzIG1vcmUg
bmF0dXJhbCB0aGFuIGxhbmd1YWdlIGFyb3VuZCBzcG9udGFuZW91cyBjcmVhdGlvbiBhbmQgZGVs
ZXRpb24gYnkgdGhlIHNlcnZlciwgZXZlbiBpZiB0aGUgbmV0IHJlc3VsdCBtYXkgYmUgdGhlIHNh
bWUuIFRoZSB2b3VjaGVyDQogZXhhbXBsZSBpcyBpbmRlZWQgWUFORyAxLjAuPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi9qYW48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw
dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAx
IGF1Zy4gMjAxNiwgYXQgMTc6MTAsIFdpbGxpYW0gSXZvcnkgJmx0OzxhIGhyZWY9Im1haWx0bzp3
aXZvcnlAYnJvY2FkZS5jb20iPndpdm9yeUBCcm9jYWRlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0QiPkhpIEFuZHksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi
PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3Mg4oCTIGluIGlz
b2xhdGlvbiB0aGF0IGlzIGNsZWFyLCBidXQgSSB3b3VsZCBiZSBpbnRlcmVzdGVkIGluIEphbuKA
mXMgdGhvdWdodHMgZ2l2ZW4gdGhhdCB0aGUgZ2l2ZW4gb3duZXJzaGlwLXZvdWNoZXIgZXhhbXBs
ZSB3b3VsZCBhcHBlYXIgdG8gYmUgWUFORyAxLjAgKjxiPmFuZDwvYj4qDQogYXNzdW1lIG11c3Qg
c3RhdGVtZW50cyBhcmUgZXZhbHVhdGVkIG9uIG5vbi1wcmVzZW5jZSBjb250YWluZXJzIGlmIHRo
ZSBwYXJlbnQgbm9kZSBleGlzdHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu
YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG
NDk3RCI+V2lsbGlhbTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xh
c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+
Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BbmR5DQog
Qmllcm1hbiBbPGEgaHJlZj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbSI+bWFpbHRvOmFuZHlA
eXVtYXdvcmtzLmNvbTwvYT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i
c3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt
c3BhY2UiPiZuYnNwOzwvc3Bhbj4wMSBBdWd1c3QgMjAxNiAxNjowMzxicj4NCjxiPlRvOjwvYj48
c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+V2lsbGlhbSBJ
dm9yeSAmbHQ7PGEgaHJlZj0ibWFpbHRvOndpdm9yeUBicm9jYWRlLmNvbSI+d2l2b3J5QEJyb2Nh
ZGUuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl
ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkxhZGlzbGF2IExob3RrYSAmbHQ7PGEgaHJlZj0ibWFpbHRv
Omxob3RrYUBuaWMuY3oiPmxob3RrYUBuaWMuY3o8L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpq
YW5sQHRhaWwtZi5jb20iPmphbmxAdGFpbC1mLmNvbTwvYT47IE5ldGNvbmYgJmx0OzxhIGhyZWY9
Im1haWx0bzpuZXRjb25mQGlldGYub3JnIj5uZXRjb25mQGlldGYub3JnPC9hPiZndDs8YnI+DQo8
Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8
L3NwYW4+UmU6IFtOZXRjb25mXSBXaGF0IHNob3VsZCBhIHNlcnZlciByZXNwb25zZSBiZT8gLSBk
ZXBlbmRpbmcgb24gTlAtY29udGFpbmVyczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+SSB0aGluayBJIG1hZGUgdGhhdCBjb21tZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gWUFORyAxLjAsIG9u
bHkgZGVmYXVsdCBsZWFmcyB3ZXJlIGNvbnNpZGVyZWQgYWx3YXlzIHByZXNlbnQuPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5JbiBZQU5HIDEuMSBOUCBjb250YWluZXJzIHdlcmUgYWRkZWQgdG8gdGhlIHNldCBvZiBhY2Nl
c3NpYmxlIG5vZGVzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIFlBTkcgMS4wLCBzZWMu
IDcuNS4zPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPHByZSBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkIj4mbmJzcDsmbmJzcDsgbyZu
YnNwOyBUaGUgYWNjZXNzaWJsZSB0cmVlIGlzIG1hZGUgdXAgb2YgYWxsIG5vZGVzIGluIHRoZSBk
YXRhIHRyZWUsIGFuZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyBhbGwgbGVhZnMgd2l0aCBkZWZhdWx0IHZhbHVlcyBpbiB1c2UgKHNlZSBTZWN0
aW9uIDcuNi4xKS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJl
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgd2FzIGNoYW5nZWQgaW4gWUFORyAx
LjE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c2VjIDcuNS4zOjxicj4NCjxicj4NCjxicj4N
CjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cHJlPiZuYnNwOyZuYnNwOyBXaGVuIGEgZGF0YXN0
b3JlIGlzIHZhbGlkYXRlZCwgYWxsICZxdW90O211c3QmcXVvdDsgY29uc3RyYWludHMgYXJlPG86
cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGNvbmNlcHR1YWxseSBldmFsdWF0ZWQg
b25jZSBmb3IgZWFjaCBub2RlIGluIHRoZSBhY2Nlc3NpYmxlIHRyZWUgKHNlZTxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBTZWN0aW9uIDYuNC4xKS48bzpwPjwvbzpwPjwvcHJl
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlYy4gNi40LjE8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IElm
IGEgbm9kZSB0aGF0IGV4aXN0cyBpbiB0aGUgYWNjZXNzaWJsZSB0cmVlIGhhcyBhIG5vbi1wcmVz
ZW5jZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgY29udGFpbmVyIGFzIGEgY2hpbGQs
IHRoZW4gdGhlIG5vbi1wcmVzZW5jZSBjb250YWluZXIgYWxzbyBleGlzdHMgaW48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PiZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoZSB0cmVlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBN
b24sIEF1ZyAxLCAyMDE2IGF0IDc6NTEgQU0sIFdpbGxpYW0gSXZvcnkgJmx0OzxhIGhyZWY9Im1h
aWx0bzp3aXZvcnlAYnJvY2FkZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s
b3I6cHVycGxlIj53aXZvcnlAYnJvY2FkZS5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2lu
LWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0
b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q291bGQgc29t
ZW9uZSBjb25maXJtIHRoZW4gdGhhdCBtdXN0IHN0YXRlbWVudHMgb24gYSBub24tcHJlc2VuY2Ug
Y29udGFpbmVyIGluIFlBTkcgMS4wIGFyZSBvbmx5IHRvIGJlIGV2YWx1YXRlZCBpZiB0aGUgbm9u
LXByZXNlbmNlIGNvbnRhaW5lciBoYXMgY29uZmlndXJlZA0KIGNoaWxkcmVuIOKApiBvciBpcyBp
dCBhbHNvIGlmIChyZWFkaW5nIExhZGHigJlzIG1haWwpIHRoZSBpbXBsZW1lbnRhdGlvbiBjaG9v
c2VzIHRvIGltcGxlbWVudCB0aGVtIHdoZW4gdGhlcmUgYXJlIG5vIGNoaWxkcmVuIHByZXNlbnQ/
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMUY0OTdEIj5JIGhhZCBhc3N1bWVkIHRoYXQgdGhlIHRleHQgaW4gWUFORyAxLjEg
d2FzIGNsYXJpZnlpbmcgWUFORyAxLjAgcmF0aGVyIHRoYW4gbmV3IGZ1bmN0aW9uYWxpdHkgaGVy
ZSBidXQgSeKAmW0gYSBsaXR0bGUgY29uZnVzZWQgbm93LCBlc3BlY2lhbGx5IGdpdmVuIHRoZSBj
b21tZW50DQogYnkgSmFuIExpbmRibGFkIHJlZ2FyZGluZyB0aGlzIFlBTkcgc25pcHBldCBhcyB0
aGUgZmlsZSBkb2VzIG5vdCBjb250YWluIOKAmHlhbmctdmVyc2lvbiAxLjHigJkgYW5kIHdvdWxk
IHN1cmVseSB0aGVyZWZvcmUgYmUgdmVyc2lvbiAxLjA/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7Y29udGFpbmVyIG93
bmVyc2hpcC12b3VjaGVyIHs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDtk
ZXNjcmlwdGlvbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsm
cXVvdDtUaGlzIGNvbnRhaW5lciBjb250YWlucyB0aGUgT3duZXJzaGlwIFZvdWNoZXIgdGhhdCB0
aGU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RldmljZSB1
c2VzIHRvIGFzY2VydGFpbiB0aGUgaWRlbnRpdHkgb2YgaXRzIHJpZ2h0ZnVsPGJyPg0KJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtvd25lciwgYXMgY2VydGlmaWVkIGJ5
IGl0cyBWZW5kb3IuJnF1b3Q7Ozxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyZuYnNwO3doZW4gJnF1b3Q7Li4vcmVkaXJlY3QtaW5mb3JtYXRpb24vc2lnbmF0dXJlIG9yIC4u
L2Jvb3RzdHJhcC1pbmZvcm1hdGlvbi8qL3NpZ25hdHVyZSZxdW90Ozs8YnI+DQombmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsmbmJzcDttdXN0ICZxdW90Oy4uL293bmVyLWNlcnRpZmljYXRlJnF1
b3Q7Ozxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwO3VzZXMgb3du
ZXJzaGlwLXZvdWNoZXItZ3JvdXBpbmc7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyB9PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw
Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48YSBocmVmPSJodHRwczovL3VybGRl
ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2dpdGh1Yi5jb21fWWFuZ01v
ZGVsc195YW5nX2Jsb2JfbWFzdGVyX3N0YW5kYXJkX2lldGZfRFJBRlRfaWV0Zi0yRHplcm90b3Vj
aC0yRGJvb3RzdHJhcC0yRHNlcnZlci55YW5nJmFtcDtkPUN3TUZhUSZhbXA7Yz1JTF9YcVFXT2p1
YmdmcUlOaTJqVHpnJmFtcDtyPUdCeUxlZzlqWnZPdl9BbGdCbzl1dmREcnhpemxPUjdsX1NuVFhv
d3lKVTgmYW1wO209VV9xbXRfVjMwSXA3MzBnbTBaTDBnOVZPQ3RTR2VYSEhVd2pyZ1hGVVdFUSZh
bXA7cz12TTNqREt6bV9xLUlCelFkbmVDVWtNWTcxMFQxa1otTzJoaF9WaFNNZEJvJmFtcDtlPSIg
dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vZ2l0aHVi
LmNvbS9ZYW5nTW9kZWxzL3lhbmcvYmxvYi9tYXN0ZXIvc3RhbmRhcmQvaWV0Zi9EUkFGVC9pZXRm
LXplcm90b3VjaC1ib290c3RyYXAtc2VydmVyLnlhbmc8L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3
RCI+SmFu4oCZcyBjb21tZW50IG9uIHRoaXMgWUFORyAoYXNzdW1pbmcgaXTigJlzIDEuMCkgYW5k
IExhZGHigJlzIGFzc2VydGlvbiAocGFzdGVkIGJlbG93KSBhcHBlYXIgY29udHJhZGljdG9yeSB0
byBtZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPuKAmDwvc3Bhbj5OUCBjb250YWluZXJzIHdlcmUgbm90IGFs
d2F5cyBwcmVzZW50IGluIFlBTkcgMS4wLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIG11c3Qtc3RtdCBvbmx5IGFwcGxpZWQgaWYgdGhleSBh
Y3R1YWxseSBhcmUgcHJlc2VudCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPndoaWNoIGlzIGFuIGltcGxlbWVudGF0aW9uIGNob2ljZS48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMUY0OTdEIj7igJg8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPknigJltIGFsc28gdGhpbmtp
bmcgdGhhdCBhbnkgbXVzdCBzdGF0ZW1lbnQgb24gYSBub24tcHJlc2VuY2UgY29udGFpbmVyIGlu
IFlBTkcgMS4wIG1vZGVscyBtaWdodCBzZW5zaWJseSBiZSAocmUpd3JpdHRlbiBhcyDigJhub3Qo
Y3VycmVudCgpIG9yICZsdDtyZXF1aXJlZF94cGF0aF9leHByZXNzaW9uJmd0O+KAmQ0KIHRvIG1h
a2UgaXQgZnV0dXJlLXByb29mIGlmIHRoZXNlIG5vZGVzIGRvIG5vdCBleGlzdCBpbiAxLjAgdy9v
IGNoaWxkcmVuIGJ1dCBkbyBpbiBZQU5HIDEuMS4mbmJzcDsgVGhhdCB3b3VsZCBhbGxvdyBmb3Ig
ZWFzaWVyIG1vZGVsIG1pZ3JhdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MUY0OTdEIj5XaWxsaWFtPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBj
bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk5ldGNv
bmYNCiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmciIHRh
cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5uZXRjb25mLWJvdW5jZXNA
aWV0Zi5vcmc8L3NwYW4+PC9hPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m
bmJzcDs8L3NwYW4+PGI+T24gQmVoYWxmIE9mPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z
cGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5BbmR5IEJpZXJtYW48YnI+DQo8Yj5TZW50OjwvYj48c3Bh
biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+MDEgQXVndXN0IDIw
MTYgMTU6MjM8YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj
ZSI+Jm5ic3A7PC9zcGFuPkxhZGlzbGF2IExob3RrYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxob3Rr
YUBuaWMuY3oiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5saG90
a2FAbmljLmN6PC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJhcHBs
ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5OZXRjb25mICZsdDs8YSBocmVmPSJtYWls
dG86bmV0Y29uZkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw
dXJwbGUiPm5ldGNvbmZAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv
Yj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtO
ZXRjb25mXSBXaGF0IHNob3VsZCBhIHNlcnZlciByZXNwb25zZSBiZT8gLSBkZXBlbmRpbmcgb24g
TlAtY29udGFpbmVyczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgQXVnIDEs
IDIwMTYgYXQgNzoxMyBBTSwgTGFkaXNsYXYgTGhvdGthICZsdDs8YSBocmVmPSJtYWlsdG86bGhv
dGthQG5pYy5jeiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmxo
b3RrYUBuaWMuY3o8L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND
IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu
LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5BbmR5IEJpZXJtYW4g
Jmx0OzxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20iIHRhcmdldD0iX2JsYW5rIj48
c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5hbmR5QHl1bWF3b3Jrcy5jb208L3NwYW4+PC9hPiZn
dDsgd3JpdGVzOjxicj4NCjxicj4NCiZndDsgSGksPGJyPg0KJmd0Ozxicj4NCiZndDsgWUFORyAx
LjEgaGFzIGJlZW4gY2hhbmdlZCBzbyB0aGUgWFBhdGggaXMgbm90IHJlYWxseSBiYWNrd2FyZC1j
b21wYXRpYmxlPGJyPg0KJmd0OyB3aXRoIFlBTkcgMS4wLiZuYnNwOyBJbiBZQU5HIDEuMSBOUC1j
b250YWluZXJzIGFsd2F5cyBleGlzdCBpZiB0aGUgbm9uLU5QIHBhcmVudDxicj4NCiZndDsgaXM8
YnI+DQomZ3Q7IGluc3RhbnRpYXRlZC48YnI+DQo8YnI+DQpNeSBtZW50YWwgbW9kZWwgcmVnYXJk
aW5nIE5QLWNvbnRhaW5lcnMgaXMgdGhhdCB0aGV5IGFyZSBwYXJ0IG9mPGJyPg0KdGhlIGRlZmF1
bHQgY29udGVudHMgb2YgYSBkYXRhc3RvcmUuIElmIGFuIE5QLWNvbnRhaW5lciBpcyAmcXVvdDtp
biB1c2UmcXVvdDs8YnI+DQooYWNjb3JkaW5nIHRvIHRoZSBzYW1lIHJ1bGVzIGFzIHNwZWNpZmll
ZCBpbiBzZWMuIDcuNi4xIG9mIDYwMjBiaXMgZm9yPGJyPg0KZGVmYXVsdCBsZWF2ZXMpLCB0aGVu
PGJyPg0KPGJyPg0KLSBjcmVhdGluZyBhIGNoaWxkIG9mIHRoaXMgY29udGFpbmVyIHN1Y2NlZWRz
LDxicj4NCjxicj4NCi0gJnF1b3Q7bXVzdCZxdW90OyBleHByZXNzaW9ucyBkZWZpbmVkIG9uIHRo
aXMgY29udGFpbmVyIGFwcGx5LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+TlAgY29udGFpbmVycyB3ZXJlIG5vdCBhbHdheXMgcHJlc2VudCBpbiBZQU5HIDEuMC48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPlRoZSBtdXN0LXN0bXQgb25seSBhcHBsaWVkIGlmIHRoZXkgYWN0dWFsbHkgYXJl
IHByZXNlbnQsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj53aGljaCBpcyBhbiBpbXBsZW1lbnRhdGlvbiBjaG9pY2UuPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3QgdW5kZXJzdGFuZCBhbGwgdGhpcyBzcGVj
aWFsIHdvcmRpbmcgYWJvdXQgJnF1b3Q7ZG8gbm90IGVycm9yIGlmLi4uJnF1b3Q7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPk5FVENPTkYgaGFzIGV4cGxpY2l0IHN1cHBvcnQgZm9yIHRoaXMg
ZXhhY3QgdXNlLWNhc2UsIGNhbGxlZCAmcXVvdDttZXJnZSZxdW90Oy48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMg
d2FzIGRvbmUgcHJlY2lzZWx5IHRvIHN1cHBvcnQgdGhlc2UgJnF1b3Q7ZG9uJ3QgZXJyb3IgaWYu
Li4mcXVvdDsgY2FzZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyB1c2UgJnF1b3Q7bWVyZ2UmcXVvdDsgaWYgeW91
IHdhbnQgdGhpcyBmdW5jdGlvbmFsaXR5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj
bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5MYWRhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj
bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48YnI+DQomZ3Q7PGJyPg0KJmd0OyBORVRDT05GIGFuZCBSRVNUQ09ORiBkbyBub3Qgc2F5
IGFueXRoaW5nIGFib3V0IHRoZSBzZXJ2ZXIgaWdub3Jpbmc8YnI+DQomZ3Q7IHRoZSBydWxlcyBm
b3Igb3BlcmF0aW9uPSZxdW90O2NyZWF0ZSZxdW90Oywgb3BlcmF0aW9uPSZxdW90O2RlbGV0ZSZx
dW90OyBhbmQ8YnI+DQomZ3Q7IGRlZmF1bHQtb3BlcmF0aW9uPSZxdW90O25vbmUmcXVvdDsuPGJy
Pg0KJmd0OyBJTU8gaXRyIHdvdWxkIGJlIGEgcmVhbGx5IGJhZCBpZGVhIHRvIGNvbnRpbnVlIHNw
cmVhZGluZyBsaXR0bGUgcHJvdG9jb2w8YnI+DQomZ3Q7IGRldGFpbHM8YnI+DQomZ3Q7IGluIHRo
ZSBZQU5HIFJGQy4mbmJzcDsgUGVvcGxlIG1pZ2h0IHJlYWQgdGhlIHByb3RvY29sIHNwZWMgYW5k
IChjb3JyZWN0bHkpIGFzc3VtZTxicj4NCiZndDsgdGhhdCB0aGUgcHJvdG9jb2wgZG9lcyBub3Qg
dHJhdCBOUCBjb250YWluZXJzIHNwZWNpYWwgYXQgYWxsLjxicj4NCiZndDs8YnI+DQomZ3Q7IElm
IGFueXRoaW5nLCB0aGUgc2VudGVuY2UgYWJvdXQgTUFZIGRlbGV0ZSBuZWVkcyB0byBiZSByZW1v
dmVkIGJlY2F1c2U8YnI+DQomZ3Q7IGl0IGlzIGluY29uc2lzdGVudCB3aXRoIHRoZSBYUGF0aCAo
YWx3YXlzIGV4aXN0cykuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEFuZHk8YnI+DQom
Z3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgT24gU3VuLCBKdWwgMzEsIDIwMTYgYXQgNjoxMyBQTSwg
RGFsZSBSLiBXb3JsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp3b3JsZXlAYXJpYWRuZS5jb20iIHRh
cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj53b3JsZXlAYXJpYWRuZS5j
b208L3NwYW4+PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7IE1haGVzaCBK
ZXRoYW5hbmRhbmkgJmx0OzxhIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSIg
dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1qZXRoYW5hbmRhbmlA
Z21haWwuY29tPC9zcGFuPjwvYT4mZ3Q7IHdyaXRlczo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IEkgdGhp
bmsgdGhpcyBhcmd1bWVudCBvZiB3aGV0aGVyIHNlcnZlciBzaG91bGQgb3Igc2hvdWxkIG5vdDxi
cj4NCiZndDsmZ3Q7ICZndDsgY3JlYXRlL2RlbGV0ZSBOUCBjb250YWluZXJzIGlzIGRpc3RyYWN0
aW5nIGZyb20gdGhlIG1haW4gcG9pbnQgb2Ygd2hlbjxicj4NCiZndDsmZ3Q7ICZndDsgTlAgY29u
dGFpbmVycyBzaG91bGQgZXhpc3QuIEluIG15IG1pbmQsIHRoZSBOUCBjb250YWluZXIgZXhpc3Rl
bmNlPGJyPg0KJmd0OyZndDsgJmd0OyBkZXBlbmRzIG9uIHdoZXRoZXIgY2hpbGQgbm9kZXMgZXhp
c3Qgb3Igbm90LiBJbiB0aGUgZW5kLCBpZiBjaGlsZDxicj4NCiZndDsmZ3Q7ICZndDsgbm9kZXMg
ZXhpc3QsIE5QIGNvbnRhaW5lcnMgc2hvdWxkIGV4aXN0IChjcmVhdGVkKSwgaWYgdGhleSBkbyBu
b3Q8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IGV4aXN0LCB0aGUgTlAgY29udGFpbmVyIHNob3VsZCBiZSBy
ZW1vdmVkLjxicj4NCiZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IENhbiB3ZSBhZ3Jl
ZSBvbiB0aGF0Pzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSWYgdGhlIGNvbmNlcHQgb2Yg
YSAmcXVvdDtub24tcHJlc2VuY2UgY29udGFpbmVyJnF1b3Q7IG1ha2VzIGFueSBzZW5zZSwgdGhl
biB0aGU8YnI+DQomZ3Q7Jmd0OyBleGlzdGVuY2Ugb2YgYW4gZW1wdHkgY29udGFpbmVyIG11c3Qg
aGF2ZSBleGFjdGx5IHRoZSBzYW1lIHNpZ25pZmljYW5jZTxicj4NCiZndDsmZ3Q7IGFzIHRoZSBu
b24tZXh0ZW5jZSBvZiB0aGUgY29udGFpbmVyLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg
R2l2ZW4gdGhhdCwgd2UgaGF2ZSB0byBtYWtlIHN1cmUgdGhlIHByb3RvY29sIGlzIGNvbnNpc3Rl
bnQgd2l0aCB0aGF0PGJyPg0KJmd0OyZndDsgcHJpbmNpcGxlLiZuYnNwOyBFLmcuLCBpZiB5b3Ug
YXNrIHRvIGNyZWF0ZSBhbiBlbGVtZW50IG9mIGEgbm9uLWV4aXN0aW5nIE5QPGJyPg0KJmd0OyZn
dDsgY29udGFpbmVyLCBpdCBtdXN0IHN1Y2NlZWQsIGJlY2F1c2UgYXNraW5nIHRvIGNyZWF0ZSBh
biBlbGVtZW50IG9mIGFuPGJyPg0KJmd0OyZndDsgZXhpc3RpbmcgYnV0IGVtcHR5IE5QIGNvbnRh
aW5lciBzdWNjZWVkcy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEkgZG9uJ3Qgc2VlIHdo
YXQgYWxsIHRoZSBjb25zZXF1ZW5jZXMgb2YgdGhpcyBwcmluY2lwbGUgYXJlLCBidXQgaWYgd2U8
YnI+DQomZ3Q7Jmd0OyBjYW4ndCBtYWtlIHRoZSBwcm90b2NvbCBjb25zaXN0ZW50IHdpdGggaXQs
IHRoZW4gd2UgY2FuJ3QgcHJvcGVybHk8YnI+DQomZ3Q7Jmd0OyBpbXBsZW1lbnQgdGhlIGNvbmNl
cHQgb2YgTlAgY29udGFpbmVycy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IERhbGU8YnI+
DQomZ3Q7Jmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX188YnI+DQomZ3Q7IE5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPg0KJmd0OzxzcGFu
IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWls
dG86TmV0Y29uZkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpw
dXJwbGUiPk5ldGNvbmZAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCiZndDs8c3BhbiBjbGFzcz0i
YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly91cmxk
ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFp
bG1hbl9saXN0aW5mb19uZXRjb25mJmFtcDtkPUN3TUZhUSZhbXA7Yz1JTF9YcVFXT2p1YmdmcUlO
aTJqVHpnJmFtcDtyPUdCeUxlZzlqWnZPdl9BbGdCbzl1dmREcnhpemxPUjdsX1NuVFhvd3lKVTgm
YW1wO209NUR4R2MxOGlnTExhem93RUpScWZsTDJWemtDLUhWY1B4WHV6N2x0Z0dUZyZhbXA7cz1s
S1FNN0s2WWFOVC1reXVYc1BScWx1WjdsUFdrODRabGFzTm1IMjg4SXowJmFtcDtlPSIgdGFyZ2V0
PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImNvbG9yOiM4
ODg4ODgiPjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPi0tPC9zcGFuPjxicj4NCjxz
cGFuIGNsYXNzPSJob2VuemIiPkxhZGlzbGF2IExob3RrYSwgQ1ouTklDIExhYnM8L3NwYW4+PGJy
Pg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+UEdQIEtleSBJRDogRTc0RThDMEM8L3NwYW4+PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K
PC9odG1sPg0K

--_000_db811e7b4b2a4da9b445d66be869009eEMEAWPEXMB11corpbrocade_--


From nobody Tue Aug  2 07:09:26 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2A812D623 for ; Tue,  2 Aug 2016 07:09:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.287
X-Spam-Level: 
X-Spam-Status: No, score=-3.287 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=-1.287] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WoMC3pMD8Q8 for ; Tue,  2 Aug 2016 07:09:19 -0700 (PDT)
Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [IPv6:2001:718:1:1f:50:56ff:feee:34]) by ietfa.amsl.com (Postfix) with ESMTP id 6956F12D666 for ; Tue,  2 Aug 2016 07:09:14 -0700 (PDT)
Received: by kalendar.cesnet.cz (Postfix, from userid 999) id CDE056017B; Tue,  2 Aug 2016 16:09:12 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1470146952; bh=hoWpvnDxDws/4OMQ8VExRyGnrb9nLeUJRsFMwxKe71M=; h=to:date:subject:from; b=C0WFbsQJJYgyhgXQzNJS+Ldlp3sFpfY6atKKEaQ2jetVrYZbNqLhexMsuc9Gzme46 Ckm1tDQaJPdcQ0A089NrlRqXhlM2bzSZyIqVvZWxW9U7l7cAMgjpxgfKWiguw9qnXe 7CpO4g08yyzsT/4LrfH+D+Lrwk0G+A/IoYRWP2bs=
content-type: text/plain; charset="utf-8"
to: netconf@ietf.org
User-Agent: SOGoMail 2.3.13
MIME-Version: 1.0
date: Tue, 02 Aug 2016 16:09:12 +0200
message-id: <4bcf-57a0a980-25-18bcab00@35396507>
X-Forward: 2001:67c:1220:80c:c47c:d5c8:6d97:6cdf
from: =?utf-8?q?Michal_Va=C5=A1ko?= 
content-transfer-encoding: quoted-printable
Archived-At: 
Subject: [Netconf] ietf-system-keychain draft module
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 02 Aug 2016 14:09:25 -0000

Hi,
I started implementing this module and I encountered some problems. I w=
ould like to know how you are planning to solve them, if they are known=
 and being worked on, or inform you about them.

Regarding the list /keychain/private-keys/private-key, it is configurab=
le. My guess is that the reason for this is being able to add certifica=
te-chains to configured private keys. However, this enables the creatio=
n of instances of this list, which seems to me does not make sense and =
should be forbidden (or what is expected to happen in that case?). For =
creating new instances there are the actions generate-private-key and l=
oad-private-key, am I missing something?

As for private keys themselves, the idea probably is to keep them inter=
nally safe somewhere, so they do not appear in configuration and thus a=
re not accidentally compromised. However, this causes major implementat=
ion issues (I know this is not considered an argument, but I believe it=
 should not be completely neglected). Why could not be private keys par=
t of the configuration with the NACM extension default-deny-all? My poi=
nt is that other applications (using this keychain) must simply somehow=
 get to the private key itself. Currently, the confidentiality of these=
 keys is ensured mainly by standard file system access control. Includi=
ng these keys in NETCONF datastore with default-deny-all is basically s=
imilar, but may even be considered safer than a file system. The keys c=
ould still be encrypted using a password and thus useless without it. N=
aturally, this password would not be part of the configuration.

Kind regards,
Michal Vasko


From nobody Tue Aug  2 07:29:17 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5784E12D757 for ; Tue,  2 Aug 2016 07:29:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.077
X-Spam-Level: 
X-Spam-Status: No, score=-3.077 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-1.287, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cesnet.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIj7O-ULvsEl for ; Tue,  2 Aug 2016 07:29:14 -0700 (PDT)
Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [IPv6:2001:718:1:1f:50:56ff:feee:34]) by ietfa.amsl.com (Postfix) with ESMTP id 4358312D666 for ; Tue,  2 Aug 2016 07:29:12 -0700 (PDT)
Received: by kalendar.cesnet.cz (Postfix, from userid 999) id 552426017B; Tue,  2 Aug 2016 16:29:12 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1470148152; bh=WGyxds22PrRTOHk39Df5xFq7GweMaJRFjGl6l+kyU4A=; h=to:date:subject:from; b=3TnOmPtACvAiyGHTFOoCgesnumEIDPtsCuvUbYRFO09dPP2Inw1ibDFo3ql9x1xZV X2lp+f2s5EVtKClcESqFIGQCyR2IX0xxvA/G/hYxCAu/ZeH0mIOiUumuuUg0gh5UIY 5dPWFmWC7Qm5UaK3PP4Ex/tVn4Is5cv11bEX//88=
content-type: text/plain; charset="utf-8"
to: netconf@ietf.org
User-Agent: SOGoMail 2.3.13
MIME-Version: 1.0
date: Tue, 02 Aug 2016 16:29:12 +0200
message-id: <7eb3-57a0ae00-9b-3e7ef100@122083013>
X-Forward: 2001:67c:1220:80c:c47c:d5c8:6d97:6cdf
from: =?utf-8?q?Michal_Va=C5=A1ko?= 
content-transfer-encoding: quoted-printable
Archived-At: 
Subject: [Netconf] ietf-netconf-server and ietf-ssh-server draft module
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 02 Aug 2016 14:29:16 -0000

Hi,
during first implementation steps of this module I noticed some issues,=
 which may or may not be relevant, but I would like to receive some fee=
dback.

Regarding the subtree /netconf-server/listen/endpoint/ssh, there is no =
configuration of known and accepted client SSH public keys during NETCO=
NF server SSH authentication. There is a list of trusted-ssh-host-keys =
in ietf-system-keychain module for NETCONF client verification of serve=
r keys, why not the other way around? In our NETCONF server we used a l=
ist of pairs of trusted client SSH keys with their username (sort-of li=
ke simplified cert-to-name on SSH keys instead certificates) and it wor=
ked well.

Next, I am unsure about the host-keys/host-key list (relative to the co=
ntainer from the previosu paragraph) meaning, In the description it say=
s that it is used for announcing the supported key algorithms. So these=
 keys are not used as SSH server host keys (whose digest is sent to SSH=
 clients)? If so, why is the configuration of these host keys missing?=


Lastly, I have noticed that in the list /netconf-server/listen/endpoint=
/ssh/host-keys/host-key, the name leaf is mandatory even though it is a=
 key, while the choice type is not and I believe it should be. Perhaps =
a misplaced mandatory?

Regards,
Michal Vasko


From nobody Tue Aug  2 07:44:09 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D59912D1DE for ; Tue,  2 Aug 2016 07:44:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.198
X-Spam-Level: 
X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A46IhgrNCkfo for ; Tue,  2 Aug 2016 07:44:03 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id AD49912D75F for ; Tue,  2 Aug 2016 07:43:54 -0700 (PDT)
Received: from syd-vpn-client-246-27.cisco.com (unknown [64.104.248.199]) by mail.tail-f.com (Postfix) with ESMTPSA id BCE721AE034E; Tue,  2 Aug 2016 16:43:48 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_07DF98DC-59DC-445E-A17F-F25F863B323F"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail
From: Jan Lindblad 
In-Reply-To: 
Date: Tue, 2 Aug 2016 16:43:26 +0200
Message-Id: 
References:  <87vazljnps.fsf@hobgoblin.ariadne.com>    <13a7626442c34f499392b67bcf29ea53@EMEAWP-EXMB11.corp.brocade.com>  <78c52bbab4d44b938e1dcf191d95b42a@EMEAWP-EXMB11.corp.brocade.com>  
To: William Ivory 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 02 Aug 2016 14:44:07 -0000

--Apple-Mail=_07DF98DC-59DC-445E-A17F-F25F863B323F
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_C98CF51C-FC08-4B71-9B5F-1D5BAE27FF46"


--Apple-Mail=_C98CF51C-FC08-4B71-9B5F-1D5BAE27FF46
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> So if I were to implement the decision on whether to evaluate musts on =
NP containers that have no children using random(), that would meet the =
spec? (-:

Not at all. I hate to repeat myself, but this is a long thread, so here =
is a summary again:

The YANG 1.0 spec introduces the presence statement and explains how NP =
containers differ from P containers. Among other things, it's noted that =
NP containers have no information content and no meaning in themselves. =
Their "existence" is therefore meaningless and their zero bits of =
information implies no such state can be remembered by a compliant =
server. I.e. they always exist, even if they MAY be "deleted" from the =
output when empty since they are meaningless. YANG 1.1 makes this a bit =
clearer, but doesn't change anything functionally IMO.

If NP containers could be "created" and "deleted", what benefit would =
that bring? If they could, what would be the purpose with the presence =
statement? Why any distinction between P and NP containers at all? I =
have asked these questions on this list several times in different words =
over the last weeks, and so far zero answers. Could someone who defends =
the position that NP containers can meaningfully be created and deleted =
comment on this? IMO, the lack of answers makes it increasingly =
difficult to take this stance seriously.

> =46rom the perspective of writing our YANG 1.0 models, we can add =
=E2=80=98not current() or =E2=80=A6=E2=80=99 on the front of any must =
statement on a NP container if we only want it to be evaluated when the =
NP container has child node(s).  That at least relaxes restrictions (so =
meets RFC 6020 section 10 backwards-compatibility requirements) and =
reduces the number of NP containers where evaluation of must statements =
would appear to be implementation-specific for YANG 1.0.

YANG 1.1 implies no functional change, so there is no need to update any =
models. I understand (and have preached this for many years in YANG =
trainings, as many readers of this list might testify) that =
clarifications always have an element of backwards incompatibility, as =
anyone who understood the original unclear statement differently after =
the clarification will see a change...

Even if "not current() or " is prepended to must expressions, that would =
have no effect at all. The expression would only be evaluated for nodes =
that do exist, so bool(current()) is always true for any node that has =
its must expressions evaluated.

> =46rom Jan=E2=80=99s perspective I can see that not evaluating must =
statements on NP containers with no child nodes would invalidate his =
YANG model,

I certainly have many examples of this in my world, but this model was =
taken from the IETF YANG repo. Zerotouch, to be exact.

Beside my point that seasoned IETF modelers that have nothing to do with =
me or our tools leverage this understanding of NP containers, it also =
highlights the utility of the NP container concept as I interpret it. =
YANG would clearly lose something if we made NP containers behave the =
same as P containers.

> but equally any NP container with the likes of =E2=80=98must =
=E2=80=9Cnot(../foo)=E2=80=9D;=E2=80=99 would make configuration of =
=E2=80=98foo=E2=80=99 impossible if we take the 1.1 clarification and =
apply it to 1.0.

I reiterate that there is no change, just a clarification in YANG 1.1.

> Unless there is existing clear guidance that the latter form of must =
statement should (must?) be avoided, then I don=E2=80=99t see any =
overpowering argument in either direction.

There is no such guidance, and there shouldn't be. This is a useful way =
to express validity of configurations in YANG. I find the zerotouch =
example elegant and simple to understand. The YANG modile would only get =
less readable if we tried to add some rules/CLRs to forbid certain must =
statement constructs, not to mention the YANG spec itself.

>   It comes down perhaps to whether we prefer to allow some =
configurations that weren=E2=80=99t intended to be allowed (not =
evaluating musts that were intended to be evaluated) or we potentially =
block valid configurations (evaluating musts that weren=E2=80=99t =
intended to always be evaluated).

Is this a real problem? Do we have a lot of models that depend on the =
(mis)understanding of how must statements on NP containers are =
evaluated?

> =46rom a pragmatic perspective, the Postel principle of being liberal =
in what you accept (at least in YANG) would seem more flexible in that =
once config is rejected, there=E2=80=99s no alternative, whereas you can =
always advise that configuration is accepted but =E2=80=98unwise=E2=80=99.=


I simply cannot imagine that leaving open whether must statements are to =
be evaluated or not could bring this WG closer to any of its goals. We =
should be working towards precision and utility.

/jan


>=20
> From: Jan Lindblad [mailto:janl@tail-f.com]
> Sent: 02 August 2016 13:13
> To: William Ivory ; Andy Bierman =

> Cc: Ladislav Lhotka ; Netconf 
> Subject: Re: [Netconf] What should a server response be? - depending =
on NP-containers
>=20
> Those of us who believe the presence statement in YANG 1.0 specifies =
some behavioral difference between P and NP containers tend to think of =
the YANG 1.1 specification edits below as clarifications rather than =
functional changes.
>=20
> This should come as no surprise to anyone who has had the strength to =
follow the full length of the thread, but since my opinion was =
requested, I thought I'd clarify anyway.
>=20
> As SDO our main goal should be to get clear specs describing useful =
functionality. NP containers, as defined in YANG 1.1 and (less clearly) =
in YANG 1.0 are very useful IMO. I would prefer to describe NP =
containers as always existing if the parent exists, but may be =
suppressed in get-config when empty. I proposed some specific language =
earlier. I find this more natural than language around spontaneous =
creation and deletion by the server, even if the net result may be the =
same. The voucher example is indeed YANG 1.0.
>=20
> /jan
>=20
> On 1 aug. 2016, at 17:10, William Ivory > wrote:
>=20
> Hi Andy,
>=20
> Thanks =E2=80=93 in isolation that is clear, but I would be interested =
in Jan=E2=80=99s thoughts given that the given ownership-voucher example =
would appear to be YANG 1.0 *and* assume must statements are evaluated =
on non-presence containers if the parent node exists.
>=20
> Regards,
>=20
> William
>=20
> From: Andy Bierman [mailto:andy@yumaworks.com =
]
> Sent: 01 August 2016 16:03
> To: William Ivory >
> Cc: Ladislav Lhotka >; =
janl@tail-f.com ; Netconf >
> Subject: Re: [Netconf] What should a server response be? - depending =
on NP-containers
>=20
> Hi,
>=20
> I think I made that comment.
> In YANG 1.0, only default leafs were considered always present.
> In YANG 1.1 NP containers were added to the set of accessible nodes
>=20
> In YANG 1.0, sec. 7.5.3
>=20
>    o  The accessible tree is made up of all nodes in the data tree, =
and
>       all leafs with default values in use (see Section 7.6.1).
>=20
> This was changed in YANG 1.1
>=20
> sec 7.5.3:
>=20
>=20
>    When a datastore is validated, all "must" constraints are
>    conceptually evaluated once for each node in the accessible tree =
(see
>    Section 6.4.1).
> Sec. 6.4.1
>=20
>       If a node that exists in the accessible tree has a non-presence
>       container as a child, then the non-presence container also =
exists in
>       the tree.
>=20
>=20
> Andy
>=20
>=20
>=20
>=20
> On Mon, Aug 1, 2016 at 7:51 AM, William Ivory > wrote:
> Hi,
>=20
> Could someone confirm then that must statements on a non-presence =
container in YANG 1.0 are only to be evaluated if the non-presence =
container has configured children =E2=80=A6 or is it also if (reading =
Lada=E2=80=99s mail) the implementation chooses to implement them when =
there are no children present?
>=20
> I had assumed that the text in YANG 1.1 was clarifying YANG 1.0 rather =
than new functionality here but I=E2=80=99m a little confused now, =
especially given the comment by Jan Lindblad regarding this YANG snippet =
as the file does not contain =E2=80=98yang-version 1.1=E2=80=99 and =
would surely therefore be version 1.0?
>=20
>       container ownership-voucher {
>         description
>           "This container contains the Ownership Voucher that the
>            device uses to ascertain the identity of its rightful
>            owner, as certified by its Vendor.";
>=20
>         when "../redirect-information/signature or =
../bootstrap-information/*/signature";
>         must "../owner-certificate";
>=20
>         uses ownership-voucher-grouping;
>       }
>=20
>=20
> =
https://github.com/YangModels/yang/blob/master/standard/ietf/DRAFT/ietf-ze=
rotouch-bootstrap-server.yang =

>=20
> Jan=E2=80=99s comment on this YANG (assuming it=E2=80=99s 1.0) and =
Lada=E2=80=99s assertion (pasted below) appear contradictory to me.
>=20
> =E2=80=98NP containers were not always present in YANG 1.0.
> The must-stmt only applied if they actually are present,
> which is an implementation choice.
> =E2=80=98
>=20
> I=E2=80=99m also thinking that any must statement on a non-presence =
container in YANG 1.0 models might sensibly be (re)written as =
=E2=80=98not(current() or =E2=80=99 to make =
it future-proof if these nodes do not exist in 1.0 w/o children but do =
in YANG 1.1.  That would allow for easier model migration.
>=20
> Regards,
>=20
> William
>=20
> From: Netconf [mailto:netconf-bounces@ietf.org =
] On Behalf Of Andy Bierman
> Sent: 01 August 2016 15:23
> To: Ladislav Lhotka >
> Cc: Netconf >
> Subject: Re: [Netconf] What should a server response be? - depending =
on NP-containers
>=20
>=20
>=20
> On Mon, Aug 1, 2016 at 7:13 AM, Ladislav Lhotka > wrote:
> Andy Bierman > writes:
>=20
> > Hi,
> >
> > YANG 1.1 has been changed so the XPath is not really =
backward-compatible
> > with YANG 1.0.  In YANG 1.1 NP-containers always exist if the non-NP =
parent
> > is
> > instantiated.
>=20
> My mental model regarding NP-containers is that they are part of
> the default contents of a datastore. If an NP-container is "in use"
> (according to the same rules as specified in sec. 7.6.1 of 6020bis for
> default leaves), then
>=20
> - creating a child of this container succeeds,
>=20
> - "must" expressions defined on this container apply.
>=20
>=20
>=20
> NP containers were not always present in YANG 1.0.
> The must-stmt only applied if they actually are present,
> which is an implementation choice.
>=20
> I don't understand all this special wording about "do not error if..."
>=20
> NETCONF has explicit support for this exact use-case, called "merge".
> This was done precisely to support these "don't error if..." cases.
> So use "merge" if you want this functionality.
>=20
>=20
> Lada
>=20
> Andy
>=20
>=20
> >
> > NETCONF and RESTCONF do not say anything about the server ignoring
> > the rules for operation=3D"create", operation=3D"delete" and
> > default-operation=3D"none".
> > IMO itr would be a really bad idea to continue spreading little =
protocol
> > details
> > in the YANG RFC.  People might read the protocol spec and =
(correctly) assume
> > that the protocol does not trat NP containers special at all.
> >
> > If anything, the sentence about MAY delete needs to be removed =
because
> > it is inconsistent with the XPath (always exists).
> >
> >
> > Andy
> >
> >
> > On Sun, Jul 31, 2016 at 6:13 PM, Dale R. Worley > wrote:
> >
> >> Mahesh Jethanandani > writes:
> >> > I think this argument of whether server should or should not
> >> > create/delete NP containers is distracting from the main point of =
when
> >> > NP containers should exist. In my mind, the NP container =
existence
> >> > depends on whether child nodes exist or not. In the end, if child
> >> > nodes exist, NP containers should exist (created), if they do not
> >> > exist, the NP container should be removed.
> >> >
> >> > Can we agree on that?
> >>
> >> If the concept of a "non-presence container" makes any sense, then =
the
> >> existence of an empty container must have exactly the same =
significance
> >> as the non-extence of the container.
> >>
> >> Given that, we have to make sure the protocol is consistent with =
that
> >> principle.  E.g., if you ask to create an element of a non-existing =
NP
> >> container, it must succeed, because asking to create an element of =
an
> >> existing but empty NP container succeeds.
> >>
> >> I don't see what all the consequences of this principle are, but if =
we
> >> can't make the protocol consistent with it, then we can't properly
> >> implement the concept of NP containers.
> >>
> >> Dale
> >>
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org 
> > https://www.ietf.org/mailman/listinfo/netconf =

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


--Apple-Mail=_C98CF51C-FC08-4B71-9B5F-1D5BAE27FF46
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


So if I were to implement the decision on =
whether to evaluate musts on NP containers that have no children using =
random(), that would meet the spec? =
(-:

Not at all. I hate to repeat myself, but this is a =
long thread, so here is a summary again:

The YANG 1.0 spec introduces the presence =
statement and explains how NP containers differ from P containers. Among =
other things, it's noted that NP containers have no information content =
and no meaning in themselves. Their "existence" is therefore meaningless =
and their zero bits of information implies no such state can be =
remembered by a compliant server. I.e. they always exist, even if they =
MAY be "deleted" from the output when empty since they are meaningless. =
YANG 1.1 makes this a bit clearer, but doesn't change anything =
functionally IMO.

If NP containers =
could be "created" and "deleted", what benefit would that bring? If they =
could, what would be the purpose with the presence statement? Why any =
distinction between P and NP containers at all? I have asked these =
questions on this list several times in different words over the last =
weeks, and so far zero answers. Could someone who defends the position =
that NP containers can meaningfully be created and deleted comment on =
this? IMO, the lack of answers makes it increasingly difficult to take =
this stance seriously.

=46rom the perspective of writing our YANG 1.0 models, we can =
add =E2=80=98not current() or =E2=80=A6=E2=80=99 on the front of any =
must statement on a NP container if we only want it to be evaluated when =
the NP container has child node(s).  That at least relaxes =
restrictions (so meets RFC 6020 section 10 backwards-compatibility =
requirements) and reduces the number of NP containers where evaluation =
of must statements would appear to be implementation-specific for YANG =
1.0.

YANG =
1.1 implies no functional change, so there is no need to update any =
models. I understand (and have preached this for many years in YANG =
trainings, as many readers of this list might testify) that =
clarifications always have an element of backwards incompatibility, as =
anyone who understood the original unclear statement differently after =
the clarification will see a change...

Even if "not current() or " is prepended to must =
expressions, that would have no effect at all. The expression would only =
be evaluated for nodes that do exist, so bool(current()) is always true =
for any node that has its must expressions evaluated.
 
=46rom Jan=E2=80=99s perspective I can see =
that not evaluating must statements on NP containers with no child nodes =
would invalidate his YANG model,

I certainly have many examples of this in my =
world, but this model was taken from the IETF YANG repo. Zerotouch, to =
be exact.

Beside my point that =
seasoned IETF modelers that have nothing to do with me or our tools =
leverage this understanding of NP containers, it also highlights the =
utility of the NP container concept as I interpret it. YANG would =
clearly lose something if we made NP containers behave the same as P =
containers.

 but equally any NP container with the =
likes of =E2=80=98must =E2=80=9Cnot(../foo)=E2=80=9D;=E2=80=99 would =
make configuration of =E2=80=98foo=E2=80=99 impossible if we take the =
1.1 clarification and apply it to =
1.0. 

I=
 reiterate that there is no change, just a clarification in YANG =
1.1.

 Unless there is existing clear guidance =
that the latter form of must statement should (must?) be avoided, then I =
don=E2=80=99t see any overpowering argument in either =
direction.

There is no such guidance, and there shouldn't be. =
This is a useful way to express validity of configurations in YANG. I =
find the zerotouch example elegant and simple to understand. The YANG =
modile would only get less readable if we tried to add some rules/CLRs =
to forbid certain must statement constructs, not to mention the YANG =
spec itself.

  It comes down perhaps to whether we =
prefer to allow some configurations that weren=E2=80=99t intended to be =
allowed (not evaluating musts that were intended to be evaluated) or we =
potentially block valid configurations (evaluating musts that weren=E2=80=99=
t intended to always be =
evaluated).

Is this a real problem? Do we have a lot of models =
that depend on the (mis)understanding of how must statements on NP =
containers are evaluated?

=46rom a pragmatic perspective, the Postel principle of being =
liberal in what you accept (at least in YANG) would seem more flexible =
in that once config is rejected, there=E2=80=99s no alternative, whereas =
you can always advise that configuration is accepted but =
=E2=80=98unwise=E2=80=99.

I simply cannot imagine that leaving open whether =
must statements are to be evaluated or not could bring this WG closer to =
any of its goals. We should be working towards precision and =
utility.

/jan


 
From: Jan Lindblad [mailto:janl@tail-f.com] 
Sent: 02 =
August 2016 13:13
To: William Ivory <wivory@Brocade.com>; =
Andy Bierman <andy@yumaworks.com>
Cc: Ladislav Lhotka <lhotka@nic.cz>; Netconf =
<netconf@ietf.org>
Subject: Re: [Netconf] What should a =
server response be? - depending on NP-containers
 
Those of us who believe the presence statement in YANG 1.0 =
specifies some behavioral difference between P and NP containers tend to =
think of the YANG 1.1 specification edits below as clarifications rather =
than functional changes. 
 
This should come as no surprise to anyone who has had =
the strength to follow the full length of the thread, but since my =
opinion was requested, I thought I'd clarify anyway.
 
As SDO our main goal should be to get =
clear specs describing useful functionality. NP containers, as defined =
in YANG 1.1 and (less clearly) in YANG 1.0 are very useful IMO. I would =
prefer to describe NP containers as always existing if the parent =
exists, but may be suppressed in get-config when empty. I proposed some =
specific language earlier. I find this more natural than language around =
spontaneous creation and deletion by the server, even if the net result =
may be the same. The voucher example is indeed YANG 1.0.
 
/jan
 
On 1 aug. 2016, at =
17:10, William Ivory <wivory@Brocade.com> wrote:
 
Hi =
Andy,
 
Thanks =E2=80=93 in isolation that is =
clear, but I would be interested in Jan=E2=80=99s thoughts given that =
the given ownership-voucher example would appear to be YANG 1.0 *and* assume must statements are evaluated on non-presence =
containers if the parent node exists.
 
Regards,
 
William
 
From: Andy Bierman [mailto:andy@yumaworks.com] 
Sent: 01 =
August 2016 16:03
To: William Ivory <wivory@Brocade.com>
Cc: Ladislav Lhotka <lhotka@nic.cz>; janl@tail-f.com; Netconf <netconf@ietf.org>
Subject: Re: [Netconf] What should a =
server response be? - depending on NP-containers
 
Hi,
 
I think I made that comment.
In YANG 1.0, only default leafs were =
considered always present.
In =
YANG 1.1 NP containers were added to the set of accessible nodes
 
In YANG 1.0, sec. 7.5.3
 
   o  The accessible =
tree is made up of all nodes in the data tree, and
      all leafs with default values =
in use (see Section 7.6.1).
 
This was changed in =
YANG 1.1
 
sec 7.5.3:

   When a datastore is validated, all "must" =
constraints are
   conceptually evaluated once for each node in the =
accessible tree (see
   Section 6.4.1).
Sec. 6.4.1
 
      =
If a node that exists in the accessible tree has a non-presence
      container as a =
child, then the non-presence container also exists in
      the tree.
 
 
Andy
 
 
 
 
On Mon, Aug 1, 2016 at 7:51 AM, William =
Ivory <wivory@brocade.com> =
wrote:
Hi,
 
Could someone confirm =
then that must statements on a non-presence container in YANG 1.0 are =
only to be evaluated if the non-presence container has configured =
children =E2=80=A6 or is it also if (reading Lada=E2=80=99s mail) the =
implementation chooses to implement them when there are no children =
present?
 
I had assumed that the text in YANG 1.1 =
was clarifying YANG 1.0 rather than new functionality here but I=E2=80=99m=
 a little confused now, especially given the comment by Jan Lindblad =
regarding this YANG snippet as the file does not contain =E2=80=98yang-ver=
sion 1.1=E2=80=99 and would surely therefore be version 1.0?
 
      container ownership-voucher {
        description
          "This container =
contains the Ownership Voucher that the
    =
       device uses to ascertain the identity of its =
rightful
           owner, =
as certified by its Vendor.";

    =
    when "../redirect-information/signature or =
../bootstrap-information/*/signature";
    =
    must "../owner-certificate";

        uses =
ownership-voucher-grouping;
      =
}
 
 
 
Jan=E2=80=99s comment =
on this YANG (assuming it=E2=80=99s 1.0) and Lada=E2=80=99s assertion =
(pasted below) appear contradictory to me.
 
=E2=80=98NP =
containers were not always present in YANG 1.0.
The must-stmt only applied if they actually are present,
which is an implementation choice.
=E2=80=98
 
I=E2=80=99m also =
thinking that any must statement on a non-presence container in YANG 1.0 =
models might sensibly be (re)written as =E2=80=98not(current() or =
<required_xpath_expression>=E2=80=99 to make it future-proof if =
these nodes do not exist in 1.0 w/o children but do in YANG 1.1.  =
That would allow for easier model migration.
 
Regards,
 
William
 
From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf =
Of Andy Bierman
Sent: 01 August 2016 15:23
To: Ladislav Lhotka <lhotka@nic.cz>
Cc: Netconf <netconf@ietf.org>
Subject: Re: [Netconf] What should a =
server response be? - depending on NP-containers
 
 
 
On Mon, Aug 1, 2016 at 7:13 AM, Ladislav =
Lhotka <lhotka@nic.cz> =
wrote:
Andy Bierman =
<andy@yumaworks.com> =
writes:

> Hi,
>
> YANG 1.1 has been changed so the XPath is not really =
backward-compatible
> with YANG 1.0.  In YANG 1.1 =
NP-containers always exist if the non-NP parent
> is
> instantiated.

My mental =
model regarding NP-containers is that they are part of
the =
default contents of a datastore. If an NP-container is "in use"
(according to the same rules as specified in sec. 7.6.1 of =
6020bis for
default leaves), then

- creating a child of this container succeeds,

- "must" expressions defined on this container =
apply.
 
 
NP containers were not always present in =
YANG 1.0.
The must-stmt only =
applied if they actually are present,
which is an implementation choice.
 
I don't understand all this special =
wording about "do not error if..."
 
NETCONF has explicit support for this =
exact use-case, called "merge".
This was done precisely to support these =
"don't error if..." cases.
So =
use "merge" if you want this functionality. 
 
 
Lada
 
Andy
 

>
> NETCONF and RESTCONF =
do not say anything about the server ignoring
> the =
rules for operation=3D"create", operation=3D"delete" and
> default-operation=3D"none".
> IMO itr =
would be a really bad idea to continue spreading little protocol
> details
> in the YANG RFC.  People =
might read the protocol spec and (correctly) assume
> =
that the protocol does not trat NP containers special at all.
>
> If anything, the sentence about MAY =
delete needs to be removed because
> it is inconsistent =
with the XPath (always exists).
>
>
> Andy
>
>
> On Sun, Jul 31, 2016 at 6:13 PM, Dale R. Worley <worley@ariadne.com> wrote:
>
>> Mahesh Jethanandani <mjethanandani@gmail.com> writes:
>> > I think this argument of whether server should =
or should not
>> > create/delete NP containers is =
distracting from the main point of when
>> > NP =
containers should exist. In my mind, the NP container existence
>> > depends on whether child nodes exist or not. In =
the end, if child
>> > nodes exist, NP containers =
should exist (created), if they do not
>> > =
exist, the NP container should be removed.
>> =
>
>> > Can we agree on that?
>>
>> If the concept of a =
"non-presence container" makes any sense, then the
>> =
existence of an empty container must have exactly the same =
significance
>> as the non-extence of the =
container.
>>
>> Given that, we =
have to make sure the protocol is consistent with that
>> principle.  E.g., if you ask to create an =
element of a non-existing NP
>> container, it must =
succeed, because asking to create an element of an
>> =
existing but empty NP container succeeds.
>>
>> I don't see what all the consequences of this =
principle are, but if we
>> can't make the protocol =
consistent with it, then we can't properly
>> =
implement the concept of NP containers.
>>
>> Dale
>>
> =
_______________________________________________
> =
Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

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

=

--Apple-Mail=_C98CF51C-FC08-4B71-9B5F-1D5BAE27FF46--

--Apple-Mail=_07DF98DC-59DC-445E-A17F-F25F863B323F
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJXoLGOAAoJEBSCnbqufIisitQIAIs0IDY8zyUWwPZFOlSJgL0u
Gp9nAd0pa5UOwyHTsUpMq4R4NevNweL63jfWYnNzIdKRlMpXyTZzH5aPn/hYl0Un
U3pEGMRTHyXVXlwBnZun6xC0956Gxc1YP9rbVNRv5teNCwHXSBJKwFrJ0nrmUYtc
b0mvjjWO0+ejMQQayWz8GWgg4E7CNBLeB79dvksAKGTWLCSqIODiAIfEKe9bhFEk
tMKA2j5DONWQnk+ZfUAKg8YVVqY1FDISTi5vLCqp4JZNqKTueaOiEb44dqPXJLyV
QWTxVSnWqOb0IwuRip0v/gPq+xjJ/ehJEnjQxEmqcv21wiT6zJaXAwI2fWT39Bo=
=PzJ2
-----END PGP SIGNATURE-----

--Apple-Mail=_07DF98DC-59DC-445E-A17F-F25F863B323F--


From nobody Tue Aug  2 09:25:55 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8191712D108 for ; Tue,  2 Aug 2016 09:25:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytCijACPg3Wd for ; Tue,  2 Aug 2016 09:25:49 -0700 (PDT)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50107.outbound.protection.outlook.com [40.107.5.107]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69BF812D158 for ; Tue,  2 Aug 2016 09:25:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TeRUnFfRcqQTeFhMcRbxKKkPm+QT7pC8kIGMMr+poHs=; b=eVoeGj3cT8uED0zKxwwVAfaoplwZjVE7rRhrEM+o+0d2hNiKvUX/OHdxf3jNgtUgLuOEFb5Jxhh2aRwmgUcVGa3SVCUlRcw7qq7c70MAIW0Jocf7eNCriZ22s6awXdJ8dn+pin0g/93Qg3OMuBVbGE//wUWKfvL2CaTH+02Rpfw=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (31.50.86.164) by DB5PR07MB1622.eurprd07.prod.outlook.com (10.166.12.149) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.549.15; Tue, 2 Aug 2016 16:25:44 +0000
Message-ID: <00a901d1ecda$27dee600$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Jan Lindblad , William Ivory 
References:  <87vazljnps.fsf@hobgoblin.ariadne.com>    <13a7626442c34f499392b67bcf29ea53@EMEAWP-EXMB11.corp.brocade.com>  <78c52bbab4d44b938e1dcf191d95b42a@EMEAWP-EXMB11.corp.brocade.com>   
Date: Tue, 2 Aug 2016 17:20:39 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
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: [31.50.86.164]
X-ClientProxiedBy: HE1PR0401CA0029.eurprd04.prod.outlook.com (10.166.116.167) To DB5PR07MB1622.eurprd07.prod.outlook.com (10.166.12.149)
X-MS-Office365-Filtering-Correlation-Id: 9c47608c-2526-4131-8106-08d3baf1a769
X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 2:OwVNVC8BWU0i21ZmscsjVJzxjvjOHYv9dvwPoynfdPq6iJAJJLBZWRK8uEygQ+y2o+ww+kgBaIRqy47HLdAlEdZFg+cWXnVHfGu8cuWXrW+Bl14Jr5m30KgdDo646o6mDdtTBBzOlROFlPd+fwA9p+pEMnX98t7uXbBgPHf7oKHK8NeN3g7a5cHzP8jjW56g; 3:lRl2GzVaSKu6z2p7XXVRkIpO19jdPetX/guEg9d0vJd7KPSY3GqiDUJLrVbNUHuv9oBru/F87Pm27Kz1StR6CTnu+dch6WKonTxUhl9jH0gczGe0YEvcAz3DYcpNdZGY; 25:hlOAOvOJv7uU3gqPrvbqSlO7PhADfo9MyE5tFPeaulC0wGIIck9AzEwAy7icQHZZcWRng6g1xZVuMv3GuQZJjV92685KEMoW3sYVvvClublpdGQb9eeL+WL9rkLm07k9X8ZmGM/3yyj6kq8FzblPg5ZXVRHyKUcR3/xXNlUHbiJeu+s40B2IGndOV+Msn1h05OQgobJxol83Hb9C40pKGHRn1cT9a8wKNSAGBTDicrkDslpZLfkX5ko8u9iNE66ams6CVdCl+Mtx4FgxRKOYew+ChrIMGASlgDTM1xajtcM6g5JGvabs9nHEupMDwQdZ/GrRioQWAgwv/vkFbGblKxJPm7RvV2/XX5qGoYQRsSX3SVQPZefgf7QtdH/qykteVeW2P0bpU6/xU+/2kjEE4pAKbEJQS7JtQ85wK0D/PM4=
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR07MB1622;
X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 31:HP/kIQgwug63xwMzr0BjWFfo0QJhfz5gqhicHHA8iHhC8JakOGrD61DuYiFL8W7uWKITaMtizxOwfvTmnzC3k+n3OaQeEYi+i62UXbxd/5CvcCVKupTlrIVTq8KXZJHqJ7dokgpEd0SLqCeavI4Qwfbyw5hbHXmqy19JotkKxBIXD5j9h80vIqQssjYkB+omL6PCBaXIeGt2fBAtiHwOxtkeXbEgToofiS/KDWSsJOY=; 4:TcAsdLbYmrMEeExJg2tqrMWgFfu+YZxj7akAAYP91KunGiTpwHieEDUu+Wxq85KK+RWPXiy3D010DAgeFf5gOs1rs+PyaOWnPV8pE64ITObfSdmxHjd/em2za8Izg3GvG7WRjPNeUkNiKoDtKgCm8JUffZZUDI8b7gGZMEokNRchQBqieiNkfiLlSMN0XKeqnbSpZPGiynsuWm7cJlDZVGU3W6x5Z5Lnl/MmiGzOJW2syMovjEoy1S9MdyXt92rKLo/32PuUq7L8y7A2m8xTPcYeqWV09ZTvZdNKuNj9HBNs4fhutXyJ0XW8Aurlyu/mz2rRjBwV3k3GiYx9PnTCZf6OySRr1+20Fsxdzki2f2xVxS4FSSLpV+Jsi9LQFPNjPsP1uMU0doBph8X7KPrQbwkywZQ7IX+iI1Us1Zh8S4JEtxLacCUvUMdW9wjAvdA+hc3FgHAsRCgjwbk6OiY3JUhTJpXN+zViV0a+sOBUphWJK/9w32b1rk4mCsOt0URAQorYlMbX89ymqYbQkHUmKhbkGwWsRcJe4GWfGdiesKB9ZdFwfXS0N18bzXDwn0JprO2O5o4jYeU1ubFhWo1xEQ==
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(60795455431006)(158342451672863)(10436049006162)(166708455590820)(131327999870524)(100405760836317);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:DB5PR07MB1622; BCL:0; PCL:0; RULEID:; SRVR:DB5PR07MB1622; 
X-Forefront-PRVS: 0022134A87
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(24454002)(13464003)(199003)(377454003)(189002)(97736004)(81686999)(23676002)(8676002)(101416001)(47776003)(92566002)(42186005)(3846002)(189998001)(6116002)(81156014)(4326007)(76176999)(81816999)(81166006)(50466002)(2870700001)(305945005)(5001770100001)(84392002)(62236002)(44716002)(44736004)(93886004)(586003)(1556002)(116806002)(14496001)(2906002)(7736002)(15975445007)(50226002)(9686002)(33646002)(86362001)(77096005)(68736007)(575784001)(1456003)(106356001)(50986999)(19580405001)(19580395003)(61296003)(7846002)(66066001)(105586002)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1622; 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: =?utf-8?B?MTtEQjVQUjA3TUIxNjIyOzIzOmwvVlR4SHJuTCthYmNJQWFHZlVjQ3N3UFZB?= =?utf-8?B?dGJ4L1hvNHNxcEdxOGIzV3QzVUp1ZkQxZWZHOGMxNkZpM0xvK3pCNUo2bUNy?= =?utf-8?B?WVVVVk1mSmc2eXRNcEdDYzBlanZtVW1zZFlnZHVYOCtOOFJmdE1TbXYyUUFX?= =?utf-8?B?NkcxTkhmWVhkckxBREYwTHRVcXlhc0luR1ZydFZYaEpQZHpIbjVMeUU5b2da?= =?utf-8?B?ZHNaN2dybjBqMGZLcDh1MTVrOUNVQWtFVUxxYnZDQzBBYUlzeS9BQ3RTS29H?= =?utf-8?B?QnRDVmhRcXJZOWt3NkplaXJFN1RiTDZvVTl0Y3VNTkNrR2JaUGh0MHFqbmhv?= =?utf-8?B?RlA3VEphcFloZ1JCeFRZNUpRSGpqQy9udkFteGpnMWU2NkoxanEvN1h2UERS?= =?utf-8?B?TkJ1eXc4c05ScXlqVVVBOEF5M0ltOUcyQkQ0SnIzMXo1U213RytaYWgwdnpq?= =?utf-8?B?MkRHWVhmR2drdEw0RGxLaDdUYkxVSGJzWDRWR21ydXVOVkJUQmM1N2VTVTM2?= =?utf-8?B?eGdmeitnSjRTL0M4WG1Fd0J4UHJYUVBQT3JCb3FzVk1QVzEwS0haM0ZnZDc5?= =?utf-8?B?RC9SS2lQWDJ2V0t0YU1ScGlkUEF5SUtzNXVOc0lnMnhIRTlBM0t0YUR6N1hH?= =?utf-8?B?VWJIT0o4QnpFZ29KeUhwa0o4SlQzMG9HQzdGejBBZDZvL0lKdHB0OGdDN2cx?= =?utf-8?B?Nm5rWDJRdVJmZmlTYXFrL2xONWJpU2tWNFpIdUI2K3BnQzhSM01idnR4VmQ3?= =?utf-8?B?WE9WQXEyOHlnM1MvbTk5aTVwek1CdWR1RlRkVlBlcm5QOS8zU2I1YkNxV1V3?= =?utf-8?B?VkpUNFNWMXNhbnowNnN3SDdTcWxHd0cya1dsRVR2TG9xK0pXRGpCclFlT2NJ?= =?utf-8?B?WEtoZFNCMHMxMW9Kdy9acmQvUHp4MkxRR1YxOFpyU3JDMi9OWWlCZXltN253?= =?utf-8?B?dXRVSHN6UFE0YWlVMTUxWFIyYjBZV2p5SkF0RFFxSkR4MER6OXNDcWpqeVZn?= =?utf-8?B?ZmNNWHorM2hrN05TRUVMaHFXbG5VSXk5YVExOXl6ck9IMnVjKzZaK0dOeTN4?= =?utf-8?B?bDlaMXRPQzk4cVovdHhyQWc2Vkd3Ri94anpmMVVMd01GdWxVTnMzSkF4YTNv?= =?utf-8?B?ck9sUHRiMXdMUnJOVlI0UERFL2ZuZTd4NU5YMFllMFFrSmFQT1FYTVJDakM2?= =?utf-8?B?VkluWUpSRkxETExUYStIL1k0RGxlVURrSEhhbGRvUWN5REVOSjg5WlE0RFBK?= =?utf-8?B?T1dKR1RWZEM1NVlXbU9RcGRVMmZneDNQRWJyWGo1RUNIOHB2MGNzUzMxbzJ4?= =?utf-8?B?RC9jZzJ2TEp3SUlnVVhUWW1HVzhyQUpNZHZnYTZwREpOZkwwUjdPb0RmYkRG?= =?utf-8?B?OEliZUl2VkNqT1NNS3BoU0F5a0VJZmFSdTlrTTlGMGNNNGpFTldOckR4N21q?= =?utf-8?B?VktGZ2t1Z3Y5RlNYUktVVVdUamNVdDVsMlBxd1Q3WHFST2lkM2ZIYmJlQ29m?= =?utf-8?B?NjA0TFdTWEJvZXZKdVZ1T05mSXNGR1gwelFxWDM1N3J3QmE2QUwrWlZiSWRD?= =?utf-8?B?c1p2VjdsUmxjUHoxb2lJMlhGSlVzMlhNWG0yWmtCNkV5OTRjNUNNTFVlRDFM?= =?utf-8?B?NjlseGdyZnRUQ3BQUzJuTWY0a3pGTFhQTkJRU1l0cXdDK1V5eERJVktNZTJR?= =?utf-8?B?NUxaZzN5eGR0U2J5ckROQXNBVWxQZzRpdlo0NmkwbHZqS1RFcHg0KzN1Tk9u?= =?utf-8?B?SS9icGRuZ2JMQlBCUVQ2c2hxWGJ5cDg2dTZ6S0NLbTdDK2NkaWNMWE9ucGJE?= =?utf-8?B?bjdTNDRhLzM3bm1UbExUUzZWZFo0Mm9UNnBEUnZHWkF5Z25ubmhPUUZOck1G?= =?utf-8?B?RjRCU3M1U2s4VVE2dWg0RDg5T0xhMnZhbEtwN2xpVkxCQlFCc1VFajI2aEtU?= =?utf-8?Q?F3ysUyIBPwp6+L67gNCmL1NV9EwAr4=3D?=
X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB1622; 6:y7z54IYHy2g91TB/hATF67LqKHMMXuLu4YK7yWq4IhOVP71uZgtt4gO+DoplWeC4E3MHAQM9TXhCwDSpWGNNm/u1tBGNUkTJ5wElfIZQbbNKVxf7KqwURGyw/8k6oyfyOKfRNA9lUEYQs6L0aqzzYTusjBwYt9QAOR2VmfgQ4bDNMGlv1FftAhImeh7Mp3bnI8nRSvNN1xoVpyCh/ikaWxJYissya4XcOoE4yQU1DVu5Kq3THNfzO9iUG3dUxnuzW+QnuC18OZ15L87nmCRtpdWoLQg5a7N2lvvo+BJK5TQ=; 5:CKU8a36fQGTErBgWjolmKH3pAS2sFRwo0I3y6zbM1lGYaOicA1sYRKToSNDKxCrSQeQ9tanl+X8QXSvCh4NtYdHjLsyU5hwyfBztjnoCH15bb423X0JIauJzsDCmpVAyRCc4YnWtWtGBWo8Xq956ig==; 24:9CqY5E+PQ7UZlYqqwL/Pcj4vXnzvBMjJJPaR5UvYGj+eC5xBeQZA0Or8hK/offhUo9IgOkbshzNwK1iq1Zo4sDXjjW0lTUyhZ2imyFvbIsQ=; 7:xhq6W2HDLxKf0zr1MmZprOr8WsIgghTAD1TMxkCfadaDzInkYZt71vjIxq2GVF8/H4pKnqqvR/E93zbFPnyCMNa3+HTiCbm5O/JJZrGxRBvIDztgUOqzp4cwGSI4ctDmUVoakGDQKXOrtjYDwtkU7couUCgT1iZ8XbFxy5gPJ62Palt7NNkIIDu93wGbLL7583wqMR6cGsGsUlqKrASaIqX8XDeAiRnWpg9YIJIuZgEvcUXPnaCQ1fGtmXzBxvwM
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Aug 2016 16:25:44.0799 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1622
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 02 Aug 2016 16:25:53 -0000

----- Original Message -----
From: "Jan Lindblad" 
To: "William Ivory" 
Cc: "Netconf" 
Sent: Tuesday, August 02, 2016 3:43 PM


If NP containers could be "created" and "deleted", what benefit would
that bring? If they could, what would be the purpose with the presence
statement? Why any distinction between P and NP containers at all? I
have asked these questions on this list several times in different words
over the last weeks, and so far zero answers. Could someone who defends
the position that NP containers can meaningfully be created and deleted
comment on this? IMO, the lack of answers makes it increasingly
difficult to take this stance seriously.


To quote from an early I-D,

A distinct container should be used when encoding lists with multiple
instances...
Some containers exist in the 'real world' and some are only modelling
artefacts.
Use of container elements allows simpler manipulation of lists and list
members.

so I have always seen the value of containers, those that exist and
those that are artefacts.  Giving some a boolean value (calling it one
bit of information sounds like information theory to me:-) is a
plausible extension of this but making them possibly vanish when empty
has seemed a little odd; suppressing them in a response, well yes, sort
of ok.

So I see the root of the problem as the defined, but indeterminate,
behaviour that a YANG server is allowed when a Non-Presence container is
empty.  One post of Andy did suggest changing that and that I think the
best way forward (but I would see that as more than a permissible
erratum).  I see the change of text in YANG 1.1 relating to must
statements as steering us in that direction

As to the IETF procedure, the WG Chairs assess rough consensus, declare
it and we move on (leaving those unhappy with it with the option to
appeal:-).  Sometimes, as at this moment with IPv6 and the insertion of
Extension Headers, that can be a protracted process.  And the main IETF
list is discussing how long the IETF takes to produce a standard and the
downsides thereof.

Tom Petch

> From the perspective of writing our YANG 1.0 models, we can add ‘not
current() or …’ on the front of any must statement on a NP container if
we only want it to be evaluated when the NP container has child node(s).
That at least relaxes restrictions (so meets RFC 6020 section 10
backwards-compatibility requirements) and reduces the number of NP
containers where evaluation of must statements would appear to be
implementation-specific for YANG 1.0.

YANG 1.1 implies no functional change, so there is no need to update any
models. I understand (and have preached this for many years in YANG
trainings, as many readers of this list might testify) that
clarifications always have an element of backwards incompatibility, as
anyone who understood the original unclear statement differently after
the clarification will see a change...

Even if "not current() or " is prepended to must expressions, that would
have no effect at all. The expression would only be evaluated for nodes
that do exist, so bool(current()) is always true for any node that has
its must expressions evaluated.

> From Jan’s perspective I can see that not evaluating must statements
on NP containers with no child nodes would invalidate his YANG model,

I certainly have many examples of this in my world, but this model was
taken from the IETF YANG repo. Zerotouch, to be exact.

Beside my point that seasoned IETF modelers that have nothing to do with
me or our tools leverage this understanding of NP containers, it also
highlights the utility of the NP container concept as I interpret it.
YANG would clearly lose something if we made NP containers behave the
same as P containers.

> but equally any NP container with the likes of ‘must “not(../foo)”;’
would make configuration of ‘foo’ impossible if we take the 1.1
clarification and apply it to 1.0.

I reiterate that there is no change, just a clarification in YANG 1.1.

> Unless there is existing clear guidance that the latter form of must
statement should (must?) be avoided, then I don’t see any overpowering
argument in either direction.

There is no such guidance, and there shouldn't be. This is a useful way
to express validity of configurations in YANG. I find the zerotouch
example elegant and simple to understand. The YANG modile would only get
less readable if we tried to add some rules/CLRs to forbid certain must
statement constructs, not to mention the YANG spec itself.

>   It comes down perhaps to whether we prefer to allow some
configurations that weren’t intended to be allowed (not evaluating musts
that were intended to be evaluated) or we potentially block valid
configurations (evaluating musts that weren’t intended to always be
evaluated).

Is this a real problem? Do we have a lot of models that depend on the
(mis)understanding of how must statements on NP containers are
evaluated?

> From a pragmatic perspective, the Postel principle of being liberal in
what you accept (at least in YANG) would seem more flexible in that once
config is rejected, there’s no alternative, whereas you can always
advise that configuration is accepted but ‘unwise’.

I simply cannot imagine that leaving open whether must statements are to
be evaluated or not could bring this WG closer to any of its goals. We
should be working towards precision and utility.

/jan

> From: Jan Lindblad [mailto:janl@tail-f.com]
> Sent: 02 August 2016 13:13
>
> Those of us who believe the presence statement in YANG 1.0 specifies
some behavioral difference between P and NP containers tend to think of
the YANG 1.1 specification edits below as clarifications rather than
functional changes.
>
> This should come as no surprise to anyone who has had the strength to
follow the full length of the thread, but since my opinion was
requested, I thought I'd clarify anyway.
>
> As SDO our main goal should be to get clear specs describing useful
functionality. NP containers, as defined in YANG 1.1 and (less clearly)
in YANG 1.0 are very useful IMO. I would prefer to describe NP
containers as always existing if the parent exists, but may be
suppressed in get-config when empty. I proposed some specific language
earlier. I find this more natural than language around spontaneous
creation and deletion by the server, even if the net result may be the
same. The voucher example is indeed YANG 1.0.
>
> /jan
>
> On 1 aug. 2016, at 17:10, William Ivory > wrote:
>
> Hi Andy,
>
> Thanks – in isolation that is clear, but I would be interested in Jan’
s thoughts given that the given ownership-voucher example would appear
to be YANG 1.0 *and* assume must statements are evaluated on
non-presence containers if the parent node exists.
>
> Regards,
>
> William
>
> From: Andy Bierman [mailto:andy@yumaworks.com
]
> Sent: 01 August 2016 16:03
>
> Hi,
>
> I think I made that comment.
> In YANG 1.0, only default leafs were considered always present.
> In YANG 1.1 NP containers were added to the set of accessible nodes
>
> In YANG 1.0, sec. 7.5.3
>
>    o  The accessible tree is made up of all nodes in the data tree,
and
>       all leafs with default values in use (see Section 7.6.1).
>
> This was changed in YANG 1.1
>
> sec 7.5.3:
>
>
>    When a datastore is validated, all "must" constraints are
>    conceptually evaluated once for each node in the accessible tree
(see
>    Section 6.4.1).
> Sec. 6.4.1
>
>       If a node that exists in the accessible tree has a non-presence
>       container as a child, then the non-presence container also
exists in
>       the tree.
>
> Andy
>
> On Mon, Aug 1, 2016 at 7:51 AM, William Ivory > wrote:
> Hi,
>
> Could someone confirm then that must statements on a non-presence
container in YANG 1.0 are only to be evaluated if the non-presence
container has configured children … or is it also if (reading Lada’s
mail) the implementation chooses to implement them when there are no
children present?
>
> I had assumed that the text in YANG 1.1 was clarifying YANG 1.0 rather
than new functionality here but I’m a little confused now, especially
given the comment by Jan Lindblad regarding this YANG snippet as the
file does not contain ‘yang-version 1.1’ and would surely therefore be
version 1.0?
>
>       container ownership-voucher {
>         description
>           "This container contains the Ownership Voucher that the
>            device uses to ascertain the identity of its rightful
>            owner, as certified by its Vendor.";
>
>         when "../redirect-information/signature or
../bootstrap-information/*/signature";
>         must "../owner-certificate";
>
>         uses ownership-voucher-grouping;
>       }
>
>
>
https://github.com/YangModels/yang/blob/master/standard/ietf/DRAFT/ietf-
zerotouch-bootstrap-server.yang

>
> Jan’s comment on this YANG (assuming it’s 1.0) and Lada’s assertion
(pasted below) appear contradictory to me.
>
> ‘NP containers were not always present in YANG 1.0.
> The must-stmt only applied if they actually are present,
> which is an implementation choice.
> ‘
>
> I’m also thinking that any must statement on a non-presence container
in YANG 1.0 models might sensibly be (re)written as ‘not(current() or
’ to make it future-proof if these nodes do
not exist in 1.0 w/o children but do in YANG 1.1.  That would allow for
easier model migration.
>
> Regards,
>
> William
>
> From: Netconf [mailto:netconf-bounces@ietf.org
] On Behalf Of Andy Bierman
> Sent: 01 August 2016 15:23
>
> On Mon, Aug 1, 2016 at 7:13 AM, Ladislav Lhotka > wrote:
> Andy Bierman > writes:
>
> > Hi,
> >
> > YANG 1.1 has been changed so the XPath is not really
backward-compatible
> > with YANG 1.0.  In YANG 1.1 NP-containers always exist if the non-NP
parent
> > is instantiated.
>
> My mental model regarding NP-containers is that they are part of
> the default contents of a datastore. If an NP-container is "in use"
> (according to the same rules as specified in sec. 7.6.1 of 6020bis for
> default leaves), then
>
> - creating a child of this container succeeds,
>
> - "must" expressions defined on this container apply.
>
> NP containers were not always present in YANG 1.0.
> The must-stmt only applied if they actually are present,
> which is an implementation choice.
>
> I don't understand all this special wording about "do not error if..."
>
> NETCONF has explicit support for this exact use-case, called "merge".
> This was done precisely to support these "don't error if..." cases.
> So use "merge" if you want this functionality.
>
> Lada
>
> Andy
>
>


From nobody Tue Aug  2 10:51:30 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8C412D1EB for ; Tue,  2 Aug 2016 10:51:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrr-j05P7s7z for ; Tue,  2 Aug 2016 10:51:25 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0106.outbound.protection.outlook.com [104.47.36.106]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CA4A12D841 for ; Tue,  2 Aug 2016 10:51:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SuZXZobjwmAF30wURPtPJp65GOP1Gg9IdHswA11lnMg=; b=jIXOOlfwlnJvgFKB2oaRug4LNGfNImjMstO9J7/SB4hkMmL/aHhch5Wc3SWXF/FvW3aG8E8bVd1KAqELedoGyYUxTnhzSX6Dt9r/j9tsMlWyoFd28pSnvHyBYDhuJYQLsEPI2IM5aT90/mEzYfr53suuAKSs+n9WFWG3fN+Xphg=
Received: from SN1PR05CA0039.namprd05.prod.outlook.com (10.163.68.177) by BY2PR0501MB2151.namprd05.prod.outlook.com (10.163.198.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.557.8; Tue, 2 Aug 2016 17:51:22 +0000
Received: from BN1AFFO11FD031.protection.gbl (2a01:111:f400:7c10::188) by SN1PR05CA0039.outlook.office365.com (2a01:111:e400:5197::49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.5 via Frontend Transport; Tue, 2 Aug 2016 17:51:22 +0000
Authentication-Results: spf=softfail (sender IP is 66.129.239.19) smtp.mailfrom=juniper.net; yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=juniper.net;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.19 as permitted sender)
Received: from P-EMFE01C-SAC.jnpr.net (66.129.239.19) by BN1AFFO11FD031.mail.protection.outlook.com (10.58.52.185) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.549.5 via Frontend Transport; Tue, 2 Aug 2016 17:51:22 +0000
Received: from magenta.juniper.net (172.17.27.123) by P-EMFE01C-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 2 Aug 2016 10:51:21 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id u72HpKx56074;	Tue, 2 Aug 2016 10:51:20 -0700 (PDT)	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id u72HlwWn028513;	Tue, 2 Aug 2016 13:47:59 -0400 (EDT)	(envelope-from phil@idle.juniper.net)
Message-ID: <201608021747.u72HlwWn028513@idle.juniper.net>
To: Jan Lindblad 
In-Reply-To: 
Date: Tue, 2 Aug 2016 13:47:58 -0400
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:66.129.239.19; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(2980300002)(199003)(189002)(48376002)(586003)(1076002)(356003)(4326007)(105596002)(68736007)(97736004)(5003940100001)(47776003)(76506005)(11100500001)(2906002)(8676002)(110136002)(7696003)(2950100001)(7846002)(69596002)(2810700001)(81156014)(86362001)(305945005)(8936002)(54356999)(92566002)(77096005)(50466002)(106466001)(50986999)(87936001)(8276002)(81166006)(53416004)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0501MB2151; H:P-EMFE01C-SAC.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD031; 1:gpq3pzvTeEKrHa4OuSeuGJQojAqsnRwCpYgAt173erDHV+SrMKjgp4hVOiImzsrdvC+xzRP8mJC7BTrBq3uVhqsVgy4HNp85DalioWyxVS1d4mrioyeLuGpDLcfYhSOPYQklMOdEfD781tOvELz2fz3zpOHF1py0GG9A/BPxpgFrVSCdOJVvAxyNSMZiwHEfmsTJt9Tzn/fMAlqYMGJVFnpCDjxqs1thIV4lgCRLhIx2QgGLMg1er44GDeIuoYTwl2DXJdc9m98liB1P7Cs8YJq8T1va8GdIcYo5iWze6vFvisFeMs1GBsAd83XWGWABrgdWuWgK+HHd313hAo/RgZsvKAcqv5i/sxkjTn0OGhvpDEPZ7zJjNmWnya6fd/2BMGXFJmXTQ58MxGB9wV2MeDWtKxDo7FDB+iZbDgpTaD1wJAaRlGEYaL5cdjYb5/8+Mly8xE4ySrciReMSncTTs1LUmS6gajwpuD1GGEomcxxF9l/bZcQoTpKKVrSzh1+jz1WsVfV1Hu0i5p6kcii2HRnO5hVmqSp6h6Gpk8uFS/qE1Srjzsnp5EeZewkSMfip
X-MS-Office365-Filtering-Correlation-Id: 15f5a5e5-2705-4616-2d57-08d3bafd9e12
X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB2151; 2:rdRBqVQcI6LWIAEfFaJDIgtAeotd+YGKZ41CJvYdPrwHkn7iCgk9xppWOBO+uF6wp38oo2KtAkDE6ohUkCxmVtpsKH1PTzglfPl6Er3S8v+q8VnCvsv8WP7KIVGLT3swTu++fDaerygkXgt7X8SCeZna8GEMPTCExWH4uuruKRLGGkd+fgGaSFsCpdUh7WWR; 3:NVqyeiBleA2lHHyC2s78n0Q045VkTMRI0nreRruBvBWQbi4wwdt6FCAyXWv3dHqUFxDPB7r+mNbmNejdTn77+mRAlPbUIxS8tgkD6y+8kzMB83HoQocuNr6Hge3yvGhLf4zcDHa3umjwkWiKHzh6PwZy41ylhdee7uFv3RprP4P2svdYw8qff+IiKEongcYSa7vcX0oCI2oB07qMNoJTpScntWPKzZsDX7Uw+j0AED4=; 25:GIfajxF1OHji/rAHVDHMIQYqlidyZ04QLkGEAMDCbS/1QRxbuZk/4rDIKj9yip3zBCkEoOPyEFFTCNWqehkherAN+C6sKbaqe7UOLxjJqoyKYiXPLsJI0hyE4dw9345reto8DAWKiqA7JYkH5gA/PQKx6cDJOX6laAbpNZ4wKFcpsfyVot2OZKghMAx7hBotrGvRs3aUniWzd/7pb7x9PSLxQroG6fCwYTswwAsfbfi1z/T7I284ArE9aRrLJw03bPIQw8qLraTC5pjoI0wUkscT9d12E1T7qq1SHKRXkgy22MqsN/zfh5JJ3njUrfhYWn9jC6XPkC/ZSvh9/evFLVw48xEyuIzlP8AqS5dxnkAbqg6IKFayTZxdtOMgPs55YZEZf9vN398WBET0d+oNp2NtbOa8h8VmDbmTdsJGWPQ=
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0501MB2151;
X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB2151; 31:SpSBZNG+Slb5vmeSc6y5XYWYNr8E0YqU6e0aDrANRY2S8CUJPuiV/8dXG8ZPCmJU5g3wk2M4RZ+lZhrAs1SxskapP9qTVZepqcPjxRBrallD2njgbv8UJ/ruC859ycX1n6NYabaEgmHM5SzEeA2NP+M7vFqGn76M8kkCXC8exF31A6KhBmS3c2iEjuH6u2w8bvVstSCq+cwklFTZfMKaCd3G7e2dzuUNs5wzVXhq1zY=; 20:Bk97trdgouLHG8kkAgsGVGMxE7uI0DKbeTlWQ0Aj3/ZBCOt1M41huV/35wwfRww9zEv+rSioC6ypJh3MbvGdCmeu3OMM8QcuIiCg5pdqtR676jC3iBm5PcHXXS/3iBZogbtpDxU4/Ig1g7L/zmCJrJTHj6Or2QkS8+p1W7kigPkEhyOg4XMs8kIR4+0+wAzvZbAZgeUnliW/+WYpOVgLeAKL7fYke32vWrZfyGUb8EDBj5M1ddUkvNJrHVrZ1/0Ys5uE6muc7lIBkdA/ntzZIXRQMeq6Ac6skkEFTom2HHxj1GzNU9Cu57RpObGVNwMVIC5v1yHv1/izjEgTsKpVcp7v1JoRH+ALAUEO1RGTnjQPQrgneYpfxKZlsVF2VMYZKI6iaquoHSGOQ8NGNnHGntk3ENFOsxN94q4ex9Bf7I2aUAvIg03SppqgW4xMm14Z1ASqNdE00zBt8ewr92cJMs1kLT6z5kaeToetVoIrzBsqGPgFvYvRuq1ocIQxWH9a
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13018025)(13024025)(13017025)(13023025)(13015025)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BY2PR0501MB2151; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0501MB2151; 
X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB2151; 4:fTlbyUwLV+wGeBjwYL1DuRfM/ccmaL6A2+eVzeqnFgBoxDrrv8WOI1XNPntpUUqoNl5skxu0foULuVx1AbsAGvH9/MUBfJKSZ5PNEuTTWH6dvZ2Y5e15FeelGyegJLrRl5MHDUbZJQJUka+IESmHdMAx6xk6cm/Lv1hPm8Mxvv3Z9Ra9CjcxLG5nW1jQ/WD0wsgf8X9EHn/4rvAFAzGVyvOuqJRPPb+iG0KBqXSvGjUsNxXABaHTkHEYQhEOjDpBNDTDyCDKQR+e99Dh5n2qj58xbrukechuZlgzNmLVs6A+YzZz66WCBjmZ9lB204zX55x4qmwSbGs78SOtbJ60r0HbV2QbOtES43R9I10dO0OIlQSrp5PWQZoT676cKMbosbvG7iZ+x2CYMOyX+p7aRizGrPyq9X/jZURjXYNCd1Cuu4lattz1DzWB7nyDhg+Yva18QX0KoUt1HjuV+Ew1fXyvBY3o7vRcy6DYnT4mTaR8v17mLzoL7f/ljzlgKsmTjJ/FHFSkPmWEju1YbHW7Xw==
X-Forefront-PRVS: 0022134A87
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR0501MB2151; 23:c9mpLjrE9WKL6rZV1Lj3L16f0ubeYJQHJAB35lr?= =?us-ascii?Q?f9svCK/2Rai8MwBwTmXNb3oISbLLht9eLKabKly42byZj38w4wzGLQ+BUBn4?= =?us-ascii?Q?0/sOBDZrKLB5+qaZkD5o7APqonRmg3Kmoxg86qNJ80d4N5Bx7/Hv5dFY+kt7?= =?us-ascii?Q?PEdNehaIJcn3m34Og83J6y78Y7+P/EEWQutzXM2swvyOQgzsw5wPCOfz/hDv?= =?us-ascii?Q?8rgkct1rDFEcDHBQ1QWkzPJPJ8NrZ1Ba5XtOZI2h11cBZxs4Al8X/p8u9/xW?= =?us-ascii?Q?UizVtmAyrv3Cipmf0z6v17mUJSUhr5qcDwmaKS13vR4fBHuyC23aoDxXpsX/?= =?us-ascii?Q?n9I7bdltjVQVu8d0ZKnFo9WqbNJi6zd0kYb9GnEcNBC4V5j7U/1AqIgVmcBx?= =?us-ascii?Q?q3WVuGfL3ftbXKZ1M9/yr+wUGrsLFisHkGXtGJ3FJxqs3EnH4FOHxj6VHcWv?= =?us-ascii?Q?XhTDi2EBwTWQ/OyhzMY3JW2VDQLJ3hKDX/rmDqV0NFK1AySRStaQIDDMJItr?= =?us-ascii?Q?qAw/nAKXU8ZqCo6HC/uFdseCv5on4h3XKYIx3TfY9BFyoX5q621Uc++GI3VI?= =?us-ascii?Q?Tgb3c36PsxdwksozZWp+im6ZkcLsV2uXaXY2jgiy+ZveADs93pYPWdl2Manw?= =?us-ascii?Q?vx/uLIr+vELh5yQ0wc/Gj95t3YwxYTEFy2ern2iXL9IH5f+LSSbM1TCwhrhr?= =?us-ascii?Q?KrsT3sJ311zfejhUl/EXGCtP0Jy+cZgUPIBDIXUEw1M9zfESnL2VpDjyi3yc?= =?us-ascii?Q?NcAJlC7smcGvyf6HCRKxMVFc7RZj0i0vi2heCQOjoTpUQU9+WtdoiW8VHCVC?= =?us-ascii?Q?PKas79PTJ7EVmqip0Sh2jYo2wRApJJUUyN3dDFVxBUjM73ZFauXAq5BmAQeY?= =?us-ascii?Q?om36JuBy8wIJw17xtDASp5y6kGayro1vLHmKK7f/xu6AA6JIhzIPHW1tzqN8?= =?us-ascii?Q?wiXD8MPqBQjfpuPWEjtW6xhEc23tRgerGdjv8Rc5XOHM1rVOP0+Tk2ZghczU?= =?us-ascii?Q?O+EjWK+VZ9MvJtFtRSMLSbP6u?=
X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB2151; 6:rwKaA1qZPaKJyy9fB++3YaSUz8P9b896PI2b4vr3PycERVpuh1HpW1eMfwmwR5ZjJcEAzUl0kpgvyEkJHZe5NJ2Inj8f6E6bnGRjGSISSrbK1IOsvf4yOHzjmzE6AvtfS/NvVfXlCvAVDov2a3sNYOpV5Q3OJccegRJG/1oSNs5cO/6d1eqcbEa3cGbxuLjlhN3DK2YwzdLTzr7nogbMsNQEKZBclVxChRVZwo3uazbhXTw7NXIQ/c2532tKj+0xQAsfL7Fb4YVJw2H2kEGMOMA3egYWsXT2iTOdGGnF8ZUgy1FEZ9QHCrWN2oWGmJGYduqmumTkg6TDnJ09saMBEg==; 5:mB6UMNoOk1qROmUufbLiyBPdbHwTSOcHJMgiOSMlIFOFgCn5sIwum9XI83r2WUB4d9OIKIXYeDuzbwZIn6RTCRQKfL4Uv71eCC286FHpV5HQYdLHylpkiY3qyTVLPbgJ6xa3Xf7k0CSA/8grfelvhw==; 24:RlRgIt+xvvf17bM2VOuGyLl7Tb4XicyVuiXcYS9RrcnyWh4rNwQuRGR8wJDEbnpBWxQz0LvdPBPH7BCGLKrjq0J6gyQI2rWpTcrxMZ5lFrc=; 7:7vYtrPeaesLpYVkLb7B24xLMKEsdbgZxQaMkg8pUqKyeFsRk2aXYPREonczTmbYaoNjLUoVibOR6tTYtZ7dFdFtiQ3sdgQ92Ep+gM7gthZzPvffR0/jpcdOS4KcAhchIYEnleuHc9LpdVVAEVcVRS+hHy9X0nKGqmmxURs3B27OjPS6hi58Bx9kUVRo/M2Bn5+BbrIeZ/oY3Ih6wiTXU5Z2J0vsAqt4WNUplEyDK+yV3dtrZrvGW2aK4X6woh+1A
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Aug 2016 17:51:22.6955 (UTC)
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.19];  Helo=[P-EMFE01C-SAC.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0501MB2151
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 02 Aug 2016 17:51:29 -0000

Jan Lindblad writes:
>I would prefer to describe NP containers as always existing if the parent exists, but may be suppressed in get-config when empty.

I wrote something for the last IETF that was described as completely
accurate technically but semantically confusing.  I would consider
this "always existing" to be similar.  The point to convey is that
the NP container is strictly an organizational node, and that their
presence in the hierarchy carries no meaning.  They are used when
containing other nodes and have no value when they do not contain
other nodes.  If none of the nodes they contain exist, they should
not be visible.  If one or more of the nodes they contain exist,
they should be visible.   Make them always exist adds confusion.

Thanks,
 Phil


From nobody Tue Aug  2 13:12:48 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D852812D942 for ; Tue,  2 Aug 2016 13:12:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level: 
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nf08mBuOdLPM for ; Tue,  2 Aug 2016 13:12:45 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0103.outbound.protection.outlook.com [104.47.32.103]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAED012D944 for ; Tue,  2 Aug 2016 13:12:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=23TwCP4wP5l3WrI72puzQUUHs0sx/pRWA8att9W4DwY=; b=Srxdptfh0cQhO7CfsMWoL1eu66E1V2A5naHrPsBMBgWwk5WxthAv/uHm4k2/Bd4aKIG6gJgZSRDCmSZaGMAAb2UZf+ruwfBc3K0rxhom/jzM5MHp+6HJCEATTykLUWQ9SXZ7nbrfy1095I5GXFbbXKN8jB4TiVnIkD55SPN6n68=
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1452.namprd05.prod.outlook.com (10.160.149.13) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.8; Tue, 2 Aug 2016 20:12:39 +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.0557.009; Tue, 2 Aug 2016 20:12:40 +0000
From: Kent Watsen 
To: =?utf-8?B?TWljaGFsIFZhxaFrbw==?= , "netconf@ietf.org" 
Thread-Topic: [Netconf] ietf-system-keychain draft module
Thread-Index: AQHR7Md7Tbc+eDrJn0O20Dk5OwjRFaA119MA
Date: Tue, 2 Aug 2016 20:12:39 +0000
Message-ID: <91B0EC86-7879-4F94-81F5-FDE72928EBCA@juniper.net>
References: <4bcf-57a0a980-25-18bcab00@35396507>
In-Reply-To: <4bcf-57a0a980-25-18bcab00@35396507>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.18.0.160709
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-ms-office365-filtering-correlation-id: 7de2b0d8-444b-4cae-90cb-08d3bb115ac8
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1452; 6:QLrOC+MHF/wUITTFOZnji3yfLII2RA3abABLDwfkno6YQb5gkyxYVl10tdRYU/kD6pPCiN/NZrsq0dogdeodPitN/yyAt14kGJVtkojTZ9tFsZfN1YUaVu+AF9vdJkwAvoTuue93eGJq9V/gbneSgLZkpHtrrPOsUvf/bl4zFEUQKoDIrGt771okrbJUvLzUsjaKOVvhxA7JCvHgqigrr54iOG3lU1vbLjis6c/9IGmRA2C9knIwl3SRv9Phfw+j2GFGM37x82ysTAHlVcGSp0WgIMUar6R58kZet3qXw++4LMIJdMIOYWXXjq8s74MyDsHMNJd8AFPqTTPbQ6Cqnw==; 5:w2WeqafBfmKxP3IEQ+qluiIfg4C7iV2yzi2+Um4dyI9UfF8tVSGx5alFAtOWQDON96zpkfuhCrQvsPd0yZN8ftxt8D6Vl9JL2/DBYr+dsTiHHFYakH08fWj6Zgyi9jDX2AkcRDyRCN7xrO9qALmjQg==; 24:sYiED3Z5CyUm4hfdIz+yQ9E9+Aty4p1F+6z8UHb+AEiWRu5bA10nNYGA3rmQA7elrFdEGw4ow2Y6rY1hjnFz9iRR8g32njUEKSwbjWNg7pA=; 7:t/+zOA4dGHkE7L3EW9KXUpn/s5+xIGO8lO2bnezKuoiZNmNsUWHc34TYgcWo9L6eDGHKkkFKWboxe7jOikOglKNIyW1ypVqKKHRZ3Hulr7LfzWPCDpgaN/bmiBUuoTryXIScXIV5pdHjEGfpuOL4m6gZwNA9oTCOYyxqskjjs+9gk78X2q7I2dQ7bSOwTF/VdWTrJi5M1M7hUbjoyOarVW0U9pBcGzHu61+Mgi4Mx9drrEeRh6p5IqmTgqKw1CZU
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1452;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(278428928389397)(166708455590820)(211171220733660); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026);  SRVR:CY1PR0501MB1452; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1452; 
x-forefront-prvs: 0022134A87
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(51444003)(76104003)(24454002)(199003)(71364002)(189002)(10400500002)(105586002)(68736007)(102836003)(3846002)(36756003)(83716003)(6116002)(87936001)(107886002)(86362001)(3280700002)(189998001)(4001350100001)(33656002)(66066001)(2501003)(5001770100001)(54356999)(3660700001)(19580395003)(305945005)(15975445007)(230783001)(586003)(5002640100001)(7736002)(7846002)(101416001)(2906002)(122556002)(50986999)(92566002)(106356001)(97736004)(77096005)(83506001)(8936002)(2950100001)(106116001)(551544002)(81156014)(81166006)(82746002)(76176999)(8676002)(99286002)(19580405001)(345774005)(2900100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1452; 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:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2016 20:12:39.9702 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1452
Archived-At: 
Subject: Re: [Netconf] ietf-system-keychain draft module
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 02 Aug 2016 20:12:47 -0000

SGkgTWljaGFsLA0KDQpUaGFuayB5b3UgZm9yIHJlcG9ydGluZyB5b3VyIGVhcmx5IGF0dGVtcHQg
dG8gaW1wbGVtZW50IHRoaXMgbW9kdWxlLiAgSSBpbXBsZW1lbnRlZCBhbiBlYXJsaWVyIHZlcnNp
b24gb2YgdGhpcyBkcmFmdCBmb3IgdGhlIE5FVENPTkYgQ2FsbCBIb21lIHJlZmVyZW5jZSBpbXBs
ZW1lbnRhdGlvbiBbMV0sIGJ1dCB0aGF0IHdhcyBiZWZvcmUgd2UgbW92ZWQgdG8gdGhlIGtleWNo
YWluLWJhc2VkIGFwcHJvYWNoLiAgSSBoYXZlIHVwZGF0ZWQgdGhlIGNvZGUgZHVyaW5nIHRoZSBs
YXN0IHR3byBIYWNrYXRob25zLCBidXQgSSBrZWVwIGhpdHRpbmcgY29tcGF0aWJpbGl0eSBpc3N1
ZXMgd2l0aCB0aGUgY3J5cHRvIGxpYnJhcmllcyBJ4oCZbSB1c2luZy4gICBJIHRoaW5rIHRoYXQg
dGhvc2UgaXNzdWVzIGFyZSBhbG1vc3QgYmVoaW5kIG1lIG5vdywgc28gc29vbiBJ4oCZbGwgYmUg
aW1wbGVtZW50aW5nIHRoZSBpZXRmLW5ldGNvbmYtc2VydmVyLCBpZXRmLXNzaC1zZXJ2ZXIsIGFu
ZCBpZXRmLXN5c3RlbS1rZXljaGFpbiBtb2R1bGVzLg0KDQpSZWdhcmRpbmcgeW91ciBxdWVyeSwg
dGhpcyBpcyBhIHNvbWV3aGF0IGtub3duIGlzc3VlIFsyXS4gIFJpZ2h0IG5vdyBJIHRoaW5rIHdl
4oCZcmUgd2FpdGluZyBmb3IgTWFydGluIHRvIGdldCBiYWNrIGZyb20gUFRPIHRvIHJlc3BvbmQs
IGJ1dCBteSBpbmNsaW5hdGlvbiBpcyB0aGF0IHdlIG1pZ2h0IGhhdmUgdG8gZG8gZXhhY3RseSBh
cyB5b3Ugc2F5OiB0byBsZXQgdGhlIHByaXZhdGUga2V5IGRhdGEgYmUgaW4gdGhlIGRhdGEgbW9k
ZWwsIHByb3RlY3RlZCBieSBqdXN0IG5hY206ZGVmYXVsdC1kZW55LWFsbC4gIEhvd2V2ZXIsIHRo
ZXJlIHdpbGwgcmVtYWluIHRoZSBpc3N1ZSB0aGF0IHNvbWUgcHJpdmF0ZS1rZXlzIHdpbGwgbmV2
ZXIgYmUgdmlzaWJsZSwgc3VjaCBhcyB0aG9zZSBzdG9yZWQgd2l0aGluIGEgVFBNICh0cnVzdGVk
IHByb3RlY3Rpb24gbW9kdWxlKS4gIEkgdGhpbmsgdGhpcyBtZWFucyB0aGF0IHRoZSDigJxwcml2
YXRlLWtleeKAnSBsZWFmIG5lZWRzIHRvIGJlIG1hbmRhdG9yeSBmYWxzZSwgYW5kIHdl4oCZbGwg
bmVlZCBzb21lIGtpbmQgb2Ygd2FybmluZyB3aGVuIHRoZSBwcml2YXRlIGtleSBjYW5ub3QgYmUg
cHJvdmlkZWQuICAgT3Igd2UgbWFrZSBpdCBtYW5kYXRvcnkgdHJ1ZSwgd2l0aCBhIGRlc2NyaXB0
aW9uIHN0YXRlbWVudCB0aGF0IGV4cGxhaW5zIHdoZW4gaXQgbWlnaHQgZmFpbC4gIFBlcmhhcHMg
YSBORVRDT05GIG5vdGlmaWNhdGlvbiBjb3VsZCBiZSB1c2VkIGZvciB0aGlzIGFzIHdlbGwuICBX
aGF0IGRvIHlvdSB0aGluaz8NCg0KWzFdIGh0dHBzOi8vZ2l0aHViLmNvbS9KdW5pcGVyL25ldGNv
bmYtY2FsbC1ob21lICh3YXJuaW5nOiBuZXcgY29kZSBub3QgY2hlY2tlZCBpbiB5ZXQpDQpbMl0g
aHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYtd2cvc3lzdGVtLWtleWNoYWluL2lzc3Vlcy8yDQoN
ClRoYW5rcywNCktlbnQNCg0KDQpPbiA4LzIvMTYsIDEwOjA5IEFNLCAiTmV0Y29uZiBvbiBiZWhh
bGYgb2YgTWljaGFsIFZhxaFrbyIgPG5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYg
b2YgbXZhc2tvQGNlc25ldC5jej4gd3JvdGU6DQoNCiAgICBIaSwNCiAgICBJIHN0YXJ0ZWQgaW1w
bGVtZW50aW5nIHRoaXMgbW9kdWxlIGFuZCBJIGVuY291bnRlcmVkIHNvbWUgcHJvYmxlbXMuIEkg
d291bGQgbGlrZSB0byBrbm93IGhvdyB5b3UgYXJlIHBsYW5uaW5nIHRvIHNvbHZlIHRoZW0sIGlm
IHRoZXkgYXJlIGtub3duIGFuZCBiZWluZyB3b3JrZWQgb24sIG9yIGluZm9ybSB5b3UgYWJvdXQg
dGhlbS4NCiAgICANCiAgICBSZWdhcmRpbmcgdGhlIGxpc3QgL2tleWNoYWluL3ByaXZhdGUta2V5
cy9wcml2YXRlLWtleSwgaXQgaXMgY29uZmlndXJhYmxlLiBNeSBndWVzcyBpcyB0aGF0IHRoZSBy
ZWFzb24gZm9yIHRoaXMgaXMgYmVpbmcgYWJsZSB0byBhZGQgY2VydGlmaWNhdGUtY2hhaW5zIHRv
IGNvbmZpZ3VyZWQgcHJpdmF0ZSBrZXlzLiBIb3dldmVyLCB0aGlzIGVuYWJsZXMgdGhlIGNyZWF0
aW9uIG9mIGluc3RhbmNlcyBvZiB0aGlzIGxpc3QsIHdoaWNoIHNlZW1zIHRvIG1lIGRvZXMgbm90
IG1ha2Ugc2Vuc2UgYW5kIHNob3VsZCBiZSBmb3JiaWRkZW4gKG9yIHdoYXQgaXMgZXhwZWN0ZWQg
dG8gaGFwcGVuIGluIHRoYXQgY2FzZT8pLiBGb3IgY3JlYXRpbmcgbmV3IGluc3RhbmNlcyB0aGVy
ZSBhcmUgdGhlIGFjdGlvbnMgZ2VuZXJhdGUtcHJpdmF0ZS1rZXkgYW5kIGxvYWQtcHJpdmF0ZS1r
ZXksIGFtIEkgbWlzc2luZyBzb21ldGhpbmc/DQogICAgDQogICAgQXMgZm9yIHByaXZhdGUga2V5
cyB0aGVtc2VsdmVzLCB0aGUgaWRlYSBwcm9iYWJseSBpcyB0byBrZWVwIHRoZW0gaW50ZXJuYWxs
eSBzYWZlIHNvbWV3aGVyZSwgc28gdGhleSBkbyBub3QgYXBwZWFyIGluIGNvbmZpZ3VyYXRpb24g
YW5kIHRodXMgYXJlIG5vdCBhY2NpZGVudGFsbHkgY29tcHJvbWlzZWQuIEhvd2V2ZXIsIHRoaXMg
Y2F1c2VzIG1ham9yIGltcGxlbWVudGF0aW9uIGlzc3VlcyAoSSBrbm93IHRoaXMgaXMgbm90IGNv
bnNpZGVyZWQgYW4gYXJndW1lbnQsIGJ1dCBJIGJlbGlldmUgaXQgc2hvdWxkIG5vdCBiZSBjb21w
bGV0ZWx5IG5lZ2xlY3RlZCkuIFdoeSBjb3VsZCBub3QgYmUgcHJpdmF0ZSBrZXlzIHBhcnQgb2Yg
dGhlIGNvbmZpZ3VyYXRpb24gd2l0aCB0aGUgTkFDTSBleHRlbnNpb24gZGVmYXVsdC1kZW55LWFs
bD8gTXkgcG9pbnQgaXMgdGhhdCBvdGhlciBhcHBsaWNhdGlvbnMgKHVzaW5nIHRoaXMga2V5Y2hh
aW4pIG11c3Qgc2ltcGx5IHNvbWVob3cgZ2V0IHRvIHRoZSBwcml2YXRlIGtleSBpdHNlbGYuIEN1
cnJlbnRseSwgdGhlIGNvbmZpZGVudGlhbGl0eSBvZiB0aGVzZSBrZXlzIGlzIGVuc3VyZWQgbWFp
bmx5IGJ5IHN0YW5kYXJkIGZpbGUgc3lzdGVtIGFjY2VzcyBjb250cm9sLiBJbmNsdWRpbmcgdGhl
c2Uga2V5cyBpbiBORVRDT05GIGRhdGFzdG9yZSB3aXRoIGRlZmF1bHQtZGVueS1hbGwgaXMgYmFz
aWNhbGx5IHNpbWlsYXIsIGJ1dCBtYXkgZXZlbiBiZSBjb25zaWRlcmVkIHNhZmVyIHRoYW4gYSBm
aWxlIHN5c3RlbS4gVGhlIGtleXMgY291bGQgc3RpbGwgYmUgZW5jcnlwdGVkIHVzaW5nIGEgcGFz
c3dvcmQgYW5kIHRodXMgdXNlbGVzcyB3aXRob3V0IGl0LiBOYXR1cmFsbHksIHRoaXMgcGFzc3dv
cmQgd291bGQgbm90IGJlIHBhcnQgb2YgdGhlIGNvbmZpZ3VyYXRpb24uDQogICAgDQogICAgS2lu
ZCByZWdhcmRzLA0KICAgIE1pY2hhbCBWYXNrbw0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgTmV0Y29uZiBtYWlsaW5nIGxpc3QN
CiAgICBOZXRjb25mQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9uZXRjb25mDQogICAgDQoNCg==


From nobody Tue Aug  2 15:35:35 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F0612D60A for ; Tue,  2 Aug 2016 15:35:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level: 
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eA2bG3uXA2ra for ; Tue,  2 Aug 2016 15:35:33 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0118.outbound.protection.outlook.com [104.47.32.118]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08D1712B061 for ; Tue,  2 Aug 2016 15:35:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rdkxz4dkdeZ97CzigHcGMR8UZdVEbYhw2Q8wNn0IiSQ=; b=KIVM1gJTyL+Dz31hRLo8uTvmiUGrenP2mGwb44zzmy0CDmROPjrtdKy/tkzmQrr8AhF6mOyFB6G5mKdKHx8YgBR4fZh5X0nojzOnTq+nOHgRN77OsnqCgcKesmGLCxolocwFcR/kttyjjenFxg5PuSLq3/IR66s0d17+PEnIW8w=
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1452.namprd05.prod.outlook.com (10.160.149.13) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.8; Tue, 2 Aug 2016 22:35:19 +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.0557.009; Tue, 2 Aug 2016 22:35:19 +0000
From: Kent Watsen 
To: =?utf-8?B?TWljaGFsIFZhxaFrbw==?= , "netconf@ietf.org" 
Thread-Topic: [Netconf] ietf-netconf-server and ietf-ssh-server draft module
Thread-Index: AQHR7MpBnyt/euAXQ0KDAHfiSYYKWqA1/6iA
Date: Tue, 2 Aug 2016 22:35:19 +0000
Message-ID: 
References: <7eb3-57a0ae00-9b-3e7ef100@122083013>
In-Reply-To: <7eb3-57a0ae00-9b-3e7ef100@122083013>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.18.0.160709
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-ms-office365-filtering-correlation-id: 54882b7c-692b-49cf-3006-08d3bb2548b7
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1452; 6:A/JFX4cMu2RZdyVNdPFBal65uOJIT7JFcfhHRndQ+utf6Z83fcsEEEFknm42OfSEicKqPcKzQCDBOWfdeGU3bpQtiMTd7ZvGGV7lA+FAC/nQi7E1J+TmkdKZ5SLaH5Ivqop6s42TJUMezGMns9i7l9hEEOr0w4GdG0po4DMqXmm/RKmjgR850TvjmDiGxuXcUlw8yfzrZUdQhyhzOXtMW70OZ5D5zfejpCft7G7WYHNff3VSy6A4ifFVmXPXc+PaDnI4yyJFYGUvk1oaMUnmC6lHIc20hIjcDrt9NxPidwkU+qn+kjVOgUy/Ew0Xw8mAzi+9ZiDhUzTNELXb9LzTsw==; 5:lu6KYdPUD+8CHDeWPmBn+KNfI0sqkgITgI3bpCQ2JFpme60wl1AU8I1nom6zYcjyoKdMUf7q4NRJ3qVG1Q1Gvwo9Xy/OwQx9U4v1qa5MLLBEZ527KNWXyCHxb40WsoF+jbFKWmIdXc+Drbxk1wRvxg==; 24:BLPhQvzReDkeReAZlDrI/l1vsXHX8Jwzh5P039MTbbGH1X4njc0067eTnTzV9LnfOU/bzJRTugouc13nMmfhzBv93Cy3tvUv6jb6eSspxOA=; 7:o/fieJs9n0uF8DwDV4jJWg+RduSZlZ3uCz+hDzztIt54pL83g20szoVmzUlKjvldxHKutMsbIVYAHnahNyYq7p8UN4PyADYNmYAFrtqk53pZY5Nf1YOh5sm1IrWsTNqW1Xj13mK00CF2MNLiqF0IZwPrDDuM0eFHuGnahYOZ0BydsDeLHyxWJtcRz8S/1eLFh5pcb87KQgsZfiR0Da2BXvJrCVjqLLkM454bJHEAXNJfVOKTZrXpqB9TdR6lk05N
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1452;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026);  SRVR:CY1PR0501MB1452; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1452; 
x-forefront-prvs: 0022134A87
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(51444003)(122556002)(50986999)(2906002)(106356001)(97736004)(92566002)(54356999)(5001770100001)(5002640100001)(101416001)(7846002)(7736002)(305945005)(230783001)(586003)(82746002)(81156014)(81166006)(3660700001)(76176999)(8676002)(2900100001)(99286002)(83506001)(77096005)(106116001)(2950100001)(8936002)(3846002)(6116002)(83716003)(102836003)(36756003)(10400500002)(68736007)(105586002)(66066001)(33656002)(4001350100001)(2501003)(86362001)(107886002)(87936001)(3280700002)(11100500001)(189998001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1452; 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:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2016 22:35:19.5078 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1452
Archived-At: 
Subject: Re: [Netconf] ietf-netconf-server and ietf-ssh-server draft module
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 02 Aug 2016 22:35:34 -0000

SGkgTWljaGFsLA0KDQogICAgSGksIGR1cmluZyBmaXJzdCBpbXBsZW1lbnRhdGlvbiBzdGVwcyBv
ZiB0aGlzIG1vZHVsZSBJIG5vdGljZWQgc29tZSBpc3N1ZXMsIHdoaWNoIG1heSBvciBtYXkgbm90
IGJlIHJlbGV2YW50LCBidXQgSSB3b3VsZCBsaWtlIHRvIHJlY2VpdmUgc29tZSBmZWVkYmFjay4N
CiAgICANCltLRU5UXSBBZ2FpbiwgaXTigJlzIGdyZWF0IHRvIHNlZSB0aGF0IHlvdeKAmXJlIHRy
eWluZyB0byB1c2UgdGhpcyBtb2R1bGUuICBJbXBsZW1lbnRhdGlvbnMgYXJlIHdoYXTigJlzIG5l
ZWRlZCB0byBwcm92ZSBldmVyeXRoaW5nIHdvcmtzLg0KDQoNCiAgICBSZWdhcmRpbmcgdGhlIHN1
YnRyZWUgL25ldGNvbmYtc2VydmVyL2xpc3Rlbi9lbmRwb2ludC9zc2gsIHRoZXJlIGlzIG5vIGNv
bmZpZ3VyYXRpb24gb2Yga25vd24gYW5kIGFjY2VwdGVkIGNsaWVudCBTU0ggcHVibGljIGtleXMg
ZHVyaW5nIE5FVENPTkYgc2VydmVyIFNTSCBhdXRoZW50aWNhdGlvbi4gVGhlcmUgaXMgYSBsaXN0
IG9mIHRydXN0ZWQtc3NoLWhvc3Qta2V5cyBpbiBpZXRmLXN5c3RlbS1rZXljaGFpbiBtb2R1bGUg
Zm9yIE5FVENPTkYgY2xpZW50IHZlcmlmaWNhdGlvbiBvZiBzZXJ2ZXIga2V5cywgd2h5IG5vdCB0
aGUgb3RoZXIgd2F5IGFyb3VuZD8gSW4gb3VyIE5FVENPTkYgc2VydmVyIHdlIHVzZWQgYSBsaXN0
IG9mIHBhaXJzIG9mIHRydXN0ZWQgY2xpZW50IFNTSCBrZXlzIHdpdGggdGhlaXIgdXNlcm5hbWUg
KHNvcnQtb2YgbGlrZSBzaW1wbGlmaWVkIGNlcnQtdG8tbmFtZSBvbiBTU0gga2V5cyBpbnN0ZWFk
IGNlcnRpZmljYXRlcykgYW5kIGl0IHdvcmtlZCB3ZWxsLg0KDQpbS0VOVF0gQ3VycmVudGx5IHRo
ZSBleHBlY3RhdGlvbiBpcyB0aGF0IGFkbWluIGFjY291bnRzIGFyZSBjb25maWd1cmVkIHZpYSB0
aGUgaWV0Zi1zeXN0ZW0gbW9kdWxlIFtSRkMgNzMxN10uICAgVGhpcyBtb2R1bGUgZW5hYmxlcyB0
aGUgY29uZmlndXJhdGlvbiBvZiBzc2ggcHVibGljIGtleXMgZm9yIGNsaWVudC1hdXRoIChzZWUg
L3N5c3RlbS9hdXRoZW50aWNhdGlvbi91c2VyL2F1dGhvcml6ZWQta2V5KS4gICBJIHRoaW5rIHRo
YXQgdGhpcyBzZXBhcmF0aW9uIGlzIGZpbmUgYXMgaXQgaXMgbWltaWNzIFNTSCB1c2luZyBQQU0u
ICBPZiBjb3Vyc2UsIHRoZW4geW91IG1pZ2h0IHdvbmRlciBhYm91dCAvbmV0Y29uZi1zZXJ2ZXIv
bGlzdGVuL2VuZHBvaW50L3NzaC9jbGllbnQtY2VydC1hdXRoLCBzdWNoIGFzIDEpIHdoeSBkb2Vz
buKAmXQgaXQgaGF2ZSBhIOKAnGNlcnQtbWFwc+KAnSBzdHJ1Y3R1cmUgbGlrZSB0bHMtbGlzdGVu
IG9yIDIpIHNob3VsZCB0aGUgY2xpZW504oCZcyBYLjUwOSBjZXJ0IGJlIGF1Z21lbnRlZCBpbnRv
IC9pZXRmLXN5c3RlbTpzeXN0ZW0vYXV0aGVudGljYXRpb24vdXNlci8/ICAgU29tZXRoaW5nIGlz
buKAmXQgcmlnaHQgaGVyZSwgYnV0IEkgaGF2ZW7igJl0IGRlY2lkZWQgb24gYSBmaXggeWV0IC0g
YW55IHN1Z2dlc3Rpb25zPyAgQWRkaXRpb25hbGx5LCBpdCBzZWVtcyB0aGF0IHRoaXMgc2VjdGlv
biBzaG91bGQgc2F5IHNvbWV0aGluZyBhYm91dCBpdHMgaW50ZXJhY3Rpb24gd2l0aCBSRkMgNzMx
NywgYWdyZWVkPw0KDQoNCiAgICBOZXh0LCBJIGFtIHVuc3VyZSBhYm91dCB0aGUgaG9zdC1rZXlz
L2hvc3Qta2V5IGxpc3QgKHJlbGF0aXZlIHRvIHRoZSBjb250YWluZXIgZnJvbSB0aGUgcHJldmlv
c3UgcGFyYWdyYXBoKSBtZWFuaW5nLCBJbiB0aGUgZGVzY3JpcHRpb24gaXQgc2F5cyB0aGF0IGl0
IGlzIHVzZWQgZm9yIGFubm91bmNpbmcgdGhlIHN1cHBvcnRlZCBrZXkgYWxnb3JpdGhtcy4gU28g
dGhlc2Uga2V5cyBhcmUgbm90IHVzZWQgYXMgU1NIIHNlcnZlciBob3N0IGtleXMgKHdob3NlIGRp
Z2VzdCBpcyBzZW50IHRvIFNTSCBjbGllbnRzKT8gSWYgc28sIHdoeSBpcyB0aGUgY29uZmlndXJh
dGlvbiBvZiB0aGVzZSBob3N0IGtleXMgbWlzc2luZz8NCg0KW0tFTlRdIFRoZXNlIGFyZSBpbmRl
ZWQgdGhlIHNlcnZlcuKAmXMgU1NIIGhvc3Qta2V5cywgYnV0IGluIHRoZSBTU0ggcHJvdG9jb2ws
IHRoZSBuYW1lIG9mIHRoZSBhbGdvcml0aG0gZm9yIHRoZSBob3N0LWtleSBpcyBzZW50IGZpcnN0
LiAgU28sIGZvciBpbnN0YW5jZSwgaWYgdGhlIGNvbmZpZ3VyZWQgaG9zdCBrZXkgaGFwcGVuZWQg
dG8gYmUgYW4gWC41MDl2MyBjZXJ0aWZpY2F0ZSB3aXRoIDIwNDggUlNBIGFuZCBTSEEyNTYsIHRo
ZW4gdGhlIHNlcnZlciB3b3VsZCBzZW5kIHRoZSBhbGdvcml0aG0gbmFtZSDigJx4NTA5djMtcnNh
MjA0OC1zaGEyNTbigJ0gKGZyb20gUkZDIDYxODcpLiAgIFBlcmhhcHMgdGhlIHRleHQgY2FuIGJl
IGltcHJvdmVkPw0KDQogICAgDQogICAgTGFzdGx5LCBJIGhhdmUgbm90aWNlZCB0aGF0IGluIHRo
ZSBsaXN0IC9uZXRjb25mLXNlcnZlci9saXN0ZW4vZW5kcG9pbnQvc3NoL2hvc3Qta2V5cy9ob3N0
LWtleSwgdGhlIG5hbWUgbGVhZiBpcyBtYW5kYXRvcnkgZXZlbiB0aG91Z2ggaXQgaXMgYSBrZXks
IHdoaWxlIHRoZSBjaG9pY2UgdHlwZSBpcyBub3QgYW5kIEkgYmVsaWV2ZSBpdCBzaG91bGQgYmUu
IFBlcmhhcHMgYSBtaXNwbGFjZWQgbWFuZGF0b3J5Pw0KDQpbS0VOVF0gSW5kZWVkLCBhbmQgSSBo
YXZlIGZpeGVkIHRoaXMgaW4gbXkgbG9jYWwgY29weSwgdGhhbmtzIQ0KDQoNCiAgICBSZWdhcmRz
LA0KICAgIE1pY2hhbCBWYXNrbw0KICAgIA0KVGhhbmtzLA0KS2VudA0KDQoNCg==


From nobody Tue Aug  2 23:23:09 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8B912D857 for ; Tue,  2 Aug 2016 23:23:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.287
X-Spam-Level: 
X-Spam-Status: No, score=-3.287 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=-1.287] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYY0ro980cST for ; Tue,  2 Aug 2016 23:23:06 -0700 (PDT)
Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [IPv6:2001:718:1:1f:50:56ff:feee:34]) by ietfa.amsl.com (Postfix) with ESMTP id E6FEE120727 for ; Tue,  2 Aug 2016 23:23:04 -0700 (PDT)
Received: by kalendar.cesnet.cz (Postfix, from userid 999) id 0973460271; Wed,  3 Aug 2016 08:23:03 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1470205383; bh=Msj4lOjpwPlEm1DYcXjvaBKTQ1zzM23cQ9exaOwqLVg=; h=in-reply-to:from:date:cc:to:subject; b=Ml2crLz4tfmptI3ZB8duDJLWPzI39quMnX20WVbu9r6zdHKy8R223fxI05aP4Fa/x P6Naz3JrVkXH83hZgxAt22XV2JZPFpNEpR6fQPe9liUmOACY3XrgLfCkQsbrKh+gH6 t73+OaVVtoaqm6tMleqzQp+GgzhSGhJA07LU4n20=
content-type: text/plain; charset="utf-8"
in-reply-to: <91B0EC86-7879-4F94-81F5-FDE72928EBCA@juniper.net>
from: =?utf-8?q?Michal_Va=C5=A1ko?= 
X-Forward: 147.229.12.224
date: Wed, 03 Aug 2016 08:23:03 +0200
to: "Kent Watsen" 
MIME-Version: 1.0
message-id: <7c89-57a18e00-29-6c42458@231030219>
User-Agent: SOGoMail 2.3.13
content-transfer-encoding: quoted-printable
Archived-At: 
Cc: =?utf-8?q?netconf=40ietf=2Eorg?= 
Subject: Re: [Netconf] =?utf-8?b?Pz09P3V0Zi04P3E/ICBpZXRmLXN5c3RlbS1rZXljaGFp?= =?utf-8?q?n_draft_module?=
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Aug 2016 06:23:09 -0000

Hi Kent,
thanks for the reply. I did not really know (or rathet have completely =
forgotten) about those module issue trackers, I will look at them from =
time to time. Regarding TPM, I personally like the idea of making the l=
eaf non-mandatory, it seems to me it is the simplest solution.

Regards,
Michal

On Tuesday, August 2, 2016 22:12 CEST, Kent Watsen  wrote: 
 
> Hi Michal,
> 
> Thank you for reporting your early attempt to implement this module. =
 I implemented an earlier version of this draft for the NETCONF Call Ho=
me reference implementation [1], but that was before we moved to the ke=
ychain-based approach.  I have updated the code during the last two Hac=
kathons, but I keep hitting compatibility issues with the crypto librar=
ies I=E2=80=99m using.   I think that those issues are almost behind me=
 now, so soon I=E2=80=99ll be implementing the ietf-netconf-server, iet=
f-ssh-server, and ietf-system-keychain modules.
> 
> Regarding your query, this is a somewhat known issue [2].  Right now =
I think we=E2=80=99re waiting for Martin to get back from PTO to respon=
d, but my inclination is that we might have to do exactly as you say: t=
o let the private key data be in the data model, protected by just nacm=
:default-deny-all.  However, there will remain the issue that some priv=
ate-keys will never be visible, such as those stored within a TPM (trus=
ted protection module).  I think this means that the =E2=80=9Cprivate-k=
ey=E2=80=9D leaf needs to be mandatory false, and we=E2=80=99ll need so=
me kind of warning when the private key cannot be provided.   Or we mak=
e it mandatory true, with a description statement that explains when it=
 might fail.  Perhaps a NETCONF notification could be used for this as =
well.  What do you think?
> 
> [1] https://github.com/Juniper/netconf-call-home (warning: new code n=
ot checked in yet)
> [2] https://github.com/netconf-wg/system-keychain/issues/2
> 
> Thanks,
> Kent
> 
> 
> On 8/2/16, 10:09 AM, "Netconf on behalf of Michal Va=C5=A1ko"  wrote:
> 
>     Hi,
>     I started implementing this module and I encountered some problem=
s. I would like to know how you are planning to solve them, if they are=
 known and being worked on, or inform you about them.
>     
>     Regarding the list /keychain/private-keys/private-key, it is conf=
igurable. My guess is that the reason for this is being able to add cer=
tificate-chains to configured private keys. However, this enables the c=
reation of instances of this list, which seems to me does not make sens=
e and should be forbidden (or what is expected to happen in that case?)=
. For creating new instances there are the actions generate-private-key=
 and load-private-key, am I missing something?
>     
>     As for private keys themselves, the idea probably is to keep them=
 internally safe somewhere, so they do not appear in configuration and =
thus are not accidentally compromised. However, this causes major imple=
mentation issues (I know this is not considered an argument, but I beli=
eve it should not be completely neglected). Why could not be private ke=
ys part of the configuration with the NACM extension default-deny-all? =
My point is that other applications (using this keychain) must simply s=
omehow get to the private key itself. Currently, the confidentiality of=
 these keys is ensured mainly by standard file system access control. I=
ncluding these keys in NETCONF datastore with default-deny-all is basic=
ally similar, but may even be considered safer than a file system. The =
keys could still be encrypted using a password and thus useless without=
 it. Naturally, this password would not be part of the configuration.
>     
>     Kind regards,
>     Michal Vasko
>     
>     =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F
>     Netconf mailing list
>     Netconf@ietf.org
>     https://www.ietf.org/mailman/listinfo/netconf
>     
> 
 
 


From nobody Wed Aug  3 00:46:32 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3658812D8F3 for ; Wed,  3 Aug 2016 00:46:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.287
X-Spam-Level: 
X-Spam-Status: No, score=-3.287 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=-1.287] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CTj6I8kotOP for ; Wed,  3 Aug 2016 00:46:26 -0700 (PDT)
Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [78.128.211.34]) by ietfa.amsl.com (Postfix) with ESMTP id 32BF012D8F5 for ; Wed,  3 Aug 2016 00:46:26 -0700 (PDT)
Received: by kalendar.cesnet.cz (Postfix, from userid 999) id F3E0160271; Wed,  3 Aug 2016 09:46:24 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1470210384; bh=YoJKFhaXG49fl5ncbVG6WbCRDVY30jemo9vIpL6v27o=; h=in-reply-to:from:date:cc:to:subject; b=b9yhG2rja059JtLRs5wx4zMbwNEPp9CWgE0hyotzXo69L1XVmaoicgRaXPInJywmZ bL774wpEZiKFGxAbQmhPfcxWgGlgQlGEm77ZNP7DuXJ1boF5TLbLAmGgiWVi7dghjy UzfSwkVcMunJvPgNWiB40bPzjb+VMNd/3PK4PEoc=
content-type: text/plain; charset="utf-8"
in-reply-to: 
from: =?utf-8?q?Michal_Va=C5=A1ko?= 
X-Forward: 147.229.12.224
date: Wed, 03 Aug 2016 09:46:24 +0200
to: "Kent Watsen" 
MIME-Version: 1.0
message-id: <7c89-57a1a180-5b-6c42458@231067740>
User-Agent: SOGoMail 2.3.13
content-transfer-encoding: quoted-printable
Archived-At: 
Cc: =?utf-8?q?netconf=40ietf=2Eorg?= 
Subject: Re: [Netconf] =?utf-8?b?Pz09P3V0Zi04P3E/ICBpZXRmLW5ldGNvbmYtc2VydmVy?= =?utf-8?q?_and_ietf-ssh-server_draft_module?=
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Aug 2016 07:46:30 -0000

Hi Kent,
my comments are inline.

On Wednesday, August 3, 2016 00:35 CEST, Kent Watsen  wrote: 
 
> Hi Michal,
> 
>     Hi, during first implementation steps of this module I noticed so=
me issues, which may or may not be relevant, but I would like to receiv=
e some feedback.
>     
> [KENT] Again, it=E2=80=99s great to see that you=E2=80=99re trying to=
 use this module.  Implementations are what=E2=80=99s needed to prove e=
verything works.
> 
> 
>     Regarding the subtree /netconf-server/listen/endpoint/ssh, there =
is no configuration of known and accepted client SSH public keys during=
 NETCONF server SSH authentication. There is a list of trusted-ssh-host=
-keys in ietf-system-keychain module for NETCONF client verification of=
 server keys, why not the other way around? In our NETCONF server we us=
ed a list of pairs of trusted client SSH keys with their username (sort=
-of like simplified cert-to-name on SSH keys instead certificates) and =
it worked well.
> 
> [KENT] Currently the expectation is that admin accounts are configure=
d via the ietf-system module [RFC 7317].   This module enables the conf=
iguration of ssh public keys for client-auth (see /system/authenticatio=
n/user/authorized-key).   I think that this separation is fine as it is=
 mimics SSH using PAM.  Of course, then you might wonder about /netconf=
-server/listen/endpoint/ssh/client-cert-auth, such as 1) why doesn=E2=80=
=99t it have a =E2=80=9Ccert-maps=E2=80=9D structure like tls-listen or=
 2) should the client=E2=80=99s X.509 cert be augmented into /ietf-syst=
em:system/authentication/user/?   Something isn=E2=80=99t right here, b=
ut I haven=E2=80=99t decided on a fix yet - any suggestions?  Additiona=
lly, it seems that this section should say something about its interact=
ion with RFC 7317, agreed?

Right, I have forgotten about this other module, now it makes sense. As=
 for client-cert-auth, we do not support X.509 certificates for SSH, so=
 I will not be implementing this and do not really know any details of =
it. Based on what I have just read (RFC 6187) I have understood that ce=
rtificates replace only the public key (which is actually quite obvious=
 looking at the .../host-key/type choice), 1) so no cert-to-name is nec=
essary. But additionally, the server must verify the certificate the st=
andard TLS-like way (go up the whole cert chain), so there must also be=
 this information. I guess 2) is not a bad idea if we want to keep it c=
onsistent, but it also disorganizes things a bit (for one action, verif=
ying the certificate chain, you need to look at 2 different places/modu=
les). The situation is similar to ietf-system and authorized SSH public=
 keys, so this is likely necessary, but I definitely agree that a refer=
ence to the other module should be included.

>     Next, I am unsure about the host-keys/host-key list (relative to =
the container from the previosu paragraph) meaning, In the description =
it says that it is used for announcing the supported key algorithms. So=
 these keys are not used as SSH server host keys (whose digest is sent =
to SSH clients)? If so, why is the configuration of these host keys mis=
sing?
> 
> [KENT] These are indeed the server=E2=80=99s SSH host-keys, but in th=
e SSH protocol, the name of the algorithm for the host-key is sent firs=
t.  So, for instance, if the configured host key happened to be an X.50=
9v3 certificate with 2048 RSA and SHA256, then the server would send th=
e algorithm name =E2=80=9Cx509v3-rsa2048-sha256=E2=80=9D (from RFC 6187=
).   Perhaps the text can be improved?

OK, so it should work like this. The server first looks through all the=
 host-keys, collects information about all the used key algorithms and =
sends it. When the algorithm negotiation is finished, server uses the k=
ey agreed upon (if several keys use the same algoithm, the one with the=
 highest priority is used, BTW is support for this really needed, to al=
low more keys for an algorithm?). Also, to my knowledge, server host ke=
ys are private keys, so maybe rename .../hostkey/type/public-key? Still=
, some description of what is expected of this configuration to affect =
(something like the first sentences in this paragraph) would be helpful=
.
    
>     Lastly, I have noticed that in the list /netconf-server/listen/en=
dpoint/ssh/host-keys/host-key, the name leaf is mandatory even though i=
t is a key, while the choice type is not and I believe it should be. Pe=
rhaps a misplaced mandatory?
> 
> [KENT] Indeed, and I have fixed this in my local copy, thanks!
> 
> 
>     Regards,
>     Michal Vasko
>     
> Thanks,
> Kent
> 
> 

Regards,
Michal


From nobody Wed Aug  3 04:35:16 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB50012DA14 for ; Wed,  3 Aug 2016 04:35:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.188
X-Spam-Level: 
X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiiCwvK0tdmp for ; Wed,  3 Aug 2016 04:35:13 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 56C9912D9D2 for ; Wed,  3 Aug 2016 04:35:13 -0700 (PDT)
Received: from syd-vpn-client-255-189.cisco.com (unknown [64.104.248.208]) by mail.tail-f.com (Postfix) with ESMTPSA id 2D3D21AE0187; Wed,  3 Aug 2016 13:35:08 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_EDA68853-91E4-400E-922D-0BFE1DADEA79"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail
From: Jan Lindblad 
In-Reply-To: <201608021747.u72HlwWn028513@idle.juniper.net>
Date: Wed, 3 Aug 2016 13:35:00 +0200
Message-Id: <87265676-0F37-47EC-AB8B-B05920DB2AE9@tail-f.com>
References: <201608021747.u72HlwWn028513@idle.juniper.net>
To: Phil Shafer 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Aug 2016 11:35:15 -0000

--Apple-Mail=_EDA68853-91E4-400E-922D-0BFE1DADEA79
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> I wrote something for the last IETF that was described as completely
> accurate technically but semantically confusing.  I would consider
> this "always existing" to be similar.  The point to convey is that
> the NP container is strictly an organizational node, and that their
> presence in the hierarchy carries no meaning.  They are used when
> containing other nodes and have no value when they do not contain
> other nodes.  If none of the nodes they contain exist, they should
> not be visible.  If one or more of the nodes they contain exist,
> they should be visible.   Make them always exist adds confusion.

I'm fine with this. Maybe we should clarify that must statements on NP =
containers are evaluated if the NP container parent exists. That's where =
the "always exists" notion might help understanding a bit.

/jan


--Apple-Mail=_EDA68853-91E4-400E-922D-0BFE1DADEA79
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJXodbkAAoJEBSCnbqufIisalYH/iGaT+hLR1+Yofdl5SBpOd3V
D4iOV79hNsjmCMVKNFuHM/Aq25djWcapKvIChSR+64JIVqRzbuKo0KTwOSBg7Tq6
/CDf5djYRm6V9N6fhfBXXxecoPqYb/+O55StnCX51HgQKcQnNHPyqELnoRNr+4Ne
exOobD2KL4KmSeWm9rBLFThlt8HAIY+RjSBkwWn3pO7FydOo8SXjUjLdxs0APFiA
dMFHyLrohcozxRP1SCW1vB/6Y+y8RxzkBQTJngdnkQ8bGalFTDhzCqqIjlBVFBYk
mu12c6hW0rZ6S2R8G7nzbtjF2wuQZx0EobCuaIv0cWqiLfLHV+MP2tqJTZQxPm4=
=r4PQ
-----END PGP SIGNATURE-----

--Apple-Mail=_EDA68853-91E4-400E-922D-0BFE1DADEA79--


From nobody Wed Aug  3 07:38:38 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF59112D1B8 for ; Wed,  3 Aug 2016 07:38:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level: 
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vn5z3fDOHiuX for ; Wed,  3 Aug 2016 07:38:36 -0700 (PDT)
Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (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 EF35212DCB9 for ; Wed,  3 Aug 2016 07:36:48 -0700 (PDT)
Received: from resomta-po-11v.sys.comcast.net ([96.114.154.235]) by resqmta-po-02v.sys.comcast.net with SMTP id UxHabkTmS1zBdUxHsbc1YW; Wed, 03 Aug 2016 14:36:48 +0000
Received: from hobgoblin.ariadne.com ([73.100.16.189]) by comcast with SMTP id UxHqbYUQKT9CgUxHrbFWPl; Wed, 03 Aug 2016 14:36:48 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u73Eak6k006599; Wed, 3 Aug 2016 10:36:46 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u73EajBD006596; Wed, 3 Aug 2016 10:36:45 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com (Dale R. Worley)
To: Jan Lindblad 
In-Reply-To: <87265676-0F37-47EC-AB8B-B05920DB2AE9@tail-f.com> (janl@tail-f.com)
Sender: worley@ariadne.com (Dale R. Worley)
Date: Wed, 03 Aug 2016 10:36:45 -0400
Message-ID: <87twf1gbr6.fsf@hobgoblin.ariadne.com>
X-CMAE-Envelope: MS4wfNEq37e42TVWe146wdj3KKBhDjZ4sVd8pLvmfcuwdXD0BCIHkoWFxw1X1FdPwCC3UYQj45rdKGfpMiCSWdY2Z09CkP0+Zx0FIaAuU3kFeNMnTa6zbNNf 9txxJZDyUqLClllnSGLJnpDHgsA7KLRvgZH6omkN+vA+FVhKb2WiCkOEob6htVl10iS09+TmKNNHwP8juPx4F+tQE7i3X6TNKeP8XctVy9Xs47g4O3vSxs0i
Archived-At: 
Cc: netconf@ietf.org
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Aug 2016 14:38:37 -0000

Jan Lindblad  writes:
>> I wrote something for the last IETF that was described as completely
>> accurate technically but semantically confusing.  I would consider
>> this "always existing" to be similar.  The point to convey is that
>> the NP container is strictly an organizational node, and that their
>> presence in the hierarchy carries no meaning.  They are used when
>> containing other nodes and have no value when they do not contain
>> other nodes.  If none of the nodes they contain exist, they should
>> not be visible.  If one or more of the nodes they contain exist,
>> they should be visible.   Make them always exist adds confusion.
>
> I'm fine with this. Maybe we should clarify that must statements on NP
> containers are evaluated if the NP container parent exists. That's
> where the "always exists" notion might help understanding a bit.

(I'm not as versed in this technology as the rest of you, but...)

Why would there be a must statement on an NP container?  If its
existence is semantically meaningless, why would the module designer
place a must on it, since a must statement is a constraint of the form
"If this node exists, then this expression must be true."

Probably what is intended is to place a must statement on the *children*
of the container, which has the effect "If this container has contents,
then this expression must be true."

Similarly, there should be no XPath expressions whose purpose is to test
for the presence of an NP container.

Dale


From nobody Wed Aug  3 07:52:04 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4630912DC0F for ; Wed,  3 Aug 2016 07:52:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwy8xiBDTutI for ; Wed,  3 Aug 2016 07:52:00 -0700 (PDT)
Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 C3CC612DBB7 for ; Wed,  3 Aug 2016 07:51:59 -0700 (PDT)
Received: by mail-ua0-x22b.google.com with SMTP id 35so154220239uap.1 for ; Wed, 03 Aug 2016 07:51:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wDTVl+y++qblO7yj/EMoGuqrLnjLs2OMghSogR0a4i4=; b=a4h9nWUDTDsHeKmWNUvxZMHlLD4WEIzCsaJHYYE0mETZKh5VddQMX15ZRokmWDxzkC GhamNtP3OcTRmOB79NvYgkVpiykrhsGNx4c2o9oZOmjFwcwU1Jtvzz7Me6JMkYQaYGyo wdub6I36+KTXELk3CZbzyzH8Cbt5+e1zXHsrtSgWVHODTPKAo8va8BBm/rM90L+hqCfX IidD8tbkRSo0sw8IDJYIA4FQ2VdwnatwpRLbyYXPsxwtRkKVNQDaUr/vD5tJY9UydLLf e/0z7c9mZbz0I7ihdzAiAxjSeKK4fJx1orxDq0A+fuVWD+oZWAZj8uTm83+Rz7oCs5He XTgA==
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:from:date :message-id:subject:to:cc; bh=wDTVl+y++qblO7yj/EMoGuqrLnjLs2OMghSogR0a4i4=; b=kKtSPAipJ/7DClaHZJM3LjhbbSbgwGwqwC0iPiw/F9vbSRmskyb6GKmlVDWCaFWACW ds33YZUg9wueAjPQ9vsDRwumO3t3s5Fu+M8BmEi257EjDKIhDotVqUcW/xq9qAl/uu3E l5895/kRgNIkpcpmgi4ueaGJOSLnFvGn8BzTof8i4HIZ+UmeNXzCkTkcT9mY1BXqeaCx kmwEgTwzAGUZm9Dcfn1aU6+kjnvMAj4O+Mkqij61YCUqsrrY3sd3wza+7R62tBWDP91F E5qxdj1r9rkHQqwBKQnzncxlZ+0QTwI9aS4Qf7U63M7uWbBnfX1TGUXHUIuuuxcdSU4K D9cQ==
X-Gm-Message-State: AEkoouupwDg2aZMBo94noeM05Jw/WDOQ1OMJxU/51Kieh5hM+iyBVe9mOruCvf8oCTJt1bkeEr0//WNa5wdw/g==
X-Received: by 10.159.35.112 with SMTP id 103mr33768853uae.55.1470235918908; Wed, 03 Aug 2016 07:51:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Wed, 3 Aug 2016 07:51:57 -0700 (PDT)
In-Reply-To: <87twf1gbr6.fsf@hobgoblin.ariadne.com>
References: <87265676-0F37-47EC-AB8B-B05920DB2AE9@tail-f.com> <87twf1gbr6.fsf@hobgoblin.ariadne.com>
From: Andy Bierman 
Date: Wed, 3 Aug 2016 07:51:57 -0700
Message-ID: 
To: "Dale R. Worley" 
Content-Type: multipart/alternative; boundary=001a113ab81aaed96f05392bf982
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Aug 2016 14:52:03 -0000

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

On Wed, Aug 3, 2016 at 7:36 AM, Dale R. Worley  wrote:

> Jan Lindblad  writes:
> >> I wrote something for the last IETF that was described as completely
> >> accurate technically but semantically confusing.  I would consider
> >> this "always existing" to be similar.  The point to convey is that
> >> the NP container is strictly an organizational node, and that their
> >> presence in the hierarchy carries no meaning.  They are used when
> >> containing other nodes and have no value when they do not contain
> >> other nodes.  If none of the nodes they contain exist, they should
> >> not be visible.  If one or more of the nodes they contain exist,
> >> they should be visible.   Make them always exist adds confusion.
> >
> > I'm fine with this. Maybe we should clarify that must statements on NP
> > containers are evaluated if the NP container parent exists. That's
> > where the "always exists" notion might help understanding a bit.
>
> (I'm not as versed in this technology as the rest of you, but...)
>
> Why would there be a must statement on an NP container?  If its
> existence is semantically meaningless, why would the module designer
> place a must on it, since a must statement is a constraint of the form
> "If this node exists, then this expression must be true."
>
> Probably what is intended is to place a must statement on the *children*
> of the container, which has the effect "If this container has contents,
> then this expression must be true."
>
>

I like this clarification a lot.
I think this change is worth an errata (or maybe AUTH48 change).

The text that says an NP container exists if its parent exists is not
consistent with the results of this discussion.  It should say an NP
container exists if any child nodes exist or default nodes exist.

In this example 'top' and 'top2' always exist because of the default leaf X.

  container top {
    container top2 {
       leaf X {
          type int32;
          default 42;
      }
   }
 }


In this example 'top' and 'top2' only when leaf /top/top2/X exists.

  container top {
    container top2 {
       leaf X {
          type int32;
      }
   }
 }


Similarly, there should be no XPath expressions whose purpose is to test
> for the presence of an NP container.
>
> Dale
>
>

Andy


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

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




On Wed, Aug 3, 2016 at 7:36 AM, Dale R. Worley <worley@ariadne.com> wrote:
Jan Lindblad <janl@tail-f.com> writes:

>> I wrote something for the last IETF that was described as complete=
ly

>> accurate technically but semantically confusing.=C2=A0 I would con=
sider

>> this "always existing" to be similar.=C2=A0 The point to=
 convey is that

>> the NP container is strictly an organizational node, and that thei=
r

>> presence in the hierarchy carries no meaning.=C2=A0 They are used =
when

>> containing other nodes and have no value when they do not contain<=
br>
>> other nodes.=C2=A0 If none of the nodes they contain exist, they s=
hould

>> not be visible.=C2=A0 If one or more of the nodes they contain exi=
st,

>> they should be visible.=C2=A0 =C2=A0Make them always exist adds co=
nfusion.

>

> I'm fine with this. Maybe we should clarify that must statements o=
n NP

> containers are evaluated if the NP container parent exists. That's=


> where the "always exists" notion might help understanding a =
bit.



(I'm not as versed in this technology as the rest of you, but...)



Why would there be a must statement on an NP container?=C2=A0 If its

existence is semantically meaningless, why would the module designer

place a must on it, since a must statement is a constraint of the form

"If this node exists, then this expression must be true."



Probably what is intended is to place a must statement on the *children*
of the container, which has the effect "If this container has contents=
,

then this expression must be true."




I like this clarificati=
on a lot.
I think this change is worth an errata (or maybe AUTH48=
 change).

The text that says an NP container exist=
s if its parent exists is not
consistent with the results of this=
 discussion.=C2=A0 It should say an NP
container exists if any ch=
ild nodes exist or default nodes exist.

In this ex=
ample 'top' and 'top2' always exist because of the default =
leaf X.

=C2=A0 container top {
=C2=A0 =
=C2=A0 container top2 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf X {
=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type int32;
=C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 default 42;
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0}
=C2=A0}


In this example 'top' and 'top2' only when leaf /top/=
top2/X exists.

=C2=A0 container top {
=
=C2=A0 =C2=A0 container top2 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf X =
{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type int32;
=C2=A0=
 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0}
=C2=A0}

<=
/div>


Similarly, there should be no XPath expressions whose purpose is to test
for the presence of an NP container.



Dale




Andy
=C2=A0

_______________________________________________

Netconf mailing list

Netconf@ietf.org

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





--001a113ab81aaed96f05392bf982--


From nobody Wed Aug  3 08:19:53 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0E212D757 for ; Wed,  3 Aug 2016 08:19:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdEjXiko-PrZ for ; Wed,  3 Aug 2016 08:19:47 -0700 (PDT)
Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::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 952E412D67E for ; Wed,  3 Aug 2016 08:18:18 -0700 (PDT)
Received: by mail-pf0-x22b.google.com with SMTP id y134so78457311pfg.0 for ; Wed, 03 Aug 2016 08:18:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=rAxn4oegUY2txPak1UzwWsakjlmnxVkOMcQgRFCIMjM=; b=ZnyPdWjVZAnCkiGeNZ/fiLFk/MOYms1vig1knMU2Suh+Ffwlrw95whswZ5LViViD2R /DLQgqNs3fcGPNznS2JezVpl7j66+lf96MkvtKJPGZEiG+zkJ99G3ha2in0tC6J6xrXX es+MZHLAAV9JlziYEUeP9h8CSLH6thkP35tZWv66tJ5V3a+J7uydh6JHFgPDQ3B8HFI2 jwVlYhE+1Ya4p2nXZP/DEfgSDIP1BgMNiN/NVcDwoFObhkR9jf6Lkxz2Hll4CcOsqiLq QaRGmfDmWdw7YH9i7vY9ytFhyGRVaVY3X4vtWY6p1KaDeOUyNdcdJcPdJkWwJBzxdmjH QKKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=rAxn4oegUY2txPak1UzwWsakjlmnxVkOMcQgRFCIMjM=; b=mFbuzOXO0yrOiFp79wHqgtkMgAbbGxxwgXh6bHKlEsyd2AMX0pkEaa/x9MK2YsYl/r 3fHv/EXNK7Cwi0bDa1Txw36zrmgIXSF8v4wg0Mf8FuGpTYtxU3BOFKfjIgto6vnRommF X6XXG4fyG0mzv2hUL9bm/FMpPTW2fouwfUbOIyJAb+WVjtpVQd0lMNOqvM5o/he95UJ1 qSj72Tvne5oeA3ZxuHKjaqEky2j39WSmwWlv2YSC81H5sXmiysw1f0jIs89sjLZDHPQE 1/yL8SHuGWZYf4HCjMuafv85MRHHgBUb1Q1PQwfUCyGYFVQlsbRyGKyUCbz4cwny2YAN dcNA==
X-Gm-Message-State: AEkoouupx6Dg/2Pqf/4jNPbZB2OZ8NHjfzfqn6qCCuxDlZpEKTn3yHfTmAqF4jPhN+fHRQ==
X-Received: by 10.98.17.152 with SMTP id 24mr116652701pfr.13.1470237498196; Wed, 03 Aug 2016 08:18:18 -0700 (PDT)
Received: from [10.24.46.40] ([128.107.241.172]) by smtp.gmail.com with ESMTPSA id b134sm13513261pfb.55.2016.08.03.08.18.16 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 03 Aug 2016 08:18:16 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_54CB1377-68CA-4DB4-8F4F-C2B89BD377E0"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mahesh Jethanandani 
In-Reply-To: <87265676-0F37-47EC-AB8B-B05920DB2AE9@tail-f.com>
Date: Wed, 3 Aug 2016 11:18:15 -0400
Message-Id: 
References: <201608021747.u72HlwWn028513@idle.juniper.net> <87265676-0F37-47EC-AB8B-B05920DB2AE9@tail-f.com>
To: Jan Lindblad 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Aug 2016 15:19:52 -0000

--Apple-Mail=_54CB1377-68CA-4DB4-8F4F-C2B89BD377E0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Here is the summary of rough consensus that I see emerging.

1. Errata in YANG 1.1 Section 7.5.7 to clarify that NP containers exist =
(and return values) when it contains a node. Some suggested text.

    OLD:
 =20
     A NETCONF server that replies to a  or  request =
MAY
     choose not to send a container element if the container node does =
not
     have the "presence" statement and no child nodes exist.

    NEW:

     A NETCONF server that replies to a  or  request =
SHOULD
     not send a container element if the container node does not
     have the "presence" statement and no child or default nodes exist. =
Similarly, must
     statements SHOULD be evaluated for the children of the container.


2. Errata in YANG 1.1 to add the following clarification at the end of =
section 7.5.8

    A client cannot know whether or not a server has deleted a =
non-presence
    container when the last child node has been deleted and so cannot =
know
    whether a "create" or "delete" will succeed or return an error.  The
    client should use "merge" or "replace" instead of "create=E2=80=9D.

3. Errata in YANG 1.1. to add the following clarification in the same =
section (7.5.8)


OLD:

   If a container does not have a "presence" statement and the last
   child node is deleted, the NETCONF server MAY delete the container.

NEW:

   If a container does not have a "presence" statement and the container =
instance
   does not have any child node instances, the NETCONF server MAY delete =
the
   container. If the server does delete a container instance in this =
case, it MUST
   re-create the container instance if a client  request =
attempts to create
   a child node instance within this container.

> On Aug 3, 2016, at 7:35 AM, Jan Lindblad  wrote:
>=20
>> I wrote something for the last IETF that was described as completely
>> accurate technically but semantically confusing.  I would consider
>> this "always existing" to be similar.  The point to convey is that
>> the NP container is strictly an organizational node, and that their
>> presence in the hierarchy carries no meaning.  They are used when
>> containing other nodes and have no value when they do not contain
>> other nodes.  If none of the nodes they contain exist, they should
>> not be visible.  If one or more of the nodes they contain exist,
>> they should be visible.   Make them always exist adds confusion.
>=20
> I'm fine with this. Maybe we should clarify that must statements on NP =
containers are evaluated if the NP container parent exists. That's where =
the "always exists" notion might help understanding a bit.
>=20
> /jan
>=20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
mjethanandani@gmail.com




--Apple-Mail=_54CB1377-68CA-4DB4-8F4F-C2B89BD377E0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Here is the summary of rough consensus that I see =
emerging.

1. Errata =
in YANG 1.1 Section 7.5.7 to clarify that NP containers exist (and =
return values) when it contains a node. Some suggested text.

    =
OLD:
  
  =
   A NETCONF server that =
replies to a <get> or <get-config> request =
MAY
    =
 choose not to send a container element if the container node does not
     have the "presence" statement and no child nodes =
exist.

    NEW:

    =
 A NETCONF server that replies to a <get> or <get-config> =
request SHOULD
     not send a container element if the container node does =
not
    =
 have the "presence" statement and no child or default nodes exist. =
Similarly, must
    =
 statements SHOULD be evaluated for the children of the =
container.


2. Errata in YANG 1.1 to =
add the following clarification at the end of section 7.5.8

    A client =
cannot know whether or not a server has deleted a =
non-presence
    container when the last child node has =
been deleted and so cannot know
    whether a =
"create" or "delete" will succeed or return an error.  The
    client should use "merge" or "replace" instead =
of "create=E2=80=9D.

3. Errata in YANG 1.1. to add the following clarification in =
the same section (7.5.8)


OLD:

   If a =
container does not have a "presence" statement and the =
last
 =
  child node is deleted, the NETCONF server MAY delete the =
container.

NEW:

   If a container does not have a =
"presence" statement and the container instance
   does not have =
any child node instances, the NETCONF server MAY delete =
the
  =
 container. If the server does delete a container instance in this =
case, it MUST
   re-create the container instance if a client =
<edit-config> request attempts to create
   a child node =
instance within this =
container.

On Aug 3, 2016, at 7:35 AM, Jan Lindblad =
<janl@tail-f.com> =
wrote:

I wrote something for =
the last IETF that was described as completely
accurate =
technically but semantically confusing.  I would consider
this "always existing" to be similar.  The point to =
convey is that
the NP container is strictly an =
organizational node, and that their
presence in the =
hierarchy carries no meaning.  They are used when
containing other nodes and have no value when they do not =
contain
other nodes.  If none of the nodes they =
contain exist, they should
not be visible.  If one or =
more of the nodes they contain exist,
they should be =
visible.   Make them always exist adds confusion.

I'm fine with this. Maybe we =
should clarify that must statements on NP containers are evaluated if =
the NP container parent exists. That's where the "always exists" notion =
might help understanding a bit.

/jan

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



Mahesh Jethanandani
mjethanandani@gmail.com







=

--Apple-Mail=_54CB1377-68CA-4DB4-8F4F-C2B89BD377E0--


From nobody Wed Aug  3 09:30:00 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0EF812D094 for ; Wed,  3 Aug 2016 09:29:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WV-odi_n4UO3 for ; Wed,  3 Aug 2016 09:29:56 -0700 (PDT)
Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (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 D4A6312D151 for ; Wed,  3 Aug 2016 09:29:39 -0700 (PDT)
Received: from pps.filterd (m0048192.ppops.net [127.0.0.1]) by m0048192.ppops.net (8.16.0.11/8.16.0.11) with SMTP id u73GT40t022563; Wed, 3 Aug 2016 09:29:39 -0700
Received: from brmwp-exmb12.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 24kkuy84p7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 03 Aug 2016 09:29:38 -0700
Received: from EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) by BRMWP-EXMB12.corp.brocade.com (172.16.59.130) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Wed, 3 Aug 2016 10:29:23 -0600
Received: from EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) by EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Wed, 3 Aug 2016 18:29:22 +0200
Received: from EMEAWP-EXMB11.corp.brocade.com ([fe80::85ea:b7da:48dd:1640]) by EMEAWP-EXMB11.corp.brocade.com ([fe80::85ea:b7da:48dd:1640%21]) with mapi id 15.00.1156.000; Wed, 3 Aug 2016 18:29:22 +0200
From: William Ivory 
To: Jan Lindblad , Phil Shafer 
Thread-Topic: [Netconf] What should a server response be? - depending on NP-containers
Thread-Index: AQHR65HjCKulpI0Pc0iHx2JTqSf796AzNTEAgADP0wCAAALRgIAAJAdA///nFYCAACJxEIABQD0AgABduACAASohAIAAcrsA
Date: Wed, 3 Aug 2016 16:28:59 +0000
Deferred-Delivery: Wed, 3 Aug 2016 16:28:10 +0000
Message-ID: <6cb1d9ce83c74799a8f8020e9114bd2c@EMEAWP-EXMB11.corp.brocade.com>
References: <201608021747.u72HlwWn028513@idle.juniper.net> <87265676-0F37-47EC-AB8B-B05920DB2AE9@tail-f.com>
In-Reply-To: <87265676-0F37-47EC-AB8B-B05920DB2AE9@tail-f.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.252.48.16]
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-03_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 impostorscore=0 lowpriorityscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608030157
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Aug 2016 16:29:59 -0000

Surely we should either evaluate on ALL non-presence containers, or none?  After all, we evaluate 'default' and 'mandatory' anywhere in the config even if no actively configured nodes are anywhere in the vicinity?  Only evaluating to a depth of one level under configured nodes seems somewhat arbitrary.

Regards,

William

-----Original Message-----
From: Jan Lindblad [mailto:janl@tail-f.com] 
Sent: 03 August 2016 12:35
To: Phil Shafer 
Cc: William Ivory ; Andy Bierman ; Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers

> I wrote something for the last IETF that was described as completely 
> accurate technically but semantically confusing.  I would consider 
> this "always existing" to be similar.  The point to convey is that the 
> NP container is strictly an organizational node, and that their 
> presence in the hierarchy carries no meaning.  They are used when 
> containing other nodes and have no value when they do not contain 
> other nodes.  If none of the nodes they contain exist, they should not 
> be visible.  If one or more of the nodes they contain exist,
> they should be visible.   Make them always exist adds confusion.

I'm fine with this. Maybe we should clarify that must statements on NP containers are evaluated if the NP container parent exists. That's where the "always exists" notion might help understanding a bit.

/jan


From nobody Wed Aug  3 09:34:01 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D787412D77C for ; Wed,  3 Aug 2016 09:33:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROmY5Cxw-_My for ; Wed,  3 Aug 2016 09:33:51 -0700 (PDT)
Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C34212D77A for ; Wed,  3 Aug 2016 09:33:49 -0700 (PDT)
Received: by mail-vk0-x232.google.com with SMTP id s189so150080229vkh.1 for ; Wed, 03 Aug 2016 09:33:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cM0JBQll8MG3xqiKVqsKny/Nbqr3yJQfPDlFbXJw3Io=; b=PjsKIJKbvFEFhiMKebg1JXNIKikVCa2SoK8JYVQ15LnC3h5aMsZthRRsFwgFRXs2Bc 2E61RgqpxsCxV4FzkI6NdprtbZ3TMEgZhFzkLeMpNMBMb6WQW2z/g1bL9+/anKmk907y 6geQr5W6XgeG2Bky8aOdSTgUIuHAM5WG6ceRbzynQgDOIqzF//+J1G45MW8iFxGjWWr+ honbdsj0GPXFN/WhOkSeT/vUsBYecGGHr04VcGqVhyM9e6FENlqtJvn4figI4pjPvMdR PgBKpMqwPPcw7IAwLUpXZz3fdlpmn1TRCgyx44iyV6zPmvBTsBIwga9rNiUMPIQuwjfa 2y0g==
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:from:date :message-id:subject:to:cc; bh=cM0JBQll8MG3xqiKVqsKny/Nbqr3yJQfPDlFbXJw3Io=; b=REweLnzNp/LdZwXvTXwhJFqU4zviREhaPf5WcOCaq4ECl0jRHoZEFsggdOnQLS7OmS ZGrA5aCiGhYZrVbxa1AnuU5JW4HTyyX6HO5SW8oGN3vsm9+kJ/R0AKGh5v1YDxZuorRk DISuyAUS53B6amlDFn9YkU6sy7hImstjhPs8ZXQjWmV3TfFU9OTHOC04B0I22UcB1XwR oeYxacaz+SlkTHmEjOLu5/QyIQxpBY+qSSolFp7o/G5fmyDqzcVZU37r2uSwuGIPd9nv yTtMCJnIyuV9PvAUGby73X8CnV1oHycYOq6+q3rfG+r8CVGZwxMRi3c9QB9GjtDoc3qT HZJA==
X-Gm-Message-State: AEkoouvFL4hyoa8klOsOTx70addywefq6rgdvjftXSq9QVGMckIJHmnuu4tGJHt8ByAcNpGYFQH5ZbiaaEn+Zw==
X-Received: by 10.31.231.3 with SMTP id e3mr34221350vkh.13.1470242028469; Wed, 03 Aug 2016 09:33:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Wed, 3 Aug 2016 09:33:47 -0700 (PDT)
In-Reply-To: <6cb1d9ce83c74799a8f8020e9114bd2c@EMEAWP-EXMB11.corp.brocade.com>
References: <201608021747.u72HlwWn028513@idle.juniper.net> <87265676-0F37-47EC-AB8B-B05920DB2AE9@tail-f.com> <6cb1d9ce83c74799a8f8020e9114bd2c@EMEAWP-EXMB11.corp.brocade.com>
From: Andy Bierman 
Date: Wed, 3 Aug 2016 09:33:47 -0700
Message-ID: 
To: William Ivory 
Content-Type: multipart/alternative; boundary=94eb2c095ca4d755c305392d6541
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Aug 2016 16:33:59 -0000

--94eb2c095ca4d755c305392d6541
Content-Type: text/plain; charset=UTF-8

On Wed, Aug 3, 2016 at 9:28 AM, William Ivory  wrote:

> Surely we should either evaluate on ALL non-presence containers, or none?
> After all, we evaluate 'default' and 'mandatory' anywhere in the config
> even if no actively configured nodes are anywhere in the vicinity?  Only
> evaluating to a depth of one level under configured nodes seems somewhat
> arbitrary.
>
>
The text currently says what you suggest.
But if the NP containers have no meaning as some claim,
then they only exist when descendant nodes with meaning exist.
Why do they exist if they have no meaning?


Regards,
>
> William
>


Andy


>
> -----Original Message-----
> From: Jan Lindblad [mailto:janl@tail-f.com]
> Sent: 03 August 2016 12:35
> To: Phil Shafer 
> Cc: William Ivory ; Andy Bierman ;
> Netconf 
> Subject: Re: [Netconf] What should a server response be? - depending on
> NP-containers
>
> > I wrote something for the last IETF that was described as completely
> > accurate technically but semantically confusing.  I would consider
> > this "always existing" to be similar.  The point to convey is that the
> > NP container is strictly an organizational node, and that their
> > presence in the hierarchy carries no meaning.  They are used when
> > containing other nodes and have no value when they do not contain
> > other nodes.  If none of the nodes they contain exist, they should not
> > be visible.  If one or more of the nodes they contain exist,
> > they should be visible.   Make them always exist adds confusion.
>
> I'm fine with this. Maybe we should clarify that must statements on NP
> containers are evaluated if the NP container parent exists. That's where
> the "always exists" notion might help understanding a bit.
>
> /jan
>
>

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




On Wed, Aug 3, 2016 at 9:28 AM, William Ivory <wivory@brocade.com=
> wrote:
Surely we should eithe=
r evaluate on ALL non-presence containers, or none?=C2=A0 After all, we eva=
luate 'default' and 'mandatory' anywhere in the config even=
 if no actively configured nodes are anywhere in the vicinity?=C2=A0 Only e=
valuating to a depth of one level under configured nodes seems somewhat arb=
itrary.



The text currently says what you sugge=
st.
But if the NP containers have no meaning as some claim,
=

then they only exist when descendant nodes with meaning exist.=C2=A0
Why do they exist if they have no meaning?



Regards,



William


Andy
=
=C2=A0



-----Original Message-----

From: Jan Lindblad [mailto:janl@tail-f.c=
om]

Sent: 03 August 2016 12:35

To: Phil Shafer <phil@juniper.net>

Cc: William Ivory <wivory@Brocade.com>; Andy Bierman <andy@yumaworks.com>; Netconf <netconf@ietf.org>

Subject: Re: [Netconf] What should a server response be? - depending on NP-=
containers



> I wrote something for the last IETF that was described as completely
> accurate technically but semantically confusing.=C2=A0 I would conside=
r

> this "always existing" to be similar.=C2=A0 The point to con=
vey is that the

> NP container is strictly an organizational node, and that their

> presence in the hierarchy carries no meaning.=C2=A0 They are used when=


> containing other nodes and have no value when they do not contain

> other nodes.=C2=A0 If none of the nodes they contain exist, they shoul=
d not

> be visible.=C2=A0 If one or more of the nodes they contain exist,

> they should be visible.=C2=A0 =C2=A0Make them always exist adds confus=
ion.



I'm fine with this. Maybe we should clarify that must statements on NP =
containers are evaluated if the NP container parent exists. That's wher=
e the "always exists" notion might help understanding a bit.



/jan







--94eb2c095ca4d755c305392d6541--


From nobody Wed Aug  3 12:45:38 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B60C12D7DE for ; Wed,  3 Aug 2016 12:45:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sATTKamol9Js for ; Wed,  3 Aug 2016 12:45:35 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0100.outbound.protection.outlook.com [104.47.33.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07AD412D13E for ; Wed,  3 Aug 2016 12:45:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0quJYiAgWMBmdz5KJEA+0+Ga/6EVSIFPfAOCEitiaWE=; b=P+AUILJ9lceV0XNjz2eICGr7EMU67jRz80OHvwo9X4WUHBdcD3pcPel2mrY2iBPlZynCNOXu8usPnMBLmHJ2dIGs1PxhquN+PSiU52fxJhDm4uVQDZKqt2g+Ln20nRhEzWYCAyvVn/iDMDgaKkqSY3Q+t3r73j+GQ3r39ijzE7A=
Received: from SN1PR05CA0017.namprd05.prod.outlook.com (10.163.68.155) by CY1PR0501MB2153.namprd05.prod.outlook.com (10.164.3.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.557.8; Wed, 3 Aug 2016 19:45:32 +0000
Received: from BN1BFFO11FD038.protection.gbl (2a01:111:f400:7c10::1:150) by SN1PR05CA0017.outlook.office365.com (2a01:111:e400:5197::27) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.549.5 via Frontend Transport; Wed, 3 Aug 2016 19:45:32 +0000
Authentication-Results: spf=softfail (sender IP is 66.129.239.19) smtp.mailfrom=juniper.net; yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=juniper.net;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.19 as permitted sender)
Received: from P-EMFE01C-SAC.jnpr.net (66.129.239.19) by BN1BFFO11FD038.mail.protection.outlook.com (10.58.144.101) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.8 via Frontend Transport; Wed, 3 Aug 2016 19:45:32 +0000
Received: from magenta.juniper.net (172.17.27.123) by P-EMFE01C-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 3 Aug 2016 12:45:32 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id u73JjUx23403;	Wed, 3 Aug 2016 12:45:30 -0700 (PDT)	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id u73Jg8ol039135;	Wed, 3 Aug 2016 15:42:09 -0400 (EDT)	(envelope-from phil@idle.juniper.net)
Message-ID: <201608031942.u73Jg8ol039135@idle.juniper.net>
To: Jan Lindblad 
In-Reply-To: <87265676-0F37-47EC-AB8B-B05920DB2AE9@tail-f.com>
Date: Wed, 3 Aug 2016 15:42:08 -0400
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:66.129.239.19; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(2980300002)(189002)(199003)(81156014)(81166006)(106466001)(110136002)(97736004)(189998001)(7846002)(53416004)(69596002)(305945005)(7696003)(1076002)(92566002)(87936001)(356003)(8676002)(48376002)(50466002)(54356999)(5003940100001)(77096005)(86362001)(11100500001)(8276002)(76506005)(105596002)(47776003)(586003)(2950100001)(68736007)(50986999)(4326007)(2906002)(2810700001)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB2153; H:P-EMFE01C-SAC.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD038; 1:e/4ODL7EfSDDMv51iGfFy77gKZp3lAQjEdRKk30lP5Jk7iNXrjUj6YLJGNT62YNneHCxu7JuLrWpNzkQbyvjoRSETHtv3XE51tUbW19ozuEvJ731KKUhJqdlDwFSJei05hz7vsKYHbZVlMKELh+nPjNpViWeLlwIQJqUUvhDA6FYA5uGeV7VLFzZn19KcBdgkLF91hUG9MOh8iH3lZ7YrgsGgQydhGMeJu6gUWuoopslq0e9DaVSAYRW9KXVCrjxlGDkraABP3OchwCPILNwOhSAPib/lnYBrza3MoFsWw7rQGdpNP6wNb5vjT+Twu/jmrReVqdTcDdVXb3ZmyZccz2pqOOylOK86RmAWgwFxYgRqUGWT+Dk/0R5NF4nnez9JXkaT+uPYuLjEfVxlN33pytry6agjrFttQLjj9QW4syfbYDjaZn7fGoD9hh2/hFEJt+han5mWbtn9nWttRy03Ha06cSFZFpIpM2Zy5aWBpBTy5OdWe2/an81BbrEdV9dRBNyvAbhp4nEA4Fbb7+io58vNXHd/db+nTbq9UFF8qKvHmxWZf0XLd/RKVyPGAq3
X-MS-Office365-Filtering-Correlation-Id: 0384c568-1dbb-4d53-be18-08d3bbd6bb4b
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2153; 2:hcFBNCHDN475OIPV4vilCjSP84cAhaz8gLTXWgUBvbmfqb4iOtH1G69yBie9bXJdOQTe6L4DNUayRKU9PnQP+nkWMi+D9k2Q2AG7InVyDFZoQuBRjLJIL9t4kJV84ZUTr4GYXRqzi2mUcVvUHM15nMuOkqADES8EXzGu7oX4fxs+uzB+B6goU5SPcHqUN/T+; 3:ATiHBofXlxhoDnKvWsVyMkv8B9l4i2uY2dfomL/v4xNqUdVjdYKXnIu1A6tD3NLSL9XxKBlO5nP4d5pphwF6UyV2kAVOOAE2fhmhu2BWFUoRXdPCq9/uoT83rMTdzU+9E5PjeOSHNmYYjbF7F2zUI14NQC6MroyQ/pH4ULXcH2okwfaB+sxkyBMGwbZVNpvyauL4nTgsu3Pu9crK6S99/y3LGPCw6xwhZruaPrT1tyM=
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB2153;
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2153; 25:BCpxquP0/m+SRu2Dz3eiaVBQGoZ6rZiunXtzoh7Iqt6PEnGbhMFGH0/XlwL/9RPWLJ8z4zFwNav8iEWlzeshumUE1mwXTtUBkYch299UXqkjgpHvtxpM/dYUiIX+lPYVw86dnLMDxbNS2Rmjgu/ZuJ6kgHxzJ1V/W0xIi6NygHX0LSPV6XIXuGh0GvlkTVCrKbKJDktqrcAuac6NvPiDb8iJY+rVNKChLGPlPHskz11b2wEEEOL5vXNULkDxqMm3Ozui7qAmXBCMKr3o5D8cqFya6gR8VP3Nn7LAsXRSSJCZs+Lg/ts/vIFL3GtlCO/9qXiLtlcyfJyNyzMzapwIxAOWIr8k3qQBhxrYuTiE0Tl2z421iqYoMC0mDhE6vgSFOWXpDBKhKLmBPkggKiGmpLQlDfqvm4gaUiGrso5UocIwye+RQ7s7L2Ikm3bjiuO04nFO6Fj2Q5ECttfbuvllks0OS2Z2xOzWCrzU5loI0RfRskLqtoYpJ4abn01zYUsKmKy133hKkEWDiDV4zdNoveUVTiK65WobatN5KG6/qHk9SF+ENimV7V/ZSbW2cYilrUE9B8PIQINbn1uUWorPvJpUok1zUs/06Low0YwsvhmZq98vMmZZlG2QoyuFbf42IvKyWJOxYb/23MdcrVw5DDX8HgG8/7HH8P6UnuEF3AGCI1pMnsczYRy4nWZYhjcS6LRJE/1BvIFF0NBOot/9liczMLfZMHGyC+VJftKBVvVPFBDAwcwoQyEc3B5iUxy/5qZ6fvTnxHQxG8Pga4l7MQ==
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2153; 31:5Ckqc1p/rSPPH6Oxopn3q50QEeZbEx3CiQvOA+j2Y1XaaZA9tOQnRgOzQnpdSheTBhe36j35Vv/j2nhieHh/wOoABU8Anm5Y9Ocs4GXRgj0Cz9zPwcpr/pxfV8qOoWUzCgUJWSE9uVnRELxQcuxdjBzEgAQQVYqObawGF60CnXZ4lDt/yr49S0ckeUBQORpTMuhIHiM/G4IvIb6A3H1oD5blU3HEZ1AELtVx5tvQk44=; 20:tj4xeSSLorLp4v4Lfp6xKfTiZ1xa1F6CIprz0o54k8TePQ3d1kQyf8QsGBrDl+786scnkm+BWzVKScc/Squlrl7kgjYsjyE7TSTystukPF03z4cqtytd1C8ivX9wWE0ndi0Q17ERwa+rjVFNqG9YqmJXn/jYqInu6Hbn8sjEHNiFMyb1bW99S3urE5l4C8jZLpjpCfdUB9qE+vbDmikN7PURvy4WLNXazVeLEWPs576c/Gl0/E+cCm7OlXjGWJdyNCV3EkyAfPfy+P7km1Yz04iIzqnym3gnUFwAxVwtOt+UVM35pkpaTNx09eSnJW2oDjbR0uWBcXKv7frJI76mrjFlQTJqVb4PW8B8Jkynp52GX+vCIYTkwr7geDon+/jRt5gZZlrrJkhkRjPzC6OwE9QZ7aNFmgPrFX6nmKEfuUVG2tGG07QhdTaKvIYux6o43hrMaN1HoO2l9kgwL+GhXBhPL7Jj6gxhRkUoCr4vW+uAAiBHrFGsSoJ9G99wCMMB
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13024025)(13015025)(13018025)(13023025)(13017025)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:CY1PR0501MB2153; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB2153; 
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2153; 4:zvtfG9SfDyjc7CLFejN6+N2CoY+Qe3MaG+taRg+1u7M7HUnPjUkPZw9Qjx/Agrnz1ppmsgb90N3/jgqn5ajWcCTcVa1of+7bvD8rReoRX/c9bEGekl66qpgjA2myAwDWyMacUce2ca6lBcHkSPhmhyEkkJp2fbFKxb/sn2AazlcdYvVhtOpV+4KubTCdiHExrCI5EqtDVKancHEiLBeJ+soRX6iXN68L/D8wHh/rUkojuN9VZQ1K7aVrliLO+3+nL4Tw/LWiptDiCERAVTwZwJvB58LzVEFmhGjzKGtuKPm4TmuUaRALG1+Qk83dBZDdys7W8uNW4onEvxRrM9zW2NlV2vVMFsD4fM9zL4w/E/pUdswQRLnZzGSiI9FLQdp83tRNDtb1qg1fa9c07ZtdHRj+7fILFuTP04xMiT13Qy9SFG36LFay3Z5uLeNLszyEnK2onAK5nEEoM3//jB7roHYaKMh7rXZOLWRPH+WtQrT4ptt/JHaaJVQggQqyAmKSPYRTXYh2ZzK8hdjKvAtpeA==
X-Forefront-PRVS: 00235A1EEF
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0501MB2153; 23:xFqwOQpYn60+JGShM0npvn6Ipa7bbqdlxnE5UHa?= =?us-ascii?Q?erjUCB98DI6GYTKJjdPlJQDcwRA4U0vy4DseASo390Jt2+w6ZlYLqJxQeLuU?= =?us-ascii?Q?LSmw2YJCZxGJlMVJ1ejBomJZY4dagMTGDMlEyPEzg58gTgUfVGQRwUkEudWi?= =?us-ascii?Q?h58BMZkUAe8YZWvk9+IGUuzStzDk4JkBfLjb5YBlOUO4CHXB1LV69RdSfhNh?= =?us-ascii?Q?OyfJ8kr4IELEtQ3ffjbkvcROU2r6+QCBxmUz4CJX8bBhLu8/ZtUQM/M+2PLw?= =?us-ascii?Q?vlnGi5gUJr1HYtTxqBCA2eqSoUQJbc57u276PFwjZPTgpzssIGiyziaKAQSV?= =?us-ascii?Q?MuME6Vz1g7PSBKrEqvkVMvuiMq8h4RUuZX0iajEBglBjyUdsEBVkScRxKZD2?= =?us-ascii?Q?fFGmZEgu1mDydk8jtLmnURJiqURucBwSu9J36WJ6TXbzMSZLD5TULKYZW1QJ?= =?us-ascii?Q?wX6Z4pU2Lo5DvnqJHZnAsRUJ8De45+XBSNlWmVeVEBUnYwYDsL93ORnzD74d?= =?us-ascii?Q?HziPSbpCDPxAGb/pkAFixM2cuo4OeZcbhuDKgD+0a9+s4rR0P3PPFr8aTbZ6?= =?us-ascii?Q?7G7utECbCC5deVRB0eF5YR+nuHR/QHxV7Z3+M2WKQB8hUk5Fxg/dP+HkPZgi?= =?us-ascii?Q?aGQGQ/jav4tKV82w1LT3FZhmPuYuQlProsAps7v5tOBxTf44p2DG11H8BpJy?= =?us-ascii?Q?Xwr+jT/SJnDYRbEY50icMbgHz8PRf72qs6dqxHaABOJheU9nRqHt18FuWwIl?= =?us-ascii?Q?N3tJxaxReXdaIv3DLRFI69vscv8r1UXjHlypizW+giww9dBAdmKF5d/jSPnq?= =?us-ascii?Q?8B4xvsXgm7KH0qe3tGn8qYICJ4G8SJKAOaLWAmMkwTQldab33UNboY+zR101?= =?us-ascii?Q?tH3Z15/R3urOJoLHYtqAyncTFO/co1MbtOVEZVgaGIly12cavhOcAkCA9dfG?= =?us-ascii?Q?Yq6Q1dXZv+kE4FMcyK9GlyoCkb4Kqo1iMz42/iyjT6ZAcsmc5mLsaE1XD2vm?= =?us-ascii?Q?bJhlaizUBB2RFWuMe7GPTRqvb?=
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB2153; 6:OjXbwvUT7enGJq+v84VZU0s9I6KdMoqNZ0pADFnvlP6AkKy1x/rsxKuk4XBKjFvcbT3C3YLSPFHSRfY6Z2OZB2XrpjvCTTfGu2lRzOcWzEXiSo0bTxy8mVFCL6zBj1VLrNh1dLoOOwmv7rdrySAY7yHVUnMr0Nzer/yC6xJljIVzuMV+ad3zEUQvhfB5mK5vVpazZXAT/WApVgAKISVBYF4L3IUXK8z4OiKiXlNEmN6l6QesXbJGBdxO+VXgiXngnf54YwsVE8ZBgAgbUHNgBQZp+6m9ox3hkssw/nwfMFnmlX8l4UMKQhAkLLDtXfJO8mOFBqhADkGdgU0S4IsgLQ==; 5:o0btPhiBEvdy+FXKXMGxxsCRQC7IzpH3ICaSD97PeMvngTskciMXwQkYTfPM0LMPC6p/OSgZQ7m/xoR8/FZ/I+lCOqYuNHuUptAmutbX4ZB2MYMqTNX8bgZTGfo35h5bXVSfP6ogYzqZOQ5wcwisIA==; 24:Wm0AVJ0Ic/Jcbiuge+s0AGsBAwGtrBJ1OOePLCXp3ezjrUpgYcYqJZ260gxgnqsLjjR5HouoYI676Dkurfz3xv8sQyE0yC8A2vcU5Zi4fDI=; 7:jXpJqQ5qVuRw/ja7TQTOaNYe88y9LwXuxJakJ/ZETMLcsN/5ZpEg5OdBEtQ98FQdD9mqR/HOhXKP7SyCU0578V6hDX06bUq/+3MtwM3oiTHNVV+cG2yDWgr6aZwKpwiyhINjbA4oEip/OIdgxLkcNrOknzcLi+Uwch/uUWSipzKJTcgVgbErQkr5+X+PvXBf1XxOGdS6YEB9bwXpLyCSU8KbjZcq8xllnoAzXxSkuIF7FPR3J1zH9a3DLEKRLPgt
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Aug 2016 19:45:32.5482 (UTC)
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.19];  Helo=[P-EMFE01C-SAC.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB2153
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Aug 2016 19:45:37 -0000

Jan Lindblad writes:
>I'm fine with this. Maybe we should clarify that must statements on NP
>containers are evaluated if the NP container parent exists. That's where
>the "always exists" notion might help understanding a bit.

Or say that their existance is meaningless and carries no semantic
value, and must/when conditions should never consider or depend
on their existence.

Thanks,
 Phil


From nobody Wed Aug  3 16:18:10 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D9612D81C for ; Wed,  3 Aug 2016 16:18:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Level: 
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6bUYP2g67n6 for ; Wed,  3 Aug 2016 16:18:06 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 94FC912D60A for ; Wed,  3 Aug 2016 16:18:06 -0700 (PDT)
Received: from syd-vpn-client-255-189.cisco.com (unknown [64.104.248.208]) by mail.tail-f.com (Postfix) with ESMTPSA id 317391AE0187; Thu,  4 Aug 2016 01:18:00 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_AB8325DB-3CB6-4554-A20D-77B661E9E576"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail
From: Jan Lindblad 
In-Reply-To: <201608031942.u73Jg8ol039135@idle.juniper.net>
Date: Thu, 4 Aug 2016 01:17:55 +0200
Message-Id: <5846F578-CFCE-4EB8-96B4-7E605336B43D@tail-f.com>
References: <201608031942.u73Jg8ol039135@idle.juniper.net>
To: Mahesh Jethanandani , Phil Shafer , Andy Bierman , William Ivory 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 03 Aug 2016 23:18:09 -0000

--Apple-Mail=_AB8325DB-3CB6-4554-A20D-77B661E9E576
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_9B965FCF-23CE-4CA0-B153-51622B9C70D8"


--Apple-Mail=_9B965FCF-23CE-4CA0-B153-51622B9C70D8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Mahesh Jethanandani writes:

> 1. Errata in YANG 1.1 Section 7.5.7 to clarify that NP containers =
exist (and return values) when it contains a node. Some suggested text.

That must statements on NP containers SHOULD be considered only when it =
contains a node is problematic.

First of all, I find a SHOULD on whether a must statement is evaluated =
or not deeply problematic. Secondly, even if this was turned into a MUST =
iff, I find this difficult in practice.

With this definition, a reader would have a hard time knowing whether =
the must statement applies. The reader would have to go through the full =
contents of the container, check if any leaf has a mandatory or default =
statement in it, or if any subordinate container, grouping or typedef =
does, transitively. For a container with three leaf children, fine, but =
there are containers out there where this would take more than an hour =
to find out.

And what about RFC 6020 section 10? It says that the addition of a =
default statement is considered a backwards-compatible model change. =
Such changes could easily modify the semantics of existing must =
statements on containers.

So while I can see some appeal with the suggested text, in practice I =
think it's a bad idea to tie the evaluation of NP container must =
statements to the existence of child nodes.


Andy Bierman writes:

> The text currently says what you suggest.
> But if the NP containers have no meaning as some claim,

Well, this claim comes from RFC 6020:

7.5.1 .  Containers =
with Presence

   YANG supports two styles of containers, those that exist only for
   organizing the hierarchy of data nodes, and those whose presence in
   the configuration has an explicit meaning.

   In the first style, the container has no meaning of its own, existing
   only to contain child nodes.  This is the default style.

> then they only exist when descendant nodes with meaning exist.
> Why do they exist if they have no meaning?

As humans, we like to organize things. We could have written
leaf ipv4-enabled { ... }
leaf ipv4-forwarding { ... }
leaf ipv4...
list ipv4-address { ... }
leaf ipv6-enabled { ... }
leaf ipv6-forwarding { ... }
...

For us humans, this set of data is easier to consume if we added some =
structure with containers. Logically, the information content is the =
same regardless which form we use.

This is what we have done for decades in our CLIs. To reflect existing =
CLI structure, we need the containers. The YANG models already out there =
prove this point well.

In existing CLIs, certain keywords exist in the command syntax only to =
group related commands together. If you type only the stem of this =
command, that will have no effect. I've never heard operators discussing =
whether the stem "exists" or not. This is what I have a need to model. I =
have been using NP containers for this.

IOS:
class-map X ip dscp ...
class-map X ip presedence ...
In itself "class-map X ip" doesn't do anything.

FTOS:
hardware watchdog
In itself "hardware" doesn't do anything.

JUNOS:
system host-name ...
system autoinstallation ...
In itself "system" doesn't do anything.


If we have to build our NETCONF servers such that they can remember a =
"creation" of "class-map X ip", "hardware" and "system", what value =
would that add? The underlaying OS has no notion of any existence of =
these "objects".


Phil Shafer writes:

> Jan Lindblad writes:
>> I'm fine with this. Maybe we should clarify that must statements on =
NP
>> containers are evaluated if the NP container parent exists. That's =
where
>> the "always exists" notion might help understanding a bit.
>=20
> Or say that their existance is meaningless and carries no semantic
> value, and must/when conditions should never consider or depend
> on their existence.

I agree, but the issue of when must statements sitting on an NP =
container are evaluated needs some clarification.

/jan


--Apple-Mail=_9B965FCF-23CE-4CA0-B153-51622B9C70D8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


Mahesh Jethanandani writes:

1. =
Errata in YANG 1.1 Section 7.5.7 to clarify that NP containers exist =
(and return values) when it contains a node. Some suggested =
text.

That must statements on NP containers SHOULD be considered =
only when it contains a node is problematic.

First of all, I find a SHOULD on =
whether a must statement is evaluated or not deeply problematic. =
Secondly, even if this was turned into a MUST iff, I find this difficult =
in practice.

With this definition, a reader would have a hard time knowing =
whether the must statement applies. The reader would have to go through =
the full contents of the container, check if any leaf has a mandatory or =
default statement in it, or if any subordinate container, grouping or =
typedef does, transitively. For a container with three leaf children, =
fine, but there are containers out there where this would take more than =
an hour to find out.

And what about RFC 6020 section 10? It says that the addition =
of a default statement is considered a backwards-compatible model =
change. Such changes could easily modify the semantics of existing must =
statements on containers.

So while I can see some appeal with the suggested text, in =
practice I think it's a bad idea to tie the evaluation of NP container =
must statements to the existence of child nodes.


Andy =
Bierman writes:

The text currently =
says what you suggest.
But if the NP containers have no meaning =
as some claim,

Well, this claim comes from RFC =
6020:

7.5.1.  Containers with =
Presence


   YANG supports two styles of containers, those that exist only for
   organizing the hierarchy of data nodes, and those whose presence in
   the configuration has an explicit meaning.

   In the first style, the container has no meaning of its own, existing
   only to contain child nodes.  This is the default style.

then they only exist when descendant nodes with meaning =
exist. 
Why do they exist if they have no =
meaning?

As =
humans, we like to organize things. We could have =
written 
leaf ipv4-enabled { ... }
leaf =
ipv4-forwarding { ... }
leaf ipv4...
list =
ipv4-address { ... }
leaf ipv6-enabled { ... }
leaf =
ipv6-forwarding { ... }
...

For us humans, this set of data is easier to =
consume if we added some structure with containers. Logically, the =
information content is the same regardless which form we =
use.

This is what we have done for =
decades in our CLIs. To reflect existing CLI structure, we need the =
containers. The YANG models already out there prove this point =
well.

In existing CLIs, certain =
keywords exist in the command syntax only to group related commands =
together. If you type only the stem of this command, that will have no =
effect. I've never heard operators discussing whether the stem "exists" =
or not. This is what I have a need to model. I have been using NP =
containers for this. 

IOS:
class-map X ip dscp =
...
class-map X ip presedence ...
In itself =
"class-map X ip" doesn't do anything.

FTOS:
hardware watchdog
In =
itself "hardware" doesn't do anything.

JUNOS:
system host-name =
...
system autoinstallation ...
In itself "system" =
doesn't do anything.


If we have to build our NETCONF servers such that =
they can remember a "creation" of "class-map X ip", "hardware" and =
"system", what value would that add? The underlaying OS has no notion of =
any existence of these "objects".


Phil Shafer writes:

Jan Lindblad =
writes:
I'm fine with =
this. Maybe we should clarify that must statements on NP
containers are evaluated if the NP container parent exists. =
That's where
the "always exists" notion might help =
understanding a bit.

Or say =
that their existance is meaningless and carries no semantic
value, and must/when conditions should never consider or =
depend
on their existence.

I =
agree, but the issue of when must statements sitting on an NP container =
are evaluated needs some clarification.

/jan

=

--Apple-Mail=_9B965FCF-23CE-4CA0-B153-51622B9C70D8--

--Apple-Mail=_AB8325DB-3CB6-4554-A20D-77B661E9E576
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJXonujAAoJEBSCnbqufIisns0IAJ5tMaQXF/zjHbjg07asCEz4
tYzvntYlBdbKwH2chVamGtMJf7I6VWq1+KFlHsue3ZaRhJ2qspRFkoszE4DIRCpb
69ramKN8QMdcV7AMC5femw/2gWgZcZ5CIO7alvqCEsBEqTw4kyq8HVKqjeHKglU2
Es2i39IdLVlDx13N+U+KQe416kfzTcRxrwSHEQp/362YW05vrR9CXhJDGUyiH1yx
EWbXknSjCzCUTJGv1VRLkU7k/W19Eg8D/uaTPSWVkQht/N0+qbFuuDwjCHkGdzga
SptiMzWzDBk+QOL4RVdTOot4d19lIlf2ZAc2jaxA+qBF3UOkMc2LjPAV0rXX3lg=
=eh8b
-----END PGP SIGNATURE-----

--Apple-Mail=_AB8325DB-3CB6-4554-A20D-77B661E9E576--


From nobody Thu Aug  4 02:54:38 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6AF12D67B for ; Thu,  4 Aug 2016 02:54:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.808
X-Spam-Level: 
X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KniUFsLR0HFY for ; Thu,  4 Aug 2016 02:54:34 -0700 (PDT)
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 5CF1C12D91A for ; Thu,  4 Aug 2016 02:54:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=947; q=dns/txt; s=iport; t=1470304464; x=1471514064; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=rwjHnj02aibiKzg4t6CMN/Ra2/sMo0d4UhpfoRsihDk=; b=BSGw5Lh0kMPiG6HqK3oZTzh597p7Nxp+YnblaLkKCKkBmImrNp99Km/D bu30aQbVr6xvnyvTkq5EUZf4NWwChek0EGh5BGg+odpbB0PMqZbGgq5+x Xm+t6/cjRQVqXeGubr5swlxmLuoU7X9Mez262OmLflgCqgsJ9/8lS3X1w Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ArCgB4D6NX/xbLJq1dhBsqUrkggX0kh?= =?us-ascii?q?S9KAoIKEgEBAQEBAQFdJ4ReAQEEAQEBNi8HCxALGC4nMAYBDAYCAQGIJQgOvxQ?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYqgXiCVYQqhXEBBJk0jwCJVIVsiGiDS?= =?us-ascii?q?IN3JQolg3s7MoglAQEB?=
X-IronPort-AV: E=Sophos;i="5.28,470,1464652800"; d="scan'208";a="638527085"
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; 04 Aug 2016 09:54:22 +0000
Received: from [10.63.23.91] (dhcp-ensft1-uk-vla370-10-63-23-91.cisco.com [10.63.23.91]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u749sMks019740; Thu, 4 Aug 2016 09:54:22 GMT
To: Phil Shafer , Jan Lindblad 
References: <201608031942.u73Jg8ol039135@idle.juniper.net>
From: Robert Wilton 
Message-ID: <5a49581e-71ef-4be9-1e51-62213901a887@cisco.com>
Date: Thu, 4 Aug 2016 10:54:22 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <201608031942.u73Jg8ol039135@idle.juniper.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 Aug 2016 09:54:36 -0000

On 03/08/2016 20:42, Phil Shafer wrote:
> Jan Lindblad writes:
>> I'm fine with this. Maybe we should clarify that must statements on NP
>> containers are evaluated if the NP container parent exists. That's where
>> the "always exists" notion might help understanding a bit.
> Or say that their existance is meaningless and carries no semantic
> value, and must/when conditions should never consider or depend
> on their existence.
Does that mean that for an empty NP container, it would be up to the 
server to decide whether or not to evaluate the containers must/when 
statements?  But if the NP container exists due to existence of child 
nodes then the must/when statements would be guaranteed to be evaluated 
by the server?

Thanks,
Rob


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


From nobody Thu Aug  4 04:16:28 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A8A12DEBC for ; Thu,  4 Aug 2016 04:16:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.497
X-Spam-Level: 
X-Spam-Status: No, score=-3.497 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jr7vqU-daUP for ; Thu,  4 Aug 2016 04:16:24 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 40E4212DD9B for ; Thu,  4 Aug 2016 04:13:22 -0700 (PDT)
X-AuditID: c1b4fb2d-fa6bb98000000190-e9-57a3234feda6
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by  (Symantec Mail Security) with SMTP id E3.8E.00400.F4323A75; Thu,  4 Aug 2016 13:13:19 +0200 (CEST)
Received: from [159.107.197.129] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.3.301.0; Thu, 4 Aug 2016 13:13:10 +0200
To: Mahesh Jethanandani , Jan Lindblad 
References: <201608021747.u72HlwWn028513@idle.juniper.net> <87265676-0F37-47EC-AB8B-B05920DB2AE9@tail-f.com> 
From: Balazs Lengyel 
Message-ID: 
Date: Thu, 4 Aug 2016 13:13:09 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUyM2K7t66/8uJwg+s3VSz+z+pjtDj9Zh2b xdRNt1kdmD12zrrL7rFkyU8mj42/FrMEMEdx2aSk5mSWpRbp2yVwZfQsvshUMEWx4sd++QbG /SJdjJwcEgImEh3/5jB3MXJxCAmsZ5TYduwTC4SzhlHi94m/zCBVwgLhEm+frmEDsUUEgiW+ XV8GVbSQUWLjjUawBLOAnMTiHz1MIDabgJHE1P7zLCA2r4C9xN3uk2A1LAIqEs++tAMN5eAQ FYiRWN+XAFEiKHFy5hMWkDCngK1Ez38fiIn6Etfv3GeFsOUlmrfOBjtHSEBD4uGFv6wTGAVm IemehaRlFpKWBYzMqxhFi1OLi3PTjYz1Uosyk4uL8/P08lJLNjECA/Xglt+6OxhXv3Y8xCjA wajEw6tguChciDWxrLgy9xCjBAezkggvr+LicCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8/i8V w4UE0hNLUrNTUwtSi2CyTBycUg2MrXbK/s8mbZjx31hR81XVDv7aNf5s0fPW1c0sv27TpZgp t/DZ/agDf5qOH4uJEEmaWOVb5/H3gtt1hd7tFUUxszfkbZ71Y5vF8nnHIlqUGzkXubD//75O 0ulVTHYvV4E618T+JHEXzc2tUwvbLR/d622ayX1nxnmhqVPn5egu+35yjzaDp4GTEktxRqKh FnNRcSIAhPC5i1ACAAA=
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 Aug 2016 11:16:26 -0000


  
    
  
  
    
Hello Mahesh,

    

    I like your text if you clarify that a deleted NP-container MUST not
    be reason for an edit-config operation=none to fail.

    Balazs

    

    
On 2016-08-03 17:18, Mahesh
      Jethanandani wrote:

    

    

      
      
3. Errata in YANG 1.1. to add the following
        clarification in the same section (7.5.8)

      


      

      


      

      

        

          

            

              

                

                  

                    
OLD:

                    

                      


                        

                      
 If
                          a container does not have a "presence"
                          statement and the last

                      

                          child node is deleted, the NETCONF server MAY
                          delete the container.

                      


                      

                      
NEW:

                      


                      

                      

                        

                            If a container does not have a "presence"
                            statement and the container instance

                        

                            does not have any child node instances, the
                            NETCONF server MAY delete the

                        

                            container. If the server does delete a
                            container instance in this case, it MUST

                      

                      

                          re-create the container instance if a client
                          <edit-config> request attempts to create

                      
 a
                          child node instance within this container.

                    

                  

                

              

            

          

        

      

    

    BALAZS: This good, but it MUST be reworded so default-operation=none
    shall also succeed.

    ADD: or if an edit-config with
      default-operation=none references the container instance.

      

      I feel the "none" case is not handled clearly enough yet. 

    

    
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com 


  



From nobody Thu Aug  4 04:28:25 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0721212DEBA for ; Thu,  4 Aug 2016 04:28:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.188
X-Spam-Level: 
X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oiMZJeIxwwFs for ; Thu,  4 Aug 2016 04:28:20 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id BFDAF12DEB4 for ; Thu,  4 Aug 2016 04:21:10 -0700 (PDT)
Received: from syd-vpn-client-247-181.cisco.com (unknown [64.104.248.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 266F61AE0198; Thu,  4 Aug 2016 13:21:06 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_DFB3F972-4A2E-44DB-A555-A244DD6F1668"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail
From: Jan Lindblad 
In-Reply-To: <5a49581e-71ef-4be9-1e51-62213901a887@cisco.com>
Date: Thu, 4 Aug 2016 13:21:00 +0200
Message-Id: <0066A47E-240F-4B6B-920B-98B064CE1E60@tail-f.com>
References: <201608031942.u73Jg8ol039135@idle.juniper.net> <5a49581e-71ef-4be9-1e51-62213901a887@cisco.com>
To: Robert Wilton 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 Aug 2016 11:28:24 -0000

--Apple-Mail=_DFB3F972-4A2E-44DB-A555-A244DD6F1668
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Rob,

>> Jan Lindblad writes:
>>> I'm fine with this. Maybe we should clarify that must statements on =
NP
>>> containers are evaluated if the NP container parent exists. That's =
where
>>> the "always exists" notion might help understanding a bit.
>> Or say that their existance is meaningless and carries no semantic
>> value, and must/when conditions should never consider or depend
>> on their existence.
> Does that mean that for an empty NP container, it would be up to the =
server to decide whether or not to evaluate the containers must/when =
statements?

That would be terrible. It must be completely clear when must statements =
are evaluated and when not.

>  But if the NP container exists due to existence of child nodes then =
the must/when statements would be guaranteed to be evaluated by the =
server?

I think there is no argument that must statements on NP containers MUST =
be evaluated when the container has child nodes. In my previous message, =
in the preceding text you didn't quote, I tried to explain why I think =
it's a bad idea to not also evaluate the must statements when the NP =
container is empty. In many real cases, it's not easy for a model reader =
to know whether the container has child nodes or not.

/jan


--Apple-Mail=_DFB3F972-4A2E-44DB-A555-A244DD6F1668
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJXoyUcAAoJEBSCnbqufIis+wQH/0Pd2cN4dx7n9qTHrRXHRB4Y
/jymF7fqjsJ26SvJ7WDFwuKe2RKraJ568wIQZvmfeuN2+cinol/d5XCJEj5m3ZJN
hwqOnrswU9Bdhps/DDNXrGSrEck5buB1NlfnK9O8VjsjsLm/gu1RBlKNA0HynId0
alomYiEj+1Naabu/vl3TNq2SXDJ3ZzQ8+ahuUcNM2tmYmT7KjBSKMp7fVRtkwisY
8cU00fYDQvnQ+KNU/J1xXfo929kTNn6bld7BTPYlDR/wj14tEhpnor3FvTqNkoGs
UJ9ka99ZNJBhnlpJoQMz+wip9DvYTlMXkaiqExgFjPtgwMeziNnhK0K2/trx8CA=
=Berp
-----END PGP SIGNATURE-----

--Apple-Mail=_DFB3F972-4A2E-44DB-A555-A244DD6F1668--


From nobody Thu Aug  4 05:29:13 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B3912DA1B for ; Thu,  4 Aug 2016 05:29:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.808
X-Spam-Level: 
X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AxIJ4zrhySA for ; Thu,  4 Aug 2016 05:29:10 -0700 (PDT)
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 1894212D9CF for ; Thu,  4 Aug 2016 05:27:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2221; q=dns/txt; s=iport; t=1470313680; x=1471523280; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=bu5c5OmyMy6FUSiA1Zy9KNC7DZgRMz58X/I30V1bxpI=; b=J98ToHqMWULEXrQSgm8d7Z9gIBTwWU09EfPpO9ABG/3z9fs0JEAxZebj 1ar5SZTmyUe6tjHBY/aMKjlcgYrRoubF8KnL8Fya3lPYPcNGe3cCaBtxy Xu9HOIqSys4rE8+VXuTeVXhLtfsBkiX3vXxLhCLekqwkjPzy2rMekOxy+ I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CUCgD3M6NX/xbLJq1dhEW7aoYdAoIOE?= =?us-ascii?q?QEBAQEBAQFdJ4ReAQEEATgvEgULCxguVwYNCAEBiCUIvmYBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBASCGKoF4glWEKoVxAQSZNI8CgWuHaSOFSYhpg0iDdzQgghIcgU07h38BA?= =?us-ascii?q?QE?=
X-IronPort-AV: E=Sophos;i="5.28,470,1464652800"; d="scan'208";a="638554834"
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; 04 Aug 2016 12:27:58 +0000
Received: from [10.63.23.91] (dhcp-ensft1-uk-vla370-10-63-23-91.cisco.com [10.63.23.91]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u74CRvh5019999; Thu, 4 Aug 2016 12:27:57 GMT
To: Jan Lindblad 
References: <201608031942.u73Jg8ol039135@idle.juniper.net> <5a49581e-71ef-4be9-1e51-62213901a887@cisco.com> <0066A47E-240F-4B6B-920B-98B064CE1E60@tail-f.com>
From: Robert Wilton 
Message-ID: 
Date: Thu, 4 Aug 2016 13:27:57 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <0066A47E-240F-4B6B-920B-98B064CE1E60@tail-f.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 Aug 2016 12:29:12 -0000

Hi Jan,


On 04/08/2016 12:21, Jan Lindblad wrote:
> Rob,
>
>>> Jan Lindblad writes:
>>>> I'm fine with this. Maybe we should clarify that must statements on NP
>>>> containers are evaluated if the NP container parent exists. That's where
>>>> the "always exists" notion might help understanding a bit.
>>> Or say that their existance is meaningless and carries no semantic
>>> value, and must/when conditions should never consider or depend
>>> on their existence.
>> Does that mean that for an empty NP container, it would be up to the server to decide whether or not to evaluate the containers must/when statements?
> That would be terrible. It must be completely clear when must statements are evaluated and when not.
It can't be that terrible, doesn't YANG 1.0 manage today with this 
behaviour? :-)

I guess that my point is thus:  if a NP container's must/when condition 
should never consider/depend on the existence of said NP container, then 
for an empty NP container it should make no difference as to whether or 
not they they are evaluated by the device.

I question whether it is sensible to allow when/must statements on an NP 
container at all.  In many ways I would rather that they were restricted 
to only schema nodes that actually exist as datanodes, at least then the 
semantics are obvious, no special magic behaviour is required.


>
>>   But if the NP container exists due to existence of child nodes then the must/when statements would be guaranteed to be evaluated by the server?
> I think there is no argument that must statements on NP containers MUST be evaluated when the container has child nodes. In my previous message, in the preceding text you didn't quote, I tried to explain why I think it's a bad idea to not also evaluate the must statements when the NP container is empty.

> In many real cases, it's not easy for a model reader to know whether the container has child nodes or not.
Yes.  I had read Phil's suggestion as: don't write must/when statements 
that depend on the existence of an NP container.  This sounds like quite 
sensible advise to me, but I might have misunderstood what he was 
suggesting.

Thanks,
Rob

>
> /jan
>


From nobody Thu Aug  4 05:40:14 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 025CC12D0BE for ; Thu,  4 Aug 2016 05:40:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lk4M_MElOz7g for ; Thu,  4 Aug 2016 05:40:11 -0700 (PDT)
Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (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 1451112B03B for ; Thu,  4 Aug 2016 05:40:11 -0700 (PDT)
Received: from pps.filterd (m0000542.ppops.net [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u74Cc6OA007076; Thu, 4 Aug 2016 05:40:09 -0700
Received: from brmwp-exmb12.corp.brocade.com ([208.47.132.227]) by mx0a-000f0801.pphosted.com with ESMTP id 24kkbsbver-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 04 Aug 2016 05:40:09 -0700
Received: from EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) by BRMWP-EXMB12.corp.brocade.com (172.16.59.130) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Thu, 4 Aug 2016 06:40:08 -0600
Received: from EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) by EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Thu, 4 Aug 2016 14:40:06 +0200
Received: from EMEAWP-EXMB11.corp.brocade.com ([fe80::85ea:b7da:48dd:1640]) by EMEAWP-EXMB11.corp.brocade.com ([fe80::85ea:b7da:48dd:1640%21]) with mapi id 15.00.1156.000; Thu, 4 Aug 2016 14:40:06 +0200
From: William Ivory 
To: Robert Wilton , Jan Lindblad 
Thread-Topic: [Netconf] What should a server response be? - depending on NP-containers
Thread-Index: AQHR65HjCKulpI0Pc0iHx2JTqSf796AzNTEAgADP0wCAAALRgIAAJAdA///nFYCAACJxEIABQD0AgABduACAASohAIAAiBoAgADuHQCAABg0AIAAErWAgAAidtA=
Date: Thu, 4 Aug 2016 12:39:37 +0000
Deferred-Delivery: Thu, 4 Aug 2016 12:38:45 +0000
Message-ID: 
References: <201608031942.u73Jg8ol039135@idle.juniper.net> <5a49581e-71ef-4be9-1e51-62213901a887@cisco.com> <0066A47E-240F-4B6B-920B-98B064CE1E60@tail-f.com> 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.27.212.173]
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-04_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 impostorscore=0 lowpriorityscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608040137
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 Aug 2016 12:40:13 -0000

Hi Rob,

What about a must statement on a NP-container that implements mutual exclusivity with another node, eg the following when top is configured:

Container top {
	Container np1 {
		Must "not(../np2_leaf)";
		Leaf np1_leaf { type string; }
	}
	Container np2 {
		Leaf np2_leaf { type string; }
	}
}

At first glance, I think many people would assume this was intended to prevent both np1_leaf and np2_leaf being configured at the same time.  However, if we configure np2_leaf, container 'top' is configured, so we evaluate the must on np1 (as a np container child of an existing node, as per YANG 1.1 stated requirements) and the must statement evaluates to false.  Therefore we cannot configure np2_leaf *ever* in this case.

Now you could argue this is badly modelled YANG, but I would suggest it's decidedly non-obvious that np2_leaf is not configurable here.

Regards,

William

-----Original Message-----
From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Robert Wilton
Sent: 04 August 2016 13:28
To: Jan Lindblad 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers

Hi Jan,


On 04/08/2016 12:21, Jan Lindblad wrote:
> Rob,
>
>>> Jan Lindblad writes:
>>>> I'm fine with this. Maybe we should clarify that must statements on 
>>>> NP containers are evaluated if the NP container parent exists. 
>>>> That's where the "always exists" notion might help understanding a bit.
>>> Or say that their existance is meaningless and carries no semantic 
>>> value, and must/when conditions should never consider or depend on 
>>> their existence.
>> Does that mean that for an empty NP container, it would be up to the server to decide whether or not to evaluate the containers must/when statements?
> That would be terrible. It must be completely clear when must statements are evaluated and when not.
It can't be that terrible, doesn't YANG 1.0 manage today with this behaviour? :-)

I guess that my point is thus:  if a NP container's must/when condition should never consider/depend on the existence of said NP container, then for an empty NP container it should make no difference as to whether or not they they are evaluated by the device.

I question whether it is sensible to allow when/must statements on an NP container at all.  In many ways I would rather that they were restricted to only schema nodes that actually exist as datanodes, at least then the semantics are obvious, no special magic behaviour is required.


>
>>   But if the NP container exists due to existence of child nodes then the must/when statements would be guaranteed to be evaluated by the server?
> I think there is no argument that must statements on NP containers MUST be evaluated when the container has child nodes. In my previous message, in the preceding text you didn't quote, I tried to explain why I think it's a bad idea to not also evaluate the must statements when the NP container is empty.

> In many real cases, it's not easy for a model reader to know whether the container has child nodes or not.
Yes.  I had read Phil's suggestion as: don't write must/when statements that depend on the existence of an NP container.  This sounds like quite sensible advise to me, but I might have misunderstood what he was suggesting.

Thanks,
Rob

>
> /jan
>

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=CwICAg&c=IL_XqQWOjubgfqINi2jTzg&r=GByLeg9jZvOv_AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=751sECIaA5HaNM0wQdHxLvA6UwL5IhKW91y_u8ZrZ2Y&s=x12_Ko8id4YJBVF1rFmAvbKVrZCHdIHsFnzswwJ1k68&e= 


From nobody Thu Aug  4 06:10:11 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E4A12D512 for ; Thu,  4 Aug 2016 06:10:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.808
X-Spam-Level: 
X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTUogEXnmiFr for ; Thu,  4 Aug 2016 06:10:05 -0700 (PDT)
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 07CED12B03B for ; Thu,  4 Aug 2016 06:10:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4639; q=dns/txt; s=iport; t=1470316205; x=1471525805; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=hqamlGEpES9l7I8kxEFH7vAG6QGO36YuhZBG6TVR950=; b=hbGAfewBCP0uVnv6al6pqLMDhRVsFN3hicmG9mJo2O4wHpAh1H0EWgdj iVqJQTcn28AkvYUOwVbG9ovX7jxGZOIMxXlt7t5mNNUV0AabHBDTbcCND gRnlkLaQecZE70jnK3xIsZbX8prmvIN6szfYaAuRsokYrSQaGduoHjmpa g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CdCgDOPaNX/xbLJq1dhBsqUrsYIIV9A?= =?us-ascii?q?oIeAQEBAQEBXieEXgEBBAE4LwcLDAQLDgMEAQEBJwdGCQgGAQwGAgEBiCUIvmo?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQEchiqBeIJVhCoWhVsBBJk0hhqIaIFrTocbI?= =?us-ascii?q?4VJiGmDSIN3VIISHIFNOzKHTQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.28,470,1464652800"; d="scan'208";a="639583698"
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; 04 Aug 2016 13:10:02 +0000
Received: from [10.63.23.91] (dhcp-ensft1-uk-vla370-10-63-23-91.cisco.com [10.63.23.91]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u74DA2JQ032493; Thu, 4 Aug 2016 13:10:02 GMT
To: William Ivory , Jan Lindblad 
References: <201608031942.u73Jg8ol039135@idle.juniper.net> <5a49581e-71ef-4be9-1e51-62213901a887@cisco.com> <0066A47E-240F-4B6B-920B-98B064CE1E60@tail-f.com>  
From: Robert Wilton 
Message-ID: <05ea80f8-665b-d9b7-53db-207fc862409e@cisco.com>
Date: Thu, 4 Aug 2016 14:10:02 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 Aug 2016 13:10:09 -0000

Hi William,

On 04/08/2016 13:39, William Ivory wrote:
> Hi Rob,
>
> What about a must statement on a NP-container that implements mutual exclusivity with another node, eg the following when top is configured:
>
> Container top {
> 	Container np1 {
> 		Must "not(../np2_leaf)";
> 		Leaf np1_leaf { type string; }
> 	}
> 	Container np2 {
> 		Leaf np2_leaf { type string; }
> 	}
> }
>
> At first glance, I think many people would assume this was intended to prevent both np1_leaf and np2_leaf being configured at the same time.  However, if we configure np2_leaf, container 'top' is configured, so we evaluate the must on np1 (as a np container child of an existing node, as per YANG 1.1 stated requirements) and the must statement evaluates to false.  Therefore we cannot configure np2_leaf *ever* in this case.
>
> Now you could argue this is badly modelled YANG, but I would suggest it's decidedly non-obvious that np2_leaf is not configurable here.
RW:

Yes, exactly.  This is why I don't like must statements on np 
containers.  Enforcing a constraint on an construct that doesn't 
properly exist is a bit odd :-)

I would suggest that it would be clearer to write this as:

Container top {
   Container np1 {
     Leaf np1_leaf {
       type string;
       must "not(../../np2_leaf)";
     }
   }
   Container np2 {
     Leaf np2_leaf {
       type string;
     }
   }
}

or perhaps:

Container top {
   Container np1 {
     Leaf np1_leaf {
       type string;
       must "not(../../np2_leaf)";
     }
   }
   Container np2 {
     Leaf np2_leaf {
       type string;
       must "not(../../np1_leaf)";
     }
   }
}

Thanks,
Rob


>
> Regards,
>
> William
>
> -----Original Message-----
> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Robert Wilton
> Sent: 04 August 2016 13:28
> To: Jan Lindblad 
> Cc: Netconf 
> Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
>
> Hi Jan,
>
>
> On 04/08/2016 12:21, Jan Lindblad wrote:
>> Rob,
>>
>>>> Jan Lindblad writes:
>>>>> I'm fine with this. Maybe we should clarify that must statements on
>>>>> NP containers are evaluated if the NP container parent exists.
>>>>> That's where the "always exists" notion might help understanding a bit.
>>>> Or say that their existance is meaningless and carries no semantic
>>>> value, and must/when conditions should never consider or depend on
>>>> their existence.
>>> Does that mean that for an empty NP container, it would be up to the server to decide whether or not to evaluate the containers must/when statements?
>> That would be terrible. It must be completely clear when must statements are evaluated and when not.
> It can't be that terrible, doesn't YANG 1.0 manage today with this behaviour? :-)
>
> I guess that my point is thus:  if a NP container's must/when condition should never consider/depend on the existence of said NP container, then for an empty NP container it should make no difference as to whether or not they they are evaluated by the device.
>
> I question whether it is sensible to allow when/must statements on an NP container at all.  In many ways I would rather that they were restricted to only schema nodes that actually exist as datanodes, at least then the semantics are obvious, no special magic behaviour is required.
>
>
>>>    But if the NP container exists due to existence of child nodes then the must/when statements would be guaranteed to be evaluated by the server?
>> I think there is no argument that must statements on NP containers MUST be evaluated when the container has child nodes. In my previous message, in the preceding text you didn't quote, I tried to explain why I think it's a bad idea to not also evaluate the must statements when the NP container is empty.
>> In many real cases, it's not easy for a model reader to know whether the container has child nodes or not.
> Yes.  I had read Phil's suggestion as: don't write must/when statements that depend on the existence of an NP container.  This sounds like quite sensible advise to me, but I might have misunderstood what he was suggesting.
>
> Thanks,
> Rob
>
>> /jan
>>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=CwICAg&c=IL_XqQWOjubgfqINi2jTzg&r=GByLeg9jZvOv_AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=751sECIaA5HaNM0wQdHxLvA6UwL5IhKW91y_u8ZrZ2Y&s=x12_Ko8id4YJBVF1rFmAvbKVrZCHdIHsFnzswwJ1k68&e=
> .
>


From nobody Thu Aug  4 06:28:19 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E532812D097 for ; Thu,  4 Aug 2016 06:28:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwA4JtjYGrWw for ; Thu,  4 Aug 2016 06:28:12 -0700 (PDT)
Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (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 0768A12D901 for ; Thu,  4 Aug 2016 06:28:11 -0700 (PDT)
Received: from pps.filterd (m0048192.ppops.net [127.0.0.1]) by m0048192.ppops.net (8.16.0.11/8.16.0.11) with SMTP id u74DS00Y022372; Thu, 4 Aug 2016 06:28:10 -0700
Received: from brmwp-exmb11.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 24kkuybtsu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 04 Aug 2016 06:28:10 -0700
Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by BRMWP-EXMB11.corp.brocade.com (172.16.59.77) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Thu, 4 Aug 2016 07:28:08 -0600
Received: from EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) by EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Thu, 4 Aug 2016 15:28:07 +0200
Received: from EMEAWP-EXMB11.corp.brocade.com ([fe80::85ea:b7da:48dd:1640]) by EMEAWP-EXMB11.corp.brocade.com ([fe80::85ea:b7da:48dd:1640%21]) with mapi id 15.00.1156.000; Thu, 4 Aug 2016 15:28:06 +0200
From: William Ivory 
To: Robert Wilton , Jan Lindblad 
Thread-Topic: [Netconf] What should a server response be? - depending on NP-containers
Thread-Index: AQHR65HjCKulpI0Pc0iHx2JTqSf796AzNTEAgADP0wCAAALRgIAAJAdA///nFYCAACJxEIABQD0AgABduACAASohAIAAiBoAgADuHQCAABg0AIAAErWAgAAidtD//+lMAIAAItBQ
Date: Thu, 4 Aug 2016 13:27:42 +0000
Deferred-Delivery: Thu, 4 Aug 2016 13:27:24 +0000
Message-ID: <5d8503f67066406a992738b766556247@EMEAWP-EXMB11.corp.brocade.com>
References: <201608031942.u73Jg8ol039135@idle.juniper.net> <5a49581e-71ef-4be9-1e51-62213901a887@cisco.com> <0066A47E-240F-4B6B-920B-98B064CE1E60@tail-f.com>   <05ea80f8-665b-d9b7-53db-207fc862409e@cisco.com>
In-Reply-To: <05ea80f8-665b-d9b7-53db-207fc862409e@cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.27.212.173]
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-04_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 impostorscore=0 lowpriorityscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608040143
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 Aug 2016 13:28:17 -0000

So I quite agree that there are better ways of writing this.  However, my initial YANG is valid, and at first glance it is tempting to write it that way unless you have been following this discussion thread (-:

The YANG 1.1 behaviour gives what I think some (many?) would see as unexpected behaviour.  If treated as clarification for YANG 1.0 (ie it applies to YANG 1.0 retrospectively) then we could end up invalidating currently valid YANG 1.0 models if they have any examples like mine below.  Conversely, Jan's ownership-voucher example would become invalid if we don't take the YANG 1.1 behaviour and retrospectively apply it to YANG 1.0.

I'm also not convinced that only evaluating musts on NP containers to one level below configured nodes is consistent with how we deal with defaults and mandatory statements.  For those we examine all possible nodes, configured or otherwise, at any depth in the tree.  I think we should either never evaluate must statements on NP containers which have no children, or we should always evaluate them at any depth in the tree.  What's so special about those that are children of a configured node versus those that are grandchildren (or more)?

I would be interested to hear from those who have written YANG models (as opposed to those implementing YANG compilers) as to the perceived impact of the different options on your existing models.  Internally our YANG 1.0 models have been written on the assumption we do not evaluate musts on NP containers with no child nodes, but it would be reasonably easy to add 'not(current() or ...' to the front of any such must statements to render the outcome of this discussion irrelevant by ensuring the statements evaluate true when the NP container is not configured and thus effectively ignoring the constraint when not configured.

Regards,

William

-----Original Message-----
From: Robert Wilton [mailto:rwilton@cisco.com] 
Sent: 04 August 2016 14:10
To: William Ivory ; Jan Lindblad 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers

Hi William,

On 04/08/2016 13:39, William Ivory wrote:
> Hi Rob,
>
> What about a must statement on a NP-container that implements mutual exclusivity with another node, eg the following when top is configured:
>
> Container top {
> 	Container np1 {
> 		Must "not(../np2_leaf)";
> 		Leaf np1_leaf { type string; }
> 	}
> 	Container np2 {
> 		Leaf np2_leaf { type string; }
> 	}
> }
>
> At first glance, I think many people would assume this was intended to prevent both np1_leaf and np2_leaf being configured at the same time.  However, if we configure np2_leaf, container 'top' is configured, so we evaluate the must on np1 (as a np container child of an existing node, as per YANG 1.1 stated requirements) and the must statement evaluates to false.  Therefore we cannot configure np2_leaf *ever* in this case.
>
> Now you could argue this is badly modelled YANG, but I would suggest it's decidedly non-obvious that np2_leaf is not configurable here.
RW:

Yes, exactly.  This is why I don't like must statements on np containers.  Enforcing a constraint on an construct that doesn't properly exist is a bit odd :-)

I would suggest that it would be clearer to write this as:

Container top {
   Container np1 {
     Leaf np1_leaf {
       type string;
       must "not(../../np2_leaf)";
     }
   }
   Container np2 {
     Leaf np2_leaf {
       type string;
     }
   }
}

or perhaps:

Container top {
   Container np1 {
     Leaf np1_leaf {
       type string;
       must "not(../../np2_leaf)";
     }
   }
   Container np2 {
     Leaf np2_leaf {
       type string;
       must "not(../../np1_leaf)";
     }
   }
}

Thanks,
Rob


>
> Regards,
>
> William
>
> -----Original Message-----
> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Robert 
> Wilton
> Sent: 04 August 2016 13:28
> To: Jan Lindblad 
> Cc: Netconf 
> Subject: Re: [Netconf] What should a server response be? - depending 
> on NP-containers
>
> Hi Jan,
>
>
> On 04/08/2016 12:21, Jan Lindblad wrote:
>> Rob,
>>
>>>> Jan Lindblad writes:
>>>>> I'm fine with this. Maybe we should clarify that must statements 
>>>>> on NP containers are evaluated if the NP container parent exists.
>>>>> That's where the "always exists" notion might help understanding a bit.
>>>> Or say that their existance is meaningless and carries no semantic 
>>>> value, and must/when conditions should never consider or depend on 
>>>> their existence.
>>> Does that mean that for an empty NP container, it would be up to the server to decide whether or not to evaluate the containers must/when statements?
>> That would be terrible. It must be completely clear when must statements are evaluated and when not.
> It can't be that terrible, doesn't YANG 1.0 manage today with this 
> behaviour? :-)
>
> I guess that my point is thus:  if a NP container's must/when condition should never consider/depend on the existence of said NP container, then for an empty NP container it should make no difference as to whether or not they they are evaluated by the device.
>
> I question whether it is sensible to allow when/must statements on an NP container at all.  In many ways I would rather that they were restricted to only schema nodes that actually exist as datanodes, at least then the semantics are obvious, no special magic behaviour is required.
>
>
>>>    But if the NP container exists due to existence of child nodes then the must/when statements would be guaranteed to be evaluated by the server?
>> I think there is no argument that must statements on NP containers MUST be evaluated when the container has child nodes. In my previous message, in the preceding text you didn't quote, I tried to explain why I think it's a bad idea to not also evaluate the must statements when the NP container is empty.
>> In many real cases, it's not easy for a model reader to know whether the container has child nodes or not.
> Yes.  I had read Phil's suggestion as: don't write must/when statements that depend on the existence of an NP container.  This sounds like quite sensible advise to me, but I might have misunderstood what he was suggesting.
>
> Thanks,
> Rob
>
>> /jan
>>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> man_listinfo_netconf&d=CwICAg&c=IL_XqQWOjubgfqINi2jTzg&r=GByLeg9jZvOv_
> AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=751sECIaA5HaNM0wQdHxLvA6UwL5IhKW91y_u
> 8ZrZ2Y&s=x12_Ko8id4YJBVF1rFmAvbKVrZCHdIHsFnzswwJ1k68&e=
> .
>


From nobody Thu Aug  4 07:55:27 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2045E12D5F7 for ; Thu,  4 Aug 2016 07:55:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhKkpW2STQbp for ; Thu,  4 Aug 2016 07:55:18 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0A54812D58A for ; Thu,  4 Aug 2016 07:55:16 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 36F731CC00A1; Thu,  4 Aug 2016 16:55:23 +0200 (CEST)
From: Ladislav Lhotka 
To: Jan Lindblad , Phil Shafer 
In-Reply-To: <87265676-0F37-47EC-AB8B-B05920DB2AE9@tail-f.com>
References: <201608021747.u72HlwWn028513@idle.juniper.net> <87265676-0F37-47EC-AB8B-B05920DB2AE9@tail-f.com>
User-Agent: Notmuch/0.22.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Thu, 04 Aug 2016 16:55:17 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 Aug 2016 14:55:21 -0000

Jan Lindblad  writes:

> [ Unknown signature status ]
>> I wrote something for the last IETF that was described as completely
>> accurate technically but semantically confusing.  I would consider
>> this "always existing" to be similar.  The point to convey is that
>> the NP container is strictly an organizational node, and that their
>> presence in the hierarchy carries no meaning.  They are used when
>> containing other nodes and have no value when they do not contain
>> other nodes.  If none of the nodes they contain exist, they should
>> not be visible.  If one or more of the nodes they contain exist,
>> they should be visible.   Make them always exist adds confusion.
>
> I'm fine with this. Maybe we should clarify that must statements on NP
> containers are evaluated if the NP container parent exists. That's

I think the rules should be the same as for leaves with default values
that are in use (sec. 7.6.1). We could introduce the term "default
content" that includes leaf/leaf-list nodes with default values and
NP-containers.

An implication of this is that a must statement on an NP-container that
is inside the default case of a choice also applies, but that should be
OK.

Of course, another question is whether empty NP-containers are included
in server's responses or not, but this is IMO up to each protocol to
decide this.

Lada

> where the "always exists" notion might help understanding a bit.
>
> /jan
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

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


From nobody Thu Aug  4 08:02:38 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE62B12D5B4 for ; Thu,  4 Aug 2016 08:02:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level: 
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTIazuiggKTS for ; Thu,  4 Aug 2016 08:02:35 -0700 (PDT)
Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (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 7E75712D541 for ; Thu,  4 Aug 2016 08:02:35 -0700 (PDT)
Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-05v.sys.comcast.net with SMTP id VKABbMFxR2FGMVKAMbqukO; Thu, 04 Aug 2016 15:02:34 +0000
Received: from hobgoblin.ariadne.com ([73.100.16.189]) by comcast with SMTP id VKALb47YDX5ezVKAMbIJkN; Thu, 04 Aug 2016 15:02:34 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u74F2XLr022151; Thu, 4 Aug 2016 11:02:33 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u74F2WeU022148; Thu, 4 Aug 2016 11:02:32 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com (Dale R. Worley)
To: William Ivory 
In-Reply-To: <5d8503f67066406a992738b766556247@EMEAWP-EXMB11.corp.brocade.com> (wivory@Brocade.com)
Sender: worley@ariadne.com (Dale R. Worley)
Date: Thu, 04 Aug 2016 11:02:32 -0400
Message-ID: <874m70efw7.fsf@hobgoblin.ariadne.com>
X-CMAE-Envelope: MS4wfDw81oxlDM3RY2tEXD7FW564RkvW5FAsUATzx+vvN9ns+vnSgfxqVY+K0UQxwDqHRe1svQ/IXyYMy8HiDndeogAEJSaTTnBq4vueFeqQWDFyke4BsZNS REMtD6ZFG8c/zerd3B8JIsqCV44Oqwn/nmnb8wYl35auomIfqIg/25IEXpF7DApEjqkbPg5gpdhMSsVTfqWWiuwvebFFVjbgFZyeczPIhaD7l3GsWHPkoUKC fl91Z1BDSxNKpzwmNR8f4Q==
Archived-At: 
Cc: netconf@ietf.org
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 Aug 2016 15:02:38 -0000

William Ivory  writes:
> So I quite agree that there are better ways of writing this.  However,
> my initial YANG is valid, and at first glance it is tempting to write
> it that way unless you have been following this discussion thread (-:

That's true.  I'd say my thesis is that NP containers MUST NOT have must
statements, and any XPath expression MUST NOT test for the presence of
an NP container node.  (I think it might be desirable in some
circumstances to return it as a member of a result set, especially if
the XPath expression is attached to a descendant node.)

Dale


From nobody Thu Aug  4 08:04:00 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3A312D0CC for ; Thu,  4 Aug 2016 08:03:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level: 
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3k5Qa12b9Z3 for ; Thu,  4 Aug 2016 08:03:58 -0700 (PDT)
Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (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 F164A12B031 for ; Thu,  4 Aug 2016 08:03:54 -0700 (PDT)
Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-12v.sys.comcast.net with SMTP id VKAobESRRxBKTVKBebK43O; Thu, 04 Aug 2016 15:03:54 +0000
Received: from hobgoblin.ariadne.com ([73.100.16.189]) by comcast with SMTP id VKBdbUm6XMJgPVKBdbbo2b; Thu, 04 Aug 2016 15:03:54 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u74F3qXN022292; Thu, 4 Aug 2016 11:03:52 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u74F3qDO022289; Thu, 4 Aug 2016 11:03:52 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com (Dale R. Worley)
To: Robert Wilton 
In-Reply-To: <05ea80f8-665b-d9b7-53db-207fc862409e@cisco.com> (rwilton@cisco.com)
Sender: worley@ariadne.com (Dale R. Worley)
Date: Thu, 04 Aug 2016 11:03:52 -0400
Message-ID: <871t24eftz.fsf@hobgoblin.ariadne.com>
X-CMAE-Envelope: MS4wfP5o/ckp2xZBAoa8V2KUKqQOz3cyLeeLg2Yk8vwOIufRCNR4eR51GVIgl5bW+DAyyERVUmJIPB8GpjNzqwL1+SbtgRhafAvG6WTacYiwQJJu8DUfCBGE Bd/K6J87MKBLFZjHJthNQmxGCvllXoOWE2DzFw664criADsWQOhBah49/beZRkbor6JtewWl3HCm9uSTabh+fI/384mPoY3KgGLua+OBHQoearHMa9A9zQC6 fqGe/5iWao57I/qTr+OJOg==
Archived-At: 
Cc: netconf@ietf.org
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 Aug 2016 15:03:59 -0000

Robert Wilton  writes:
> Container top {
>    Container np1 {
>      Leaf np1_leaf {
>        type string;
>        must "not(../../np2_leaf)";
>      }
>    }
>    Container np2 {
>      Leaf np2_leaf {
>        type string;
>      }
>    }
> }

Should that be "not(../../np2/np2_leaf)", or can you can abbreviate
XPath by leaving out intermediate nodes?

Dale


From nobody Thu Aug  4 10:28:48 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36FC12D099 for ; Thu,  4 Aug 2016 10:28:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.808
X-Spam-Level: 
X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFr9zAPzlTQQ for ; Thu,  4 Aug 2016 10:28:45 -0700 (PDT)
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 F221312D633 for ; Thu,  4 Aug 2016 10:28:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=925; q=dns/txt; s=iport; t=1470331725; x=1471541325; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=uO6kzpM9zUDpioLYC14r+yY5neeKrX8EU+aWoml7AOo=; b=jDIb/5CfyMsHK6WJztmNq27wRFqL4JjvyqhwR3FCE6BwFRk4NSkgNxQN R4oA75VmV1Xgn9TmLtPoySO4D/Xyj9UbdjkFzgyQQnVnKWm4SGiSFca/P hcIsfDG8L5uKS08MFgV7VDkMn/CVN9thh2Ku5VB1w8utei5IwzbZv9mlc A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CVCgB5eqNX/xbLJq1dhEVSuxyGHQKCA?= =?us-ascii?q?xEBAQEBAQEBXSeEXwEFOEEQCxguVwYNBgIBAYgtvwwBAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BASCGKoF4glWEKoVxAQSZNI8CiVSFbIhpg0iDdzQgg3s7ModNAQEB?=
X-IronPort-AV: E=Sophos;i="5.28,470,1464652800"; d="scan'208";a="638610830"
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; 04 Aug 2016 17:28:43 +0000
Received: from [10.63.23.91] (dhcp-ensft1-uk-vla370-10-63-23-91.cisco.com [10.63.23.91]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u74HShkX032552; Thu, 4 Aug 2016 17:28:43 GMT
To: "Dale R. Worley" 
References: <871t24eftz.fsf@hobgoblin.ariadne.com>
From: Robert Wilton 
Message-ID: 
Date: Thu, 4 Aug 2016 18:28:42 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <871t24eftz.fsf@hobgoblin.ariadne.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netconf@ietf.org
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 Aug 2016 17:28:47 -0000

Hi Dale,

No, you are right, it should include the np2 container.

IIRC, Xpath does have syntax to allow layers to be missed out, perhaps 
something like "not(../..//np2_leaf)", although I don't know whether 
this format is allowed by YANG, and even if it was, I wouldn't be 
surprised if this unsupported by some YANG must/when statement 
processors because of the additional complexity and processing overhead.

Thanks,
Rob


On 04/08/2016 16:03, Dale R. Worley wrote:
> Robert Wilton  writes:
>> Container top {
>>     Container np1 {
>>       Leaf np1_leaf {
>>         type string;
>>         must "not(../../np2_leaf)";
>>       }
>>     }
>>     Container np2 {
>>       Leaf np2_leaf {
>>         type string;
>>       }
>>     }
>> }
> Should that be "not(../../np2/np2_leaf)", or can you can abbreviate
> XPath by leaving out intermediate nodes?
>
> Dale
> .
>


From nobody Thu Aug  4 11:22:05 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799A112D097 for ; Thu,  4 Aug 2016 11:22:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level: 
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBwukW972tWq for ; Thu,  4 Aug 2016 11:22:01 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0103.outbound.protection.outlook.com [104.47.36.103]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BD7812B019 for ; Thu,  4 Aug 2016 11:22:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OlOL09wBSOi69UQXKXQz43xr4pcaDdfD4TI5bCAmeCE=; b=Su4UShQSEi8CYEgWFRpdTmhfrOmolgj8hQqwCl2sNNWnJsDtzxRI+dcndXvTBX3d6wxo0bGOd8GOOnog3vB9HOVnG9dJwvfVejTrt3rT5jUydsAQNL4NmgDIwHJ/XvP6kp7EoomBQQNFKhz9W3ePhqLOFuakfapQ5j0n0hck6Qs=
Received: from CO2PR05CA034.namprd05.prod.outlook.com (10.141.241.162) by BLUPR05MB1954.namprd05.prod.outlook.com (10.162.224.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.557.8; Thu, 4 Aug 2016 18:21:58 +0000
Received: from BL2FFO11FD009.protection.gbl (2a01:111:f400:7c09::141) by CO2PR05CA034.outlook.office365.com (2a01:111:e400:1429::34) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.549.5 via Frontend Transport; Thu, 4 Aug 2016 18:21:57 +0000
Authentication-Results: spf=softfail (sender IP is 66.129.239.19) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.19 as permitted sender)
Received: from P-EMFE01C-SAC.jnpr.net (66.129.239.19) by BL2FFO11FD009.mail.protection.outlook.com (10.173.161.15) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.8 via Frontend Transport; Thu, 4 Aug 2016 18:21:58 +0000
Received: from magenta.juniper.net (172.17.27.123) by P-EMFE01C-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 4 Aug 2016 11:21:57 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id u74ILux61520;	Thu, 4 Aug 2016 11:21:56 -0700 (PDT)	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id u74IIY1E047694;	Thu, 4 Aug 2016 14:18:34 -0400 (EDT)	(envelope-from phil@idle.juniper.net)
Message-ID: <201608041818.u74IIY1E047694@idle.juniper.net>
To: Robert Wilton 
In-Reply-To: 
Date: Thu, 4 Aug 2016 14:18:34 -0400
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:66.129.239.19; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(2980300002)(199003)(189002)(54356999)(87936001)(50986999)(86362001)(5003940100001)(2906002)(68736007)(76506005)(4326007)(106466001)(110136002)(69596002)(2950100001)(1076002)(305945005)(47776003)(8276002)(7846002)(50466002)(48376002)(105596002)(92566002)(97736004)(53416004)(7696003)(77096005)(586003)(81156014)(8936002)(356003)(189998001)(81166006)(8676002)(2810700001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB1954; H:P-EMFE01C-SAC.jnpr.net; FPR:;  SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD009; 1:YNOTTgn7lANzOrTADOfZw56tXip/rUANvSMKoSuZWQ1AfAu0gRzx0qdCXQCynaHh6cfxLOhXa4rUtj/YI17u9ctHT7KiKoxBoEqmpM88nuk4SxbC3Fdyavpr/SJBpZnRNXtCmcdSDua6gl12jn4hx1At0yZRCpPpDq+poKCm61GRZlej04sg9M92wx3Exk5p8ejdbDhTkvT6925im7WTyv7KiC6Ql8RmTcjq8UIVsmm4fzwrj8zqNd9Eghdusb/4JP4yNuUmHqKTPZVCyFmA+5OlQTtGsUNcHFsWVnovY/P60oPfdhYeOJkzHf9yFKgi4dh7ZLuLSIZNBT31LMWa2/OWOr9KnDWvtMPn01LmaW9z4SHB0eLQELXZrwB70WF2ifgoF2dnhC7nVsvNk8cmq6SKcqWK5Y7Q3ph+3YO6VPBof7b0hUIgXNjTM4XrVFEbyOjIz6kUnKlwoXvB1NY5p2n5pgSnuRFo0SCeqbuly14EC5xytdwRnniFZDBar8e8DLHxudgqw5F01qLlEAPmVbB4WI4WmvjtklVodduO0iD4DfRvqcMaHMbQ9h+/VnaoZbu+cWbYv67ZyzL6+y2dtA==
X-MS-Office365-Filtering-Correlation-Id: 29232cbf-8ac7-4dda-52c5-08d3bc9438d4
X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB1954; 2:WSLPhy82bw8rSUiBJrdqepk1+voSvFCoVUV0TL6C66leu4DkANuwxAfC8/4fmAcWiWLtp3D1vZHKqpZFunm85pB7qsQfVrjhe6XXlccaKPNKthra1UJIKervWu7m16D6cO7UB3RyVPsEp/BE/dT35AiNQaNlmjKwPptNM+Olyaql+hqLbN69lYfTL1tVSSvu; 3:yZQ9BmqBQIuYt9B+qav/JbEoZh8yWaKktgUZ72FzbM7Us1/SRk4Ibb/QuDOLic8t+wpEsFB8r8G/Jk4njlas1WqN535qhHC/yG1o7rW9M+MucbT5jScT+dEorqGt8LNkJq0sgU5XJ3/NrtWp3MNKIScIJqWTxzwROiHyEEfUWZnF3NcEl6+P2AuGYv5bY/6FVWZvbZWvNOdbAEGZnaZ2gSHKcOxErtJGkxwwCKYBo1g=
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB1954;
X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB1954; 25:imzWRMxc7L46kod2QBllWNmOz+rVZM7w0SUVOOhcMspjxPbI7IrlnuMN40WaroELDdxIVFukQBVQBURVbuqn8cj781YWgsqrJmQVVjswa08z0QUJhyYRWcJQHUb/kgonGaWQo6QY+SHpClBp/Db/CYUcyMQksc5Y18GNLfMcKFnWwGZXmOFu8rCNganSSRabDzPJlLJZS9YGP82SExyzCui9ZIcOP9UQAFmb0r+V9ppSV2poh1+WoW8WJhSUT0YuLvteIsSoIbScmLouuj4kUq1+80pPpIwrL+BbfG3xv6vVi2oGEFYxaWOWWXijEZj+vTF2/wpk9mCbrShXUy2M9E57oRssuiUADkg4ctj4YJAMAkLYhi66WL7QIlnqqt6Ug/ogK0HhE0QyqRryn3FaMubbxWIHtw0aG80WUZwoppnlciSS7yOXsbdFsaAHFdNMzMdGB9ZESDnwMAWoAb+g5skcKZ4JbwXivRcrQpcfh8P3eV6Lq9OivMLVrcwOHzdXwbB53SkV4jQN+Sockk+sCULb4imVc/sLVjuQdRxSSJ/hMVqjoUPtOfRbzahwrTp5jMQZL0cvcBE5cMIlxgZZmNMfzPwcsLcAf765ioXWwyqF/2kQLqBznlo/XxlXM+qHBj7HaOzz0tJwSzxMTkG8pZTTeUtRkiSYlxCAtW72a/SmzLR0CfyX2MKAqkFcJSXzWNHmCIJQZeBskawmjeQZTAD/qOogbKXhm10S4WxNdvjUEojThqYVT1xaVl+gOt3U
X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB1954; 31:A0PKk6nfvAR1obVEm1WmDvou9fFaX0q5NTfl94RvTCqClQM7cPMrlccKZzjbHtm1Gua7gfCXwQHl4lKQM2Sb1YrmVDEw+YyrHfWm27U/d7ByOmSNlRguF55/ExVvEQEL52/STcbsvXI5llo5GkcBBF/ag9upERkMZY9YXRwccr7s7Cdqi7cewWHP7F9dXYospnkudmhfSSjrkhuUlL3jPFOEVErA2PSKizn69jfW/s0=; 20:ksevWMFAL2XPad0Vc84NJ8YjAiRiEsO2129bYvG6bATMkUMjkNkYIPjHdqKQaIMhT5zJRYS/ekot72CrsxLzH/HLfTx3+XVVlty2UBH2Y1tGJzV+GA0XaUG4OoQEXjuJvzm4munzG+gsfPF8la+qDB+AY13InI2i8PVjC9NtV/Mx4qevxbtYOfSkXU1yTAmLZP2wv3YB3N6xDIWVWrklUIXaMZhEiaUfPMTP7FOO8sf+q4ivJwI4QRKlKzSiuxewz/jbC/rsgFTGbapnKEv/qEO9YxrRRX/F4JJsRdJLXzAOCuSBV8NWxHfsyn9LNOki6A9dZfARO/yQQLWPemNfdf+EeKlxm0BNH+MP4H+qq2KEOG09tKYLaBMqClElKoJIyO9+FbDbtGLQDI4C1WaWV1LGqZMpIui5zM/HmAUaO1G4gb4XvbL85te27L8NlhbLnJ5rxmigJ3gtduxfJ8T/nSDSctUiJwDeKeYHY+yQ4eRF733aYIKF6hdgFdUnFZ93
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(13017025)(13018025)(13023025)(13024025)(13015025)(3002001)(10201501046)(6055026); SRVR:BLUPR05MB1954; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB1954; 
X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB1954; 4:abfpncZXBzvZQDmqG7v88SlfcidaMCJCCRNzSWjm9JmxnAVu9DdbRXaWV0Hoyd0/55R2sE90le9LBtw9UOzbpTiWK+SEsRSTxBJXosVNceyjw+b8WwWcgDiP8u4lwvUzj3OLwqavCssK7a0Eq/3VhDnzjtyuFlQlNNdCcmb+XO0MSFTLSjw0QfxmnqJhGrmYx6Yukhdw2kkZOuJs0ovOxp9Cp1o+ZZsc0ugElBR/9dsvShlOU+Yy1hlxKMinSVrT15AH3hDYQF530rOQAEWslmcm1iVQeC1iJXfQ7q9zBpRGPWL0xu5rhZi3WsYA6qCVtP6+4BScm2aIfaAave8e1P1oyVLgZGDPOaW3ZEF3dksdkiICnzu2jlWlLGa3V5O7uoxKbOTLVXsGAZkqmSTX5fzhYoWq+ZrzO8ji6mr9l6ng6WE4P2mjtVsjap6BVc0P3EfmiKqlMWEExY25VMoZ+t1rPmpu7RD/km+RbFenbABufNgh+DH+6AhehXqnLWNvqWHJ0nXuiQZ9dMUILfUUNA==
X-Forefront-PRVS: 00246AB517
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR05MB1954; 23:eKGH37ONzkzPdfMZOxEmMMQB19tPibLPlxAkEj8VO?= =?us-ascii?Q?IS9sW297A8KtLFzWScJa6sPJxMDOazOqHflJXIIrkNvWi058hu4Lt/YvUjRx?= =?us-ascii?Q?FfOYnygIxif9UVplBKtHD/G4jaiF4kjXWl3OpwekM4jbZru52xQsibqWb48B?= =?us-ascii?Q?nYfbClMFoO/vqEFdwwCF5jrmKyNDcWjg8x8TFAxxPMC7zMq2b/bxtNNrVody?= =?us-ascii?Q?vbLvamoW/PcSjSGbf7kINlQ1ugDOfHkF/ORxE21ra1Ka+agN+eKe+r/eUh5K?= =?us-ascii?Q?i3bDt6zFM+/zrqYPfSKwAIN49RWVYy2PBdTpqhS9ogtrN6nwJT7rl+rGMgtw?= =?us-ascii?Q?CDZ3dmKqAtf0fSm2VbQgNXF1oJOM323Zv9eKslsBybNqrgRtnbwsHZimOd6D?= =?us-ascii?Q?nOPajSeXRDpIftRsbKCwCmavO3mZGnL0Iq7DMGs53Ob2Gf8FeeR5u7L93dSJ?= =?us-ascii?Q?7v8b/uXjUVEj7EyhoAKFQJml7FMfyVOeBQxtyNbkWcswp8QPCK+fmZz1vhBv?= =?us-ascii?Q?WGM/RjWySP9TKzqtGvLQnzdW+CQ9bIHyruq7PHJVAxiHMHg/RY6Z2EJRsgd9?= =?us-ascii?Q?xNUJ12r1hiU4oqaK/KdvwIcV9cjYZQ7WVVKYwBFMOvQgTPnWDibyeIzBhg5m?= =?us-ascii?Q?KouK4MLqZfL/Lme8OrkIg23DRvJGtLpWAqM7ROISKzt/Tbk1UISYOE71T2UP?= =?us-ascii?Q?zP5Q5YDdH2eZm+7AQ7J2dMaep6OiIiUDNrGAdKV8suMtcytiUq3V15ZbiQ5O?= =?us-ascii?Q?bYnBaS1glk2sKiXGwWAgLhZLzSb4PmgIc1enC/yNFap8uB+4PGSFDkq9VNKg?= =?us-ascii?Q?ZjgD0GHxaXOJ0Y9dPabjHdqF7DQJi7jR8FAY5hySfF4SolvBsPETHLwU9WCK?= =?us-ascii?Q?kbSIbFXtKF+ezJAxjenIMVZxw8YbDGbo2qN18SCQrA1OzejSAKrAc0it2xW2?= =?us-ascii?Q?FX36lpTPbq+IjzNj9JdRq8cV1YmhkRwjmmi3qufgegMdjFiS+BbgWA3WTSd+?= =?us-ascii?Q?1Q=3D?=
X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB1954; 6:+IrXRZpRx3S8hTh2GGIISocjBeWyx8E7dkwWGT7n79369j2BU/fP/06AvtQEbKufGnImKv6thbalU0vtbE4chnD//+uAHgf6qdOmh5x5S93Nps8vmN8mvVKm/7qS/z5Q/13hVv/i1wap8HaYNGHtOWcHJsGe4NFrozUvfz7Q7rKS6yQscqzS78BHR0Zk3SpOOxk5hB6d833kA9DW952Eaoze8zx5TNYcRnQnUajgfUccR3FOnU01yz6DQ0Yvci7ALZ5SCVl5ivERTgo03C+bd3c1ClCmDjJ9L+TkDX/4R+Dy9NrILjUK+htxayJ5RWWTYDUatjfuTmErlxFyjQkvaw==; 5:jalf49w+yUGrHKY1fuGzkJzjeqvB0CsOEaFHAI07UmZYf0GkMa0+Xgq8FZCyJ/jTVlOIBeYGmuTj6bOpKMXuVLMFZdeMqGt6GCFqVLYhUr+iZC67g775T2jvX9giEj8vFRAjaf6x6JaMAcLtjzdSLw==; 24:ylEyz5SGoJ5tNTZu3Y384YfKdewWRlyUzTGW3cWIn5N5HzBgtSH2qG7c9Ue5yHQLYdX0yudPYUO5dAg8BwJejTjkxl3pOZ1F41m74RyXqsE=; 7:JZ5aIpoLPAIMSeza9QFeIxzI/VEFeLV1bkxQl9zqyj4+2QrDB2RAYYwtJZEeBadq8KnoOZWpJkaaKVmvR+0Emb3CqJL9IMorbFIBQ6Y4UlHpXn+B96a8IDGifNT8r7E3zAs0LiiCvcxQbvvP1klZ2XWYl1d7d/OvKoynz0SmDbX0oRrQVnX5bCQ8YrgjMrnRVjs04qtLFoQP/dSytw6hxBU4er2UJfEq8Q3q7PMjCU3IU6wFzTJrdGZsT0moR3Dd
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Aug 2016 18:21:58.0404 (UTC)
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.19];  Helo=[P-EMFE01C-SAC.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB1954
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 Aug 2016 18:22:03 -0000

Robert Wilton writes:
>I guess that my point is thus:  if a NP container's must/when condition 
>should never consider/depend on the existence of said NP container, then 
>for an empty NP container it should make no difference as to whether or 
>not they they are evaluated by the device.

And the natural outcome is that a "must"/"when" expression on an
NP container must always be validated without regard to the existence
of any NP container.

>I question whether it is sensible to allow when/must statements on an NP 
>container at all.  In many ways I would rather that they were restricted 
>to only schema nodes that actually exist as datanodes, at least then the 
>semantics are obvious, no special magic behaviour is required.

If we take the position above, then it won't matter.  Sometimes
it's more convenient or meaningful (to the reader) to place conditions
on the container.

Thanks,
 Phil


From nobody Thu Aug  4 11:46:43 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0227612DAC1 for ; Thu,  4 Aug 2016 11:46:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JexcJoJevZCK for ; Thu,  4 Aug 2016 11:46:39 -0700 (PDT)
Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C303A12B01B for ; Thu,  4 Aug 2016 11:46:37 -0700 (PDT)
Received: by mail-vk0-x236.google.com with SMTP id x130so174980959vkc.0 for ; Thu, 04 Aug 2016 11:46:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DcRACzEmdNK2/T2AP0g0REr55bp1VZRvxU4Dr48/uZM=; b=gv6ck0bFFTg7w1mXTjVES40ZDs1WNwv+FIEz/ykbyT8WscMI5e3BT3p5E5HYXeoggG TGZPB9k06oulEkzEROb0Qz98tLt5vcUqS2wW5HIPFt6w0RMy5t6UmSCM9wWlRlAVizzD qjicQzP+CAymTH6zZo44fehw469KYI1iOHOH+r9vndo8qofOE7MVl/T0ReZNSsZIuTj0 +NC7k4F10oJU8N2l22PC8oEm+V9v7cW43misX7OIj9E7/xYl4y6jpd76N1inxWhqoXI5 FlAUvU/DXIWB+4SauCyqJpABxMsEhh4xpcJtu9PFdmjbH3vpeQu7ws4hwlqJ6bZ7eqn8 2WyA==
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:from:date :message-id:subject:to:cc; bh=DcRACzEmdNK2/T2AP0g0REr55bp1VZRvxU4Dr48/uZM=; b=kjev13Ses/5Iv1TW55dEoUPrLB0jh4ARZIaUMflY7L1+AYfOSgw1ZtGCLyE2xpWSH6 BmQ9/2wlazA4qkAf95UZM94OZChyo5Q6kvoCG4fPA2q9rARRq03pBmYYNyMolWAXvXhX kj063Jt68TXzKSILGsVZ7W8lZ3W7ZU7wGciDNJjb11nMQ/aJ8rw8H0SN72h8utwpEh1d S0hIXHc4SoyrraLjHt/4VaQFPhGoGNAhRTLHgWJ19I1jYT6XGb05fqSX9RFJa7WIvn8Z KKE72JCRjnfU9JUdSdpmaVPgMA7E/Qjd/iSxR3bzhzoDgMelofotodI5uxJn96juDhqJ D4WQ==
X-Gm-Message-State: AEkoouutcG0A2IiArF3MdvYRrl9Z/gxxJx2LY+/OpYzhTiitd9JuF+oBF3o8I4RTK3P69STJIzmQoMbs7lerIg==
X-Received: by 10.31.252.203 with SMTP id a194mr33038751vki.44.1470336396887;  Thu, 04 Aug 2016 11:46:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Thu, 4 Aug 2016 11:46:35 -0700 (PDT)
In-Reply-To: <201608041818.u74IIY1E047694@idle.juniper.net>
References:  <201608041818.u74IIY1E047694@idle.juniper.net>
From: Andy Bierman 
Date: Thu, 4 Aug 2016 11:46:35 -0700
Message-ID: 
To: Phil Shafer 
Content-Type: multipart/alternative; boundary=94eb2c149bd4a34bc20539435e9a
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 Aug 2016 18:46:42 -0000

--94eb2c149bd4a34bc20539435e9a
Content-Type: text/plain; charset=UTF-8

On Thu, Aug 4, 2016 at 11:18 AM, Phil Shafer  wrote:

> Robert Wilton writes:
> >I guess that my point is thus:  if a NP container's must/when condition
> >should never consider/depend on the existence of said NP container, then
> >for an empty NP container it should make no difference as to whether or
> >not they they are evaluated by the device.
>
> And the natural outcome is that a "must"/"when" expression on an
> NP container must always be validated without regard to the existence
> of any NP container.
>
> >I question whether it is sensible to allow when/must statements on an NP
> >container at all.  In many ways I would rather that they were restricted
> >to only schema nodes that actually exist as datanodes, at least then the
> >semantics are obvious, no special magic behaviour is required.
>
> If we take the position above, then it won't matter.  Sometimes
> it's more convenient or meaningful (to the reader) to place conditions
> on the container.
>
>
But the main use-case for must-stmt inside the container are for constraints
on the child nodes.  For lists and P-containers, this works fine.



> Thanks,
>  Phil
>
>
Andy


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

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




On Thu, Aug 4, 2016 at 11:18 AM, Phil Shafer <phil@juniper.net><=
/span> wrote:
Robert Wilton writes:

>I guess that my point is thus:=C2=A0 if a NP container's must/when =
condition

>should never consider/depend on the existence of said NP container, the=
n

>for an empty NP container it should make no difference as to whether or=


>not they they are evaluated by the device.



And the natural outcome is that a "must"/"when" express=
ion on an

NP container must always be validated without regard to the existence

of any NP container.



>I question whether it is sensible to allow when/must statements on an N=
P

>container at all.=C2=A0 In many ways I would rather that they were rest=
ricted

>to only schema nodes that actually exist as datanodes, at least then th=
e

>semantics are obvious, no special magic behaviour is required.



If we take the position above, then it won't matter.=C2=A0 Sometimes
it's more convenient or meaningful (to the reader) to place conditions<=
br>
on the container.



But the main use-case for must-stmt in=
side the container are for constraints
on the child nodes.=C2=A0 =
For lists and P-containers, this works fine.

=C2=
=A0

Thanks,

=C2=A0Phil



Andy
=C2=A0

_______________________________________________

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mailman/listinfo/netconf<=
br>




--94eb2c149bd4a34bc20539435e9a--


From nobody Thu Aug  4 16:14:31 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6AFA12D5E9 for ; Thu,  4 Aug 2016 16:14:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level: 
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JL2h5B5HlspY for ; Thu,  4 Aug 2016 16:14:28 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0112.outbound.protection.outlook.com [104.47.41.112]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5599212D0C2 for ; Thu,  4 Aug 2016 16:14:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Q/X2gpehDA/4QuX/pLqO54Wdo39N4HsFJyR+nQl+KM8=; b=fuUlJPffD4hCoyB4WNB5L9/MIE6TpngvdA4hK3saL7TE1rRksAQOmKSpwaG9pbNHBnww/2mNJgeyegi61eEdu43SEnQohaw3jRKSMUx889+vMIMvD+BvItXK19sJYsxzpLhAmVyhRQNWHEXD/HRq2TGVRVG8ZYZA5r11/PlN3Nw=
Received: from SN1PR0501CA0018.namprd05.prod.outlook.com (10.163.126.156) by CY1PR05MB1962.namprd05.prod.outlook.com (10.162.216.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.557.8; Thu, 4 Aug 2016 23:14:25 +0000
Received: from BL2FFO11FD029.protection.gbl (2a01:111:f400:7c09::157) by SN1PR0501CA0018.outlook.office365.com (2a01:111:e400:52fe::28) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.549.5 via Frontend Transport; Thu, 4 Aug 2016 23:14:26 +0000
Authentication-Results: spf=softfail (sender IP is 66.129.239.19) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.19 as permitted sender)
Received: from P-EMFE01C-SAC.jnpr.net (66.129.239.19) by BL2FFO11FD029.mail.protection.outlook.com (10.173.160.69) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.8 via Frontend Transport; Thu, 4 Aug 2016 23:14:26 +0000
Received: from magenta.juniper.net (172.17.27.123) by P-EMFE01C-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 4 Aug 2016 16:14:25 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id u74NEOx61588;	Thu, 4 Aug 2016 16:14:24 -0700 (PDT)	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id u74NB2l2049513;	Thu, 4 Aug 2016 19:11:03 -0400 (EDT)	(envelope-from phil@idle.juniper.net)
Message-ID: <201608042311.u74NB2l2049513@idle.juniper.net>
To: Andy Bierman 
In-Reply-To: 
Date: Thu, 4 Aug 2016 19:11:02 -0400
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:66.129.239.19; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(2980300002)(189002)(199003)(68736007)(356003)(50986999)(189998001)(7846002)(87936001)(1076002)(11100500001)(305945005)(97736004)(7696003)(4326007)(106466001)(586003)(69596002)(110136002)(2810700001)(8936002)(2906002)(92566002)(47776003)(81166006)(5003940100001)(8276002)(2950100001)(50466002)(53416004)(8676002)(81156014)(76506005)(86362001)(105596002)(48376002)(54356999)(77096005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB1962; H:P-EMFE01C-SAC.jnpr.net; FPR:;  SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD029; 1:RTWaE+lfEVW5ZrDuWPTQeWbb1FZEDpuFvBl80wapGlEZaPk58dFoC/5hGxWEUnPY0bK2zBOT0tU2gcYXm7QlRwouN1omCOxGgcOvz/SLam4O+xMADXaFX5zsJ3Hh/e3c/G0SWrrqXcLXFkV/GsPB3UdPf/MyrNFgCpuBtVNFq+yvqwQdF9WLZDTObZLRVGlbuqnA2zrKUP0knxGRU9VIq1o37BRBGnYyiSbWBlqmTsSNTnIN8xzsVs3a5hADDz3P43GnyKIhMf5t6TIs1BCtIa7MotFrV5a2BLbwHNGXK1d8JsSY9lszGMjL9ls6KkSGQUrhWeXyH5RIGUksqovKVenEFjbVnHaWCXP56+VCOBwdXL8RfOjNAZqiRB2QW6b26+G19XIedAOZ02Di8mtv9GpJGr93cPdW6g1SrraCX8+UkLMerM6Bq9yTIL5De3w5Hjjqy0p8VKfpe2PyV4t3PRuNP83zxI4YYHqguKcBAmfEHYVJcE4O/uSon4QNc3x8Ywdznw52HNpClRBGn04x3Lnh1cWNguwkRxEcSTDoeIQR4Zv2KAqkUoXuajviN2X8zgmeJiTI3N183ie01uLX+w==
X-MS-Office365-Filtering-Correlation-Id: 4081c273-117c-452a-aa32-08d3bcbd1453
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB1962; 2:wIZ1zhA7rdJ2TKrX7SyAlsxnCckDBYubUHOpSxZdSPqEuootml2eHlhMzZQg5owwuzZpFL8qYq9ipL3/LhdZb560P+F42L0NnIUR8sXWczn/hPPeioly66b75vclIkNVux2X2JXgI51tk2qIqrJvHCXmsjc3fx0gyJNRN14ZKVyxa2zrRkw8T3hkfjHYd6cz; 3:y/3u1cryUCa8NuTHvkxWaIxeBE6mWNFy8z6Q5VYwyDE563m7YezW7DuuQ9TPCH9vWD1mUbm1TBFADkjEkQ1YfRLBAc2qhm9y+mhDqYpstC+KGIe1ElAWQm4+RSREKl3qcaQ+fxNO7ImwZdiiYbj2P6inpGkdqFTxjIK3wfQ7IPI7foy3odYDSN9hh5s0zqLSsnwmOCnP/XAkGlQdY7OE+mhgRMJITGzvWxpa1Ho7C5I=
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR05MB1962;
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB1962; 25:3Yjg+c1Ylq+ZWtsaTs2125dZz6hS6l9FU5WnH0EsvTNgB+RpDOd9D/90aSsuHXivWXXFSix/DqCraeVLlt1Kgcz1UTjwDACgkrLl1DXXUNOeWri5RtcxUx+2cGhzOEPeMqr0mLaDrhWVPIW9Yu/gIzUcufjb+tjvAIpl1Xlr2eI86Q+Kxi4v0M4aAMNrryX41TqeUjSFrhcq1oDar2ocAo83Lta0IdMEEzdDoI8puzolpg+aM7lUasmq93OhlS+BcZ2UsZ6HxcMjFRFT/pH9tQLM9D+VcZlp96X1JX3npbv95mZ0/voxjrbz5/D8VTm694FGk5/YhyknhcEdp0nrOE2/NEhbmIHGK+NZ4IgjPb5cw31CoekC1lNyIACpL9YRcLz3rPfo64GIa00Nk68Sc2HfOpnmh+5RktH4oLMHcC8aGBzaZSWRp/BVOFR+/Vl/3M3xivShneLiQTHJAjWaSRv654rnBVN4sucpyMDiDhYOmpjH/UDi2AvxxUKFnZSKrD6ir2wCIqGrcrjeDok9c47x+u8G0RPc/oWbybP8L+bdLMW8ebUj1huiOk4ualyZM92nPPOZtZ7Mlzk+yr4irfDIGv7e/VgH0HK+LcoeCCwY7py+rPDAU6KgU7qnaF88zg4j/MtVNTVf6Um84vTUz0jq8D+FWWEI/iv4sc325RZcI9SS5rnrbYWW1BKMHWpaXQdsTISjESe7RNdZkn/7VpcXArRVbeBLkySOYUY40piXXAhZp6MOQixgGGqY7W4R
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB1962; 31:xdJQm62LnnsWvk+o3Xp5fmNHKsgOCjrAvZw9926i9Y2vKGTVlp4YUEy3yucWiRwjPsdF2BdSwqex0dQwe0Cjo1AQo5lncABBnDVDxSwrnv2ClBKyg8CBceZPYmmJNeAxAUpzUmctZLZnvbwLLlXhcNJ1Aqn6pD020wuHyWaXSeFV5b9mpflMqtTwzyM97mqgD7hmbspRPj50ACvIJ091XLJQtSbPA67fACmGdCv01pY=; 20:BkP4HAnj/qo7aSoO8R8SVrrEmhACTw/bRAMipXx+oSVfvQt7863Yk8CNk3RkoEwDZ8k9eQdwpOsuYtHloNYHSEw/YHnq+UvrttT3dxBSpvOJttcDDApH9JtFgxpd4bZu3qFfYmwIyiKAYozfcdwihDVPiMALMNaFbA2nuq5xfuoV7DRVTyUSwcjOa/SFdPoVlL5dNG+FZSiNhPc0Dn1DqrpwzRDSC9bcVGIs8gT7RQ/AbbuhZKu1Q9BHu7f3z/C6IVZcuBairCSnX+C0cf5woGTlWbUB2PAPKzAL2yXZGGRs6+B8n0AbD5jnuoXqst+1ykRl3BcH5k2XKzEEGwW2NPUwUvIZxrJKzWtS8rUYVTTl6iIM3U8RuzpUcEPYiqvCZwFvo9bo+mqjWe97D2kSJxko33tR3ZlMTfAfDrcNw4V54dv3UdMcSKMpi35F7JOCLobHd+0ZGQiD3M1ObhpvpHdJriWO98fOuxdo0hCL4fL7yDDxxxjEC+t9KnxPg/kK
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(17755550239193);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13023025)(8121501046)(13017025)(13024025)(13015025)(5005006)(13018025)(3002001)(10201501046)(6055026); SRVR:CY1PR05MB1962; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB1962; 
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB1962; 4:UkehJERiSg1bSVzxNwftpaPnWdETbeTGFT2FU9d7ulja3VTh9mu47O3bGvJh4hMUe7/yrTm8H1p8Rux40uFoibOYQMtzk94OEc6UWpqRlH7SWePQtFcMo2TMoWckuANaYScBydLapBc7K5NQoradxzytQC39NmTC+hjbAyX5wkg7pYAWzEImWb0q9kdSreRsabL0tVO3OFrWvmrYFldnmdoay9AL4n6uIK0njl1gFRmfHsN/8mk+RmEcMgJU186yL+oi7e2HtaRYWj3k2lOrE2gF7xat7p/fA1TtC6zgu+ISUfbnsN2w+iW0OCZypyQHO0lDE7JsXpKSIuxx56qJwLYHinM/89YwDjy6xJZHJlQQExXP/1G2ncysHCT5Z8tpOeO2SCoFgLSpR7NZ1GaPihxd7KD7qQZyrWCzx1rY4kM58xq8qPcbZIaAoni+NHuTryeUdRzo/Zbeg/qRG0s1UrrfDogZKNak5BBdWBkM6Ws4RTHa8SJmFNJGlYwNJ4w75cGaXbGc4SgGy4qGYyddVa8Al9EjP1Ta/Qy61EnqlXxhgbo5C8H81f4ywJFIkyWE
X-Forefront-PRVS: 00246AB517
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB1962; 23:uUOA21CYDhy9bc3iZzT+G2ZZP014ROX977jUPHNP1?= =?us-ascii?Q?hWClHbQR+y/GN2LwDuUm/17k7mB3/U9mmFjq3r7muCEkkW2yHvY2N2FZOva4?= =?us-ascii?Q?jcYWKFesSEmAE0qmw3avubUEGC2ZYvUsX7i/cGtzhxgdAzSryetRPkv/HT1E?= =?us-ascii?Q?/yBPSvpkv4CfKhe+sB4KbZtNAW/gfI0T4pryu696iIImsLszPpTwNLlveQZD?= =?us-ascii?Q?euP1Dl87tRCYAPP6dlpU89RaKuAPcDxK5wDNL3KId/BNSeBJ7dFa+Nsf0VZo?= =?us-ascii?Q?PSa4NasioeRDjx3nUMslnqjBMrYEUQdhFg9zeoXuxKd87FaF34wR6RvBDclr?= =?us-ascii?Q?2FSbB+/WXax3FUaehhJJRAsxwubHoWQGsLkaHsMm9+PEqugEy713rN6+h5Ku?= =?us-ascii?Q?Ws25fQcf77HFeDdSuwdMBNnTGiTmySMh54lqF2JG2knwwEauhCwnDOkAYo9G?= =?us-ascii?Q?sv3g7HDAYjemTyE5v5DNybTLve8GD9dSNNzIjOMIstpttaWOM74Wt3zBrd3L?= =?us-ascii?Q?RoyAN9Csr3JZ2ahiDrG1ABLeN6DYkYS1/qL7v9CduA58DN2VYeiTaZeCbems?= =?us-ascii?Q?/oLdVBQ+Y/DsgGX08Xrx2R3qOX5eCJrz1hLFti5CDFrFPKHnGUSWO6oj5Gei?= =?us-ascii?Q?HTWpi9RroXgGATtRdRmSfdbYR1bk/izEBfANo4nexJ+mwtw6bTtg/8Oy0swY?= =?us-ascii?Q?v6Futq8pFuu+U6+GVsHAryqoT16D3/lirTGdzYB9tVEJWjTSW5IWhlMt4rQg?= =?us-ascii?Q?ssw+tWSOkw/4FD6S5Xwc25uzdn1Ujsgu9jOT2qy0nAKrLuV3lIkP2QgHTF6U?= =?us-ascii?Q?y7E/cW6DM9MXLXKtCcVXAmCklC0W6L/FVa8Q4yCsM9+KdarZeyKVlv4PzY4O?= =?us-ascii?Q?44CssSVE+aQ6Ezc3LLAgjYTAojGBE+yF7qng7rZ0djqmwTm3bZFQaQKZSMVl?= =?us-ascii?Q?OvHHoUHyYYEGADmxY26fi+hVlyL6P8WRah3G7n9HbOVmIxqZ8ZgsYsVIHumd?= =?us-ascii?Q?lhFV6QkG3Z+yQR06rwqm3Cx?=
X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB1962; 6:Jemi5Hj1Qe2i7HpFkAIc3GmiEg2xvyt/RnMNwXCWyfICJquTRRxuzhu31NeO4UZw4nsAGvB7Y4h80suybsGH2pDjvljTAyvL1fcJFOZbAKbb7yxtr/v5Es6wm25dM9OfFP0M5IlYvw9JiZFTqsPQCkvlMQujZ7YIFHfx25yK3IDZtALGSfel+sOsvsI+ipJ6tTTAFzTzkNUqDHyTUrLf/Py87VadocQdINzjhlOfVQ5b4cPBNk5572iuHOszKKo1+yab5l+45CcZIgQC5hj6sG+ku6oaTjfRBQTV1EPU3lyhMqTmJBSn9HSwtKffm2Tu/2GxQJbLcAzwTqjrR2gNsg==; 5:SOwY7iTliSd+uMrM6Z9oDLF8zm3I1JonVliaMKQMYv/0/FXL/eVk+fnzPYyc13G4sdqlIdSB6Gq9CWPMHRutPZs3rMbmSfunqb7+aAKVgjDXmGLXAW/3BgMRVBf6/Si7J15Cwssyzp1jL/pVlEWf1Q==; 24:1vSsnj9c0Bq8Xs/yc5ABcB1DrpQWb91jY8oyHAn9w31j4CcFHD4y2jJ1DZqKcZbocBI3dk3ENMWzglUdKo5MYjJkNUr9Seq61W3BY7Wffgw=; 7:/FQyOYFpKntlZCYtD2wQeDUYv+lhPMr1QOwzXUnFQkwSVA6C3l9hu6SEF89oUuJ8LUuPKja0fLHfTNpC6lNAlnYZhdhS9FIwfII8J2H02pE4hwwLnAnFcEgJegV7wbFcsaFLB5mlQFA6IQy3tndA4ijYfp9Lx/+GAdzvw/JqfGgSirPh6hjhZzQyMhE7UVIuTejVARKlfoSt9/Ka9fjLtD9iAJd/vbEic4H6KieHPW5nRBU5ufbQLo2U0O264z5N
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Aug 2016 23:14:26.1652 (UTC)
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.19];  Helo=[P-EMFE01C-SAC.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB1962
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 Aug 2016 23:14:31 -0000

Andy Bierman writes:
>But the main use-case for must-stmt inside the container are for constraints
>on the child nodes.  For lists and P-containers, this works fine.

Absolutely.  I'm advocating for allowing, not preventing, must/when
on NP containers, and that they be validated without regard to the
existence of the container.

container system {
   container services {
      container ssh {
         presense "Enable SSH";
         ...
      }
      container ssh-evil-twin {
         presense "Enable SSH's evil twin protocol";
         ...
      }
      must "ssh || ssh-evil-twin";
   }
}

This "must" constraint should be validated regardless of whether
[system] or [system services] appear in the database.  In the
end, one of [system services ssh] or [system services ssh-evil-twin]
must exist for the configuration to be valid.

Of course, the implementation may internally rewrite this to be a
top-level constraint of:

   must "system/services/ssh || system/services/ssh-evil-twin";

if that's more convenient to the implementation.  But to the reader,
having the constraint placed near the appropriate nodes is a win.

Thanks,
 Phil


From nobody Fri Aug  5 00:49:15 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC7312D11A for ; Fri,  5 Aug 2016 00:49:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.287
X-Spam-Level: 
X-Spam-Status: No, score=-8.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gg4ouHNbeT7f for ; Fri,  5 Aug 2016 00:49:11 -0700 (PDT)
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 307BA12B036 for ; Fri,  5 Aug 2016 00:49:10 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:f1a7:12ca:e7a0:6d2f] (unknown [IPv6:2001:718:1a02:1:f1a7:12ca:e7a0:6d2f]) by mail.nic.cz (Postfix) with ESMTPSA id CF0CF61DDC; Fri,  5 Aug 2016 09:49:08 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1470383348; bh=qcw2wY+2cLYPWd/71Yhsn+D6nFiuZHYRVR03marKhgU=; h=From:Date:To; b=N+7LCLL3RGBlNP1wJJoYqYa/dDJ2tz25+bFf2ihrxC7qAIxNgaYbjjWaoiZ6H8mUg 554YXNEa2AvE5gABLkpnX0u26fTryQ5dYHZERPgGsqUNDWWaJ0UMhI/1Gz9LXHPHue 8O909LAMb7FQMOCk+h+n+F37okbapP9l/fhdiSW0=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <201608042311.u74NB2l2049513@idle.juniper.net>
Date: Fri, 5 Aug 2016 09:49:16 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <5EFDFAF7-0FD9-48B2-A5C0-763BFA8D199C@nic.cz>
References: <201608042311.u74NB2l2049513@idle.juniper.net>
To: Phil Shafer 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 Aug 2016 07:49:13 -0000

> On 05 Aug 2016, at 01:11, Phil Shafer  wrote:
>=20
> Andy Bierman writes:
>> But the main use-case for must-stmt inside the container are for =
constraints
>> on the child nodes.  For lists and P-containers, this works fine.
>=20
> Absolutely.  I'm advocating for allowing, not preventing, must/when
> on NP containers, and that they be validated without regard to the
> existence of the container.

And since we need them as the context node for such evaluations, it is =
IMO easier to assume that they are present in the (conceptual) =
datastore. The when statement, if present, needs to be evaluated as =
described in sec. 7.21.5, and if it evaluates to false, the NP-container =
should be considered absent - so that must statements aren't evaluated, =
if they are present. I think it is consistent, albeit somewhat =
complicated.=20

>=20
> container system {
>   container services {
>      container ssh {
>         presense "Enable SSH";
>         ...
>      }
>      container ssh-evil-twin {
>         presense "Enable SSH's evil twin protocol";
>         ...
>      }
>      must "ssh || ssh-evil-twin";
>   }
> }
>=20
> This "must" constraint should be validated regardless of whether
> [system] or [system services] appear in the database.  In the
> end, one of [system services ssh] or [system services ssh-evil-twin]
> must exist for the configuration to be valid.

Yes (except that the above isn't a valid XPath expression).

Lada

>=20
> Of course, the implementation may internally rewrite this to be a
> top-level constraint of:
>=20
>   must "system/services/ssh || system/services/ssh-evil-twin";
>=20
> if that's more convenient to the implementation.  But to the reader,
> having the constraint placed near the appropriate nodes is a win.
>=20
> Thanks,
> Phil
>=20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

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





From nobody Fri Aug  5 01:43:27 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B974212D103 for ; Fri,  5 Aug 2016 01:43:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aiMU4T6pAtw for ; Fri,  5 Aug 2016 01:43:24 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 D1ABF12D0B1 for ; Fri,  5 Aug 2016 01:43:23 -0700 (PDT)
X-AuditID: c1b4fb30-ea88e980000009f9-d1-57a451a9c4c2
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by  (Symantec Mail Security) with SMTP id F6.0E.02553.9A154A75; Fri,  5 Aug 2016 10:43:22 +0200 (CEST)
Received: from [159.107.197.123] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.3.301.0; Fri, 5 Aug 2016 10:43:20 +0200
To: William Ivory , Robert Wilton , Jan Lindblad 
References: <201608031942.u73Jg8ol039135@idle.juniper.net> <5a49581e-71ef-4be9-1e51-62213901a887@cisco.com> <0066A47E-240F-4B6B-920B-98B064CE1E60@tail-f.com>   <05ea80f8-665b-d9b7-53db-207fc862409e@cisco.com> <5d8503f67066406a992738b766556247@EMEAWP-EXMB11.corp.brocade.com>
From: Balazs Lengyel 
Message-ID: 
Date: Fri, 5 Aug 2016 10:43:20 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <5d8503f67066406a992738b766556247@EMEAWP-EXMB11.corp.brocade.com>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsUyM2K7je6qwCXhBg/X8lj8n9XHaDF1021W ixPn+pgt3rxtYHJg8eg5dpnNY8rvjaweS5b8ZPLY+GsxSwBLFJdNSmpOZllqkb5dAlfGtVfz mApWclUcPbCbuYFxMkcXIweHhICJxJ7HpV2MXBxCAusZJZZMf8YG4axhlOh5dpOxi5GTQ1gg XOLt0zVsIA0iAtkSrzdyQtT0M0u837eXDaSGWUBOYvGPHiYQm03ASGJq/3kWEJtXwF5i1cNT YHNYBFQkPs1qZQSZIyoQI7G+LwGiRFDi5MwnYOWcAn4Se49MZQEpYQZqfbC1DGK6vMT2t3OY QWwhAQ2Jhxf+sk5gFJiFpHsWQscsJB0LGJlXMYoWpxYn5aYbGemlFmUmFxfn5+nlpZZsYgQG 7sEtvw12ML587niIUYCDUYmHd0HT4nAh1sSy4srcQ4wSHMxKIrz3PZeEC/GmJFZWpRblxxeV 5qQWH2KU5mBREuf1f6kYLiSQnliSmp2aWpBaBJNl4uCUamCsX8a+MT78gaBCHPe5NwFbzLYf 759ZJ3BKNDPoy//3MiIK0qVxTtk/ilPvqvyZIj/lLffvx/UdJ2zmxP7p+/To//FlMgK/6iVe vuTlVVN4uGkn9+Kw7fN+L3FQN+nlPlWr2iPM81RAukpT5IFpiNRv5w+RlaKXOwN0v39Yo86z U3z5Zr8ta58rsRRnJBpqMRcVJwIAbN5xjlgCAAA=
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 Aug 2016 08:43:26 -0000

Hello,

As both a network node but also as a model writer: We avoid "must" on NP 
containers.  Or declare containers as presence just to avoid the risk.

Generally any YANG feature that is not defined clearly enough is avoided 
by us. Better do an "ugly" workaround then be surprised and face 
potentially backward incompatible changes to our models. I can live with 
a good YANG solution I can live with a bad YANG solution, I can not live 
with uncertainty.

Balazs


On 2016-08-04 15:27, William Ivory wrote:
> I would be interested to hear from those who have written YANG models (as opposed to those implementing YANG compilers) as to the perceived impact of the different options on your existing models.  Internally our YANG 1.0 models have been written on the assumption we do not evaluate musts on NP containers with no child nodes, but it would be reasonably easy to add 'not(current() or ...' to the front of any such must statements to render the outcome of this discussion irrelevant by ensuring the statements evaluate true when the NP container is not configured and thus effectively ignoring the constraint when not configured.

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com


From nobody Fri Aug  5 01:50:36 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C35112D6B2 for ; Fri,  5 Aug 2016 01:50:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.287
X-Spam-Level: 
X-Spam-Status: No, score=-8.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fq9KQ9LFZsr3 for ; Fri,  5 Aug 2016 01:50:33 -0700 (PDT)
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 DD09B12D5A9 for ; Fri,  5 Aug 2016 01:50:32 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:f1a7:12ca:e7a0:6d2f] (unknown [IPv6:2001:718:1a02:1:f1a7:12ca:e7a0:6d2f]) by mail.nic.cz (Postfix) with ESMTPSA id 5E3A86099F; Fri,  5 Aug 2016 10:50:31 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1470387031; bh=Bi+C9niIaodqjMEWfAmCxEBCUrtOtCqLE8DHOKXYQr4=; h=From:Date:To; b=Jg9tl8gsnpCaURIQCDdQuQAWuSPh4FH5Q+NnIzZOtkSm3+/T0Dy+5ya/nzXQwmPyY 5rOdhRR+UvF0UklPReE6smLjvRA1XhpogBPMT9lkA9sTpVFx8tPY3iuXmsG1jIiYq7 eC01eYCdWh0Bg0+7Cgc/6kDIqglTaz/+g++4Brt4=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <5d8503f67066406a992738b766556247@EMEAWP-EXMB11.corp.brocade.com>
Date: Fri, 5 Aug 2016 10:50:39 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <201608031942.u73Jg8ol039135@idle.juniper.net> <5a49581e-71ef-4be9-1e51-62213901a887@cisco.com> <0066A47E-240F-4B6B-920B-98B064CE1E60@tail-f.com>   <05ea80f8-665b-d9b7-53db-207fc862409e@cisco.com> <5d8503f67066406a992738b766556247@EMEAWP-EXMB11.corp.brocade.com>
To: William Ivory 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 Aug 2016 08:50:35 -0000

> On 04 Aug 2016, at 15:27, William Ivory  wrote:
>=20
> So I quite agree that there are better ways of writing this.  However, =
my initial YANG is valid, and at first glance it is tempting to write it =
that way unless you have been following this discussion thread (-:
>=20
> The YANG 1.1 behaviour gives what I think some (many?) would see as =
unexpected behaviour.  If treated as clarification for YANG 1.0 (ie it =
applies to YANG 1.0 retrospectively) then we could end up invalidating =
currently valid YANG 1.0 models if they have any examples like mine =
below.  Conversely, Jan's ownership-voucher example would become invalid =
if we don't take the YANG 1.1 behaviour and retrospectively apply it to =
YANG 1.0.
>=20
> I'm also not convinced that only evaluating musts on NP containers to =
one level below configured nodes is consistent with how we deal with =
defaults and mandatory statements.  For those we examine all possible =
nodes, configured or otherwise, at any depth in the tree.  I think we =
should either never evaluate must statements on NP containers which have =
no children, or we should always evaluate them at any depth in the tree. =
 What's so special about those that are children of a configured node =
versus those that are grandchildren (or more)?
>=20
> I would be interested to hear from those who have written YANG models =
(as opposed to those implementing YANG compilers) as to the perceived =
impact of the different options on your existing models.  Internally our =
YANG 1.0 models have been written on the assumption we do not evaluate =
musts on NP containers with no child nodes, but it would be reasonably =
easy to add 'not(current() or ...' to the

This doesn't really work: in order to evaluate an XPath expression, the =
context node must exist, and in our case the context node is an instance =
of the NP-container. So "not(current())" by definition always evaluates =
to false.

Lada=20

>  front of any such must statements to render the outcome of this =
discussion irrelevant by ensuring the statements evaluate true when the =
NP container is not configured and thus effectively ignoring the =
constraint when not configured.
>=20
> Regards,
>=20
> William
>=20
> -----Original Message-----
> From: Robert Wilton [mailto:rwilton@cisco.com]=20
> Sent: 04 August 2016 14:10
> To: William Ivory ; Jan Lindblad 
> Cc: Netconf 
> Subject: Re: [Netconf] What should a server response be? - depending =
on NP-containers
>=20
> Hi William,
>=20
> On 04/08/2016 13:39, William Ivory wrote:
>> Hi Rob,
>>=20
>> What about a must statement on a NP-container that implements mutual =
exclusivity with another node, eg the following when top is configured:
>>=20
>> Container top {
>> 	Container np1 {
>> 		Must "not(../np2_leaf)";
>> 		Leaf np1_leaf { type string; }
>> 	}
>> 	Container np2 {
>> 		Leaf np2_leaf { type string; }
>> 	}
>> }
>>=20
>> At first glance, I think many people would assume this was intended =
to prevent both np1_leaf and np2_leaf being configured at the same time. =
 However, if we configure np2_leaf, container 'top' is configured, so we =
evaluate the must on np1 (as a np container child of an existing node, =
as per YANG 1.1 stated requirements) and the must statement evaluates to =
false.  Therefore we cannot configure np2_leaf *ever* in this case.
>>=20
>> Now you could argue this is badly modelled YANG, but I would suggest =
it's decidedly non-obvious that np2_leaf is not configurable here.
> RW:
>=20
> Yes, exactly.  This is why I don't like must statements on np =
containers.  Enforcing a constraint on an construct that doesn't =
properly exist is a bit odd :-)
>=20
> I would suggest that it would be clearer to write this as:
>=20
> Container top {
>   Container np1 {
>     Leaf np1_leaf {
>       type string;
>       must "not(../../np2_leaf)";
>     }
>   }
>   Container np2 {
>     Leaf np2_leaf {
>       type string;
>     }
>   }
> }
>=20
> or perhaps:
>=20
> Container top {
>   Container np1 {
>     Leaf np1_leaf {
>       type string;
>       must "not(../../np2_leaf)";
>     }
>   }
>   Container np2 {
>     Leaf np2_leaf {
>       type string;
>       must "not(../../np1_leaf)";
>     }
>   }
> }
>=20
> Thanks,
> Rob
>=20
>=20
>>=20
>> Regards,
>>=20
>> William
>>=20
>> -----Original Message-----
>> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Robert=20=

>> Wilton
>> Sent: 04 August 2016 13:28
>> To: Jan Lindblad 
>> Cc: Netconf 
>> Subject: Re: [Netconf] What should a server response be? - depending=20=

>> on NP-containers
>>=20
>> Hi Jan,
>>=20
>>=20
>> On 04/08/2016 12:21, Jan Lindblad wrote:
>>> Rob,
>>>=20
>>>>> Jan Lindblad writes:
>>>>>> I'm fine with this. Maybe we should clarify that must statements=20=

>>>>>> on NP containers are evaluated if the NP container parent exists.
>>>>>> That's where the "always exists" notion might help understanding =
a bit.
>>>>> Or say that their existance is meaningless and carries no semantic=20=

>>>>> value, and must/when conditions should never consider or depend on=20=

>>>>> their existence.
>>>> Does that mean that for an empty NP container, it would be up to =
the server to decide whether or not to evaluate the containers must/when =
statements?
>>> That would be terrible. It must be completely clear when must =
statements are evaluated and when not.
>> It can't be that terrible, doesn't YANG 1.0 manage today with this=20
>> behaviour? :-)
>>=20
>> I guess that my point is thus:  if a NP container's must/when =
condition should never consider/depend on the existence of said NP =
container, then for an empty NP container it should make no difference =
as to whether or not they they are evaluated by the device.
>>=20
>> I question whether it is sensible to allow when/must statements on an =
NP container at all.  In many ways I would rather that they were =
restricted to only schema nodes that actually exist as datanodes, at =
least then the semantics are obvious, no special magic behaviour is =
required.
>>=20
>>=20
>>>>   But if the NP container exists due to existence of child nodes =
then the must/when statements would be guaranteed to be evaluated by the =
server?
>>> I think there is no argument that must statements on NP containers =
MUST be evaluated when the container has child nodes. In my previous =
message, in the preceding text you didn't quote, I tried to explain why =
I think it's a bad idea to not also evaluate the must statements when =
the NP container is empty.
>>> In many real cases, it's not easy for a model reader to know whether =
the container has child nodes or not.
>> Yes.  I had read Phil's suggestion as: don't write must/when =
statements that depend on the existence of an NP container.  This sounds =
like quite sensible advise to me, but I might have misunderstood what he =
was suggesting.
>>=20
>> Thanks,
>> Rob
>>=20
>>> /jan
>>>=20
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail
>> =
man_listinfo_netconf&d=3DCwICAg&c=3DIL_XqQWOjubgfqINi2jTzg&r=3DGByLeg9jZvO=
v_
>> =
AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=3D751sECIaA5HaNM0wQdHxLvA6UwL5IhKW91y_u
>> 8ZrZ2Y&s=3Dx12_Ko8id4YJBVF1rFmAvbKVrZCHdIHsFnzswwJ1k68&e=3D
>> .
>>=20
>=20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

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





From nobody Fri Aug  5 02:02:04 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D9712D6B2 for ; Fri,  5 Aug 2016 02:02:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vu0TD8bLmjzL for ; Fri,  5 Aug 2016 02:02:01 -0700 (PDT)
Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (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 31E5D12D1D2 for ; Fri,  5 Aug 2016 02:02:01 -0700 (PDT)
Received: from pps.filterd (m0000700.ppops.net [127.0.0.1]) by m0000700.ppops.net (8.16.0.11/8.16.0.11) with SMTP id u759042h028712; Fri, 5 Aug 2016 02:01:57 -0700
Received: from brmwp-exmb12.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 24kkqcfrj3-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 05 Aug 2016 02:01:57 -0700
Received: from EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) by BRMWP-EXMB12.corp.brocade.com (172.16.59.130) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Fri, 5 Aug 2016 03:01:55 -0600
Received: from EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) by EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Fri, 5 Aug 2016 11:01:53 +0200
Received: from EMEAWP-EXMB11.corp.brocade.com ([fe80::85ea:b7da:48dd:1640]) by EMEAWP-EXMB11.corp.brocade.com ([fe80::85ea:b7da:48dd:1640%21]) with mapi id 15.00.1156.000; Fri, 5 Aug 2016 11:01:53 +0200
From: William Ivory 
To: Balazs Lengyel , Robert Wilton , Jan Lindblad 
Thread-Topic: [Netconf] What should a server response be? - depending on NP-containers
Thread-Index: AQHR65HjCKulpI0Pc0iHx2JTqSf796AzNTEAgADP0wCAAALRgIAAJAdA///nFYCAACJxEIABQD0AgABduACAASohAIAAiBoAgADuHQCAABg0AIAAErWAgAAidtD//+lMAIAAItBQgAElAQCAACXJYA==
Date: Fri, 5 Aug 2016 09:01:47 +0000
Deferred-Delivery: Fri, 5 Aug 2016 09:01:11 +0000
Message-ID: <618e6ee1e4224101b4f3e732d2f39bb2@EMEAWP-EXMB11.corp.brocade.com>
References: <201608031942.u73Jg8ol039135@idle.juniper.net> <5a49581e-71ef-4be9-1e51-62213901a887@cisco.com> <0066A47E-240F-4B6B-920B-98B064CE1E60@tail-f.com>   <05ea80f8-665b-d9b7-53db-207fc862409e@cisco.com> <5d8503f67066406a992738b766556247@EMEAWP-EXMB11.corp.brocade.com> 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.27.212.173]
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-05_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 impostorscore=0 lowpriorityscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608050111
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 Aug 2016 09:02:03 -0000

Hi Balazs,

That is good practical advice for model writers.  However, it doesn't help anyone who is validating configuration against a YANG model as there you are not necessarily in control of the models presented to you.

William

-----Original Message-----
From: Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] 
Sent: 05 August 2016 09:43
To: William Ivory ; Robert Wilton ; Jan Lindblad 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers

Hello,

As both a network node but also as a model writer: We avoid "must" on NP containers.  Or declare containers as presence just to avoid the risk.

Generally any YANG feature that is not defined clearly enough is avoided by us. Better do an "ugly" workaround then be surprised and face potentially backward incompatible changes to our models. I can live with a good YANG solution I can live with a bad YANG solution, I can not live with uncertainty.

Balazs


On 2016-08-04 15:27, William Ivory wrote:
> I would be interested to hear from those who have written YANG models (as opposed to those implementing YANG compilers) as to the perceived impact of the different options on your existing models.  Internally our YANG 1.0 models have been written on the assumption we do not evaluate musts on NP containers with no child nodes, but it would be reasonably easy to add 'not(current() or ...' to the front of any such must statements to render the outcome of this discussion irrelevant by ensuring the statements evaluate true when the NP container is not configured and thus effectively ignoring the constraint when not configured.

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com


From nobody Fri Aug  5 02:03:16 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5E112D6B2 for ; Fri,  5 Aug 2016 02:03:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.287
X-Spam-Level: 
X-Spam-Status: No, score=-8.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEjZL5b39lpk for ; Fri,  5 Aug 2016 02:03:12 -0700 (PDT)
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 7A6E612D1D2 for ; Fri,  5 Aug 2016 02:03:12 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:f1a7:12ca:e7a0:6d2f] (unknown [IPv6:2001:718:1a02:1:f1a7:12ca:e7a0:6d2f]) by mail.nic.cz (Postfix) with ESMTPSA id EE72461345; Fri,  5 Aug 2016 11:03:10 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1470387791; bh=Sou72q/cXJVaGeNp501AKMTWy4Sn1TtO47sq+RfDOO4=; h=From:Date:To; b=NHx54At43kViq6n9XFqA9JrtRqU2Zy4F3en7PnkQpZ5Bk0VVisITFP7iCU4ouDO8i /ri5ZtOhKqd6aG98gRExa//ex4cp/hcYquOHPHZbv4wq02at0kOcs4K0B63sSCx0Xl 4pPvKJVdRyv0mnKyyCHORunjzoD1HDDSonD6A6lQ=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Fri, 5 Aug 2016 11:03:19 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <2F68D737-84B5-4509-9670-694A84579E19@nic.cz>
References: <201608031942.u73Jg8ol039135@idle.juniper.net> <5a49581e-71ef-4be9-1e51-62213901a887@cisco.com> <0066A47E-240F-4B6B-920B-98B064CE1E60@tail-f.com>   <05ea80f8-665b-d9b7-53db-207fc862409e@cisco.com> <5d8503f67066406a992738b766556247@EMEAWP-EXMB11.corp.brocade.com> 
To: Balazs Lengyel 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 Aug 2016 09:03:15 -0000

> On 05 Aug 2016, at 10:43, Balazs Lengyel  =
wrote:
>=20
> Hello,
>=20
> As both a network node but also as a model writer: We avoid "must" on =
NP containers.  Or declare containers as presence just to avoid the =
risk.

I strongly disagree.

>=20
> Generally any YANG feature that is not defined clearly enough is =
avoided by us. Better do an "ugly" workaround then be surprised and face =
potentially backward incompatible changes to our models. I can live with =
a good YANG solution I can live with a bad YANG solution, I can not live =
with uncertainty.

Perhaps 6020bis is not (yet) sufficently clear but IMO there is no =
uncertainty in what Jan and I proposed earlier:

1. Conceptual data tree may have some default contents: instances of =
leaf and leaf-list nodes with default values defined by the data  =20
   model, and NP-containers.

2. The rules that determine whether a given default instance is in use =
or not are exactly those specified in sec. 7.6.1:

"""
The usage of the default value depends on the leaf's closest ancestor =
node in the schema tree that is not a non-presence container (see =
Section 7.5.1):

   o  If no such ancestor exists in the schema tree, the default value
      MUST be used.

   o  Otherwise, if this ancestor is a case node, the default value MUST
      be used if any node from the case exists in the data tree, or if
      the case node is the choice's default case, and no nodes from any
      other case exist in the data tree.

   o  Otherwise, the default value MUST be used if the ancestor node
      exists in the data tree.

   In these cases, the default value is said to be in use.
"""

I believe that everything else follows from this and the current text of =
6020bis.

Lada

>=20
> Balazs
>=20
>=20
> On 2016-08-04 15:27, William Ivory wrote:
>> I would be interested to hear from those who have written YANG models =
(as opposed to those implementing YANG compilers) as to the perceived =
impact of the different options on your existing models.  Internally our =
YANG 1.0 models have been written on the assumption we do not evaluate =
musts on NP containers with no child nodes, but it would be reasonably =
easy to add 'not(current() or ...' to the front of any such must =
statements to render the outcome of this discussion irrelevant by =
ensuring the statements evaluate true when the NP container is not =
configured and thus effectively ignoring the constraint when not =
configured.
>=20
> --=20
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909              email: =
Balazs.Lengyel@ericsson.com
>=20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

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





From nobody Fri Aug  5 02:20:16 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A6012D143 for ; Fri,  5 Aug 2016 02:20:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVzI1fUl9kD3 for ; Fri,  5 Aug 2016 02:20:13 -0700 (PDT)
Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (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 4913812D0F1 for ; Fri,  5 Aug 2016 02:20:13 -0700 (PDT)
Received: from pps.filterd (m0000700.ppops.net [127.0.0.1]) by m0000700.ppops.net (8.16.0.11/8.16.0.11) with SMTP id u759IxJ7010811; Fri, 5 Aug 2016 02:20:12 -0700
Received: from brmwp-exmb11.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 24kkqcft86-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 05 Aug 2016 02:20:11 -0700
Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by BRMWP-EXMB11.corp.brocade.com (172.16.59.77) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Fri, 5 Aug 2016 03:19:55 -0600
Received: from EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) by EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Fri, 5 Aug 2016 11:19:54 +0200
Received: from EMEAWP-EXMB11.corp.brocade.com ([fe80::85ea:b7da:48dd:1640]) by EMEAWP-EXMB11.corp.brocade.com ([fe80::85ea:b7da:48dd:1640%21]) with mapi id 15.00.1156.000; Fri, 5 Aug 2016 11:19:53 +0200
From: William Ivory 
To: Ladislav Lhotka 
Thread-Topic: [Netconf] What should a server response be? - depending on NP-containers
Thread-Index: AQHR65HjCKulpI0Pc0iHx2JTqSf796AzNTEAgADP0wCAAALRgIAAJAdA///nFYCAACJxEIABQD0AgABduACAASohAIAAiBoAgADuHQCAABg0AIAAErWAgAAidtD//+lMAIAAItBQgAEnDICAACTUoA==
Date: Fri, 5 Aug 2016 09:19:49 +0000
Deferred-Delivery: Fri, 5 Aug 2016 09:19:40 +0000
Message-ID: <357980ab80a64bbba5d6778fdf2160f8@EMEAWP-EXMB11.corp.brocade.com>
References: <201608031942.u73Jg8ol039135@idle.juniper.net> <5a49581e-71ef-4be9-1e51-62213901a887@cisco.com> <0066A47E-240F-4B6B-920B-98B064CE1E60@tail-f.com>   <05ea80f8-665b-d9b7-53db-207fc862409e@cisco.com> <5d8503f67066406a992738b766556247@EMEAWP-EXMB11.corp.brocade.com> 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.27.212.173]
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-05_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 impostorscore=0 lowpriorityscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608050111
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 Aug 2016 09:20:15 -0000

Hi Lada,

I was assuming that if a NP container had no children then from the perspective of current() it didn't exist, but that it was reasonable to evaluate the must expression on it as a 'virtual' node.  This just gets messier and messier, though I guess that 'count(*) = 0' (assuming no non-presence container children, otherwise would need to name children) would work instead?

There seem to be 3 options for evaluating must statements on NP containers that have no children - would appreciate others' input on this.  In addition, Balazs' suggestion that modellers avoid must statements on NP containers where possible would seem sensible advice!

(a) Never evaluate

Never evaluate a must statement on a non-presence container that has no children.

Pros:
- simple to understand
- reduces number of must statements to evaluate when validating configuration
- less likely to lead to unintended consequences of must statements being evaluated on nodes that don't appear in configuration

Cons:
- some existing models (in YANG 1.0 and presumably YANG 1.1) assume evaluation of must statements on NP container children of existing nodes as added / clarified in YANG 1.1
- need to confirm we can still model the likes of the ownership voucher must statement by altenative means if we adopt this interpretation

(b) Evaluate when parent exists

We evaluate must statements on non-presence container if their parent node is configured.

Pros:
- this is the stated position in YANG 1.1 (conflicting opinions exist on this alias as to whether it should be retrospectively applied to YANG 1.0 as 'clarification' or not)
- some existing models assume this is the case (eg Jan's ownership-voucher example (YANG 1.0 model))

Cons:
- may lead to unintended consequences of must statements being unexpectedly evaluated (albeit model writers *should* understand how it works once we have clarified it!)
- why only children, not grandchildren etc?  We examine mandatory and default on every single node, so why not for NP containers as well

(c) Always evaluate

We always evaluate must statements on non-presence containers

Pros:
- easy to understand this rule

Cons:
- this is different to both YANG 1.0 and YANG 1.1 current interpretation (whether you take the YANG 1.1 position as a change or as clarification on YANG 1.0)
- validation now has the overhead of evaluating ALL must statements on all NP containers even when not configured.

---

Regards,

William

-----Original Message-----
From: Ladislav Lhotka [mailto:lhotka@nic.cz] 
Sent: 05 August 2016 09:51
To: William Ivory 
Cc: Robert Wilton ; Jan Lindblad ; Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers


> On 04 Aug 2016, at 15:27, William Ivory  wrote:
> 
> So I quite agree that there are better ways of writing this.  However, my initial YANG is valid, and at first glance it is tempting to write it that way unless you have been following this discussion thread (-:
> 
> The YANG 1.1 behaviour gives what I think some (many?) would see as unexpected behaviour.  If treated as clarification for YANG 1.0 (ie it applies to YANG 1.0 retrospectively) then we could end up invalidating currently valid YANG 1.0 models if they have any examples like mine below.  Conversely, Jan's ownership-voucher example would become invalid if we don't take the YANG 1.1 behaviour and retrospectively apply it to YANG 1.0.
> 
> I'm also not convinced that only evaluating musts on NP containers to one level below configured nodes is consistent with how we deal with defaults and mandatory statements.  For those we examine all possible nodes, configured or otherwise, at any depth in the tree.  I think we should either never evaluate must statements on NP containers which have no children, or we should always evaluate them at any depth in the tree.  What's so special about those that are children of a configured node versus those that are grandchildren (or more)?
> 
> I would be interested to hear from those who have written YANG models 
> (as opposed to those implementing YANG compilers) as to the perceived 
> impact of the different options on your existing models.  Internally 
> our YANG 1.0 models have been written on the assumption we do not 
> evaluate musts on NP containers with no child nodes, but it would be 
> reasonably easy to add 'not(current() or ...' to the

This doesn't really work: in order to evaluate an XPath expression, the context node must exist, and in our case the context node is an instance of the NP-container. So "not(current())" by definition always evaluates to false.

Lada 

>  front of any such must statements to render the outcome of this discussion irrelevant by ensuring the statements evaluate true when the NP container is not configured and thus effectively ignoring the constraint when not configured.
> 
> Regards,
> 
> William
> 
> -----Original Message-----
> From: Robert Wilton [mailto:rwilton@cisco.com]
> Sent: 04 August 2016 14:10
> To: William Ivory ; Jan Lindblad 
> Cc: Netconf 
> Subject: Re: [Netconf] What should a server response be? - depending 
> on NP-containers
> 
> Hi William,
> 
> On 04/08/2016 13:39, William Ivory wrote:
>> Hi Rob,
>> 
>> What about a must statement on a NP-container that implements mutual exclusivity with another node, eg the following when top is configured:
>> 
>> Container top {
>> 	Container np1 {
>> 		Must "not(../np2_leaf)";
>> 		Leaf np1_leaf { type string; }
>> 	}
>> 	Container np2 {
>> 		Leaf np2_leaf { type string; }
>> 	}
>> }
>> 
>> At first glance, I think many people would assume this was intended to prevent both np1_leaf and np2_leaf being configured at the same time.  However, if we configure np2_leaf, container 'top' is configured, so we evaluate the must on np1 (as a np container child of an existing node, as per YANG 1.1 stated requirements) and the must statement evaluates to false.  Therefore we cannot configure np2_leaf *ever* in this case.
>> 
>> Now you could argue this is badly modelled YANG, but I would suggest it's decidedly non-obvious that np2_leaf is not configurable here.
> RW:
> 
> Yes, exactly.  This is why I don't like must statements on np 
> containers.  Enforcing a constraint on an construct that doesn't 
> properly exist is a bit odd :-)
> 
> I would suggest that it would be clearer to write this as:
> 
> Container top {
>   Container np1 {
>     Leaf np1_leaf {
>       type string;
>       must "not(../../np2_leaf)";
>     }
>   }
>   Container np2 {
>     Leaf np2_leaf {
>       type string;
>     }
>   }
> }
> 
> or perhaps:
> 
> Container top {
>   Container np1 {
>     Leaf np1_leaf {
>       type string;
>       must "not(../../np2_leaf)";
>     }
>   }
>   Container np2 {
>     Leaf np2_leaf {
>       type string;
>       must "not(../../np1_leaf)";
>     }
>   }
> }
> 
> Thanks,
> Rob
> 
> 
>> 
>> Regards,
>> 
>> William
>> 
>> -----Original Message-----
>> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Robert 
>> Wilton
>> Sent: 04 August 2016 13:28
>> To: Jan Lindblad 
>> Cc: Netconf 
>> Subject: Re: [Netconf] What should a server response be? - depending 
>> on NP-containers
>> 
>> Hi Jan,
>> 
>> 
>> On 04/08/2016 12:21, Jan Lindblad wrote:
>>> Rob,
>>> 
>>>>> Jan Lindblad writes:
>>>>>> I'm fine with this. Maybe we should clarify that must statements 
>>>>>> on NP containers are evaluated if the NP container parent exists.
>>>>>> That's where the "always exists" notion might help understanding a bit.
>>>>> Or say that their existance is meaningless and carries no semantic 
>>>>> value, and must/when conditions should never consider or depend on 
>>>>> their existence.
>>>> Does that mean that for an empty NP container, it would be up to the server to decide whether or not to evaluate the containers must/when statements?
>>> That would be terrible. It must be completely clear when must statements are evaluated and when not.
>> It can't be that terrible, doesn't YANG 1.0 manage today with this 
>> behaviour? :-)
>> 
>> I guess that my point is thus:  if a NP container's must/when condition should never consider/depend on the existence of said NP container, then for an empty NP container it should make no difference as to whether or not they they are evaluated by the device.
>> 
>> I question whether it is sensible to allow when/must statements on an NP container at all.  In many ways I would rather that they were restricted to only schema nodes that actually exist as datanodes, at least then the semantics are obvious, no special magic behaviour is required.
>> 
>> 
>>>>   But if the NP container exists due to existence of child nodes then the must/when statements would be guaranteed to be evaluated by the server?
>>> I think there is no argument that must statements on NP containers MUST be evaluated when the container has child nodes. In my previous message, in the preceding text you didn't quote, I tried to explain why I think it's a bad idea to not also evaluate the must statements when the NP container is empty.
>>> In many real cases, it's not easy for a model reader to know whether the container has child nodes or not.
>> Yes.  I had read Phil's suggestion as: don't write must/when statements that depend on the existence of an NP container.  This sounds like quite sensible advise to me, but I might have misunderstood what he was suggesting.
>> 
>> Thanks,
>> Rob
>> 
>>> /jan
>>> 
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mai
>> l 
>> man_listinfo_netconf&d=CwICAg&c=IL_XqQWOjubgfqINi2jTzg&r=GByLeg9jZvOv
>> _ 
>> AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=751sECIaA5HaNM0wQdHxLvA6UwL5IhKW91y_
>> u 8ZrZ2Y&s=x12_Ko8id4YJBVF1rFmAvbKVrZCHdIHsFnzswwJ1k68&e=
>> .
>> 
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> man_listinfo_netconf&d=CwIFAg&c=IL_XqQWOjubgfqINi2jTzg&r=GByLeg9jZvOv_
> AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=6jlb0kQeoX8x29SUyoT8wXmmEAZeH2PaJOIXx
> ueVRP4&s=o-TUEWoTedxYQZ0UmLD-TX17raAc9Dz1VMLk78SnXdU&e=

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





From nobody Fri Aug  5 03:09:40 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD98312B00B for ; Fri,  5 Aug 2016 03:09:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.287
X-Spam-Level: 
X-Spam-Status: No, score=-8.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBVEY4o-Wng0 for ; Fri,  5 Aug 2016 03:09:34 -0700 (PDT)
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 2F8B112D0FB for ; Fri,  5 Aug 2016 03:09:34 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:f1a7:12ca:e7a0:6d2f] (unknown [IPv6:2001:718:1a02:1:f1a7:12ca:e7a0:6d2f]) by mail.nic.cz (Postfix) with ESMTPSA id 4A94E60997 for ; Fri,  5 Aug 2016 12:09:32 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1470391772; bh=VQZ1afbs8xKqH/TTvAj3VUSSdKnci79Y14a/N+rlUr0=; h=From:Date:To; b=wsiXRrpV06wuXKX5axpIo0LxUzdCPkr6iKsTMtdSPkbPCkNBXGBQwWPmJMv4sN+rm I/1Bdx2LWDoFmdnz2UN6RIa1c9xjojpHP9e9bqpkUkxgpF6ZvvsgnVOCPet4kM624U h/UEgpZzh6d3ibJyEogiqepywHmDZqw1Rgt4aekE=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <357980ab80a64bbba5d6778fdf2160f8@EMEAWP-EXMB11.corp.brocade.com>
Date: Fri, 5 Aug 2016 12:09:40 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <91C219A9-B80C-40D0-BD48-81D91771108D@nic.cz>
References: <201608031942.u73Jg8ol039135@idle.juniper.net> <5a49581e-71ef-4be9-1e51-62213901a887@cisco.com> <0066A47E-240F-4B6B-920B-98B064CE1E60@tail-f.com>   <05ea80f8-665b-d9b7-53db-207fc862409e@cisco.com> <5d8503f67066406a992738b766556247@EMEAWP-EXMB11.corp.brocade.com>  <357980ab80a64bbba5d6778fdf2160f8@EMEAWP-EXMB11.corp.brocade.com>
To: netconf@ietf.org
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 Aug 2016 10:09:38 -0000

> On 05 Aug 2016, at 11:19, William Ivory  wrote:
>=20
> Hi Lada,
>=20
> I was assuming that if a NP container had no children then from the =
perspective of current() it didn't exist, but that it was reasonable to =
evaluate the must expression on it as a 'virtual' node.  This just gets =
messier and messier, though I guess that

XPath spec requires a certain context, and we have to provide it because =
otherwise the evaluation may not be well defined. Pretending that the =
context node exists and doesn't exist at the same time seems weird, and =
IMO it's unnecessary - we can just assume the NP-container is present in =
the conceptual data tree, as we do, e.g., for leaves with default =
values.

> 'count(*) =3D 0' (assuming no non-presence container children, =
otherwise would need to name children) would work instead?

Right, for a non-existent NP-container that's in use, 'count(*) =3D 0' =
is true.

>=20
> There seem to be 3 options for evaluating must statements on NP =
containers that have no children - would appreciate others' input on =
this.  In addition, Balazs' suggestion that modellers avoid must =
statements on NP containers where possible would seem sensible advice!

I don't think so, an NP-container may be a good place for specifying =
semantics constrains for its children. I have used it in my modules =
several times.

>=20
> (a) Never evaluate
>=20
> Never evaluate a must statement on a non-presence container that has =
no children.
>=20
> Pros:
> - simple to understand
> - reduces number of must statements to evaluate when validating =
configuration
> - less likely to lead to unintended consequences of must statements =
being evaluated on nodes that don't appear in configuration
>=20
> Cons:
> - some existing models (in YANG 1.0 and presumably YANG 1.1) assume =
evaluation of must statements on NP container children of existing nodes =
as added / clarified in YANG 1.1
> - need to confirm we can still model the likes of the ownership =
voucher must statement by altenative means if we adopt this =
interpretation
>=20
> (b) Evaluate when parent exists

I support this one, except that it's not every parent that's counts. I =
wrote down the exact rules in my response to Balazs.

>=20
> We evaluate must statements on non-presence container if their parent =
node is configured.
>=20
> Pros:
> - this is the stated position in YANG 1.1 (conflicting opinions exist =
on this alias as to whether it should be retrospectively applied to YANG =
1.0 as 'clarification' or not)
> - some existing models assume this is the case (eg Jan's =
ownership-voucher example (YANG 1.0 model))
>=20
> Cons:
> - may lead to unintended consequences of must statements being =
unexpectedly evaluated (albeit model writers *should* understand how it =
works once we have clarified it!)

Model writers shouldn't be surprised if it is clearly stated in the =
spec, otherwise they could also be surprised by must statements being =
unexpectedly evaluated on default leaves or leaf-lists.=20

> - why only children, not grandchildren etc?  We examine mandatory and =
default on every single node, so why not for NP containers as well

My rules work for grandchildren, too, because it is the ancestor node =
that is not a non-presence container that has to be present (see sec. =
7.6.1 in 6020bis).

Cheers, Lada

>=20
> (c) Always evaluate
>=20
> We always evaluate must statements on non-presence containers
>=20
> Pros:
> - easy to understand this rule
>=20
> Cons:
> - this is different to both YANG 1.0 and YANG 1.1 current =
interpretation (whether you take the YANG 1.1 position as a change or as =
clarification on YANG 1.0)
> - validation now has the overhead of evaluating ALL must statements on =
all NP containers even when not configured.
>=20
> ---
>=20
> Regards,
>=20
> William
>=20
> -----Original Message-----
> From: Ladislav Lhotka [mailto:lhotka@nic.cz]=20
> Sent: 05 August 2016 09:51
> To: William Ivory 
> Cc: Robert Wilton ; Jan Lindblad ; =
Netconf 
> Subject: Re: [Netconf] What should a server response be? - depending =
on NP-containers
>=20
>=20
>> On 04 Aug 2016, at 15:27, William Ivory  wrote:
>>=20
>> So I quite agree that there are better ways of writing this.  =
However, my initial YANG is valid, and at first glance it is tempting to =
write it that way unless you have been following this discussion thread =
(-:
>>=20
>> The YANG 1.1 behaviour gives what I think some (many?) would see as =
unexpected behaviour.  If treated as clarification for YANG 1.0 (ie it =
applies to YANG 1.0 retrospectively) then we could end up invalidating =
currently valid YANG 1.0 models if they have any examples like mine =
below.  Conversely, Jan's ownership-voucher example would become invalid =
if we don't take the YANG 1.1 behaviour and retrospectively apply it to =
YANG 1.0.
>>=20
>> I'm also not convinced that only evaluating musts on NP containers to =
one level below configured nodes is consistent with how we deal with =
defaults and mandatory statements. For those we examine all possible =
nodes, configured or otherwise, at any depth in the tree.  I think we =
should either never evaluate must statements on NP containers which have =
no children, or we should always evaluate them at any depth in the tree. =
 What's so special about those that are children of a configured node =
versus those that are grandchildren (or more)?
>>=20
>> I would be interested to hear from those who have written YANG models=20=

>> (as opposed to those implementing YANG compilers) as to the perceived=20=

>> impact of the different options on your existing models.  Internally=20=

>> our YANG 1.0 models have been written on the assumption we do not=20
>> evaluate musts on NP containers with no child nodes, but it would be=20=

>> reasonably easy to add 'not(current() or ...' to the
>=20
> This doesn't really work: in order to evaluate an XPath expression, =
the context node must exist, and in our case the context node is an =
instance of the NP-container. So "not(current())" by definition always =
evaluates to false.
>=20
> Lada=20
>=20
>> front of any such must statements to render the outcome of this =
discussion irrelevant by ensuring the statements evaluate true when the =
NP container is not configured and thus effectively ignoring the =
constraint when not configured.
>>=20
>> Regards,
>>=20
>> William
>>=20
>> -----Original Message-----
>> From: Robert Wilton [mailto:rwilton@cisco.com]
>> Sent: 04 August 2016 14:10
>> To: William Ivory ; Jan Lindblad =

>> Cc: Netconf 
>> Subject: Re: [Netconf] What should a server response be? - depending=20=

>> on NP-containers
>>=20
>> Hi William,
>>=20
>> On 04/08/2016 13:39, William Ivory wrote:
>>> Hi Rob,
>>>=20
>>> What about a must statement on a NP-container that implements mutual =
exclusivity with another node, eg the following when top is configured:
>>>=20
>>> Container top {
>>> 	Container np1 {
>>> 		Must "not(../np2_leaf)";
>>> 		Leaf np1_leaf { type string; }
>>> 	}
>>> 	Container np2 {
>>> 		Leaf np2_leaf { type string; }
>>> 	}
>>> }
>>>=20
>>> At first glance, I think many people would assume this was intended =
to prevent both np1_leaf and np2_leaf being configured at the same time. =
 However, if we configure np2_leaf, container 'top' is configured, so we =
evaluate the must on np1 (as a np container child of an existing node, =
as per YANG 1.1 stated requirements) and the must statement evaluates to =
false.  Therefore we cannot configure np2_leaf *ever* in this case.
>>>=20
>>> Now you could argue this is badly modelled YANG, but I would suggest =
it's decidedly non-obvious that np2_leaf is not configurable here.
>> RW:
>>=20
>> Yes, exactly.  This is why I don't like must statements on np=20
>> containers.  Enforcing a constraint on an construct that doesn't=20
>> properly exist is a bit odd :-)
>>=20
>> I would suggest that it would be clearer to write this as:
>>=20
>> Container top {
>> Container np1 {
>>   Leaf np1_leaf {
>>     type string;
>>     must "not(../../np2_leaf)";
>>   }
>> }
>> Container np2 {
>>   Leaf np2_leaf {
>>     type string;
>>   }
>> }
>> }
>>=20
>> or perhaps:
>>=20
>> Container top {
>> Container np1 {
>>   Leaf np1_leaf {
>>     type string;
>>     must "not(../../np2_leaf)";
>>   }
>> }
>> Container np2 {
>>   Leaf np2_leaf {
>>     type string;
>>     must "not(../../np1_leaf)";
>>   }
>> }
>> }
>>=20
>> Thanks,
>> Rob
>>=20
>>=20
>>>=20
>>> Regards,
>>>=20
>>> William
>>>=20
>>> -----Original Message-----
>>> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Robert=20=

>>> Wilton
>>> Sent: 04 August 2016 13:28
>>> To: Jan Lindblad 
>>> Cc: Netconf 
>>> Subject: Re: [Netconf] What should a server response be? - depending=20=

>>> on NP-containers
>>>=20
>>> Hi Jan,
>>>=20
>>>=20
>>> On 04/08/2016 12:21, Jan Lindblad wrote:
>>>> Rob,
>>>>=20
>>>>>> Jan Lindblad writes:
>>>>>>> I'm fine with this. Maybe we should clarify that must statements=20=

>>>>>>> on NP containers are evaluated if the NP container parent =
exists.
>>>>>>> That's where the "always exists" notion might help understanding =
a bit.
>>>>>> Or say that their existance is meaningless and carries no =
semantic=20
>>>>>> value, and must/when conditions should never consider or depend =
on=20
>>>>>> their existence.
>>>>> Does that mean that for an empty NP container, it would be up to =
the server to decide whether or not to evaluate the containers must/when =
statements?
>>>> That would be terrible. It must be completely clear when must =
statements are evaluated and when not.
>>> It can't be that terrible, doesn't YANG 1.0 manage today with this=20=

>>> behaviour? :-)
>>>=20
>>> I guess that my point is thus:  if a NP container's must/when =
condition should never consider/depend on the existence of said NP =
container, then for an empty NP container it should make no difference =
as to whether or not they they are evaluated by the device.
>>>=20
>>> I question whether it is sensible to allow when/must statements on =
an NP container at all.  In many ways I would rather that they were =
restricted to only schema nodes that actually exist as datanodes, at =
least then the semantics are obvious, no special magic behaviour is =
required.
>>>=20
>>>=20
>>>>> But if the NP container exists due to existence of child nodes =
then the must/when statements would be guaranteed to be evaluated by the =
server?
>>>> I think there is no argument that must statements on NP containers =
MUST be evaluated when the container has child nodes. In my previous =
message, in the preceding text you didn't quote, I tried to explain why =
I think it's a bad idea to not also evaluate the must statements when =
the NP container is empty.
>>>> In many real cases, it's not easy for a model reader to know =
whether the container has child nodes or not.
>>> Yes.  I had read Phil's suggestion as: don't write must/when =
statements that depend on the existence of an NP container.  This sounds =
like quite sensible advise to me, but I might have misunderstood what he =
was suggesting.
>>>=20
>>> Thanks,
>>> Rob
>>>=20
>>>> /jan
>>>>=20
>>> _______________________________________________
>>> Netconf mailing list
>>> Netconf@ietf.org
>>> =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai
>>> l=20
>>> =
man_listinfo_netconf&d=3DCwICAg&c=3DIL_XqQWOjubgfqINi2jTzg&r=3DGByLeg9jZvO=
v
>>> _=20
>>> =
AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=3D751sECIaA5HaNM0wQdHxLvA6UwL5IhKW91y_
>>> u 8ZrZ2Y&s=3Dx12_Ko8id4YJBVF1rFmAvbKVrZCHdIHsFnzswwJ1k68&e=3D
>>> .
>>>=20
>>=20
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail
>> =
man_listinfo_netconf&d=3DCwIFAg&c=3DIL_XqQWOjubgfqINi2jTzg&r=3DGByLeg9jZvO=
v_
>> =
AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=3D6jlb0kQeoX8x29SUyoT8wXmmEAZeH2PaJOIXx
>> ueVRP4&s=3Do-TUEWoTedxYQZ0UmLD-TX17raAc9Dz1VMLk78SnXdU&e=3D
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

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





From nobody Fri Aug  5 04:31:57 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E56C12B053 for ; Fri,  5 Aug 2016 04:31:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.287
X-Spam-Level: 
X-Spam-Status: No, score=-8.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toFqN8hRro6p for ; Fri,  5 Aug 2016 04:31:53 -0700 (PDT)
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 9778312D72A for ; Fri,  5 Aug 2016 04:31:53 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:f1a7:12ca:e7a0:6d2f] (unknown [IPv6:2001:718:1a02:1:f1a7:12ca:e7a0:6d2f]) by mail.nic.cz (Postfix) with ESMTPSA id 95CD7607DD for ; Fri,  5 Aug 2016 13:31:51 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1470396711; bh=R2VptSlm18L5UpuBO3/Rut8HV8qdvprhsEhrQuPuZdw=; h=From:Date:To; b=Up70HVSrGNEzLfLMnYZp3UtIckEd0rCA5Ne8ksA03RpXoKFK55uazMuadlpkOni6B iPU2X2oBczFMnHZhzAkDU71v7cO28Vd4WJTQuQqKjTK4v/kC4oJEAHIPftH3LeqYn9 J46PYGHAok/oO0jjTo+IzxV0Qn9zCXQgbwm28pcM=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <91C219A9-B80C-40D0-BD48-81D91771108D@nic.cz>
Date: Fri, 5 Aug 2016 13:31:59 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <89C08339-0913-4EB2-B232-7A16D3899AE7@nic.cz>
References: <201608031942.u73Jg8ol039135@idle.juniper.net> <5a49581e-71ef-4be9-1e51-62213901a887@cisco.com> <0066A47E-240F-4B6B-920B-98B064CE1E60@tail-f.com>   <05ea80f8-665b-d9b7-53db-207fc862409e@cisco.com> <5d8503f67066406a992738b766556247@EMEAWP-EXMB11.corp.brocade.com>  <357980ab80a64bbba5d6778fdf2160f8@EMEAWP-EXMB11.corp.brocade.com> <91C219A9-B80C-40D0-BD48-81D91771108D@nic.cz>
To: Netconf 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 Aug 2016 11:31:56 -0000

> On 05 Aug 2016, at 12:09, Ladislav Lhotka  wrote:
>=20
>>=20
>> On 05 Aug 2016, at 11:19, William Ivory  wrote:
>>=20
>> Hi Lada,
>>=20
>> I was assuming that if a NP container had no children then from the =
perspective of current() it didn't exist, but that it was reasonable to =
evaluate the must expression on it as a 'virtual' node.  This just gets =
messier and messier, though I guess that
>=20
> XPath spec requires a certain context, and we have to provide it =
because otherwise the evaluation may not be well defined. Pretending =
that the context node exists and doesn't exist at the same time seems =
weird, and IMO it's unnecessary - we can just assume the NP-container is =
present in the conceptual data tree, as we do, e.g., for leaves with =
default values.
>=20
>> 'count(*) =3D 0' (assuming no non-presence container children, =
otherwise would need to name children) would work instead?
>=20
> Right, for a non-existent NP-container that's in use, 'count(*) =3D 0' =
is true.

Actually, this won't be true if the NP-container has another =
NP-container as its child. Sorry for the confusion.

Lada=20

>=20
>>=20
>> There seem to be 3 options for evaluating must statements on NP =
containers that have no children - would appreciate others' input on =
this.  In addition, Balazs' suggestion that modellers avoid must =
statements on NP containers where possible would seem sensible advice!
>=20
> I don't think so, an NP-container may be a good place for specifying =
semantics constrains for its children. I have used it in my modules =
several times.
>=20
>>=20
>> (a) Never evaluate
>>=20
>> Never evaluate a must statement on a non-presence container that has =
no children.
>>=20
>> Pros:
>> - simple to understand
>> - reduces number of must statements to evaluate when validating =
configuration
>> - less likely to lead to unintended consequences of must statements =
being evaluated on nodes that don't appear in configuration
>>=20
>> Cons:
>> - some existing models (in YANG 1.0 and presumably YANG 1.1) assume =
evaluation of must statements on NP container children of existing nodes =
as added / clarified in YANG 1.1
>> - need to confirm we can still model the likes of the ownership =
voucher must statement by altenative means if we adopt this =
interpretation
>>=20
>> (b) Evaluate when parent exists
>=20
> I support this one, except that it's not every parent that's counts. I =
wrote down the exact rules in my response to Balazs.
>=20
>>=20
>> We evaluate must statements on non-presence container if their parent =
node is configured.
>>=20
>> Pros:
>> - this is the stated position in YANG 1.1 (conflicting opinions exist =
on this alias as to whether it should be retrospectively applied to YANG =
1.0 as 'clarification' or not)
>> - some existing models assume this is the case (eg Jan's =
ownership-voucher example (YANG 1.0 model))
>>=20
>> Cons:
>> - may lead to unintended consequences of must statements being =
unexpectedly evaluated (albeit model writers *should* understand how it =
works once we have clarified it!)
>=20
> Model writers shouldn't be surprised if it is clearly stated in the =
spec, otherwise they could also be surprised by must statements being =
unexpectedly evaluated on default leaves or leaf-lists.=20
>=20
>> - why only children, not grandchildren etc?  We examine mandatory and =
default on every single node, so why not for NP containers as well
>=20
> My rules work for grandchildren, too, because it is the ancestor node =
that is not a non-presence container that has to be present (see sec. =
7.6.1 in 6020bis).
>=20
> Cheers, Lada
>=20
>>=20
>> (c) Always evaluate
>>=20
>> We always evaluate must statements on non-presence containers
>>=20
>> Pros:
>> - easy to understand this rule
>>=20
>> Cons:
>> - this is different to both YANG 1.0 and YANG 1.1 current =
interpretation (whether you take the YANG 1.1 position as a change or as =
clarification on YANG 1.0)
>> - validation now has the overhead of evaluating ALL must statements =
on all NP containers even when not configured.
>>=20
>> ---
>>=20
>> Regards,
>>=20
>> William
>>=20
>> -----Original Message-----
>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]=20
>> Sent: 05 August 2016 09:51
>> To: William Ivory 
>> Cc: Robert Wilton ; Jan Lindblad =
; Netconf 
>> Subject: Re: [Netconf] What should a server response be? - depending =
on NP-containers
>>=20
>>=20
>>> On 04 Aug 2016, at 15:27, William Ivory  wrote:
>>>=20
>>> So I quite agree that there are better ways of writing this.  =
However, my initial YANG is valid, and at first glance it is tempting to =
write it that way unless you have been following this discussion thread =
(-:
>>>=20
>>> The YANG 1.1 behaviour gives what I think some (many?) would see as =
unexpected behaviour.  If treated as clarification for YANG 1.0 (ie it =
applies to YANG 1.0 retrospectively) then we could end up invalidating =
currently valid YANG 1.0 models if they have any examples like mine =
below.  Conversely, Jan's ownership-voucher example would become invalid =
if we don't take the YANG 1.1 behaviour and retrospectively apply it to =
YANG 1.0.
>>>=20
>>> I'm also not convinced that only evaluating musts on NP containers =
to one level below configured nodes is consistent with how we deal with =
defaults and mandatory statements. For those we examine all possible =
nodes, configured or otherwise, at any depth in the tree.  I think we =
should either never evaluate must statements on NP containers which have =
no children, or we should always evaluate them at any depth in the tree. =
 What's so special about those that are children of a configured node =
versus those that are grandchildren (or more)?
>>>=20
>>> I would be interested to hear from those who have written YANG =
models=20
>>> (as opposed to those implementing YANG compilers) as to the =
perceived=20
>>> impact of the different options on your existing models.  Internally=20=

>>> our YANG 1.0 models have been written on the assumption we do not=20
>>> evaluate musts on NP containers with no child nodes, but it would be=20=

>>> reasonably easy to add 'not(current() or ...' to the
>>=20
>> This doesn't really work: in order to evaluate an XPath expression, =
the context node must exist, and in our case the context node is an =
instance of the NP-container. So "not(current())" by definition always =
evaluates to false.
>>=20
>> Lada=20
>>=20
>>> front of any such must statements to render the outcome of this =
discussion irrelevant by ensuring the statements evaluate true when the =
NP container is not configured and thus effectively ignoring the =
constraint when not configured.
>>>=20
>>> Regards,
>>>=20
>>> William
>>>=20
>>> -----Original Message-----
>>> From: Robert Wilton [mailto:rwilton@cisco.com]
>>> Sent: 04 August 2016 14:10
>>> To: William Ivory ; Jan Lindblad =

>>> Cc: Netconf 
>>> Subject: Re: [Netconf] What should a server response be? - depending=20=

>>> on NP-containers
>>>=20
>>> Hi William,
>>>=20
>>> On 04/08/2016 13:39, William Ivory wrote:
>>>> Hi Rob,
>>>>=20
>>>> What about a must statement on a NP-container that implements =
mutual exclusivity with another node, eg the following when top is =
configured:
>>>>=20
>>>> Container top {
>>>> 	Container np1 {
>>>> 		Must "not(../np2_leaf)";
>>>> 		Leaf np1_leaf { type string; }
>>>> 	}
>>>> 	Container np2 {
>>>> 		Leaf np2_leaf { type string; }
>>>> 	}
>>>> }
>>>>=20
>>>> At first glance, I think many people would assume this was intended =
to prevent both np1_leaf and np2_leaf being configured at the same time. =
 However, if we configure np2_leaf, container 'top' is configured, so we =
evaluate the must on np1 (as a np container child of an existing node, =
as per YANG 1.1 stated requirements) and the must statement evaluates to =
false.  Therefore we cannot configure np2_leaf *ever* in this case.
>>>>=20
>>>> Now you could argue this is badly modelled YANG, but I would =
suggest it's decidedly non-obvious that np2_leaf is not configurable =
here.
>>> RW:
>>>=20
>>> Yes, exactly.  This is why I don't like must statements on np=20
>>> containers.  Enforcing a constraint on an construct that doesn't=20
>>> properly exist is a bit odd :-)
>>>=20
>>> I would suggest that it would be clearer to write this as:
>>>=20
>>> Container top {
>>> Container np1 {
>>>  Leaf np1_leaf {
>>>    type string;
>>>    must "not(../../np2_leaf)";
>>>  }
>>> }
>>> Container np2 {
>>>  Leaf np2_leaf {
>>>    type string;
>>>  }
>>> }
>>> }
>>>=20
>>> or perhaps:
>>>=20
>>> Container top {
>>> Container np1 {
>>>  Leaf np1_leaf {
>>>    type string;
>>>    must "not(../../np2_leaf)";
>>>  }
>>> }
>>> Container np2 {
>>>  Leaf np2_leaf {
>>>    type string;
>>>    must "not(../../np1_leaf)";
>>>  }
>>> }
>>> }
>>>=20
>>> Thanks,
>>> Rob
>>>=20
>>>=20
>>>>=20
>>>> Regards,
>>>>=20
>>>> William
>>>>=20
>>>> -----Original Message-----
>>>> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Robert=20=

>>>> Wilton
>>>> Sent: 04 August 2016 13:28
>>>> To: Jan Lindblad 
>>>> Cc: Netconf 
>>>> Subject: Re: [Netconf] What should a server response be? - =
depending=20
>>>> on NP-containers
>>>>=20
>>>> Hi Jan,
>>>>=20
>>>>=20
>>>> On 04/08/2016 12:21, Jan Lindblad wrote:
>>>>> Rob,
>>>>>=20
>>>>>>> Jan Lindblad writes:
>>>>>>>> I'm fine with this. Maybe we should clarify that must =
statements=20
>>>>>>>> on NP containers are evaluated if the NP container parent =
exists.
>>>>>>>> That's where the "always exists" notion might help =
understanding a bit.
>>>>>>> Or say that their existance is meaningless and carries no =
semantic=20
>>>>>>> value, and must/when conditions should never consider or depend =
on=20
>>>>>>> their existence.
>>>>>> Does that mean that for an empty NP container, it would be up to =
the server to decide whether or not to evaluate the containers must/when =
statements?
>>>>> That would be terrible. It must be completely clear when must =
statements are evaluated and when not.
>>>> It can't be that terrible, doesn't YANG 1.0 manage today with this=20=

>>>> behaviour? :-)
>>>>=20
>>>> I guess that my point is thus:  if a NP container's must/when =
condition should never consider/depend on the existence of said NP =
container, then for an empty NP container it should make no difference =
as to whether or not they they are evaluated by the device.
>>>>=20
>>>> I question whether it is sensible to allow when/must statements on =
an NP container at all.  In many ways I would rather that they were =
restricted to only schema nodes that actually exist as datanodes, at =
least then the semantics are obvious, no special magic behaviour is =
required.
>>>>=20
>>>>=20
>>>>>> But if the NP container exists due to existence of child nodes =
then the must/when statements would be guaranteed to be evaluated by the =
server?
>>>>> I think there is no argument that must statements on NP containers =
MUST be evaluated when the container has child nodes. In my previous =
message, in the preceding text you didn't quote, I tried to explain why =
I think it's a bad idea to not also evaluate the must statements when =
the NP container is empty.
>>>>> In many real cases, it's not easy for a model reader to know =
whether the container has child nodes or not.
>>>> Yes.  I had read Phil's suggestion as: don't write must/when =
statements that depend on the existence of an NP container.  This sounds =
like quite sensible advise to me, but I might have misunderstood what he =
was suggesting.
>>>>=20
>>>> Thanks,
>>>> Rob
>>>>=20
>>>>> /jan
>>>>>=20
>>>> _______________________________________________
>>>> Netconf mailing list
>>>> Netconf@ietf.org
>>>> =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai
>>>> l=20
>>>> =
man_listinfo_netconf&d=3DCwICAg&c=3DIL_XqQWOjubgfqINi2jTzg&r=3DGByLeg9jZvO=
v
>>>> _=20
>>>> =
AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=3D751sECIaA5HaNM0wQdHxLvA6UwL5IhKW91y_
>>>> u 8ZrZ2Y&s=3Dx12_Ko8id4YJBVF1rFmAvbKVrZCHdIHsFnzswwJ1k68&e=3D
>>>> .
>>>>=20
>>>=20
>>> _______________________________________________
>>> Netconf mailing list
>>> Netconf@ietf.org
>>> =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail
>>> =
man_listinfo_netconf&d=3DCwIFAg&c=3DIL_XqQWOjubgfqINi2jTzg&r=3DGByLeg9jZvO=
v_
>>> =
AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=3D6jlb0kQeoX8x29SUyoT8wXmmEAZeH2PaJOIXx
>>> ueVRP4&s=3Do-TUEWoTedxYQZ0UmLD-TX17raAc9Dz1VMLk78SnXdU&e=3D
>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

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





From nobody Fri Aug  5 05:01:12 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7F4512D7B5 for ; Fri,  5 Aug 2016 05:01:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level: 
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BGrUquLpNnE for ; Fri,  5 Aug 2016 05:01:09 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0118.outbound.protection.outlook.com [104.47.40.118]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D364112D09F for ; Fri,  5 Aug 2016 05:01:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=n2+cpxMIDfd7yw71g+5tPPMskkWpoE9wA2rI0tfyjIY=; b=VqayJ3rjKQW8Pbz+r2leGPbyK4Q62XYe0OW71beEDX1aqreC0Rbxq8BsRYNZCBNkdpNXgNonEvlv8yJ7m0yX2XATZfz/MT/qjoWTRCPUPdSA6Ndq0aYNOUxSXlmGVz4eSOpEB57+ThK3DeEJ6++vjDBrd1N+ZPIhBZpcRwwUbdY=
Received: from BY1PR0501CA0034.namprd05.prod.outlook.com (10.162.139.44) by BY2PR0501MB2151.namprd05.prod.outlook.com (10.163.198.25) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.8; Fri, 5 Aug 2016 12:01:06 +0000
Received: from BN1BFFO11FD002.protection.gbl (2a01:111:f400:7c10::1:173) by BY1PR0501CA0034.outlook.office365.com (2a01:111:e400:4821::44) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.8 via Frontend Transport; Fri, 5 Aug 2016 12:01:06 +0000
Authentication-Results: spf=softfail (sender IP is 66.129.239.19) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.19 as permitted sender)
Received: from P-EMFE01C-SAC.jnpr.net (66.129.239.19) by BN1BFFO11FD002.mail.protection.outlook.com (10.58.144.65) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.8 via Frontend Transport; Fri, 5 Aug 2016 12:01:06 +0000
Received: from magenta.juniper.net (172.17.27.123) by P-EMFE01C-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 5 Aug 2016 05:01:05 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id u75C13x84587;	Fri, 5 Aug 2016 05:01:04 -0700 (PDT)	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id u75Bvgf8053861;	Fri, 5 Aug 2016 07:57:42 -0400 (EDT)	(envelope-from phil@idle.juniper.net)
Message-ID: <201608051157.u75Bvgf8053861@idle.juniper.net>
To: Ladislav Lhotka 
In-Reply-To: <5EFDFAF7-0FD9-48B2-A5C0-763BFA8D199C@nic.cz>
Date: Fri, 5 Aug 2016 07:57:42 -0400
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:66.129.239.19; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(2980300002)(189002)(199003)(81156014)(305945005)(2810700001)(69596002)(86362001)(92566002)(2950100001)(7846002)(106466001)(189998001)(87936001)(50986999)(81166006)(53416004)(8936002)(54356999)(50466002)(7696003)(77096005)(8276002)(48376002)(4326007)(76506005)(1076002)(356003)(586003)(11100500001)(110136002)(68736007)(105596002)(558084003)(47776003)(5003940100001)(97736004)(8676002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0501MB2151; H:P-EMFE01C-SAC.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD002; 1:RewXgpeqImbvpkslHGl4ZvCImxCRg4Vg2IaHvA9S+A91AtRABMlKNWToRfAlwCVAi+e4gz4Rlv088ELq5G+v8oKnYPXmzH2jAj1Fy/DY3bmgMJcw3Zx54Z2Yuki2F5d1O8L8eBBASgfAIaqRRHIGvT1kPVmCXZsyWdY8RblWNj3U40KQkevlet8O7/7QabT6two54J2v000sUL8+fo5zhm/2kv2KJlAlUBIuKjVUZS90eAGhCAvBxnWaeblfQJ6RvquFYr7T+iqsDQA1I3tISVBTD43X2tTdFh7LDrQNZZo+nuplZ8xTCJAq5e1o/6r6xTcgnSwnVDLSKLa6L+RO87C6fR+1AzlHsS7bC4iSc/I936wz1Jxkfgr1gnet9GvIETFxdd2WDgL7XrKnj3298P9x9YrQg6tTvneUt7S2UF46GJt4UEQSvr4ruKUw+K0/AjpFoQTYdxkCEFFknXnlpUbiKKOvnbeSTmtqV0Xwze8kjPfjsaNAPuaLNEiH/Z+Uvp/KIX3FNznP1cCy8yZXdElAX2KrWeMgOAgkXYARSU5DXy0Qd0muPNJ01hfWed/l
X-MS-Office365-Filtering-Correlation-Id: 44b63541-f334-4b8c-0f63-08d3bd282ea3
X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB2151; 2:gjpCMUiqZGMhftElXpepBE3YNYG+KEUVjQzLyB9klaB4vEdF/hg5H19EN2COL6b0Uqr/oc1lOZBYkE3eNDMrnFtvArfSmBpgPkyVj901VICB1oJKmlTsZzLiT9Xuf5GEd+Yu3ECdU6Wa/weqULPjBohTadgOFWk3j8tlp9Jonqr2dHz7+rlQlF31uHjYfmpe; 3:zNF9TtzYc9faafls/s43apnYnmbc26yDTIutIfVO85FN4lSkNOWUwT31gds4DVCe1GWWDvnH/JjAjp9ABzaGreLm34wXzMuByVrFwsOvqhk2+oaAFdhpqxryDpuo8Dnz2jF+FwQB1RxVdLBpE+PBZTlyvlGpMyzLctxFh/zCc5AZBzkq+Aa98GqweZgjaV/n9Bca6fvCj7EZBgVCAhrvYCEd9z9G8F0IdX7puq/Fpho=; 25:vZDathU3vSmVgI1hCAbdQ8jIFArakQLzb+EZD67ypFbkNVBlZvpWpeN/8nOIF/L1t6m1GFvek/fqtrYvLwfAu6GKqXDOxdDJS46/hT6ZJfh0SrjnmDrYsxLb8Byu7L2sLq6xDEKfs+ADpzuQzfwnMHkgu6Hp0UykDqQMm4v1KZsOWNAZY13N1aZjKhNoG3dMZXdbiN0AL5He2JkudgPZ4AWQ7PWHXHc42e6/aZeqWvKvnz4TBUEzzoh6hIhCyyjkMoA3sEeeJngOnMdjIJK5VF9Z4hvpD+2LyO2nr9/OYqNIaSelpOA5zxOoc/j/R0xfz2Wm59LMyO67V62qjPAf/vEi/HOWXjAlB+/dcTUjFFeOsXKoMFIsKpgmdnDHna/QD6Dx4FqcV+/OJXEuyfly7n7i92Mo/NFxnMxIfvVSVsU=
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0501MB2151;
X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB2151; 31:GYNdkS0wiqsCuOaTAyEyaRZee3KjXDff7MAsc9r+d1mbVanEMpHimb0IDCLynl7hL2PWqUMGtVAcIeFMmriJkJSgJPuXbWgcgch2we/FqBfnYxj2b+lE5wjZNXoo+lrUw+cjipc545QbMUa9ZtDRgwdeKqkt9uXJgLPQEInXo0UnCdkVtK3qBiEa5kltyU3x40Ga+OEHwrrH3HDHFbEh6yu8yn2v+KgIfnYKC5R3og8=; 20:7nLq4/rRjj9MgjouMYgD4ShkLWmD116y31xTOEwtHEcX/0gWVraphCqUOVZXGoo9pcn/2LEVUg6Ke8L/n9i6Y+Eeh5PatE7SiJC2hZpbEPVATUKvzamApM3eqM1PlgCXTw/kWJ3vKyxBuvIof9mSC1NKKsWORkAitZ7HJVIaB3ilfzz93FxtlxPqR9PQF/pc7BdZXiTHl0YSHj170ucm9eNFtC+klKmlqEYlHqdzU0ZuTPhGq/5Ocvdm6cJrOhSMOziWzEgggH+RvSXaqXJK6YYO/J4zQ3b2wE9N2gizVxN2eIAZVgwSAcJOeytqWMwLv7e6UMLixWv09r3zicaXVMls58LHRcN9J2jXIl83aMfTxAGQ6pXzseaDcijWhWK1XiOQqJqE51r/3bdvDZQsdbGmqpPJSZGt3OBMWkyDxJHMxB8kNDa8vN+MMuJjrAvn0Eh9rzG2j8PXMYfXW/w5uNBVh27pThaPCOzktu86NpzQgVj9GwLQFkzT8jj21kOm
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(13024025)(13015025)(13017025)(13023025)(5005006)(13018025)(10201501046)(3002001)(6055026); SRVR:BY2PR0501MB2151; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0501MB2151; 
X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB2151; 4:+fLHPBLj0mKI7hSv5OFE7gNBmz14SShX69IJnNinwF3DGHS7C5Vii5zgIDKYLFCipzvPLdP455cRAjh20VnogQ6+EMJr2Ix8Dp3tCfbBRIrXfaYOQqVngyO6Xx0/KWiQe2RNe0cvlwBztOg1rsRQ6tdeqQlvF59KVx5BHU+3TGF+as0GKyzstBS8YOV7zMIM/eRXna8lO/w5LIToSdt/6Ev9R+0htKfIlUnY5QW95UWPvieCVOE97vjGEUR7npVu5Fs+cOChFHuEz/osNSU7ajTdopZzity4MTj4pwaO5L51fFc5hElUenqsYxBf3l6LtFdDU/j9UCi19iUkDaxAYcgv+UKsKGWDOAHyUqO6+j+ONkFi/w1D595TMaR5V7U1nEMbMyXA6yFU6bwJ4a3dT9yHx/X+/u/wgP3MG22eFMiEMMIpuPWQ/fuok7ubKk5A7sX0hDSdI6b7E5ro5MN0JI9AE802A6t80KZRAgV/bO5vV9ESN+jnBAq7nl+FasoqjyhhcixohbUta6mHN5wMkg==
X-Forefront-PRVS: 0025434D2D
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR0501MB2151; 23:LNEnJbBGO8CgjGhYcVd8PWA5sJA98nTVZ3FZBVo?= =?us-ascii?Q?rM74BZ9Lhue5CGCV06H/+I2pR6DUUNLQJ5O6ObNP0i1ZnGXB4FxP9DFhUZnP?= =?us-ascii?Q?BIkK03HcB0wVIJ4J2R/HXlgC9SyIKo3tr293TEAnQp6HKLedoreaT29GvvIz?= =?us-ascii?Q?+qdwOLKF3viSO+RqLQCn+gmCK3ddVQtw8QdpgeduY7wdQdyTKopGDLN6oSvM?= =?us-ascii?Q?oKIK3jFi6eFrloG9yZBCcEsiaO7mdj4i2OdHwT2M6aKg/LZLvBOUMJeH8T0n?= =?us-ascii?Q?12+ZqQqlRf6Rcx2SRep3hBVii2FICG5rh1g7KeM+CZPzxnC7R5cPRD9jw28p?= =?us-ascii?Q?aP6p2sFf9LG/Ze4I1LkiOPsSYVMc8RQX6coiZwd4uxhcJth+R2QlNUkAyc0C?= =?us-ascii?Q?rtmvei/jRGtrRL9QvcJuof0i6NQWweBgzTxIUYLLpWzz/LZmP5IxDdFZ1F/C?= =?us-ascii?Q?bEZk18pC9KFdhVeR4Jt0EHVmpSYbfSMythfNWRdYFhKY4n9jxMvpfW5OkO4/?= =?us-ascii?Q?YuzZqG6/J9YR7qgUX3QqhuRcZ8mPqX2ZVrm/SIcJoVulBEX0OQ1CsqQsk0yj?= =?us-ascii?Q?IVUsxHN3xdbDGYyK1t0KjpSHt5NkLaW0hiLDfVvb6SmevfBJUJEuwXxeulTX?= =?us-ascii?Q?7Fg6l7R7gKVPtXG7AEs6lz57HslRdUCP6uCwlWqrfZ8uxxEt9hiW2sxznvE/?= =?us-ascii?Q?Nry3aF4RzOPQzT48a+Wd4JkDcq+VDkNTSnoWBjqqYc6Vahc7rkxjJQ0SsGex?= =?us-ascii?Q?/2UDpJDLTqIbYNFjFhN30ApcWQPK9o9jSebtjQrpruWe3VC++Hrrj3WFHsC4?= =?us-ascii?Q?pvgsrBrtFAyNAarBvUSyBD+4orDMEzZrFSZxsCNRYSRH+yxmEBoCIAuuCI96?= =?us-ascii?Q?mhT4FrTHx5GFDjVR4s7JFO501QpF839Tqa4OYXx/AQMSPFjIkxrlJQV7AGJ8?= =?us-ascii?Q?MCBQndBr74pRW3JVTgru76bwGPkrKnTrdhFaJZKTFGH7iY/1Jq9rpScFk7Mz?= =?us-ascii?Q?GwO0ZExOLL8ItIKg6xMq0AcUydKibE30abx5g7VeSJ1ZeIA=3D=3D?=
X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB2151; 6:wu9d9GRs/jyjuc4niopD0rqDiCVPDFN7ft+GRcKL7u2l1bVRrDEESAxlXCpAZclnKk05paHxjEFeMY2pFoOMXsbXL/RaGYtnW6XilDyD6dNPKvPOoPE1bKImMNGxVWdndvVohvH+uY1PuQtjm3K5AuTCR7yLFabFpWvATrQaNQE5HlrUnThNs2yGzd3WXkv+CY7MESeqGByXdH4zvV5QavRJPI5fFy6dzC6PlUZ4Kfo6RfXSv4YXBW3FOK1nKsd9WBPxLNuBYSohi8PiUGYhLErwCCuOcU22xCBYVGqgXh5ytRIxZxkZ19ue5E4btpwjZza/WEJM6OPKlwmqjeCUuw==; 5:/y5UqENbAOM632KdtKpngFLTN64tibJkUDhKUYTywf2udn4MhmXEZ3g+Dh4CEXMVgPHMBjeM4DLptD9Imz9mSpGL8pc42bPPB03BeFNC5cMj2WbXCJbWqFFaV/EinYnR3gpTP7UmqJGu5LV+nCdXNA==; 24:aSDs9qrRVZ8fUCH8cseTfUyVcMCvWnRUut0CNvQlECH2/OdtOwWhIeWMX263osJLE63i0ZOuiwyynaCHCo90liyFFe9QQwr2GWw7MmXKClA=; 7:6qCLdG8ItOt6Q5PvyG+CyxJMQ3o+lKdhf7uMnQATaM6sN7c0Lrlae6IQIF1nZpRwwm3UUyd2+R/NTjBc7fsGoitOYVZLOB+DTbiyExh2nm9V+JvlDwD5IiMsgqu2Tk5C14sXWg3HmoUlmb0VhnfsM32cnY5LpuEPtw0f7nOBPPbz9GKQ/sTfqsbQ4pCHqQF7zjgwvYFMs+D6162+97lhB04OUNQQ3m0egC9Vbimp14E4cOdYwQ7NOrU942kZwp+9
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Aug 2016 12:01:06.1599 (UTC)
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.19];  Helo=[P-EMFE01C-SAC.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0501MB2151
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 Aug 2016 12:01:11 -0000

Ladislav Lhotka writes:
>Yes (except that the above isn't a valid XPath expression).

Doh!  Mine allows this (and "&&" and "=="), since old fingers are
hard to retrain, and the single equals makes a very bad habit.
And we can rewrite them in standard xpath as we export them.

Thanks,
 Phil


From nobody Fri Aug  5 06:58:10 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 053FE12D1DD for ; Fri,  5 Aug 2016 06:58:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.808
X-Spam-Level: 
X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4LrBYHuLSBh for ; Fri,  5 Aug 2016 06:57:59 -0700 (PDT)
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 8A94D12D511 for ; Fri,  5 Aug 2016 06:57:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11491; q=dns/txt; s=iport; t=1470405477; x=1471615077; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=E/MHWtVk9CP808jFGJ3kzV7A2agVsUpcJKZOv8hz6t4=; b=ejJarcNPFCp0pR9RXvA7Va0s8UTx6q2jkvHZO0z1O9+UhjUWBy/KB6zu x9+BxKXejooRx7ZGkG4QQt8+YFh16xvegt0ZsXWb74hNBiwjeu5DN/1aq a8GspH8AghA70iJO5bMzpRqsbTTPvTgfE6q8SbySDVUaYf8AfMKtmtt9R E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByBgAImqRX/xbLJq1chBsqUrsfJIV5A?= =?us-ascii?q?oIWAQEBAQEBXieEXgEBBTgvBwsMBAsOAwQBAQEnB0YJCAYBDAYCAQGILQ6+RgE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBARcFhiqBeIJVhCoWhVsBBI4Xix6GHYJ8hW+Ba?= =?us-ascii?q?4dpI4VLiGmDSoN3VIISHIFNOzIBAYYgK4EYAQEB?=
X-IronPort-AV: E=Sophos;i="5.28,474,1464652800"; d="scan'208";a="641666096"
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; 05 Aug 2016 13:57:55 +0000
Received: from [10.63.23.91] (dhcp-ensft1-uk-vla370-10-63-23-91.cisco.com [10.63.23.91]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u75Dvsum022063; Fri, 5 Aug 2016 13:57:54 GMT
To: William Ivory , Ladislav Lhotka 
References: <201608031942.u73Jg8ol039135@idle.juniper.net> <5a49581e-71ef-4be9-1e51-62213901a887@cisco.com> <0066A47E-240F-4B6B-920B-98B064CE1E60@tail-f.com>   <05ea80f8-665b-d9b7-53db-207fc862409e@cisco.com> <5d8503f67066406a992738b766556247@EMEAWP-EXMB11.corp.brocade.com>  <357980ab80a64bbba5d6778fdf2160f8@EMEAWP-EXMB11.corp.brocade.com>
From: Robert Wilton 
Message-ID: <49054fe2-b1d1-ba18-a0a0-ea799e8947ef@cisco.com>
Date: Fri, 5 Aug 2016 14:57:54 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <357980ab80a64bbba5d6778fdf2160f8@EMEAWP-EXMB11.corp.brocade.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 Aug 2016 13:58:08 -0000

Hi William,

Pragmatically, I think that I would also go for (b), with the fix 
suggested by Lada.

My reasoning is that despite not liking "when"/"must" statements on 
np-containers they are clearly useful in some cases and cannot be banned 
outright.

I also like Phil's explanation that a server could effectively rewrite 
the paths in the xpath so the "when"/"must" statement is effectively 
bound to the nearest parent container that has presence.  That almost 
seems like a better way of thinking about what they really are.

Thanks,
Rob


On 05/08/2016 10:19, William Ivory wrote:
> Hi Lada,
>
> I was assuming that if a NP container had no children then from the perspective of current() it didn't exist, but that it was reasonable to evaluate the must expression on it as a 'virtual' node.  This just gets messier and messier, though I guess that 'count(*) = 0' (assuming no non-presence container children, otherwise would need to name children) would work instead?
>
> There seem to be 3 options for evaluating must statements on NP containers that have no children - would appreciate others' input on this.  In addition, Balazs' suggestion that modellers avoid must statements on NP containers where possible would seem sensible advice!
>
> (a) Never evaluate
>
> Never evaluate a must statement on a non-presence container that has no children.
>
> Pros:
> - simple to understand
> - reduces number of must statements to evaluate when validating configuration
> - less likely to lead to unintended consequences of must statements being evaluated on nodes that don't appear in configuration
>
> Cons:
> - some existing models (in YANG 1.0 and presumably YANG 1.1) assume evaluation of must statements on NP container children of existing nodes as added / clarified in YANG 1.1
> - need to confirm we can still model the likes of the ownership voucher must statement by altenative means if we adopt this interpretation
>
> (b) Evaluate when parent exists
>
> We evaluate must statements on non-presence container if their parent node is configured.
>
> Pros:
> - this is the stated position in YANG 1.1 (conflicting opinions exist on this alias as to whether it should be retrospectively applied to YANG 1.0 as 'clarification' or not)
> - some existing models assume this is the case (eg Jan's ownership-voucher example (YANG 1.0 model))
>
> Cons:
> - may lead to unintended consequences of must statements being unexpectedly evaluated (albeit model writers *should* understand how it works once we have clarified it!)
> - why only children, not grandchildren etc?  We examine mandatory and default on every single node, so why not for NP containers as well
>
> (c) Always evaluate
>
> We always evaluate must statements on non-presence containers
>
> Pros:
> - easy to understand this rule
>
> Cons:
> - this is different to both YANG 1.0 and YANG 1.1 current interpretation (whether you take the YANG 1.1 position as a change or as clarification on YANG 1.0)
> - validation now has the overhead of evaluating ALL must statements on all NP containers even when not configured.
>
> ---
>
> Regards,
>
> William
>
> -----Original Message-----
> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
> Sent: 05 August 2016 09:51
> To: William Ivory 
> Cc: Robert Wilton ; Jan Lindblad ; Netconf 
> Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
>
>
>> On 04 Aug 2016, at 15:27, William Ivory  wrote:
>>
>> So I quite agree that there are better ways of writing this.  However, my initial YANG is valid, and at first glance it is tempting to write it that way unless you have been following this discussion thread (-:
>>
>> The YANG 1.1 behaviour gives what I think some (many?) would see as unexpected behaviour.  If treated as clarification for YANG 1.0 (ie it applies to YANG 1.0 retrospectively) then we could end up invalidating currently valid YANG 1.0 models if they have any examples like mine below.  Conversely, Jan's ownership-voucher example would become invalid if we don't take the YANG 1.1 behaviour and retrospectively apply it to YANG 1.0.
>>
>> I'm also not convinced that only evaluating musts on NP containers to one level below configured nodes is consistent with how we deal with defaults and mandatory statements.  For those we examine all possible nodes, configured or otherwise, at any depth in the tree.  I think we should either never evaluate must statements on NP containers which have no children, or we should always evaluate them at any depth in the tree.  What's so special about those that are children of a configured node versus those that are grandchildren (or more)?
>>
>> I would be interested to hear from those who have written YANG models
>> (as opposed to those implementing YANG compilers) as to the perceived
>> impact of the different options on your existing models.  Internally
>> our YANG 1.0 models have been written on the assumption we do not
>> evaluate musts on NP containers with no child nodes, but it would be
>> reasonably easy to add 'not(current() or ...' to the
> This doesn't really work: in order to evaluate an XPath expression, the context node must exist, and in our case the context node is an instance of the NP-container. So "not(current())" by definition always evaluates to false.
>
> Lada
>
>>   front of any such must statements to render the outcome of this discussion irrelevant by ensuring the statements evaluate true when the NP container is not configured and thus effectively ignoring the constraint when not configured.
>>
>> Regards,
>>
>> William
>>
>> -----Original Message-----
>> From: Robert Wilton [mailto:rwilton@cisco.com]
>> Sent: 04 August 2016 14:10
>> To: William Ivory ; Jan Lindblad 
>> Cc: Netconf 
>> Subject: Re: [Netconf] What should a server response be? - depending
>> on NP-containers
>>
>> Hi William,
>>
>> On 04/08/2016 13:39, William Ivory wrote:
>>> Hi Rob,
>>>
>>> What about a must statement on a NP-container that implements mutual exclusivity with another node, eg the following when top is configured:
>>>
>>> Container top {
>>> 	Container np1 {
>>> 		Must "not(../np2_leaf)";
>>> 		Leaf np1_leaf { type string; }
>>> 	}
>>> 	Container np2 {
>>> 		Leaf np2_leaf { type string; }
>>> 	}
>>> }
>>>
>>> At first glance, I think many people would assume this was intended to prevent both np1_leaf and np2_leaf being configured at the same time.  However, if we configure np2_leaf, container 'top' is configured, so we evaluate the must on np1 (as a np container child of an existing node, as per YANG 1.1 stated requirements) and the must statement evaluates to false.  Therefore we cannot configure np2_leaf *ever* in this case.
>>>
>>> Now you could argue this is badly modelled YANG, but I would suggest it's decidedly non-obvious that np2_leaf is not configurable here.
>> RW:
>>
>> Yes, exactly.  This is why I don't like must statements on np
>> containers.  Enforcing a constraint on an construct that doesn't
>> properly exist is a bit odd :-)
>>
>> I would suggest that it would be clearer to write this as:
>>
>> Container top {
>>    Container np1 {
>>      Leaf np1_leaf {
>>        type string;
>>        must "not(../../np2_leaf)";
>>      }
>>    }
>>    Container np2 {
>>      Leaf np2_leaf {
>>        type string;
>>      }
>>    }
>> }
>>
>> or perhaps:
>>
>> Container top {
>>    Container np1 {
>>      Leaf np1_leaf {
>>        type string;
>>        must "not(../../np2_leaf)";
>>      }
>>    }
>>    Container np2 {
>>      Leaf np2_leaf {
>>        type string;
>>        must "not(../../np1_leaf)";
>>      }
>>    }
>> }
>>
>> Thanks,
>> Rob
>>
>>
>>> Regards,
>>>
>>> William
>>>
>>> -----Original Message-----
>>> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Robert
>>> Wilton
>>> Sent: 04 August 2016 13:28
>>> To: Jan Lindblad 
>>> Cc: Netconf 
>>> Subject: Re: [Netconf] What should a server response be? - depending
>>> on NP-containers
>>>
>>> Hi Jan,
>>>
>>>
>>> On 04/08/2016 12:21, Jan Lindblad wrote:
>>>> Rob,
>>>>
>>>>>> Jan Lindblad writes:
>>>>>>> I'm fine with this. Maybe we should clarify that must statements
>>>>>>> on NP containers are evaluated if the NP container parent exists.
>>>>>>> That's where the "always exists" notion might help understanding a bit.
>>>>>> Or say that their existance is meaningless and carries no semantic
>>>>>> value, and must/when conditions should never consider or depend on
>>>>>> their existence.
>>>>> Does that mean that for an empty NP container, it would be up to the server to decide whether or not to evaluate the containers must/when statements?
>>>> That would be terrible. It must be completely clear when must statements are evaluated and when not.
>>> It can't be that terrible, doesn't YANG 1.0 manage today with this
>>> behaviour? :-)
>>>
>>> I guess that my point is thus:  if a NP container's must/when condition should never consider/depend on the existence of said NP container, then for an empty NP container it should make no difference as to whether or not they they are evaluated by the device.
>>>
>>> I question whether it is sensible to allow when/must statements on an NP container at all.  In many ways I would rather that they were restricted to only schema nodes that actually exist as datanodes, at least then the semantics are obvious, no special magic behaviour is required.
>>>
>>>
>>>>>    But if the NP container exists due to existence of child nodes then the must/when statements would be guaranteed to be evaluated by the server?
>>>> I think there is no argument that must statements on NP containers MUST be evaluated when the container has child nodes. In my previous message, in the preceding text you didn't quote, I tried to explain why I think it's a bad idea to not also evaluate the must statements when the NP container is empty.
>>>> In many real cases, it's not easy for a model reader to know whether the container has child nodes or not.
>>> Yes.  I had read Phil's suggestion as: don't write must/when statements that depend on the existence of an NP container.  This sounds like quite sensible advise to me, but I might have misunderstood what he was suggesting.
>>>
>>> Thanks,
>>> Rob
>>>
>>>> /jan
>>>>
>>> _______________________________________________
>>> Netconf mailing list
>>> Netconf@ietf.org
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mai
>>> l
>>> man_listinfo_netconf&d=CwICAg&c=IL_XqQWOjubgfqINi2jTzg&r=GByLeg9jZvOv
>>> _
>>> AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=751sECIaA5HaNM0wQdHxLvA6UwL5IhKW91y_
>>> u 8ZrZ2Y&s=x12_Ko8id4YJBVF1rFmAvbKVrZCHdIHsFnzswwJ1k68&e=
>>> .
>>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
>> man_listinfo_netconf&d=CwIFAg&c=IL_XqQWOjubgfqINi2jTzg&r=GByLeg9jZvOv_
>> AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=6jlb0kQeoX8x29SUyoT8wXmmEAZeH2PaJOIXx
>> ueVRP4&s=o-TUEWoTedxYQZ0UmLD-TX17raAc9Dz1VMLk78SnXdU&e=
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> .
>


From nobody Fri Aug  5 09:15:45 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3091D12D5FD for ; Fri,  5 Aug 2016 09:15:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHwstIvydu2H for ; Fri,  5 Aug 2016 09:15:41 -0700 (PDT)
Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F62E12D5D5 for ; Fri,  5 Aug 2016 09:15:41 -0700 (PDT)
Received: by mail-ua0-x235.google.com with SMTP id 35so201131335uap.1 for ; Fri, 05 Aug 2016 09:15:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=bo93ul2klIwS3MIL06PfgCShV3OAyfytPiV8PpPDtH0=; b=1ScnUq99M/hrWm9rtZE1loQtWHSDmimld0sKvG9z8bx3CE/BcEITlmGuIjM0B8jaPv 4kG7kFUV3RkWh9SytZd4aVkcg12K+sV3Xb4eItFShdtHScOUAvT0tY4T9iA4P/EXxlnY FBoziO6KWcFpdsYs2tRth69ckiotN9xt8lG6V1ghN7T/+hXwLkiWrePE9Ldf/wReDpKC ZAL6pcQKqzL56he+vXNUySTSC3NZ9+1JRDbsrxaFrNshqsuNiWtlwKvvOKmETyAxmk+H x+Def9s+miNzzX9elLMrxWFdvp9QzE32wedI1f0E19WOATeRjoE6w33G+QLRLPGOfW1I YOrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=bo93ul2klIwS3MIL06PfgCShV3OAyfytPiV8PpPDtH0=; b=Q/FgkQVJsrQwZUOznKeq8ToUS9O89vYvqHIn3wLg3FL/4IGCiQkA7CFJpXvI4J0cdg AI/zBheEnJKQWXJ31jGICiykX1Vcyj2EopIzzvA6HxHfMbpMmhaqpiPoxuaF1Rfh5Ouc D7CDC8ojG7fS9IUqWJzanVl3fU6dUDcLBHfJxv1Ji2UtfAktbUDg11Q7dt42saztbFqu lsztFF94FI/C0EfuSMZBkv5xwdqVshfOpn71vsbhD9UtjPZun4WeKNCDyHyctv/AkioF XD+KZ2f2Kr4srR90WeEXxoHcZrfUVEUG2DllU7/3+lM96CPOuaMaH1BcmHqjdrO00SoO eESg==
X-Gm-Message-State: AEkoouvs7dLgwShlf32lTAUtkVtQhTn4hsUR14fG26zUl+1XrKj7H3GN1J4UkfZ0lfb5b8aZ0daNLUKoNBt4+w==
X-Received: by 10.159.35.112 with SMTP id 103mr40975294uae.55.1470413740173; Fri, 05 Aug 2016 09:15:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Fri, 5 Aug 2016 09:15:39 -0700 (PDT)
From: Andy Bierman 
Date: Fri, 5 Aug 2016 09:15:39 -0700
Message-ID: 
To: Netconf 
Content-Type: multipart/alternative; boundary=001a113ab81aa80081053955607c
Archived-At: 
Subject: [Netconf] NP-containers: 3 issues
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 Aug 2016 16:15:43 -0000

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

Hi,

There are 3 separate issues here of importance.


1) YANG Data Model: how NP containers work in the conceptual data model?

2) Protocol Interaction Models: how specific protocols (NETCONF, RESTCONF)
handle NP-container access?

3) RFC Publication Process: how much can be done with Errata statements?
(When will NETCONF  be moved from YANG 1.1 to NETCONF1.2?)

I am not sure any of these issues have been decided after MBs of email.

For (1), the current draft is clear wrt/ instances in the accessible tree

For (2), there are some that say use the operations intended for your
use-case
(merge/remove) and others that say make special rules for create/delete.

For (3), this looks like a significant change, not really an editorial
bugfix.
We need to wait to see the proposed edits, but changing major protocol
behavior in the NETCONF protocol, using an errata for the YANG RFC,
doesn't seem like a good idea.


Andy

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


Hi,

There are 3 separate issues here of=
 importance.


1) YANG Data Model: ho=
w NP containers work in the conceptual data model?

2) Protocol Interaction Models: how specific protocols (NETCONF, RESTCONF)=

handle NP-container access?

3) RFC Publ=
ication Process: how much can be done with Errata statements?
(Wh=
en will NETCONF <edit-config> be moved from YANG 1.1 to NETCONF1.2?)<=
/div>

I am not sure any of these issues have been decide=
d after MBs of email.

For (1), the current draft i=
s clear wrt/ instances in the accessible tree

For =
(2), there are some that say use the operations intended for your use-case<=
/div>
(merge/remove) and others that say make special rules for create/=
delete.

For (3), this looks like a significant cha=
nge, not really an editorial bugfix.
We need to wait to see the p=
roposed edits, but changing major protocol
behavior in the NETCON=
F protocol, using an errata for the YANG RFC,
doesn't seem li=
ke a good idea.


Andy

=



--001a113ab81aa80081053955607c--


From nobody Fri Aug  5 11:18:41 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D0C12D09B for ; Fri,  5 Aug 2016 11:18:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBCxvtUqvvm1 for ; Fri,  5 Aug 2016 11:18:38 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A63B812B049 for ; Fri,  5 Aug 2016 11:18:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 0C9261420DB4 for ; Fri,  5 Aug 2016 20:18:36 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id DMD7VlyAtjgb for ; Fri,  5 Aug 2016 20:18:35 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id DA0771420DC2 for ; Fri,  5 Aug 2016 20:18:35 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id oN2LhrnkSOFP for ; Fri,  5 Aug 2016 20:18:35 +0200 (CEST)
Received: from [192.168.209.141] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id BA6101420DB4 for ; Fri,  5 Aug 2016 20:18:35 +0200 (CEST)
Message-ID: <57A4D87A.1030604@transpacket.com>
Date: Fri, 05 Aug 2016 20:18:34 +0200
From: Vladimir Vassilev 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0
MIME-Version: 1.0
To: netconf@ietf.org
References: <201608031942.u73Jg8ol039135@idle.juniper.net> <5a49581e-71ef-4be9-1e51-62213901a887@cisco.com> <0066A47E-240F-4B6B-920B-98B064CE1E60@tail-f.com>   <05ea80f8-665b-d9b7-53db-207fc862409e@cisco.com> <5d8503f67066406a992738b766556247@EMEAWP-EXMB11.corp.brocade.com>  <357980ab80a64bbba5d6778fdf2160f8@EMEAWP-EXMB11.corp.brocade.com> <49054fe2-b1d1-ba18-a0a0-ea799e8947ef@cisco.com>
In-Reply-To: <49054fe2-b1d1-ba18-a0a0-ea799e8947ef@cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 Aug 2016 18:18:40 -0000

Hello,

The proposed changes must take into account the implications on existing 
models and extensions. I can think of NACM  for example where in some 
use-cases NP containers are used to grant update (but not create) rights 
to user groups. It is absolutely legal to configure "update" rights to 
/interfaces to a group of users reserving the "create" right to the 
superuser. How is this scenario handled by servers ignoring empty 
non-presence containers?

I personally do not like the YANG 1.1 auto evaluation of child NP 
containers text. The example of William Ivory from 08/04/2016 02:39 PM 
with the 2 mutually exclusive containers which is impossible in YANG 1.1 
is one of the precedents.

Vladimir



From nobody Sat Aug  6 10:38:51 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4AA12D552 for ; Sat,  6 Aug 2016 10:38:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfZQrcTL-XBR for ; Sat,  6 Aug 2016 10:38:48 -0700 (PDT)
Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::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 D4BB012D520 for ; Sat,  6 Aug 2016 10:38:48 -0700 (PDT)
Received: by mail-ua0-x233.google.com with SMTP id i31so73510617uai.2 for ; Sat, 06 Aug 2016 10:38:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=xOOYkGuyIJuo7tnW1Br8rIq/iOylw8n8AwgXMZNCGlY=; b=PZK512DnhVAYZBevcyChDGkjMvuZUyYY6GZ14xGbl3Z/VZ6E2d+9M8y5hWPJz5T/H0 ujSis8zhR5XORNYvqp1LfaDUgZ972VyIE/p68wvzNTVKer+Iz3TU0fxewgipJhEOQ5rH kLR5CnKUFuvYcvCYX/M4vlHF3z2yFxNwmw0HEVfnQ/jeoIFfj8GhBtmE5rfxAyNIr4eB +0LoPQLleN6JAVWK8nPbri+oMdlZmI30CjYYj4jpuYVDoIwirZTqf2kJIc6z/uc342YK +A2SmsJhCde2G9ZTkzhVp+WHAaGgo4l5IXqmzseRmrtdwb9XuqLT55mDS9kuEQtErMqc vi6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xOOYkGuyIJuo7tnW1Br8rIq/iOylw8n8AwgXMZNCGlY=; b=E9tQgKmiOUWNbg+oWx8mAhaPtxj35Mtu3ht8fRJd1EJUXFGj1W4vBRBKO5wG9m7lUf 3ymeOabSvXnFqJh4LpFO6uZ7xau2vaABhIuSima98xXgUonHX5Y8wE7E6RPz6Z83CuQx ZyZDDO1veCI5Is9MTgbchHswXqovMXMyU7c7b/b4oZvU+Tv0tEPXmwEow7totHP2+CHY MotRDkCEpZZVowO92UoSfEoazwEYiFsIX/pvr9z1EKdlPMVLWniPU0fZqi32QDfLR0iC CKqMgxK00NxYWSoETDuQDCjZNU9lNspTqtCelLXgW++6ukodz+pLVAwa+OKoa3JNVKXz V+bg==
X-Gm-Message-State: AEkoousAhjjdBdpzQMw5RQceo/zwjX25I9HEV0M2ckuJeHh9otWnogdFwkyMW+YIg/ze+XIh8Q9UESs4okcbLQ==
X-Received: by 10.176.3.232 with SMTP id 95mr2344556uau.9.1470505127575; Sat, 06 Aug 2016 10:38:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Sat, 6 Aug 2016 10:38:46 -0700 (PDT)
From: Andy Bierman 
Date: Sat, 6 Aug 2016 10:38:46 -0700
Message-ID: 
To: Netconf 
Content-Type: multipart/alternative; boundary=94eb2c056550c51c8505396aa74c
Archived-At: 
Subject: [Netconf] RESTCONF: #72: Location URI
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 06 Aug 2016 17:38:50 -0000

--94eb2c056550c51c8505396aa74c
Content-Type: text/plain; charset=UTF-8

Hi,

A Last Call comment has been raised about the URIs used in the
server because the host name needs to be specified in the URI.
It may not be known by the RESTCONF server.

This affects the Location URI returned by the server for created resources,
and the URIs for .well-known entry point, event stream, and schema
retrieval.


https://github.com/netconf-wg/restconf/issues/72


Is there an existing solution?
If not then I propose RESTCONF should not invent a new one.

This seems like an implementation detail for the server to
know the host-name it is supposed to use.


Andy

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


Hi,

A Last Call comment has been raised about=
 the URIs used in the
server because the host name needs to be sp=
ecified in the URI.
It may not be known by the RESTCONF server.

This affects the Location URI returned by the serve=
r for created resources,
and the URIs for .well-known entry=
 point, event stream, and schema retrieval.

Is there an existing solution?
If not then I pro=
pose RESTCONF should not invent a new one.

This se=
ems like an implementation detail for the server to
know the host=
-name it is supposed to use.


Andy








--94eb2c056550c51c8505396aa74c--


From nobody Mon Aug  8 15:08:31 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5841012D0CB for ; Mon,  8 Aug 2016 15:08:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level: 
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2qmPVhRf_Kr for ; Mon,  8 Aug 2016 15:08:28 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30134.outbound.protection.outlook.com [40.107.3.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9484C12D0AD for ; Mon,  8 Aug 2016 15:02:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=73R/aa7Iiq2aNN+8oGXcmTScPiX/jRos6lhNljW8/wE=; b=MakALnf0C5750hNHCVIhGZgIZsYNKGf4Ie/2YAEEEBEbqSREDUtBJIjJzRWZI8qbMSFCcsafFAiBVUImYYzX7GklzAzeEJkilazJnIXcT5FuRU8YVcNiTY/0kAfd6Rc4NiBRb9L9JYdkQdzg5ZREs+jz8wrDRfS1NxRD3iRaNUM=
Received: from HE1PR0701MB2859.eurprd07.prod.outlook.com (10.168.91.149) by HE1PR0701MB2858.eurprd07.prod.outlook.com (10.168.91.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Mon, 8 Aug 2016 22:02:15 +0000
Received: from HE1PR0701MB2859.eurprd07.prod.outlook.com ([10.168.91.149]) by HE1PR0701MB2859.eurprd07.prod.outlook.com ([10.168.91.149]) with mapi id 15.01.0549.025; Mon, 8 Aug 2016 22:02:15 +0000
From: "Ersue, Mehmet (Nokia - DE/Munich)" 
To: Netconf 
Thread-Topic: New Liaison Statement, "In Response to Liaison to IETF on YANG Models to enable G.fast deployments"
Thread-Index: AQHR8bzJ58q2CzgQhUq3Dzje3eB75aA/nWZQ
Date: Mon, 8 Aug 2016 22:02:15 +0000
Message-ID: 
References: <147069212837.32181.3094970359014067018.idtracker@ietfa.amsl.com>
In-Reply-To: <147069212837.32181.3094970359014067018.idtracker@ietfa.amsl.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=mehmet.ersue@nokia.com; 
x-originating-ip: [217.251.0.112]
x-ms-office365-filtering-correlation-id: 6fbcf710-9282-4329-6762-08d3bfd7a876
x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2858; 6:aLTFpYj3PFQ/oYEt7BsErGiBmy7Xq9Xnya8IOJ2xnVhKiwrCHyuLEJNfc9sFSf9/RHWezialqae9p5WqqmljKnIoy4Ce3R3lRvZHEc5V8+i+m9UZpyTrY1mj23wKPATSoVJfyl21Ttau06MJUllW1qfUs7qjaAK/bz5bGXBjnS1YqWSuWB4RtDBFcBXdX3okSNpeCRCfEGNGH3K5Pp6YnhrL6CA0byCpEdrGPyINMSrz05VkDtvNAB81mrv/nz3M81FfeSkAT8wmO+rlRKkOasNhxiEjYHY6VQfEvPk666TdqGp5C4f7J+CcPEJRHtKGcyXLuJGXarDP3052WuKFPQ==; 5:HV7naNhRWljHWHlxTdoYoezdEN4AdLU4yDA4Nw63YCMdHCXapUW4VeFm5wxNyNtSe8OUsVX3KKxg2cJtj7uZMAlB9dMB5ACVv3rZKV9aGUzVNJBc5lXJp7E6mKLx+BVZ3dPGunm3rwGbdfJvZ5qKFw==; 24:nZ8Eec5ljk6gX7RP65idNg2EzyX6Z7GPWauIC9NqzjQFNnH1pWeHtlFx6GvMwGsx44lnRPk+dyPG2mnoeXsjcNftdiC6ROTpH1nwnGZJM/U=; 7:H7iVgPKyGJVSx+VCuqD1BZ672LK2PMjnRYP8QCM2ATsmUjbDOS2NF2LjIwwzRoTpCjJn2FVGiPOaUIW7/jfTY9rADLOPRIUGlzPdFbyoYHf92xOal1jzIHYYUqu2nnmAYmzgo9blgRmG1Aatd5qGUD5OCAeZaCFPQ2KenVi1ONhYnwq/5/Ey4weyEyEreqjYiduge3kJpObzKDIaHv+mYPc+1QVIwaSRrkVwf6fSCBzYY1WtoB4n0QYoyeaoFTQS
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0701MB2858;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(37575265505322)(120809045254105)(138986009662008)(82608151540597)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026);  SRVR:HE1PR0701MB2858; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2858; 
x-forefront-prvs: 00286C0CA6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377424004)(13464003)(199003)(377454003)(189002)(189998001)(107886002)(110136002)(2950100001)(8936002)(19580395003)(87936001)(66066001)(76176999)(97736004)(19580405001)(77096005)(54356999)(101416001)(15975445007)(2900100001)(5890100001)(106356001)(50986999)(106116001)(105586002)(450100001)(5002640100001)(81156014)(305945005)(33656002)(81166006)(2906002)(3280700002)(3660700001)(345774005)(586003)(86362001)(3846002)(10400500002)(7846002)(7696003)(11100500001)(6116002)(9686002)(102836003)(74316002)(92566002)(68736007)(7736002)(122556002)(8676002)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2858; H:HE1PR0701MB2859.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Aug 2016 22:02:15.1395 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2858
Archived-At: 
Subject: [Netconf] FW: New Liaison Statement, "In Response to Liaison to IETF on YANG Models to enable G.fast deployments"
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 Aug 2016 22:08:30 -0000

LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExpYWlzb24gU3RhdGVtZW50IE1hbmFn
ZW1lbnQgVG9vbCBbbWFpbHRvOmxzbXRAaWV0Zi5vcmddIA0KU2VudDogTW9uZGF5LCBBdWd1c3Qg
MDgsIDIwMTYgMTE6MzUgUE0NClRvOiBtaWNoYWVsLmZhcmdhbm9AY2VudHVyeWxpbmsuY29tDQpT
dWJqZWN0OiBOZXcgTGlhaXNvbiBTdGF0ZW1lbnQsICJJbiBSZXNwb25zZSB0byBMaWFpc29uIHRv
IElFVEYgb24gWUFORyBNb2RlbHMgdG8gZW5hYmxlIEcuZmFzdCBkZXBsb3ltZW50cyINCg0KVGl0
bGU6IEluIFJlc3BvbnNlIHRvIExpYWlzb24gdG8gSUVURiBvbiBZQU5HIE1vZGVscyB0byBlbmFi
bGUgRy5mYXN0IGRlcGxveW1lbnRzDQpTdWJtaXNzaW9uIERhdGU6IDIwMTYtMDgtMDgNClVSTCBv
ZiB0aGUgSUVURiBXZWIgcGFnZTogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29u
LzE0ODgvDQoNCkZyb206ICJCZW5vaXQgQ2xhaXNlIiA8YmNsYWlzZUBjaXNjby5jb20+DQpUbzog
bWljaGFlbC5mYXJnYW5vQGNlbnR1cnlsaW5rLmNvbQ0KQ2M6IEpvZWwgSmFlZ2dsaSA8am9lbGph
QGJvZ3VzLmNvbT4sTWFoZXNoIEpldGhhbmFuZGFuaSA8bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+
LERhdmlkIFNpbmljcm9wZSA8ZGF2aWQuc2luaWNyb3BlQGVyaWNzc29uLmNvbT4sTWVobWV0IEVy
c3VlIDxtZWhtZXQuZXJzdWVAbm9raWEuY29tPixORVRDT05GIERhdGEgTW9kZWxpbmcgTGFuZ3Vh
Z2UgRGlzY3Vzc2lvbiBMaXN0IDxuZXRtb2RAaWV0Zi5vcmc+LEtlbnQgV2F0c2VuIDxrd2F0c2Vu
QGp1bmlwZXIubmV0PixMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0PixCZW5vaXQgQ2xhaXNl
IDxiY2xhaXNlQGNpc2NvLmNvbT4sTmV0d29yayBDb25maWd1cmF0aW9uIERpc2N1c3Npb24gTGlz
dCA8bmV0Y29uZkBpZXRmLm9yZz4sDQpSZXNwb25zZSBDb250YWN0czogSsO8cmdlbiBTY2jDtm53
w6RsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+LCBUb20gTmFkZWF1
IDx0bmFkZWF1QGx1Y2lkdmlzaW9uLmNvbT4sTWFoZXNoIEpldGhhbmFuZGFuaSA8bWpldGhhbmFu
ZGFuaUBnbWFpbC5jb20+LE1laG1ldCBFcnN1ZSA8bWVobWV0LmVyc3VlQG5va2lhLmNvbT4NClRl
Y2huaWNhbCBDb250YWN0czogDQpQdXJwb3NlOiBJbiByZXNwb25zZQ0KDQpSZWZlcmVuY2VkIGxp
YWlzb246IExpYWlzb24gdG8gSUVURiBvbiBZQU5HIE1vZGVscyB0byBlbmFibGUgRy5mYXN0IGRl
cGxveW1lbnRzIChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTQ3Ni8pDQoN
CkJvZHk6IERlYXIgYWxsLA0KDQpUaGUgTkVUTU9EIGFuZCBORVRDT05GIFdHcyB0aGFuayB5b3Ug
Zm9yIHJlZmVyZW5jaW5nIHRoZSB3b3JrIG9mIHRoZQ0KSUVURiBhbmQgY29udHJpYnV0aW5nIHRv
IHRoZSBkcmFmdHMgeW91IG1lbnRpb24gdGhyb3VnaCB0aGUgSUVURg0KcHJvY2Vzcy4gVGhpcyBp
cyBieSBmYXIgdGhlIGJlc3Qgd2F5IHRvIGNvbXBsZXRlIHRoZSB3b3JrIGluIGEgdGltZWx5DQpt
YW5uZXIgYW5kIGNvbnRpbnVlcyB0byBmb3N0ZXIgdGhlIG9wZW4gYW5kIGNvb3BlcmF0aXZlIHdv
cmtpbmcNCnJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBJRVRGIGFuZCB0aGUgQnJvYWRiYW5kIEZv
cnVtLg0KDQpJbiB0aGUgbWVhbiB0aW1lLCB0aGUgdHdvIGRyYWZ0cyB5b3Ugbm90ZSBiZWNhbWUg
V0cgZG9jdW1lbnRzOg0KZHJhZnQtaWV0Zi1uZXRtb2QtZW50aXR5IGFuZCBkcmFmdC1pZXRmLW5l
dG1vZC1pbnRmLWV4dC15YW5nLTAwLiBXZQ0KZW5jb3VyYWdlIHlvdSB0byBmb2xsb3cgcHJvZ3Jl
c3Mgb24gZGF0YSB0cmFja2VyDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm
dC1pZXRmLW5ldG1vZC1pbnRmLWV4dC15YW5nLyBhbmQNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0
Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0bW9kLWVudGl0eS8gYW5kIHRocm91Z2gNCnRoZSBwYXJ0
aWNpcGF0aW9uIHlvdSBoYXZlIG5vdGVkLg0KDQpSZWdhcmRpbmcgeW91ciBpbnRlcmVzdCB0byB3
b3JrIG9uICJmb3J3YXJkaW5nL1FvUyBhbmQgcmVxdWlyZWQNCnByb3RvY29scyAoZS5nLiBsYXll
ciAyIG11bHRpY2FzdCBtb2RlbCAmIERIQ1ApIiwgcGxlYXNlIG5vdGUgdGhhdCB0aGVyZQ0KYXJl
IGFscmVhZHkgYSBjb3VwbGUgb2YgZm9yd2FyZGluZyByZWxhdGVkIFlBTkcgZGF0YSBtb2RlbHMs
IG1haW5seSBMMw0KZm9yd2FyZGluZy4gVGhlcmUgaXMgYWxzbyBhIFFvUyByZWxhdGVkIFlBTkcg
ZGF0YSBtb2RlbCwNCmRyYWZ0LWFzZWNob3VkLW5ldG1vZC1xb3MtbW9kZWwsIHdoaWNoIHdlIGJl
bGlldmUgY291bGQgYmVjb21lIGEgV0cNCmRvY3VtZW50LiBBbmQgZmluYWxseSwgYSBZQU5HIG11
bHRpY2FzdCBkZXNpZ24gdGVhbSwNCmh0dHBzOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9waW0v
dHJhYy93aWtpL3lhbmcsIGZvY3VzZXMgb24gcHJvZHVjaW5nDQpQSU0gYW5kIElHTVAvTUxEIFlB
TkcgZGF0YSBtb2RlbHMuIFBsZWFzZSB3b3JrIHdpdGggdGhlIHJlc3BlY3RpdmUNCmNvbnRyaWJ1
dG9ycyBzbyB0aGF0IHRoZSBsYXllciAyIHNwZWNpZmljIGRhdGEgbW9kZWwgYXNwZWN0cyBuaWNl
bHkgZml0DQppbiB0aGUgb3ZlcmFsbCBkYXRhIG1vZGVscy4NCg0KSWYgeW91IGhhdmUgaW50ZXJl
c3QgaW4gb3RoZXIgcmVsYXRlZCBJRVRGIHdvcmsgcGxlYXNlIGRvbid0IGhlc2l0YXRlIHRvDQps
ZXQgdXMga25vdy4NCg0KUGxlYXNlIGNvbnRpbnVlIHRvIGtlZXAgdXMgYXBwcmlzZWQgb2YgeW91
ciB3b3JrIG5vdGVkLg0KQXR0YWNobWVudHM6DQoNCk5vIGRvY3VtZW50IGhhcyBiZWVuIGF0dGFj
aGVkDQoNCg==


From nobody Wed Aug 10 14:23:18 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C06812D85E for ; Wed, 10 Aug 2016 14:23:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqcE4Shwyeh7 for ; Wed, 10 Aug 2016 14:23:13 -0700 (PDT)
Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::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 3605212D54C for ; Wed, 10 Aug 2016 14:23:13 -0700 (PDT)
Received: by mail-ua0-x234.google.com with SMTP id 97so90848962uav.3 for ; Wed, 10 Aug 2016 14:23:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mTfKBH9I5dvvfRgXquI/hBdFoiS/BTmJLF+PDJEnTtk=; b=OFKnV1xDSN9jjU+uL1/zrOWxxY+eWUz160IiX0RYfoAUN8nS9nclli0jp8WBwoldAW Q27bvDe3IyqzJEmER403Imyv8tA+yIyVsLmMlTWOceMPhSI2vzDJ7Kp8rU72dAHh+4VB brAXN9Ih3AKc7zwLAS0C20Ff4mvyoEI+3YPzv172GqhSWdk3jlKZNgJcStkrx3JTDy6N rwYKyWt+i6cbTnZYl+L2wnnZ3CJikcNVSgWOqusAJRhvzdmozbsH8JJtCZO3uRSOmzbI ZAS7+fdtWNzt5nXS5LVIKEvX5j3K4ZH7Op0R8QoeDx9HDNpanQUmdk/tBesj6BDlF6PP Gumw==
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:from:date :message-id:subject:to:cc; bh=mTfKBH9I5dvvfRgXquI/hBdFoiS/BTmJLF+PDJEnTtk=; b=K99BcX/lTlCTaBeDPTBLA1fBs+5+zN08puYpHh8KKqLFHccjnLBqKDymuqYLIk7TCz p+ubFLRccPCD4iDhqn52HLw2cAlA3LinvMzUf4QeJhbXj3r5xQXBuq2J1OY5EiPE2xuM zOC5u+yQ5sdievFj4kZqMmxHKbWXo9UpPxnl7nwG8oUzQYxGhoVji4oJ21W0TmRrcq6V Bw2USp6IMZOlqvX7ZBD0YPWcLCrEUcYAZN5t2bB3PI/XeIStGubRl3H+kvkNx+J+0HX6 FtHMpTshZIJL2oimhPNGXunNbUG/w0x9fhRJu64i+ESK9n14vM8hVsjv9MksW0O3VCTo KgOg==
X-Gm-Message-State: AEkoouua97RQ9ZmiQ7HxJX6sc1wLlGZMnsnV2uNJfVI69TlUcceV8QeHVasMmxZcl5LIoEKu0Nd3gBd8UY5Wvg==
X-Received: by 10.31.252.203 with SMTP id a194mr2617122vki.44.1470864192075; Wed, 10 Aug 2016 14:23:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Wed, 10 Aug 2016 14:23:10 -0700 (PDT)
In-Reply-To: <49054fe2-b1d1-ba18-a0a0-ea799e8947ef@cisco.com>
References: <201608031942.u73Jg8ol039135@idle.juniper.net> <5a49581e-71ef-4be9-1e51-62213901a887@cisco.com> <0066A47E-240F-4B6B-920B-98B064CE1E60@tail-f.com>   <05ea80f8-665b-d9b7-53db-207fc862409e@cisco.com> <5d8503f67066406a992738b766556247@EMEAWP-EXMB11.corp.brocade.com>  <357980ab80a64bbba5d6778fdf2160f8@EMEAWP-EXMB11.corp.brocade.com> <49054fe2-b1d1-ba18-a0a0-ea799e8947ef@cisco.com>
From: Andy Bierman 
Date: Wed, 10 Aug 2016 14:23:10 -0700
Message-ID: 
To: Robert Wilton 
Content-Type: multipart/alternative; boundary=94eb2c149bd4ae8d7b0539be41b4
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Aug 2016 21:23:16 -0000

--94eb2c149bd4ae8d7b0539be41b4
Content-Type: text/plain; charset=UTF-8

Hi,

I am quite willing to accept the existing design in YANG 1.1 that NP
containers
are considered to be present if there is a non-NP ancestor present (or the
NP container is a top-level data node).  This is easier to support.
It matches the top-down callback design of many server implementations.

The update rules in sec 11 of 6020bis do not cover NP-containers correctly.
It should be illegal to add a mandatory NP-container as a child node
to the augment target.


This needs to include must-stmt (fixed in the term "mandatory node", bullet
3)
I don't think the text below is quite right.  I suspect Lada can do better.


OLD:

sec 3.

   o  mandatory node: A mandatory node is one of:

      *  A leaf, choice, anydata, or anyxml node with a "mandatory"
         statement with the value "true".

      *  A list or leaf-list node with a "min-elements" statement with a
         value greater than zero.

      *  A container node without a "presence" statement and which has
         at least one mandatory node as a child.



NEW:

  o  mandatory node: A mandatory node is one of:

      *  A leaf, choice, anydata, or anyxml node with a "mandatory"
         statement with the value "true".

      *  A list or leaf-list node with a "min-elements" statement with a
         value greater than zero.

      *  A container node without a "presence" statement and which has
         at least one mandatory node as a child, or has a "must" statement
         that will evaluate to "false" if the container has no child node
instances.



Andy





On Fri, Aug 5, 2016 at 6:57 AM, Robert Wilton  wrote:

> Hi William,
>
> Pragmatically, I think that I would also go for (b), with the fix
> suggested by Lada.
>
> My reasoning is that despite not liking "when"/"must" statements on
> np-containers they are clearly useful in some cases and cannot be banned
> outright.
>
> I also like Phil's explanation that a server could effectively rewrite the
> paths in the xpath so the "when"/"must" statement is effectively bound to
> the nearest parent container that has presence.  That almost seems like a
> better way of thinking about what they really are.
>
> Thanks,
> Rob
>
>
> On 05/08/2016 10:19, William Ivory wrote:
>
>> Hi Lada,
>>
>> I was assuming that if a NP container had no children then from the
>> perspective of current() it didn't exist, but that it was reasonable to
>> evaluate the must expression on it as a 'virtual' node.  This just gets
>> messier and messier, though I guess that 'count(*) = 0' (assuming no
>> non-presence container children, otherwise would need to name children)
>> would work instead?
>>
>> There seem to be 3 options for evaluating must statements on NP
>> containers that have no children - would appreciate others' input on this.
>> In addition, Balazs' suggestion that modellers avoid must statements on NP
>> containers where possible would seem sensible advice!
>>
>> (a) Never evaluate
>>
>> Never evaluate a must statement on a non-presence container that has no
>> children.
>>
>> Pros:
>> - simple to understand
>> - reduces number of must statements to evaluate when validating
>> configuration
>> - less likely to lead to unintended consequences of must statements being
>> evaluated on nodes that don't appear in configuration
>>
>> Cons:
>> - some existing models (in YANG 1.0 and presumably YANG 1.1) assume
>> evaluation of must statements on NP container children of existing nodes as
>> added / clarified in YANG 1.1
>> - need to confirm we can still model the likes of the ownership voucher
>> must statement by altenative means if we adopt this interpretation
>>
>> (b) Evaluate when parent exists
>>
>> We evaluate must statements on non-presence container if their parent
>> node is configured.
>>
>> Pros:
>> - this is the stated position in YANG 1.1 (conflicting opinions exist on
>> this alias as to whether it should be retrospectively applied to YANG 1.0
>> as 'clarification' or not)
>> - some existing models assume this is the case (eg Jan's
>> ownership-voucher example (YANG 1.0 model))
>>
>> Cons:
>> - may lead to unintended consequences of must statements being
>> unexpectedly evaluated (albeit model writers *should* understand how it
>> works once we have clarified it!)
>> - why only children, not grandchildren etc?  We examine mandatory and
>> default on every single node, so why not for NP containers as well
>>
>> (c) Always evaluate
>>
>> We always evaluate must statements on non-presence containers
>>
>> Pros:
>> - easy to understand this rule
>>
>> Cons:
>> - this is different to both YANG 1.0 and YANG 1.1 current interpretation
>> (whether you take the YANG 1.1 position as a change or as clarification on
>> YANG 1.0)
>> - validation now has the overhead of evaluating ALL must statements on
>> all NP containers even when not configured.
>>
>> ---
>>
>> Regards,
>>
>> William
>>
>> -----Original Message-----
>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>> Sent: 05 August 2016 09:51
>> To: William Ivory 
>> Cc: Robert Wilton ; Jan Lindblad ;
>> Netconf 
>> Subject: Re: [Netconf] What should a server response be? - depending on
>> NP-containers
>>
>>
>> On 04 Aug 2016, at 15:27, William Ivory  wrote:
>>>
>>> So I quite agree that there are better ways of writing this.  However,
>>> my initial YANG is valid, and at first glance it is tempting to write it
>>> that way unless you have been following this discussion thread (-:
>>>
>>> The YANG 1.1 behaviour gives what I think some (many?) would see as
>>> unexpected behaviour.  If treated as clarification for YANG 1.0 (ie it
>>> applies to YANG 1.0 retrospectively) then we could end up invalidating
>>> currently valid YANG 1.0 models if they have any examples like mine below.
>>> Conversely, Jan's ownership-voucher example would become invalid if we
>>> don't take the YANG 1.1 behaviour and retrospectively apply it to YANG 1.0.
>>>
>>> I'm also not convinced that only evaluating musts on NP containers to
>>> one level below configured nodes is consistent with how we deal with
>>> defaults and mandatory statements.  For those we examine all possible
>>> nodes, configured or otherwise, at any depth in the tree.  I think we
>>> should either never evaluate must statements on NP containers which have no
>>> children, or we should always evaluate them at any depth in the tree.
>>> What's so special about those that are children of a configured node versus
>>> those that are grandchildren (or more)?
>>>
>>> I would be interested to hear from those who have written YANG models
>>> (as opposed to those implementing YANG compilers) as to the perceived
>>> impact of the different options on your existing models.  Internally
>>> our YANG 1.0 models have been written on the assumption we do not
>>> evaluate musts on NP containers with no child nodes, but it would be
>>> reasonably easy to add 'not(current() or ...' to the
>>>
>> This doesn't really work: in order to evaluate an XPath expression, the
>> context node must exist, and in our case the context node is an instance of
>> the NP-container. So "not(current())" by definition always evaluates to
>> false.
>>
>> Lada
>>
>>   front of any such must statements to render the outcome of this
>>> discussion irrelevant by ensuring the statements evaluate true when the NP
>>> container is not configured and thus effectively ignoring the constraint
>>> when not configured.
>>>
>>> Regards,
>>>
>>> William
>>>
>>> -----Original Message-----
>>> From: Robert Wilton [mailto:rwilton@cisco.com]
>>> Sent: 04 August 2016 14:10
>>> To: William Ivory ; Jan Lindblad 
>>> Cc: Netconf 
>>> Subject: Re: [Netconf] What should a server response be? - depending
>>> on NP-containers
>>>
>>> Hi William,
>>>
>>> On 04/08/2016 13:39, William Ivory wrote:
>>>
>>>> Hi Rob,
>>>>
>>>> What about a must statement on a NP-container that implements mutual
>>>> exclusivity with another node, eg the following when top is configured:
>>>>
>>>> Container top {
>>>>         Container np1 {
>>>>                 Must "not(../np2_leaf)";
>>>>                 Leaf np1_leaf { type string; }
>>>>         }
>>>>         Container np2 {
>>>>                 Leaf np2_leaf { type string; }
>>>>         }
>>>> }
>>>>
>>>> At first glance, I think many people would assume this was intended to
>>>> prevent both np1_leaf and np2_leaf being configured at the same time.
>>>> However, if we configure np2_leaf, container 'top' is configured, so we
>>>> evaluate the must on np1 (as a np container child of an existing node, as
>>>> per YANG 1.1 stated requirements) and the must statement evaluates to
>>>> false.  Therefore we cannot configure np2_leaf *ever* in this case.
>>>>
>>>> Now you could argue this is badly modelled YANG, but I would suggest
>>>> it's decidedly non-obvious that np2_leaf is not configurable here.
>>>>
>>> RW:
>>>
>>> Yes, exactly.  This is why I don't like must statements on np
>>> containers.  Enforcing a constraint on an construct that doesn't
>>> properly exist is a bit odd :-)
>>>
>>> I would suggest that it would be clearer to write this as:
>>>
>>> Container top {
>>>    Container np1 {
>>>      Leaf np1_leaf {
>>>        type string;
>>>        must "not(../../np2_leaf)";
>>>      }
>>>    }
>>>    Container np2 {
>>>      Leaf np2_leaf {
>>>        type string;
>>>      }
>>>    }
>>> }
>>>
>>> or perhaps:
>>>
>>> Container top {
>>>    Container np1 {
>>>      Leaf np1_leaf {
>>>        type string;
>>>        must "not(../../np2_leaf)";
>>>      }
>>>    }
>>>    Container np2 {
>>>      Leaf np2_leaf {
>>>        type string;
>>>        must "not(../../np1_leaf)";
>>>      }
>>>    }
>>> }
>>>
>>> Thanks,
>>> Rob
>>>
>>>
>>> Regards,
>>>>
>>>> William
>>>>
>>>> -----Original Message-----
>>>> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Robert
>>>> Wilton
>>>> Sent: 04 August 2016 13:28
>>>> To: Jan Lindblad 
>>>> Cc: Netconf 
>>>> Subject: Re: [Netconf] What should a server response be? - depending
>>>> on NP-containers
>>>>
>>>> Hi Jan,
>>>>
>>>>
>>>> On 04/08/2016 12:21, Jan Lindblad wrote:
>>>>
>>>>> Rob,
>>>>>
>>>>> Jan Lindblad writes:
>>>>>>>
>>>>>>>> I'm fine with this. Maybe we should clarify that must statements
>>>>>>>> on NP containers are evaluated if the NP container parent exists.
>>>>>>>> That's where the "always exists" notion might help understanding a
>>>>>>>> bit.
>>>>>>>>
>>>>>>> Or say that their existance is meaningless and carries no semantic
>>>>>>> value, and must/when conditions should never consider or depend on
>>>>>>> their existence.
>>>>>>>
>>>>>> Does that mean that for an empty NP container, it would be up to the
>>>>>> server to decide whether or not to evaluate the containers must/when
>>>>>> statements?
>>>>>>
>>>>> That would be terrible. It must be completely clear when must
>>>>> statements are evaluated and when not.
>>>>>
>>>> It can't be that terrible, doesn't YANG 1.0 manage today with this
>>>> behaviour? :-)
>>>>
>>>> I guess that my point is thus:  if a NP container's must/when condition
>>>> should never consider/depend on the existence of said NP container, then
>>>> for an empty NP container it should make no difference as to whether or not
>>>> they they are evaluated by the device.
>>>>
>>>> I question whether it is sensible to allow when/must statements on an
>>>> NP container at all.  In many ways I would rather that they were restricted
>>>> to only schema nodes that actually exist as datanodes, at least then the
>>>> semantics are obvious, no special magic behaviour is required.
>>>>
>>>>
>>>>    But if the NP container exists due to existence of child nodes then
>>>>>> the must/when statements would be guaranteed to be evaluated by the server?
>>>>>>
>>>>> I think there is no argument that must statements on NP containers
>>>>> MUST be evaluated when the container has child nodes. In my previous
>>>>> message, in the preceding text you didn't quote, I tried to explain why I
>>>>> think it's a bad idea to not also evaluate the must statements when the NP
>>>>> container is empty.
>>>>> In many real cases, it's not easy for a model reader to know whether
>>>>> the container has child nodes or not.
>>>>>
>>>> Yes.  I had read Phil's suggestion as: don't write must/when statements
>>>> that depend on the existence of an NP container.  This sounds like quite
>>>> sensible advise to me, but I might have misunderstood what he was
>>>> suggesting.
>>>>
>>>> Thanks,
>>>> Rob
>>>>
>>>> /jan
>>>>>
>>>>> _______________________________________________
>>>> Netconf mailing list
>>>> Netconf@ietf.org
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mai
>>>> l
>>>> man_listinfo_netconf&d=CwICAg&c=IL_XqQWOjubgfqINi2jTzg&r=GByLeg9jZvOv
>>>> _
>>>> AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=751sECIaA5HaNM0wQdHxLvA6UwL5IhKW91y_
>>>> u 8ZrZ2Y&s=x12_Ko8id4YJBVF1rFmAvbKVrZCHdIHsFnzswwJ1k68&e=
>>>> .
>>>>
>>>> _______________________________________________
>>> Netconf mailing list
>>> Netconf@ietf.org
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
>>> man_listinfo_netconf&d=CwIFAg&c=IL_XqQWOjubgfqINi2jTzg&r=GByLeg9jZvOv_
>>> AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=6jlb0kQeoX8x29SUyoT8wXmmEAZeH2PaJOIXx
>>> ueVRP4&s=o-TUEWoTedxYQZ0UmLD-TX17raAc9Dz1VMLk78SnXdU&e=
>>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>>
>>
>>
>> .
>>
>>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>

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


Hi,

I am quite willing to accept the ex=
isting design in YANG 1.1 that NP containers
are considered to be=
 present if there is a non-NP ancestor present (or the
NP contain=
er is a top-level data node).=C2=A0 This is easier to support.
It=
 matches the top-down callback design of many server implementations.
=


The update rules in sec 11 of 6020bis do not cover NP-c=
ontainers correctly.
It should be illegal to add a mandatory NP-c=
ontainer as a child node
to the augment target.=C2=A0
<=
br>

This needs to include must-stmt (fixed in the =
term "mandatory node", bullet 3)
I don't think the =
text below is quite right.=C2=A0 I suspect Lada can do better.

OLD:

sec 3.
=

=C2=A0 =C2=A0o =C2=A0mandatory node: A mandatory node i=
s one of:

=C2=A0 =C2=A0 =C2=A0 * =C2=A0A leaf, cho=
ice, anydata, or anyxml node with a "mandatory"
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0statement with the value "true".
=


=C2=A0 =C2=A0 =C2=A0 * =C2=A0A list or leaf-list node w=
ith a "min-elements" statement with a
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0value greater than zero.

=C2=A0 =
=C2=A0 =C2=A0 * =C2=A0A container node without a "presence" state=
ment and which has
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0at least one=
 mandatory node as a child.


<=
br>
NEW:

=C2=A0=C2=A0o =C2=A0mandatory n=
ode: A mandatory node is one of:

=C2=A0 =
=C2=A0 =C2=A0 * =C2=A0A leaf, choice, anydata, or anyxml node with a "=
mandatory"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0statement with =
the value "true".

=C2=A0 =C2=A0 =C2=A0 *=
 =C2=A0A list or leaf-list node with a "min-elements" statement w=
ith a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0value greater than zero.<=
/div>

=C2=A0 =C2=A0 =C2=A0 * =C2=A0A container node with=
out a "presence" statement and which has
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0at least one mandatory node as a child, or has a "=
must" statement
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that=
 will evaluate to "false" if the container has no child node inst=
ances.



Andy





On Fri, Aug 5, 2016 at 6:57=
 AM, Robert Wilton <rwilton@cisco.com> wrote:
Hi William,



Pragmatically, I think that I would also go for (b), with the fix suggested=
 by Lada.



My reasoning is that despite not liking "when"/"must" s=
tatements on np-containers they are clearly useful in some cases and cannot=
 be banned outright.



I also like Phil's explanation that a server could effectively rewrite =
the paths in the xpath so the "when"/"must" statement i=
s effectively bound to the nearest parent container that has presence.=C2=
=A0 That almost seems like a better way of thinking about what they really =
are.



Thanks,

Rob





On 05/08/2016 10:19, William Ivory wrote:



Hi Lada,



I was assuming that if a NP container had no children then from the perspec=
tive of current() it didn't exist, but that it was reasonable to evalua=
te the must expression on it as a 'virtual' node.=C2=A0 This just g=
ets messier and messier, though I guess that 'count(*) =3D 0' (assu=
ming no non-presence container children, otherwise would need to name child=
ren) would work instead?



There seem to be 3 options for evaluating must statements on NP containers =
that have no children - would appreciate others' input on this.=C2=A0 I=
n addition, Balazs' suggestion that modellers avoid must statements on =
NP containers where possible would seem sensible advice!



(a) Never evaluate



Never evaluate a must statement on a non-presence container that has no chi=
ldren.



Pros:

- simple to understand

- reduces number of must statements to evaluate when validating configurati=
on

- less likely to lead to unintended consequences of must statements being e=
valuated on nodes that don't appear in configuration



Cons:

- some existing models (in YANG 1.0 and presumably YANG 1.1) assume evaluat=
ion of must statements on NP container children of existing nodes as added =
/ clarified in YANG 1.1

- need to confirm we can still model the likes of the ownership voucher mus=
t statement by altenative means if we adopt this interpretation



(b) Evaluate when parent exists



We evaluate must statements on non-presence container if their parent node =
is configured.



Pros:

- this is the stated position in YANG 1.1 (conflicting opinions exist on th=
is alias as to whether it should be retrospectively applied to YANG 1.0 as =
'clarification' or not)

- some existing models assume this is the case (eg Jan's ownership-vouc=
her example (YANG 1.0 model))



Cons:

- may lead to unintended consequences of must statements being unexpectedly=
 evaluated (albeit model writers *should* understand how it works once we h=
ave clarified it!)

- why only children, not grandchildren etc?=C2=A0 We examine mandatory and =
default on every single node, so why not for NP containers as well



(c) Always evaluate



We always evaluate must statements on non-presence containers



Pros:

- easy to understand this rule



Cons:

- this is different to both YANG 1.0 and YANG 1.1 current interpretation (w=
hether you take the YANG 1.1 position as a change or as clarification on YA=
NG 1.0)

- validation now has the overhead of evaluating ALL must statements on all =
NP containers even when not configured.



---



Regards,



William



-----Original Message-----

From: Ladislav Lhotka [mailto:lhotka@nic.cz]

Sent: 05 August 2016 09:51

To: William Ivory <wivory@Brocade.com>

Cc: Robert Wilton <rwilton@cisco.com>; Jan Lindblad <janl@tail-f.com>; Netconf <netconf@ietf.org>

Subject: Re: [Netconf] What should a server response be? - depending on NP-=
containers







On 04 Aug 2016, at 15:27, William Ivory <wivory@Brocade.com> wrote:


So I quite agree that there are better ways of writing this.=C2=A0 However,=
 my initial YANG is valid, and at first glance it is tempting to write it t=
hat way unless you have been following this discussion thread (-:



The YANG 1.1 behaviour gives what I think some (many?) would see as unexpec=
ted behaviour.=C2=A0 If treated as clarification for YANG 1.0 (ie it applie=
s to YANG 1.0 retrospectively) then we could end up invalidating currently =
valid YANG 1.0 models if they have any examples like mine below.=C2=A0 Conv=
ersely, Jan's ownership-voucher example would become invalid if we don&=
#39;t take the YANG 1.1 behaviour and retrospectively apply it to YANG 1.0.=




I'm also not convinced that only evaluating musts on NP containers to o=
ne level below configured nodes is consistent with how we deal with default=
s and mandatory statements.=C2=A0 For those we examine all possible nodes, =
configured or otherwise, at any depth in the tree.=C2=A0 I think we should =
either never evaluate must statements on NP containers which have no childr=
en, or we should always evaluate them at any depth in the tree.=C2=A0 What&=
#39;s so special about those that are children of a configured node versus =
those that are grandchildren (or more)?



I would be interested to hear from those who have written YANG models

(as opposed to those implementing YANG compilers) as to the perceived

impact of the different options on your existing models.=C2=A0 Internally
our YANG 1.0 models have been written on the assumption we do not

evaluate musts on NP containers with no child nodes, but it would be

reasonably easy to add 'not(current() or ...' to the



This doesn't really work: in order to evaluate an XPath expression, the=
 context node must exist, and in our case the context node is an instance o=
f the NP-container. So "not(current())" by definition always eval=
uates to false.



Lada





=C2=A0 front of any such must statements to render the outcome of this disc=
ussion irrelevant by ensuring the statements evaluate true when the NP cont=
ainer is not configured and thus effectively ignoring the constraint when n=
ot configured.



Regards,



William



-----Original Message-----

From: Robert Wilton [mailto:rwilton@cisco.com]

Sent: 04 August 2016 14:10

To: William Ivory <wivory@Brocade.com>; Jan Lindblad <janl@tail-f.com>

Cc: Netconf <netco=
nf@ietf.org>

Subject: Re: [Netconf] What should a server response be? - depending

on NP-containers



Hi William,



On 04/08/2016 13:39, William Ivory wrote:



Hi Rob,



What about a must statement on a NP-container that implements mutual exclus=
ivity with another node, eg the following when top is configured:



Container top {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Container np1 {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Must "not(../n=
p2_leaf)";

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Leaf np1_leaf { typ=
e string; }

=C2=A0 =C2=A0 =C2=A0 =C2=A0 }

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Container np2 {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Leaf np2_leaf { typ=
e string; }

=C2=A0 =C2=A0 =C2=A0 =C2=A0 }

}



At first glance, I think many people would assume this was intended to prev=
ent both np1_leaf and np2_leaf being configured at the same time.=C2=A0 How=
ever, if we configure np2_leaf, container 'top' is configured, so w=
e evaluate the must on np1 (as a np container child of an existing node, as=
 per YANG 1.1 stated requirements) and the must statement evaluates to fals=
e.=C2=A0 Therefore we cannot configure np2_leaf *ever* in this case.



Now you could argue this is badly modelled YANG, but I would suggest it'=
;s decidedly non-obvious that np2_leaf is not configurable here.



RW:



Yes, exactly.=C2=A0 This is why I don't like must statements on np

containers.=C2=A0 Enforcing a constraint on an construct that doesn't
properly exist is a bit odd :-)



I would suggest that it would be clearer to write this as:



Container top {

=C2=A0 =C2=A0Container np1 {

=C2=A0 =C2=A0 =C2=A0Leaf np1_leaf {

=C2=A0 =C2=A0 =C2=A0 =C2=A0type string;

=C2=A0 =C2=A0 =C2=A0 =C2=A0must "not(../../np2_leaf)";

=C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0}

=C2=A0 =C2=A0Container np2 {

=C2=A0 =C2=A0 =C2=A0Leaf np2_leaf {

=C2=A0 =C2=A0 =C2=A0 =C2=A0type string;

=C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0}

}



or perhaps:



Container top {

=C2=A0 =C2=A0Container np1 {

=C2=A0 =C2=A0 =C2=A0Leaf np1_leaf {

=C2=A0 =C2=A0 =C2=A0 =C2=A0type string;

=C2=A0 =C2=A0 =C2=A0 =C2=A0must "not(../../np2_leaf)";

=C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0}

=C2=A0 =C2=A0Container np2 {

=C2=A0 =C2=A0 =C2=A0Leaf np2_leaf {

=C2=A0 =C2=A0 =C2=A0 =C2=A0type string;

=C2=A0 =C2=A0 =C2=A0 =C2=A0must "not(../../np1_leaf)";

=C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0}

}



Thanks,

Rob







Regards,



William



-----Original Message-----

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Robert

Wilton

Sent: 04 August 2016 13:28

To: Jan Lindblad <j=
anl@tail-f.com>

Cc: Netconf <netco=
nf@ietf.org>

Subject: Re: [Netconf] What should a server response be? - depending

on NP-containers



Hi Jan,





On 04/08/2016 12:21, Jan Lindblad wrote:



Rob,





Jan Lindblad writes:



I'm fine with this. Maybe we should clarify that must statements

on NP containers are evaluated if the NP container parent exists.

That's where the "always exists" notion might help understand=
ing a bit.



Or say that their existance is meaningless and carries no semantic

value, and must/when conditions should never consider or depend on

their existence.



Does that mean that for an empty NP container, it would be up to the server=
 to decide whether or not to evaluate the containers must/when statements?<=
br>


That would be terrible. It must be completely clear when must statements ar=
e evaluated and when not.



It can't be that terrible, doesn't YANG 1.0 manage today with this<=
br>
behaviour? :-)



I guess that my point is thus:=C2=A0 if a NP container's must/when cond=
ition should never consider/depend on the existence of said NP container, t=
hen for an empty NP container it should make no difference as to whether or=
 not they they are evaluated by the device.



I question whether it is sensible to allow when/must statements on an NP co=
ntainer at all.=C2=A0 In many ways I would rather that they were restricted=
 to only schema nodes that actually exist as datanodes, at least then the s=
emantics are obvious, no special magic behaviour is required.







=C2=A0 =C2=A0But if the NP container exists due to existence of child nodes=
 then the must/when statements would be guaranteed to be evaluated by the s=
erver?



I think there is no argument that must statements on NP containers MUST be =
evaluated when the container has child nodes. In my previous message, in th=
e preceding text you didn't quote, I tried to explain why I think it=
9;s a bad idea to not also evaluate the must statements when the NP contain=
er is empty.

In many real cases, it's not easy for a model reader to know whether th=
e container has child nodes or not.



Yes.=C2=A0 I had read Phil's suggestion as: don't write must/when s=
tatements that depend on the existence of an NP container.=C2=A0 This sound=
s like quite sensible advise to me, but I might have misunderstood what he =
was suggesting.



Thanks,

Rob





/jan





_______________________________________________

Netconf mailing list

Netconf@ietf.org<=
br>
https://urldefense.proofpoint=
.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai

l

man_listinfo_netconf&d=3DCwICAg&c=3DIL_XqQWOjubgfqINi2jTzg&=
;r=3DGByLeg9jZvOv

_

AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=3D751sECIaA5HaNM0wQdHxLvA6UwL5IhKW91y_

u 8ZrZ2Y&s=3Dx12_Ko8id4YJBVF1rFmAvbKVrZCHdIHsFnzswwJ1k68&e=3D<=
br>
.





_______________________________________________

Netconf mailing list

Netconf@ietf.org<=
br>
https://urldefense.proofpoin=
t.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail

man_listinfo_netconf&d=3DCwIFAg&c=3DIL_XqQWOjubgfqINi2jTzg&=
;r=3DGByLeg9jZvOv_

AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=3D6jlb0kQeoX8x29SUyoT8wXmmEAZeH2PaJOIXx

ueVRP4&s=3Do-TUEWoTedxYQZ0UmLD-TX17raAc9Dz1VMLk78SnXdU&e=3D


--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C









.







_______________________________________________

Netconf mailing list

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




--94eb2c149bd4ae8d7b0539be41b4--


From nobody Wed Aug 10 18:51:00 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6BEA12B012 for ; Wed, 10 Aug 2016 18:50:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhAue-TstQti for ; Wed, 10 Aug 2016 18:50:55 -0700 (PDT)
Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::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 7E666126579 for ; Wed, 10 Aug 2016 18:50:55 -0700 (PDT)
Received: by mail-pf0-x231.google.com with SMTP id x72so21289594pfd.2 for ; Wed, 10 Aug 2016 18:50:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Ffbt2ZvRZlnNUAvE2IZ2EAVWZZHcSxLwt/YRQ3gv5Ec=; b=Pd6nAXS/u6Tc284hizgBMXQhMfEc7yp5dyvKtasZc8+vXk+/b9cQfHaztqzptGPKGB UKzy2F9f3ZtdQvXfWgZ0J9z1KzFKDlGlJoCbBlmCkotKj+YIQuKS3thPDkOOv4WDI0Jy Gg46Ufkq9ziqAP8svSi8i1e2yygrHRcgsPXXgoZ2H7QR29Iz6qMfOmnGkHgb4K63maDG ZsQ8y1D9Sl/0HxmyKUSGY+cpDkTkEbGLlfPR4NVcF4P80FMByFh/WlIWh2HM/1PlLMjR Px4LYVWpfpF53O6npLms3b6mVGjZNHgZMmstcERSLNPuXafqeDPGP2RExawY+p9chG/m 1/2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Ffbt2ZvRZlnNUAvE2IZ2EAVWZZHcSxLwt/YRQ3gv5Ec=; b=IHw77+t2WpsY9rEpFDoHAyvAGgi9fTu++u6TUhI4NvwrdnU0oM/Q0ddJeJY+srxmrf FoubUVGhyG5x2H3+acz+Et5EX5izEzg0NxJKzTLSTXWGuj/6gCvSFDpux4b5KihqIL8A mWgHrAFHcc7ZcdR1d//5SByg2PvkeLi5hasyoLsLDUZIjxCznCna6UJLeEKevikNy4Hh j1DrIii+dj43H3nzjh7VSHofF8WcjQJllOvg7VEVixTzPGsKiZ37YRHBr9U5IagTQinz nhkcXauzNifjz6BNF+IFPpPshqHmfF3Rvq5q05iDRmp2PW6Zh4KVD9Ud2hbrxuyxe4r7 RcOw==
X-Gm-Message-State: AEkooutbKl0Di+kUGICIOwHOrQhQ0+mlPodcYIV9XwXlq2jl8xGxZxnRnmfJ2tSnYUoRxQ==
X-Received: by 10.98.65.81 with SMTP id o78mr12545310pfa.48.1470880254975; Wed, 10 Aug 2016 18:50:54 -0700 (PDT)
Received: from ?IPv6:2001:420:30d:1320:146f:9e6d:3f26:ca10? ([2001:420:30d:1320:146f:9e6d:3f26:ca10]) by smtp.gmail.com with ESMTPSA id e68sm261308pfk.1.2016.08.10.18.50.53 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 10 Aug 2016 18:50:53 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_6CBC98C7-0B20-46BF-B917-FFA1D5621C95"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mahesh Jethanandani 
In-Reply-To: 
Date: Wed, 10 Aug 2016 18:50:52 -0700
Message-Id: <77367611-5986-45C7-8701-0A74B26F2702@gmail.com>
References: <201608031942.u73Jg8ol039135@idle.juniper.net> <5a49581e-71ef-4be9-1e51-62213901a887@cisco.com> <0066A47E-240F-4B6B-920B-98B064CE1E60@tail-f.com>   <05ea80f8-665b-d9b7-53db-207fc862409e@cisco.com> <5d8503f67066406a992738b766556247@EMEAWP-EXMB11.corp.brocade.com>  <357980ab80a64bbba5d6778fdf2160f8@EMEAWP-EXMB11.corp.brocade.com> <49054fe2-b1d1-ba18-a0a0-ea799e8947ef@cisco.com> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Aug 2016 01:50:59 -0000

--Apple-Mail=_6CBC98C7-0B20-46BF-B917-FFA1D5621C95
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Aug 10, 2016, at 2:23 PM, Andy Bierman  wrote:
>=20
> Hi,
>=20
> I am quite willing to accept the existing design in YANG 1.1 that NP =
containers
> are considered to be present if there is a non-NP ancestor present (or =
the
> NP container is a top-level data node).  This is easier to support.
> It matches the top-down callback design of many server =
implementations.
>=20
> The update rules in sec 11 of 6020bis do not cover NP-containers =
correctly.
> It should be illegal to add a mandatory NP-container as a child node
> to the augment target.=20
>=20
>=20
> This needs to include must-stmt (fixed in the term "mandatory node", =
bullet 3)
> I don't think the text below is quite right.  I suspect Lada can do =
better.
>=20
>=20
> OLD:
>=20
> sec 3.
>=20
>    o  mandatory node: A mandatory node is one of:
>=20
>       *  A leaf, choice, anydata, or anyxml node with a "mandatory"
>          statement with the value "true".
>=20
>       *  A list or leaf-list node with a "min-elements" statement with =
a
>          value greater than zero.
>=20
>       *  A container node without a "presence" statement and which has
>          at least one mandatory node as a child.
>=20
>=20
>=20
> NEW:
>=20
>   o  mandatory node: A mandatory node is one of:
>=20
>       *  A leaf, choice, anydata, or anyxml node with a "mandatory"
>          statement with the value "true".
>=20
>       *  A list or leaf-list node with a "min-elements" statement with =
a
>          value greater than zero.
>=20
>       *  A container node without a "presence" statement and which has
>          at least one mandatory node as a child, or has a "must" =
statement
>          that will evaluate to "false" if the container has no child =
node instances.

A slight modification to the third bullet.

OLD:

      *  A container node without a "presence" statement and which has
         at least one mandatory node as a child, or has a "must" =
statement
         that will evaluate to "false" if the container has no child =
node instances.

NEW:

      *  A container node without a "presence" statement and which has
         at least one mandatory node as a child, or has a "must" =
statement
         that will evaluate to =E2=80=9Ctrue" if the container has =
default nodes as defined
         for leafs (section 7.6.1) or for leaf-list (section 7.7.2).

>=20
>=20
>=20
> Andy
>=20
>=20
>=20
>=20
>=20
> On Fri, Aug 5, 2016 at 6:57 AM, Robert Wilton > wrote:
> Hi William,
>=20
> Pragmatically, I think that I would also go for (b), with the fix =
suggested by Lada.
>=20
> My reasoning is that despite not liking "when"/"must" statements on =
np-containers they are clearly useful in some cases and cannot be banned =
outright.
>=20
> I also like Phil's explanation that a server could effectively rewrite =
the paths in the xpath so the "when"/"must" statement is effectively =
bound to the nearest parent container that has presence.  That almost =
seems like a better way of thinking about what they really are.
>=20
> Thanks,
> Rob
>=20
>=20
> On 05/08/2016 10:19, William Ivory wrote:
> Hi Lada,
>=20
> I was assuming that if a NP container had no children then from the =
perspective of current() it didn't exist, but that it was reasonable to =
evaluate the must expression on it as a 'virtual' node.  This just gets =
messier and messier, though I guess that 'count(*) =3D 0' (assuming no =
non-presence container children, otherwise would need to name children) =
would work instead?
>=20
> There seem to be 3 options for evaluating must statements on NP =
containers that have no children - would appreciate others' input on =
this.  In addition, Balazs' suggestion that modellers avoid must =
statements on NP containers where possible would seem sensible advice!
>=20
> (a) Never evaluate
>=20
> Never evaluate a must statement on a non-presence container that has =
no children.
>=20
> Pros:
> - simple to understand
> - reduces number of must statements to evaluate when validating =
configuration
> - less likely to lead to unintended consequences of must statements =
being evaluated on nodes that don't appear in configuration
>=20
> Cons:
> - some existing models (in YANG 1.0 and presumably YANG 1.1) assume =
evaluation of must statements on NP container children of existing nodes =
as added / clarified in YANG 1.1
> - need to confirm we can still model the likes of the ownership =
voucher must statement by altenative means if we adopt this =
interpretation
>=20
> (b) Evaluate when parent exists
>=20
> We evaluate must statements on non-presence container if their parent =
node is configured.
>=20
> Pros:
> - this is the stated position in YANG 1.1 (conflicting opinions exist =
on this alias as to whether it should be retrospectively applied to YANG =
1.0 as 'clarification' or not)
> - some existing models assume this is the case (eg Jan's =
ownership-voucher example (YANG 1.0 model))
>=20
> Cons:
> - may lead to unintended consequences of must statements being =
unexpectedly evaluated (albeit model writers *should* understand how it =
works once we have clarified it!)
> - why only children, not grandchildren etc?  We examine mandatory and =
default on every single node, so why not for NP containers as well
>=20
> (c) Always evaluate
>=20
> We always evaluate must statements on non-presence containers
>=20
> Pros:
> - easy to understand this rule
>=20
> Cons:
> - this is different to both YANG 1.0 and YANG 1.1 current =
interpretation (whether you take the YANG 1.1 position as a change or as =
clarification on YANG 1.0)
> - validation now has the overhead of evaluating ALL must statements on =
all NP containers even when not configured.
>=20
> ---
>=20
> Regards,
>=20
> William
>=20
> -----Original Message-----
> From: Ladislav Lhotka [mailto:lhotka@nic.cz ]
> Sent: 05 August 2016 09:51
> To: William Ivory 
> Cc: Robert Wilton >; Jan =
Lindblad >; Netconf =
>
> Subject: Re: [Netconf] What should a server response be? - depending =
on NP-containers
>=20
>=20
> On 04 Aug 2016, at 15:27, William Ivory  wrote:
>=20
> So I quite agree that there are better ways of writing this.  However, =
my initial YANG is valid, and at first glance it is tempting to write it =
that way unless you have been following this discussion thread (-:
>=20
> The YANG 1.1 behaviour gives what I think some (many?) would see as =
unexpected behaviour.  If treated as clarification for YANG 1.0 (ie it =
applies to YANG 1.0 retrospectively) then we could end up invalidating =
currently valid YANG 1.0 models if they have any examples like mine =
below.  Conversely, Jan's ownership-voucher example would become invalid =
if we don't take the YANG 1.1 behaviour and retrospectively apply it to =
YANG 1.0.
>=20
> I'm also not convinced that only evaluating musts on NP containers to =
one level below configured nodes is consistent with how we deal with =
defaults and mandatory statements.  For those we examine all possible =
nodes, configured or otherwise, at any depth in the tree.  I think we =
should either never evaluate must statements on NP containers which have =
no children, or we should always evaluate them at any depth in the tree. =
 What's so special about those that are children of a configured node =
versus those that are grandchildren (or more)?
>=20
> I would be interested to hear from those who have written YANG models
> (as opposed to those implementing YANG compilers) as to the perceived
> impact of the different options on your existing models.  Internally
> our YANG 1.0 models have been written on the assumption we do not
> evaluate musts on NP containers with no child nodes, but it would be
> reasonably easy to add 'not(current() or ...' to the
> This doesn't really work: in order to evaluate an XPath expression, =
the context node must exist, and in our case the context node is an =
instance of the NP-container. So "not(current())" by definition always =
evaluates to false.
>=20
> Lada
>=20
>   front of any such must statements to render the outcome of this =
discussion irrelevant by ensuring the statements evaluate true when the =
NP container is not configured and thus effectively ignoring the =
constraint when not configured.
>=20
> Regards,
>=20
> William
>=20
> -----Original Message-----
> From: Robert Wilton [mailto:rwilton@cisco.com =
]
> Sent: 04 August 2016 14:10
> To: William Ivory ; Jan Lindblad >
> Cc: Netconf >
> Subject: Re: [Netconf] What should a server response be? - depending
> on NP-containers
>=20
> Hi William,
>=20
> On 04/08/2016 13:39, William Ivory wrote:
> Hi Rob,
>=20
> What about a must statement on a NP-container that implements mutual =
exclusivity with another node, eg the following when top is configured:
>=20
> Container top {
>         Container np1 {
>                 Must "not(../np2_leaf)";
>                 Leaf np1_leaf { type string; }
>         }
>         Container np2 {
>                 Leaf np2_leaf { type string; }
>         }
> }
>=20
> At first glance, I think many people would assume this was intended to =
prevent both np1_leaf and np2_leaf being configured at the same time.  =
However, if we configure np2_leaf, container 'top' is configured, so we =
evaluate the must on np1 (as a np container child of an existing node, =
as per YANG 1.1 stated requirements) and the must statement evaluates to =
false.  Therefore we cannot configure np2_leaf *ever* in this case.
>=20
> Now you could argue this is badly modelled YANG, but I would suggest =
it's decidedly non-obvious that np2_leaf is not configurable here.
> RW:
>=20
> Yes, exactly.  This is why I don't like must statements on np
> containers.  Enforcing a constraint on an construct that doesn't
> properly exist is a bit odd :-)
>=20
> I would suggest that it would be clearer to write this as:
>=20
> Container top {
>    Container np1 {
>      Leaf np1_leaf {
>        type string;
>        must "not(../../np2_leaf)";
>      }
>    }
>    Container np2 {
>      Leaf np2_leaf {
>        type string;
>      }
>    }
> }
>=20
> or perhaps:
>=20
> Container top {
>    Container np1 {
>      Leaf np1_leaf {
>        type string;
>        must "not(../../np2_leaf)";
>      }
>    }
>    Container np2 {
>      Leaf np2_leaf {
>        type string;
>        must "not(../../np1_leaf)";
>      }
>    }
> }
>=20
> Thanks,
> Rob
>=20
>=20
> Regards,
>=20
> William
>=20
> -----Original Message-----
> From: Netconf [mailto:netconf-bounces@ietf.org =
] On Behalf Of Robert
> Wilton
> Sent: 04 August 2016 13:28
> To: Jan Lindblad >
> Cc: Netconf >
> Subject: Re: [Netconf] What should a server response be? - depending
> on NP-containers
>=20
> Hi Jan,
>=20
>=20
> On 04/08/2016 12:21, Jan Lindblad wrote:
> Rob,
>=20
> Jan Lindblad writes:
> I'm fine with this. Maybe we should clarify that must statements
> on NP containers are evaluated if the NP container parent exists.
> That's where the "always exists" notion might help understanding a =
bit.
> Or say that their existance is meaningless and carries no semantic
> value, and must/when conditions should never consider or depend on
> their existence.
> Does that mean that for an empty NP container, it would be up to the =
server to decide whether or not to evaluate the containers must/when =
statements?
> That would be terrible. It must be completely clear when must =
statements are evaluated and when not.
> It can't be that terrible, doesn't YANG 1.0 manage today with this
> behaviour? :-)
>=20
> I guess that my point is thus:  if a NP container's must/when =
condition should never consider/depend on the existence of said NP =
container, then for an empty NP container it should make no difference =
as to whether or not they they are evaluated by the device.
>=20
> I question whether it is sensible to allow when/must statements on an =
NP container at all.  In many ways I would rather that they were =
restricted to only schema nodes that actually exist as datanodes, at =
least then the semantics are obvious, no special magic behaviour is =
required.
>=20
>=20
>    But if the NP container exists due to existence of child nodes then =
the must/when statements would be guaranteed to be evaluated by the =
server?
> I think there is no argument that must statements on NP containers =
MUST be evaluated when the container has child nodes. In my previous =
message, in the preceding text you didn't quote, I tried to explain why =
I think it's a bad idea to not also evaluate the must statements when =
the NP container is empty.
> In many real cases, it's not easy for a model reader to know whether =
the container has child nodes or not.
> Yes.  I had read Phil's suggestion as: don't write must/when =
statements that depend on the existence of an NP container.  This sounds =
like quite sensible advise to me, but I might have misunderstood what he =
was suggesting.
>=20
> Thanks,
> Rob
>=20
> /jan
>=20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org 
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai =

> l
> man_listinfo_netconf&d=3DCwICAg&c=3DIL_XqQWOjubgfqINi2jTzg&r=3DGByLeg9jZ=
vOv
> _
> AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=3D751sECIaA5HaNM0wQdHxLvA6UwL5IhKW91y_
> u 8ZrZ2Y&s=3Dx12_Ko8id4YJBVF1rFmAvbKVrZCHdIHsFnzswwJ1k68&e=3D
> .
>=20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org 
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail=
 =
=

> man_listinfo_netconf&d=3DCwIFAg&c=3DIL_XqQWOjubgfqINi2jTzg&r=3DGByLeg9jZ=
vOv_
> AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=3D6jlb0kQeoX8x29SUyoT8wXmmEAZeH2PaJOIXx=

> ueVRP4&s=3Do-TUEWoTedxYQZ0UmLD-TX17raAc9Dz1VMLk78SnXdU&e=3D
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20
> .
>=20
>=20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org 
> https://www.ietf.org/mailman/listinfo/netconf =

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

Mahesh Jethanandani
mjethanandani@gmail.com




--Apple-Mail=_6CBC98C7-0B20-46BF-B917-FFA1D5621C95
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On Aug 10, 2016, at 2:23 PM, Andy Bierman <andy@yumaworks.com> =
wrote:

Hi,

I am quite willing to accept the existing design in YANG 1.1 =
that NP containers
are considered to be present if =
there is a non-NP ancestor present (or the
NP =
container is a top-level data node).  This is easier to =
support.
It matches the top-down callback design of =
many server implementations.

The update rules in sec 11 of 6020bis =
do not cover NP-containers correctly.
It should be =
illegal to add a mandatory NP-container as a child node
to the augment target. 


This=
 needs to include must-stmt (fixed in the term "mandatory node", bullet =
3)
I don't think the text below is quite =
right.  I suspect Lada can do better.


OLD:

sec 3.

   o  mandatory node: A =
mandatory node is one of:

      *  A leaf, choice, anydata, or =
anyxml node with a "mandatory"
      =
   statement with the value "true".

      *  A list or =
leaf-list node with a "min-elements" statement with a
         value greater than =
zero.

  =
    *  A container node without a "presence" statement =
and which has
         at =
least one mandatory node as a child.



NEW:

  o =
 mandatory node: A mandatory node is one of:

  =
    *  A leaf, choice, anydata, or anyxml node with a =
"mandatory"
        =
 statement with the value "true".

      *  A list or =
leaf-list node with a "min-elements" statement with a
         value greater than =
zero.

  =
    *  A container node without a "presence" statement =
and which has
         at =
least one mandatory node as a child, or has a "must" =
statement
        =
 that will evaluate to "false" if the container has no child node =
instances.

A =
slight modification to the third bullet.

OLD:

      *  A container node =
without a "presence" statement and which has
  =
       at least one mandatory node as a child, or =
has a "must" statement
      =
   that will evaluate to "false" if the container has no child =
node instances.

NEW:

      *  A container node without a =
"presence" statement and which has
         at least one mandatory node =
as a child, or has a "must" statement
  =
       that will evaluate to =E2=80=9Ctrue" if the =
container has default nodes as defined
  =
       for leafs (section 7.6.1) or for leaf-list =
(section 7.7.2).




Andy





On Fri, =
Aug 5, 2016 at 6:57 AM, Robert Wilton <rwilton@cisco.com> wrote:
Hi William,



Pragmatically, I think that I would also go for (b), with the fix =
suggested by Lada.



My reasoning is that despite not liking "when"/"must" statements on =
np-containers they are clearly useful in some cases and cannot be banned =
outright.



I also like Phil's explanation that a server could effectively rewrite =
the paths in the xpath so the "when"/"must" statement is effectively =
bound to the nearest parent container that has presence.  That =
almost seems like a better way of thinking about what they really =
are.



Thanks,

Rob





On 05/08/2016 10:19, William Ivory wrote:



Hi Lada,



I was assuming that if a NP container had no children then from the =
perspective of current() it didn't exist, but that it was reasonable to =
evaluate the must expression on it as a 'virtual' node.  This just =
gets messier and messier, though I guess that 'count(*) =3D 0' (assuming =
no non-presence container children, otherwise would need to name =
children) would work instead?



There seem to be 3 options for evaluating must statements on NP =
containers that have no children - would appreciate others' input on =
this.  In addition, Balazs' suggestion that modellers avoid must =
statements on NP containers where possible would seem sensible =
advice!



(a) Never evaluate



Never evaluate a must statement on a non-presence container that has no =
children.



Pros:

- simple to understand

- reduces number of must statements to evaluate when validating =
configuration

- less likely to lead to unintended consequences of must statements =
being evaluated on nodes that don't appear in configuration
=



Cons:

- some existing models (in YANG 1.0 and presumably YANG 1.1) assume =
evaluation of must statements on NP container children of existing nodes =
as added / clarified in YANG 1.1

- need to confirm we can still model the likes of the ownership voucher =
must statement by altenative means if we adopt this interpretation



(b) Evaluate when parent exists



We evaluate must statements on non-presence container if their parent =
node is configured.



Pros:

- this is the stated position in YANG 1.1 (conflicting opinions exist on =
this alias as to whether it should be retrospectively applied to YANG =
1.0 as 'clarification' or not)

- some existing models assume this is the case (eg Jan's =
ownership-voucher example (YANG 1.0 model))



Cons:

- may lead to unintended consequences of must statements being =
unexpectedly evaluated (albeit model writers *should* understand how it =
works once we have clarified it!)

- why only children, not grandchildren etc?  We examine mandatory =
and default on every single node, so why not for NP containers as =
well



(c) Always evaluate



We always evaluate must statements on non-presence containers



Pros:

- easy to understand this rule



Cons:

- this is different to both YANG 1.0 and YANG 1.1 current interpretation =
(whether you take the YANG 1.1 position as a change or as clarification =
on YANG 1.0)

- validation now has the overhead of evaluating ALL must statements on =
all NP containers even when not configured.



---



Regards,



William



-----Original Message-----

From: Ladislav Lhotka [mailto:lhotka@nic.cz]

Sent: 05 August 2016 09:51

To: William Ivory <wivory@Brocade.com>

Cc: Robert Wilton <rwilton@cisco.com>; Jan Lindblad =
<janl@tail-f.com>; Netconf <netconf@ietf.org>

Subject: Re: [Netconf] What should a server response be? - depending on =
NP-containers







On 04 Aug 2016, at 15:27, William Ivory <wivory@Brocade.com> =
wrote:



So I quite agree that there are better ways of writing this.  =
However, my initial YANG is valid, and at first glance it is tempting to =
write it that way unless you have been following this discussion thread =
(-:



The YANG 1.1 behaviour gives what I think some (many?) would see as =
unexpected behaviour.  If treated as clarification for YANG 1.0 (ie =
it applies to YANG 1.0 retrospectively) then we could end up =
invalidating currently valid YANG 1.0 models if they have any examples =
like mine below.  Conversely, Jan's ownership-voucher example would =
become invalid if we don't take the YANG 1.1 behaviour and =
retrospectively apply it to YANG 1.0.



I'm also not convinced that only evaluating musts on NP containers to =
one level below configured nodes is consistent with how we deal with =
defaults and mandatory statements.  For those we examine all =
possible nodes, configured or otherwise, at any depth in the tree.  =
I think we should either never evaluate must statements on NP containers =
which have no children, or we should always evaluate them at any depth =
in the tree.  What's so special about those that are children of a =
configured node versus those that are grandchildren (or more)?



I would be interested to hear from those who have written YANG models

(as opposed to those implementing YANG compilers) as to the perceived

impact of the different options on your existing models.  =
Internally

our YANG 1.0 models have been written on the assumption we do not

evaluate musts on NP containers with no child nodes, but it would be

reasonably easy to add 'not(current() or ...' to the



This doesn't really work: in order to evaluate an XPath expression, the =
context node must exist, and in our case the context node is an instance =
of the NP-container. So "not(current())" by definition always evaluates =
to false.



Lada





  front of any such must statements to render the outcome of this =
discussion irrelevant by ensuring the statements evaluate true when the =
NP container is not configured and thus effectively ignoring the =
constraint when not configured.



Regards,



William



-----Original Message-----

From: Robert Wilton [mailto:rwilton@cisco.com]

Sent: 04 August 2016 14:10

To: William Ivory <wivory@Brocade.com>; Jan Lindblad <janl@tail-f.com>

Cc: Netconf <netconf@ietf.org>

Subject: Re: [Netconf] What should a server response be? - depending

on NP-containers



Hi William,



On 04/08/2016 13:39, William Ivory wrote:



Hi Rob,



What about a must statement on a NP-container that implements mutual =
exclusivity with another node, eg the following when top is =
configured:



Container top {

        Container np1 {

                Must =
"not(../np2_leaf)";

                Leaf np1_leaf { =
type string; }

        }

        Container np2 {

                Leaf np2_leaf { =
type string; }

        }

}



At first glance, I think many people would assume this was intended to =
prevent both np1_leaf and np2_leaf being configured at the same =
time.  However, if we configure np2_leaf, container 'top' is =
configured, so we evaluate the must on np1 (as a np container child of =
an existing node, as per YANG 1.1 stated requirements) and the must =
statement evaluates to false.  Therefore we cannot configure =
np2_leaf *ever* in this case.



Now you could argue this is badly modelled YANG, but I would suggest =
it's decidedly non-obvious that np2_leaf is not configurable here.



RW:



Yes, exactly.  This is why I don't like must statements on np

containers.  Enforcing a constraint on an construct that doesn't

properly exist is a bit odd :-)



I would suggest that it would be clearer to write this as:



Container top {

   Container np1 {

     Leaf np1_leaf {

       type string;

       must "not(../../np2_leaf)";

     }

   }

   Container np2 {

     Leaf np2_leaf {

       type string;

     }

   }

}



or perhaps:



Container top {

   Container np1 {

     Leaf np1_leaf {

       type string;

       must "not(../../np2_leaf)";

     }

   }

   Container np2 {

     Leaf np2_leaf {

       type string;

       must "not(../../np1_leaf)";

     }

   }

}



Thanks,

Rob







Regards,



William



-----Original Message-----

From: Netconf [mailto:netconf-bounces@ietf.org]=
 On Behalf Of Robert

Wilton

Sent: 04 August 2016 13:28

To: Jan Lindblad <janl@tail-f.com>

Cc: Netconf <netconf@ietf.org>

Subject: Re: [Netconf] What should a server response be? - depending

on NP-containers



Hi Jan,





On 04/08/2016 12:21, Jan Lindblad wrote:



Rob,





Jan Lindblad writes:



I'm fine with this. Maybe we should clarify that must statements

on NP containers are evaluated if the NP container parent exists.

That's where the "always exists" notion might help understanding a =
bit.



Or say that their existance is meaningless and carries no semantic

value, and must/when conditions should never consider or depend on

their existence.



Does that mean that for an empty NP container, it would be up to the =
server to decide whether or not to evaluate the containers must/when =
statements?



That would be terrible. It must be completely clear when must statements =
are evaluated and when not.



It can't be that terrible, doesn't YANG 1.0 manage today with this

behaviour? :-)



I guess that my point is thus:  if a NP container's must/when =
condition should never consider/depend on the existence of said NP =
container, then for an empty NP container it should make no difference =
as to whether or not they they are evaluated by the device.
=



I question whether it is sensible to allow when/must statements on an NP =
container at all.  In many ways I would rather that they were =
restricted to only schema nodes that actually exist as datanodes, at =
least then the semantics are obvious, no special magic behaviour is =
required.







   But if the NP container exists due to existence of child =
nodes then the must/when statements would be guaranteed to be evaluated =
by the server?



I think there is no argument that must statements on NP containers MUST =
be evaluated when the container has child nodes. In my previous message, =
in the preceding text you didn't quote, I tried to explain why I think =
it's a bad idea to not also evaluate the must statements when the NP =
container is empty.

In many real cases, it's not easy for a model reader to know whether the =
container has child nodes or not.



Yes.  I had read Phil's suggestion as: don't write must/when =
statements that depend on the existence of an NP container.  This =
sounds like quite sensible advise to me, but I might have misunderstood =
what he was suggesting.



Thanks,

Rob





/jan





_______________________________________________

Netconf mailing list

Netconf@ietf.org

https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai

l

man_listinfo_netconf&d=3DCwICAg&c=3DIL_XqQWOjubgfqINi2jTzg&r=3DGByLeg9jZvOv

_

AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=3D751sECIaA5HaNM0wQdHxLvA6UwL5IhKW91y_

u 8ZrZ2Y&s=3Dx12_Ko8id4YJBVF1rFmAvbKVrZCHdIHsFnzswwJ1k68&e=3D

.





_______________________________________________

Netconf mailing list

Netconf@ietf.org

https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail

man_listinfo_netconf&d=3DCwIFAg&c=3DIL_XqQWOjubgfqINi2jTzg&r=3DGByLeg9jZvOv_

AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=3D6jlb0kQeoX8x29SUyoT8wXmmEAZeH2PaJOIXx

ueVRP4&s=3Do-TUEWoTedxYQZ0UmLD-TX17raAc9Dz1VMLk78SnXdU&e=3D



--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C









.







_______________________________________________

Netconf mailing list

Netconf@ietf.org

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




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



Mahesh Jethanandani
mjethanandani@gmail.com







=

--Apple-Mail=_6CBC98C7-0B20-46BF-B917-FFA1D5621C95--


From nobody Wed Aug 10 19:09:08 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE2712D567 for ; Wed, 10 Aug 2016 19:09:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SDWi_7QFZ_L for ; Wed, 10 Aug 2016 19:09:03 -0700 (PDT)
Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::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 5CCA812B063 for ; Wed, 10 Aug 2016 19:09:03 -0700 (PDT)
Received: by mail-ua0-x230.google.com with SMTP id n59so97964137uan.2 for ; Wed, 10 Aug 2016 19:09:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yhuq8bq3alofq99qfbzYJDLlNscwN+nwVpq7euTbAx4=; b=K0uMeWhRARAwGBjMtSUWvudXezI4YCfeXtaYJpqmxIFZATV+lKudxHNLQQoULWsRVm RlNjTlPQyf86tDHDCmwvjR6ubqQhiV46NZwEHYe2SsI3ofQa0JUbC3ADcx93lzuJ1D4h o2e2AHuXZW8zj6niMkkFPjntMcOayxdpr5KVlgB1mCGyntuhXL0iRXzuadV3Aj/9n1m+ SPt4+ZHUWLQWCpgjX/qMXmWHiNf1u+39mICXyU5mDxzoR2CUxigsWX67wPPe08JpPzeo 6DEqYOeFN1SrWJaW9d/21ic9LtPFdnULYTdzwPyHGI8+Z3SI67GeT8MzVi2W6noNN6ao WVxw==
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:from:date :message-id:subject:to:cc; bh=yhuq8bq3alofq99qfbzYJDLlNscwN+nwVpq7euTbAx4=; b=Zsm+54JDNuxSTiwF3KPY8FCcvBMIyclNshxF+TgytfbHyn3xdFcc2NZDBXZxzfneG3 /S4oAo8XBRUb99R1s64OTb63SGg2rLEX35clcO/8g4xoJd6YtfEL0IHr2ALXsR+6Z2SD 5NwdLql5m147fgLqLn3/eGJBlOTZokwZD10Yu/ApDQftHW828vRdYmA8J14KRIzc/N6M Iv09uD3vbjxzIggll/yLYvwI5hShoR88oGJjW5dBS62p/Oan4mLmXzDjsRjPC7WssULl XKDpvAtf6VqWAoWVFsPuP4iUvFIXeA7dQUi7+qRt6K3cyrrITsQWKFFzu6piaPtSH48x 6ebQ==
X-Gm-Message-State: AEkoousAlgNVwRhzUlr2txWlDWmcgETLGAyMhj2Yc6QMud+AYioTRZG6ZFlLx4ooMLKKJ92CcjZdSmDg6OfOCA==
X-Received: by 10.31.175.1 with SMTP id y1mr3551984vke.123.1470881342374; Wed, 10 Aug 2016 19:09:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Wed, 10 Aug 2016 19:08:59 -0700 (PDT)
In-Reply-To: <77367611-5986-45C7-8701-0A74B26F2702@gmail.com>
References: <201608031942.u73Jg8ol039135@idle.juniper.net> <5a49581e-71ef-4be9-1e51-62213901a887@cisco.com> <0066A47E-240F-4B6B-920B-98B064CE1E60@tail-f.com>   <05ea80f8-665b-d9b7-53db-207fc862409e@cisco.com> <5d8503f67066406a992738b766556247@EMEAWP-EXMB11.corp.brocade.com>  <357980ab80a64bbba5d6778fdf2160f8@EMEAWP-EXMB11.corp.brocade.com> <49054fe2-b1d1-ba18-a0a0-ea799e8947ef@cisco.com>  <77367611-5986-45C7-8701-0A74B26F2702@gmail.com>
From: Andy Bierman 
Date: Wed, 10 Aug 2016 19:08:59 -0700
Message-ID: 
To: Mahesh Jethanandani 
Content-Type: multipart/alternative; boundary=001a114413b4eb5ca10539c23f3e
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Aug 2016 02:09:06 -0000

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

On Wed, Aug 10, 2016 at 6:50 PM, Mahesh Jethanandani <
mjethanandani@gmail.com> wrote:

>
> On Aug 10, 2016, at 2:23 PM, Andy Bierman  wrote:
>
> Hi,
>
> I am quite willing to accept the existing design in YANG 1.1 that NP
> containers
> are considered to be present if there is a non-NP ancestor present (or th=
e
> NP container is a top-level data node).  This is easier to support.
> It matches the top-down callback design of many server implementations.
>
> The update rules in sec 11 of 6020bis do not cover NP-containers correctl=
y.
> It should be illegal to add a mandatory NP-container as a child node
> to the augment target.
>
>
> This needs to include must-stmt (fixed in the term "mandatory node",
> bullet 3)
> I don't think the text below is quite right.  I suspect Lada can do bette=
r.
>
>
> OLD:
>
> sec 3.
>
>    o  mandatory node: A mandatory node is one of:
>
>       *  A leaf, choice, anydata, or anyxml node with a "mandatory"
>          statement with the value "true".
>
>       *  A list or leaf-list node with a "min-elements" statement with a
>          value greater than zero.
>
>       *  A container node without a "presence" statement and which has
>          at least one mandatory node as a child.
>
>
>
> NEW:
>
>   o  mandatory node: A mandatory node is one of:
>
>       *  A leaf, choice, anydata, or anyxml node with a "mandatory"
>          statement with the value "true".
>
>       *  A list or leaf-list node with a "min-elements" statement with a
>          value greater than zero.
>
>       *  A container node without a "presence" statement and which has
>          at least one mandatory node as a child, or has a "must" statemen=
t
>          that will evaluate to "false" if the container has no child node
> instances.
>
>
> A slight modification to the third bullet.
>
> OLD:
>
>       *  A container node without a "presence" statement and which has
>          at least one mandatory node as a child, or has a "must" statemen=
t
>          that will evaluate to "false" if the container has no child node
> instances.
>
> NEW:
>
>       *  A container node without a "presence" statement and which has
>          at least one mandatory node as a child, or has a "must" statemen=
t
>          that will evaluate to =E2=80=9Ctrue" if the container has defaul=
t nodes
> as defined
>          for leafs (section 7.6.1) or for leaf-list (section 7.7.2).
>
>
>

It is "false" must-stmts that cause a problem.

e.g.:


augment /foo:/top {
   container okay {
      must "A >=3D 1 and B >=3D A";
      leaf A { type int32; default 1;  }
      leaf B { type int32; default 2;  }
  }
}

We want to prevent an augment with a mandatory NP-container
where only the augmented parent exists, causing the must-stmt
to be evaluated as false, causing the creation of the parent node to fail.
This is not allowed for augment (just in-line NP containers in the first
release)

augment /foo:/top {
   container not-okay {
      must "A >=3D 1 and B >=3D A";
      leaf A { type int32; }
      leaf B { type int32; }
  }
}


>
> Andy
>
>
>
>
>
> On Fri, Aug 5, 2016 at 6:57 AM, Robert Wilton  wrote:
>
>> Hi William,
>>
>> Pragmatically, I think that I would also go for (b), with the fix
>> suggested by Lada.
>>
>> My reasoning is that despite not liking "when"/"must" statements on
>> np-containers they are clearly useful in some cases and cannot be banned
>> outright.
>>
>> I also like Phil's explanation that a server could effectively rewrite
>> the paths in the xpath so the "when"/"must" statement is effectively bou=
nd
>> to the nearest parent container that has presence.  That almost seems li=
ke
>> a better way of thinking about what they really are.
>>
>> Thanks,
>> Rob
>>
>>
>> On 05/08/2016 10:19, William Ivory wrote:
>>
>>> Hi Lada,
>>>
>>> I was assuming that if a NP container had no children then from the
>>> perspective of current() it didn't exist, but that it was reasonable to
>>> evaluate the must expression on it as a 'virtual' node.  This just gets
>>> messier and messier, though I guess that 'count(*) =3D 0' (assuming no
>>> non-presence container children, otherwise would need to name children)
>>> would work instead?
>>>
>>> There seem to be 3 options for evaluating must statements on NP
>>> containers that have no children - would appreciate others' input on th=
is.
>>> In addition, Balazs' suggestion that modellers avoid must statements on=
 NP
>>> containers where possible would seem sensible advice!
>>>
>>> (a) Never evaluate
>>>
>>> Never evaluate a must statement on a non-presence container that has no
>>> children.
>>>
>>> Pros:
>>> - simple to understand
>>> - reduces number of must statements to evaluate when validating
>>> configuration
>>> - less likely to lead to unintended consequences of must statements
>>> being evaluated on nodes that don't appear in configuration
>>>
>>> Cons:
>>> - some existing models (in YANG 1.0 and presumably YANG 1.1) assume
>>> evaluation of must statements on NP container children of existing node=
s as
>>> added / clarified in YANG 1.1
>>> - need to confirm we can still model the likes of the ownership voucher
>>> must statement by altenative means if we adopt this interpretation
>>>
>>> (b) Evaluate when parent exists
>>>
>>> We evaluate must statements on non-presence container if their parent
>>> node is configured.
>>>
>>> Pros:
>>> - this is the stated position in YANG 1.1 (conflicting opinions exist o=
n
>>> this alias as to whether it should be retrospectively applied to YANG 1=
.0
>>> as 'clarification' or not)
>>> - some existing models assume this is the case (eg Jan's
>>> ownership-voucher example (YANG 1.0 model))
>>>
>>> Cons:
>>> - may lead to unintended consequences of must statements being
>>> unexpectedly evaluated (albeit model writers *should* understand how it
>>> works once we have clarified it!)
>>> - why only children, not grandchildren etc?  We examine mandatory and
>>> default on every single node, so why not for NP containers as well
>>>
>>> (c) Always evaluate
>>>
>>> We always evaluate must statements on non-presence containers
>>>
>>> Pros:
>>> - easy to understand this rule
>>>
>>> Cons:
>>> - this is different to both YANG 1.0 and YANG 1.1 current interpretatio=
n
>>> (whether you take the YANG 1.1 position as a change or as clarification=
 on
>>> YANG 1.0)
>>> - validation now has the overhead of evaluating ALL must statements on
>>> all NP containers even when not configured.
>>>
>>> ---
>>>
>>> Regards,
>>>
>>> William
>>>
>>> -----Original Message-----
>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>> Sent: 05 August 2016 09:51
>>> To: William Ivory >
>>> Cc: Robert Wilton ; Jan Lindblad ;
>>> Netconf 
>>> Subject: Re: [Netconf] What should a server response be? - depending on
>>> NP-containers
>>>
>>>
>>> On 04 Aug 2016, at 15:27, William Ivory >>> > wrote:
>>>>
>>>> So I quite agree that there are better ways of writing this.  However,
>>>> my initial YANG is valid, and at first glance it is tempting to write =
it
>>>> that way unless you have been following this discussion thread (-:
>>>>
>>>> The YANG 1.1 behaviour gives what I think some (many?) would see as
>>>> unexpected behaviour.  If treated as clarification for YANG 1.0 (ie it
>>>> applies to YANG 1.0 retrospectively) then we could end up invalidating
>>>> currently valid YANG 1.0 models if they have any examples like mine be=
low.
>>>> Conversely, Jan's ownership-voucher example would become invalid if we
>>>> don't take the YANG 1.1 behaviour and retrospectively apply it to YANG=
 1.0.
>>>>
>>>> I'm also not convinced that only evaluating musts on NP containers to
>>>> one level below configured nodes is consistent with how we deal with
>>>> defaults and mandatory statements.  For those we examine all possible
>>>> nodes, configured or otherwise, at any depth in the tree.  I think we
>>>> should either never evaluate must statements on NP containers which ha=
ve no
>>>> children, or we should always evaluate them at any depth in the tree.
>>>> What's so special about those that are children of a configured node v=
ersus
>>>> those that are grandchildren (or more)?
>>>>
>>>> I would be interested to hear from those who have written YANG models
>>>> (as opposed to those implementing YANG compilers) as to the perceived
>>>> impact of the different options on your existing models.  Internally
>>>> our YANG 1.0 models have been written on the assumption we do not
>>>> evaluate musts on NP containers with no child nodes, but it would be
>>>> reasonably easy to add 'not(current() or ...' to the
>>>>
>>> This doesn't really work: in order to evaluate an XPath expression, the
>>> context node must exist, and in our case the context node is an instanc=
e of
>>> the NP-container. So "not(current())" by definition always evaluates to
>>> false.
>>>
>>> Lada
>>>
>>>   front of any such must statements to render the outcome of this
>>>> discussion irrelevant by ensuring the statements evaluate true when th=
e NP
>>>> container is not configured and thus effectively ignoring the constrai=
nt
>>>> when not configured.
>>>>
>>>> Regards,
>>>>
>>>> William
>>>>
>>>> -----Original Message-----
>>>> From: Robert Wilton [mailto:rwilton@cisco.com]
>>>> Sent: 04 August 2016 14:10
>>>> To: William Ivory >; Jan
>>>> Lindblad 
>>>> Cc: Netconf 
>>>> Subject: Re: [Netconf] What should a server response be? - depending
>>>> on NP-containers
>>>>
>>>> Hi William,
>>>>
>>>> On 04/08/2016 13:39, William Ivory wrote:
>>>>
>>>>> Hi Rob,
>>>>>
>>>>> What about a must statement on a NP-container that implements mutual
>>>>> exclusivity with another node, eg the following when top is configure=
d:
>>>>>
>>>>> Container top {
>>>>>         Container np1 {
>>>>>                 Must "not(../np2_leaf)";
>>>>>                 Leaf np1_leaf { type string; }
>>>>>         }
>>>>>         Container np2 {
>>>>>                 Leaf np2_leaf { type string; }
>>>>>         }
>>>>> }
>>>>>
>>>>> At first glance, I think many people would assume this was intended t=
o
>>>>> prevent both np1_leaf and np2_leaf being configured at the same time.
>>>>> However, if we configure np2_leaf, container 'top' is configured, so =
we
>>>>> evaluate the must on np1 (as a np container child of an existing node=
, as
>>>>> per YANG 1.1 stated requirements) and the must statement evaluates to
>>>>> false.  Therefore we cannot configure np2_leaf *ever* in this case.
>>>>>
>>>>> Now you could argue this is badly modelled YANG, but I would suggest
>>>>> it's decidedly non-obvious that np2_leaf is not configurable here.
>>>>>
>>>> RW:
>>>>
>>>> Yes, exactly.  This is why I don't like must statements on np
>>>> containers.  Enforcing a constraint on an construct that doesn't
>>>> properly exist is a bit odd :-)
>>>>
>>>> I would suggest that it would be clearer to write this as:
>>>>
>>>> Container top {
>>>>    Container np1 {
>>>>      Leaf np1_leaf {
>>>>        type string;
>>>>        must "not(../../np2_leaf)";
>>>>      }
>>>>    }
>>>>    Container np2 {
>>>>      Leaf np2_leaf {
>>>>        type string;
>>>>      }
>>>>    }
>>>> }
>>>>
>>>> or perhaps:
>>>>
>>>> Container top {
>>>>    Container np1 {
>>>>      Leaf np1_leaf {
>>>>        type string;
>>>>        must "not(../../np2_leaf)";
>>>>      }
>>>>    }
>>>>    Container np2 {
>>>>      Leaf np2_leaf {
>>>>        type string;
>>>>        must "not(../../np1_leaf)";
>>>>      }
>>>>    }
>>>> }
>>>>
>>>> Thanks,
>>>> Rob
>>>>
>>>>
>>>> Regards,
>>>>>
>>>>> William
>>>>>
>>>>> -----Original Message-----
>>>>> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Robert
>>>>> Wilton
>>>>> Sent: 04 August 2016 13:28
>>>>> To: Jan Lindblad 
>>>>> Cc: Netconf 
>>>>> Subject: Re: [Netconf] What should a server response be? - depending
>>>>> on NP-containers
>>>>>
>>>>> Hi Jan,
>>>>>
>>>>>
>>>>> On 04/08/2016 12:21, Jan Lindblad wrote:
>>>>>
>>>>>> Rob,
>>>>>>
>>>>>> Jan Lindblad writes:
>>>>>>>>
>>>>>>>>> I'm fine with this. Maybe we should clarify that must statements
>>>>>>>>> on NP containers are evaluated if the NP container parent exists.
>>>>>>>>> That's where the "always exists" notion might help understanding =
a
>>>>>>>>> bit.
>>>>>>>>>
>>>>>>>> Or say that their existance is meaningless and carries no semantic
>>>>>>>> value, and must/when conditions should never consider or depend on
>>>>>>>> their existence.
>>>>>>>>
>>>>>>> Does that mean that for an empty NP container, it would be up to th=
e
>>>>>>> server to decide whether or not to evaluate the containers must/whe=
n
>>>>>>> statements?
>>>>>>>
>>>>>> That would be terrible. It must be completely clear when must
>>>>>> statements are evaluated and when not.
>>>>>>
>>>>> It can't be that terrible, doesn't YANG 1.0 manage today with this
>>>>> behaviour? :-)
>>>>>
>>>>> I guess that my point is thus:  if a NP container's must/when
>>>>> condition should never consider/depend on the existence of said NP
>>>>> container, then for an empty NP container it should make no differenc=
e as
>>>>> to whether or not they they are evaluated by the device.
>>>>>
>>>>> I question whether it is sensible to allow when/must statements on an
>>>>> NP container at all.  In many ways I would rather that they were rest=
ricted
>>>>> to only schema nodes that actually exist as datanodes, at least then =
the
>>>>> semantics are obvious, no special magic behaviour is required.
>>>>>
>>>>>
>>>>>    But if the NP container exists due to existence of child nodes the=
n
>>>>>>> the must/when statements would be guaranteed to be evaluated by the=
 server?
>>>>>>>
>>>>>> I think there is no argument that must statements on NP containers
>>>>>> MUST be evaluated when the container has child nodes. In my previous
>>>>>> message, in the preceding text you didn't quote, I tried to explain =
why I
>>>>>> think it's a bad idea to not also evaluate the must statements when =
the NP
>>>>>> container is empty.
>>>>>> In many real cases, it's not easy for a model reader to know whether
>>>>>> the container has child nodes or not.
>>>>>>
>>>>> Yes.  I had read Phil's suggestion as: don't write must/when
>>>>> statements that depend on the existence of an NP container.  This sou=
nds
>>>>> like quite sensible advise to me, but I might have misunderstood what=
 he
>>>>> was suggesting.
>>>>>
>>>>> Thanks,
>>>>> Rob
>>>>>
>>>>> /jan
>>>>>>
>>>>>> _______________________________________________
>>>>> Netconf mailing list
>>>>> Netconf@ietf.org
>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_m=
ai
>>>>> l
>>>>> man_listinfo_netconf&d=3DCwICAg&c=3DIL_XqQWOjubgfqINi2jTzg&r=3DGByLeg=
9jZvOv
>>>>> _
>>>>> AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=3D751sECIaA5HaNM0wQdHxLvA6UwL5IhKW91=
y_
>>>>> u 8ZrZ2Y&s=3Dx12_Ko8id4YJBVF1rFmAvbKVrZCHdIHsFnzswwJ1k68&e=3D
>>>>> .
>>>>>
>>>>> _______________________________________________
>>>> Netconf mailing list
>>>> Netconf@ietf.org
>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma=
il
>>>> man_listinfo_netconf&d=3DCwIFAg&c=3DIL_XqQWOjubgfqINi2jTzg&r=3DGByLeg9=
jZvOv_
>>>> AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=3D6jlb0kQeoX8x29SUyoT8wXmmEAZeH2PaJOI=
Xx
>>>> ueVRP4&s=3Do-TUEWoTedxYQZ0UmLD-TX17raAc9Dz1VMLk78SnXdU&e=3D
>>>>
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>>
>>>
>>>
>>>
>>> .
>>>
>>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>
> Mahesh Jethanandani
> mjethanandani@gmail.com
>
>
>
>

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




On Wed, Aug 10, 2016 at 6:50 PM, Mahesh Jethanandani =
<mjethanand=
ani@gmail.com> wrote:

On Aug 10, 2016, a=
t 2:23 PM, Andy Bierman <andy@yumaworks.com> wrote:

H=
i,

I am quite willing to accept the existing design in Y=
ANG 1.1 that NP containers
are considered to be present if there =
is a non-NP ancestor present (or the
NP container is a top-level =
data node).=C2=A0 This is easier to support.
It matches the top-d=
own callback design of many server implementations.

The update rules in sec 11 of 6020bis do not cover NP-containers correctl=
y.
It should be illegal to add a mandatory NP-container as a chil=
d node
to the augment target.=C2=A0


=

This needs to include must-stmt (fixed in the term "mandato=
ry node", bullet 3)
I don't think the text below is quit=
e right.=C2=A0 I suspect Lada can do better.


<=
/div>
OLD:

sec 3.

=C2=A0 =C2=A0o =C2=A0mandatory node: A mandatory node is one of:

=C2=A0 =C2=A0 =C2=A0 * =C2=A0A leaf, choice, anydata, or a=
nyxml node with a "mandatory"
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0statement with the value "true".

=C2=A0 =C2=A0 =C2=A0 * =C2=A0A list or leaf-list node with a "min-e=
lements" statement with a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
value greater than zero.

=C2=A0 =C2=A0 =C2=A0 * =
=C2=A0A container node without a "presence" statement and which h=
as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0at least one mandatory node =
as a child.



NE=
W:

=C2=A0=C2=A0o =C2=A0mandatory node: A mandatory=
 node is one of:

=C2=A0 =C2=A0 =C2=A0 * =
=C2=A0A leaf, choice, anydata, or anyxml node with a "mandatory"<=
/div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0statement with the value "=
true".

=C2=A0 =C2=A0 =C2=A0 * =C2=A0A list or=
 leaf-list node with a "min-elements" statement with a
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0value greater than zero.

=C2=A0 =C2=A0 =C2=A0 * =C2=A0A container node without a "pres=
ence" statement and which has
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0at least one mandatory node as a child, or has a "must" sta=
tement
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that will evaluate=
 to "false" if the container has no child node instances.

A slight modification to the third bu=
llet.

OLD:

=C2=
=A0 =C2=A0 =C2=A0 * =C2=A0A container node without a "presence" s=
tatement and which has
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0at least=
 one mandatory node as a child, or has a "must" statement
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that will evaluate to "fals=
e" if the container has no child node instances.

<=
div>NEW:

=C2=A0 =C2=A0 =C2=A0 * =C2=A0A container =
node without a "presence" statement and which has
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0at least one mandatory node as a child, o=
r has a "must" statement
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0that will evaluate to =E2=80=9Ctrue" if the container has de=
fault nodes as defined
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for leaf=
s (section 7.6.1) or for leaf-list (section 7.7.2).




It is "false" must-stmts that cause a problem.
e.g.:


augment /foo:/to=
p {
=C2=A0 =C2=A0container okay {
=C2=A0 =C2=A0 =C2=
=A0 must "A >=3D 1 and B >=3D A";
=C2=A0 =C2=A0 =
=C2=A0 leaf A { type int32; default 1; =C2=A0}
=C2=A0 =C2=A0 =C2=
=A0 leaf B { type int32; default 2; =C2=A0}
=C2=A0 }
}<=
/div>

We want to prevent an augment with a mandatory NP-=
container
where only the augmented parent exists, causing the mus=
t-stmt
to be evaluated as false, causing the creation of the pare=
nt node to fail.
This is not allowed for augment (just in-line NP=
 containers in the first release)

augment /foo:/to=
p {
=C2=A0 =C2=A0container not-okay {
=C2=A0 =C2=
=A0 =C2=A0 must "A >=3D 1 and B >=3D A";
=C2=A0 =
=C2=A0 =C2=A0 leaf A { type int32; }
=C2=A0 =C2=A0 =C2=A0 leaf B =
{ type int32; }
=C2=A0 }
}



=
Andy





On Fri, Aug 5, 2=
016 at 6:57 AM, Robert Wilton <rwilton@cisco.com> wrote:
=

Hi William,



Pragmatically, I think that I would also go for (b), with the fix suggested=
 by Lada.



My reasoning is that despite not liking "when"/"must" s=
tatements on np-containers they are clearly useful in some cases and cannot=
 be banned outright.



I also like Phil's explanation that a server could effectively rewrite =
the paths in the xpath so the "when"/"must" statement i=
s effectively bound to the nearest parent container that has presence.=C2=
=A0 That almost seems like a better way of thinking about what they really =
are.



Thanks,

Rob





On 05/08/2016 10:19, William Ivory wrote:



Hi Lada,



I was assuming that if a NP container had no children then from the perspec=
tive of current() it didn't exist, but that it was reasonable to evalua=
te the must expression on it as a 'virtual' node.=C2=A0 This just g=
ets messier and messier, though I guess that 'count(*) =3D 0' (assu=
ming no non-presence container children, otherwise would need to name child=
ren) would work instead?



There seem to be 3 options for evaluating must statements on NP containers =
that have no children - would appreciate others' input on this.=C2=A0 I=
n addition, Balazs' suggestion that modellers avoid must statements on =
NP containers where possible would seem sensible advice!



(a) Never evaluate



Never evaluate a must statement on a non-presence container that has no chi=
ldren.



Pros:

- simple to understand

- reduces number of must statements to evaluate when validating configurati=
on

- less likely to lead to unintended consequences of must statements being e=
valuated on nodes that don't appear in configuration



Cons:

- some existing models (in YANG 1.0 and presumably YANG 1.1) assume evaluat=
ion of must statements on NP container children of existing nodes as added =
/ clarified in YANG 1.1

- need to confirm we can still model the likes of the ownership voucher mus=
t statement by altenative means if we adopt this interpretation



(b) Evaluate when parent exists



We evaluate must statements on non-presence container if their parent node =
is configured.



Pros:

- this is the stated position in YANG 1.1 (conflicting opinions exist on th=
is alias as to whether it should be retrospectively applied to YANG 1.0 as =
'clarification' or not)

- some existing models assume this is the case (eg Jan's ownership-vouc=
her example (YANG 1.0 model))



Cons:

- may lead to unintended consequences of must statements being unexpectedly=
 evaluated (albeit model writers *should* understand how it works once we h=
ave clarified it!)

- why only children, not grandchildren etc?=C2=A0 We examine mandatory and =
default on every single node, so why not for NP containers as well



(c) Always evaluate



We always evaluate must statements on non-presence containers



Pros:

- easy to understand this rule



Cons:

- this is different to both YANG 1.0 and YANG 1.1 current interpretation (w=
hether you take the YANG 1.1 position as a change or as clarification on YA=
NG 1.0)

- validation now has the overhead of evaluating ALL must statements on all =
NP containers even when not configured.



---



Regards,



William



-----Original Message-----

From: Ladislav Lhotka [mailto:lhotka@nic.cz]

Sent: 05 August 2016 09:51

To: William Ivory <wivory@Brocade.com>

Cc: Robert Wilton <rwilton@cisco.com>; Jan Lindblad <janl@tail-f.com>; Netconf <netconf@ietf.org>

Subject: Re: [Netconf] What should a server response be? - depending on NP-=
containers







On 04 Aug 2016, at 15:27, William Ivory <wivory@Brocade.com> wrote:



So I quite agree that there are better ways of writing this.=C2=A0 However,=
 my initial YANG is valid, and at first glance it is tempting to write it t=
hat way unless you have been following this discussion thread (-:



The YANG 1.1 behaviour gives what I think some (many?) would see as unexpec=
ted behaviour.=C2=A0 If treated as clarification for YANG 1.0 (ie it applie=
s to YANG 1.0 retrospectively) then we could end up invalidating currently =
valid YANG 1.0 models if they have any examples like mine below.=C2=A0 Conv=
ersely, Jan's ownership-voucher example would become invalid if we don&=
#39;t take the YANG 1.1 behaviour and retrospectively apply it to YANG 1.0.=




I'm also not convinced that only evaluating musts on NP containers to o=
ne level below configured nodes is consistent with how we deal with default=
s and mandatory statements.=C2=A0 For those we examine all possible nodes, =
configured or otherwise, at any depth in the tree.=C2=A0 I think we should =
either never evaluate must statements on NP containers which have no childr=
en, or we should always evaluate them at any depth in the tree.=C2=A0 What&=
#39;s so special about those that are children of a configured node versus =
those that are grandchildren (or more)?



I would be interested to hear from those who have written YANG models

(as opposed to those implementing YANG compilers) as to the perceived

impact of the different options on your existing models.=C2=A0 Internally
our YANG 1.0 models have been written on the assumption we do not

evaluate musts on NP containers with no child nodes, but it would be

reasonably easy to add 'not(current() or ...' to the



This doesn't really work: in order to evaluate an XPath expression, the=
 context node must exist, and in our case the context node is an instance o=
f the NP-container. So "not(current())" by definition always eval=
uates to false.



Lada





=C2=A0 front of any such must statements to render the outcome of this disc=
ussion irrelevant by ensuring the statements evaluate true when the NP cont=
ainer is not configured and thus effectively ignoring the constraint when n=
ot configured.



Regards,



William



-----Original Message-----

From: Robert Wilton [mailto:rwilton@cisco.com]

Sent: 04 August 2016 14:10

To: William Ivory <wivory@Brocade.com>; Jan Lindblad <janl@tail-f.com>

Cc: Netconf <netco=
nf@ietf.org>

Subject: Re: [Netconf] What should a server response be? - depending

on NP-containers



Hi William,



On 04/08/2016 13:39, William Ivory wrote:



Hi Rob,



What about a must statement on a NP-container that implements mutual exclus=
ivity with another node, eg the following when top is configured:



Container top {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Container np1 {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Must "not(../n=
p2_leaf)";

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Leaf np1_leaf { typ=
e string; }

=C2=A0 =C2=A0 =C2=A0 =C2=A0 }

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Container np2 {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Leaf np2_leaf { typ=
e string; }

=C2=A0 =C2=A0 =C2=A0 =C2=A0 }

}



At first glance, I think many people would assume this was intended to prev=
ent both np1_leaf and np2_leaf being configured at the same time.=C2=A0 How=
ever, if we configure np2_leaf, container 'top' is configured, so w=
e evaluate the must on np1 (as a np container child of an existing node, as=
 per YANG 1.1 stated requirements) and the must statement evaluates to fals=
e.=C2=A0 Therefore we cannot configure np2_leaf *ever* in this case.



Now you could argue this is badly modelled YANG, but I would suggest it'=
;s decidedly non-obvious that np2_leaf is not configurable here.



RW:



Yes, exactly.=C2=A0 This is why I don't like must statements on np

containers.=C2=A0 Enforcing a constraint on an construct that doesn't
properly exist is a bit odd :-)



I would suggest that it would be clearer to write this as:



Container top {

=C2=A0 =C2=A0Container np1 {

=C2=A0 =C2=A0 =C2=A0Leaf np1_leaf {

=C2=A0 =C2=A0 =C2=A0 =C2=A0type string;

=C2=A0 =C2=A0 =C2=A0 =C2=A0must "not(../../np2_leaf)";

=C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0}

=C2=A0 =C2=A0Container np2 {

=C2=A0 =C2=A0 =C2=A0Leaf np2_leaf {

=C2=A0 =C2=A0 =C2=A0 =C2=A0type string;

=C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0}

}



or perhaps:



Container top {

=C2=A0 =C2=A0Container np1 {

=C2=A0 =C2=A0 =C2=A0Leaf np1_leaf {

=C2=A0 =C2=A0 =C2=A0 =C2=A0type string;

=C2=A0 =C2=A0 =C2=A0 =C2=A0must "not(../../np2_leaf)";

=C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0}

=C2=A0 =C2=A0Container np2 {

=C2=A0 =C2=A0 =C2=A0Leaf np2_leaf {

=C2=A0 =C2=A0 =C2=A0 =C2=A0type string;

=C2=A0 =C2=A0 =C2=A0 =C2=A0must "not(../../np1_leaf)";

=C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0}

}



Thanks,

Rob







Regards,



William



-----Original Message-----

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Robert

Wilton

Sent: 04 August 2016 13:28

To: Jan Lindblad <j=
anl@tail-f.com>

Cc: Netconf <netco=
nf@ietf.org>

Subject: Re: [Netconf] What should a server response be? - depending

on NP-containers



Hi Jan,





On 04/08/2016 12:21, Jan Lindblad wrote:



Rob,





Jan Lindblad writes:



I'm fine with this. Maybe we should clarify that must statements

on NP containers are evaluated if the NP container parent exists.

That's where the "always exists" notion might help understand=
ing a bit.



Or say that their existance is meaningless and carries no semantic

value, and must/when conditions should never consider or depend on

their existence.



Does that mean that for an empty NP container, it would be up to the server=
 to decide whether or not to evaluate the containers must/when statements?<=
br>


That would be terrible. It must be completely clear when must statements ar=
e evaluated and when not.



It can't be that terrible, doesn't YANG 1.0 manage today with this<=
br>
behaviour? :-)



I guess that my point is thus:=C2=A0 if a NP container's must/when cond=
ition should never consider/depend on the existence of said NP container, t=
hen for an empty NP container it should make no difference as to whether or=
 not they they are evaluated by the device.



I question whether it is sensible to allow when/must statements on an NP co=
ntainer at all.=C2=A0 In many ways I would rather that they were restricted=
 to only schema nodes that actually exist as datanodes, at least then the s=
emantics are obvious, no special magic behaviour is required.







=C2=A0 =C2=A0But if the NP container exists due to existence of child nodes=
 then the must/when statements would be guaranteed to be evaluated by the s=
erver?



I think there is no argument that must statements on NP containers MUST be =
evaluated when the container has child nodes. In my previous message, in th=
e preceding text you didn't quote, I tried to explain why I think it=
9;s a bad idea to not also evaluate the must statements when the NP contain=
er is empty.

In many real cases, it's not easy for a model reader to know whether th=
e container has child nodes or not.



Yes.=C2=A0 I had read Phil's suggestion as: don't write must/when s=
tatements that depend on the existence of an NP container.=C2=A0 This sound=
s like quite sensible advise to me, but I might have misunderstood what he =
was suggesting.



Thanks,

Rob





/jan





_______________________________________________

Netconf mailing list

Netconf@ietf.org<=
br>
https://urldefense.proofpoint=
.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai

l

man_listinfo_netconf&d=3DCwICAg&c=3DIL_XqQWOjubgfqINi2jTzg&=
;r=3DGByLeg9jZvOv

_

AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=3D751sECIaA5HaNM0wQdHxLvA6UwL5IhKW91y_

u 8ZrZ2Y&s=3Dx12_Ko8id4YJBVF1rFmAvbKVrZCHdIHsFnzswwJ1k68&e=3D<=
br>
.





_______________________________________________

Netconf mailing list

Netconf@ietf.org<=
br>
https://urldefense.proofpoin=
t.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail

man_listinfo_netconf&d=3DCwIFAg&c=3DIL_XqQWOjubgfqINi2jTzg&=
;r=3DGByLeg9jZvOv_

AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=3D6jlb0kQeoX8x29SUyoT8wXmmEAZeH2PaJOIXx

ueVRP4&s=3Do-TUEWoTedxYQZ0UmLD-TX17raAc9Dz1VMLk78SnXdU&e=3D


--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C









.







_______________________________________________

Netconf mailing list

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



_______________________________________________
Netconf mailing lis=
t
Netconf@ietf.org=

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



Mahesh Jethanandani










--001a114413b4eb5ca10539c23f3e--


From nobody Thu Aug 11 01:01:10 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC12212D729 for ; Thu, 11 Aug 2016 01:01:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZbHdwkgaOIc for ; Thu, 11 Aug 2016 01:00:54 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0290812D6AE for ; Thu, 11 Aug 2016 01:00:53 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 3A1611CC02F0; Thu, 11 Aug 2016 10:01:06 +0200 (CEST)
From: Ladislav Lhotka 
To: Andy Bierman , Robert Wilton 
In-Reply-To: 
References: <201608031942.u73Jg8ol039135@idle.juniper.net> <5a49581e-71ef-4be9-1e51-62213901a887@cisco.com> <0066A47E-240F-4B6B-920B-98B064CE1E60@tail-f.com>   <05ea80f8-665b-d9b7-53db-207fc862409e@cisco.com> <5d8503f67066406a992738b766556247@EMEAWP-EXMB11.corp.brocade.com>  <357980ab80a64bbba5d6778fdf2160f8@EMEAWP-EXMB11.corp.brocade.com> <49054fe2-b1d1-ba18-a0a0-ea799e8947ef@cisco.com> 
User-Agent: Notmuch/0.22.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Thu, 11 Aug 2016 10:00:52 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Aug 2016 08:01:09 -0000

Andy Bierman  writes:

> Hi,
>
> I am quite willing to accept the existing design in YANG 1.1 that NP
> containers
> are considered to be present if there is a non-NP ancestor present (or the
> NP container is a top-level data node).  This is easier to support.
> It matches the top-down callback design of many server implementations.
>
> The update rules in sec 11 of 6020bis do not cover NP-containers correctly.
> It should be illegal to add a mandatory NP-container as a child node
> to the augment target.
>
>
> This needs to include must-stmt (fixed in the term "mandatory node", bullet
> 3)
> I don't think the text below is quite right.  I suspect Lada can do better.
>
>
> OLD:
>
> sec 3.
>
>    o  mandatory node: A mandatory node is one of:
>
>       *  A leaf, choice, anydata, or anyxml node with a "mandatory"
>          statement with the value "true".
>
>       *  A list or leaf-list node with a "min-elements" statement with a
>          value greater than zero.
>
>       *  A container node without a "presence" statement and which has
>          at least one mandatory node as a child.
>
>
>
> NEW:
>
>   o  mandatory node: A mandatory node is one of:
>
>       *  A leaf, choice, anydata, or anyxml node with a "mandatory"
>          statement with the value "true".
>
>       *  A list or leaf-list node with a "min-elements" statement with a
>          value greater than zero.
>
>       *  A container node without a "presence" statement and which has
>          at least one mandatory node as a child, or has a "must" statement
>          that will evaluate to "false" if the container has no child node
> instances.

I don't agree with this, "must" statements on leaf(-list) default
instances are also evaluated but it doesn't make them mandatory.

As I wrote, IMO the easiest solution is to add NP-containers to default
content, subject to the same rules as we have for leaf(-list)s with
defaults.

I'd suggest to wait for Martin, hopefully he isn't shipwrecked on a
deserted island.

Lada

>
>
>
> Andy
>
>
>
>
>
> On Fri, Aug 5, 2016 at 6:57 AM, Robert Wilton  wrote:
>
>> Hi William,
>>
>> Pragmatically, I think that I would also go for (b), with the fix
>> suggested by Lada.
>>
>> My reasoning is that despite not liking "when"/"must" statements on
>> np-containers they are clearly useful in some cases and cannot be banned
>> outright.
>>
>> I also like Phil's explanation that a server could effectively rewrite the
>> paths in the xpath so the "when"/"must" statement is effectively bound to
>> the nearest parent container that has presence.  That almost seems like a
>> better way of thinking about what they really are.
>>
>> Thanks,
>> Rob
>>
>>
>> On 05/08/2016 10:19, William Ivory wrote:
>>
>>> Hi Lada,
>>>
>>> I was assuming that if a NP container had no children then from the
>>> perspective of current() it didn't exist, but that it was reasonable to
>>> evaluate the must expression on it as a 'virtual' node.  This just gets
>>> messier and messier, though I guess that 'count(*) = 0' (assuming no
>>> non-presence container children, otherwise would need to name children)
>>> would work instead?
>>>
>>> There seem to be 3 options for evaluating must statements on NP
>>> containers that have no children - would appreciate others' input on this.
>>> In addition, Balazs' suggestion that modellers avoid must statements on NP
>>> containers where possible would seem sensible advice!
>>>
>>> (a) Never evaluate
>>>
>>> Never evaluate a must statement on a non-presence container that has no
>>> children.
>>>
>>> Pros:
>>> - simple to understand
>>> - reduces number of must statements to evaluate when validating
>>> configuration
>>> - less likely to lead to unintended consequences of must statements being
>>> evaluated on nodes that don't appear in configuration
>>>
>>> Cons:
>>> - some existing models (in YANG 1.0 and presumably YANG 1.1) assume
>>> evaluation of must statements on NP container children of existing nodes as
>>> added / clarified in YANG 1.1
>>> - need to confirm we can still model the likes of the ownership voucher
>>> must statement by altenative means if we adopt this interpretation
>>>
>>> (b) Evaluate when parent exists
>>>
>>> We evaluate must statements on non-presence container if their parent
>>> node is configured.
>>>
>>> Pros:
>>> - this is the stated position in YANG 1.1 (conflicting opinions exist on
>>> this alias as to whether it should be retrospectively applied to YANG 1.0
>>> as 'clarification' or not)
>>> - some existing models assume this is the case (eg Jan's
>>> ownership-voucher example (YANG 1.0 model))
>>>
>>> Cons:
>>> - may lead to unintended consequences of must statements being
>>> unexpectedly evaluated (albeit model writers *should* understand how it
>>> works once we have clarified it!)
>>> - why only children, not grandchildren etc?  We examine mandatory and
>>> default on every single node, so why not for NP containers as well
>>>
>>> (c) Always evaluate
>>>
>>> We always evaluate must statements on non-presence containers
>>>
>>> Pros:
>>> - easy to understand this rule
>>>
>>> Cons:
>>> - this is different to both YANG 1.0 and YANG 1.1 current interpretation
>>> (whether you take the YANG 1.1 position as a change or as clarification on
>>> YANG 1.0)
>>> - validation now has the overhead of evaluating ALL must statements on
>>> all NP containers even when not configured.
>>>
>>> ---
>>>
>>> Regards,
>>>
>>> William
>>>
>>> -----Original Message-----
>>> From: Ladislav Lhotka [mailto:lhotka@nic.cz]
>>> Sent: 05 August 2016 09:51
>>> To: William Ivory 
>>> Cc: Robert Wilton ; Jan Lindblad ;
>>> Netconf 
>>> Subject: Re: [Netconf] What should a server response be? - depending on
>>> NP-containers
>>>
>>>
>>> On 04 Aug 2016, at 15:27, William Ivory  wrote:
>>>>
>>>> So I quite agree that there are better ways of writing this.  However,
>>>> my initial YANG is valid, and at first glance it is tempting to write it
>>>> that way unless you have been following this discussion thread (-:
>>>>
>>>> The YANG 1.1 behaviour gives what I think some (many?) would see as
>>>> unexpected behaviour.  If treated as clarification for YANG 1.0 (ie it
>>>> applies to YANG 1.0 retrospectively) then we could end up invalidating
>>>> currently valid YANG 1.0 models if they have any examples like mine below.
>>>> Conversely, Jan's ownership-voucher example would become invalid if we
>>>> don't take the YANG 1.1 behaviour and retrospectively apply it to YANG 1.0.
>>>>
>>>> I'm also not convinced that only evaluating musts on NP containers to
>>>> one level below configured nodes is consistent with how we deal with
>>>> defaults and mandatory statements.  For those we examine all possible
>>>> nodes, configured or otherwise, at any depth in the tree.  I think we
>>>> should either never evaluate must statements on NP containers which have no
>>>> children, or we should always evaluate them at any depth in the tree.
>>>> What's so special about those that are children of a configured node versus
>>>> those that are grandchildren (or more)?
>>>>
>>>> I would be interested to hear from those who have written YANG models
>>>> (as opposed to those implementing YANG compilers) as to the perceived
>>>> impact of the different options on your existing models.  Internally
>>>> our YANG 1.0 models have been written on the assumption we do not
>>>> evaluate musts on NP containers with no child nodes, but it would be
>>>> reasonably easy to add 'not(current() or ...' to the
>>>>
>>> This doesn't really work: in order to evaluate an XPath expression, the
>>> context node must exist, and in our case the context node is an instance of
>>> the NP-container. So "not(current())" by definition always evaluates to
>>> false.
>>>
>>> Lada
>>>
>>>   front of any such must statements to render the outcome of this
>>>> discussion irrelevant by ensuring the statements evaluate true when the NP
>>>> container is not configured and thus effectively ignoring the constraint
>>>> when not configured.
>>>>
>>>> Regards,
>>>>
>>>> William
>>>>
>>>> -----Original Message-----
>>>> From: Robert Wilton [mailto:rwilton@cisco.com]
>>>> Sent: 04 August 2016 14:10
>>>> To: William Ivory ; Jan Lindblad 
>>>> Cc: Netconf 
>>>> Subject: Re: [Netconf] What should a server response be? - depending
>>>> on NP-containers
>>>>
>>>> Hi William,
>>>>
>>>> On 04/08/2016 13:39, William Ivory wrote:
>>>>
>>>>> Hi Rob,
>>>>>
>>>>> What about a must statement on a NP-container that implements mutual
>>>>> exclusivity with another node, eg the following when top is configured:
>>>>>
>>>>> Container top {
>>>>>         Container np1 {
>>>>>                 Must "not(../np2_leaf)";
>>>>>                 Leaf np1_leaf { type string; }
>>>>>         }
>>>>>         Container np2 {
>>>>>                 Leaf np2_leaf { type string; }
>>>>>         }
>>>>> }
>>>>>
>>>>> At first glance, I think many people would assume this was intended to
>>>>> prevent both np1_leaf and np2_leaf being configured at the same time.
>>>>> However, if we configure np2_leaf, container 'top' is configured, so we
>>>>> evaluate the must on np1 (as a np container child of an existing node, as
>>>>> per YANG 1.1 stated requirements) and the must statement evaluates to
>>>>> false.  Therefore we cannot configure np2_leaf *ever* in this case.
>>>>>
>>>>> Now you could argue this is badly modelled YANG, but I would suggest
>>>>> it's decidedly non-obvious that np2_leaf is not configurable here.
>>>>>
>>>> RW:
>>>>
>>>> Yes, exactly.  This is why I don't like must statements on np
>>>> containers.  Enforcing a constraint on an construct that doesn't
>>>> properly exist is a bit odd :-)
>>>>
>>>> I would suggest that it would be clearer to write this as:
>>>>
>>>> Container top {
>>>>    Container np1 {
>>>>      Leaf np1_leaf {
>>>>        type string;
>>>>        must "not(../../np2_leaf)";
>>>>      }
>>>>    }
>>>>    Container np2 {
>>>>      Leaf np2_leaf {
>>>>        type string;
>>>>      }
>>>>    }
>>>> }
>>>>
>>>> or perhaps:
>>>>
>>>> Container top {
>>>>    Container np1 {
>>>>      Leaf np1_leaf {
>>>>        type string;
>>>>        must "not(../../np2_leaf)";
>>>>      }
>>>>    }
>>>>    Container np2 {
>>>>      Leaf np2_leaf {
>>>>        type string;
>>>>        must "not(../../np1_leaf)";
>>>>      }
>>>>    }
>>>> }
>>>>
>>>> Thanks,
>>>> Rob
>>>>
>>>>
>>>> Regards,
>>>>>
>>>>> William
>>>>>
>>>>> -----Original Message-----
>>>>> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Robert
>>>>> Wilton
>>>>> Sent: 04 August 2016 13:28
>>>>> To: Jan Lindblad 
>>>>> Cc: Netconf 
>>>>> Subject: Re: [Netconf] What should a server response be? - depending
>>>>> on NP-containers
>>>>>
>>>>> Hi Jan,
>>>>>
>>>>>
>>>>> On 04/08/2016 12:21, Jan Lindblad wrote:
>>>>>
>>>>>> Rob,
>>>>>>
>>>>>> Jan Lindblad writes:
>>>>>>>>
>>>>>>>>> I'm fine with this. Maybe we should clarify that must statements
>>>>>>>>> on NP containers are evaluated if the NP container parent exists.
>>>>>>>>> That's where the "always exists" notion might help understanding a
>>>>>>>>> bit.
>>>>>>>>>
>>>>>>>> Or say that their existance is meaningless and carries no semantic
>>>>>>>> value, and must/when conditions should never consider or depend on
>>>>>>>> their existence.
>>>>>>>>
>>>>>>> Does that mean that for an empty NP container, it would be up to the
>>>>>>> server to decide whether or not to evaluate the containers must/when
>>>>>>> statements?
>>>>>>>
>>>>>> That would be terrible. It must be completely clear when must
>>>>>> statements are evaluated and when not.
>>>>>>
>>>>> It can't be that terrible, doesn't YANG 1.0 manage today with this
>>>>> behaviour? :-)
>>>>>
>>>>> I guess that my point is thus:  if a NP container's must/when condition
>>>>> should never consider/depend on the existence of said NP container, then
>>>>> for an empty NP container it should make no difference as to whether or not
>>>>> they they are evaluated by the device.
>>>>>
>>>>> I question whether it is sensible to allow when/must statements on an
>>>>> NP container at all.  In many ways I would rather that they were restricted
>>>>> to only schema nodes that actually exist as datanodes, at least then the
>>>>> semantics are obvious, no special magic behaviour is required.
>>>>>
>>>>>
>>>>>    But if the NP container exists due to existence of child nodes then
>>>>>>> the must/when statements would be guaranteed to be evaluated by the server?
>>>>>>>
>>>>>> I think there is no argument that must statements on NP containers
>>>>>> MUST be evaluated when the container has child nodes. In my previous
>>>>>> message, in the preceding text you didn't quote, I tried to explain why I
>>>>>> think it's a bad idea to not also evaluate the must statements when the NP
>>>>>> container is empty.
>>>>>> In many real cases, it's not easy for a model reader to know whether
>>>>>> the container has child nodes or not.
>>>>>>
>>>>> Yes.  I had read Phil's suggestion as: don't write must/when statements
>>>>> that depend on the existence of an NP container.  This sounds like quite
>>>>> sensible advise to me, but I might have misunderstood what he was
>>>>> suggesting.
>>>>>
>>>>> Thanks,
>>>>> Rob
>>>>>
>>>>> /jan
>>>>>>
>>>>>> _______________________________________________
>>>>> Netconf mailing list
>>>>> Netconf@ietf.org
>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mai
>>>>> l
>>>>> man_listinfo_netconf&d=CwICAg&c=IL_XqQWOjubgfqINi2jTzg&r=GByLeg9jZvOv
>>>>> _
>>>>> AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=751sECIaA5HaNM0wQdHxLvA6UwL5IhKW91y_
>>>>> u 8ZrZ2Y&s=x12_Ko8id4YJBVF1rFmAvbKVrZCHdIHsFnzswwJ1k68&e=
>>>>> .
>>>>>
>>>>> _______________________________________________
>>>> Netconf mailing list
>>>> Netconf@ietf.org
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
>>>> man_listinfo_netconf&d=CwIFAg&c=IL_XqQWOjubgfqINi2jTzg&r=GByLeg9jZvOv_
>>>> AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=6jlb0kQeoX8x29SUyoT8wXmmEAZeH2PaJOIXx
>>>> ueVRP4&s=o-TUEWoTedxYQZ0UmLD-TX17raAc9Dz1VMLk78SnXdU&e=
>>>>
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>>
>>>
>>>
>>>
>>> .
>>>
>>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>>

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


From nobody Thu Aug 11 05:36:22 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC7D12D1D7 for ; Thu, 11 Aug 2016 05:36:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8V3lBdsmrq5 for ; Thu, 11 Aug 2016 05:36:19 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B508D12D162 for ; Thu, 11 Aug 2016 05:36:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 2766B92E28F; Thu, 11 Aug 2016 14:36:16 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id qzdT5VS94KMi; Thu, 11 Aug 2016 14:36:16 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id EA70192E27A; Thu, 11 Aug 2016 14:36:15 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 5529tGkKwySX; Thu, 11 Aug 2016 14:36:15 +0200 (CEST)
Received: from [192.168.209.141] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id C1E0092DFE1; Thu, 11 Aug 2016 14:36:15 +0200 (CEST)
Message-ID: <57AC713E.8080006@transpacket.com>
Date: Thu, 11 Aug 2016 14:36:14 +0200
From: Vladimir Vassilev 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0
MIME-Version: 1.0
To: Ladislav Lhotka , Andy Bierman 
References: <201608031942.u73Jg8ol039135@idle.juniper.net> <5a49581e-71ef-4be9-1e51-62213901a887@cisco.com> <0066A47E-240F-4B6B-920B-98B064CE1E60@tail-f.com>   <05ea80f8-665b-d9b7-53db-207fc862409e@cisco.com> <5d8503f67066406a992738b766556247@EMEAWP-EXMB11.corp.brocade.com>  <357980ab80a64bbba5d6778fdf2160f8@EMEAWP-EXMB11.corp.brocade.com> <49054fe2-b1d1-ba18-a0a0-ea799e8947ef@cisco.com>  
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Aug 2016 12:36:20 -0000

On 08/11/2016 10:00 AM, Ladislav Lhotka wrote:
> I'd suggest to wait for Martin, hopefully he isn't shipwrecked on a 
> deserted island. Lada
+1

Because Martin knows why the following text was introduced between rev. 
01 and rev. 02  in 6.4.1 Xpath Context:

    If a node that exists in the accessible tree has a non-presence
    container as a child, then the non-presence container also exists in
    the tree.

I can't find nothing relevant to the change on the mailing list and the 
minutes in that time period, or the issue list.

IMO the solution is to accept that both presence and non-presence 
containers are explicitly created and deleted. This would allow the 
following patch to rfc6020.txt as a starting point and yield this 
discussion pointless. In the same time it would fix the conflict with 
NACM in the cases when non-presence container are used to organize 
access rights which is often the only sane way to do it.

Incremental editing of configuration trees is another feature e.g. you 
would hate operating system that does not allow you the creation of 
empty directories or automatically creates them for you just because 
they do not contain a file. And we accept to live with the overhead of 
empty directories for various reasons ... like access control etc. In 
the end this is what has started the entire problem.

567,569d566
<    o  A container node without a "presence" statement, which has at
<       least one mandatory node as a child.
<
2875,2877c2872
<    and to keep these nodes together.  The "scrambling" node itself has
<    no meaning, so removing the node when it becomes empty relieves the
<    user from performing this task.
---
 >    and to keep these nodes together.
2882,2883c2877
<    organizing related configuration.  These containers are explicitly
<    created and deleted.
---
 >    organizing related configuration.
3118,3124d3111
<    A NETCONF server that replies to a  or  request MAY
<    choose not to send a container element if the container node does not
<    have the "presence" statement and no child nodes exist. Thus, a
<    client that receives an  for a  or 
<    request, must be prepared to handle the case that a container node
<    without a "presence" statement is not present in the XML.
<
3131,3133d3117
<    If a container does not have a "presence" statement and the last
<    child node is deleted, the NETCONF server MAY delete the container.
<
3235,3236c3219
<    depends on the leaf's closest ancestor node in the schema tree that
<    is not a non-presence container:
---
 >    depends on the leaf's closest ancestor node in the schema tree:
3321,3322c3304,3305
<    the type of the leaf's closest ancestor node in the schema tree that
<    is not a non-presence container (see Section 7.5.1):
---
 >    the type of the leaf's closest ancestor node in the schema tree
 >    (see Section 7.5.1):
3509,3510c3492
<    or list's closest ancestor node in the schema tree that is not a non-
<    presence container (see Section 7.5.1):
---
 >    or list's closest ancestor node in the schema tree (see Section 
7.5.1):
4385,4386c4367
<    closest ancestor node in the schema tree which is not a non-presence
<    container (see Section 7.5.1):
---
 >    closest ancestor node in the schema tree (see Section 7.5.1):

Vladimir


From nobody Thu Aug 11 07:35:12 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914EE12D769 for ; Thu, 11 Aug 2016 07:35:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.497
X-Spam-Level: 
X-Spam-Status: No, score=-3.497 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f_7pbnU-h0sk for ; Thu, 11 Aug 2016 07:35:01 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 22DFB12D76E for ; Thu, 11 Aug 2016 07:34:28 -0700 (PDT)
X-AuditID: c1b4fb2d-917ff700000019a3-9a-57ac8cf18e7b
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by  (Symantec Mail Security) with SMTP id C4.79.06563.1FC8CA75; Thu, 11 Aug 2016 16:34:26 +0200 (CEST)
Received: from [159.107.197.188] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.3.301.0; Thu, 11 Aug 2016 16:34:25 +0200
To: Vladimir Vassilev , Ladislav Lhotka , Andy Bierman 
References: <201608031942.u73Jg8ol039135@idle.juniper.net> <5a49581e-71ef-4be9-1e51-62213901a887@cisco.com> <0066A47E-240F-4B6B-920B-98B064CE1E60@tail-f.com>   <05ea80f8-665b-d9b7-53db-207fc862409e@cisco.com> <5d8503f67066406a992738b766556247@EMEAWP-EXMB11.corp.brocade.com>  <357980ab80a64bbba5d6778fdf2160f8@EMEAWP-EXMB11.corp.brocade.com> <49054fe2-b1d1-ba18-a0a0-ea799e8947ef@cisco.com>   <57AC713E.8080006@transpacket.com>
From: Balazs Lengyel 
Message-ID: <3a6fcf51-b808-e2aa-0548-e2ac705ee6bd@ericsson.com>
Date: Thu, 11 Aug 2016 16:34:24 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <57AC713E.8080006@transpacket.com>
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM2K7pe6nnjXhBi/6bSweHJnFbnFh1Vw2 i6mbbrNanJr/jdWBxWPJkp9MHpsu32H0uPrhJItHS/9FlgCWKC6blNSczLLUIn27BK6Mg9cv MxbsNq341nePtYFxi0oXIyeHhICJxJej99m7GLk4hATWM0rs/b+cFSQhJLCWUaLhXCmILSwQ LvH26Ro2EFtEoExizey3TBANu1glzuy7wA6SYBaQk1j8o4cJxGYTMJKY2n+eBcTmFbCX+LV2 OiOIzSKgKvGq4TqQzcEhKhAjsb4vAaJEUOLkzCdg5ZwC+hJ3526HGqkvcf3OfVYIW16ieets ZojbNCQeXvjLOoFRYBaS9llIWmYhaVnAyLyKUbQ4tbg4N93IWC+1KDO5uDg/Ty8vtWQTIzB8 D275rbuDcfVrx0OMAhyMSjy8C7JXhwuxJpYVV+YeYpTgYFYS4fVoXRMuxJuSWFmVWpQfX1Sa k1p8iFGag0VJnNf/pWK4kEB6YklqdmpqQWoRTJaJg1OqgdHnsNeLmNC7YZ3SXc7qv3al90rt eqfDt8x8o/xiL6mtR1zl7Isfsk/lnH7vyO+VBhMrpmpWv/9R+2th9Y6Xn1+K/rzrvdygtLHq 7Cpfo0vHT6jLvkuzzOCW8N9y/1nrx3tPtx+/ZNL24oz75ClP7x678M/HgmPywVcFq+XiX0z3 S87sfr/vaLytEktxRqKhFnNRcSIAsh/xmFsCAAA=
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Aug 2016 14:35:07 -0000


  
    
  
  
    
As I remember the discussion was started because netconf
      default-operation=none works in an unstable way on NP-containers.

    
The RFCs allows the sequence which some implementations do use:

    
    
      
  • edit-config operation=create empty NP-container
    • 
      
  • server deletes the empty NP-container
    • 
      
  • client uses edit-config default-operation=none on NP-container
        with operation=create to create a child node of the NP-container
    • 
      
  • server rejects the edit-config as the NP-container does not
        exist, although the user explicitly created it.
    • 
    

    
This makes default-operation=none unusable. This is a MAJOR
      problem for us, so we need a solution for this BUG.

    

    
regards Balazs

    

    

    
On 2016-08-11 14:36, Vladimir Vassilev
      wrote:

    

    
On
      08/11/2016 10:00 AM, Ladislav Lhotka wrote:
      

      
I'd suggest to wait for Martin, hopefully
        he isn't shipwrecked on a deserted island. Lada
        

      

      +1
      

      

      Because Martin knows why the following text was introduced between
      rev. 01 and rev. 02 in 6.4.1 Xpath Context:
      

      

       If a node that exists in the accessible tree has a non-presence
      

       container as a child, then the non-presence container also
      exists in
      

       the tree.
      

      

      I can't find nothing relevant to the change on the mailing list
      and the minutes in that time period, or the issue list.
      

      

      IMO the solution is to accept that both presence and non-presence
      containers are explicitly created and deleted. This would allow
      the following patch to rfc6020.txt as a starting point and yield
      this discussion pointless. In the same time it would fix the
      conflict with NACM in the cases when non-presence container are
      used to organize access rights which is often the only sane way to
      do it.
      

      

      Incremental editing of configuration trees is another feature e.g.
      you would hate operating system that does not allow you the
      creation of empty directories or automatically creates them for
      you just because they do not contain a file. And we accept to live
      with the overhead of empty directories for various reasons ...
      like access control etc. In the end this is what has started the
      entire problem.
      

      

      567,569d566
      

      < o A container node without a "presence" statement, which
      has at
      

      < least one mandatory node as a child.
      

      <
      

      2875,2877c2872
      

      < and to keep these nodes together. The "scrambling" node
      itself has
      

      < no meaning, so removing the node when it becomes empty
      relieves the
      

      < user from performing this task.
      

      ---
      

      > and to keep these nodes together.
      

      2882,2883c2877
      

      < organizing related configuration. These containers are
      explicitly
      

      < created and deleted.
      

      ---
      

      > organizing related configuration.
      

      3118,3124d3111
      

      < A NETCONF server that replies to a <get> or
      <get-config> request MAY
      

      < choose not to send a container element if the container
      node does not
      

      < have the "presence" statement and no child nodes exist.
      Thus, a
      

      < client that receives an <rpc-reply> for a
      <get> or <get-config>
      

      < request, must be prepared to handle the case that a
      container node
      

      < without a "presence" statement is not present in the XML.
      

      <
      

      3131,3133d3117
      

      < If a container does not have a "presence" statement and
      the last
      

      < child node is deleted, the NETCONF server MAY delete the
      container.
      

      <
      

      3235,3236c3219
      

      < depends on the leaf's closest ancestor node in the schema
      tree that
      

      < is not a non-presence container:
      

      ---
      

      > depends on the leaf's closest ancestor node in the schema
      tree:
      

      3321,3322c3304,3305
      

      < the type of the leaf's closest ancestor node in the schema
      tree that
      

      < is not a non-presence container (see Section 7.5.1):
      

      ---
      

      > the type of the leaf's closest ancestor node in the schema
      tree
      

      > (see Section 7.5.1):
      

      3509,3510c3492
      

      < or list's closest ancestor node in the schema tree that is
      not a non-
      

      < presence container (see Section 7.5.1):
      

      ---
      

      > or list's closest ancestor node in the schema tree (see
      Section 7.5.1):
      

      4385,4386c4367
      

      < closest ancestor node in the schema tree which is not a
      non-presence
      

      < container (see Section 7.5.1):
      

      ---
      

      > closest ancestor node in the schema tree (see Section
      7.5.1):
      

      

      Vladimir
      

      

      _______________________________________________
      

      Netconf mailing list
      

      Netconf@ietf.org
      

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

      

    

    

    
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com 


  



From nobody Thu Aug 11 07:38:32 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2582712D0A6 for ; Thu, 11 Aug 2016 07:38:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X56nECKYVkcl for ; Thu, 11 Aug 2016 07:38:28 -0700 (PDT)
Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 D9D8A12D513 for ; Thu, 11 Aug 2016 07:38:15 -0700 (PDT)
Received: by mail-ua0-x22e.google.com with SMTP id n59so9401935uan.2 for ; Thu, 11 Aug 2016 07:38:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pBE/nN74RlLkdMvO/ZJfVwKKYlvIJtx24dW7OF2mX80=; b=s5ALR/t/EByATsG5Q/Vm74HCQptNOtwHIrW4cQVyqldyNCzW20FQQhwqclzOnic4Ll BRbVmp73UIGG7uZTzX62Kqmrd5TRTXSuwRZI4sZQqO7CzQF7UynbUeOBzXVGDggTH0mc 0j6h4APS8xYGyWzdYc4b8Cq6wgKxkYwa35uJ/7BCfm1Yr2/oLbuIZFMqlgnRLiy6ONys r9qTcx6gNy74a4vfA9bGH9tciu03ymfDlzPX/3FYEdHMM0AYs3SVfM/PLkrCRsyEpNVj HHS2ZlZbEQlicv3Lun0mRh7haB4I8msy3rvoY9TKLtwpqiFC6dRc4Fw6UEPw13oOMyp0 y43A==
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:from:date :message-id:subject:to:cc; bh=pBE/nN74RlLkdMvO/ZJfVwKKYlvIJtx24dW7OF2mX80=; b=U3HWZz+UNxDNBCmBuIIU5XthdcJHAraKpCJoMSL5L12SjFuYVcEE/Zhmn40bzHGcYg s2WrwZkBh0TJM84xuJz8ZSrU/jnR+964dIwULhg24MlTqv54mCPCzRj97v24K2QHTOm7 tnra8VeAZAE1EKFf0fw2Rukz9zK5MofVovnzUYYHJ7eXRiaGnjiPNA5WGHTL1AcHnvMN slGrDQwm7t8OIqLCeOpOmtvhy2CGUFeYEnvByxII8tMYmIUrC/VEmrRUtPG8JhCkua+A vd2juWNrgVX34kM6o6RVzodWo30dniwBR8LnWoojvIeiO8fXxYpWJtACrTDFmBR36O53 0hDQ==
X-Gm-Message-State: AEkoouvWmLF8+aa9/rxUNYziC+b9V/NJpzJNjtHP3s0qutuFxtqAxnQVIIUJ9zSYzA3f/+YJ0kx3mmyaxerRYg==
X-Received: by 10.176.80.47 with SMTP id b44mr4919957uaa.135.1470926294993; Thu, 11 Aug 2016 07:38:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Thu, 11 Aug 2016 07:38:13 -0700 (PDT)
In-Reply-To: <3a6fcf51-b808-e2aa-0548-e2ac705ee6bd@ericsson.com>
References: <201608031942.u73Jg8ol039135@idle.juniper.net> <5a49581e-71ef-4be9-1e51-62213901a887@cisco.com> <0066A47E-240F-4B6B-920B-98B064CE1E60@tail-f.com>   <05ea80f8-665b-d9b7-53db-207fc862409e@cisco.com> <5d8503f67066406a992738b766556247@EMEAWP-EXMB11.corp.brocade.com>  <357980ab80a64bbba5d6778fdf2160f8@EMEAWP-EXMB11.corp.brocade.com> <49054fe2-b1d1-ba18-a0a0-ea799e8947ef@cisco.com>   <57AC713E.8080006@transpacket.com> <3a6fcf51-b808-e2aa-0548-e2ac705ee6bd@ericsson.com>
From: Andy Bierman 
Date: Thu, 11 Aug 2016 07:38:13 -0700
Message-ID: 
To: Balazs Lengyel 
Content-Type: multipart/alternative; boundary=94eb2c18f30a4de2570539ccb738
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Aug 2016 14:38:32 -0000

--94eb2c18f30a4de2570539ccb738
Content-Type: text/plain; charset=UTF-8

On Thu, Aug 11, 2016 at 7:34 AM, Balazs Lengyel  wrote:

> As I remember the discussion was started because netconf
> default-operation=none  works in an unstable way on NP-containers.
>
> The RFCs allows the sequence which some implementations do use:
>
>    - edit-config operation=create empty NP-container
>    - server deletes  the empty NP-container
>    - client uses edit-config default-operation=none on NP-container with
>    operation=create to create a child node of the NP-container
>    - server rejects the edit-config as the NP-container does not exist,
>    although the user explicitly created it.
>
> This makes default-operation=none unusable. This is a MAJOR problem for
> us, so we need a solution for this BUG.
>

This is not a bug.

You can place an nc:operation="merge" attribute in your edit request and
make it work.
In fact, default-operation="none" cannot possibly do anything unless you
put the
nc:operation attribute in the payload at the proper node.





> regards Balazs
>

Andy



>
> On 2016-08-11 14:36, Vladimir Vassilev wrote:
>
> On 08/11/2016 10:00 AM, Ladislav Lhotka wrote:
>
> I'd suggest to wait for Martin, hopefully he isn't shipwrecked on a
> deserted island. Lada
>
> +1
>
> Because Martin knows why the following text was introduced between rev. 01
> and rev. 02  in 6.4.1 Xpath Context:
>
>    If a node that exists in the accessible tree has a non-presence
>    container as a child, then the non-presence container also exists in
>    the tree.
>
> I can't find nothing relevant to the change on the mailing list and the
> minutes in that time period, or the issue list.
>
> IMO the solution is to accept that both presence and non-presence
> containers are explicitly created and deleted. This would allow the
> following patch to rfc6020.txt as a starting point and yield this
> discussion pointless. In the same time it would fix the conflict with NACM
> in the cases when non-presence container are used to organize access rights
> which is often the only sane way to do it.
>
> Incremental editing of configuration trees is another feature e.g. you
> would hate operating system that does not allow you the creation of empty
> directories or automatically creates them for you just because they do not
> contain a file. And we accept to live with the overhead of empty
> directories for various reasons ... like access control etc. In the end
> this is what has started the entire problem.
>
> 567,569d566
> <    o  A container node without a "presence" statement, which has at
> <       least one mandatory node as a child.
> <
> 2875,2877c2872
> <    and to keep these nodes together.  The "scrambling" node itself has
> <    no meaning, so removing the node when it becomes empty relieves the
> <    user from performing this task.
> ---
> >    and to keep these nodes together.
> 2882,2883c2877
> <    organizing related configuration.  These containers are explicitly
> <    created and deleted.
> ---
> >    organizing related configuration.
> 3118,3124d3111
> <    A NETCONF server that replies to a  or  request MAY
> <    choose not to send a container element if the container node does not
> <    have the "presence" statement and no child nodes exist. Thus, a
> <    client that receives an  for a  or 
> <    request, must be prepared to handle the case that a container node
> <    without a "presence" statement is not present in the XML.
> <
> 3131,3133d3117
> <    If a container does not have a "presence" statement and the last
> <    child node is deleted, the NETCONF server MAY delete the container.
> <
> 3235,3236c3219
> <    depends on the leaf's closest ancestor node in the schema tree that
> <    is not a non-presence container:
> ---
> >    depends on the leaf's closest ancestor node in the schema tree:
> 3321,3322c3304,3305
> <    the type of the leaf's closest ancestor node in the schema tree that
> <    is not a non-presence container (see Section 7.5.1):
> ---
> >    the type of the leaf's closest ancestor node in the schema tree
> >    (see Section 7.5.1):
> 3509,3510c3492
> <    or list's closest ancestor node in the schema tree that is not a non-
> <    presence container (see Section 7.5.1):
> ---
> >    or list's closest ancestor node in the schema tree (see Section
> 7.5.1):
> 4385,4386c4367
> <    closest ancestor node in the schema tree which is not a non-presence
> <    container (see Section 7.5.1):
> ---
> >    closest ancestor node in the schema tree (see Section 7.5.1):
>
> Vladimir
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>
> --
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
>
>

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




On Thu, Aug 11, 2016 at 7:34 AM, Balazs Lengyel <<=
a href=3D"mailto:balazs.lengyel@ericsson.com" target=3D"_blank">balazs.leng=
yel@ericsson.com> wrote:

 =20
   =20
 =20
  

    
As I remember the discussion was started because netconf
      default-operation=3Dnone=C2=A0 works in an unstable way on NP-contain=
ers.

    
The RFCs allows the sequence which some implementations do use:

    
    
      
  • edit-config operation=3Dcreate empty NP-container
    • 
      
  • server deletes=C2=A0 the empty NP-container
    • 
      
  • client uses edit-config default-operation=3Dnone on NP-container
        with operation=3Dcreate to create a child node of the NP-container<=
/li>
      
  • server rejects the edit-config as the NP-container does not
        exist, although the user explicitly created it.
    • 
    

    
This makes default-operation=3Dnone unusable. This is a MAJOR
      problem for us, so we need a solution for this BUG.

This is not a bug.

Yo=
u can place an nc:operation=3D"merge" attribute in your edit requ=
est and make it work.
In fact, default-operation=3D"none&quo=
t; cannot possibly do anything unless you put the
nc:operation at=
tribute in the payload at the proper node.



=C2=A0

    

    
regards Balazs

Andy

=C2=A0

    

    

    
On 2016-08-11 14:36, Vladimir Vassilev
      wrote:

    

    
On
      08/11/2016 10:00 AM, Ladislav Lhotka wrote:
      

      
I'd suggest to wait for Martin, hopeful=
ly
        he isn't shipwrecked on a deserted island. Lada
        

      

      +1
      

      

      Because Martin knows why the following text was introduced between
      rev. 01 and rev. 02=C2=A0 in 6.4.1 Xpath Context:
      

      

      =C2=A0=C2=A0 If a node that exists in the accessible tree has a non-p=
resence
      

      =C2=A0=C2=A0 container as a child, then the non-presence container al=
so
      exists in
      

      =C2=A0=C2=A0 the tree.
      

      

      I can't find nothing relevant to the change on the mailing list
      and the minutes in that time period, or the issue list.
      

      

      IMO the solution is to accept that both presence and non-presence
      containers are explicitly created and deleted. This would allow
      the following patch to rfc6020.txt as a starting point and yield
      this discussion pointless. In the same time it would fix the
      conflict with NACM in the cases when non-presence container are
      used to organize access rights which is often the only sane way to
      do it.
      

      

      Incremental editing of configuration trees is another feature e.g.
      you would hate operating system that does not allow you the
      creation of empty directories or automatically creates them for
      you just because they do not contain a file. And we accept to live
      with the overhead of empty directories for various reasons ...
      like access control etc. In the end this is what has started the
      entire problem.
      

      

      567,569d566
      

      <=C2=A0=C2=A0=C2=A0 o=C2=A0 A container node without a "prese=
nce" statement, which
      has at
      

      <=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 least one mandatory node as =
a child.
      

      <
      

      2875,2877c2872
      

      <=C2=A0=C2=A0=C2=A0 and to keep these nodes together.=C2=A0 The &q=
uot;scrambling" node
      itself has
      

      <=C2=A0=C2=A0=C2=A0 no meaning, so removing the node when it becom=
es empty
      relieves the
      

      <=C2=A0=C2=A0=C2=A0 user from performing this task.
      

      ---
      

      >=C2=A0=C2=A0=C2=A0 and to keep these nodes together.
      

      2882,2883c2877
      

      <=C2=A0=C2=A0=C2=A0 organizing related configuration.=C2=A0 These =
containers are
      explicitly
      

      <=C2=A0=C2=A0=C2=A0 created and deleted.
      

      ---
      

      >=C2=A0=C2=A0=C2=A0 organizing related configuration.
      

      3118,3124d3111
      

      <=C2=A0=C2=A0=C2=A0 A NETCONF server that replies to a <get>=
 or
      <get-config> request MAY
      

      <=C2=A0=C2=A0=C2=A0 choose not to send a container element if the =
container
      node does not
      

      <=C2=A0=C2=A0=C2=A0 have the "presence" statement and no=
 child nodes exist.
      Thus, a
      

      <=C2=A0=C2=A0=C2=A0 client that receives an <rpc-reply> for =
a
      <get> or <get-config>
      

      <=C2=A0=C2=A0=C2=A0 request, must be prepared to handle the case t=
hat a
      container node
      

      <=C2=A0=C2=A0=C2=A0 without a "presence" statement is no=
t present in the XML.
      

      <
      

      3131,3133d3117
      

      <=C2=A0=C2=A0=C2=A0 If a container does not have a "presence&=
quot; statement and
      the last
      

      <=C2=A0=C2=A0=C2=A0 child node is deleted, the NETCONF server MAY =
delete the
      container.
      

      <
      

      3235,3236c3219
      

      <=C2=A0=C2=A0=C2=A0 depends on the leaf's closest ancestor nod=
e in the schema
      tree that
      

      <=C2=A0=C2=A0=C2=A0 is not a non-presence container:
      

      ---
      

      >=C2=A0=C2=A0=C2=A0 depends on the leaf's closest ancestor nod=
e in the schema
      tree:
      

      3321,3322c3304,3305
      

      <=C2=A0=C2=A0=C2=A0 the type of the leaf's closest ancestor no=
de in the schema
      tree that
      

      <=C2=A0=C2=A0=C2=A0 is not a non-presence container (see Section 7=
.5.1):
      

      ---
      

      >=C2=A0=C2=A0=C2=A0 the type of the leaf's closest ancestor no=
de in the schema
      tree
      

      >=C2=A0=C2=A0=C2=A0 (see Section 7.5.1):
      

      3509,3510c3492
      

      <=C2=A0=C2=A0=C2=A0 or list's closest ancestor node in the sch=
ema tree that is
      not a non-
      

      <=C2=A0=C2=A0=C2=A0 presence container (see Section 7.5.1):
      

      ---
      

      >=C2=A0=C2=A0=C2=A0 or list's closest ancestor node in the sch=
ema tree (see
      Section 7.5.1):
      

      4385,4386c4367
      

      <=C2=A0=C2=A0=C2=A0 closest ancestor node in the schema tree which=
 is not a
      non-presence
      

      <=C2=A0=C2=A0=C2=A0 container (see Section 7.5.1):
      

      ---
      

      >=C2=A0=C2=A0=C2=A0 closest ancestor node in the schema tree (see =
Section
      7.5.1):
      

      

      Vladimir
      

      

      _______________________________________________
      

      Netconf mailing list
      

      Netconf@ietf.or=
g
      

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

      

    

    

    
--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com=20


  






--94eb2c18f30a4de2570539ccb738--


From nobody Thu Aug 11 08:07:42 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 962FB12D5C4 for ; Thu, 11 Aug 2016 08:07:39 -0700 (PDT)
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 autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rLBR93NUEmu for ; Thu, 11 Aug 2016 08:07:35 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 819A812D74C for ; Thu, 11 Aug 2016 08:07:18 -0700 (PDT)
X-AuditID: c1b4fb30-ea88e980000009f9-ed-57ac94a405e8
Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by  (Symantec Mail Security) with SMTP id AA.47.02553.4A49CA75; Thu, 11 Aug 2016 17:07:16 +0200 (CEST)
Received: from [159.107.197.188] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.3.301.0; Thu, 11 Aug 2016 17:07:14 +0200
To: Andy Bierman 
References: <201608031942.u73Jg8ol039135@idle.juniper.net> <5a49581e-71ef-4be9-1e51-62213901a887@cisco.com> <0066A47E-240F-4B6B-920B-98B064CE1E60@tail-f.com>   <05ea80f8-665b-d9b7-53db-207fc862409e@cisco.com> <5d8503f67066406a992738b766556247@EMEAWP-EXMB11.corp.brocade.com>  <357980ab80a64bbba5d6778fdf2160f8@EMEAWP-EXMB11.corp.brocade.com> <49054fe2-b1d1-ba18-a0a0-ea799e8947ef@cisco.com>   <57AC713E.8080006@transpacket.com> <3a6fcf51-b808-e2aa-0548-e2ac705ee6bd@ericsson.com> 
From: Balazs Lengyel 
Message-ID: <14005cdf-3f72-b04d-365a-024ba7e13d38@ericsson.com>
Date: Thu, 11 Aug 2016 17:07:14 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM2J7uO6SKWvCDd40q1g8ODKL3eLCqrls FlM33Wa1ODX/G6sDi8eSJT+ZPDZdvsPocfXDSRaPlv6LLAEsUVw2Kak5mWWpRfp2CVwZW5oO sBacS67o6p7P1MD4zqaLkZNDQsBE4kL/PpYuRi4OIYH1jBIfV/QzQjhrGSWe7zrCAlIlLBAu 8fbpGjYQW0RAVeLC3InMEEXb2SQ6v7xjAkkwC+RLnDr0DqyBTcBIYmr/eTCbV8BeYumnI2A1 LEDN1x9+Zu1i5OAQFYiRWN+XAFEiKHFy5hOwck6BQIn3u1dCjdSQaJ0zlx3Clpdo3jqbGcQW Aoo/vPCXdQKjwCwk7bOQtMxC0rKAkXkVo2hxanFSbrqRkV5qUWZycXF+nl5easkmRmAAH9zy 22AH48vnjocYBTgYlXh4F2SvDhdiTSwrrsw9xCjBwawkwps2eU24EG9KYmVValF+fFFpTmrx IUZpDhYlcV7/l4rhQgLpiSWp2ampBalFMFkmDk6pBsZm3Y5/IfMf7VA1KrYwmDfxh7vpVDt5 1c1FM7cL3VU8Lm//d9pxkf9Wv5S+GzXNm9v4r2DOJo5f1989NXJ25bZ+J/r/f7/fjFk8Oq+f ae1sMP2fvbF0J2O+kMLeC5se5hatM3JfH/Q/RnaJ+yetqSIHvp/WW2Y/9WROqfH1UJ1/tjd7 GdZ93L9YiaU4I9FQi7moOBEA20VDVVwCAAA=
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Aug 2016 15:07:39 -0000


  
    
  
  
    
Andy you can find the very first mail of the thread at

https://www.ietf.org/mail-archive/web/netconf/current/msg11438.html

    
Also the same example with a bit more detail:

    
container npCont {
   leaf foo {}
}

1st request:
  <edit-config>
    <config>
      <npCont/>
    </config>
  </edit-config>

Result=OK
The server creates npCont and later removes it (or maybe it does not even create it as it is empty)

2nd request:
  <edit-config>
    <default-operation>none</default-operation>
    <config>
      <npCont>
        <foo operation="create">27</foo>
      </npCont>
    </config>
  </edit-config>

Result=Error as npCont does not exist.



    
This makes default-operation=none unusable. This is a MAJOR
      problem for us, so we need a solution for this BUG. 

    

    
Saying: "don't use none because it is buggy, use merge instead"
      is not nice. Also as I have described in earlier mails using
      default-operation=merge can lead to accidentally creating
      data-nodes. So the BUG around default-operation=none was the
      starting point and is still a major issue.

    

    
regards Balazs

    

    
On 2016-08-11 16:38, Andy Bierman
      wrote:

    

    

      
      


        


          
On Thu, Aug 11, 2016 at 7:34 AM,
            Balazs Lengyel <balazs.lengyel@ericsson.com>
            wrote:

            

              

                
As I remember the discussion was started because
                  netconf default-operation=none  works in an unstable
                  way on NP-containers.

                
The RFCs allows the sequence which some
                  implementations do use:

                
    
                  
  • edit-config operation=create empty NP-container
    • 
                  
  • server deletes  the empty NP-container
    • 
                  
  • client uses edit-config default-operation=none on
                    NP-container with operation=create to create a child
                    node of the NP-container
    • 
                  
  • server rejects the edit-config as the NP-container
                    does not exist, although the user explicitly created
                    it.
    • 
                

                
This makes default-operation=none unusable. This is a
                  MAJOR problem for us, so we need a solution for this
                  BUG.

                

              

            

            


            

            
This is not a bug.

            


            

            
You can place an nc:operation="merge" attribute in your
              edit request and make it work.

            
In fact, default-operation="none" cannot possibly do
              anything unless you put the

            
nc:operation attribute in the payload at the proper
              node.

            


            

            


            

            


            

            
 

            

              

                
 

                
regards Balazs

                

              

            

            


            

            
Andy

            


            

            
 

            

              

                
 

                

                
On 2016-08-11 14:36, Vladimir Vassilev wrote:

                

                
On 08/11/2016 10:00 AM, Ladislav
                  Lhotka wrote: 

                  
I'd suggest to wait for
                    Martin, hopefully he isn't shipwrecked on a deserted
                    island. Lada 

                  

                  +1 

                  

                  Because Martin knows why the following text was
                  introduced between rev. 01 and rev. 02  in 6.4.1 Xpath
                  Context: 

                  

                     If a node that exists in the accessible tree has a
                  non-presence 

                     container as a child, then the non-presence
                  container also exists in 

                     the tree. 

                  

                  I can't find nothing relevant to the change on the
                  mailing list and the minutes in that time period, or
                  the issue list. 

                  

                  IMO the solution is to accept that both presence and
                  non-presence containers are explicitly created and
                  deleted. This would allow the following patch to
                  rfc6020.txt as a starting point and yield this
                  discussion pointless. In the same time it would fix
                  the conflict with NACM in the cases when non-presence
                  container are used to organize access rights which is
                  often the only sane way to do it. 

                  

                  Incremental editing of configuration trees is another
                  feature e.g. you would hate operating system that does
                  not allow you the creation of empty directories or
                  automatically creates them for you just because they
                  do not contain a file. And we accept to live with the
                  overhead of empty directories for various reasons ...
                  like access control etc. In the end this is what has
                  started the entire problem. 

                  

                  567,569d566 

                  <    o  A container node without a "presence"
                  statement, which has at 

                  <       least one mandatory node as a child. 

                  < 

                  2875,2877c2872 

                  <    and to keep these nodes together.  The
                  "scrambling" node itself has 

                  <    no meaning, so removing the node when it
                  becomes empty relieves the 

                  <    user from performing this task. 

                  --- 

                  >    and to keep these nodes together. 

                  2882,2883c2877 

                  <    organizing related configuration.  These
                  containers are explicitly 

                  <    created and deleted. 

                  --- 

                  >    organizing related configuration. 

                  3118,3124d3111 

                  <    A NETCONF server that replies to a <get>
                  or <get-config> request MAY 

                  <    choose not to send a container element if the
                  container node does not 

                  <    have the "presence" statement and no child
                  nodes exist. Thus, a 

                  <    client that receives an <rpc-reply> for
                  a <get> or <get-config> 

                  <    request, must be prepared to handle the case
                  that a container node 

                  <    without a "presence" statement is not present
                  in the XML. 

                  < 

                  3131,3133d3117 

                  <    If a container does not have a "presence"
                  statement and the last 

                  <    child node is deleted, the NETCONF server MAY
                  delete the container. 

                  < 

                  3235,3236c3219 

                  <    depends on the leaf's closest ancestor node in
                  the schema tree that 

                  <    is not a non-presence container: 

                  --- 

                  >    depends on the leaf's closest ancestor node in
                  the schema tree: 

                  3321,3322c3304,3305 

                  <    the type of the leaf's closest ancestor node
                  in the schema tree that 

                  <    is not a non-presence container (see Section
                  7.5.1): 

                  --- 

                  >    the type of the leaf's closest ancestor node
                  in the schema tree 

                  >    (see Section 7.5.1): 

                  3509,3510c3492 

                  <    or list's closest ancestor node in the schema
                  tree that is not a non- 

                  <    presence container (see Section 7.5.1): 

                  --- 

                  >    or list's closest ancestor node in the schema
                  tree (see Section 7.5.1): 

                  4385,4386c4367 

                  <    closest ancestor node in the schema tree which
                  is not a non-presence 

                  <    container (see Section 7.5.1): 

                  --- 

                  >    closest ancestor node in the schema tree (see
                  Section 7.5.1): 

                  

                  Vladimir 

                  

                  _______________________________________________ 

                  Netconf mailing list 

                  Netconf@ietf.org
                  

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

                  

                   

                 

                    
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com 


                  

            

          

          

        

      

    

    

    
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com 


  



From nobody Thu Aug 11 08:22:18 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 140A412D7A8 for ; Thu, 11 Aug 2016 08:22:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpBK6kGKXu_4 for ; Thu, 11 Aug 2016 08:22:16 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59D7712D792 for ; Thu, 11 Aug 2016 08:22:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 2B3D914225AB; Thu, 11 Aug 2016 17:22:13 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 4f3pkEuZpJ3R; Thu, 11 Aug 2016 17:22:13 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id F3C7A14225AA; Thu, 11 Aug 2016 17:22:12 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id lEud5QDlfrSQ; Thu, 11 Aug 2016 17:22:12 +0200 (CEST)
Received: from [192.168.209.141] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id C9EAD14225A7; Thu, 11 Aug 2016 17:22:12 +0200 (CEST)
Message-ID: <57AC9823.90404@transpacket.com>
Date: Thu, 11 Aug 2016 17:22:11 +0200
From: Vladimir Vassilev 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0
MIME-Version: 1.0
To: Balazs Lengyel ,  Ladislav Lhotka , Andy Bierman 
References: <201608031942.u73Jg8ol039135@idle.juniper.net> <5a49581e-71ef-4be9-1e51-62213901a887@cisco.com> <0066A47E-240F-4B6B-920B-98B064CE1E60@tail-f.com>   <05ea80f8-665b-d9b7-53db-207fc862409e@cisco.com> <5d8503f67066406a992738b766556247@EMEAWP-EXMB11.corp.brocade.com>  <357980ab80a64bbba5d6778fdf2160f8@EMEAWP-EXMB11.corp.brocade.com> <49054fe2-b1d1-ba18-a0a0-ea799e8947ef@cisco.com>   <57AC713E.8080006@transpacket.com> <3a6fcf51-b808-e2aa-0548-e2ac705ee6bd@ericsson.com>
In-Reply-To: <3a6fcf51-b808-e2aa-0548-e2ac705ee6bd@ericsson.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Aug 2016 15:22:18 -0000

On 08/11/2016 04:34 PM, Balazs Lengyel wrote:
>
> As I remember the discussion was started because netconf 
> default-operation=none  works in an unstable way on NP-containers.
>
> The RFCs allows the sequence which some implementations do use:
>
>   * edit-config operation=create empty NP-container
>   * server deletes  the empty NP-container
>   * client uses edit-config default-operation=none on NP-container
>     with operation=create to create a child node of the NP-container
>   * server rejects the edit-config as the NP-container does not exist,
>     although the user explicitly created it.
>
> This makes default-operation=none unusable. This is a MAJOR problem 
> for us, so we need a solution for this BUG.
>
Right. Do you agree the patch I propose which removes the 
differentiation between presence and non-presence containers in terms of 
the requirement to explicitly create and delete them is a better 
solution then building on top of the problem simply to save bandwidth in 
case sloppy users create empty non-presence containers not used as 
instance identifier targets in NACM? Can someone explain why this is bad 
and instead we need kilobytes of clarifications and breaking backwards 
compatibility of the validation statements, NACM, iterative 
configuration editing etc. in YANG 1.1?

> regards Balazs
>
>
> On 2016-08-11 14:36, Vladimir Vassilev wrote:
>> On 08/11/2016 10:00 AM, Ladislav Lhotka wrote:
>>> I'd suggest to wait for Martin, hopefully he isn't shipwrecked on a 
>>> deserted island. Lada
>> +1
>>
>> Because Martin knows why the following text was introduced between 
>> rev. 01 and rev. 02  in 6.4.1 Xpath Context:
>>
>>    If a node that exists in the accessible tree has a non-presence
>>    container as a child, then the non-presence container also exists in
>>    the tree.
>>
>> I can't find nothing relevant to the change on the mailing list and 
>> the minutes in that time period, or the issue list.
>>
>> IMO the solution is to accept that both presence and non-presence 
>> containers are explicitly created and deleted. This would allow the 
>> following patch to rfc6020.txt as a starting point and yield this 
>> discussion pointless. In the same time it would fix the conflict with 
>> NACM in the cases when non-presence container are used to organize 
>> access rights which is often the only sane way to do it.
>>
>> Incremental editing of configuration trees is another feature e.g. 
>> you would hate operating system that does not allow you the creation 
>> of empty directories or automatically creates them for you just 
>> because they do not contain a file. And we accept to live with the 
>> overhead of empty directories for various reasons ... like access 
>> control etc. In the end this is what has started the entire problem.
>>
>> 567,569d566
>> <    o  A container node without a "presence" statement, which has at
>> <       least one mandatory node as a child.
>> <
>> 2875,2877c2872
>> <    and to keep these nodes together.  The "scrambling" node itself has
>> <    no meaning, so removing the node when it becomes empty relieves the
>> <    user from performing this task.
>> ---
>> >    and to keep these nodes together.
>> 2882,2883c2877
>> <    organizing related configuration.  These containers are explicitly
>> <    created and deleted.
>> ---
>> >    organizing related configuration.
>> 3118,3124d3111
>> <    A NETCONF server that replies to a  or  request 
>> MAY
>> <    choose not to send a container element if the container node 
>> does not
>> <    have the "presence" statement and no child nodes exist. Thus, a
>> <    client that receives an  for a  or 
>> <    request, must be prepared to handle the case that a container node
>> <    without a "presence" statement is not present in the XML.
>> <
>> 3131,3133d3117
>> <    If a container does not have a "presence" statement and the last
>> <    child node is deleted, the NETCONF server MAY delete the container.
>> <
>> 3235,3236c3219
>> <    depends on the leaf's closest ancestor node in the schema tree that
>> <    is not a non-presence container:
>> ---
>> >    depends on the leaf's closest ancestor node in the schema tree:
>> 3321,3322c3304,3305
>> <    the type of the leaf's closest ancestor node in the schema tree 
>> that
>> <    is not a non-presence container (see Section 7.5.1):
>> ---
>> >    the type of the leaf's closest ancestor node in the schema tree
>> >    (see Section 7.5.1):
>> 3509,3510c3492
>> <    or list's closest ancestor node in the schema tree that is not a 
>> non-
>> <    presence container (see Section 7.5.1):
>> ---
>> >    or list's closest ancestor node in the schema tree (see Section 
>> 7.5.1):
>> 4385,4386c4367
>> <    closest ancestor node in the schema tree which is not a 
>> non-presence
>> <    container (see Section 7.5.1):
>> ---
>> >    closest ancestor node in the schema tree (see Section 7.5.1):
>>
>> Vladimir
>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>>
>
> -- 
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909              email:Balazs.Lengyel@ericsson.com  


From nobody Thu Aug 11 08:23:38 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBF312D0A6 for ; Thu, 11 Aug 2016 08:23:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.447
X-Spam-Level: 
X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZO0ev3ZruSA for ; Thu, 11 Aug 2016 08:23:30 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4485812B008 for ; Thu, 11 Aug 2016 08:15:38 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 867C5129A; Thu, 11 Aug 2016 17:15:36 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id TeZ2wdndnaui; Thu, 11 Aug 2016 17:15:32 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 11 Aug 2016 17:15:35 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 926F6200A3; Thu, 11 Aug 2016 17:15:35 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id jrLlkCg90lA5; Thu, 11 Aug 2016 17:15:34 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B68B92009B; Thu, 11 Aug 2016 17:15:34 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 211D63C17F1B; Thu, 11 Aug 2016 17:15:34 +0200 (CEST)
Date: Thu, 11 Aug 2016 17:15:33 +0200
From: Juergen Schoenwaelder 
To: Balazs Lengyel 
Message-ID: <20160811151533.GB4102@elstar.local>
Mail-Followup-To: Balazs Lengyel , Andy Bierman , Netconf 
References: <5d8503f67066406a992738b766556247@EMEAWP-EXMB11.corp.brocade.com>  <357980ab80a64bbba5d6778fdf2160f8@EMEAWP-EXMB11.corp.brocade.com> <49054fe2-b1d1-ba18-a0a0-ea799e8947ef@cisco.com>   <57AC713E.8080006@transpacket.com> <3a6fcf51-b808-e2aa-0548-e2ac705ee6bd@ericsson.com>  <14005cdf-3f72-b04d-365a-024ba7e13d38@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <14005cdf-3f72-b04d-365a-024ba7e13d38@ericsson.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Aug 2016 15:23:31 -0000

On Thu, Aug 11, 2016 at 05:07:14PM +0200, Balazs Lengyel wrote:
> 
>  2nd request:
>    
>      none
>      
>        
>          27
>        
>      
>    
> 
>  Result=Error as npCont does not exist.
> 
> 
>    This makes default-operation=none unusable. This is a MAJOR problem for
>    us, so we need a solution for this BUG.
> 
>    Saying: "don't use none because it is buggy, use merge instead" is not
>    nice. Also as I have described in earlier mails using
>    default-operation=merge can lead to accidentally creating data-nodes. So
>    the BUG around default-operation=none was the starting point and is still
>    a major issue.
>

If you add operation="merge" on npCont, does this not work around the
problem while being robust against accidentally creating data nodes?

/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 Aug 11 08:33:33 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99DB612D0DD for ; Thu, 11 Aug 2016 08:33:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.247
X-Spam-Level: 
X-Spam-Status: No, score=-8.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.247] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WUuDs_8lmix for ; Thu, 11 Aug 2016 08:33:30 -0700 (PDT)
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 48BCC12D787 for ; Thu, 11 Aug 2016 08:25:25 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:a0b8:585b:a5a9:4ab8] (unknown [IPv6:2001:718:1a02:1:a0b8:585b:a5a9:4ab8]) by mail.nic.cz (Postfix) with ESMTPSA id C7FF461117; Thu, 11 Aug 2016 17:25:23 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1470929123; bh=W9sfdbZmUj/8ZMWTxbjrtrWh0fukQTji6oqMSuoRD9U=; h=From:Date:To; b=E8WQDzilgrIhPGjf6b1LLegJS8qe4cQs+YzvIvAxqOgJq0KCxieKmIl+rmjOKr9Rw ebqTY78WRElESypIOdWSdfNwIeejm8nFmyJiPoml3LLyz1mdWuvf/uwIc5BqNZIhHR vkN/D3w4u4Iqssvg+vYG/4wxF9cW1AZUxP34OJ4M=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <3a6fcf51-b808-e2aa-0548-e2ac705ee6bd@ericsson.com>
Date: Thu, 11 Aug 2016 17:25:24 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <201608031942.u73Jg8ol039135@idle.juniper.net> <5a49581e-71ef-4be9-1e51-62213901a887@cisco.com> <0066A47E-240F-4B6B-920B-98B064CE1E60@tail-f.com>   <05ea80f8-665b-d9b7-53db-207fc862409e@cisco.com> <5d8503f67066406a992738b766556247@EMEAWP-EXMB11.corp.brocade.com>  <357980ab80a64bbba5d6778fdf2160f8@EMEAWP-EXMB11.corp.brocade.com> <49054fe2-b1d1-ba18-a0a0-ea799e8947ef@cisco.com>   <57AC713E.8080006@transpacket.com> <3a6fcf51-b808-e2aa-0548-e2ac705ee6bd@ericsson.com>
To: Balazs Lengyel 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Aug 2016 15:33:31 -0000

> On 11 Aug 2016, at 16:34, Balazs Lengyel  =
wrote:
>=20
> As I remember the discussion was started because netconf =
default-operation=3Dnone  works in an unstable way on NP-containers.
>=20
> The RFCs allows the sequence which some implementations do use:
>=20
> 	=95 edit-config operation=3Dcreate empty NP-container
> 	=95 server deletes  the empty NP-container
> 	=95 client uses edit-config default-operation=3Dnone on =
NP-container with operation=3Dcreate to create a child node of the =
NP-container
> 	=95 server rejects the edit-config as the NP-container does not =
exist, although the user explicitly created it.

IMO this should succeed, and it could also succeed even without the =
first two steps.

What is the result if the NP-container happens to contain another leaf =
with a default value specified in the data model, but this leaf hasn't =
been explicitly configured?

Lada

> This makes default-operation=3Dnone unusable. This is a MAJOR problem =
for us, so we need a solution for this BUG.
> regards Balazs
>=20
> On 2016-08-11 14:36, Vladimir Vassilev wrote:
>> On 08/11/2016 10:00 AM, Ladislav Lhotka wrote:=20
>>> I'd suggest to wait for Martin, hopefully he isn't shipwrecked on a =
deserted island. Lada=20
>> +1=20
>>=20
>> Because Martin knows why the following text was introduced between =
rev. 01 and rev. 02  in 6.4.1 Xpath Context:=20
>>=20
>>    If a node that exists in the accessible tree has a non-presence=20
>>    container as a child, then the non-presence container also exists =
in=20
>>    the tree.=20
>>=20
>> I can't find nothing relevant to the change on the mailing list and =
the minutes in that time period, or the issue list.=20
>>=20
>> IMO the solution is to accept that both presence and non-presence =
containers are explicitly created and deleted. This would allow the =
following patch to rfc6020.txt as a starting point and yield this =
discussion pointless. In the same time it would fix the conflict with =
NACM in the cases when non-presence container are used to organize =
access rights which is often the only sane way to do it.=20
>>=20
>> Incremental editing of configuration trees is another feature e.g. =
you would hate operating system that does not allow you the creation of =
empty directories or automatically creates them for you just because =
they do not contain a file. And we accept to live with the overhead of =
empty directories for various reasons ... like access control etc. In =
the end this is what has started the entire problem.=20
>>=20
>> 567,569d566=20
>> <    o  A container node without a "presence" statement, which has at=20=

>> <       least one mandatory node as a child.=20
>> <=20
>> 2875,2877c2872=20
>> <    and to keep these nodes together.  The "scrambling" node itself =
has=20
>> <    no meaning, so removing the node when it becomes empty relieves =
the=20
>> <    user from performing this task.=20
>> ---=20
>> >    and to keep these nodes together.=20
>> 2882,2883c2877=20
>> <    organizing related configuration.  These containers are =
explicitly=20
>> <    created and deleted.=20
>> ---=20
>> >    organizing related configuration.=20
>> 3118,3124d3111=20
>> <    A NETCONF server that replies to a  or  request =
MAY=20
>> <    choose not to send a container element if the container node =
does not=20
>> <    have the "presence" statement and no child nodes exist. Thus, a=20=

>> <    client that receives an  for a  or =20=

>> <    request, must be prepared to handle the case that a container =
node=20
>> <    without a "presence" statement is not present in the XML.=20
>> <=20
>> 3131,3133d3117=20
>> <    If a container does not have a "presence" statement and the last=20=

>> <    child node is deleted, the NETCONF server MAY delete the =
container.=20
>> <=20
>> 3235,3236c3219=20
>> <    depends on the leaf's closest ancestor node in the schema tree =
that=20
>> <    is not a non-presence container:=20
>> ---=20
>> >    depends on the leaf's closest ancestor node in the schema tree:=20=

>> 3321,3322c3304,3305=20
>> <    the type of the leaf's closest ancestor node in the schema tree =
that=20
>> <    is not a non-presence container (see Section 7.5.1):=20
>> ---=20
>> >    the type of the leaf's closest ancestor node in the schema tree=20=

>> >    (see Section 7.5.1):=20
>> 3509,3510c3492=20
>> <    or list's closest ancestor node in the schema tree that is not a =
non-=20
>> <    presence container (see Section 7.5.1):=20
>> ---=20
>> >    or list's closest ancestor node in the schema tree (see Section =
7.5.1):=20
>> 4385,4386c4367=20
>> <    closest ancestor node in the schema tree which is not a =
non-presence=20
>> <    container (see Section 7.5.1):=20
>> ---=20
>> >    closest ancestor node in the schema tree (see Section 7.5.1):=20
>>=20
>> Vladimir=20
>>=20
>> _______________________________________________=20
>> Netconf mailing list=20
>> Netconf@ietf.org=20
>> https://www.ietf.org/mailman/listinfo/netconf=20
>>=20
>=20
> --=20
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909              email:=20
> Balazs.Lengyel@ericsson.com
> =20
>=20

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





From nobody Thu Aug 11 17:32:53 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 849ED12D74E for ; Thu, 11 Aug 2016 17:32:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9yzqReb9oDt for ; Thu, 11 Aug 2016 17:32:49 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0129.outbound.protection.outlook.com [104.47.42.129]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E630D12D66E for ; Thu, 11 Aug 2016 17:32:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9Dc4dt7vhPA4gARq4qCl/QWaZhc++CoqC2YweeVTS1s=; b=E0+UxQo3nbMYyDb+9csps+bSmruo+dDn31QqV14qyaCCrlZ4tooBzTUXX74VE6jleg9OLMe/Dn/Z9J36xe2PTTp0E5Kd6vvVtP8TqFSUxm9rP7iWjzZt3fElSze6OQsh0vpyJ+6V6W3j3sqrb9da+50PWxFh3c3pSzbFRDBFzbo=
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1452.namprd05.prod.outlook.com (10.160.149.13) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.8; Fri, 12 Aug 2016 00:32:46 +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.0557.009; Fri, 12 Aug 2016 00:32:46 +0000
From: Kent Watsen 
To: "netconf@ietf.org" 
Thread-Topic: [Netconf] zerotouch/12: How to commit config? Merge/replace?
Thread-Index: AQHR0lkNTjORHFXcL06wK5dz8frwDKAL/CeAgDh+L4A=
Date: Fri, 12 Aug 2016 00:32:45 +0000
Message-ID: <24A6B4F9-5BBC-4F11-8AF3-90658EB63D06@juniper.net>
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.18.0.160709
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.14]
x-ms-office365-filtering-correlation-id: ec1bed51-961c-46f4-98e8-08d3c2482e69
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1452; 6:OAQUpxkMysDeN2SJBdqTkatXi/8gj9Q1V/fGUliIG8CFaRJXEDxp+pw6xa3YGY+dShF0Gq7epsgazNZ8yu57a0SEK26EEVnax8DnLh1y6QhHt/QKGfQjGyII3FqBhoqA2uEXHarwM5/qp2+ZrXK4hpX0+4dj7o3AFIGgfCwusepOBAsRwZzZnkxW2Vz9FHHJoqX1DbBbHRYE7ZqKWrDkrL/pPt7yfrSmt1UpdQZPpQU1mqQu2kQ6W95RIasvCne7xuCLodmSQdUzdqzYm/QZOMWB2M1DMQmKUqSrkdIfjWjmaxelScDADTGYroSM6nIuDNFRp6VM7ey0EFlv6TpNSg==; 5:xcJ8VKMmPHpU5L5Bud8Stq9LdCxE+4AzGq9jokfHCrdvikLBAH2VWpDrnxHj24GjRZLNBg7WGWgtuOzB6Yjn4gg7SlIDjmLed2sHajb/rEg/JfgYTqqI/5vQ2R1vDreEbT/UEZ0k8OynIDJOMla1kQ==; 24:xfS9V4pB0Bsi4AbM98rfTEqQHQxDnK1yC2YzwiTxIK1lpkLMn7jPCiIqd9i7wJ5cHLf37/rdRTlS/7NFrkEtMMUbdTNMfDDCtDaESNqDjes=; 7:87Up9CDCtMvG+TN5aROXb0qGzL3C8W+2I5ZbsVtvKUSIn8TpviHp3bsnW3JbctTG4pe9DYVeCaX1eY1UKGTOh6gyM6cfVF6VKpVN/spb6E7HRR2oI85lw8SseGiLM0HqoFbKdzaTVEK4lyxWdLl2vRjhOGOS6PV01qwwEZhIAYNU6Y4fcXHweBuRPczBJTZtgxTPTDvdAbWbW9NuhzTo6ey1T/5h6CiS51EBjRTUF8TVrCefnyFk8Q1AxvguEh59
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1452;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(138986009662008)(788757137089)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040175)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:CY1PR0501MB1452; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1452; 
x-forefront-prvs: 003245E729
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(377454003)(199003)(51444003)(105586002)(189998001)(50986999)(87936001)(36756003)(2906002)(101416001)(2501003)(19300405004)(54356999)(76176999)(7736002)(4001350100001)(7846002)(2351001)(97736004)(107886002)(5002640100001)(68736007)(2900100001)(10400500002)(110136002)(19625215002)(2950100001)(450100001)(15975445007)(99286002)(11100500001)(92566002)(1730700003)(19580395003)(106356001)(3280700002)(83716003)(3660700001)(106116001)(16236675004)(66066001)(122556002)(5640700001)(6116002)(3846002)(33656002)(86362001)(8676002)(77096005)(19580405001)(82746002)(8936002)(83506001)(81156014)(81166006)(586003)(102836003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1452; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_24A6B4F95BBC4F118AF390658EB63D06junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Aug 2016 00:32:45.9716 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1452
Archived-At: 
Subject: Re: [Netconf] zerotouch/12: How to commit config? Merge/replace?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Aug 2016 00:32:51 -0000

--_000_24A6B4F95BBC4F118AF390658EB63D06junipernet_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

TGV04oCZcyBjbG9zZSBhbGwgdGhlIG9wZW4gaXNzdWVzIGZvciB0aGUgemVyb3RvdWNoIGRyYWZ0
LiAgU3RhcnRpbmcgd2l0aCBsb3ctaGFuZ2luZyBmcnVpdCBmaXJzdCBtYWtlcyBzZW5zZS4uLg0K
DQpGb3IgdGhpcyBwYXJ0aWN1bGFyIGlzc3VlLCBpdCBzZWVtcyB0byBtZSB0aGF0IHRoZSBzaW1w
bGVzdCBhbmQgZWFzaWVzdCBzb2x1dGlvbiBpcyB0byBqdXN0IHN1cHBvcnQgdGhlIOKAmG1lcmdl
4oCZIGFuZCDigJhyZXBsYWNl4oCZIG9wdGlvbnMgZm9yIG5vdyAobm8gZWRpdC1jb25maWcgb3Ig
eWFuZy1wYXRjaCkuDQoNClRob3VnaCBub3QgZGlzY3Vzc2VkIHByZXZpb3VzbHksIEkgYWxzbyBy
ZXBsYWNlZCB0aGUg4oCYZGVmYXVsdCByZXBsYWNl4oCZIHdpdGggYSDigJhtYW5kYXRvcnkgdHJ1
ZeKAmSwgYXMgdGhlcmUgdHJ1bHkgY2FuIGJlIG5vIHByZWZlcnJlZCBvcHRpb24gaGVyZSAoaXTi
gJlzIGEgY3VzdG9tZXItZHJpdmVuIGNob2ljZSkuDQoNClNvLCB0aGUgbmV0IHJlc3VsdCBpczoN
Cg0KICAgICAgICAgIGxlYWYgY29uZmlndXJhdGlvbi1oYW5kbGluZyB7DQogICAgICAgICAgICB0
eXBlIGVudW1lcmF0aW9uIHsNCiAgICAgICAgICAgICAgZW51bSBtZXJnZSB7DQogICAgICAgICAg
ICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAgICAgICAgIk1lcmdlIGNvbmZpZ3VyYXRpb24g
aW50byBleGlzdGluZyBydW5uaW5nIGNvbmZpZ3VyYXRpb24uIjsNCiAgICAgICAgICAgICAgfQ0K
ICAgICAgICAgICAgICBlbnVtIHJlcGxhY2Ugew0KICAgICAgICAgICAgICAgIGRlc2NyaXB0aW9u
DQogICAgICAgICAgICAgICAgICAiUmVwbGFjZSBleGlzdGluZyBydW5uaW5nIGNvbmZpZ3VyYXRp
b24gd2l0aCB0aGUgcGFzc2VkDQogICAgICAgICAgICAgICAgICAgY29uZmlndXJhdGlvbi4iOw0K
ICAgICAgICAgICAgICB9DQogICAgICAgICAgICB9DQogICAgICAgICAgICBtYW5kYXRvcnkgdHJ1
ZTsNCiAgICAgICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAgICAgICJUaGlzIGVudW1lcmF0
aW9uIGluZGljYXRlcyBob3cgdGhlIHNlcnZlciBzaG91bGQgcHJvY2Vzcw0KICAgICAgICAgICAg
ICAgdGhlIHByb3ZpZGVkIGNvbmZpZ3VyYXRpb24uIjsNCiAgICAgICAgICB9DQoNCknigJlsbCBh
c3N1bWUgdGhpcyBhcHByb2FjaCBpcyBjb25maXJtZWQgaWYgbm8gb2JqZWN0aW9uIGlzIHJhaXNl
ZCBieSB0aGUgZW5kIG9mIG5leHQgd2Vlay4NCg0KVGhhbmtzLA0KS2VudA0KDQoNCkZyb206IE5l
dGNvbmYgPG5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEtlbnQgV2F0c2Vu
IDxrd2F0c2VuQGp1bmlwZXIubmV0Pg0KRGF0ZTogV2VkbmVzZGF5LCBKdWx5IDYsIDIwMTYgYXQg
OTo1MCBQTQ0KVG86ICJuZXRjb25mQGlldGYub3JnIiA8bmV0Y29uZkBpZXRmLm9yZz4NClN1Ympl
Y3Q6IFJlOiBbTmV0Y29uZl0gemVyb3RvdWNoLzEyOiBIb3cgdG8gY29tbWl0IGNvbmZpZz8gTWVy
Z2UvcmVwbGFjZT8NCg0KDQpTbyBJ4oCZdmUgYWRkZWQgdGhlIGZvbGxvd2luZyBsZWFmIC0gYW55
IHRob3VnaHRzPw0KDQogICAgICAgICAgbGVhZiBjb25maWctaGFuZGxpbmcgew0KICAgICAgICAg
ICAgdHlwZSBlbnVtZXJhdGlvbiB7DQogICAgICAgICAgICAgIGVudW0gbWVyZ2Ugew0KICAgICAg
ICAgICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAgICAgICAgICJNZXJnZSBjb25maWd1cmF0
aW9uIGludG8gZXhpc3RpbmcgcnVubmluZyBjb25maWd1cmF0aW9uLiI7DQogICAgICAgICAgICAg
IH0NCiAgICAgICAgICAgICAgZW51bSByZXBsYWNlIHsNCiAgICAgICAgICAgICAgICBkZXNjcmlw
dGlvbg0KICAgICAgICAgICAgICAgICAgIlJlcGxhY2UgZXhpc3RpbmcgcnVubmluZyBjb25maWd1
cmF0aW9uIHdpdGggcGFzc2VkDQogICAgICAgICAgICAgICAgICAgY29uZmlndXJhdGlvbi4iOw0K
ICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgIGVudW0gZWRpdC1jb25maWcgew0KICAgICAg
ICAgICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAgICAgICAgICAiUHJvY2VzcyBjb25maWd1
cmF0aW9uIGFzIGFuIDxlZGl0LWNvbmZpZz4gZG9jdW1lbnQuIjsNCiAgICAgICAgICAgICAgfQ0K
ICAgICAgICAgICAgICBlbnVtIHlhbmctcGF0Y2ggew0KICAgICAgICAgICAgICAgIGRlc2NyaXB0
aW9uDQogICAgICAgICAgICAgICAgICAiUHJvY2VzcyBjb25maWd1cmF0aW9uIGFzIGEgWUFORyBQ
YXRjaCBkb2N1bWVudC4iOw0KICAgICAgICAgICAgICB9DQogICAgICAgICAgICB9DQogICAgICAg
ICAgfQ0KDQpJIHdpc2ggZWRpdC1jb25maWcgYW5kIHlhbmctcGF0Y2ggY291bGQgYmUgb3B0aW9u
cy9mZWF0dXJlcywgYnV0IHRoaXMgZG9lc27igJl0IHJlZHVjZSB0aGUgbnVtYmVyIG9mIGZvcm1h
dHMgdGhhdCBkZXZpY2VzIHdvdWxkIG5lZWQgdG8gc3VwcG9ydCwgYXMgbGltaXRpbmcgd2hhdCBh
IHNwZWNpZmljIGJvb3RzdHJhcC1zZXJ2ZXJzIHN1cHBvcnRzIGRvZXNu4oCZdCBsaW1pdCB3aGF0
IG90aGVyIGJvb3RzdHJhcC1zZXJ2ZXJzIG1pZ2h0IHN1cHBvcnQuLi4NCg0KS2VudA0KDQoNCkZy
b206IE5ldGNvbmYgPG5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEtlbnQg
V2F0c2VuIDxrd2F0c2VuQGp1bmlwZXIubmV0Pg0KRGF0ZTogV2VkbmVzZGF5LCBKdW5lIDI5LCAy
MDE2IGF0IDY6NTMgUE0NClRvOiAibmV0Y29uZkBpZXRmLm9yZyIgPG5ldGNvbmZAaWV0Zi5vcmc+
DQpTdWJqZWN0OiBSZTogW05ldGNvbmZdIHplcm90b3VjaC8xMjogSG93IHRvIGNvbW1pdCBjb25m
aWc/IE1lcmdlL3JlcGxhY2U/DQoNCg0KVHJ5aW5nIHRvIG1vdmUgdGhpcyBkaXNjdXNzaW9uIGZv
cndhcmQuDQoNCknigJltIHN0aWxsIHByZWZlciAoYikgZm9yIHRoZSByZWFzb25zIGxpc3RlZCBi
ZWxvdywgYnV0IGl0IG1heSBiZSBwb3NzaWJsZSB0byBkbyBzb21ldGhpbmcgaW4gYmV0d2VlbiAo
YikgYW5kIChjKS4gIEluIHBhcnRpY3VsYXIsIGEgdG9wLWxldmVsIGZsYWcgY291bGQgYWxsb3cg
Zm9yIGVkaXQtY29uZmlnIGFuZCB5YW5nLXBhdGNoIG9wdGlvbnMgYWxzby4NCg0KT0xEOg0KICAg
ICAgICAgICAgICArLS06KGJvb3RzdHJhcC1pbmZvcm1hdGlvbikNCiAgICAgICAgICAgICAgICAg
Ky0tcm8gYm9vdHN0cmFwLWluZm9ybWF0aW9uDQogICAgICAgICAgICAgICAgICAgICstLXJvIGJv
b3QtaW1hZ2UNCiAgICAgICAgICAgICAgICAgICAgfCAgLi4uDQogICAgICAgICAgICAgICAgICAg
ICstLXJvIGNvbmZpZ3VyYXRpb24NCiAgICAgICAgICAgICAgICAgICAgKy0tcm8gc2NyaXB0PyAg
ICAgICAgICBzdHJpbmcNCg0KTkVXOg0KICAgICAgICAgICAgICArLS06KGJvb3RzdHJhcC1pbmZv
cm1hdGlvbikNCiAgICAgICAgICAgICAgICAgKy0tcm8gYm9vdHN0cmFwLWluZm9ybWF0aW9uDQog
ICAgICAgICAgICAgICAgICAgICstLXJvIGJvb3QtaW1hZ2UNCiAgICAgICAgICAgICAgICAgICAg
fCAgLi4uDQogICAgICAgICAgICAgICAgICAgICstLXJvIGNvbmZpZy1oYW5kbGluZyAgZW51bSB7
cmVwbGFjZSwgbWVyZ2UsIGVkaXQtY29uZmlnLCB5YW5nLXBhdGNofQ0KICAgICAgICAgICAgICAg
ICAgICArLS1ybyBjb25maWd1cmF0aW9uDQogICAgICAgICAgICAgICAgICAgKy0tcm8gc2NyaXB0
PyAgICAgICAgICBzdHJpbmcNCg0KVGhvdWdodHM/ICAtIGlzIGl0IHdvcnRoIGl0Pw0KDQpUaGFu
a3MsDQpLZW50DQoNCg0KRnJvbTogTmV0Y29uZiA8bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPiBv
biBiZWhhbGYgb2YgS2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+DQpEYXRlOiBXZWRu
ZXNkYXksIE1heSAxMSwgMjAxNiBhdCA3OjAzIFBNDQpUbzogIm5ldGNvbmZAaWV0Zi5vcmciIDxu
ZXRjb25mQGlldGYub3JnPg0KU3ViamVjdDogW05ldGNvbmZdIHplcm90b3VjaC8xMjogSG93IHRv
IGNvbW1pdCBjb25maWc/IE1lcmdlL3JlcGxhY2U/DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9uZXRj
b25mLXdnL3plcm8tdG91Y2gvaXNzdWVzLzEyDQoNCg0KU2xpZGUgMTAgZnJvbSB0aGUgemVybyB0
b3VjaCBwcmVzbyBAIDk1IGhhZDoNCg0KICBPcHRpb25zOg0KQS4gSGFyZGNvZGUg4oCdcmVwbGFj
ZeKAnSAgICAgICAgICAgICAgICAgICAgICAgIC8vIGFsd2F5cyB3b3JrcywgYnV0IGxhcmdlIGlu
IHNpemUNCkIuIFVzZSBhIHRvcC1sZXZlbCBmbGFnICAgICAgICAgICAgICAgICAgICAgICAgIC8v
IGxldCBkZXBsb3ltZW50cyBkZWNpZGUNCkMuIFVzZSBlZGl0LWNvbmZpZyBvciB5YW5nLXBhdGNo
PyAgICAgLy8gaXMgdGhpcyBtdWNoIGdyYW51bGFyaXR5IG5lZWRlZD8NCg0KVGhlIG1pbnV0ZXMg
bm90ZSB0aGF0IFJpY2sgVGF5bG9yIHByZWZlcnMgdGhlIGxhc3Qgb3B0aW9uLCBzdGF0aW5nIHRo
YXQgdGhlIGNvbmZpZ3VyYXRpb24gY2FuIGJlIGJpZy4NCg0KQnV0IGxldCdzIGNvbnNpZGVyIG9w
dGlvbiAoYikgaW4gdGhlIGNvbnRleHQgb2YgdGhlIGNvbmZpZyBiZWluZyBiaWcuICAgSWYgdGhl
IHRvcC1sZXZlbCBmbGFnIGlzICdtZXJnZScgYW5kIHRoZSBjb25maWcgaXMgaHVnZSwgdGhlbiBp
dCdzIGVmZmVjdGl2ZWx5IHRoZSBzYW1lIGFzIDxlZGl0LWNvbmZpZz4uICAgT3RoZXJ3aXNlLCBp
ZiB0aGUgdG9wLWxldmVsIGZsYWcgaXMgJ3JlcGxhY2UnIGFuZCB0aGUgY29uZmlnIGlzIGh1Z2Us
IHRoZW4gdGhlIGFtb3VudCBvZiBmYWN0b3J5LWRlZmF1bHQgY29uZmlnIHRoYXQgZ2V0cyByZXBs
YWNlZCBpcyByZWxhdGl2ZWx5IHNtYWxsLiAgU28gaXQgc2VlbXMgdGhhdCBvcHRpb24gKGIpIGlz
IGVxdWFsbHkgdmlhYmxlIGluIHRoZSBjb250ZXh0IG9mIGh1Z2UgY29uZmlncy4NCg0KSSBwZXJz
b25hbGx5IHByZWZlciBvcHRpb24gKGIpLCBiZWNhdXNlIEkgdGhpbmsgdGhhdCBpdCdzIGJldHRl
ciBpbiB0aGlzIGNhc2UgdG8gbm90IHJlcXVpcmUgdGhlIGNsaWVudCB0byBoYXZlIHRvIHVuZGVy
c3RhbmQgZWRpdC1jb25maWcgb3IgeWFuZy1wYXRjaC4gIFJlY2FsbCwgdGhlIGRldmljZSBpcyB0
aGUgSFRUUCBjbGllbnQsIGFuZCB0aGUgbG9naWMgdGhhdCBpbXBsZW1lbnRzIHRoZSBib290c3Ry
YXBwaW5nIGNvZGUgbWF5IGJlIGRpZmZlcmVudCB0aGFuIHRoZSBsb2dpYyB0aGF0IGtub3dzIGhv
dyB0byBwcm9jZXNzIE5FVENPTkYgb3IgUkVTVENPTkYsIGF0IGxlYXN0IHRoaXMgaG93IEkndmUg
c2VlbiBpdCBpbXBsZW1lbnRlZC4uLg0KDQpUaG91Z2h0cz8NCg0KS2VudA0KDQo=

--_000_24A6B4F95BBC4F118AF390658EB63D06junipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: <63C0F3CEC4F94F4ABFA594952002EA11@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls
eTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBE
ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K
CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0
Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl
cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1k
ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93
ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNv
cmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmFwcGxlLXRhYi1zcGFuDQoJe21zby1zdHlsZS1uYW1l
OmFwcGxlLXRhYi1zcGFuO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBl
cnNvbmFsOw0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFu
LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseTpD
YWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0
eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3
aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K
CW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6
dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm
b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp
bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K
CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xv
cj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8
ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+TGV04oCZcyBjbG9zZSBh
bGwgdGhlIG9wZW4gaXNzdWVzIGZvciB0aGUgemVyb3RvdWNoIGRyYWZ0LiZuYnNwOyBTdGFydGlu
ZyB3aXRoIGxvdy1oYW5naW5nIGZydWl0IGZpcnN0IG1ha2VzIHNlbnNlLi4uJm5ic3A7DQo8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTpDYWxpYnJpIj5Gb3IgdGhpcyBwYXJ0aWN1bGFyIGlzc3VlLCBpdCBzZWVt
cyB0byBtZSB0aGF0IHRoZSBzaW1wbGVzdCBhbmQgZWFzaWVzdCBzb2x1dGlvbiBpcyB0byBqdXN0
IHN1cHBvcnQgdGhlIOKAmG1lcmdl4oCZIGFuZCDigJhyZXBsYWNl4oCZIG9wdGlvbnMgZm9yIG5v
dyAobm8gZWRpdC1jb25maWcgb3IgeWFuZy1wYXRjaCkuJm5ic3A7ICZuYnNwOzxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OkNhbGlicmkiPlRob3VnaCBub3QgZGlzY3Vzc2VkIHByZXZpb3VzbHksIEkgYWxzbyBy
ZXBsYWNlZCB0aGUg4oCYZGVmYXVsdCByZXBsYWNl4oCZIHdpdGggYSDigJhtYW5kYXRvcnkgdHJ1
ZeKAmSwgYXMgdGhlcmUgdHJ1bHkgY2FuIGJlIG5vIHByZWZlcnJlZCBvcHRpb24gaGVyZSAoaXTi
gJlzIGEgY3VzdG9tZXItZHJpdmVuIGNob2ljZSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+
U28sIHRoZSBuZXQgcmVzdWx0IGlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGli
cmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsZWFmIGNvbmZp
Z3VyYXRpb24taGFuZGxpbmcgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmki
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyB0eXBlIGVudW1lcmF0aW9uIHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZW51bSBtZXJnZSB7PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IGRlc2NyaXB0aW9uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmcXVvdDtNZXJnZSBj
b25maWd1cmF0aW9uIGludG8gZXhpc3RpbmcgcnVubmluZyBjb25maWd1cmF0aW9uLiZxdW90Ozs8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyBlbnVtIHJlcGxhY2UgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGli
cmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlwdGlvbjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtSZXBsYWNlIGV4aXN0aW5nIHJ1bm5pbmcgY29uZmln
dXJhdGlvbiB3aXRoIHRoZSBwYXNzZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp
YnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
Y29uZmlndXJhdGlvbi4mcXVvdDs7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy
aSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD
YWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmki
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyBtYW5kYXRvcnkgdHJ1ZTs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD
YWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgZGVzY3JpcHRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JnF1b3Q7VGhpcyBlbnVtZXJhdGlvbiBp
bmRpY2F0ZXMgaG93IHRoZSBzZXJ2ZXIgc2hvdWxkIHByb2Nlc3M8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIHByb3Zp
ZGVkIGNvbmZpZ3VyYXRpb24uJnF1b3Q7OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNh
bGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyB9PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+SeKAmWxsIGFzc3VtZSB0aGlzIGFwcHJv
YWNoIGlzIGNvbmZpcm1lZCBpZiBubyBvYmplY3Rpb24gaXMgcmFpc2VkIGJ5IHRoZSBlbmQgb2Yg
bmV4dCB3ZWVrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlRoYW5rcyw8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5LZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y
ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7
Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj4NCjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
Q2FsaWJyaTtjb2xvcjpibGFjayI+TmV0Y29uZiAmbHQ7bmV0Y29uZi1ib3VuY2VzQGlldGYub3Jn
Jmd0OyBvbiBiZWhhbGYgb2YgS2VudCBXYXRzZW4gJmx0O2t3YXRzZW5AanVuaXBlci5uZXQmZ3Q7
PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2RheSwgSnVseSA2LCAyMDE2IGF0IDk6NTAgUE08YnI+
DQo8Yj5UbzogPC9iPiZxdW90O25ldGNvbmZAaWV0Zi5vcmcmcXVvdDsgJmx0O25ldGNvbmZAaWV0
Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbTmV0Y29uZl0gemVyb3RvdWNoLzEy
OiBIb3cgdG8gY29tbWl0IGNvbmZpZz8gTWVyZ2UvcmVwbGFjZT88bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5TbyBJ4oCZdmUgYWRkZWQgdGhlIGZvbGxv
d2luZyBsZWFmIC0gYW55IHRob3VnaHRzPw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxlYWYg
Y29uZmlnLWhhbmRsaW5nIHs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgdHlwZSBlbnVtZXJhdGlvbiB7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVudW0gbWVyZ2Ugezwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyBkZXNjcmlwdGlvbg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JnF1b3Q7TWVyZ2UgY29u
ZmlndXJhdGlvbiBpbnRvIGV4aXN0aW5nIHJ1bm5pbmcgY29uZmlndXJhdGlvbi4mcXVvdDs7PC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IH08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgZW51bSByZXBsYWNlIHs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJp
Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVzY3JpcHRpb248L3NwYW4+PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7UmVwbGFjZSBleGlzdGluZyBydW5uaW5nIGNvbmZpZ3Vy
YXRpb24gd2l0aCBwYXNzZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29uZmln
dXJhdGlvbi4mcXVvdDs7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJp
Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZW51bSBlZGl0LWNvbmZpZyB7PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IGRlc2NyaXB0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O1Byb2Nlc3MgY29u
ZmlndXJhdGlvbiBhcyBhbiAmbHQ7ZWRpdC1jb25maWcmZ3Q7IGRvY3VtZW50LiZxdW90Ozs8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
fTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyBlbnVtIHlhbmctcGF0Y2ggezwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGli
cmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlwdGlvbjwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtQcm9jZXNzIGNvbmZpZ3VyYXRpb24gYXMgYSBZQU5H
IFBhdGNoIGRvY3VtZW50LiZxdW90Ozs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp
YnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyB9PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy
aSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IH08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5JIHdpc2ggZWRpdC1jb25maWcgYW5kIHlhbmct
cGF0Y2ggY291bGQgYmUgb3B0aW9ucy9mZWF0dXJlcywgYnV0IHRoaXMgZG9lc27igJl0IHJlZHVj
ZSB0aGUgbnVtYmVyIG9mIGZvcm1hdHMgdGhhdCBkZXZpY2VzIHdvdWxkIG5lZWQgdG8gc3VwcG9y
dCwgYXMgbGltaXRpbmcgd2hhdCBhIHNwZWNpZmljIGJvb3RzdHJhcC1zZXJ2ZXJzDQogc3VwcG9y
dHMgZG9lc27igJl0IGxpbWl0IHdoYXQgb3RoZXIgYm9vdHN0cmFwLXNlcnZlcnMgbWlnaHQgc3Vw
cG9ydC4uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPktlbnQ8L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD
YWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6
bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu
IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
Q2FsaWJyaTtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5OZXRjb25mICZsdDtuZXRjb25mLWJvdW5jZXNA
aWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBLZW50IFdhdHNlbiAmbHQ7a3dhdHNlbkBqdW5pcGVy
Lm5ldCZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBKdW5lIDI5LCAyMDE2IGF0IDY6
NTMgUE08YnI+DQo8Yj5UbzogPC9iPiZxdW90O25ldGNvbmZAaWV0Zi5vcmcmcXVvdDsgJmx0O25l
dGNvbmZAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbTmV0Y29uZl0gemVy
b3RvdWNoLzEyOiBIb3cgdG8gY29tbWl0IGNvbmZpZz8gTWVyZ2UvcmVwbGFjZT88L3NwYW4+PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJz
cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5UcnlpbmcgdG8gbW92ZSB0
aGlzIGRpc2N1c3Npb24gZm9yd2FyZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp
YnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5J4oCZbSBz
dGlsbCBwcmVmZXIgKGIpIGZvciB0aGUgcmVhc29ucyBsaXN0ZWQgYmVsb3csIGJ1dCBpdCBtYXkg
YmUgcG9zc2libGUgdG8gZG8gc29tZXRoaW5nIGluIGJldHdlZW4gKGIpIGFuZCAoYykuJm5ic3A7
IEluIHBhcnRpY3VsYXIsIGEgdG9wLWxldmVsIGZsYWcgY291bGQgYWxsb3cgZm9yIGVkaXQtY29u
ZmlnIGFuZCB5YW5nLXBhdGNoDQogb3B0aW9ucyBhbHNvLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGli
cmkiPk9MRDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
ICZuYnNwOyZuYnNwOyYjNDM7LS06KGJvb3RzdHJhcC1pbmZvcm1hdGlvbik8L3NwYW4+PG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyYjNDM7LS1ybyBib290c3RyYXAtaW5mb3JtYXRpb248L3NwYW4+PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyYjNDM7LS1ybyBib290LWltYWdlPC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7IC4uLjwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JiM0MzstLXJvIGNvbmZpZ3VyYXRpb248L3NwYW4+PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyYjNDM7LS1ybyBzY3JpcHQ/Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN0cmluZzwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OkNhbGlicmkiPk5FVzo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD
b25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyYjNDM7LS06KGJvb3RzdHJhcC1pbmZvcm1h
dGlvbik8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyYjNDM7LS1ybyBib290c3RyYXAtaW5mb3JtYXRp
b248L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyYjNDM7LS1ybyBib290
LWltYWdlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7IC4u
Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JiM0MzstLXJvIGNvbmZp
Zy1oYW5kbGluZyZuYnNwOyBlbnVtIHtyZXBsYWNlLCBtZXJnZSwgZWRpdC1jb25maWcsIHlhbmct
cGF0Y2h9PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmIzQzOy0tcm8g
Y29uZmlndXJhdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmIzQz
Oy0tcm8gc2NyaXB0PyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyBzdHJpbmc8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4m
bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5UaG91Z2h0cz8mbmJz
cDsgLSBpcyBpdCB3b3J0aCBpdD88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJp
Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5UaGFua3MsPC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+S2VudDwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl
cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw
aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls
eTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+DQo8L2I+PHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPk5ldGNvbmYgJmx0O25ldGNvbmYtYm91bmNl
c0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIEtlbnQgV2F0c2VuICZsdDtrd2F0c2VuQGp1bmlw
ZXIubmV0Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIE1heSAxMSwgMjAxNiBhdCA3
OjAzIFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtuZXRjb25mQGlldGYub3JnJnF1b3Q7ICZsdDtu
ZXRjb25mQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bTmV0Y29uZl0gemVyb3Rv
dWNoLzEyOiBIb3cgdG8gY29tbWl0IGNvbmZpZz8gTWVyZ2UvcmVwbGFjZT88L3NwYW4+PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7
Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+aHR0cHM6Ly9naXRodWIuY29tL25ldGNv
bmYtd2cvemVyby10b3VjaC9pc3N1ZXMvMTI8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw
dDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj4mbmJzcDs8
L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9y
OmJsYWNrIj5TbGlkZSAxMCBmcm9tIHRoZSB6ZXJvIHRvdWNoIHByZXNvIEAgOTUgaGFkOjwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6Ymxh
Y2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNh
bGlicmk7Y29sb3I6YmxhY2siPiZuYnNwOyBPcHRpb25zOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPkEuIEhhcmRjb2RlIOKA
nXJlcGxhY2XigJ0gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsvLyBhbHdheXMgd29ya3MsIGJ1
dCBsYXJnZSBpbiBzaXplPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p
bHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+Qi4gVXNlIGEgdG9wLWxldmVsIGZsYWcgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsvLyBsZXQgZGVwbG95bWVudHMgZGVjaWRlPC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+
Qy4gVXNlIGVkaXQtY29uZmlnIG9yIHlhbmctcGF0Y2g/ICZuYnNwOyAmbmJzcDsmbmJzcDsvLyBp
cyB0aGlzIG11Y2ggZ3JhbnVsYXJpdHkgbmVlZGVkPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPlRo
ZSBtaW51dGVzIG5vdGUgdGhhdCBSaWNrIFRheWxvciBwcmVmZXJzIHRoZSBsYXN0IG9wdGlvbiwg
c3RhdGluZyB0aGF0IHRoZSBjb25maWd1cmF0aW9uIGNhbiBiZSBiaWcuICZuYnNwOzwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2si
PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGli
cmk7Y29sb3I6YmxhY2siPkJ1dCBsZXQncyBjb25zaWRlciBvcHRpb24gKGIpIGluIHRoZSBjb250
ZXh0IG9mIHRoZSBjb25maWcgYmVpbmcgYmlnLiAmbmJzcDsgSWYgdGhlIHRvcC1sZXZlbCBmbGFn
IGlzICdtZXJnZScgYW5kIHRoZSBjb25maWcgaXMgaHVnZSwgdGhlbiBpdCdzIGVmZmVjdGl2ZWx5
IHRoZSBzYW1lIGFzICZsdDtlZGl0LWNvbmZpZyZndDsuDQogJm5ic3A7IE90aGVyd2lzZSwgaWYg
dGhlIHRvcC1sZXZlbCBmbGFnIGlzICdyZXBsYWNlJyBhbmQgdGhlIGNvbmZpZyBpcyBodWdlLCB0
aGVuIHRoZSBhbW91bnQgb2YgZmFjdG9yeS1kZWZhdWx0IGNvbmZpZyB0aGF0IGdldHMgcmVwbGFj
ZWQgaXMgcmVsYXRpdmVseSBzbWFsbC4gJm5ic3A7U28gaXQgc2VlbXMgdGhhdCBvcHRpb24gKGIp
IGlzIGVxdWFsbHkgdmlhYmxlIGluIHRoZSBjb250ZXh0IG9mIGh1Z2UgY29uZmlncy4gJm5ic3A7
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q2FsaWJy
aTtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u
dC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+SSBwZXJzb25hbGx5IHByZWZlciBvcHRpb24g
KGIpLCBiZWNhdXNlIEkgdGhpbmsgdGhhdCBpdCdzIGJldHRlciBpbiB0aGlzIGNhc2UgdG8gbm90
IHJlcXVpcmUgdGhlIGNsaWVudCB0byBoYXZlIHRvIHVuZGVyc3RhbmQgZWRpdC1jb25maWcgb3Ig
eWFuZy1wYXRjaC4gJm5ic3A7UmVjYWxsLCB0aGUgZGV2aWNlDQogaXMgdGhlIEhUVFAgY2xpZW50
LCBhbmQgdGhlIGxvZ2ljIHRoYXQgaW1wbGVtZW50cyB0aGUgYm9vdHN0cmFwcGluZyBjb2RlIG1h
eSBiZSBkaWZmZXJlbnQgdGhhbiB0aGUgbG9naWMgdGhhdCBrbm93cyBob3cgdG8gcHJvY2VzcyBO
RVRDT05GIG9yIFJFU1RDT05GLCBhdCBsZWFzdCB0aGlzIGhvdyBJJ3ZlIHNlZW4gaXQgaW1wbGVt
ZW50ZWQuLi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDYWxp
YnJpO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm
b250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5UaG91Z2h0cz88L3NwYW4+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj4mbmJzcDs8
L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9y
OmJsYWNrIj5LZW50PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250
LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_24A6B4F95BBC4F118AF390658EB63D06junipernet_--


From nobody Thu Aug 11 17:43:33 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD9212D0FA for ; Thu, 11 Aug 2016 17:43:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level: 
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrT1Nl3pmOyT for ; Thu, 11 Aug 2016 17:43:30 -0700 (PDT)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0136.outbound.protection.outlook.com [104.47.37.136]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B0CC12D5C8 for ; Thu, 11 Aug 2016 17:43:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+zuqD7N5FJvT/tjPLbiBVsn1eMOmATs0ceOr5mjYges=; b=J0qJCOYs6PHmSkVFVknTiaqMmiOTE87pKfHIhtEC1VZX9oC9cx+Foi7yo+Udt80oL7Opd3IeFsK2HI6C2xrdTu5ouy7K2438TVKUhPBaSeG0x30xXHbWb+rv0FTl9Q8/f3D3eUS9LuEJFujIGwcTpQMhQjNMVtl8Ql0eQDbbYtk=
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1452.namprd05.prod.outlook.com (10.160.149.13) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.8; Fri, 12 Aug 2016 00:43:28 +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.0557.009; Fri, 12 Aug 2016 00:43:27 +0000
From: Kent Watsen 
To: "netconf@ietf.org" 
Thread-Topic: [Netconf] zerotouch/14: Removable storage details?
Thread-Index: AQHRq96aoeOBJizsz0Suy3PZsyqGQJ+0zf+AgEvicgCARBnXgA==
Date: Fri, 12 Aug 2016 00:43:27 +0000
Message-ID: 
References: <633A61C1-905D-4C4E-98D6-4C864FD752A7@juniper.net> <20160512055519.GA54966@elstar.local> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.18.0.160709
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.14]
x-ms-office365-filtering-correlation-id: ad9b1c06-c770-46a0-2d4f-08d3c249acea
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1452; 6:RsRu4fL29tlKETMYXcU8aglSM3sX9t8xrF5mdTcBiXRdQLfhWzQRZPRh0OTu9ViFLs3a49xSVSc2i9t4Q/myQ66exLxJd3LyZUPIwxY/eX6QAMMVh60pKwbRKIibjOnoEIpLucoNvT1n1IsKxdrwGK1RnqtFz9kD8QiQOSNp1a5ftGev14R9e8q0gmoMfIr7yn4ATukJmFjF5fQhBL3DqaGN/Bjs4TGDJeXfAud2R0HFJDQfYVxXGfQxj9n/VHmszAvP+H5Vb+cYdL+qRAKW3Se4fCGp6afkzxVnr8XrAD1FnfV+bvG7l6IZn/InzlAvmUKGjlj4AOHOJ+jizmizrA==; 5:F6VIWjhMcdYnKRp3CP41vsgjLh5feNs+JxRy4OX861kT5AWXazVWLva9lkEfsRQAbacssJdfKtirtF/GrHW8rHiweY/jFLh/5f+E9tYcpAlM9ecaYoCjDJ/BZVrJ4J756Xla0LIaAwk2BgfrT0Qnjw==; 24:c3eg++SB6JlrNNdX1MfYoBGvkgjSr7eLSgJVU1GbV/4+C0K22Jl5Y8HcexvMv1XAUhncBCBMVTXFPfOZ0DC9e74aZ+JHmo5Xgp1oS0eq4Gs=; 7:j8OxbjZ5OiDm5X600IOji/RpmuDanerFfd47HRapJJFGSsJu7h8RO9WoVD2I23N6e9Vkw547a+Wfwxqqu6FS5A39sGcaX5NajgPtC0jzuQfjqNau5xpALhyx9h+WiF9saJE7pwMRJe/vVabMQdTbfUrwzp5u1mS83QqKC/P2CceP0x/XPL+F3sFGjeApg8hGXLxHTZPjVypdzi2YTsFLpyP2oqzEM025VteBRg0/CnagPWnhgBjj0MKv4K0Tfv7T
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1452;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(166708455590820)(138986009662008);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040175)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:CY1PR0501MB1452; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1452; 
x-forefront-prvs: 003245E729
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(51444003)(24454002)(377454003)(189002)(199003)(106116001)(122556002)(66066001)(106356001)(3280700002)(19580395003)(1730700003)(3660700001)(83716003)(8936002)(8676002)(82746002)(19580405001)(77096005)(81156014)(586003)(102836003)(81166006)(83506001)(3846002)(6116002)(5640700001)(33656002)(86362001)(4001350100001)(7846002)(7736002)(2501003)(76176999)(54356999)(97736004)(2351001)(50986999)(105586002)(189998001)(36756003)(101416001)(2906002)(87936001)(450100001)(15975445007)(2950100001)(92566002)(305945005)(99286002)(10400500002)(68736007)(2900100001)(5002640100001)(107886002)(110136002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1452; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <5EA00B4ECE907A408BB31BBAD2C611AD@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Aug 2016 00:43:27.6079 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1452
Archived-At: 
Subject: Re: [Netconf] zerotouch/14: Removable storage details?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Aug 2016 00:43:32 -0000

VGhpcyBpc3N1ZSB3YXMgZGlzY3Vzc2VkIGluIEJlcmxpbi4gIE5vIGlzc3VlcyB3ZXJlIHJhaXNl
ZCB0aGVuIG9yIG9uIGxpc3QuICAgDQpIZW5jZSB0aGlzIGNoYW5nZSBpcyBjb25maXJtZWQgYW5k
IHRoZSBpc3N1ZSB3aWxsIGJlIGNsb3NlZC4NCg0KVGhhbmtzLA0KS2VudA0KDQoNCk9uIDYvMjkv
MTYsIDEyOjQ1IFBNLCAiTmV0Y29uZiBvbiBiZWhhbGYgb2YgS2VudCBXYXRzZW4iIDxuZXRjb25m
LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGt3YXRzZW5AanVuaXBlci5uZXQ+IHdyb3Rl
Og0KDQogICAgDQogICAgUGlja2luZyB1cCBvbiB0aGlzIHRocmVhZCwgcGVyIEp1ZXJnZW7igJlz
IHJlY29tbWVuZGF0aW9uLCBJIGFkZGVkIGEgcmVjb21tZW5kYXRpb246DQogICAgDQogICAgT0xE
Og0KICAgICAgIE5vdGU6IGRldGFpbHMgc3VjaCBhcyB0aGUgZm9ybWF0IG9mIHRoZSBmaWxlc3lz
dGVtIGFuZCB0aGUgbmFtaW5nIG9mDQogICAgICAgdGhlIGZpbGVzIGFyZSBsZWZ0IHRvIHRoZSBk
ZXZpY2UncyBtYW51ZmFjdHVyZXIgdG8gZGVmaW5lLg0KICAgIA0KICAgIE5FVzoNCiAgICAgICBO
b3RlOiBkZXRhaWxzIHN1Y2ggYXMgdGhlIGZvcm1hdCBvZiB0aGUgZmlsZXN5c3RlbSBhbmQgdGhl
IG5hbWluZyBvZg0KICAgICAgIHRoZSBmaWxlcyBhcmUgbGVmdCB0byB0aGUgZGV2aWNlJ3MgbWFu
dWZhY3R1cmVyIHRvIGRlZmluZS4gIEhvd2V2ZXIsDQogICAgICAgaW4gb3JkZXIgdG8gZmFjaWxp
dGF0ZSBpbnRlcm9wZXJhYmlsaXR5LCBpdCBpcyBSRUNPTU1FTkRFRCB0byBzdXBwb3J0DQogICAg
ICAgb3Blbi9zdGFuZGFyZHMgYmFzZWQgZmlsZXN5c3RlbXMgYW5kIHRvIGhhdmUgYSBmaWxlIG5h
bWluZyBjb252ZW50aW9uDQogICAgICAgdGhhdCBpcyBub3QgbGlrZWx5IHRvIGhhdmUgY29sbGlz
aW9ucyB3aXRoIGZpbGVzIGZyb20gb3RoZXIgdmVuZG9ycy4NCiAgICANCiAgICBUaG91Z2h0cz8N
CiAgICANCiAgICBLZW50DQogICAgDQogICAgDQogICAgDQogICAgT24gNS8xMi8xNiwgMTo1NSBB
TSwgIkp1ZXJnZW4gU2Nob2Vud2FlbGRlciIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVy
c2l0eS5kZT4gd3JvdGU6DQogICAgDQogICAgT24gV2VkLCBNYXkgMTEsIDIwMTYgYXQgMTE6NDE6
MTNQTSArMDAwMCwgS2VudCBXYXRzZW4gd3JvdGU6DQogICAgPiBodHRwczovL2dpdGh1Yi5jb20v
bmV0Y29uZi13Zy96ZXJvLXRvdWNoL2lzc3Vlcy8xNA0KICAgID4gDQogICAgPiBUaGUgY3VycmVu
dCBkcmFmdCBzYXlzOiAiRGV0YWlscyBzdWNoIGFzIHRoZSBmb3JtYXQgb2YgZmlsZSBzeXN0ZW0g
YW5kIHRoZSBuYW1pbmcgb2YgdGhlIGZpbGVzIGFyZSBsZWZ0IHRvIHRoZSBkZXZpY2UncyBtYW51
ZmFjdHVyZXIgdG8gZGVmaW5lIiwgIGJ1dCBhbiBvbi1saXN0IHJldmlldyByZWNvbW1lbmRzIHRo
YXQgdGhlIGRyYWZ0IGJlIG1vcmUgbm9ybWF0aXZlIGFib3V0IHRoaXMuDQogICAgPiANCiAgICA+
IFRoZSBhYm92ZSBpcyBlc3NlbnRpYWxseSBzbGlkZSAjMTIgZnJvbSB0aGUgSUVURiA5NSBwcmVz
ZW50YXRpb24uICBUaGUgbWludXRlcyB0aGVuIGNhcHR1cmUgdGhlIGZvbGxvd2luZyBkaWFsb2c6
DQogICAgPiANCiAgICA+ICAgLSBKSDogc3RvcmFnZSBmb3JtYXRzIGhhdmUgY2hhbmdlZCBpbW1l
bnNlbHkgb3ZlciB0aGUgeWVhcnMuICBGaXhpbmcgdGhlbSBpbiB0aGUgbW9kZWwgd2lsbCBsaWtl
bHkganVzdCBtYWtlIHRoZSBtb2RlbCBvYnNlbGV0ZSBxdWlja2x5IC4gTWF5YmUgYSByZWdpc3Ry
eSA/DQogICAgPiAgIC0gS1c6IFdoYXQgd291bGQgYmUgdGhlIG1vdGl2YXRpb24/DQogICAgPiAg
IC0gTUNSOiBOb3QgdGhhdCB3ZSBkZWZpbmUgdGhlbSwgd2Ugc2hvdWxkIGp1c3QgcmVmZXIgdG8g
dGhlbS4NCiAgICA+ICAgLSBSVDogd2hhdCBhcmUgd2UgdHJ5aW5nIHRvIGFjaGlldmUgaGVyZSA/
ICBKdXN0IGJhc2ljIGJvb3RpbmcgPyAgb3IgbW9yZSA/DQogICAgPiANCiAgICA+IEkgdGhpbmsg
dGhhdCB0aGVyZSB3YXMvaXMgYSBmdW5kYW1lbnRhbCBtaXN1bmRlcnN0YW5kaW5nLiAgV2UncmUg
bm90IGhlcmUgZGlzY3Vzc2luZyB0aGUgZm9ybWF0IG9mIHRoZSBmaWxlc3lzdGVtIGZvciB0aGUg
ZGV2aWNlIGl0c2VsZiwgdGhhdCBpcyBjb21wbGV0ZWx5IG91dCBvZiBzY29wZS4gIEluc3RlYWQs
IHdlJ3JlIGp1c3QgZGlzY3Vzc2luZyB0aGUgZm9ybWF0IG9mIHRoZSBmaWxlc3lzdGVtIGZvciB0
aGUgcmVtb3ZhYmxlIHN0b3JhZ2UgZGV2aWNlIChlLmcuLCBhIFVTQiBmbGFzaCBkcml2ZSksIGFu
ZC9vciB0aGUgbmFtZXMgb2YgdGhlIGZpbGVzIHRoYXQgdGhlIGRldmljZSBtaWdodCBsb29rIGZv
ciBvbiB0aGUgc3RvcmFnZSBkZXZpY2UuDQogICAgPiANCiAgICA+IE15IHZpZXcgaXMgdGhhdCB3
ZSBzaG91bGQgbGV0IGVhY2ggdmVuZG9yIGRlY2lkZSBmb3IgdGhlbXNlbHZlcy4gIElmIHRoZXkg
d2FudCB0byBzdXBwb3J0IGV4dDMsIG1zZG9zLCBudGZzLCBoZmYrLCBvciB3aGF0ZXZlciAtIGl0
J3MgdXAgdG8gdGhlbSB0byBkZWNpZGUuIEZ1cnRoZXIsIHRoZXkgc2hvdWxkIGJlIGFsbG93ZWQg
dG8gZGVmaW5lIHRoZSBmaWxlIG5hbWVzIGFuZCBmb3JtYXRzIGFzIHdlbGwuICAgTXkgdGhvdWdo
dCBpdHMgdGhhdCB0aGVyZSBpcyBsaXR0bGUgbmVlZCB0byBwbHVnIGEgc3BlY2lmaWMgcmVtb3Zh
YmxlIHN0b3JhZ2UgZGV2aWNlIGluc3RhbmNlIGludG8gbW9yZSB0aGFuIG9uZSBkZXZpY2UsIHRo
dXMgdGhlIG11bHRpLXZlbmRvciBhc3BlY3Qgb2YgdGhpcyBpdCBub3QgdmVyeSBzdHJvbmcsIGFu
ZCBzbyB3ZSBzaG91bGQgZGVjbGFyZSBpdCBhcyBvdXQtb2Ytc2NvcGUuDQogICAgPg0KICAgIA0K
ICAgIEkgdGhpbmsgaXQgaXMgdXNlZnVsIHRvIGhhdmUgYSBmb3JtYXQgdGhhdCBpcyByZWFkYWJs
ZSBhbmQgd3JpdGFibGUgYnkNCiAgICAncmVndWxhcicgY29tcHV0ZXJzOyBpZiB2ZW5kb3JzIHN0
YXJ0IHRvIHByb2R1Y2Ugc3RvcmFnZSBzdGlja3MgdGhhdA0KICAgIGNhbid0IGJlIHJlYWQgb3Ig
Y29waWVkIHVzaW5nICdyZWd1bGFyJyBjb21wdXRlcnMsIEkgd291bGQgYmUgc29tZXdoYXQNCiAg
ICB1bmhhcHB5LiBUaGF0IHNhaWQsIEkgYW0gbm90IHN1cmUgYSBzdGFuZGFyZCBjYW4gcmVhbGx5
IHByZXZlbnQgdGhpcw0KICAgIGZyb20gaGFwcGVuaW5nIGJ1dCBnaXZpbmcgc29tZSBhZHZpY2Ug
dGhhdCB1c2luZyBvcGVuIGZvcm1hdHMgaXMgYQ0KICAgIGdvb2QgdGhpbmcgbWF5IGJlIHVzZWZ1
bC4gKEFuIG9wZW4gZm9ybWF0IG1heSBhbGxvdyBtZSB0byBjcmVhdGUNCiAgICBjb21iaW5lZCBi
b290IHN0aWNrcyB0aGF0IGNhbiBib290IG1vcmUgdGhhbiBhIHNpbmdsZSBkZXZpY2UgdHlwZS4p
DQogICAgDQogICAgL2pzDQogICAgDQogICAgLS0gDQogICAgSnVlcmdlbiBTY2hvZW53YWVsZGVy
ICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCiAgICBQaG9uZTogKzQ5
IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJt
YW55DQogICAgRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cDovL3d3dy5qYWNv
YnMtdW5pdmVyc2l0eS5kZS8+DQogICAgDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBOZXRjb25mIG1haWxpbmcgbGlzdA0KICAg
IE5ldGNvbmZAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL25ldGNvbmYNCiAgICANCg0K


From nobody Thu Aug 11 17:45:49 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A94B12D5C8 for ; Thu, 11 Aug 2016 17:45:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level: 
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpwYRqfmZm4D for ; Thu, 11 Aug 2016 17:45:46 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0132.outbound.protection.outlook.com [104.47.33.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B3AC12D630 for ; Thu, 11 Aug 2016 17:45:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=10eQR+pU2uuwYko2MRODD24J3pcCQF6jUOXvd27JRqU=; b=WkZve6ewOYXbqoTiPDt9Ok7iYB4/JiZmcz3JB41MNCjxFXhVaiCi2Xdn5BMNlnm9KgaztLPuz6M1hhg9ZI28xSl6Aeez5y11uJ+b6fxvke8+pt/1kkBZHDm0DFTIcOLklrSjkhqjwAb1zDQVxebEAE0vEe56NUk++5N/NNlN8cU=
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1452.namprd05.prod.outlook.com (10.160.149.13) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.8; Fri, 12 Aug 2016 00:45:42 +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.0557.009; Fri, 12 Aug 2016 00:45:42 +0000
From: Kent Watsen 
To: "netconf@ietf.org" 
Thread-Topic: [Netconf] zerotouch/15: Enhanced script support
Thread-Index: AQHR1+4c7FxNR59PjU6DiewErpapT6BEcsoA
Date: Fri, 12 Aug 2016 00:45:42 +0000
Message-ID: <72143566-D753-4BA8-B919-D4C9FAFB12EC@juniper.net>
References: <42DA2449-AE04-44FD-863A-55569D6A6F28@juniper.net>
In-Reply-To: <42DA2449-AE04-44FD-863A-55569D6A6F28@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.18.0.160709
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.14]
x-ms-office365-filtering-correlation-id: a152d06c-d5c1-4c64-47f0-08d3c249fd34
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1452; 6:TeNVSxmCsEYJIFxZN+F17aSmb3yaZyzj8UHO59v3KL5DQigTXY1P0AyWv/Pp34DnUKM4MS1bxFrSgayE/EsKWSzUJXGFI4hUhfAK4M6+huRpSPcV6wnwJiDhLZPw25aGLTRi6w6WkvvBQ5hFPaC5DArPgsQUpthsq5CryPUrTwyYW3SfUY5L9vlipPm2Dl9jG7BiTGhWctgH7BrEfX/zqtSP6qq15OYiYShEqwCd1501V7ZyqOmvKlhTHqfVj2zvnvN3ojHBwE0t23sFWcjPMTk/uf7CS2pKnfyoUerLWEH1eixr6b7OnDtdgNAP1AC0rXeifrqjDgGXmLx9/cMVZw==; 5:LAL07zIF25BqyYO7lEfQRY1h7Twyb8KRRCVSfn7O/z6UpGXIjNhNFa+v0mruvSEu1YFbJEThA2lHIH9pYGfHCCoyhsa/6bTCE4v0JCxuY/BbaJ513XeKSH3wK7polWuGwE+5fw1/j4u0+VeN697JEg==; 24:qFb2y+WvszBdyxuRFA1MTCqiEmOlIr9dy3QsQ8zcl9gziylqDAX/mM8pit3m6LAP0cQnCCHl1ccwmkYwfucYnD0gHxeEwt6vd38YDHaN+rg=; 7:qNP4gJUpEmaRgMvWg0lLDU+AacqqWNuUnnZUJeq9Ve1Y7EiNFwYhXs09GGqErJ+Omn/1z3NK2TONW6+/PdT/JP1sQgp5IcBlSqZ5BkfOIJ51nufx75qHMMNZWxXvtyGFMg83QRZwDl2djiC1GqzdcMVs7b31i13AWFsjvIPQxa2PiGRfPA9efAnmpAViPLWDpijDXl7DoMTK6F8BzVS3O8NJdMP0Mv2B5CY9xeJg0OdKCxEBmG08UIS2TGg3GjnF
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1452;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(166708455590820)(138986009662008);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040175)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:CY1PR0501MB1452; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1452; 
x-forefront-prvs: 003245E729
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(377454003)(189002)(199003)(478694002)(106116001)(122556002)(66066001)(106356001)(3280700002)(19580395003)(1730700003)(3660700001)(83716003)(8936002)(8676002)(82746002)(19580405001)(77096005)(81156014)(586003)(102836003)(81166006)(83506001)(3846002)(6116002)(5640700001)(33656002)(86362001)(4001350100001)(7846002)(7736002)(2501003)(76176999)(54356999)(97736004)(2351001)(50986999)(105586002)(189998001)(36756003)(101416001)(2906002)(87936001)(450100001)(15975445007)(2950100001)(92566002)(305945005)(11100500001)(99286002)(10400500002)(68736007)(2900100001)(5002640100001)(107886002)(110136002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1452; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Aug 2016 00:45:42.4143 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1452
Archived-At: 
Subject: Re: [Netconf] zerotouch/15: Enhanced script support
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Aug 2016 00:45:48 -0000

VGhpcyBpc3N1ZSB3YXMgZGlzY3Vzc2VkIGluIEJlcmxpbi4gIE5vIGlzc3VlcyB3ZXJlIHJhaXNl
ZCB0aGVuIG9yIG9uIGxpc3QuICANCkhlbmNlIHRoaXMgY2hhbmdlIGlzIGNvbmZpcm1lZCBhbmQg
dGhlIGlzc3VlIHdpbGwgYmUgY2xvc2VkLg0KDQpUaGFua3MsDQpLZW50DQoNCg0KDQpPbiA3LzYv
MTYsIDk6MjMgUE0sICJOZXRjb25mIG9uIGJlaGFsZiBvZiBLZW50IFdhdHNlbiIgPG5ldGNvbmYt
Ym91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yga3dhdHNlbkBqdW5pcGVyLm5ldD4gd3JvdGU6
DQoNCiAgICANCiAgICBTbyBteSB0aG91Z2h0cyBvbiB0aGlzIGFyZSB0byBzdXBwb3J0IGFsc28g
YSDigJxwcmUtY29uZmlndXJhdGlvbi1zY3JpcHTigJ0sIGJ1dCB0byBub3Qgd29ycnkgYWJvdXQg
cGFyYW1ldGVycyBhcyB0aGUgYW55IHN1Y2ggZGV2aWNlLXNwZWNpZmljIHBhcmFtZXRlcnMgY2Fu
IGJlIGVuY29kZWQgaW50byB0aGUgc2NyaXB0IGl0c2VsZi4gICBPZiBjb3Vyc2UsIEnigJltIGFz
c3VtaW5nIHRoYXQgdGhlIHNjcmlwdCBpcyByZWFsbHkgYSBzY3JpcHQsIGFuZCBub3QgYSBjb21w
aWxlZCBleGVjdXRhYmxlLiAgIElmIHdlIHdhbnQgdG8gc3VwcG9ydCBjb21waWxlZCBleGVjdXRh
YmxlcywgdGhlbiBwYXJhbWV0ZXJzIG1pZ2h0IGJlIGdvb2QuICBBbnkgY29tbWVudHM/ICAtIHNo
b3VsZCB3ZSB0cnkgdG8gc3VwcG9ydCBjb21waWxlZCBleGVjdXRhYmxlcz8NCiAgICANCiAgICBL
ZW50DQogICAgDQogICAgDQogICAgDQogICAgT24gNi8yOS8xNiwgNzozNiBQTSwgIk5ldGNvbmYg
b24gYmVoYWxmIG9mIEtlbnQgV2F0c2VuIiA8bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIG9uIGJl
aGFsZiBvZiBrd2F0c2VuQGp1bmlwZXIubmV0PiB3cm90ZToNCiAgICANCiAgICBodHRwczovL2dp
dGh1Yi5jb20vbmV0Y29uZi13Zy96ZXJvLXRvdWNoL2lzc3Vlcy8xNQ0KICAgIA0KICAgIFRoZSBj
dXJyZW50IGRyYWZ0IGFsbG93cyBmb3IgYSBzaW5nbGUgc2NyaXB0IHRoYXQgdGFrZXMgbm8gY29t
bWFuZC1saW5lIHBhcmFtZXRlcnMuIE9uLWdvaW5nIGltcGxlbWVudGF0aW9uIGRpc2N1c3Npb25z
IHN1Z2dlc3QgdGhhdDoNCiAgICANCiAgICAxKSB0aGVyZSBzaG91bGQgYmUgc3VwcG9ydCB0byBy
dW4gYSBzY3JpcHQgYm90aCBiZWZvcmUgYW5kIGFmdGVyIHRoZSBjb25maWd1cmF0aW9uIGlzIGNv
bW1pdHRlZC4NCiAgICAgICAgICAgLSB0aGlzIG1lYW5zIHRoYXQgd2UnZCBuZWVkIGJvdGggInBy
ZS1zY3JpcHQiIGFuZCAicG9zdC1zY3JpcHQiIGxlYXZlcw0KICAgICAgICAgICAtIGZvciBpbnN0
YW5jZToNCiAgICANCiAgICBPTEQ6DQogICAgDQogICAgICAgICAgICAgICAgICAgICArLS1ybyBi
b290c3RyYXAtaW5mb3JtYXRpb24NCiAgICAgICAgICAgICAgICAgICAgICAgICstLXJvIGJvb3Qt
aW1hZ2UNCiAgICAgICAgICAgICAgICAgICAgICAgIHwgICstLS4uLg0KICAgICAgICAgICAgICAg
ICAgICAgICAgKy0tcm8gY29uZmlndXJhdGlvbg0KICAgICAgICAgICAgICAgICAgICAgICAgKy0t
cm8gc2NyaXB0PyAgICAgICAgICBzdHJpbmcNCiAgICBORVc6DQogICAgDQogICAgICAgICAgICAg
ICAgICAgICArLS1ybyBib290c3RyYXAtaW5mb3JtYXRpb24NCiAgICAgICAgICAgICAgICAgICAg
ICAgICstLXJvIGJvb3QtaW1hZ2UNCiAgICAgICAgICAgICAgICAgICAgICAgIHwgICstLS4uLg0K
ICAgICAgICAgICAgICAgICAgICAgICAgKy0tcm8gcHJlLWNvbmZpZ3VyYXRpb24tc2NyaXB0PyAg
ICAgICAgICBzdHJpbmcNCiAgICAgICAgICAgICAgICAgICAgICAgICstLXJvIGNvbmZpZ3VyYXRp
b24NCiAgICAgICAgICAgICAgICAgICAgICAgICstLXJvIHBvc3QtY29uZmlndXJhdGlvbi1zY3Jp
cHQ/ICAgICAgICAgU3RyaW5nDQogICAgDQogICAgDQogICAgDQogICAgMikgdGhlcmUgc2hvdWxk
IGJlIHN1cHBvcnQgZm9yIHBhc3NpbmcgY29tbWFuZCBsaW5lIHBhcmFtZXRlcnMsIHNvIHRoYXQg
dGhlIHNhbWUgc2NyaXB0IGNhbiBiZSB1c2VkIG9uIG1hbnkgZGV2aWNlcy4gVGhpcyBpcyBlc3Nl
bnRpYWxseSBzaGlmdGluZyB3aGVyZSB2YXJpYWJsZSBiaW5kaW5ncyBvY2N1ciAtIGVpdGhlciB0
aGUgTk1TIHJlbmRlcnMgYSBkZXZpY2Utc3BlY2lmaWMgc2NyaXB0IChpbmNvcnBvcmF0aW5nIGRl
dmljZS1zcGVjaWZpYyB2YWx1ZXMpLCBvciB0aGUgZGV2aWNlIHJlbmRlcnMgaXQgKHVzaW5nIGNv
bW1hbmQtbGluZSB2YXJpYWJsZXMgdG8ga25vdyBob3cgdG8gZG8gdGhlIHN1YnN0aXR1dGlvbnMp
LiBUaGUgbGF0dGVyIGlzIGhhcmRlciBvbiBkZXZpY2VzLCBidXQgdGhlIGZvcm1lciBtYXkgZW5h
YmxlIGJldHRlciBzY2FsYWJpbGl0eS4gVG8gaW1wbGVtZW50IHRoaXMsIHdlIG1pZ2h0IGhhdmUg
c29tZXRoaW5nIGxpa2U6DQogICAgDQogICAgTkVXOiAvLyBhZGRpbmcgb250byB0aGUgYWJvdmUg
ZXhhbXBsZQ0KICAgIA0KICAgICAgICAgICAgICAgICAgICAgKy0tcm8gYm9vdHN0cmFwLWluZm9y
bWF0aW9uDQogICAgICAgICAgICAgICAgICAgICAgICArLS1ybyBib290LWltYWdlDQogICAgICAg
ICAgICAgICAgICAgICAgICB8ICArLS0uLi4NCiAgICAgICAgICAgICAgICAgICAgICAgICstLXJv
IHByZS1jb25maWd1cmF0aW9uLXNjcmlwdA0KICAgICAgICAgICAgICAgICAgICAgICAgfCAgKy0t
IHNjcmlwdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJpbmcNCiAg
ICAgICAgICAgICAgICAgICAgICAgIHwgICstLSBwYXJhbWV0ZXJzICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBzdHJpbmcNCiAgICAgICAgICAgICAgICAgICAgICAgICstLXJvIGNvbmZpZ3Vy
YXRpb24NCiAgICAgICAgICAgICAgICAgICAgICAgICstLXJvIHBvc3QtY29uZmlndXJhdGlvbi1z
Y3JpcHQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICstLSBzY3JpcHQgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RyaW5nDQogICAgICAgICAgICAgICAgICAgICAg
ICAgICArLS0gcGFyYW1ldGVycyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3RyaW5nDQog
ICAgDQogICAgDQogICAgQW55IHRob3VnaHRzIG9uIHRoaXMgb25lPw0KICAgIA0KICAgIA0KICAg
IFRoYW5rcywNCiAgICBLZW50DQogICAgDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBOZXRjb25mIG1haWxpbmcgbGlzdA0KICAg
IE5ldGNvbmZAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL25ldGNvbmYNCiAgICANCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KICAgIE5ldGNvbmYgbWFpbGluZyBsaXN0DQogICAgTmV0Y29u
ZkBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0
Y29uZg0KICAgIA0KDQo=


From nobody Fri Aug 12 16:00:32 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F3512D927 for ; Fri, 12 Aug 2016 16:00:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrNw24YLr2CQ for ; Fri, 12 Aug 2016 16:00:28 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0104.outbound.protection.outlook.com [104.47.42.104]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC8BC12D924 for ; Fri, 12 Aug 2016 16:00:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4UqssOBju+QkRB8AYyGEy0Jy3zynuvTvT9DQ0fDNg3U=; b=Ih1wOPo6JpcEc1pKims8uy+Mb7VuY5ve6GrrNBy485qPiOTduhWOVyj4LU6BtXfmQYiMvhf8qfc5uwggEpky+ZFZBDFjBAC0nZTCgoIVN2WVvrfiwW8v+J9lzpYgqjOeMlBN3CkzWEMzNicPs5S8dCsew7WmcfZXTo9f0gobJEk=
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 (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.8; Fri, 12 Aug 2016 23:00:26 +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.0557.009; Fri, 12 Aug 2016 23:00:26 +0000
From: Kent Watsen 
To: "netconf@ietf.org" 
Thread-Topic: [Netconf] zerotouch/16: How to encode a chain of certs?
Thread-Index: AQHR9O1QL2hT7JffXUKb2eXuCtz2rA==
Date: Fri, 12 Aug 2016 23:00:26 +0000
Message-ID: <35D8022F-B00A-4916-92DD-3D1E4C44FA16@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.18.0.160709
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.14]
x-ms-office365-filtering-correlation-id: b54d48f0-8638-443f-82e4-08d3c30472d3
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1451; 6:AuKtprHHfkF+mKX99rELVrD4qfI40PIjMIMgh0cZPJ70Ssd5cJRojn22h0E+xNJ6xsJpy4hdpn6zsevJnr33HFCk/Ims5E/A1u42Dq0DyUMS9xNEs/orn2OqTRDPV/vMDTO1Ig/06NK3IUlda+aptWbFpKyeIDHVBzRZlXkcJmTdscMP8v8kO94laqibp/HB2AwkJsrzJ3xrIAXgBMLdwo0z4S9PiIwJ+T1fsvj7akmnxu2S3/VStlBjl98KobGfIF3mdAT32VRbTg5oin0IdlEku8I0WZ5vINyklERnUX5mgBjIOQtIr4++OpKCOQ4NhH6rmI95rbIDYMsgZlDqRA==; 5:JiCxniKrCf3Gci+DRWgQb6M/29nWcT7n0Oim+peOuF+65LVknmFHmb0BLTMS/cse4KB3aSnlkpOwFg05aosYaA6uTwL+0CirjzNu1blEerKrBr+3HTsLqMsHSkTrqHp0FAB+ymdFjxlf9WwA5qQxBOwn5bmKGQdQn4Q5KZh5Nko=; 24:x+3UR0BuOriK0VNYmAXeGHhy1nXRGNrn02xggpcZuBwlGe5Oz1Lgzk8Og2e8sAiFuMZKL2jhwJnySeSxVV9N94DCL5Zrw+SQQhmW+wncpAo=; 7:TZ7nezean3NLWHzLGaYG8HkKlbGKsJG3rvrlY3Xi5IsS1xUQRf+gwenQtY999waw6yi+PmptLthewirl21TWC1yf6Udj197xS3dlR6utq2nv2+GWVOwKL+47X8Q0VSugfna97IePzn9XfYpS9N43+eIRzX1CCYlCGRjZqaFUXL34oyqAWhrV58aaDIoS1aaZdwnEKu2DJZqy2Aeb2EheLSX623L1Zc/aDUnchvMgxufvwgsvW1PvYgE3/6J2dWv1
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1451;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(192374486261705)(788757137089)(21748063052155); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:CY1PR0501MB1451; BCL:0; PCL:0; RULEID:(304825118); SRVR:CY1PR0501MB1451; 
x-forefront-prvs: 003245E729
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(478694002)(199003)(189002)(6116002)(106116001)(3280700002)(3660700001)(7846002)(77096005)(15975445007)(7736002)(83506001)(86362001)(106356001)(2906002)(97736004)(551544002)(4001350100001)(2351001)(110136002)(102836003)(189998001)(87936001)(122556002)(107886002)(19580395003)(54356999)(33656002)(36756003)(82746002)(450100001)(92566002)(99286002)(5640700001)(50986999)(19625215002)(101416001)(11100500001)(3846002)(81156014)(16236675004)(5002640100001)(83716003)(19300405004)(1730700003)(8936002)(81166006)(2900100001)(10400500002)(66066001)(2501003)(586003)(68736007)(8676002)(105586002)(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:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_35D8022FB00A491692DD3D1E4C44FA16junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Aug 2016 23:00:26.0769 (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: [Netconf] zerotouch/16: How to encode a chain of certs?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Aug 2016 23:00:31 -0000

--_000_35D8022FB00A491692DD3D1E4C44FA16junipernet_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQpUaGlzIGlzc3VlIHdhcyBkaXNjdXNzZWQgaW4gQmVybGluLCBidXQgbm8gZGVjaXNpb24gd2Fz
IHJlYWNoZWQuICAgSGVyZSBhcmUgbXkgY3VycmVudCB0aG91Z2h0czoNCg0KMS4gdXNlIGFuIG9y
ZGVyZWQtYnktdXNlciBsZWFmLWxpc3Qgb2YgdGhlIFguNTA5djMgc3RydWN0dXJlcyBlbmNvZGVk
IHVzaW5nIERFUg0KDQogICAgICBJIGRvbuKAmXQgdGhpbmsgdGhpcyBpcyBhIGdvb2Qgc29sdXRp
b24uICBJbiBmYWN0LCB0aGlzIGlzIHRoZSBjdXJyZW50IHNvbHV0aW9uIGluDQogICAgICB0aGUg
aWV0Zi1zeXN0ZW0ta2V5Y2hhaW4gbW9kdWxlLCBmb3Igd2hpY2ggdGhlcmUgYWxyZWFkeSBpcyBh
biBvcGVuIGlzc3VlDQogICAgICB0byByZXBsYWNlIGl0IHdpdGggYmV0dGVyIHNvbHV0aW9uLiAg
VGhlIHJlYXNvbiB0aGlzIGFwcHJvYWNoIGlzbuKAmXQgYQ0KICAgICAgZ29vZCBvbmUgaXMgYmVj
YXVzZSB0b29scyBnZW5lcmFsbHkgdXNlIGZpbGUgZm9ybWF0cyB0aGF0IGVuY29kZSBtdWx0aXBs
ZQ0KICAgICAgY2VydHMgaW50byBhIHNpbmdsZSBmaWxlIChlLmcuLCBhIC5wZW0gb3IgLnAxMiBm
aWxlKSAtIHRoYXQgaXMsIG9uZSBibG9iIChub3QgbWFueSkNCg0KDQoyLiBjb25jYXRlbmF0ZSBt
dWx0aXBsZSBQRU0gdG9nZXRoZXIgdG8gZW5jb2RlIGEgYnVuZGxlIG9mIGNlcnRzDQoNCiAgICAg
RW5jb2RpbmcgYSBzaW5nbGUgY2VydGlmaWNhdGUgaW50byBhIFBFTSBlbmNvZGluZyBpcyBkZWZp
bmVkIGluIFJGQyA3NDY4LA0KICAgICBTZWN0aW9uIDguICAgIEkgYW0gbm90IGFibGUgbG9jYXRl
IGEgcmVmZXJlbmNlIGNvbmNhdGVuYXRpbmcgbXVsdGlwbGUgUEVNDQogICAgIGVuY29kaW5ncyBp
bnRvIGEgc2luZ2xlIG1lc3NhZ2Uvc3RyaW5nLiAgIFdpdGhvdXQgYSBub3JtYXRpdmUgcmVmZXJl
bmNlLA0KICAgICBJ4oCZbSBoZXNpdGFudCB0byByZWNvbW1lbmQgZ29pbmcgdGhpcyByb3V0ZS4N
Cg0KDQozLiB1c2UgYSBQS0NTIzEyIHN0cnVjdHVyZSBmcm9tIFJGQyA3MjkyIHRvIGVuY29kZSBh
IGJ1bmRsZSBvZiBjZXJ0cw0KDQogICAgICBQS0NTIzEyIGlzIGEgZmxleGlibGUgZm9ybWF0IHRo
YXQgY2FuIGVuY29kZSBtYW55IG9iamVjdHMsIGluY2x1ZGluZw0KICAgICAgd2hhdCBpcyBjYWxs
cyBhIOKAnENlcnRCYWfigJ0gKGkuZS4gYSBiYWcgb2YgY2VydGlmaWNhdGVzKSBkZWZpbmVkIGlu
IFNlY3Rpb24NCiAgICAgIDQuMi4zLiAgT3BlblNTTCBjYW4gY29udmVydCB0byBhbmQgZnJvbSBh
IGZpbGUgY29udGFpbmluZyBtdWx0aXBsZQ0KICAgICAgUEVNcyBhbmQgYSBQS0NTIzEyIGFzIGZv
bGxvd3M6DQoNCiAgICAgICMgIGNhdCByaWdodGZ1bF9vd25lci9vd25lcl9jZXJ0LnBlbSBpbnRl
cm1lZGlhdGUvY2FfY2VydC5wZW0gPiBvd25lcl9idW5kbGUucGVtDQogICAgICAjICBvcGVuc3Ns
IHBrY3MxMiAtZXhwb3J0IC1pbiBvd25lcl9idW5kbGUucGVtIC1ub2tleXMgLW91dCBvd25lcl9i
dW5kbGUucDEyDQogICAgICAjICBvcGVuc3NsIHBrY3MxMiAtaW4gb3duZXJfYnVuZGxlLnAxMiAt
bm9kZXMgLW91dCBvd25lcl9idW5kbGUucGVtLjINCiAgICAgIyAgZGlmZiBvd25lcl9idW5kbGUu
cGVtKiAgLy8gdGhlcmXigJlzIGEgc21hbGwgZGlmZmVyZW5jZSAoY29tbWVudHMgb25seSkNCg0K
DQo0LiB1c2UgYSBkZWdlbmVyYXRlIFBLQ1MgIzcgc3RydWN0dXJlIGZyb20gUkZDIDIzMTUgdG8g
ZW5jb2RlIGEgYnVuZGxlIG9mIGNlcnRzDQoNCiAgICAgIFdoaWxlIFBLQ1MjNyBpcyBwcmltYXJp
bHkgdXNlZCB0byBlbmNvZGUgc2lnbmVkIGRhdGEsIHRoZXJlIGlzIGENCiAgICAgIGRlZ2VuZXJh
dGUgZm9ybSBvZiBpdCB0aGF0IGhhcyBubyBzaWduYXR1cmVzLCB3aGljaCBhY2NvcmRpbmcgdG8N
CiAgICAgIFNlY3Rpb24gOSDigJxwcm92aWRlcyBhIG1lYW5zIGZvciBkaXNzZW1pbmF0aW5nIGNl
cnRpZmljYXRlc+KAnS4gT3BlblNTTA0KICAgICAgY2FuIGNvbnZlcnQgdG8gYW5kIGZyb20gYSBm
aWxlIGNvbnRhaW5pbmcgbXVsdGlwbGUgUEVNcyBhbmQgYQ0KICAgICAgUEtDUyM3IGFzIGZvbGxv
d3M6DQoNCiAgICAgICMgY2F0IHJpZ2h0ZnVsX293bmVyL293bmVyX2NlcnQucGVtIGludGVybWVk
aWF0ZS9jYV9jZXJ0LnBlbSA+IG93bmVyX2J1bmRsZS5wZW0NCiAgICAgICMgb3BlbnNzbCBjcmwy
cGtjczcgLW5vY3JsIC1jZXJ0ZmlsZSBvd25lcl9idW5kbGUucGVtIC1vdXQgb3duZXJfYnVuZGxl
LnA3Yg0KICAgICAgIyBvcGVuc3NsIHBrY3M3IC1wcmludF9jZXJ0cyAtaW4gb3duZXJfYnVuZGxl
LnA3YiAtb3V0IG93bmVyX2J1bmRsZS5wZW0uMg0KICAgICAgIyBkaWZmIG93bmVyX2J1bmRsZS5w
ZW0qICAvLyB0aGVyZeKAmXMgYSBzbWFsbCBkaWZmZXJlbmNlIChjb21tZW50cyBvbmx5KQ0KDQoN
CjUuIHVzZSBhIOKAmGNob2ljZeKAmSBhcm91bmQgYWxsIG9mIHRoZSBQRU0gYW5kIFBLQ1MjNyBh
bmQgUEtDUyMxMiBmb3JtYXRzDQoNCiAgICAgICAgY2hvaWNlIHsNCiAgICAgICAgICBsZWFmIGNl
cnRpZmljYXRlLXBlbSB7DQogICAgICAgICAgICB0eXBlIGJpbmFyeTsNCiAgICAgICAgICB9DQog
ICAgICAgICAgbGVhZiBjZXJ0aWZpY2F0ZS1wazcgew0KICAgICAgICAgICAgdHlwZSBiaW5hcnk7
DQogICAgICAgICAgfQ0KICAgICAgICAgIGxlYWYgY2VydGlmaWNhdGUtcDEyIHsNCiAgICAgICAg
ICAgIHR5cGUgYmluYXJ5Ow0KICAgICAgICAgIH0NCiAgICAgICAgfQ0KDQoNCjYuIHVzZSBhIOKA
mGZvcm1hdOKAmSBsZWFmIHRvIGluZGljYXRlIGlmDQoNCiAgICAgICAgY29udGFpbmVyIGNlcnRp
ZmljYXRlIHsNCiAgICAgICAgICBsZWFmIGZvcm1hdCB7DQogICAgICAgICAgICB0eXBlIGVudW1l
cmF0aW9uIHsNCiAgICAgICAgICAgICAgZW51bSBwZW07DQogICAgICAgICAgICAgIGVudW0gcGs3
Ow0KICAgICAgICAgICAgICBlbnVtIHAxMjsNCiAgICAgICAgICAgIH0NCiAgICAgICAgICB9DQog
ICAgICAgICAgbGVhZiBkYXRhIHsNCiAgICAgICAgICAgIHR5cGUgYmluYXJ5Ow0KICAgICAgICAg
IH0NCiAgICAgICAgfQ0KDQoNCg0KUmVjb21tZW5kYXRpb25zOg0KICAtIElmIHdlIGhhdmUgdG8g
cGljayBqdXN0IG9uZSwgSeKAmWQgYXNrIHNlY3VyaXR5IGV4cGVydHMgdG8gcGljayBiZXR3ZWVu
DQogICAgcGs3IGFuZCBwMTIuICBOb3RlOiBwazcgd2FzIGEgYml0IGVhc2llciBvbiB0aGUgY29t
bWFuZCBsaW5lLCBpbg0KICAgIHRoYXQgaXQgZGlkbuKAmXQgcHJvbXB0IGZvciBwYXNzd29yZC4g
IEFsc28sIHBrNyByb3VuZC10cmlwcGluZw0KICAgIHN0YWJpbGl6ZWQgZmFzdGVyLg0KICAtIElm
IHdl4oCZcmUgb2theSB3aXRoIGRldmljZXMgaGF2aW5nIHRvIHN1cHBvcnQgYWxsIGZvcm1hdHMs
IHRoZW4gSQ0KICAgIHRoaW5rIHNvbHV0aW9uICM2IGlzIGJldHRlciB0aGFuICM1Lg0KDQoNCkRv
ZXMgYW55b25lIGVsc2UgaGF2ZSBhbnkgdGhvdWdodHMgb24gdGhpcz8NCg0KS2VudA0KDQo=

--_000_35D8022FB00A491692DD3D1E4C44FA16junipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: <005EEDED642B824086AB79BA83616F65@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z
b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo
DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmln
aHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2lu
LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJy
aTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250
LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkN
Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsN
Cgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9y
dC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7
DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt
b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu
NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT
ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJv
ZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1
NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5U
aGlzIGlzc3VlIHdhcyBkaXNjdXNzZWQgaW4gQmVybGluLCBidXQgbm8gZGVjaXNpb24gd2FzIHJl
YWNoZWQuJm5ic3A7Jm5ic3A7IEhlcmUgYXJlIG15IGN1cnJlbnQgdGhvdWdodHM6PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4xLiB1c2UgYW4gb3JkZXJlZC1ieS11
c2VyIGxlYWYtbGlzdCBvZiB0aGUgWC41MDl2MyBzdHJ1Y3R1cmVzIGVuY29kZWQgdXNpbmcgREVS
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgSSBkb27igJl0IHRoaW5rIHRoaXMgaXMgYSBnb29kIHNvbHV0aW9u
LiZuYnNwOyBJbiBmYWN0LCB0aGlzIGlzIHRoZSBjdXJyZW50IHNvbHV0aW9uIGluPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDt0aGUgaWV0Zi1zeXN0ZW0t
a2V5Y2hhaW4gbW9kdWxlLCBmb3Igd2hpY2ggdGhlcmUgYWxyZWFkeSBpcyBhbiBvcGVuIGlzc3Vl
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0byByZXBs
YWNlIGl0IHdpdGggYmV0dGVyIHNvbHV0aW9uLiZuYnNwOyBUaGUgcmVhc29uIHRoaXMgYXBwcm9h
Y2ggaXNu4oCZdCBhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsm
bmJzcDtnb29kIG9uZSBpcyBiZWNhdXNlIHRvb2xzIGdlbmVyYWxseSB1c2UgZmlsZSBmb3JtYXRz
IHRoYXQgZW5jb2RlIG11bHRpcGxlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyAmbmJz
cDsmbmJzcDsmbmJzcDtjZXJ0cyBpbnRvIGEgc2luZ2xlIGZpbGUgKGUuZy4sIGEgLnBlbSBvciAu
cDEyIGZpbGUpIC0gdGhhdCBpcywgb25lIGJsb2IgKG5vdCBtYW55KTxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjIuIGNv
bmNhdGVuYXRlIG11bHRpcGxlIFBFTSB0b2dldGhlciB0byBlbmNvZGUgYSBidW5kbGUgb2YgY2Vy
dHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyBFbmNvZGluZyBhIHNpbmdsZSBjZXJ0aWZpY2F0ZSBpbnRvIGEgUEVNIGVu
Y29kaW5nIGlzIGRlZmluZWQgaW4gUkZDIDc0NjgsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZu
YnNwOyZuYnNwOyAmbmJzcDtTZWN0aW9uIDguJm5ic3A7Jm5ic3A7Jm5ic3A7IEkgYW0gbm90IGFi
bGUgbG9jYXRlIGEgcmVmZXJlbmNlIGNvbmNhdGVuYXRpbmcgbXVsdGlwbGUgUEVNPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbmNvZGluZ3MgaW50byBhIHNpbmds
ZSBtZXNzYWdlL3N0cmluZy4mbmJzcDsmbmJzcDsgV2l0aG91dCBhIG5vcm1hdGl2ZSByZWZlcmVu
Y2UsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJ4oCZbSBoZXNp
dGFudCB0byByZWNvbW1lbmQgZ29pbmcgdGhpcyByb3V0ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4zLiB1c2UgYSBQ
S0NTIzEyIHN0cnVjdHVyZSBmcm9tIFJGQyA3MjkyIHRvIGVuY29kZSBhIGJ1bmRsZSBvZiBjZXJ0
czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBLQ1MjMTIgaXMgYSBmbGV4aWJsZSBmb3JtYXQgdGhhdCBjYW4g
ZW5jb2RlIG1hbnkgb2JqZWN0cywgaW5jbHVkaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3aGF0IGlzIGNhbGxzIGEg4oCcQ2VydEJhZ+KAnSAoaS5l
LiBhIGJhZyBvZiBjZXJ0aWZpY2F0ZXMpIGRlZmluZWQgaW4gU2VjdGlvbjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7NC4yLjMuICZuYnNwO09wZW5TU0wg
Y2FuIGNvbnZlcnQgdG8gYW5kIGZyb20gYSBmaWxlIGNvbnRhaW5pbmcgbXVsdGlwbGU8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO1BFTXMgYW5kIGEgUEtD
UyMxMiBhcyBmb2xsb3dzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyMmbmJzcDsgY2F0IHJpZ2h0ZnVsX293
bmVyL293bmVyX2NlcnQucGVtIGludGVybWVkaWF0ZS9jYV9jZXJ0LnBlbSAmZ3Q7IG93bmVyX2J1
bmRsZS5wZW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNw
OyMmbmJzcDsgb3BlbnNzbCBwa2NzMTIgLWV4cG9ydCAtaW4gb3duZXJfYnVuZGxlLnBlbSAtbm9r
ZXlzIC1vdXQgb3duZXJfYnVuZGxlLnAxMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsm
bmJzcDsgJm5ic3A7Jm5ic3A7IyZuYnNwOyBvcGVuc3NsIHBrY3MxMiAtaW4gb3duZXJfYnVuZGxl
LnAxMiAtbm9kZXMgLW91dCBvd25lcl9idW5kbGUucGVtLjI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IyZuYnNwOyBkaWZmIG93bmVyX2J1bmRsZS5wZW0q
Jm5ic3A7IC8vIHRoZXJl4oCZcyBhIHNtYWxsIGRpZmZlcmVuY2UgKGNvbW1lbnRzIG9ubHkpPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdCI+NC4gdXNlIGEgZGVnZW5lcmF0ZSBQS0NTICM3IHN0cnVjdHVyZSBmcm9tIFJGQyAy
MzE1IHRvIGVuY29kZSBhIGJ1bmRsZSBvZiBjZXJ0czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFdoaWxlIFBL
Q1MjNyBpcyBwcmltYXJpbHkgdXNlZCB0byBlbmNvZGUgc2lnbmVkIGRhdGEsIHRoZXJlIGlzIGEN
CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtk
ZWdlbmVyYXRlIGZvcm0gb2YgaXQgdGhhdCBoYXMgbm8gc2lnbmF0dXJlcywgd2hpY2ggYWNjb3Jk
aW5nIHRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBT
ZWN0aW9uIDkg4oCccHJvdmlkZXMgYSBtZWFucyBmb3IgZGlzc2VtaW5hdGluZyBjZXJ0aWZpY2F0
ZXPigJ0uIE9wZW5TU0wNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDtjYW4gY29udmVydCB0byBhbmQgZnJvbSBhIGZpbGUgY29udGFpbmluZyBt
dWx0aXBsZSBQRU1zIGFuZCBhDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7UEtDUyM3IGFzIGZvbGxvd3M6PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7IyBj
YXQgcmlnaHRmdWxfb3duZXIvb3duZXJfY2VydC5wZW0gaW50ZXJtZWRpYXRlL2NhX2NlcnQucGVt
ICZndDsgb3duZXJfYnVuZGxlLnBlbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJz
cDsgJm5ic3A7Jm5ic3A7IyBvcGVuc3NsIGNybDJwa2NzNyAtbm9jcmwgLWNlcnRmaWxlIG93bmVy
X2J1bmRsZS5wZW0gLW91dCBvd25lcl9idW5kbGUucDdiPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAjIG9wZW5zc2wgcGtjczcgLXByaW50X2NlcnRzIC1p
biBvd25lcl9idW5kbGUucDdiIC1vdXQgb3duZXJfYnVuZGxlLnBlbS4yPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAjIGRpZmYgb3duZXJfYnVuZGxlLnBl
bSombmJzcDsgLy8gdGhlcmXigJlzIGEgc21hbGwgZGlmZmVyZW5jZSAoY29tbWVudHMgb25seSk8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0Ij41LiB1c2UgYSDigJhjaG9pY2XigJkgYXJvdW5kIGFsbCBvZiB0aGUgUEVNIGFu
ZCBQS0NTIzcgYW5kIFBLQ1MjMTIgZm9ybWF0czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IGNob2ljZSB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtsZWFmIGNlcnRpZmljYXRlLXBlbSB7PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQiPiZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDt0eXBlIGJpbmFyeTs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO308bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdCI+Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwO2xlYWYgY2VydGlmaWNhdGUtcGs3IHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7
ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwO3R5cGUgYmluYXJ5OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJz
cDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bGVhZiBj
ZXJ0aWZpY2F0ZS1wMTIgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsgJm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dHlwZSBiaW5hcnk7
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDt9PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Ni4gdXNlIGEg4oCYZm9ybWF04oCZ
IGxlYWYgdG8gaW5kaWNhdGUgaWYNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbnRh
aW5lciBjZXJ0aWZpY2F0ZSB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyAmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtsZWFmIGZvcm1hdCB7PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQiPiZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDt0eXBlIGVudW1lcmF0aW9uIHs8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVudW0gcGVtOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgZW51bSBwazc7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyBlbnVtIHAxMjs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwO308bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2xlYWYgZGF0YSB7PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu
YnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDt0eXBlIGJpbmFyeTs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO308bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdCI+UmVjb21tZW5kYXRpb25zOjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
Ij4mbmJzcDsgLSBJZiB3ZSBoYXZlIHRvIHBpY2sganVzdCBvbmUsIEnigJlkIGFzayBzZWN1cml0
eSBleHBlcnRzIHRvIHBpY2sgYmV0d2VlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsg
Jm5ic3A7cGs3IGFuZCBwMTIuICZuYnNwO05vdGU6IHBrNyB3YXMgYSBiaXQgZWFzaWVyIG9uIHRo
ZSBjb21tYW5kIGxpbmUsIGluPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyB0
aGF0IGl0IGRpZG7igJl0IHByb21wdCBmb3IgcGFzc3dvcmQuJm5ic3A7IEFsc28sIHBrNyByb3Vu
ZC10cmlwcGluZw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3N0
YWJpbGl6ZWQgZmFzdGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsgLSBJZiB3ZeKAmXJlIG9r
YXkgd2l0aCBkZXZpY2VzIGhhdmluZyB0byBzdXBwb3J0IGFsbCBmb3JtYXRzLCB0aGVuIEkNCjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0aGluayBzb2x1dGlvbiAj
NiBpcyBiZXR0ZXIgdGhhbiAjNS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Eb2VzIGFueW9uZSBlbHNlIGhhdmUgYW55
IHRob3VnaHRzIG9uIHRoaXM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0Ij5LZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_35D8022FB00A491692DD3D1E4C44FA16junipernet_--


From nobody Sat Aug 13 05:57:49 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4346A12B069 for ; Sat, 13 Aug 2016 05:57:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtHT8QXJk8UW for ; Sat, 13 Aug 2016 05:57:46 -0700 (PDT)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50138.outbound.protection.outlook.com [40.107.5.138]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AE33127071 for ; Sat, 13 Aug 2016 05:57:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jDkRG228xbnubrrWFsmDYt1ln5DNYy9KlecMUXoS5FM=; b=Lno1pj87kM9BUAmUs/JDOrshYwlFhIJ9gep70JeemVjnc0gTyc6wkFjYfKeKgJxNh8leCVZxPtZx1k0oRuiWXBUsJV2f0sfafkhGt3C+7YZOpLWvO5Evox2wTTN9HCmEwT3DNODeaFrbjcrx62puVAz7nrRSrCb8z2UgNkVqHlg=
Received: from HE1PR0701MB2859.eurprd07.prod.outlook.com (10.168.91.149) by HE1PR0701MB2857.eurprd07.prod.outlook.com (10.168.91.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Sat, 13 Aug 2016 12:57:41 +0000
Received: from HE1PR0701MB2859.eurprd07.prod.outlook.com ([10.168.91.149]) by HE1PR0701MB2859.eurprd07.prod.outlook.com ([10.168.91.149]) with mapi id 15.01.0549.027; Sat, 13 Aug 2016 12:57:41 +0000
From: "Ersue, Mehmet (Nokia - DE/Munich)" 
To: Kent Watsen , "netconf@ietf.org" 
Thread-Topic: [Netconf] zerotouch/16: How to encode a chain of certs?
Thread-Index: AQHR9O1QL2hT7JffXUKb2eXuCtz2rKBG2Yag
Date: Sat, 13 Aug 2016 12:57:40 +0000
Message-ID: 
References: <35D8022F-B00A-4916-92DD-3D1E4C44FA16@juniper.net>
In-Reply-To: <35D8022F-B00A-4916-92DD-3D1E4C44FA16@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=mehmet.ersue@nokia.com; 
x-originating-ip: [62.159.77.186]
x-ms-office365-filtering-correlation-id: 6b1c3793-21ca-4166-9a22-08d3c3796917
x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2857; 6:fiehoLYsYxUulxm/OY85RZLBTGz6ImYRCkQjzR8DrqAENs9wEbpP0mcf0MwBChujJHat3qTxp7PbFalT7uuC1V6RcMC4tqH6u8v3oIyb0EKEToPPdrVRs9o6VQ65kHOyKNMLpHxP2QCz6CBs/RdepM9MUEDszE9aa9GkHWwvjSlxwHdWnp9vkbJ5J4pJVLhElT/9XF0aFlqyqUUTfsHxCSckMV6lvrYX8WjvkDXrmgQvg3/sn4bKKlgPP1v/hwjca4ueY3qkhe/BcqhpZWHvUXxpmQBLEcZpnVEyFf3/AvR+7mSWM8qw/c+IQWAVvH66D41o3NrPgOwywc8QtnKwnA==; 5:allye1ZB0gMyd3VUxuhTCdjCNDH+Wbma2wbLWTEj2QK76zUQbm0lGzp3MwpUXy/32wkb1TsLBQCDvIiOQINHxKe9AmWkxSTaZ/+RkCbNv/xA4JA05QUPTHIgcyWPltWnxpP1xaoVCTVqAi0pA23fyg==; 24:xHdTRjjaLegbAstYZ9eCDoBjEtX1pQNG9p/OI+bLKJGpYAJSlFSbTOM9YOFKpXhrjVbKgKNALlp/Tv5ZbJR92G4u09wTsR4Pbb1y4/ED8Fo=; 7:L5slV/ppmQDk20OsMlOG5ANOyFL5D0JtfBIYRzhRlYnV7MMtDCNSkplkiABtau7hWg9ghmoIsw0jM8mlQbfccfQqp5m6hDi17QkrvY+gog1LpR7aHZYXeYYqmC7t/H9JO155PVDelAGaCBxEeSbgDMQNu8jKFRT6xHver9blBGBccWrGrQAiSWJiusbllgWyWBkJD050PrVheKv+BO6jGzpxChv6GrCS/I1X9USgVCTkdZkPdVnVpBLPSoRL6i2D
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0701MB2857;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(192374486261705)(788757137089)(21748063052155); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:HE1PR0701MB2857; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2857; 
x-forefront-prvs: 0033AAD26D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(199003)(478694002)(189002)(106116001)(561944003)(586003)(97736004)(5002640100001)(2906002)(8676002)(3280700002)(102836003)(107886002)(790700001)(6116002)(92566002)(106356001)(10400500002)(33656002)(5001770100001)(3846002)(86362001)(189998001)(1941001)(19580395003)(8936002)(68736007)(2950100001)(54356999)(66066001)(19580405001)(122556002)(76176999)(11100500001)(16236675004)(76576001)(87936001)(81166006)(101416001)(81156014)(15975445007)(19625215002)(19300405004)(2501003)(2900100001)(50986999)(105586002)(551544002)(9686002)(77096005)(3660700001)(8666005)(74316002)(7846002)(7696003)(7736002)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2857; H:HE1PR0701MB2859.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB2859454E93CCDAA868BBB16E91100HE1PR0701MB2859_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2016 12:57:40.8753 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2857
Archived-At: 
Subject: Re: [Netconf] zerotouch/16: How to encode a chain of certs?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Aug 2016 12:57:48 -0000

--_000_HE1PR0701MB2859454E93CCDAA868BBB16E91100HE1PR0701MB2859_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

RGVhciBBbGwsDQoNCnRlY2huaWNhbCBzcG9rZW4gSeKAmW0gaW4gZmF2b3Igb2Ygc3VwcG9ydGlu
ZyBhbGwgZm9ybWF0cyB3aXRoIGEg4oCYZm9ybWF04oCZIGxlYWYuDQoNCkBBbGw6IFBsZWFzZSBj
b21tZW50IG9uIHRoZSBwcm9wb3NhbCBmcm9tIEtlbnQgYmVsb3cuDQoNCk1laG1ldA0KDQpGcm9t
OiBOZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg
S2VudCBXYXRzZW4NClNlbnQ6IFNhdHVyZGF5LCBBdWd1c3QgMTMsIDIwMTYgMTowMCBBTQ0KVG86
IG5ldGNvbmZAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gemVyb3RvdWNoLzE2OiBI
b3cgdG8gZW5jb2RlIGEgY2hhaW4gb2YgY2VydHM/DQoNCg0KVGhpcyBpc3N1ZSB3YXMgZGlzY3Vz
c2VkIGluIEJlcmxpbiwgYnV0IG5vIGRlY2lzaW9uIHdhcyByZWFjaGVkLiAgIEhlcmUgYXJlIG15
IGN1cnJlbnQgdGhvdWdodHM6DQoNCjEuIHVzZSBhbiBvcmRlcmVkLWJ5LXVzZXIgbGVhZi1saXN0
IG9mIHRoZSBYLjUwOXYzIHN0cnVjdHVyZXMgZW5jb2RlZCB1c2luZyBERVINCg0KICAgICAgSSBk
b27igJl0IHRoaW5rIHRoaXMgaXMgYSBnb29kIHNvbHV0aW9uLiAgSW4gZmFjdCwgdGhpcyBpcyB0
aGUgY3VycmVudCBzb2x1dGlvbiBpbg0KICAgICAgdGhlIGlldGYtc3lzdGVtLWtleWNoYWluIG1v
ZHVsZSwgZm9yIHdoaWNoIHRoZXJlIGFscmVhZHkgaXMgYW4gb3BlbiBpc3N1ZQ0KICAgICAgdG8g
cmVwbGFjZSBpdCB3aXRoIGJldHRlciBzb2x1dGlvbi4gIFRoZSByZWFzb24gdGhpcyBhcHByb2Fj
aCBpc27igJl0IGENCiAgICAgIGdvb2Qgb25lIGlzIGJlY2F1c2UgdG9vbHMgZ2VuZXJhbGx5IHVz
ZSBmaWxlIGZvcm1hdHMgdGhhdCBlbmNvZGUgbXVsdGlwbGUNCiAgICAgIGNlcnRzIGludG8gYSBz
aW5nbGUgZmlsZSAoZS5nLiwgYSAucGVtIG9yIC5wMTIgZmlsZSkgLSB0aGF0IGlzLCBvbmUgYmxv
YiAobm90IG1hbnkpDQoNCg0KMi4gY29uY2F0ZW5hdGUgbXVsdGlwbGUgUEVNIHRvZ2V0aGVyIHRv
IGVuY29kZSBhIGJ1bmRsZSBvZiBjZXJ0cw0KDQogICAgIEVuY29kaW5nIGEgc2luZ2xlIGNlcnRp
ZmljYXRlIGludG8gYSBQRU0gZW5jb2RpbmcgaXMgZGVmaW5lZCBpbiBSRkMgNzQ2OCwNCiAgICAg
U2VjdGlvbiA4LiAgICBJIGFtIG5vdCBhYmxlIGxvY2F0ZSBhIHJlZmVyZW5jZSBjb25jYXRlbmF0
aW5nIG11bHRpcGxlIFBFTQ0KICAgICBlbmNvZGluZ3MgaW50byBhIHNpbmdsZSBtZXNzYWdlL3N0
cmluZy4gICBXaXRob3V0IGEgbm9ybWF0aXZlIHJlZmVyZW5jZSwNCiAgICAgSeKAmW0gaGVzaXRh
bnQgdG8gcmVjb21tZW5kIGdvaW5nIHRoaXMgcm91dGUuDQoNCg0KMy4gdXNlIGEgUEtDUyMxMiBz
dHJ1Y3R1cmUgZnJvbSBSRkMgNzI5MiB0byBlbmNvZGUgYSBidW5kbGUgb2YgY2VydHMNCg0KICAg
ICAgUEtDUyMxMiBpcyBhIGZsZXhpYmxlIGZvcm1hdCB0aGF0IGNhbiBlbmNvZGUgbWFueSBvYmpl
Y3RzLCBpbmNsdWRpbmcNCiAgICAgIHdoYXQgaXMgY2FsbHMgYSDigJxDZXJ0QmFn4oCdIChpLmUu
IGEgYmFnIG9mIGNlcnRpZmljYXRlcykgZGVmaW5lZCBpbiBTZWN0aW9uDQogICAgICA0LjIuMy4g
IE9wZW5TU0wgY2FuIGNvbnZlcnQgdG8gYW5kIGZyb20gYSBmaWxlIGNvbnRhaW5pbmcgbXVsdGlw
bGUNCiAgICAgIFBFTXMgYW5kIGEgUEtDUyMxMiBhcyBmb2xsb3dzOg0KDQogICAgICAjICBjYXQg
cmlnaHRmdWxfb3duZXIvb3duZXJfY2VydC5wZW0gaW50ZXJtZWRpYXRlL2NhX2NlcnQucGVtID4g
b3duZXJfYnVuZGxlLnBlbQ0KICAgICAgIyAgb3BlbnNzbCBwa2NzMTIgLWV4cG9ydCAtaW4gb3du
ZXJfYnVuZGxlLnBlbSAtbm9rZXlzIC1vdXQgb3duZXJfYnVuZGxlLnAxMg0KICAgICAgIyAgb3Bl
bnNzbCBwa2NzMTIgLWluIG93bmVyX2J1bmRsZS5wMTIgLW5vZGVzIC1vdXQgb3duZXJfYnVuZGxl
LnBlbS4yDQogICAgICMgIGRpZmYgb3duZXJfYnVuZGxlLnBlbSogIC8vIHRoZXJl4oCZcyBhIHNt
YWxsIGRpZmZlcmVuY2UgKGNvbW1lbnRzIG9ubHkpDQoNCg0KNC4gdXNlIGEgZGVnZW5lcmF0ZSBQ
S0NTICM3IHN0cnVjdHVyZSBmcm9tIFJGQyAyMzE1IHRvIGVuY29kZSBhIGJ1bmRsZSBvZiBjZXJ0
cw0KDQogICAgICBXaGlsZSBQS0NTIzcgaXMgcHJpbWFyaWx5IHVzZWQgdG8gZW5jb2RlIHNpZ25l
ZCBkYXRhLCB0aGVyZSBpcyBhDQogICAgICBkZWdlbmVyYXRlIGZvcm0gb2YgaXQgdGhhdCBoYXMg
bm8gc2lnbmF0dXJlcywgd2hpY2ggYWNjb3JkaW5nIHRvDQogICAgICBTZWN0aW9uIDkg4oCccHJv
dmlkZXMgYSBtZWFucyBmb3IgZGlzc2VtaW5hdGluZyBjZXJ0aWZpY2F0ZXPigJ0uIE9wZW5TU0wN
CiAgICAgIGNhbiBjb252ZXJ0IHRvIGFuZCBmcm9tIGEgZmlsZSBjb250YWluaW5nIG11bHRpcGxl
IFBFTXMgYW5kIGENCiAgICAgIFBLQ1MjNyBhcyBmb2xsb3dzOg0KDQogICAgICAjIGNhdCByaWdo
dGZ1bF9vd25lci9vd25lcl9jZXJ0LnBlbSBpbnRlcm1lZGlhdGUvY2FfY2VydC5wZW0gPiBvd25l
cl9idW5kbGUucGVtDQogICAgICAjIG9wZW5zc2wgY3JsMnBrY3M3IC1ub2NybCAtY2VydGZpbGUg
b3duZXJfYnVuZGxlLnBlbSAtb3V0IG93bmVyX2J1bmRsZS5wN2INCiAgICAgICMgb3BlbnNzbCBw
a2NzNyAtcHJpbnRfY2VydHMgLWluIG93bmVyX2J1bmRsZS5wN2IgLW91dCBvd25lcl9idW5kbGUu
cGVtLjINCiAgICAgICMgZGlmZiBvd25lcl9idW5kbGUucGVtKiAgLy8gdGhlcmXigJlzIGEgc21h
bGwgZGlmZmVyZW5jZSAoY29tbWVudHMgb25seSkNCg0KDQo1LiB1c2UgYSDigJhjaG9pY2XigJkg
YXJvdW5kIGFsbCBvZiB0aGUgUEVNIGFuZCBQS0NTIzcgYW5kIFBLQ1MjMTIgZm9ybWF0cw0KDQog
ICAgICAgIGNob2ljZSB7DQogICAgICAgICAgbGVhZiBjZXJ0aWZpY2F0ZS1wZW0gew0KICAgICAg
ICAgICAgdHlwZSBiaW5hcnk7DQogICAgICAgICAgfQ0KICAgICAgICAgIGxlYWYgY2VydGlmaWNh
dGUtcGs3IHsNCiAgICAgICAgICAgIHR5cGUgYmluYXJ5Ow0KICAgICAgICAgIH0NCiAgICAgICAg
ICBsZWFmIGNlcnRpZmljYXRlLXAxMiB7DQogICAgICAgICAgICB0eXBlIGJpbmFyeTsNCiAgICAg
ICAgICB9DQogICAgICAgIH0NCg0KDQo2LiB1c2UgYSDigJhmb3JtYXTigJkgbGVhZiB0byBpbmRp
Y2F0ZSBpZg0KDQogICAgICAgIGNvbnRhaW5lciBjZXJ0aWZpY2F0ZSB7DQogICAgICAgICAgbGVh
ZiBmb3JtYXQgew0KICAgICAgICAgICAgdHlwZSBlbnVtZXJhdGlvbiB7DQogICAgICAgICAgICAg
IGVudW0gcGVtOw0KICAgICAgICAgICAgICBlbnVtIHBrNzsNCiAgICAgICAgICAgICAgZW51bSBw
MTI7DQogICAgICAgICAgICB9DQogICAgICAgICAgfQ0KICAgICAgICAgIGxlYWYgZGF0YSB7DQog
ICAgICAgICAgICB0eXBlIGJpbmFyeTsNCiAgICAgICAgICB9DQogICAgICAgIH0NCg0KDQoNClJl
Y29tbWVuZGF0aW9uczoNCiAgLSBJZiB3ZSBoYXZlIHRvIHBpY2sganVzdCBvbmUsIEnigJlkIGFz
ayBzZWN1cml0eSBleHBlcnRzIHRvIHBpY2sgYmV0d2Vlbg0KICAgIHBrNyBhbmQgcDEyLiAgTm90
ZTogcGs3IHdhcyBhIGJpdCBlYXNpZXIgb24gdGhlIGNvbW1hbmQgbGluZSwgaW4NCiAgICB0aGF0
IGl0IGRpZG7igJl0IHByb21wdCBmb3IgcGFzc3dvcmQuICBBbHNvLCBwazcgcm91bmQtdHJpcHBp
bmcNCiAgICBzdGFiaWxpemVkIGZhc3Rlci4NCiAgLSBJZiB3ZeKAmXJlIG9rYXkgd2l0aCBkZXZp
Y2VzIGhhdmluZyB0byBzdXBwb3J0IGFsbCBmb3JtYXRzLCB0aGVuIEkNCiAgICB0aGluayBzb2x1
dGlvbiAjNiBpcyBiZXR0ZXIgdGhhbiAjNS4NCg0KDQpEb2VzIGFueW9uZSBlbHNlIGhhdmUgYW55
IHRob3VnaHRzIG9uIHRoaXM/DQoNCktlbnQNCg0K

--_000_HE1PR0701MB2859454E93CCDAA868BBB16E91100HE1PR0701MB2859_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph
OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj
OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBo
LCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUt
cHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJn
aW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAw
MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy
aWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u
dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFu
LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHls
ZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp
YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDAwOTk7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv
LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk
U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQg
NzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N
Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6
ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn
dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2
OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t
LT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJERSIgbGluaz0iIzA1NjND
MSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj
b2xvcjojMDAwMDk5O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5EZWFyIEFsbCw8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzAwMDA5OTttc28tZmFyZWFzdC1sYW5ndWFn
ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDAw
OTk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPnRlY2huaWNhbCBzcG9rZW4gSeKAmW0gaW4g
ZmF2b3Igb2Ygc3VwcG9ydGluZyBhbGwgZm9ybWF0cyB3aXRoIGEg4oCYZm9ybWF04oCZIGxlYWYu
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMwMDAwOTk7bXNvLWZhcmVhc3Qt
bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xv
cjojMDAwMDk5O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5AQWxsOiBQbGVhc2UgY29tbWVu
dCBvbiB0aGUgcHJvcG9zYWwgZnJvbSBLZW50IGJlbG93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtjb2xvcjojMDAwMDk5O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzAwMDBDQyI+TWVobWV0IDxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzAwMDA5OTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu
b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g
MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdCI+IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0
Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPktlbnQgV2F0c2VuPGJyPg0KPGI+U2VudDo8L2I+
IFNhdHVyZGF5LCBBdWd1c3QgMTMsIDIwMTYgMTowMCBBTTxicj4NCjxiPlRvOjwvYj4gbmV0Y29u
ZkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW05ldGNvbmZdIHplcm90b3VjaC8x
NjogSG93IHRvIGVuY29kZSBhIGNoYWluIG9mIGNlcnRzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGlzIGlz
c3VlIHdhcyBkaXNjdXNzZWQgaW4gQmVybGluLCBidXQgbm8gZGVjaXNpb24gd2FzIHJlYWNoZWQu
Jm5ic3A7Jm5ic3A7IEhlcmUgYXJlIG15IGN1cnJlbnQgdGhvdWdodHM6PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjEu
IHVzZSBhbiBvcmRlcmVkLWJ5LXVzZXIgbGVhZi1saXN0IG9mIHRoZSBYLjUwOXYzIHN0cnVjdHVy
ZXMgZW5jb2RlZCB1c2luZyBERVI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IEkgZG9u4oCZdCB0aGluayB0aGlzIGlzIGEgZ29vZCBzb2x1dGlvbi4mbmJzcDsgSW4g
ZmFjdCwgdGhpcyBpcyB0aGUgY3VycmVudCBzb2x1dGlvbiBpbjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwO3RoZSBpZXRmLXN5c3Rl
bS1rZXljaGFpbiBtb2R1bGUsIGZvciB3aGljaCB0aGVyZSBhbHJlYWR5IGlzIGFuIG9wZW4gaXNz
dWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyB0byByZXBsYWNlIGl0IHdpdGggYmV0dGVyIHNvbHV0aW9uLiZuYnNwOyBUaGUgcmVh
c29uIHRoaXMgYXBwcm9hY2ggaXNu4oCZdCBhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
Ij4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Z29vZCBvbmUgaXMgYmVjYXVzZSB0b29s
cyBnZW5lcmFsbHkgdXNlIGZpbGUgZm9ybWF0cyB0aGF0IGVuY29kZSBtdWx0aXBsZTxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwO2Nl
cnRzIGludG8gYSBzaW5nbGUgZmlsZSAoZS5nLiwgYSAucGVtIG9yIC5wMTIgZmlsZSkgLSB0aGF0
IGlzLCBvbmUgYmxvYiAobm90IG1hbnkpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdCI+Mi4gY29uY2F0ZW5hdGUgbXVsdGlwbGUgUEVNIHRvZ2V0aGVyIHRv
IGVuY29kZSBhIGJ1bmRsZSBvZiBjZXJ0czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgRW5jb2RpbmcgYSBzaW5nbGUgY2VydGlmaWNhdGUgaW50byBhIFBFTSBlbmNvZGluZyBp
cyBkZWZpbmVkIGluIFJGQyA3NDY4LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO1NlY3Rpb24gOC4mbmJzcDsmbmJzcDsmbmJzcDsgSSBhbSBu
b3QgYWJsZSBsb2NhdGUgYSByZWZlcmVuY2UgY29uY2F0ZW5hdGluZyBtdWx0aXBsZSBQRU08bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbmNv
ZGluZ3MgaW50byBhIHNpbmdsZSBtZXNzYWdlL3N0cmluZy4mbmJzcDsmbmJzcDsgV2l0aG91dCBh
IG5vcm1hdGl2ZSByZWZlcmVuY2UsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgSeKAmW0gaGVzaXRhbnQgdG8gcmVjb21tZW5kIGdvaW5nIHRo
aXMgcm91dGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dCI+My4gdXNlIGEgUEtDUyMxMiBzdHJ1Y3R1cmUgZnJvbSBSRkMgNzI5MiB0byBlbmNvZGUgYSBi
dW5kbGUgb2YgY2VydHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IFBLQ1MjMTIgaXMgYSBmbGV4aWJsZSBmb3JtYXQgdGhhdCBjYW4gZW5jb2RlIG1hbnkgb2JqZWN0
cywgaW5jbHVkaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgd2hhdCBpcyBjYWxscyBhIOKAnENlcnRCYWfigJ0gKGkuZS4gYSBi
YWcgb2YgY2VydGlmaWNhdGVzKSBkZWZpbmVkIGluIFNlY3Rpb248bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDs0LjIuMy4gJm5ic3A7
T3BlblNTTCBjYW4gY29udmVydCB0byBhbmQgZnJvbSBhIGZpbGUgY29udGFpbmluZyBtdWx0aXBs
ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
ICZuYnNwO1BFTXMgYW5kIGEgUEtDUyMxMiBhcyBmb2xsb3dzOjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsm
bmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7IyZuYnNwOyBjYXQgcmlnaHRmdWxfb3duZXIvb3duZXJf
Y2VydC5wZW0gaW50ZXJtZWRpYXRlL2NhX2NlcnQucGVtICZndDsgb3duZXJfYnVuZGxlLnBlbTxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZu
YnNwOyMmbmJzcDsgb3BlbnNzbCBwa2NzMTIgLWV4cG9ydCAtaW4gb3duZXJfYnVuZGxlLnBlbSAt
bm9rZXlzIC1vdXQgb3duZXJfYnVuZGxlLnAxMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyMmbmJzcDsgb3BlbnNzbCBwa2NzMTIg
LWluIG93bmVyX2J1bmRsZS5wMTIgLW5vZGVzIC1vdXQgb3duZXJfYnVuZGxlLnBlbS4yPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsj
Jm5ic3A7IGRpZmYgb3duZXJfYnVuZGxlLnBlbSombmJzcDsgLy8gdGhlcmXigJlzIGEgc21hbGwg
ZGlmZmVyZW5jZSAoY29tbWVudHMgb25seSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0Ij40LiB1c2UgYSBkZWdlbmVyYXRlIFBLQ1MgIzcgc3RydWN0dXJl
IGZyb20gUkZDIDIzMTUgdG8gZW5jb2RlIGEgYnVuZGxlIG9mIGNlcnRzPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBXaGlsZSBQS0NTIzcgaXMgcHJpbWFyaWx5IHVz
ZWQgdG8gZW5jb2RlIHNpZ25lZCBkYXRhLCB0aGVyZSBpcyBhDQo8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2RlZ2VuZXJh
dGUgZm9ybSBvZiBpdCB0aGF0IGhhcyBubyBzaWduYXR1cmVzLCB3aGljaCBhY2NvcmRpbmcgdG88
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyBTZWN0aW9uIDkg4oCccHJvdmlkZXMgYSBtZWFucyBmb3IgZGlzc2VtaW5hdGluZyBjZXJ0
aWZpY2F0ZXPigJ0uIE9wZW5TU0wNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Y2FuIGNvbnZlcnQgdG8gYW5kIGZyb20g
YSBmaWxlIGNvbnRhaW5pbmcgbXVsdGlwbGUgUEVNcyBhbmQgYQ0KPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtQS0NTIzcg
YXMgZm9sbG93czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyMg
Y2F0IHJpZ2h0ZnVsX293bmVyL293bmVyX2NlcnQucGVtIGludGVybWVkaWF0ZS9jYV9jZXJ0LnBl
bSAmZ3Q7IG93bmVyX2J1bmRsZS5wZW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu
YnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsjIG9wZW5zc2wgY3JsMnBrY3M3IC1ub2NybCAt
Y2VydGZpbGUgb3duZXJfYnVuZGxlLnBlbSAtb3V0IG93bmVyX2J1bmRsZS5wN2I8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAjIG9w
ZW5zc2wgcGtjczcgLXByaW50X2NlcnRzIC1pbiBvd25lcl9idW5kbGUucDdiIC1vdXQgb3duZXJf
YnVuZGxlLnBlbS4yPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgIyBkaWZmIG93bmVyX2J1bmRsZS5wZW0qJm5ic3A7IC8vIHRoZXJl
4oCZcyBhIHNtYWxsIGRpZmZlcmVuY2UgKGNvbW1lbnRzIG9ubHkpPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+NS4gdXNlIGEg4oCYY2hvaWNl4oCZIGFy
b3VuZCBhbGwgb2YgdGhlIFBFTSBhbmQgUEtDUyM3IGFuZCBQS0NTIzEyIGZvcm1hdHM8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNob2ljZSB7
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bGVhZiBjZXJ0aWZpY2F0ZS1wZW0gezxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3R5cGUgYmluYXJ5OzxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwO308bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu
YnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtsZWFm
IGNlcnRpZmljYXRlLXBrNyB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsg
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7dHlwZSBiaW5hcnk7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJz
cDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fTxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwO2xlYWYgY2VydGlmaWNhdGUtcDEyIHs8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQiPiZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0eXBlIGJpbmFyeTs8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDt9PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjYuIHVzZSBhIOKAmGZvcm1hdOKAmSBsZWFmIHRvIGlu
ZGljYXRlIGlmDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IGNvbnRhaW5lciBjZXJ0aWZpY2F0ZSB7PG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0Ij4mbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7bGVhZiBmb3JtYXQgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7
ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwO3R5cGUgZW51bWVyYXRpb24gezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVudW0gcGVtOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVudW0gcGs3OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVudW0gcDEyOzxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi
PiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt9
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bGVhZiBkYXRhIHs8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQiPiZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0eXBlIGJpbmFyeTs8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDt9PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdCI+UmVjb21tZW5kYXRpb25zOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5i
c3A7IC0gSWYgd2UgaGF2ZSB0byBwaWNrIGp1c3Qgb25lLCBJ4oCZZCBhc2sgc2VjdXJpdHkgZXhw
ZXJ0cyB0byBwaWNrIGJldHdlZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNw
OyZuYnNwOyAmbmJzcDtwazcgYW5kIHAxMi4gJm5ic3A7Tm90ZTogcGs3IHdhcyBhIGJpdCBlYXNp
ZXIgb24gdGhlIGNvbW1hbmQgbGluZSwgaW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi
PiZuYnNwOyZuYnNwOyZuYnNwOyB0aGF0IGl0IGRpZG7igJl0IHByb21wdCBmb3IgcGFzc3dvcmQu
Jm5ic3A7IEFsc28sIHBrNyByb3VuZC10cmlwcGluZw0KPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtzdGFiaWxpemVkIGZhc3Rlci48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyAtIElmIHdl4oCZcmUgb2theSB3aXRoIGRl
dmljZXMgaGF2aW5nIHRvIHN1cHBvcnQgYWxsIGZvcm1hdHMsIHRoZW4gSQ0KPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0aGluayBzb2x1dGlv
biAjNiBpcyBiZXR0ZXIgdGhhbiAjNS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0Ij5Eb2VzIGFueW9uZSBlbHNlIGhhdmUgYW55IHRob3VnaHRzIG9uIHRo
aXM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQiPktlbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_HE1PR0701MB2859454E93CCDAA868BBB16E91100HE1PR0701MB2859_--


From nobody Mon Aug 15 11:38:02 2016
Return-Path: 
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E466C124281; Mon, 15 Aug 2016 11:38:00 -0700 (PDT)
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.29.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147128628092.31571.4239269368148893942.idtracker@ietfa.amsl.com>
Date: Mon, 15 Aug 2016 11:38:00 -0700
Archived-At: 
Cc: netconf@ietf.org
Subject: [Netconf] I-D Action: draft-ietf-netconf-restconf-16.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Aug 2016 18:38:01 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration of the IETF.

        Title           : RESTCONF Protocol
        Authors         : Andy Bierman
                          Martin Bjorklund
                          Kent Watsen
	Filename        : draft-ietf-netconf-restconf-16.txt
	Pages           : 132
	Date            : 2016-08-15

Abstract:
   This document describes an HTTP-based protocol that provides a
   programmatic interface for accessing data defined in YANG, using the
   datastore concepts defined in NETCONF.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netconf-restconf-16

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-16


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 Aug 15 11:40:09 2016
Return-Path: 
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE8C12D127; Mon, 15 Aug 2016 11:40:07 -0700 (PDT)
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.29.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147128640777.31546.5965034967964862585.idtracker@ietfa.amsl.com>
Date: Mon, 15 Aug 2016 11:40:07 -0700
Archived-At: 
Cc: netconf@ietf.org
Subject: [Netconf] I-D Action: draft-ietf-netconf-yang-patch-11.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 Aug 2016 18:40:08 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration of the IETF.

        Title           : YANG Patch Media Type
        Authors         : Andy Bierman
                          Martin Bjorklund
                          Kent Watsen
	Filename        : draft-ietf-netconf-yang-patch-11.txt
	Pages           : 41
	Date            : 2016-08-15

Abstract:
   This document describes a method for applying patches to
   configuration datastores using data defined with the YANG data
   modeling language.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-patch/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-yang-patch-11


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 Aug 15 17:01:56 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB97C12D7BA for ; Mon, 15 Aug 2016 17:01:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZ_dBjS4DuB4 for ; Mon, 15 Aug 2016 17:01:53 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0114.outbound.protection.outlook.com [104.47.42.114]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBC3912D5EC for ; Mon, 15 Aug 2016 17:01:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kDyeBpWGttb6og82m2pmR4anMVDLnKrj8Rwkk0Ge1ZQ=; b=iAwcIIdukusH4VED9sFt6Wmr7Ppn5uxmm8U1ugcY3oNL0W8c2RRgS6Zj4ykyAZPJ/ueRtNOGRsBwvEbXxLxeYRpSwdvK4q4SUVv/sWoZEw5M7gOKziGKqAUc41/UeKxxEH88JRogFO+K55SlNhaSqRlQ2dQCLch+Yrc5ocHbE3E=
Received: from DM2PR0501MB1455.namprd05.prod.outlook.com (10.161.224.152) by DM2PR0501MB1454.namprd05.prod.outlook.com (10.161.224.151) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.8; Tue, 16 Aug 2016 00:01:50 +0000
Received: from DM2PR0501MB1455.namprd05.prod.outlook.com ([10.161.224.152]) by DM2PR0501MB1455.namprd05.prod.outlook.com ([10.161.224.152]) with mapi id 15.01.0557.009; Tue, 16 Aug 2016 00:01:49 +0000
From: Kent Watsen 
To: "netconf@ietf.org" 
Thread-Topic: [Netconf] zerotouch/17: How to verify boot-image integrity?
Thread-Index: AQHR1+0zZ+YKXSlsgEa0qw/6IXOQEaANMM8AgD1/DYA=
Date: Tue, 16 Aug 2016 00:01:49 +0000
Message-ID: <3526F999-12EE-4F57-A5BB-86397D60A650@juniper.net>
References: <8C077DAC-4A77-4467-9B2E-E04F226DBBC1@juniper.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.18.0.160709
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.11]
x-ms-office365-filtering-correlation-id: e2e0284a-a6f0-4544-5c1f-08d3c568859e
x-microsoft-exchange-diagnostics: 1; DM2PR0501MB1454; 6:gOY25zMQTNNMsWLXg9U+eJLhINSI81Dsef09G2ehaGeD+qubSzQCNHw59AaZxGl4Kio47SsJlQV93MlSIGN9qjqI1I/oMTRndhacYl8TtxSYFT2RVwf8BwxcqrMKFmasSquEULfy+hMAAvt+n9peTjcsQJjcscqeMvUQ6dK9cesEmu/7WdKvNFmZW0iDsFwRDgdC+9sSMlAGS3ppYLXMs87MxBfL6eguTGKR7+Zst27HP5CVwWEUX03P+5SYnZQNz3rrN8hgdQK+vXw4yAhIzd08iaySWJnMQ4cg6kk29L104CtYqNvzhrZ6D9XwXcTg9jEUCdfRsUwXg8nyVa4TJg==; 5:LJW6Pd23CVtY34PsXwFZp/k0JJUlhsGcrgaKKHUuwpx/EdlAtxxaBU/T7mRwA+bWWjBY18GhrHTyrlL6yDh+TCpCkhMobCl3LatDu20p9AIGYOkek3CZ5VJrWzTPlQM+VzSAtzVmckIM6ExyyXTlcg==; 24:oTXD4OvWZPq5lXpQlI5ALGIme7c3bpHx9MYCVUJH5mX1XmAk07bdMkRxMwK22TbsEv3pO2W32Ml/NvfEL8shfD/luJolrfJeqGusiSvEMHM=; 7:WqLDJap32hGJj3MM+VdztX8NpACvxeaQhF6r3o3uQGzRGmXrwJvbTiy0FIBiyvpSni9goXc2mqw2FqlVBxki9B4vmSS1hDyWxMyCtNYqvnVfYXZOvU1NDS6kaAsajYHsum10edPk3+17tWyxquKSbrgX09Rrc7kKF2cR0o531R6kY7RIHqi5mENTJAEGpIW6vFqhbkJb4aflcZWXv74ctcHmClfgoIfwqvCjasjQN5LQGeLAT+lW0VMCWf/iG2Gl
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1454;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(192374486261705)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:DM2PR0501MB1454; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB1454; 
x-forefront-prvs: 0036736630
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(76104003)(199003)(2351001)(83716003)(5002640100001)(6116002)(81166006)(1730700003)(99286002)(8676002)(106356001)(81156014)(8936002)(68736007)(105586002)(82746002)(102836003)(586003)(2906002)(50986999)(76176999)(7846002)(101416001)(10400500002)(2501003)(54356999)(87936001)(36756003)(33656002)(575784001)(3846002)(7736002)(77096005)(19580395003)(450100001)(10710500007)(15650500001)(122556002)(92566002)(3660700001)(106116001)(2420400007)(19625215002)(97736004)(86362001)(19300405004)(110136002)(4001350100001)(5640700001)(107886002)(2900100001)(3280700002)(66066001)(15975445007)(16236675004)(189998001)(7110500001)(83506001)(2950100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1454; H:DM2PR0501MB1455.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_3526F99912EE4F57A5BB86397D60A650junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2016 00:01:49.6609 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1454
Archived-At: 
Subject: Re: [Netconf] zerotouch/17: How to verify boot-image integrity?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2016 00:01:55 -0000

--_000_3526F99912EE4F57A5BB86397D60A650junipernet_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhpcyBpc3N1ZSB3YXMgZGlzY3Vzc2VkIGluIEJlcmxpbi4gIFRoZSBtaW51dGVzIGNhcHR1cmUg
dGhlIGZvbGxvd2luZzoNCg0KICAgIElzc3VlICMxNzoNCiAgICBSVzogTXkgcHJlZmVyZW5jZSBp
cyBOT1QgdG8gZG8gbm90aGluZy4gSSBzdXBwb3J0IG9wdGlvbiAjMyAtIGVuY29kZSBib3RoLg0K
ICAgIEtXOiBpdCBpcyBnb29kIG5vdCB0byBoYXZlIHRvIHdvcnJ5IGFib3V0IG91dGRhdGVkIHNl
Y3VyaXR5IG1ldGhvZHMsIGhlbmNlIG9wdGlvbiAxIGlzIG5vdCBhIGdvb2QgaWRlYS4NCg0KTGlz
dGVuaW5nIHRvIHRoZSBhdWRpbyByZWNvcmRpbmcsIGl0IHNlZW1zIHRoYXQgd2Ugd2VyZSBsZWFu
aW5nIHRvd2FyZHMgb3B0aW9uICMzICAtIHRoYXQgaXMsIGEgZm9ybWF0IHRoYXQgYWxsb3dzIHVz
IHRvIHVzZSBTSEEyNTYgbm93LCBhbmQgZ3JhY2VmdWxseSBhZGQgc3VwcG9ydCBmb3IgYWRkaXRp
b25hbCBhbGdvcml0aG1zIGluIHRoZSBmdXR1cmUgaWYgbmVlZGVkLg0KDQpEdXJpbmcgdGhlIG1l
ZXRpbmcsIHdlIGRpc2N1c3NlZCBhbiBvcHRpb24gZm9yIHRoZSBTZWN1cml0eSBBcmVhIHRvIHF1
aWNrbHkgcHVibGlzaCBhIG5ldyBkcmFmdCBkZWZpbmluZyBhIGdlbmVyaWMgaGFzaGluZyBmb3Jt
YXQsIGJ1dCBJ4oCZbSBub3Qgc3VyZSBpZiBpdOKAmXMgbmVlZGVkLCBhcyBpdCBzZWVtcyB0aGF0
IHdlIGNvdWxkIG1vcmUgZWFzaWx5IGRvIGl0IHVzaW5nIGEg4oCYY2hvaWNl4oCZIHN0YXRlbWVu
dCBhcyBmb2xsb3dzOg0KDQogICAgIGNvbnRhaW5lciBib290LWltYWdlIHsNCiAgICAgICAgbGVh
ZiBuYW1lIHsNCiAgICAgICAgICAgdHlwZSBzdHJpbmc7DQogICAgICAgIH0NCiAgICAgICAgY2hv
aWNlIG5hbWUgew0KICAgICAgICAgICBsZWFmIHNoYTI1NiB7ICAgICAgPC0tLSB0aGlzIHdvdWxk
IGJlIHRoZSBvbmx5IGNob2ljZSBmb3Igbm93DQogICAgICAgICAgICAgIHR5cGUgc3RyaW5nOw0K
ICAgICAgICAgICB9DQogICAgICAgICAgIG1hbmRhdG9yeSB0cnVlOw0KICAgICAgICB9DQogICAg
ICAgIDxzbmlwLz4NCiAgICAgfQ0KDQpJbiB0aGlzIHdheSwgZnV0dXJlIHJldmlzaW9ucyBvZiB0
aGUgbW9kdWxlIGNhbiBhZGQgbmV3IOKAmGNhc2XigJkgc3RhdGVtZW50cy4gIFRoaXMgc29sdXRp
b24gcmVzdWx0cyBpbiBhIHNpbXBsZSBpbnN0YW5jZSBlbmNvZGluZywgZm9yIGV4YW1wbGU6DQoN
CiAgPGJvb3QtaW1hZ2U+DQogICAgIDxuYW1lPmJvb3QtaW1hZ2UtdjMuMlIxLjYuaW1nPC9uYW1l
Pg0KICAgIDxzaGEyNTY+OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWEwYzU1YWQwMTVhM2JmNGYxYjJi
MGI4MjJjZDE1ZDZjMTViMGYwMGEwODwvc2hhMjU2Pg0KICAgIC4uLg0KICA8L2Jvb3QtaW1hZ2U+
DQoNCg0KV2hhdCBkbyB5b3UgdGhpbms/ICBJ4oCZbGwgYXNzdW1lIHRoaXMgaXMgb2theSBJZiBu
byBvYmplY3Rpb25zIGFyZSByYWlzZWQgYnkgdGhlIGVuZCBvZiB0aGlzIHdlZWsuDQoNClRoYW5r
cywNCktlbnQNCg0KDQoNCg==

--_000_3526F99912EE4F57A5BB86397D60A650junipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: <4D9E07C0306E2143BBA2630D40911BBE@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm
b250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7
bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1k
ZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z
by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y
ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp
biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv
c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9
ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OkNhbGlicmkiPlRoaXMgaXNzdWUgd2FzIGRpc2N1c3NlZCBpbiBCZXJsaW4uJm5ic3A7IFRoZSBt
aW51dGVzIGNhcHR1cmUgdGhlIGZvbGxvd2luZzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4m
bmJzcDsmbmJzcDsmbmJzcDsgSXNzdWUgIzE3OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyBSVzogTXkgcHJlZmVyZW5jZSBpcyBOT1QgdG8g
ZG8gbm90aGluZy4gSSBzdXBwb3J0IG9wdGlvbiAjMyAtIGVuY29kZSBib3RoLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyBLVzogaXQgaXMg
Z29vZCBub3QgdG8gaGF2ZSB0byB3b3JyeSBhYm91dCBvdXRkYXRlZCBzZWN1cml0eSBtZXRob2Rz
LCBoZW5jZSBvcHRpb24gMSBpcyBub3QgYSBnb29kIGlkZWEuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2Fs
aWJyaSI+TGlzdGVuaW5nIHRvIHRoZSBhdWRpbyByZWNvcmRpbmcsIGl0IHNlZW1zIHRoYXQgd2Ug
d2VyZSBsZWFuaW5nIHRvd2FyZHMgb3B0aW9uICMzJm5ic3A7IC0gdGhhdCBpcywgYSBmb3JtYXQg
dGhhdCBhbGxvd3MgdXMgdG8gdXNlIFNIQTI1NiBub3csIGFuZCBncmFjZWZ1bGx5IGFkZCBzdXBw
b3J0IGZvciBhZGRpdGlvbmFsIGFsZ29yaXRobXMNCiBpbiB0aGUgZnV0dXJlIGlmIG5lZWRlZC4m
bmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+RHVyaW5nIHRoZSBtZWV0aW5nLCB3ZSBk
aXNjdXNzZWQgYW4gb3B0aW9uIGZvciB0aGUgU2VjdXJpdHkgQXJlYSB0byBxdWlja2x5IHB1Ymxp
c2ggYSBuZXcgZHJhZnQgZGVmaW5pbmcgYSBnZW5lcmljIGhhc2hpbmcgZm9ybWF0LCBidXQgSeKA
mW0gbm90IHN1cmUgaWYgaXTigJlzIG5lZWRlZCwgYXMgaXQgc2VlbXMgdGhhdCB3ZSBjb3VsZA0K
IG1vcmUgZWFzaWx5IGRvIGl0IHVzaW5nIGEg4oCYY2hvaWNl4oCZIHN0YXRlbWVudCBhcyBmb2xs
b3dzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBj
b250YWluZXIgYm9vdC1pbWFnZSB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy
aSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxlYWYgbmFtZSB7
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGUgc3RyaW5nOzxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2Fs
aWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO2Nob2ljZSBu
YW1lIHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbGVhZiBzaGEy
NTYgeyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7LS0tIHRoaXMgd291bGQgYmUg
dGhlIG9ubHkgY2hvaWNlIGZvciBub3c8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp
YnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dHlwZSBzdHJpbmc7PG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwO308bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD
YWxpYnJpIj4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7bWFuZGF0b3J5IHRydWU7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO308bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O3NuaXAvJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6Q2FsaWJyaSI+SW4gdGhpcyB3YXksIGZ1dHVyZSByZXZpc2lvbnMgb2YgdGhlIG1vZHVsZSBj
YW4gYWRkIG5ldyDigJhjYXNl4oCZIHN0YXRlbWVudHMuJm5ic3A7IFRoaXMgc29sdXRpb24gcmVz
dWx0cyBpbiBhIHNpbXBsZSBpbnN0YW5jZSBlbmNvZGluZywgZm9yIGV4YW1wbGU6PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7ICZsdDtib290LWltYWdlJmd0OzxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7bmFt
ZSZndDtib290LWltYWdlLXYzLjJSMS42LmltZyZsdDsvbmFtZSZndDs8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7c2hhMjU2
Jmd0OzlmODZkMDgxODg0YzdkNjU5YTJmZWFhMGM1NWFkMDE1YTNiZjRmMWIyYjBiODIyY2QxNWQ2
YzE1YjBmMDBhMDgmbHQ7L3NoYTI1NiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD
YWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsuLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsgJmx0Oy9ib290LWltYWdlJmd0OzxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmki
PldoYXQgZG8geW91IHRoaW5rPyZuYnNwOyBJ4oCZbGwgYXNzdW1lIHRoaXMgaXMgb2theSBJZiBu
byBvYmplY3Rpb25zIGFyZSByYWlzZWQgYnkgdGhlIGVuZCBvZiB0aGlzIHdlZWsuPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6Q2FsaWJyaSI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNh
bGlicmkiPktlbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_3526F99912EE4F57A5BB86397D60A650junipernet_--


From nobody Tue Aug 16 12:27:18 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C208212B00B; Tue, 16 Aug 2016 12:27:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.148
X-Spam-Level: 
X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-JyCUaPcFOw; Tue, 16 Aug 2016 12:27:14 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83BBD12D739; Tue, 16 Aug 2016 12:27:14 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A5D98200A5; Tue, 16 Aug 2016 15:38:15 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 01C58639DC; Tue, 16 Aug 2016 15:27:13 -0400 (EDT)
From: Michael Richardson 
To: anima-bootstrap 
X-Attribution: mcr
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Archived-At: 
Cc: netconf 
Subject: [Netconf] minutes for anima-bootstrap design team meeting, 2016-08-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: anima-bootstrap 
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2016 19:27:17 -0000

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


We return to weekly meetings after a few weeks off for vacations and IETF96.

WEEKLY INVITE, SEE ANIMA BOOTSTRAP WIKI: https://trac.tools.ietf.org/wg/ani=
ma/trac/wiki/Bootstrap

2016-08-16:
    present: mcr, max, kent, toerless, P. Kampanakis

We had three items on our agenda:
   1) recap on, do we need/want to write up an example ownership voucher.
   2) the level of detail/protocol around getting =C2=A0 the pledge to put =
the
      "right things" into the CSR.
   3) draft-pritikin-coap-bootstrap-00

I think that Kampanakis joined after I asked he was joining our team, being=
 a
co-author of coap-bootstrap.  He is a Cisco person with ties to the EST
implementations at Cisco.

We started on item one, which was the question as to whether or not we need=
ed
to have a standards track document that defined the onwership voucher.

The tl;dr conclusion was that we do need a document, but that it could be
Informational.  That it should be a WG product, not an independent
submission.  We did not rule out a standards track document as yet.

The ownership voucher, as conceived by
   draft-ietf-anima-bootstrapping-keyinfra-03#section-5.3

is created by the manufacturer, "signed" with a key the manufacturer posses=
ses,
and then is verified by the device which the manufacturer created.  The word
"signed" is in quotes, because it does not have to be asymmetrically signed.
The exact details are essentially private to the manufacturer.

The netconf ownership voucher, as explained at:
    https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-09#appendix-A.1

describes a sample voucher in YANG.  Netconf is mostly consistent with the
view that voucher is a private matter, however there are some situations in
netconf where it may be necessary to distinguish one voucher from another.
In most cases (DHCP, HTTP) it is possible for the provider of boot
information to return a voucher specific to the device asking, but in the
DNSSD situation, the responder can not really provide customized replies,
so the likely reply is a set of group vouchers.  This requires that the
booting device be able to sort through the replies looking for one which
applies to it.  This requires some structure to the voucher, even if most
of the voucher can be proprietary.

In the ANIMA situation, there is an additional situation where we something
very similiar to the voucher, which is in the log provided by the MASA!
The MASA audit log is essentially a record of vouchers which have been
observed.

In discussion, we further acknowledge that in order to debug things in the
field, knowing what is in the voucher would aid greatly in diagnosing
systems.

We further discussed the question as to whether or not there were
confidentiality or privacy issues.  We conclude that:
   We believe there is no confidentiality requirement for vouchers.

   i.e. nothing breaks in the micro-cosm of a single device enrollment.

In the macro-cosm of thousands of devices and thousands of ownership
vouchers being observed, there are quite possibly privacy issues.

We do not think that we can or should encrypt the vouchers themselves; the
key management problem is large if each are encrypted seperately, and
if asymmetrically encrypted, then diagnostics are out.

We came up with three possible actions:
   3 paths forward:
     a) treat this as a hard requirement
     b) try to leave the door open for future work here
     c) declare totally out of scope.

proposed decision: (b) try to keep the door open but not address at this ti=
me.




=2D-
Michael Richardson , Sandelman Software Works
 -=3D IPv6 IoT consulting =3D-




--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEVAwUBV7NpDoCLcPvd0N1lAQL2Sgf+MZC2M/8x/oiy0WoTtnOx+zQNCQh0IqwJ
8j7ibG01BJ7+L/pHmXn30mZfc7hpR4O6mAI7hbqu+mQfcl2U8MdanoNyVL3mqfD6
TwnG4YNi6Jz06T6bLv/Cs5sz+475JuH6IjtINeUIUN8fzW5/O5cf4aKQ1EmXfXFo
V+u4rn4j9zMwR8UdEb+enOLOjRsq6DPAXibuFItFLuz0ocxsLgoBYNPpfOmCEpYb
OZIfG+4Z3OiU8E5ehUt9Y43JeX6GQO9iOT4cEzkuaOef8yHkJ42jvcg8pdoUQ63y
v8YWKnYDCNq3tWD0iYDh8+14lztAhVAMEp/atcHiUNcO6g2+KW/kuw==
=XmD3
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Tue Aug 16 13:34:11 2016
Return-Path: 
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 483D5126D74; Tue, 16 Aug 2016 13:34:09 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Meeting Session Request Tool\"" 
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.29.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147137964926.22952.16848048568304624086.idtracker@ietfa.amsl.com>
Date: Tue, 16 Aug 2016 13:34:09 -0700
Archived-At: 
Cc: netconf-chairs@ietf.org, netconf@ietf.org
Subject: [Netconf] netconf - New Meeting Session Request for IETF 97
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2016 20:34:09 -0000

A new meeting session request has just been submitted by Mahesh Jethanandani, a Chair of the netconf working group.


---------------------------------------------------------
Working Group Name: Network Configuration
Area Name: Operations and Management Area
Session Requester: Mahesh Jethanandani

Number of Sessions: 1
Length of Session(s):  2 Hours
Number of Attendees: 100
Conflicts to Avoid: 
 First Priority: netmod opsarea opsawg
 Second Priority: i2nsf sfc i2rs nmrg lmap radext dime nfvrg sdnrg
 Third Priority: sacm tls 6lo 6tisch v6ops intarea tsvarea apparea saag anima


Special Requests:
  Please schedule session on Thursday.
Friday is NOT possible for Netconf.
Please avoid a conflict with vnfrg.
(added i2nsf as a conflict per Benoit)

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


From nobody Tue Aug 16 14:11:01 2016
Return-Path: 
X-Original-To: netconf@ietf.org
Delivered-To: netconf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADCC12D127; Tue, 16 Aug 2016 14:11:00 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Meeting Session Request Tool\"" 
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.29.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147138186013.22880.890991653448778660.idtracker@ietfa.amsl.com>
Date: Tue, 16 Aug 2016 14:11:00 -0700
Archived-At: 
Cc: netconf-chairs@ietf.org, netconf@ietf.org
Subject: [Netconf] netconf - Update to a Meeting Session Request for IETF 97
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2016 21:11:00 -0000

An update to a meeting session request has just been submitted by Mehmet Ersue, a Chair of the netconf working group.


---------------------------------------------------------
Working Group Name: Network Configuration
Area Name: Operations and Management Area
Session Requester: Mehmet Ersue

Number of Sessions: 1
Length of Session(s):  2 Hours
Number of Attendees: 100
Conflicts to Avoid: 
 First Priority: netmod opsarea opsawg
 Second Priority: i2nsf sfc i2rs nmrg supa lmap radext dime core nfvrg sdnrg
 Third Priority: sacm tls 6lo 6tisch v6ops saag anima


Special Requests:
  Please schedule session on Thursday.
Friday is NOT possible for Netconf.
(i2nsf supa lmap radext dime as a conflict per Benoit)

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


From nobody Tue Aug 16 15:06:20 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73AB12D873 for ; Tue, 16 Aug 2016 15:06:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zJVe4Kc7zok for ; Tue, 16 Aug 2016 15:06:15 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0123.outbound.protection.outlook.com [104.47.42.123]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 722CC12D785 for ; Tue, 16 Aug 2016 15:06:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SFzL3pfW5jvKr3S2TeAZd0DyyZSwK28NX3sL5SP13oU=; b=hBRFvbuHMazWhrxa5mwJtWdGTxT+hzm1wn4r9uRMefIb0cBAhQj43qXCWBkpoiG7Fcfpc9HbxoAb9SVgoSmBXyJUSmqlg76+MnVDFdVbBs5wZLGmWfbLvjWJ6MA8Q7xbhQhpqGlI4oegIrutCSCDQynZNSLJ8E7bReBNg+f7YYc=
Received: from DM2PR0501MB1455.namprd05.prod.outlook.com (10.161.224.152) by DM2PR0501MB1454.namprd05.prod.outlook.com (10.161.224.151) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.8; Tue, 16 Aug 2016 22:06:12 +0000
Received: from DM2PR0501MB1455.namprd05.prod.outlook.com ([10.161.224.152]) by DM2PR0501MB1455.namprd05.prod.outlook.com ([10.161.224.152]) with mapi id 15.01.0557.009; Tue, 16 Aug 2016 22:06:13 +0000
From: Kent Watsen 
To: "netconf@ietf.org" 
Thread-Topic: =?utf-8?B?W05ldGNvbmZdIHplcm90b3VjaC8xMTogT3duZXJzaGlwIFZvdWNoZXIg4oCT?= =?utf-8?Q?_formally_define=3F?=
Thread-Index: AQHR0luDrStCCWc4KU2Ev5oCeFbVpqBMLQcA
Date: Tue, 16 Aug 2016 22:06:13 +0000
Message-ID: 
References: <15A40A51-6FBE-4952-98ED-C92EBDFB6373@juniper.net>
In-Reply-To: <15A40A51-6FBE-4952-98ED-C92EBDFB6373@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.18.0.160709
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.11]
x-ms-office365-filtering-correlation-id: d367c675-5b10-4ec0-8e4e-08d3c6218981
x-microsoft-exchange-diagnostics: 1; DM2PR0501MB1454; 6:ac1GKZ0NnCYKjIhIIMRbX0A7ReMXewq9zd6BHSg/cJhZs8/oqmAX7cjwaMzO9ZYlqxI3mLg5K4lA/dKdnQrQhKgn7vtJQWpjAEbS0zgl1XNgX/RpDPHNiuadulBlo3q4Lb0X9QfKbXsGfADlzbP41mDUQD2O0UdjFJz4MBO+RyJYFiG04U9OZaHNuoDHhLSF50oktEcA6Gr85lwb/pGH3zYoWP0zrezsSA+ZjzR9OZ+u4Vqm0cHaUyEMvg1irt2yRpdw6SNl94Z68wBCu0ifpW8hJL7vbL0djuMDBBetZxvKg/WGKkdLxoMbOS6/ixPIg6pkx0r45zASRc2N50asUA==; 5:7u1Dkl6Ir8Q3/+CoioxKNQmgB8en9cVDInOAVprxY+xHSEZ3AbvW+sXG+QLZYU93GTkgmR+ibjHp5JLTMY7Q8mJLvEE0pUxsF+Ka5FcQuCa5htW5CQ/6GIEJMO/Q/o8NIAP2+9ZRV0n+4xXh4+DPtA==; 24:redrDAY3s6aysJh63aqrkIaNFW1t80Zm1sI3smd1+DAeF2DC4tq25ST66DSUmp316m1/Ke/PqF29BCrmReV6Mc/8PRSUytRvBXLw++QjKfY=; 7:buuzhM0E5T2XYUUD0f3QrT44Efl90SGom4rI14z+P0DAeQZ1bWodNo3L3Bprt7BwyV7bNewqVMV+A39cMd4OOfPZC9lWY/+sSckDFlrIA/cGPo0p3WfYYP9rOC1Za/PM1J9tFv3o9j3CQyajKR73bfgtxr8xuw+Xj3P8qNe4/0MPE0HpNZAVIpoyNsGxqdkAIZ1G6DxrxK7x0Fvi0hx/8U7wYYQgfA0QcMD8DvTD0JIciK1T8LcwwTx1Vr7pC+Z+
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1454;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(60795455431006)(166708455590820)(138986009662008)(21748063052155); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:DM2PR0501MB1454; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB1454; 
x-forefront-prvs: 0036736630
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(377454003)(199003)(561944003)(5002640100001)(83716003)(6116002)(122556002)(1730700003)(81166006)(2351001)(2906002)(99286002)(106356001)(81156014)(19580405001)(68736007)(105586002)(102836003)(8936002)(82746002)(586003)(50986999)(2501003)(54356999)(87936001)(76176999)(7846002)(10400500002)(101416001)(36756003)(7736002)(3846002)(19580395003)(77096005)(450100001)(106116001)(33656002)(3660700001)(19625215002)(97736004)(19300405004)(110136002)(92566002)(86362001)(5640700001)(4001350100001)(15975445007)(2900100001)(66066001)(16236675004)(2950100001)(3280700002)(83506001)(189998001)(107886002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1454; H:DM2PR0501MB1455.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_F6B44B1E5D6E4B968861945A2428A354junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2016 22:06:13.0359 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1454
Archived-At: 
Subject: Re: [Netconf] =?utf-8?q?zerotouch/11=3A_Ownership_Voucher_=E2=80=93_f?= =?utf-8?q?ormally_define=3F?=
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2016 22:06:19 -0000

--_000_F6B44B1E5D6E4B968861945A2428A354junipernet_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QW5vdGhlciB1cGRhdGUuICBUaGlzIGlzc3VlIHdhcyBkaXNjdXNzZWQgZm9yIGFib3V0IGFuIGhv
dXIgdGhpcyBtb3JuaW5nIHdpdGggQU5JTUEgZm9sa3MgKE1pY2hhZWwgc2VudCBtaW51dGVzKS4g
IE9uZSB0aGluZyB0aGF0IGNhbWUgb3V0IG9mIGl0LCBmb3IgdXMgYXQgbGVhc3QsIGlzIHRoYXQg
dGhlcmUgaXMgYSBuZWVkIHRvIGZvcm1hbGx5IGRlZmluZSBhbiBvd25lcnNoaXAgdm91Y2hlciBm
b3JtYXQgc28gdGhhdDoNCg0KICAxLiBzbyB0aGF0IGEgRE5TLVNEIHJlc3BvbnNlIGNhbiBhcHBs
eSB0byBtdWx0aXBsZSB2ZW5kb3IgZGV2aWNlcw0KICAyLiBzbyB0aGF0IHRoZSB2b3VjaGVyIGNh
biBiZSB2aWV3ZWQgb3V0c2lkZSBvZiB0aGUgYm9vdHN0cmFwcGluZyBpbmZyYXN0cnVjdHVyZSAo
ZS5nLiwgZm9yIGRlYnVnZ2luZykNCg0KU28sIHRvIHRoZSBxdWVzdGlvbiBhc2tlZCBieSB0aGUg
c3ViamVjdCBsaW5lLCB0aGUgYW5zd2VyIHNlZW1zIHRvIGJlIOKAnHllc+KAnSAocGxlYXNlIG9i
amVjdCB3aXRoaW4gYSB3ZWVrIGlmIHlvdSBkaXNhZ3JlZSkuICBPZiBjb3Vyc2UsIG5vdyB3ZSBo
YXZlIHRvIGRvIHRoZSBoYXJkIHBhcnQgb2YgZGVmaW5pbmcgd2hhdCB0aGF0IGZvcm1hdCBpcywg
YW5kIHRvIHdoYXQgZXh0ZW50IGl04oCZcyBzaGFyZWQgd2l0aCB0aGUgQU5JTUEgc29sdXRpb24u
ICBUaGlzIHdpbGwgYmUgZGlzY3Vzc2VkIGZ1cnRoZXIgaW4gbmV4dCB3ZWVr4oCZcyBBTklNQSBj
YWxsLCBzdGF5IHR1bmVkIQ0KDQpUaGFua3MsDQpLZW50DQoNCg0KRnJvbTogTmV0Y29uZiA8bmV0
Y29uZi1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgS2VudCBXYXRzZW4gPGt3YXRzZW5A
anVuaXBlci5uZXQ+DQpEYXRlOiBXZWRuZXNkYXksIEp1bmUgMjksIDIwMTYgYXQgNzoxMSBQTQ0K
VG86ICJuZXRjb25mQGlldGYub3JnIiA8bmV0Y29uZkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb
TmV0Y29uZl0gemVyb3RvdWNoLzExOiBPd25lcnNoaXAgVm91Y2hlciDigJMgZm9ybWFsbHkgZGVm
aW5lPw0KDQoNClVwZGF0ZTogVGhpcyBpc3N1ZSBoYXMgYmVlbiBkaXNjdXNzZWQgd2l0aCB0aGUg
QU5JTUEgZm9sa3MuICBUaGUgY3VycmVudCBwcm9wb3NhbCBpczoNCg0KT0xEOg0KICAgbW9kdWxl
OiBpZXRmLXplcm90b3VjaC1vd25lcnNoaXAtdm91Y2hlcg0KICAgICAgKy0tcncgdm91Y2hlcg0K
ICAgICAgICAgKy0tcncgb3duZXItaWQgICAgICBzdHJpbmcNCiAgICAgICAgICstLXJ3IHVuaXF1
ZS1pZCogICAgc3RyaW5nDQogICAgICAgICArLS1ydyBjcmVhdGVkLW9uICAgIHlhbmc6ZGF0ZS1h
bmQtdGltZQ0KICAgICAgICAgKy0tcncgZXhwaXJlcy1vbj8gICB5YW5nOmRhdGUtYW5kLXRpbWUN
CiAgICAgICAgICstLXJ3IHNpZ25hdHVyZSAgICAgc3RyaW5nDQoNCk5FVzoNCiAgICAgbW9kdWxl
OiBpZXRmLXplcm90b3VjaC1vd25lcnNoaXAtdm91Y2hlcg0KICAgICAgKy0tcncgdm91Y2hlcg0K
ICAgICAgICAgKy0tcncgb3duZXItaWQgICAgICAgICAgIHN0cmluZw0KICAgICAgICAgKy0tcncg
dW5pcXVlLWlkKiAgICAgICAgIHN0cmluZyAgICAgICAgICAgICAgICAgICAgLy8gQU5JTUEgd291
bGQgYWx3YXlzIGhhdmUganVzdCAxIGxpc3QgZW50cnkNCiAgICAgICAgICstLXJ3IG5vbmNlPyAg
ICAgICAgICAgICB1bml0NjQgICAgICAgICAgICAgICAgICAgIC8vIG9ubHkgQU5JTUEgd291bGQg
dXNlIHRoaXMgbm9uY2UgZmllbGQNCiAgICAgICAgICstLXJ3IHZlcmlmaWNhdGlvbi10eXBlICBl
bnVtIHt2ZXJpZmllZCwgbG9nZ2VkKSAgIC8vIE5FVENPTkYgd291bGQgYWx3YXlzIGJlIFZFUklG
SUVEDQogICAgICAgICArLS1ydyBjcmVhdGVkLW9uICAgICAgICAgeWFuZzpkYXRlLWFuZC10aW1l
DQogICAgICAgICArLS1ydyBleHBpcmVzLW9uPyAgICAgICAgeWFuZzpkYXRlLWFuZC10aW1lDQoN
CkFzIGNvbXBhcmVkIHRvIEFOSU1B4oCZcyBjdXJyZW50IOKAmHZvdWNoZXLigJkgZm9ybWF0Og0K
ICAgew0KICAgIm5vbmNlIjoiPDY0Yml0IG5vbmNlIHZhbHVlPiIsDQogICAic2VyaWFsbnVtYmVy
IjoiPHN0cmluZyB2YWx1ZT4iLCAgICAtLT4gdW5pcXVlLWlkDQogICAiZG9tYWluSUQiOjxkb21h
aW5JRCB2YWx1ZT4gICAgICAgIC0tPiBvd25lci1pZA0KICAgIH0NCg0KDQpUaGlzIG9uZSBsaWtl
bHkgbmVlZHMgbW9yZSBkaXNjdXNzaW9uLCBidXQgd291bGQgbG92ZSB0byBoZWFyIG9waW5pb25z
IG5vdy4uLg0KDQpLZW50DQoNCg0KDQpGcm9tOiBOZXRjb25mIDxuZXRjb25mLWJvdW5jZXNAaWV0
Zi5vcmc+IG9uIGJlaGFsZiBvZiBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4NCkRh
dGU6IFdlZG5lc2RheSwgTWF5IDExLCAyMDE2IGF0IDY6NTcgUE0NClRvOiAibmV0Y29uZkBpZXRm
Lm9yZyIgPG5ldGNvbmZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbTmV0Y29uZl0gemVyb3RvdWNoLzEx
OiBPd25lcnNoaXAgVm91Y2hlciDigJMgZm9ybWFsbHkgZGVmaW5lPw0KDQoNCmh0dHBzOi8vZ2l0
aHViLmNvbS9uZXRjb25mLXdnL3plcm8tdG91Y2gvaXNzdWVzLzExDQoNClRoaXMgaXNzdWUgcmVn
YXJkcyB0aGUgZm9ybWF0IG9mIHRoZSBvd25lcnNoaXAgdm91Y2hlci4gIFRoZSBjdXJyZW50IGRy
YWZ0IGRlZmluZXMgdGhlIG93bmVyc2hpcCB2b3VjaGVyIGFzIGEgdmVuZG9yLXNwZWNpZmljIGZv
cm1hdCwgYnV0IHRoZXJlIG1heSBiZSBhIGRlc2lyZSB0byBkZWZpbmUgYSBub3JtYXRpdmUgZm9y
bWF0LCBzbyB0aGF0IGl0IGhlbHBzIHdpdGggRE5TLVNEIGFzIHdlbGwgYXMgd2l0aCB0aGUgQU5J
TUEgYm9vdHN0cmFwcGluZyBhcHByb2FjaC4NCg0KQ3VycmVudGx5IHRoaXMgaXRlbSBpcyBvbiB0
aGUgQU5JTUEgYm9vdHN0cmFwcGluZyB0ZWFtJ3MgYWdlbmRhIHRvIGRpc2N1c3MgaW4gYW4gdXBj
b21pbmcgbWVldGluZy4gIEl0J3MgcHJvYmFibHkgYmVzdCB0byBkZWZlciBkaXNjdXNzaW9uIG9u
IHRoaXMgaXNzdWUgdW50aWwgYWZ0ZXIgdGhlIEFOSU1BIGZvbGtzIGhhdmUgZGlzY3Vzc2VkIGl0
LiAgSSB3aWxsIHNlbmQgYW4gdXBkYXRlIHRvIHRoZSBsaXN0IHdpdGggdGhlIHJlc3VsdHMgb2Yg
dGhhdCBkaXNjdXNzaW9uIGFzIHNvb24gYXMgSSBjYW4uDQoNCg0KDQpSZWdhcmRzLA0KDQpLZW50
DQoNCg0K

--_000_F6B44B1E5D6E4B968861945A2428A354junipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: <56481D143108F444A6DF2270E5535177@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls
eToiSGVsdmV0aWNhIE5ldWUiOw0KCXBhbm9zZS0xOjIgMCA1IDMgMCAwIDAgMiAwIDQ7fQ0KQGZv
bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIg
NCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v
cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw
dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30N
CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv
bG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw
YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y
OiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwg
bGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5
OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1h
cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OkNh
bGlicmk7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN
CgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt
ZXMgTmV3IFJvbWFuIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJz
b25hbDsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5F
bWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p
bHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXtt
c28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7
DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0K
c3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5h
bWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29D
aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w
cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox
LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl
Y3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFu
Zz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9Ildv
cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5Bbm90aGVyIHVwZGF0ZS4mbmJzcDsgVGhpcyBp
c3N1ZSB3YXMgZGlzY3Vzc2VkIGZvciBhYm91dCBhbiBob3VyIHRoaXMgbW9ybmluZyB3aXRoIEFO
SU1BIGZvbGtzIChNaWNoYWVsIHNlbnQgbWludXRlcykuJm5ic3A7IE9uZSB0aGluZyB0aGF0IGNh
bWUgb3V0IG9mIGl0LCBmb3IgdXMgYXQgbGVhc3QsIGlzIHRoYXQgdGhlcmUgaXMgYSBuZWVkDQog
dG8gZm9ybWFsbHkgZGVmaW5lIGFuIG93bmVyc2hpcCB2b3VjaGVyIGZvcm1hdCBzbyB0aGF0Ojxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyAxLiBzbyB0aGF0IGEgRE5TLVNEIHJlc3Bv
bnNlIGNhbiBhcHBseSB0byBtdWx0aXBsZSB2ZW5kb3IgZGV2aWNlczxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyAyLiBzbyB0aGF0IHRoZSB2b3VjaGVyIGNhbiBi
ZSB2aWV3ZWQgb3V0c2lkZSBvZiB0aGUgYm9vdHN0cmFwcGluZyBpbmZyYXN0cnVjdHVyZSAoZS5n
LiwgZm9yIGRlYnVnZ2luZyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5TbywgdG8gdGhlIHF1
ZXN0aW9uIGFza2VkIGJ5IHRoZSBzdWJqZWN0IGxpbmUsIHRoZSBhbnN3ZXIgc2VlbXMgdG8gYmUg
4oCceWVz4oCdIChwbGVhc2Ugb2JqZWN0IHdpdGhpbiBhIHdlZWsgaWYgeW91IGRpc2FncmVlKS4m
bmJzcDsgT2YgY291cnNlLCBub3cgd2UgaGF2ZSB0byBkbyB0aGUgaGFyZCBwYXJ0IG9mIGRlZmlu
aW5nIHdoYXQgdGhhdA0KIGZvcm1hdCBpcywgYW5kIHRvIHdoYXQgZXh0ZW50IGl04oCZcyBzaGFy
ZWQgd2l0aCB0aGUgQU5JTUEgc29sdXRpb24uJm5ic3A7IFRoaXMgd2lsbCBiZSBkaXNjdXNzZWQg
ZnVydGhlciBpbiBuZXh0IHdlZWvigJlzIEFOSU1BIGNhbGwsIHN0YXkgdHVuZWQhPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6Q2FsaWJyaSI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNh
bGlicmkiPktlbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0
REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+RnJvbTog
PC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNr
Ij5OZXRjb25mICZsdDtuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBL
ZW50IFdhdHNlbiAmbHQ7a3dhdHNlbkBqdW5pcGVyLm5ldCZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+
V2VkbmVzZGF5LCBKdW5lIDI5LCAyMDE2IGF0IDc6MTEgUE08YnI+DQo8Yj5UbzogPC9iPiZxdW90
O25ldGNvbmZAaWV0Zi5vcmcmcXVvdDsgJmx0O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+
U3ViamVjdDogPC9iPlJlOiBbTmV0Y29uZl0gemVyb3RvdWNoLzExOiBPd25lcnNoaXAgVm91Y2hl
ciDigJMgZm9ybWFsbHkgZGVmaW5lPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OkNhbGlicmkiPlVwZGF0ZTogVGhpcyBpc3N1ZSBoYXMgYmVlbiBkaXNjdXNzZWQgd2l0
aCB0aGUgQU5JTUEgZm9sa3MuJm5ic3A7IFRoZSBjdXJyZW50IHByb3Bvc2FsIGlzOjwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OkNhbGlicmkiPk9MRDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25z
b2xhcyI+Jm5ic3A7Jm5ic3A7IG1vZHVsZTogaWV0Zi16ZXJvdG91Y2gtb3duZXJzaGlwLXZvdWNo
ZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyB2b3VjaGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6Q29uc29sYXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyAmIzQzOy0tcncgb3duZXItaWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
c3RyaW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgdW5pcXVlLWlk
KiZuYnNwOyZuYnNwOyAmbmJzcDtzdHJpbmc8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD
b25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
ICYjNDM7LS1ydyBjcmVhdGVkLW9uJm5ic3A7Jm5ic3A7Jm5ic3A7IHlhbmc6ZGF0ZS1hbmQtdGlt
ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IGV4cGlyZXMtb24/Jm5i
c3A7Jm5ic3A7IHlhbmc6ZGF0ZS1hbmQtdGltZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OkNvbnNvbGFzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgJiM0MzstLXJ3IHNpZ25hdHVyZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzdHJpbmc8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTpDYWxpYnJpIj5ORVc6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
Q2FsaWJyaSI+Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+bW9kdWxlOiBpZXRmLXplcm90b3Vj
aC1vd25lcnNoaXAtdm91Y2hlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFz
Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHZvdWNoZXI8L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBvd25lci1pZCZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtzdHJpbmc8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyB1bmlxdWUtaWQqJm5ic3A7Jm5i
c3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3N0cmluZyZuYnNwOyZuYnNw
OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsvLyBBTklNQSB3
b3VsZCBhbHdheXMgaGF2ZSBqdXN0IDEgbGlzdCBlbnRyeTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgJiM0MzstLXJ3IG5vbmNlPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt1bml0NjQmbmJzcDsgJm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Ly8gb25seSBB
TklNQSB3b3VsZCB1c2UgdGhpcyBub25jZSBmaWVsZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OkNvbnNvbGFzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgJiM0MzstLXJ3IHZlcmlmaWNhdGlvbi10eXBlJm5ic3A7IGVudW0ge3ZlcmlmaWVkLCBs
b2dnZWQpJm5ic3A7Jm5ic3A7IC8vIE5FVENPTkYgd291bGQgYWx3YXlzIGJlIFZFUklGSUVEPC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgY3JlYXRlZC1vbiZuYnNwOyZu
YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt5YW5nOmRhdGUtYW5kLXRp
bWU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBleHBpcmVzLW9uPyZu
YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt5YW5nOmRhdGUtYW5kLXRp
bWU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5BcyBjb21wYXJlZCB0byBBTklNQeKAmXMgY3Vy
cmVudCDigJh2b3VjaGVy4oCZIGZvcm1hdDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD
YWxpYnJpIj4mbmJzcDsmbmJzcDsgezwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGli
cmkiPiZuYnNwOyZuYnNwOyAmcXVvdDtub25jZSZxdW90OzomcXVvdDsmbHQ7NjRiaXQgbm9uY2Ug
dmFsdWUmZ3Q7JnF1b3Q7LA0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7JnF1b3Q7c2VyaWFsbnVtYmVyJnF1b3Q7OiZxdW90OyZsdDtzdHJp
bmcgdmFsdWUmZ3Q7JnF1b3Q7LCZuYnNwOyZuYnNwOyZuYnNwOyAtLSZndDsgdW5pcXVlLWlkPC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7ICZxdW90O2Rv
bWFpbklEJnF1b3Q7OiZsdDtkb21haW5JRCB2YWx1ZSZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0mZ3Q7IG93bmVyLWlkPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD
YWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5UaGlz
IG9uZSBsaWtlbHkgbmVlZHMgbW9yZSBkaXNjdXNzaW9uLCBidXQgd291bGQgbG92ZSB0byBoZWFy
IG9waW5pb25zIG5vdy4uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPiZu
YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPktlbnQ8L3NwYW4+PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp
YnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u
ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp
biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs
aWJyaTtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5OZXRjb25mICZsdDtuZXRjb25mLWJvdW5jZXNAaWV0
Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBLZW50IFdhdHNlbiAmbHQ7a3dhdHNlbkBqdW5pcGVyLm5l
dCZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBNYXkgMTEsIDIwMTYgYXQgNjo1NyBQ
TTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7bmV0Y29uZkBpZXRmLm9yZyZxdW90OyAmbHQ7bmV0Y29u
ZkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W05ldGNvbmZdIHplcm90b3VjaC8x
MTogT3duZXJzaGlwIFZvdWNoZXIg4oCTIGZvcm1hbGx5IGRlZmluZT88L3NwYW4+PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbi1i
b3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom
cXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojMzMzMzMzIj5odHRwczovL2dpdGh1Yi5j
b20vbmV0Y29uZi13Zy96ZXJvLXRvdWNoL2lzc3Vlcy8xMTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxwIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDtib3gtc2l6aW5nOiBib3JkZXItYm94Ij48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Eg
TmV1ZSZxdW90Oztjb2xvcjojMzMzMzMzIj5UaGlzIGlzc3VlIHJlZ2FyZHMgdGhlIGZvcm1hdCBv
ZiB0aGUgb3duZXJzaGlwIHZvdWNoZXIuICZuYnNwO1RoZSBjdXJyZW50IGRyYWZ0IGRlZmluZXMg
dGhlIG93bmVyc2hpcCB2b3VjaGVyIGFzIGEgdmVuZG9yLXNwZWNpZmljIGZvcm1hdCwNCiBidXQg
dGhlcmUgbWF5IGJlIGEgZGVzaXJlIHRvIGRlZmluZSBhIG5vcm1hdGl2ZSBmb3JtYXQsIHNvIHRo
YXQgaXQgaGVscHMgd2l0aCBETlMtU0QgYXMgd2VsbCBhcyB3aXRoIHRoZSBBTklNQSBib290c3Ry
YXBwaW5nIGFwcHJvYWNoLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4t
dG9wOjBpbjtib3gtc2l6aW5nOiBib3JkZXItYm94Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjojMzMzMzMz
Ij5DdXJyZW50bHkgdGhpcyBpdGVtIGlzIG9uIHRoZSBBTklNQSBib290c3RyYXBwaW5nIHRlYW0n
cyBhZ2VuZGEgdG8gZGlzY3VzcyBpbiBhbiB1cGNvbWluZyBtZWV0aW5nLiAmbmJzcDtJdCdzIHBy
b2JhYmx5IGJlc3QgdG8gZGVmZXIgZGlzY3Vzc2lvbg0KIG9uIHRoaXMgaXNzdWUgdW50aWwgYWZ0
ZXIgdGhlIEFOSU1BIGZvbGtzIGhhdmUgZGlzY3Vzc2VkIGl0LiAmbmJzcDtJIHdpbGwgc2VuZCBh
biB1cGRhdGUgdG8gdGhlIGxpc3Qgd2l0aCB0aGUgcmVzdWx0cyBvZiB0aGF0IGRpc2N1c3Npb24g
YXMgc29vbiBhcyBJIGNhbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2lu
LXRvcDowaW47Ym94LXNpemluZzogYm9yZGVyLWJveCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6IzMzMzMz
MyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MGlu
O2JveC1zaXppbmc6IGJvcmRlci1ib3giPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv
bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7O2NvbG9yOiMzMzMzMzMiPlJlZ2Fy
ZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MGluO2JveC1z
aXppbmc6IGJvcmRlci1ib3giPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7O2NvbG9yOiMzMzMzMzMiPktlbnQ8L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowaW47Ym94LXNpemluZzogYm9y
ZGVyLWJveCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6IzMzMzMzMyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9ib2R5Pg0KPC9odG1sPg0K

--_000_F6B44B1E5D6E4B968861945A2428A354junipernet_--


From nobody Tue Aug 16 16:47:01 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E69B12B02C; Tue, 16 Aug 2016 16:47:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.148
X-Spam-Level: 
X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yu2jWJ0z43RY; Tue, 16 Aug 2016 16:46:58 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99F8D12B00B; Tue, 16 Aug 2016 16:46:58 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 519B3200A5; Tue, 16 Aug 2016 19:58:00 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E85B6639DC; Tue, 16 Aug 2016 19:46:56 -0400 (EDT)
From: Michael Richardson 
To: anima-bootstrap , netconf@ietf.org
In-Reply-To: <3A795BB6-03A8-46B0-9EAD-1607427EE0CD@cisco.com>
References: <13187.1471375632@obiwan.sandelman.ca>  <3A795BB6-03A8-46B0-9EAD-1607427EE0CD@cisco.com>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Archived-At: 
Subject: Re: [Netconf] minutes for anima-bootstrap design team meeting, 2016-08-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2016 23:47:00 -0000

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Max Pritikin (pritikin)  wrote:
    > The common elements we=E2=80=99ve discussed are:

    > 1) some type information
    > 2) signature and/or encryption method
    > 3) validity period / nonce verification
    > 4) client device identity
    > 5) domain identity
    > 7) ability for extensibility(?)

    > There is also the encoding choices that need to be made. If it turns
    > out anima and netconf, for example, have entirely different
    > requirements for encoding (e.g. one requires json and the other cbor =
or
    > something) then there is a problem.

Okay, so if we are going to create a ownership voucher format, where will we
do it?   I don't think it's a question if it fits into the various charters,
so much as which one it should fit into.

=2D-
Michael Richardson , Sandelman Software Works
 -=3D IPv6 IoT consulting =3D-




--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEVAwUBV7Ol7YCLcPvd0N1lAQLg6Qf+MrSfLY/MJrt8ytYmf6CNqdzlznHt7PhO
dopNl5Cil3cHjnByBNLeQGRApzrTtpOpqR0ZAWbNOUuEMtAhu+dIPe6HY8AER4v6
8tUacuqk+0GBEVf7BOoquroK/nFIzAqb/nv9utwEu8XfoOnKH9ATLroEuouej/0S
mm6OJHIXaT9JNsIxShv9m9Tg3eaNcTMVe41coEkoJ3mBmucNQHHOckCwOW7EN2eP
M67SAiQSHG/5qbuhxe8vtkHmcUFhQBBjK6dmPYX6M7us6OtQopBQ4NxyhnQiDMB2
iC5QxuIJF+DxbBm5jH56oksqy6t06bRyAcQvi1M053atTEgDguq7qg==
=fzZD
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Wed Aug 17 01:29:18 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04EB12D146 for ; Wed, 17 Aug 2016 01:29:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.148
X-Spam-Level: 
X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nB4_ujEv89c3 for ; Wed, 17 Aug 2016 01:29:16 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2C95112B00C for ; Wed, 17 Aug 2016 01:29:16 -0700 (PDT)
Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 327081AE0285; Wed, 17 Aug 2016 10:29:15 +0200 (CEST)
Date: Wed, 17 Aug 2016 10:28:21 +0200 (CEST)
Message-Id: <20160817.102821.2247775938129211118.mbj@tail-f.com>
To: vladimir@transpacket.com
From: Martin Bjorklund 
In-Reply-To: <57AC713E.8080006@transpacket.com>
References:   <57AC713E.8080006@transpacket.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netconf@ietf.org
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 08:29:18 -0000

Vladimir Vassilev  wrote:
> On 08/11/2016 10:00 AM, Ladislav Lhotka wrote:
> > I'd suggest to wait for Martin, hopefully he isn't shipwrecked on a
> > deserted island. Lada
> +1
> 
> Because Martin knows why the following text was introduced between
> rev. 01 and rev. 02 in 6.4.1 Xpath Context:
> 
>    If a node that exists in the accessible tree has a non-presence
>    container as a child, then the non-presence container also exists in
>    the tree.
> 
> I can't find nothing relevant to the change on the mailing list and
> the minutes in that time period, or the issue list.

This is issue #41.

[it seems the link to the issues list doesn't work anymore.  so see
https://trac.tools.ietf.org/wg/netmod/trac/browser/yang-1.1/issues.txt]



/martin


From nobody Wed Aug 17 02:14:46 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16DF812D0DA for ; Wed, 17 Aug 2016 02:14:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.148
X-Spam-Level: 
X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqOJ1EQXVYbI for ; Wed, 17 Aug 2016 02:14:45 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 085E812D08C for ; Wed, 17 Aug 2016 02:14:45 -0700 (PDT)
Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 103341AE0285 for ; Wed, 17 Aug 2016 11:14:37 +0200 (CEST)
Date: Wed, 17 Aug 2016 11:13:43 +0200 (CEST)
Message-Id: <20160817.111343.387561472405973484.mbj@tail-f.com>
To: netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20160817.102821.2247775938129211118.mbj@tail-f.com>
References:  <57AC713E.8080006@transpacket.com> <20160817.102821.2247775938129211118.mbj@tail-f.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 09:14:46 -0000

Hi,

I have read this long ML thread twice now, and I agree with Andy that:

1)  We should not / cannot make design changes in an errata or late in
    AUTH48; in order to do this we need to pull the document back to
    the WG and reach (rough) consensus on the behavior (note btw that
    this thread is currently in NETCONF, it really should be NETMOD).

2)  Since servers MAY delete NP-containers in some cases, clients can
    easily handle NP-containers by using "merge" on them.


I also agree with Jason that ideally the server should never fail on
any kind of operation on an NP-container, regardless of current state
and requested operation.  (But again, this is not a simple
clarification of the current text.)


And to answer the original question, I think the server that first got
a request to create the empty NP-containers and then a request w/
operation "none" is not correct when it fails with a "data-missing"
error.  There is no text in 6241 or 6020 that supports this behavior.


/martin


From nobody Wed Aug 17 02:37:33 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3106812D523 for ; Wed, 17 Aug 2016 02:37:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.247
X-Spam-Level: 
X-Spam-Status: No, score=-8.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46W0S3L44aMj for ; Wed, 17 Aug 2016 02:37:30 -0700 (PDT)
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 5B08C12D0EB for ; Wed, 17 Aug 2016 02:37:30 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:9560:5d13:3f9e:910c] (unknown [IPv6:2001:718:1a02:1:9560:5d13:3f9e:910c]) by mail.nic.cz (Postfix) with ESMTPSA id 7AB2F6106C; Wed, 17 Aug 2016 11:37:28 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1471426648; bh=4Vils8GxucQsNVNRrxU0Q9kU1Cs3/5XFFQ8XfXlOAGA=; h=From:Date:To; b=fifOZGikkI1IxgKFSzZ3KI3sUeswhwYN/0aEGw0atGmzBsiwxO7iw+cmHKponQPyf d1T52HnCPTaVeBOfyqba7tJ6hA2rS4EjXQ54E0cue2siqAuxwpdQ7oRDkPEirESg5c MJ0c4FdINPLL1CFtRm8S6/PbHz4JIWJQy+QJ21j0=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <20160817.102821.2247775938129211118.mbj@tail-f.com>
Date: Wed, 17 Aug 2016 11:37:33 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <57AC713E.8080006@transpacket.com> <20160817.102821.2247775938129211118.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 09:37:32 -0000

> On 17 Aug 2016, at 10:28, Martin Bjorklund  wrote:
>=20
> Vladimir Vassilev  wrote:
>> On 08/11/2016 10:00 AM, Ladislav Lhotka wrote:
>>> I'd suggest to wait for Martin, hopefully he isn't shipwrecked on a
>>> deserted island. Lada
>> +1
>>=20
>> Because Martin knows why the following text was introduced between
>> rev. 01 and rev. 02 in 6.4.1 Xpath Context:
>>=20
>>   If a node that exists in the accessible tree has a non-presence
>>   container as a child, then the non-presence container also exists =
in
>>   the tree.
>>=20
>> I can't find nothing relevant to the change on the mailing list and
>> the minutes in that time period, or the issue list.
>=20
> This is issue #41.
>=20
> [it seems the link to the issues list doesn't work anymore.  so see
> =
https://trac.tools.ietf.org/wg/netmod/trac/browser/yang-1.1/issues.txt]

It was reflected in 6020bis in sec. 6.4.1:

   If a node that exists in the accessible tree has a non-presence
   container as a child, then the non-presence container also exists in
   the tree.

I think for XPath evaluation this is sufficient, and it also addresses =
NP-containers inside NP-containers.

Lada

>=20
>=20
>=20
> /martin

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





From nobody Wed Aug 17 02:45:01 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA85412D599 for ; Wed, 17 Aug 2016 02:44:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.247
X-Spam-Level: 
X-Spam-Status: No, score=-8.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEL_FTDYUHmi for ; Wed, 17 Aug 2016 02:44:58 -0700 (PDT)
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 5AE5012B012 for ; Wed, 17 Aug 2016 02:44:58 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:9560:5d13:3f9e:910c] (unknown [IPv6:2001:718:1a02:1:9560:5d13:3f9e:910c]) by mail.nic.cz (Postfix) with ESMTPSA id 9A8FA60B75; Wed, 17 Aug 2016 11:44:56 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1471427096; bh=RqIEU4GSvBbeJSXRzFau2IZDzjNENvzZEnmpbNruOKM=; h=From:Date:To; b=JF5JQFoDbYUpPHtcXUdG5B25M0er1IPrwtqv7njl86t5lcwGbZDCkWFkmbxoyuMbG CdSRhqztW6zjgF89s9IaPKCj7fvrRNZBa2aWwdwDjm9BI0Gsnk6f+qrwiez1anFhEn NGw2D7s1pKAI+FJlV0pHHmgv8aqfbT0tllrlILxQ=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <20160817.111343.387561472405973484.mbj@tail-f.com>
Date: Wed, 17 Aug 2016 11:45:01 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <5D70F187-9607-4566-9953-9EBB9042D9AC@nic.cz>
References:  <57AC713E.8080006@transpacket.com> <20160817.102821.2247775938129211118.mbj@tail-f.com> <20160817.111343.387561472405973484.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 09:45:00 -0000

> On 17 Aug 2016, at 11:13, Martin Bjorklund  wrote:
> 
> Hi,
> 
> I have read this long ML thread twice now, and I agree with Andy that:
> 
> 1)  We should not / cannot make design changes in an errata or late in
>    AUTH48; in order to do this we need to pull the document back to
>    the WG and reach (rough) consensus on the behavior (note btw that
>    this thread is currently in NETCONF, it really should be NETMOD).

Agreed. Moreover, other documents have it as a normative reference.

> 
> 2)  Since servers MAY delete NP-containers in some cases, clients can
>    easily handle NP-containers by using "merge" on them.
> 
> 
> I also agree with Jason that ideally the server should never fail on
> any kind of operation on an NP-container, regardless of current state
> and requested operation.  (But again, this is not a simple
> clarification of the current text.)

And it belongs to protocol specification anyway.

Lada

> 
> 
> And to answer the original question, I think the server that first got
> a request to create the empty NP-containers and then a request w/
> operation "none" is not correct when it fails with a "data-missing"
> error.  There is no text in 6241 or 6020 that supports this behavior.
> 
> 
> /martin
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

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





From nobody Wed Aug 17 08:35:43 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E9312DA8B for ; Wed, 17 Aug 2016 08:35:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level: 
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uv9lFfjMVPDg for ; Wed, 17 Aug 2016 08:35:37 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0094.outbound.protection.outlook.com [104.47.36.94]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AADAE12D800 for ; Wed, 17 Aug 2016 08:35:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ex5Dpmf5ScNT4NAm0ab83MpcPzCqs0rub2RtZQtYQ7g=; b=cWY0xj1Rqjk+dfTzTdRh5b/DTlf7jomv88APnwiltuYW895Z21B2aQuCWauhsb08ooG0P+d41qPkTfQ4GGF5/LMXlApzLPfQtLGYJvwfxoCtMKvFhmeqEHWbEfMgl55wtV9iwmRvj2ePDqeAaEBCC7H9zyU8y9XFMf1y1FDpSaA=
Received: from BL2PR05CA0042.namprd05.prod.outlook.com (10.255.226.42) by BY2PR0501MB1814.namprd05.prod.outlook.com (10.163.155.144) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.5; Wed, 17 Aug 2016 15:35:33 +0000
Received: from BL2FFO11FD018.protection.gbl (2a01:111:f400:7c09::198) by BL2PR05CA0042.outlook.office365.com (2a01:111:e400:c04::42) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.5 via Frontend Transport; Wed, 17 Aug 2016 15:35:32 +0000
Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender)
Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BL2FFO11FD018.mail.protection.outlook.com (10.173.161.36) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.567.7 via Frontend Transport; Wed, 17 Aug 2016 15:35:33 +0000
Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 17 Aug 2016 08:34:26 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id u7HFYP6R022055; Wed, 17 Aug 2016 08:34:25 -0700	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id u7HFV3eR048072; Wed, 17 Aug 2016 11:31:04 -0400 (EDT)	(envelope-from phil@idle.juniper.net)
Message-ID: <201608171531.u7HFV3eR048072@idle.juniper.net>
To: Martin Bjorklund 
In-Reply-To: <20160817.111343.387561472405973484.mbj@tail-f.com>
Date: Wed, 17 Aug 2016 11:31:03 -0400
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:66.129.239.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(2980300002)(199003)(189002)(47776003)(1076002)(2906002)(87936001)(92566002)(86362001)(50466002)(76506005)(626004)(48376002)(53416004)(106466001)(7126002)(5003940100001)(97736004)(110136002)(2810700001)(105596002)(189998001)(586003)(2950100001)(4326007)(54356999)(77096005)(50986999)(69596002)(68736007)(305945005)(7696003)(8936002)(7846002)(8276002)(8676002)(356003)(81166006)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0501MB1814; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD018; 1:p/gyaA/r7EKBL05u++txSeU4gP8kfIhKX+mx04KOvn8EWx/SLXn2/6ydqx6BKAsJStK6mw3OvQaSBILoPh5Pn88mv9MP3n9jGo8OHfQ4S1VgBRTwQ3e3vXKlWvz1uiQYt1AG3OgdGuKrraaezHI0jZY2w95bnRItZip2lC8Zldbd2PoTq2o/T1uz0V2UCwHDmLLMUPvEWtj2g6P0IpmHsk5h40GWjE4VZiD3uc593ChSHdqZQKW3k9luzJDPoq+ZUHpGjPGvDxVmTy4y3gIDWbTRiPjTfmnomuiUmSuFJPWQQA04oGUJCUNsRquEMHs4tetW/EQRsRHH+WvAu6GfwWuNjplp3Iaf2qtZdpZsuwV4bbACpp192zOI+sf9NHIDCDyWP7CVdkjjIzMjxqZ4KIYNN69BkBq3lQw2U8th3X2JF0CoaAnJeEu8rhhNUh/9hEVYoXiOARQW4b3bqPh+fNEW3EFeUVmvDboDcMF3Yk/jrEbUv40uMR6dtKvK5ZM+0jFrTaA8eekGWKrt/xvoLc1ftqd8Dcufpdy3A7or01sQb6Uh/EK3i/M1g3xBPEn3
X-MS-Office365-Filtering-Correlation-Id: 454e45ec-2230-4b1d-ff79-08d3c6b420da
X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB1814; 2:7sYDyA/VwQAgNO8Hi6cbv9KCbvmxQKkDbySXeCRGy5fHF/J9kOSY3/53vuqxL09Gdah81mCNwJowF3wxMGs5kYzFxNEzsrX+VH0WgnxrWxM2aHWspLRYGPH63a1PYMUjim0aOcnj2euQCv4OcLG5Pe8w9htSDIX5QwDDuNITvBAhTE8DdApk4breuv6WUSsY; 3:CAwmhub37m2gSB2XyZsM04+8ayuyyVJJH40/elxwqEo0NF8gcUZTFmnu0SdUs1DZusZfoXkAho8AMx1aIfek2nJZKR8Pg4U1seDwgOPnF1dk8tqWZKbZM6sAiss/sNJKl3eAHqyo1vmRYmOyTA7S41FtlsFjQiKCX3acb2SwHYtcHZK5wL4R5s6tWlqTa0g+kOgPIDxc6JUeB8toC9X/i6MlvtIg5RmUYtMGdxiiVL4=; 25:wqfzNFnxltrV79NHoGf0hSbTYK8r7pUrUWw1b9Y6fr2MUrnAunjmsNEU5qXX6rZbmc8aAzK/41haQ2dtLJ00SBj8PGMDaiBdNlPSEQ2TXkxy3gB2eeJ6Qs0orj021HYS9sQRNL5CnpciDdLa0RUfROMGFPM6N5ISuvOSqV5J7iY7/5LBiZfeZxSa90ylQrbXWuBQkTpZ+XbO2RUJXi3raT0dL8q8xsM3GjM0k+bnsvwpIPEEIzTJbI02gyO7I8k1NKF2RnXNynWqjRRC546V9xaCi3+AAvJXx9vCuNNUpRpaRO8/msOIsap8QvzfcywdixWRAaLe5udQB+vRUB3tXAdaafA+Re9BkU5cEJQjFz8HplSEdUNsRkSKpB4zfBYWt3JzXxTDqN1BbdSAp0Sj6s1RrKPK1LvKbxmHnx3iYKk=
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0501MB1814;
X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB1814; 31:mMTOwSBd2cTyD4p+0L2GY7PSXMiFzb/W8PKtm1ZQJTNFnCXmzhZ5Dr18bNklifzdSWXa3XAWAdVbp89SRDNf8P6JDloINALBGpux4qbznvvsZvua3P3jcpwcQ4b6mXc6WW8Cl2X03A/5H3EBSVnA1JfDv1t6MBYM+QZLQV6ToO1XBTg4W/SAaouKyz1ftZS5oPoBokiizqCnfKIBEjRgzF1y4AKkV5mRl473q1ZVZic=; 20:lXZcpgyksRZSU0srDMhgvcjsZM8Bo5TFzLag6i9KKxhLkVkuuVYPd3y4kuzzcDVgEsN6vvFanbTtgmZO16HClS3YXivuc6xqeLRw3nrgKZTuU+ktfACicgATmWcjxkJxDhw76kPm7/VuLOy+t/zQUfNaNPx8ZfCMklHBgwdU1MzH5eDKwtNbzg7CcvNUTE5tDBagSk5Va5PK1TECanl3PtUDJNlLA56B15sxA6LRBrMypsDpkHWWbjn7QBT3PSmsSbswmCheDNmk+6WKNIv22FEzTX6cCCJNvxYZE0N2+EKALbPfXeqhxB48ZX/SmXzFA8xnI8E3ygSih8EsftTfAuwHPbOUNB+Qn0EpF4r8ckkCcHlHMnKgCI9L5g44Ld905XYI+LAs8eI7T0oZLQloJctkigjAtWhxDncdXnCZU0ycZY1pRfk5P8R3X7K41V9V3znrXUxWy/Cl8yCIP03cmVuSt5b7EogI2WdwvHtrBRJA7XqQhgBzhbdHl3tXA5SI
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(13018025)(13015025)(13017025)(13023025)(13024025)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:BY2PR0501MB1814; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0501MB1814; 
X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB1814; 4:24W70rMD9mDS1YbvF15LzdqEOfYtCFi1hypgY/A2wLxosyY95aIci5VsUvk3lnoA01U8NI+/cmW7Ch/Hz5P5yWcJH2vg776rFCGP0Bc5Sa4cTzqptecnB9lUmM9reWRNy1Q2Jwa8JY8IVJbVKTtsfSq7eKCGjrsZbHCENOe2gDKYaheMbQx2BasVmOblSdIjaATGVUpZfAgMHSttV6sBgX1fJD0uc7pnhASSoJ+qWUiHDazXP/I1kbLowPeCOPlwR4ZniCrGxTE0hKQZh5yquYD0ubHd4wrdb3Xlh4u6W7qQeYrIfvJ/HTSSDrXnmtJG/RS3DdhBhY0BXP2HEkEjn/hVyZUbtfFLFQCvH+n2yvEtFtvEvJdE3dMQcd8dsYbJ/5HJjC9VzGTDIcvYH1YNHcEhWiMV2CGISH2hnncsi2L+Db5gWTpSyIzpa/lUCWstvUjzqtVhWpCPYkkpjb8OHFlSlF+uonBhqaF7AF1qcb0Wh8319UGnpolq21ihyi8RFJOpN45y5mY6DC91u0lvMhM8y8htVXG8jigtN3XTgQM=
X-Forefront-PRVS: 0037FD6480
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR0501MB1814; 23:mtDKDEvk/iBvvcpUIqw9m+KYZzmpzGJgag2oUsQ?= =?us-ascii?Q?WmcfMYOEESXyQMrIDFb6AAeyNqGCbbTnakMkQ/n5MTyD8AXlYBHvedGZ63Hx?= =?us-ascii?Q?12ulNB+Ds1d7ScWfJu4q6vk8CYu9Gg3gk6fT3b7WlUpROJg+vhiYWynRDkq5?= =?us-ascii?Q?zcGG5gtXNL19PxqlwoKuHaFC5e+k6LWPEV80mfCVWu+sXic5LcGd1xljP8o6?= =?us-ascii?Q?LQk5d+UIaZlehhLJgoUu+cdLu2K47g8CJjTj4j0e3HCQfQSy9hYiior0q3BZ?= =?us-ascii?Q?cDF/yMrykmFyZs3HJ0lBui6cXeERMyNYmOpAQUtiNFTNro9auDV+TL/vILap?= =?us-ascii?Q?V9ftPacgeJHjPoSLde69L130nakITLpLTI2a9GDnBBfJ8REbwJR+IgLnjtPy?= =?us-ascii?Q?lz0qYDa/FG24KcvY+c+UxbiyVjMtoJ7Qh1CG6do1jrjvUgnTWSssJ68OgoJy?= =?us-ascii?Q?R4a8i8IgXYEnDTL74Tnj9/8QkdnbUvLob6rfQMlFZyUHJnqQxj6CbfCsgSIA?= =?us-ascii?Q?VVPrybh81FdReAykffFuMdYAvIcxjbKInRZeVpDvKSgXy+FzL7luX9cgHcMn?= =?us-ascii?Q?dmQBTuXSiJH1kXzYTF/jEprtvOyiZpMdHFVrBuodftoXRqTpMfsVCxcXgWBP?= =?us-ascii?Q?a1Vdvv4NHX0RYIXHGJbOA1K7X7ithWvHKy30OqKG7B5xyo2mt+UAJd0/M014?= =?us-ascii?Q?P6p3isbxAIwurj7vwh8eEGdNFDwrT/sY7QXCm9kYvsNTUXpD/BA492l0lPYK?= =?us-ascii?Q?ZP+KBQJsryDPWJSOJQYdr9oq5GFDV0sypd5IVD1mzUYDtuNSLrYR3iEt/wbY?= =?us-ascii?Q?NVhasUD3+W4dZ4BFJoXvFxRgvr6vN5uIYfL7jzjuG50eMOCToXP7gxw61Afh?= =?us-ascii?Q?U6LD5+gL6Yp6C1JcGepjmJoOYZ/rDUHsyVJl6yKD/0fwayThlOle+2d4xuzT?= =?us-ascii?Q?hDpNOwVxUt6F0ZfuJp57bt5lqW/tH/+M0U8Q2HAM9hfyBafwWxkQ/Nuw5KM/?= =?us-ascii?Q?gubo=3D?=
X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB1814; 6:JiQMcAqOcmkQBIyFcUcFvXx4oHk8SRVEpmJWo5dWp5d+iGjT0VtwxNrfAiuUOxF+6qNpXpqLH0DOLFpZ+CODsJ8v8WEmhdSr7H28eegQuTlTixoVo2nOGnRbOq2HRowFmPJH/akAouM9MmywKbV+77rMWpIPOQBkn/fRPCRiZLkEILVk6mtRyp1AzQGLshWiHofI7No/K0GdhAP5xbsYl1rhXWTOVNQPBjxJJSkR6PMwuz1GWSOkpylkhPJZ9QthXBpZjyiW0fInJpyapMPB8DDmbKoRoFRffaibkmpCyiWkAjqukSoB+RyeMW/7PSd7xhkwuNg4b7evENR9Amapuw==; 5:pZMR+HT1iqktUEIwNAv0Msxm7molpy+VQrErpGS2XVtZRmyod2h6FtL1leFHkG74Wj/9DwrEafL9mx9wlfclPsm29RQxPmGgxttmMQLXi+H5NDfNRw0WNli183Lvk0iOxLXJosIGWBDwvxt3cz7sjA==; 24:JgnJxmciqT/7dTd2mQUwrctriaFEP+eUpgWJgIssMlWkCwpHs4Fkeqvwo2VXZ5MzwmnPenJsTcxjaiAMW4Vbsj+3kPjMdweyEU1ws3Ns7MU=; 7:91fUNEHOFDdPsNq2q6yHWlog+qSTvZDmdHIAgymaPr3Q+9911V3At/AZVG4kBu4TQBc23glXFVFLh/BU4RWaG4Y2mTETVgxBuaieDfxz4rFDvWlNwHna7qbWCCwMIgAoQTnbZy5jU42noUDlAjkw0xUvCMXZp7HvNrBBGjqqSAZWL5GFvFCl0XXYIqvXBzFzvUZQlj1/0R+rR0Zn4aJNsNT8M6V6YeQOqNHap1arqkUv5zvMQ6XpfUq2a+AOQ/EW
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Aug 2016 15:35:33.3263 (UTC)
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18];  Helo=[p-emfe01a-sac.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0501MB1814
Archived-At: 
Cc: netconf@ietf.org
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 15:35:42 -0000

Martin Bjorklund writes:
>I also agree with Jason that ideally the server should never fail on
>any kind of operation on an NP-container, regardless of current state
>and requested operation.  (But again, this is not a simple
>clarification of the current text.)

It really feels like this _is_ a clarification.  We're saying what
an implementation does to behave in a meaningful and consistent
way.  It's not a significant chance, but something that should have
been more clear in the original.

Thanks,
 Phil


From nobody Wed Aug 17 08:44:54 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E501012DA50 for ; Wed, 17 Aug 2016 08:44:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ywaa-EouuCwS for ; Wed, 17 Aug 2016 08:44:51 -0700 (PDT)
Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 0D0CD12D881 for ; Wed, 17 Aug 2016 08:44:51 -0700 (PDT)
Received: by mail-ua0-x22d.google.com with SMTP id k90so177746626uak.1 for ; Wed, 17 Aug 2016 08:44:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SjjVmmg4J0g06RBhJ2IyWDA4ks4Eb5Tm1w5I9UY1jyc=; b=anfW4X5Z/ohdSy+TLpwWxV4JNuNxPmKDpFaMvAzOTuGO7dncfj2KsclhZCZiatWDV+ 0h6niNv7QwcqJIGgnrfbo1Xfaigt7UHmNudhscUpDy56/TT7IG+5g1XKmA33E26RKsAE 21BdjRI7Zn50gbUZ/m5z+RVuE1aE1Z1tkVkZ4m2FaAVDOrSKg6tm9c5tHoDfy700WFFh qgNMMWgLSR7eMlISUj+7HozguRMmj6vWu8e+5RXc2XpfK1zALGCGJBgYHGOvUfR6UddG zBLT1MWlzB7xLwUy6x+CiwmPDMqoUwiQ7XnEPZbgxd8SbCKseQ2WneUQuegz7bnq/Yii qJ7g==
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:from:date :message-id:subject:to:cc; bh=SjjVmmg4J0g06RBhJ2IyWDA4ks4Eb5Tm1w5I9UY1jyc=; b=QCb3zDLG91Ol8mGEuV/kWGm2FKjFRLkQsqe7jkxwZCGU6YC2KDVvl7jOoaZPxN2nrt tlsPOpeHmeM2U4Y7gv1bfVumWubvy3hEtGw6/mIjuI0G/QRO5DcmCz1MlPfW58pG2EOU jfGrECWwbMWu8EbeNR8tGoJeX9Ybfm4MgI7/mlRjmzKGq+45GJbOiF0oqQ+L+A892MmM vXLSoDPRyEnPjToNdZFMQbAm/IYpeA9AeocRvDCLbawiZaCgPzG6d84sDOLUTpxhj9FS WUok+d+YKITUW1ehALotKGml7QihdSybCaz2a7MA1wX6hIcAAMx9dUXPnaMDBmkTeY8N mLUg==
X-Gm-Message-State: AEkoousSuI71MNDWpf0KPuVaMO7jVyRLRORRbUPc40oi6JHa/DJ6uXDiNdWEkqupRuxAoOLcawvrcVVvOgBkpA==
X-Received: by 10.176.82.219 with SMTP id w27mr20405673uaw.121.1471448690192;  Wed, 17 Aug 2016 08:44:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Wed, 17 Aug 2016 08:44:47 -0700 (PDT)
In-Reply-To: <201608171531.u7HFV3eR048072@idle.juniper.net>
References: <20160817.111343.387561472405973484.mbj@tail-f.com> <201608171531.u7HFV3eR048072@idle.juniper.net>
From: Andy Bierman 
Date: Wed, 17 Aug 2016 08:44:47 -0700
Message-ID: 
To: Phil Shafer 
Content-Type: multipart/alternative; boundary=94eb2c1915ee7c0f27053a465859
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 15:44:53 -0000

--94eb2c1915ee7c0f27053a465859
Content-Type: text/plain; charset=UTF-8

On Wed, Aug 17, 2016 at 8:31 AM, Phil Shafer  wrote:

> Martin Bjorklund writes:
> >I also agree with Jason that ideally the server should never fail on
> >any kind of operation on an NP-container, regardless of current state
> >and requested operation.  (But again, this is not a simple
> >clarification of the current text.)
>
> It really feels like this _is_ a clarification.  We're saying what
> an implementation does to behave in a meaningful and consistent
> way.  It's not a significant chance, but something that should have
> been more clear in the original.
>
>
I do not agree this is a clarification.
The behavior that makes the most sense is for the
server to NEVER change what the client did (e.g. deleting
the empty NP-container) in the first place.

If the server follows this rule then the client always gets what it expects.
The client can also choose to use "merge" and "remove" and then
all problems with NP-containers also go away.

RFC 6241 does not have any text at all that would even slightly
suggest that all operations on NP containers should always succeed.

The NETCONF WG would need to create NETCONF 1.2 that
had this behavior, because NETCONF 1.1 does not.
IMO this is not needed because there are existing workarounds.


Thanks,
>  Phil
>

Andy


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

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




On Wed, Aug 17, 2016 at 8:31 AM, Phil Shafer <phil@juniper.net><=
/span> wrote:
Martin Bjorklund writes:
>I also agree with Jason that ideally the server should never fail on
>any kind of operation on an NP-container, regardless of current state
>and requested operation.=C2=A0 (But again, this is not a simple

>clarification of the current text.)



It really feels like this _is_ a clarification.=C2=A0 We're saying what=


an implementation does to behave in a meaningful and consistent

way.=C2=A0 It's not a significant chance, but something that should hav=
e

been more clear in the original.



I do not agree this is a clarification=
.
The behavior that makes the most sense is for the
server to NEVER change what the client did (e.g. deleting
the em=
pty NP-container) in the first place.

If the serve=
r follows this rule then the client always gets what it expects.
=
The client can also choose to use "merge" and "remove" =
and then
all problems with NP-containers also go away.
=

RFC 6241 does not have any text at all that would even sligh=
tly
suggest that all operations on NP containers should always su=
cceed.=C2=A0

The NETCONF WG would need to create N=
ETCONF 1.2 that
had this behavior, because NETCONF 1.1 does not.<=
/div>
IMO this is not needed because there are existing workarounds.



Thanks,

=C2=A0Phil

Andy
=C2=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">


_______________________________________________

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mailman/listinfo/netconf<=
br>




--94eb2c1915ee7c0f27053a465859--


From nobody Wed Aug 17 08:53:47 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6394412D88E for ; Wed, 17 Aug 2016 08:53:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HP16ms92TuDd for ; Wed, 17 Aug 2016 08:53:44 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0100.outbound.protection.outlook.com [104.47.33.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C771012D1D7 for ; Wed, 17 Aug 2016 08:53:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Fm5d9Kzz9kDAHiS4NBHtU3eRFEEf5/36QGZOJSL1Fh0=; b=IrjHAkbW4vQv+vzW45OSH+go+IXJkfJINSp839KrYJnzzFJuPpsXhf/MTWIHrluTGWzhtpw6g1vEywl2c5HKDlS13o8MbD2x4a4joktUBo3Y+zcqPm4K9TSgaPD33zGe6Q8Q+D1snG8a9pzqZhcbldXEIYPdZq3iQApNbu9LufE=
Received: from BLUPR05CA0045.namprd05.prod.outlook.com (10.141.20.15) by SN1PR0501MB1824.namprd05.prod.outlook.com (10.163.131.147) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.5; Wed, 17 Aug 2016 15:53:41 +0000
Received: from BN1AFFO11FD056.protection.gbl (2a01:111:f400:7c10::143) by BLUPR05CA0045.outlook.office365.com (2a01:111:e400:855::15) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.2 via Frontend Transport; Wed, 17 Aug 2016 15:53:40 +0000
Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender)
Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BN1AFFO11FD056.mail.protection.outlook.com (10.58.53.71) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.567.7 via Frontend Transport; Wed, 17 Aug 2016 15:53:40 +0000
Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 17 Aug 2016 08:53:29 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id u7HFrTDi025572; Wed, 17 Aug 2016 08:53:29 -0700	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id u7HFo7Wf048341; Wed, 17 Aug 2016 11:50:07 -0400 (EDT)	(envelope-from phil@idle.juniper.net)
Message-ID: <201608171550.u7HFo7Wf048341@idle.juniper.net>
To: Andy Bierman 
In-Reply-To: 
Date: Wed, 17 Aug 2016 11:50:07 -0400
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:66.129.239.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(2980300002)(189002)(199003)(305945005)(7696003)(48376002)(110136002)(54356999)(50986999)(68736007)(2950100001)(5003940100001)(189998001)(53416004)(69596002)(77096005)(81156014)(1076002)(81166006)(8936002)(105596002)(47776003)(8676002)(7126002)(87936001)(50466002)(106466001)(92566002)(586003)(76506005)(8276002)(11100500001)(97736004)(7846002)(2810700001)(4326007)(356003)(626004)(86362001)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1824; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD056; 1:9m9kt/l7C8TGcZCl1h3VTOC0PPCdm2E4vqrx7JhRVjyJoobOoMOe0girqQcDi5Ex3DsM2bZcBxkrgHBqscNdH+VxiADaImRRHKXyzlZok1iww8C+19aG0xFbnvzM48ATVD+0EReyRyKJK5yl0DZXFyqRMyhQ6ZTjCt/ybib2RYKX/Xnwv8LypttFZQNj0GQg7ee4TZ9xR8B1ve4ZKWdkh+T8y4S6pDVdjN09xoFAUjLkk4/amZeG97BJaYYI4Y4QrkqUyNwGGfYo03xrwH0TGy1shrcfUnamn6x7vAlWeR70KR7sibybVNt9pHG2evY5lfZEUU0XYphP3zXnpjj4SGSEwMWr0rJ/tL1VpGsLAfl7nxRcyYQjQE98zjpuCjdQbAU77ufIHhY1TLXPEzIlxc9f+PRkFOTRlaYk2aGb6dZiD6Ro3FD0tAtfOdP0tazP7od3XdG30m9LWvsuMmFa+J0trxoHngA9YgNjD+Hk3HCKF08vHC8RVuQGe4+6Mx76nlxEHz+3LW5ttzWjR3VL4z0GNnCrPK5KQSTZbQJt3ClZED68EKdjA0TySgdL7ekx
X-MS-Office365-Filtering-Correlation-Id: d7bbac1f-e959-436b-eeb7-08d3c6b6a93c
X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB1824; 2:Q6hYrKtuvLBFyIVZ9UWLZz4rdRLDjnGOFkC06+FjzmB2XHabqSry9LucfSpr8yY7nrBll/UHc75QwZdhPk5fVHNrimjT5Gdfz6pMsbiuyeCawOziUt6dQ5uwgv/8+9q7ddv+K2FjIIjPfNKqvPVSQwCovBtB03p0UON4lKz63d+SwIaPudMUkXmckeC0Rx9v; 3:fiCbMrxuK2jUN17rjOVZ+O8V6NWoBMBvZCHW6/Zfu/ziwWcCCq4OQSg4bjxngiT/O8OgfkOzQLukjyWNBd03owlauprtNF+6PXUFxb6RjOfVHWX4QByanaO8UkLmO4Cfj5yy9ldy1MOkVll+MMsAsJ2mXhSXlJ+Kk8Whi6HU5lekaR0eBM7OWYdedRMqTLJucHd8644/g/6y99PBFEk93EOIG10vbJB/mhbeJxcJwrc=; 25:PhLR9m+d4Xzn8Gu/UKXTE3ems0nXXwSfyu+pMk0gHcU/FIA8JFt80qknzSdwUIOGy+easImE4QNE7cNkJ1n7tfwSMmU0rc8f+wmLEKdnYmGFsfQEeRPRB6pEHdODUTPHRZr4FVnDFQuNqpPhc8PEW0nx4jT8F03GQ3LBiVLeZ4/yxtk7XnBwV05I8CeAbfhHO0vAvo1vYthyoWMW2pqMUfb0hjjk5PY5PU4tMzwMgcf/KmPo8dl9rgDumgQ4TlAbGBnC2wGUCqPrc11C7/BKeC5Z7Tv1hifg2N+D3YUpd013yv1C/F3gAuTfVmAFRop3jQiVdsAvbz0zHsTNgthXe9429TtujI4S6ZFH419ZED25DGFNaLPIBKpoZZpUhL56gGhVIYH93A8y5fTY2moLIrK3gtCGYaNLoIHKoZo7/nA=
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB1824;
X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB1824; 31:bt3eOigaALDdmoRmGEMuEhBMDC8Lq/LWGEPi3j5jK9DXkNe2Hd+uFnSJFCk5AQnJ6wXLCX28tUGDeiuMXaTs3uVdIjp8s5yVcQfwwkQpndFt6GUNN5ABFNNDwf4LeNp/ryNL6NykbfkP75wecn78LFOp8vAcF7h/CxApl3lTNqtGGLQ7ad03+PhX4d0q1fQc3kEkbjV3Wqo731TeOa9xmZybZgBvlT01FR4OPQwKi+c=; 20:K0K+aaD2UeQcTymTWZqddQhCTT6snyFj7OPeOnsD6mYR7SDei3w3vrY8bZ8FE1TU+pwYtDhgmieI3EXl9bEUZfpmbyXmQC2QoPi/dqeH/l6N2DGSUhK1yAujSUa3gOjrYvv7t/paOEWCzXs1tgBLSeqBHLcD8pxZEsuQjE7ZPX/bmQ23sxzVonF3rK4swfO+EnG3oYJeY7xKVRcKhQtYhUl/FtYSsctyuQJ9MfQYYrawcy1h+sOSSpmUrAWShomalh49YU65kC9hvwnM7i3bYcnSj/rURpxoAJxP2RbYczCTFcMYGu4QxyP2j5QmI5lQ2Fbdie8wSkfSnmYWMakebLv9TvYPjfVnERLyUr3KGVNtD+bcJ7u+txoy9yMFkgc7kymwFzptWGoZUwZPjQceZNvUXry82Is4DnZIxDxkXrPzQ5mYeAVvVvqoVKWsfRfBPuim4fWgz6T6Ei5BtcEAQKMaxWzOSDgEag2Q7Q2p7ss/0V+WNXz50KWCaoFr+laD
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(17755550239193);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(13017025)(13015025)(13018025)(13023025)(13024025)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:SN1PR0501MB1824; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1824; 
X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB1824; 4:nSvShHomGwrM8ug+2yGPfrmCkjyql4I1SX5z+nvZNyfCrQVXheK1/sGRgdDBcV5ngzhH0d7wsfNTrSNTL7vJ7JVwb+e8y81hMei1t+B3FJ7LYFxjlUpCgnY+xs/+mY/0JWNfuKuvXkaFZgrtnEZswie2F7FOlC5xbn1jIA7pfKlW0Ofwbm6e1pDAX6xtiHTVK9UQikNw/xnUUUF8gJoC3OPk+wkAhycKzIpCxRViGbPWVOaT5udYzx/N+EjflfBMqWKYiOxnbWmvxfNd84cpRcErlmueLrIiDWjbkhBoQT7s9lW9U8H0NbniiENW0KFkqNSbRtoav9Yy5mowJBGZtukkkGcCd+eUCAhMzHyPQj3fWScxltUATc/aL0C1OtdUxfMIRq+s61E+vRnwmi5E7hcR0TM1DtYn1sR5Snw2aKeukkcDkdFul6n3U+RNdkYPTOwPSdXZuGbpSpotpxMhVu2ht6UEggpVSFfj19Okb3MtSU+6M45kv/NPT0sgycniX+lWsTho5/doKm1j/CE9Jv2LbtLQG+id+lNaP7Euo2xcXaTF/WYaIFJklp3mFSwgwShGlcBFvq/k8Jmkg1j/LA==
X-Forefront-PRVS: 0037FD6480
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN1PR0501MB1824; 23:/+jUOEzdJfG16lJeNvbd1V1swIfESkLxoljbRYK?= =?us-ascii?Q?IhAw9RG23sEl9je0HZpSZUFCn5m9buDMboQY9wYYjx2xT/qF1tUHGJ6kCOMZ?= =?us-ascii?Q?cnmbs+V7zIoqBYolXA+wxbFQri3wMD0VUpv9/jkF8d+nCzTEhl+J9RkmH6Lk?= =?us-ascii?Q?pNi6cOyFRlUkH7GU5ktaHnSWgsOBo7OeZ4206Htq+2sW6Sfdqz3j4Wki55vw?= =?us-ascii?Q?X1c0LRNKrTNlh2AwqTB3pzBYJ8kqR3/BF3O8+T71LN6pp3Q6uQoEYt4fndgT?= =?us-ascii?Q?OURsovjnfn0UhEfWaZrBsSZlGhtoRgdYrh9q1pDhdZ4xxlRNW10oODVjzlEc?= =?us-ascii?Q?hrIlD3pnyzP0UIcRR15tCO2DTDqFDz7Tci20ykqSz6IXFG0w3TOyzBEjsMNe?= =?us-ascii?Q?Ia9D1FjAILnGwBoq2HItXak4/3ODg+QeFdmRLwzQvq4Cf9Zx2loGCm1Q5r0v?= =?us-ascii?Q?puf0a98F1ta3uIg9NXtVxQcfBYFjwMIlzIkF4ClL++K5GjC6WUj8vwYxJDKg?= =?us-ascii?Q?QWeufvwbYb3YifqXVq+Bqv3u7jhVkdxSrPgOUSk70yXG1YKbxyjI5L3EtSxk?= =?us-ascii?Q?45ByE50Q/eZGbdqr4iF3mESBJr1XIdlKoKWaQGkXygxpfGAE6uKyzUPwds7/?= =?us-ascii?Q?1ZiULLYdw1hZnJwlm4TPWZEVXKKvI4Zp61kubYVhOAoccLJ3JKMoKZjPIHpc?= =?us-ascii?Q?WpjKMDi/L1fGIfx63LB7wQTbVu+l8phl5u3PH0xJElJcXCSUFDfhwHfJI1Kb?= =?us-ascii?Q?ahxtn8ZNDXV+glKfy/Ex3NlMr9qcJAaX53greMsoXgdygHW+N5UjAJMNEeAh?= =?us-ascii?Q?89fCW+txqO42rlyQmgMe3OFnXZAr92Nr4ClxfcwmgbsQG9/BUJKldpUWg1gw?= =?us-ascii?Q?bdbRWwmvYOAa7tjTTGbVAsI8kZOKhCrHPeMubKE7mw75JD1tR9EKRwWlAJd8?= =?us-ascii?Q?64186hcfCbCOUUum+EiJuR3UzCQKex0PeJNqvK2cdlBvs3HdbQxtiv8AJuDt?= =?us-ascii?Q?h6ynv2N3GoGcIY/vIphlXEl95?=
X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB1824; 6:WftCIjvmOryLBAc80DA1wSlNWSk841fL1Q5R/qjM9HF7Y1okrCcUbvSG/Rk8rEwVCJd8c7YMaMLFM2JZ7UoPpc8k9GLA9RlC8GaIwxv8ieiShTKSFgees0jUV5XHufjT7qS8DBf3Rnqu8/USplLbdxXj8ouYN3tHErDbbjC2IFIZG3m7pXJShgrG/qo8owL4vlMpBFw3+QIWGOOmrOKjCw7rimBrUqCqpwlrMZ+EQJGyS/425ddn9PYAbTHg6nFF0H4hbxy9ONbCL6T/jnPxwTpb1qLUFF+8aYJwnLthNQKWxesxCckRYnh2xEVAadmuSJLE+4psmWfEWNu2T5SacQ==; 5:6vRgJ8JS+nd4FfW66xBKc6keBXAHxZKPhJHOMwqmAuOjOtKk2ozktaT5Qf+EPokh73XKGHiUK7ost6J4ji+rqAVOY/8mUwzsKoQBPQFwMwdDKszbzqA3fzgzfm6HGbXaN1FCJuwcWZ/e57bhaNbUdQ==; 24:d5uWInrFt2QoShroJt5SLosjFiSVpE8GWcsyzE+T7Z4j0j1pSoHXGxgkh2122LHrjjz1CC5KwWJFwDKBGaEPRdrfKZzJyu1lvCCSxtzhS54=; 7:ZrG4R3r/3pZSfo2ISkFdNjlc5/DZaeAl9M3Y0z0NBMlmYIsCASvdDxu2nqJK2pkEh/eDZmb3Ntfg9CFIziKhChRnzdiNVzevSPpbbF/ISDZnmYOuoy89wGvZov6+n24dF9kOzqC/bKRXA1wYMGMcsn2OMHcqtHLcgk6eDJ8TQlRN3xI/28a4e68Utp5C5tO96/5N3kvvJ0IGkd6THsJXqcX2Neh54vrNK4uFciojAIcoeyBa5+qdRIEP04D2LDCZ
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Aug 2016 15:53:40.3518 (UTC)
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18];  Helo=[p-emfe01a-sac.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1824
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 15:53:45 -0000

Andy Bierman writes:
>RFC 6241 does not have any text at all that would even slightly
>suggest that all operations on NP containers should always succeed.

   In the first style, the container has no meaning of its own, existing
   only to contain child nodes.  This is the default style.

   For example, the set of scrambling options for Synchronous Optical
   Network (SONET) interfaces may be placed inside a "scrambling"
   container to enhance the organization of the configuration hierarchy,
   and to keep these nodes together.  The "scrambling" node itself has
   no meaning, so removing the node when it becomes empty relieves the
   user from performing this task.

   In the second style, the presence of the container itself is
   configuration data, representing a single bit of configuration data.
   The container acts as both a configuration knob and a means of
   organizing related configuration.  These containers are explicitly
   created and deleted.

One can infer that since the second style are explicitly created
and deleted, the first style are implicitly created and deleted.

It seems awkward to say "the client must take particular care in
creating containers that have no real meaning".   The opposite
of the Postel Principle.

Thanks,
 Phil


From nobody Wed Aug 17 09:09:04 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44BD412D96B for ; Wed, 17 Aug 2016 09:09:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXxsaZ9WXq9G for ; Wed, 17 Aug 2016 09:09:01 -0700 (PDT)
Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::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 86F9012D9E9 for ; Wed, 17 Aug 2016 09:08:59 -0700 (PDT)
Received: by mail-ua0-x22a.google.com with SMTP id 97so178717421uav.3 for ; Wed, 17 Aug 2016 09:08:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=46xBJ/8LjmgBVhUTZ4x9ZC/KnYfWILJf9l6gPi1LWJA=; b=Ys2CmUHGZtbZC0VHi7hatkpw/AueGJ1qDBO+snhaxt3P3NMfCNtnik8Hr7Glk97ovP 4skWLFdNiVEDhLnojg7++MUHmaRLaNIU6pXeZZ77YcZNjxUQFNRb3wmt60KO6H+f50fc Ui9Nz7zQvSchSEv2ORtiJO0G+zGM6f8Vv4E0lOEbQNOMIvGIOS/ZF4XTJHdI7EXBugVP LE3Q+II6L31bi3USn/IzJLblvmvoH+La9m0QBpSA71GVpT2lAtbnYmjp6qReHL4HGEcQ uvUo3B58FSLzBnSZaFpexlY5sx6YWJy38lwA6MDHFR+qA3Wto5Y5p0eFL+2n8Ogh7pOu Jg1A==
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:from:date :message-id:subject:to:cc; bh=46xBJ/8LjmgBVhUTZ4x9ZC/KnYfWILJf9l6gPi1LWJA=; b=YRmfTkjCKieRLNBdyr/LXt0QP93oL2DdLdThz9CpDTarEgyMkpp/Rj1oEuS60igSUY EPJvhvnCW2ElWKknMgU9YA49oWhA9vQt9brLQX5UgAbIPHzWsYNvuoCSTOCQdTZ9XQSD Jb2i5TCFNV80J8rbYoNOdWOm+XZD/dFemm/0wlIK/cAv1DUqNzRJ76itMIjyQmKT2dPS RbIIP77pu4oY/feqJh7hy/g1MVRxURRlANXMDJARYYzH4A29Q6Z6pHGfQFKmGilPpdFQ f5qM1fUXa7umrDWCuqYYPRYFigc5CweCdlWLyzUDSIMpXudpZBXG7F3fuPg8tJJFeVo6 A8fA==
X-Gm-Message-State: AEkoouvBgewDuIi3EtdQsgffULR5rqpDy8q8qDEILG4w4z15q5GGtfmdUuShw4P05xXmN/HY2hzFnUP8N2dICA==
X-Received: by 10.31.139.207 with SMTP id n198mr9517243vkd.121.1471450138655;  Wed, 17 Aug 2016 09:08:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Wed, 17 Aug 2016 09:08:57 -0700 (PDT)
In-Reply-To: <201608171550.u7HFo7Wf048341@idle.juniper.net>
References:  <201608171550.u7HFo7Wf048341@idle.juniper.net>
From: Andy Bierman 
Date: Wed, 17 Aug 2016 09:08:57 -0700
Message-ID: 
To: Phil Shafer 
Content-Type: multipart/alternative; boundary=001a114584d0d1c8e3053a46aefb
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 16:09:03 -0000

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

On Wed, Aug 17, 2016 at 8:50 AM, Phil Shafer  wrote:

> Andy Bierman writes:
> >RFC 6241 does not have any text at all that would even slightly
> >suggest that all operations on NP containers should always succeed.
>
>    In the first style, the container has no meaning of its own, existing
>    only to contain child nodes.  This is the default style.
>
>    For example, the set of scrambling options for Synchronous Optical
>    Network (SONET) interfaces may be placed inside a "scrambling"
>    container to enhance the organization of the configuration hierarchy,
>    and to keep these nodes together.  The "scrambling" node itself has
>    no meaning, so removing the node when it becomes empty relieves the
>    user from performing this task.
>
>    In the second style, the presence of the container itself is
>    configuration data, representing a single bit of configuration data.
>    The container acts as both a configuration knob and a means of
>    organizing related configuration.  These containers are explicitly
>    created and deleted.
>
>


> One can infer that since the second style are explicitly created
> and deleted, the first style are implicitly created and deleted.
>
> It seems awkward to say "the client must take particular care in
> creating containers that have no real meaning".   The opposite
> of the Postel Principle.
>
>

But NETCONF already thought of this problem.
It is no different than each server treating defaults differently.
The "merge" and "remove" operations are designed for this exact purpose.
The "create" and "delete" operations were not.



Thanks,
>  Phil
>

Andy

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




On Wed, Aug 17, 2016 at 8:50 AM, Phil Shafer <phil@juniper.net><=
/span> wrote:
Andy Bierman writes:

>RFC 6241 does not have any text at all that would even slightly

>suggest that all operations on NP containers should always succeed.



=C2=A0 =C2=A0In the first style, the container has no meaning of its own, e=
xisting

=C2=A0 =C2=A0only to contain child nodes.=C2=A0 This is the default style.<=
br>


=C2=A0 =C2=A0For example, the set of scrambling options for Synchronous Opt=
ical

=C2=A0 =C2=A0Network (SONET) interfaces may be placed inside a "scramb=
ling"

=C2=A0 =C2=A0container to enhance the organization of the configuration hie=
rarchy,

=C2=A0 =C2=A0and to keep these nodes together.=C2=A0 The "scrambling&q=
uot; node itself has

=C2=A0 =C2=A0no meaning, so removing the node when it becomes empty relieve=
s the

=C2=A0 =C2=A0user from performing this task.



=C2=A0 =C2=A0In the second style, the presence of the container itself is
=C2=A0 =C2=A0configuration data, representing a single bit of configuration=
 data.

=C2=A0 =C2=A0The container acts as both a configuration knob and a means of=


=C2=A0 =C2=A0organizing related configuration.=C2=A0 These containers are e=
xplicitly

=C2=A0 =C2=A0created and deleted.



=C2=A0

One can infer that since the second style are explicitly created

and deleted, the first style are implicitly created and deleted.



It seems awkward to say "the client must take particular care in

creating containers that have no real meaning".=C2=A0 =C2=A0The opposi=
te

of the Postel Principle.




But NETCONF already tho=
ught of this problem.
It is no different than each server treatin=
g defaults differently.
The "merge" and "remove&qu=
ot; operations are designed for this exact purpose.
The "cre=
ate" and "delete" operations were not.

<=
div>


Thanks,

=C2=A0Phil



Andy



--001a114584d0d1c8e3053a46aefb--


From nobody Wed Aug 17 09:47:27 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56EEE12DBE7 for ; Wed, 17 Aug 2016 09:47:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BM-ArSjtWHE for ; Wed, 17 Aug 2016 09:47:24 -0700 (PDT)
Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 4549C12D9A3 for ; Wed, 17 Aug 2016 09:47:24 -0700 (PDT)
Received: by mail-ua0-x22b.google.com with SMTP id n59so180449750uan.2 for ; Wed, 17 Aug 2016 09:47:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+IlBwHeLlC0L1f9PjTjJaDcPc/0omABP2XApfM1X5I8=; b=E+170DuQjeSTUESP2zY0r8dCR7I9qb8p98HyCOHoNQPknwXhuJVweViEkSls9jg22D Z98LIOHJmrwKq0lnKXHK+eXC9EwdDFEGtwN7Gh/lI9hhCx/0kN+IvZAAp5iGE03yzoDj +ZkyFijDbM2OcHzdodbJ35kTW2EUBQDNVEs0mupQK0jq7YmLpptgN/WkRVktz24q1dP8 XBVFLn64mxS7ZHex7F+vm5/JW//bLQKq2UnuqEgejMCU0p5X1BjVkYmRpkpFBnzd8K9e HlkhlgLbg9xmOlp55snbscWmH6xVwoGep38kowVokX0lWDQt205+0FmHUoiiDXuLHhTI 6luQ==
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:from:date :message-id:subject:to:cc; bh=+IlBwHeLlC0L1f9PjTjJaDcPc/0omABP2XApfM1X5I8=; b=ANoxrB1cl+u5Bd8KYGvrN7HMLRlVUR5Iw5T/0Gw003UB4lyxhQxAa7ERTWPZw6GTCn tT/atoMReWrd/Ab9M7PdraqhpDWxKHL8sUZJqrcWYoC+Y8UVJ3PUdrWxeWcA2F3rN5CK jDqDJXfQB3UJMT3BcaYJ0p5URwSesY9/MfACFUiYvYCwslQOeoPE7GWb2OHQm2wNmH9n 3ULU2fgX8szssqyRB8hLKsR3hrHUCVCIjtDaGr2KeGXft6U5I5KbmGXsb/98oVDgG4EY fh4GRwhYzg+dV6sX/D3Ey5C7SkaOKbFNjBTXvMeDWS5fMY/3+wjbN+/5aK8V5L1S3yga jPwQ==
X-Gm-Message-State: AEkoouslPqc0++14qndZ7Cf9UIABHOoYn0LqGw1xtaYSapN8SlY9Fv1JaSluKnqjD4GDah8lIg0khFJ1gxkS1A==
X-Received: by 10.176.68.166 with SMTP id n35mr11171145uan.47.1471452443399; Wed, 17 Aug 2016 09:47:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Wed, 17 Aug 2016 09:47:22 -0700 (PDT)
In-Reply-To: <201608171550.u7HFo7Wf048341@idle.juniper.net>
References:  <201608171550.u7HFo7Wf048341@idle.juniper.net>
From: Andy Bierman 
Date: Wed, 17 Aug 2016 09:47:22 -0700
Message-ID: 
To: Phil Shafer 
Content-Type: multipart/alternative; boundary=94eb2c05c5de3170ec053a47383f
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 16:47:26 -0000

--94eb2c05c5de3170ec053a47383f
Content-Type: text/plain; charset=UTF-8

On Wed, Aug 17, 2016 at 8:50 AM, Phil Shafer  wrote:

> Andy Bierman writes:
> >RFC 6241 does not have any text at all that would even slightly
> >suggest that all operations on NP containers should always succeed.
>
>    In the first style, the container has no meaning of its own, existing
>    only to contain child nodes.  This is the default style.
>
>    For example, the set of scrambling options for Synchronous Optical
>    Network (SONET) interfaces may be placed inside a "scrambling"
>    container to enhance the organization of the configuration hierarchy,
>    and to keep these nodes together.  The "scrambling" node itself has
>    no meaning, so removing the node when it becomes empty relieves the
>    user from performing this task.
>
>    In the second style, the presence of the container itself is
>    configuration data, representing a single bit of configuration data.
>    The container acts as both a configuration knob and a means of
>    organizing related configuration.
> *These containers are explicitly    created and deleted.*
>
> One can infer that since the second style are explicitly created
> and deleted, the first style are implicitly created and deleted.
>
>

No -- I do not see that the text says anything about create and delete
operations in NETCONF.  This section in YANG 1.1 is not even marked
as  in NETCONF like the others.

But if that text is supposed to mean that NP containers are not
explicitly created and deleted, then this text in 7.5.8 is wrong:


   If a container does not have a "presence" statement and the last
   child node is deleted, the NETCONF server MAY delete the container.

This text is explicitly referring to creating and deleting NP container
nodes,
and it contradicts the implied text you cited.


Andy



It seems awkward to say "the client must take particular care in
> creating containers that have no real meaning".   The opposite
> of the Postel Principle.
>
> Thanks,
>  Phil
>

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




On Wed, Aug 17, 2016 at 8:50 AM, Phil Shafer <phil@juniper.net><=
/span> wrote:
Andy Bierman writes:

>RFC 6241 does not have any text at all that would even slightly

>suggest that all operations on NP containers should always succeed.



=C2=A0 =C2=A0In the first style, the container has no meaning of its own, e=
xisting

=C2=A0 =C2=A0only to contain child nodes.=C2=A0 This is the default style.<=
br>


=C2=A0 =C2=A0For example, the set of scrambling options for Synchronous Opt=
ical

=C2=A0 =C2=A0Network (SONET) interfaces may be placed inside a "scramb=
ling"

=C2=A0 =C2=A0container to enhance the organization of the configuration hie=
rarchy,

=C2=A0 =C2=A0and to keep these nodes together.=C2=A0 The "scrambling&q=
uot; node itself has

=C2=A0 =C2=A0no meaning, so removing the node when it becomes empty relieve=
s the

=C2=A0 =C2=A0user from performing this task.



=C2=A0 =C2=A0In the second style, the presence of the container itself is
=C2=A0 =C2=A0configuration data, representing a single bit of configuration=
 data.

=C2=A0 =C2=A0The container acts as both a configuration knob and a means of=


=C2=A0 =C2=A0organizing related configuration.=C2=A0 These containers ar=
e explicitly

=C2=A0 =C2=A0created and deleted.



One can infer that since the second style are explicitly created

and deleted, the first style are implicitly created and deleted.




No -- I do not see that=
 the text says anything about create and delete
operations in NET=
CONF.=C2=A0 This section in YANG 1.1 is not even marked
as <ed=
it-config> in NETCONF like the others.

But if t=
hat text is supposed to mean that NP containers are not
explicitl=
y created and deleted, then this text in 7.5.8 is wrong:


=C2=A0 =C2=A0If a container does not have a &quo=
t;presence" statement and the last
=C2=A0 =C2=A0child node i=
s deleted, the NETCONF server MAY delete the container.
This text is explicitly referring to creating and deleting NP c=
ontainer nodes,
and it contradicts the implied text you cited.


Andy




It seems awkward to say "the client must take particular care in

creating containers that have no real meaning".=C2=A0 =C2=A0The opposi=
te

of the Postel Principle.



Thanks,

=C2=A0Phil





--94eb2c05c5de3170ec053a47383f--


From nobody Wed Aug 17 09:48:12 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7D912DBA6 for ; Wed, 17 Aug 2016 09:48:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4lbWCgo_c6Q for ; Wed, 17 Aug 2016 09:48:09 -0700 (PDT)
Received: from p3plsmtpa08-04.prod.phx3.secureserver.net (p3plsmtpa08-04.prod.phx3.secureserver.net [173.201.193.105]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E01D12D9A3 for ; Wed, 17 Aug 2016 09:48:09 -0700 (PDT)
Received: from xiangliToshiba ([38.124.116.11]) by p3plsmtpa08-04.prod.phx3.secureserver.net with  id YGo71t00K0EpkFa01Go8Xy; Wed, 17 Aug 2016 09:48:09 -0700
From: "Xiang Li" 
To: "'Phil Shafer'" , "'Andy Bierman'" 
References:  <201608171550.u7HFo7Wf048341@idle.juniper.net>
In-Reply-To: <201608171550.u7HFo7Wf048341@idle.juniper.net>
Date: Wed, 17 Aug 2016 11:48:04 -0500
Message-ID: <005d01d1f8a7$20b6c1d0$62244570$@seguesoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQI1CwioKaPXVaIlpC6JshvGpdwcoZ+HKw/A
Content-Language: en-us
Archived-At: 
Cc: 'Netconf' 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 16:48:11 -0000

Hi

> -----Original Message-----
> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Phil Shafer
> Sent: Wednesday, August 17, 2016 10:50 AM
> To: Andy Bierman 
> Cc: Netconf 
> Subject: Re: [Netconf] What should a server response be? - depending on
> NP-containers
> 
> Andy Bierman writes:
> >RFC 6241 does not have any text at all that would even slightly suggest
> >that all operations on NP containers should always succeed.
> 
>    In the first style, the container has no meaning of its own, existing
>    only to contain child nodes.  This is the default style.
> 
>    For example, the set of scrambling options for Synchronous Optical
>    Network (SONET) interfaces may be placed inside a "scrambling"
>    container to enhance the organization of the configuration hierarchy,
>    and to keep these nodes together.  The "scrambling" node itself has
>    no meaning, so removing the node when it becomes empty relieves the
>    user from performing this task.
> 
>    In the second style, the presence of the container itself is
>    configuration data, representing a single bit of configuration data.
>    The container acts as both a configuration knob and a means of
>    organizing related configuration.  These containers are explicitly
>    created and deleted.
> 
> One can infer that since the second style are explicitly created and
deleted,
> the first style are implicitly created and deleted.


I agree with this interpretation.
But current RFC6020bis: Section 7.5.8 clearly suggests that both NP and P
containers
can be manipulated explicitly, except that "If a container does not 
have a "presence" statement and the last child node is deleted, the NETCONF 
server MAY delete the container."

RFC6020bis:
----------------------------------------------------------------------------
---------------
7.5.8.  NETCONF  Operations

   Containers can be created, deleted, replaced, and modified through
   , by using the "operation" attribute (see [RFC6241],
   Section 7.2) in the container's XML element.

   If a container does not have a "presence" statement and the last
   child node is deleted, the NETCONF server MAY delete the container.

When a NETCONF server processes an  request, the
   elements of procedure for the container node are:

      If the operation is "merge" or "replace", the node is created if
      it does not exist.

      If the operation is "create", the node is created if it does not
      exist.  If the node already exists, a "data-exists" error is
      returned.

      If the operation is "delete", the node is deleted if it exists.
      If the node does not exist, a "data-missing" error is returned.


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

I think if this paragraph instead says:

----------------------------------------------------------------------------
-------------
7.5.8.  NETCONF  Operations

 Containers with a "presence" statement can be created, deleted, replaced, 
and modified through , by using the "operation" attribute (see
[RFC6241],
   Section 7.2) in the container's XML element.

When a NETCONF server processes an  request, the
   elements of procedure for the container node with a "presence" statement
are:

      If the operation is "merge" or "replace", the node is created if
      it does not exist.

      If the operation is "create", the node is created if it does not
      exist.  If the node already exists, a "data-exists" error is
      returned.

      If the operation is "delete", the node is deleted if it exists.
      If the node does not exist, a "data-missing" error is returned.

Containers without a "presence" statement are merely structural nodes, and
are
 implicitly created and deleted by the server. 

If a container does not have a "presence" statement, it is created
implicitly 
 along with creating any of its child nodes. If  the last child node of such
a container 
is deleted, the NETCONF server MAY delete the container.

Creating, replacing or deleting a container without a "presence" statement
through 
 explicitly has no effect on server configuration, and would
never
result in an error.

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

would clarify it. But it should not appear as errata item IMO.


> It seems awkward to say "the client must take particular care in
> creating containers that have no real meaning".   The opposite
> of the Postel Principle.

I also don't like the idea of placing this kind of restrictions in the
client. 

Best
-Xiang

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


From nobody Wed Aug 17 10:45:23 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED95912D954; Wed, 17 Aug 2016 10:45:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.768
X-Spam-Level: 
X-Spam-Status: No, score=-15.768 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcGmUd6Zf9_9; Wed, 17 Aug 2016 10:45:19 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0046512D946; Wed, 17 Aug 2016 10:45:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1914; q=dns/txt; s=iport; t=1471455919; x=1472665519; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RmFZcI/aBeykbtuLugnANeG9M7rPrd0wcn2qadY5lf0=; b=FQTvkzS+9Lu9035k1LcgPxunk1oK0vIyCFJL/N52Mu0j0O02tLzwxDG7 vXPqtOWLKKBVbA/L3Z+B5b6E/1tSlTcNyfFpdhMu2J94KaOZE/69SApGy vqxGvmbl8NWwf8570REVmYfQQPAOR+MQRU3ndFROt4CUi0yWwY+H6XfHr k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAgC9obRX/4oNJK1VCYNEVnwHuTOBf?= =?us-ascii?q?SSCQoM3AhyBTjgUAgEBAQEBAQFeJ4ReAQEEAQEBIRE6CwULAgEIGAICJgICAiU?= =?us-ascii?q?LFRACBA4FiCkIDq0KkBkBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYEBhyGCVYE5g?= =?us-ascii?q?mAngwErgi8FmUQBjx2PSYw7g3cBHjaCHyaBNW6FdX8BAQE?=
X-IronPort-AV: E=Sophos;i="5.28,535,1464652800"; d="scan'208";a="310539963"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Aug 2016 17:45:18 +0000
Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u7HHjI5G021376 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 17 Aug 2016 17:45:18 GMT
Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 17 Aug 2016 12:45:17 -0500
Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1210.000; Wed, 17 Aug 2016 12:45:17 -0500
From: "Max Pritikin (pritikin)" 
To: Michael Richardson 
Thread-Topic: [Anima-bootstrap] [Netconf] minutes for anima-bootstrap design team meeting, 2016-08-16
Thread-Index: AQHR9/vYepfUxY+FxUu8HZIY/Q/TqqBMhcuAgAAPAACAAS1IAA==
Date: Wed, 17 Aug 2016 17:45:17 +0000
Message-ID: <9F5B50E2-DFE5-443B-B150-DA30CF8B90D8@cisco.com>
References: <13187.1471375632@obiwan.sandelman.ca>  <3A795BB6-03A8-46B0-9EAD-1607427EE0CD@cisco.com> <7698.1471391216@obiwan.sandelman.ca>
In-Reply-To: <7698.1471391216@obiwan.sandelman.ca>
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.99.106.10]
Content-Type: text/plain; charset="utf-8"
Content-ID: <1E351652970CF345931359A94AE6B6C0@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: anima-bootstrap , "netconf@ietf.org" 
Subject: Re: [Netconf] [Anima-bootstrap] minutes for anima-bootstrap design team meeting, 2016-08-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 Aug 2016 17:45:21 -0000

DQo+IE9uIEF1ZyAxNiwgMjAxNiwgYXQgNTo0NiBQTSwgTWljaGFlbCBSaWNoYXJkc29uIDxtY3Ir
aWV0ZkBzYW5kZWxtYW4uY2E+IHdyb3RlOg0KPiANCj4gDQo+IE1heCBQcml0aWtpbiAocHJpdGlr
aW4pIDxwcml0aWtpbkBjaXNjby5jb20+IHdyb3RlOg0KPj4gVGhlIGNvbW1vbiBlbGVtZW50cyB3
ZeKAmXZlIGRpc2N1c3NlZCBhcmU6DQo+IA0KPj4gMSkgc29tZSB0eXBlIGluZm9ybWF0aW9uDQo+
PiAyKSBzaWduYXR1cmUgYW5kL29yIGVuY3J5cHRpb24gbWV0aG9kDQo+PiAzKSB2YWxpZGl0eSBw
ZXJpb2QgLyBub25jZSB2ZXJpZmljYXRpb24NCj4+IDQpIGNsaWVudCBkZXZpY2UgaWRlbnRpdHkN
Cj4+IDUpIGRvbWFpbiBpZGVudGl0eQ0KPj4gNykgYWJpbGl0eSBmb3IgZXh0ZW5zaWJpbGl0eSg/
KQ0KPiANCj4+IFRoZXJlIGlzIGFsc28gdGhlIGVuY29kaW5nIGNob2ljZXMgdGhhdCBuZWVkIHRv
IGJlIG1hZGUuIElmIGl0IHR1cm5zDQo+PiBvdXQgYW5pbWEgYW5kIG5ldGNvbmYsIGZvciBleGFt
cGxlLCBoYXZlIGVudGlyZWx5IGRpZmZlcmVudA0KPj4gcmVxdWlyZW1lbnRzIGZvciBlbmNvZGlu
ZyAoZS5nLiBvbmUgcmVxdWlyZXMganNvbiBhbmQgdGhlIG90aGVyIGNib3Igb3INCj4+IHNvbWV0
aGluZykgdGhlbiB0aGVyZSBpcyBhIHByb2JsZW0uDQo+IA0KPiBPa2F5LCBzbyBpZiB3ZSBhcmUg
Z29pbmcgdG8gY3JlYXRlIGEgb3duZXJzaGlwIHZvdWNoZXIgZm9ybWF0LCB3aGVyZSB3aWxsIHdl
DQo+IGRvIGl0PyAgIEkgZG9uJ3QgdGhpbmsgaXQncyBhIHF1ZXN0aW9uIGlmIGl0IGZpdHMgaW50
byB0aGUgdmFyaW91cyBjaGFydGVycywNCj4gc28gbXVjaCBhcyB3aGljaCBvbmUgaXQgc2hvdWxk
IGZpdCBpbnRvLg0KDQpCUlNLSSBzZWN0aW9uIDUuMyBzZWVtcyBsb2dpY2FsIHRvIG1lLiA6KSBX
ZSBuZWVkIHNvbWV0aGluZyB0aGVyZSBhbmQsIGxvLCB0aGVyZSBpcyBhIGN1cnJlbnQgZm9ybWF0
IGRlc2NyaWJlZC4gSW4gbXkgbWluZCB3ZeKAmXJlIGRpc2N1c3NpbmcgaWYgdGhpcyBpcyB0aGUg
Y29ycmVjdCBhbmQgY29tcGxldGUgZm9ybWF0IG9yIGlmIHdlIG5lZWQgdG8gc3BlY2lmeSBpdCBm
dXJ0aGVyLg0KDQotIG1heA0KDQo+IA0KPiAtLQ0KPiBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitJ
RVRGQHNhbmRlbG1hbi5jYT4sIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3Jrcw0KPiAtPSBJUHY2IElv
VCBjb25zdWx0aW5nID0tDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fDQo+IEFuaW1hLWJvb3RzdHJhcCBtYWlsaW5nIGxpc3QNCj4g
QW5pbWEtYm9vdHN0cmFwQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vYW5pbWEtYm9vdHN0cmFwDQoNCg==


From nobody Fri Aug 19 06:14:14 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3422312D9BA for ; Fri, 19 Aug 2016 06:14:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.148
X-Spam-Level: 
X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0IJVUqbwl4A for ; Fri, 19 Aug 2016 06:14:12 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 182F212D7E7 for ; Fri, 19 Aug 2016 06:14:11 -0700 (PDT)
Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 11F1E1AE0399 for ; Fri, 19 Aug 2016 15:14:09 +0200 (CEST)
Date: Fri, 19 Aug 2016 15:13:15 +0200 (CEST)
Message-Id: <20160819.151315.521966750953162176.mbj@tail-f.com>
To: netconf@ietf.org
From: Martin Bjorklund 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; boundary="--Next_Part(Fri_Aug_19_15_13_15_2016_979)--"
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [Netconf] YANG 1.1 XML naming restriction in RESTCONF
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2016 13:14:14 -0000

----Next_Part(Fri_Aug_19_15_13_15_2016_979)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

There is a proposal in NETMOD (see attachment) to get rid of the
cl^h^hrule that an identifier must not start with case-insensitive
"xml".  If this proposal is accpted, it also affects RESTCONF.  We
should remove this restriction in Section 3.5.3.1 in
draft-ietf-netconf-restconf-16:

OLD:

   An identifier is not allowed to start with the case-insensitive
   string "XML", according to YANG identifier rules.  The syntax for
   "api-identifier" and "key-value" MUST conform to the JSON identifier
   encoding rules in Section 4 of [I-D.ietf-netmod-yang-json]: The
   RESTCONF root resource path is required.  Additional sub-resource
   identifiers are optional.  The characters in a key value string are
   constrained, and some characters need to be percent-encoded, as
   described in Section 3.5.3.

   ...

       ;; An identifier MUST NOT start with
       ;; (('X'|'x') ('M'|'m') ('L'|'l'))
       identifier  = (ALPHA / "_")
                     *(ALPHA / DIGIT / "_" / "-" / ".")

NEW:

   The syntax for
   "api-identifier" and "key-value" MUST conform to the JSON identifier
   encoding rules in Section 4 of [I-D.ietf-netmod-yang-json]: The
   RESTCONF root resource path is required.  Additional sub-resource
   identifiers are optional.  The characters in a key value string are
   constrained, and some characters need to be percent-encoded, as
   described in Section 3.5.3.

   ...

       identifier  = (ALPHA / "_")
                     *(ALPHA / DIGIT / "_" / "-" / ".")



/martin


----Next_Part(Fri_Aug_19_15_13_15_2016_979)--
Content-Type: Message/Rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Return-Path: 
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on metgos.tail-f.com
X-Spam-Level: 
X-Spam-Status: No, score=-103.1 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,
	RCVD_IN_MSPIKE_H2,RP_MATCHES_RCVD,SPF_PASS,T_DKIM_INVALID,
	T_HEADER_FROM_DIFFERENT_DOMAINS,USER_IN_WHITELIST autolearn=ham
	autolearn_force=no version=3.4.0
X-Original-To: mbj@tail-f.com
Delivered-To: mbj@tail-f.com
Received: from mail.ietf.org (mail.ietf.org [4.31.198.44])
	by mail.tail-f.com (Postfix) with ESMTPS id A57B91AE0187;
	Thu, 18 Aug 2016 12:02:30 +0200 (CEST)
Received: from ietfa.amsl.com (localhost [IPv6:::1])
	by ietfa.amsl.com (Postfix) with ESMTP id D706F12D51A;
	Thu, 18 Aug 2016 03:02:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1;
	t=1471514547; bh=ZvZycwxcFE/trr7emNkM8HNg+Vkm8TZ1FC8HkpMk+vA=;
	h=Date:From:To:Subject:Reply-To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe;
	b=S2rnc8pDCKgLkDUxIwKmhVG6sPkY6EfOKw759nrpb1f1kx8TGm8g4nf6hi1oJGStn
	 +b2y0Ab93YdzMMuCNy+JlmU41A6KAMltVONaVU7bGWt/UTHabppo8WqBU5GCD/qjBL
	 Z6+obuTgbs9HbTqWjV7aV23893nkQ2eJPHN4x0To=
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
 by ietfa.amsl.com (Postfix) with ESMTP id 654AD12D56D
 for ; Thu, 18 Aug 2016 03:02:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([4.31.198.44])
 by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id QPG7IhOcS3Tl for ;
 Thu, 18 Aug 2016 03:02:10 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de
 [212.201.44.18])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by ietfa.amsl.com (Postfix) with ESMTPS id 7488F12D16D
 for ; Thu, 18 Aug 2016 03:02:10 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222])
 by atlas3.jacobs-university.de (Postfix) with ESMTP id 39BFB8F7
 for ; Thu, 18 Aug 2016 12:02:09 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.205])
 by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new,
 port 10030) with ESMTP id oPtOnZ4M3tq8 for ;
 Thu, 18 Aug 2016 12:02:08 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de
 [212.201.44.23])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "hermes.jacobs-university.de",
 Issuer "Jacobs University CA - G01" (verified OK))
 by atlas3.jacobs-university.de (Postfix) with ESMTPS
 for ; Thu, 18 Aug 2016 12:02:08 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47])
 by hermes.jacobs-university.de (Postfix) with ESMTP id 309BE200A5
 for ; Thu, 18 Aug 2016 12:02:08 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23])
 by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new,
 port 10024)
 with ESMTP id 8fZS0fDh6pMf; Thu, 18 Aug 2016 12:02:03 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de
 [10.50.231.133])
 by hermes.jacobs-university.de (Postfix) with ESMTP id 0B83B200A3;
 Thu, 18 Aug 2016 12:02:03 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501)
 id 426DF3C24619; Thu, 18 Aug 2016 12:02:02 +0200 (CEST)
Date: Thu, 18 Aug 2016 12:02:01 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20160818100201.GA4794@elstar.local>
Mail-Followup-To: netmod@ietf.org
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Subject: [netmod] YANG 1.1 bug fix last call (was YANG 1.1: XML naming
	restriction)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: ,
 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: netmod-bounces@ietf.org
Sender: "netmod" 
X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4
   int  cnt   prob  spamicity histogram
  0.00  149 0.016502 0.015742 ################################################
  0.10    8 0.111940 0.021464 ###
  0.20    0 0.000000 0.021464 
  0.30    0 0.000000 0.021464 
  0.40    0 0.000000 0.021464 
  0.50    0 0.000000 0.021464 
  0.60    0 0.000000 0.021464 
  0.70    0 0.000000 0.021464 
  0.80    0 0.000000 0.021464 
  0.90    0 0.000000 0.021464 

Hi,

as discussed in the thread 'YANG 1.1: XML naming restriction', it
seems that the restriction that identifiers may not start with "xml"
is not necessary according to XML 1.0 (5th edition). In addition, it
seems the YANG 1.1 specification should have an explicit normative
reference to the XML specification it is based on. The suggested
document changes are detailed below (thanks to Martin for writing this
up). Please let the WG know by August 24th if you object against
implementing this change before YANG 1.1 is published.

/js (with my RFC6020bis document shepherd hat on)

Section 1:

OLD:

   This document describes the syntax and semantics of version 1.1 of
   the YANG language.  It also describes how a data model defined in a
   YANG module is encoded in the Extensible Markup Language (XML), and

NEW:

   This document describes the syntax and semantics of version 1.1 of
   the YANG language.  It also describes how a data model defined in a
   YANG module is encoded in the Extensible Markup Language (XML)
   [XML], and


Section 1.1:

OLD:

   o  Allow type empty in a key.

   The following changes have been done to the NETCONF mapping:

NEW:

   o  Allow type empty in a key.

   o  Removed the restriction that identifiers could not start with
      the characters "xml".

   The following changes have been done to the NETCONF mapping:


Section 14:

OLD:

   ;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l'))
   identifier          = (ALPHA / "_")
                         *(ALPHA / DIGIT / "_" / "-" / ".")

NEW:

   identifier          = (ALPHA / "_")
                         *(ALPHA / DIGIT / "_" / "-" / ".")


Section 21.1:

NEW:

   [XML]      Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
              F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
              Edition)", World Wide Web Consortium Recommendation REC-
              xml-20081126, November 2008,
              .


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


----Next_Part(Fri_Aug_19_15_13_15_2016_979)----


From nobody Fri Aug 19 16:50:53 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA27012D150 for ; Fri, 19 Aug 2016 16:50:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLQ7CJgbdGoy for ; Fri, 19 Aug 2016 16:50:47 -0700 (PDT)
Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::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 81E7212D14A for ; Fri, 19 Aug 2016 16:50:47 -0700 (PDT)
Received: by mail-ua0-x232.google.com with SMTP id 97so105525419uav.3 for ; Fri, 19 Aug 2016 16:50:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KqqhvwbpLSWm68lVccL8A+60QKspvov0Rw4bTqrwl/4=; b=z58g7rGTjEP+x08urRo2lXuN+fp5sVara4VYFUxv+J0uk5v2YBGf5EX4gp1UTDrS5l apQ+HLKgXrqrEFkPD9EbgiLHrfxF3VrfQnEMJz0gHaId5DWfbeL6DwvM7sZRmV1jrSOH eyuZCpFCo09O5Ywiw/zXdrCYipbOARxG8c9k4Vgy3c0JB1lOtA4ZY15vPgKYFnBXqRVr KRtkwBtiCtkk0kkKC/Ibh2HKLwfWFHEr3SuBEctKai8rNfuG/WCObW46R5gDZU/EdKp2 1mTZVH/CCkEHkILe0Zp6K4s06eN5xU0QBkdvQIM+snRjI1cjoFfUZltFmiZXEEuTyDGk wYDQ==
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:from:date :message-id:subject:to:cc; bh=KqqhvwbpLSWm68lVccL8A+60QKspvov0Rw4bTqrwl/4=; b=C+sPe+gQR4pFao+em3bi7cLrRQZn+PFaGNYUCGjw5gfQ5NfJcqZn2p1faS0+D8iI+P /uLI/J5jYlSG6mQNCPbVmXFC8ISkaLG4TV1MtMMrNsVk3rr68XhahQcXTxcVW/obgnYk +rjAwNJ8LH1HGM9ispc8ZxnDZoX4Kc8r+xKXxXqCNcmBzQLKB+6wEo/JtZa+Xpm8jHg3 5b9o28QZHUdK2C0Pn5aW5jRtKlLBwPe5DuxwQB4vzE1hgex+CjrBxu4Bva1KXETiyX7+ kXtRsa8O6XD26UDKacAui9MB00WtaUtjwOFy39dcHeWz/eLEss68VtrrfaekyPq+Mzsm ABkA==
X-Gm-Message-State: AEkoouut1U8354e9J4MWDvYS6juLW1neiBPshenbhsvwKo+UVXBtHE5xomF51iE7WnZMhhMm4aO8GSpuNfvXLQ==
X-Received: by 10.176.68.166 with SMTP id n35mr5716947uan.47.1471650646602; Fri, 19 Aug 2016 16:50:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.134 with HTTP; Fri, 19 Aug 2016 16:50:45 -0700 (PDT)
In-Reply-To: <20160817.111343.387561472405973484.mbj@tail-f.com>
References:  <57AC713E.8080006@transpacket.com> <20160817.102821.2247775938129211118.mbj@tail-f.com> <20160817.111343.387561472405973484.mbj@tail-f.com>
From: Andy Bierman 
Date: Fri, 19 Aug 2016 16:50:45 -0700
Message-ID: 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=94eb2c05c5de0650da053a755ec4
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2016 23:50:50 -0000

--94eb2c05c5de0650da053a755ec4
Content-Type: text/plain; charset=UTF-8

Hi,

I think we agree that YANG 1.1 says an NP container exists if its parent
exists.
I am not proposing to change that consensus, and perhaps nobody else is
either.

So now we have a definition of an NP container instance.
NETCONF is rather clear wrt/ how operations behave regarding data node
existence.

Using this rather clear definition of NETCONF edit operations and
NP container existence, it seems obvious that

  1) a "create" operation always fails on an NP container with a
data-exists error
  2) a "delete" operation never fails because of a data-missing error.
     Both "delete" and "remove" justs deletes all child nodes.  They have
no affect on empty
     NP containers

This would be consistent with RFC 6241 and how we already treat default
leafs.


Andy


On Wed, Aug 17, 2016 at 2:13 AM, Martin Bjorklund  wrote:

> Hi,
>
> I have read this long ML thread twice now, and I agree with Andy that:
>
> 1)  We should not / cannot make design changes in an errata or late in
>     AUTH48; in order to do this we need to pull the document back to
>     the WG and reach (rough) consensus on the behavior (note btw that
>     this thread is currently in NETCONF, it really should be NETMOD).
>
> 2)  Since servers MAY delete NP-containers in some cases, clients can
>     easily handle NP-containers by using "merge" on them.
>
>
> I also agree with Jason that ideally the server should never fail on
> any kind of operation on an NP-container, regardless of current state
> and requested operation.  (But again, this is not a simple
> clarification of the current text.)
>
>
> And to answer the original question, I think the server that first got
> a request to create the empty NP-containers and then a request w/
> operation "none" is not correct when it fails with a "data-missing"
> error.  There is no text in 6241 or 6020 that supports this behavior.
>
>
> /martin
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>

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


Hi,

I think we agree that YANG 1.1 says=
 an NP container exists if its parent exists.
I am not proposing =
to change that consensus, and perhaps nobody else is either.

=

So now we have a definition of an NP container instance.
NETCONF is rather clear wrt/ how operations behave regarding data node e=
xistence.

Using this rather clear definition of NE=
TCONF edit operations and
NP container existence, it seems obviou=
s that

=C2=A0 1) a "create" operation al=
ways fails on an NP container with a data-exists error
=C2=A0 2) =
a "delete" operation never fails because of a data-missing error.=

=C2=A0 =C2=A0 =C2=A0Both "delete" and "remove&quo=
t;=C2=A0justs deletes all child nodes.=C2=A0 They have no affect on empty
=C2=A0 =C2=A0 =C2=A0NP containers

This wo=
uld be consistent with RFC 6241 and how we already treat default leafs.


Andy


On Wed, Aug 17, 2016 at 2=
:13 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Hi,



I have read this long ML thread twice now, and I agree with Andy that:



1)=C2=A0 We should not / cannot make design changes in an errata or late in=


=C2=A0 =C2=A0 AUTH48; in order to do this we need to pull the document back=
 to

=C2=A0 =C2=A0 the WG and reach (rough) consensus on the behavior (note btw =
that

=C2=A0 =C2=A0 this thread is currently in NETCONF, it really should be NETM=
OD).



2)=C2=A0 Since servers MAY delete NP-containers in some cases, clients can<=
br>
=C2=A0 =C2=A0 easily handle NP-containers by using "merge" on the=
m.





I also agree with Jason that ideally the server should never fail on

any kind of operation on an NP-container, regardless of current state

and requested operation.=C2=A0 (But again, this is not a simple

clarification of the current text.)





And to answer the original question, I think the server that first got

a request to create the empty NP-containers and then a request w/

operation "none" is not correct when it fails with a "data-m=
issing"

error.=C2=A0 There is no text in 6241 or 6020 that supports this behavior.<=
br>




/martin



_______________________________________________

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mailman/listinfo/netconf<=
br>




--94eb2c05c5de0650da053a755ec4--


From nobody Fri Aug 19 19:04:19 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1FC012D135; Fri, 19 Aug 2016 19:04:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFHaf6vANDLq; Fri, 19 Aug 2016 19:04:13 -0700 (PDT)
Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C07EB12B076; Fri, 19 Aug 2016 19:04:13 -0700 (PDT)
Received: by mail-pf0-x235.google.com with SMTP id x72so14333850pfd.2; Fri, 19 Aug 2016 19:04:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DHgdOanVhXeSUmt5Or72obFMANROWB3bEAN6zRpyhWM=; b=bUJY8NQozp9etJ8QYWgHS37J/huopGTX0lC+uRONPEkU6QCRyiQPuMhH8OY+yeSvZO uicbeJNrlshBwOwyZf6uvflX3aMaufr77EF8VzxPlJETH6C3vD4sdjCtEmWQatE9kX1w 7okfg+Objoq8bk+neM6dac+TP0FR5qQ3YRDu2N6OHFyAnqCn1dVPPIvOZbHdw02pUe+z OSHOiSR0U1yTCsiI8rfStikMjFJ4i2v8gtfdym9+mvJ25GX28XeQFO6nXmqOh6k2iJMc 6rYEPvmfZdFL+3Vyh8BIgGWaPDTIWd5B1D3e15p84tcoNaTz9nR25c7UhKPEdtA8e3Py N/NA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DHgdOanVhXeSUmt5Or72obFMANROWB3bEAN6zRpyhWM=; b=LVOjTyY8lgK9s4usBGuKLoItVCLCENzLRAm73O8JDNbdQjbmv5t4T76J+/V8uwI9kt 2qRXKhdjRdQsaOk8cF2bkmglsN4rDGIe2oHbtIJHDeq76lq+3glE8idCja5ApXOwJHao Hp/ns6B4UTyHOlvcZcaCTRyzpjmdesSQTZs1lSBKkupuu3fNkTD/B7C5H69uASF2ekqD sg7BsVw6hw2utGiG+dP0Nyhm84tox0ZO3dKTebn2gs3FzrcEc0mcez6E9rKMf7teke8y u5S2fC1fLZ/ntoTz6gw42s8jRO3gYXpkYYjsQnupsvvgh/aYy1VFYFQXEKVPBEfY/JX+ Ad5g==
X-Gm-Message-State: AEkoousdDrxnhxRFk5o7f/h33FbyLYsNZRIDGmnqPB/fkfUVhERJdmRQ5/w/nKrFkts+BA==
X-Received: by 10.98.34.151 with SMTP id p23mr19943169pfj.102.1471658653295; Fri, 19 Aug 2016 19:04:13 -0700 (PDT)
Received: from sjc-mahesh-nitro6.cisco.com ([128.107.241.170]) by smtp.gmail.com with ESMTPSA id wp4sm14420649pab.15.2016.08.19.19.04.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 19 Aug 2016 19:04:11 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mahesh Jethanandani 
In-Reply-To: <20160817.111343.387561472405973484.mbj@tail-f.com>
Date: Fri, 19 Aug 2016 19:04:10 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <08053DE7-EF6C-4A14-B926-79723F516405@gmail.com>
References:  <57AC713E.8080006@transpacket.com> <20160817.102821.2247775938129211118.mbj@tail-f.com> <20160817.111343.387561472405973484.mbj@tail-f.com>
To: Martin Bjorklund 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Netconf , netmod WG 
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 20 Aug 2016 02:04:16 -0000

Moving the thread from netconf to netmod.

Will the authors pull 6020bis back into the WG to reach the rough consensus?

> On Aug 17, 2016, at 2:13 AM, Martin Bjorklund  wrote:
> 
> Hi,
> 
> I have read this long ML thread twice now, and I agree with Andy that:
> 
> 1)  We should not / cannot make design changes in an errata or late in
>    AUTH48; in order to do this we need to pull the document back to
>    the WG and reach (rough) consensus on the behavior (note btw that
>    this thread is currently in NETCONF, it really should be NETMOD).
> 
> 2)  Since servers MAY delete NP-containers in some cases, clients can
>    easily handle NP-containers by using "merge" on them.
> 
> 
> I also agree with Jason that ideally the server should never fail on
> any kind of operation on an NP-container, regardless of current state
> and requested operation.  (But again, this is not a simple
> clarification of the current text.)
> 
> 
> And to answer the original question, I think the server that first got
> a request to create the empty NP-containers and then a request w/
> operation "none" is not correct when it fails with a "data-missing"
> error.  There is no text in 6241 or 6020 that supports this behavior.
> 
> 
> /martin
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
mjethanandani@gmail.com




From nobody Mon Aug 22 00:52:23 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC1912B025 for ; Mon, 22 Aug 2016 00:52:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.55
X-Spam-Level: 
X-Spam-Status: No, score=-0.55 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMRiOQxd70Je for ; Mon, 22 Aug 2016 00:52:21 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1278C12B00B for ; Mon, 22 Aug 2016 00:52:21 -0700 (PDT)
Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id D01DD1AE00B6 for ; Mon, 22 Aug 2016 09:52:19 +0200 (CEST)
Date: Mon, 22 Aug 2016 09:51:25 +0200 (CEST)
Message-Id: <20160822.095125.441569814811766535.mbj@tail-f.com>
To: netconf@ietf.org
From: Martin Bjorklund 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [Netconf] YANG Patch target resource issue
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Aug 2016 07:52:22 -0000

Hi,

I got a question from a developer if the target resource for a PATCH
request must exist, or if it should be created by the server if it
doesn't exist.

The RESTCONF spec is silent on this issue.

The HTTP spec for PATCH (RFC 5789) says:

   If the Request-URI does not
   point to an existing resource, the server MAY create a new resource,
   depending on the patch document type (whether it can logically modify
   a null resource) and permissions, etc.

This text seems to indicate that each patch-format specification must
indicate if the target resource must exist or not.

If this interpretation is correct, both the YANG Patch document and
RESTCONF (which defines Plain Patch) need to specify this behavior.

Alternatively, RESTCONF should specify this for the PATCH method, for
all patch formats.



/martin


From nobody Mon Aug 22 01:06:46 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8692712B00A for ; Mon, 22 Aug 2016 01:06:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.548
X-Spam-Level: 
X-Spam-Status: No, score=-7.548 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.548] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7tReCnAy_pT for ; Mon, 22 Aug 2016 01:06:43 -0700 (PDT)
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 8740F12B03A for ; Mon, 22 Aug 2016 01:06:43 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:c91d:9203:b6d5:6ec4] (unknown [IPv6:2001:718:1a02:1:c91d:9203:b6d5:6ec4]) by mail.nic.cz (Postfix) with ESMTPSA id 0A1E560BF3; Mon, 22 Aug 2016 10:06:42 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1471853202; bh=L9OtwrbTvktwHfYkyDFoqZZbVpnq5+qWvYWhIlxJYqE=; h=From:Date:To; b=evGgAF8OO1ri/UPlXu5YsSFLyizo0CbdBBfo45Kxt1zlvu0T8Jrqdq1VC/C5hV42s qp53YtTvhwLsl5Mp0g7+Ce2MQuo/wMP94DcnsHjS/VipilRZkZf6QHM+rMW0NY3r1x wgkWr0RjWsYgMUSnhrfctzpVe7Z98iHPdbr7m21A=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <20160822.095125.441569814811766535.mbj@tail-f.com>
Date: Mon, 22 Aug 2016 10:06:42 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <2912B3AE-4A00-4A73-801D-A3EE60234952@nic.cz>
References: <20160822.095125.441569814811766535.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] YANG Patch target resource issue
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Aug 2016 08:06:45 -0000

> On 22 Aug 2016, at 09:51, Martin Bjorklund  wrote:
>=20
> Hi,
>=20
> I got a question from a developer if the target resource for a PATCH
> request must exist, or if it should be created by the server if it
> doesn't exist.
>=20
> The RESTCONF spec is silent on this issue.
>=20
> The HTTP spec for PATCH (RFC 5789) says:
>=20
>   If the Request-URI does not
>   point to an existing resource, the server MAY create a new resource,
>   depending on the patch document type (whether it can logically =
modify
>   a null resource) and permissions, etc.
>=20
> This text seems to indicate that each patch-format specification must
> indicate if the target resource must exist or not.
>=20
> If this interpretation is correct, both the YANG Patch document and
> RESTCONF (which defines Plain Patch) need to specify this behavior.
>=20
> Alternatively, RESTCONF should specify this for the PATCH method, for
> all patch formats.
>=20

IMO, the server should only "create" an NP-container or a leaf(-list) =
with a default value specified in the data model. Everything else should =
result in Error 404.

Lada

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

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





From nobody Mon Aug 22 08:16:09 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C8E12B075 for ; Mon, 22 Aug 2016 08:16:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level: 
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3_5Bw_xDvmG for ; Mon, 22 Aug 2016 08:16:05 -0700 (PDT)
Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (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 727CF12B056 for ; Mon, 22 Aug 2016 08:16:04 -0700 (PDT)
Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-08v.sys.comcast.net with SMTP id bqq3bXV3084vjbqxHbdvAc; Mon, 22 Aug 2016 15:16:03 +0000
Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-ch2-10v.sys.comcast.net with SMTP id bqxGbBrctduaCbqxHbAHFe; Mon, 22 Aug 2016 15:16:03 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u7MFG18k026039; Mon, 22 Aug 2016 11:16:01 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u7MFG18U026032; Mon, 22 Aug 2016 11:16:01 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com (Dale R. Worley)
To: Martin Bjorklund 
In-Reply-To: <20160822.095125.441569814811766535.mbj@tail-f.com>
Sender: worley@ariadne.com (Dale R. Worley)
Date: Mon, 22 Aug 2016 11:16:01 -0400
Message-ID: <87pop04yxa.fsf@hobgoblin.ariadne.com>
X-CMAE-Envelope: MS4wfCFgIhkH0uwHniqg99C2P4VrGr3hffK0BDuJrdH0Y4Xqpe42O6UkHz8ovrxoiZqXrG/pumdpy2zDdxe25FG/niP/MwFV2Okp0vFfUQm/wtN7cE7ICpqg LVKr0Jt92Od5qgyHM61Oo9I3OKTVkM1v9dCFqHMxz7mJyd591jWrueroqbpGOk5gIWOhjkL99A+ZdUTMqesNH124mkurhflRB/I=
Archived-At: 
Cc: netconf@ietf.org
Subject: Re: [Netconf] YANG Patch target resource issue
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Aug 2016 15:16:06 -0000

Martin Bjorklund  writes:
> If this interpretation is correct, both the YANG Patch document and
> RESTCONF (which defines Plain Patch) need to specify this behavior.

I agree that this aspect of behavior needs to be specified somewhere.

Looking at draft-ietf-netconf-restconf-15, I see in section 4:

   The "remove" operation attribute for the NETCONF 
   operation is not supported by the HTTP DELETE method.  The resource
   must exist or the DELETE method will fail.  The PATCH method is
   equivalent to a "merge" operation when using a plain patch (see
   Section 4.6.1); other media-types may provide more granular control.

This suggests that the resource URL could be non-existing, and the plain
patch creates that resource.

Dale


From nobody Mon Aug 22 08:48:50 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE64012D61A for ; Mon, 22 Aug 2016 08:48:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyDI6JW-pl-G for ; Mon, 22 Aug 2016 08:48:47 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 85D6012D741 for ; Mon, 22 Aug 2016 08:48:47 -0700 (PDT)
Received: from localhost (h-85-226.a165.priv.bahnhof.se [94.254.85.226]) by mail.tail-f.com (Postfix) with ESMTPSA id D54B61AE00B6; Mon, 22 Aug 2016 17:48:42 +0200 (CEST)
Date: Mon, 22 Aug 2016 17:48:42 +0200 (CEST)
Message-Id: <20160822.174842.47995237712639601.mbj@tail-f.com>
To: worley@ariadne.com
From: Martin Bjorklund 
In-Reply-To: <87pop04yxa.fsf@hobgoblin.ariadne.com>
References: <20160822.095125.441569814811766535.mbj@tail-f.com> <87pop04yxa.fsf@hobgoblin.ariadne.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: netconf@ietf.org
Subject: Re: [Netconf] YANG Patch target resource issue
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Aug 2016 15:48:49 -0000

worley@ariadne.com (Dale R. Worley) wrote:
> Martin Bjorklund  writes:
> > If this interpretation is correct, both the YANG Patch document and
> > RESTCONF (which defines Plain Patch) need to specify this behavior.
> 
> I agree that this aspect of behavior needs to be specified somewhere.
> 
> Looking at draft-ietf-netconf-restconf-15, I see in section 4:
> 
>    The "remove" operation attribute for the NETCONF 
>    operation is not supported by the HTTP DELETE method.  The resource
>    must exist or the DELETE method will fail.  The PATCH method is
>    equivalent to a "merge" operation when using a plain patch (see
>    Section 4.6.1); other media-types may provide more granular control.
> 
> This suggests that the resource URL could be non-existing, and the plain
> patch creates that resource.

I think this text means that the contents of the body of the request
is merged into the datastore.  It doesn't necessarily mean that the
target resource is created if it doesn't exist (and all its
ancestors).


/martin


From nobody Mon Aug 22 09:09:55 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C912F12D65F for ; Mon, 22 Aug 2016 09:09:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eh-egwOJVr9g for ; Mon, 22 Aug 2016 09:09:53 -0700 (PDT)
Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::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 4BDB212D124 for ; Mon, 22 Aug 2016 09:09:53 -0700 (PDT)
Received: by mail-ua0-x232.google.com with SMTP id n59so197188548uan.2 for ; Mon, 22 Aug 2016 09:09:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+mbzHgSV/RRpjTzmDiwuFrVd9YR7Q68WrCdr7sgUYPs=; b=dQOnQVMTNkTGfujtujYo6AmpSg3nVDYMY6mPP1Q4U19ip3ek9C1HYTQQQUr0SsbYNd WmEBcsQjfUvUFpa4tCZKydoeheacXiiubVQWI1GweVgYSF7buHDozdOHQej3NwjMOZNv 0xZePC/Xyi3H+8IIxTGXvfIZxQsRm+KjQ0RWSybMauJIJ8EvR6nek27M6q3ZPQxY8tx5 sstJoa9SL19Pe5+lGC60CG4v0KBEnMMScrSdOSHhkYG0phgSknNNDq5zU2B3QmtCEc9f XtuY7BM5GNxNr5wGsqWNsW/0WCv9WDeOKJcx1tUj+1oAP504RkhnXDWCH6Msx55lA7WI 1F7Q==
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:from:date :message-id:subject:to:cc; bh=+mbzHgSV/RRpjTzmDiwuFrVd9YR7Q68WrCdr7sgUYPs=; b=ZADmzF3KCG45bW15Z1thU1gR9YJHEWzJzB01a8Uz8Iv11kOqIT+6uCzeXg8Gc342Re 0QKWZKuMPWk9OQm8fUTGTVQFh/7X19CVkVut8gWXo50w/NSh0F+VKycaLAn23q/yTkbG BCNil71Xniw8gM3sNG8zCTPJx4CXeg6TU1d0S6DR7SoX1d+CqF7/5M4R9DiumKa6TPZA fKzczQ8qPTd7WcB4ahvtspClQLeEXqIpKfNP+p5DNlVBh/4mHcngjDcqaZ2vkFjNbkkN +iF0r/ItHTzWzI5zYpnzNwugnVzcSDPOXT5Krm+qM2Of5pEoAQG3FXTfF+Ut/daFAHLi 740g==
X-Gm-Message-State: AEkooutjFeuGYJL5VX6x0RPgO73WjYdi0JKtwUZrA482VTiwqTCtfZpfUlNQy4U2UGIQKqcN5/Mh/shdbX+xMw==
X-Received: by 10.176.68.166 with SMTP id n35mr12166818uan.47.1471882192312; Mon, 22 Aug 2016 09:09:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.134 with HTTP; Mon, 22 Aug 2016 09:09:51 -0700 (PDT)
In-Reply-To: <20160822.174842.47995237712639601.mbj@tail-f.com>
References: <20160822.095125.441569814811766535.mbj@tail-f.com> <87pop04yxa.fsf@hobgoblin.ariadne.com> <20160822.174842.47995237712639601.mbj@tail-f.com>
From: Andy Bierman 
Date: Mon, 22 Aug 2016 09:09:51 -0700
Message-ID: 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=94eb2c05c5de39703d053aab476f
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] YANG Patch target resource issue
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Aug 2016 16:09:54 -0000

--94eb2c05c5de39703d053aab476f
Content-Type: text/plain; charset=UTF-8

On Mon, Aug 22, 2016 at 8:48 AM, Martin Bjorklund  wrote:

> worley@ariadne.com (Dale R. Worley) wrote:
> > Martin Bjorklund  writes:
> > > If this interpretation is correct, both the YANG Patch document and
> > > RESTCONF (which defines Plain Patch) need to specify this behavior.
> >
> > I agree that this aspect of behavior needs to be specified somewhere.
> >
> > Looking at draft-ietf-netconf-restconf-15, I see in section 4:
> >
> >    The "remove" operation attribute for the NETCONF 
> >    operation is not supported by the HTTP DELETE method.  The resource
> >    must exist or the DELETE method will fail.  The PATCH method is
> >    equivalent to a "merge" operation when using a plain patch (see
> >    Section 4.6.1); other media-types may provide more granular control.
> >
> > This suggests that the resource URL could be non-existing, and the plain
> > patch creates that resource.
>
> I think this text means that the contents of the body of the request
> is merged into the datastore.  It doesn't necessarily mean that the
> target resource is created if it doesn't exist (and all its
> ancestors).
>
>
>
agreed

IMO the target resource MUST exist for YANG Patch (and plain PATCH
in RESTCONF).




> /martin
>


Andy


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

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




On Mon, Aug 22, 2016 at 8:48 AM, Martin Bjorklund <=
;mbj@tail-f.com>=
 wrote:
worley@ariadne.com (Dale R. Worley) wrote:

> Martin Bjorklund <mbj@tail-f.com<=
/a>> writes:

> > If this interpretation is correct, both the YANG Patch document a=
nd

> > RESTCONF (which defines Plain Patch) need to specify this behavio=
r.

>

> I agree that this aspect of behavior needs to be specified somewhere.<=
br>
>

> Looking at draft-ietf-netconf-restconf-15, I see in section 4:
>

>=C2=A0 =C2=A0 The "remove" operation attribute for the NETCON=
F <edit-config>

>=C2=A0 =C2=A0 operation is not supported by the HTTP DELETE method.=C2=
=A0 The resource

>=C2=A0 =C2=A0 must exist or the DELETE method will fail.=C2=A0 The PATC=
H method is

>=C2=A0 =C2=A0 equivalent to a "merge" operation when using a =
plain patch (see

>=C2=A0 =C2=A0 Section 4.6.1); other media-types may provide more granul=
ar control.

>

> This suggests that the resource URL could be non-existing, and the pla=
in

> patch creates that resource.



I think this text means that the contents of the body of the request

is merged into the datastore.=C2=A0 It doesn't necessarily mean that th=
e

target resource is created if it doesn't exist (and all its

ancestors).









/martin





_______________________________________________

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mailman/listinfo/netconf<=
br>




--94eb2c05c5de39703d053aab476f--


From nobody Mon Aug 22 10:00:09 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB00312D520 for ; Mon, 22 Aug 2016 10:00:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrhIuMoGuBpi for ; Mon, 22 Aug 2016 10:00:06 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 252D412D179 for ; Mon, 22 Aug 2016 10:00:06 -0700 (PDT)
Received: from localhost (h-85-226.a165.priv.bahnhof.se [94.254.85.226]) by mail.tail-f.com (Postfix) with ESMTPSA id C16021AE00B6; Mon, 22 Aug 2016 19:00:04 +0200 (CEST)
Date: Mon, 22 Aug 2016 19:00:04 +0200 (CEST)
Message-Id: <20160822.190004.948480241612659981.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund 
In-Reply-To: 
References: <87pop04yxa.fsf@hobgoblin.ariadne.com> <20160822.174842.47995237712639601.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: netconf@ietf.org
Subject: Re: [Netconf] YANG Patch target resource issue
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 Aug 2016 17:00:08 -0000

Andy Bierman  wrote:
> On Mon, Aug 22, 2016 at 8:48 AM, Martin Bjorklund  wrote:
> 
> > worley@ariadne.com (Dale R. Worley) wrote:
> > > Martin Bjorklund  writes:
> > > > If this interpretation is correct, both the YANG Patch document and
> > > > RESTCONF (which defines Plain Patch) need to specify this behavior.
> > >
> > > I agree that this aspect of behavior needs to be specified somewhere.
> > >
> > > Looking at draft-ietf-netconf-restconf-15, I see in section 4:
> > >
> > >    The "remove" operation attribute for the NETCONF 
> > >    operation is not supported by the HTTP DELETE method.  The resource
> > >    must exist or the DELETE method will fail.  The PATCH method is
> > >    equivalent to a "merge" operation when using a plain patch (see
> > >    Section 4.6.1); other media-types may provide more granular control.
> > >
> > > This suggests that the resource URL could be non-existing, and the plain
> > > patch creates that resource.
> >
> > I think this text means that the contents of the body of the request
> > is merged into the datastore.  It doesn't necessarily mean that the
> > target resource is created if it doesn't exist (and all its
> > ancestors).
> >
> >
> >
> agreed
> 
> IMO the target resource MUST exist for YANG Patch (and plain PATCH
> in RESTCONF).

I agree.  The text need to make this clear.


/martin


From nobody Fri Aug 26 00:56:32 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3D512D0C4 for ; Fri, 26 Aug 2016 00:56:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSlo4Pa5st9a for ; Fri, 26 Aug 2016 00:56:29 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8784812D09C for ; Fri, 26 Aug 2016 00:56:29 -0700 (PDT)
Received: from localhost (unknown [173.38.220.42]) by mail.tail-f.com (Postfix) with ESMTPSA id 71FE61AE018C for ; Fri, 26 Aug 2016 09:56:23 +0200 (CEST)
Date: Fri, 26 Aug 2016 09:55:28 +0200 (CEST)
Message-Id: <20160826.095528.319078548872509327.mbj@tail-f.com>
To: netconf@ietf.org
From: Martin Bjorklund 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [Netconf] restconf confusing text
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Aug 2016 07:56:31 -0000

Hi,

I got a comment from a guy implementing RESTCONF regarding this text
in section 4.3 GET:


   If a retrieval request for a data resource representing a YANG leaf-
   list or list object identifies more than one instance, and XML
   encoding is used in the response, then an error response containing a
   "400 Bad Request" status-line MUST be returned by the server.

First of all, what exactly is such a retrieval request?

Second, it seems to say that we can never add something like
collections, since this spec require us to return a 400 in this case.


I suggest that this paragraph is removed.


/martin


From nobody Fri Aug 26 06:43:31 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F47412D8CA; Fri, 26 Aug 2016 06:43:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.946
X-Spam-Level: 
X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bi8LEk5_8odd; Fri, 26 Aug 2016 06:43:19 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [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 F205112D92A; Fri, 26 Aug 2016 06:31:20 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.166; 
From: "Susan Hares" 
To: "'Netconf'" , , "'TEAS WG'" , 
Date: Fri, 26 Aug 2016 09:30:11 -0400
Message-ID: <088101d1ff9d$f8fddc70$eaf99550$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0882_01D1FF7C.71EDC310"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdH/nc6dK6XhOH24RUiLR0Uhb4KVrg==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com 
Archived-At: 
Subject: [Netconf] Feedback on WG Last call on the draft-ietf-i2rs-yang-network-topo-05.txt (8/26 to 9/9)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Aug 2016 13:43:24 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0882_01D1FF7C.71EDC310
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The I2RS WG has begun a WG LC on the Yang data model for network topologies,
and looks for feedback from your working  on this draft.  You may just
respond to this email to provide feedback. 

 

Sue Hares 

 

From: Susan Hares [mailto:shares@ndzh.com] 
Sent: Friday, August 26, 2016 9:28 AM
To: 'i2rs@ietf.org'
Cc: 'draft-ietf-i2rs-yang-network-topo@ietf.org'; 'russ@riw.us'
Subject: WG Last call on the draft-ietf-i2rs-yang-network-topo

 

This begins a 2 week WG LC on draft-ietf-i2rs-yang-network-topo-05.txt (8/26
to 9/9).  

 

The authors should indicate if they know of IPR on this draft by 8/31/2016.
In considering this draft, the WG should consider: 

 

1)      Does the implementations of this draft in ODL open source code base
sufficient experience on the Yang drafts? 

2)      Does anyone know of other implementations of this model? 

3)      Do you believe this Yang model is stable enough to publish and
distribute to yang libraries? 

 

Sue Hares and Russ White 

Co-chairs 

 

 


------=_NextPart_000_0882_01D1FF7C.71EDC310
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


The I2RS WG has begun a WG LC on the Yang data =
model for network topologies, and looks for feedback from your working =
 on this draft.  You may just respond to this email to provide =
feedback. 
 
Sue Hares =

 
From:=
 =
Susan Hares [mailto:shares@ndzh.com] 
Sent: Friday, August 26, =
2016 9:28 AM
To: 'i2rs@ietf.org'
Cc: =
'draft-ietf-i2rs-yang-network-topo@ietf.org'; =
'russ@riw.us'
Subject: WG Last call on the =
draft-ietf-i2rs-yang-network-topo
 
This begins =
a 2 week WG LC on draft-ietf-i2rs-yang-network-topo-05.txt (8/26 to =
9/9).  
 
The authors should indicate if they know of IPR on =
this draft by 8/31/2016.  In considering this draft, the WG should =
consider: 
 
1)      =
Does the implementations of this draft in ODL =
open source code base sufficient experience on the Yang drafts? =

2)      =
Does anyone know of other implementations of =
this model? 
3)      =
Do you believe this Yang model is stable enough =
to publish and distribute to yang libraries? 
 
Sue Hares =
and Russ White 
Co-chairs =

 
 

------=_NextPart_000_0882_01D1FF7C.71EDC310--


From nobody Fri Aug 26 06:55:26 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E533912D7B0; Fri, 26 Aug 2016 06:55:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.957
X-Spam-Level: 
X-Spam-Status: No, score=0.957 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L5=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7J9mAPQ0t6NY; Fri, 26 Aug 2016 06:55:20 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [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 D91AC12D815; Fri, 26 Aug 2016 06:43:07 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.166; 
From: "Susan Hares" 
To: "'Netconf'" , , , "'TEAS WG'" 
References: 
In-Reply-To: 
Date: Fri, 26 Aug 2016 09:41:58 -0400
Message-ID: <088e01d1ff9f$9e34fa10$da9eee30$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_088F_01D1FF7E.1723F650"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHxkphU7njWmJH4A5s+GBIshhds06AcFslg
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com 
Archived-At: 
Subject: [Netconf] FW: WG LC on draft-ietf-i2rs-yang-l3-topology-03.txt (8/26 to 9/9)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Aug 2016 13:55:22 -0000

This is a multipart message in MIME format.

------=_NextPart_000_088F_01D1FF7E.1723F650
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The I2RS WG is starting a WG LC on the L3 network topology model and wishes
input.  

 

Sue Hares and Russ White 

 

From: Susan Hares [mailto:shares@ndzh.com] 
Sent: Friday, August 26, 2016 9:28 AM
To: 'i2rs@ietf.org'
Cc: 'draft-ietf-i2rs-yang-l3-topology@ietf.org'; 'Alia Atlas'; 'russ@riw.us'
Subject: WG LC on draft-ietf-i2rs-yang-l3-topology-03.txt (8/26 to 9/9) 

 

 

This begins a 2 week WG LC on draft-ietf-i2rs-yang-l3-network-topo-05.txt
(8/26 to 9/9).  

 

The authors should indicate if they know of IPR on this draft by 8/31/2016.
In considering this draft, the WG should consider: 

 

1)      Does the implementations of this draft in ODL open source code base
sufficient experience on the Yang drafts? 

2)      Does anyone know of other implementations of this model? 

3)      Do you believe this Yang model is stable enough to publish and
distribute to yang libraries? 

 

Sue Hares and Russ White 

Co-chairs 

 

 


------=_NextPart_000_088F_01D1FF7E.1723F650
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


The I2RS WG is starting a WG LC on the L3 =
network topology model and wishes input.  
 
Sue Hares and Russ White =

 
From:=
 =
Susan Hares [mailto:shares@ndzh.com] 
Sent: Friday, August 26, =
2016 9:28 AM
To: 'i2rs@ietf.org'
Cc: =
'draft-ietf-i2rs-yang-l3-topology@ietf.org'; 'Alia Atlas'; =
'russ@riw.us'
Subject: WG LC on =
draft-ietf-i2rs-yang-l3-topology-03.txt (8/26 to 9/9) =

 
 
This begins =
a 2 week WG LC on draft-ietf-i2rs-yang-l3-network-topo-05.txt (8/26 to =
9/9).  
 
The authors should indicate if they know of IPR on =
this draft by 8/31/2016.  In considering this draft, the WG should =
consider: 
 
1)      =
Does the implementations of this draft in ODL =
open source code base sufficient experience on the Yang drafts? =

2)      =
Does anyone know of other implementations of =
this model? 
3)      =
Do you believe this Yang model is stable enough =
to publish and distribute to yang libraries? 
 
Sue Hares =
and Russ White 
Co-chairs =

 
 

------=_NextPart_000_088F_01D1FF7E.1723F650--


From nobody Fri Aug 26 14:03:25 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD21412D82D for ; Fri, 26 Aug 2016 14:03:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level: 
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ay2-mVCKwfWQ for ; Fri, 26 Aug 2016 14:03:23 -0700 (PDT)
Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (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 6701F12D825 for ; Fri, 26 Aug 2016 14:03:23 -0700 (PDT)
Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-12v.sys.comcast.net with SMTP id dOHBbnAvmxBKTdOHabRKLr; Fri, 26 Aug 2016 21:03:22 +0000
Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-ch2-17v.sys.comcast.net with SMTP id dOHZbI3UlrtSbdOHab3WG5; Fri, 26 Aug 2016 21:03:22 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u7QL3L0l024348; Fri, 26 Aug 2016 17:03:21 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u7QL3KbR024345; Fri, 26 Aug 2016 17:03:20 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com (Dale R. Worley)
To: Martin Bjorklund 
In-Reply-To: <20160826.095528.319078548872509327.mbj@tail-f.com>
Sender: worley@ariadne.com (Dale R. Worley)
Date: Fri, 26 Aug 2016 17:03:20 -0400
Message-ID: <87h9a75jl3.fsf@hobgoblin.ariadne.com>
X-CMAE-Envelope: MS4wfPkZrrE7HDvZpEcqvr1Fq9wev7jibFjo0NyZaz6PJSfQsMl9FskWZSeiLKdhmnwTnIzVkV79H0Xk5TtXu8Q889A1TuLnFIAHRtQnMqax9671aF7G+yeY ifQnf2Qkj5d429ZEQCoqVivAUmzAbBSF1iaBw3/X91fGE2ix5cDUBY4G/sEB+eKosWZZvdHTPPKi4LKtjKnX239IqK7im+8OASo=
Archived-At: 
Cc: netconf@ietf.org
Subject: Re: [Netconf] restconf confusing text
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Aug 2016 21:03:25 -0000

Martin Bjorklund  writes:
> I got a comment from a guy implementing RESTCONF regarding this text
> in section 4.3 GET:
>
>    If a retrieval request for a data resource representing a YANG leaf-
>    list or list object identifies more than one instance, and XML
>    encoding is used in the response, then an error response containing a
>    "400 Bad Request" status-line MUST be returned by the server.
>
> First of all, what exactly is such a retrieval request?

That can happen because the path of the request need not identify a
unique leaf.  Consider a modification of example-jukebox from section C.1 of
draft-ietf-netconf-restconf-15:

      container jukebox {
        presence
          "An empty container indicates that the jukebox
           service is available";

        description
          "Represents a jukebox resource, with a library, playlists,
           and a play operation.";

	// state data
        config false;

        container library {

          description "Represents the jukebox library resource.";

          list artist {
	    // no key

            leaf name {
              type string {
                length "1 .. max";
              }
              description "The name of the artist.";
            }

            ...

You can request

   GET /restconf/data/example-jukebox:jukebox/library/artist/name HTTP/1.1
   Host: example.com
   Accept: application/yang-data

But since jukebox is not state data (i.e., is read-only), then there is
no key for the list "artist", and the URL collectively identifies all
name children of all elements of the list "artist".

If the returned data is to be application/yang-data+json, JSON can
return multiple values.  But if the returned datais to be
application/yang-data, XML cannot return return multiple values.

Dale


From nobody Mon Aug 29 02:19:28 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87FB112D505 for ; Mon, 29 Aug 2016 02:19:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCuvwxyBhV5X for ; Mon, 29 Aug 2016 02:19:24 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A369412D511 for ; Mon, 29 Aug 2016 02:19:24 -0700 (PDT)
Received: from localhost (unknown [173.38.220.42]) by mail.tail-f.com (Postfix) with ESMTPSA id C02021AE018C; Mon, 29 Aug 2016 11:19:23 +0200 (CEST)
Date: Mon, 29 Aug 2016 11:18:27 +0200 (CEST)
Message-Id: <20160829.111827.1667009134223115157.mbj@tail-f.com>
To: worley@ariadne.com
From: Martin Bjorklund 
In-Reply-To: <87h9a75jl3.fsf@hobgoblin.ariadne.com>
References: <20160826.095528.319078548872509327.mbj@tail-f.com> <87h9a75jl3.fsf@hobgoblin.ariadne.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netconf@ietf.org
Subject: Re: [Netconf] restconf confusing text
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Aug 2016 09:19:26 -0000

worley@ariadne.com (Dale R. Worley) wrote:
> Martin Bjorklund  writes:
> > I got a comment from a guy implementing RESTCONF regarding this text
> > in section 4.3 GET:
> >
> >    If a retrieval request for a data resource representing a YANG leaf-
> >    list or list object identifies more than one instance, and XML
> >    encoding is used in the response, then an error response containing a
> >    "400 Bad Request" status-line MUST be returned by the server.
> >
> > First of all, what exactly is such a retrieval request?
> 
> That can happen because the path of the request need not identify a
> unique leaf.  Consider a modification of example-jukebox from section C.1 of
> draft-ietf-netconf-restconf-15:
> 
>       container jukebox {
>         presence
>           "An empty container indicates that the jukebox
>            service is available";
> 
>         description
>           "Represents a jukebox resource, with a library, playlists,
>            and a play operation.";
> 
> 	// state data
>         config false;
> 
>         container library {
> 
>           description "Represents the jukebox library resource.";
> 
>           list artist {
> 	    // no key
> 
>             leaf name {
>               type string {
>                 length "1 .. max";
>               }
>               description "The name of the artist.";
>             }
> 
>             ...
> 
> You can request
> 
>    GET /restconf/data/example-jukebox:jukebox/library/artist/name HTTP/1.1
>    Host: example.com
>    Accept: application/yang-data
> 
> But since jukebox is not state data (i.e., is read-only), then there is
> no key for the list "artist", and the URL collectively identifies all
> name children of all elements of the list "artist".

Note that the original text talks about a request for a "data
resource" representing more than one instance.  But "data resource" is
a well-defined term that refers to a node in the data tree.  data
resource maps one-to-one to data node, so it is not possible for a
data resource to "identify mote than one instance".

> If the returned data is to be application/yang-data+json, JSON can
> return multiple values.  But if the returned datais to be
> application/yang-data, XML cannot return return multiple values.

Sure it can, but it needs to be wrapped in something like a
 element (as was the original idea behinf collections).

And just b/c JSAON can return multiple values, it doesn't mean that
the RESTCONF spec has defined support for such collections for JSON.



/martin


From nobody Mon Aug 29 06:10:00 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660FD12D10F for ; Mon, 29 Aug 2016 06:09:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkF5sVM75GJK for ; Mon, 29 Aug 2016 06:09:57 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0123.outbound.protection.outlook.com [104.47.36.123]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4ED012D5F7 for ; Mon, 29 Aug 2016 06:09:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5o8EBAQd0XeaSoLTpNwJKUfIB4jU3RuPYUAGP3zuBL8=; b=MNBbLpisWZiG0mzHKaAyicvxENZshMmCD16lka2c6o903B249y3uR2uLgNxxvUVogY0tibpNoyIxCOWft3ytmUxmY3yk1gfcXd3ZYxnywBt2hp3+Qhp1XKAjXAyGNeG4vjb+qbFP/j2uv7lhb7eXB5mVbasjDDihyTY4sKeusu0=
Received: from DM2PR0501MB1455.namprd05.prod.outlook.com (10.161.224.152) by DM2PR0501MB1453.namprd05.prod.outlook.com (10.161.224.150) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.609.3; Mon, 29 Aug 2016 13:09:49 +0000
Received: from DM2PR0501MB1455.namprd05.prod.outlook.com ([10.161.224.152]) by DM2PR0501MB1455.namprd05.prod.outlook.com ([10.161.224.152]) with mapi id 15.01.0599.001; Mon, 29 Aug 2016 13:09:49 +0000
From: Kent Watsen 
To: Martin Bjorklund , "netconf@ietf.org" 
Thread-Topic: [Netconf] restconf confusing text
Thread-Index: AQHR/29eYBhuBXGDKEuucMYvQyMjoaBfq1aA
Date: Mon, 29 Aug 2016 13:09:49 +0000
Message-ID: <29EA4D21-A2D5-4C53-8433-C731B46EAA49@juniper.net>
References: <20160826.095528.319078548872509327.mbj@tail-f.com>
In-Reply-To: <20160826.095528.319078548872509327.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.18.0.160709
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [137.118.194.222]
x-ms-office365-filtering-correlation-id: 6f53046a-f76d-40f0-ad7a-08d3d00dc1d9
x-microsoft-exchange-diagnostics: 1; DM2PR0501MB1453; 6:pXuJ9y8OjTDwAFfLE0WNjmSJgkq0s4nuG+gZxyUKr7F+ivLhDrdF1Ct9/95x8cgpdIwX+kmaRXpWYrbPkPc6qd/EKInR/Hy23hBweh6l4cCWnTJLvtnao/ee1zwvB5ycHnTRdgCHTjqDJVeUqZ17D9XLJq4P5rUfaW5Iy8+2q6I02n8wCZ70l/2WskKfJl2BqK9zdZWdiz5xLvgRdaKa4wtoHEE8skJ78ehnSRmi16nd/lFajtFAdVhWVHtZ2MRLXZZGDgP2p46DkilEE/2rPkZ22kwgu9WnB1Roy5FaAg5bLxC+BsY1qFWWgUn9dehCW1fAjolJSA2sTZ2dvI3A2Q==; 5:TZ7v+DhC/CnL0d8vHOhjggyRmVbzTJePZN/OvVPVf6HNyzKX2S02sCaq/1JO0opqQViax2Df0lTFemUsRwl2QYLxg4THJ4LQoszcxK/qrXgfCBbjCwNCVmyjmiDhh9BQ0tajKg7wBK1PgrEoNCsAWg==; 24:eM7u8M7Dp2kVxQN6QtOXT27tj/lRgslAOnFORqfaKU5Kkw/rF7oVLUqD4NTRa5TDNgu+FBA+6RlMqvjyvOgWyRIgZ185cz8WI74HaAcpMs4=; 7:fXH0W6RB62/BlOridaBCnCy0tT+NRTScRbVFgXIJV9K5xqYawYUWj2wWsPwY9o0cwjAfLd7fYvCklfLeCmh2B6q5wDO4aJq8QWUDirsiV8zyACw8hMoeSDR0Fwqybj3l3CkrnO7J/iGGesPl0aU1/HIdNaNwZXEJMlPCZvplBJKjA65XO+Ohaxg5Oy7/EJWeOU1/JrlHdlTsVD6AFLAF3q8UOajlIQUW23j0yOq35eooglTVohkYZbatvjDaFSxR
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1453;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:DM2PR0501MB1453; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB1453; 
x-forefront-prvs: 0049B3F387
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(189002)(377454003)(199003)(82746002)(19580405001)(5002640100001)(99286002)(122556002)(189998001)(3660700001)(3280700002)(107886002)(6116002)(105586002)(106116001)(11100500001)(81156014)(81166006)(8676002)(106356001)(66066001)(586003)(8936002)(102836003)(3846002)(97736004)(4001350100001)(5001770100001)(54356999)(10400500002)(7736002)(7846002)(77096005)(76176999)(36756003)(86362001)(5660300001)(87936001)(101416001)(2501003)(68736007)(83506001)(2906002)(19580395003)(33656002)(92566002)(305945005)(15975445007)(50986999)(83716003)(2950100001)(2900100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1453; H:DM2PR0501MB1455.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <39FD5F687380444683DF87AABF5272D9@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2016 13:09:49.4322 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1453
Archived-At: 
Subject: Re: [Netconf] restconf confusing text
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Aug 2016 13:09:59 -0000

SSBhc3N1bWUgdGhhdCDigJxyZXRyaWV2YWwgcmVxdWVzdOKAnSBzaG91bGQgYmUg4oCcR0VUIHJl
cXVlc3TigJ0uICAgDQoNCknigJltIG5vdCBzdXJlIGlmIGl04oCZcyBva2F5IHRvIGp1c3QgZGVs
ZXRlIHRoZSBwYXJhZ3JhcGguICBJdCBzZWVtcyB0aGF0IHRoZXJlIG5lZWRzIHRvIGJlIHNvbWUg
Z3VpZGFuY2UgdG8gaGFuZGxlIHRoaXMgY2FzZSwgYXMgb3RoZXJ3aXNlIGltcGxlbWVudGF0aW9u
cyB3aWxsIHZhcnkuICAgICANCg0KQXNzdW1pbmcgdGhlIGNvbGxlY3Rpb25zIGRyYWZ0IHdvdWxk
IOKAmHVwZGF0ZeKAmSB0aGlzIGRyYWZ0LCBjb3VsZCBpdCBub3QgcHJvdmlkZSBhbiBhbHRlcm5h
dGUgc29sdXRpb24gZm9yIHdoZW4gYSBjb2xsZWN0aW9ucy1zcGVjaWZpYyBxdWVyeSBwYXJhbWV0
ZXIgaXMgdXNlZCAtIGVmZmVjdGl2ZWx5IG92ZXJyaWRpbmcgdGhpcyBwYXJhZ3JhcGguICBVbmZv
cnR1bmF0ZWx5LCB0aGlzIHdvdWxkIGxlYWQgdG8gYSByZXF1aXJlbWVudCB0aGF0IGEgY29sbGVj
dGlvbnMtc3BlY2lmaWMgcXVlcnkgcGFyYW1ldGVyIGFsd2F5cyBuZWVkcyB0byBiZSBwYXNzZWQs
IGV2ZW4gZm9yIHRoZSB0cml2aWFsIGNhc2Ugd2hlbiBub25lIHdvdWxkIGhhdmUgdG8gYmUgcGFz
c2VkIG90aGVyd2lzZSAoaS5lLiwgZ2l2ZSBtZSBldmVyeXRoaW5nIHdpdGggbm8gc29ydGluZyBv
ciBwYWdpbmcpLg0KDQpQUzogdG8gYmFkIHRoZSBjb2xsZWN0aW9ucyBzdXBwb3J0IGlzbuKAmXQg
aW4gdGhpcyBkcmFmdCAgOykNCg0KS2VudA0KDQoNCk9uIDgvMjYvMTYsIDM6NTUgQU0sICJOZXRj
b25mIG9uIGJlaGFsZiBvZiBNYXJ0aW4gQmpvcmtsdW5kIiA8bmV0Y29uZi1ib3VuY2VzQGlldGYu
b3JnIG9uIGJlaGFsZiBvZiBtYmpAdGFpbC1mLmNvbT4gd3JvdGU6DQoNCiAgICBIaSwNCiAgICAN
CiAgICBJIGdvdCBhIGNvbW1lbnQgZnJvbSBhIGd1eSBpbXBsZW1lbnRpbmcgUkVTVENPTkYgcmVn
YXJkaW5nIHRoaXMgdGV4dA0KICAgIGluIHNlY3Rpb24gNC4zIEdFVDoNCiAgICANCiAgICANCiAg
ICAgICBJZiBhIHJldHJpZXZhbCByZXF1ZXN0IGZvciBhIGRhdGEgcmVzb3VyY2UgcmVwcmVzZW50
aW5nIGEgWUFORyBsZWFmLQ0KICAgICAgIGxpc3Qgb3IgbGlzdCBvYmplY3QgaWRlbnRpZmllcyBt
b3JlIHRoYW4gb25lIGluc3RhbmNlLCBhbmQgWE1MDQogICAgICAgZW5jb2RpbmcgaXMgdXNlZCBp
biB0aGUgcmVzcG9uc2UsIHRoZW4gYW4gZXJyb3IgcmVzcG9uc2UgY29udGFpbmluZyBhDQogICAg
ICAgIjQwMCBCYWQgUmVxdWVzdCIgc3RhdHVzLWxpbmUgTVVTVCBiZSByZXR1cm5lZCBieSB0aGUg
c2VydmVyLg0KICAgIA0KICAgIEZpcnN0IG9mIGFsbCwgd2hhdCBleGFjdGx5IGlzIHN1Y2ggYSBy
ZXRyaWV2YWwgcmVxdWVzdD8NCiAgICANCiAgICBTZWNvbmQsIGl0IHNlZW1zIHRvIHNheSB0aGF0
IHdlIGNhbiBuZXZlciBhZGQgc29tZXRoaW5nIGxpa2UNCiAgICBjb2xsZWN0aW9ucywgc2luY2Ug
dGhpcyBzcGVjIHJlcXVpcmUgdXMgdG8gcmV0dXJuIGEgNDAwIGluIHRoaXMgY2FzZS4NCiAgICAN
CiAgICANCiAgICBJIHN1Z2dlc3QgdGhhdCB0aGlzIHBhcmFncmFwaCBpcyByZW1vdmVkLg0KICAg
IA0KICAgIA0KICAgIC9tYXJ0aW4NCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KICAgIE5ldGNvbmYgbWFpbGluZyBsaXN0DQogICAgTmV0
Y29uZkBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
bmV0Y29uZg0KICAgIA0KDQo=


From nobody Mon Aug 29 06:19:46 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2370F12D5FD for ; Mon, 29 Aug 2016 06:19:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2567Z1J3Oxc for ; Mon, 29 Aug 2016 06:19:41 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5A03112D112 for ; Mon, 29 Aug 2016 06:19:41 -0700 (PDT)
Received: from localhost (unknown [173.38.220.42]) by mail.tail-f.com (Postfix) with ESMTPSA id 3AC4D1AE018C; Mon, 29 Aug 2016 15:19:40 +0200 (CEST)
Date: Mon, 29 Aug 2016 15:18:43 +0200 (CEST)
Message-Id: <20160829.151843.1201990968547518910.mbj@tail-f.com>
To: kwatsen@juniper.net
From: Martin Bjorklund 
In-Reply-To: <29EA4D21-A2D5-4C53-8433-C731B46EAA49@juniper.net>
References: <20160826.095528.319078548872509327.mbj@tail-f.com> <29EA4D21-A2D5-4C53-8433-C731B46EAA49@juniper.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Cc: netconf@ietf.org
Subject: Re: [Netconf] restconf confusing text
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Aug 2016 13:19:45 -0000

S2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+IHdyb3RlOg0KPiBJIGFzc3VtZSB0aGF0
IOKAnHJldHJpZXZhbCByZXF1ZXN04oCdIHNob3VsZCBiZSDigJxHRVQgcmVxdWVzdOKAnS4gICAN
Cj4gDQo+IEnigJltIG5vdCBzdXJlIGlmIGl04oCZcyBva2F5IHRvIGp1c3QgZGVsZXRlIHRoZSBw
YXJhZ3JhcGguICBJdCBzZWVtcyB0aGF0DQo+IHRoZXJlIG5lZWRzIHRvIGJlIHNvbWUgZ3VpZGFu
Y2UgdG8gaGFuZGxlIHRoaXMgY2FzZSwgYXMgb3RoZXJ3aXNlDQo+IGltcGxlbWVudGF0aW9ucyB3
aWxsIHZhcnkuDQoNCkNhbiB5b3Ugc2hvdyBtZSBhbiBleGFtcGxlIG9mICJ0aGlzIGNhc2UiPyAg
U2VlIGFsc28gbXkgcmVwbHkgdG8gRGFsZQ0KVy4gdG9kYXkuDQoNCg0KL21hcnRpbg0KDQoNCg0K
PiANCj4gQXNzdW1pbmcgdGhlIGNvbGxlY3Rpb25zIGRyYWZ0IHdvdWxkIOKAmHVwZGF0ZeKAmSB0
aGlzIGRyYWZ0LCBjb3VsZCBpdCBub3QNCj4gcHJvdmlkZSBhbiBhbHRlcm5hdGUgc29sdXRpb24g
Zm9yIHdoZW4gYSBjb2xsZWN0aW9ucy1zcGVjaWZpYyBxdWVyeQ0KPiBwYXJhbWV0ZXIgaXMgdXNl
ZCAtIGVmZmVjdGl2ZWx5IG92ZXJyaWRpbmcgdGhpcyBwYXJhZ3JhcGguDQo+IFVuZm9ydHVuYXRl
bHksIHRoaXMgd291bGQgbGVhZCB0byBhIHJlcXVpcmVtZW50IHRoYXQgYQ0KPiBjb2xsZWN0aW9u
cy1zcGVjaWZpYyBxdWVyeSBwYXJhbWV0ZXIgYWx3YXlzIG5lZWRzIHRvIGJlIHBhc3NlZCwgZXZl
bg0KPiBmb3IgdGhlIHRyaXZpYWwgY2FzZSB3aGVuIG5vbmUgd291bGQgaGF2ZSB0byBiZSBwYXNz
ZWQgb3RoZXJ3aXNlDQo+IChpLmUuLCBnaXZlIG1lIGV2ZXJ5dGhpbmcgd2l0aCBubyBzb3J0aW5n
IG9yIHBhZ2luZykuDQo+IA0KPiBQUzogdG8gYmFkIHRoZSBjb2xsZWN0aW9ucyBzdXBwb3J0IGlz
buKAmXQgaW4gdGhpcyBkcmFmdCAgOykNCj4gDQo+IEtlbnQNCj4gDQo+IA0KPiBPbiA4LzI2LzE2
LCAzOjU1IEFNLCAiTmV0Y29uZiBvbiBiZWhhbGYgb2YgTWFydGluIEJqb3JrbHVuZCINCj4gPG5l
dGNvbmYtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgbWJqQHRhaWwtZi5jb20+IHdyb3Rl
Og0KPiANCj4gICAgIEhpLA0KPiAgICAgDQo+ICAgICBJIGdvdCBhIGNvbW1lbnQgZnJvbSBhIGd1
eSBpbXBsZW1lbnRpbmcgUkVTVENPTkYgcmVnYXJkaW5nIHRoaXMgdGV4dA0KPiAgICAgaW4gc2Vj
dGlvbiA0LjMgR0VUOg0KPiAgICAgDQo+ICAgICANCj4gICAgICAgIElmIGEgcmV0cmlldmFsIHJl
cXVlc3QgZm9yIGEgZGF0YSByZXNvdXJjZSByZXByZXNlbnRpbmcgYSBZQU5HIGxlYWYtDQo+ICAg
ICAgICBsaXN0IG9yIGxpc3Qgb2JqZWN0IGlkZW50aWZpZXMgbW9yZSB0aGFuIG9uZSBpbnN0YW5j
ZSwgYW5kIFhNTA0KPiAgICAgICAgZW5jb2RpbmcgaXMgdXNlZCBpbiB0aGUgcmVzcG9uc2UsIHRo
ZW4gYW4gZXJyb3IgcmVzcG9uc2UgY29udGFpbmluZyBhDQo+ICAgICAgICAiNDAwIEJhZCBSZXF1
ZXN0IiBzdGF0dXMtbGluZSBNVVNUIGJlIHJldHVybmVkIGJ5IHRoZSBzZXJ2ZXIuDQo+ICAgICAN
Cj4gICAgIEZpcnN0IG9mIGFsbCwgd2hhdCBleGFjdGx5IGlzIHN1Y2ggYSByZXRyaWV2YWwgcmVx
dWVzdD8NCj4gICAgIA0KPiAgICAgU2Vjb25kLCBpdCBzZWVtcyB0byBzYXkgdGhhdCB3ZSBjYW4g
bmV2ZXIgYWRkIHNvbWV0aGluZyBsaWtlDQo+ICAgICBjb2xsZWN0aW9ucywgc2luY2UgdGhpcyBz
cGVjIHJlcXVpcmUgdXMgdG8gcmV0dXJuIGEgNDAwIGluIHRoaXMgY2FzZS4NCj4gICAgIA0KPiAg
ICAgDQo+ICAgICBJIHN1Z2dlc3QgdGhhdCB0aGlzIHBhcmFncmFwaCBpcyByZW1vdmVkLg0KPiAg
ICAgDQo+ICAgICANCj4gICAgIC9tYXJ0aW4NCj4gICAgIA0KPiAgICAgX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gICAgIE5ldGNvbmYgbWFpbGluZyBs
aXN0DQo+ICAgICBOZXRjb25mQGlldGYub3JnDQo+ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4gICAgIA0KPiANCg==


From nobody Mon Aug 29 07:09:23 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0108612D75C for ; Mon, 29 Aug 2016 07:09:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level: 
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvQI1WMJXwSj for ; Mon, 29 Aug 2016 07:09:21 -0700 (PDT)
Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (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 6768712D75F for ; Mon, 29 Aug 2016 07:09:19 -0700 (PDT)
Received: from resomta-po-20v.sys.comcast.net ([96.114.154.244]) by resqmta-po-06v.sys.comcast.net with SMTP id eNFWbzD9TjWBpeNFWbFo1E; Mon, 29 Aug 2016 14:09:18 +0000
Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-po-20v.sys.comcast.net with SMTP id eNFVb6u10dYyLeNFWbrKoA; Mon, 29 Aug 2016 14:09:18 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u7TE9Goc030195; Mon, 29 Aug 2016 10:09:16 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u7TE9G7G030192; Mon, 29 Aug 2016 10:09:16 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com (Dale R. Worley)
To: Martin Bjorklund 
In-Reply-To: <20160829.111827.1667009134223115157.mbj@tail-f.com>
Sender: worley@ariadne.com (Dale R. Worley)
Date: Mon, 29 Aug 2016 10:09:16 -0400
Message-ID: <87wpiz3bw3.fsf@hobgoblin.ariadne.com>
X-CMAE-Envelope: MS4wfAcU2m5LsP3spxjJUnow8isbhfK5jR8E6GQ/RDMVUwTSQ+APhc+fXjygKzQqKTxD3xPS8HEOx22yeNctcxeisAU0MiQxrhtD7KPaU+ZK/PF2wtwFb4Qy SBcC51X6EAX0tpGbdlMYgK2znFVmBIzJhfqMNq/sidr9c4rTMRpsnJbv/JSb4uKdtN5q6E6Sfb1VHDhzryhatlKkN/+E54K3Ovs=
Archived-At: 
Cc: netconf@ietf.org
Subject: Re: [Netconf] restconf confusing text
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Aug 2016 14:09:22 -0000

Martin Bjorklund  writes:
> Note that the original text talks about a request for a "data
> resource" representing more than one instance.  But "data resource" is
> a well-defined term that refers to a node in the data tree.  data
> resource maps one-to-one to data node, so it is not possible for a
> data resource to "identify mote than one instance".

Well, I take "resource" to be "the thing identified by a URL", and so
"resource" maps one-to-one to URL, and some URLs identify multiple data
nodes.  I mean, the "R" in "URL" stands for "resource".  I'm not privy
to the full history behind this document, but the text of the document
seems to be consistent with my interpretation, along with all of the
HTTP documentation.

>> If the returned data is to be application/yang-data+json, JSON can
>> return multiple values.  But if the returned datais to be
>> application/yang-data, XML cannot return return multiple values.
>
> Sure it can, but it needs to be wrapped in something like a
>  element (as was the original idea behinf collections).

Yeah, but this document didn't define that.  I can see some advantage if
it had.  But it seems that the authors decided not to do that, which
leads to the oddly asymmetric restriction that you can do a GET of a
multiple-instance URL if the response is allowed to be in JSON but not
if the response is in XML.

Since multiple-resource URLs can only identify state data, which is
read-only, trying to do a POST, DELETE, or PATCH against one fails for
that reason, which is why only GET needs this special consideration.

> And just b/c JSAON can return multiple values, it doesn't mean that
> the RESTCONF spec has defined support for such collections for JSON.

I've been assuming that that support is implicit in JSON, and I know
little about JSON.  But if it's *not* a conventional part of JSON, that
needs to be spelled out in the document.

Dale


From nobody Mon Aug 29 07:13:28 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF0F12D763 for ; Mon, 29 Aug 2016 07:13:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPVcdscsx-Xj for ; Mon, 29 Aug 2016 07:13:26 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0129.outbound.protection.outlook.com [104.47.42.129]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 125E5126579 for ; Mon, 29 Aug 2016 07:13:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9F/7zr+ryF4EgmJ3WuSa4nWHkuYJXhkU65KQcl7/oOY=; b=XvQpEiWONK1+vGyf2RMXWBCt7r4J+TqKemoWHMoh8V9G7iI0k3jTPIYExFDHI2l+fyvBhxKqyb42UK4NWzmU0w0Lq4jqS2l/tBW6N/GdXIst7goSARfsyjpjfkF0TiJdS5hm5oJyfXSUMiu/RZpznv6M0fov8IaKvGJI/v1gg6M=
Received: from DM2PR0501MB1455.namprd05.prod.outlook.com (10.161.224.152) by DM2PR0501MB1454.namprd05.prod.outlook.com (10.161.224.151) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.609.3; Mon, 29 Aug 2016 14:13:23 +0000
Received: from DM2PR0501MB1455.namprd05.prod.outlook.com ([10.161.224.152]) by DM2PR0501MB1455.namprd05.prod.outlook.com ([10.161.224.152]) with mapi id 15.01.0599.001; Mon, 29 Aug 2016 14:13:23 +0000
From: Kent Watsen 
To: Martin Bjorklund 
Thread-Topic: [Netconf] restconf confusing text
Thread-Index: AQHR/29eYBhuBXGDKEuucMYvQyMjoaBfq1aAgABFhoD//8w8gA==
Date: Mon, 29 Aug 2016 14:13:23 +0000
Message-ID: <1342C4E4-B0EB-4038-8FF4-AAA3A017B504@juniper.net>
References: <20160826.095528.319078548872509327.mbj@tail-f.com> <29EA4D21-A2D5-4C53-8433-C731B46EAA49@juniper.net> <20160829.151843.1201990968547518910.mbj@tail-f.com>
In-Reply-To: <20160829.151843.1201990968547518910.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.18.0.160709
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [137.118.194.222]
x-ms-office365-filtering-correlation-id: 7dff46c4-3f26-4412-4086-08d3d016a366
x-microsoft-exchange-diagnostics: 1; DM2PR0501MB1454; 6:hxSsUSJqY65lU69nYOvTpY6imrjAgFf/lRLLC1z8xp1TVzlXZCVCKxN5lY8gDIbLmle4KVEI1G5xVeKgNUDZBOqAwmRH4Z/bnvYWxDeJnHta/BOV9QFdq53UbUVHzITWPVXPhxbzgSY7+IshG5cK51CoHSWgamTZdf7P6R1gUhrWfcQr7DZDMkHcynl7hRG/zgi67Sp7zWYJO+TAGtN5TfrzM9loqyToX5XlSRojuZpjHscShUuB1OqSqajI09AkLuxsAilT3s63hZotOfAZJZbc0iQbrtM3B4fqIcskFjHo7rqukMHCfn1+jmWITDolkkYQ4Ii755sFi2TlPxVu2A==; 5:2N0surAq3edPDV502lGqOF+kfBwPwkV4s59gTbol0PeLR9LgvlykEAPZRjmgst3suHWxEwcALzDt0dsNi5uvwLb4fVDFZyp3xFPhOC+aEWRHIgMOetpgsK+SGdGey+hUXHYXCc8+jezdEH8XJya5iA==; 24:TXkLVQRPoJxS+WNLuC7DdR6k+IYDJzugFhSa9kDfHJyEUrQ2zwHPXOTKaolqeMQCoPEXP2MClCSmoBFfwAEbX7EKP6AG4czNbxSMb3uaurE=; 7:10HpYYCozRcPVgwqjllCSK9Glyetp3VVThwwOMt1t3A34pkz0gFH7ZbgA+apUntNDgpkYdu78C+91wcWgp2e2LlGrHeQJhpkE7LQMasKuFfle1C9P94vASXKrDxwSgGyQemKTGJXGJaYxu7eHSqKaatXyAvbx54ecFipWfUbYjBZQKO6ApkzhZZOEhDAiQZkJOm0hRjFRpqqqIXm+8l4ERbkPbw0dXZkqJej2DH9s/3y4ZFrrApRL1i4VeKh4UUv
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1454;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:DM2PR0501MB1454; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB1454; 
x-forefront-prvs: 0049B3F387
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(189002)(199003)(377454003)(2906002)(4326007)(50986999)(305945005)(36756003)(66066001)(99286002)(33656002)(106116001)(105586002)(3846002)(6116002)(102836003)(3280700002)(586003)(8676002)(122556002)(7736002)(81156014)(3660700001)(7846002)(81166006)(5002640100001)(54356999)(76176999)(19580405001)(19580395003)(10400500002)(82746002)(83506001)(8936002)(68736007)(5660300001)(11100500001)(2900100001)(83716003)(2950100001)(87936001)(77096005)(97736004)(4001350100001)(86362001)(110136002)(101416001)(106356001)(189998001)(92566002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1454; H:DM2PR0501MB1455.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <82635FFF40908A46B5914440BB3E9EFA@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2016 14:13:23.7015 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1454
Archived-At: 
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] restconf confusing text
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Aug 2016 14:13:27 -0000

DQoNCk9uIDgvMjkvMTYsIDk6MTggQU0sICJNYXJ0aW4gQmpvcmtsdW5kIiA8bWJqQHRhaWwtZi5j
b20+IHdyb3RlOg0KDQogICAgS2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+IHdyb3Rl
Og0KICAgID4gSSBhc3N1bWUgdGhhdCDigJxyZXRyaWV2YWwgcmVxdWVzdOKAnSBzaG91bGQgYmUg
4oCcR0VUIHJlcXVlc3TigJ0uICAgDQogICAgPiANCiAgICA+IEnigJltIG5vdCBzdXJlIGlmIGl0
4oCZcyBva2F5IHRvIGp1c3QgZGVsZXRlIHRoZSBwYXJhZ3JhcGguICBJdCBzZWVtcyB0aGF0DQog
ICAgPiB0aGVyZSBuZWVkcyB0byBiZSBzb21lIGd1aWRhbmNlIHRvIGhhbmRsZSB0aGlzIGNhc2Us
IGFzIG90aGVyd2lzZQ0KICAgID4gaW1wbGVtZW50YXRpb25zIHdpbGwgdmFyeS4NCiAgICANCiAg
ICBDYW4geW91IHNob3cgbWUgYW4gZXhhbXBsZSBvZiAidGhpcyBjYXNlIj8gIFNlZSBhbHNvIG15
IHJlcGx5IHRvIERhbGUNCiAgICBXLiB0b2RheS4NCiAgICANCiAgICANClNhbWUgYXMgRGFsZeKA
mXMgZXhhbXBsZS4gICBBcmUgeW91IHRyeWluZyB0byBtYWtlIHRoZSBwb2ludCB0aGF0IGl0IGlz
IG5vdCB0ZWNobmljYWxseSBhIOKAnHJlc291cmNl4oCdIGFuZCB0aGVyZWZvcmUgbm90IGEgcHJv
cGVyIEdFVCB0YXJnZXQsIGFuZCB0aHVzIHRoZSBkb2N1bWVudCBkb2VzbuKAmXQgbmVlZCB0byBz
YXkgYW55dGhpbmcgYWJvdXQgaXQ/DQoNCksuDQoNCg0KDQo=


From nobody Mon Aug 29 07:39:10 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 718A012D785 for ; Mon, 29 Aug 2016 07:39:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPuZq3lg97vH for ; Mon, 29 Aug 2016 07:39:02 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0633312D78A for ; Mon, 29 Aug 2016 07:39:00 -0700 (PDT)
Received: from localhost (unknown [173.38.220.42]) by mail.tail-f.com (Postfix) with ESMTPSA id 97E5B1AE018C; Mon, 29 Aug 2016 16:38:57 +0200 (CEST)
Date: Mon, 29 Aug 2016 16:38:01 +0200 (CEST)
Message-Id: <20160829.163801.2294516285410948326.mbj@tail-f.com>
To: worley@ariadne.com
From: Martin Bjorklund 
In-Reply-To: <87wpiz3bw3.fsf@hobgoblin.ariadne.com>
References: <20160829.111827.1667009134223115157.mbj@tail-f.com> <87wpiz3bw3.fsf@hobgoblin.ariadne.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netconf@ietf.org
Subject: Re: [Netconf] restconf confusing text
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Aug 2016 14:39:08 -0000

worley@ariadne.com (Dale R. Worley) wrote:
> Martin Bjorklund  writes:
> > Note that the original text talks about a request for a "data
> > resource" representing more than one instance.  But "data resource" is
> > a well-defined term that refers to a node in the data tree.  data
> > resource maps one-to-one to data node, so it is not possible for a
> > data resource to "identify mote than one instance".
> 
> Well, I take "resource" to be "the thing identified by a URL", and so
> "resource" maps one-to-one to URL, and some URLs identify multiple data
> nodes.  I mean, the "R" in "URL" stands for "resource".  I'm not privy
> to the full history behind this document, but the text of the document
> seems to be consistent with my interpretation, along with all of the
> HTTP documentation.
> 
> >> If the returned data is to be application/yang-data+json, JSON can
> >> return multiple values.  But if the returned datais to be
> >> application/yang-data, XML cannot return return multiple values.
> >
> > Sure it can, but it needs to be wrapped in something like a
> >  element (as was the original idea behinf collections).
> 
> Yeah, but this document didn't define that.  I can see some advantage if
> it had.  But it seems that the authors decided not to do that, which
> leads to the oddly asymmetric restriction that you can do a GET of a
> multiple-instance URL if the response is allowed to be in JSON but not
> if the response is in XML.

I don't think that this document specifies how the reply to a
"multi-instance URL" would work for JSON.  For example, what would the
reply be for /interfaces-state/interface/ipv4/address, assuming there are
multiple addresses defined on multiple interfaces?

> Since multiple-resource URLs can only identify state data

What text in the document says this?



/martin



> , which is
> read-only, trying to do a POST, DELETE, or PATCH against one fails for
> that reason, which is why only GET needs this special consideration.
> 
> > And just b/c JSAON can return multiple values, it doesn't mean that
> > the RESTCONF spec has defined support for such collections for JSON.
> 
> I've been assuming that that support is implicit in JSON, and I know
> little about JSON.  But if it's *not* a conventional part of JSON, that
> needs to be spelled out in the document.
> 
> Dale
> 


From nobody Mon Aug 29 07:40:02 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726B912D782 for ; Mon, 29 Aug 2016 07:40:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhx9lX2Mp_Mv for ; Mon, 29 Aug 2016 07:40:00 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E41A112D787 for ; Mon, 29 Aug 2016 07:39:59 -0700 (PDT)
Received: from localhost (unknown [173.38.220.42]) by mail.tail-f.com (Postfix) with ESMTPSA id 154141AE018C; Mon, 29 Aug 2016 16:39:59 +0200 (CEST)
Date: Mon, 29 Aug 2016 16:39:02 +0200 (CEST)
Message-Id: <20160829.163902.249281557887179222.mbj@tail-f.com>
To: kwatsen@juniper.net
From: Martin Bjorklund 
In-Reply-To: <1342C4E4-B0EB-4038-8FF4-AAA3A017B504@juniper.net>
References: <29EA4D21-A2D5-4C53-8433-C731B46EAA49@juniper.net> <20160829.151843.1201990968547518910.mbj@tail-f.com> <1342C4E4-B0EB-4038-8FF4-AAA3A017B504@juniper.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Cc: netconf@ietf.org
Subject: Re: [Netconf] restconf confusing text
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Aug 2016 14:40:02 -0000

S2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+IHdyb3RlOg0KPiANCj4gDQo+IE9uIDgv
MjkvMTYsIDk6MTggQU0sICJNYXJ0aW4gQmpvcmtsdW5kIiA8bWJqQHRhaWwtZi5jb20+IHdyb3Rl
Og0KPiANCj4gICAgIEtlbnQgV2F0c2VuIDxrd2F0c2VuQGp1bmlwZXIubmV0PiB3cm90ZToNCj4g
ICAgID4gSSBhc3N1bWUgdGhhdCDigJxyZXRyaWV2YWwgcmVxdWVzdOKAnSBzaG91bGQgYmUg4oCc
R0VUIHJlcXVlc3TigJ0uICAgDQo+ICAgICA+IA0KPiAgICAgPiBJ4oCZbSBub3Qgc3VyZSBpZiBp
dOKAmXMgb2theSB0byBqdXN0IGRlbGV0ZSB0aGUgcGFyYWdyYXBoLiAgSXQgc2VlbXMgdGhhdA0K
PiAgICAgPiB0aGVyZSBuZWVkcyB0byBiZSBzb21lIGd1aWRhbmNlIHRvIGhhbmRsZSB0aGlzIGNh
c2UsIGFzIG90aGVyd2lzZQ0KPiAgICAgPiBpbXBsZW1lbnRhdGlvbnMgd2lsbCB2YXJ5Lg0KPiAg
ICAgDQo+ICAgICBDYW4geW91IHNob3cgbWUgYW4gZXhhbXBsZSBvZiAidGhpcyBjYXNlIj8gIFNl
ZSBhbHNvIG15IHJlcGx5IHRvIERhbGUNCj4gICAgIFcuIHRvZGF5Lg0KPiAgICAgDQo+ICAgICAN
Cj4gU2FtZSBhcyBEYWxl4oCZcyBleGFtcGxlLiAgQXJlIHlvdSB0cnlpbmcgdG8gbWFrZSB0aGUg
cG9pbnQgdGhhdCBpdCBpcw0KPiBub3QgdGVjaG5pY2FsbHkgYSDigJxyZXNvdXJjZeKAnSBhbmQg
dGhlcmVmb3JlIG5vdCBhIHByb3BlciBHRVQgdGFyZ2V0LA0KPiBhbmQgdGh1cyB0aGUgZG9jdW1l
bnQgZG9lc27igJl0IG5lZWQgdG8gc2F5IGFueXRoaW5nIGFib3V0IGl0Pw0KDQpJdCdzIG5vdCB0
ZWNobmljYWxseSBhICJkYXRhIHJlc291cmNlIiwgYW5kIHRodXMgdGhpcyBkb2N1bWVudCBkb2Vz
bid0DQpoYXZlIHRvIHNheSBhbnl0aGluZyBhYm91dCBpdC4NCg0KDQovbWFydGluDQo=


From nobody Mon Aug 29 08:10:10 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC2412D77F for ; Mon, 29 Aug 2016 08:10:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level: 
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdtJE0EvAgqR for ; Mon, 29 Aug 2016 08:10:07 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0108.outbound.protection.outlook.com [104.47.34.108]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E92A12D787 for ; Mon, 29 Aug 2016 08:10:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5MpyAs+V25EUv7VX616WuIO9QVbh5/k+NOxUudwhD1U=; b=jf5PCIlqsZjuM3pANVkGoVtd6sz2zXT+wwMWPRL1dPDmavpRTVRfi4X8pqi9sbh63Ct3Va9pcOnyXes+eldNOA514StEEzvGCfguge1bHT0nSGTZdP34a6cd6AQiTDp0So2rJDzjreACJOZdXVM+ToSTKd+CXe7ovWprcaU82VY=
Received: from DM2PR0501MB1455.namprd05.prod.outlook.com (10.161.224.152) by DM2PR0501MB1455.namprd05.prod.outlook.com (10.161.224.152) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.2; Mon, 29 Aug 2016 15:10:05 +0000
Received: from DM2PR0501MB1455.namprd05.prod.outlook.com ([10.161.224.152]) by DM2PR0501MB1455.namprd05.prod.outlook.com ([10.161.224.152]) with mapi id 15.01.0599.001; Mon, 29 Aug 2016 15:10:05 +0000
From: Kent Watsen 
To: Martin Bjorklund 
Thread-Topic: [Netconf] restconf confusing text
Thread-Index: AQHR/29eYBhuBXGDKEuucMYvQyMjoaBfq1aAgABFhoD//8w8gIAASjQA///FpIA=
Date: Mon, 29 Aug 2016 15:10:05 +0000
Message-ID: <71E4B73E-891B-41FD-8F0A-0A9FB510AF00@juniper.net>
References: <29EA4D21-A2D5-4C53-8433-C731B46EAA49@juniper.net> <20160829.151843.1201990968547518910.mbj@tail-f.com> <1342C4E4-B0EB-4038-8FF4-AAA3A017B504@juniper.net> <20160829.163902.249281557887179222.mbj@tail-f.com>
In-Reply-To: <20160829.163902.249281557887179222.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.18.0.160709
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [137.118.194.222]
x-ms-office365-filtering-correlation-id: 5139808c-77b4-4647-142c-08d3d01e8f14
x-microsoft-exchange-diagnostics: 1; DM2PR0501MB1455; 6:3clZqtUltxfSv8mKp/NedJlA7suFyqN9ARpc6irQPzWYmlPaJJd7tnAy2qAtRn5QqF5+yY4F0UHs8wLeeUy7lebVfbhp/t2fzMN1qM40Vlwt79mSQj8DEc+T7aadXvdofauwbd8xX7WK7agxfwLgmQ8Mw+3tqP4pvY38zjVUJ+GoASMksYeO8UTqI/ThOAr4cP92hVwL6cZ/wFSea4NZdxrUHrncfI53e48tnhv28oSZ86xwpkQoX2/Qff30ZgcVjbWGnOiVjYRmJZTjX/TufLp1a0o/yF5whYQN0rqMS469DAq20Leu6YkbmOdAkEnzfGHSYEih2ovoYbFDvbqcbQ==; 5:6O29xAQgQXWd6o2bjQjpr0tc2D2IhQVAz4GXfvdt3GNWru+GqAZQJkKN2y/PISQH7VEZM0GeeyFE3jRN1gE636E1ypKNaNDWcCJMe0mCioIhiwsnmGb2CAgpRBbeyoJxAlSYzmJiyRz/91IfqFvzsQ==; 24:Bu3/mV+Yjh5wHduMc/K5oSnFPAkodk0xZKe7ci6u9xTmZnXQu9q5X3AyS1pn5me6q/6a97lompsSAJ/uZezVfkV8niyVtvpLwgTMm3j+X2M=; 7:2y8Q6ohKzNpvtLDu9d1EpK0PLpcW1bIoz7OEwh46x0YPmtChcIIAXManufx5ZshbKJzJ4Nxk9K+zb3lsjrq0ZatAwWLZmrNeacnvNaQqk8B4ZlaH0bymsk21dlW3kPao9GUWI71+A7igVg1cC8gm5WZ+1rYa0G6qEjApmniyOG+vuH9UO8SZiNll94IDPl0Y8cs5jkIW/qVcPT81g9ZqWd5+NOeR09y12fX0I4XpQfJaC4Lhui12dONJlfcqjvmZ
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1455;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:DM2PR0501MB1455; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB1455; 
x-forefront-prvs: 0049B3F387
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(189002)(199003)(24454002)(586003)(106116001)(110136002)(4001350100001)(83506001)(77096005)(86362001)(101416001)(92566002)(97736004)(50986999)(54356999)(76176999)(5002640100001)(10400500002)(189998001)(81156014)(66066001)(106356001)(2950100001)(105586002)(2900100001)(99286002)(5660300001)(7846002)(93886004)(87936001)(33656002)(4326007)(305945005)(83716003)(11100500001)(122556002)(36756003)(68736007)(102836003)(2906002)(7736002)(19580405001)(8936002)(8676002)(3660700001)(81166006)(3846002)(3280700002)(82746002)(6116002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1455; H:DM2PR0501MB1455.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2016 15:10:05.6235 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1455
Archived-At: 
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] restconf confusing text
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Aug 2016 15:10:09 -0000

DQoNCg0KT24gOC8yOS8xNiwgMTA6MzkgQU0sICJNYXJ0aW4gQmpvcmtsdW5kIiA8bWJqQHRhaWwt
Zi5jb20+IHdyb3RlOg0KDQogICAgSXQncyBub3QgdGVjaG5pY2FsbHkgYSAiZGF0YSByZXNvdXJj
ZSIsIGFuZCB0aHVzIHRoaXMgZG9jdW1lbnQgZG9lc24ndA0KICAgIGhhdmUgdG8gc2F5IGFueXRo
aW5nIGFib3V0IGl0Lg0KICAgICAgICANCiAgICAvbWFydGluDQogICAgDQoNCkluIHRoYXQgY2Fz
ZSwgSSBhZ3JlZSB3aXRoIHlvdXIgYXNzZXNzbWVudCwgYnV0IGZlZWwgdGhhdCB0aGlzIGRvY3Vt
ZW50IHNob3VsZCBzdGlsbCBzYXkgc29tZXRoaW5nIGFib3V0LiAgU3BlY2lmaWNhbGx5LCBJIHRo
aW5rIGl0IHNob3VsZCBzYXkgc29tZXRoaW5nIGFsb25nIHRoZSBsaW5lcyBvZiB3aGF0IHlvdSBq
dXN0IHdyb3RlIGFib3ZlLg0KDQpLZW50DQoNCg0KDQo=


From nobody Mon Aug 29 09:36:50 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F40512D0E4 for ; Mon, 29 Aug 2016 09:36:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level: 
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6czCo3rorbo for ; Mon, 29 Aug 2016 09:36:47 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BA3C12D1AF for ; Mon, 29 Aug 2016 09:36:47 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7B0A5EF1; Mon, 29 Aug 2016 18:36:45 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 6LnKRWf1WQm1; Mon, 29 Aug 2016 18:36:42 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 29 Aug 2016 18:36:44 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B0DD9200A5; Mon, 29 Aug 2016 18:36:44 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id fB5-jIt8Hwhl; Mon, 29 Aug 2016 18:36:44 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 012AC200A6; Mon, 29 Aug 2016 18:36:44 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id B758C3C52519; Mon, 29 Aug 2016 18:36:42 +0200 (CEST)
Date: Mon, 29 Aug 2016 18:36:42 +0200
From: Juergen Schoenwaelder 
To: Kent Watsen 
Message-ID: <20160829163642.GA671@elstar.local>
Mail-Followup-To: Kent Watsen , Martin Bjorklund , "netconf@ietf.org" 
References: <29EA4D21-A2D5-4C53-8433-C731B46EAA49@juniper.net> <20160829.151843.1201990968547518910.mbj@tail-f.com> <1342C4E4-B0EB-4038-8FF4-AAA3A017B504@juniper.net> <20160829.163902.249281557887179222.mbj@tail-f.com> <71E4B73E-891B-41FD-8F0A-0A9FB510AF00@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <71E4B73E-891B-41FD-8F0A-0A9FB510AF00@juniper.net>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] restconf confusing text
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 Aug 2016 16:36:49 -0000

On Mon, Aug 29, 2016 at 03:10:05PM +0000, Kent Watsen wrote:
> 
> 
> 
> On 8/29/16, 10:39 AM, "Martin Bjorklund"  wrote:
> 
>     It's not technically a "data resource", and thus this document doesn't
>     have to say anything about it.
>         
>     /martin
>     
> 
> In that case, I agree with your assessment, but feel that this document should still say something about.  Specifically, I think it should say something along the lines of what you just wrote above.
>

Stupid question: Is there an HTTP status code that can be returned in
these cases (e.g., 406 Not Acceptable)? A future specification can
then define how to handle these requests.

/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 Aug 30 03:17:13 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD90812D0E8 for ; Tue, 30 Aug 2016 03:17:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.022
X-Spam-Level: 
X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=metaswitch.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yU_7_579mBJt for ; Tue, 30 Aug 2016 03:17:07 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0090.outbound.protection.outlook.com [104.47.42.90]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0AE1126B6D for ; Tue, 30 Aug 2016 03:17:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=K40Cj9naSWiwawut8p/dq7u15mPSqfiCNSarqfYEbIA=; b=AqHBEjIazr/sng3DWsta6Np/pGPgneYy1guIQVr0samoMZ0rkJE6aTxBoH4TgSKWeHYgyfcJ/Y/k+EVAkHpO4sl/49wdam2WLGooPIFvOySNbnlDIOE5UhGV3fSySsv7tcxP0VgNe7gcyvGN1Nlb3JL7vDi/dC+9U9+OwakMGak=
Received: from BY2PR02MB2007.namprd02.prod.outlook.com (10.166.110.7) by BY2PR02MB2005.namprd02.prod.outlook.com (10.166.109.155) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.9; Tue, 30 Aug 2016 10:17:05 +0000
Received: from BY2PR02MB2007.namprd02.prod.outlook.com ([10.166.110.7]) by BY2PR02MB2007.namprd02.prod.outlook.com ([10.166.110.7]) with mapi id 15.01.0557.022; Tue, 30 Aug 2016 10:17:05 +0000
From: Nick Weeds 
To: "netconf@ietf.org" 
Thread-Topic: [Netconf] restconf confusing text
Thread-Index: AQHR/29foyOXQga4s0GKMiF8DTwHRaBf7l+AgAACfYCAAA9GgIAAByoAgAAIrYCAAT73wA==
Date: Tue, 30 Aug 2016 10:17:04 +0000
Message-ID: 
References: <29EA4D21-A2D5-4C53-8433-C731B46EAA49@juniper.net> <20160829.151843.1201990968547518910.mbj@tail-f.com> <1342C4E4-B0EB-4038-8FF4-AAA3A017B504@juniper.net> <20160829.163902.249281557887179222.mbj@tail-f.com> <71E4B73E-891B-41FD-8F0A-0A9FB510AF00@juniper.net>
In-Reply-To: <71E4B73E-891B-41FD-8F0A-0A9FB510AF00@juniper.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=nick.weeds@metaswitch.com; 
x-originating-ip: [2620:104:4000:3064:6c7c:2d0e:85b6:c8a0]
x-ms-office365-filtering-correlation-id: 783e3409-6d00-4278-3c80-08d3d0becac2
x-microsoft-exchange-diagnostics: 1; BY2PR02MB2005; 6:JAQ7sqN7QXLlJUNpY74eD0ZTbMWrRnWT3Nw8k8tT1lIJiOrJuRHpT/RDGCr0dgzd8oUk1WkDvspR/hXe71E20va2mj5pX/uu+HHarnit54cbrCOxBsdxI7eWugDONHT24PExC7jz9pk24lca8/gsIy9ydve0d6VVZKLESPwp2G9SQQ/aa81oNTB6XjpoqxbAhwcREKuDmuCrmZ/VfcS1NjRkpGoUpjVP9GIqqvnqN47G2NPugqz9vQeGBplpXxJ7zMm/dLUNe29KVAeX7kAR7dYMXKYKjIzur4PlFbJe5NA=; 5:N+WxHHCOPH2Ye3fcQNWH+/zDIFXftVB81pQ7vBcS3z85zNtMNQSimXM62IIx+61FAA9TDht4JZl+EeFFJt/L4LOImilrdHV901MrYbLc1zf1LQxMiwH51m0J2zSqIxJ3tlIUik7G1ssPBlAcNGipCw==; 24:EJD2lUhgeIkRk+P3xdbSy5WnhgpjBxGkqAYKMXyLL89TStBqhW1NnmyjaQxDn+Gnikfx1lHyd54EXcpphkJ9BVw9a7BhkphYJBmuD+wWeuw=; 7:da3gPtSlzr1to3gH925tz9Vbz2o5XvKtuvwXHsy+sRplywJ3OTrHu81tQd13CjCPeiANCgiqBV5CaH4ndfaqkgcgWGMvbk+TQYPAlq6O0ytHeYEtohMkw0kQpLuQSulZ33qSpM0HWmS4KIE0zcpWzLdHyZNCkUPvxOHKe3I3LgTpf+5smRRDGWlk+34Sq+PU8nVakWuxhjXhzWlLteoxey0mvZU9474ZaOg9eELMvNKk8uoC253RALZawv5RCE2y
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR02MB2005;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001);  SRVR:BY2PR02MB2005; BCL:0; PCL:0; RULEID:; SRVR:BY2PR02MB2005; 
x-forefront-prvs: 0050CEFE70
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(24454002)(377454003)(199003)(189002)(74316002)(105586002)(2950100001)(8676002)(99286002)(86362001)(68736007)(81166006)(122556002)(11100500001)(8936002)(1730700003)(3280700002)(2351001)(97736004)(5640700001)(19580405001)(19580395003)(189998001)(106116001)(305945005)(93886004)(7696003)(101416001)(107886002)(87936001)(586003)(6116002)(76176999)(5002640100001)(77096005)(106356001)(81156014)(2900100001)(76576001)(102836003)(450100001)(10400500002)(3660700001)(2501003)(7736002)(7846002)(50986999)(110136002)(33656002)(15975445007)(92566002)(5660300001)(9686002)(2906002)(54356999)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR02MB2005; H:BY2PR02MB2007.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: metaswitch.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2016 10:17:05.1591 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR02MB2005
Archived-At: 
Subject: Re: [Netconf] restconf confusing text
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Aug 2016 10:17:10 -0000

In case it helps other readers: I believe it is possible to perform the get=
 the artist name information in Dale's example using:

   GET /restconf/data/example-jukebox:jukebox/library;fields=3Dartist/name =
HTTP/1.1

instead of

   GET /restconf/data/example-jukebox:jukebox/library/artist/name HTTP/1.1

The former satisfies the requirement that the target (/restconf/data/exampl=
e-jukebox:jukebox/library) is a "data resource".
The response would be a single "library" object containing multiple artist =
list entries, and would be valid in both XML and JSON encodings.

	Nick.


-----Original Message-----
From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Kent Watsen
Sent: 29 August 2016 16:10
To: Martin Bjorklund
Cc: netconf@ietf.org
Subject: Re: [Netconf] restconf confusing text




On 8/29/16, 10:39 AM, "Martin Bjorklund"  wrote:

    It's not technically a "data resource", and thus this document doesn't
    have to say anything about it.
       =20
    /martin
   =20

In that case, I agree with your assessment, but feel that this document sho=
uld still say something about.  Specifically, I think it should say somethi=
ng along the lines of what you just wrote above.

Kent



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


From nobody Tue Aug 30 05:45:27 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E340D12D53D for ; Tue, 30 Aug 2016 05:45:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level: 
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZxWSXRflaHv for ; Tue, 30 Aug 2016 05:45:23 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0137.outbound.protection.outlook.com [104.47.38.137]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E92312D53C for ; Tue, 30 Aug 2016 05:45:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IUBjsPu7MGrhJ8VgSHpzersxM1bcFFtlKqZYhWOc/RQ=; b=TXSezfUzD89/9XSA+s7bWFlJFS8NrKRn3LDyjp18uI60sHAZV+tx/2ipgE75HKy3T92YI5lndoJV3KFufW2a1Te0l26HpIbs0s18HOFgH2Eus2euxd29cW0YVka8gNa5DrWBC8Am5O2no62/LRK42PeWQ2B9JOqCvSk+29UcskU=
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1449.namprd05.prod.outlook.com (10.160.148.155) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.8; Tue, 30 Aug 2016 12:45:20 +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.0609.002; Tue, 30 Aug 2016 12:45:20 +0000
From: Kent Watsen 
To: Nick Weeds , "netconf@ietf.org" 
Thread-Topic: [Netconf] restconf confusing text
Thread-Index: AQHR/29eYBhuBXGDKEuucMYvQyMjoaBfq1aAgABFhoD//8w8gIAASjQA///FpICAAYOAAP//5l4A
Date: Tue, 30 Aug 2016 12:45:20 +0000
Message-ID: <692F9B08-DD59-41C4-BBD9-74A635160E05@juniper.net>
References: <29EA4D21-A2D5-4C53-8433-C731B46EAA49@juniper.net> <20160829.151843.1201990968547518910.mbj@tail-f.com> <1342C4E4-B0EB-4038-8FF4-AAA3A017B504@juniper.net> <20160829.163902.249281557887179222.mbj@tail-f.com> <71E4B73E-891B-41FD-8F0A-0A9FB510AF00@juniper.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.18.0.160709
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.14]
x-ms-office365-filtering-correlation-id: 280c7333-ff9a-4a17-bfd1-08d3d0d38087
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1449; 6:JGLSaegkt4uupJ+4cXgJ0LtOWBLWbatOUaO32RWFzKm/uXcZGavmad0KduIvYn0Ivm4xYxIl2AK4sKU5+BamxmPpFfIqnLhkRtifPoubCY7neLaX+Cck3wLS9MRzWevdNsZSuumwHSY+pj5g9oQ8X98DibruC71xOxtPXmbC2RoOgYt8d/aBFVwaRUrGRIqGOix7+2XVfqOBZfornRm9lKJGxD6auoFxEkqTUhNZ9xYxZx8lUZz/lR+4BPUc8qxSoqGLBRj+MflqDXRRVThFW60xZ6aSxOfiAn022EVRBnysnJKy4iJIkdrDifADtdpV+VhxuJhdXtU0xiZz/kEzhQ==; 5:BFivBXmmtaDDTh1S8X01XJdieIXWRkGUlZALrjKkXlK5gFNd87dHARsYPYTLAKfxwOpHZoz1EqIEroTp98xgyVwN8pGfngEbeiL+aRaJSBmzwOSRVvsq9SHFTZTOZE8U5fujzy5tuWXQYWqI7m5eNQ==; 24:u78bO55ruShpta2eyQ+Sdbxa/s7eP+O+bZEv9aPkn7i0o8Ok58eC3tqiUyhTt6PqnUAecmDnFkd5NrDwBgv8zIIhT0jZ2W1biJ5ZAIt31CA=; 7:iyVQwvZmttTwMhPOOZAYMM4ibftu7+y3GngJZDjr3zTW7Z1XrFcx3Yc1T25CT9IfwrOZt/Xll24FNZiZ5RV7C/8NP7SyNM4DJguGmQoxIQPtEgYLQ3i3PqGZr6G+HdLpGQDJ7uer6AkESQWgQ9nNQfw/grnXmcNgCsGfJKSz2vDrYfv7CQbin/GpIFIWOSAvGnfsIDnb1PM7QnW8rwmiYPPcal40oaqNFFjtwwan74VJxQw80suNS8jh0KxIbiGF
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1449;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:CY1PR0501MB1449; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1449; 
x-forefront-prvs: 0050CEFE70
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(24454002)(189002)(13464003)(377454003)(33656002)(2900100001)(107886002)(586003)(86362001)(6116002)(50986999)(5660300001)(76176999)(2906002)(83506001)(66066001)(3846002)(54356999)(99286002)(102836003)(82746002)(81166006)(83716003)(8676002)(8936002)(19580405001)(122556002)(15975445007)(81156014)(5001770100001)(10400500002)(105586002)(3660700001)(305945005)(2950100001)(93886004)(7736002)(97736004)(77096005)(87936001)(7846002)(2501003)(106356001)(106116001)(4001350100001)(5002640100001)(3280700002)(189998001)(11100500001)(92566002)(19580395003)(36756003)(68736007)(101416001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1449; 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:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <79E4E65D432E7D49B0D98CB975BD3A85@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2016 12:45:20.0717 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1449
Archived-At: 
Subject: Re: [Netconf] restconf confusing text
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Aug 2016 12:45:26 -0000

DQpUcnVlLCB0aGUg4oCcbGlicmFyeeKAnSBub2RlIGlzIGEgZGF0YSByZXNvdXJjZSwgd2l0aCBv
ciB3aXRob3V0IHRoZSBxdWVyeSBwYXJhbWV0ZXJzLiAgTm90ZSB0aGF0IGl0IGlzIGEg4oCYY29u
dGFpbmVy4oCZIG5vZGUgKG5vdCBhIGxpc3Qgb3IgbGVhZi1saXN0KSwgd2hpY2ggaXMgd2h5IGl0
IHdvcmtzLiAgQlRXLCBxdWVyeSBwYXJhbWV0ZXJzIGFyZSBzZXBhcmF0ZWQgYnkgYSDigJg/4oCZ
IChub3Qg4oCYO+KAmSkgY2hhcmFjdGVyLiBTbyB0aGUgcmVxdWVzdCBzaG91bGTigJl2ZSBiZWVu
Og0KDQoJICAgICAgIEdFVCAvcmVzdGNvbmYvZGF0YS9leGFtcGxlLWp1a2Vib3g6anVrZWJveC9s
aWJyYXJ5P2ZpZWxkcz1hcnRpc3QvbmFtZSBIVFRQLzEuMQ0KDQpCVFcsIEnigJltIG5vdCBzdXJl
IGlmIHRoZSBleGFtcGxlIGluIEQuMy4zIGlzIGNvcnJlY3QuICBJdCBzZWVtcyB0aGF0IGl0IHNo
b3VsZCByZXR1cm4gYSDigJxkYXRh4oCdIG9iamVjdCAobm90IGEg4oCcbW9kdWxlcy1zdGF0ZeKA
nSBvYmplY3QpLg0KDQpDaGVlcnMsDQpLZW50DQoNCk9uIDgvMzAvMTYsIDY6MTcgQU0sICJOZXRj
b25mIG9uIGJlaGFsZiBvZiBOaWNrIFdlZWRzIiA8bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIG9u
IGJlaGFsZiBvZiBuaWNrLndlZWRzQG1ldGFzd2l0Y2guY29tPiB3cm90ZToNCg0KICAgIEluIGNh
c2UgaXQgaGVscHMgb3RoZXIgcmVhZGVyczogSSBiZWxpZXZlIGl0IGlzIHBvc3NpYmxlIHRvIHBl
cmZvcm0gdGhlIGdldCB0aGUgYXJ0aXN0IG5hbWUgaW5mb3JtYXRpb24gaW4gRGFsZSdzIGV4YW1w
bGUgdXNpbmc6DQogICAgDQogICAgICAgR0VUIC9yZXN0Y29uZi9kYXRhL2V4YW1wbGUtanVrZWJv
eDpqdWtlYm94L2xpYnJhcnk7ZmllbGRzPWFydGlzdC9uYW1lIEhUVFAvMS4xDQogICAgDQogICAg
aW5zdGVhZCBvZg0KICAgIA0KICAgICAgIEdFVCAvcmVzdGNvbmYvZGF0YS9leGFtcGxlLWp1a2Vi
b3g6anVrZWJveC9saWJyYXJ5L2FydGlzdC9uYW1lIEhUVFAvMS4xDQogICAgDQogICAgVGhlIGZv
cm1lciBzYXRpc2ZpZXMgdGhlIHJlcXVpcmVtZW50IHRoYXQgdGhlIHRhcmdldCAoL3Jlc3Rjb25m
L2RhdGEvZXhhbXBsZS1qdWtlYm94Omp1a2Vib3gvbGlicmFyeSkgaXMgYSAiZGF0YSByZXNvdXJj
ZSIuDQogICAgVGhlIHJlc3BvbnNlIHdvdWxkIGJlIGEgc2luZ2xlICJsaWJyYXJ5IiBvYmplY3Qg
Y29udGFpbmluZyBtdWx0aXBsZSBhcnRpc3QgbGlzdCBlbnRyaWVzLCBhbmQgd291bGQgYmUgdmFs
aWQgaW4gYm90aCBYTUwgYW5kIEpTT04gZW5jb2RpbmdzLg0KICAgIA0KICAgIAlOaWNrLg0KICAg
IA0KICAgIA0KICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgRnJvbTogTmV0Y29u
ZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEtlbnQgV2F0
c2VuDQogICAgU2VudDogMjkgQXVndXN0IDIwMTYgMTY6MTANCiAgICBUbzogTWFydGluIEJqb3Jr
bHVuZA0KICAgIENjOiBuZXRjb25mQGlldGYub3JnDQogICAgU3ViamVjdDogUmU6IFtOZXRjb25m
XSByZXN0Y29uZiBjb25mdXNpbmcgdGV4dA0KICAgIA0KICAgIA0KICAgIA0KICAgIA0KICAgIE9u
IDgvMjkvMTYsIDEwOjM5IEFNLCAiTWFydGluIEJqb3JrbHVuZCIgPG1iakB0YWlsLWYuY29tPiB3
cm90ZToNCiAgICANCiAgICAgICAgSXQncyBub3QgdGVjaG5pY2FsbHkgYSAiZGF0YSByZXNvdXJj
ZSIsIGFuZCB0aHVzIHRoaXMgZG9jdW1lbnQgZG9lc24ndA0KICAgICAgICBoYXZlIHRvIHNheSBh
bnl0aGluZyBhYm91dCBpdC4NCiAgICAgICAgICAgIA0KICAgICAgICAvbWFydGluDQogICAgICAg
IA0KICAgIA0KICAgIEluIHRoYXQgY2FzZSwgSSBhZ3JlZSB3aXRoIHlvdXIgYXNzZXNzbWVudCwg
YnV0IGZlZWwgdGhhdCB0aGlzIGRvY3VtZW50IHNob3VsZCBzdGlsbCBzYXkgc29tZXRoaW5nIGFi
b3V0LiAgU3BlY2lmaWNhbGx5LCBJIHRoaW5rIGl0IHNob3VsZCBzYXkgc29tZXRoaW5nIGFsb25n
IHRoZSBsaW5lcyBvZiB3aGF0IHlvdSBqdXN0IHdyb3RlIGFib3ZlLg0KICAgIA0KICAgIEtlbnQN
CiAgICANCiAgICANCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KICAgIE5ldGNvbmYgbWFpbGluZyBsaXN0DQogICAgTmV0Y29uZkBpZXRm
Lm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0K
ICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQogICAgTmV0Y29uZiBtYWlsaW5nIGxpc3QNCiAgICBOZXRjb25mQGlldGYub3JnDQogICAgaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQogICAgDQoNCg==


From nobody Tue Aug 30 07:08:02 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C3A12D67A for ; Tue, 30 Aug 2016 07:07:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rByKVRJJZoS7 for ; Tue, 30 Aug 2016 07:07:48 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38F0C12D61B for ; Tue, 30 Aug 2016 07:07:48 -0700 (PDT)
Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id B92C79868BFA2 for ; Tue, 30 Aug 2016 14:07:44 +0000 (GMT)
Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u7UE7koV031773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 30 Aug 2016 14:07:47 GMT
Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u7UE7kbC022788 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 30 Aug 2016 14:07:46 GMT
Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.103]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Tue, 30 Aug 2016 10:07:46 -0400
From: "Sterne, Jason (Nokia - CA)" 
To: Netconf 
Thread-Topic: 'report-all' (RFC 6243) and leafs without defaults
Thread-Index: AdICx+FMi5IAyyiVTjyvy6wCJfB1ug==
Date: Tue, 30 Aug 2016 14:07:45 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.17]
Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5CD0F03AUS70TWXCHMBA11z_"
MIME-Version: 1.0
Archived-At: 
Subject: [Netconf] 'report-all' (RFC 6243) and leafs without defaults
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Aug 2016 14:07:57 -0000

--_000_A125E53CE190A749957C19483DC79F9F5CD0F03AUS70TWXCHMBA11z_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

I was hoping to confirm my understanding of  for non-configured=
 leafs that don't have a schema default (i.e. no 'default' statement in the=
 YANG).

e.g. from openconfig-bgp:
    leaf tcp-mss {
      type uint16;
      description
        "Sets the max segment size for BGP TCP sessions.";
    }

Or link-up-down-trap-enable* or description from ietf-interfaces.

If there is no default and the client hasn't configured a value, then the l=
eaf is simply absent in a  reply (assuming 'trim' or 'explicit'=
 modes from RFC 6243). I suppose the typical assumption is that the absence=
 of the leaf implies it is disabled/not in operation/not in use.

If a  is done using report-all t=
hen leafs without defaults specified in the YANG model, and that haven't be=
en configured/set by the client, are simply not returned in the response ri=
ght ? They will be absent from a report-all request just as they were with =
a trim (or explicit) response.

Regards,
Jason

* In the case of link-up-down-trap-enable the description explains how the =
server behaves when this leaf isn't configured but that doesn't change the =
type of response behavior I describe above.



--_000_A125E53CE190A749957C19483DC79F9F5CD0F03AUS70TWXCHMBA11z_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi all,


 


I was hoping to confirm my understanding of <get-config> for non=
-configured leafs that don’t have a schema default (i.e. no ‘de=
fault’ statement in the YANG).


 


e.g. from openconfig-bgp:


    leaf tcp-mss {


      type uint16;


      description


        "Sets the max segment =
size for BGP TCP sessions.";


    }


 


Or link-up-down-trap-enable* or description from ietf-interfaces.

 


If there is no default and the client hasn’t configured a value,=
 then the leaf is simply absent in a <get-config> reply (assuming =
216;trim’ or ‘explicit’ modes from RFC 6243). I suppose t=
he typical assumption is that the absence of the leaf implies it is
disabled/not in operation/not in use.


 


If a <get-config> is done using <with-defaults>report-all&=
lt;/with-defaults> then leafs without defaults specified in the YANG mod=
el, and that haven’t been configured/set by the client, are simply no=
t returned in the response right ? They will be absent from
a report-all request just as they were with a trim (or explicit) response.<=
/div>

 


Regards,


Jason


 


* In the case of link-up-down-trap-enable the description explains how=
 the server behaves when this leaf isn’t configured but that doesn=
217;t change the type of response behavior I describe above.


 


 





--_000_A125E53CE190A749957C19483DC79F9F5CD0F03AUS70TWXCHMBA11z_--


From nobody Tue Aug 30 07:27:05 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8E112D68D for ; Tue, 30 Aug 2016 07:27:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level: 
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TODjYqxAjbwu for ; Tue, 30 Aug 2016 07:26:59 -0700 (PDT)
Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (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 0543612D6B9 for ; Tue, 30 Aug 2016 07:23:12 -0700 (PDT)
Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-06v.sys.comcast.net with SMTP id ejwDbjLKR2NhqejwWbQFIT; Tue, 30 Aug 2016 14:23:12 +0000
Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-ch2-19v.sys.comcast.net with SMTP id ejwUbmsDmg3APejwVbuRuA; Tue, 30 Aug 2016 14:23:11 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u7UENBBk005701; Tue, 30 Aug 2016 10:23:11 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u7UENAd6005698; Tue, 30 Aug 2016 10:23:10 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com (Dale R. Worley)
To: Martin Bjorklund 
In-Reply-To: <20160829.163801.2294516285410948326.mbj@tail-f.com>
Sender: worley@ariadne.com (Dale R. Worley)
Date: Tue, 30 Aug 2016 10:23:10 -0400
Message-ID: <87zinu1gkx.fsf@hobgoblin.ariadne.com>
X-CMAE-Envelope: MS4wfFVc5StiUjf4z8GOTNsFUSjPSYwo9dFFc3UFdYl2OpC27bcS+7xfyznRrnFMiJjK/7sE04xB0l3L3w/j0Q57G03nj+FBOBOAYPAZhLoHUt2touvb4+jR O8HN9doKmzZ2HrLK1H98MV5zPjdWD7a1WeVwHPfbB+/qAKP4tIHcsNlNmiFIJbaIZuL8SSWYBQDk3D6oCHp4qUDaLRZDduUbFFw=
Archived-At: 
Cc: netconf@ietf.org
Subject: Re: [Netconf] restconf confusing text
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Aug 2016 14:27:03 -0000

Martin Bjorklund  writes:
> I don't think that this document specifies how the reply to a
> "multi-instance URL" would work for JSON.

Indeed, it doesn't (as far as I remember).  As I said,

    I've been assuming that that support is implicit in JSON, and I know
    little about JSON.  But if it's *not* a conventional part of JSON, that
    needs to be spelled out in the document.

>> Since multiple-resource URLs can only identify state data
>
> What text in the document says this?

The only way you can create a multi-node URL is to explot the fact that
some lists do not have unique keys, allowing you to write the list node
name as a path segment in the URL without providing a key value.  (In
Yang, the list statement doesn't have a key substatement.)  But only
non-configuration lists can have no key.  See
draft-ietf-netmod-rfc6020bis-14 section 7.8.2, or parallel statements in
RFC 6020 or later versions of the draft.

Martin Bjorklund  writes:
> It's not technically a "data resource", and thus this document doesn't
> have to say anything about it.

True, it doesn't fit within the definition of the term in the
terminology section.  But it's clear from the meanings of the text that
the writers *intended* for this sort of multi-node URL to be
implemented, and to mean what I've described.  So they need to fix the
language to match their intentions.

Or decide they're going to change the semantics of Restconf.

Juergen Schoenwaelder :
> Stupid question: Is there an HTTP status code that can be returned in
> these cases (e.g., 406 Not Acceptable)? A future specification can
> then define how to handle these requests.

Yeah, in draft-ietf-netconf-restconf-15 section 4.3, it specifies 404 as
the response code:

   If a retrieval request for a data resource representing a YANG leaf-
   list or list object identifies more than one instance, and XML
   encoding is used in the response, then an error response containing a
   "400 Bad Request" status-line MUST be returned by the server.

Somewhat oddly, if the client gives the server the option of using
either XML or JSON in this situation, the server can either choose XML
and return 404 or choose JSON and return the requested data.  To ensure
that it will get the data, the client must allow JSON responses only.
But that is consistent.

Dale


From nobody Tue Aug 30 09:10:37 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0502112DBA6 for ; Tue, 30 Aug 2016 09:10:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level: 
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chGMG318wih4 for ; Tue, 30 Aug 2016 09:10:33 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6157212D9F0 for ; Tue, 30 Aug 2016 08:50:03 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BBDF96D8; Tue, 30 Aug 2016 17:50:01 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Qh_WUX_-W9K2; Tue, 30 Aug 2016 17:49:53 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 30 Aug 2016 17:50:01 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E0C5B200A6; Tue, 30 Aug 2016 17:50:00 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Pg202HSRQsdu; Tue, 30 Aug 2016 17:49:59 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4744F200A5; Tue, 30 Aug 2016 17:49:59 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 0B4123C53BA9; Tue, 30 Aug 2016 17:49:57 +0200 (CEST)
Date: Tue, 30 Aug 2016 17:49:57 +0200
From: Juergen Schoenwaelder 
To: "Sterne, Jason (Nokia - CA)" 
Message-ID: <20160830154957.GB2356@elstar.local>
Mail-Followup-To: "Sterne, Jason (Nokia - CA)" , Netconf 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] 'report-all' (RFC 6243) and leafs without defaults
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Aug 2016 16:10:37 -0000

On Tue, Aug 30, 2016 at 02:07:45PM +0000, Sterne, Jason (Nokia - CA) wrote:
> Hi all,
> 
> I was hoping to confirm my understanding of  for non-configured leafs that don't have a schema default (i.e. no 'default' statement in the YANG).
> 
> e.g. from openconfig-bgp:
>     leaf tcp-mss {
>       type uint16;
>       description
>         "Sets the max segment size for BGP TCP sessions.";
>     }
> 
> Or link-up-down-trap-enable* or description from ietf-interfaces.
> 
> If there is no default and the client hasn't configured a value, then the leaf is simply absent in a  reply (assuming 'trim' or 'explicit' modes from RFC 6243). I suppose the typical assumption is that the absence of the leaf implies it is disabled/not in operation/not in use.

If there is no configured value and no default that applies, then the
operationally used value (if any) depends on the semantics of the
leaf.  In some situations, this may mean that an implementation
specific value is actually used (likely true for the tcp-mss
case). For link-up-down-trap-enable, the exact semantics are actually
explained in the description clause. So in this case, there is a clear
specification what a client can assume that is aware of the specific
semantics of the leaf.
 
> If a  is done using report-all then leafs without defaults specified in the YANG model, and that haven't been configured/set by the client, are simply not returned in the response right ? They will be absent from a report-all request just as they were with a trim (or explicit) response.

Yes. There simply is no config value. There may be an operationally
used value. (I hope we do not get back into the debate what 'config'
means now...)

/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 Aug 30 14:09:23 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4DE12D81A for ; Tue, 30 Aug 2016 14:09:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level: 
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeG1uwoI_T8j for ; Tue, 30 Aug 2016 14:09:21 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBBDE12B05D for ; Tue, 30 Aug 2016 14:09:20 -0700 (PDT)
Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id 2A204501F4388; Tue, 30 Aug 2016 21:09:16 +0000 (GMT)
Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u7UL9JSV027193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Aug 2016 21:09:19 GMT
Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u7UL9I13011808 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Aug 2016 21:09:18 GMT
Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.103]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Tue, 30 Aug 2016 17:09:18 -0400
From: "Sterne, Jason (Nokia - CA)" 
To: Juergen Schoenwaelder 
Thread-Topic: [Netconf] 'report-all' (RFC 6243) and leafs without defaults
Thread-Index: AdICx+FMi5IAyyiVTjyvy6wCJfB1ugAL84aAAABGlzA=
Date: Tue, 30 Aug 2016 21:09:18 +0000
Message-ID: 
References:  <20160830154957.GB2356@elstar.local>
In-Reply-To: <20160830154957.GB2356@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.17]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: Netconf 
Subject: Re: [Netconf] 'report-all' (RFC 6243) and leafs without defaults
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 Aug 2016 21:09:22 -0000

Thx Juergen.

I guess you are right that the behavior of the server when there is no defa=
ult in the schema and nothing configured could be pretty much anything (inc=
luding an operationally used value that isn't in the YANG or may be dynamic=
, disabled, etc). There is simply no configured value (so reading config sh=
ould return nothing).

Regards,
Jason

-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20
Sent: Tuesday, August 30, 2016 11:50
To: Sterne, Jason (Nokia - CA)
Cc: Netconf
Subject: Re: [Netconf] 'report-all' (RFC 6243) and leafs without defaults

On Tue, Aug 30, 2016 at 02:07:45PM +0000, Sterne, Jason (Nokia - CA) wrote:
> Hi all,
>=20
> I was hoping to confirm my understanding of  for non-configur=
ed leafs that don't have a schema default (i.e. no 'default' statement in t=
he YANG).
>=20
> e.g. from openconfig-bgp:
>     leaf tcp-mss {
>       type uint16;
>       description
>         "Sets the max segment size for BGP TCP sessions.";
>     }
>=20
> Or link-up-down-trap-enable* or description from ietf-interfaces.
>=20
> If there is no default and the client hasn't configured a value, then the=
 leaf is simply absent in a  reply (assuming 'trim' or 'explici=
t' modes from RFC 6243). I suppose the typical assumption is that the absen=
ce of the leaf implies it is disabled/not in operation/not in use.

If there is no configured value and no default that applies, then the opera=
tionally used value (if any) depends on the semantics of the leaf.  In some=
 situations, this may mean that an implementation specific value is actuall=
y used (likely true for the tcp-mss case). For link-up-down-trap-enable, th=
e exact semantics are actually explained in the description clause. So in t=
his case, there is a clear specification what a client can assume that is a=
ware of the specific semantics of the leaf.
=20
> If a  is done using report-all=
 then leafs without defaults specified in the YANG model, and that haven't =
been configured/set by the client, are simply not returned in the response =
right ? They will be absent from a report-all request just as they were wit=
h a trim (or explicit) response.

Yes. There simply is no config value. There may be an operationally used va=
lue. (I hope we do not get back into the debate what 'config'
means now...)

/js

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


From nobody Wed Aug 31 08:51:23 2016
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4C712D12B for ; Wed, 31 Aug 2016 08:51:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvfVoZh16iNY for ; Wed, 31 Aug 2016 08:51:18 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2162212D520 for ; Wed, 31 Aug 2016 08:40:22 -0700 (PDT)
Received: from localhost (h-85-226.a165.priv.bahnhof.se [94.254.85.226]) by mail.tail-f.com (Postfix) with ESMTPSA id DD03A1AE035B for ; Wed, 31 Aug 2016 17:40:19 +0200 (CEST)
Date: Wed, 31 Aug 2016 17:40:19 +0200 (CEST)
Message-Id: <20160831.174019.1420525303963119375.mbj@tail-f.com>
To: netconf@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: [Netconf] question about "event drafts"
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Aug 2016 15:51:22 -0000

Hi,

I just watched the recorded NETCONF session from IETF 96, and read
the minutes.  In the minutes I read that four new drafts related to
event notifications are supposed to be adopted, after validation on
the ML.  I haven't seen any email about this adoption, and I don't
understand which four drafts you referred to.  I can guess that three
of them are:

  draft-gonzalez-netconf-event-notifications-00
  draft-gonzalez-netconf-5277bis-02
  draft-voit-netconf-restconf-notif-00

I don't think that these documents are ready for adoption.  It is not
clear to me how they are supposed to work.  First of all, we have the
5277bis document, which apparently doesn't obsolete 5277.  However,
the event-notifications draft says that it obsoletes 5277.  Also,
there is still quite some overlap between the documents.

For example, 5277bis says:

   This document defines mechanisms that provide an asynchronous message
   notification delivery service for the NETCONF protocol .  This is an
   optional capability built on top of the base NETCONF definition.

And draft-gonzalez-netconf-event-notifications says:

   This document defines the support of [event-notifications] by the
   Network Configuration protocol (NETCONF).

So it seems both drafts define how notifications are sent over
NETCONF.

Further, the intent of draft-voit-netconf-restconf-notif-00 is not
clear.  RESTCONF already supports notifications, and this new draft
has:

  3.1.1.  Dynamic YANG Subscription over RESTCONF

     Dynamic Subscriptions are configured and manage Subscriptions via
     signaling.  This signaling is transported over [restconf].  Once
     established, streaming Event Notifications are then delivered via
     Restconf SSE.

I don't understand what this means.


I think that this confusion is basically just the result of some
reshuffling of contents, and that's fine.  But I think that the intent
of each individual draft must be more clear, and that the text in the
drafts actually reflects this.


/martin