From nobody Fri Sep 1 02:46:24 2017 Return-Path: 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 CBF261331DE for ; Fri, 1 Sep 2017 02:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 hh_HSquyiBzk for ; Fri, 1 Sep 2017 02:46:18 -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 8E905132EFE for ; Fri, 1 Sep 2017 02:46:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32842; q=dns/txt; s=iport; t=1504259177; x=1505468777; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=SzFIVYzwBz3g1VORuy1AqDD/WdblVnUB09unNlTDv7w=; b=ZKVll5Oj+dFSauSpYGUiQo1ILmRPaG9yV5eH1rEWq7FZ9/2gt5HOCtA1 c1W7pf0HhCm/GGUiwn4EVJFIebqCV2/zJw93j+fcwK+ykBUYobw4zcT6t +6k0wDqL7CAghoSfwDdatD/MZ9thRGx4fTMCymIGQ5HW1MGn7y92YBAVX I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BFAgCwK6lZ/xbLJq1ZAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJvAYFOgRWPC5B5IneVMQ6CAQMhAQqDPIEQTwKEVBYBAgEBAQE?= =?us-ascii?q?BAQFrKIUYAQEBAQIBAQEYVBAJAgsQAQQBAQEgBwcbDB8JCAYBDAYCAQEVihAIE?= =?us-ascii?q?LJjJ4s5AQEBAQEBAQEBAQEBAQEBAQEBAQEBHQWDJYNQgWMrC4I9NYRCARIBCRw?= =?us-ascii?q?ZAhURhS0FigUTiHaFJYg/lFGCE4lAJIZ3jVOIdCYMJUFBCzIhCBwVSYRfgj0/N?= =?us-ascii?q?ohQgjIBAQE?= X-IronPort-AV: E=Sophos;i="5.41,457,1498521600"; d="scan'208,217";a="657169267" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Sep 2017 09:45:52 +0000 Received: from [10.63.23.169] (dhcp-ensft1-uk-vla370-10-63-23-169.cisco.com [10.63.23.169]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v819jpjY031331; Fri, 1 Sep 2017 09:45:51 GMT To: Alex Campbell , "netmod@ietf.org" References: <599F0991.7020900@tail-f.com> <20170825125254.6nhnzkrar6fhu7zr@elstar.local> <20170828154640.pzg7jfy5uepkb22q@elstar.local> <20170830102902.2n5q6rgq2x2dxfq2@elstar.local> <20170830123156.cssrg5kklpo67fie@elstar.local> <1504223854014.55228@Aviatnet.com> From: Robert Wilton Message-ID: <847e5bf9-7b3d-9ff8-9954-970f32a2094c@cisco.com> Date: Fri, 1 Sep 2017 10:45:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1504223854014.55228@Aviatnet.com> Content-Type: multipart/alternative; boundary="------------D8FBC31F519115DCFC7D3C1B" Content-Language: en-US Archived-At: Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 09:46:23 -0000 This is a multi-part message in MIME format. --------------D8FBC31F519115DCFC7D3C1B Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Alex, On 01/09/2017 00:57, Alex Campbell wrote: > > Hi, > > > I'd be very wary of adding guidelines that restrict the regex syntax. > > > A tool that supports YANG must implement the full regex language > anyway (or ignore regexes altogether if they are not relevant to the > tool's function). > This is true if the tool is designed to work with any arbitrary YANG module.  But if a tool only needs to work with a subset of YANG modules (e.g. perhaps just IETF, OpenConfig, and Vendor models) then they only need to support the subset of the XML RE language that is used by the YANG modules that they load. > However, these guidelines will inevitably encourage some tool authors > to take shortcuts. > Yes, that is one of the two aims of these guidelines (the other being ease/accuracy of comprehension). A proper way for a tool policing this to spot the parts of the XML RE language that it can't handle, and generating appropriate warnings.  I believe that this is easy to do. But I would rather that all YANG modules use the same regex syntax rather than two separate regex syntaxes as is the current status today (e.g. OpenConfig modules are using the POSIX extended RE language). > > I'm sure there are already tools that take shortcuts - but if the > shortcuts cause problems, right now it's squarely the tool's fault, > rather than the model being processed. > > If there are official guidelines saying not to use such-and-such regex > feature, then the tool author can point to the guideline and say "See? > You aren't supposed to be using that". > These are guidelines, not rules, and all of my proposed guidelines are SHOULDs not MUSTs, except that I've mandated not to use '\d' when matching [0-9] is what is required.  My guess is that most of pattern statements that use \d instead of [0-9] are probably not what the author intended. Can you provide any examples of where the XML RE constructs that I am suggesting avoiding are required in any standard network management YANG modules? > > We may end up with a compatibility nightmare on our hands where > certain modules are only compatible with certain tools, even more-so > than is the case now. > The way I see it, adopting these guidelines is likely to improve compatibility rather than lessen it, since it encourages authors to write YANG models in a way that more tools are likely to cleanly interoperate with, and basically happens to be the way that folk are writing standards based YANG modules anyway ... Thanks, Rob > > The only way I'd ever approve of this is if it was a MUST requirement > in a new version of YANG. > > > > ------------------------------------------------------------------------ > *From:* netmod on behalf of Robert Wilton > > *Sent:* Thursday, 31 August 2017 4:44 a.m. > *To:* Andy Bierman; Juergen Schoenwaelder; Xufeng Liu; netmod@ietf.org > *Subject:* Re: [netmod] Potential additions to rfc6087bis: RegEx > guidelines > > Hi, > > On 30/08/2017 15:52, Andy Bierman wrote: >> >> >> On Wed, Aug 30, 2017 at 5:31 AM, Juergen Schoenwaelder >> > > wrote: >> >> On Wed, Aug 30, 2017 at 12:48:19PM +0100, Robert Wilton wrote: >> > >> > >> > On 30/08/2017 11:29, Juergen Schoenwaelder wrote: >> > > On Wed, Aug 30, 2017 at 10:16:30AM +0100, Robert Wilton wrote: >> > > > Hi Andy, >> > > > >> > > > What I am suggesting makes it easier for readers, because I >> am a proponent >> > > > of simpler regular expressions that are easy to read and >> understand. >> > > > >> > > > For example, I wonder how many YANG model readers would >> immediately >> > > > comprehend what this pattern statement means: >> > > > >> > > > pattern "\p{Sc}\p{Zs}?\p{Nd}+\.\p{Nd}{2}"? >> > > > >> > > > Does allowing such patterns really make it easier for model >> readers? >> > > This is always difficult to judge but to be fair you have to >> show how >> > > you express _the same_ (and not a subset) with some other kind of >> > > regular expressions. (My understanding is that \p{Sc} is a >> currency >> > > symbol.) >> > Yes, the expression would cover a currency amount, along with >> associated >> > symbol (e.g. "$200.00"). >> > >> > If I was writing a module, I would probably use the following >> pattern >> > statement instead, which I think a lot more people would likely >> be able to >> > comprehend: >> > >> > pattern "[A-Z]{3}\s?\d+\.\d{2}", using the 3 letter, ISO 4217, >> currency codes.  e.g. ("USD 200.00") >> >> But that is not the same. Apples versus oranges. (I expect people to >> tell me that (i) currency is irrelevant and (ii) that three ASCII >> letter currency acronyms are better than currency symbols anyway but >> this is a separate discussion I am not interested in.) >> >> > > >> > > > The proposes guidelines obviously make it easier (or at >> least no harder) for >> > > > tool makers. >> > > > >> > > > I agree that there is an minor impact to model writers, but >> really only in >> > > > the sense that the guidelines would be telling them not to >> use the esoteric >> > > > options of the XML regex syntax that they probably don't >> know about anyway. >> > > What is 'esoteric' largely depends on your language >> environment. What >> > > you are saying by 'do not use \p{}' is essentially 'do not >> use any >> > > unicode long live ASCII'. >> > No, that is not my intention, i.e. I'm not suggesting banning >> all use of >> > \p{}, but instead limiting it to the character classes that >> seem like they >> > may plausibly be used in standardized YANG modules. >> >> This is entirely subjective. And if you still allow some \p{}, >> what is >> the point of the exercise? >> >> > I'm not trying to change what 6020/7950 defines the pattern >> statement as, >> > just give what I perceive as some pragmatic guidance as to what >> parts of XML >> > RE it makes sense to use in standardized YANG modules, making >> it easier for >> > readers and implementations. >> > >> > I think that it is fine for companies, vendors, etc to use the >> full breadth >> > of XML RE if they wish. >> >> Implementations have to be prepared to handle XSD pattern if they >> claim compliance to YANG 1.0 and 1.1. So all this only helps >> non-compliant implementations. This may indeed be a goal - but >> then we >> should spell this out as such - this helps non-compliant >> implementations (and they may still fail on the first \p{} that >> you still allow). >> >> If implementations do not implement the YANG pattern statement but >> something else, then then they should ignore patterns they can't >> understand and treat the pattern as if it would have been in a >> description clause - i.e., leave it to humans to write the code that >> implements the pattern correctly. Note that YANG does not say >> anything >> how stuff is implemented. >> >> >> >> This does not work. >> There are 3 outcomes from the regex compiler >> >> 1) proper syntax was used and accepted; pattern matches correctly >> 2) improper syntax was used and accepted; pattern matches incorrectly >> 3) improper syntax was used and rejected; compiler error generated >> >> Case (2) is the really bad one and we have seen in in bug reports. >> >> This issue was discussed in detail for almost 2 years and the >> conclusion was >> that a YANG extension would be used to specify other pattern types than >> the XSD pattern mandated by the standard. > I actually think that XML RE is a good choice for YANG pattern > statements (because it is one of the more simple RE languages), I just > don't think that we need all of it. > > > First question: How many pattern statements in draft and standard IETF > YANG modules actually use Unicode properties (e.g \p{}). > Answer: Just 2.  To add a zone at the end of the IPv4/IPv6 address. > > E.g.       pattern > '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}' >       +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])' >       + '(%[\p{N}\p{L}]+)?'; > > This could quite possibly have been written just as > "\d{1,3}\.{3}\d{1,3)(%\w+)?" and not use Unicode properties at all. > > There a couple more occurrences of Unicode character classes in the > vendor models on github, but only to restrict them to the ASCII > character set (oh the irony), which I believe can be accomplished > without resorting to Unicode properties. > > > Another question: How often is character class subtraction (e.g. > [A-Z-[PQ]] used in standard & the github YANG modules? > Answer: 0.  AFAICT, it isn't used at all, anywhere ... > > > > Now, I'm not proposing using a different regex syntax for pattern > statements, just a sensible subset of XSD RE, such that it easier for > folks to read/review pattern statements, and it is easier for client > and server implementations to translate into other common regex > implementations if they so wish. > > Of course, as part of that translation, I would expect a translation > function to check and generate an error if the translation cannot > handle the input regex (e.g. if it uses an obscure unmatched unicode > property or a unicode block, or character class subtraction syntax).  > This really doesn't seem hard to me. > > But the XML RE language has stuff in it that I don't think anyone is > ever going to use in a standardized network management YANG model.   > Forcing everyone to implement support for this stuff just seems like a > complete waste of time and effort.  Looking at the regex info website > it looks like there are about 143 unicode properties and blocks > defined (it may be incomplete), or which I think that 135+ of these > probably have no relevance in network management YANG modules, and the > benefit of the remaining ones is pretty suspect. > > I mean, how many network management YANG modules really need a pattern > statement that only matches Runic characters?  Perhaps someone out > there is busy defining "middle-earth.yang" ;-) > > If I am the only person opposed to making life unnecessarily difficult > to readers of YANG models, and client/server tool implementors > interacting with YANG then it is probably time to give up this > discussion. ;-) > > Python, quite likely a common tool for client side network management, > also doesn't seem to have any support of unicode properties or > blocks.  Perhaps implementations will hook it up to libxml2 instead, > or write a full translation XML RE to Python RE conversion tool.  But > probably most people will just feed the pattern statement into the > native Python regex engine, and my guess is that this will probably > work 95% of the time.  The other 5% ... who knows what will happen ... > oh well, better to try and fail than to not try at all. > > Apologies if this email comes across as a rant. > > Rob > > >> >> >> /js >> >> >> Andy >> >> -- >> Juergen Schoenwaelder           Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | >> Germany >> Fax:   +49 421 200 3103         > > >> >> > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------D8FBC31F519115DCFC7D3C1B Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Alex,


On 01/09/2017 00:57, Alex Campbell wrote:

Hi,


I'd be very wary of adding guidelines that restrict the regex syntax.


A tool that supports YANG must implement the full regex language anyway (or ignore regexes altogether if they are not relevant to the tool's function).

This is true if the tool is designed to work with any arbitrary YANG module.  But if a tool only needs to work with a subset of YANG modules (e.g. perhaps just IETF, OpenConfig, and Vendor models) then they only need to support the subset of the XML RE language that is used by the YANG modules that they load.

However, these guidelines will inevitably encourage some tool authors to take shortcuts.

Yes, that is one of the two aims of these guidelines (the other being ease/accuracy of comprehension).

A proper way for a tool policing this to spot the parts of the XML RE language that it can't handle, and generating appropriate warnings.  I believe that this is easy to do.

But I would rather that all YANG modules use the same regex syntax rather than two separate regex syntaxes as is the current status today (e.g. OpenConfig modules are using the POSIX extended RE language).


I'm sure there are already tools that take shortcuts - but if the shortcuts cause problems, right now it's squarely the tool's fault, rather than the model being processed.

If there are official guidelines saying not to use such-and-such regex feature, then the tool author can point to the guideline and say "See? You aren't supposed to be using that".

These are guidelines, not rules, and all of my proposed guidelines are SHOULDs not MUSTs, except that I've mandated not to use '\d' when matching [0-9] is what is required.  My guess is that most of pattern statements that use \d instead of [0-9] are probably not what the author intended.

Can you provide any examples of where the XML RE constructs that I am suggesting avoiding are required in any standard network management YANG modules?


We may end up with a compatibility nightmare on our hands where certain modules are only compatible with certain tools, even more-so than is the case now.

The way I see it, adopting these guidelines is likely to improve compatibility rather than lessen it, since it encourages authors to write YANG models in a way that more tools are likely to cleanly interoperate with, and basically happens to be the way that folk are writing standards based YANG modules anyway ...

Thanks,
Rob



The only way I'd ever approve of this is if it was a MUST requirement in a new version of YANG.



From: netmod <netmod-bounces@ietf.org> on behalf of Robert Wilton <rwilton@cisco.com>
Sent: Thursday, 31 August 2017 4:44 a.m.
To: Andy Bierman; Juergen Schoenwaelder; Xufeng Liu; netmod@ietf.org
Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines
 

Hi,

On 30/08/2017 15:52, Andy Bierman wrote:


On Wed, Aug 30, 2017 at 5:31 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Aug 30, 2017 at 12:48:19PM +0100, Robert Wilton wrote:
>
>
> On 30/08/2017 11:29, Juergen Schoenwaelder wrote:
> > On Wed, Aug 30, 2017 at 10:16:30AM +0100, Robert Wilton wrote:
> > > Hi Andy,
> > >
> > > What I am suggesting makes it easier for readers, because I am a proponent
> > > of simpler regular expressions that are easy to read and understand.
> > >
> > > For example, I wonder how many YANG model readers would immediately
> > > comprehend what this pattern statement means:
> > >
> > > pattern "\p{Sc}\p{Zs}?\p{Nd}+\.\p{Nd}{2}"?
> > >
> > > Does allowing such patterns really make it easier for model readers?
> > This is always difficult to judge but to be fair you have to show how
> > you express _the same_ (and not a subset) with some other kind of
> > regular expressions. (My understanding is that \p{Sc} is a currency
> > symbol.)
> Yes, the expression would cover a currency amount, along with associated
> symbol (e.g. "$200.00").
>
> If I was writing a module, I would probably use the following pattern
> statement instead, which I think a lot more people would likely be able to
> comprehend:
>
> pattern "[A-Z]{3}\s?\d+\.\d{2}", using the 3 letter, ISO 4217, currency codes.  e.g. ("USD 200.00")

But that is not the same. Apples versus oranges. (I expect people to
tell me that (i) currency is irrelevant and (ii) that three ASCII
letter currency acronyms are better than currency symbols anyway but
this is a separate discussion I am not interested in.)

> >
> > > The proposes guidelines obviously make it easier (or at least no harder) for
> > > tool makers.
> > >
> > > I agree that there is an minor impact to model writers, but really only in
> > > the sense that the guidelines would be telling them not to use the esoteric
> > > options of the XML regex syntax that they probably don't know about anyway.
> > What is 'esoteric' largely depends on your language environment. What
> > you are saying by 'do not use \p{}' is essentially 'do not use any
> > unicode long live ASCII'.
> No, that is not my intention, i.e. I'm not suggesting banning all use of
> \p{}, but instead limiting it to the character classes that seem like they
> may plausibly be used in standardized YANG modules.

This is entirely subjective. And if you still allow some \p{}, what is
the point of the exercise?

> I'm not trying to change what 6020/7950 defines the pattern statement as,
> just give what I perceive as some pragmatic guidance as to what parts of XML
> RE it makes sense to use in standardized YANG modules, making it easier for
> readers and implementations.
>
> I think that it is fine for companies, vendors, etc to use the full breadth
> of XML RE if they wish.

Implementations have to be prepared to handle XSD pattern if they
claim compliance to YANG 1.0 and 1.1. So all this only helps
non-compliant implementations. This may indeed be a goal - but then we
should spell this out as such - this helps non-compliant
implementations (and they may still fail on the first \p{} that
you still allow).

If implementations do not implement the YANG pattern statement but
something else, then then they should ignore patterns they can't
understand and treat the pattern as if it would have been in a
description clause - i.e., leave it to humans to write the code that
implements the pattern correctly. Note that YANG does not say anything
how stuff is implemented.


This does not work.
There are 3 outcomes from the regex compiler

1) proper syntax was used and accepted; pattern matches correctly
2) improper syntax was used and accepted; pattern matches incorrectly
3) improper syntax was used and rejected; compiler error generated

Case (2) is the really bad one and we have seen in in bug reports.

This issue was discussed in detail for almost 2 years and the conclusion was
that a YANG extension would be used to specify other pattern types than
the XSD pattern mandated by the standard.
I actually think that XML RE is a good choice for YANG pattern statements (because it is one of the more simple RE languages), I just don't think that we need all of it.


First question: How many pattern statements in draft and standard IETF YANG modules actually use Unicode properties (e.g \p{}).
Answer: Just 2.  To add a zone at the end of the IPv4/IPv6 address.

E.g.       pattern
        '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
      +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'
      + '(%[\p{N}\p{L}]+)?';

This could quite possibly have been written just as "\d{1,3}\.{3}\d{1,3)(%\w+)?" and not use Unicode properties at all.

There a couple more occurrences of Unicode character classes in the vendor models on github, but only to restrict them to the ASCII character set (oh the irony), which I believe can be accomplished without resorting to Unicode properties.


Another question: How often is character class subtraction (e.g. [A-Z-[PQ]] used in standard & the github YANG modules?
Answer: 0.  AFAICT, it isn't used at all, anywhere ...



Now, I'm not proposing using a different regex syntax for pattern statements, just a sensible subset of XSD RE, such that it easier for folks to read/review pattern statements, and it is easier for client and server implementations to translate into other common regex implementations if they so wish.

Of course, as part of that translation, I would expect a translation function to check and generate an error if the translation cannot handle the input regex (e.g. if it uses an obscure unmatched unicode property or a unicode block, or character class subtraction syntax).  This really doesn't seem hard to me.
 
But the XML RE language has stuff in it that I don't think anyone is ever going to use in a standardized network management YANG model.   Forcing everyone to implement support for this stuff just seems like a complete waste of time and effort.  Looking at the regex info website it looks like there are about 143 unicode properties and blocks defined (it may be incomplete), or which I think that 135+ of these probably have no relevance in network management YANG modules, and the benefit of the remaining ones is pretty suspect.

I mean, how many network management YANG modules really need a pattern statement that only matches Runic characters?  Perhaps someone out there is busy defining "middle-earth.yang" ;-)

If I am the only person opposed to making life unnecessarily difficult to readers of YANG models, and client/server tool implementors interacting with YANG then it is probably time to give up this discussion. ;-)

Python, quite likely a common tool for client side network management, also doesn't seem to have any support of unicode properties or blocks.  Perhaps implementations will hook it up to libxml2 instead, or write a full translation XML RE to Python RE conversion tool.  But probably most people will just feed the pattern statement into the native Python regex engine, and my guess is that this will probably work 95% of the time.  The other 5% ... who knows what will happen ... oh well, better to try and fail than to not try at all.

Apologies if this email comes across as a rant.

Rob




/js


Andy
 
--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>




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

--------------D8FBC31F519115DCFC7D3C1B-- From nobody Fri Sep 1 07:40:59 2017 Return-Path: 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 DEA1A13419C for ; Fri, 1 Sep 2017 07:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[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 Zx_IBZwqjWNt for ; Fri, 1 Sep 2017 07:40:56 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 988911330B5 for ; Fri, 1 Sep 2017 07:40:56 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 60AC4B80E23; Fri, 1 Sep 2017 07:40:56 -0700 (PDT) To: j.schoenwaelder@jacobs-university.de, bclaise@cisco.com, warren@kumari.net, kwatsen@juniper.net, lberger@labn.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: lhotka@nic.cz, netmod@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170901144056.60AC4B80E23@rfc-editor.org> Date: Fri, 1 Sep 2017 07:40:56 -0700 (PDT) Archived-At: Subject: [netmod] [Technical Errata Reported] RFC6991 (5105) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 14:40:58 -0000 The following errata report has been submitted for RFC6991, "Common YANG Data Types". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5105 -------------------------------------- Type: Technical Reported by: Ladislav Lhotka Section: 3 Original Text ------------- A schema node of this type will be set to zero (0) on creation and will thereafter increase monotonically until it reaches a maximum value of 2^32-1 (4294967295 decimal), when it wraps around and starts increasing again from zero. Corrected Text -------------- A leaf instance of this type will be set to zero (0) on creation and will thereafter increase monotonically until it reaches a maximum value of 2^32-1 (4294967295 decimal), when it wraps around and starts increasing again from zero. Notes ----- In a number of descriptions in both ietf-yang-types and ietf-inet-types, the term "schema node" is used incorrectly in places where "leaf instance" or "instance of a leaf" should be used instead. However, not all occurences of "schema node" are wrong: schema nodes just have to be distinguished from nodes in an instance data tree. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6991 (draft-ietf-netmod-rfc6021-bis-03) -------------------------------------- Title : Common YANG Data Types Publication Date : July 2013 Author(s) : J. Schoenwaelder, Ed. Category : PROPOSED STANDARD Source : NETCONF Data Modeling Language Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Fri Sep 1 09:24:09 2017 Return-Path: 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 F1FED132F6A for ; Fri, 1 Sep 2017 09:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.121 X-Spam-Level: X-Spam-Status: No, score=-0.121 tagged_above=-999 required=5 tests=[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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 6reD8FAN-9cY for ; Fri, 1 Sep 2017 09:24:06 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0107.outbound.protection.outlook.com [104.47.42.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13D0F132E51 for ; Fri, 1 Sep 2017 09:24:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lgaiiGn1OTNQFDSsnzUxFZ+hSc4HYLYTlqzfk/Oo/Oc=; b=PsfOJ6/YzmVZ9Kll0flCa9i2aD8PrESJkmixEHM0mRrRjgocx+M6SEJUlZaAdT/8SgAjOujK9RErKHj3D93nsFiqSBeX6P73ziUdl9KNS/OmVD77SvHEYkRBDSafUaeIPGbPVv+Hzyb0FmJiome59at4oIXU8E/85M6zZ44iyL8= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1547.namprd05.prod.outlook.com (10.161.161.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.2; Fri, 1 Sep 2017 16:24:04 +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.20.0013.014; Fri, 1 Sep 2017 16:24:04 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: regarding draft-bierman-netmod-yang-data-ext-00 Thread-Index: AQHTIz66ZM/zAubP+UmCwbr4E6YP3w== Date: Fri, 1 Sep 2017 16:24:04 +0000 Message-ID: <57AA997C-6E52-49D2-B6AF-7DDE8F13D7B3@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1547; 6:rWqurRrfRsY30/9hbeCR6fthF0Id1OfA/QQteZk/OmETeph8fvJltIiqozXtygVAklgJ2IX2WZyORTEU8/KTrAdOCvWvy21m00ZoRNoNbFA35Mu231StJnh0iOOWz8qc9trXWf3WrU74vkv+HxY0np78llfGHc6UnyFgQx2LPCXRvLicOARb34u/YCI+xBMTr40lngRYnAjPEE7D9DQFFMxJNCV4BOiqdi1OGX+bPtyX5NjAN7+R4VXP65szDvNrKSMig4mNxnLosuB5HxJ0qDVciXxCgD+M0FgBEVWbVBP0NmLDCfXw3mQ2cHbU+caJ4QJabz/cea7IlV8zkyDPkw==; 5:zVlB1Wls9Ms7dFrmo57DNj798vAdfDAYsW9+IUAdpfHT8dDAhQBKja64cOIxR9bvrY1SmbplkDuvzOORokyQbxFK2Ktm1bYphwqQuXvxFcDFX9zc0TqSJwiKGyYtBOhtHTnG/65jKgUCGdpLO3laIA==; 24:hYxJoGwdZ2+UniL+6dmfNXWk2SeJ6LJhMBSMjumGEpKYtI1lIr5psbSwS5bok3OPRj9U/JrOVmueXtjULnRyCLNM6RmuMuQlfGYn4bfZ3v0=; 7:9YpdjOBtF7BTZg8yArBiK03L0/OxcgRJqwZaXummdWdKzC7UxZV7KkiDlGQ3PLuNBXeteo3P8x49rdmM+wdtKAOvLDrRd6Tvcb+ePs9MU3g597uDcMvv4virWFQiA1oQwzy7gjy2MIuaawPLrGNENW7rYHlFSdeuR+UgqamcCEO8j8DxnxXoW+j9IQfEwAjlHAzGV04DMXxgF7ehouFxaur0Ykng+OGKNj5jGgVRZ5Q= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 753ae5ba-3dc3-4f2b-6de8-08d4f155dcf0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR0501MB1547; x-ms-traffictypediagnostic: CY1PR0501MB1547: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR0501MB1547; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR0501MB1547; x-forefront-prvs: 0417A3FFD2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(54094003)(189002)(199003)(230783001)(110136004)(14454004)(6512007)(99286003)(5640700003)(50986999)(2900100001)(54356999)(101416001)(97736004)(86362001)(82746002)(4001350100001)(2501003)(83716003)(36756003)(53936002)(5660300001)(6486002)(6506006)(6436002)(68736007)(77096006)(83506001)(305945005)(7736002)(3660700001)(33656002)(2351001)(66066001)(189998001)(81166006)(81156014)(8936002)(6916009)(8676002)(3846002)(25786009)(1730700003)(102836003)(2906002)(6116002)(105586002)(3280700002)(106356001)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1547; 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: <678AA1086CC4DA419E47FFD17B313367@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2017 16:24:04.5934 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1547 Archived-At: Subject: [netmod] regarding draft-bierman-netmod-yang-data-ext-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 16:24:08 -0000 DQpJJ2QgbGlrZSB0byBzdGFydCBhIGRpc2N1c3Npb24gYWJvdXQgYWRvcHRpbmcgdGhpcyBkcmFm dC4uLm9yIHNvbWV0aGluZyBsaWtlIGl0IChzZWUgYmVsb3cpLg0KDQpUaGUgcHJpbWFyeSBkcml2 ZXIgZm9yIHdhbnRpbmcgdG8gZXhwZWRpdGUgdGhpcyBkcmFmdCBpcyB0aGF0IGl0IGlzIGJlaW5n IGRpc2N1c3NlZCBhcyBhIHJlcXVpcmVkIGFzcGVjdCBvZiBhIGNoYXJ0ZXJlZCBORVRDT05GIFdH IGVmZm9ydCB0byBkZWZpbmUgYSBuZXcgZW5jb2RpbmcgZm9yIFlBTkcncyAnbm90aWZpY2F0aW9u JyBzdGF0ZW1lbnQuDQoNCkJ1dCBJIHdvbmRlciBpZiBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gZGVm aW5lIHNvbWV0aGluZyBsaWtlIHlkOnVzZXMteWFuZy1kYXRhIHRoYXQgY2FuIGhhdmUgYm90aCAn YXVnbWVudCcgYW5kICdyZWZpbmUnIGFzIHN1YnN0YXRlbWVudHMuICBUaGUgbW90aXZhdGlvbiBm b3IgdGhpcyBpcyBiZWNhdXNlIHRoZSBBTklNQSBXRyB3aXNoZXMgdG8gZGVmaW5lIGEgInZvdWNo ZXItcmVxdWVzdCIgeWFuZy1kYXRhIGFydGlmYWN0IHRoYXQgaXMgZXNzZW50aWFsbHkgYSAidm91 Y2hlciIgeWFuZy1kYXRhIGFydGlmYWN0IHRoYXQgaGFzIGhhZCBhIGxlYWYgY2hhbmdlZCBmcm9t ICJtYW5kYXRvcnkgdHJ1ZSIgdG8gIm1hbmRhdG9yeSBmYWxzZSIgKHZpYSByZWZpbmVtZW50KSB3 aGlsZSBhbHNvIGFkZGluZyBzb21lIG5ldyBmaWVsZHMgKHZpYSBhdWdtZW50YXRpb24pLiAgVGhl IGN1cnJlbnQgQU5JTUEgc29sdXRpb24gZGVmaW5lcyBhIGNvbW1vbiBncm91cGluZyB1c2VkIGJ5 IHR3byB5YW5nLWRhdGEgc3RhdGVtZW50cywgYnV0IHRoaXMgYXBwcm9hY2ggaXMgbmVpdGhlciBp bnR1aXRpdmUgbm9yIGxlbmRzIGl0c2VsZiB0byBmdXJ0aGVyIGRvd25zdHJlYW0gY29uc3VtcHRp b24uDQoNCkxhc3RseSwgSSB3b25kZXIgaWYgaXQgd291bGQgYmUgYmV0dGVyIHRvIGhhdmUgYSBk cmFmdCB0aGF0IFtyZS1dZGVmaW5lcyBhICd5YW5nLWRhdGEnIHN0YXRlbWVudCBvdXRzaWRlIG9m IFJGQzgwNDAuICBUaGlzIHdheSBkcmFmdHMgd2FudGluZyB0byBkZWZpbmUgeWFuZy1kYXRhIHdv dWxkbid0IGhhdmUgdG8gZXhwbGFpbiB3aHkgdGhleSBoYXZlIGFuIG90aGVyd2lzZSB1bmV4cGVj dGVkIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gUkVTVENPTkYuDQoNClRob3VnaHRzPw0KDQpLZW50 IC8vIHBpY2sgYSBoYXQNCg0KDQoNCg0K From nobody Fri Sep 1 09:34:11 2017 Return-Path: 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 9FF891330AE for ; Fri, 1 Sep 2017 09:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.6 X-Spam-Level: X-Spam-Status: No, score=-12.6 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 N9YdkeIKKPfD for ; Fri, 1 Sep 2017 09:34:07 -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 3C59E132113 for ; Fri, 1 Sep 2017 09:34:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6135; q=dns/txt; s=iport; t=1504283647; x=1505493247; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=bj03oEFmeBXYu6fns7OULXTf/bm9sX8uUZcOGMwwV7A=; b=kRVN0n0Eit6/HuBXx17K/z4Fm6PGm+pzqax0ByzyZZWow2YTFALxfugF pZi7QkeQGEOx1DFl2KCFEpdB8czPyEgH1Biq3pwJvmcwXHToUAh5rACyv YmzPy1PZz8fVgDhBzyqgRN4CvRkRdzu/6DKMEL9CEoT9glXCV3eDTfLlx s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BuAQDwiqlZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy2BEYEVjwuRGpBphT+CEiEBCoRMTwKEVRcBAgEBAQEBAQFrKIU?= =?us-ascii?q?ZAQEBAwEBbAkSCw4KLicwBgEMBgIBAYotELEyJ4srAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBGAWDKoNQgWMrgn2KaQWgc5RRghOJQIcdiXmDWoh0IAE2gQ0yIQgcFUm?= =?us-ascii?q?FGBwZgU8/Nop/AQEB?= X-IronPort-AV: E=Sophos;i="5.41,459,1498521600"; d="scan'208,217";a="657175621" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Sep 2017 16:34:02 +0000 Received: from [10.63.23.169] (dhcp-ensft1-uk-vla370-10-63-23-169.cisco.com [10.63.23.169]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v81GY2Qt005797; Fri, 1 Sep 2017 16:34:02 GMT To: Martin Bjorklund , netmod@ietf.org References: <20170821.140610.1599460825983098893.mbj@tail-f.com> From: Robert Wilton Message-ID: Date: Fri, 1 Sep 2017 17:34:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170821.140610.1599460825983098893.mbj@tail-f.com> Content-Type: multipart/alternative; boundary="------------9CAB2239288BAE497748B03C" Content-Language: en-US Archived-At: Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-rfc7277bis-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 16:34:10 -0000 This is a multi-part message in MIME format. --------------9CAB2239288BAE497748B03C Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Martin, I have reviewed this document (mainly as a diff against the 7277). In summary, the transformation to NMDA looks good.   Given that it is a fairly formulaic conversion, I hope that the WG will be able to quickly move to WG adoption, and even WG last call! I did have a few minor comments (and spotted one bug): 1. leaf "origin" under IPv4 neighbors should be marked as "config false". 2. Sometimes the YANG module description refers to "the intended configuration datastore" or "the operational state datastore", but I think that it would be better to just refer to "intended configuration" and "operational state".  I.e. I think that it is OK for the draft to reference the different datastores, but I think that it might be better if the YANG modules don't.  This is partly in the sense that the YANG modules are just schema for configuration and state data, and that I see the use of datastores is effectively an IETF decision on how that configuration/state is instantiated. To take the analogy further, I think that the it is conceivable that the source OpenConfig YANG models could also be usefully structured in the same NMDA style.  This would allow the OpenConfig models to work better with NETCONF/RESTCONF implementations that support NMDA.  An alternative implementation choice would be to use a script to convert NMDA style OpenConfig YANG models to equivalent existing OpenConfig style with their split config/state containers. A second justification (if you don't like the one above), is that the configurable leaves could also be set via a dynamic configuration datastore such as via I2RS, hence it wouldn't necessarily always be via the intended datastore. 3. I think that it might be useful to add a comment to the IPv6 link-layer-address leaf description to indicate that it wouldn't expect to be populated if the associated "state" is set to "incomplete". Thanks, Rob On 21/08/2017 13:06, Martin Bjorklund wrote: > Hi, > > This document defines an NMDA-compliant update to the IP model > (RFC 7277). > > I would like to ask the WG to adopt this individual draft as a working > group document. > > > /martin > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------9CAB2239288BAE497748B03C Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Martin,

I have reviewed this document (mainly as a diff against the 7277).

In summary, the transformation to NMDA looks good.   Given that it is a fairly formulaic conversion, I hope that the WG will be able to quickly move to WG adoption, and even WG last call!


I did have a few minor comments (and spotted one bug):

1. leaf "origin" under IPv4 neighbors should be marked as "config false".


2. Sometimes the YANG module description refers to "the intended configuration datastore" or "the operational state datastore", but I think that it would be better to just refer to "intended configuration" and "operational state".  I.e. I think that it is OK for the draft to reference the different datastores, but I think that it might be better if the YANG modules don't.  This is partly in the sense that the YANG modules are just schema for configuration and state data, and that I see the use of datastores is effectively an IETF decision on how that configuration/state is instantiated.

To take the analogy further, I think that the it is conceivable that the source OpenConfig YANG models could also be usefully structured in the same NMDA style.  This would allow the OpenConfig models to work better with NETCONF/RESTCONF implementations that support NMDA.  An alternative implementation choice would be to use a script to convert NMDA style OpenConfig YANG models to equivalent existing OpenConfig style with their split config/state containers.

A second justification (if you don't like the one above), is that the configurable leaves could also be set via a dynamic configuration datastore such as via I2RS, hence it wouldn't necessarily always be via the intended datastore.


3. I think that it might be useful to add a comment to the IPv6 link-layer-address leaf description to indicate that it wouldn't expect to be populated if the associated "state" is set to "incomplete".


Thanks,
Rob


On 21/08/2017 13:06, Martin Bjorklund wrote:
Hi,

This document defines an NMDA-compliant update to the IP model
(RFC 7277).

I would like to ask the WG to adopt this individual draft as a working
group document.


/martin




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

--------------9CAB2239288BAE497748B03C-- From nobody Fri Sep 1 09:39:50 2017 Return-Path: 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 501101341ED for ; Fri, 1 Sep 2017 09:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[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 l_ioV4G0xRsk for ; Fri, 1 Sep 2017 09:39:46 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 231801341E0 for ; Fri, 1 Sep 2017 09:39:46 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id u26so4660861wma.0 for ; Fri, 01 Sep 2017 09:39:46 -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=XQ3xG7zvZgrV0erG1pzvh9ofmoTZD66NO39jeNNA3W4=; b=SR3qAeKY/CdJJnubiREYRE0ypXm5c8lzn8iCz34nWX9lePcErQUfe3LAyT26kfspag 949CC2SRYACEacc+BGAZ2teDVsdRYO0ZH0MHO63P0z0BHfPOC4Ehf7sqfGH0nPUtPsMX Vs9eKX1XjCafGaAuYSdUSjxkAi7uWUZKn7oI7OmbnhmwraKByZlehBIUJh0N5iLrZuSd 2v6lHY7iysxEO48qEWTQGHEi2REmm8SOR1wiQhi+lM64wgnlrTfa5vK2YvNh6aCVW32L QXoTKgr+cKzgyNGYxHIbREYlWRFIjfYQG9eANjMkV7Rr8LiL1x7wMp6Fs597X3Ip60J9 fvdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XQ3xG7zvZgrV0erG1pzvh9ofmoTZD66NO39jeNNA3W4=; b=qd9eaF8fKBfgeBxlv4pCM9jJ6flyOrzYtANHeXb4ku/Y4+MpwtoLl7xgjxm7gNqpH/ Aj8kb23ZoVdW43x6W9bAqHMRdgLStfUn1cenm7MDWCBHGsKdsniSlRoP1gxGK9H8BWe0 gGLpldFrN0yLcgSANUP3Rh84agjydZR9iOQfsw6gSdRRmEPqDN9sltEs0fxArlMyg4BI uyqmbrhSYeQbTtLslteONCzpGhV5jmPPNhX6gwlhjTi7IS5Lr9En+DQSlm6/qvA/8dnG BbiIGb5aRn3CEld2xV55bXyl3rsa1S9cajv7h1pZOLMrWy2PgBsfZioZB3ZP8mNvLKNp S7lw== X-Gm-Message-State: AHPjjUj6rqSdv6dv18r6Djx12qpw9aN2Hs+4ttjx6//ZptE9UW2v/VL2 RrCMwMzhIwgppnfaJ5PL++uFJLdGSPSQet8= X-Google-Smtp-Source: ADKCNb644NtD/mxhCwYcuHzsCsP6lh+IjSW8kDPNGRX0TqVylaJ9abU0RjznnQoQo+jXhcoDN8LfnXZYU+zOOaEuIpk= X-Received: by 10.28.147.8 with SMTP id v8mr785959wmd.153.1504283984644; Fri, 01 Sep 2017 09:39:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.171.84 with HTTP; Fri, 1 Sep 2017 09:39:43 -0700 (PDT) In-Reply-To: <57AA997C-6E52-49D2-B6AF-7DDE8F13D7B3@juniper.net> References: <57AA997C-6E52-49D2-B6AF-7DDE8F13D7B3@juniper.net> From: Andy Bierman Date: Fri, 1 Sep 2017 09:39:43 -0700 Message-ID: To: Kent Watsen Cc: "netmod@ietf.org" Content-Type: multipart/alternative; boundary="001a114733ac8be2e50558236878" Archived-At: Subject: Re: [netmod] regarding draft-bierman-netmod-yang-data-ext-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 16:39:48 -0000 --001a114733ac8be2e50558236878 Content-Type: text/plain; charset="UTF-8" On Fri, Sep 1, 2017 at 9:24 AM, Kent Watsen wrote: > > I'd like to start a discussion about adopting this draft...or something > like it (see below). > > The primary driver for wanting to expedite this draft is that it is being > discussed as a required aspect of a chartered NETCONF WG effort to define a > new encoding for YANG's 'notification' statement. > > But I wonder if it would be better to define something like > yd:uses-yang-data that can have both 'augment' and 'refine' as > substatements. The motivation for this is because the ANIMA WG wishes to > define a "voucher-request" yang-data artifact that is essentially a > "voucher" yang-data artifact that has had a leaf changed from "mandatory > true" to "mandatory false" (via refinement) while also adding some new > fields (via augmentation). The current ANIMA solution defines a common > grouping used by two yang-data statements, but this approach is neither > intuitive nor lends itself to further downstream consumption. > > I am not sure any new construct is needed at all. The current definition covers it. module foo { grouping plain-old-group1 { ... } rc:yang-data artifact1 { uses plain-old-group1; } } module bar { import foo { ... } rc:yang-data artifact2 { uses foo:plain-old-group1 { refine ... } } } Lastly, I wonder if it would be better to have a draft that [re-]defines a > 'yang-data' statement outside of RFC8040. This way drafts wanting to > define yang-data wouldn't have to explain why they have an otherwise > unexpected normative reference to RESTCONF. > > We went through that issue at least twice before RFC 8040. There was no concern about this extension being in the RESTCONF spec. We really have to try to keep the documents stable, and not republish an RFC just to move definitions around. Thoughts? > > Kent // pick a hat > > > Andy > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a114733ac8be2e50558236878 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Sep 1, 2017 at 9:24 AM, Kent Watsen <kwatsen@juniper.net= > wrote:
I'd like to start a discussion about adopting this draft...or something= like it (see below).

The primary driver for wanting to expedite this draft is that it is being d= iscussed as a required aspect of a chartered NETCONF WG effort to define a = new encoding for YANG's 'notification' statement.

But I wonder if it would be better to define something like yd:uses-yang-da= ta that can have both 'augment' and 'refine' as substatemen= ts.=C2=A0 The motivation for this is because the ANIMA WG wishes to define = a "voucher-request" yang-data artifact that is essentially a &quo= t;voucher" yang-data artifact that has had a leaf changed from "m= andatory true" to "mandatory false" (via refinement) while a= lso adding some new fields (via augmentation).=C2=A0 The current ANIMA solu= tion defines a common grouping used by two yang-data statements, but this a= pproach is neither intuitive nor lends itself to further downstream consump= tion.


I am not sure any new construct is nee= ded at all.
The current definition covers it.

module foo {
=C2=A0 grouping plain-old-group1 {
= =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 }

=C2=A0= rc:yang-data artifact1 {
=C2=A0 =C2=A0 =C2=A0uses plain-old-grou= p1;
=C2=A0 }
}


= module bar {
=C2=A0 =C2=A0import foo { ... }

=
=C2=A0 =C2=A0 =C2=A0rc:yang-data artifact2 {
=C2=A0 =C2=A0 = =C2=A0 =C2=A0uses foo:plain-old-group1 {
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 refine ...
=C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2= =A0 =C2=A0 =C2=A0}
=C2=A0 }


Lastly, I wonder if it would be better to have a draft that [re-]defines a = 'yang-data' statement outside of RFC8040.=C2=A0 This way drafts wan= ting to define yang-data wouldn't have to explain why they have an othe= rwise unexpected normative reference to RESTCONF.


We went through that issue at least tw= ice before RFC 8040.
There was no concern about this extension be= ing in the RESTCONF spec.
We really have to try to keep the docum= ents stable, and not republish an RFC just to move
definitions ar= ound.


Thoughts?

Kent // pick a hat



Andy
=C2=A0


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

--001a114733ac8be2e50558236878-- From nobody Fri Sep 1 09:48:56 2017 Return-Path: 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 902FE132D9C for ; Fri, 1 Sep 2017 09:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 gbEkMTn0QoTE for ; Fri, 1 Sep 2017 09:48:46 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2114134280 for ; Fri, 1 Sep 2017 09:48:45 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id CE2A6F14; Fri, 1 Sep 2017 18:48:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id j6ZbsSRaPe0u; Fri, 1 Sep 2017 18:48:40 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 1 Sep 2017 18:48:43 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 91B51200FA; Fri, 1 Sep 2017 18:48:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Q-4BPvbK0eNz; Fri, 1 Sep 2017 18:48:43 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C75D9200F6; Fri, 1 Sep 2017 18:48:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 924BA407A171; Fri, 1 Sep 2017 18:48:41 +0200 (CEST) Date: Fri, 1 Sep 2017 18:48:41 +0200 From: Juergen Schoenwaelder To: RFC Errata System Cc: bclaise@cisco.com, warren@kumari.net, kwatsen@juniper.net, lberger@labn.net, lhotka@nic.cz, netmod@ietf.org Message-ID: <20170901164841.ebs2fqvf2vl3adlx@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: RFC Errata System , bclaise@cisco.com, warren@kumari.net, kwatsen@juniper.net, lberger@labn.net, lhotka@nic.cz, netmod@ietf.org References: <20170901144056.60AC4B80E23@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170901144056.60AC4B80E23@rfc-editor.org> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [netmod] [Technical Errata Reported] RFC6991 (5105) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 16:48:48 -0000 On Fri, Sep 01, 2017 at 07:40:56AM -0700, RFC Errata System wrote: > The following errata report has been submitted for RFC6991, > "Common YANG Data Types". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5105 > > -------------------------------------- > Type: Technical > Reported by: Ladislav Lhotka > > Section: 3 > > Original Text > ------------- > A schema node of this type will be set to zero (0) on creation > and will thereafter increase monotonically until it reaches > a maximum value of 2^32-1 (4294967295 decimal), when it > wraps around and starts increasing again from zero. > > Corrected Text > -------------- > A leaf instance of this type will be set to zero (0) on creation > and will thereafter increase monotonically until it reaches > a maximum value of 2^32-1 (4294967295 decimal), when it > wraps around and starts increasing again from zero. > > Notes > ----- > In a number of descriptions in both ietf-yang-types and ietf-inet-types, the term "schema node" is used incorrectly in places where "leaf instance" or "instance of a leaf" should be used instead. However, not all occurences of "schema node" are wrong: schema nodes just have to be distinguished from nodes in an instance data tree. > Yes. I would probably prefer 'a data node instance of this type' instead of 'a leaf instance' - I am not sure I would to exclude a leaf-list and who knows whether we have any other data nodes in the future. And yes, all occurances of 'schema node' need careful inspection. I am not sure whether you want to identify all occurances now or whether you wanted to have a generic errata just so that we do not forget to fix this when this document is revised. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Sep 1 10:43:17 2017 Return-Path: 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 7FAF4132E31 for ; Fri, 1 Sep 2017 10:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.12 X-Spam-Level: X-Spam-Status: No, score=-0.12 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 1-r_SK0rN1fT for ; Fri, 1 Sep 2017 10:43:13 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0098.outbound.protection.outlook.com [104.47.37.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 810061330C2 for ; Fri, 1 Sep 2017 10:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MaEFMgUk5XeDTRReE5hXjqEdWXLaLMVAn0STFAMhMYk=; b=Y37K6yWpz5upIDU54HIuVkZqcpfgWO7X3zPN7mpzxWeajw/vVkE209iB6frzP6VzeqlFZwfUJqTaqCO6mmJizlNK7yxsu+Pe4HPf6AeVRFryx9dFdp/N9NxQvyAp5x1tgC97MGv8Eg33DeNYrg89N5ibPdhV2eqcYNMBgcIgz54= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1625.namprd05.prod.outlook.com (10.161.165.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.2; Fri, 1 Sep 2017 17:43:11 +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.20.0013.014; Fri, 1 Sep 2017 17:43:11 +0000 From: Kent Watsen To: Andy Bierman CC: "netmod@ietf.org" Thread-Topic: [netmod] regarding draft-bierman-netmod-yang-data-ext-00 Thread-Index: AQHTIz66ZM/zAubP+UmCwbr4E6YP36KgO1WA///OrQA= Date: Fri, 1 Sep 2017 17:43:11 +0000 Message-ID: <56D58AA8-E71E-4CA1-B81E-70E2EDD94E91@juniper.net> References: <57AA997C-6E52-49D2-B6AF-7DDE8F13D7B3@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.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1625; 6:ySDDUrJL482heNuCTVS6NORHqdKT00O7aSnSZL2ZaGMNUKwufrp9i3KvmSTwxXMzaPAFD68XEhpnKFVB02dyexlkt7L2hHvK0gn3Mg//o2xvyxrCylvXPR9Vcr/+DNrryNxF24Z2fiOQUEbkJsQwQwFW9gEMGEVjXPrnSfUee5L1hBPOydP1dSxOc99zro7l2dX1TwjiD9ki4rKiizT/BrWE9nuF2Sv6zOmySK7ZEY14/Qdq547Ek/eS38rCWZ3ZWokgaAL3qPedjGehUkcQ1Abl4w9GZIhM+bg5qEcSpWPwSC8KulijW/W9+qt5KpM/0HX/92x7f6l7ycTws1CGxQ==; 5:pvWLBAV8GoAP2OKVB+Q38x9WejU86Sr0jUMl5rrGrjOxj+fdEgjBmlkpeExyyjf4oLb6fzo87eEllaA63BZglNHzwYwww/Z/yPRF3n/aTH2eY/1bpGbZXDc+2jN1iehFfkz2R0f/GcaFdHXX86XsKw==; 24:6cnUrkVQswm4DR0ECeYgbSY2Y4+Nfhr96kPxL/wnPRq6ZLywXoB8yZiCm8U3yDcxccwlwa2nXYcTwb/KDKO4nYQJtWAWGrD6F34FpnEBLUM=; 7:2eKmsVHOWl4n4Nygd963Ak4nyUQ3w1HOfbeaumYwF6Q9a2cYQMGwUkvlmUQpfCZ83+Us/4boxuD651QG0sT0ZWB6Zk6qrEVkjSa9hpOhXI7vKAlh0G0DF0s/9Uww/zNjA+cfHdtA7txIlpUV7E+R1yG9eMeRUWriY9D58CDO3AYow3he2uh8UYcuTg/Q7DdYMjb3znp//JpkC3c31lReRenpJhQvvSelM/T58ai1K0Y= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 6c97edcf-0573-4492-89c4-08d4f160ea29 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR0501MB1625; x-ms-traffictypediagnostic: CY1PR0501MB1625: x-exchange-antispam-report-test: UriScan:(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123560025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR0501MB1625; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR0501MB1625; x-forefront-prvs: 0417A3FFD2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(189002)(199003)(25786009)(36756003)(229853002)(86362001)(6916009)(2950100002)(97736004)(6486002)(105586002)(33656002)(106356001)(6436002)(5660300001)(4326008)(77096006)(6246003)(2900100001)(6506006)(99286003)(83506001)(68736007)(110136004)(50986999)(81166006)(3280700002)(53936002)(6512007)(3660700001)(478600001)(54356999)(76176999)(81156014)(54896002)(6306002)(66066001)(8676002)(2906002)(6116002)(102836003)(230783001)(101416001)(83716003)(3846002)(82746002)(8936002)(14454004)(189998001)(4001350100001)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1625; 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_56D58AA8E71E4CA1B81E70E2EDD94E91junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2017 17:43:11.2733 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1625 Archived-At: Subject: Re: [netmod] regarding draft-bierman-netmod-yang-data-ext-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 17:43:16 -0000 --_000_56D58AA8E71E4CA1B81E70E2EDD94E91junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCj4gSSBhbSBub3Qgc3VyZSBhbnkgbmV3IGNvbnN0cnVjdCBpcyBuZWVkZWQgYXQgYWxsLg0K PiBUaGUgY3VycmVudCBkZWZpbml0aW9uIGNvdmVycyBpdC4NCjxzbmlwLz4NCg0KUmlnaHQsIHRo aXMgaXMgd2hhdCBpcyBjdXJyZW50bHkgYmVpbmcgZG9uZSwgYnV0IGl0IGlzIG5laXRoZXIgaW50 dWl0aXZlIG5vciBjb25kdWNpdmUgdG8gZG93bnN0cmVhbSBleHRlbnNpb25z4oCmDQoNCg0KPiBX ZSB3ZW50IHRocm91Z2ggdGhhdCBpc3N1ZSBhdCBsZWFzdCB0d2ljZSBiZWZvcmUgUkZDIDgwNDAu DQo+IFRoZXJlIHdhcyBubyBjb25jZXJuIGFib3V0IHRoaXMgZXh0ZW5zaW9uIGJlaW5nIGluIHRo ZSBSRVNUQ09ORiBzcGVjLg0KDQpJIGRvbid0IHRoaW5rIHBlb3BsZSB1bmRlcnN0b29kIHdoYXQg d2FzIGF0IHN0YWtlIGF0IHRoZSB0aW1lIC0geWFuZy1kYXRhIGhhcyBzaW5jZSB0YWtlbiBvbiBt b3JlIHByb21pbmVuY2UuICAgIFlvdSB3cml0ZSAibm8gY29uY2VybiIsIGJ1dCBJIHRoaW5rIGl0 IHdhcyBtb3JlIGxpa2UgIm5vIHJlc3BvbnNlIiwgYW5kIHRoZSBzb2x1dGlvbiBqdXN0IHJvbGxl ZCBvbi4NCg0KDQo+IFdlIHJlYWxseSBoYXZlIHRvIHRyeSB0byBrZWVwIHRoZSBkb2N1bWVudHMg c3RhYmxlLCBhbmQgbm90IHJlcHVibGlzaCBhbiBSRkMNCj4ganVzdCB0byBtb3ZlIGRlZmluaXRp b25zIGFyb3VuZC4NCg0KV2UgYXJlIHRhbGtpbmcgYWJvdXQgYSBuZXcgUkZDICh0aGlzIGRyYWZ0 KS4gIEkgZG9uJ3QgY2FyZSBpZiA4MDQwIGV2ZXIgdXNlcyB0aGUgbmV3IHlhbmctZGF0YSBzdGF0 ZW1lbnQsIGl0IGNhbiBmb3JldmVyIGhhdmUgaXRzIG93biBwcml2YXRlIGRlZmluaXRpb24uICBJ IGRvIGNhcmUgdGhhdCB3ZSBpbnRyb2R1Y2UgYSBsb25nLXRlcm0gc29sdXRpb24gKGFnYWluLCBh dWdtZW50IGFsb25lIHNlZW1zIGxpbWl0ZWQpIGFuZCB3b3VsZCBsaWtlIHRvIG1ha2UgYW4gaW5j cmVtZW50YWwgaW1wcm92ZW1lbnQgZm9yIG5vcm1hdGl2ZSByZWZlcmVuY2VzLg0KDQoNCksuICAv LyBjb250cmlidXRvcg0KDQoNCg== --_000_56D58AA8E71E4CA1B81E70E2EDD94E91junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <1F9769189EA6024BA989A5CFBBB78EB9@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 b250LWZhbWlseTpDYWxpYnJpOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCglj b2xvcjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9u Om5vbmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLm1zb0lucw0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZndDsgSSBhbSBub3Qgc3VyZSBhbnkgbmV3IGNvbnN0cnVjdCBpcyBu ZWVkZWQgYXQgYWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jmd0OyBUaGUgY3VycmVudCBkZWZpbml0aW9uIGNvdmVycyBpdC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDtzbmlwLyZndDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmlnaHQsIHRoaXMgaXMgd2hhdCBpcyBjdXJyZW50bHkg YmVpbmcgZG9uZSwgYnV0IGl0IGlzIG5laXRoZXIgaW50dWl0aXZlIG5vciBjb25kdWNpdmUgdG8g ZG93bnN0cmVhbSBleHRlbnNpb25z4oCmPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jmd0OyBXZSB3ZW50IHRocm91Z2ggdGhhdCBpc3N1ZSBhdCBsZWFzdCB0d2ljZSBi ZWZvcmUgUkZDIDgwNDAuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mZ3Q7IFRoZXJlIHdhcyBubyBjb25jZXJuIGFib3V0IHRoaXMgZXh0ZW5zaW9u IGJlaW5nIGluIHRoZSBSRVNUQ09ORiBzcGVjLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRv bid0IHRoaW5rIHBlb3BsZSB1bmRlcnN0b29kIHdoYXQgd2FzIGF0IHN0YWtlIGF0IHRoZSB0aW1l IC0geWFuZy1kYXRhIGhhcyBzaW5jZSB0YWtlbiBvbiBtb3JlIHByb21pbmVuY2UuJm5ic3A7ICZu YnNwOyZuYnNwO1lvdSB3cml0ZSAmcXVvdDtubyBjb25jZXJuJnF1b3Q7LCBidXQgSSB0aGluayBp dCB3YXMgbW9yZSBsaWtlICZxdW90O25vIHJlc3BvbnNlJnF1b3Q7LCBhbmQgdGhlIHNvbHV0aW9u IGp1c3Qgcm9sbGVkIG9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgV2UgcmVhbGx5 IGhhdmUgdG8gdHJ5IHRvIGtlZXAgdGhlIGRvY3VtZW50cyBzdGFibGUsIGFuZCBub3QgcmVwdWJs aXNoIGFuIFJGQzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBqdXN0 IHRvIG1vdmUgZGVmaW5pdGlvbnMgYXJvdW5kLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5XZSBhcmUgdGFsa2luZyBhYm91dCBhIG5ldyBSRkMgKHRoaXMgZHJhZnQpLiZu YnNwOyBJIGRvbid0IGNhcmUgaWYgODA0MCBldmVyIHVzZXMgdGhlIG5ldyB5YW5nLWRhdGEgc3Rh dGVtZW50LCBpdCBjYW4gZm9yZXZlciBoYXZlIGl0cyBvd24gcHJpdmF0ZSBkZWZpbml0aW9uLiZu YnNwOyBJIGRvIGNhcmUgdGhhdCB3ZSBpbnRyb2R1Y2UgYSBsb25nLXRlcm0gc29sdXRpb24gKGFn YWluLCBhdWdtZW50IGFsb25lIHNlZW1zIGxpbWl0ZWQpDQogYW5kIHdvdWxkIGxpa2UgdG8gbWFr ZSBhbiBpbmNyZW1lbnRhbCBpbXByb3ZlbWVudCBmb3Igbm9ybWF0aXZlIHJlZmVyZW5jZXMuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPksuJm5ic3A7IC8vIGNvbnRyaWJ1dG9yPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_56D58AA8E71E4CA1B81E70E2EDD94E91junipernet_-- From nobody Fri Sep 1 10:58:17 2017 Return-Path: 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 E8C9B1320DC for ; Fri, 1 Sep 2017 10:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[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 UNwyKskKpQgR for ; Fri, 1 Sep 2017 10:58:14 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33ACC134434 for ; Fri, 1 Sep 2017 10:58:14 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id v2so5889679wmf.0 for ; Fri, 01 Sep 2017 10:58:14 -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=BPj2faM7+tNuaJqx1O1aVKB9MUWLeZpqlotDRSsDSwM=; b=1vxHpdDeNhezOMSWjvnwJAWo4/FuJk9LZ22aRgybn+bf3MLcX3kNe9Jo4AT0cH8RWH vPctJDKk2gER9qAa+PC7bxfCPY4ytbU5GYQIgN2LFm4vivlUNi2t70HeURt/Vopew+db ojFHT+E3k+cfaL5+fwD10kx2c5azGx0zZpUHzNIIGzmME6Js4G9AAzhZnPf72wD/4Ys/ hNKB0ky4foitgvxeGvO/jRpOeerDEZDoh/6QwFycBG2qs2VGao4gZUX93aFJn7kIMcRY sB8pGt73p8NYHCUx2C4ImFh52uWhEL1PrCaMkuGNAEzEJ6Ni8nQAn95FoXG18Z6LG6p7 EQyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BPj2faM7+tNuaJqx1O1aVKB9MUWLeZpqlotDRSsDSwM=; b=jhsbksQgYs9vJ6tHY8XwO36qeAuI8sJD4RJQt7Q8mI4BZHixycphAXXdXys54J8yf9 ZGXIjiaJXoCzYoxQrc6vZNNJN0X2ZBSRL1+0nkiV2nanL20Rs/UpCCF4SfoG5pgo6T6b 2wz74kZT6fevWmcCsJiecYVL6dehUtxBOp6GaAE074rGFRtzKtGop23oO8WwpIPHQFaF ww3IL6g3sT+Q3FfQaJ/v0xWznfDkk945f/6KYuf+EU10Hz9i0U/uG4Xdt7WGutlIoJuc QePnCsMFOOleKrLQb1gaS6sIGstNex0bMO5ds/UOftJ+EPkXZ7OLOWQmHpLKTgolGtoQ ITFQ== X-Gm-Message-State: AHPjjUjdwVYay+oqGyUHv7UUru85B5gwCTCqyqQKOd+KWeWmg5mrXfcs OYDzmrytpxX6o0nsOdBONYBnKUGvG3HQ X-Google-Smtp-Source: ADKCNb7Db0Z7Vxbf3VEQab1qLirAULpewy+HDW5P71LE5L1JSkO+Oxkfv40Zb0QtKh1d+j0Yn6M5LK3xZieuwSXIGfo= X-Received: by 10.28.156.198 with SMTP id f189mr901155wme.28.1504288692643; Fri, 01 Sep 2017 10:58:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.171.84 with HTTP; Fri, 1 Sep 2017 10:58:11 -0700 (PDT) In-Reply-To: <56D58AA8-E71E-4CA1-B81E-70E2EDD94E91@juniper.net> References: <57AA997C-6E52-49D2-B6AF-7DDE8F13D7B3@juniper.net> <56D58AA8-E71E-4CA1-B81E-70E2EDD94E91@juniper.net> From: Andy Bierman Date: Fri, 1 Sep 2017 10:58:11 -0700 Message-ID: To: Kent Watsen Cc: "netmod@ietf.org" Content-Type: multipart/alternative; boundary="001a114b2e582a69c2055824816d" Archived-At: Subject: Re: [netmod] regarding draft-bierman-netmod-yang-data-ext-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 17:58:16 -0000 --001a114b2e582a69c2055824816d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Sep 1, 2017 at 10:43 AM, Kent Watsen wrote: > > > > > > I am not sure any new construct is needed at all. > > > The current definition covers it. > > > > > > Right, this is what is currently being done, but it is neither intuitive > nor conducive to downstream extensions=E2=80=A6 > > > I agree with Martin that we do not need to replicate plain YANG in extensions. We want to avoid new extensions, especially if a regular YANG statement with work. > > > > We went through that issue at least twice before RFC 8040. > > > There was no concern about this extension being in the RESTCONF spec. > > > > I don't think people understood what was at stake at the time - yang-data > has since taken on more prominence. You write "no concern", but I thin= k > it was more like "no response", and the solution just rolled on. > I think I explained it well enough at the time. There is a normative reference to RESTCONF to use yang-data. This is just an RFC detail. In a server, the yang-library can indicate that ietf-restconf is just imported (not implemented). It really does not matter that this extension is in ietf-restconf.yang. > > > > > > We really have to try to keep the documents stable, and not republish a= n > RFC > > > just to move definitions around. > > > > We are talking about a new RFC (this draft). I don't care if 8040 ever > uses the new yang-data statement, it can forever have its own private > definition. I do care that we introduce a long-term solution (again, > augment alone seems limited) and would like to make an incremental > improvement for normative references. > > > IMO it is not worth the trouble. There are NMDA drafts to work on instead. > > > K. // contributor > > > > > Andy --001a114b2e582a69c2055824816d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Sep 1, 2017 at 10:43 AM, Kent Watsen <kwatsen@juniper.net> wrote:

=C2=A0=

=C2=A0

> I am not sure any new construct is needed at al= l.

> The current definition covers it.=

<snip/>

=C2=A0

Right, this is what is currently being done, but it = is neither intuitive nor conducive to downstream extensions=E2=80=A6=

=C2=A0


I agree with Martin that we do not need t= o replicate plain YANG in extensions.
We want to avoid new extens= ions, especially if a regular YANG statement with work.

=C2=A0

=C2=A0

> We went through that issue at least twice befor= e RFC 8040.

> There was no concern about this extension being= in the RESTCONF spec.

=C2=A0

I don't think people understood what was at stak= e at the time - yang-data has since taken on more prominence.=C2=A0 =C2=A0= =C2=A0You write "no concern", but I think it was more like "= no response", and the solution just rolled on.


I think I explained it wel= l enough at the time.
There is a normative reference to RESTCONF = to use yang-data.
This is just an RFC detail. In a server, the ya= ng-library can indicate
that ietf-restconf is just imported (not = implemented). It really does not matter
that this extension is in= ietf-restconf.yang.

=C2=A0

=C2=A0

=C2=A0

> We really have to try to keep the documents sta= ble, and not republish an RFC

> just to move definitions around.<= /p>

=C2=A0

We are talking about a new RFC (this draft).=C2=A0 I= don't care if 8040 ever uses the new yang-data statement, it can forev= er have its own private definition.=C2=A0 I do care that we introduce a lon= g-term solution (again, augment alone seems limited) and would like to make an incremental improvement for normative references= .

=C2=A0


IMO it is not worth the trouble. There ar= e NMDA drafts to work on instead.
=C2=A0

=C2=A0

K.=C2=A0 // contributor

=C2=A0

=C2=A0


Andy

--001a114b2e582a69c2055824816d-- From nobody Fri Sep 1 12:22:01 2017 Return-Path: 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 666C4134399 for ; Fri, 1 Sep 2017 12:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.12 X-Spam-Level: X-Spam-Status: No, score=-0.12 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 ZrGDQQErDStm for ; Fri, 1 Sep 2017 12:21:57 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0094.outbound.protection.outlook.com [104.47.33.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F25E13448F for ; Fri, 1 Sep 2017 12:21:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XDc9AKJMNnKXt8Pni71ExRQAYlj5h04gkFXjizVGwk8=; b=CiO8J/0N/pOkOvvgIWmHUszsbbo5XRNrBtpEAZOMSHORFAgJ7x1DTvGoninchDYUWsJGCXHzS0aNuUC+Uuw4eAvqeEAVHgG6pi+Dc3QbmruvojyidZ1gJ8UUO+7x4Nxa1zHkFCM/qkUNYEeMeyohw5rJwMC0Z+AvwLa6eY9Sfb8= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB2009.namprd05.prod.outlook.com (10.164.2.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.3; Fri, 1 Sep 2017 19:21: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.20.0013.014; Fri, 1 Sep 2017 19:21:55 +0000 From: Kent Watsen To: Andy Bierman CC: "netmod@ietf.org" Thread-Topic: [netmod] regarding draft-bierman-netmod-yang-data-ext-00 Thread-Index: AQHTIz66ZM/zAubP+UmCwbr4E6YP36KgO1WA///OrQCAAEdAgP//1FYA Date: Fri, 1 Sep 2017 19:21:55 +0000 Message-ID: References: <57AA997C-6E52-49D2-B6AF-7DDE8F13D7B3@juniper.net> <56D58AA8-E71E-4CA1-B81E-70E2EDD94E91@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.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR0501MB2009; 6:aYvfGsfvjDEKy/+52WJYAT/bkpdQNW+TPLeQy5uVJsc5Ntqhnb9puAWCv3b0avU21pgJxEKazckXktPl8MkjtmAw2pxXHKIwjK610p8URrd+5zHSDZa0UMcjtZh/m1b3E0jdq/PVDid8YkFnh54FOy4MRLD9vUi1548IIF5QDy4EHcjvSC2kTib/nZMafoXYjs/HegWbQaoNfdDbLy0KkwYCnvr1eahsQrncUcEC1l6JPFEoBvxsrpNr9c3JO279azspvZmSI9VMaNVkmaQgq4CoGc0ohIsxfGt+/I/fg7nZafaSIpcpsXjc+kzwVrJQnOn/Isp7cr+/PwpXCFOcHA==; 5:t7uWum/UOwlRIU3tNu+A7bvWelQFQsG7o6a2MySNWVKI2lO4MiUt5qm6Oy2Ci6fyhVJV6nqM50FycXQmHyZddCODzCASxSDYdX5gj8trtMu/xtujxpKVRhaT8oj3vRwQr+tm5hSEmPiWvZ3z7YdwKg==; 24:viqC956a6Eyev9RcB/wJQn3xKdlq+17LMKDpaBq5Qyh6A5Rx8waWncxwxv9HiwszcGDzgHEh0iSOd2jpa9HkStRMSN13o5DAS3/h4V39xhE=; 7:5VEY0S8zmZzGYtJN13e7hSo4HK2ZgyEAmFWqg2my8iJwnlMqUaHvUf10UPZyP71d1AH3XCkfKMIGzfDU2nZMIVR3mNdt8Izenx5PwPRfS6wpsWh9X2HmjgjxbURnexVpHfFnAMURteTp5Z7tUkhr9mLIfugPsQfG6kMqOFQiknEfvODgnw86WaB4pOM3BAW6pOFXY8Vl6Q2aQ/5PIR2xP64TH2WBmXA7bIxeYtLY3Mc= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 29ccfcea-299d-425f-7f91-08d4f16eb550 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR0501MB2009; x-ms-traffictypediagnostic: CY1PR0501MB2009: x-exchange-antispam-report-test: UriScan:(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123558100)(20161123562025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR0501MB2009; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR0501MB2009; x-forefront-prvs: 0417A3FFD2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(189002)(199003)(4001350100001)(6486002)(2950100002)(8936002)(77096006)(36756003)(6246003)(110136004)(50986999)(6436002)(6116002)(102836003)(86362001)(3846002)(25786009)(6506006)(76176999)(54356999)(478600001)(6512007)(2900100001)(6916009)(53936002)(3660700001)(3280700002)(68736007)(106356001)(8676002)(2906002)(6306002)(33656002)(66066001)(54896002)(5660300001)(105586002)(230783001)(99286003)(82746002)(229853002)(83506001)(189998001)(101416001)(81166006)(81156014)(7736002)(93886005)(14454004)(97736004)(83716003)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB2009; 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_E4E113589E08415EADBCB4F3A2F81AE7junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2017 19:21:55.5637 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB2009 Archived-At: Subject: Re: [netmod] regarding draft-bierman-netmod-yang-data-ext-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 19:21:59 -0000 --_000_E4E113589E08415EADBCB4F3A2F81AE7junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQo+PiBSaWdodCwgdGhpcyBpcyB3aGF0IGlzIGN1cnJlbnRseSBiZWluZyBkb25lLCBidXQgaXQg aXMgbmVpdGhlciBpbnR1aXRpdmUgbm9yIGNvbmR1Y2l2ZQ0KPj4gdG8gZG93bnN0cmVhbSBleHRl bnNpb25z4oCmDQo+DQo+IEkgYWdyZWUgd2l0aCBNYXJ0aW4gdGhhdCB3ZSBkbyBub3QgbmVlZCB0 byByZXBsaWNhdGUgcGxhaW4gWUFORyBpbiBleHRlbnNpb25zLg0KPiBXZSB3YW50IHRvIGF2b2lk IG5ldyBleHRlbnNpb25zLCBlc3BlY2lhbGx5IGlmIGEgcmVndWxhciBZQU5HIHN0YXRlbWVudCB3 aXRoIHdvcmsuDQoNCkJ5ICJkb3duc3RyZWFtIGV4dGVuc2lvbnMiIEkgbWVhbnQgZnV0dXJlIHlh bmctZGF0YSBkZWZpbml0aW9ucy4gIEltYWdpbmUgd2UgaGF2ZQ0KeWFuZy1kYXRhICdBJyBhbmQg dGhlbiwgbGF0ZXIsIGEgeWFuZy1kYXRhICdCJyB0aGF0IGJ1aWxkcyBvbiAnQScgYW5kIHRoZW4s IGV2ZW4gbGF0ZXIsIGENCnlhbmctZGF0YSAnQycgdGhhdCBidWlsZHMgb24gJ0InLiAgIFRoZSBn cm91cGluZyBhcHByb2FjaCBvbmx5IHdvcmtzIGZvciAnQicgaWYgdGhlDQpkZWZpbml0aW9uIG9m ICdBJyBoYWQgdGhlIGZvcmVzaWdodCB0byBkZWZpbmUgYSBncm91cGluZyAnQicgY291bGQgdXNl LCBidXQgJ0MnIGNvdWxkIGJlDQpvdXQgb2YgbHVjay4NCg0KDQo+IElNTyBpdCBpcyBub3Qgd29y dGggdGhlIHRyb3VibGUuDQoNCkdvdGNoYS4gIFdoYXQgZG8gb3RoZXIgcGVvcGxlIHRoaW5rLCB3 b3VsZCBhICJ1c2VzLXlhbmctZGF0YSIgc3RhdGVtZW50IGJlIGdlbmVyYWxseQ0KbW9yZSB1c2Vm dWw/DQoNCg0KSy4NCg0K --_000_E4E113589E08415EADBCB4F3A2F81AE7junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <983AA9998886214781552309B3E53648@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 b250LWZhbWlseTpDYWxpYnJpOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCglj b2xvcjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9u Om5vbmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLm1zb0lucw0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mZ3Q7Jmd0OyBSaWdodCwgdGhpcyBpcyB3aGF0IGlzIGN1cnJlbnRseSBiZWlu ZyBkb25lLCBidXQgaXQgaXMgbmVpdGhlciBpbnR1aXRpdmUgbm9yIGNvbmR1Y2l2ZTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZndDsgdG8gZG93bnN0cmVhbSBleHRl bnNpb25z4oCmPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7 IEkgYWdyZWUgd2l0aCBNYXJ0aW4gdGhhdCB3ZSBkbyBub3QgbmVlZCB0byByZXBsaWNhdGUgcGxh aW4gWUFORyBpbiBleHRlbnNpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBXZSB3YW50IHRvIGF2b2lkIG5ldyBleHRlbnNpb25zLCBl c3BlY2lhbGx5IGlmIGEgcmVndWxhciBZQU5HIHN0YXRlbWVudCB3aXRoIHdvcmsuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ5ICZxdW90O2Rvd25zdHJlYW0gZXh0ZW5z aW9ucyZxdW90OyBJIG1lYW50IGZ1dHVyZSB5YW5nLWRhdGEgZGVmaW5pdGlvbnMuJm5ic3A7IElt YWdpbmUgd2UgaGF2ZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj55YW5n LWRhdGEgJ0EnIGFuZCB0aGVuLCBsYXRlciwgYSB5YW5nLWRhdGEgJ0InIHRoYXQgYnVpbGRzIG9u ICdBJyBhbmQgdGhlbiwgZXZlbiBsYXRlciwgYQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj55YW5nLWRhdGEgJ0MnIHRoYXQgYnVpbGRzIG9uICdCJy4mbmJzcDsmbmJzcDsg VGhlIGdyb3VwaW5nIGFwcHJvYWNoIG9ubHkgd29ya3MgZm9yICdCJyBpZiB0aGUNCjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZGVmaW5pdGlvbiBvZiAnQScgaGFkIHRoZSBm b3Jlc2lnaHQgdG8gZGVmaW5lIGEgZ3JvdXBpbmcgJ0InIGNvdWxkIHVzZSwgYnV0ICdDJyBjb3Vs ZCBiZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+b3V0IG9mIGx1Y2suPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBJTU8gaXQgaXMgbm90 IHdvcnRoIHRoZSB0cm91YmxlLiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R290Y2hhLiZuYnNw OyBXaGF0IGRvIG90aGVyIHBlb3BsZSB0aGluaywgd291bGQgYSAmcXVvdDt1c2VzLXlhbmctZGF0 YSZxdW90OyBzdGF0ZW1lbnQgYmUgZ2VuZXJhbGx5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5tb3JlIHVzZWZ1bD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E4E113589E08415EADBCB4F3A2F81AE7junipernet_-- From nobody Fri Sep 1 13:09:23 2017 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0E3132E48; Fri, 1 Sep 2017 13:09:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150429655642.6502.1093755384621488599@ietfa.amsl.com> Date: Fri, 01 Sep 2017 13:09:16 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-acl-model-12.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 20:09:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : Network Access Control List (ACL) YANG Data Model Authors : Mahesh Jethanandani Lisa Huang Sonal Agarwal Dana Blair Filename : draft-ietf-netmod-acl-model-12.txt Pages : 46 Date : 2017-09-01 Abstract: This document describes a data model of Access Control List (ACL) basic building blocks. Editorial Note (To be removed by RFC Editor) This draft contains many placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. Please note that no other RFC Editor instructions are specified anywhere else in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements o "XXXX" --> the assigned RFC value for this draft both in this draft and in the YANG models under the revision statement. o Revision date in model needs to get updated with the date the draft gets approved. The date also needs to get reflected on the line with . The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-acl-model-12 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-model-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 1 13:55:18 2017 Return-Path: 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 D9BDB13441A for ; Fri, 1 Sep 2017 13:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 k1ws8QSMHGOG for ; Fri, 1 Sep 2017 13:55:15 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC2E413462A for ; Fri, 1 Sep 2017 13:55:15 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 808ED6A2; Fri, 1 Sep 2017 22:55:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id lIKlBrt_lUO1; Fri, 1 Sep 2017 22:55:11 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 1 Sep 2017 22:55:14 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5CDDD200E2; Fri, 1 Sep 2017 22:55:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ZVMmUZjlJQAC; Fri, 1 Sep 2017 22:55:14 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D30F5200E0; Fri, 1 Sep 2017 22:55:12 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 24AA2407A5E2; Fri, 1 Sep 2017 22:55:11 +0200 (CEST) Date: Fri, 1 Sep 2017 22:55:11 +0200 From: Juergen Schoenwaelder To: Kent Watsen Cc: Andy Bierman , "netmod@ietf.org" Message-ID: <20170901205511.3hgalynjpur2gjqf@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , Andy Bierman , "netmod@ietf.org" References: <57AA997C-6E52-49D2-B6AF-7DDE8F13D7B3@juniper.net> <56D58AA8-E71E-4CA1-B81E-70E2EDD94E91@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [netmod] regarding draft-bierman-netmod-yang-data-ext-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 20:55:18 -0000 On Fri, Sep 01, 2017 at 07:21:55PM +0000, Kent Watsen wrote: > > The grouping approach only works for 'B' if the definition of 'A' > had the foresight to define a grouping 'B' could use, but 'C' could > be out of luck. This is generally true. YANG kind of require to design something for reuse (and often you have to be carefuly how you word descriptions etc. for things that are intended to be reused). > Gotcha. What do other people think, would a "uses-yang-data" > statement be generally more useful? But does this mean we also do uses-yang-container, uses-yang-list, uses-yang-xyz to other definitions as well? I do not think this is desirable and why would yang-data be any different? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Sep 1 14:02:32 2017 Return-Path: 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 A1E3613435E for ; Fri, 1 Sep 2017 14:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfcehKADVf5F for ; Fri, 1 Sep 2017 14:02:29 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 CF0CB1344D9 for ; Fri, 1 Sep 2017 14:02:29 -0700 (PDT) Received: from cmgw3 (unknown [10.0.90.84]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 6F0041E0890 for ; Fri, 1 Sep 2017 15:02:29 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id 4M2R1w0122SSUrH01M2UCX; Fri, 01 Sep 2017 15:02:29 -0600 X-Authority-Analysis: v=2.2 cv=F98nTupN c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=2JCJgTwv5E4A:10 a=ri0MzPERGHgdVGHnxEEA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Cc:To:Subject:From:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=liefz7FK1lbdXdOhBYlT4OkcFF0RUCFlaA+5GPknCbY=; b=pl/mHGPedsbFuWM8Ntjyan56Ys S0JWluy+B8XXHg+6cbSlHDOyIOwiIExdS2bRNlX5CLuWrARcQRoP6kqbdKAs6AFFmG1VMxetGN0KE i3k3GsbVPYKxW45bovXTbeCex; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:47158 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dnt57-00315c-Hn; Fri, 01 Sep 2017 15:02:25 -0600 From: Lou Berger To: netmod WG Cc: "netmod-chairs@ietf.org" , draft-ietf-netmod-revised-datastores@ietf.org Message-ID: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> Date: Fri, 1 Sep 2017 17:02:24 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.84.20 X-Exim-ID: 1dnt57-00315c-Hn X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:47158 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 21:02:31 -0000 All, This starts a two week working group last call on draft-ietf-netmod-revised-datastores-04. The working group last call ends on September 17. Please send your comments to the netmod mailing list. Positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome! This is useful and important, even from authors. Thank you, Netmod Chairs From nobody Sat Sep 2 00:33:51 2017 Return-Path: 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 DBF3513422D for ; Sat, 2 Sep 2017 00:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qr8bmFUYwj7U for ; Sat, 2 Sep 2017 00:33:45 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8791A134218 for ; Sat, 2 Sep 2017 00:33:45 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 8F1B218; Sat, 2 Sep 2017 09:33:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 3i6FOPMWRxib; Sat, 2 Sep 2017 09:33:40 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Sat, 2 Sep 2017 09:33:43 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6C10D200E3; Sat, 2 Sep 2017 09:33:43 +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 fXnwMzQUFyOg; Sat, 2 Sep 2017 09:33:43 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F362D200E0; Sat, 2 Sep 2017 09:33:42 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C99B8407AB4F; Sat, 2 Sep 2017 09:33:42 +0200 (CEST) Date: Sat, 2 Sep 2017 09:33:42 +0200 From: Juergen Schoenwaelder To: Robert Wilton Cc: Alex Campbell , "netmod@ietf.org" Message-ID: <20170902073342.xoziwor4tdr5bipw@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Robert Wilton , Alex Campbell , "netmod@ietf.org" References: <20170830102902.2n5q6rgq2x2dxfq2@elstar.local> <20170830123156.cssrg5kklpo67fie@elstar.local> <1504223854014.55228@Aviatnet.com> <847e5bf9-7b3d-9ff8-9954-970f32a2094c@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <847e5bf9-7b3d-9ff8-9954-970f32a2094c@cisco.com> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Sep 2017 07:33:48 -0000 On Fri, Sep 01, 2017 at 10:45:51AM +0100, Robert Wilton wrote: > Hi Alex, > > > On 01/09/2017 00:57, Alex Campbell wrote: > > > > Hi, > > > > > > I'd be very wary of adding guidelines that restrict the regex syntax. > > > > > > A tool that supports YANG must implement the full regex language anyway > > (or ignore regexes altogether if they are not relevant to the tool's > > function). > > > This is true if the tool is designed to work with any arbitrary YANG > module.  But if a tool only needs to work with a subset of YANG modules > (e.g. perhaps just IETF, OpenConfig, and Vendor models) then they only need > to support the subset of the XML RE language that is used by the YANG > modules that they load. > Rob, you are on the path to create multiple flavours of YANG, an IETF flavour, an OC flavour, a Vendor XYZ flavour - in my view this can't be the goal of a standard. A compliant implementation of YANG 1.0 and YANG 1.1 must handle XSD pattern. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sat Sep 2 01:24:29 2017 Return-Path: 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 2262E1336EA for ; Sat, 2 Sep 2017 01:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-RV3O6Tirq9 for ; Sat, 2 Sep 2017 01:24:26 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E970132F8F for ; Sat, 2 Sep 2017 01:24:26 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 53AD06A2; Sat, 2 Sep 2017 10:24:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 0maTCgcmct-x; Sat, 2 Sep 2017 10:24:21 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Sat, 2 Sep 2017 10:24:25 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 089EA200E2; Sat, 2 Sep 2017 10:24:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Khulfkm9n5jo; Sat, 2 Sep 2017 10:24:24 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 739EF200E0; Sat, 2 Sep 2017 10:24:24 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 42655407AC38; Sat, 2 Sep 2017 10:24:24 +0200 (CEST) Date: Sat, 2 Sep 2017 10:24:24 +0200 From: Juergen Schoenwaelder To: Robert Wilton Cc: Andy Bierman , Xufeng Liu , "netmod@ietf.org" Message-ID: <20170902082424.zhirq544fqea4zab@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Robert Wilton , Andy Bierman , Xufeng Liu , "netmod@ietf.org" References: <20170828154640.pzg7jfy5uepkb22q@elstar.local> <20170830102902.2n5q6rgq2x2dxfq2@elstar.local> <20170830123156.cssrg5kklpo67fie@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Sep 2017 08:24:28 -0000 On Wed, Aug 30, 2017 at 05:44:01PM +0100, Robert Wilton wrote: > > First question: How many pattern statements in draft and standard IETF YANG > modules actually use Unicode properties (e.g \p{}). > Answer: Just 2.  To add a zone at the end of the IPv4/IPv6 address. > > E.g.       pattern >         '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}' >       +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])' >       + '(%[\p{N}\p{L}]+)?'; > > This could quite possibly have been written just as > "\d{1,3}\.{3}\d{1,3)(%\w+)?" and not use Unicode properties at all. Shorter but less precise. The thread started with a proposal to ban \d, you seem to like it. Note that \d is not the same as [0-9] in unicode as far as I know. \d is defined to be \p{Nd} and Nd has way more than [0-9]. https://www.w3.org/TR/xmlschema-2/#regexs http://www.fileformat.info/info/unicode/category/Nd/list.htm Perhaps the usage of \p{N} and \p{L} above is not quite right (I recall that I tried to find out what exactly the rules for a zone index are and often you find out that there is not really a precise definition). My standpoint is that it is the WGs that are responsible to work out the pattern; the WGs are responsible to decide how strict they want patterns to be. The pattern in RFC6991 rejects an 'IP address' of the form 321.1.2.3 or 01.2.3.4 and I think this is goodness but it is ultimately a decision of the WG producing the YANG module how the patterns should look like and how strict they are. And we should separate the discussion of how strict a pattern should be from the discussion of using unicode constructs or other 'more recent' constructs in pattern. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sat Sep 2 03:40:02 2017 Return-Path: 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 2F819132335 for ; Sat, 2 Sep 2017 03:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 IlWalb_myOEb for ; Sat, 2 Sep 2017 03:39:59 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 672841329C0 for ; Sat, 2 Sep 2017 03:39:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2374; q=dns/txt; s=iport; t=1504348799; x=1505558399; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Fs1olKM714J2KlK11ZJ+asEAXGOL6lpg8kRAvnz+RUk=; b=QVU47M03YTGZGpHBZyUb2Tc6xoHJ/c8tDQ+ZtFiw4xH9X0zeepAExj0/ 4B+PAatOUbMJQUjpT5M0R3Q7MiCCDcJTvPMfl3x8pAQNyoTidejiOgKz5 wWHmBtblECKS1X9JLtSA/g4sYOCajQTyW7Swlzr2Ci01oNM2na6/P1n/k g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D+AAC+iapZ/5JdJa1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNaZIEVB4NwiiCQIIFxliiCEiELhExPAhqDez8YAQIBAQEBAQE?= =?us-ascii?q?BayiFGQEBAQMBASEROgsOAgIBCA4CCAICJgICAhkMCxUQAgQOBYoxELF8gieLW?= =?us-ascii?q?gEBAQEBAQEBAQEBAQEBAQEBAQEBAR0FgQiCHYIChlmEdRcKJoJMgmEFoHQClE+?= =?us-ascii?q?ScZZKAR84gQ13FUmHG3aJcoEPAQEB?= X-IronPort-AV: E=Sophos;i="5.41,463,1498521600"; d="scan'208";a="479796315" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Sep 2017 10:39:58 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v82Advaj010930 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 2 Sep 2017 10:39:58 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 2 Sep 2017 06:39:57 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1263.000; Sat, 2 Sep 2017 06:39:57 -0400 From: "Acee Lindem (acee)" To: Juergen Schoenwaelder , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" CC: "netmod@ietf.org" Thread-Topic: [netmod] Potential additions to rfc6087bis: RegEx guidelines Thread-Index: AQHTHPE2wiW48ODwX0muaRIIfazDyAAhqHwAAAKnWIAAEce1gAAC0wGAACizCwAAAHCnAACXFjOAAAXbNQAAL4LGgAADyxwAACOm9gAAAoh/AAACxNqAAAGF9gAABORxgAAD6VyAADKKfzyik1ZcgIABbWkA///w5oA= Date: Sat, 2 Sep 2017 10:39:57 +0000 Message-ID: References: <20170830102902.2n5q6rgq2x2dxfq2@elstar.local> <20170830123156.cssrg5kklpo67fie@elstar.local> <1504223854014.55228@Aviatnet.com> <847e5bf9-7b3d-9ff8-9954-970f32a2094c@cisco.com> <20170902073342.xoziwor4tdr5bipw@elstar.local> In-Reply-To: <20170902073342.xoziwor4tdr5bipw@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Sep 2017 10:40:01 -0000 SnVlcmdlbiwgDQoNCk9uIDkvMi8xNywgMzozMyBBTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgSnVl cmdlbiBTY2hvZW53YWVsZGVyIg0KPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBv Zg0Kai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCg0KPk9uIEZy aSwgU2VwIDAxLCAyMDE3IGF0IDEwOjQ1OjUxQU0gKzAxMDAsIFJvYmVydCBXaWx0b24gd3JvdGU6 DQo+PiBIaSBBbGV4LA0KPj4gDQo+PiANCj4+IE9uIDAxLzA5LzIwMTcgMDA6NTcsIEFsZXggQ2Ft cGJlbGwgd3JvdGU6DQo+PiA+IA0KPj4gPiBIaSwNCj4+ID4gDQo+PiA+IA0KPj4gPiBJJ2QgYmUg dmVyeSB3YXJ5IG9mIGFkZGluZyBndWlkZWxpbmVzIHRoYXQgcmVzdHJpY3QgdGhlIHJlZ2V4IHN5 bnRheC4NCj4+ID4gDQo+PiA+IA0KPj4gPiBBIHRvb2wgdGhhdCBzdXBwb3J0cyBZQU5HIG11c3Qg aW1wbGVtZW50IHRoZSBmdWxsIHJlZ2V4IGxhbmd1YWdlDQo+PmFueXdheQ0KPj4gPiAob3IgaWdu b3JlIHJlZ2V4ZXMgYWx0b2dldGhlciBpZiB0aGV5IGFyZSBub3QgcmVsZXZhbnQgdG8gdGhlIHRv b2wncw0KPj4gPiBmdW5jdGlvbikuDQo+PiA+IA0KPj4gVGhpcyBpcyB0cnVlIGlmIHRoZSB0b29s IGlzIGRlc2lnbmVkIHRvIHdvcmsgd2l0aCBhbnkgYXJiaXRyYXJ5IFlBTkcNCj4+IG1vZHVsZS4g IEJ1dCBpZiBhIHRvb2wgb25seSBuZWVkcyB0byB3b3JrIHdpdGggYSBzdWJzZXQgb2YgWUFORyBt b2R1bGVzDQo+PiAoZS5nLiBwZXJoYXBzIGp1c3QgSUVURiwgT3BlbkNvbmZpZywgYW5kIFZlbmRv ciBtb2RlbHMpIHRoZW4gdGhleSBvbmx5DQo+Pm5lZWQNCj4+IHRvIHN1cHBvcnQgdGhlIHN1YnNl dCBvZiB0aGUgWE1MIFJFIGxhbmd1YWdlIHRoYXQgaXMgdXNlZCBieSB0aGUgWUFORw0KPj4gbW9k dWxlcyB0aGF0IHRoZXkgbG9hZC4NCj4+DQo+DQo+Um9iLA0KPg0KPnlvdSBhcmUgb24gdGhlIHBh dGggdG8gY3JlYXRlIG11bHRpcGxlIGZsYXZvdXJzIG9mIFlBTkcsIGFuIElFVEYNCj5mbGF2b3Vy LCBhbiBPQyBmbGF2b3VyLCBhIFZlbmRvciBYWVogZmxhdm91ciAtIGluIG15IHZpZXcgdGhpcyBj YW4ndA0KPmJlIHRoZSBnb2FsIG9mIGEgc3RhbmRhcmQuDQoNClRoaXMgaXMgbm90IGFuIGVmZm9y dCB0byBjaGFuZ2Ugb3IgYmlmdXJjYXRlIHRoZSBZQU5HIDEuMS4gSXQgaXMgc2ltcGx5IHRvDQpS RUNPTU1FTkQgYSBwcm9wZXIgc3Vic2V0IG9mIFhTRCBwYXR0ZXJuIHRoYXQgaXMgbW9yZSBwb3J0 YWJsZS4NCg0KVGhhbmtzLA0KQWNlZQ0KDQoNCj4NCj5BIGNvbXBsaWFudCBpbXBsZW1lbnRhdGlv biBvZiBZQU5HIDEuMCBhbmQgWUFORyAxLjEgbXVzdCBoYW5kbGUgWFNEDQo+cGF0dGVybi4NCj4N Cj4vanMNCj4NCj4tLSANCj5KdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBV bml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPlBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAg Q2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCj5GYXg6ICAgKzQ5IDQyMSAy MDAgMzEwMyAgICAgICAgIDxodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCj4NCj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPm5ldG1vZCBt YWlsaW5nIGxpc3QNCj5uZXRtb2RAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldG1vZA0KDQo= From nobody Sat Sep 2 04:28:38 2017 Return-Path: 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 A1FAA132812 for ; Sat, 2 Sep 2017 04:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4U84s9bdAWvA for ; Sat, 2 Sep 2017 04:28:34 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 702E5132D60 for ; Sat, 2 Sep 2017 04:28:34 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 2E73369A; Sat, 2 Sep 2017 13:28:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id Tis7kkHFlPs2; Sat, 2 Sep 2017 13:28:29 +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 atlas5.jacobs-university.de (Postfix) with ESMTPS; Sat, 2 Sep 2017 13:28:32 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id DDA0F200E2; Sat, 2 Sep 2017 13:28:32 +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 qNK9Yxrp87_8; Sat, 2 Sep 2017 13:28:32 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5ED15200E0; Sat, 2 Sep 2017 13:28:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4E36B407AFCA; Sat, 2 Sep 2017 13:28:32 +0200 (CEST) Date: Sat, 2 Sep 2017 13:28:32 +0200 From: Juergen Schoenwaelder To: "Acee Lindem (acee)" Cc: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" , "netmod@ietf.org" Message-ID: <20170902112832.ymorfgdthobeio6q@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Acee Lindem (acee)" , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" , "netmod@ietf.org" References: <20170830102902.2n5q6rgq2x2dxfq2@elstar.local> <20170830123156.cssrg5kklpo67fie@elstar.local> <1504223854014.55228@Aviatnet.com> <847e5bf9-7b3d-9ff8-9954-970f32a2094c@cisco.com> <20170902073342.xoziwor4tdr5bipw@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Sep 2017 11:28:37 -0000 On Sat, Sep 02, 2017 at 10:39:57AM +0000, Acee Lindem (acee) wrote: > > This is not an effort to change or bifurcate the YANG 1.1. It is simply to > RECOMMEND a proper subset of XSD pattern that is more portable. > If you implement YANG as it is defined, pattern are portable. Given this, I do not understand the notion of 'more portable'. Anyway, it seems that those who want a more portable subset do not even agree on what that subset is. Perhaps people pushing for this should go and write an I-D that explains why a 'more portable' subset is needed (which problems are we fixing), that defines such a 'more portable subset', and which includes the reasoning how the subset has been determined. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sat Sep 2 09:46:43 2017 Return-Path: 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 26DC3126B6D for ; Sat, 2 Sep 2017 09:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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, URIBL_BLOCKED=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 wBUjW3BmHlYk for ; Sat, 2 Sep 2017 09:46:40 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 2159B132FD6 for ; Sat, 2 Sep 2017 09:46:40 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id j17so5912901iti.1 for ; Sat, 02 Sep 2017 09:46:40 -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; bh=zTJ0+1a7rGGfdh2zROtZNSKFaSvTZEk790uAwV6+C9w=; b=RD4WRxUr080JfnO+m0T0MpolxuWYfcZGHsGLzp4Zb+6Pq4IgXic4XXJOzafv5TDFys 3dcLHgb5DOJ+irfSPe3PQl0pje5rM8dDDlstaKZdcqmkBYObkma7Cvo28S72ziBvB/a8 LRsks95YPBYJjBwZFSI8ZB4c0fEsrxtWTxdO6aQkOjWSMeV9jY0+0SLCsSGyXM2riu0S b1FqvcgSsEsMkvVXSUa2NI1K4PlUDL9sYogcPvkzsFS03PZyZeeNLt+1FvQprp/jVhKW g0PX6EKuaNQ2l21wp1tPTaPG19Cud8x1Ly163X+lo/tZX9R1d8Sn+xa0A6HanWS0p8Zh HUbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=zTJ0+1a7rGGfdh2zROtZNSKFaSvTZEk790uAwV6+C9w=; b=URVHr8ld9r6nEOZ3pjJ6SPMcxSbXm6YiOel/L7/f7P/xCifcUHi7U1YwtRO3xfDCzC 6TI8SNpcWaI/GZV/3p/mesQDP6JTZ3jk8kerqsIW7QxlQx6DvNtPqEDO2dI1jQ03nUGy PzR+0Q4bB3YRx4JO18vSrqM5V/lViPAfFJgHo1Jq19SvF3TEmTXjAPKYbEpjaoAtPO+3 ZcuMY62LjXaHQgrO3+/GeIU1x6LSNonNlowWH/uwATVyU+/z6iWbiRwy3TDt3EieoGc8 Hk9A09xQNsLAHkyo1PPqgAGsYXsuGGnkdz+ZRzMlGKl03e3ebCfYVTi4LNM7L0rh7nru We7g== X-Gm-Message-State: AHPjjUhNxU5JIz9jBYVvY35B2+5Iy4M4AAqT+DnTkHazWgf6nT5J89LU bXk4yRDCdR5STDcgkwklS7C+RURLbEaC X-Google-Smtp-Source: ADKCNb6UJg6cyCtf7cv9ukGAHH7bgTBfQbPsbsNlOtw9/mF0RybsoNP44kNQfslMk03ZQjEfM/cqWtZgHnCDsHdTXCo= X-Received: by 10.36.40.138 with SMTP id h132mr1562073ith.26.1504370799428; Sat, 02 Sep 2017 09:46:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.6.206 with HTTP; Sat, 2 Sep 2017 09:46:38 -0700 (PDT) In-Reply-To: <20170902112832.ymorfgdthobeio6q@elstar.local> References: <20170830102902.2n5q6rgq2x2dxfq2@elstar.local> <20170830123156.cssrg5kklpo67fie@elstar.local> <1504223854014.55228@Aviatnet.com> <847e5bf9-7b3d-9ff8-9954-970f32a2094c@cisco.com> <20170902073342.xoziwor4tdr5bipw@elstar.local> <20170902112832.ymorfgdthobeio6q@elstar.local> From: Andy Bierman Date: Sat, 2 Sep 2017 09:46:38 -0700 Message-ID: To: Juergen Schoenwaelder , "Acee Lindem (acee)" , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="001a113f62ec1c697f0558379f1f" Archived-At: Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Sep 2017 16:46:42 -0000 --001a113f62ec1c697f0558379f1f Content-Type: text/plain; charset="UTF-8" On Sat, Sep 2, 2017 at 4:28 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Sat, Sep 02, 2017 at 10:39:57AM +0000, Acee Lindem (acee) wrote: > > > > This is not an effort to change or bifurcate the YANG 1.1. It is simply > to > > RECOMMEND a proper subset of XSD pattern that is more portable. > > > > If you implement YANG as it is defined, pattern are portable. Given > this, I do not understand the notion of 'more portable'. > > Anyway, it seems that those who want a more portable subset do not > even agree on what that subset is. Perhaps people pushing for this > should go and write an I-D that explains why a 'more portable' subset > is needed (which problems are we fixing), that defines such a 'more > portable subset', and which includes the reasoning how the subset has > been determined. > > I do not agree that the YANG pattern contains a string that is both a POSIX and XSD regular expression. The RFC is very clear it contains an XSD expression. Pretending it is both is a hack that does not even seem to work 100%, so it is not reliable. If the community wants to support both XSD and POSIX expressions, then the proper engineering solution is to introduce a new statement that is defined to contain a POSIX expression. This can be done with a YANG extension now and added to YANG 2.0 later. > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a113f62ec1c697f0558379f1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --001a113f62ec1c697f0558379f1f-- From nobody Sat Sep 2 09:59:33 2017 Return-Path: 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 E9B68132FD6 for ; Sat, 2 Sep 2017 09:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 bT5Bu5yxs0kv for ; Sat, 2 Sep 2017 09:59:30 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0134.outbound.protection.outlook.com [104.47.37.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFE03132FAC for ; Sat, 2 Sep 2017 09:59:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UDMIZUggPl2h6J0QFLFV8hko8J5z6Ifeoil4vPbETVA=; b=CrPhB6mDPP3J35dEjnHXaY2yZSbBdDVDZ9WgQzBf2/A2yJNl4PfygiEXAeX3WOz2Ktvufr1i1kjJyK4l0+Hm3SUvxh09Az0Sr28tT39nTexL2xdN1YJbkjPw7T5WWK4mTAcnJBbyS/NUsYKG3c3onT2RA0PQlaO4XEsBANU717U= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1236.namprd05.prod.outlook.com (10.160.183.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.3; Sat, 2 Sep 2017 16:59:27 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.20.0035.006; Sat, 2 Sep 2017 16:59:27 +0000 From: Kent Watsen To: Juergen Schoenwaelder CC: Andy Bierman , "netmod@ietf.org" Thread-Topic: [netmod] regarding draft-bierman-netmod-yang-data-ext-00 Thread-Index: AQHTIz66ZM/zAubP+UmCwbr4E6YP36KgO1WA///OrQCAAEdAgP//1FYAgABdHoCAAQ1oAA== Date: Sat, 2 Sep 2017 16:59:27 +0000 Message-ID: References: <57AA997C-6E52-49D2-B6AF-7DDE8F13D7B3@juniper.net> <56D58AA8-E71E-4CA1-B81E-70E2EDD94E91@juniper.net> <20170901205511.3hgalynjpur2gjqf@elstar.local> In-Reply-To: <20170901205511.3hgalynjpur2gjqf@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1236; 6:2Rk8z1IluZ3w2mnWuxOOM1j0cCMzD0H/Vobx40C0vfpD99GywhdGsEqryKN8fG5+ATjeuhZR5bl85uWQWxioM/vDPPXRbxh+GHsKrIHAfR0h/1GGrlp7XZB8Nr/AQ3mB7cJrBMB+oTwTA76yxexrqTR10TMatU/sVRjLZ5/YiRX5nY8Rwy83uZyA8yB3nJgw0f6qxPqR+mna3ZUD1XvhHk70Zs93IIaqP+zT2W4RpJZKBlOPIfOfvGBIE5JHExeNK6f8UmYXkyuG4fqkgQPPqtDAVP/3DlwIelEB1IWn2HYyBswnWh9QNsYtAGcvYsvcuCZz204XlQyrHm9g8yOQJA==; 5:2jqxfFaMei05LXoUWZrGU79RWxLnsYj8MQXOAIowXPXS9ca3UpU6DWIf6Okn9nma2QmltRX0k82lLEBBTX8K6WQSdDkjDs8MxAHTXb3ZRdlYUhReZD7fLG8ZlT+Vrs2FKRC3tMOtDTuic4cCESlIfw==; 24:aO7dj16GLxuSCWMg8sW0hhGAjspvGpbhVaQg+50Z2ak9N0Ax4O/hBP+QpaZf5BwxeMvlQ/sw7yHIImzdydPO87Vm3l4s+7vvpLhM4LJd3s0=; 7:ssuIlEimXB//odh6RZXAQfEEZphdrLdkwxGNRsWYdZfBkbC0oYTD49UgNG3SjMyHx02/45JLc5IT50Ajb1e3S6Rq9hAxhyTxd50jqgO5AXuJW4N8cnq+Ai9Tr2yXuLV3hz1uIroWlxuYLammHdJ9SWAhEZE9K0CP96tOmBdhROhYpGbeiiVEFXFWcuFx6i35J0o5JcIHjL6ePIH6BlzFWVJFiHIKj1oGk8HlAe84iqE= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ba244d3b-2c4a-4748-1c08-08d4f223f893 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1236; x-ms-traffictypediagnostic: BN3PR0501MB1236: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1236; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1236; x-forefront-prvs: 04180B6720 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(189002)(199003)(83506001)(102836003)(86362001)(81166006)(81156014)(8676002)(6512007)(68736007)(53936002)(14454004)(6486002)(36756003)(189998001)(105586002)(106356001)(7736002)(305945005)(6916009)(99286003)(6436002)(6116002)(77096006)(8936002)(110136004)(3280700002)(83716003)(4001350100001)(3846002)(478600001)(3660700001)(229853002)(2950100002)(54906002)(6246003)(2900100001)(2906002)(82746002)(97736004)(6506006)(5660300001)(230783001)(33656002)(76176999)(4326008)(66066001)(50986999)(54356999)(25786009)(101416001)(93886005); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1236; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <72E1A7CB568DE34A96D1A393DB6501A9@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2017 16:59:27.3156 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1236 Archived-At: Subject: Re: [netmod] regarding draft-bierman-netmod-yang-data-ext-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Sep 2017 16:59:32 -0000 DQoNCj4+IEdvdGNoYS4gIFdoYXQgZG8gb3RoZXIgcGVvcGxlIHRoaW5rLCB3b3VsZCBhICJ1c2Vz LXlhbmctZGF0YSINCj4+IHN0YXRlbWVudCBiZSBnZW5lcmFsbHkgbW9yZSB1c2VmdWw/DQo+DQo+ IEJ1dCBkb2VzIHRoaXMgbWVhbiB3ZSBhbHNvIGRvIHVzZXMteWFuZy1jb250YWluZXIsIHVzZXMt eWFuZy1saXN0LA0KPiB1c2VzLXlhbmcteHl6IHRvIG90aGVyIGRlZmluaXRpb25zIGFzIHdlbGw/ IEkgZG8gbm90IHRoaW5rIHRoaXMgaXMNCj4gZGVzaXJhYmxlIGFuZCB3aHkgd291bGQgeWFuZy1k YXRhIGJlIGFueSBkaWZmZXJlbnQ/DQoNCg0KT2gsIG5vLiAgSSB2aWV3IHlhbmctZGF0YSBhcyBh IGJvZHktc3RtdCwgbm90IGEgZGF0YS1kZWYtc3RtdCwNCmFraW4gdG8gJ3JwYycgYW5kICdub3Rp ZmljYXRpb24nLiAgQnV0IGJhY2sgdG8gdGhlIGRyYWZ0J3MgDQpwcm9wb3NlZCBzb2x1dGlvbiwg SSB1bmRlcnN0YW5kIHRoYXQgYXVnbWVudC1zdG10IGlzIGEgdG9wLWxldmVsIA0KYm9keS1zdG10 LCBidXQgaXQncyBhbHNvIGEgdXNlcy1zdG10LCBhbmQgaW4gdGhhdCBjb250ZXh0LCBpdCBpcw0K YSBzaWJsaW5nIHRvIHRoZSByZWZpbmUtc3RtdC4gIEFscmVhZHkgQU5JTUEgaGFzIGEgbmVlZCB0 byBib3RoDQphdWdtZW50IGFuZCByZWZpbmUgYSB5YW5nLWRhdGEgZGVmaW5lZCBzdHJ1Y3R1cmUu ICBUbyBtZSwgYQ0KJ3VzZXMteWFuZy1kYXRhJyBzdGF0ZW1lbnQgc2VlbXMganVzdCBvbmUgc3Rl cCBtb3JlIGdlbmVyYWwgdGhhbg0KYSAnYXVnbWVudC15YW5nLWRhdGEnIHN0YXRlbWVudC4NCg0K U3BlY2lhbGx5LCBpZiB3ZSB3ZXJlIHVwZGF0aW5nIFlBTkc6DQoNCiAgIC8vIGp1c3QgYWRkZWQg bGFzdCBlbnRyeQ0KICAgYm9keS1zdG10cyAgICAgICAgICA9ICooZXh0ZW5zaW9uLXN0bXQgLw0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgZmVhdHVyZS1zdG10IC8NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgIGlkZW50aXR5LXN0bXQgLw0KICAgICAgICAgICAgICAgICAgICAgICAgICAg dHlwZWRlZi1zdG10IC8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgIGdyb3VwaW5nLXN0bXQg Lw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgZGF0YS1kZWYtc3RtdCAvDQogICAgICAgICAg ICAgICAgICAgICAgICAgICBhdWdtZW50LXN0bXQgLw0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgcnBjLXN0bXQgLw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgbm90aWZpY2F0aW9uLXN0 bXQgLw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgZGV2aWF0aW9uLXN0bXQgLw0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgeWFuZy1kYXRhLXN0bXQpDQoNCiAgIC8vIHNvbWV0aGluZyBs aWtlIHRoaXM/DQogICB5YW5nLWRhdGEtc3RtdCAgICAgICAgICAgID0geWFuZy1kYXRhLWtleXdv cmQgc2VwIGlkZW50aWZpZXItYXJnLXN0ciBvcHRzZXANCiAgICAgICAgICAgICAgICAgICAgICAg ICAoIjsiIC8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgInsiIHN0bXRzZXANCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDs7IHRoZXNlIHN0bXRzIGNhbiBhcHBlYXIgaW4gYW55IG9y ZGVyDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbc3RhdHVzLXN0bXRdDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBbZGVzY3JpcHRpb24tc3RtdF0NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFtyZWZlcmVuY2Utc3RtdF0NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICoodHlwZWRlZi1zdG10IC8geWFuZy1kYXRhLWdyb3VwaW5nLXN0bXQpDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAqZGF0YS1kZWYtc3RtdA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgW3VzZXMteWFuZy1kYXRhLXN0bXRdDQogICAgICAgICAgICAgICAgICAgICAg ICAgICJ9Iikgc3RtdHNlcA0KDQogICAvLyBsaWtlICd1c2VzLXN0bXQnLCBidXQgd2l0aCBhIGRp ZmZlcmVudCBrZXl3b3JkDQogICB1c2VzLXlhbmctZGF0YS1zdG10ICAgICAgID0gdXNlcy15YW5n LWRhdGEta2V5d29yZCBzZXAgaWRlbnRpZmllci1yZWYtYXJnLXN0ciBvcHRzZXANCiAgICAgICAg ICAgICAgICAgICAgICAgICAoIjsiIC8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgInsiIHN0 bXRzZXANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDs7IHRoZXNlIHN0bXRzIGNhbiBh cHBlYXIgaW4gYW55IG9yZGVyDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbd2hlbi1z dG10XQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKmlmLWZlYXR1cmUtc3RtdA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgW3N0YXR1cy1zdG10XQ0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgW2Rlc2NyaXB0aW9uLXN0bXRdDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBbcmVmZXJlbmNlLXN0bXRdDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAq cmVmaW5lLXN0bXQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICp1c2VzLWF1Z21lbnQt c3RtdA0KICAgICAgICAgICAgICAgICAgICAgICAgICAifSIpIHN0bXRzZXANCg0KICAgLy8gbGlr ZSAnZ3JvdXBpbmctc3RtdCcsIGJ1dCB3aXRoICdhY3Rpb24nIGFuZCAnbm90aWZpY2F0aW9uJyBy ZW1vdmVkDQogICB5YW5nLWRhdGEtZ3JvdXBpbmctc3RtdCAgICAgICA9IHlhbmctZGF0YS1ncm91 cGluZy1rZXl3b3JkIHNlcCBpZGVudGlmaWVyLWFyZy1zdHIgb3B0c2VwDQogICAgICAgICAgICAg ICAgICAgICAgICAgKCI7IiAvDQogICAgICAgICAgICAgICAgICAgICAgICAgICJ7IiBzdG10c2Vw DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA7OyB0aGVzZSBzdG10cyBjYW4gYXBwZWFy IGluIGFueSBvcmRlcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW3N0YXR1cy1zdG10 XQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW2Rlc2NyaXB0aW9uLXN0bXRdDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBbcmVmZXJlbmNlLXN0bXRdDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAqKHR5cGVkZWYtc3RtdCAvIHlhbmctZGF0YS1ncm91cGluZy1zdG10 KQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKmRhdGEtZGVmLXN0bXQNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgIn0iKSBzdG10c2VwDQoNCg0KICAgeWFuZy1kYXRhLWtleXdvcmQg ICAgICAgICAgICAgID0gJXMieWFuZy1kYXRhIg0KICAgdXNlcy15YW5nLWRhdGEta2V5d29yZCAg ICAgICAgID0gJXMidXNlcy15YW5nLWRhdGEiDQogICB5YW5nLWRhdGEtZ3JvdXBpbmcta2V5d29y ZCAgICAgPSAlcyJ5YW5nLWRhdGEtZ3JvdXBpbmciDQoNCg0KSG93IGNsb3NlIHRvIHRoaXMgY2Fu IHdlIGdldCB1c2luZyBhbiBleHRlbnNpb24gc3RhdGVtZW50LCBzbyB0aGF0IGENCmZ1dHVyZSBh ZG9wdGlvbiB0byBZQU5HIHdpbGwgYmUgYXMgc2VhbWxlc3MgYXMgcG9zc2libGU/DQoNCksuDQoN Cg0K From nobody Sat Sep 2 11:02:48 2017 Return-Path: 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 7D40F132FAC for ; Sat, 2 Sep 2017 11:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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, URIBL_BLOCKED=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 FWSKjX_0Ld46 for ; Sat, 2 Sep 2017 11:02:44 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86D58132F6D for ; Sat, 2 Sep 2017 11:02:44 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id t134so3412309ita.0 for ; Sat, 02 Sep 2017 11:02:44 -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=1lW0VGCA1wn4/XDP35kGe9TY4pVE7KrFvzAyI2zcOKw=; b=EX+gnaefv3fAvc8crNNtZ51Up8O0xCrkjBxX0fttp50VbNSQE2qxhBinfquvLcumnS //8yNQ0uREQxQzSFFqVNVbcEyqiREfbj7JqBQePqJNp5O/LlAufKlpqrKaTtyborhFMU e2baX3CsRfV2ASRjSdU/W7YGAVFTcwgHfu+KaP6dQvD/XUmT5hNaowyzUb6mQuupwj0z RdZ9OHMdYiR/Z5bD++48pSH3kULDnYqAzWpInDnnQ88btdhIxK+JwmWctp8gtSxZiHQf ohDEDdI8VZ5eLVSX27GnFdWvQm50Q8NxUwbTKHiMuv8VJnFypm6/PTCEi3PyDm1Sn1GE u+tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1lW0VGCA1wn4/XDP35kGe9TY4pVE7KrFvzAyI2zcOKw=; b=fyd6Xt4uoxOqPDjgeRT1PxTd2qWxO9jy4fEMvjCVND2mPUz4kPCzD+J9PE6vQHak0y ZWhS8G5u1ORJ1euXvonMNUWjgHj2qizONwvoshDxFdGyy6HGVaEbone92rPMlLA8FdkB ytir37DgHSWeXuK0Ebg/mkvH1J+kFDKh/OKCCPhjRpzmgh5Gf4C/rFu0SgB2CvV5H261 vuMchqUp26C4Tci8NWliKEMS4sgfvC6/cYC3Pnx1HLyqGxb6cDDlzrGJpBaaO6PqBHX2 dj4jn5X+Z3OSB0N+0W4nv4b5PLdsap6ZtTw7EL6uSoqtEz44HTz3cEBSzpgrC+SVhWAF lQpQ== X-Gm-Message-State: AHPjjUgrTNLIME5302zjnRLmFImQaIj17KMqF1Wg2fR4nQdwos9DoGve aO0r/BNM+e4VVGzWkhG2imtO2UqMvlKa X-Google-Smtp-Source: ADKCNb7usMQYIaQtbeEtysFLXM8JYKZe9dU6lftku7umu+zGL7AS1kpR8ZFMeeyWi3oZGJd/WERrLLtfd8nIU3QbjKw= X-Received: by 10.36.36.210 with SMTP id f201mr1757034ita.24.1504375363679; Sat, 02 Sep 2017 11:02:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.6.206 with HTTP; Sat, 2 Sep 2017 11:02:42 -0700 (PDT) In-Reply-To: References: <57AA997C-6E52-49D2-B6AF-7DDE8F13D7B3@juniper.net> <56D58AA8-E71E-4CA1-B81E-70E2EDD94E91@juniper.net> <20170901205511.3hgalynjpur2gjqf@elstar.local> From: Andy Bierman Date: Sat, 2 Sep 2017 11:02:42 -0700 Message-ID: To: Kent Watsen Cc: Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="001a1147c68e294f05055838af7c" Archived-At: Subject: Re: [netmod] regarding draft-bierman-netmod-yang-data-ext-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Sep 2017 18:02:46 -0000 --001a1147c68e294f05055838af7c Content-Type: text/plain; charset="UTF-8" Hi, The use-cases for groupings/uses and augment are not identical. Alternative NMDA Approach: I don't see a big difference between defining YANG for an artifact vs. defining some YANG for a special-purpose datastore. There is nothing about the YANG data that is different. There are only differences in the operations on that data, which are properties of the datastore. Perhaps an datastore is a cleaner long-term solution. Andy On Sat, Sep 2, 2017 at 9:59 AM, Kent Watsen wrote: > > > >> Gotcha. What do other people think, would a "uses-yang-data" > >> statement be generally more useful? > > > > But does this mean we also do uses-yang-container, uses-yang-list, > > uses-yang-xyz to other definitions as well? I do not think this is > > desirable and why would yang-data be any different? > > > Oh, no. I view yang-data as a body-stmt, not a data-def-stmt, > akin to 'rpc' and 'notification'. But back to the draft's > proposed solution, I understand that augment-stmt is a top-level > body-stmt, but it's also a uses-stmt, and in that context, it is > a sibling to the refine-stmt. Already ANIMA has a need to both > augment and refine a yang-data defined structure. To me, a > 'uses-yang-data' statement seems just one step more general than > a 'augment-yang-data' statement. > > Specially, if we were updating YANG: > > // just added last entry > body-stmts = *(extension-stmt / > feature-stmt / > identity-stmt / > typedef-stmt / > grouping-stmt / > data-def-stmt / > augment-stmt / > rpc-stmt / > notification-stmt / > deviation-stmt / > yang-data-stmt) > > // something like this? > yang-data-stmt = yang-data-keyword sep identifier-arg-str > optsep > (";" / > "{" stmtsep > ;; these stmts can appear in any order > [status-stmt] > [description-stmt] > [reference-stmt] > *(typedef-stmt / yang-data-grouping-stmt) > *data-def-stmt > [uses-yang-data-stmt] > "}") stmtsep > > // like 'uses-stmt', but with a different keyword > uses-yang-data-stmt = uses-yang-data-keyword sep > identifier-ref-arg-str optsep > (";" / > "{" stmtsep > ;; these stmts can appear in any order > [when-stmt] > *if-feature-stmt > [status-stmt] > [description-stmt] > [reference-stmt] > *refine-stmt > *uses-augment-stmt > "}") stmtsep > > // like 'grouping-stmt', but with 'action' and 'notification' removed > yang-data-grouping-stmt = yang-data-grouping-keyword sep > identifier-arg-str optsep > (";" / > "{" stmtsep > ;; these stmts can appear in any order > [status-stmt] > [description-stmt] > [reference-stmt] > *(typedef-stmt / yang-data-grouping-stmt) > *data-def-stmt > "}") stmtsep > > > yang-data-keyword = %s"yang-data" > uses-yang-data-keyword = %s"uses-yang-data" > yang-data-grouping-keyword = %s"yang-data-grouping" > > > How close to this can we get using an extension statement, so that a > future adoption to YANG will be as seamless as possible? > > K. > > > --001a1147c68e294f05055838af7c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+SGksPGRpdj48YnI+PC9kaXY+PGRpdj5UaGUgdXNlLWNhc2VzIGZvciBn cm91cGluZ3MvdXNlcyBhbmQgYXVnbWVudCBhcmUgbm90IGlkZW50aWNhbC48L2Rpdj48ZGl2Pjxi cj48L2Rpdj48ZGl2PkFsdGVybmF0aXZlIE5NREEgQXBwcm9hY2g6PC9kaXY+PGRpdj48YnI+PC9k aXY+PGRpdj5JIGRvbiYjMzk7dCBzZWUgYSBiaWcgZGlmZmVyZW5jZSBiZXR3ZWVuIGRlZmluaW5n IFlBTkcgZm9yIGFuIGFydGlmYWN0IHZzLjwvZGl2PjxkaXY+ZGVmaW5pbmcgc29tZSBZQU5HIGZv ciBhIHNwZWNpYWwtcHVycG9zZSBkYXRhc3RvcmUuPC9kaXY+PGRpdj5UaGVyZSBpcyBub3RoaW5n IGFib3V0IHRoZSBZQU5HIGRhdGEgdGhhdCBpcyBkaWZmZXJlbnQuPC9kaXY+PGRpdj5UaGVyZSBh cmUgb25seSBkaWZmZXJlbmNlcyBpbiB0aGUgb3BlcmF0aW9ucyBvbiB0aGF0IGRhdGEsPC9kaXY+ PGRpdj53aGljaCBhcmUgcHJvcGVydGllcyBvZiB0aGUgZGF0YXN0b3JlLiBQZXJoYXBzIGFuICZs dDthcnRpZmFjdCZndDsgZGF0YXN0b3JlPC9kaXY+PGRpdj5pcyBhIGNsZWFuZXIgbG9uZy10ZXJt IHNvbHV0aW9uLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+QW5keTwv ZGl2PjxkaXY+PGJyPjwvZGl2PjwvZGl2PjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+PGRp diBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFNhdCwgU2VwIDIsIDIwMTcgYXQgOTo1OSBBTSwgS2Vu dCBXYXRzZW4gPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86a3dhdHNlbkBqdW5p cGVyLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmt3YXRzZW5AanVuaXBlci5uZXQ8L2E+Jmd0Ozwvc3Bh bj4gd3JvdGU6PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdp bjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgi Pjxicj4NCjxicj4NCiZndDsmZ3Q7IEdvdGNoYS7CoCBXaGF0IGRvIG90aGVyIHBlb3BsZSB0aGlu aywgd291bGQgYSAmcXVvdDt1c2VzLXlhbmctZGF0YSZxdW90Ozxicj4NCiZndDsmZ3Q7IHN0YXRl bWVudCBiZSBnZW5lcmFsbHkgbW9yZSB1c2VmdWw/PGJyPg0KJmd0Ozxicj4NCiZndDsgQnV0IGRv ZXMgdGhpcyBtZWFuIHdlIGFsc28gZG8gdXNlcy15YW5nLWNvbnRhaW5lciwgdXNlcy15YW5nLWxp c3QsPGJyPg0KJmd0OyB1c2VzLXlhbmcteHl6IHRvIG90aGVyIGRlZmluaXRpb25zIGFzIHdlbGw/ IEkgZG8gbm90IHRoaW5rIHRoaXMgaXM8YnI+DQomZ3Q7IGRlc2lyYWJsZSBhbmQgd2h5IHdvdWxk IHlhbmctZGF0YSBiZSBhbnkgZGlmZmVyZW50Pzxicj4NCjxicj4NCjxicj4NCk9oLCBuby7CoCBJ IHZpZXcgeWFuZy1kYXRhIGFzIGEgYm9keS1zdG10LCBub3QgYSBkYXRhLWRlZi1zdG10LDxicj4N CmFraW4gdG8gJiMzOTtycGMmIzM5OyBhbmQgJiMzOTtub3RpZmljYXRpb24mIzM5Oy7CoCBCdXQg YmFjayB0byB0aGUgZHJhZnQmIzM5O3M8YnI+DQpwcm9wb3NlZCBzb2x1dGlvbiwgSSB1bmRlcnN0 YW5kIHRoYXQgYXVnbWVudC1zdG10IGlzIGEgdG9wLWxldmVsPGJyPg0KYm9keS1zdG10LCBidXQg aXQmIzM5O3MgYWxzbyBhIHVzZXMtc3RtdCwgYW5kIGluIHRoYXQgY29udGV4dCwgaXQgaXM8YnI+ DQphIHNpYmxpbmcgdG8gdGhlIHJlZmluZS1zdG10LsKgIEFscmVhZHkgQU5JTUEgaGFzIGEgbmVl ZCB0byBib3RoPGJyPg0KYXVnbWVudCBhbmQgcmVmaW5lIGEgeWFuZy1kYXRhIGRlZmluZWQgc3Ry dWN0dXJlLsKgIFRvIG1lLCBhPGJyPg0KJiMzOTt1c2VzLXlhbmctZGF0YSYjMzk7IHN0YXRlbWVu dCBzZWVtcyBqdXN0IG9uZSBzdGVwIG1vcmUgZ2VuZXJhbCB0aGFuPGJyPg0KYSAmIzM5O2F1Z21l bnQteWFuZy1kYXRhJiMzOTsgc3RhdGVtZW50Ljxicj4NCjxicj4NClNwZWNpYWxseSwgaWYgd2Ug d2VyZSB1cGRhdGluZyBZQU5HOjxicj4NCjxicj4NCsKgIMKgLy8ganVzdCBhZGRlZCBsYXN0IGVu dHJ5PGJyPg0KwqAgwqBib2R5LXN0bXRzwqAgwqAgwqAgwqAgwqAgPSAqKGV4dGVuc2lvbi1zdG10 IC88YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGZlYXR1cmUt c3RtdCAvPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqBpZGVu dGl0eS1zdG10IC88YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oHR5cGVkZWYtc3RtdCAvPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqBncm91cGluZy1zdG10IC88YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoGRhdGEtZGVmLXN0bXQgLzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgYXVnbWVudC1zdG10IC88YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoHJwYy1zdG10IC88YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoG5vdGlmaWNhdGlvbi1zdG10IC88YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoGRldmlhdGlvbi1zdG10IC88YnI+DQrCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoHlhbmctZGF0YS1zdG10KTxicj4NCjxi cj4NCsKgIMKgLy8gc29tZXRoaW5nIGxpa2UgdGhpcz88YnI+DQrCoCDCoHlhbmctZGF0YS1zdG10 wqAgwqAgwqAgwqAgwqAgwqAgPSB5YW5nLWRhdGEta2V5d29yZCBzZXAgaWRlbnRpZmllci1hcmct c3RyIG9wdHNlcDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgKCZx dW90OzsmcXVvdDsgLzxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg ICZxdW90O3smcXVvdDsgc3RtdHNlcDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIDs7IHRoZXNlIHN0bXRzIGNhbiBhcHBlYXIgaW4gYW55IG9yZGVyPGJy Pg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgW3N0YXR1cy1z dG10XTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFtk ZXNjcmlwdGlvbi1zdG10XTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIFtyZWZlcmVuY2Utc3RtdF08YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCAqKHR5cGVkZWYtc3RtdCAvIHlhbmctZGF0YS1ncm91cGluZy1z dG10KTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICpk YXRhLWRlZi1zdG10PGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgW3VzZXMteWFuZy1kYXRhLXN0bXRdPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgJnF1b3Q7fSZxdW90Oykgc3RtdHNlcDxicj4NCjxicj4NCsKgIMKgLy8g bGlrZSAmIzM5O3VzZXMtc3RtdCYjMzk7LCBidXQgd2l0aCBhIGRpZmZlcmVudCBrZXl3b3JkPGJy Pg0KwqAgwqB1c2VzLXlhbmctZGF0YS1zdG10wqAgwqAgwqAgwqA9IHVzZXMteWFuZy1kYXRhLWtl eXdvcmQgc2VwIGlkZW50aWZpZXItcmVmLWFyZy1zdHIgb3B0c2VwPGJyPg0KwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAoJnF1b3Q7OyZxdW90OyAvPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgJnF1b3Q7eyZxdW90OyBzdG10c2VwPGJyPg0K wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgOzsgdGhlc2Ugc3Rt dHMgY2FuIGFwcGVhciBpbiBhbnkgb3JkZXI8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBbd2hlbi1zdG10XTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICppZi1mZWF0dXJlLXN0bXQ8YnI+DQrCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBbc3RhdHVzLXN0bXRdPGJyPg0KwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgW2Rlc2NyaXB0aW9uLXN0 bXRdPGJyPg0KwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgW3Jl ZmVyZW5jZS1zdG10XTxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgICpyZWZpbmUtc3RtdDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgICp1c2VzLWF1Z21lbnQtc3RtdDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgICZxdW90O30mcXVvdDspIHN0bXRzZXA8YnI+DQo8YnI+DQrCoCDC oC8vIGxpa2UgJiMzOTtncm91cGluZy1zdG10JiMzOTssIGJ1dCB3aXRoICYjMzk7YWN0aW9uJiMz OTsgYW5kICYjMzk7bm90aWZpY2F0aW9uJiMzOTsgcmVtb3ZlZDxicj4NCsKgIMKgeWFuZy1kYXRh LWdyb3VwaW5nLXN0bXTCoCDCoCDCoCDCoD0geWFuZy1kYXRhLWdyb3VwaW5nLWtleXdvcmQgc2Vw IGlkZW50aWZpZXItYXJnLXN0ciBvcHRzZXA8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCgmcXVvdDs7JnF1b3Q7IC88YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCAmcXVvdDt7JnF1b3Q7IHN0bXRzZXA8YnI+DQrCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCA7OyB0aGVzZSBzdG10cyBjYW4gYXBwZWFy IGluIGFueSBvcmRlcjxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIFtzdGF0dXMtc3RtdF08YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBbZGVzY3JpcHRpb24tc3RtdF08YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBbcmVmZXJlbmNlLXN0bXRdPGJyPg0KwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgKih0eXBlZGVmLXN0bXQgLyB5YW5n LWRhdGEtZ3JvdXBpbmctc3RtdCk8YnI+DQrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCAqZGF0YS1kZWYtc3RtdDxicj4NCsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgICZxdW90O30mcXVvdDspIHN0bXRzZXA8YnI+DQo8YnI+DQo8YnI+DQrC oCDCoHlhbmctZGF0YS1rZXl3b3JkwqAgwqAgwqAgwqAgwqAgwqAgwqAgPSAlcyZxdW90O3lhbmct ZGF0YSZxdW90Ozxicj4NCsKgIMKgdXNlcy15YW5nLWRhdGEta2V5d29yZMKgIMKgIMKgIMKgIMKg PSAlcyZxdW90O3VzZXMteWFuZy1kYXRhJnF1b3Q7PGJyPg0KwqAgwqB5YW5nLWRhdGEtZ3JvdXBp bmcta2V5d29yZMKgIMKgIMKgPSAlcyZxdW90O3lhbmctZGF0YS1ncm91cGluZyZxdW90Ozxicj4N Cjxicj4NCjxicj4NCkhvdyBjbG9zZSB0byB0aGlzIGNhbiB3ZSBnZXQgdXNpbmcgYW4gZXh0ZW5z aW9uIHN0YXRlbWVudCwgc28gdGhhdCBhPGJyPg0KZnV0dXJlIGFkb3B0aW9uIHRvIFlBTkcgd2ls bCBiZSBhcyBzZWFtbGVzcyBhcyBwb3NzaWJsZT88YnI+DQo8c3BhbiBjbGFzcz0iSE9FblpiIj48 Zm9udCBjb2xvcj0iIzg4ODg4OCI+PGJyPg0KSy48YnI+DQo8YnI+DQo8YnI+DQo8L2ZvbnQ+PC9z cGFuPjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+DQo= --001a1147c68e294f05055838af7c-- From nobody Mon Sep 4 00:26:24 2017 Return-Path: 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 5E033132199 for ; Mon, 4 Sep 2017 00:26:24 -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 b6K0Jdu5spOY for ; Mon, 4 Sep 2017 00:26:22 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9A3126C7A for ; Mon, 4 Sep 2017 00:26:22 -0700 (PDT) Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id E8D0A1AE00A0; Mon, 4 Sep 2017 09:26:19 +0200 (CEST) Date: Mon, 04 Sep 2017 09:29:13 +0200 (CEST) Message-Id: <20170904.092913.858833299379016670.mbj@tail-f.com> To: andy@yumaworks.com Cc: kwatsen@juniper.net, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <56D58AA8-E71E-4CA1-B81E-70E2EDD94E91@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=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] regarding draft-bierman-netmod-yang-data-ext-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 07:26:24 -0000 Andy Bierman wrote: > On Fri, Sep 1, 2017 at 10:43 AM, Kent Watsen wrote: [Re: moving the definition of rc:yang-data to a new document] > > > > > We went through that issue at least twice before RFC 8040. > > > > > There was no concern about this extension being in the RESTCONF spec. > > > > > > > > I don't think people understood what was at stake at the time - yang-data > > has since taken on more prominence. You write "no concern", but I think > > it was more like "no response", and the solution just rolled on. > > > > I think I explained it well enough at the time. > There is a normative reference to RESTCONF to use yang-data. > This is just an RFC detail. In a server, the yang-library can indicate > that ietf-restconf is just imported (not implemented). It really does not > matter > that this extension is in ietf-restconf.yang. > > > > > > > > > > > > > > We really have to try to keep the documents stable, and not republish an > > RFC > > > > > just to move definitions around. > > > > > > > > We are talking about a new RFC (this draft). I don't care if 8040 ever > > uses the new yang-data statement, it can forever have its own private > > definition. I do care that we introduce a long-term solution (again, > > augment alone seems limited) and would like to make an incremental > > improvement for normative references. > > > > > > > > IMO it is not worth the trouble. If it wasn't for the new 'augment-yang-data' statement, I'd agree. But if we're doing a new standalone document for 'augment-yang-data', I think we should also define 'yang-data' in that document. The cost is minimal, and we get one self-contained document with all things related to 'yang-data'. /martin From nobody Mon Sep 4 01:12:10 2017 Return-Path: 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 04594132199 for ; Mon, 4 Sep 2017 01:12:09 -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 as7U7DAXgDuV for ; Mon, 4 Sep 2017 01:12: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 0C2E3126D0C for ; Mon, 4 Sep 2017 01:12:05 -0700 (PDT) Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 236761AE00A0; Mon, 4 Sep 2017 10:12:05 +0200 (CEST) Date: Mon, 04 Sep 2017 10:14:59 +0200 (CEST) Message-Id: <20170904.101459.32252942329486377.mbj@tail-f.com> To: rwilton@cisco.com Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20170821.140610.1599460825983098893.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=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-rfc7277bis-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 08:12:09 -0000 Hi, Thanks for reviewing this document! Robert Wilton wrote: > Hi Martin, > = > I have reviewed this document (mainly as a diff against the 7277). > = > In summary, the transformation to NMDA looks good. =A0 Given that it = is > a fairly formulaic conversion, I hope that the WG will be able to > quickly move to WG adoption, and even WG last call! > = > = > I did have a few minor comments (and spotted one bug): > = > 1. leaf "origin" under IPv4 neighbors should be marked as "config > false". Fixed. > 2. Sometimes the YANG module description refers to "the intended > configuration datastore" or "the operational state datastore", but I > think that it would be better to just refer to "intended > configuration" and "operational state". Yes I agree, and I actually inteded to use the term "intended configuration" and "operational state", but missed that. The terminology should be aligned in all our documents, so I'll make sure to use this terminology also in the hardware (entity) draft, and the interfaces draft. > =A0 I.e. I think that it is OK > for the draft to reference the different datastores, but I think that= > it might be better if the YANG modules don't.=A0 This is partly in th= e > sense that the YANG modules are just schema for configuration and > state data, and that I see the use of datastores is effectively an > IETF decision on how that configuration/state is instantiated. > = > To take the analogy further, I think that the it is conceivable that > the source OpenConfig YANG models could also be usefully structured i= n > the same NMDA style.=A0 This would allow the OpenConfig models to wor= k > better with NETCONF/RESTCONF implementations that support NMDA.=A0 An= > alternative implementation choice would be to use a script to convert= > NMDA style OpenConfig YANG models to equivalent existing OpenConfig > style with their split config/state containers. > = > A second justification (if you don't like the one above), is that the= > configurable leaves could also be set via a dynamic configuration > datastore such as via I2RS, hence it wouldn't necessarily always be > via the intended datastore. > = > = > 3. I think that it might be useful to add a comment to the IPv6 > link-layer-address leaf description to indicate that it wouldn't > expect to be populated if the associated "state" is set to > "incomplete". Ok, done. /martin > = > = > Thanks, > Rob > = > = > On 21/08/2017 13:06, Martin Bjorklund wrote: > > Hi, > > > > This document defines an NMDA-compliant update to the IP model > > (RFC 7277). > > > > I would like to ask the WG to adopt this individual draft as a work= ing > > group document. > > > > > > /martin > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > = From nobody Mon Sep 4 01:12:28 2017 Return-Path: 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 E76C7132392 for ; Mon, 4 Sep 2017 01:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] 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 BQ14n8qWSQkM for ; Mon, 4 Sep 2017 01:12:25 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 EB60813237B for ; Mon, 4 Sep 2017 01:12:21 -0700 (PDT) Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 3767761109; Mon, 4 Sep 2017 10:12:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1504512740; bh=CeJ2a195+HJ/o3qnjQmWhWnNezeVmy84XE7qGFslSGE=; h=From:To:Date; b=QbSeubmtqnG40zPEYzMKiRVaEAvb5sxcsTX6JSQOHTG/JnLAuz/5WZ1LsRHBWlMHl AT0KpwUFa6RhbfjeIxjhw6n9cX2P/R86Yshf/EbKdBG+tZ9rdzvd1qeVHn1ZFU0gE6 11YqBpb3QDo8vZ5r6fsQY+Dv9IUaYZPYZ1iLS2wI= Message-ID: <1504512772.5874.4.camel@nic.cz> From: Ladislav Lhotka To: Juergen Schoenwaelder , RFC Errata System Cc: bclaise@cisco.com, warren@kumari.net, kwatsen@juniper.net, lberger@labn.net, netmod@ietf.org Date: Mon, 04 Sep 2017 10:12:52 +0200 In-Reply-To: <20170901164841.ebs2fqvf2vl3adlx@elstar.local> References: <20170901144056.60AC4B80E23@rfc-editor.org> <20170901164841.ebs2fqvf2vl3adlx@elstar.local> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.5 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] [Technical Errata Reported] RFC6991 (5105) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 08:12:28 -0000 Juergen Schoenwaelder píše v Pá 01. 09. 2017 v 18:48 +0200: > On Fri, Sep 01, 2017 at 07:40:56AM -0700, RFC Errata System wrote: > > The following errata report has been submitted for RFC6991, > > "Common YANG Data Types". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata/eid5105 > > > > -------------------------------------- > > Type: Technical > > Reported by: Ladislav Lhotka > > > > Section: 3 > > > > Original Text > > ------------- > > A schema node of this type will be set to zero (0) on creation > > and will thereafter increase monotonically until it reaches > > a maximum value of 2^32-1 (4294967295 decimal), when it > > wraps around and starts increasing again from zero. > > > > Corrected Text > > -------------- > > A leaf instance of this type will be set to zero (0) on creation > > and will thereafter increase monotonically until it reaches > > a maximum value of 2^32-1 (4294967295 decimal), when it > > wraps around and starts increasing again from zero. > > > > Notes > > ----- > > In a number of descriptions in both ietf-yang-types and ietf-inet-types, the term "schema node" is used incorrectly in places where "leaf instance" or "instance of a leaf" should be used instead. However, not all occurences of "schema node" are wrong: schema nodes just have to be distinguished from nodes in an instance data tree. > > > > Yes. I would probably prefer 'a data node instance of this type' > instead of 'a leaf instance' - I am not sure I would to exclude a > leaf-list and who knows whether we have any other data nodes in the > future. And yes, all occurances of 'schema node' need careful OK. > inspection. I am not sure whether you want to identify all occurances > now or whether you wanted to have a generic errata just so that we do > not forget to fix this when this document is revised. I think it should suffice to keep this general erratum and fixed it in the next revision. Thanks, Lada > > /js > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Sep 4 04:04:48 2017 Return-Path: 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 585C5126DD9 for ; Mon, 4 Sep 2017 04:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 sy4VdrRj0n0V for ; Mon, 4 Sep 2017 04:04:46 -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 8439E1241FC for ; Mon, 4 Sep 2017 04:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2393; q=dns/txt; s=iport; t=1504523085; x=1505732685; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=u4OgE9vP5KFT4aBhPUMtyrFvxpfuCdF6zp8MUyV+Usc=; b=elGEeMp6DLJjaOuj+3l4BpOTBbkVSk2+vUcrT9MGy1FvEhaRJlAU+OIj fJbeV+jdxQIPKMn57XgCZGdu13REQhJ1Q6Ucy/UEnG3IwRB4ezsj6iKoo 11kkpLZ8I696E1ITUMbcCHQhVFHMQGyxtGmhZoEd390DtCRQ/Ybmz0o2I 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuAgCzMK1Z/xbLJq1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBiUqLFJEbmDoKhT4ChF4UAQIBAQEBAQEBayiFGAEBAQECASMPAQVRCxg?= =?us-ascii?q?CAiYCAlcGAQwIAQGKJQi1aIIni08BAQEBAQEBAQIBAQEBAQEBIYENgh2DUIIOg?= =?us-ascii?q?n2ICIJhBaB0lFGLVIcdjVeHKQMGBQIZgTk2IYENMiEIHBWHZT+LVQEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,474,1498521600"; d="scan'208";a="696957031" 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; 04 Sep 2017 11:04:43 +0000 Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v84B4hnp003070; Mon, 4 Sep 2017 11:04:43 GMT To: Alex Campbell , "netmod@ietf.org" References: <20170830102902.2n5q6rgq2x2dxfq2@elstar.local> <20170830123156.cssrg5kklpo67fie@elstar.local> <1504223854014.55228@Aviatnet.com> <847e5bf9-7b3d-9ff8-9954-970f32a2094c@cisco.com> <20170902073342.xoziwor4tdr5bipw@elstar.local> From: Robert Wilton Message-ID: Date: Mon, 4 Sep 2017 12:04:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170902073342.xoziwor4tdr5bipw@elstar.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 11:04:47 -0000 Hi Juergen, On 02/09/2017 08:33, Juergen Schoenwaelder wrote: > On Fri, Sep 01, 2017 at 10:45:51AM +0100, Robert Wilton wrote: >> Hi Alex, >> >> >> On 01/09/2017 00:57, Alex Campbell wrote: >>> Hi, >>> >>> >>> I'd be very wary of adding guidelines that restrict the regex syntax. >>> >>> >>> A tool that supports YANG must implement the full regex language anyway >>> (or ignore regexes altogether if they are not relevant to the tool's >>> function). >>> >> This is true if the tool is designed to work with any arbitrary YANG >> module.  But if a tool only needs to work with a subset of YANG modules >> (e.g. perhaps just IETF, OpenConfig, and Vendor models) then they only need >> to support the subset of the XML RE language that is used by the YANG >> modules that they load. >> > Rob, > > you are on the path to create multiple flavours of YANG, an IETF > flavour, an OC flavour, a Vendor XYZ flavour - in my view this can't > be the goal of a standard. This is the actually the polar opposite of my aim.  My aim is to try and stop the fragmentation that is already happening in the industry, via what I perceive is a pragmatic compromise.  I appreciate others feel differently. I.e. make XML RE easy enough to use that others in the industry don't feel that they need to fork YANG for this reason.  My understanding is that for the OpenConfig YANG models authors, the "must use an XML RE implementation argument" doesn't seem to be working, in that their models are currently defined using POSIX regex pattern statements that are certainly incompatible with XML RE (they have anchors).  Although my understanding is that they may move to define a separate "posix pattern" statement instead, I would guess that they will probably only use the "posix pattern" statement in their models and not define both the POSIX and XML RE expressions. So, as it stands today, I think that we will either already end up with effective multiple flavours of YANG, or that YANG implementations will need to support both XML RE and POSIX RE implementations.  I think that is a worse outcome for the wider industry than just encouraging people to only use a pragmatic subset of XML RE for network management YANG models. Rob > > A compliant implementation of YANG 1.0 and YANG 1.1 must handle XSD > pattern. > > /js > From nobody Mon Sep 4 04:18:27 2017 Return-Path: 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 16DA513292B for ; Mon, 4 Sep 2017 04:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 ZoVkAm21kG_v for ; Mon, 4 Sep 2017 04:18:23 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 A8FB91320CF for ; Mon, 4 Sep 2017 04:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v84BI921007797; Mon, 4 Sep 2017 13:18:09 +0200 (CEST) Received: from [192.168.217.124] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3xm6lj2zYpzDLpn; Mon, 4 Sep 2017 13:18:09 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Mon, 4 Sep 2017 13:18:08 +0200 Cc: Alex Campbell , "netmod@ietf.org" X-Mao-Original-Outgoing-Id: 526216687.990243-512ad12e7549ced14f7f233fc7c38eea Content-Transfer-Encoding: quoted-printable Message-Id: <90927C99-0BE9-488D-AB96-ACEBBE3F0F14@tzi.org> References: <20170830102902.2n5q6rgq2x2dxfq2@elstar.local> <20170830123156.cssrg5kklpo67fie@elstar.local> <1504223854014.55228@Aviatnet.com> <847e5bf9-7b3d-9ff8-9954-970f32a2094c@cisco.com> <20170902073342.xoziwor4tdr5bipw@elstar.local> To: Robert Wilton X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 11:18:25 -0000 I=E2=80=99m not going to say we have solved the underlying problem (too = many flavors of regular expression) completely for CDDL, but in CDDL we = are using PCRE with anchors then added: https://tools.ietf.org/html/draft-ietf-cbor-cddl-00#section-3.8.3 (And here is the implementation: h[k] =3D Regexp.new("\\A#{k}\\z") That should not be too hard to replicate in any language :-) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Sep 4 04:41:33 2017 Return-Path: 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 3285A1241FC for ; Mon, 4 Sep 2017 04:41:32 -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 lQeZKAG9jEAh for ; Mon, 4 Sep 2017 04:41: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 71DB2124E15 for ; Mon, 4 Sep 2017 04:41:29 -0700 (PDT) Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id C6C941AE00A0; Mon, 4 Sep 2017 13:41:27 +0200 (CEST) Date: Mon, 04 Sep 2017 13:44:23 +0200 (CEST) Message-Id: <20170904.134423.2046223123247669108.mbj@tail-f.com> To: bart.bogaert@nokia.com Cc: netmod@ietf.org, ludwig.pauwels@nokia.com, joey.boyd@adtran.com From: Martin Bjorklund In-Reply-To: References: <20170817.130222.702011777700824230.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: [netmod] What is the best way to HW identities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 11:41:32 -0000 Hi, I think there are two separate issues here. 1. A more flexible way to handle how parent-rel-pos is assigned by an implementation. 2. Handling of sub-classes to ianahw:hardware-class. For 1, I suggest we use this description for the parent-rel-class: "An indication of the relative position of this child component among all its sibling components. Sibling components are defined as components that: o Share the same value of the 'parent' node; and o Share a common base identity for the 'class' node. Note that the last rule gives implementations flexibility in how components are numbered. For example, some implementations might have a single number series for all components derived from 'ianahw:port', while some others might have different number series for different components with identities derived from 'ianahw:port' (for example, one for RJ45 and one for SFP)."; For 2, we (the WG) needs to decide if we want to allow for standard hardware subclasses. If so, we (just) need to inform IANA about the procedure for doing this. /martin "Bogaert, Bart (Nokia - BE/Antwerp)" wrote: > Hi Martin, > > Using this feedback, there is a basis to continue the work in BBF > > What is the best way to continue with the sub-classes w.r.t. IANA, who needs > to initiate this? Your reply seems to suggest that irrespective of this > email, still something was required? Anyhow, BBF can define sub-identities > to continue and align later when there would be standardized HW > sub-identities. > > Best regards, Bart > > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Thursday, August 17, 2017 1:02 PM > To: Bogaert, Bart (Nokia - BE/Antwerp) > Cc: netmod@ietf.org; joey.boyd@adtran.com; Pauwels, Ludwig (Nokia - > BE/Antwerp) > Subject: Re: [netmod] What is the best way to HW identities > > Hi, > > "Bogaert, Bart (Nokia - BE/Antwerp)" wrote: > > Hello, > > > > > > > > Within BBF we have had a discussion on the use of > > draft-ietf-netmod-entity-03, and we would appreciate to hear the > > opinion of IETF. More specific the discussion is on the use of the > > leaf 'class' and the leaf 'parent-rel-pos'. > > > > > > > > First some BBF context: > > > > - the systems for which BBF specifies YANG models can be built with > > various 'types of hardware', e.g. as pluggable item (module) it can > > contain boards and it can contain SFP/XFPs. As 'type of port' it can > > have connectors to terminate fastdsl links (supported over copper > > wires), and it can have positions to insert optical fibers (e.g. the > > position in the SFP in which one can plug the optical fiber). > > > > > > > > - in the data model we have the need for some conditional data: e.g. > > an SFP/XFP has some data that is defined in SFF-8472. This data is not > > applicable to boards. Hence we need to distinguish between these 2 > > types of pluggable items. A 2nd example: for the optical fibers > > terminated by an SFP/XFP, we have specific data that is also defined > > in SFF-8472, e.g. the wavelength. This data is not applicable to > > fastdsl ports. On fastdsl ports we have specific data that relates to > > remote power feeding. Obviously there is no power feeding over the > > optical fiber. There might be other ports with (for now) no specific > > data, e.g. an rj45. Conclusion: need data conditional to the port type. > > > > > > > > In draft-ietf-netmod-entity-03 we read > > > > - "The "class" leaf is a YANG identity that describes the type of the > > hardware. Vendors are encouraged to either directly use one of the > > common IANA-defined identities, or derive a more specific identity > > from one of them. > > > > > > > > - As description for 'parent-rel-pos': "An indication of the relative > > position of this child component among all its sibling components. > > Sibling components are defined as components that share the same > > instance values of each of the 'parent' and 'class' nodes. > > > > > > > > Based on what we read in the first bullet a thought was to specialize > > the various hardware-class identities. Examples: > > > > > > > > identity board { > > > > base ianahw:module; > > > > description > > > > "A board is a special type of module that represents a physical > > item, commonly known as a board or a card."; > > > > } > > > > > > > > identity transceiver { > > > > base ianahw:module; > > > > description > > > > "A transceiver is a special type of module that represents a > > physical item like a pluggable SFP, an SFP+, or an XFP; or a soldered > > SFF."; > > > > } > > > > > > > > identity transceiver-link { > > > > base ianahw:port; > > > > description > > > > "A transceiver-link is a special type of port that terminates an > > optical fiber."; > > > > } > > > > > > > > identity rj45 { > > > > base ianahw:port; > > > > description > > > > "A RJ45 is a special type of port that terminates an electrical > > Ethernet link."; > > > > } > > > > identity fastdsl { > > > > base ianahw:port; > > > > description > > > > "A fastdsl is a special type of port that terminates a copper > > wire supporting a FAST or one of the DSL types link."; > > > > } > > > > > > > > The intention with this approach: the 'class' leaf is used to > > distinguish between all types of hardware. If hardware specific data > > is augmented to the hardware model, then it is using a 'when' > > condition referring to the value of the leaf 'class'. > > > > > > > > Based on the description of the parent-rel-pos it is understood that > > the value of this leaf is relative to the value of the class, so > > numbering of e.g. the various types of port supported by one board is > > independent of each other. > > > > > > > > Then the worry starts: > > > > - some of the BBF members understand this concept of specializing the > > hardware identities and use these values for the leaf class as the way > > to go, and take the impact on the numbering as a given. > > > > > > > > - Others think this impact on the parent-rel-pos is not the intention > > and assume a flat numbering of all childs within a parent > > Good point. In the original model (i.e. the MIB), with fixed values for the > class, having separate numbering schemes for separate classes makes sense. > For example, if a certain board has a set of ports, some fans and a power > supply, it makes sense that these are numbered individually. > > However, with specialized ports, this may or may not make sense. > > It might be possible to define parent-rel-pos in a way that gives the > implementation some flexibility. For example, all ports could share the > same numbering scheme. The important thing in the current model is that > there must not exist two components with the same values for 'parent', > 'class', and 'parent-rel-pos'. (strictly speaking, there is no requirement > that the parent-rel-pos is always monotonically increasing amongst siblings, > so maybe this is possible even today) > > > , hence do not want to > > use the class leaf for further specialization, hence want to introduce > > a new separate leaf to contain the more detailed information, hence > > the conditional data for the various types of hardware shall be > > defined with a 'when statement' referring to this new separate leaf. > > > > > > > > The feedback we would appreciate from IETF: > > > > - did IETF consider the need for additional conditional data? > > Yes, the idea was to use the 'class' leaf for this. > > > - which approach is the IETF preference? > > I would prefer to see if we can find a definition of parent-rel-pos that > makes numbering work better so that the 'class' identity can be used for > specialization. > > > - in case the IETF preference is to specialize the hardware > > identities, does IETF think it is worth to standardize them in IANA, > > or is the preference to keep these identities within BBF? > > I don't know the answer to this question, but if we want to allow for > standardized sub-classes, we have to create a new IANA registry (or extend > the current one), since the current one only contains the top-level class > (hmm, I just realized that the document needs an updated IANA considerations > section anyway; it needs to mimic RFC > 7224 -- probably needs to create a common registry for hardware types from > which the MIB and YANG module can be generated) > > > /martin From nobody Mon Sep 4 07:05:07 2017 Return-Path: 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 2EBA3132A84 for ; Mon, 4 Sep 2017 07:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 0CLn0BNJmhP3 for ; Mon, 4 Sep 2017 07:05:03 -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 EDD25129C41 for ; Mon, 4 Sep 2017 07:05:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13180; q=dns/txt; s=iport; t=1504533903; x=1505743503; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=t2qh6xIusZ23PgDiWhn7wkK15i0oKxs8xtSY5d2Vtq8=; b=MQarm2WyJDMahwfV5DdR8sWFZDRGYVPgV88q5i1gN0SlZka/dxJvqv/o ECSWc5fzuY5dCcDm1Z6VJ9tPne3dNG96wwYg7XPtpnwVmDO5GWLNTOSev 8aJ4aOQsQCzPJqgxJ4TamuYKJlblSa3ht4Jd8BRwt1ohREwmlr0QV2dea U=; X-IronPort-AV: E=Sophos;i="5.41,474,1498521600"; d="scan'208,217";a="657235058" 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; 04 Sep 2017 14:05:01 +0000 Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v84E50rw026631; Mon, 4 Sep 2017 14:05:01 GMT To: Andy Bierman , Juergen Schoenwaelder , "Acee Lindem (acee)" , "netmod@ietf.org" References: <20170830102902.2n5q6rgq2x2dxfq2@elstar.local> <20170830123156.cssrg5kklpo67fie@elstar.local> <1504223854014.55228@Aviatnet.com> <847e5bf9-7b3d-9ff8-9954-970f32a2094c@cisco.com> <20170902073342.xoziwor4tdr5bipw@elstar.local> <20170902112832.ymorfgdthobeio6q@elstar.local> From: Robert Wilton Message-ID: <1e95ba5d-7aa2-e08f-56f9-27aa70822a11@cisco.com> Date: Mon, 4 Sep 2017 15:05:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9777293457911A956D3A9FB2" Content-Language: en-US Archived-At: Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 14:05:06 -0000 This is a multi-part message in MIME format. --------------9777293457911A956D3A9FB2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Andy, On 02/09/2017 17:46, Andy Bierman wrote: > > > On Sat, Sep 2, 2017 at 4:28 AM, Juergen Schoenwaelder > > wrote: > > On Sat, Sep 02, 2017 at 10:39:57AM +0000, Acee Lindem (acee) wrote: > > > > This is not an effort to change or bifurcate the YANG 1.1. It is > simply to > > RECOMMEND a proper subset of XSD pattern that is more portable. > > > > If you implement YANG as it is defined, pattern are portable. Given > this, I do not understand the notion of 'more portable'. > > Anyway, it seems that those who want a more portable subset do not > even agree on what that subset is. Perhaps people pushing for this > should go and write an I-D that explains why a 'more portable' subset > is needed (which problems are we fixing), that defines such a 'more > portable subset', and which includes the reasoning how the subset has > been determined. > > > > I do not agree that the YANG pattern contains a string that is both a > POSIX and XSD regular expression. > The RFC is very clear it contains an XSD expression. Pretending it is > both is a hack that does not even seem > to work 100%, so it is not reliable. I am not suggesting that the YANG pattern is both a POSIX and XSD regular expression. I am only suggesting that the guidelines recommend that authors use a subset of XSD, to make it easier to programmatically *convert* the 'XSD subset compliant regular expression' into a functionally equivalent regular expression for whatever regular expression engine the tooling decides to use. E.g. this seems to be the approach used by "libyang" that uses libpcre as the backend RE library rather than libxml. Unfortunately, I think that the libyang library would currently fail if the pattern statement contained "[[A-Z]-[P-R]]" because it looks like the PCRE2 language does not support character class subtraction.  ACAICT, no standard YANG modules currently support character class subtraction, so the authors of libyang have a choice here:   (i) write a block of code that most likely nobody is going to use, or   (ii) document the limitation, spot character class subtraction in the regex, and flag that it is not supported (or perhaps just ignore it). > > If the community wants to support both XSD and POSIX expressions, then > the proper engineering > solution is to introduce a new statement that is defined to contain a > POSIX expression. > This can be done with a YANG extension now and added to YANG 2.0 later. I think that this is an inferior solution: - there are many languages that YANG tools could be written in: C/C++, Python, Java, Go, Rust, Javascript are all reasonably plausible choices. - they all have similar, but with small differences regular expression flavours (according to http://www.regular-expressions.info/reference.html). - Personally, I see no inherent advantage of the POSIX Extended Regex over XML RE.   In fact, given that it doesn't support Unicode at all, it would seem to be a somewhat strange choice for a second pattern statement. - Nor does it seem pragmatic to introduce lots of different flavors of pattern statements into YANG each supporting a different regex syntax. I also don't like the solution that every YANG tool maker has to either link against libxml2,  or write their own efficient regular expression engine.  I'm not convinced that what the world needs is yet more regular expression implementations :-) So, I still see that the better technical solution is always only define the pattern statements in XML RE language, but to strongly encourage folks to use a subset of that language for standards models (which they appear to be doing anyway) to make it easier to covert the regular expression into compatible versions for other engines. Thanks, Rob > > /js > > > Andy > > > -- > Juergen Schoenwaelder           Jacobs University Bremen gGmbH > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany > Fax:   +49 421 200 3103          > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > --------------9777293457911A956D3A9FB2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Andy,


On 02/09/2017 17:46, Andy Bierman wrote:


On Sat, Sep 2, 2017 at 4:28 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Sat, Sep 02, 2017 at 10:39:57AM +0000, Acee Lindem (acee) wrote:
>
> This is not an effort to change or bifurcate the YANG 1.1. It is simply to
> RECOMMEND a proper subset of XSD pattern that is more portable.
>

If you implement YANG as it is defined, pattern are portable. Given
this, I do not understand the notion of 'more portable'.

Anyway, it seems that those who want a more portable subset do not
even agree on what that subset is. Perhaps people pushing for this
should go and write an I-D that explains why a 'more portable' subset
is needed (which problems are we fixing), that defines such a 'more
portable subset', and which includes the reasoning how the subset has
been determined.



I do not agree that the YANG pattern contains a string that is both a POSIX and XSD regular expression.
The RFC is very clear it contains an XSD expression. Pretending it is both is a hack that does not even seem
to work 100%, so it is not reliable.
I am not suggesting that the YANG pattern is both a POSIX and XSD regular expression.

I am only suggesting that the guidelines recommend that authors use a subset of XSD, to make it easier to programmatically *convert* the 'XSD subset compliant regular expression' into a functionally equivalent regular expression for whatever regular expression engine the tooling decides to use.

E.g. this seems to be the approach used by "libyang" that uses libpcre as the backend RE library rather than libxml.  Unfortunately, I think that the libyang library would currently fail if the pattern statement contained "[[A-Z]-[P-R]]" because it looks like the PCRE2 language does not support character class subtraction.  ACAICT, no standard YANG modules currently support character class subtraction, so the authors of libyang have a choice here:
  (i) write a block of code that most likely nobody is going to use, or
  (ii) document the limitation, spot character class subtraction in the regex, and flag that it is not supported (or perhaps just ignore it).



If the community wants to support both XSD and POSIX expressions, then the proper engineering
solution is to introduce a new statement that is defined to contain a POSIX expression.
This can be done with a YANG extension now and added to YANG 2.0 later.
I think that this is an inferior solution:
- there are many languages that YANG tools could be written in: C/C++, Python, Java, Go, Rust, Javascript are all reasonably plausible choices.
- they all have similar, but with small differences regular expression flavours (according to http://www.regular-expressions.info/reference.html).
- Personally, I see no inherent advantage of the POSIX Extended Regex over XML RE.   In fact, given that it doesn't support Unicode at all, it would seem to be a somewhat strange choice for a second pattern statement.
- Nor does it seem pragmatic to introduce lots of different flavors of pattern statements into YANG each supporting a different regex syntax.

I also don't like the solution that every YANG tool maker has to either link against libxml2,  or write their own efficient regular expression engine.  I'm not convinced that what the world needs is yet more regular expression implementations :-)

So, I still see that the better technical solution is always only define the pattern statements in XML RE language, but to strongly encourage folks to use a subset of that language for standards models (which they appear to be doing anyway) to make it easier to covert the regular expression into compatible versions for other engines.

Thanks,
Rob



 
/js

Andy
 

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

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


--------------9777293457911A956D3A9FB2-- From nobody Mon Sep 4 07:37:46 2017 Return-Path: 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 4AF4F132AA5 for ; Mon, 4 Sep 2017 07:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 ML54zObf5URK for ; Mon, 4 Sep 2017 07:37:42 -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 EFE7C1321AE for ; Mon, 4 Sep 2017 07:37:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=955; q=dns/txt; s=iport; t=1504535862; x=1505745462; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=j3bG9Uxtj7aFL5gyigU8yfPGnoODVWvm8PeMc0k7gB8=; b=Xq/c+BOZZ84afw4FGqcKA6Uq4DKkHYY4zbMWuAGFpp1hFgDDW9+m1dJ2 MSFKj9eBVYlWCwWOnHkt84GWf9Fo2230az3o4rfGmYWGsDQVAV6+4WB8f OLsEMbRQUK9CtRaEcYaovpx2W8nvhjMVicOAVrSz5VE922UE79Cc3x1JN k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CFAgBgZK1Z/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD6BFYN3ixSQfCKYOgojhRsChF8UAQIBAQEBAQEBayiFGQEFIw8?= =?us-ascii?q?BBUEQCQIOCgICJgICVwYNCAEBii0QlnydZoIni1IBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBGgWBDYIdg1CBYysLgnKICIJhAQSgdIdbjHaLVIcdjVeHKQMGBQIZgTk2IYE?= =?us-ascii?q?NMiEIHBWHZT82AQGLFwEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,475,1498521600"; d="scan'208";a="654391836" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Sep 2017 14:37:40 +0000 Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v84EbdU6014039; Mon, 4 Sep 2017 14:37:39 GMT To: Carsten Bormann Cc: Alex Campbell , "netmod@ietf.org" References: <20170830102902.2n5q6rgq2x2dxfq2@elstar.local> <20170830123156.cssrg5kklpo67fie@elstar.local> <1504223854014.55228@Aviatnet.com> <847e5bf9-7b3d-9ff8-9954-970f32a2094c@cisco.com> <20170902073342.xoziwor4tdr5bipw@elstar.local> <90927C99-0BE9-488D-AB96-ACEBBE3F0F14@tzi.org> From: Robert Wilton Message-ID: Date: Mon, 4 Sep 2017 15:37:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <90927C99-0BE9-488D-AB96-ACEBBE3F0F14@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 14:37:44 -0000 Hi Carsten, I'm slightly lost :-) Don't you have the same issue for CDDL in that the specification supports the full syntax from PCRE (which appears to be one of the much larger and more complex regex language specifications) which will force implementations to use a PCRE compatible implementation? I think that the world needs a minimal common regex language ... but presumably that is just walking into the XKCD trap: https://xkcd.com/927/ ;-) Rob On 04/09/2017 12:18, Carsten Bormann wrote: > I’m not going to say we have solved the underlying problem (too many flavors of regular expression) completely for CDDL, but in CDDL we are using PCRE with anchors then added: > > https://tools.ietf.org/html/draft-ietf-cbor-cddl-00#section-3.8.3 > > (And here is the implementation: > h[k] = Regexp.new("\\A#{k}\\z") > That should not be too hard to replicate in any language :-) > > Grüße, Carsten > > . > From nobody Mon Sep 4 07:58:34 2017 Return-Path: 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 5938E13219F for ; Mon, 4 Sep 2017 07:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] 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 yOAL8k01FO7D for ; Mon, 4 Sep 2017 07:58:30 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 1520C12426E for ; Mon, 4 Sep 2017 07:58:30 -0700 (PDT) Received: from birdie (unknown [IPv6:2001:1488:fffe:6:ecb1:1ff:fe9a:e257]) by mail.nic.cz (Postfix) with ESMTPSA id 3401A60B35 for ; Mon, 4 Sep 2017 16:58:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1504537108; bh=Lfi06drr9wENtkpwAqbQdWhU4HycmGiE4NXo1duZZZQ=; h=From:To:Date; b=FJNHlNjZ/2BTaJIRjMHjvdLyXALeXXkGgCUVH7HNv9gcqpbbftVRVzIpVPeFeyoyJ t3G9DV+bbKkYt5kqlmQn26PiO68EcJ8YtKohMkN5W1fl2ygL4hl4SjVsSKEOl+SKZt xzfs0GIUFnFjGZLx3pNubBroBMMdaQ8XHP5y7d60= Message-ID: <1504537140.5874.38.camel@nic.cz> From: Ladislav Lhotka To: netmod@ietf.org Date: Mon, 04 Sep 2017 16:59:00 +0200 In-Reply-To: <1e95ba5d-7aa2-e08f-56f9-27aa70822a11@cisco.com> References: <20170830102902.2n5q6rgq2x2dxfq2@elstar.local> <20170830123156.cssrg5kklpo67fie@elstar.local> <1504223854014.55228@Aviatnet.com> <847e5bf9-7b3d-9ff8-9954-970f32a2094c@cisco.com> <20170902073342.xoziwor4tdr5bipw@elstar.local> <20170902112832.ymorfgdthobeio6q@elstar.local> <1e95ba5d-7aa2-e08f-56f9-27aa70822a11@cisco.com> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.5 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 14:58:33 -0000 Robert Wilton píše v Po 04. 09. 2017 v 15:05 +0100: > Hi Andy, > > On 02/09/2017 17:46, Andy Bierman wrote: > > > > On Sat, Sep 2, 2017 at 4:28 AM, Juergen Schoenwaelder wrote: > > > On Sat, Sep 02, 2017 at 10:39:57AM +0000, Acee Lindem (acee) wrote: > > > > > > > > This is not an effort to change or bifurcate the YANG 1.1. It is simply to > > > > RECOMMEND a proper subset of XSD pattern that is more portable. > > > > > > > > > > If you implement YANG as it is defined, pattern are portable. Given > > > this, I do not understand the notion of 'more portable'. > > > > > > Anyway, it seems that those who want a more portable subset do not > > > even agree on what that subset is. Perhaps people pushing for this > > > should go and write an I-D that explains why a 'more portable' subset > > > is needed (which problems are we fixing), that defines such a 'more > > > portable subset', and which includes the reasoning how the subset has > > > been determined. > > > > > > > > > > > > I do not agree that the YANG pattern contains a string that is both a POSIX and XSD regular expression. > > The RFC is very clear it contains an XSD expression. Pretending it is both is a hack that does not even seem > > to work 100%, so it is not reliable. > I am not suggesting that the YANG pattern is both a POSIX and XSD regular expression. > > I am only suggesting that the guidelines recommend that authors use a subset of XSD, to make it easier to programmatically *convert* the 'XSD subset compliant regular expression' into a functionally equivalent regular expression for whatever regular expression engine the tooling decides to use. And that's the point, I think: each developer needs to get a library function so as to translate the XSD pattern into a native regex of whatever programming language he/she is currently using. So I guess what we really need is to identify libraries for common languages that do it correctly - or write simple translators ourselves if none is available. > > E.g. this seems to be the approach used by "libyang" that uses libpcre as the backend RE library rather than libxml. Unfortunately, I think that the libyang library would currently fail if the pattern statement contained "[[A-Z]-[P-R]]" because it looks like the PCRE2 language does not support character class subtraction. ACAICT, no standard YANG modules currently support character class subtraction, so the authors of libyang have a choice here: Note that your example is incorrect, it should be [A-Z-[P-R]]. FWIW, Python module PyXB (that I used in Yangson library) does support this. Lada > (i) write a block of code that most likely nobody is going to use, or > (ii) document the limitation, spot character class subtraction in the regex, and flag that it is not supported (or perhaps just ignore it). > > > > If the community wants to support both XSD and POSIX expressions, then the proper engineering > > solution is to introduce a new statement that is defined to contain a POSIX expression. > > This can be done with a YANG extension now and added to YANG 2.0 later. > I think that this is an inferior solution: > - there are many languages that YANG tools could be written in: C/C++, Python, Java, Go, Rust, Javascript are all reasonably plausible choices. > - they all have similar, but with small differences regular expression flavours (according to http://www.regular-expressions.info/reference.html). > - Personally, I see no inherent advantage of the POSIX Extended Regex over XML RE. In fact, given that it doesn't support Unicode at all, it would seem to be a somewhat strange choice for a second pattern statement. > - Nor does it seem pragmatic to introduce lots of different flavors of pattern statements into YANG each supporting a different regex syntax. > > I also don't like the solution that every YANG tool maker has to either link against libxml2, or write their own efficient regular expression engine. I'm not convinced that what the world needs is yet more regular expression implementations :-) > > So, I still see that the better technical solution is always only define the pattern statements in XML RE language, but to strongly encourage folks to use a subset of that language for standards models (which they appear to be doing anyway) to make it easier to covert the regular expression into compatible versions for other engines. > > Thanks, > Rob > > > > > > > /js > > > > > > > Andy > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > Fax: +49 421 200 3103 > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Sep 4 08:55:36 2017 Return-Path: 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 1A9F91321CB for ; Mon, 4 Sep 2017 08:55:34 -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 y-k_Iom7kCeU for ; Mon, 4 Sep 2017 08:55:31 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 3187A1321C4 for ; Mon, 4 Sep 2017 08:55:31 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id k189so3393443itk.0 for ; Mon, 04 Sep 2017 08:55:31 -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=4uZ2f9rNiSRU8wQzOnejk3qQTCZ/PeNyUEw3OKX8+4E=; b=gfUzNET2OwXimQ1NhDNHZCKmIPYdC/rkyQLpPhV/X8gj+CeKMSquyHcwUvkGHK5XqX ycufa5bYvUlkqJUhZE2bQ3h6uqHBlBjs3J+Mz4QJJ6Gn/G1yD+3jSDPyhRrP5Kg7NXQr /uKZvJKXnntpFCXafLZTj33NiwM4/FOgxupPvgbnNGdUhU6VVhkuItJ5JwGtqZL9aQRI rXMjFBDVS1dcL/upob1J2XNwlB7BqNOO1yPAqwX+0d5lEL31VOJoUA0uf2Dx/+8I+jW7 VHPGdhySRFL75Gy8R5hAhUVtqyzzFB0+d1aLdQmaGRbeDIFR37ZRv/Tzm4h79wZ7Lg8C yCOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4uZ2f9rNiSRU8wQzOnejk3qQTCZ/PeNyUEw3OKX8+4E=; b=IrYsOa4qSt3O96v2te65NMi5A3IgT9l9x8X5xKrmuhci9hEtwDjf92nDQBc8u+2Eb7 hcC2sM0mVCiBdLZliHpfAtmPup6Dny/9oVNnJ/TJzh60asYspilBhAjGeddbjVqg6YUZ tTHvAG+P1XGBespdAv4qBZTXrtvaVe4/EF0lGATOBg3WZNXdxHup6jMXtojNy6ZTrMgZ 8fPGyeWSiQkZVAEDE/9OHonnsgNKGRUUYoAARtKM7r87NIAXzNI4U1YkL/SBF7lxl25R qQpR7eoBc7+WAQ/dORECybVJBdRb/oZXezx7zh00mYJ8qLispRVSLdDlRnMCDRnnHVe5 DLzg== X-Gm-Message-State: AHPjjUhKdsjrJuU6sYzrkKEdDhApnopJCdyxEK2brZpMvPJva8vXZiNn EjCJQKr7/MxEwheWWHaeTT8YvVSfPR2B X-Google-Smtp-Source: ADKCNb7PkH9JB5YctidpOZ+kjo4fearxkpP2QL+goJ4ljYZYkpMFjJ8g9VUmBCTdcdVF1NgMLwbXqAJkP94mkFWOXig= X-Received: by 10.36.40.138 with SMTP id h132mr1259537ith.26.1504540530501; Mon, 04 Sep 2017 08:55:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.6.206 with HTTP; Mon, 4 Sep 2017 08:55:29 -0700 (PDT) In-Reply-To: <1e95ba5d-7aa2-e08f-56f9-27aa70822a11@cisco.com> References: <20170830102902.2n5q6rgq2x2dxfq2@elstar.local> <20170830123156.cssrg5kklpo67fie@elstar.local> <1504223854014.55228@Aviatnet.com> <847e5bf9-7b3d-9ff8-9954-970f32a2094c@cisco.com> <20170902073342.xoziwor4tdr5bipw@elstar.local> <20170902112832.ymorfgdthobeio6q@elstar.local> <1e95ba5d-7aa2-e08f-56f9-27aa70822a11@cisco.com> From: Andy Bierman Date: Mon, 4 Sep 2017 08:55:29 -0700 Message-ID: To: Robert Wilton Cc: Juergen Schoenwaelder , "Acee Lindem (acee)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="001a113f62ecdf051005585f23eb" Archived-At: Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 15:55:34 -0000 --001a113f62ecdf051005585f23eb Content-Type: text/plain; charset="UTF-8" On Mon, Sep 4, 2017 at 7:05 AM, Robert Wilton wrote: > Hi Andy, > > On 02/09/2017 17:46, Andy Bierman wrote: > > > > On Sat, Sep 2, 2017 at 4:28 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > >> On Sat, Sep 02, 2017 at 10:39:57AM +0000, Acee Lindem (acee) wrote: >> > >> > This is not an effort to change or bifurcate the YANG 1.1. It is simply >> to >> > RECOMMEND a proper subset of XSD pattern that is more portable. >> > >> >> If you implement YANG as it is defined, pattern are portable. Given >> this, I do not understand the notion of 'more portable'. >> >> Anyway, it seems that those who want a more portable subset do not >> even agree on what that subset is. Perhaps people pushing for this >> should go and write an I-D that explains why a 'more portable' subset >> is needed (which problems are we fixing), that defines such a 'more >> portable subset', and which includes the reasoning how the subset has >> been determined. >> >> > > I do not agree that the YANG pattern contains a string that is both a > POSIX and XSD regular expression. > The RFC is very clear it contains an XSD expression. Pretending it is both > is a hack that does not even seem > to work 100%, so it is not reliable. > > I am not suggesting that the YANG pattern is both a POSIX and XSD regular > expression. > > I am only suggesting that the guidelines recommend that authors use a > subset of XSD, to make it easier to programmatically *convert* the 'XSD > subset compliant regular expression' into a functionally equivalent regular > expression for whatever regular expression engine the tooling decides to > use. > > Looks like you want the expression to mean the exact same thing in multiple expression languages and you want to put the burden of this perfect subset on humans who write YANG. This is a really unworkable plan. > E.g. this seems to be the approach used by "libyang" that uses libpcre as > the backend RE library rather than libxml. Unfortunately, I think that the > libyang library would currently fail if the pattern statement contained > "[[A-Z]-[P-R]]" because it looks like the PCRE2 language does not support > character class subtraction. ACAICT, no standard YANG modules currently > support character class subtraction, so the authors of libyang have a > choice here: > (i) write a block of code that most likely nobody is going to use, or > (ii) document the limitation, spot character class subtraction in the > regex, and flag that it is not supported (or perhaps just ignore it). > > > > If the community wants to support both XSD and POSIX expressions, then the > proper engineering > solution is to introduce a new statement that is defined to contain a > POSIX expression. > This can be done with a YANG extension now and added to YANG 2.0 later. > > I think that this is an inferior solution: > - there are many languages that YANG tools could be written in: C/C++, > Python, Java, Go, Rust, Javascript are all reasonably plausible choices. > - they all have similar, but with small differences regular expression > flavours (according to http://www.regular-expressions.info/reference.html > ). > - Personally, I see no inherent advantage of the POSIX Extended Regex over > XML RE. In fact, given that it doesn't support Unicode at all, it would > seem to be a somewhat strange choice for a second pattern statement. > - Nor does it seem pragmatic to introduce lots of different flavors of > pattern statements into YANG each supporting a different regex syntax. > > You seem to be confirming that picking 1 flavor of Posix would be impossible. All the more reason to keep the XSD pattern unburdened. I see no reason XSD patterns should be constrained because some implementors want to ignore the RFC and pretend the string is some other expression language. > I also don't like the solution that every YANG tool maker has to either > link against libxml2, or write their own efficient regular expression > engine. I'm not convinced that what the world needs is yet more regular > expression implementations :-) > The write your own tools and don't use libxml2. > So, I still see that the better technical solution is always only define > the pattern statements in XML RE language, but to strongly encourage folks > to use a subset of that language for standards models (which they appear to > be doing anyway) to make it easier to covert the regular expression into > compatible versions for other engines. > > Thanks, > Rob > > > Andy > > > >> /js >> > > Andy > > >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > > > --001a113f62ecdf051005585f23eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Sep 4, 2017 at 7:05 AM, Robert Wilton <rwilton@cisco.com&g= t; wrote:
=20 =20 =20

Hi Andy,


On 02/09/2017 17:4= 6, Andy Bierman wrote:
=20


On Sat, Sep 2, 2017 at 4:28 AM, Juergen Schoenwaelder <j.schoenwaelder@jaco= bs-university.de> wrote:
On Sat, Sep 02, 2017 at 10:39:57AM +0000, Acee Lindem (acee) wrote:
>
> This is not an effort to change or bifurcate the YANG 1.1. It is simply to
> RECOMMEND a proper subset of XSD pattern that is more portable.
>

If you implement YANG as it is defined, pattern are portable. Given
this, I do not understand the notion of 'more portable= 9;.

Anyway, it seems that those who want a more portable subset do not
even agree on what that subset is. Perhaps people pushing for this
should go and write an I-D that explains why a 'more portable' subset
is needed (which problems are we fixing), that defines such a 'more
portable subset', and which includes the reasoning how th= e subset has
been determined.



I do not agree that the YANG pattern contains a string that is both a POSIX and XSD regular expression.
The RFC is very clear it contains an XSD expression. Pretending it is both is a hack that does not even seem
to work 100%, so it is not reliable.
I am not suggesting that the YANG pattern is both a POSIX and XSD regular expression.

I am only suggesting that the guidelines recommend that authors use a subset of XSD, to make it easier to programmatically *convert* the 'XSD subset compliant regular expression' into a functionally equivalent regular expression for whatever regular expression engine the tooling decides to use.


Looks like you want the expr= ession to mean the exact same thing in multiple expression languages
<= div>and you want to put the burden of this perfect subset on humans who wri= te YANG.
This is a really unworkable plan.

=C2=A0
E.g. this seems to be the approach used by "libyang" that use= s libpcre as the backend RE library rather than libxml.=C2=A0 Unfortunately, I think that the libyang library would currently fail if the pattern statement contained "[[A-Z]-[P-R]]" because it= looks like the PCRE2 language does not support character class subtraction.=C2=A0 ACAICT, no standard YANG modules currently support character class subtraction, so the authors of libyang have a choice here:
=C2=A0 (i) write a block of code that most likely nobody is going to us= e, or
=C2=A0 (ii) document the limitation, spot character class subtraction i= n the regex, and flag that it is not supported (or perhaps just ignore it).



If the community wants to support both XSD and POSIX expressions, then the proper engineering
solution is to introduce a new statement that is defined to contain a POSIX expression.
This can be done with a YANG extension now and added to YANG 2.0 later.
I think that this is an inferior solution:
- there are many languages that YANG tools could be written in: C/C++, Python, Java, Go, Rust, Javascript are all reasonably plausible choices.
- they all have similar, but with small differences regular expression flavours (according to http://www.= regular-expressions.info/reference.html).
- Personally, I see no inherent advantage of the POSIX Extended Regex over XML RE.=C2=A0=C2=A0 In fact, given that it doesn't suppo= rt Unicode at all, it would seem to be a somewhat strange choice for a second pattern statement.
- Nor does it seem pragmatic to introduce lots of different flavors of pattern statements into YANG each supporting a different regex syntax.



You seem to b= e confirming that picking 1 flavor of Posix would be impossible.
= All the more reason to keep the XSD pattern unburdened.=C2=A0
I s= ee no reason XSD patterns should be constrained because some implementors w= ant to
ignore the RFC and pretend the string is some other expres= sion language.

=C2=A0
I also don't like the solution that every YANG tool maker has to either link against libxml2,=C2=A0 or write their own efficient regular expression engine.=C2=A0 I'm not convinced that what the world need= s is yet more regular expression implementations :-)
<= div>=C2=A0
The write your own tools and don't use libxml2.



So, I still see that the better technical solution is always only define the pattern statements in XML RE language, but to strongly encourage folks to use a subset of that language for standards models (which they appear to be doing anyway) to make it easier to covert the regular expression into compatible versions for other engines.

Thanks,
Rob




Andy
=C2=A0


On Sat, Sep 2, 2017 at 4:28 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Sat, Sep 02, 2017 at 10:39:57AM +0000, Acee Lindem= (acee) wrote:
>
> This is not an effort to change or bifurcate the YANG 1.1. It is simpl= y to
> RECOMMEND a proper subset of XSD pattern that is more portable.
>

If you implement YANG as it is defined, pattern are portable. Given
this, I do not understand the notion of 'more portable'.

Anyway, it seems that those who want a more portable subset do not
even agree on what that subset is. Perhaps people pushing for this
should go and write an I-D that explains why a 'more portable' subs= et
is needed (which problems are we fixing), that defines such a 'more
portable subset', and which includes the reasoning how the subset has been determined.



I do not agree that the YANG pattern = contains a string that is both a POSIX and XSD regular expression.
The RFC is very clear it contains an XSD expression. Pretending it is bot= h is a hack that does not even seem
to work 100%, so it is not re= liable.

If the community wants to support both XSD= and POSIX expressions, then the proper engineering
solution is t= o introduce a new statement that is defined to contain a POSIX expression.<= /div>
This can be done with a YANG extension now and added to YANG 2.0 = later.

=C2=A0
= /js

Andy
=C2=A0=

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

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


=C2=A0
/js

Andy
=C2=A0

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Jacobs University Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Campus Ring 1 | 28759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0<http://www.jacobs-university.de/>

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



--001a113f62ecdf051005585f23eb-- From nobody Mon Sep 4 09:07:47 2017 Return-Path: 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 135D41321A5 for ; Mon, 4 Sep 2017 09:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 ndjV25_HVOKx for ; Mon, 4 Sep 2017 09:07:42 -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 EBFFE1321C4 for ; Mon, 4 Sep 2017 09:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7271; q=dns/txt; s=iport; t=1504541262; x=1505750862; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=65CKN3/P8a+KtZJK1VaF5HzbIDKB6yw73ukKsuPoVXc=; b=Ks1XczGBodJWgHSAqSJDLNa/aVl2LmH1SRLliMZnXrQRrlUlj06qwTF2 uEIhdGM1iWdnSx6C83J8nbmWDVTDYBgBKjw+pWlz/5Nt/izH3H1WALlev Ow1eYX16fawstk8LYG8YfLUFCCcSgcAYim1ajzsqKz1UrQk1rDrTiImxW s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAgB/ea1Z/xbLJq1TBwMZAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGEPoEVg3eLFJEed5RLgngKGAuETE8ChGAUAQIBAQEBAQEBayi?= =?us-ascii?q?FGAEBAQECAQEBIQ8BBTYZAgkCEAgCAiYCAhsMMAYBDAYCAQEQB4oOCBCWH51mg?= =?us-ascii?q?ieLUgEBAQEBAQEBAQEBAQEBAQEBAQEBAR0FgQiCHYNQgWMrgkg1hEpMJoJMgmE?= =?us-ascii?q?FoHSUUYtUhx2NV4Qcgw0DBgUCGYE5NiGBDTIhCBwVSYccPzYBixgBAQE?= X-IronPort-AV: E=Sophos;i="5.41,475,1498521600"; d="scan'208";a="654393103" 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 Sep 2017 16:07:39 +0000 Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v84G7d7j018680; Mon, 4 Sep 2017 16:07:39 GMT To: Ladislav Lhotka , netmod@ietf.org References: <20170830102902.2n5q6rgq2x2dxfq2@elstar.local> <20170830123156.cssrg5kklpo67fie@elstar.local> <1504223854014.55228@Aviatnet.com> <847e5bf9-7b3d-9ff8-9954-970f32a2094c@cisco.com> <20170902073342.xoziwor4tdr5bipw@elstar.local> <20170902112832.ymorfgdthobeio6q@elstar.local> <1e95ba5d-7aa2-e08f-56f9-27aa70822a11@cisco.com> <1504537140.5874.38.camel@nic.cz> From: Robert Wilton Message-ID: Date: Mon, 4 Sep 2017 17:07:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1504537140.5874.38.camel@nic.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 16:07:45 -0000 Hi Lada, On 04/09/2017 15:59, Ladislav Lhotka wrote: > Robert Wilton píše v Po 04. 09. 2017 v 15:05 +0100: >> Hi Andy, >> >> On 02/09/2017 17:46, Andy Bierman wrote: >>> On Sat, Sep 2, 2017 at 4:28 AM, Juergen Schoenwaelder wrote: >>>> On Sat, Sep 02, 2017 at 10:39:57AM +0000, Acee Lindem (acee) wrote: >>>>> This is not an effort to change or bifurcate the YANG 1.1. It is simply to >>>>> RECOMMEND a proper subset of XSD pattern that is more portable. >>>>> >>>> If you implement YANG as it is defined, pattern are portable. Given >>>> this, I do not understand the notion of 'more portable'. >>>> >>>> Anyway, it seems that those who want a more portable subset do not >>>> even agree on what that subset is. Perhaps people pushing for this >>>> should go and write an I-D that explains why a 'more portable' subset >>>> is needed (which problems are we fixing), that defines such a 'more >>>> portable subset', and which includes the reasoning how the subset has >>>> been determined. >>>> >>>> >>> >>> I do not agree that the YANG pattern contains a string that is both a POSIX and XSD regular expression. >>> The RFC is very clear it contains an XSD expression. Pretending it is both is a hack that does not even seem >>> to work 100%, so it is not reliable. >> I am not suggesting that the YANG pattern is both a POSIX and XSD regular expression. >> >> I am only suggesting that the guidelines recommend that authors use a subset of XSD, to make it easier to programmatically *convert* the 'XSD subset compliant regular expression' into a functionally equivalent regular expression for whatever regular expression engine the tooling decides to use. > And that's the point, I think: each developer needs to get a library function so > as to translate the XSD pattern into a native regex of whatever programming > language he/she is currently using. So I guess what we really need is to > identify libraries for common languages that do it correctly - or write simple > translators ourselves if none is available. Yes, exactly. Looking at http://www.regular-expressions.info/ then XML RE does look like a good standard choice of RE language for YANG pattern statements because it is generally one of the most basic RE languages, and hence it should be feasible to convert an XML RE into a form usable by most RE languages. But converting some parts of the XML RE syntax would probably be laborious: 1) E.g. the unicode property '\p{Nd}' that is equivalent to '\d' matches 590 characters (http://www.fileformat.info/info/unicode/category/Nd/list.htm). There are approx 32 unicode properties, presumably these could also be extended over time as well. 2) There are currently 105 unicode blocks, which each block is a discrete range of characters (e.g. \p{InTibetan}: U+0F00–U+0FFF) 3) Handling the character class subtraction is also possible, but probably tedious to implement, since it requires the translation to fully understand the set of characters in the character class so it can form an equivalent character class without any subtractions. These were the three parts of the XML RE that I was hoping to discourage in the YANG author guidelines so that performing a translation is much easier.  Spotting these 3 parts in the regex should be simple, so the translation would still be robust, even if not complete. There are other conversions that may also need to be performed (depending on the target RE engine): 1) Character class shorthands (e.g. \d, \w) need to be converted to represent the Unicode set equivalent, since for a lot of engines they only match ASCII characters.  For '\s' it must match ASCII whitespace only. 2) If the engine supports greedy alternation (e.g. POSIX basic/extended regex), then alternations need to be converted to an eager form if required. 3) The syntax for escaping characters seems to differ in XML RE from other common languages. 4) Linebreak match handling seems to differ. These conversions would need to be done regardless, but would seem to be much quicker/simpler to implement than the ones above. Thanks, Rob > >> E.g. this seems to be the approach used by "libyang" that uses libpcre as the backend RE library rather than libxml. Unfortunately, I think that the libyang library would currently fail if the pattern statement contained "[[A-Z]-[P-R]]" because it looks like the PCRE2 language does not support character class subtraction. ACAICT, no standard YANG modules currently support character class subtraction, so the authors of libyang have a choice here: > Note that your example is incorrect, it should be [A-Z-[P-R]]. FWIW, Python > module PyXB (that I used in Yangson library) does support this. > > Lada > >> (i) write a block of code that most likely nobody is going to use, or >> (ii) document the limitation, spot character class subtraction in the regex, and flag that it is not supported (or perhaps just ignore it). >> >> >>> If the community wants to support both XSD and POSIX expressions, then the proper engineering >>> solution is to introduce a new statement that is defined to contain a POSIX expression. >>> This can be done with a YANG extension now and added to YANG 2.0 later. >> I think that this is an inferior solution: >> - there are many languages that YANG tools could be written in: C/C++, Python, Java, Go, Rust, Javascript are all reasonably plausible choices. >> - they all have similar, but with small differences regular expression flavours (according to http://www.regular-expressions.info/reference.html). >> - Personally, I see no inherent advantage of the POSIX Extended Regex over XML RE. In fact, given that it doesn't support Unicode at all, it would seem to be a somewhat strange choice for a second pattern statement. >> - Nor does it seem pragmatic to introduce lots of different flavors of pattern statements into YANG each supporting a different regex syntax. >> >> I also don't like the solution that every YANG tool maker has to either link against libxml2, or write their own efficient regular expression engine. I'm not convinced that what the world needs is yet more regular expression implementations :-) >> >> So, I still see that the better technical solution is always only define the pattern statements in XML RE language, but to strongly encourage folks to use a subset of that language for standards models (which they appear to be doing anyway) to make it easier to covert the regular expression into compatible versions for other engines. >> >> Thanks, >> Rob >> >> >>> >>>> /js >>>> >>> Andy >>> >>>> -- >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>>> Fax: +49 421 200 3103 >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Sep 4 09:22:52 2017 Return-Path: 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 A052E1321B7 for ; Mon, 4 Sep 2017 09:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 ryG55W-M63EV for ; Mon, 4 Sep 2017 09:22:47 -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 E1923126DD9 for ; Mon, 4 Sep 2017 09:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22433; q=dns/txt; s=iport; t=1504542167; x=1505751767; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=3RsAM/8S3fZ8QpGM9mzpiLZJpSF/MQKg7mJLZdGSfOI=; b=Y0RP3iKKJT0i1dKguDTQJV93Dh/b9IFI2SVErto4QwnOx2Dpv3GJfsN5 wiJZtFJn5oKGu+/4+oLxVfP57qZ3vq+3IBm9FoJOzHVlgQexWeousGgD6 eafrH09KKd0DsfpAgC6OUTr75zI8/RqRtBaoeMr/c/5cQO8YgBSdafzOd I=; X-IronPort-AV: E=Sophos;i="5.41,475,1498521600"; d="scan'208,217";a="654393312" 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 Sep 2017 16:22:45 +0000 Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v84GMifh030374; Mon, 4 Sep 2017 16:22:45 GMT To: Andy Bierman Cc: Juergen Schoenwaelder , "Acee Lindem (acee)" , "netmod@ietf.org" References: <20170830102902.2n5q6rgq2x2dxfq2@elstar.local> <20170830123156.cssrg5kklpo67fie@elstar.local> <1504223854014.55228@Aviatnet.com> <847e5bf9-7b3d-9ff8-9954-970f32a2094c@cisco.com> <20170902073342.xoziwor4tdr5bipw@elstar.local> <20170902112832.ymorfgdthobeio6q@elstar.local> <1e95ba5d-7aa2-e08f-56f9-27aa70822a11@cisco.com> From: Robert Wilton Message-ID: Date: Mon, 4 Sep 2017 17:22:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5DF8CC9F5CE6942A870A5295" Content-Language: en-US Archived-At: Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 16:22:51 -0000 This is a multi-part message in MIME format. --------------5DF8CC9F5CE6942A870A5295 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 04/09/2017 16:55, Andy Bierman wrote: > > > On Mon, Sep 4, 2017 at 7:05 AM, Robert Wilton > wrote: > > Hi Andy, > > > On 02/09/2017 17:46, Andy Bierman wrote: >> >> >> On Sat, Sep 2, 2017 at 4:28 AM, Juergen Schoenwaelder >> > > wrote: >> >> On Sat, Sep 02, 2017 at 10:39:57AM +0000, Acee Lindem (acee) >> wrote: >> > >> > This is not an effort to change or bifurcate the YANG 1.1. >> It is simply to >> > RECOMMEND a proper subset of XSD pattern that is more portable. >> > >> >> If you implement YANG as it is defined, pattern are portable. >> Given >> this, I do not understand the notion of 'more portable'. >> >> Anyway, it seems that those who want a more portable subset >> do not >> even agree on what that subset is. Perhaps people pushing for >> this >> should go and write an I-D that explains why a 'more >> portable' subset >> is needed (which problems are we fixing), that defines such a >> 'more >> portable subset', and which includes the reasoning how the >> subset has >> been determined. >> >> >> >> I do not agree that the YANG pattern contains a string that is >> both a POSIX and XSD regular expression. >> The RFC is very clear it contains an XSD expression. Pretending >> it is both is a hack that does not even seem >> to work 100%, so it is not reliable. > I am not suggesting that the YANG pattern is both a POSIX and XSD > regular expression. > > I am only suggesting that the guidelines recommend that authors > use a subset of XSD, to make it easier to programmatically > *convert* the 'XSD subset compliant regular expression' into a > functionally equivalent regular expression for whatever regular > expression engine the tooling decides to use. > > > Looks like you want the expression to mean the exact same thing in > multiple expression languages > and you want to put the burden of this perfect subset on humans who > write YANG. Again, no, that is not what I want. I would like the rules to recommend that authors of standards based YANG modules don't use the bits of the XML RE language that (i) they don't use anyway, (ii) don't appear to have any compelling use case in standard YANG modules, and (iii) are hard to convert to other RE languages. There recommendations also have the additional advantage that the pattern statements that follow these rules are likely to be much easier to understand because they use the aspects of regular expressions languages that folks are likely to be more familiar with. > This is a really unworkable plan. Is my proposed 6087bis text really that complicated? Thanks, Rob > > > E.g. this seems to be the approach used by "libyang" that uses > libpcre as the backend RE library rather than libxml. > Unfortunately, I think that the libyang library would currently > fail if the pattern statement contained "[[A-Z]-[P-R]]" because it > looks like the PCRE2 language does not support character class > subtraction.  ACAICT, no standard YANG modules currently support > character class subtraction, so the authors of libyang have a > choice here: >   (i) write a block of code that most likely nobody is going to > use, or >   (ii) document the limitation, spot character class subtraction > in the regex, and flag that it is not supported (or perhaps just > ignore it). > > >> >> If the community wants to support both XSD and POSIX expressions, >> then the proper engineering >> solution is to introduce a new statement that is defined to >> contain a POSIX expression. >> This can be done with a YANG extension now and added to YANG 2.0 >> later. > I think that this is an inferior solution: > - there are many languages that YANG tools could be written in: > C/C++, Python, Java, Go, Rust, Javascript are all reasonably > plausible choices. > - they all have similar, but with small differences regular > expression flavours (according to > http://www.regular-expressions.info/reference.html > ). > - Personally, I see no inherent advantage of the POSIX Extended > Regex over XML RE.   In fact, given that it doesn't support > Unicode at all, it would seem to be a somewhat strange choice for > a second pattern statement. > - Nor does it seem pragmatic to introduce lots of different > flavors of pattern statements into YANG each supporting a > different regex syntax. > > > > You seem to be confirming that picking 1 flavor of Posix would be > impossible. > All the more reason to keep the XSD pattern unburdened. > I see no reason XSD patterns should be constrained because some > implementors want to > ignore the RFC and pretend the string is some other expression language. > > I also don't like the solution that every YANG tool maker has to > either link against libxml2,  or write their own efficient regular > expression engine.  I'm not convinced that what the world needs is > yet more regular expression implementations :-) > > The write your own tools and don't use libxml2. > > > > So, I still see that the better technical solution is always only > define the pattern statements in XML RE language, but to strongly > encourage folks to use a subset of that language for standards > models (which they appear to be doing anyway) to make it easier to > covert the regular expression into compatible versions for other > engines. > > Thanks, > Rob > > > > > Andy > >> >> /js >> >> >> Andy >> >> >> -- >> Juergen Schoenwaelder           Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen >> | Germany >> Fax:   +49 421 200 3103        >>  > > >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> >> > > --------------5DF8CC9F5CE6942A870A5295 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 04/09/2017 16:55, Andy Bierman wrote:


On Mon, Sep 4, 2017 at 7:05 AM, Robert Wilton <rwilton@cisco.com> wrote:

Hi Andy,


On 02/09/2017 17:46, Andy Bierman wrote:


On Sat, Sep 2, 2017 at 4:28 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Sat, Sep 02, 2017 at 10:39:57AM +0000, Acee Lindem (acee) wrote:
>
> This is not an effort to change or bifurcate the YANG 1.1. It is simply to
> RECOMMEND a proper subset of XSD pattern that is more portable.
>

If you implement YANG as it is defined, pattern are portable. Given
this, I do not understand the notion of 'more portable'.

Anyway, it seems that those who want a more portable subset do not
even agree on what that subset is. Perhaps people pushing for this
should go and write an I-D that explains why a 'more portable' subset
is needed (which problems are we fixing), that defines such a 'more
portable subset', and which includes the reasoning how the subset has
been determined.



I do not agree that the YANG pattern contains a string that is both a POSIX and XSD regular expression.
The RFC is very clear it contains an XSD expression. Pretending it is both is a hack that does not even seem
to work 100%, so it is not reliable.
I am not suggesting that the YANG pattern is both a POSIX and XSD regular expression.

I am only suggesting that the guidelines recommend that authors use a subset of XSD, to make it easier to programmatically *convert* the 'XSD subset compliant regular expression' into a functionally equivalent regular expression for whatever regular expression engine the tooling decides to use.


Looks like you want the expression to mean the exact same thing in multiple expression languages
and you want to put the burden of this perfect subset on humans who write YANG.
Again, no, that is not what I want.

I would like the rules to recommend that authors of standards based YANG modules don't use the bits of the XML RE language that (i) they don't use anyway, (ii) don't appear to have any compelling use case in standard YANG modules, and (iii) are hard to convert to other RE languages.

There recommendations also have the additional advantage that the pattern statements that follow these rules are likely to be much easier to understand because they use the aspects of regular expressions languages that folks are likely to be more familiar with.

This is a really unworkable plan.
Is my proposed 6087bis text really that complicated?

Thanks,
Rob



 
E.g. this seems to be the approach used by "libyang" that uses libpcre as the backend RE library rather than libxml.  Unfortunately, I think that the libyang library would currently fail if the pattern statement contained "[[A-Z]-[P-R]]" because it looks like the PCRE2 language does not support character class subtraction.  ACAICT, no standard YANG modules currently support character class subtraction, so the authors of libyang have a choice here:
  (i) write a block of code that most likely nobody is going to use, or
  (ii) document the limitation, spot character class subtraction in the regex, and flag that it is not supported (or perhaps just ignore it).



If the community wants to support both XSD and POSIX expressions, then the proper engineering
solution is to introduce a new statement that is defined to contain a POSIX expression.
This can be done with a YANG extension now and added to YANG 2.0 later.
I think that this is an inferior solution:
- there are many languages that YANG tools could be written in: C/C++, Python, Java, Go, Rust, Javascript are all reasonably plausible choices.
- they all have similar, but with small differences regular expression flavours (according to http://www.regular-expressions.info/reference.html).
- Personally, I see no inherent advantage of the POSIX Extended Regex over XML RE.   In fact, given that it doesn't support Unicode at all, it would seem to be a somewhat strange choice for a second pattern statement.
- Nor does it seem pragmatic to introduce lots of different flavors of pattern statements into YANG each supporting a different regex syntax.



You seem to be confirming that picking 1 flavor of Posix would be impossible.
All the more reason to keep the XSD pattern unburdened. 
I see no reason XSD patterns should be constrained because some implementors want to
ignore the RFC and pretend the string is some other expression language.

 
I also don't like the solution that every YANG tool maker has to either link against libxml2,  or write their own efficient regular expression engine.  I'm not convinced that what the world needs is yet more regular expression implementations :-)
 
The write your own tools and don't use libxml2.



So, I still see that the better technical solution is always only define the pattern statements in XML RE language, but to strongly encourage folks to use a subset of that language for standards models (which they appear to be doing anyway) to make it easier to covert the regular expression into compatible versions for other engines.

Thanks,
Rob




Andy
 

 
/js

Andy
 

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

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




--------------5DF8CC9F5CE6942A870A5295-- From nobody Mon Sep 4 09:24:33 2017 Return-Path: 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 33FF21321B7 for ; Mon, 4 Sep 2017 09:24:32 -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 2dReP-to62TX for ; Mon, 4 Sep 2017 09:24:29 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001: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 ABFC01321C9 for ; Mon, 4 Sep 2017 09:24:28 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id z67so2699385iof.3 for ; Mon, 04 Sep 2017 09:24:28 -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=CKl5dmKFFC1kmzY8MOJTOVDQXbCkmJyqtnyak92d1hE=; b=K8zJ+ShRW0TkeenTWk9kncVVrAHbqlO4pVrS7CvEJcZcgvZgxxRKrREDdcx9Kl0mDL qbJtZtxzPJdrjLlMWPIe1llO0d+WSzXCrJ054S6lBZT4aOLwhRjwVz+WMVX7+cziRepf VWf/fgNL5eMicjmgrpQOPb34+LA35VwGxCjuqhUOrbM4yRme5YRC0aX1ZDPd8HKrRnz4 +YysVvkSj5Ar712OczgfPyYbK7MkzI4/eKhleO9tbJM1q4LRon205FreOvGHXCgrf71X FcjIGOKct5Z6We1EBItPF51OjeL1U87KqSlivSJE2QXQ6uk04Xfx48t0fXuCpdCYto2x phSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CKl5dmKFFC1kmzY8MOJTOVDQXbCkmJyqtnyak92d1hE=; b=QUByMiiPN43R/attTmmCOdZznA17+02x9pg/yCY7ie+93Uvm4rNExJfJHpUWAwPEuu B3uV2fDNkNZ9oiHoAltxfSXGWqqtA1b68Krcrt6ctETIcFBfxtYGhI0EZUio4w7ggiuK gzZUyi09KBpEE+8Ov45HwRXErUG6Hxt7Op5bI8YBBGpr1f1/Tg3RM2P9US0fLsEmure8 qlVTnjRID+eRTXUSCeg1vZDbhWZbkFeDF8vfGoWjpLF+4YTeJkh/TY4K+4aAlwlET/5W 9uody6lKvPhOGAGkiA6QJcFSDMZQRVTJ4e3zBHuRPhI2WWw/wOfiifSVWE23sGjqKkQK nmQg== X-Gm-Message-State: AHPjjUhBXuL8kwKFONOq6EY4KfRA67Qdf9sUIg4sNi3ARkabyE7xIVr4 dD6UvrmQn5ABVXCUIOuwGrArxmcPari8 X-Google-Smtp-Source: ADKCNb6k5SpagYsBwCy2hD36bc/86aVNfylBnDDwA8PqckpW/VJL9C3c1G8EHZlh+L5J5PH1vI9PRRUP9PL3xhpDzW0= X-Received: by 10.107.171.70 with SMTP id u67mr1267549ioe.227.1504542267936; Mon, 04 Sep 2017 09:24:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.6.206 with HTTP; Mon, 4 Sep 2017 09:24:27 -0700 (PDT) In-Reply-To: <20170904.092913.858833299379016670.mbj@tail-f.com> References: <56D58AA8-E71E-4CA1-B81E-70E2EDD94E91@juniper.net> <20170904.092913.858833299379016670.mbj@tail-f.com> From: Andy Bierman Date: Mon, 4 Sep 2017 09:24:27 -0700 Message-ID: To: Martin Bjorklund Cc: Kent Watsen , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="001a1148bd7a6e263405585f8bd6" Archived-At: Subject: Re: [netmod] regarding draft-bierman-netmod-yang-data-ext-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 16:24:32 -0000 --001a1148bd7a6e263405585f8bd6 Content-Type: text/plain; charset="UTF-8" On Mon, Sep 4, 2017 at 12:29 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Fri, Sep 1, 2017 at 10:43 AM, Kent Watsen > wrote: > > [Re: moving the definition of rc:yang-data to a new document] > > > > > > > > We went through that issue at least twice before RFC 8040. > > > > > > > There was no concern about this extension being in the RESTCONF spec. > > > > > > > > > > > > I don't think people understood what was at stake at the time - > yang-data > > > has since taken on more prominence. You write "no concern", but I > think > > > it was more like "no response", and the solution just rolled on. > > > > > > > I think I explained it well enough at the time. > > There is a normative reference to RESTCONF to use yang-data. > > This is just an RFC detail. In a server, the yang-library can indicate > > that ietf-restconf is just imported (not implemented). It really does not > > matter > > that this extension is in ietf-restconf.yang. > > > > > > > > > > > > > > > > > > > > > > We really have to try to keep the documents stable, and not > republish an > > > RFC > > > > > > > just to move definitions around. > > > > > > > > > > > > We are talking about a new RFC (this draft). I don't care if 8040 ever > > > uses the new yang-data statement, it can forever have its own private > > > definition. I do care that we introduce a long-term solution (again, > > > augment alone seems limited) and would like to make an incremental > > > improvement for normative references. > > > > > > > > > > > > > IMO it is not worth the trouble. > > If it wasn't for the new 'augment-yang-data' statement, I'd agree. > > But if we're doing a new standalone document for 'augment-yang-data', > I think we should also define 'yang-data' in that document. The cost > is minimal, and we get one self-contained document with all things > related to 'yang-data'. > > So you are saying I was right 2 years ago when I brought this issue up repeatedly? ;-) I don't agree that moving YANG definitions around for minor reasons is helpful. The larger YANG community (outside the IETF) are not asking for the foundation to be constantly replaced. They are not appreciative of constant churn in the standards. It seems we have already reached a point where we understand that modules are cheap. In some cases a new module does not even cost the length of a namespace string in a packet. We should learn to use YANG modularity, because it is almost free. The cost of high coupling and low cohesion is much worse that the cost of splitting up YANG modules at the start. > /martin > Andy --001a1148bd7a6e263405585f8bd6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Sep 4, 2017 at 12:29 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Fri, Sep 1, 2017 at 10:43 AM, Kent Watsen <kwatsen@juniper.net> wrote:

[Re: moving the definition of rc:yang-data to a new document]

> >
> > > We went through that issue at least twice before RFC 8040. > >
> > > There was no concern about this extension being in the RESTC= ONF spec.
> >
> >
> >
> > I don't think people understood what was at stake at the time= - yang-data
> > has since taken on more prominence.=C2=A0 =C2=A0 You write "= no concern", but I think
> > it was more like "no response", and the solution just r= olled on.
> >
>
> I think I explained it well enough at the time.
> There is a normative reference to RESTCONF to use yang-data.
> This is just an RFC detail. In a server, the yang-library can indicate=
> that ietf-restconf is just imported (not implemented). It really does = not
> matter
> that this extension is in ietf-restconf.yang.
>
>
>
> >
> >
> >
> >
> > > We really have to try to keep the documents stable, and not = republish an
> > RFC
> >
> > > just to move definitions around.
> >
> >
> >
> > We are talking about a new RFC (this draft).=C2=A0 I don't ca= re if 8040 ever
> > uses the new yang-data statement, it can forever have its own pri= vate
> > definition.=C2=A0 I do care that we introduce a long-term solutio= n (again,
> > augment alone seems limited) and would like to make an incrementa= l
> > improvement for normative references.
> >
> >
> >
>
> IMO it is not worth the trouble.

If it wasn't for the new 'augment-yang-data' statement, I'd= agree.

But if we're doing a new standalone document for 'augment-yang-data= ',
I think we should also define 'yang-data' in that document.=C2=A0 T= he cost
is minimal, and we get one self-contained document with all things
related to 'yang-data'.


So you are saying I was right 2 years ago when I bro= ught this issue up repeatedly? =C2=A0;-)
I don't agree that m= oving YANG definitions around for minor reasons is helpful.
The larger Y= ANG community (outside the IETF) are not asking for the foundation
to be constantly replaced. They are not appreciative of constant churn in= the standards.

It seems we have already reached a= point where we understand that modules are cheap.
In some cases = a new module does not even cost the length of a namespace string in a packe= t.
We should learn to use YANG modularity, because it is almost f= ree.=C2=A0 The cost of high coupling
and low cohesion is much wor= se that the cost of splitting up YANG modules at the start.

<= /div>



/martin

Andy<= /div>

--001a1148bd7a6e263405585f8bd6-- From nobody Mon Sep 4 09:50:45 2017 Return-Path: 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 489A91321B0 for ; Mon, 4 Sep 2017 09:50:44 -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 tRxEo6jkElOL for ; Mon, 4 Sep 2017 09:50:41 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 A6D79126C19 for ; Mon, 4 Sep 2017 09:50:41 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id b2so3059167iof.1 for ; Mon, 04 Sep 2017 09:50:41 -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=px9mw5rc67ivHXlkrvPsHebchrjhGCO6DuMORSXGZNI=; b=zeixHS+XG9Bpy7sGYD18W/48vM+JbybKaOFlYxGrJfc+J4fWqO+wSDpQJ+QW7dr5PF x3v9UXYZn0FCvLgCU/nnFKEkssa1wTnUFw1NRJv6jjkhmA6NTa+CIEemiUgoNDa/uFyZ wfs5184LHknXTtFqDSEFAaigV/j4B+kp4Wkjmkr5ROAATYOyn7veIzYJB6Af2jG8froh 6mNz5p8IfOjr0UADqbXn/X9hqOYPAUDMSiJQQYxppVnGHfUZunNhK+MzxMGvt76RrZJo qo83f0ILnVe+gfoRN5dsGNO+Ao4kkW6JVKakutSj8Xfb66L98w2cg+fudOkTA2LFwdl1 EirQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=px9mw5rc67ivHXlkrvPsHebchrjhGCO6DuMORSXGZNI=; b=S3VWRx+VOB2cHztyteoNuCmc3i26HW1aWZRKmSTQPS2V9V3YWhKWsf58wdUIZ2cdor Aq4EMb7DQ+52j347FUbefMIV+gAJ1ofgRRWyg0CW7WEncXj1/Bt5RmbNqPoWUnNUMhVh VpqzCIr1mMwUxLjgGoiHTmnZh2Jb1UYJQNMzqvaDyY1ufhW+a+Hi4NWyupP6DzAVdN/8 u/6WPVQK1DdXaplRn2JO+2LGzlA3BGRnJ5VjlNlnsQpTzm2fYqjKcz7yxZPf1xl74z9a 5/zATEWETPUzJDRYegk1siAiatQEQgyPt1HuebAme4652TI1C3tjArltg5dz1vrYoUev JrrA== X-Gm-Message-State: AHPjjUjZDgaQurM3gbw7gkroc9Sq/XLUPwZdcpfY3l6e8P4xH4NOUsOa M+hBsH27+/6pVX87DgftWeNJR2+h+dkG X-Google-Smtp-Source: ADKCNb4jCtSJs6Z/jX9NgPqLqPr1/ZGidmZAOe+3UJeKtD0n6FcogBVAmA4akb8mo8dA5eMW8hhXoduqnP0z4SVpOnU= X-Received: by 10.107.51.81 with SMTP id z78mr1347577ioz.146.1504543840901; Mon, 04 Sep 2017 09:50:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.6.206 with HTTP; Mon, 4 Sep 2017 09:50:40 -0700 (PDT) In-Reply-To: References: <20170830102902.2n5q6rgq2x2dxfq2@elstar.local> <20170830123156.cssrg5kklpo67fie@elstar.local> <1504223854014.55228@Aviatnet.com> <847e5bf9-7b3d-9ff8-9954-970f32a2094c@cisco.com> <20170902073342.xoziwor4tdr5bipw@elstar.local> <20170902112832.ymorfgdthobeio6q@elstar.local> <1e95ba5d-7aa2-e08f-56f9-27aa70822a11@cisco.com> From: Andy Bierman Date: Mon, 4 Sep 2017 09:50:40 -0700 Message-ID: To: Robert Wilton Cc: Juergen Schoenwaelder , "Acee Lindem (acee)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="001a11440c9c2fc69905585fe938" Archived-At: Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 16:50:44 -0000 --001a11440c9c2fc69905585fe938 Content-Type: text/plain; charset="UTF-8" On Mon, Sep 4, 2017 at 9:22 AM, Robert Wilton wrote: > > > On 04/09/2017 16:55, Andy Bierman wrote: > > > > On Mon, Sep 4, 2017 at 7:05 AM, Robert Wilton wrote: > >> Hi Andy, >> >> On 02/09/2017 17:46, Andy Bierman wrote: >> >> >> >> On Sat, Sep 2, 2017 at 4:28 AM, Juergen Schoenwaelder < >> j.schoenwaelder@jacobs-university.de> wrote: >> >>> On Sat, Sep 02, 2017 at 10:39:57AM +0000, Acee Lindem (acee) wrote: >>> > >>> > This is not an effort to change or bifurcate the YANG 1.1. It is >>> simply to >>> > RECOMMEND a proper subset of XSD pattern that is more portable. >>> > >>> >>> If you implement YANG as it is defined, pattern are portable. Given >>> this, I do not understand the notion of 'more portable'. >>> >>> Anyway, it seems that those who want a more portable subset do not >>> even agree on what that subset is. Perhaps people pushing for this >>> should go and write an I-D that explains why a 'more portable' subset >>> is needed (which problems are we fixing), that defines such a 'more >>> portable subset', and which includes the reasoning how the subset has >>> been determined. >>> >>> >> >> I do not agree that the YANG pattern contains a string that is both a >> POSIX and XSD regular expression. >> The RFC is very clear it contains an XSD expression. Pretending it is >> both is a hack that does not even seem >> to work 100%, so it is not reliable. >> >> I am not suggesting that the YANG pattern is both a POSIX and XSD regular >> expression. >> >> I am only suggesting that the guidelines recommend that authors use a >> subset of XSD, to make it easier to programmatically *convert* the 'XSD >> subset compliant regular expression' into a functionally equivalent regular >> expression for whatever regular expression engine the tooling decides to >> use. >> >> > Looks like you want the expression to mean the exact same thing in > multiple expression languages > and you want to put the burden of this perfect subset on humans who write > YANG. > > Again, no, that is not what I want. > > I would like the rules to recommend that authors of standards based YANG > modules don't use the bits of the XML RE language that (i) they don't use > anyway, (ii) don't appear to have any compelling use case in standard YANG > modules, and (iii) are hard to convert to other RE languages. > > There recommendations also have the additional advantage that the pattern > statements that follow these rules are likely to be much easier to > understand because they use the aspects of regular expressions languages > that folks are likely to be more familiar with. > > This is a really unworkable plan. > > Is my proposed 6087bis text really that complicated? > Yes -- way too complicated to burden all YANG module writers. We did a study at Cisco around 2002 to find out why engineers were having such a hard time learning to write MIB modules. It turned out that all the CLRs, the "helpful" arcane rules on top of standard rules, were causing great pain. IMO the IETF should not create a new special variant of the definition in XSD-TYPES, which is what 'SHOULD NOT use' guidelines in 6087bis will do. The pattern-stmt is like YANG XPath -- it is for describing the constraint. An implementation is not required to use off the shelf tools to enforce the constraint. In this case (libxml2) there are widely-available tools that could be leveraged. If conversion to a different parser is the desired implementation choice, then that should be the tool-makers problem. If a YANG module writer can be told "convert A to B" then so can a tool-maker. > Thanks, > Rob > > Andy > > > > >> E.g. this seems to be the approach used by "libyang" that uses libpcre as >> the backend RE library rather than libxml. Unfortunately, I think that the >> libyang library would currently fail if the pattern statement contained >> "[[A-Z]-[P-R]]" because it looks like the PCRE2 language does not support >> character class subtraction. ACAICT, no standard YANG modules currently >> support character class subtraction, so the authors of libyang have a >> choice here: >> (i) write a block of code that most likely nobody is going to use, or >> (ii) document the limitation, spot character class subtraction in the >> regex, and flag that it is not supported (or perhaps just ignore it). >> >> >> >> If the community wants to support both XSD and POSIX expressions, then >> the proper engineering >> solution is to introduce a new statement that is defined to contain a >> POSIX expression. >> This can be done with a YANG extension now and added to YANG 2.0 later. >> >> I think that this is an inferior solution: >> - there are many languages that YANG tools could be written in: C/C++, >> Python, Java, Go, Rust, Javascript are all reasonably plausible choices. >> - they all have similar, but with small differences regular expression >> flavours (according to http://www.regular-expressions.info/reference.html >> ). >> - Personally, I see no inherent advantage of the POSIX Extended Regex >> over XML RE. In fact, given that it doesn't support Unicode at all, it >> would seem to be a somewhat strange choice for a second pattern statement. >> - Nor does it seem pragmatic to introduce lots of different flavors of >> pattern statements into YANG each supporting a different regex syntax. >> >> > > You seem to be confirming that picking 1 flavor of Posix would be > impossible. > All the more reason to keep the XSD pattern unburdened. > I see no reason XSD patterns should be constrained because some > implementors want to > ignore the RFC and pretend the string is some other expression language. > > > >> I also don't like the solution that every YANG tool maker has to either >> link against libxml2, or write their own efficient regular expression >> engine. I'm not convinced that what the world needs is yet more regular >> expression implementations :-) >> > > The write your own tools and don't use libxml2. > > > >> So, I still see that the better technical solution is always only define >> the pattern statements in XML RE language, but to strongly encourage folks >> to use a subset of that language for standards models (which they appear to >> be doing anyway) to make it easier to covert the regular expression into >> compatible versions for other engines. >> >> Thanks, >> Rob >> >> >> > > Andy > > >> >> >> >>> /js >>> >> >> Andy >> >> >>> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>> Fax: +49 421 200 3103 >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> >> >> > > --001a11440c9c2fc69905585fe938 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Sep 4, 2017 at 9:22 AM, Robert Wilton <rwilton@cisco.com&g= t; wrote:
=20 =20 =20



On 04/09/2017 16:55= , Andy Bierman wrote:
=20


On Mon, Sep 4, 2017 at 7:05 AM, Robert Wilton <rwilton@cisco.com> wrote:

Hi Andy,


On 02/09/2017 17:46, Andy Bierman wrote:


On Sat, Sep 2, 2017 at 4:28 AM, Juergen Schoenwaelder &l= t;j.schoenwaelder@jacobs-university.de> wrote:
On Sat, Sep 02, 2017 at 10:39:57AM +0000, Acee Lindem (acee) wrote: >
> This is not an effort to change or bifurcate the YANG 1.1. It is simply to
> RECOMMEND a proper subset of XSD pattern that is more portable.
>

If you implement YANG as it is defined, pattern are portable. Given
this, I do not understand the notion of 'more portable'.

Anyway, it seems that those who want a more portable subset do not
even agree on what that subset is. Perhaps people pushing for this
should go and write an I-D that explains why a 'more portable' subset
is needed (which problems are we fixing), that defines such a 'more
portable subset', and which includes the reasoning how the subset has
been determined.



I do not agree that the YANG pattern contains a string that is both a POSIX and XSD regular expression.
The RFC is very clear it contains an XSD expression. Pretending it is both is a hack that does not even seem
to work 100%, so it is not reliable.
I am not suggesting that the YANG pattern is both a POSIX and XSD regular expression.

I am only suggesting that the guidelines recommend that authors use a subset of XSD, to make it easier to programmatically *convert* the 'XSD subset compliant regular expression' into a functionally equivalent regular expression for whatever regular expression engine the tooling decides to use.


Looks like you want the expression to mean the exact same thing in multiple expression languages
and you want to put the burden of this perfect subset on humans who write YANG.
Again, no, that is not what I want.

I would like the rules to recommend that authors of standards based YANG modules don't use the bits of the XML RE language that (i) the= y don't use anyway, (ii) don't appear to have any compelling use = case in standard YANG modules, and (iii) are hard to convert to other RE languages.

There recommendations also have the additional advantage that the pattern statements that follow these rules are likely to be much easier to understand because they use the aspects of regular expressions languages that folks are likely to be more familiar with.

This is a really unworkable plan.
Is my proposed 6087bis text really that complicated?


Yes -- way too complicated to burden= all YANG module writers.
We did a study at Cisco around 2002 to = find out why engineers were having
such a hard time learning to w= rite MIB modules.=C2=A0 It turned out that all the CLRs,
the &quo= t;helpful" arcane rules on top of standard rules, were causing great p= ain.
IMO the IETF should not create a new special variant of the = definition in XSD-TYPES,
which is what 'SHOULD NOT use' g= uidelines in 6087bis will do.

The pattern-stmt is = like YANG XPath -- it is for describing the constraint.
An implem= entation is not required to use off the shelf tools to enforce the constrai= nt.
In this case (libxml2) there are widely-available tools that = could be leveraged.
If conversion to a different parser is the de= sired implementation choice, then
that should be the tool-makers = problem. If a YANG module writer can be told "convert A to B"
then so can a tool-maker.



Thanks,
Rob


Andy
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">


=C2=A0
E.g. this seems to be the approach used by "libyang" that uses libpc= re as the backend RE library rather than libxml.=C2=A0 Unfortunately, I think that the libyang library would currently fail if the pattern statement contained "[[A-Z]-[P-R]]" because it looks like the PCRE2 l= anguage does not support character class subtraction.=C2=A0 ACAICT, no standard YANG modules currently support character class subtraction, so the authors of libyang have a choice here:
=C2=A0 (i) write a block of code that most likely nobody is going to use, or
=C2=A0 (ii) document the limitation, spot character class subtraction in the regex, and flag that it is not supported (or perhaps just ignore it).



If the community wants to support both XSD and POSIX expressions, then the proper engineering
solution is to introduce a new statement that is defined to contain a POSIX expression.
This can be done with a YANG extension now and added to YANG 2.0 later.
I think that this is an inferior solution:
- there are many languages that YANG tools could be written in: C/C++, Python, Java, Go, Rust, Javascript are all reasonably plausible choices.
- they all have similar, but with small differences regular expression flavours (according to http://www.= regular-expressions.info/reference.html).
- Personally, I see no inherent advantage of the POSIX Extended Regex over XML RE.=C2=A0=C2=A0 In fact, given that= it doesn't support Unicode at all, it would seem to be a somewhat strange choice for a second pattern statement.
- Nor does it seem pragmatic to introduce lots of different flavors of pattern statements into YANG each supporting a different regex syntax.



You seem to be confirming that picking 1 flavor of Posix would be impossible.
All the more reason to keep the XSD pattern unburdened.=C2=A0
I see no reason XSD patterns should be constrained because some implementors want to
ignore the RFC and pretend the string is some other expression language.

=C2=A0
I also don't l= ike the solution that every YANG tool maker has to either link against libxml2,=C2=A0 or write their own efficient regular expression engine.=C2=A0 I'm not convinced that= what the world needs is yet more regular expression implementations :-)
=C2=A0
The write your own tools and don't use libxml2.



So, I still see that the better technical solution is always only define the pattern statements in XML RE language, but to strongly encourage folks to use a subset of that language for standards models (which they appear to be doing anyway) to make it easier to covert the regular expression into compatible versions for other engines.

Thanks,
Rob




Andy
=C2=A0

=C2=A0
/js<= br>

Andy
=C2=A0

<= font color=3D"#888888"> --
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0Jacobs University Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/= >

____________________________________= ___________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/m= ailman/listinfo/netmod





--001a11440c9c2fc69905585fe938-- From nobody Tue Sep 5 00:12:35 2017 Return-Path: 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 9000713240D; Tue, 5 Sep 2017 00:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 s1UMp9jAmTrN; Tue, 5 Sep 2017 00:12:33 -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 8D6E1120727; Tue, 5 Sep 2017 00:12:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1071; q=dns/txt; s=iport; t=1504595552; x=1505805152; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=3/115RJ332EwH0zdJ1c1FLEM/tXEX7BFa8zuKwIri2g=; b=UMddJcpdfDi+RFb3NgkGMmLdQt35LIXeGMOEIZTxMCrI+OalR/u8Ip13 FU2zxALLLcVB3m6/zjVBO9P81V5TvHJKcAUCG2RZTNdMvtHdIKZ7GY0ls lK76I6xtcAYwqq5Ff9LtmhxiFmJL8Ssh2PryNFkJaCsxOLS6hWKmJJUmv s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DcAACwTa5Z/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD6BFYN3iiB0p0aCEgoYDYRKTwKEXxgBAgEBAQEBAQFrKIUZAgE?= =?us-ascii?q?DAQEhDwEFNhsLDgwCJgICJzAGAQwGAgEBii0QsHGCJ4tTAQEBAQEBAQECAQEBA?= =?us-ascii?q?QEBAQEbBYENgh2DUIFjK4J9iAiCYQEEoHSHW4x2ghOFZ4Nahx2JfINbhykDBgU?= =?us-ascii?q?CGYE5HziBDTIhCBwVSYcdPjaLHQEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,479,1498521600"; d="scan'208";a="696974395" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Sep 2017 07:12:30 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v857CUXJ014981; Tue, 5 Sep 2017 07:12:30 GMT To: Kent Watsen , "netmod@ietf.org" , "netconf-chairs@ietf.org" References: <14299503-509D-43BE-A938-0B7B88C3B249@juniper.net> From: Benoit Claise Message-ID: <3620aafe-bc72-cc54-9dbd-b687a0178df2@cisco.com> Date: Tue, 5 Sep 2017 09:12:30 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <14299503-509D-43BE-A938-0B7B88C3B249@juniper.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] upcoming adoptions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 07:12:34 -0000 Kent, > Hey folks, > > As discussed at the last meeting, we are heading to revising existing RFCs to align them with NMDA. The first batch have been published as individual drafts: > > 1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00 > 2. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00 > 3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00 Good. And there is one more in for NETMOD, as discussed in https://datatracker.ietf.org/meeting/99/materials/slides-99-netmod-sessa-nmda-qa: RFC 7317 In NETCONF, we have also:     RFC 6022, no I-D submitted yet     RFC 7895, already adopted     RFC 8040, no I-D submitted yet. No immediate plan to update? > > Please take a look (comments welcome!) and stay tuned for the related adoption calls. Yes, we know that we have to update those RFCs. Regards, Benoit > > Thanks, > Kent (and Lou) > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Tue Sep 5 00:18:50 2017 Return-Path: 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 965CD13263F; Tue, 5 Sep 2017 00:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMIC_nzSQSTC; Tue, 5 Sep 2017 00:18:41 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3057D132397; Tue, 5 Sep 2017 00:18:41 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2CBD8B819C5; Tue, 5 Sep 2017 00:18:37 -0700 (PDT) To: lhotka@nic.cz, j.schoenwaelder@jacobs-university.de X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: bclaise@cisco.com, iesg@ietf.org, netmod@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170905071837.2CBD8B819C5@rfc-editor.org> Date: Tue, 5 Sep 2017 00:18:37 -0700 (PDT) Archived-At: Subject: [netmod] [Errata Held for Document Update] RFC6991 (5105) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 07:18:43 -0000 The following errata report has been held for document update for RFC6991, "Common YANG Data Types". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5105 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Ladislav Lhotka Date Reported: 2017-09-01 Held by: Benoit Claise (IESG) Section: 3 Original Text ------------- A schema node of this type will be set to zero (0) on creation and will thereafter increase monotonically until it reaches a maximum value of 2^32-1 (4294967295 decimal), when it wraps around and starts increasing again from zero. Corrected Text -------------- A leaf instance of this type will be set to zero (0) on creation and will thereafter increase monotonically until it reaches a maximum value of 2^32-1 (4294967295 decimal), when it wraps around and starts increasing again from zero. Notes ----- In a number of descriptions in both ietf-yang-types and ietf-inet-types, the term "schema node" is used incorrectly in places where "leaf instance" or "instance of a leaf" should be used instead. However, not all occurences of "schema node" are wrong: schema nodes just have to be distinguished from nodes in an instance data tree. -------------------------------------- RFC6991 (draft-ietf-netmod-rfc6021-bis-03) -------------------------------------- Title : Common YANG Data Types Publication Date : July 2013 Author(s) : J. Schoenwaelder, Ed. Category : PROPOSED STANDARD Source : NETCONF Data Modeling Language Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Tue Sep 5 00:19:19 2017 Return-Path: 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 25A8C132623 for ; Tue, 5 Sep 2017 00:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 vM3y7apwdwQU for ; Tue, 5 Sep 2017 00:19:16 -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 336CD132397 for ; Tue, 5 Sep 2017 00:19:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2200; q=dns/txt; s=iport; t=1504595956; x=1505805556; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=xcbBMYDSK84gD62+3t0Jc2e9UX2wQDwyHvaFmkHA8aA=; b=TJyuX1bE5qnB+gjpMFtf6FCjsUpKzEIa52091FKojNM4eGtgzxmOTQMR SI0bmOlUfGSpDNOF3oYT2ahHEmSnvEQg5Ot/HGXB7JzAoa62tRiLElzNk 93YxaNJHbAXlXJ/PygonlddDHGi9sqSqcCGyMs4ZW3iCfAPULRi+xhFs2 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APBADNTq5Z/xbLJq1TChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQ+gRUBg3aLFJEemDoKI4UbAoRiFQECAQEBAQEBAWsohRkBBSM?= =?us-ascii?q?PAQVBEAkCGAICJgICVwYBDAYCAQGKLRCTDZ1mgieLUwEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAR2BDYIdg1CCDoJ9gTyDDoM+gmEBBIoGlm6UUYtUhx2NV4cpAwYFAhm?= =?us-ascii?q?BOTUigQ0yIQgcFUmFJIF5PjaLHQEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,479,1498521600"; d="scan'208";a="654405904" 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; 05 Sep 2017 07:19:14 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v857JDnD032656; Tue, 5 Sep 2017 07:19:14 GMT To: Ladislav Lhotka , Juergen Schoenwaelder , RFC Errata System Cc: warren@kumari.net, kwatsen@juniper.net, lberger@labn.net, netmod@ietf.org References: <20170901144056.60AC4B80E23@rfc-editor.org> <20170901164841.ebs2fqvf2vl3adlx@elstar.local> <1504512772.5874.4.camel@nic.cz> From: Benoit Claise Message-ID: <361fc21c-bc94-73e8-f92f-7130e1a5b889@cisco.com> Date: Tue, 5 Sep 2017 09:19:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1504512772.5874.4.camel@nic.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] [Technical Errata Reported] RFC6991 (5105) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 07:19:18 -0000 On 9/4/2017 10:12 AM, Ladislav Lhotka wrote: > Juergen Schoenwaelder píše v Pá 01. 09. 2017 v 18:48 +0200: >> On Fri, Sep 01, 2017 at 07:40:56AM -0700, RFC Errata System wrote: >>> The following errata report has been submitted for RFC6991, >>> "Common YANG Data Types". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata/eid5105 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Ladislav Lhotka >>> >>> Section: 3 >>> >>> Original Text >>> ------------- >>> A schema node of this type will be set to zero (0) on creation >>> and will thereafter increase monotonically until it reaches >>> a maximum value of 2^32-1 (4294967295 decimal), when it >>> wraps around and starts increasing again from zero. >>> >>> Corrected Text >>> -------------- >>> A leaf instance of this type will be set to zero (0) on creation >>> and will thereafter increase monotonically until it reaches >>> a maximum value of 2^32-1 (4294967295 decimal), when it >>> wraps around and starts increasing again from zero. >>> >>> Notes >>> ----- >>> In a number of descriptions in both ietf-yang-types and ietf-inet-types, the term "schema node" is used incorrectly in places where "leaf instance" or "instance of a leaf" should be used instead. However, not all occurences of "schema node" are wrong: schema nodes just have to be distinguished from nodes in an instance data tree. >>> >> Yes. I would probably prefer 'a data node instance of this type' >> instead of 'a leaf instance' - I am not sure I would to exclude a >> leaf-list and who knows whether we have any other data nodes in the >> future. And yes, all occurances of 'schema node' need careful > OK. > >> inspection. I am not sure whether you want to identify all occurances >> now or whether you wanted to have a generic errata just so that we do >> not forget to fix this when this document is revised. > I think it should suffice to keep this general erratum and fixed it in the next > revision. Just flagged as such in the system. Regards, Benoit > > Thanks, Lada > >> /js >> From nobody Tue Sep 5 01:01:33 2017 Return-Path: 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 396461326DF; Tue, 5 Sep 2017 01:01: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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2s0O30Jgb1nR; Tue, 5 Sep 2017 01:01:25 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 28BB4132396; Tue, 5 Sep 2017 01:01:25 -0700 (PDT) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id CBAE21AE02C9; Tue, 5 Sep 2017 10:01:22 +0200 (CEST) Date: Tue, 05 Sep 2017 09:59:49 +0200 (CEST) Message-Id: <20170905.095949.1829098658779783521.mbj@tail-f.com> To: bclaise@cisco.com Cc: kwatsen@juniper.net, netmod@ietf.org, netconf-chairs@ietf.org From: Martin Bjorklund In-Reply-To: <3620aafe-bc72-cc54-9dbd-b687a0178df2@cisco.com> References: <14299503-509D-43BE-A938-0B7B88C3B249@juniper.net> <3620aafe-bc72-cc54-9dbd-b687a0178df2@cisco.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] upcoming adoptions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 08:01:31 -0000 Benoit Claise wrote: > Kent, > > Hey folks, > > > > As discussed at the last meeting, we are heading to revising existi= ng > > RFCs to align them with NMDA. The first batch have been published = as > > individual drafts: > > > > 1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00= > > 2. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00= > > 3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00 > Good. And there is one more in for NETMOD, as discussed in > https://datatracker.ietf.org/meeting/99/materials/slides-99-netmod-se= ssa-nmda-qa: > RFC 7317 > In NETCONF, we have also: > =A0=A0=A0 RFC 6022, no I-D submitted yet I don't think this one requires an update at this time. *If* it is changed, it might be worthwhile to remove definitions already covered by yang-library, and probably align with the netconf server model. > =A0=A0=A0 RFC 7895, already adopted > =A0=A0=A0 RFC 8040, no I-D submitted yet. No immediate plan to update= ? We have draft-ietf-netconf-nmda-restconf-00 which "Updates: 8040". /martin From nobody Tue Sep 5 09:35:28 2017 Return-Path: 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 D7991132D86 for ; Tue, 5 Sep 2017 09:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 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, URIBL_BLOCKED=0.001] 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 Z4aIO5hOkq44 for ; Tue, 5 Sep 2017 09:35:23 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 4749B132D79 for ; Tue, 5 Sep 2017 09:35:22 -0700 (PDT) Received: from birdie (cst-prg-10-96.cust.vodafone.cz [46.135.10.96]) by mail.nic.cz (Postfix) with ESMTPSA id E534061E0E; Tue, 5 Sep 2017 18:35:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1504629320; bh=J1PbPq8MoLf7Uaz4t9t6X6BDt0LkvAEUCk69JHVJBO8=; h=From:To:Date; b=DeUKu+F75ayvvvfFtR3lORe9tdBscZuWxIXpsBBF2vvwj7/K+FPy1vVxBOsiZNTDM Jb7H3wipC7sV1F6L3bwc7G/p4BB/7JdMBh3zwMAxLZGDyobibBFYEufOlkyZ725QVP p74VvM+zJF2dKSufH7wvL2/a+XvtfRVORn/N7140= Message-ID: <1504629352.7175.40.camel@nic.cz> From: Ladislav Lhotka To: Robert Wilton , netmod@ietf.org Date: Tue, 05 Sep 2017 18:35:52 +0200 In-Reply-To: References: <20170830102902.2n5q6rgq2x2dxfq2@elstar.local> <20170830123156.cssrg5kklpo67fie@elstar.local> <1504223854014.55228@Aviatnet.com> <847e5bf9-7b3d-9ff8-9954-970f32a2094c@cisco.com> <20170902073342.xoziwor4tdr5bipw@elstar.local> <20170902112832.ymorfgdthobeio6q@elstar.local> <1e95ba5d-7aa2-e08f-56f9-27aa70822a11@cisco.com> <1504537140.5874.38.camel@nic.cz> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.5 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 16:35:27 -0000 Robert Wilton píše v Po 04. 09. 2017 v 17:07 +0100: > Hi Lada, > > On 04/09/2017 15:59, Ladislav Lhotka wrote: > > Robert Wilton píše v Po 04. 09. 2017 v 15:05 +0100: > > > Hi Andy, > > > > > > On 02/09/2017 17:46, Andy Bierman wrote: > > > > On Sat, Sep 2, 2017 at 4:28 AM, Juergen Schoenwaelder > > > acobs-university.de> wrote: > > > > > On Sat, Sep 02, 2017 at 10:39:57AM +0000, Acee Lindem (acee) wrote: > > > > > > This is not an effort to change or bifurcate the YANG 1.1. It is > > > > > > simply to > > > > > > RECOMMEND a proper subset of XSD pattern that is more portable. > > > > > > > > > > > > > > > > If you implement YANG as it is defined, pattern are portable. Given > > > > > this, I do not understand the notion of 'more portable'. > > > > > > > > > > Anyway, it seems that those who want a more portable subset do not > > > > > even agree on what that subset is. Perhaps people pushing for this > > > > > should go and write an I-D that explains why a 'more portable' subset > > > > > is needed (which problems are we fixing), that defines such a 'more > > > > > portable subset', and which includes the reasoning how the subset has > > > > > been determined. > > > > > > > > > > > > > > > > > > I do not agree that the YANG pattern contains a string that is both a > > > > POSIX and XSD regular expression. > > > > The RFC is very clear it contains an XSD expression. Pretending it is > > > > both is a hack that does not even seem > > > > to work 100%, so it is not reliable. > > > > > > I am not suggesting that the YANG pattern is both a POSIX and XSD > > > regular expression. > > > > > > I am only suggesting that the guidelines recommend that authors use a > > > subset of XSD, to make it easier to programmatically *convert* the 'XSD > > > subset compliant regular expression' into a functionally equivalent > > > regular expression for whatever regular expression engine the tooling > > > decides to use. > > > > And that's the point, I think: each developer needs to get a library > > function so > > as to translate the XSD pattern into a native regex of whatever programming > > language he/she is currently using. So I guess what we really need is to > > identify libraries for common languages that do it correctly - or write > > simple > > translators ourselves if none is available. > > Yes, exactly. > > Looking at http://www.regular-expressions.info/ then XML RE does look > like a good standard choice of RE language for YANG pattern statements > because it is generally one of the most basic RE languages, and hence it > should be feasible to convert an XML RE into a form usable by most RE > languages. Yes, and the XSD RE language was also designed for pretty much the same purpose (data type system). > > But converting some parts of the XML RE syntax would probably be laborious: Unicode support is of course hairy but since YANG permits it in the string type it makes sense that the pattern language follow suit. RE flavours used in modern programming languages support Unicode, so the translation should be doable (if it hasn't been done yet). > 1) E.g. the unicode property '\p{Nd}' that is equivalent to '\d' matches > 590 characters > (http://www.fileformat.info/info/unicode/category/Nd/list.htm). There > are approx 32 unicode properties, presumably these could also be > extended over time as well. > 2) There are currently 105 unicode blocks, which each block is a > discrete range of characters (e.g. \p{InTibetan}: U+0F00–U+0FFF) > 3) Handling the character class subtraction is also possible, but > probably tedious to implement, since it requires the translation to > fully understand the set of characters in the character class so it can > form an equivalent character class without any subtractions. But now with the "invert-match" modifier in YANG 1.1, implementations have to be able to perform such set differences anyway, right? > These were the three parts of the XML RE that I was hoping to discourage > in the YANG author guidelines so that performing a translation is much > easier. Spotting these 3 parts in the regex should be simple, so the > translation would still be robust, even if not complete. I believe that tools intended for general use should follow the YANG spec literally. > > There are other conversions that may also need to be performed > (depending on the target RE engine): > 1) Character class shorthands (e.g. \d, \w) need to be converted to > represent the Unicode set equivalent, since for a lot of engines they > only match ASCII characters. For '\s' it must match ASCII whitespace only. I think they should mean exactly what XSD spec says they mean. > 2) If the engine supports greedy alternation (e.g. POSIX basic/extended > regex), then alternations need to be converted to an eager form if required. Yes, and this is a subtle point that could otherwise be easily overlooked. > 3) The syntax for escaping characters seems to differ in XML RE from > other common languages. > 4) Linebreak match handling seems to differ. 3 and 4 are IMO not a big deal. > These conversions would need to be done regardless, but would seem to be > much quicker/simpler to implement than the ones above. Tools and libraries would then differ in the degree of sloppiness and possibly give different results, which is not good. Lada > > Thanks, > Rob > > > > > > > E.g. this seems to be the approach used by "libyang" that uses libpcre as > > > the backend RE library rather than libxml. Unfortunately, I think that > > > the libyang library would currently fail if the pattern statement > > > contained "[[A-Z]-[P-R]]" because it looks like the PCRE2 language does > > > not support character class subtraction. ACAICT, no standard YANG modules > > > currently support character class subtraction, so the authors of libyang > > > have a choice here: > > > > Note that your example is incorrect, it should be [A-Z-[P-R]]. FWIW, Python > > module PyXB (that I used in Yangson library) does support this. > > > > Lada > > > > > (i) write a block of code that most likely nobody is going to use, or > > > (ii) document the limitation, spot character class subtraction in the > > > regex, and flag that it is not supported (or perhaps just ignore it). > > > > > > > > > > If the community wants to support both XSD and POSIX expressions, then > > > > the proper engineering > > > > solution is to introduce a new statement that is defined to contain a > > > > POSIX expression. > > > > This can be done with a YANG extension now and added to YANG 2.0 later. > > > > > > I think that this is an inferior solution: > > > - there are many languages that YANG tools could be written in: C/C++, > > > Python, Java, Go, Rust, Javascript are all reasonably plausible choices. > > > - they all have similar, but with small differences regular expression > > > flavours (according to http://www.regular-expressions.info/reference.html) > > > . > > > - Personally, I see no inherent advantage of the POSIX Extended Regex over > > > XML RE. In fact, given that it doesn't support Unicode at all, it would > > > seem to be a somewhat strange choice for a second pattern statement. > > > - Nor does it seem pragmatic to introduce lots of different flavors of > > > pattern statements into YANG each supporting a different regex syntax. > > > > > > I also don't like the solution that every YANG tool maker has to either > > > link against libxml2, or write their own efficient regular expression > > > engine. I'm not convinced that what the world needs is yet more regular > > > expression implementations :-) > > > > > > So, I still see that the better technical solution is always only define > > > the pattern statements in XML RE language, but to strongly encourage folks > > > to use a subset of that language for standards models (which they appear > > > to be doing anyway) to make it easier to covert the regular expression > > > into compatible versions for other engines. > > > > > > Thanks, > > > Rob > > > > > > > > > > > > > > > /js > > > > > > > > > > > > > Andy > > > > > > > > > -- > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > > > Fax: +49 421 200 3103 > > > > > > > > > > _______________________________________________ > > > > > netmod mailing list > > > > > netmod@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Sep 5 10:17:18 2017 Return-Path: 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 595D2132DD6 for ; Tue, 5 Sep 2017 10:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 01-RqYaM66Ck for ; Tue, 5 Sep 2017 10:17:14 -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 4500A132D9C for ; Tue, 5 Sep 2017 10:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10516; q=dns/txt; s=iport; t=1504631834; x=1505841434; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=u75SwsWUwi3sWhG5TdInqjwEltQrEzB/JqOO9rEbPq8=; b=B00n4+o/WbLQlgEyiTd7shmeO946pA/pvnITKlcUTBf4InruSP83ljSA d8jwJ8pDp8oTkJyonzj/Q5idn36DouS2xPpzUYT1NKKkYVQFa0mreQdSS p6RBKULvWqwFkclIYrjwNt9W8DFKnSXk9JPyLJ2n54aF3K2rxegKvybyv A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CsAgCJ2q5Z/xbLJq1UBwMZAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGEPoEVg3eLFJB8IneUS4J4ChgLhExPAoR1FAECAQEBAQEBAWs?= =?us-ascii?q?ohRgBAQEBAgEBASEPAQU2GQIJAhAIAgImAgIbDDAGAQwGAgEBEAeKDggQlEGdZ?= =?us-ascii?q?oInizMBAQEBAQEBAQIBAQEBAQEBAQEBAR0FgQiCHYNQgWMrC4I9NYRKTCaCTIJ?= =?us-ascii?q?hBaB0h1uMdotUhx2NV4Qcgw0DBgUCGYE5NiGBDTIhCBwVSYccPzYBixEBAQE?= X-IronPort-AV: E=Sophos;i="5.41,480,1498521600"; d="scan'208";a="654419012" 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; 05 Sep 2017 17:17:09 +0000 Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v85HH9oI002966; Tue, 5 Sep 2017 17:17:09 GMT To: Ladislav Lhotka , netmod@ietf.org References: <20170830102902.2n5q6rgq2x2dxfq2@elstar.local> <20170830123156.cssrg5kklpo67fie@elstar.local> <1504223854014.55228@Aviatnet.com> <847e5bf9-7b3d-9ff8-9954-970f32a2094c@cisco.com> <20170902073342.xoziwor4tdr5bipw@elstar.local> <20170902112832.ymorfgdthobeio6q@elstar.local> <1e95ba5d-7aa2-e08f-56f9-27aa70822a11@cisco.com> <1504537140.5874.38.camel@nic.cz> <1504629352.7175.40.camel@nic.cz> From: Robert Wilton Message-ID: <8af6041d-7cd5-9608-70b4-7cffc4f884f8@cisco.com> Date: Tue, 5 Sep 2017 18:17:09 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1504629352.7175.40.camel@nic.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 17:17:17 -0000 On 05/09/2017 17:35, Ladislav Lhotka wrote: > Robert Wilton píše v Po 04. 09. 2017 v 17:07 +0100: >> Hi Lada, >> >> On 04/09/2017 15:59, Ladislav Lhotka wrote: >>> Robert Wilton píše v Po 04. 09. 2017 v 15:05 +0100: >>>> Hi Andy, >>>> >>>> On 02/09/2017 17:46, Andy Bierman wrote: >>>>> On Sat, Sep 2, 2017 at 4:28 AM, Juergen Schoenwaelder >>>> acobs-university.de> wrote: >>>>>> On Sat, Sep 02, 2017 at 10:39:57AM +0000, Acee Lindem (acee) wrote: >>>>>>> This is not an effort to change or bifurcate the YANG 1.1. It is >>>>>>> simply to >>>>>>> RECOMMEND a proper subset of XSD pattern that is more portable. >>>>>>> >>>>>> If you implement YANG as it is defined, pattern are portable. Given >>>>>> this, I do not understand the notion of 'more portable'. >>>>>> >>>>>> Anyway, it seems that those who want a more portable subset do not >>>>>> even agree on what that subset is. Perhaps people pushing for this >>>>>> should go and write an I-D that explains why a 'more portable' subset >>>>>> is needed (which problems are we fixing), that defines such a 'more >>>>>> portable subset', and which includes the reasoning how the subset has >>>>>> been determined. >>>>>> >>>>>> >>>>> I do not agree that the YANG pattern contains a string that is both a >>>>> POSIX and XSD regular expression. >>>>> The RFC is very clear it contains an XSD expression. Pretending it is >>>>> both is a hack that does not even seem >>>>> to work 100%, so it is not reliable. >>>> I am not suggesting that the YANG pattern is both a POSIX and XSD >>>> regular expression. >>>> >>>> I am only suggesting that the guidelines recommend that authors use a >>>> subset of XSD, to make it easier to programmatically *convert* the 'XSD >>>> subset compliant regular expression' into a functionally equivalent >>>> regular expression for whatever regular expression engine the tooling >>>> decides to use. >>> And that's the point, I think: each developer needs to get a library >>> function so >>> as to translate the XSD pattern into a native regex of whatever programming >>> language he/she is currently using. So I guess what we really need is to >>> identify libraries for common languages that do it correctly - or write >>> simple >>> translators ourselves if none is available. >> Yes, exactly. >> >> Looking at http://www.regular-expressions.info/ then XML RE does look >> like a good standard choice of RE language for YANG pattern statements >> because it is generally one of the most basic RE languages, and hence it >> should be feasible to convert an XML RE into a form usable by most RE >> languages. > Yes, and the XSD RE language was also designed for pretty much the same purpose > (data type system). > >> But converting some parts of the XML RE syntax would probably be laborious: > Unicode support is of course hairy but since YANG permits it in the string type > it makes sense that the pattern language follow suit. > > RE flavours used in modern programming languages support Unicode, so the > translation should be doable (if it hasn't been done yet). Yes. POSIX extended regex (that one proposed by OpenConfig) is the odd one out here because it doesn't support unicode. Still I haven't seen any standards based RFC or IETF draft YANG models that need to match either unicode properties or blocks.  The IPv4/v6 zone address uses them, but I suspect that '\w' would have been sufficient. > >> 1) E.g. the unicode property '\p{Nd}' that is equivalent to '\d' matches >> 590 characters >> (http://www.fileformat.info/info/unicode/category/Nd/list.htm). There >> are approx 32 unicode properties, presumably these could also be >> extended over time as well. >> 2) There are currently 105 unicode blocks, which each block is a >> discrete range of characters (e.g. \p{InTibetan}: U+0F00–U+0FFF) >> 3) Handling the character class subtraction is also possible, but >> probably tedious to implement, since it requires the translation to >> fully understand the set of characters in the character class so it can >> form an equivalent character class without any subtractions. > But now with the "invert-match" modifier in YANG 1.1, implementations have to be > able to perform such set differences anyway, right? No.  Character class subtraction applies to a single character class match in the expression.  The "invert-match" applies to the whole regex check.  The same regex check can be performed and the boolean result reversed. > >> These were the three parts of the XML RE that I was hoping to discourage >> in the YANG author guidelines so that performing a translation is much >> easier. Spotting these 3 parts in the regex should be simple, so the >> translation would still be robust, even if not complete. > I believe that tools intended for general use should follow the YANG spec > literally. I don't fully agree.  I think that they only need to cover the parts of the YANG spec for the models that they are using (or might use). If nobody uses Unicode blocks then it doesn't really matter whether a given tool supports them or not.  It is always possible to caveat and add support for the missing bits later.  E.g. if I was writing a bespoke XPATH implementation for YANG then there is probably quite a lot of the XPATH spec that I would also leave out as well, and just concentrate on the parts that people actually use, or are likely to use. > >> There are other conversions that may also need to be performed >> (depending on the target RE engine): >> 1) Character class shorthands (e.g. \d, \w) need to be converted to >> represent the Unicode set equivalent, since for a lot of engines they >> only match ASCII characters. For '\s' it must match ASCII whitespace only. > I think they should mean exactly what XSD spec says they mean. Yes.  I agree.  I'm only listing that conversions are likely necessary to convert an XSD RE into one of the other standard RE implementations. > >> 2) If the engine supports greedy alternation (e.g. POSIX basic/extended >> regex), then alternations need to be converted to an eager form if required. > Yes, and this is a subtle point that could otherwise be easily overlooked. > >> 3) The syntax for escaping characters seems to differ in XML RE from >> other common languages. >> 4) Linebreak match handling seems to differ. > 3 and 4 are IMO not a big deal. But they do matter to avoid "Tools and libraries would then differ in the degree of sloppiness and possibly give different results, which is not good." > >> These conversions would need to be done regardless, but would seem to be >> much quicker/simpler to implement than the ones above. > Tools and libraries would then differ in the degree of sloppiness and possibly > give different results, which is not good. Sorry, I don't get this last point. However, I have thrown in the towel on my regex crusade. But I still suspect that most model authors/readers are likely to get the usage of '\d' wrong ...  but perhaps it doesn't really matter. Thanks, Rob > > Lada > >> Thanks, >> Rob >> >> >>>> E.g. this seems to be the approach used by "libyang" that uses libpcre as >>>> the backend RE library rather than libxml. Unfortunately, I think that >>>> the libyang library would currently fail if the pattern statement >>>> contained "[[A-Z]-[P-R]]" because it looks like the PCRE2 language does >>>> not support character class subtraction. ACAICT, no standard YANG modules >>>> currently support character class subtraction, so the authors of libyang >>>> have a choice here: >>> Note that your example is incorrect, it should be [A-Z-[P-R]]. FWIW, Python >>> module PyXB (that I used in Yangson library) does support this. >>> >>> Lada >>> >>>> (i) write a block of code that most likely nobody is going to use, or >>>> (ii) document the limitation, spot character class subtraction in the >>>> regex, and flag that it is not supported (or perhaps just ignore it). >>>> >>>> >>>>> If the community wants to support both XSD and POSIX expressions, then >>>>> the proper engineering >>>>> solution is to introduce a new statement that is defined to contain a >>>>> POSIX expression. >>>>> This can be done with a YANG extension now and added to YANG 2.0 later. >>>> I think that this is an inferior solution: >>>> - there are many languages that YANG tools could be written in: C/C++, >>>> Python, Java, Go, Rust, Javascript are all reasonably plausible choices. >>>> - they all have similar, but with small differences regular expression >>>> flavours (according to http://www.regular-expressions.info/reference.html) >>>> . >>>> - Personally, I see no inherent advantage of the POSIX Extended Regex over >>>> XML RE. In fact, given that it doesn't support Unicode at all, it would >>>> seem to be a somewhat strange choice for a second pattern statement. >>>> - Nor does it seem pragmatic to introduce lots of different flavors of >>>> pattern statements into YANG each supporting a different regex syntax. >>>> >>>> I also don't like the solution that every YANG tool maker has to either >>>> link against libxml2, or write their own efficient regular expression >>>> engine. I'm not convinced that what the world needs is yet more regular >>>> expression implementations :-) >>>> >>>> So, I still see that the better technical solution is always only define >>>> the pattern statements in XML RE language, but to strongly encourage folks >>>> to use a subset of that language for standards models (which they appear >>>> to be doing anyway) to make it easier to covert the regular expression >>>> into compatible versions for other engines. >>>> >>>> Thanks, >>>> Rob >>>> >>>> >>>>> >>>>>> /js >>>>>> >>>>> Andy >>>>> >>>>>> -- >>>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>>>>> Fax: +49 421 200 3103 >>>>>> >>>>>> _______________________________________________ >>>>>> netmod mailing list >>>>>> netmod@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>> >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >> From nobody Tue Sep 5 10:40:28 2017 Return-Path: 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 47915132DA2 for ; Tue, 5 Sep 2017 10:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.011 X-Spam-Level: X-Spam-Status: No, score=-3.011 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 d1TwIfrAh2pg for ; Tue, 5 Sep 2017 10:40:24 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0094.outbound.protection.outlook.com [104.47.42.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7DF132D62 for ; Tue, 5 Sep 2017 10:40:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pm5pgJ2C3W2PlIkPD0AT06HxukyX/XZHwgl0g0jyeTA=; b=Ku8JUG5gkxQFC17f2X7A3Keguuyb4p3Krxhiv6tzEemNAy1ebX0t41pa1jbXovs57kQGadd3RSXR6hFG84MoInAXlrQDqytLwR9I3kWPxlyqCuSbdntglyIB/0ZodujpDmVeukGhRb+NIB5NI/GCEQUX9k/VntgG3Z46G8PzslU= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1153.namprd05.prod.outlook.com (10.160.113.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.3; Tue, 5 Sep 2017 17:40:23 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.20.0035.010; Tue, 5 Sep 2017 17:40:23 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: 'status' statement needed on every node Thread-Index: AQHTJm4NQwnHS69prEmUfJVnsti89w== Date: Tue, 5 Sep 2017 17:40:23 +0000 Message-ID: <13F2175A-C913-4173-BE2A-50C668C08FF6@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1153; 6:Wk4jw3ugjKt5eVGM+yy/Y8CKOcB/qZ4OuWnnQshPDjU89GFfhoHZL1VkMFAp7cOoHzXYE6mRab4u7mapL0mEH9BWktTwIPRQkabF00P7llriU2W3Tag1kLUoeH+85xYYDIA4xWPBJJAQMxKWhGHKWavf99MF6zy5/dSNWBVp9UwSkClDCcEYLM7l1Hgkeb5NFNInSuSwpixcrc7V6g3mpkYcKCSqC5iP+L0u0L8Unh4t1hGYJokZswWEVK/xzB3rr2zKL6OnzCnV9cZJNTdpXc1zZBFjOzcPvPyESmWOlcEF2eRsU3s5Jtp409muttAYa9eyPXIK7AArP5VzygqTKA==; 5:BwxFtZlAGjnyfCUWfegjDRQR+zMWy1mi3m48COIdpvQBB2UI2QjLiVJ1lcPAKRj69VZnXBnqQuL/IsI0fjPUbm6lsrSMdKrgnstblXWZZ7OXLa3f7L0/eJk/SZiY6jeTApocm9BWfg0HfC80tvtNvg==; 24:E4eCHAJLpq0FyoVP6oeGX8EBcaxZllyX0NrRsBb4gG3xUsz+TCJ5a11/RKHnBuP94yrjiXuAJbwwHEIegNmAN7f4bcByo+4kT3u70vbDatg=; 7:EmfzWz34Zgfs2bUfscxxTlimp2R9KBJHAb3w3zN3l8OPC+XzEE3RzvOdVB7ZAQcGDHLWo0ptNLCAD55MoW+p73Ad5K3WrvF8mSC84F0hLr90+vd1yllsc1C7cauWvvGOAXEoRXUOU5f1mX9IuYVJU5k+jcBf8h7WLXO27ATKdxoHE7vXmdecYscp8JeUe4skj4Ll2Ha2nITe2EHb7TAPEGmwgz/mVP6Mj5iQedIdOZ0= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 686c68ef-e77d-46a9-90cb-08d4f4852ff7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1153; x-ms-traffictypediagnostic: BN3PR0501MB1153: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123564025)(20161123555025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1153; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1153; x-forefront-prvs: 0421BF7135 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(189002)(199003)(105586002)(2351001)(8676002)(14454004)(2900100001)(106356001)(478600001)(102836003)(6116002)(3846002)(7736002)(5640700003)(83506001)(81166006)(8936002)(81156014)(5660300001)(53936002)(83716003)(86362001)(1730700003)(4001350100001)(25786009)(101416001)(66066001)(110136004)(54356999)(97736004)(2906002)(2501003)(6486002)(77096006)(3280700002)(305945005)(189998001)(36756003)(99286003)(82746002)(33656002)(50986999)(6512007)(68736007)(6506006)(6436002)(6916009)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1153; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <7407549DE3F8A449B876D90551F3048F@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Sep 2017 17:40:23.7257 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1153 Archived-At: Subject: [netmod] 'status' statement needed on every node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 17:40:26 -0000 DQoNCldpdGggYWxsIHRoZSBkZXByZWNhdGluZyBvZiAiLXN0YXRlIiB0cmVlcyBnb2luZyBvbiB0 aGVzZSBkYXlzLA0KdGhlICdzdGF0dXMnIHN0YXRlbWVudCBpcyBnZXR0aW5nIGxvdHMgb2YgdXNl LiAgDQoNCkkgdW5kZXJzdGFuZCB0aGF0IHNvbWUgZmVlbCB0aGF0IHRoZSBzdGF0dXMgc3RhdGVt ZW50IG5lZWRzIHRvIGJlDQpwbGFjZWQgb24gZXZlcnkgbm9kZSwgc2luY2UgaXQgaXMgbm90IGlu aGVyaXRlZC4gIFRoaXMgc2VudGltZW50DQpsaWtlbHkgc3RlbXMgZnJvbSBSRkMgNzk1MCBzdGF0 aW5nICJJZiBubyBzdGF0dXMgaXMgc3BlY2lmaWVkLCANCnRoZSBkZWZhdWx0IGlzIGN1cnJlbnQi IGFuZCwgb2YgY291cnNlLCBpdCBub3Qgc3RhdGluZyB0aGF0IHN0YXR1cw0KaXMgaW5oZXJpdGVk Lg0KDQpJIGFwcHJlY2lhdGUgdGhhdCB0aGlzIGlzIGp1c3QgZm9sbG93aW5nIHJ1bGVzLCBidXQg aXQgc2VlbXMNCmV4Y2Vzc2l2ZSBhbmQgSSBkb24ndCB1bmRlcnN0YW5kIGhvdyBhbnkgb3RoZXIg aW50ZXJwcmV0YXRpb24NCm1ha2VzIHNlbnNlLg0KDQpBbHNvIEkgcXVlc3Rpb24gaG93IGl0J3Mg c3VwcG9zZWQgdG8gd29yayBmb3IgYSBncm91cGluZyB0aGF0IA0KaXMgdXNlZCBvbmNlIGluIGEg ZGVwcmVjYXRlZCB0cmVlIGFuZCBhZ2FpbiBpbiBhIG5vdCBkZXByZWNhdGVkIA0KdHJlZS4gIFdo YXQgaWYgdGhlIGdyb3VwaW5nIGlzIGRlZmluZWQgaW4gYW5vdGhlciBSRkM/ICBXb3VsZA0Kd2Ug bmVlZCB0byBjb3B5IHRoZSBncm91cGluZyBpbnRvIHRoZSBjdXJyZW50IG1vZHVsZSBpbiBvcmRl cg0KdG8gc2V0IHN0YXR1cyBkZXByZWNhdGVkIG9uIGFsbCBvZiBpdHMgbm9kZXM/DQoNCg0KS2Vu dCAvLyBjb250cmlidXRvcg0KDQoNCg== From nobody Tue Sep 5 11:00:17 2017 Return-Path: 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 A8ED5132E01 for ; Tue, 5 Sep 2017 11:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dy2Vh0uox98c for ; Tue, 5 Sep 2017 11:00:09 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 439C8132DA2 for ; Tue, 5 Sep 2017 11:00:09 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 1AA99F6A; Tue, 5 Sep 2017 20:00:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id JhpMC_W3oJYV; Tue, 5 Sep 2017 20:00:01 +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 atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 5 Sep 2017 20:00:07 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D02D0200E2; Tue, 5 Sep 2017 20:00:07 +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 vTliGe0294zA; Tue, 5 Sep 2017 20:00:07 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F024C200E0; Tue, 5 Sep 2017 20:00:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4D7504095F0A; Tue, 5 Sep 2017 20:00:06 +0200 (CEST) Date: Tue, 5 Sep 2017 20:00:06 +0200 From: Juergen Schoenwaelder To: Robert Wilton Cc: Ladislav Lhotka , netmod@ietf.org Message-ID: <20170905180006.yecbqqdhxtkvosxk@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Robert Wilton , Ladislav Lhotka , netmod@ietf.org References: <847e5bf9-7b3d-9ff8-9954-970f32a2094c@cisco.com> <20170902073342.xoziwor4tdr5bipw@elstar.local> <20170902112832.ymorfgdthobeio6q@elstar.local> <1e95ba5d-7aa2-e08f-56f9-27aa70822a11@cisco.com> <1504537140.5874.38.camel@nic.cz> <1504629352.7175.40.camel@nic.cz> <8af6041d-7cd5-9608-70b4-7cffc4f884f8@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <8af6041d-7cd5-9608-70b4-7cffc4f884f8@cisco.com> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 18:00:15 -0000 On Tue, Sep 05, 2017 at 06:17:09PM +0100, Robert Wilton wrote: > > > I believe that tools intended for general use should follow the YANG spec > > literally. > > I don't fully agree.  I think that they only need to cover the parts of the > YANG spec for the models that they are using (or might use). If nobody uses > Unicode blocks then it doesn't really matter whether a given tool supports > them or not.  It is always possible to caveat and add support for the > missing bits later.  E.g. if I was writing a bespoke XPATH implementation > for YANG then there is probably quite a lot of the XPATH spec that I would > also leave out as well, and just concentrate on the parts that people > actually use, or are likely to use. > If this is your understanding of standards, why do you want to define a subset of XSD pattern based on the your observation what is used or not used? Simply do not implement what you observe is not used. Why do we need guidelines of constructs not to use so that they are not used? There are multiple contradictions in your posts, one of them was the idea of translating unicode matching to ASCII - which simply does not work. Or the post where you said \d is OK but then later said \d is not OK since it translates to a large number of numeric characters. You really need to sort out what you want, what the problem is you are trying to solve, how you select the subset of XSD pattern etc. Write and I-D. And at the end, people who only do POSIX regular expressions, because they come with the standard C library on POSIX systems or whatever the reason really is, still will either have to continue to cheat by silently interpreting XSD pattern as POSIX pattern or they create a proper new statement to at least properly distinguish different pattern languages. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Sep 5 11:14:49 2017 Return-Path: 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 7BB4C132D86 for ; Tue, 5 Sep 2017 11:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fa9sHLY3x4Nn for ; Tue, 5 Sep 2017 11:14:46 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2427132D61 for ; Tue, 5 Sep 2017 11:14:45 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id B0BC2F14; Tue, 5 Sep 2017 20:14:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id R4OQuY7axasM; Tue, 5 Sep 2017 20:14:38 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 5 Sep 2017 20:14:44 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8FEA0200E2; Tue, 5 Sep 2017 20:14:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JsASWBdwGp0q; Tue, 5 Sep 2017 20:14: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 29A6E200E0; Tue, 5 Sep 2017 20:14:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 165594095F75; Tue, 5 Sep 2017 20:14:44 +0200 (CEST) Date: Tue, 5 Sep 2017 20:14:44 +0200 From: Juergen Schoenwaelder To: Kent Watsen Cc: "netmod@ietf.org" Message-ID: <20170905181444.tdfliar5zk4hixsd@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , "netmod@ietf.org" References: <13F2175A-C913-4173-BE2A-50C668C08FF6@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13F2175A-C913-4173-BE2A-50C668C08FF6@juniper.net> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [netmod] 'status' statement needed on every node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 18:14:47 -0000 On Tue, Sep 05, 2017 at 05:40:23PM +0000, Kent Watsen wrote: > > > With all the deprecating of "-state" trees going on these days, > the 'status' statement is getting lots of use. > > I understand that some feel that the status statement needs to be > placed on every node, since it is not inherited. This sentiment > likely stems from RFC 7950 stating "If no status is specified, > the default is current" and, of course, it not stating that status > is inherited. > > I appreciate that this is just following rules, but it seems > excessive and I don't understand how any other interpretation > makes sense. There is in my view no problem worth to be solved and today's YANG rules are clear. I am a big fan of definitions that can be copied and moved around without changing meaning just because they appear in a different context. I would even prefer to have config true/false not inherited down the schema tree but rather have no config statement default to config true and everything config false needs an explicit statement. Side effect free cut and paste is a feature that is for me worth the price of a few more explicit statements. Even a human reader can skip over these statements very quickly. > Also I question how it's supposed to work for a grouping that > is used once in a deprecated tree and again in a not deprecated > tree. What if the grouping is defined in another RFC? Would > we need to copy the grouping into the current module in order > to set status deprecated on all of its nodes? It would be nice to simply use refine but unfortunately section 7.13.2 of RFC 7950 does not allow to refine the status (which in my view is an oversight but the RFC says what it says). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Sep 5 11:44:35 2017 Return-Path: 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 C06BA132E13 for ; Tue, 5 Sep 2017 11:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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, URIBL_BLOCKED=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 S-i4C45eUXFG for ; Tue, 5 Sep 2017 11:44:32 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 304E8132E07 for ; Tue, 5 Sep 2017 11:44:32 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id q132so12781837lfe.5 for ; Tue, 05 Sep 2017 11:44:32 -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; bh=u9GLvzHWUXBfQMWxEn4dQ280ik/zXVXXFyCCXI9yKck=; b=m+MxU2edyZfYrI51DvYd2WHN9bUkhHR0TvgIFy7z8tebC2Bm0ujlOVbZoENFPaCljy ehUOkaoLxIFc5LlODf5gacpuR50m2Pg9BF0/kU/KveyRHCOqIfsKi5zKWxn2xKIdh5ox 9Ugs+IkcCmzQfqRWiIkk/kX7AGAd8hOC0inbqJ5PKfxBQq/2kJioNm5K+CfP5F72VhVM D5pJhIZNOkH6kQ/RIxG9Nt7HHj8f6qFZGUbm3sssWLv6CAjv7RMzi5On46sYGBs9BH4M xku3YXfiQi+4VYH28lg4TaWiIrSlO14eqCc8cWk2Omi+ZC3i1QlrSgmfvPMwg2fKHLSB cRJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=u9GLvzHWUXBfQMWxEn4dQ280ik/zXVXXFyCCXI9yKck=; b=o3q4h4PZBKxY/t6REj2VcgOFNBWG8sisylMI+Qikn7qXd/5lHm7EoET0Tx558wHM6Z 3Ewc/MR7CMu27fEAiFkrUMpw4ELoLzA+5U59vvJvYnP3ibrVFk9IVMdGE4kZA+RMIGxW vAw5Vk+EsgS0cjYWP5gD3iP19Huzc23fgTxgMXOi2n6/f5g0n2bxpn/9j6EX5MR96lI0 6y7F6nhPD+7DjgRsmbBXEkfp/ylzoTpYjGEsTnPc3Hm1k8uRe2R2WM9hPkYvNi3xa4Rn 1ce/aMzsd23PW3A1sfytjFyP2K23MU9QK29/YFPQ0KbhtbtLmXfxHteylCzD1Z0E1BU6 G31g== X-Gm-Message-State: AHPjjUgyl6FiLP5cglq7BS+0h3kY9jlL7kTVjOSclZbS2/r8h/CLp9eq E7DgW19YER5t/AWYMmVA7i76CXMKhasy X-Google-Smtp-Source: ADKCNb4miprSASOzC4w2i4STKYnjavtwXpGywNsBcsdLi2PThx0IZJ3s7A8OZWJ5rm6gJGenN8vtW/J4vyoWbcsjfW8= X-Received: by 10.46.86.220 with SMTP id k89mr5002lje.65.1504637070439; Tue, 05 Sep 2017 11:44:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.68.216 with HTTP; Tue, 5 Sep 2017 11:44:29 -0700 (PDT) In-Reply-To: <20170905181444.tdfliar5zk4hixsd@elstar.local> References: <13F2175A-C913-4173-BE2A-50C668C08FF6@juniper.net> <20170905181444.tdfliar5zk4hixsd@elstar.local> From: Andy Bierman Date: Tue, 5 Sep 2017 11:44:29 -0700 Message-ID: To: Juergen Schoenwaelder , Kent Watsen , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1a1914198d8c0558759e23" Archived-At: Subject: Re: [netmod] 'status' statement needed on every node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 18:44:35 -0000 --94eb2c1a1914198d8c0558759e23 Content-Type: text/plain; charset="UTF-8" On Tue, Sep 5, 2017 at 11:14 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Sep 05, 2017 at 05:40:23PM +0000, Kent Watsen wrote: > > > > > > With all the deprecating of "-state" trees going on these days, > > the 'status' statement is getting lots of use. > > > > I understand that some feel that the status statement needs to be > > placed on every node, since it is not inherited. This sentiment > > likely stems from RFC 7950 stating "If no status is specified, > > the default is current" and, of course, it not stating that status > > is inherited. > > > > I appreciate that this is just following rules, but it seems > > excessive and I don't understand how any other interpretation > > makes sense. > > There is in my view no problem worth to be solved and today's YANG > rules are clear. > > > I am a big fan of definitions that can be copied and moved around > without changing meaning just because they appear in a different > context. I would even prefer to have config true/false not inherited > down the schema tree but rather have no config statement default to > config true and everything config false needs an explicit > statement. Side effect free cut and paste is a feature that is for > me worth the price of a few more explicit statements. Even a human > reader can skip over these statements very quickly. > > > Blind cut-and-paste is not a good design goal. I still don't know what it means to define hierarchical data and say the parent is deprecated but not the descendant nodes. This is rather non-intuitive, as is the idea that all descendant nodes need to be manually edited (status is not inherited). It also means the objects expanded from groupings cannot ever be changed (clearly a bug in YANG). We have not seen these issues yet because this is the first time 'status deprecated' is being used. > > Also I question how it's supposed to work for a grouping that > > is used once in a deprecated tree and again in a not deprecated > > tree. What if the grouping is defined in another RFC? Would > > we need to copy the grouping into the current module in order > > to set status deprecated on all of its nodes? > > It would be nice to simply use refine but unfortunately section 7.13.2 > of RFC 7950 does not allow to refine the status (which in my view is > an oversight but the RFC says what it says). > > /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --94eb2c1a1914198d8c0558759e23 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Sep 5, 2017 at 11:14 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Sep 05, 2017 at 05:40:23PM +0000, Kent Watse= n wrote:
>
>
> With all the deprecating of "-state" trees going on these da= ys,
> the 'status' statement is getting lots of use.
>
> I understand that some feel that the status statement needs to be
> placed on every node, since it is not inherited.=C2=A0 This sentiment<= br> > likely stems from RFC 7950 stating "If no status is specified, > the default is current" and, of course, it not stating that statu= s
> is inherited.
>
> I appreciate that this is just following rules, but it seems
> excessive and I don't understand how any other interpretation
> makes sense.

There is in my view no problem worth to be solved and today's YANG
rules are clear.

<outing>
=C2=A0 I am a big fan of definitions that can be copied and moved around =C2=A0 without changing meaning just because they appear in a different
=C2=A0 context. I would even prefer to have config true/false not inherited=
=C2=A0 down the schema tree but rather have no config statement default to<= br> =C2=A0 config true and everything config false needs an explicit
=C2=A0 statement. Side effect free cut and paste is a feature that is for =C2=A0 me worth the price of a few more explicit statements. Even a human =C2=A0 reader can skip over these statements very quickly.
</outing>



Blind cut-and-paste is = not a good design goal.

I still don't know wha= t it means to define hierarchical data and say the
parent is depr= ecated but not the descendant nodes.

This is rathe= r non-intuitive, as is the idea that all descendant nodes need to
be manually edited (status is not inherited).=C2=A0 It also means the obje= cts expanded from
groupings cannot ever be changed (clearly a bug= in YANG).

We have not seen these issues yet becau= se this is the first time 'status deprecated'
is being us= ed.

=C2=A0
> Also I question how it's supposed to work for a grouping that
> is used once in a deprecated tree and again in a not deprecated
> tree.=C2=A0 What if the grouping is defined in another RFC?=C2=A0 Woul= d
> we need to copy the grouping into the current module in order
> to set status deprecated on all of its nodes?

It would be nice to simply use refine but unfortunately section 7.13.2
of RFC 7950 does not allow to refine the status (which in my view is
an oversight but the RFC says what it says).

/js


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

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

--94eb2c1a1914198d8c0558759e23-- From nobody Tue Sep 5 12:01:57 2017 Return-Path: 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 AB20E132E13 for ; Tue, 5 Sep 2017 12:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVMviHA1jNuz for ; Tue, 5 Sep 2017 12:01:54 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C23651201F8 for ; Tue, 5 Sep 2017 12:01:53 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 9AE4EF4B; Tue, 5 Sep 2017 21:01:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id ZtIYcEmCn3fA; Tue, 5 Sep 2017 21:01:45 +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 atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 5 Sep 2017 21:01:52 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 78755200E2; Tue, 5 Sep 2017 21:01:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id I34plCZEUOqI; Tue, 5 Sep 2017 21:01:52 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1D273200E0; Tue, 5 Sep 2017 21:01:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C5A0D409626D; Tue, 5 Sep 2017 21:01:51 +0200 (CEST) Date: Tue, 5 Sep 2017 21:01:51 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: Kent Watsen , "netmod@ietf.org" Message-ID: <20170905190151.fizr5dljufbyuyty@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Andy Bierman , Kent Watsen , "netmod@ietf.org" References: <13F2175A-C913-4173-BE2A-50C668C08FF6@juniper.net> <20170905181444.tdfliar5zk4hixsd@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [netmod] 'status' statement needed on every node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 19:01:56 -0000 On Tue, Sep 05, 2017 at 11:44:29AM -0700, Andy Bierman wrote: > > Blind cut-and-paste is not a good design goal. > Definitions that stand on their own since they are not context sensitive is IMHO a plus. If I am n pages down a YANG tree and I want to know whether I look at config false or config true leaves, searching backwards is really painful if you read on paper (oh, how old school I am - perhaps this is the issue). Copying a definition into an email and it stands on its own is a feature I appreciate. Of course, I understand that others have different preferences. > I still don't know what it means to define hierarchical data and say the > parent is deprecated but not the descendant nodes. It is odd but can happen anyway. A current augmentation of something that got deprecated likely stays current. I would hope that tools warn if they see this but that's it. > This is rather non-intuitive, as is the idea that all descendant > nodes need to be manually edited (status is not inherited). Not a big deal. The benefit is that a reader like me knows clear that the definition I am look at is deprecated, no need to search backwards to find out. > It also means the objects expanded from groupings cannot ever be > changed (clearly a bug in YANG). Yes, bug in YANG. > We have not seen these issues yet because this is the first time > 'status deprecated' is being used. Yes. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Sep 5 13:51:55 2017 Return-Path: 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 1EEAB132E2A for ; Tue, 5 Sep 2017 13:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 7SKFGrVzNLkN for ; Tue, 5 Sep 2017 13:51:51 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35945126B6E for ; Tue, 5 Sep 2017 13:51:51 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id m199so13512886lfe.3 for ; Tue, 05 Sep 2017 13:51: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; bh=022MKwgdqOaWuBTdFKDm+Wc8WW8IB4SIcfsBQpRPfPQ=; b=Ibbw4FY6BnYknGJOyi1ai2v5EQXzFzmnZH5fJGaREXV2z4HLA+b31DEqXmVqk5151t WBrxbRII+tL/l/A3yNS4Na4bBf1h6xjMhdU+z6T55OLsdgfwvCG4YyjMaSpp8tr03Kip s7xVXnNbfbCf0T5fLDS2Cn8zWLOX0rMDu0lPdeoRsHdsYEHWttj6NBfMKHevcZDJkAj6 QzXp2kHjwKrHfR91wq1zJkea2Z5r5ggXITEujZLe/GJyWWkHMpFoAQs9Waq3P126Qa2L cVuzIbu1KPT9p6qo1+1Ld7vewvizSBlb5tiUruaDh9lardjgCdEkCUbfCZxGkkMUABPg mftw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=022MKwgdqOaWuBTdFKDm+Wc8WW8IB4SIcfsBQpRPfPQ=; b=rlLeU+ajiQ2/CyoKMwBKlkYE85QspVMhY7mmeifmEbW2BwXhfg3swYMhiIGqh1hHiv UtzJFz/9HzvHYutfvIYLLlR7yBd2dw/xrnKNZGMAZX7VK0gut5o1dCLyOoXvpDxDiiAM /6dWWDfx0IGpTtYiqTXUklAmTsFe13+oFDl7gxjXuq/b5Skt1BxyspK+VkncCJ6drWo+ S3HGD6+mLv3Zo0vd5fJ4KzAu+RCDL20XeRW4lXwL9LQQjlP9wfsEcyuDoSejd1azKqpT g5CekgQ3ofsAgeAhZvDjtdk166sjQBP66e3i1cCuScNJHXY6hoxli2Ml+giPBnVkTPiZ xwcw== X-Gm-Message-State: AHPjjUg68RQP/f9VuLqHQ7PIgorpCEKr/zCkeYnTd6S6NekLaFwXbZn1 QE+0tWm8aZSFQuPZpovG6imu48Ac/Zno X-Google-Smtp-Source: ADKCNb4PLEDqod+i+sIXDj1wm/N63K+BESBq820uIzQ5Aq4QQP+3TjYviHXifV/xhHurtmgYijabcugoE2dL0RQI0bI= X-Received: by 10.25.31.143 with SMTP id f137mr106477lff.66.1504644709424; Tue, 05 Sep 2017 13:51:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.68.216 with HTTP; Tue, 5 Sep 2017 13:51:48 -0700 (PDT) In-Reply-To: <20170905190151.fizr5dljufbyuyty@elstar.local> References: <13F2175A-C913-4173-BE2A-50C668C08FF6@juniper.net> <20170905181444.tdfliar5zk4hixsd@elstar.local> <20170905190151.fizr5dljufbyuyty@elstar.local> From: Andy Bierman Date: Tue, 5 Sep 2017 13:51:48 -0700 Message-ID: To: Juergen Schoenwaelder , Andy Bierman , Kent Watsen , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="001a114017d06b39a1055877653d" Archived-At: Subject: Re: [netmod] 'status' statement needed on every node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 20:51:53 -0000 --001a114017d06b39a1055877653d Content-Type: text/plain; charset="UTF-8" On Tue, Sep 5, 2017 at 12:01 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Sep 05, 2017 at 11:44:29AM -0700, Andy Bierman wrote: > > > > Blind cut-and-paste is not a good design goal. > > > > Definitions that stand on their own since they are not context > sensitive is IMHO a plus. If I am n pages down a YANG tree and I want > to know whether I look at config false or config true leaves, > searching backwards is really painful if you read on paper (oh, how > old school I am - perhaps this is the issue). Copying a definition > into an email and it stands on its own is a feature I appreciate. Of > course, I understand that others have different preferences. > > > I still don't know what it means to define hierarchical data and say the > > parent is deprecated but not the descendant nodes. > > It is odd but can happen anyway. A current augmentation of something > that got deprecated likely stays current. I would hope that tools warn > if they see this but that's it. > OK > > > This is rather non-intuitive, as is the idea that all descendant > > nodes need to be manually edited (status is not inherited). > > Not a big deal. The benefit is that a reader like me knows clear that > the definition I am look at is deprecated, no need to search backwards > to find out. > OK -- this does not happen too often so it is not a huge impact of writers. > > > It also means the objects expanded from groupings cannot ever be > > changed (clearly a bug in YANG). > > Yes, bug in YANG. > With no way to fix it in RFC 7950 > > > We have not seen these issues yet because this is the first time > > 'status deprecated' is being used. > > Yes. > > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a114017d06b39a1055877653d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Sep 5, 2017 at 12:01 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Sep 05, 2017 at 11:44:29AM -0700, Andy Bierm= an wrote:
>
> Blind cut-and-paste is not a good design goal.
>

Definitions that stand on their own since they are not context
sensitive is IMHO a plus. If I am n pages down a YANG tree and I want
to know whether I look at config false or config true leaves,
searching backwards is really painful if you read on paper (oh, how
old school I am - perhaps this is the issue). Copying a definition
into an email and it stands on its own is a feature I appreciate. Of
course, I understand that others have different preferences.

> I still don't know what it means to define hierarchical data and s= ay the
> parent is deprecated but not the descendant nodes.

It is odd but can happen anyway. A current augmentation of something
that got deprecated likely stays current. I would hope that tools warn
if they see this but that's it.

OK<= /div>
=C2=A0

> This is rather non-intuitive, as is the idea that all descendant
> nodes need to be manually edited (status is not inherited).

Not a big deal. The benefit is that a reader like me knows clear that
the definition I am look at is deprecated, no need to search backwards
to find out.

OK -- this does not happen= too often so it is not a huge impact of writers.

= =C2=A0

> It also means the objects expanded from groupings cannot ever be
> changed (clearly a bug in YANG).

Yes, bug in YANG.


With n= o way to fix it in RFC 7950
=C2=A0

> We have not seen these issues yet because this is the first time
> 'status deprecated' is being used.

Yes.

/js


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

--001a114017d06b39a1055877653d-- From nobody Tue Sep 5 14:37:27 2017 Return-Path: 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 DFDB61243F6 for ; Tue, 5 Sep 2017 14:37:25 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlfFieIhc0ma for ; Tue, 5 Sep 2017 14:37:24 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (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 4646E12422F for ; Tue, 5 Sep 2017 14:37:24 -0700 (PDT) Received: from cmgw3 (unknown [10.0.90.84]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id 0CD56175DE1 for ; Tue, 5 Sep 2017 15:37:23 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id 5xdK1w00X2SSUrH01xdNE0; Tue, 05 Sep 2017 15:37:23 -0600 X-Authority-Analysis: v=2.2 cv=F98nTupN c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=2JCJgTwv5E4A:10 a=jSkAN_dlk0_1SahIaKkA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: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=91P3iDPv1jTqGNnDg9Lhw3NjLs97fLXd1f+3n2Kqhxw=; b=hsVw9rpyLCvd7jjHPw6mabHGYI VRUVy5l5iOu+KB3NHnRVUM3WSCPY6kNeOOr7TPkw3gNAY8OgmJ7PG3OwUdSCJJ/mFSiIS9J8w4a1Q 2XO4cp8KIdyBQDhIlCqXz8oBF; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:58250 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dpLX5-000O1e-AA; Tue, 05 Sep 2017 15:37:19 -0600 To: Robert Wilton , Ladislav Lhotka , netmod@ietf.org References: <20170830102902.2n5q6rgq2x2dxfq2@elstar.local> <20170830123156.cssrg5kklpo67fie@elstar.local> <1504223854014.55228@Aviatnet.com> <847e5bf9-7b3d-9ff8-9954-970f32a2094c@cisco.com> <20170902073342.xoziwor4tdr5bipw@elstar.local> <20170902112832.ymorfgdthobeio6q@elstar.local> <1e95ba5d-7aa2-e08f-56f9-27aa70822a11@cisco.com> <1504537140.5874.38.camel@nic.cz> <1504629352.7175.40.camel@nic.cz> <8af6041d-7cd5-9608-70b4-7cffc4f884f8@cisco.com> From: Lou Berger Message-ID: <2a70ce5e-7727-d280-98e4-481d87314d14@labn.net> Date: Tue, 5 Sep 2017 17:37:18 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <8af6041d-7cd5-9608-70b4-7cffc4f884f8@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.84.20 X-Exim-ID: 1dpLX5-000O1e-AA X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:58250 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 21:37:26 -0000 Rob, (as chair) On 9/5/2017 1:17 PM, Robert Wilton wrote: > However, I have thrown in the towel on my regex crusade. I'm sorry, I've lost the thread here a bit. in order to guage consensus on this topic, it would be helpful to send the latest text that you are proposing for inclusion in the the bis.  If you are willing to do these, we can poll to see if there is/is not support for inclusion of this text.  Are you willing, i.e., can you send the current proposed text change? Thank you, Lou From nobody Tue Sep 5 15:50:07 2017 Return-Path: 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 47B02132E37 for ; Tue, 5 Sep 2017 15:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 eNYkfxOWkgye for ; Tue, 5 Sep 2017 15:50:04 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0133.outbound.protection.outlook.com [104.47.36.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F2541320D9 for ; Tue, 5 Sep 2017 15:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Hb97lrN5OrLzjDdakD/gZ6fTHQQv4EGRH4U8NFtqtlo=; b=ZkBDDL6dkS0CrGIklhr8sjKyLeiQk6+QQLZhDjkL6lUmXh25ztT3pnXFDv8SPEna5pjDVYAvF70Oreki5tAew+vrjJW0saing+W30VGlHgPashLs/5j1JHGaLbh3ryvZCzGS8se3raiBq29va1bBm7BGbzrFZ9tyKWje504ctqI= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1411.namprd05.prod.outlook.com (10.160.117.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.3; Tue, 5 Sep 2017 22:50:03 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.20.0035.010; Tue, 5 Sep 2017 22:50:03 +0000 From: Kent Watsen To: Juergen Schoenwaelder , Andy Bierman CC: "netmod@ietf.org" Thread-Topic: [netmod] 'status' statement needed on every node Thread-Index: AQHTJm4NQwnHS69prEmUfJVnsti896KmmNYAgAAIUICAAATagP///LMA Date: Tue, 5 Sep 2017 22:50:03 +0000 Message-ID: References: <13F2175A-C913-4173-BE2A-50C668C08FF6@juniper.net> <20170905181444.tdfliar5zk4hixsd@elstar.local> <20170905190151.fizr5dljufbyuyty@elstar.local> In-Reply-To: <20170905190151.fizr5dljufbyuyty@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1411; 6:jy5Pq3A3iNObXp48GO8jXSgWR7lrBAizbI0FFbLyk2HyKUCn3hcA2qMm/yo/wNgCuMHWSFw0p4UzX63/2Sdl80PC1WNWIDOqyrZIApJFxYB3Zzq510VbkQKWzh8xfnl/zQH5Hg4SKPMv12nQIgMpwDaUDhP5ZfVTOwa+DFcCm5NeAEc7GpK02EaxXxqMMgOtnnL56v315UwY5GhsLaQeYXCJ7nrG2bKR/rLBGdEoDK70624c+gYmpHUf+g+y6Zu2egiMw5XQyYvvJLiFY2fWZ6Kuxm8ounyZgrmU0ue6clrhFTPOEEWrEKjs/FWls+GaMKbIvv5a/iIZv9Ifg80z6A==; 5:GOjwsePG7AlQEQl7A/VYliuv7+O4pnE1971Sg38Zc93H9S0ZXcvUqx17exuIWLtPKC3BTo81NJoTNNdzQRjNBHe2pqtbtwhdCIexA94TG4timvJJcXh2ir3Ab5C2Ng2FYc9XMyBVFCaCeLof3gbKqQ==; 24:0kbl2oXZ89VWaa4UN1U5X+KBOcdloxIpmWMwNUo2ymH/XGe6BSdyKn6izaqVQwufTWr67X4RNkWfrjyZTe6lkp+Z0SbYfgJA/fCm7ZN6HQ0=; 7:qDy8ARTQ/qqH6/Hye+OCoq0A/RSS2z0Hc2EHVpN/7VyWbwMppkpEybrKeg0rMdb+NQ9frwQuoiAs4ues70Trpd6mfVBOAx94k7DE77J7Arr1JyB0SbVd2z8dM4iIaT+hbGHCQ4rYvL9HJVAA3IdWCbcd0zfk/xspY/BCeOOEYiZnIPhYszMoaWQcbhkGraRvtASFVUBoQ1UoQv1LXNxUk5f9rluK3i/eh5fmWwUb1DU= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 5b2581ad-5cee-486b-8983-08d4f4b07213 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1411; x-ms-traffictypediagnostic: BN3PR0501MB1411: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1411; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1411; x-forefront-prvs: 0421BF7135 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(199003)(189002)(4326008)(229853002)(54356999)(76176999)(50986999)(3280700002)(36756003)(101416001)(6512007)(25786009)(7736002)(82746002)(3660700001)(305945005)(33656002)(2900100001)(5660300001)(2950100002)(14454004)(99286003)(102836003)(106356001)(53936002)(478600001)(105586002)(8676002)(6506006)(4001350100001)(97736004)(83506001)(81156014)(81166006)(2906002)(3846002)(6436002)(83716003)(66066001)(8936002)(93886005)(77096006)(6246003)(6486002)(68736007)(6116002)(86362001)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1411; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <24792E11A18802428DBE344F14D490B7@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Sep 2017 22:50:03.0762 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1411 Archived-At: Subject: Re: [netmod] 'status' statement needed on every node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 22:50:06 -0000 DQoNCg0KPj4gSSBzdGlsbCBkb24ndCBrbm93IHdoYXQgaXQgbWVhbnMgdG8gZGVmaW5lIGhpZXJh cmNoaWNhbCBkYXRhIGFuZCBzYXkgdGhlDQo+PiBwYXJlbnQgaXMgZGVwcmVjYXRlZCBidXQgbm90 IHRoZSBkZXNjZW5kYW50IG5vZGVzLg0KPg0KPiBJdCBpcyBvZGQgYnV0IGNhbiBoYXBwZW4gYW55 d2F5LiBBIGN1cnJlbnQgYXVnbWVudGF0aW9uIG9mIHNvbWV0aGluZw0KPiB0aGF0IGdvdCBkZXBy ZWNhdGVkIGxpa2VseSBzdGF5cyBjdXJyZW50LiBJIHdvdWxkIGhvcGUgdGhhdCB0b29scyB3YXJu DQo+IGlmIHRoZXkgc2VlIHRoaXMgYnV0IHRoYXQncyBpdC4NCg0KVGhpcyBleGFtcGxlIHNlZW1z IHRvIHByb3ZpZGUgc3VwcG9ydCBmb3Igc2F5aW5nIHN0YXR1cyBzaG91bGQgYmUNCmluaGVyaXRl ZC4gIEJ1dCwgdG8gYmUgY2xlYXIsIHlvdSBhZ3JlZSB0aGF0IGlmIGEgcGFyZW50IGlzIGRlcHJl Y2F0ZWQsDQp0aGFuIGl0cyBkZWNlZGVudHMgc2hvdWxkIGJlIGRlcHJlY2F0ZWQgYXMgd2VsbCwg cmlnaHQ/IA0KDQoNCg0KPj4gVGhpcyBpcyByYXRoZXIgbm9uLWludHVpdGl2ZSwgYXMgaXMgdGhl IGlkZWEgdGhhdCBhbGwgZGVzY2VuZGFudA0KPj4gbm9kZXMgbmVlZCB0byBiZSBtYW51YWxseSBl ZGl0ZWQgKHN0YXR1cyBpcyBub3QgaW5oZXJpdGVkKS4NCj4NCj4gTm90IGEgYmlnIGRlYWwuIFRo ZSBiZW5lZml0IGlzIHRoYXQgYSByZWFkZXIgbGlrZSBtZSBrbm93cyBjbGVhciB0aGF0DQo+IHRo ZSBkZWZpbml0aW9uIEkgYW0gbG9vayBhdCBpcyBkZXByZWNhdGVkLCBubyBuZWVkIHRvIHNlYXJj aCBiYWNrd2FyZHMNCj4gdG8gZmluZCBvdXQuDQoNCnRyZWUgZGlhZ3JhbXMgZG8gdGhpcyB0b28s IHRob3VnaCBJIGxpa2UgTWFydGluJ3MgYXBwcm9hY2ggb2YgcmVtb3ZpbmcNCnRoZSBkZXByZWNh dGVkIC1zdGF0ZSB0cmVlcyBmcm9tIHRoZSB0cmVlIGRpYWdyYW0gYWx0b2dldGhlci4NCg0KDQoN Cj4+IEl0IGFsc28gbWVhbnMgdGhlIG9iamVjdHMgZXhwYW5kZWQgZnJvbSBncm91cGluZ3MgY2Fu bm90IGV2ZXIgYmUNCj4+IGNoYW5nZWQgKGNsZWFybHkgYSBidWcgaW4gWUFORykuDQo+DQo+IFll cywgYnVnIGluIFlBTkcuDQoNCklzIHRoaXMgdGhlIHNhbWUgaXNzdWUgSSByYWlzZWQ/DQoNCiAg aW1wb3J0IGlldGYtZm9vIHsNCiAgICBwcmVmaXggZjsNCiAgfQ0KDQogIGNvbnRhaW5lciBiYXIg ew0KICAgIHVzZXMgZjpmb287DQogIH0NCg0KICBjb250YWluZXIgYmF6IHsNCiAgICBzdGF0dXMg ZGVwcmVjYXRlZDsNCiAgICB1c2VzIGY6Zm9vOyAgICAgICAgICAgIDwtLSBvb3BzLCBkZXNjZW5k YW50cyBub3QgZGVwcmVjYXRlZCENCiAgfSAgICAgICAgICAgICAgICAgICAgICAgICAgIChub3Qg YSBwcm9ibGVtIGlmIHN0YXR1cyBpbmhlcml0ZWQpDQoNCg0KSy4NCg0KDQoNCg0K From nobody Tue Sep 5 16:05:34 2017 Return-Path: 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 D6E8A132E37 for ; Tue, 5 Sep 2017 16:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFibt6loZZYk for ; Tue, 5 Sep 2017 16:05:30 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 55E63132195 for ; Tue, 5 Sep 2017 16:05:30 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id j141so16472880ioj.4 for ; Tue, 05 Sep 2017 16:05:30 -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=GQ5KlCW6HztpEY1biCieqnyj7ksLswGa79wqFd9vDmM=; b=s6hDmzwQajK2oRpnpYq8zlswPKgUcWuOeAwwapkYYa6gVTWGzJ+kKGCqCo11ed+n0B KMFTuSg8FvTvrg6ARhAg26bAvbuWPGY72m/Agl0r+mnfG2RGHZBLMcsuXA1SNLCR4cpu J+H+CeH0KILkU5b2BGTKN7u+8nP9cZyn1eglaw2EMM1Z0atFa0N/Jes+BvdCln0z73B6 j185RHSkoIMZvZWjjrQo7lrFySvUaV2x18onJmF3DnKVR0ROTJh/NeL7nc2pqZTWYw+x snc0LnnrrDU1A0+8AEXSy6/Ml9/fDhhL4rq2dliVsSPnq+6VhEMIlPhRfQ8iXGx4dVdg j+Pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GQ5KlCW6HztpEY1biCieqnyj7ksLswGa79wqFd9vDmM=; b=MzJwvTNFOk6fyntSbwwwADsGbDJdaHIkeF8XwB6Rvzg/22xHdPKqNLUHq0xj3l21P6 es9GvDdI/4amc8UCB+5H6Z2xQq87HAcbAGOs4EuIn2eZg+gQMxED6u40CVJ26hT6hdyg s9V10y8gqZ06E8v8w1+KTZGmaq5Cf8UZAJBKJpKGFFuvBhfL6hoWMdtHpKnqTbvZjlIk C6ns1MoOROWrSM6pQsDm/YOEIBlef1LiSt8VfA6jjAeXwJpyADBNBd4SlJ9I+cjAKuv/ 5yVDCMqwDjjTB82+POue7GgAxUd/NSGP/KQExr22ok+VYj+22pac8SxDESewSUCnq876 Dj3g== X-Gm-Message-State: AHPjjUigu9C0Q+ANbAhS56gmYFJOGd1SqeHuZjNW1zjaozEd3eykHW21 g6xb1BnZJU8jZ05PEeT5Xu/YijA86i+R X-Google-Smtp-Source: AOwi7QD6vH6ksHaVWsERHBf1tT3bppyOIwY1adaeMs0h/74IsV7Ocbw0roR1/s6oZLy4T1sabc4BgVltTC3xbTFzSPs= X-Received: by 10.107.190.134 with SMTP id o128mr739573iof.10.1504652729519; Tue, 05 Sep 2017 16:05:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.6.206 with HTTP; Tue, 5 Sep 2017 16:05:28 -0700 (PDT) In-Reply-To: <20170905.095949.1829098658779783521.mbj@tail-f.com> References: <14299503-509D-43BE-A938-0B7B88C3B249@juniper.net> <3620aafe-bc72-cc54-9dbd-b687a0178df2@cisco.com> <20170905.095949.1829098658779783521.mbj@tail-f.com> From: Andy Bierman Date: Tue, 5 Sep 2017 16:05:28 -0700 Message-ID: To: Martin Bjorklund Cc: Benoit Claise , NETCONF Working Group , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="001a114f364474416f055879438e" Archived-At: Subject: Re: [netmod] upcoming adoptions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 23:05:33 -0000 --001a114f364474416f055879438e Content-Type: text/plain; charset="UTF-8" On Tue, Sep 5, 2017 at 12:59 AM, Martin Bjorklund wrote: > Benoit Claise wrote: > > Kent, > > > Hey folks, > > > > > > As discussed at the last meeting, we are heading to revising existing > > > RFCs to align them with NMDA. The first batch have been published as > > > individual drafts: > > > > > > 1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00 > > > 2. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00 > > > 3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00 > > Good. And there is one more in for NETMOD, as discussed in > > https://datatracker.ietf.org/meeting/99/materials/slides- > 99-netmod-sessa-nmda-qa: > > RFC 7317 > > In NETCONF, we have also: > > RFC 6022, no I-D submitted yet > > I don't think this one requires an update at this time. *If* it is > changed, it might be worthwhile to remove definitions already covered > by yang-library, and probably align with the netconf server model. > > > RFC 7895, already adopted > > RFC 8040, no I-D submitted yet. No immediate plan to update? > > We have draft-ietf-netconf-nmda-restconf-00 which "Updates: 8040". > > This draft does not address ietf-restconf-monitoring. YANG tree diagram for the "ietf-restconf-monitoring" module: +--ro restconf-state +--ro capabilities | +--ro capability* inet:uri +--ro streams +--ro stream* [name] +--ro name string +--ro description? string +--ro replay-support? boolean +--ro replay-log-creation-time? yang:date-and-time +--ro access* [encoding] +--ro encoding string +--ro location inet:uri I guess the NMDA transition plan to move the child nodes to a config=true node name /restconf that has only config=false nodes in it. This seems quite disruptive and not a productive use of engineering resources, or support and customer re-training. The /netconf-state container is the same, and many more just like it. NEW: +--rw restconf +--ro capabilities | +--ro capability* inet:uri +--ro streams +--ro stream* [name] +--ro name string +--ro description? string +--ro replay-support? boolean +--ro replay-log-creation-time? yang:date-and-time +--ro access* [encoding] +--ro encoding string +--ro location inet:uri (+ old tree, but deprecated) I doubt vendors will prioritize this high-impact/low-value upgrade, so the deprecated foo-state trees will be needed for many years. > /martin > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a114f364474416f055879438e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Sep 5, 2017 at 12:59 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Benoit = Claise <bclaise@cisco.com> w= rote:
> Kent,
> > Hey folks,
> >
> > As discussed at the last meeting, we are heading to revising exis= ting
> > RFCs to align them with NMDA.=C2=A0 The first batch have been pub= lished as
> > individual drafts:
> >
> > 1. https://tools.ietf.org/= html/draft-bjorklund-netmod-rfc7223bis-00
> > 2. https://tools.ietf.org/= html/draft-bjorklund-netmod-rfc7277bis-00
> > 3. https://tools.ietf.org/html/= draft-acee-netmod-rfc8022bis-00
> Good. And there is one more in for NETMOD, as discussed in
> https://datatra= cker.ietf.org/meeting/99/materials/slides-99-netmod-sessa-nmda-qa= :
> RFC 7317
> In NETCONF, we have also:
> =C2=A0=C2=A0=C2=A0 RFC 6022, no I-D submitted yet

I don't think this one requires an update at this time.=C2=A0 *If* it i= s
changed, it might be worthwhile to remove definitions already covered
by yang-library, and probably align with the netconf server model.

> =C2=A0=C2=A0=C2=A0 RFC 7895, already adopted
> =C2=A0=C2=A0=C2=A0 RFC 8040, no I-D submitted yet. No immediate plan t= o update?

We have draft-ietf-netconf-nmda-restconf-00 which "Updates: 8040&= quot;.



This draft does not add= ress ietf-restconf-monitoring.

   YANG tree diagram for =
the "ietf-restconf-monitoring" module:

      +--ro restconf-state
         +--ro capabilities
         |  +--ro capability*   inet:uri
         +--ro streams
            +--ro stream* [name]
               +--ro name                        string
               +--ro description?                string
               +--ro replay-support?             boolean
               +--ro replay-log-creation-time?   yang:date-and-time
               +--ro access* [encoding]
                  +--ro encoding  string
                  +--ro location  inet:uri
I guess the NMDA transition plan to move the child nodes to a config= =3Dtrue node
name /restconf that has only config=3Dfalse nodes in it.=C2= =A0 This seems quite disruptive
and not a p= roductive use of engineering resources, or support and customer re-training= .
The = /netconf-state container is the same, and many more just like it.

NE= W:

     +--rw restconf
         +--ro capabilities
         |  +--ro capability*   inet:uri
         +--ro streams
            +--ro stream* [name]
               +--ro name                        string
               +--ro description?                string
               +--ro replay-support?             boolean
               +--ro replay-log-creation-time?   yang:date-and-time
               +--ro access* [encoding]
                  +--ro encoding  string
                  +--ro location  inet:uri
    (+ old tree, but deprecat=
ed)
I doubt vendors will prioritize this high-impact/low-value = upgrade, so
the deprecated foo-state trees will be needed for many years= .


/martin

Andy
=C2=A0

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

--001a114f364474416f055879438e-- From nobody Tue Sep 5 16:36:15 2017 Return-Path: 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 913B81320DC for ; Tue, 5 Sep 2017 16:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 C8HoGZpMo0DQ for ; Tue, 5 Sep 2017 16:36:11 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C486012426E for ; Tue, 5 Sep 2017 16:36:11 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id k189so5921615itk.0 for ; Tue, 05 Sep 2017 16:36:11 -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=ktbHDndeKXvIaN5rG8G90g5ljEdbcgxNRb0vphZ7vps=; b=pGvi0Dvw8vujDpF2AEs1xorGRiUspKRzOwEkhNRVoL0X84gvyEg6CejgrfhOysl+s8 f2ykHKrVuhlTH3SA0dt/V8nXs6opNVZiE85tBWQTJLcBC3+YXUvIzH6SZg0cVmEQrABa izLVkZq+9I4UcKGgtppG73SJ+ftmTrOENZNt7v/S+4vMeJZdykrQALcSlaPx08t1d+/H nabnB5lYqzZ5Hp57Qe5YQQhUBC3NDAOD+jHCv/2HLovozr7OfFKfYkV9Zu8+W0yKfgnV JKTNdWKWdXAcItAOjY7gY/fKvrcTyJRX72Y3h2YUh7uYItK/HTCz+xjrhqe0ErsygpvA gOGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ktbHDndeKXvIaN5rG8G90g5ljEdbcgxNRb0vphZ7vps=; b=s+6o+aM5ETmtmYvpxCaUtSR411eajUziMVX625B83aJA58zpb6DMUQwewDuyf0dL+L xwj45XObMZyB6sA9f2vXouhLFbeGYnlJlOLXG194RZFH00IglHvXX4qIXwIL3QcFYE4Y ruEii3AbfIB+pTGygWuFMJEXucHed+exk5K/ZesT5gJzbt7qRSbMhmWASlQ2gj3z6YoJ lOOYHU9LS0Vgpq0OLm3iC3aU0iW2vYRIDSGPOmLyQNqlDWKZgUx6iRyrRwbCsa0PvNEX CHmjqjTHjZfIXuHcSvfhdhdINBwrx3V7g+EVAAE1+/pp4vv2fGgTcIOFI9tLfsJLewHm lCQg== X-Gm-Message-State: AHPjjUjHaE/yrF8RSRCbZ1EgAdQ0Yj2nK2Nln7HyHgGXZXtG8wA2Do5K A3xc0BXljUTY5gjWCFf0NA7pczwVs2sM X-Google-Smtp-Source: ADKCNb5Pr4eTsdhl3E9i0crIbu3ZljWRX08K6FnuVu/FJW06unl7PIUCfPmGyjgRl5c1/iC6nvDpS+z+9FwFMDddQL0= X-Received: by 10.36.40.138 with SMTP id h132mr1033129ith.26.1504654571076; Tue, 05 Sep 2017 16:36:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.6.206 with HTTP; Tue, 5 Sep 2017 16:36:10 -0700 (PDT) In-Reply-To: References: <13F2175A-C913-4173-BE2A-50C668C08FF6@juniper.net> <20170905181444.tdfliar5zk4hixsd@elstar.local> <20170905190151.fizr5dljufbyuyty@elstar.local> From: Andy Bierman Date: Tue, 5 Sep 2017 16:36:10 -0700 Message-ID: To: Kent Watsen Cc: Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="001a113f62ec38248b055879b15a" Archived-At: Subject: Re: [netmod] 'status' statement needed on every node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 23:36:13 -0000 --001a113f62ec38248b055879b15a Content-Type: text/plain; charset="UTF-8" On Tue, Sep 5, 2017 at 3:50 PM, Kent Watsen wrote: > > > > >> I still don't know what it means to define hierarchical data and say the > >> parent is deprecated but not the descendant nodes. > > > > It is odd but can happen anyway. A current augmentation of something > > that got deprecated likely stays current. I would hope that tools warn > > if they see this but that's it. > > This example seems to provide support for saying status should be > inherited. But, to be clear, you agree that if a parent is deprecated, > than its decedents should be deprecated as well, right? > > > right -- the RFC says this has to be done manually. A missing status-stmt means status=current. > > >> This is rather non-intuitive, as is the idea that all descendant > >> nodes need to be manually edited (status is not inherited). > > > > Not a big deal. The benefit is that a reader like me knows clear that > > the definition I am look at is deprecated, no need to search backwards > > to find out. > > tree diagrams do this too, though I like Martin's approach of removing > the deprecated -state trees from the tree diagram altogether. > > > > >> It also means the objects expanded from groupings cannot ever be > >> changed (clearly a bug in YANG). > > > > Yes, bug in YANG. > > Is this the same issue I raised? > > import ietf-foo { > prefix f; > } > > container bar { > uses f:foo; > } > > container baz { > status deprecated; > uses f:foo; <-- oops, descendants not deprecated! > } (not a problem if status inherited) > > According to my interpretation of 7.21.2, this is a MUST NOT: If a definition is "current", it MUST NOT reference a "deprecated" or "obsolete" definition within the same module. If a definition is "deprecated", it MUST NOT reference an "obsolete" definition within the same module. For example, the following is illegal: typedef my-type { status deprecated; type int32; } leaf my-leaf { status current; type my-type; // illegal, since my-type is deprecated } The term "reference" is not really defined above. It should also clearly apply to "uses" (e.g., your example) and leafref path-stmt. leaf foo { type string; status deprecated; } leaf bar { type leafref { path /foo; } } If it apples to path-stmt, then why not all XPath? Why doesn't "reference" include descendant nodes? The text in 7950 is too strict and can cause a massive ripple-effect when any status-stmt is changed. At the same time it is too vague to be useful to implementors. > K. > > > > > Andy --001a113f62ec38248b055879b15a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Sep 5, 2017 at 3:50 PM, Kent Watsen <kwatsen@juniper.net= > wrote:


>> I still don't know what it means to define hierarchical data a= nd say the
>> parent is deprecated but not the descendant nodes.
>
> It is odd but can happen anyway. A current augmentation of something > that got deprecated likely stays current. I would hope that tools warn=
> if they see this but that's it.

This example seems to provide support for saying status should be
inherited.=C2=A0 But, to be clear, you agree that if a parent is deprecated= ,
than its decedents should be deprecated as well, right?



right -- the RFC says this has to be d= one manually.
A missing status-stmt means status=3Dcurrent.
=

=C2=A0

>> This is rather non-intuitive, as is the idea that all descendant >> nodes need to be manually edited (status is not inherited).
>
> Not a big deal. The benefit is that a reader like me knows clear that<= br> > the definition I am look at is deprecated, no need to search backwards=
> to find out.

tree diagrams do this too, though I like Martin's approach of removing<= br> the deprecated -state trees from the tree diagram altogether.



>> It also means the objects expanded from groupings cannot ever be >> changed (clearly a bug in YANG).
>
> Yes, bug in YANG.

Is this the same issue I raised?

=C2=A0 import ietf-foo {
=C2=A0 =C2=A0 prefix f;
=C2=A0 }

=C2=A0 container bar {
=C2=A0 =C2=A0 uses f:foo;
=C2=A0 }

=C2=A0 container baz {
=C2=A0 =C2=A0 status deprecated;
=C2=A0 =C2=A0 uses f:foo;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <-- o= ops, descendants not deprecated!
=C2=A0 }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(not a problem if status inherited)


According to my interpretation of 7.21.2, this= is a MUST NOT:

   If a definition is "current=
", it MUST NOT reference a "deprecated" or
   "obsolete" definition within the same module.   
   If a definiti=
on is "deprecated", it MUST NOT reference an "obsolete"
   definition within the same module.

   For example, the following is illegal:

     typedef my-type {
       status deprecated;
       type int32;
     }

     leaf my-leaf {
       status current;
       type my-type; // illegal, since my-type is deprecated
     }
The term "reference" is not really defined above.
It should also clearly apply to "uses" (e.g., your example) and = =C2=A0leafref path-stmt.

=C2=A0 =C2=A0leaf foo {
=C2=A0 =C2=A0 =C2=A0type string;
=C2=A0 =C2=A0 =C2=A0sta= tus deprecated;
=C2=A0 }

=C2=A0 leaf bar= {
=C2=A0 =C2=A0 type leafref { path /foo; }
=C2=A0 }

If it apples to path-stmt, then why not all XPath?<= /div>
Why doesn't "reference" include descendant nodes?

The text in 7950 is too strict and can cause a mass= ive ripple-effect when any status-stmt is changed.
=C2=A0At the s= ame time it is too vague to be useful to implementors.

=

K.





Andy<= /div>

--001a113f62ec38248b055879b15a-- From nobody Tue Sep 5 18:48:01 2017 Return-Path: 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 D34A51321AA for ; Tue, 5 Sep 2017 18:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.715 X-Spam-Level: X-Spam-Status: No, score=-2.715 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, 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 5Lz6ptLnhhxO for ; Tue, 5 Sep 2017 18:47:58 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C82132192 for ; Tue, 5 Sep 2017 18:47:58 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 65AC4864AA; Wed, 6 Sep 2017 01:47:57 +0000 (UTC) Date: Wed, 6 Sep 2017 01:47:57 +0000 From: heasley To: netmod@ietf.org Message-ID: <20170906014757.GD31035@shrubbery.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170905190151.fizr5dljufbyuyty@elstar.local> User-Agent: Mutt/1.8.3 (2017-05-23) Archived-At: Subject: Re: [netmod] 'status' statement needed on every node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 01:48:00 -0000 > On Tue, Sep 05, 2017 at 11:44:29AM -0700, Andy Bierman wrote: > > Blind cut-and-paste is not a good design goal. > > Definitions that stand on their own since they are not context > sensitive is IMHO a plus. If I am n pages down a YANG tree and I want > to know whether I look at config false or config true leaves, > searching backwards is really painful if you read on paper (oh, how Isn't this something that is fixed with display (human representation) tools? > > I still don't know what it means to define hierarchical data and say the > > parent is deprecated but not the descendant nodes. > > It is odd but can happen anyway. A current augmentation of something > that got deprecated likely stays current. I would hope that tools warn > if they see this but that's it. How is anything ever expunged if parsing tools do not refuse to load a module that depends on a deprecated node that it is attempting to augment? From nobody Tue Sep 5 23:43:03 2017 Return-Path: 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 36943132357; Tue, 5 Sep 2017 23:43:02 -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 7fNsSi0nzHes; Tue, 5 Sep 2017 23:43: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 5C85E126E7A; Tue, 5 Sep 2017 23:43:00 -0700 (PDT) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 5471C1AE0187; Wed, 6 Sep 2017 08:42:58 +0200 (CEST) Date: Wed, 06 Sep 2017 08:41:24 +0200 (CEST) Message-Id: <20170906.084124.2282926097915349446.mbj@tail-f.com> To: andy@yumaworks.com Cc: bclaise@cisco.com, netconf-chairs@ietf.org, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <3620aafe-bc72-cc54-9dbd-b687a0178df2@cisco.com> <20170905.095949.1829098658779783521.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: [netmod] upcoming adoptions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 06:43:02 -0000 Andy Bierman wrote: > On Tue, Sep 5, 2017 at 12:59 AM, Martin Bjorklund wrote: > > > Benoit Claise wrote: > > > Kent, > > > > Hey folks, > > > > > > > > As discussed at the last meeting, we are heading to revising existing > > > > RFCs to align them with NMDA. The first batch have been published as > > > > individual drafts: > > > > > > > > 1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00 > > > > 2. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00 > > > > 3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00 > > > Good. And there is one more in for NETMOD, as discussed in > > > https://datatracker.ietf.org/meeting/99/materials/slides- > > 99-netmod-sessa-nmda-qa: > > > RFC 7317 > > > In NETCONF, we have also: > > > RFC 6022, no I-D submitted yet > > > > I don't think this one requires an update at this time. *If* it is > > changed, it might be worthwhile to remove definitions already covered > > by yang-library, and probably align with the netconf server model. > > > > > RFC 7895, already adopted > > > RFC 8040, no I-D submitted yet. No immediate plan to update? > > > > We have draft-ietf-netconf-nmda-restconf-00 which "Updates: 8040". > > > > > > This draft does not address ietf-restconf-monitoring. Correct. See below. > > YANG tree diagram for the "ietf-restconf-monitoring" module: > > +--ro restconf-state > +--ro capabilities > | +--ro capability* inet:uri > +--ro streams > +--ro stream* [name] > +--ro name string > +--ro description? string > +--ro replay-support? boolean > +--ro replay-log-creation-time? yang:date-and-time > +--ro access* [encoding] > +--ro encoding string > +--ro location inet:uri > > > I guess the NMDA transition plan to move the child nodes to a config=true > node > name /restconf that has only config=false nodes in it. This seems quite > disruptive > and not a productive use of engineering resources, or support and customer > re-training. I agree with you. We've said that it is ok to have pure config false trees, if it makes sense for what we're trying to model. The only "issue" with the tree above is that its top-level node's name contains the word "state". But OTOH, maybe we need to revisit this model for the upcoming new notification work anyway. It has a new defintiion of streams, so at least we need to deprecate the /restconf-state/streams contianer. /martin > The /netconf-state container is the same, and many more just like it. > > NEW: > > +--rw restconf > +--ro capabilities > | +--ro capability* inet:uri > +--ro streams > +--ro stream* [name] > +--ro name string > +--ro description? string > +--ro replay-support? boolean > +--ro replay-log-creation-time? yang:date-and-time > +--ro access* [encoding] > +--ro encoding string > +--ro location inet:uri > > (+ old tree, but deprecated) > > I doubt vendors will prioritize this high-impact/low-value upgrade, so > the deprecated foo-state trees will be needed for many years. > > > > /martin > > > > Andy > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > From nobody Tue Sep 5 23:44:47 2017 Return-Path: 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 9610F13235A for ; Tue, 5 Sep 2017 23:44:45 -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 fczqEB4lLiW1 for ; Tue, 5 Sep 2017 23:44:43 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19F73132357 for ; Tue, 5 Sep 2017 23:44:43 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id E80C721; Wed, 6 Sep 2017 08:44:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id G-0cPr9isvTO; Wed, 6 Sep 2017 08:44:41 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 6 Sep 2017 08:44:41 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C859C200E2; Wed, 6 Sep 2017 08:44:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id z6poe2nPKOds; Wed, 6 Sep 2017 08:44:40 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 682E9200E0; Wed, 6 Sep 2017 08:44:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 50FFF4096DD3; Wed, 6 Sep 2017 08:44:40 +0200 (CEST) Date: Wed, 6 Sep 2017 08:44:40 +0200 From: Juergen Schoenwaelder To: Kent Watsen Cc: Andy Bierman , "netmod@ietf.org" Message-ID: <20170906064440.4br5kjna6toeqzlo@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , Andy Bierman , "netmod@ietf.org" References: <13F2175A-C913-4173-BE2A-50C668C08FF6@juniper.net> <20170905181444.tdfliar5zk4hixsd@elstar.local> <20170905190151.fizr5dljufbyuyty@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [netmod] 'status' statement needed on every node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 06:44:46 -0000 On Tue, Sep 05, 2017 at 10:50:03PM +0000, Kent Watsen wrote: > > > > >> I still don't know what it means to define hierarchical data and say the > >> parent is deprecated but not the descendant nodes. > > > > It is odd but can happen anyway. A current augmentation of something > > that got deprecated likely stays current. I would hope that tools warn > > if they see this but that's it. > > This example seems to provide support for saying status should be > inherited. No, I do not support your conclusion. I think it is crucial that whoever maintains an augmenting module is actually aware that his module depends on something deprecated. Silently deprecating (and eventually obsoleting) definitions maintained by other parties is in my view not a good idea. It is far better to clearly indicate that there is some work to do by the augmenting module maintainer. > But, to be clear, you agree that if a parent is deprecated, > than its decedents should be deprecated as well, right? Yes. > >> This is rather non-intuitive, as is the idea that all descendant > >> nodes need to be manually edited (status is not inherited). > > > > Not a big deal. The benefit is that a reader like me knows clear that > > the definition I am look at is deprecated, no need to search backwards > > to find out. > > tree diagrams do this too, though I like Martin's approach of removing > the deprecated -state trees from the tree diagram altogether. > > > > >> It also means the objects expanded from groupings cannot ever be > >> changed (clearly a bug in YANG). > > > > Yes, bug in YANG. > > Is this the same issue I raised? > > import ietf-foo { > prefix f; > } > > container bar { > uses f:foo; > } > > container baz { > status deprecated; > uses f:foo; <-- oops, descendants not deprecated! > } (not a problem if status inherited) I think I look at this very differently. If something is defined in f:foo that is current, then this is inherited where f:foo is used. What we need is a way to refine that if the usage context has differnet requirements, like we allow to refine other properties of a grouping to adapt it to the usage context. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Sep 5 23:53:59 2017 Return-Path: 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 F2D9513235C for ; Tue, 5 Sep 2017 23:53:57 -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 8Uo7aTX4-DQs for ; Tue, 5 Sep 2017 23:53:56 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 88C06126E7A for ; Tue, 5 Sep 2017 23:53:56 -0700 (PDT) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 925A11AE0187; Wed, 6 Sep 2017 08:53:55 +0200 (CEST) Date: Wed, 06 Sep 2017 08:52:22 +0200 (CEST) Message-Id: <20170906.085222.355333494940576314.mbj@tail-f.com> To: andy@yumaworks.com Cc: kwatsen@juniper.net, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20170905190151.fizr5dljufbyuyty@elstar.local> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] 'status' statement needed on every node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 06:53:58 -0000 Andy Bierman wrote: > On Tue, Sep 5, 2017 at 3:50 PM, Kent Watsen wrote: > > > > > > > > > >> I still don't know what it means to define hierarchical data and say the > > >> parent is deprecated but not the descendant nodes. > > > > > > It is odd but can happen anyway. A current augmentation of something > > > that got deprecated likely stays current. I would hope that tools warn > > > if they see this but that's it. > > > > This example seems to provide support for saying status should be > > inherited. But, to be clear, you agree that if a parent is deprecated, > > than its decedents should be deprecated as well, right? > > > > > > > right -- the RFC says this has to be done manually. > A missing status-stmt means status=current. > > > > > > > >> This is rather non-intuitive, as is the idea that all descendant > > >> nodes need to be manually edited (status is not inherited). > > > > > > Not a big deal. The benefit is that a reader like me knows clear that > > > the definition I am look at is deprecated, no need to search backwards > > > to find out. > > > > tree diagrams do this too, though I like Martin's approach of removing > > the deprecated -state trees from the tree diagram altogether. > > > > > > > > >> It also means the objects expanded from groupings cannot ever be > > >> changed (clearly a bug in YANG). > > > > > > Yes, bug in YANG. > > > > Is this the same issue I raised? > > > > import ietf-foo { > > prefix f; > > } > > > > container bar { > > uses f:foo; > > } > > > > container baz { > > status deprecated; > > uses f:foo; <-- oops, descendants not deprecated! > > } (not a problem if status inherited) As Andy explains below, this should be: container baz { status deprecated; uses f:foo { status deprecated; } } > According to my interpretation of 7.21.2, this is a MUST NOT: > > If a definition is "current", it MUST NOT reference a "deprecated" or > "obsolete" definition within the same module. > > If a definition is "deprecated", it MUST NOT reference an "obsolete" > definition within the same module. > > For example, the following is illegal: > > typedef my-type { > status deprecated; > type int32; > } > > leaf my-leaf { > status current; > type my-type; // illegal, since my-type is deprecated > } > > The term "reference" is not really defined above. > It should also clearly apply to "uses" (e.g., your example) and leafref > path-stmt. > > leaf foo { > type string; > status deprecated; > } > > leaf bar { > type leafref { path /foo; } > } > > If it apples to path-stmt, then why not all XPath? B/c in XPath it is even ok to refer to non-existing nodes. And you might have things like /baz/*. > Why doesn't "reference" include descendant nodes? > > The text in 7950 is too strict and can cause a massive ripple-effect when > any status-stmt is changed. > At the same time it is too vague to be useful to implementors. While I agree that it is not clear what it means to have a "current" child to a "deprecated" node, I don't think this is a big issue. If a node is deprecated, it is ok for an implementation to not implement it. Obviously this means that no child nodes to that node is implemented either, regardless of their status, if they are augmented in, or comes from a grouping. /martin From nobody Tue Sep 5 23:55:58 2017 Return-Path: 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 2F66B1321A5 for ; Tue, 5 Sep 2017 23:55:57 -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 c1aOnCnbGzve for ; Tue, 5 Sep 2017 23:55:56 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E71E3126E7A for ; Tue, 5 Sep 2017 23:55:55 -0700 (PDT) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id F22A61AE0187; Wed, 6 Sep 2017 08:55:54 +0200 (CEST) Date: Wed, 06 Sep 2017 08:54:21 +0200 (CEST) Message-Id: <20170906.085421.399708327964847720.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de Cc: kwatsen@juniper.net, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20170906064440.4br5kjna6toeqzlo@elstar.local> References: <20170905190151.fizr5dljufbyuyty@elstar.local> <20170906064440.4br5kjna6toeqzlo@elstar.local> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] 'status' statement needed on every node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 06:55:57 -0000 Juergen Schoenwaelder wrote: > On Tue, Sep 05, 2017 at 10:50:03PM +0000, Kent Watsen wrote: > > > > > > > > >> I still don't know what it means to define hierarchical data and say the > > >> parent is deprecated but not the descendant nodes. > > > > > > It is odd but can happen anyway. A current augmentation of something > > > that got deprecated likely stays current. I would hope that tools warn > > > if they see this but that's it. > > > > This example seems to provide support for saying status should be > > inherited. > > No, I do not support your conclusion. I think it is crucial that > whoever maintains an augmenting module is actually aware that his > module depends on something deprecated. Silently deprecating (and > eventually obsoleting) definitions maintained by other parties is in > my view not a good idea. It is far better to clearly indicate that > there is some work to do by the augmenting module maintainer. > > > But, to be clear, you agree that if a parent is deprecated, > > than its decedents should be deprecated as well, right? > > Yes. > > > >> This is rather non-intuitive, as is the idea that all descendant > > >> nodes need to be manually edited (status is not inherited). > > > > > > Not a big deal. The benefit is that a reader like me knows clear that > > > the definition I am look at is deprecated, no need to search backwards > > > to find out. > > > > tree diagrams do this too, though I like Martin's approach of removing > > the deprecated -state trees from the tree diagram altogether. > > > > > > > > >> It also means the objects expanded from groupings cannot ever be > > >> changed (clearly a bug in YANG). > > > > > > Yes, bug in YANG. > > > > Is this the same issue I raised? > > > > import ietf-foo { > > prefix f; > > } > > > > container bar { > > uses f:foo; > > } > > > > container baz { > > status deprecated; > > uses f:foo; <-- oops, descendants not deprecated! > > } (not a problem if status inherited) > > I think I look at this very differently. If something is defined in > f:foo that is current, then this is inherited where f:foo is > used. What we need is a way to refine that if the usage context has > differnet requirements, like we allow to refine other properties of a > grouping to adapt it to the usage context. I think that marking the uses statement with status deprecated should mean that all nodes in the grouping are "auto-refined" with status deprecated. Listing them all in explciit refine doesn't help anyone imo. /martin From nobody Tue Sep 5 23:57:30 2017 Return-Path: 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 89C15132D66 for ; Tue, 5 Sep 2017 23:57:29 -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 C_IyXe3_ozWq for ; Tue, 5 Sep 2017 23:57:28 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09B2C1321A5 for ; Tue, 5 Sep 2017 23:57:27 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id CE36F21; Wed, 6 Sep 2017 08:57:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id EAwMzgXEmjsA; Wed, 6 Sep 2017 08:57:25 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 6 Sep 2017 08:57:25 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id ADB5A200E2; Wed, 6 Sep 2017 08:57:25 +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 Z_O83dOB1AMz; Wed, 6 Sep 2017 08:57:25 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 27481200E0; Wed, 6 Sep 2017 08:57:25 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id ECEE64096E25; Wed, 6 Sep 2017 08:57:23 +0200 (CEST) Date: Wed, 6 Sep 2017 08:57:23 +0200 From: Juergen Schoenwaelder To: heasley Cc: netmod@ietf.org Message-ID: <20170906065723.dnv4xl2mchszcvlo@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: heasley , netmod@ietf.org References: <20170905190151.fizr5dljufbyuyty@elstar.local> <20170906014757.GD31035@shrubbery.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170906014757.GD31035@shrubbery.net> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [netmod] 'status' statement needed on every node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 06:57:29 -0000 On Wed, Sep 06, 2017 at 01:47:57AM +0000, heasley wrote: > > Isn't this something that is fixed with display (human representation) > tools? > I often work with the original definitions. And if the original definitions depend on context, I have to do another lookup (whether this is inside the original definition or some tool generated human representation does not matter). With the old /foo and /foo-state approach this was really bad since you had often objects with the same name and it was often not at all clear whether I have been looking at the config true or the config false definition without an additional search operation. Perhaps I could program my favourite editor to generate explicit config statements and status statements on the fly but I think we would be better off if readers would not have to program editors or use special tools to easily understand what a definition really means. > > > I still don't know what it means to define hierarchical data and say the > > > parent is deprecated but not the descendant nodes. > > > > It is odd but can happen anyway. A current augmentation of something > > that got deprecated likely stays current. I would hope that tools warn > > if they see this but that's it. > > How is anything ever expunged if parsing tools do not refuse to load > a module that depends on a deprecated node that it is attempting to > augment? Expunged? Deprecating a definition does not expunge anything. Tools that refuse to load a module that depends on deprecated nodes are in my view broken. It was one of YANG's design goals to support augmentations such that definitions and be augmented by independent organizations. Hence, we must face reality that it is impossible to determine how many augmentations of a definition are out there and hence it is impossible to have them all updated at the same time. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Sep 6 00:27:54 2017 Return-Path: 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 E77341321D5 for ; Wed, 6 Sep 2017 00:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] 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 7-z1auz5ir44 for ; Wed, 6 Sep 2017 00:27:51 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 0285C127005 for ; Wed, 6 Sep 2017 00:27:51 -0700 (PDT) Received: from birdie106 (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 2408C60B35; Wed, 6 Sep 2017 09:27:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1504682869; bh=f/qbwXwc1LuIW/e3ARI4vh7uk9U4HH/hlz9T68OHkyU=; h=From:To:Date; b=d1xgyjxXDadDS48Rgi17HYwofuiJl08BYJMrvNCNBGRoMeMU8kwL911MOYKGAzckh z1b/nTMn12uLUOiF9eWyl7cK26JnoCQVN1/J5TjPbPrNzrShDclKTiGiB5hvuYIQDB J1+jkQwfP0U5pa1067Q14kVCY0ruucWsxYEzzCF4= Message-ID: <1504682901.3468.5.camel@nic.cz> From: Ladislav Lhotka To: Juergen Schoenwaelder , Robert Wilton Cc: netmod@ietf.org Date: Wed, 06 Sep 2017 09:28:21 +0200 In-Reply-To: <20170905180006.yecbqqdhxtkvosxk@elstar.local> References: <847e5bf9-7b3d-9ff8-9954-970f32a2094c@cisco.com> <20170902073342.xoziwor4tdr5bipw@elstar.local> <20170902112832.ymorfgdthobeio6q@elstar.local> <1e95ba5d-7aa2-e08f-56f9-27aa70822a11@cisco.com> <1504537140.5874.38.camel@nic.cz> <1504629352.7175.40.camel@nic.cz> <8af6041d-7cd5-9608-70b4-7cffc4f884f8@cisco.com> <20170905180006.yecbqqdhxtkvosxk@elstar.local> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.5 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 07:27:53 -0000 Juergen Schoenwaelder píše v Út 05. 09. 2017 v 20:00 +0200: > On Tue, Sep 05, 2017 at 06:17:09PM +0100, Robert Wilton wrote: > > > > > I believe that tools intended for general use should follow the YANG spec > > > literally. > > > > I don't fully agree. I think that they only need to cover the parts of the > > YANG spec for the models that they are using (or might use). If nobody uses > > Unicode blocks then it doesn't really matter whether a given tool supports > > them or not. It is always possible to caveat and add support for the > > missing bits later. E.g. if I was writing a bespoke XPATH implementation > > for YANG then there is probably quite a lot of the XPATH spec that I would > > also leave out as well, and just concentrate on the parts that people > > actually use, or are likely to use. > > > > If this is your understanding of standards, why do you want to define > a subset of XSD pattern based on the your observation what is used or > not used? Simply do not implement what you observe is not used. Why do > we need guidelines of constructs not to use so that they are not used? Agreed. Also, XPath is different: due to the restrictions imposed on data trees modelled with YANG compared to general XML (no mixed content, no document order) som XPath features don't make sense by definition. This is not the case for Unicode strings. Lada > > There are multiple contradictions in your posts, one of them was the > idea of translating unicode matching to ASCII - which simply does not > work. Or the post where you said \d is OK but then later said \d is > not OK since it translates to a large number of numeric characters. > You really need to sort out what you want, what the problem is you are > trying to solve, how you select the subset of XSD pattern etc. Write > and I-D. And at the end, people who only do POSIX regular expressions, > because they come with the standard C library on POSIX systems or > whatever the reason really is, still will either have to continue to > cheat by silently interpreting XSD pattern as POSIX pattern or they > create a proper new statement to at least properly distinguish > different pattern languages. > > /js > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Sep 6 00:53:04 2017 Return-Path: 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 989881323F7 for ; Wed, 6 Sep 2017 00:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 St4onvlaS7Pv for ; Wed, 6 Sep 2017 00:53:00 -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 C50601323B0 for ; Wed, 6 Sep 2017 00:52:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4344; q=dns/txt; s=iport; t=1504684379; x=1505893979; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=csupYKrRQOToZUI1GVJyJYala7JIXtowy6kCg25qjOQ=; b=QktvGdw5C13Chyl+PtAIchuJfhSdWmSu+nUvP5+/xh0kwtm4zV/jeLdd fXpF6YvJiTzpejBcS2JSfSTqro43tEWnm2LutXQUOyKLCrjS18duaefJp j/IVyK5nk0yOzCgFsIBRYXbGrtMFw0rEPD4umuoJ54UeQ06I+3Zw+10UG U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DbAQBsqK9Z/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBiUqLFZEeljaCBAqFPgKEexQBAgEBAQEBAQFrKIUZAQUjDwEFUQk?= =?us-ascii?q?CDgoCAiYCAlcGAQwIAQGKLZEbnWaCJ4s5AQEBAQEBAQECAQEBAQEBASGBDYIdg?= =?us-ascii?q?1CBYyuCfYRCg0aCYQWgdIs1iRyCE4lBJIZ5jVeHVIE5NiGBAgsyIQgcFYdlP4p?= =?us-ascii?q?fAQEB?= X-IronPort-AV: E=Sophos;i="5.41,483,1498521600"; d="scan'208";a="657272860" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Sep 2017 07:52:55 +0000 Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v867qtOP006588; Wed, 6 Sep 2017 07:52:55 GMT To: Lou Berger , Ladislav Lhotka , netmod@ietf.org References: <20170830102902.2n5q6rgq2x2dxfq2@elstar.local> <20170830123156.cssrg5kklpo67fie@elstar.local> <1504223854014.55228@Aviatnet.com> <847e5bf9-7b3d-9ff8-9954-970f32a2094c@cisco.com> <20170902073342.xoziwor4tdr5bipw@elstar.local> <20170902112832.ymorfgdthobeio6q@elstar.local> <1e95ba5d-7aa2-e08f-56f9-27aa70822a11@cisco.com> <1504537140.5874.38.camel@nic.cz> <1504629352.7175.40.camel@nic.cz> <8af6041d-7cd5-9608-70b4-7cffc4f884f8@cisco.com> <2a70ce5e-7727-d280-98e4-481d87314d14@labn.net> From: Robert Wilton Message-ID: Date: Wed, 6 Sep 2017 08:52:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <2a70ce5e-7727-d280-98e4-481d87314d14@labn.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 07:53:01 -0000 Hi Lou, This is the addition to 6087bis that I propose.   Note, this is the same text in my email on the 31st of August. I propose adding the following 2 paragraphs to 6087bis section on pattern and ranges: NEW: To ensure patterns are easy to read and implement, authors SHOULD restrict themselves to the parts of the XML schema regular expression language that are common across most regular expression languages.  In particular, pattern statements SHOULD avoid using 'character class subtraction' (e.g. '[a-z-[aeiou]]').  They SHOULD avoid matching unicode properties and blocks (e.g. '\p{L} or \p{IsBasic_Latin}'). They MAY use the '\d', '\w', '\s' character class shorthands and their negated versions, where appropriate, but SHOULD avoid other character class shorthands.  To match ASCII digits 0-9 the character class '[0-9]' MUST be used instead of the '\d' character class shorthand that matches Unicode digits in all scripts. Pattern statements do not have to strictly restrict numerical values, and a simple less specific pattern may be preferable over a more complex and precise pattern, e.g. as illustrated in the 'ipv4-address-no-zone' example pattern below. Or, put in context of the existing text 6087bis text: *** Patterns and Ranges For string data types, if a machine-readable pattern can be defined for the desired semantics, then one or more pattern statements SHOULD be present. A single quoted string SHOULD be used to specify the pattern, since a double-quoted string can modify the content. To ensure patterns are easy to read and implement, authors SHOULD restrict themselves to the parts of the XML schema regular expression language that are common across most regular expression languages.  In particular, pattern statements SHOULD avoid using 'character class subtraction' (e.g. '[a-z-[aeiou]]').  They SHOULD avoid matching unicode properties and blocks (e.g. '\p{L} or \p{IsBasic_Latin}'). They MAY use the '\d', '\w', '\s' character class shorthands and their negated versions, where appropriate, but SHOULD avoid other character class shorthands.  To match ASCII digits 0-9 the character class '[0-9]' MUST be used instead of the '\d' character class shorthand that also matches Unicode digits in all scripts. Pattern statements do not have to strictly restrict numerical values, and a simple less specific pattern may be preferable over a more complex and precise pattern, e.g. as illustrated in the 'ipv4-address-no-zone' example pattern below. The following typedef from ^RFC6991^ demonstrates the proper use of the "pattern" statement:     typedef ipv4-address-no-zone {       type inet:ipv4-address {         pattern '[0-9\.]*';       }       ...     } For string data types, if the length of the string is required to be bounded in all implementations, then a length statement MUST be present. The following typedef from ^RFC6991^ demonstrates the proper use of the "length" statement:     typedef yang-identifier {       type string {         length "1..max";         pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*';         pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*';       }       ...     } For numeric data types, if the values allowed by the intended semantics are different than those allowed by the unbounded intrinsic data type (e.g., 'int32'), then a range statement SHOULD be present. The following typedef from ^RFC6991^ demonstrates the proper use of the "range" statement:     typedef dscp {       type uint8 {          range "0..63";       }       ...     } Thanks, Rob On 05/09/2017 22:37, Lou Berger wrote: > Rob, > > (as chair) > On 9/5/2017 1:17 PM, Robert Wilton wrote: >> However, I have thrown in the towel on my regex crusade. > I'm sorry, I've lost the thread here a bit. in order to guage consensus > on this topic, it would be helpful to send the latest text that you are > proposing for inclusion in the the bis.  If you are willing to do these, > we can poll to see if there is/is not support for inclusion of this > text.  Are you willing, i.e., can you send the current proposed text change? > > Thank you, > Lou > > . > From nobody Wed Sep 6 01:02:33 2017 Return-Path: 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 940721323F7 for ; Wed, 6 Sep 2017 01:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3] 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 5U-m4inhx9Ky for ; Wed, 6 Sep 2017 01:02:26 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) (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 8440E1323B0 for ; Wed, 6 Sep 2017 01:02:26 -0700 (PDT) Received: from pckrejci.nat9.vcit.vutbr.net (unknown [IPv6:2001:67c:1220:80c:d0:552c:73a5:18da]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id B20B940005D; Wed, 6 Sep 2017 10:02:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1504684943; bh=izhyX4aYPuAdq7FESMOP0q7uk8c3Q2Uv+v+OYWvfFHY=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=rAyVt3SIVyqJpZfMIxq6OonaETeliK0oEC98RFAW/mRN2YTBeRN9R3CU5+1E2LUoY pZdcJSMvelouytXneTFyD+jXldsFeXVsLxiu9da6ZnlOUSXFvs3Cql65xWKRyfxMCq ow2mw00RhITzqAflh8dP/zNJF6uh99wftdEX3z9g= To: Martin Bjorklund , andy@yumaworks.com Cc: netmod@ietf.org References: <20170905190151.fizr5dljufbyuyty@elstar.local> <20170906.085222.355333494940576314.mbj@tail-f.com> From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= Message-ID: Date: Wed, 6 Sep 2017 10:02:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170906.085222.355333494940576314.mbj@tail-f.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [netmod] 'status' statement needed on every node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 08:02:30 -0000 Dne 6.9.2017 v 08:52 Martin Bjorklund napsal(a): > Andy Bierman wrote: >> On Tue, Sep 5, 2017 at 3:50 PM, Kent Watsen wrot= e: >> >>> >>> >>>>> I still don't know what it means to define hierarchical data and sa= y the >>>>> parent is deprecated but not the descendant nodes. >>>> It is odd but can happen anyway. A current augmentation of something= >>>> that got deprecated likely stays current. I would hope that tools wa= rn >>>> if they see this but that's it. >>> This example seems to provide support for saying status should be >>> inherited. But, to be clear, you agree that if a parent is deprecate= d, >>> than its decedents should be deprecated as well, right? >>> >>> >>> >> right -- the RFC says this has to be done manually. >> A missing status-stmt means status=3Dcurrent. >> >> >> >>>>> This is rather non-intuitive, as is the idea that all descendant >>>>> nodes need to be manually edited (status is not inherited). >>>> Not a big deal. The benefit is that a reader like me knows clear tha= t >>>> the definition I am look at is deprecated, no need to search backwar= ds >>>> to find out. >>> tree diagrams do this too, though I like Martin's approach of removin= g >>> the deprecated -state trees from the tree diagram altogether. >>> >>> >>> >>>>> It also means the objects expanded from groupings cannot ever be >>>>> changed (clearly a bug in YANG). >>>> Yes, bug in YANG. >>> Is this the same issue I raised? >>> >>> import ietf-foo { >>> prefix f; >>> } >>> >>> container bar { >>> uses f:foo; >>> } >>> >>> container baz { >>> status deprecated; >>> uses f:foo; <-- oops, descendants not deprecated! >>> } (not a problem if status inherited) > As Andy explains below, this should be: > > container baz { > status deprecated; > uses f:foo { > status deprecated; > } > } despite I see this explanation of status in uses as useful, I don't see a= nything in RFC that would support this. >> According to my interpretation of 7.21.2, this is a MUST NOT: >> >> If a definition is "current", it MUST NOT reference a "deprecated" = or >> "obsolete" definition within the same module. >> >> If a definition is "deprecated", it MUST NOT reference an "obsolete= " >> definition within the same module. >> >> For example, the following is illegal: >> >> typedef my-type { >> status deprecated; >> type int32; >> } >> >> leaf my-leaf { >> status current; >> type my-type; // illegal, since my-type is deprecated >> } >> >> The term "reference" is not really defined above. >> It should also clearly apply to "uses" (e.g., your example) and leafr= ef >> path-stmt. >> >> leaf foo { >> type string; >> status deprecated; >> } >> >> leaf bar { >> type leafref { path /foo; } >> } >> >> If it apples to path-stmt, then why not all XPath? > B/c in XPath it is even ok to refer to non-existing nodes. And you > might have things like /baz/*. > >> Why doesn't "reference" include descendant nodes? >> >> The text in 7950 is too strict and can cause a massive ripple-effect w= hen >> any status-stmt is changed. >> At the same time it is too vague to be useful to implementors. > While I agree that it is not clear what it means to have a "current" > child to a "deprecated" node, I don't think this is a big issue. If a > node is deprecated, it is ok for an implementation to not implement > it. Obviously this means that no child nodes to that node is > implemented either, regardless of their status, if they are augmented > in, or comes from a grouping. what about the mandatory nodes inside a deprecated container? Formally, t= hey are not deprecated (default status is current) so still mandatory, ri= ght? Radek From nobody Wed Sep 6 01:33:16 2017 Return-Path: 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 792E81326EA for ; Wed, 6 Sep 2017 01:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] 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 btDYf0Zwz6Mo for ; Wed, 6 Sep 2017 01:33:12 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 4EF141326BB for ; Wed, 6 Sep 2017 01:33:11 -0700 (PDT) Received: from birdie109 (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 7892C621CA; Wed, 6 Sep 2017 10:33:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1504686789; bh=n35XL9XVg3GN80Yax3vcT8iNgArOPKBoKCHWjWFSv4o=; h=From:To:Date; b=jRa5eXI7HD/AAZhAFBLQHi4RPqayTUxxZZpQYa9rEacFio4Q/MDZQwe37ZitOd/s6 +bRKP2pZtsXf+IlW8mWiGOwI842M+a1f9gJevZjenJvJ5ubZdHAiODujY1lY4losk3 MfjdDJAIwd0sW/fRWgKXnvJDzJ+jRCzoURoiJvEg= Message-ID: <1504686822.3468.22.camel@nic.cz> From: Ladislav Lhotka To: Robert Wilton , Lou Berger , netmod@ietf.org Date: Wed, 06 Sep 2017 10:33:42 +0200 In-Reply-To: References: <20170830102902.2n5q6rgq2x2dxfq2@elstar.local> <20170830123156.cssrg5kklpo67fie@elstar.local> <1504223854014.55228@Aviatnet.com> <847e5bf9-7b3d-9ff8-9954-970f32a2094c@cisco.com> <20170902073342.xoziwor4tdr5bipw@elstar.local> <20170902112832.ymorfgdthobeio6q@elstar.local> <1e95ba5d-7aa2-e08f-56f9-27aa70822a11@cisco.com> <1504537140.5874.38.camel@nic.cz> <1504629352.7175.40.camel@nic.cz> <8af6041d-7cd5-9608-70b4-7cffc4f884f8@cisco.com> <2a70ce5e-7727-d280-98e4-481d87314d14@labn.net> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.5 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 08:33:14 -0000 Robert Wilton píše v St 06. 09. 2017 v 08:52 +0100: > Hi Lou, > > This is the addition to 6087bis that I propose. Note, this is the same > text in my email on the 31st of August. > > I propose adding the following 2 paragraphs to 6087bis section on > pattern and ranges: > > NEW: > To ensure patterns are easy to read and implement, authors SHOULD > restrict themselves to the parts of the XML schema regular expression > language that are common across most regular expression languages. In > particular, pattern statements SHOULD avoid using 'character class > subtraction' (e.g. '[a-z-[aeiou]]'). They SHOULD avoid matching > unicode properties and blocks (e.g. '\p{L} or \p{IsBasic_Latin}'). > They MAY use the '\d', '\w', '\s' character class shorthands and their > negated versions, where appropriate, but SHOULD avoid other character > class shorthands. To match ASCII digits 0-9 the character class I don't agree, things like \p{L} may be useful, at least in this part of the world. Moreover, \w means "any Unicode character not defined as punctuation, separator, or other" in YANG, but it may mean something else in a programming language, perhaps also depending on locale setting. This is a slippery slope, developers should not assume they can take a regex from YANG, enclose it in ^..$ and then feed into a RE-matching function. Lada > '[0-9]' MUST be used instead of the '\d' character class shorthand > that matches Unicode digits in all scripts. > > Pattern statements do not have to strictly restrict numerical values, > and a simple less specific pattern may be preferable over a more > complex and precise pattern, e.g. as illustrated in the > 'ipv4-address-no-zone' example pattern below. > > > Or, put in context of the existing text 6087bis text: > > *** Patterns and Ranges > > For string data types, if a machine-readable pattern > can be defined for the desired semantics, then > one or more pattern statements SHOULD be present. > A single quoted string SHOULD be used to specify the pattern, > since a double-quoted string can modify the content. > > To ensure patterns are easy to read and implement, authors SHOULD > restrict themselves to the parts of the XML schema regular expression > language that are common across most regular expression languages. In > particular, pattern statements SHOULD avoid using 'character class > subtraction' (e.g. '[a-z-[aeiou]]'). They SHOULD avoid matching > unicode properties and blocks (e.g. '\p{L} or \p{IsBasic_Latin}'). > They MAY use the '\d', '\w', '\s' character class shorthands and their > negated versions, where appropriate, but SHOULD avoid other character > class shorthands. To match ASCII digits 0-9 the character class > '[0-9]' MUST be used instead of the '\d' character class shorthand > that also matches Unicode digits in all scripts. > > Pattern statements do not have to strictly restrict numerical values, > and a simple less specific pattern may be preferable over a more > complex and precise pattern, e.g. as illustrated in the > 'ipv4-address-no-zone' example pattern below. > > The following typedef from ^RFC6991^ demonstrates the proper > use of the "pattern" statement: > > typedef ipv4-address-no-zone { > type inet:ipv4-address { > pattern '[0-9\.]*'; > } > ... > } > > For string data types, if the length of the string > is required to be bounded in all implementations, > then a length statement MUST be present. > > The following typedef from ^RFC6991^ demonstrates the proper > use of the "length" statement: > > typedef yang-identifier { > type string { > length "1..max"; > pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*'; > pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*'; > } > ... > } > > For numeric data types, if the values allowed > by the intended semantics are different than > those allowed by the unbounded intrinsic data > type (e.g., 'int32'), then a range statement SHOULD be present. > > The following typedef from ^RFC6991^ demonstrates the proper > use of the "range" statement: > > typedef dscp { > type uint8 { > range "0..63"; > } > ... > } > > Thanks, > Rob > > > On 05/09/2017 22:37, Lou Berger wrote: > > Rob, > > > > (as chair) > > On 9/5/2017 1:17 PM, Robert Wilton wrote: > > > However, I have thrown in the towel on my regex crusade. > > > > I'm sorry, I've lost the thread here a bit. in order to guage consensus > > on this topic, it would be helpful to send the latest text that you are > > proposing for inclusion in the the bis. If you are willing to do these, > > we can poll to see if there is/is not support for inclusion of this > > text. Are you willing, i.e., can you send the current proposed text change? > > > > Thank you, > > Lou > > > > . > > > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Sep 6 01:51:13 2017 Return-Path: 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 4F716132396 for ; Wed, 6 Sep 2017 01:51:12 -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 aO3_9M1zueJU for ; Wed, 6 Sep 2017 01:51:10 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7161270AB for ; Wed, 6 Sep 2017 01:51:10 -0700 (PDT) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 8D0C81AE0187; Wed, 6 Sep 2017 10:51:09 +0200 (CEST) Date: Wed, 06 Sep 2017 10:49:36 +0200 (CEST) Message-Id: <20170906.104936.1524498889327990684.mbj@tail-f.com> To: rkrejci@cesnet.cz Cc: andy@yumaworks.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20170906.085222.355333494940576314.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netmod] 'status' statement needed on every node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 08:51:12 -0000 UmFkZWsgS3JlasSNw60gPHJrcmVqY2lAY2VzbmV0LmN6PiB3cm90ZToNCj4gRG5lIDYuOS4yMDE3 IHYgMDg6NTIgTWFydGluIEJqb3JrbHVuZCBuYXBzYWwoYSk6DQo+ID4gQW5keSBCaWVybWFuIDxh bmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiA+PiBPbiBUdWUsIFNlcCA1LCAyMDE3IGF0IDM6 NTAgUE0sIEtlbnQgV2F0c2VuIDxrd2F0c2VuQGp1bmlwZXIubmV0PiB3cm90ZToNCj4gPj4NCj4g Pj4+DQo+ID4+Pg0KPiA+Pj4+PiBJIHN0aWxsIGRvbid0IGtub3cgd2hhdCBpdCBtZWFucyB0byBk ZWZpbmUgaGllcmFyY2hpY2FsIGRhdGEgYW5kIHNheSB0aGUNCj4gPj4+Pj4gcGFyZW50IGlzIGRl cHJlY2F0ZWQgYnV0IG5vdCB0aGUgZGVzY2VuZGFudCBub2Rlcy4NCj4gPj4+PiBJdCBpcyBvZGQg YnV0IGNhbiBoYXBwZW4gYW55d2F5LiBBIGN1cnJlbnQgYXVnbWVudGF0aW9uIG9mIHNvbWV0aGlu Zw0KPiA+Pj4+IHRoYXQgZ290IGRlcHJlY2F0ZWQgbGlrZWx5IHN0YXlzIGN1cnJlbnQuIEkgd291 bGQgaG9wZSB0aGF0IHRvb2xzIHdhcm4NCj4gPj4+PiBpZiB0aGV5IHNlZSB0aGlzIGJ1dCB0aGF0 J3MgaXQuDQo+ID4+PiBUaGlzIGV4YW1wbGUgc2VlbXMgdG8gcHJvdmlkZSBzdXBwb3J0IGZvciBz YXlpbmcgc3RhdHVzIHNob3VsZCBiZQ0KPiA+Pj4gaW5oZXJpdGVkLiAgQnV0LCB0byBiZSBjbGVh ciwgeW91IGFncmVlIHRoYXQgaWYgYSBwYXJlbnQgaXMgZGVwcmVjYXRlZCwNCj4gPj4+IHRoYW4g aXRzIGRlY2VkZW50cyBzaG91bGQgYmUgZGVwcmVjYXRlZCBhcyB3ZWxsLCByaWdodD8NCj4gPj4+ DQo+ID4+Pg0KPiA+Pj4NCj4gPj4gcmlnaHQgLS0gdGhlIFJGQyBzYXlzIHRoaXMgaGFzIHRvIGJl IGRvbmUgbWFudWFsbHkuDQo+ID4+IEEgbWlzc2luZyBzdGF0dXMtc3RtdCBtZWFucyBzdGF0dXM9 Y3VycmVudC4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4+Pj4gVGhpcyBpcyByYXRoZXIgbm9uLWlu dHVpdGl2ZSwgYXMgaXMgdGhlIGlkZWEgdGhhdCBhbGwgZGVzY2VuZGFudA0KPiA+Pj4+PiBub2Rl cyBuZWVkIHRvIGJlIG1hbnVhbGx5IGVkaXRlZCAoc3RhdHVzIGlzIG5vdCBpbmhlcml0ZWQpLg0K PiA+Pj4+IE5vdCBhIGJpZyBkZWFsLiBUaGUgYmVuZWZpdCBpcyB0aGF0IGEgcmVhZGVyIGxpa2Ug bWUga25vd3MgY2xlYXIgdGhhdA0KPiA+Pj4+IHRoZSBkZWZpbml0aW9uIEkgYW0gbG9vayBhdCBp cyBkZXByZWNhdGVkLCBubyBuZWVkIHRvIHNlYXJjaCBiYWNrd2FyZHMNCj4gPj4+PiB0byBmaW5k IG91dC4NCj4gPj4+IHRyZWUgZGlhZ3JhbXMgZG8gdGhpcyB0b28sIHRob3VnaCBJIGxpa2UgTWFy dGluJ3MgYXBwcm9hY2ggb2YgcmVtb3ZpbmcNCj4gPj4+IHRoZSBkZXByZWNhdGVkIC1zdGF0ZSB0 cmVlcyBmcm9tIHRoZSB0cmVlIGRpYWdyYW0gYWx0b2dldGhlci4NCj4gPj4+DQo+ID4+Pg0KPiA+ Pj4NCj4gPj4+Pj4gSXQgYWxzbyBtZWFucyB0aGUgb2JqZWN0cyBleHBhbmRlZCBmcm9tIGdyb3Vw aW5ncyBjYW5ub3QgZXZlciBiZQ0KPiA+Pj4+PiBjaGFuZ2VkIChjbGVhcmx5IGEgYnVnIGluIFlB TkcpLg0KPiA+Pj4+IFllcywgYnVnIGluIFlBTkcuDQo+ID4+PiBJcyB0aGlzIHRoZSBzYW1lIGlz c3VlIEkgcmFpc2VkPw0KPiA+Pj4NCj4gPj4+ICAgaW1wb3J0IGlldGYtZm9vIHsNCj4gPj4+ICAg ICBwcmVmaXggZjsNCj4gPj4+ICAgfQ0KPiA+Pj4NCj4gPj4+ICAgY29udGFpbmVyIGJhciB7DQo+ ID4+PiAgICAgdXNlcyBmOmZvbzsNCj4gPj4+ICAgfQ0KPiA+Pj4NCj4gPj4+ICAgY29udGFpbmVy IGJheiB7DQo+ID4+PiAgICAgc3RhdHVzIGRlcHJlY2F0ZWQ7DQo+ID4+PiAgICAgdXNlcyBmOmZv bzsgICAgICAgICAgICA8LS0gb29wcywgZGVzY2VuZGFudHMgbm90IGRlcHJlY2F0ZWQhDQo+ID4+ PiAgIH0gICAgICAgICAgICAgICAgICAgICAgICAgICAobm90IGEgcHJvYmxlbSBpZiBzdGF0dXMg aW5oZXJpdGVkKQ0KPiA+IEFzIEFuZHkgZXhwbGFpbnMgYmVsb3csIHRoaXMgc2hvdWxkIGJlOg0K PiA+DQo+ID4gICAgY29udGFpbmVyIGJheiB7DQo+ID4gICAgICBzdGF0dXMgZGVwcmVjYXRlZDsN Cj4gPiAgICAgIHVzZXMgZjpmb28gew0KPiA+ICAgICAgICBzdGF0dXMgZGVwcmVjYXRlZDsNCj4g PiAgICAgIH0NCj4gPiAgICB9DQo+IA0KPiBkZXNwaXRlIEkgc2VlIHRoaXMgZXhwbGFuYXRpb24g b2Ygc3RhdHVzIGluIHVzZXMgYXMgdXNlZnVsLCBJIGRvbid0DQo+IHNlZSBhbnl0aGluZyBpbiBS RkMgdGhhdCB3b3VsZCBzdXBwb3J0IHRoaXMuDQoNCkknbSBqdXN0IHNheWluZyB0aGF0IGFsc28g InVzZXMiIGNhbiwgYW5kIHNob3VsZCBiZSBpbiB0aGlzIGNhc2UsDQptYXJrZWQgYXMgZGVwcmVj YXRlZC4NCg0KPiA+PiBBY2NvcmRpbmcgdG8gbXkgaW50ZXJwcmV0YXRpb24gb2YgNy4yMS4yLCB0 aGlzIGlzIGEgTVVTVCBOT1Q6DQo+ID4+DQo+ID4+ICAgIElmIGEgZGVmaW5pdGlvbiBpcyAiY3Vy cmVudCIsIGl0IE1VU1QgTk9UIHJlZmVyZW5jZSBhICJkZXByZWNhdGVkIiBvcg0KPiA+PiAgICAi b2Jzb2xldGUiIGRlZmluaXRpb24gd2l0aGluIHRoZSBzYW1lIG1vZHVsZS4NCj4gPj4NCj4gPj4g ICAgSWYgYSBkZWZpbml0aW9uIGlzICJkZXByZWNhdGVkIiwgaXQgTVVTVCBOT1QgcmVmZXJlbmNl IGFuICJvYnNvbGV0ZSINCj4gPj4gICAgZGVmaW5pdGlvbiB3aXRoaW4gdGhlIHNhbWUgbW9kdWxl Lg0KPiA+Pg0KPiA+PiAgICBGb3IgZXhhbXBsZSwgdGhlIGZvbGxvd2luZyBpcyBpbGxlZ2FsOg0K PiA+Pg0KPiA+PiAgICAgIHR5cGVkZWYgbXktdHlwZSB7DQo+ID4+ICAgICAgICBzdGF0dXMgZGVw cmVjYXRlZDsNCj4gPj4gICAgICAgIHR5cGUgaW50MzI7DQo+ID4+ICAgICAgfQ0KPiA+Pg0KPiA+ PiAgICAgIGxlYWYgbXktbGVhZiB7DQo+ID4+ICAgICAgICBzdGF0dXMgY3VycmVudDsNCj4gPj4g ICAgICAgIHR5cGUgbXktdHlwZTsgLy8gaWxsZWdhbCwgc2luY2UgbXktdHlwZSBpcyBkZXByZWNh dGVkDQo+ID4+ICAgICAgfQ0KPiA+Pg0KPiA+PiBUaGUgdGVybSAicmVmZXJlbmNlIiBpcyBub3Qg cmVhbGx5IGRlZmluZWQgYWJvdmUuDQo+ID4+IEl0IHNob3VsZCBhbHNvIGNsZWFybHkgYXBwbHkg dG8gInVzZXMiIChlLmcuLCB5b3VyIGV4YW1wbGUpIGFuZCAgbGVhZnJlZg0KPiA+PiBwYXRoLXN0 bXQuDQo+ID4+DQo+ID4+ICAgIGxlYWYgZm9vIHsNCj4gPj4gICAgICB0eXBlIHN0cmluZzsNCj4g Pj4gICAgICBzdGF0dXMgZGVwcmVjYXRlZDsNCj4gPj4gICB9DQo+ID4+DQo+ID4+ICAgbGVhZiBi YXIgew0KPiA+PiAgICAgdHlwZSBsZWFmcmVmIHsgcGF0aCAvZm9vOyB9DQo+ID4+ICAgfQ0KPiA+ Pg0KPiA+PiBJZiBpdCBhcHBsZXMgdG8gcGF0aC1zdG10LCB0aGVuIHdoeSBub3QgYWxsIFhQYXRo Pw0KPiA+IEIvYyBpbiBYUGF0aCBpdCBpcyBldmVuIG9rIHRvIHJlZmVyIHRvIG5vbi1leGlzdGlu ZyBub2Rlcy4gIEFuZCB5b3UNCj4gPiBtaWdodCBoYXZlIHRoaW5ncyBsaWtlIC9iYXovKi4NCj4g Pg0KPiA+PiBXaHkgZG9lc24ndCAicmVmZXJlbmNlIiBpbmNsdWRlIGRlc2NlbmRhbnQgbm9kZXM/ DQo+ID4+DQo+ID4+IFRoZSB0ZXh0IGluIDc5NTAgaXMgdG9vIHN0cmljdCBhbmQgY2FuIGNhdXNl IGEgbWFzc2l2ZSByaXBwbGUtZWZmZWN0IHdoZW4NCj4gPj4gYW55IHN0YXR1cy1zdG10IGlzIGNo YW5nZWQuDQo+ID4+ICBBdCB0aGUgc2FtZSB0aW1lIGl0IGlzIHRvbyB2YWd1ZSB0byBiZSB1c2Vm dWwgdG8gaW1wbGVtZW50b3JzLg0KPiA+IFdoaWxlIEkgYWdyZWUgdGhhdCBpdCBpcyBub3QgY2xl YXIgd2hhdCBpdCBtZWFucyB0byBoYXZlIGEgImN1cnJlbnQiDQo+ID4gY2hpbGQgdG8gYSAiZGVw cmVjYXRlZCIgbm9kZSwgSSBkb24ndCB0aGluayB0aGlzIGlzIGEgYmlnIGlzc3VlLiAgSWYgYQ0K PiA+IG5vZGUgaXMgZGVwcmVjYXRlZCwgaXQgaXMgb2sgZm9yIGFuIGltcGxlbWVudGF0aW9uIHRv IG5vdCBpbXBsZW1lbnQNCj4gPiBpdC4gIE9idmlvdXNseSB0aGlzIG1lYW5zIHRoYXQgbm8gY2hp bGQgbm9kZXMgdG8gdGhhdCBub2RlIGlzDQo+ID4gaW1wbGVtZW50ZWQgZWl0aGVyLCByZWdhcmRs ZXNzIG9mIHRoZWlyIHN0YXR1cywgaWYgdGhleSBhcmUgYXVnbWVudGVkDQo+ID4gaW4sIG9yIGNv bWVzIGZyb20gYSBncm91cGluZy4NCj4gDQo+IHdoYXQgYWJvdXQgdGhlIG1hbmRhdG9yeSBub2Rl cyBpbnNpZGUgYSBkZXByZWNhdGVkIGNvbnRhaW5lcj8NCj4gRm9ybWFsbHksIHRoZXkgYXJlIG5v dCBkZXByZWNhdGVkIChkZWZhdWx0IHN0YXR1cyBpcyBjdXJyZW50KSBzbw0KPiBzdGlsbCBtYW5k YXRvcnksIHJpZ2h0Pw0KDQptYW5kYXRvcnkgb3Igbm90IGRvZXNuJ3QgbWF0dGVyOyBtYW5kYXRv cnkgZG9lc24ndCBtZWFuICJtdXN0DQppbXBsZW1lbnQiLCBidXQgIm11c3QgZXhpc3QgaWYgdGhl IHBhcmVudCBleGlzdHMiLg0KDQoNCg0KL21hcnRpbg0K From nobody Wed Sep 6 01:59:14 2017 Return-Path: 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 AAFB3132518 for ; Wed, 6 Sep 2017 01:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 0h4GsckizKcg for ; Wed, 6 Sep 2017 01:59:11 -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 8FB3D1270AB for ; Wed, 6 Sep 2017 01:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5621; q=dns/txt; s=iport; t=1504688350; x=1505897950; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=/zPD9nm65v9HLatwjPb9OCN32blM7+NzOldjJzPoozc=; b=iVNkICEzL2GASWBDKCg9TMzxps3hg9sXCXAF/awjEKj38ngpPLBOf7V4 kyf6U9JsJAlZKSjYXlt4to9o+xETNF723TjZJnBaew+eEQnYbQ7hwpJgz d9et3rrhqg2VsoiSdp40sMbAGYXRaTE/mIHJBw+6Uj0OdPBS8GTlPrECC 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BFAgCIt69Z/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBiUqLFZB8IpY2ggQKhT4ChHwUAQIBAQEBAQEBayiFGAEBAQECASM?= =?us-ascii?q?PAQVRCQIYAgImAgJXBgEMCAEBiiUIkTOdZoInizkBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEdgQ2CHYNQgWMrC4JyhEKDRoJhBaB0izWJHIITiUEkhnmNV4dUgTk2IYE?= =?us-ascii?q?CCzIhCBwVh2U/il8BAQE?= X-IronPort-AV: E=Sophos;i="5.41,483,1498521600"; d="scan'208";a="657274092" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Sep 2017 08:59:06 +0000 Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v868x6g0011000; Wed, 6 Sep 2017 08:59:06 GMT To: Ladislav Lhotka , Lou Berger , netmod@ietf.org References: <20170830102902.2n5q6rgq2x2dxfq2@elstar.local> <20170830123156.cssrg5kklpo67fie@elstar.local> <1504223854014.55228@Aviatnet.com> <847e5bf9-7b3d-9ff8-9954-970f32a2094c@cisco.com> <20170902073342.xoziwor4tdr5bipw@elstar.local> <20170902112832.ymorfgdthobeio6q@elstar.local> <1e95ba5d-7aa2-e08f-56f9-27aa70822a11@cisco.com> <1504537140.5874.38.camel@nic.cz> <1504629352.7175.40.camel@nic.cz> <8af6041d-7cd5-9608-70b4-7cffc4f884f8@cisco.com> <2a70ce5e-7727-d280-98e4-481d87314d14@labn.net> <1504686822.3468.22.camel@nic.cz> From: Robert Wilton Message-ID: Date: Wed, 6 Sep 2017 09:59:05 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1504686822.3468.22.camel@nic.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 08:59:12 -0000 On 06/09/2017 09:33, Ladislav Lhotka wrote: > Robert Wilton píše v St 06. 09. 2017 v 08:52 +0100: >> Hi Lou, >> >> This is the addition to 6087bis that I propose. Note, this is the same >> text in my email on the 31st of August. >> >> I propose adding the following 2 paragraphs to 6087bis section on >> pattern and ranges: >> >> NEW: >> To ensure patterns are easy to read and implement, authors SHOULD >> restrict themselves to the parts of the XML schema regular expression >> language that are common across most regular expression languages. In >> particular, pattern statements SHOULD avoid using 'character class >> subtraction' (e.g. '[a-z-[aeiou]]'). They SHOULD avoid matching >> unicode properties and blocks (e.g. '\p{L} or \p{IsBasic_Latin}'). >> They MAY use the '\d', '\w', '\s' character class shorthands and their >> negated versions, where appropriate, but SHOULD avoid other character >> class shorthands. To match ASCII digits 0-9 the character class > I don't agree, things like \p{L} may be useful, at least in this part of the > world. > > Moreover, \w means "any Unicode character not defined as punctuation, separator, > or other" in YANG, but it may mean something else in a programming language, > perhaps also depending on locale setting. This is a slippery slope, developers > should not assume they can take a regex from YANG, enclose it in ^..$ and then > feed into a RE-matching function. For clarity: I am not suggesting that they pass the pattern statement directly into the local regex engine.  Instead, I am suggesting that they convert it first (which may involve expanding \w to the equivalent XSD RE character class) before feeding it into the RE-matching function.  Whatever RE engine is used to interpret the pattern statement, the result must be the same as if an XSD RE engine was used (as defined by the YANG spec). Thanks, Rob > > Lada > >> '[0-9]' MUST be used instead of the '\d' character class shorthand >> that matches Unicode digits in all scripts. >> >> Pattern statements do not have to strictly restrict numerical values, >> and a simple less specific pattern may be preferable over a more >> complex and precise pattern, e.g. as illustrated in the >> 'ipv4-address-no-zone' example pattern below. >> >> >> Or, put in context of the existing text 6087bis text: >> >> *** Patterns and Ranges >> >> For string data types, if a machine-readable pattern >> can be defined for the desired semantics, then >> one or more pattern statements SHOULD be present. >> A single quoted string SHOULD be used to specify the pattern, >> since a double-quoted string can modify the content. >> >> To ensure patterns are easy to read and implement, authors SHOULD >> restrict themselves to the parts of the XML schema regular expression >> language that are common across most regular expression languages. In >> particular, pattern statements SHOULD avoid using 'character class >> subtraction' (e.g. '[a-z-[aeiou]]'). They SHOULD avoid matching >> unicode properties and blocks (e.g. '\p{L} or \p{IsBasic_Latin}'). >> They MAY use the '\d', '\w', '\s' character class shorthands and their >> negated versions, where appropriate, but SHOULD avoid other character >> class shorthands. To match ASCII digits 0-9 the character class >> '[0-9]' MUST be used instead of the '\d' character class shorthand >> that also matches Unicode digits in all scripts. >> >> Pattern statements do not have to strictly restrict numerical values, >> and a simple less specific pattern may be preferable over a more >> complex and precise pattern, e.g. as illustrated in the >> 'ipv4-address-no-zone' example pattern below. >> >> The following typedef from ^RFC6991^ demonstrates the proper >> use of the "pattern" statement: >> >> typedef ipv4-address-no-zone { >> type inet:ipv4-address { >> pattern '[0-9\.]*'; >> } >> ... >> } >> >> For string data types, if the length of the string >> is required to be bounded in all implementations, >> then a length statement MUST be present. >> >> The following typedef from ^RFC6991^ demonstrates the proper >> use of the "length" statement: >> >> typedef yang-identifier { >> type string { >> length "1..max"; >> pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*'; >> pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*'; >> } >> ... >> } >> >> For numeric data types, if the values allowed >> by the intended semantics are different than >> those allowed by the unbounded intrinsic data >> type (e.g., 'int32'), then a range statement SHOULD be present. >> >> The following typedef from ^RFC6991^ demonstrates the proper >> use of the "range" statement: >> >> typedef dscp { >> type uint8 { >> range "0..63"; >> } >> ... >> } >> >> Thanks, >> Rob >> >> >> On 05/09/2017 22:37, Lou Berger wrote: >>> Rob, >>> >>> (as chair) >>> On 9/5/2017 1:17 PM, Robert Wilton wrote: >>>> However, I have thrown in the towel on my regex crusade. >>> I'm sorry, I've lost the thread here a bit. in order to guage consensus >>> on this topic, it would be helpful to send the latest text that you are >>> proposing for inclusion in the the bis. If you are willing to do these, >>> we can poll to see if there is/is not support for inclusion of this >>> text. Are you willing, i.e., can you send the current proposed text change? >>> >>> Thank you, >>> Lou >>> >>> . >>> >> From nobody Wed Sep 6 02:16:43 2017 Return-Path: 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 511E81323B4 for ; Wed, 6 Sep 2017 02:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 iaALobKtsbtr for ; Wed, 6 Sep 2017 02:16:41 -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 B7D62132623 for ; Wed, 6 Sep 2017 02:16:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3799; q=dns/txt; s=iport; t=1504689400; x=1505899000; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=93qCK8s1UozrI416/nfmUU/lUZC0EQrtuhmSVeH1lEE=; b=PGpgGqHZP/KsiqTdlqoKJ1WfObNHX3GgvlX5x5pTInBLfEEPMJVE5Up9 O9IwsWzgRI/9KlmIyIWMuH8kCEIYwtRrlVviOinD9xJqFUe8IPwQBKbt6 cmvwLt9Ykwf27SU/MtUp1lcI5LOd9PGi8KHFKcuiE0g2b6GZbHzwTxqhX I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BFAgCUvK9Z/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBiUqLFZB8Ipg6CoU+AoR9FAECAQEBAQEBAWsohRgBAQEBAgEjDwE?= =?us-ascii?q?FRgsLGAICJgICVwYBDAgBAReKDgivEYInizkBAQEBAQEBAQIBAQEBAQEBIYENg?= =?us-ascii?q?h2DUIIOC4JyiAiCYQWgdJRRi1SHHY1Xh1SBOTYhgQ0yIQgcFYVhHIFoP4pfAQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.41,483,1498521600"; d="scan'208";a="655453635" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Sep 2017 09:16:36 +0000 Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v869GaOj023525; Wed, 6 Sep 2017 09:16:36 GMT To: "j.schoenwaelder@jacobs-university.de" , netmod@ietf.org References: <847e5bf9-7b3d-9ff8-9954-970f32a2094c@cisco.com> <20170902073342.xoziwor4tdr5bipw@elstar.local> <20170902112832.ymorfgdthobeio6q@elstar.local> <1e95ba5d-7aa2-e08f-56f9-27aa70822a11@cisco.com> <1504537140.5874.38.camel@nic.cz> <1504629352.7175.40.camel@nic.cz> <8af6041d-7cd5-9608-70b4-7cffc4f884f8@cisco.com> <20170905180006.yecbqqdhxtkvosxk@elstar.local> From: Robert Wilton Message-ID: Date: Wed, 6 Sep 2017 10:16:36 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170905180006.yecbqqdhxtkvosxk@elstar.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 09:16:42 -0000 On 05/09/2017 19:00, Juergen Schoenwaelder wrote: > On Tue, Sep 05, 2017 at 06:17:09PM +0100, Robert Wilton wrote: >>> I believe that tools intended for general use should follow the YANG spec >>> literally. >> I don't fully agree.  I think that they only need to cover the parts of the >> YANG spec for the models that they are using (or might use). If nobody uses >> Unicode blocks then it doesn't really matter whether a given tool supports >> them or not.  It is always possible to caveat and add support for the >> missing bits later.  E.g. if I was writing a bespoke XPATH implementation >> for YANG then there is probably quite a lot of the XPATH spec that I would >> also leave out as well, and just concentrate on the parts that people >> actually use, or are likely to use. >> > If this is your understanding of standards, why do you want to define > a subset of XSD pattern based on the your observation what is used or > not used? Simply do not implement what you observe is not used. Why do > we need guidelines of constructs not to use so that they are not used? My aims: 1) To make pattern statements in standard YANG models easier to comprehend. 2) So that implementations designed to only support standard YANG models can have more confidence that they don't need to support all of the Unciode properties and character blocks. > > There are multiple contradictions in your posts, one of them was the > idea of translating unicode matching to ASCII - which simply does not > work. This does work if your implementation is willing to be restricted to only supporting ASCII.  Some users of YANG seem to think that ASCII is sufficient to configure and manage network devices.  My person opinion is that they are probably broadly right, but there are some places where supporting a unicode string is better (e.g. the interface description leaf).  However, in these cases I think that either no pattern statement is required, or otherwise \w,\s,\d are probably sufficient. I understand, and agree, that an implementation that restricts pattern statement support to only ASCII strings makes the implementation non compliant to the YANG spec. > Or the post where you said \d is OK but then later said \d is > not OK since it translates to a large number of numeric characters. Yes, my opinion changed when I found our that '\d' covers more than just ASCII.  As per the 6087bis text that I sent out, I think that '\d' can be used, but must not be used if the regex is meant to only match ASCII 0 to 9.  My concern is that many readers/authors/implementors of YANG models may not understand properly understand that '\d' also covers digits in other unicode scripts, and hence I think that it is more clear (and hence better) to use '[0-9]' in pattern statements instead, since the interpretation of that is entirely unambiguous. > You really need to sort out what you want, what the problem is you are > trying to solve, how you select the subset of XSD pattern etc. Write > and I-D. Do you think that writing an I-D, that would contain the same arguments that I've presented here, would sway your opinion at all? My assumption is that it wouldn't and hence writing up an ID would seem to be a waste of effort. > And at the end, people who only do POSIX regular expressions, > because they come with the standard C library on POSIX systems or > whatever the reason really is, still will either have to continue to > cheat by silently interpreting XSD pattern as POSIX pattern or they > create a proper new statement to at least properly distinguish > different pattern languages. Sure, but I don't regard either of these as good long term solutions. Thanks, Rob > > /js > From nobody Wed Sep 6 02:34:41 2017 Return-Path: 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 B98E213247A for ; Wed, 6 Sep 2017 02:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 rU2aOov_6luL for ; Wed, 6 Sep 2017 02:34:38 -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 9E7D01323B4 for ; Wed, 6 Sep 2017 02:34:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2863; q=dns/txt; s=iport; t=1504690477; x=1505900077; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=esNSAIocypIutyc8FLJdB7hWyN0SgRIHSuOCMCZxSjA=; b=hO7A8rjbhCogjpRd06k2IkXlAwejKqo2SVCKxkvvkw5USlvO9+apv25S mFxs7R/7mZwMp6iRY8Ute5keHNRw96pG7wVXpGTFGpbrBYuL0EIoq/znR 3i1nfLIvC5E1W0KwtTwcwtlKg4ndpui2N2bYtTTvX20pWAod/1s70u3l5 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtAQAGwK9Z/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBiUqLFZEemDoKhT4ChH0UAQIBAQEBAQEBayiFGQEFIw8BBVELGAI?= =?us-ascii?q?CJgICVxMIAQGKLa8cgieLOAEBAQcCJoENgh2DUIIOgn2EX2KCR4JhBZEoj0yUU?= =?us-ascii?q?YtUhx2NV4dUgTk2IYENMiEIHBWHZT+KWwEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,483,1498521600"; d="scan'208";a="655454066" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Sep 2017 09:34:33 +0000 Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v869YXck027567 for ; Wed, 6 Sep 2017 09:34:33 GMT To: netmod@ietf.org References: <20170905190151.fizr5dljufbyuyty@elstar.local> <20170906014757.GD31035@shrubbery.net> <20170906065723.dnv4xl2mchszcvlo@elstar.local> From: Robert Wilton Message-ID: <478d00da-2cdf-b416-c0e5-cbba29c9ed43@cisco.com> Date: Wed, 6 Sep 2017 10:34:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170906065723.dnv4xl2mchszcvlo@elstar.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] 'status' statement needed on every node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 09:34:40 -0000 I would prefer if it status was inherited (as an errata to 6020, 7950).  It seems that when it comes to implementation that is what is going to happen regardless.   If a server chooses to not support a deprecated node then any children nodes will also not be supported.  Hence, regardless of what the YANG module states, their real status is that they are deprecated since they won't necessarily be present in all servers that implement the module. However, I do get Juergen's point about clarity.  Given the lengthy regex discussion, I suspect others may not agree, but this part could potentially be solved via YANG Author Guidelines.  I.e. something roughly along the lines of "If a node is marked as deprecated/obsolete in a YANG module then all descendant nodes SHOULD also be explicitly marked as deprecated/obsolete". Thanks, Rob On 06/09/2017 07:57, Juergen Schoenwaelder wrote: > On Wed, Sep 06, 2017 at 01:47:57AM +0000, heasley wrote: >> Isn't this something that is fixed with display (human representation) >> tools? >> > I often work with the original definitions. And if the original > definitions depend on context, I have to do another lookup (whether > this is inside the original definition or some tool generated human > representation does not matter). With the old /foo and /foo-state > approach this was really bad since you had often objects with the same > name and it was often not at all clear whether I have been looking at > the config true or the config false definition without an additional > search operation. Perhaps I could program my favourite editor to > generate explicit config statements and status statements on the fly > but I think we would be better off if readers would not have to > program editors or use special tools to easily understand what a > definition really means. > >>>> I still don't know what it means to define hierarchical data and say the >>>> parent is deprecated but not the descendant nodes. >>> It is odd but can happen anyway. A current augmentation of something >>> that got deprecated likely stays current. I would hope that tools warn >>> if they see this but that's it. >> How is anything ever expunged if parsing tools do not refuse to load >> a module that depends on a deprecated node that it is attempting to >> augment? > Expunged? Deprecating a definition does not expunge anything. Tools > that refuse to load a module that depends on deprecated nodes are in > my view broken. It was one of YANG's design goals to support > augmentations such that definitions and be augmented by independent > organizations. Hence, we must face reality that it is impossible to > determine how many augmentations of a definition are out there and > hence it is impossible to have them all updated at the same time. > > /js > From nobody Wed Sep 6 02:41:48 2017 Return-Path: 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 AE68F132707 for ; Wed, 6 Sep 2017 02:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] 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 V8NJXOuhArdS for ; Wed, 6 Sep 2017 02:41:44 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 E5842132386 for ; Wed, 6 Sep 2017 02:41:43 -0700 (PDT) Received: from birdie109 (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 38D80623E2 for ; Wed, 6 Sep 2017 11:41:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1504690902; bh=kgFO7g4EQJPKj2aizXkDGXno5aDY979lcER79fXH7tQ=; h=From:To:Date; b=KkeiTG6zQYSy2mD1zcdDs6COCieF68TVwC5Vn94pqVcRFTTVr3S0hJ8e0MADrNiSM jWYdzF12GCbb4P6l2GxOkr8UYqv2fU5ZLei4VxX1FTIBW1brT8nGU1jZcglyurptMW byJuM5YSU7Q2eBIWVGC0tS4vEoD/6wBUhEZIC2sQ= Message-ID: <1504690934.3468.50.camel@nic.cz> From: Ladislav Lhotka To: netmod@ietf.org Date: Wed, 06 Sep 2017 11:42:14 +0200 In-Reply-To: <20170906.104936.1524498889327990684.mbj@tail-f.com> References: <20170906.085222.355333494940576314.mbj@tail-f.com> <20170906.104936.1524498889327990684.mbj@tail-f.com> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.5 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] 'status' statement needed on every node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 09:41:47 -0000 Martin Bjorklund píše v St 06. 09. 2017 v 10:49 +0200: > Radek KrejÄí wrote: > > Dne 6.9.2017 v 08:52 Martin Bjorklund napsal(a): > > > Andy Bierman wrote: > > > > On Tue, Sep 5, 2017 at 3:50 PM, Kent Watsen wrote: > > > > > > > > > > > > > > > > > > > > > I still don't know what it means to define hierarchical data and > > > > > > > say the > > > > > > > parent is deprecated but not the descendant nodes. > > > > > > > > > > > > It is odd but can happen anyway. A current augmentation of something > > > > > > that got deprecated likely stays current. I would hope that tools > > > > > > warn > > > > > > if they see this but that's it. > > > > > > > > > > This example seems to provide support for saying status should be > > > > > inherited. But, to be clear, you agree that if a parent is > > > > > deprecated, > > > > > than its decedents should be deprecated as well, right? > > > > > > > > > > > > > > > > > > > > > > > right -- the RFC says this has to be done manually. > > > > A missing status-stmt means status=current. > > > > > > > > > > > > > > > > > > > This is rather non-intuitive, as is the idea that all descendant > > > > > > > nodes need to be manually edited (status is not inherited). > > > > > > > > > > > > Not a big deal. The benefit is that a reader like me knows clear > > > > > > that > > > > > > the definition I am look at is deprecated, no need to search > > > > > > backwards > > > > > > to find out. > > > > > > > > > > tree diagrams do this too, though I like Martin's approach of removing > > > > > the deprecated -state trees from the tree diagram altogether. > > > > > > > > > > > > > > > > > > > > > > It also means the objects expanded from groupings cannot ever be > > > > > > > changed (clearly a bug in YANG). > > > > > > > > > > > > Yes, bug in YANG. > > > > > > > > > > Is this the same issue I raised? > > > > > > > > > > import ietf-foo { > > > > > prefix f; > > > > > } > > > > > > > > > > container bar { > > > > > uses f:foo; > > > > > } > > > > > > > > > > container baz { > > > > > status deprecated; > > > > > uses f:foo; <-- oops, descendants not deprecated! > > > > > } (not a problem if status inherited) > > > > > > As Andy explains below, this should be: > > > > > > container baz { > > > status deprecated; > > > uses f:foo { > > > status deprecated; > > > } > > > } > > > > despite I see this explanation of status in uses as useful, I don't > > see anything in RFC that would support this. > > I'm just saying that also "uses" can, and should be in this case, > marked as deprecated. But it also affect augments, and the author of the module where something is being deprecated may not have access to the augmenting module. Lada > > > > > According to my interpretation of 7.21.2, this is a MUST NOT: > > > > > > > > If a definition is "current", it MUST NOT reference a "deprecated" or > > > > "obsolete" definition within the same module. > > > > > > > > If a definition is "deprecated", it MUST NOT reference an "obsolete" > > > > definition within the same module. > > > > > > > > For example, the following is illegal: > > > > > > > > typedef my-type { > > > > status deprecated; > > > > type int32; > > > > } > > > > > > > > leaf my-leaf { > > > > status current; > > > > type my-type; // illegal, since my-type is deprecated > > > > } > > > > > > > > The term "reference" is not really defined above. > > > > It should also clearly apply to "uses" (e.g., your example) and leafref > > > > path-stmt. > > > > > > > > leaf foo { > > > > type string; > > > > status deprecated; > > > > } > > > > > > > > leaf bar { > > > > type leafref { path /foo; } > > > > } > > > > > > > > If it apples to path-stmt, then why not all XPath? > > > > > > B/c in XPath it is even ok to refer to non-existing nodes. And you > > > might have things like /baz/*. > > > > > > > Why doesn't "reference" include descendant nodes? > > > > > > > > The text in 7950 is too strict and can cause a massive ripple-effect > > > > when > > > > any status-stmt is changed. > > > > At the same time it is too vague to be useful to implementors. > > > > > > While I agree that it is not clear what it means to have a "current" > > > child to a "deprecated" node, I don't think this is a big issue. If a > > > node is deprecated, it is ok for an implementation to not implement > > > it. Obviously this means that no child nodes to that node is > > > implemented either, regardless of their status, if they are augmented > > > in, or comes from a grouping. > > > > what about the mandatory nodes inside a deprecated container? > > Formally, they are not deprecated (default status is current) so > > still mandatory, right? > > mandatory or not doesn't matter; mandatory doesn't mean "must > implement", but "must exist if the parent exists". > > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Sep 6 03:15:31 2017 Return-Path: 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 6636F13239A for ; Wed, 6 Sep 2017 03:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3] 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 2rVegBr2dAXY for ; Wed, 6 Sep 2017 03:15:27 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) (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 F16851270AB for ; Wed, 6 Sep 2017 03:15:26 -0700 (PDT) Received: from pckrejci.nat9.vcit.vutbr.net (unknown [IPv6:2001:67c:1220:80c:d0:552c:73a5:18da]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id 620F640005D; Wed, 6 Sep 2017 12:15:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1504692923; bh=dRbZEWuTPbL8llT7P86x/QEOHi8mPURKOoYtYK9ZUq4=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=BeIHFpMO9VcjqSAH3lr2l2HqvduuAJryp92YBVw3S07KFrFNfcZ8i1xjJCuhWcDrP H3L2A+pgzAXIaMI1CzTEx/2GiWd8crQT8l5LTLn1qFBr3TBeFr1CxVFD3OHcZJKZki kuq2gc7R8byjvQDgMJLAZNvVvKu3hBW465V9x3SA= To: Martin Bjorklund Cc: andy@yumaworks.com, netmod@ietf.org References: <20170906.085222.355333494940576314.mbj@tail-f.com> <20170906.104936.1524498889327990684.mbj@tail-f.com> From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= Message-ID: <4678e7c0-c72b-a3d3-2161-213d9ad0b37f@cesnet.cz> Date: Wed, 6 Sep 2017 12:15:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170906.104936.1524498889327990684.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [netmod] 'status' statement needed on every node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 10:15:29 -0000 Dne 6.9.2017 v 10:49 Martin Bjorklund napsal(a): > Radek Krej=C4=8D=C3=AD wrote: >> Dne 6.9.2017 v 08:52 Martin Bjorklund napsal(a): >>> Andy Bierman wrote: >>>> On Tue, Sep 5, 2017 at 3:50 PM, Kent Watsen wr= ote: >>>> >>>>> >>>>>>> I still don't know what it means to define hierarchical data and = say the >>>>>>> parent is deprecated but not the descendant nodes. >>>>>> It is odd but can happen anyway. A current augmentation of somethi= ng >>>>>> that got deprecated likely stays current. I would hope that tools = warn >>>>>> if they see this but that's it. >>>>> This example seems to provide support for saying status should be >>>>> inherited. But, to be clear, you agree that if a parent is depreca= ted, >>>>> than its decedents should be deprecated as well, right? >>>>> >>>>> >>>>> >>>> right -- the RFC says this has to be done manually. >>>> A missing status-stmt means status=3Dcurrent. >>>> >>>> >>>> >>>>>>> This is rather non-intuitive, as is the idea that all descendant >>>>>>> nodes need to be manually edited (status is not inherited). >>>>>> Not a big deal. The benefit is that a reader like me knows clear t= hat >>>>>> the definition I am look at is deprecated, no need to search backw= ards >>>>>> to find out. >>>>> tree diagrams do this too, though I like Martin's approach of remov= ing >>>>> the deprecated -state trees from the tree diagram altogether. >>>>> >>>>> >>>>> >>>>>>> It also means the objects expanded from groupings cannot ever be >>>>>>> changed (clearly a bug in YANG). >>>>>> Yes, bug in YANG. >>>>> Is this the same issue I raised? >>>>> >>>>> import ietf-foo { >>>>> prefix f; >>>>> } >>>>> >>>>> container bar { >>>>> uses f:foo; >>>>> } >>>>> >>>>> container baz { >>>>> status deprecated; >>>>> uses f:foo; <-- oops, descendants not deprecated! >>>>> } (not a problem if status inherited) >>> As Andy explains below, this should be: >>> >>> container baz { >>> status deprecated; >>> uses f:foo { >>> status deprecated; >>> } >>> } >> despite I see this explanation of status in uses as useful, I don't >> see anything in RFC that would support this. > I'm just saying that also "uses" can, and should be in this case, > marked as deprecated. > >>>> According to my interpretation of 7.21.2, this is a MUST NOT: >>>> >>>> If a definition is "current", it MUST NOT reference a "deprecated= " or >>>> "obsolete" definition within the same module. >>>> >>>> If a definition is "deprecated", it MUST NOT reference an "obsole= te" >>>> definition within the same module. >>>> >>>> For example, the following is illegal: >>>> >>>> typedef my-type { >>>> status deprecated; >>>> type int32; >>>> } >>>> >>>> leaf my-leaf { >>>> status current; >>>> type my-type; // illegal, since my-type is deprecated >>>> } >>>> >>>> The term "reference" is not really defined above. >>>> It should also clearly apply to "uses" (e.g., your example) and lea= fref >>>> path-stmt. >>>> >>>> leaf foo { >>>> type string; >>>> status deprecated; >>>> } >>>> >>>> leaf bar { >>>> type leafref { path /foo; } >>>> } >>>> >>>> If it apples to path-stmt, then why not all XPath? >>> B/c in XPath it is even ok to refer to non-existing nodes. And you >>> might have things like /baz/*. >>> >>>> Why doesn't "reference" include descendant nodes? >>>> >>>> The text in 7950 is too strict and can cause a massive ripple-effect= when >>>> any status-stmt is changed. >>>> At the same time it is too vague to be useful to implementors. >>> While I agree that it is not clear what it means to have a "current" >>> child to a "deprecated" node, I don't think this is a big issue. If = a >>> node is deprecated, it is ok for an implementation to not implement >>> it. Obviously this means that no child nodes to that node is >>> implemented either, regardless of their status, if they are augmented= >>> in, or comes from a grouping. >> what about the mandatory nodes inside a deprecated container? >> Formally, they are not deprecated (default status is current) so >> still mandatory, right? > mandatory or not doesn't matter; mandatory doesn't mean "must > implement", but "must exist if the parent exists". > that's not true in case of non-presence containers: container x { =C2=A0 status deprecated; =C2=A0 leaf foo { =C2=A0=C2=A0=C2=A0 type string; =C2=A0=C2=A0=C2=A0 mandatory true; =C2=A0 } } or with groupings: grouping g { =C2=A0 leaf foo { =C2=A0=C2=A0=C2=A0 type string; =C2=A0=C2=A0=C2=A0 mandatory true; =C2=A0 } } container x { =C2=A0 status deprecated; =C2=A0 uses pre:g; } =C2=A0=C2=A0=C2=A0 Radek From nobody Wed Sep 6 04:10:12 2017 Return-Path: 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 7FA121321AC for ; Wed, 6 Sep 2017 04:10:11 -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 pIx10wxsULUi for ; Wed, 6 Sep 2017 04:10:09 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5182113202D for ; Wed, 6 Sep 2017 04:10:09 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 2B6C8F37; Wed, 6 Sep 2017 13:10:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id naVroqcjjt00; Wed, 6 Sep 2017 13:10:07 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 6 Sep 2017 13:10:08 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0B047200E2; Wed, 6 Sep 2017 13:10:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id VcejtwPLMQJg; Wed, 6 Sep 2017 13:10:07 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B43E0200E0; Wed, 6 Sep 2017 13:10:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 864DB40973AD; Wed, 6 Sep 2017 13:10:07 +0200 (CEST) Date: Wed, 6 Sep 2017 13:10:07 +0200 From: Juergen Schoenwaelder To: Robert Wilton Cc: netmod@ietf.org Message-ID: <20170906111007.ordythmm4i2t5gr7@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Robert Wilton , netmod@ietf.org References: <20170905190151.fizr5dljufbyuyty@elstar.local> <20170906014757.GD31035@shrubbery.net> <20170906065723.dnv4xl2mchszcvlo@elstar.local> <478d00da-2cdf-b416-c0e5-cbba29c9ed43@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <478d00da-2cdf-b416-c0e5-cbba29c9ed43@cisco.com> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [netmod] 'status' statement needed on every node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 11:10:11 -0000 On Wed, Sep 06, 2017 at 10:34:33AM +0100, Robert Wilton wrote: > I would prefer if it status was inherited (as an errata to 6020, 7950). Erratas are not a tool to change a specification. You have to write and RFC that updates 6020 and 7950 in order to change what these RFCs say. This requires full WG / IETF consensus since the change affects implementations. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Sep 6 04:31:52 2017 Return-Path: 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 29D91132707 for ; Wed, 6 Sep 2017 04:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] 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 874LJ3qBJ8IX for ; Wed, 6 Sep 2017 04:31:48 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 39ACC132351 for ; Wed, 6 Sep 2017 04:31:48 -0700 (PDT) Received: from birdie109 (unknown [IPv6:2001:1488:fffe:6:209d:b6ff:fe02:f314]) by mail.nic.cz (Postfix) with ESMTPSA id BC4E1616D0 for ; Wed, 6 Sep 2017 13:31:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1504697506; bh=3uf/xu20wYnZuciq2IsbnYxoQzePClmC3Rs1MsIrxkY=; h=From:To:Date; b=eZ90IQNM46A4YyTDE6mwDu+DYpbtg3yPAn6qKH7D6b34Y/x4lHJl8f+u+fvkGUE45 Y3vc6gb9aD5ydJgk0hUFwUqivzMClCVraNdPbqn/vOr+kgyP58YmU5QZ6OeWoRmqrr W3yhWsC2ssasmijNl1o93UOd/YkcvUQncWXZz/tw= Message-ID: <1504697539.3468.64.camel@nic.cz> From: Ladislav Lhotka To: netmod@ietf.org Date: Wed, 06 Sep 2017 13:32:19 +0200 In-Reply-To: <20170906111007.ordythmm4i2t5gr7@elstar.local> References: <20170905190151.fizr5dljufbyuyty@elstar.local> <20170906014757.GD31035@shrubbery.net> <20170906065723.dnv4xl2mchszcvlo@elstar.local> <478d00da-2cdf-b416-c0e5-cbba29c9ed43@cisco.com> <20170906111007.ordythmm4i2t5gr7@elstar.local> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.5 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] 'status' statement needed on every node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 11:31:50 -0000 Juergen Schoenwaelder píše v St 06. 09. 2017 v 13:10 +0200: > On Wed, Sep 06, 2017 at 10:34:33AM +0100, Robert Wilton wrote: > > > I would prefer if it status was inherited (as an errata to 6020, 7950). > > Erratas are not a tool to change a specification. You have to write > and RFC that updates 6020 and 7950 in order to change what these RFCs > say. This requires full WG / IETF consensus since the change affects > implementations. A current node with a deprecated ancestor doesn't make sense, so it looks like an omission. IMO, a technical erratum is then appropriate. Regarding the documentation needs, 6087bis could recommend not to rely completely on the inheritance of deprecated status, and put it to other places for documentation purposes (using common sense). Lada > > /js > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Sep 6 06:11:56 2017 Return-Path: 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 2D1BE132F38; Wed, 6 Sep 2017 06:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 AljkZvJXXEP7; Wed, 6 Sep 2017 06:11:53 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0112.outbound.protection.outlook.com [104.47.37.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE3F1132F37; Wed, 6 Sep 2017 06:11:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TiVZ80eN8PyHyG/NDG8ThGrJa6jlyy+zqMSH6VAjWP0=; b=cqqAk+IYvdqqIWe5mo1PfsYmwSVaxcEaFWWkj7AMJKxaY0djEUIKOu/6tyLvjgNgh+a7KRtKtNIL6HSZyCKwBRYPLNu1Jt9zlCqKakDup+SoQkOeMb9rFTTBoyzcrGDkJuLLSdl5RmS8Lu2MmicIyVQDW03RkVWgx+wTswGW8a0= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1250.namprd05.prod.outlook.com (10.160.183.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.3; Wed, 6 Sep 2017 13:11:51 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.20.0035.010; Wed, 6 Sep 2017 13:11:51 +0000 From: Kent Watsen To: Martin Bjorklund , "andy@yumaworks.com" CC: "bclaise@cisco.com" , "netconf-chairs@ietf.org" , "netmod@ietf.org" Thread-Topic: [netmod] upcoming adoptions Thread-Index: AQHTISEQvmg9jr+3gUCv+5ltP9XhHqKl6moAgAANOICAAP0JAIAAf2MAgAAqCYA= Date: Wed, 6 Sep 2017 13:11:51 +0000 Message-ID: <38E666E2-EECE-4554-9A55-B98D829EB4CA@juniper.net> References: <3620aafe-bc72-cc54-9dbd-b687a0178df2@cisco.com> <20170905.095949.1829098658779783521.mbj@tail-f.com> <20170906.084124.2282926097915349446.mbj@tail-f.com> In-Reply-To: <20170906.084124.2282926097915349446.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.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1250; 6:kTIQONpC23Hg7n+F90H3es7Na6viDLTVzvOE+ijg0uz85WBIGgAxGMrGUkziUr+HLBT3Dl8OA2jrFHg76jS7ECCa0UC/bzbO52Ms63ka7zGnCOVjZvjT4+LeOl641wibFXPRjfcGPWjqby0+0jJMGJ8dYbhbquDlhlBIbcoDGvkPqRFpDHF96lwwVAUD70lgi41vgWY6QiUn9/5/jZS3h8WmXEFQMC+Qfu9qCyYHzjxNku9j+lvPa8UMLcU+Av7kPqy842P2jSXKYYpl8+Prr1pheZqNjEJClt/q/joNERuG77ggssbt4i/OriRhK0MLUdZOhi0OVXlPHf7Rb9EDRQ==; 5:l7M3SaTWcDeBdOIODH2uld8ZQ0U+450SbfVNr+xNVQNcKrgISapLq+96PE7SlfyY3J8Nyi6TqjvmUCVsoNfCH1Ftz9iPpWc7lOUGuleQ91LZ04/FyqScNKPlMgwAjEPMqstdZ3oSBIJEOQlv3Q20MQ==; 24:MAr9FHSKPUVVC6ealGCassnxoDrSmz/22AGoizvCkHhxcfMylnen0ILbxVP9cJoaWJRMYGal/kk929IbV9+fYK0pMfr7q5kiQ9jc2bhdMik=; 7:PLYn1nkHggKaD9bVl+dYA/RWo7r260LF0eU6yCM/uRAY61xYQo+P+WCNn9oE6ztkoBqj8s0CYEoDgAwIys8ugMJwCgtLL4afUscONEfO0rhK6uEa8ogFBq1GwcDVXHvDEatj1wXcGvJ1RRJFgxmvu0QwTpcaBXkgBKgO2qAOOsFrnqZQqzcPOjhIODwtnKJK2PFCMcijbpQTcAOGucZuuyReIk06yqLnV+C+uQxyfK4= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9b49feeb-af66-41c0-c933-08d4f528d6d2 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1250; x-ms-traffictypediagnostic: BN3PR0501MB1250: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123555025)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1250; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1250; x-forefront-prvs: 0422860ED4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(199003)(189002)(25786009)(2900100001)(82746002)(53936002)(6512007)(99286003)(54906002)(4326008)(6436002)(6486002)(77096006)(229853002)(6246003)(2950100002)(6506006)(3660700001)(86362001)(83716003)(50986999)(101416001)(93886005)(68736007)(54356999)(3280700002)(76176999)(83506001)(478600001)(6116002)(102836003)(5660300001)(14454004)(105586002)(106356001)(7736002)(305945005)(81166006)(81156014)(97736004)(189998001)(2501003)(8936002)(3846002)(2906002)(36756003)(8676002)(66066001)(33656002)(4001350100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1250; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Sep 2017 13:11:51.6467 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1250 Archived-At: Subject: Re: [netmod] upcoming adoptions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 13:11:55 -0000 Pj4gSSBndWVzcyB0aGUgTk1EQSB0cmFuc2l0aW9uIHBsYW4gdG8gbW92ZSB0aGUgY2hpbGQgbm9k ZXMgdG8gYSBjb25maWc9dHJ1ZQ0KPj4gbm9kZQ0KPj4gbmFtZSAvcmVzdGNvbmYgdGhhdCBoYXMg b25seSBjb25maWc9ZmFsc2Ugbm9kZXMgaW4gaXQuICBUaGlzIHNlZW1zIHF1aXRlDQo+PiBkaXNy dXB0aXZlDQo+PiBhbmQgbm90IGEgcHJvZHVjdGl2ZSB1c2Ugb2YgZW5naW5lZXJpbmcgcmVzb3Vy Y2VzLCBvciBzdXBwb3J0IGFuZCBjdXN0b21lcg0KPj4gcmUtdHJhaW5pbmcuDQo+DQo+IEkgYWdy ZWUgd2l0aCB5b3UuICBXZSd2ZSBzYWlkIHRoYXQgaXQgaXMgb2sgdG8gaGF2ZSBwdXJlIGNvbmZp ZyBmYWxzZQ0KPiB0cmVlcywgaWYgaXQgbWFrZXMgc2Vuc2UgZm9yIHdoYXQgd2UncmUgdHJ5aW5n IHRvIG1vZGVsLg0KPg0KPiBUaGUgb25seSAiaXNzdWUiIHdpdGggdGhlIHRyZWUgYWJvdmUgaXMg dGhhdCBpdHMgdG9wLWxldmVsIG5vZGUncyBuYW1lDQo+IGNvbnRhaW5zIHRoZSB3b3JkICJzdGF0 ZSIuDQoNCi9uZXRjb25mLXN0YXRlIGFuZCAvcmVzdGNvbmYtc3RhdGUgZG9uJ3Qgc2VlbSB0byBm b2xsb3cgdGhlIGdlbmVyYWwgDQpwYXR0ZXJuIHdlJ3JlIGNvcnJlY3Rpbmcgd2l0aCB0aGUgdmFy aW91cyBOTURBIHVwZGF0ZXMuICBQYXJ0aWN1bGFybHksDQp0aGVzZSAtc3RhdGUgdHJlZXMgYXJl IE5PVCBmb3IgdGhlIHB1cnBvc2UgdG8gcHJvdmlkaW5nIHRoZSBvcHN0YXRlDQp2YWx1ZSBmb3Ig Y29uZmlndXJlZCBub2Rlcy4gIFRoZXNlIG1vZHVsZXMgaGF2ZSB0aGUgbWlzZm9ydHVuZSBvZg0K aGF2aW5nICItc3RhdGUiIGluIHRoZWlyIG5hbWUsIGJ1dCB0aGV5J3JlIG90aGVyd2lzZSBmaW5l Lg0KDQpLLiAgLy8gY29udHJpYnV0b3INCg0KDQoNCg== From nobody Wed Sep 6 06:53:53 2017 Return-Path: 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 38865132FD9 for ; Wed, 6 Sep 2017 06:53:51 -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 JDtdk9wGMkIu for ; Wed, 6 Sep 2017 06:53:49 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9DA4132A0D for ; Wed, 6 Sep 2017 06:53:11 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 8C9AF34; Wed, 6 Sep 2017 15:53:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id uJ-91zmNReSK; Wed, 6 Sep 2017 15:53:09 +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 atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 6 Sep 2017 15:53:10 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6E420200E2; Wed, 6 Sep 2017 15:53:10 +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 Az5FcloeMEq3; Wed, 6 Sep 2017 15:53:10 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 04D10200E0; Wed, 6 Sep 2017 15:53:10 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DA1824097823; Wed, 6 Sep 2017 15:53:09 +0200 (CEST) Date: Wed, 6 Sep 2017 15:53:09 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Cc: netmod@ietf.org Message-ID: <20170906135309.kizcrymtgacwwuau@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: <20170905190151.fizr5dljufbyuyty@elstar.local> <20170906014757.GD31035@shrubbery.net> <20170906065723.dnv4xl2mchszcvlo@elstar.local> <478d00da-2cdf-b416-c0e5-cbba29c9ed43@cisco.com> <20170906111007.ordythmm4i2t5gr7@elstar.local> <1504697539.3468.64.camel@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <1504697539.3468.64.camel@nic.cz> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [netmod] 'status' statement needed on every node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 13:53:51 -0000 On Wed, Sep 06, 2017 at 01:32:19PM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder píše v St 06. 09. 2017 v 13:10 +0200: > > On Wed, Sep 06, 2017 at 10:34:33AM +0100, Robert Wilton wrote: > > > > > I would prefer if it status was inherited (as an errata to 6020, 7950). > > > > Erratas are not a tool to change a specification. You have to write > > and RFC that updates 6020 and 7950 in order to change what these RFCs > > say. This requires full WG / IETF consensus since the change affects > > implementations. > > A current node with a deprecated ancestor doesn't make sense, so it > looks like an omission. IMO, a technical erratum is then > appropriate. You can make status work recursively via an erratum. It clearly does not work recursively in the YANG specifications. And as explain before, given that we have augmentations, current definitions below deprecated definitions cannot be avoided. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Sep 6 08:24:52 2017 Return-Path: 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 DC81C132EA2 for ; Wed, 6 Sep 2017 08:24:50 -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 reQw2sOdXN5j for ; Wed, 6 Sep 2017 08:24:49 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 820CA132E28 for ; Wed, 6 Sep 2017 08:24:49 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id y123so24479216iod.0 for ; Wed, 06 Sep 2017 08:24: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=RqSBWrtP44OjdwOGvap2XXQpspInXnNZwTlyzGz2XgM=; b=Pk0yRYUnLxn8TevElfWIHPosIQ3qSLMSmqO+NV+zA283MT03BBePUSE5zUlws51dE4 Uf6lx8c92tHj9Mvc5XRccGvqSOjAx8QwKLA+xidh1jBpbMlta5uFOL8bUllGiNwjrlV0 OV8Wb76z1BIV4I3Bo897kBM78effLXI1u18+jwK91BNtPudI+UmztUMLR3B6tL08Jnmy YWNy77ccizAC/hZ4OzFzzOe0VlQCNYV8u1N87AADqD+if+Dux5wj189KpYXNHQHGH1Fv WeZpODCT97ZrIdsap0wfZEe7rpO8c4lJwR7umNXy445VLW5gWT4WUk67EsnPN1K4Vz3r UAOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RqSBWrtP44OjdwOGvap2XXQpspInXnNZwTlyzGz2XgM=; b=iYZN+v7UTMRQKpPGkRi6DieVlBUaoQAmTkXKuFa/2YiCcwocfjeEnZQIGpmF9yPoTL 5i1XTBfoXmK6hzcDG8/WCo0l54PwK9xgVrlk0reH7ZpJJ3CvHiI0H8494B36ZLCmm6VG GnOFkO4jOV6UICRdisLcuBfW7czMeWs4GYbdmwgi9LS8Tk5p/ucXjwzmh6WFcnhVMT6Y 2MwovdtNDPWG+AYB0FaIuAQ9wIceWJPQnp5dM1x42gNbybivfyEWR+layVj99Ig56MU7 C1+tjHrslQiIFz6lVHXIjoR/G4XsmkZT5Fn4gB2qJQ9+fjGGA8zaFRpQPemEEKX7jed5 Rbsw== X-Gm-Message-State: AHPjjUhb2t6HccXpMe4xSLsjP1VEN4VKtY2/XZBi4MNBZW2q3LZ5xGxj KCxF59SpB9feoZ544NSLgYZW4Ex0QJAM X-Google-Smtp-Source: AOwi7QB5Va2dWkn2VbPCNQ9cCcHQN7MAHXjvW7Mvv8JO+SID7cIO7pKsvFJC0GRBVn8i/zqfolgnBmwS4I9eVc2VgvQ= X-Received: by 10.107.51.81 with SMTP id z78mr3302492ioz.146.1504711488748; Wed, 06 Sep 2017 08:24:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.6.206 with HTTP; Wed, 6 Sep 2017 08:24:48 -0700 (PDT) In-Reply-To: <38E666E2-EECE-4554-9A55-B98D829EB4CA@juniper.net> References: <3620aafe-bc72-cc54-9dbd-b687a0178df2@cisco.com> <20170905.095949.1829098658779783521.mbj@tail-f.com> <20170906.084124.2282926097915349446.mbj@tail-f.com> <38E666E2-EECE-4554-9A55-B98D829EB4CA@juniper.net> From: Andy Bierman Date: Wed, 6 Sep 2017 08:24:48 -0700 Message-ID: To: Kent Watsen Cc: Martin Bjorklund , "bclaise@cisco.com" , "netconf-chairs@ietf.org" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="001a11440c9cc6ff76055886f131" Archived-At: Subject: Re: [netmod] upcoming adoptions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 15:24:51 -0000 --001a11440c9cc6ff76055886f131 Content-Type: text/plain; charset="UTF-8" On Wed, Sep 6, 2017 at 6:11 AM, Kent Watsen wrote: > >> I guess the NMDA transition plan to move the child nodes to a > config=true > >> node > >> name /restconf that has only config=false nodes in it. This seems quite > >> disruptive > >> and not a productive use of engineering resources, or support and > customer > >> re-training. > > > > I agree with you. We've said that it is ok to have pure config false > > trees, if it makes sense for what we're trying to model. > > > > The only "issue" with the tree above is that its top-level node's name > > contains the word "state". > > /netconf-state and /restconf-state don't seem to follow the general > pattern we're correcting with the various NMDA updates. Particularly, > these -state trees are NOT for the purpose to providing the opstate > value for configured nodes. These modules have the misfortune of > having "-state" in their name, but they're otherwise fine. > > This contradicts some details we have been told about NMDA 1) the transition guidelines say otherwise New modules and modules that are not concerned with the operational state of configuration information SHOULD immediately be structured to be NMDA-compatible 2) RD defines operational state to include config=false nodes such as counters, so these modules are properly named. K. // contributor > > > > Andy --001a11440c9cc6ff76055886f131 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Sep 6, 2017 at 6:11 AM, Kent Watsen <kwatsen@juniper.net= > wrote:
>= ;> I guess the NMDA transition plan to move the child nodes to a config= =3Dtrue
>> node
>> name /restconf that has only config=3Dfalse nodes in it.=C2=A0 Thi= s seems quite
>> disruptive
>> and not a productive use of engineering resources, or support and = customer
>> re-training.
>
> I agree with you.=C2=A0 We've said that it is ok to have pure conf= ig false
> trees, if it makes sense for what we're trying to model.
>
> The only "issue" with the tree above is that its top-level n= ode's name
> contains the word "state".

/netconf-state and /restconf-state don't seem to follow the general
pattern we're correcting with the various NMDA updates.=C2=A0 Particula= rly,
these -state trees are NOT for the purpose to providing the opstate
value for configured nodes.=C2=A0 These modules have the misfortune of
having "-state" in their name, but they're otherwise fine.


This contradicts some d= etails we have been told about NMDA

1) the transit= ion guidelines say otherwise

New modules and = modules that are not concerned with the
operational state of conf= iguration information SHOULD
immediately be structured to be NMDA= -compatible


2) RD defines ope= rational state to include config=3Dfalse nodes such as counters,
= so these modules are properly named.



K.=C2=A0 // contributor




Andy

--001a11440c9cc6ff76055886f131-- From nobody Wed Sep 6 09:28:12 2017 Return-Path: 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 7CF1C132962 for ; Wed, 6 Sep 2017 09:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 tvn2F8WAkBES for ; Wed, 6 Sep 2017 09:28:09 -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 D863E13292A for ; Wed, 6 Sep 2017 09:28:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1475; q=dns/txt; s=iport; t=1504715289; x=1505924889; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=rvUuswsBbo6jBIIQYpBRSXXBYh3KM99wr6bq54KW0nY=; b=ABvV/FP1POEzmxQG+xFQUkrcawng0hmTHH0nvvx0TcAMe6KboIWVe4q9 nVUn72kilNBVx4+iblhqElPmVrUK0lRLqpaPGT0n/1NRwuqWgF4LzmUeS t4h0oR6cvuu+23A0qrK2cVMppq5m60fpq/lzbo+rFSb7RWfnslRwq3tiy c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CXAQBoIbBZ/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBiUqLFZBzCSKYOgqFPgKFARUBAgEBAQEBAQFrKIUZAQUjDwEFUQk?= =?us-ascii?q?CGAICJgICVxMIAQGKLZBSnWaCJ4tRAQEBBwImgQ2CHYNQgg4LgnKFQYJHgmEBB?= =?us-ascii?q?KB0izWJHItUhx2NV4dUgTk1IoENMiEIHBWHZT+LQAEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,484,1498521600"; d="scan'208";a="655461818" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Sep 2017 16:28:04 +0000 Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v86GS4CL015724 for ; Wed, 6 Sep 2017 16:28:04 GMT To: netmod@ietf.org References: <20170905190151.fizr5dljufbyuyty@elstar.local> <20170906014757.GD31035@shrubbery.net> <20170906065723.dnv4xl2mchszcvlo@elstar.local> <478d00da-2cdf-b416-c0e5-cbba29c9ed43@cisco.com> <20170906111007.ordythmm4i2t5gr7@elstar.local> <1504697539.3468.64.camel@nic.cz> <20170906135309.kizcrymtgacwwuau@elstar.local> From: Robert Wilton Message-ID: <718a1863-6840-7238-eeaf-0fe7bad831ff@cisco.com> Date: Wed, 6 Sep 2017 17:28:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170906135309.kizcrymtgacwwuau@elstar.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] 'status' statement needed on every node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 16:28:10 -0000 On 06/09/2017 14:53, Juergen Schoenwaelder wrote: > On Wed, Sep 06, 2017 at 01:32:19PM +0200, Ladislav Lhotka wrote: >> Juergen Schoenwaelder píše v St 06. 09. 2017 v 13:10 +0200: >>> On Wed, Sep 06, 2017 at 10:34:33AM +0100, Robert Wilton wrote: >>> >>>> I would prefer if it status was inherited (as an errata to 6020, 7950). >>> Erratas are not a tool to change a specification. You have to write >>> and RFC that updates 6020 and 7950 in order to change what these RFCs >>> say. This requires full WG / IETF consensus since the change affects >>> implementations. >> A current node with a deprecated ancestor doesn't make sense, so it >> looks like an omission. IMO, a technical erratum is then >> appropriate. > You can make status work recursively via an erratum. It clearly does > not work recursively in the YANG specifications. > > And as explain before, given that we have augmentations, current > definitions below deprecated definitions cannot be avoided. It seems like there are two different meanings (or interpretations) of what the "status" of a node is: The first is in the module definition, where the author of the YANG model indicates whether they think the definition is still current or not. The second is within a set of modules on a device, where the status of the node depends both on the YANG "status" statement for the given node, but also the actual status of the parent node. Thanks, Rob > > /js > From nobody Wed Sep 6 10:01:27 2017 Return-Path: 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 D96E0132199 for ; Wed, 6 Sep 2017 10:01:25 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGAdgbeOjn1B for ; Wed, 6 Sep 2017 10:01:23 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 725E4126DD9 for ; Wed, 6 Sep 2017 10:01:23 -0700 (PDT) Received: from cmgw4 (unknown [10.0.90.85]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 10A841E079F for ; Wed, 6 Sep 2017 11:01:19 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id 6H1F1w0162SSUrH01H1Jcf; Wed, 06 Sep 2017 11:01:19 -0600 X-Authority-Analysis: v=2.2 cv=G8xsK5s5 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=2JCJgTwv5E4A:10 a=AUd_NHdVAAAA:8 a=56UHFMiXxEOKVdtXrv8A:9 a=zKwG5hstDfRHNScl:21 a=4coidPkXTUeKCKLF:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:To:From:Sender:Reply-To:Cc: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=v4IWkn9HjXh6vMDPdHKupPXeyDtDIO3ey1p53PsJrdw=; b=nU93+GAjZK4ya7HWczBcVpXjbE IFpUl6CqepcJBtvx5e0XmaLdNJqb2xdNRUc1NrPP1meAhXz6pkK1AacExGsC2EVkMa1KhRw1HoPtF o/AvKwYitBJUKMJoR1wP5xYW/; Received: from [172.58.184.147] (port=29769 helo=[IPV6:2607:fb90:6515:1458:0:6:ab1e:ce01]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dpdhS-004BSo-RW; Wed, 06 Sep 2017 11:01:15 -0600 From: Lou Berger To: Robert Wilton , Ladislav Lhotka , Date: Wed, 06 Sep 2017 13:01:12 -0400 Message-ID: <15e58235480.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: References: <20170830102902.2n5q6rgq2x2dxfq2@elstar.local> <20170830123156.cssrg5kklpo67fie@elstar.local> <1504223854014.55228@Aviatnet.com> <847e5bf9-7b3d-9ff8-9954-970f32a2094c@cisco.com> <20170902073342.xoziwor4tdr5bipw@elstar.local> <20170902112832.ymorfgdthobeio6q@elstar.local> <1e95ba5d-7aa2-e08f-56f9-27aa70822a11@cisco.com> <1504537140.5874.38.camel@nic.cz> <1504629352.7175.40.camel@nic.cz> <8af6041d-7cd5-9608-70b4-7cffc4f884f8@cisco.com> <2a70ce5e-7727-d280-98e4-481d87314d14@labn.net> User-Agent: AquaMail/1.10.0-403 (build: 101000001) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 172.58.184.147 X-Exim-ID: 1dpdhS-004BSo-RW X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPV6:2607:fb90:6515:1458:0:6:ab1e:ce01]) [172.58.184.147]:29769 X-Source-Auth: lberger@labn.net X-Email-Count: 1 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 17:01:26 -0000 Thanks Rob. I'll get with Kent and then one of us will get back to the wg on next steps. Lou On September 6, 2017 3:53:33 AM Robert Wilton wrote: > Hi Lou, > > This is the addition to 6087bis that I propose.   Note, this is the same > text in my email on the 31st of August. > > I propose adding the following 2 paragraphs to 6087bis section on > pattern and ranges: > > NEW: > To ensure patterns are easy to read and implement, authors SHOULD > restrict themselves to the parts of the XML schema regular expression > language that are common across most regular expression languages.  In > particular, pattern statements SHOULD avoid using 'character class > subtraction' (e.g. '[a-z-[aeiou]]').  They SHOULD avoid matching > unicode properties and blocks (e.g. '\p{L} or \p{IsBasic_Latin}'). > They MAY use the '\d', '\w', '\s' character class shorthands and their > negated versions, where appropriate, but SHOULD avoid other character > class shorthands.  To match ASCII digits 0-9 the character class > '[0-9]' MUST be used instead of the '\d' character class shorthand > that matches Unicode digits in all scripts. > > Pattern statements do not have to strictly restrict numerical values, > and a simple less specific pattern may be preferable over a more > complex and precise pattern, e.g. as illustrated in the > 'ipv4-address-no-zone' example pattern below. > > > Or, put in context of the existing text 6087bis text: > > *** Patterns and Ranges > > For string data types, if a machine-readable pattern > can be defined for the desired semantics, then > one or more pattern statements SHOULD be present. > A single quoted string SHOULD be used to specify the pattern, > since a double-quoted string can modify the content. > > To ensure patterns are easy to read and implement, authors SHOULD > restrict themselves to the parts of the XML schema regular expression > language that are common across most regular expression languages.  In > particular, pattern statements SHOULD avoid using 'character class > subtraction' (e.g. '[a-z-[aeiou]]').  They SHOULD avoid matching > unicode properties and blocks (e.g. '\p{L} or \p{IsBasic_Latin}'). > They MAY use the '\d', '\w', '\s' character class shorthands and their > negated versions, where appropriate, but SHOULD avoid other character > class shorthands.  To match ASCII digits 0-9 the character class > '[0-9]' MUST be used instead of the '\d' character class shorthand > that also matches Unicode digits in all scripts. > > Pattern statements do not have to strictly restrict numerical values, > and a simple less specific pattern may be preferable over a more > complex and precise pattern, e.g. as illustrated in the > 'ipv4-address-no-zone' example pattern below. > > The following typedef from ^RFC6991^ demonstrates the proper > use of the "pattern" statement: > >     typedef ipv4-address-no-zone { >       type inet:ipv4-address { >         pattern '[0-9\.]*'; >       } >       ... >     } > > For string data types, if the length of the string > is required to be bounded in all implementations, > then a length statement MUST be present. > > The following typedef from ^RFC6991^ demonstrates the proper > use of the "length" statement: > >     typedef yang-identifier { >       type string { >         length "1..max"; >         pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*'; >         pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*'; >       } >       ... >     } > > For numeric data types, if the values allowed > by the intended semantics are different than > those allowed by the unbounded intrinsic data > type (e.g., 'int32'), then a range statement SHOULD be present. > > The following typedef from ^RFC6991^ demonstrates the proper > use of the "range" statement: > >     typedef dscp { >       type uint8 { >          range "0..63"; >       } >       ... >     } > > Thanks, > Rob > > > On 05/09/2017 22:37, Lou Berger wrote: >> Rob, >> >> (as chair) >> On 9/5/2017 1:17 PM, Robert Wilton wrote: >>> However, I have thrown in the towel on my regex crusade. >> I'm sorry, I've lost the thread here a bit. in order to guage consensus >> on this topic, it would be helpful to send the latest text that you are >> proposing for inclusion in the the bis.  If you are willing to do these, >> we can poll to see if there is/is not support for inclusion of this >> text.  Are you willing, i.e., can you send the current proposed text change? >> >> Thank you, >> Lou >> >> . >> > > From nobody Wed Sep 6 10:04:32 2017 Return-Path: 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 F0DFB13292A for ; Wed, 6 Sep 2017 10:04:30 -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 2lyerTl3dFmb for ; Wed, 6 Sep 2017 10:04:28 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F6C132199 for ; Wed, 6 Sep 2017 10:04:28 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id b142so6205444ioe.1 for ; Wed, 06 Sep 2017 10:04:28 -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=R4ILr0nIwnOdJ6nn4plWFMkd1wYadl4CkePcUibizfg=; b=RfHsF/cC1UkcZb61cc7/QmFai+XUZMRXjW9q6rKOqltwP+qUTXQgyY1U1JeprYcBqM v8qm40IBwgqz4ng6r7cibpA6g0etWocSWiTXp9JJWCm0d7z0wkfYRBmspHaxFFxmzvGj BynFc0UG+A5ox7K8lOyP/3HF8Eqh51qaBhJ+VuDX9o+ZwOmSfLgsvrkcxXCLap39L+jq gWDJM8Plxlw1+X5mSE4WmXd/sqFY82FfhyVR3KtEf9Vzvr2cZ3WGnyklSdmWj/Bz+E4G CKzsm6WG2URO0wO+UgCyf5uSoOzOHG+rroprmeZ/Qj6hVsLoNQmQhSMCxDVxSbyNQrt6 DfBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=R4ILr0nIwnOdJ6nn4plWFMkd1wYadl4CkePcUibizfg=; b=f+TzGOvsjVJuBbfMaI6r4sWdXg6GDUQPsVCEklUGa/OOXV8ooQKaTTmGm7z2rE+Pyf Cx7Qt5Ih7bTMkh6y4mh7IsAUqy6zb0pfKdAhb7xy+7GfsVMx0BHBJbMMrdKEGT0IUIVf J4F2quaDFRKN9kdqygtD+aB+7S3Dt+ZPBnsaFeBAsk9shrF9mxQBfDwMFa08vzYhQt58 DvTsAWbfG50VsO766rkZisLX4Aa0Saiy9jHXX9kl1qcRKv/pYwQ6ZUwo2VBsu7CduDxN 1+k/3KZQIQirD+Rk/S1+8sHnxf1Co4ZC4amnswTx6eN++aQp+a3CUeoCG0EJnhzSHRzD vjSg== X-Gm-Message-State: AHPjjUhZp0jBPGnjwCq+qCMDvUzDvg8ywCidnZOhZ/2ts/bkYVzWK7Ym vcoi12o6XD1E0IvmEFca43kgChrtiS7k X-Google-Smtp-Source: AOwi7QDNEgPXrVgr6HQFXY/AMVqX1LuP/urv15re/QfAZcCBt+VTh52seyBgGw47N3AMjUfLtyl3nobegkiGD3sa3wM= X-Received: by 10.107.32.205 with SMTP id g196mr3493002iog.349.1504717467662; Wed, 06 Sep 2017 10:04:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.6.206 with HTTP; Wed, 6 Sep 2017 10:04:26 -0700 (PDT) In-Reply-To: <20170906.085421.399708327964847720.mbj@tail-f.com> References: <20170905190151.fizr5dljufbyuyty@elstar.local> <20170906064440.4br5kjna6toeqzlo@elstar.local> <20170906.085421.399708327964847720.mbj@tail-f.com> From: Andy Bierman Date: Wed, 6 Sep 2017 10:04:26 -0700 Message-ID: To: Martin Bjorklund Cc: Juergen Schoenwaelder , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="001a1140be0e260264055888569a" Archived-At: Subject: Re: [netmod] 'status' statement needed on every node X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 17:04:31 -0000 --001a1140be0e260264055888569a Content-Type: text/plain; charset="UTF-8" On Tue, Sep 5, 2017 at 11:54 PM, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Tue, Sep 05, 2017 at 10:50:03PM +0000, Kent Watsen wrote: > > > > > > > > > > > > >> I still don't know what it means to define hierarchical data and > say the > > > >> parent is deprecated but not the descendant nodes. > > > > > > > > It is odd but can happen anyway. A current augmentation of something > > > > that got deprecated likely stays current. I would hope that tools > warn > > > > if they see this but that's it. > > > > > > This example seems to provide support for saying status should be > > > inherited. > > > > No, I do not support your conclusion. I think it is crucial that > > whoever maintains an augmenting module is actually aware that his > > module depends on something deprecated. Silently deprecating (and > > eventually obsoleting) definitions maintained by other parties is in > > my view not a good idea. It is far better to clearly indicate that > > there is some work to do by the augmenting module maintainer. > > > > > But, to be clear, you agree that if a parent is deprecated, > > > than its decedents should be deprecated as well, right? > > > > Yes. > > > > > >> This is rather non-intuitive, as is the idea that all descendant > > > >> nodes need to be manually edited (status is not inherited). > > > > > > > > Not a big deal. The benefit is that a reader like me knows clear that > > > > the definition I am look at is deprecated, no need to search > backwards > > > > to find out. > > > > > > tree diagrams do this too, though I like Martin's approach of removing > > > the deprecated -state trees from the tree diagram altogether. > > > > > > > > > > > > >> It also means the objects expanded from groupings cannot ever be > > > >> changed (clearly a bug in YANG). > > > > > > > > Yes, bug in YANG. > > > > > > Is this the same issue I raised? > > > > > > import ietf-foo { > > > prefix f; > > > } > > > > > > container bar { > > > uses f:foo; > > > } > > > > > > container baz { > > > status deprecated; > > > uses f:foo; <-- oops, descendants not deprecated! > > > } (not a problem if status inherited) > > > > I think I look at this very differently. If something is defined in > > f:foo that is current, then this is inherited where f:foo is > > used. What we need is a way to refine that if the usage context has > > differnet requirements, like we allow to refine other properties of a > > grouping to adapt it to the usage context. > > I think that marking the uses statement with status deprecated should > mean that all nodes in the grouping are "auto-refined" with status > deprecated. Listing them all in explciit refine doesn't help > anyone imo. > > Lifecycle status of abstract definitions (identity, typedef, grouping) should only be changed it applies to all possible usage of the definition. Modules that use these external definitions should only override the deprecated or obsolete status with extreme caution. The uses-stmt should not even have a status-stmt since conformance is only for the conceptual grouping expansion, not for the grouping or the uses statements. The only useful interpretation is that it applies to actual data nodes (after all nested groupings have been expanded). I would refine your "auto-refine" a bit :-) It does not increase the status enum, just lower it to the uses-stmt status value uses(current) -> do not convert any status during expansion uses(deprecated) --> convert current to deprecated; leave obsolete unchanged uses(obsolete) --> convert current and deprecated to obsolete There is still no ability to say that an expanded data node is deprecated, e.g., deprecate some but not all of the nodes from the uses expansion. > /martin > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a1140be0e260264055888569a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Sep 5, 2017 at 11:54 PM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Juergen Schoenwaelder <= j.schoenwaelder@jac= obs-university.de> wrote:
> On Tue, Sep 05, 2017 at 10:50:03PM +0000, Kent Watsen wrote:
> >
> >
> >
> > >> I still don't know what it means to define hierarchi= cal data and say the
> > >> parent is deprecated but not the descendant nodes.
> > >
> > > It is odd but can happen anyway. A current augmentation of s= omething
> > > that got deprecated likely stays current. I would hope that = tools warn
> > > if they see this but that's it.
> >
> > This example seems to provide support for saying status should be=
> > inherited.
>
> No, I do not support your conclusion. I think it is crucial that
> whoever maintains an augmenting module is actually aware that his
> module depends on something deprecated. Silently deprecating (and
> eventually obsoleting) definitions maintained by other parties is in > my view not a good idea. It is far better to clearly indicate that
> there is some work to do by the augmenting module maintainer.
>
> > But, to be clear, you agree that if a parent is deprecated,
> > than its decedents should be deprecated as well, right?
>
> Yes.
>
> > >> This is rather non-intuitive, as is the idea that all de= scendant
> > >> nodes need to be manually edited (status is not inherite= d).
> > >
> > > Not a big deal. The benefit is that a reader like me knows c= lear that
> > > the definition I am look at is deprecated, no need to search= backwards
> > > to find out.
> >
> > tree diagrams do this too, though I like Martin's approach of= removing
> > the deprecated -state trees from the tree diagram altogether.
> >
> >
> >
> > >> It also means the objects expanded from groupings cannot= ever be
> > >> changed (clearly a bug in YANG).
> > >
> > > Yes, bug in YANG.
> >
> > Is this the same issue I raised?
> >
> >=C2=A0 =C2=A0import ietf-foo {
> >=C2=A0 =C2=A0 =C2=A0prefix f;
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0container bar {
> >=C2=A0 =C2=A0 =C2=A0uses f:foo;
> >=C2=A0 =C2=A0}
> >
> >=C2=A0 =C2=A0container baz {
> >=C2=A0 =C2=A0 =C2=A0status deprecated;
> >=C2=A0 =C2=A0 =C2=A0uses f:foo;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 <-- oops, descendants not deprecated!
> >=C2=A0 =C2=A0}=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(not a problem if status inher= ited)
>
> I think I look at this very differently. If something is defined in > f:foo that is current, then this is inherited where f:foo is
> used. What we need is a way to refine that if the usage context has > differnet requirements, like we allow to refine other properties of a<= br> > grouping to adapt it to the usage context.

I think that marking the uses statement with status deprecated should
mean that all nodes in the grouping are "auto-refined" with statu= s
deprecated.=C2=A0 Listing them all in explciit refine doesn't help
anyone imo.


Lifecycle status of abstract definitio= ns (identity, typedef, grouping) should only
be changed it applie= s to all possible usage of the definition. Modules that use
these= external definitions should only override the deprecated or obsolete statu= s
with extreme caution.

The uses-stmt sh= ould not even have a status-stmt since conformance is only for the
conceptual grouping expansion, not for the grouping or the uses statement= s.
The only useful interpretation is that it applies to actual da= ta nodes (after all
nested groupings have been expanded).

I would refine your "auto-refine" a bit :-)
It does not increase the status enum, just lower it to the uses-stmt= status value
=C2=A0 =C2=A0uses(current) -> do not convert any= status during expansion
=C2=A0 =C2=A0uses(deprecated) --> con= vert current to deprecated; leave obsolete unchanged
=C2=A0 =C2= =A0uses(obsolete) --> convert current and deprecated to obsolete

There is still no ability to say that an expanded data no= de is deprecated,
e.g., deprecate some but not all of the nodes f= rom the uses expansion.



<= div>

/martin


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

--001a1140be0e260264055888569a-- From nobody Wed Sep 6 10:27:35 2017 Return-Path: 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 BC88D132055 for ; Wed, 6 Sep 2017 10:27:32 -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 eKX_4UTjdkv4 for ; Wed, 6 Sep 2017 10:27:31 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 E4ABF1243F6 for ; Wed, 6 Sep 2017 10:27:30 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id f199so14324964ita.1 for ; Wed, 06 Sep 2017 10:27:30 -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=v3YW1xs5BMK14fMD6zeYfI5c9KhuvQoysuqjwaUUy2M=; b=UKVyMgZwkWwPIRqFLDyUc4CyEqgZeMR1pFuJrwfPIYJx9A6Pm+Liz5Xm/fLJsZ8t5r JJArfWhqz18uOvhzuWqtPCEQUmiS0+5Ajdh+aMp6RT2LTh7HvWxcNkSH4OyaJjafXekc nCmo0bl+VD2bjEvT20D4Xdg44rxUVuzCnNlma/LjFR4ArneMMfv7kCWLPHwX/v0G3G/N Zhp1ZO/9PQoDXhWwXiluPFFk3OOs+7OYBcZWJefeaailBJ6/Nv2Q3hrkUDlZsualtPbz JbJjNVjs4YshCqzEIeVIsMxNCTtTDyxMdyickhzOqjdJiJoHOnZpmjTDZSnsDVIPyJcE zEww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=v3YW1xs5BMK14fMD6zeYfI5c9KhuvQoysuqjwaUUy2M=; b=nila8Bc3Qb0y8NK7LxYpU5FGxXgnyonnUSkUkYcvwK7DvOkCHA8Ml3vsAMjuzdF8Rd fOztKJ6BD/01xJmJPsIVEcKiEOwgsMzVXCi0SeTwzAUTSWueVHU7bPlh1HUqrUkFQ07o trXt57vfh0/4FLc2p6xsmSTxaCPB9VbXdYQwkdwe1S6I5NM+EQDvu6+5RplzDUlL4CIT SIQS8Kwf69++yBwjxz/ZVnz4cLDGDCJIkMMFXpPVhXx/YLi2rNnAGBIUCC5KDd2cAhV2 VSv1mXkdH2fYVVgDHgV8exSKNY7Hs2ez8IHpa4D0r/hnwQv0D/euj2rXavgNfcMvYLQj bvYA== X-Gm-Message-State: AHPjjUg2sjnJOb/+9ENdT/Y7HBIrwNDWgJg//4qE0h+Y5COA9CE/AQ7D n8nBw7JhjDK/7pe2b9hz7Df/2Tiu8LmX X-Google-Smtp-Source: ADKCNb6EfpFXFaNFY7Wu3XPg+JGhFlo4adQ/Xf3DQylOhioNmgi/6IAou0JQhigJXY0YbEtifvV61ZxMZ107RsaYKZg= X-Received: by 10.36.250.5 with SMTP id v5mr617168ith.24.1504718850135; Wed, 06 Sep 2017 10:27:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.6.206 with HTTP; Wed, 6 Sep 2017 10:27:29 -0700 (PDT) In-Reply-To: References: <847e5bf9-7b3d-9ff8-9954-970f32a2094c@cisco.com> <20170902073342.xoziwor4tdr5bipw@elstar.local> <20170902112832.ymorfgdthobeio6q@elstar.local> <1e95ba5d-7aa2-e08f-56f9-27aa70822a11@cisco.com> <1504537140.5874.38.camel@nic.cz> <1504629352.7175.40.camel@nic.cz> <8af6041d-7cd5-9608-70b4-7cffc4f884f8@cisco.com> <20170905180006.yecbqqdhxtkvosxk@elstar.local> From: Andy Bierman Date: Wed, 6 Sep 2017 10:27:29 -0700 Message-ID: To: Robert Wilton Cc: "j.schoenwaelder@jacobs-university.de" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c034f528cae6d055888a800" Archived-At: Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 17:27:32 -0000 --94eb2c034f528cae6d055888a800 Content-Type: text/plain; charset="UTF-8" On Wed, Sep 6, 2017 at 2:16 AM, Robert Wilton wrote: > > > On 05/09/2017 19:00, Juergen Schoenwaelder wrote: > >> On Tue, Sep 05, 2017 at 06:17:09PM +0100, Robert Wilton wrote: >> >>> I believe that tools intended for general use should follow the YANG spec >>>> literally. >>>> >>> I don't fully agree. I think that they only need to cover the parts of >>> the >>> YANG spec for the models that they are using (or might use). If nobody >>> uses >>> Unicode blocks then it doesn't really matter whether a given tool >>> supports >>> them or not. It is always possible to caveat and add support for the >>> missing bits later. E.g. if I was writing a bespoke XPATH implementation >>> for YANG then there is probably quite a lot of the XPATH spec that I >>> would >>> also leave out as well, and just concentrate on the parts that people >>> actually use, or are likely to use. >>> >>> If this is your understanding of standards, why do you want to define >> a subset of XSD pattern based on the your observation what is used or >> not used? Simply do not implement what you observe is not used. Why do >> we need guidelines of constructs not to use so that they are not used? >> > My aims: > 1) To make pattern statements in standard YANG models easier to comprehend. > 2) So that implementations designed to only support standard YANG models > can have more confidence that they don't need to support all of the Unciode > properties and character blocks. > > I do not agree that goal (1) is achieved by limited the usage of the pattern expression language. IMO it is important to achieve the full interoperability that is possible between tools that conform to the pattern definition language. This is true whether the language is XSD or some flavor of Posix or whatever. It is valuable for readers, writers, and tool-makers to know that all tools that conform to the standard use the same pattern expression language. I do not agree that (2) should be a goal of the standard. If tool-makers have a false expectation that they can use the parser for any pattern expression language, then tools will be fragile. The Andy >> There are multiple contradictions in your posts, one of them was the >> idea of translating unicode matching to ASCII - which simply does not >> work. >> > This does work if your implementation is willing to be restricted to only > supporting ASCII. Some users of YANG seem to think that ASCII is > sufficient to configure and manage network devices. My person opinion is > that they are probably broadly right, but there are some places where > supporting a unicode string is better (e.g. the interface description > leaf). However, in these cases I think that either no pattern statement is > required, or otherwise \w,\s,\d are probably sufficient. > > I understand, and agree, that an implementation that restricts pattern > statement support to only ASCII strings makes the implementation non > compliant to the YANG spec. > > > Or the post where you said \d is OK but then later said \d is >> not OK since it translates to a large number of numeric characters. >> > Yes, my opinion changed when I found our that '\d' covers more than just > ASCII. As per the 6087bis text that I sent out, I think that '\d' can be > used, but must not be used if the regex is meant to only match ASCII 0 to > 9. My concern is that many readers/authors/implementors of YANG models may > not understand properly understand that '\d' also covers digits in other > unicode scripts, and hence I think that it is more clear (and hence better) > to use '[0-9]' in pattern statements instead, since the interpretation of > that is entirely unambiguous. > > > You really need to sort out what you want, what the problem is you are >> trying to solve, how you select the subset of XSD pattern etc. Write >> and I-D. >> > Do you think that writing an I-D, that would contain the same arguments > that I've presented here, would sway your opinion at all? > > My assumption is that it wouldn't and hence writing up an ID would seem to > be a waste of effort. > > And at the end, people who only do POSIX regular expressions, >> because they come with the standard C library on POSIX systems or >> whatever the reason really is, still will either have to continue to >> cheat by silently interpreting XSD pattern as POSIX pattern or they >> create a proper new statement to at least properly distinguish >> different pattern languages. >> > Sure, but I don't regard either of these as good long term solutions. > > Thanks, > Rob > > >> /js >> >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --94eb2c034f528cae6d055888a800 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Sep 6, 2017 at 2:16 AM, Robert Wilton <rwilton@cisco.com&g= t; wrote:


On 05/09/2017 19:00, Juergen Schoenwaelder wrote:
On Tue, Sep 05, 2017 at 06:17:09PM +0100, Robert Wilton wrote:
I believe that tools intended for general use should follow the YANG spec literally.
I don't fully agree.=C2=A0 I think that they only need to cover the par= ts of the
YANG spec for the models that they are using (or might use). If nobody uses=
Unicode blocks then it doesn't really matter whether a given tool suppo= rts
them or not.=C2=A0 It is always possible to caveat and add support for the<= br> missing bits later.=C2=A0 E.g. if I was writing a bespoke XPATH implementat= ion
for YANG then there is probably quite a lot of the XPATH spec that I would<= br> also leave out as well, and just concentrate on the parts that people
actually use, or are likely to use.

If this is your understanding of standards, why do you want to define
a subset of XSD pattern based on the your observation what is used or
not used? Simply do not implement what you observe is not used. Why do
we need guidelines of constructs not to use so that they are not used?
My aims:
1) To make pattern statements in standard YANG models easier to comprehend.=
2) So that implementations designed to only support standard YANG models ca= n have more confidence that they don't need to support all of the Uncio= de properties and character blocks.



I do not agree that goa= l (1) is achieved by limited the usage of the pattern expression language.<= /div>
IMO it is important to achieve the full interoperability that is = possible between tools
that conform to the pattern definition lan= guage.=C2=A0 This is true whether the language is XSD or some flavor
<= div>of Posix or whatever.=C2=A0 It is valuable for readers, writers, and to= ol-makers to know that all
tools that conform to the standard use= the same pattern expression language.

I do not ag= ree that (2) should be a goal of the standard.
If tool-makers hav= e a false expectation that they can use the parser for any pattern
expression language, then tools will be fragile. The=C2=A0

=

Andy



There are multiple contradictions in your posts, one of them was the
idea of translating unicode matching to ASCII - which simply does not
work.
This does work if your implementation is willing to be restricted to only s= upporting ASCII.=C2=A0 Some users of YANG seem to think that ASCII is suffi= cient to configure and manage network devices.=C2=A0 My person opinion is t= hat they are probably broadly right, but there are some places where suppor= ting a unicode string is better (e.g. the interface description leaf).=C2= =A0 However, in these cases I think that either no pattern statement is req= uired, or otherwise \w,\s,\d are probably sufficient.

I understand, and agree, that an implementation that restricts pattern stat= ement support to only ASCII strings makes the implementation non compliant = to the YANG spec.


=C2=A0 Or the post where you said \d is OK but then later said \d is
not OK since it translates to a large number of numeric characters.
Yes, my opinion changed when I found our that '\d' covers more than= just ASCII.=C2=A0 As per the 6087bis text that I sent out, I think that &#= 39;\d' can be used, but must not be used if the regex is meant to only = match ASCII 0 to 9.=C2=A0 My concern is that many readers/authors/implement= ors of YANG models may not understand properly understand that '\d'= also covers digits in other unicode scripts, and hence I think that it is = more clear (and hence better) to use '[0-9]' in pattern statements = instead, since the interpretation of that is entirely unambiguous.


You really need to sort out what you want, what the problem is you are
trying to solve, how you select the subset of XSD pattern etc. Write
and I-D.
Do you think that writing an I-D, that would contain the same arguments tha= t I've presented here, would sway your opinion at all?

My assumption is that it wouldn't and hence writing up an ID would seem= to be a waste of effort.

=C2=A0 And at the end, people who only do POSIX regular expressions,
because they come with the standard C library on POSIX systems or
whatever the reason really is, still will either have to continue to
cheat by silently interpreting XSD pattern as POSIX pattern or they
create a proper new statement to at least properly distinguish
different pattern languages.
Sure, but I don't regard either of these as good long term solutions.
Thanks,
Rob


/js


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

--94eb2c034f528cae6d055888a800-- From nobody Wed Sep 6 10:34:37 2017 Return-Path: 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 6AC9E132055 for ; Wed, 6 Sep 2017 10:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.011 X-Spam-Level: X-Spam-Status: No, score=-3.011 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 o4h2JkKON3iV for ; Wed, 6 Sep 2017 10:34:33 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0100.outbound.protection.outlook.com [104.47.40.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00E4E1321A2 for ; Wed, 6 Sep 2017 10:34:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ji7HV164PYaNGLfO0u2CpRHb/L/7Z4X5348NVMLXWY8=; b=EfSpzbqfGlFFpX4NOFiH9QdVWuk4rtA3ts/uv/RhYqLfVXFuJTisGt2AUrkwFqORQMIGTsiK3gDV1BoivAIXBUPew4Cbc9DbjqCRbqLObPCgkdrLCKjKjJHGk+NzfpdmxjusJ4/66y9iQGctr3XTpVwj+gH588AfE/ZTFg4RdMA= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1572.namprd05.prod.outlook.com (10.161.217.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.3; Wed, 6 Sep 2017 17:34:30 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.20.0035.010; Wed, 6 Sep 2017 17:34:30 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: two options for removing /foo-state trees? Thread-Index: AQHTJzZlKMfT3FTQbEyg9FUCwcWxgA== Date: Wed, 6 Sep 2017 17:34:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1572; 6:8Ep4A4Gw1cFaozx2+qfZkvC8ngabQTofCBEdMr0LcYKs4+jgV0FJaqJ6SRInwqPZC+Lt0zsgJUVIM1t34AT0l261rsWsZbPPLQHT/1UbeEJFR+AgW+Ote+Plf4WhqMkoV/2jGefPTFjPTHVl05WYuwyzhF8hApTLOPY8cp8hOKAzhqGW2fjXNl9IGCtyOzSH/C6vRFE1gEaiWPaqlIlyyGDS6H+n/e/zI1s2dJfgb+2UrYgMB+2913XERCBF/jGgjbPRpOnZdNE/eb4Ph8jNRz3ia/9pxAhad9EFqriLBLUu/XDfh3hGQQlAmM5EScDk4SZ3MU+83Lzq/sFBipZg/A==; 5:Q2k8fbIs3345WDubrANq+Fzt6Lwc5wKlodrUFq2DQSsz6yfvno7J/T4W5XQXxij2Fa/wiQ3pKbdBPFDlp4hx/9wQm1d8s8bVw3O9xbhcqSfqdCqbrxylADH/Ecwmye9+EyHxwOnbXw0TcH5RczO4FQ==; 24:qjetmSFvsJErDlYPhVtKCbDbUZb4wcH3oqbxsop1ikx5j6TNJNZ++sXQbs38ZR6tq8+OsACd3GsF6Qezp4s1Vh6/0rh4eZfKMGq7gV2ZTTI=; 7:Znk39YHvG2WzRov/93mmUYAxEv4ETbngZWKv1AwwVlIP4Wtotty0xYeIf29pyWICSzlQzPxCec2yEBKONOKf2v1LDnLQT32hS9n6KVAru8QuXYE8r0hnexjGERzDDQdkYrrug+QiTBLoUTKN5vCbUzC6IAXVgZWKmP9YExIJTnJdFsbTZdMsA3feGn0iz/pnZut1w/rUIRdSVREAC4O1hQWmWXHhmKz0kvAtcNmm0Uw= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: b5e5f6c8-3987-45a3-d463-08d4f54d87cf x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1572; x-ms-traffictypediagnostic: BN3PR0501MB1572: x-exchange-antispam-report-test: UriScan:(158342451672863); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123564025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1572; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1572; x-forefront-prvs: 0422860ED4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(199003)(189002)(99286003)(6116002)(110136004)(102836003)(66066001)(3660700001)(3280700002)(5640700003)(2906002)(4326008)(478600001)(83716003)(82746002)(86362001)(4001350100001)(83506001)(68736007)(966005)(2900100001)(189998001)(1730700003)(81156014)(8936002)(8676002)(97736004)(81166006)(106356001)(105586002)(101416001)(6506006)(6436002)(305945005)(6916009)(5660300001)(2351001)(33656002)(6486002)(77096006)(14454004)(7736002)(54356999)(50986999)(53936002)(3846002)(2501003)(36756003)(6512007)(25786009)(6306002)(54906002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1572; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <979E420F3D2F9644874682A588C4369D@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Sep 2017 17:34:30.5288 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1572 Archived-At: Subject: [netmod] two options for removing /foo-state trees? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 17:34:35 -0000 W2NoYW5naW5nIHN1YmplY3QgbGluZSwgd2FzICJ1cGNvbWluZyBhZG9wdGlvbnMiXQ0KDQpXZSd2 ZSBiZWVuIHByaW1hcmlseSBmb2N1c2VkIG9uIHVwZGF0aW5nIG1vZHVsZXMgYnkNCmRlcHJlY2F0 aW5nIHRoZSAvZm9vLXN0YXRlIHRyZWUgaW4gc2l0dS4gIFRoaXMgaXMgd2hhdCB0aGUNCm5tZGEt Z3VpZGVsaW5lcyBkcmFmdCBzYWlkIHRvIGRvIGFuZCBpcyBtdWNoIG9mIHdoYXQgdGhlIA0KInN0 YXR1cyBzdGF0ZW1lbnQgbmVlZGVkIG9uIGV2ZXJ5IG5vZGUiIHRocmVhZCByZWdhcmRzLg0KDQpI b3dldmVyLCB0aGUgUlRHIFlBTkcgRFQgcHV0IGZvcndhcmQgYW4gYWx0ZXJuYXRlIGFwcHJvYWNo Lg0KVGhlIGlkZWEgaXMgc2ltcGx5LCByYXRoZXIgdGhhbiBkZXByZWNhdGUgdGhlIC9mb28tc3Rh dGUgDQp0cmVlLCBjcmVhdGUgYSBuZXcgbW9kdWxlIHRoYXQgbGVhdmVzIGl0IG91dCBhbHRvZ2V0 aGVyLiAgDQpJJ20gYXNzdW1pbmcgdGhhdCByZmM4MDIyYmlzLTAwIHJldXNpbmcgdGhlIHNhbWUg bW9kdWxlIA0KbmFtZSB3YXMgYW4gb3ZlcnNpdGUsIGFzIGl0IG90aGVyd2lzZSBicmVha3MgWUFO RyBtb2R1bGUgDQp1cGRhdGUgcnVsZXMuICBBbmQsIHRvIGJlIGNvbXBsZXRlIGFib3V0IGl0LCBJ J20gYXNzdW1pbmcNCnRoYXQgcmZjODAyMmJpcy0wMCBzaG91bGQgYWxzbyByZXB1Ymxpc2ggdGhl IG9sZCBtb2R1bGUgDQp3aXRoICphbGwqIG5vZGVzIG1hcmtlZCBkZXByZWNhdGVkLCBzbyB0aGF0 IHRoZXJlJ3Mgbm8gDQpjb25mdXNpb24gbGlrZSB0aGF0IHNlZW4gd2l0aCB0aGUgU01JdjIgdXBk YXRlLg0KDQpQUk9zOg0KIDEpIHRoZSBuZXcgbW9kdWxlIGlzIG1vcmUgcmVhZGFibGUsIGFzIGl0 IGRvZXNuJ3QgaGF2ZSB0byANCiAgICBjYXJyeS1mb3J3YXJkIHRoZSBkZXByZWNhdGVkIChhbmQg bGF0ZXIgb2Jzb2xldGVkKSBub2Rlcw0KICAgIGZvcmV2ZXIuICBbcmFudDogSSBkb24ndCB1bmRl cnN0YW5kIHdoeSBvYnNvbGV0ZSBub2Rlcw0KICAgIGNhbid0IGJlIGRyb3BwZWQgYWZ0ZXIgc29t ZSBhbW91bnQgb2YgdGltZSAtIGhvdyBkb2VzDQogICAgc29tZSBmdXR1cmUgdXNlIG9mIGFuIG9s ZCBub2RlIG5hbWUgbWF0dGVyP10uICBZZXMsIHRoZQ0KICAgIGRlcHJlY2F0ZWQgL2Zvby1zdGF0 ZSB0cmVlIGNvdWxkIGJlIHB1dCBpbnRvIGEgc3VibW9kdWxlLA0KICAgIGJ1dCB0aGF0IGRvZXNu J3QgY2hhbmdlIHRoZSByZWFkYWJpbGl0eSBtdWNoLCBhbmQgYWN0dWFsbHkNCiAgICBtaWdodCBt YWtlIHJlYWRhYmlsaXR5IHdvcnNlLCBiZWNhdXNlIHRoZSByZWFkZXIgdGhlbiBoYXMNCiAgICB0 byBjaGFzZSBkb3duIHRoZSBzdWJtb2R1bGUgd2hlbiB0cnlpbmcgdG8gdW5kZXJzdGFuZCB0aGUN CiAgICAnaW5jbHVkZScgc3RhdGVtZW50Lg0KDQpDT05zOg0KIDEpIGEgbmV3IG1vZHVsZSBuYW1l IG1heSBjb25mdXNlIHRob3NlIHdobyBoYXZlIGdyb3duIGFjY3VzdG9tDQogICAgdG8gdGhlIG9s ZCBuYW1lLiAgVG8gaGVscCB3aXRoIHRoaXMsIHRoZSBuZXcgbmFtZSBjb3VsZCANCiAgICBmb2xs b3cgc29tZSBjb252ZW50aW9uIChlLmcuICotMiBvciAqLWV4KSwgYnV0IHN1Y2gNCiAgICBjb252 ZW50aW9ucyBhbHdheXMgc2VlbSBob2tleSB0byBtZS4NCiAyKSBhIG5ldyBtb2R1bGUgbmFtZSBm b3JjZXMgYW4gdXBkYXRlIHRvIG90aGVyIG1vZHVsZXMgdGhhdA0KICAgIGltcG9ydGluZyBpdCAo ZS5nLiwgdG8gcmVzb2x2ZSBYUGF0aHMpLCB0aGF0IG90aGVyd2lzZSBtYXkNCiAgICBub3QgbmVl ZCB0byBiZSB1cGRhdGVkLg0KIDMpIHRoZSBhcHByb2FjaCBkb2Vzbid0IGZvbGxvdyB3aGF0IGRy YWZ0LWRzZHQtbm1kYS1ndWlkZWxpbmVzDQogICAgc2F5cyBpbiBndWlkZWxpbmUgKGMpLCBidXQg dGhpcyBzZWVtcyB0byBiZSBhIG1pbm9yIHBvaW50Lg0KIDQpIHJlcHVibGlzaGluZyB0aGUgb2xk IG1vZHVsZSB3aXRoIGFsbCBub2RlcyBkZXByZWNhdGVkIHNlZW1zDQogICAgb2ZmLCBidXQgNzk1 MCBkb2Vzbid0IGxpc3QgJ3N0YXR1cycgYXMgYSBzdWJzdGF0ZW1lbnQgdG8NCiAgICB0aGUgJ21v ZHVsZScgc3RhdGVtZW50LCBzbyB3aGF0IGVsc2UgY2FuIHdlIGRvPw0KDQpBbnkgb3RoZXIgcHJv cyBvciBjb25zPw0KDQoNCkFub3RoZXIgcXVlc3Rpb24gaXMgaWYgYWxsIHRoZSBtb2R1bGVzIGhh dmUgdG8gYmUgdXBkYXRlZCB0aGUNCnNhbWUgd2F5ICh3aGljaCBjb3VsZCBibG9jayBhZG9wdGlv biBvZiB0aGVzZSBkcmFmdHMgdW50aWwgd2UNCnNldHRsZWQgb24gYW4gYXBwcm9hY2gpLCBvciBk byB3ZSBsZXQgZWFjaCBtb2R1bGUgdXBkYXRlIGluIGEgDQp3YXkgdGhhdCBzdWl0ZXMgaXQgYmVz dCBiYXNlIG9uLCBlLmcuLCBob3cgZGVwbG95ZWQgaXQgaXMsIGhvdw0Kb2Z0ZW4gaXQncyBiZWVu IGltcG9ydGVkIGJ5IG90aGVyIGRyYWZ0cywgZXRjLiAgVGhvdWdodHM/DQoNCg0KS2VudCAgLy8g Y29udHJpYnV0b3INCg0KDQoNCj4+Pj4gS2VudCB3cml0ZXM6DQo+Pj4+IDMuIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hY2VlLW5ldG1vZC1yZmM4MDIyYmlzLTAwDQo+Pj4NCj4+ PiBNYXJ0aW4gd3JpdGVzOg0KPj4+ICBvICBBbGwgdGhlIG9sZCAtc3RhdGUgZGVmaW5pdGlvbnMg YXJlIHJlbW92ZWQsIHJhdGhlciB0aGFuIGJlaW5nDQo+Pj4gICAgIG1hcmtlZCBhcyAiZGVwcmVj YXRlZCIuDQo+Pg0KPj4gQWNlZSB3cml0ZXM6DQo+PiBJ4oCZbSBnbGFkIHlvdSBicm91Z2h0IHRo aXMgdXAuIFdlIGRpc2N1c3NlZCB0aGlzIGluIHRoZSBSb3V0aW5nIA0KPj4gWUFORyBEZXNpZ24g VGVhbSBhbmQgd2VyZSBwbGFubmluZyB0byBkaXNjdXNzIGl0IG9uIGEgd2lkZSBzY2FsZS4NCj4+ IE9uZSBvZiB0aGUgYWR2YW50YWdlcyBvZiB0aGUgTk1EQSBpcyB0aGF0IGl0IG1ha2VzIHRoZSBt b2RlbHMgDQo+PiBlYXNpZXIgdG8gcmVhZCBhbmQgY29uc3VtZS4gVGhpcyBpcyBzb21ld2hhdCBu ZWdhdGVkIGlmIHdlIGhhdmUNCj4+IHRvIHJldGFpbiBhbGwgdGhlc2UgZGF0YSBub2RlcyBpbiB0 aGUgYXNzb2NpYXRlZCBtb2R1bGVzIGFuZCBtYXJrDQo+PiB0aGVtIGFzIOKAnGRlcHJlY2F0ZWTi gJ0uIFdoYXQgaXMgdGhlIGNvbnNlcXVlbmNlIG9mIG5vdCBpbmNsdWRpbmcgDQo+PiB0aGVtPyBU aGV5IGFyZSBhdmFpbGFibGUgaW4gdGhlIHByZXZpb3VzIHZlcnNpb24gb2YgdGhlIG1vZGVsIA0K Pj4gaWYgdGhleSBhcmUgbmVlZCBmb3IgY29tcGF0aWJpbGl0eS4NCj4NCj4gSXQgaXMgZmFpcmx5 IGNvbW1vbiB0aGF0IGluc3RlYWQgb2YgcmVtb3ZpbmcgZnVuY3Rpb25zIGZyb20gYQ0KPiBwdWJs aXNoZWQgQVBJLCB5b3UgbWFyayB0aGVtIGFzIGRlcHJlY2F0ZWQgZm9yIHNvbWUgdGltZSwgYW5k IHRoZW4sDQo+IGxhdGVyLCByZW1vdmUgdGhlbSAoKikuDQo+DQo+IE5vdGUgdGhhdCBzaW5jZSBh IHNlcnZlciBjYW5ub3QgaW1wbGVtZW50IHR3byB2ZXJzaW9ucyBvZiBhIGdpdmVuDQo+IG1vZHVs ZSwgaXQgaGFzIHRvIGRlY2lkZSB3aGljaCB2ZXJzaW9uIHRvIGltcGxlbWVudC4gIFRoZXJlIG1p Z2h0IGJlDQo+IG90aGVyIG1vZHVsZXMgdGhhdCB1c2UgLyBhdWdtZW50IHRoZSAtc3RhdGUgdHJl ZTsgaWYgdGhlIHNlcnZlcg0KPiBpbXBsZW1lbnRzIHRoZSBsYXRlc3QgdmVyc2lvbiB3L28gdGhl IC1zdGF0ZSB0cmVlLCBpdCBjYW5ub3QgYXQgdGhlDQo+IHNhbWUgdGltZSBpbXBsZW1lbnQgdGhl c2UgYXVnbWVudGluZyBtb2R1bGVzLg0KPg0KPiAoKikgWUFORyBpbmhlcml0cyB0aGUgZGVwcmVj YXRpb24gbW9kZWwgZnJvbSBTTUl2Mi4gIFdlIGFjdHVhbGx5IGhhdmUNCj4gdGhyZWUgc3RhdGVz OiBjdXJyZW50IC0+IGRlcHJlY2F0ZWQgLT4gb2Jzb2xldGUuICBBbmQgZXZlbiB3aGVuDQo+IHNv bWV0aGluZyBpcyBvYnNvbGV0ZSwgaXQgaXMgbm90IHJlbW92ZWQuICBJIGd1ZXNzIGluIFNNSXYy IHRoaXMgd2FzDQo+IG5lY2Vzc2FyeSBiL2Mgb2YgT0lEIGFzc2lnbm1lbnRzOyBtYXliZSB0aGlz IGNvdWxkIGJlIHJldmlzaXRlZCBmb3INCj4gWUFORy4gIEJ1dCB0aGlzIHdvdWxkIHJlcXVpcmUg YW4gdXBkYXRlIHRvIFJGQyA3OTUwLg0KPg0KPiBJZiB3ZSB0aGluayB0aGF0IGEgbW9kdWxlIGJl Y29tZXMgY2x1dHRlcmVkIHdpdGggYWxsIHRoZSBkZXByZWNhdGVkDQo+IGRlZmluaXRpb25zLCB3 ZSBjYW4gYWN0dWFsbHkgbW92ZSB0aGVtIGFsbCB0byBhIHNlcGFyYXRlIHN1Ym1vZHVsZS4NCg0K DQoNCg== From nobody Wed Sep 6 10:57:11 2017 Return-Path: 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 1AAAE132494; Wed, 6 Sep 2017 10:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 2GgUpM-H5aRX; Wed, 6 Sep 2017 10:57:08 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0127.outbound.protection.outlook.com [104.47.34.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56977132055; Wed, 6 Sep 2017 10:57:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sYooAI+SO1vEoHZnyD9TBjibxkZlovD/YP88IMBVyHo=; b=U26JA1In6wrglqeRG3PaXYN84Zsp/o/kIV2GvBM/igSVlcFEiaeKjkRkijBkqnCHavjuAVPYUBqymFrcWs9we3ei9CQ1U3I9ru1wGt6VuWdasHkYN2kGuqNEKi/GscM7zYzJlevGdRDdFD/8SnWJrYYhIZDQQQ3miyhjJsSB7S0= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1266.namprd05.prod.outlook.com (10.160.183.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Wed, 6 Sep 2017 17:57:06 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.20.0035.010; Wed, 6 Sep 2017 17:57:06 +0000 From: Kent Watsen To: Andy Bierman CC: Martin Bjorklund , "bclaise@cisco.com" , "netconf-chairs@ietf.org" , "netmod@ietf.org" Thread-Topic: [netmod] upcoming adoptions Thread-Index: AQHTISEQvmg9jr+3gUCv+5ltP9XhHqKl6moAgAANOICAAP0JAIAAf2MAgAAqCYCAAGgzAP//54AA Date: Wed, 6 Sep 2017 17:57:06 +0000 Message-ID: References: <3620aafe-bc72-cc54-9dbd-b687a0178df2@cisco.com> <20170905.095949.1829098658779783521.mbj@tail-f.com> <20170906.084124.2282926097915349446.mbj@tail-f.com> <38E666E2-EECE-4554-9A55-B98D829EB4CA@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.20.0.170309 x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1266; 6:mGrnyjUVvTGJKlYTD9exs3WPPJQzs1Y+bh9kvDWHwIGMqzY4aEW0qPwMJUBaLL8FoZ4TnVCzW+BhVQK3tvEtrehZ5D64vfcRHf9aZ/Fv/ZHaQaU6ViNso9TUXfb9ZzFBPIiqKW0elUUmlvjY4y+WEJF81CWfO0MRsoZ09bISAChazJH3dZSi+JD/TEHyyJ5m86kn4W6oy8g1w9qJapL4ZjSE+Pp/hZy3sH5xK6q28NpiGi9P3k9TkicGAz13S5lgPMsdjQ47jHbk8NtKzlEPPuDCAddpIuBXefwpReOs57rlGaLPjB9crTqkMH38hSUXpEjFba/QkZLbvyJpY5eyhw==; 5:eXWF0pziCsvprnhmSDL2KvdpV2P5FebV0k1rrBUkv1r0w0sDs8Ku+rS5Hi7sK3uEAh9oRw4DaFZHdpeE2iRS9kdu8cHxqUtukvvwMI5NWqvQIY6cdo3hBWv2WZHw798ctvY76/AHW3dW6kdGpwqOgw==; 24:/yPcr91sYROpwxBZij+ylLdcxri6X9gQndKA5PeZXt0mps0u8Ok5dH77QG5qDSwAmmSRZfM5TUnaiMbGojHgo6OQtQTsqftpPlB00uZO7xc=; 7:PfeAHZq5n83zmyaeyTmdhFh6HPD7pCGAw7o+tQiXGNk/LLXK2Ycoeeg5hrVOk8x6EV7MCHPECM/MrWV9Vp3hz2QcEKm49CROgXFCt1wdq65q0+xosKIxTRkmx4MFYpo+nt/XRuajAF9kmVWVslkym1g5CKT54bS+saVjIAPfqsWqRPebiykWkT1bmu0nnEe+zOIxaShIDneC1yHjo6r7eBZJfWi4vHvHou/BYv4hMoM= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 1f6c614f-2fd9-483e-1e31-08d4f550b043 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1266; x-ms-traffictypediagnostic: BN3PR0501MB1266: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123562025)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1266; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1266; x-forefront-prvs: 0422860ED4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(189002)(199003)(2906002)(82746002)(50986999)(86362001)(54356999)(76176999)(66066001)(106356001)(105586002)(8936002)(36756003)(93886005)(81166006)(8676002)(81156014)(478600001)(68736007)(2950100002)(229853002)(6916009)(189998001)(101416001)(3846002)(33656002)(7736002)(305945005)(83716003)(99286003)(54906002)(25786009)(97736004)(3280700002)(14454004)(2900100001)(102836003)(6116002)(110136004)(4326008)(6506006)(5660300001)(77096006)(6486002)(3660700001)(4001350100001)(6512007)(53936002)(6246003)(83506001)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1266; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Sep 2017 17:57:06.8053 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1266 Archived-At: Subject: Re: [netmod] upcoming adoptions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 17:57:10 -0000 DQoNCj4+IC9uZXRjb25mLXN0YXRlIGFuZCAvcmVzdGNvbmYtc3RhdGUgZG9uJ3Qgc2VlbSB0byBm b2xsb3cgdGhlIGdlbmVyYWwNCj4+IHBhdHRlcm4gd2UncmUgY29ycmVjdGluZyB3aXRoIHRoZSB2 YXJpb3VzIE5NREEgdXBkYXRlcy7CoCBQYXJ0aWN1bGFybHksDQo+PiB0aGVzZSAtc3RhdGUgdHJl ZXMgYXJlIE5PVCBmb3IgdGhlIHB1cnBvc2UgdG8gcHJvdmlkaW5nIHRoZSBvcHN0YXRlDQo+PiB2 YWx1ZSBmb3IgY29uZmlndXJlZCBub2Rlcy7CoCBUaGVzZSBtb2R1bGVzIGhhdmUgdGhlIG1pc2Zv cnR1bmUgb2YNCj4+IGhhdmluZyAiLXN0YXRlIiBpbiB0aGVpciBuYW1lLCBidXQgdGhleSdyZSBv dGhlcndpc2UgZmluZS4NCj4NCj4NCj4gVGhpcyBjb250cmFkaWN0cyBzb21lIGRldGFpbHMgd2Ug aGF2ZSBiZWVuIHRvbGQgYWJvdXQgTk1EQQ0KPiANCj4gMSkgdGhlIHRyYW5zaXRpb24gZ3VpZGVs aW5lcyBzYXkgb3RoZXJ3aXNlDQo+IA0KPiBOZXcgbW9kdWxlcyBhbmQgbW9kdWxlcyB0aGF0IGFy ZSBub3QgY29uY2VybmVkIHdpdGggdGhlDQo+IG9wZXJhdGlvbmFsIHN0YXRlIG9mIGNvbmZpZ3Vy YXRpb24gaW5mb3JtYXRpb24gU0hPVUxEDQo+IGltbWVkaWF0ZWx5IGJlIHN0cnVjdHVyZWQgdG8g YmUgTk1EQS1jb21wYXRpYmxlDQoNClllcywgSSdtIHN1Z2dlc3Rpbmcgd2UgZ2l2ZSBvdXJzZWx2 ZXMgc29tZSBsZWV3YXksIGJ5IHRha2luZw0KYWR2YW50YWdlIG9mIHRoZSBTSE9VTEQga2V5d29y ZCBhYm92ZSBhbmQgZGVmZXIgdXBkYXRpbmcgdGhlc2UNCnR3byBtb2R1bGVzIHRvIHdoZW4gaXQg bWFrZXMgbW9yZSBzZW5zZSB0byBkbyBzby4NCg0KDQo+IDIpIFJEIGRlZmluZXMgb3BlcmF0aW9u YWwgc3RhdGUgdG8gaW5jbHVkZSBjb25maWc9ZmFsc2Ugbm9kZXMNCj4gc3VjaCBhcyBjb3VudGVy cywgc28gdGhlc2UgbW9kdWxlcyBhcmUgcHJvcGVybHkgbmFtZWQuDQoNCm1vZHVsZS1uYW1lID09 IHRvcC1sZXZlbCBub2RlIG5hbWUuICBFaXRoZXIgd2F5LCBteSBwb2ludCBpcyB0aGF0DQp0aGUg LXN0YXRlIHRyZWUgaW4gdGhlc2UgbW9kdWxlcyBpcyBub3QgdHJ5aW5nIHRvIHByb3ZpZGUgdGhl IA0Kb3BzdGF0ZSB2YWx1ZSBmb3IgY29uZmlndXJlZCBub2RlcyAoaS5lLiBhcHBsaWVkIGNvbmZp Z3VyYXRpb24pLiAgDQoNCg0KSy4NCg0KDQoNCg== From nobody Wed Sep 6 11:02:38 2017 Return-Path: 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 2C67D132705 for ; Wed, 6 Sep 2017 11:02:36 -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 m-WdgmwIoAqj for ; Wed, 6 Sep 2017 11:02: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 A3637132055 for ; Wed, 6 Sep 2017 11:02:29 -0700 (PDT) Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 8EB341AE0352; Wed, 6 Sep 2017 20:02:28 +0200 (CEST) Date: Wed, 06 Sep 2017 20:05:45 +0200 (CEST) Message-Id: <20170906.200545.1646568136744118938.mbj@tail-f.com> To: kwatsen@juniper.net Cc: netmod@ietf.org, acee@cisco.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netmod] two options for removing /foo-state trees? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 18:02:37 -0000 S2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+IHdyb3RlOg0KPiBbY2hhbmdpbmcgc3Vi amVjdCBsaW5lLCB3YXMgInVwY29taW5nIGFkb3B0aW9ucyJdDQo+IA0KPiBXZSd2ZSBiZWVuIHBy aW1hcmlseSBmb2N1c2VkIG9uIHVwZGF0aW5nIG1vZHVsZXMgYnkNCj4gZGVwcmVjYXRpbmcgdGhl IC9mb28tc3RhdGUgdHJlZSBpbiBzaXR1LiAgVGhpcyBpcyB3aGF0IHRoZQ0KPiBubWRhLWd1aWRl bGluZXMgZHJhZnQgc2FpZCB0byBkbyBhbmQgaXMgbXVjaCBvZiB3aGF0IHRoZSANCj4gInN0YXR1 cyBzdGF0ZW1lbnQgbmVlZGVkIG9uIGV2ZXJ5IG5vZGUiIHRocmVhZCByZWdhcmRzLg0KPiANCj4g SG93ZXZlciwgdGhlIFJURyBZQU5HIERUIHB1dCBmb3J3YXJkIGFuIGFsdGVybmF0ZSBhcHByb2Fj aC4NCj4gVGhlIGlkZWEgaXMgc2ltcGx5LCByYXRoZXIgdGhhbiBkZXByZWNhdGUgdGhlIC9mb28t c3RhdGUgDQo+IHRyZWUsIGNyZWF0ZSBhIG5ldyBtb2R1bGUgdGhhdCBsZWF2ZXMgaXQgb3V0IGFs dG9nZXRoZXIuICANCj4gSSdtIGFzc3VtaW5nIHRoYXQgcmZjODAyMmJpcy0wMCByZXVzaW5nIHRo ZSBzYW1lIG1vZHVsZSANCj4gbmFtZSB3YXMgYW4gb3ZlcnNpdGUsIGFzIGl0IG90aGVyd2lzZSBi cmVha3MgWUFORyBtb2R1bGUgDQo+IHVwZGF0ZSBydWxlcy4gIEFuZCwgdG8gYmUgY29tcGxldGUg YWJvdXQgaXQsIEknbSBhc3N1bWluZw0KPiB0aGF0IHJmYzgwMjJiaXMtMDAgc2hvdWxkIGFsc28g cmVwdWJsaXNoIHRoZSBvbGQgbW9kdWxlIA0KPiB3aXRoICphbGwqIG5vZGVzIG1hcmtlZCBkZXBy ZWNhdGVkLCBzbyB0aGF0IHRoZXJlJ3Mgbm8gDQo+IGNvbmZ1c2lvbiBsaWtlIHRoYXQgc2VlbiB3 aXRoIHRoZSBTTUl2MiB1cGRhdGUuDQo+IA0KPiBQUk9zOg0KPiAgMSkgdGhlIG5ldyBtb2R1bGUg aXMgbW9yZSByZWFkYWJsZSwgYXMgaXQgZG9lc24ndCBoYXZlIHRvIA0KPiAgICAgY2FycnktZm9y d2FyZCB0aGUgZGVwcmVjYXRlZCAoYW5kIGxhdGVyIG9ic29sZXRlZCkgbm9kZXMNCj4gICAgIGZv cmV2ZXIuICBbcmFudDogSSBkb24ndCB1bmRlcnN0YW5kIHdoeSBvYnNvbGV0ZSBub2Rlcw0KPiAg ICAgY2FuJ3QgYmUgZHJvcHBlZCBhZnRlciBzb21lIGFtb3VudCBvZiB0aW1lIC0gaG93IGRvZXMN Cj4gICAgIHNvbWUgZnV0dXJlIHVzZSBvZiBhbiBvbGQgbm9kZSBuYW1lIG1hdHRlcj9dLiAgWWVz LCB0aGUNCj4gICAgIGRlcHJlY2F0ZWQgL2Zvby1zdGF0ZSB0cmVlIGNvdWxkIGJlIHB1dCBpbnRv IGEgc3VibW9kdWxlLA0KPiAgICAgYnV0IHRoYXQgZG9lc24ndCBjaGFuZ2UgdGhlIHJlYWRhYmls aXR5IG11Y2gsIGFuZCBhY3R1YWxseQ0KPiAgICAgbWlnaHQgbWFrZSByZWFkYWJpbGl0eSB3b3Jz ZSwgYmVjYXVzZSB0aGUgcmVhZGVyIHRoZW4gaGFzDQo+ICAgICB0byBjaGFzZSBkb3duIHRoZSBz dWJtb2R1bGUgd2hlbiB0cnlpbmcgdG8gdW5kZXJzdGFuZCB0aGUNCj4gICAgICdpbmNsdWRlJyBz dGF0ZW1lbnQuDQoNCldlbGwsIHRoZSBtb2R1bGUgd2l0aCB0aGUgaW5jbHVkZSB3aWxsIGJlIGV4 YWN0bHkgYXMgcmVhZGFibGUgYXMgYSBuZXcNCm1vZHVsZSwgd2l0aCB0aGUgYWRkaXRpb24gb2Yg b25lIGxpbmU6DQoNCiAgaW5jbHVkZSBpZXRmLWRlcHJlY2F0ZWQtcm91dGluZy1kZWZpbml0aW9u czsNCg0KWW91IGNhbiBldmVuIGFkZCBhIGNvbW1lbnQgdG8gZnVydGhlciBleHBsYWluIHRlaCBk ZXByZWNhdGlvbi4NCg0KPiBDT05zOg0KPiAgMSkgYSBuZXcgbW9kdWxlIG5hbWUgbWF5IGNvbmZ1 c2UgdGhvc2Ugd2hvIGhhdmUgZ3Jvd24gYWNjdXN0b20NCj4gICAgIHRvIHRoZSBvbGQgbmFtZS4g IFRvIGhlbHAgd2l0aCB0aGlzLCB0aGUgbmV3IG5hbWUgY291bGQgDQo+ICAgICBmb2xsb3cgc29t ZSBjb252ZW50aW9uIChlLmcuICotMiBvciAqLWV4KSwgYnV0IHN1Y2gNCj4gICAgIGNvbnZlbnRp b25zIGFsd2F5cyBzZWVtIGhva2V5IHRvIG1lLg0KPiAgMikgYSBuZXcgbW9kdWxlIG5hbWUgZm9y Y2VzIGFuIHVwZGF0ZSB0byBvdGhlciBtb2R1bGVzIHRoYXQNCj4gICAgIGltcG9ydGluZyBpdCAo ZS5nLiwgdG8gcmVzb2x2ZSBYUGF0aHMpLCB0aGF0IG90aGVyd2lzZSBtYXkNCj4gICAgIG5vdCBu ZWVkIHRvIGJlIHVwZGF0ZWQuDQoNClRoaXMgaXMgYSBtYWpvciBkcmF3YmFjayENCg0KDQo+ICAz KSB0aGUgYXBwcm9hY2ggZG9lc24ndCBmb2xsb3cgd2hhdCBkcmFmdC1kc2R0LW5tZGEtZ3VpZGVs aW5lcw0KPiAgICAgc2F5cyBpbiBndWlkZWxpbmUgKGMpLCBidXQgdGhpcyBzZWVtcyB0byBiZSBh IG1pbm9yIHBvaW50Lg0KPiAgNCkgcmVwdWJsaXNoaW5nIHRoZSBvbGQgbW9kdWxlIHdpdGggYWxs IG5vZGVzIGRlcHJlY2F0ZWQgc2VlbXMNCj4gICAgIG9mZiwgYnV0IDc5NTAgZG9lc24ndCBsaXN0 ICdzdGF0dXMnIGFzIGEgc3Vic3RhdGVtZW50IHRvDQo+ICAgICB0aGUgJ21vZHVsZScgc3RhdGVt ZW50LCBzbyB3aGF0IGVsc2UgY2FuIHdlIGRvPw0KPiANCj4gQW55IG90aGVyIHByb3Mgb3IgY29u cz8NCj4gDQo+IA0KPiBBbm90aGVyIHF1ZXN0aW9uIGlzIGlmIGFsbCB0aGUgbW9kdWxlcyBoYXZl IHRvIGJlIHVwZGF0ZWQgdGhlDQo+IHNhbWUgd2F5DQoNCkluIGdlbmVyYWwgSSdkIHNheSBuby4g IEFuIGVudGlyZWx5IG5ldyBtb2R1bGUgbWlnaHQgYmUgdGhlIHJpZ2h0DQphcHByb2FjaCBpbiBz b21lIGNhc2VzLCBidXQgaW4gdGhlIG1ham9yaXR5IG9mIGNhc2VzIG5vdC4NCg0KRm9yIHRoZSBy b3V0aW5nIG1vZHVsZXMsIEkgZG9uJ3QgdGhpbmsgYSBuZXcgbmFtZSBpcyB3b3J0aCBpdC4NCg0K DQovbWFydGluDQoNCg0KPiAod2hpY2ggY291bGQgYmxvY2sgYWRvcHRpb24gb2YgdGhlc2UgZHJh ZnRzIHVudGlsIHdlDQo+IHNldHRsZWQgb24gYW4gYXBwcm9hY2gpLCBvciBkbyB3ZSBsZXQgZWFj aCBtb2R1bGUgdXBkYXRlIGluIGEgDQo+IHdheSB0aGF0IHN1aXRlcyBpdCBiZXN0IGJhc2Ugb24s IGUuZy4sIGhvdyBkZXBsb3llZCBpdCBpcywgaG93DQo+IG9mdGVuIGl0J3MgYmVlbiBpbXBvcnRl ZCBieSBvdGhlciBkcmFmdHMsIGV0Yy4gIFRob3VnaHRzPw0KPiANCj4gDQo+IEtlbnQgIC8vIGNv bnRyaWJ1dG9yDQo+IA0KPiANCj4gDQo+ID4+Pj4gS2VudCB3cml0ZXM6DQo+ID4+Pj4gMy4gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWFjZWUtbmV0bW9kLXJmYzgwMjJiaXMtMDAN Cj4gPj4+DQo+ID4+PiBNYXJ0aW4gd3JpdGVzOg0KPiA+Pj4gIG8gIEFsbCB0aGUgb2xkIC1zdGF0 ZSBkZWZpbml0aW9ucyBhcmUgcmVtb3ZlZCwgcmF0aGVyIHRoYW4gYmVpbmcNCj4gPj4+ICAgICBt YXJrZWQgYXMgImRlcHJlY2F0ZWQiLg0KPiA+Pg0KPiA+PiBBY2VlIHdyaXRlczoNCj4gPj4gSeKA mW0gZ2xhZCB5b3UgYnJvdWdodCB0aGlzIHVwLiBXZSBkaXNjdXNzZWQgdGhpcyBpbiB0aGUgUm91 dGluZyANCj4gPj4gWUFORyBEZXNpZ24gVGVhbSBhbmQgd2VyZSBwbGFubmluZyB0byBkaXNjdXNz IGl0IG9uIGEgd2lkZSBzY2FsZS4NCj4gPj4gT25lIG9mIHRoZSBhZHZhbnRhZ2VzIG9mIHRoZSBO TURBIGlzIHRoYXQgaXQgbWFrZXMgdGhlIG1vZGVscyANCj4gPj4gZWFzaWVyIHRvIHJlYWQgYW5k IGNvbnN1bWUuIFRoaXMgaXMgc29tZXdoYXQgbmVnYXRlZCBpZiB3ZSBoYXZlDQo+ID4+IHRvIHJl dGFpbiBhbGwgdGhlc2UgZGF0YSBub2RlcyBpbiB0aGUgYXNzb2NpYXRlZCBtb2R1bGVzIGFuZCBt YXJrDQo+ID4+IHRoZW0gYXMg4oCcZGVwcmVjYXRlZOKAnS4gV2hhdCBpcyB0aGUgY29uc2VxdWVu Y2Ugb2Ygbm90IGluY2x1ZGluZyANCj4gPj4gdGhlbT8gVGhleSBhcmUgYXZhaWxhYmxlIGluIHRo ZSBwcmV2aW91cyB2ZXJzaW9uIG9mIHRoZSBtb2RlbCANCj4gPj4gaWYgdGhleSBhcmUgbmVlZCBm b3IgY29tcGF0aWJpbGl0eS4NCj4gPg0KPiA+IEl0IGlzIGZhaXJseSBjb21tb24gdGhhdCBpbnN0 ZWFkIG9mIHJlbW92aW5nIGZ1bmN0aW9ucyBmcm9tIGENCj4gPiBwdWJsaXNoZWQgQVBJLCB5b3Ug bWFyayB0aGVtIGFzIGRlcHJlY2F0ZWQgZm9yIHNvbWUgdGltZSwgYW5kIHRoZW4sDQo+ID4gbGF0 ZXIsIHJlbW92ZSB0aGVtICgqKS4NCj4gPg0KPiA+IE5vdGUgdGhhdCBzaW5jZSBhIHNlcnZlciBj YW5ub3QgaW1wbGVtZW50IHR3byB2ZXJzaW9ucyBvZiBhIGdpdmVuDQo+ID4gbW9kdWxlLCBpdCBo YXMgdG8gZGVjaWRlIHdoaWNoIHZlcnNpb24gdG8gaW1wbGVtZW50LiAgVGhlcmUgbWlnaHQgYmUN Cj4gPiBvdGhlciBtb2R1bGVzIHRoYXQgdXNlIC8gYXVnbWVudCB0aGUgLXN0YXRlIHRyZWU7IGlm IHRoZSBzZXJ2ZXINCj4gPiBpbXBsZW1lbnRzIHRoZSBsYXRlc3QgdmVyc2lvbiB3L28gdGhlIC1z dGF0ZSB0cmVlLCBpdCBjYW5ub3QgYXQgdGhlDQo+ID4gc2FtZSB0aW1lIGltcGxlbWVudCB0aGVz ZSBhdWdtZW50aW5nIG1vZHVsZXMuDQo+ID4NCj4gPiAoKikgWUFORyBpbmhlcml0cyB0aGUgZGVw cmVjYXRpb24gbW9kZWwgZnJvbSBTTUl2Mi4gIFdlIGFjdHVhbGx5IGhhdmUNCj4gPiB0aHJlZSBz dGF0ZXM6IGN1cnJlbnQgLT4gZGVwcmVjYXRlZCAtPiBvYnNvbGV0ZS4gIEFuZCBldmVuIHdoZW4N Cj4gPiBzb21ldGhpbmcgaXMgb2Jzb2xldGUsIGl0IGlzIG5vdCByZW1vdmVkLiAgSSBndWVzcyBp biBTTUl2MiB0aGlzIHdhcw0KPiA+IG5lY2Vzc2FyeSBiL2Mgb2YgT0lEIGFzc2lnbm1lbnRzOyBt YXliZSB0aGlzIGNvdWxkIGJlIHJldmlzaXRlZCBmb3INCj4gPiBZQU5HLiAgQnV0IHRoaXMgd291 bGQgcmVxdWlyZSBhbiB1cGRhdGUgdG8gUkZDIDc5NTAuDQo+ID4NCj4gPiBJZiB3ZSB0aGluayB0 aGF0IGEgbW9kdWxlIGJlY29tZXMgY2x1dHRlcmVkIHdpdGggYWxsIHRoZSBkZXByZWNhdGVkDQo+ ID4gZGVmaW5pdGlvbnMsIHdlIGNhbiBhY3R1YWxseSBtb3ZlIHRoZW0gYWxsIHRvIGEgc2VwYXJh dGUgc3VibW9kdWxlLg0KPiANCj4gDQo+IA0K From nobody Wed Sep 6 19:36:34 2017 Return-Path: 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 92B8E1321B6 for ; Wed, 6 Sep 2017 19:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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, URIBL_BLOCKED=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 nlOS3UbRfZvj for ; Wed, 6 Sep 2017 19:36:30 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 0541E124319 for ; Wed, 6 Sep 2017 19:36:30 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id q64so1247798iod.5 for ; Wed, 06 Sep 2017 19:36:29 -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=aRpImF2ZLuyF+k7WEGtdm8qSJI/K+1+96pKJGlILZfQ=; b=EI07Rb0xUaLzVTT7pLUn2PklUwzF+NtDV1ZzPllYmxwBpF/1IkWB5OKGuGVhwiNO+e ZSyrYXCZ8HXn93UBhbDQBPAMvk3plsSx0TFauXV+APVMW5M42EFNZnUGerMFWK1AC+jk w2mHGu2ly99lgfq70UbXHi22jr7MTw13fe1ulktVVcFEl6UBWpkqTvneWpFbFSm9oqup cTlprGa6k1aQtdu3nOyJHWleCZtZxmPDvAVwwiB0pPEDlW2VTmdDVXNyu/NbXY5fJaJB E+FuBBpExwqn68Bte5JQjNjmaYKC3KJMVBdy4FAywg6LK/3xJ/O1H7EFgJ93e/eYGAia znag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aRpImF2ZLuyF+k7WEGtdm8qSJI/K+1+96pKJGlILZfQ=; b=hwIkyvt7Y7do93tbeLirpU+BHCf5FF0D1p21cV7oX9vNJDmj23TUTlEwwjYqyNhtmj qA2gFsBxV0TyyPMO5ydM4ZM+Glb4GzsGZjLHrBNXG9v8YRfgOx9gM2WZUmyTA4a/8cVW vedXYCsxeN80bGURddYtCYs2d/JEk5voM7r3pRx0FCZDgVrMVqPa09f07Cycikctt9QL Lgafhwek+JwavehEInHGvMyKmAwG/AT16p9cVmGhMCrF03pAr+OdsI+CjRbFamWDUjQl p4DeuzL6zQLXsB5ercIgQrazZa2SZwUebyXtRqs5ATCyVTpRjFj9sVsiEzMBdw4+P3tY YlFA== X-Gm-Message-State: AHPjjUhD3NptXiOzbyiL04poZ3Li628LVTEl/NrwjRlUo2XYtHQHM8Yz f6GgiWUZ57MPNpRWtjRYGZv7Tu2U/kio X-Google-Smtp-Source: AOwi7QDQOxWtYEsgCvtUskAkV2DhCQl05rNTqOb90yNU3CPw2NJl9feZpMfQJcyF9FPaxppHJzgx7si4HS4RFCb7t3U= X-Received: by 10.107.171.70 with SMTP id u67mr1497564ioe.227.1504751789260; Wed, 06 Sep 2017 19:36:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.6.206 with HTTP; Wed, 6 Sep 2017 19:36:28 -0700 (PDT) In-Reply-To: References: <3620aafe-bc72-cc54-9dbd-b687a0178df2@cisco.com> <20170905.095949.1829098658779783521.mbj@tail-f.com> <20170906.084124.2282926097915349446.mbj@tail-f.com> <38E666E2-EECE-4554-9A55-B98D829EB4CA@juniper.net> From: Andy Bierman Date: Wed, 6 Sep 2017 19:36:28 -0700 Message-ID: To: Kent Watsen Cc: Martin Bjorklund , "bclaise@cisco.com" , "netconf-chairs@ietf.org" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="001a1148bd7adfe17005589053b1" Archived-At: Subject: Re: [netmod] upcoming adoptions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 02:36:32 -0000 --001a1148bd7adfe17005589053b1 Content-Type: text/plain; charset="UTF-8" On Wed, Sep 6, 2017 at 10:57 AM, Kent Watsen wrote: > > > >> /netconf-state and /restconf-state don't seem to follow the general > >> pattern we're correcting with the various NMDA updates. Particularly, > >> these -state trees are NOT for the purpose to providing the opstate > >> value for configured nodes. These modules have the misfortune of > >> having "-state" in their name, but they're otherwise fine. > > > > > > This contradicts some details we have been told about NMDA > > > > 1) the transition guidelines say otherwise > > > > New modules and modules that are not concerned with the > > operational state of configuration information SHOULD > > immediately be structured to be NMDA-compatible > > Yes, I'm suggesting we give ourselves some leeway, by taking > advantage of the SHOULD keyword above and defer updating these > two modules to when it makes more sense to do so. > > OK -- good. I think another sentence needs to be added. NMDA compatibility conversion MAY be deferred if the module does not contain any configuration datastore objects. > > 2) RD defines operational state to include config=false nodes > > such as counters, so these modules are properly named. > > module-name == top-level node name. Either way, my point is that > the -state tree in these modules is not trying to provide the > opstate value for configured nodes (i.e. applied configuration). > > So a data node naming convention is needed? And a module naming convention? We need a rule that says the suffix "-state" is reserved for NMDA compatibility so module names and data nodes SHOULD NOT be named with an identifier that ends in this suffix. (Automation tools like deterministic rules, not naming conventions. Here is an example why... there are always exceptions that do not follow the conventions. Always people who are unaware of the conventions.) > > K. > > > > Andy --001a1148bd7adfe17005589053b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Sep 6, 2017 at 10:57 AM, Kent Watsen <kwatsen@juniper.net> wrote:


>> /netconf-state and /restconf-state don't seem to follow the ge= neral
>> pattern we're correcting with the various NMDA updates.=C2=A0 = Particularly,
>> these -state trees are NOT for the purpose to providing the opstat= e
>> value for configured nodes.=C2=A0 These modules have the misfortun= e of
>> having "-state" in their name, but they're otherwise= fine.
>
>
> This contradicts some details we have been told about NMDA
>
> 1) the transition guidelines say otherwise
>
> New modules and modules that are not concerned with the
> operational state of configuration information SHOULD
> immediately be structured to be NMDA-compatible

Yes, I'm suggesting we give ourselves some leeway, by taking
advantage of the SHOULD keyword above and defer updating these
two modules to when it makes more sense to do so.



OK -- good.
I= think another sentence needs to be added.


NMDA compatibility conversion MAY be deferred if the module
does not contain any configuration datastore objects.



> 2) RD defines operational state to include config=3Dfalse nodes
> such as counters, so these modules are properly named.

module-name =3D=3D top-level node name.=C2=A0 Either way, my point is that<= br> the -state tree in these modules is not trying to provide the
opstate value for configured nodes (i.e. applied configuration).


So a data node naming convention is needed?
And a module naming convention?

We need a rule t= hat says the suffix "-state" is reserved for NMDA compatibility
so module names and data nodes SHOULD NOT be named with an identif= ier that
ends in this suffix.

(Automatio= n tools like deterministic rules, not naming conventions.
Here is= an example why... there are always exceptions that do not follow
the conventions. Always people who are unaware of the conventions.)
<= div>


K.




Andy<= /div>

--001a1148bd7adfe17005589053b1-- From nobody Thu Sep 7 02:35:32 2017 Return-Path: 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 434571326ED; Thu, 7 Sep 2017 02:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 WgmCeObn5-Rp; Thu, 7 Sep 2017 02:35:28 -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 E5E82132EDE; Thu, 7 Sep 2017 02:35:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8984; q=dns/txt; s=iport; t=1504776928; x=1505986528; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=NoT6SXitmtAEl3aa4KIz8F1PBgowz3aQyHOu7v/BgkQ=; b=fVIPx0rIbIeuAr/76qo+rneG9ofhq6A2btyRScPIAC0WTwQgslxZ5ue7 ex2GIAmMxLdv8h/ywmWrYtbiqFIJk1ZKB2AY+a+sWXGGFmartKbINj4+7 c0CYCeRaZvrOETAIhMCaj+kjMA3aXFrG3GwquzkNNDtdm2hQvoGbtLC3N I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DhAwD3EbFZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD5uJ4N3ixWQcyuQaYdRChgBCoRMTwKEQhUBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQEBAQIBAQEhSwsFCwsYJwMCAicfEQYBDAYCAQGKJQgQrUaCJyeLIgEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARgFgyqDUIFjKwuCcogIgmEFkSiHDIhAlFGLVIcdjVe?= =?us-ascii?q?HVIE5NSKBDTIhCBwVSYccPzaLCgEBAQ?= X-IronPort-AV: E=Sophos;i="5.42,357,1500940800"; d="scan'208,217";a="655474278" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Sep 2017 09:35:25 +0000 Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v879ZPhN016457; Thu, 7 Sep 2017 09:35:25 GMT To: Andy Bierman , Kent Watsen Cc: "netconf-chairs@ietf.org" , "netmod@ietf.org" References: <3620aafe-bc72-cc54-9dbd-b687a0178df2@cisco.com> <20170905.095949.1829098658779783521.mbj@tail-f.com> <20170906.084124.2282926097915349446.mbj@tail-f.com> <38E666E2-EECE-4554-9A55-B98D829EB4CA@juniper.net> From: Robert Wilton Message-ID: <9cd0c109-6430-a649-66b1-8228c721538d@cisco.com> Date: Thu, 7 Sep 2017 10:35:25 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------001FF6F31DB488A4DD06A186" Content-Language: en-US Archived-At: Subject: Re: [netmod] upcoming adoptions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 09:35:30 -0000 This is a multi-part message in MIME format. --------------001FF6F31DB488A4DD06A186 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 07/09/2017 03:36, Andy Bierman wrote: > > > On Wed, Sep 6, 2017 at 10:57 AM, Kent Watsen > wrote: > > > > >> /netconf-state and /restconf-state don't seem to follow the general > >> pattern we're correcting with the various NMDA updates.  > Particularly, > >> these -state trees are NOT for the purpose to providing the opstate > >> value for configured nodes.  These modules have the misfortune of > >> having "-state" in their name, but they're otherwise fine. > > > > > > This contradicts some details we have been told about NMDA > > > > 1) the transition guidelines say otherwise > > > > New modules and modules that are not concerned with the > > operational state of configuration information SHOULD > > immediately be structured to be NMDA-compatible > > Yes, I'm suggesting we give ourselves some leeway, by taking > advantage of the SHOULD keyword above and defer updating these > two modules to when it makes more sense to do so. > > > > OK -- good. > I think another sentence needs to be added. > > > NMDA compatibility conversion MAY be deferred if the module > does not contain any configuration datastore objects. I agree. > > > > > 2) RD defines operational state to include config=false nodes > > such as counters, so these modules are properly named. > > module-name == top-level node name.  Either way, my point is that > the -state tree in these modules is not trying to provide the > opstate value for configured nodes (i.e. applied configuration). > > > So a data node naming convention is needed? > And a module naming convention? > > We need a rule that says the suffix "-state" is reserved for NMDA > compatibility > so module names and data nodes SHOULD NOT be named with an identifier that > ends in this suffix. Also agree. Thanks, Rob > > (Automation tools like deterministic rules, not naming conventions. > Here is an example why... there are always exceptions that do not follow > the conventions. Always people who are unaware of the conventions.) > > > > K. > > > > > Andy > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------001FF6F31DB488A4DD06A186 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 07/09/2017 03:36, Andy Bierman wrote:


On Wed, Sep 6, 2017 at 10:57 AM, Kent Watsen <kwatsen@juniper.net> wrote:


>> /netconf-state and /restconf-state don't seem to follow the general
>> pattern we're correcting with the various NMDA updates.  Particularly,
>> these -state trees are NOT for the purpose to providing the opstate
>> value for configured nodes.  These modules have the misfortune of
>> having "-state" in their name, but they're otherwise fine.
>
>
> This contradicts some details we have been told about NMDA
>
> 1) the transition guidelines say otherwise
>
> New modules and modules that are not concerned with the
> operational state of configuration information SHOULD
> immediately be structured to be NMDA-compatible

Yes, I'm suggesting we give ourselves some leeway, by taking
advantage of the SHOULD keyword above and defer updating these
two modules to when it makes more sense to do so.



OK -- good.
I think another sentence needs to be added.


NMDA compatibility conversion MAY be deferred if the module
does not contain any configuration datastore objects.
I agree.




> 2) RD defines operational state to include config=false nodes
> such as counters, so these modules are properly named.

module-name == top-level node name.  Either way, my point is that
the -state tree in these modules is not trying to provide the
opstate value for configured nodes (i.e. applied configuration).


So a data node naming convention is needed?
And a module naming convention?

We need a rule that says the suffix "-state" is reserved for NMDA compatibility
so module names and data nodes SHOULD NOT be named with an identifier that
ends in this suffix.
Also agree.

Thanks,
Rob



(Automation tools like deterministic rules, not naming conventions.
Here is an example why... there are always exceptions that do not follow
the conventions. Always people who are unaware of the conventions.)


 

K.




Andy



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

--------------001FF6F31DB488A4DD06A186-- From nobody Thu Sep 7 03:07:18 2017 Return-Path: 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 897331321A1; Thu, 7 Sep 2017 03:07: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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H049l2m3PS5o; Thu, 7 Sep 2017 03:07:11 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 564121320D9; Thu, 7 Sep 2017 03:07:11 -0700 (PDT) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 9B1E61AE0312; Thu, 7 Sep 2017 12:07:08 +0200 (CEST) Date: Thu, 07 Sep 2017 12:05:35 +0200 (CEST) Message-Id: <20170907.120535.1715167966300628135.mbj@tail-f.com> To: rwilton@cisco.com Cc: andy@yumaworks.com, kwatsen@juniper.net, netconf-chairs@ietf.org, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <9cd0c109-6430-a649-66b1-8228c721538d@cisco.com> References: <9cd0c109-6430-a649-66b1-8228c721538d@cisco.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] upcoming adoptions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 10:07:17 -0000 Robert Wilton wrote: > = > = > On 07/09/2017 03:36, Andy Bierman wrote: > > > > > > On Wed, Sep 6, 2017 at 10:57 AM, Kent Watsen > > wrote: > > > > > > > > >> /netconf-state and /restconf-state don't seem to follow the = general > > >> pattern we're correcting with the various NMDA updates.=A0 > > Particularly, > > >> these -state trees are NOT for the purpose to providing the = opstate > > >> value for configured nodes.=A0 These modules have the misfor= tune of > > >> having "-state" in their name, but they're otherwise fine. > > > > > > > > > This contradicts some details we have been told about NMDA > > > > > > 1) the transition guidelines say otherwise > > > > > > New modules and modules that are not concerned with the > > > operational state of configuration information SHOULD > > > immediately be structured to be NMDA-compatible > > > > Yes, I'm suggesting we give ourselves some leeway, by taking > > advantage of the SHOULD keyword above and defer updating these > > two modules to when it makes more sense to do so. > > > > > > > > OK -- good. > > I think another sentence needs to be added. > > > > > > NMDA compatibility conversion MAY be deferred if the module > > does not contain any configuration datastore objects. > I agree. +1 > > > 2) RD defines operational state to include config=3Dfalse nod= es > > > such as counters, so these modules are properly named. > > > > module-name =3D=3D top-level node name.=A0 Either way, my point= is that > > the -state tree in these modules is not trying to provide the > > opstate value for configured nodes (i.e. applied configuration)= .= > > > > > > So a data node naming convention is needed? > > And a module naming convention? > > > > We need a rule that says the suffix "-state" is reserved for NMDA > > compatibility > > so module names and data nodes SHOULD NOT be named with an identifi= er > > that > > ends in this suffix. > Also agree. -1 There are cases where a -state suffix is natural, e.g. in ietf-hardware we have admin-state, oper-state, usage-state etc. I prefer to have a recommendation that generated modules and top-level nodes are called ...-state, but that should not be a reason for making -state illegal in general. /martin From nobody Thu Sep 7 03:14:09 2017 Return-Path: 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 20558132EDE; Thu, 7 Sep 2017 03:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 MyJPmjlwIXbY; Thu, 7 Sep 2017 03:14:04 -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 1F2B613239C; Thu, 7 Sep 2017 03:14:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2661; q=dns/txt; s=iport; t=1504779244; x=1505988844; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=d8yepCE0QvanaAEqdwJ1w651E7s+O7gfQqcntdGbmds=; b=SelHKIO9kgIuJIBtUdGRIhZ0YF7yta7zlzkcGY0VF4Gj3slZW56obrnt SdxL98K3VDdaX/1lCj5D7bJpTkyzx9ayL8vD2k2HA9uReVGAtN1qPV+cu r8WKOfrnsVUSlXoLAjFPc6aKoxa8zrk8OjPAQUfVdyUz6x4aMVB9GrDCD c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DeAwBdG7FZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhSwng3eLFZBzK5g6CoU+AoRDFAECAQEBAQEBAWsohRkBBSMPAQV?= =?us-ascii?q?BEAsOCgICIwMCAkYRBg0GAgEBii2uFYIni0oBAQEBAQEBAQEBAQEBAQEBASGBD?= =?us-ascii?q?YIdg1CBYyuCfYgIgmEFkSiPTJRRi1SHHY1Xh1SBOTYhgQ0yIQgcFYdlPzaLCgE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.42,357,1500940800"; d="scan'208";a="654452075" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Sep 2017 10:14:01 +0000 Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v87AE1BS025646; Thu, 7 Sep 2017 10:14:01 GMT To: Martin Bjorklund Cc: andy@yumaworks.com, kwatsen@juniper.net, netconf-chairs@ietf.org, netmod@ietf.org References: <9cd0c109-6430-a649-66b1-8228c721538d@cisco.com> <20170907.120535.1715167966300628135.mbj@tail-f.com> From: Robert Wilton Message-ID: <232e44d5-28b9-a017-ec10-54a597a66c7b@cisco.com> Date: Thu, 7 Sep 2017 11:14:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170907.120535.1715167966300628135.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] upcoming adoptions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 10:14:06 -0000 On 07/09/2017 11:05, Martin Bjorklund wrote: > Robert Wilton wrote: >> >> On 07/09/2017 03:36, Andy Bierman wrote: >>> >>> On Wed, Sep 6, 2017 at 10:57 AM, Kent Watsen >> > wrote: >>> >>> >>> >>> >> /netconf-state and /restconf-state don't seem to follow the general >>> >> pattern we're correcting with the various NMDA updates. >>> Particularly, >>> >> these -state trees are NOT for the purpose to providing the opstate >>> >> value for configured nodes.  These modules have the misfortune of >>> >> having "-state" in their name, but they're otherwise fine. >>> > >>> > >>> > This contradicts some details we have been told about NMDA >>> > >>> > 1) the transition guidelines say otherwise >>> > >>> > New modules and modules that are not concerned with the >>> > operational state of configuration information SHOULD >>> > immediately be structured to be NMDA-compatible >>> >>> Yes, I'm suggesting we give ourselves some leeway, by taking >>> advantage of the SHOULD keyword above and defer updating these >>> two modules to when it makes more sense to do so. >>> >>> >>> >>> OK -- good. >>> I think another sentence needs to be added. >>> >>> >>> NMDA compatibility conversion MAY be deferred if the module >>> does not contain any configuration datastore objects. >> I agree. > +1 > > >>> > 2) RD defines operational state to include config=false nodes >>> > such as counters, so these modules are properly named. >>> >>> module-name == top-level node name.  Either way, my point is that >>> the -state tree in these modules is not trying to provide the >>> opstate value for configured nodes (i.e. applied configuration). >>> >>> >>> So a data node naming convention is needed? >>> And a module naming convention? >>> >>> We need a rule that says the suffix "-state" is reserved for NMDA >>> compatibility >>> so module names and data nodes SHOULD NOT be named with an identifier >>> that >>> ends in this suffix. >> Also agree. > -1 > > There are cases where a -state suffix is natural, e.g. in > ietf-hardware we have admin-state, oper-state, usage-state etc. > > I prefer to have a recommendation that generated modules and top-level > nodes are called ...-state, but that should not be a reason for making > -state illegal in general. Sorry, it was specifically modules and top level data nodes that I think this restriction should apply to. Thanks, Rob > > > /martin > . > From nobody Thu Sep 7 03:17:23 2017 Return-Path: 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 BFFB3132EDE; Thu, 7 Sep 2017 03:17:22 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xavV1Y-IHhi7; Thu, 7 Sep 2017 03:17: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 825CF132396; Thu, 7 Sep 2017 03:17:21 -0700 (PDT) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 63FF01AE0312; Thu, 7 Sep 2017 12:17:20 +0200 (CEST) Date: Thu, 07 Sep 2017 12:15:47 +0200 (CEST) Message-Id: <20170907.121547.1207208093298972388.mbj@tail-f.com> To: rwilton@cisco.com Cc: andy@yumaworks.com, kwatsen@juniper.net, netconf-chairs@ietf.org, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <232e44d5-28b9-a017-ec10-54a597a66c7b@cisco.com> References: <9cd0c109-6430-a649-66b1-8228c721538d@cisco.com> <20170907.120535.1715167966300628135.mbj@tail-f.com> <232e44d5-28b9-a017-ec10-54a597a66c7b@cisco.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] upcoming adoptions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 10:17:22 -0000 Robert Wilton wrote: > = > = > On 07/09/2017 11:05, Martin Bjorklund wrote: > > Robert Wilton wrote: > >> > >> On 07/09/2017 03:36, Andy Bierman wrote: > >>> > >>> On Wed, Sep 6, 2017 at 10:57 AM, Kent Watsen >>> > wrote: > >>> > >>> > >>> > >>> >> /netconf-state and /restconf-state don't seem to follow t= he > >>> >> general > >>> >> pattern we're correcting with the various NMDA updates. > >>> Particularly, > >>> >> these -state trees are NOT for the purpose to providing t= he > >>> >> opstate > >>> >> value for configured nodes.=A0 These modules have the mis= fortune of > >>> >> having "-state" in their name, but they're otherwise fine= .= > >>> > > >>> > > >>> > This contradicts some details we have been told about NMDA= > >>> > > >>> > 1) the transition guidelines say otherwise > >>> > > >>> > New modules and modules that are not concerned with the > >>> > operational state of configuration information SHOULD > >>> > immediately be structured to be NMDA-compatible > >>> > >>> Yes, I'm suggesting we give ourselves some leeway, by taking= > >>> advantage of the SHOULD keyword above and defer updating the= se > >>> two modules to when it makes more sense to do so. > >>> > >>> > >>> > >>> OK -- good. > >>> I think another sentence needs to be added. > >>> > >>> > >>> NMDA compatibility conversion MAY be deferred if the module > >>> does not contain any configuration datastore objects. > >> I agree. > > +1 > > > > > >>> > 2) RD defines operational state to include config=3Dfalse = nodes > >>> > such as counters, so these modules are properly named. > >>> > >>> module-name =3D=3D top-level node name.=A0 Either way, my po= int is that > >>> the -state tree in these modules is not trying to provide th= e > >>> opstate value for configured nodes (i.e. applied configurati= on). > >>> > >>> > >>> So a data node naming convention is needed? > >>> And a module naming convention? > >>> > >>> We need a rule that says the suffix "-state" is reserved for NMDA= > >>> compatibility > >>> so module names and data nodes SHOULD NOT be named with an identi= fier > >>> that > >>> ends in this suffix. > >> Also agree. > > -1 > > > > There are cases where a -state suffix is natural, e.g. in > > ietf-hardware we have admin-state, oper-state, usage-state etc. > > > > I prefer to have a recommendation that generated modules and top-le= vel > > nodes are called ...-state, but that should not be a reason for mak= ing > > -state illegal in general. > Sorry, it was specifically modules and top level data nodes that I > think this restriction should apply to. Even in this case I'd prefer to make a one-way recommendation. Is there a technical reason for not allowing a normal module or top-level node be called ...-state? IMO, *if* it is important to mark these modules as being generated, we should use a formal way to convey this information, not rely on a naming convention. (i.e., use a YANG extension in the module). /martin From nobody Thu Sep 7 03:52:02 2017 Return-Path: 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 2C38E132EE4; Thu, 7 Sep 2017 03:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 VYafdr28XTyp; Thu, 7 Sep 2017 03:51: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 A8232126D0C; Thu, 7 Sep 2017 03:51:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4681; q=dns/txt; s=iport; t=1504781518; x=1505991118; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=qL3Tf6lfbnDzsPjXYAcZpvGAADXbmFvx2a4WzDZT3II=; b=mpjiBEnD+zyM9DxYI3ctOJnHqM3ozqQhS3aq+ZAIuo5dLqkKd7Ychxgj fGmOrEzqTBYMx4R1iMEu1uGopSc38aQORimpBtJiCD1sU89i7iDQrUdMI ByAF0X27iOYlmcvUclrLhnacueCVPhITfoqD3Jj7lQZX4xSOD0x254ndi w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYBQDpIrFZ/xbLJq1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBhSwng3eLFZBzK5g6CoU+AoRDFAECAQEBAQEBAWsohRkBBSMPAQVBEAs?= =?us-ascii?q?OCgICIwMCAkYRBg0GAgEBii2tfYIni0oBAQEBAQEBAQEBAQEBAQEBASGBDYIdg?= =?us-ascii?q?1CBYysLgnKICIJhBZEoj0yKbIlli1SHHY1Xh1SBOTYhgQ0yIQgcFYdlPzaLCgE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.42,357,1500940800"; d="scan'208";a="657296553" 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; 07 Sep 2017 10:51:56 +0000 Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v87ApuLA018443; Thu, 7 Sep 2017 10:51:56 GMT To: Martin Bjorklund Cc: andy@yumaworks.com, kwatsen@juniper.net, netconf-chairs@ietf.org, netmod@ietf.org References: <9cd0c109-6430-a649-66b1-8228c721538d@cisco.com> <20170907.120535.1715167966300628135.mbj@tail-f.com> <232e44d5-28b9-a017-ec10-54a597a66c7b@cisco.com> <20170907.121547.1207208093298972388.mbj@tail-f.com> From: Robert Wilton Message-ID: <89b4053a-19de-a77b-8442-84c3d75e3457@cisco.com> Date: Thu, 7 Sep 2017 11:51:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170907.121547.1207208093298972388.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] upcoming adoptions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 10:52:01 -0000 On 07/09/2017 11:15, Martin Bjorklund wrote: > Robert Wilton wrote: >> >> On 07/09/2017 11:05, Martin Bjorklund wrote: >>> Robert Wilton wrote: >>>> On 07/09/2017 03:36, Andy Bierman wrote: >>>>> On Wed, Sep 6, 2017 at 10:57 AM, Kent Watsen >>>> > wrote: >>>>> >>>>> >>>>> >>>>> >> /netconf-state and /restconf-state don't seem to follow the >>>>> >> general >>>>> >> pattern we're correcting with the various NMDA updates. >>>>> Particularly, >>>>> >> these -state trees are NOT for the purpose to providing the >>>>> >> opstate >>>>> >> value for configured nodes.  These modules have the misfortune of >>>>> >> having "-state" in their name, but they're otherwise fine. >>>>> > >>>>> > >>>>> > This contradicts some details we have been told about NMDA >>>>> > >>>>> > 1) the transition guidelines say otherwise >>>>> > >>>>> > New modules and modules that are not concerned with the >>>>> > operational state of configuration information SHOULD >>>>> > immediately be structured to be NMDA-compatible >>>>> >>>>> Yes, I'm suggesting we give ourselves some leeway, by taking >>>>> advantage of the SHOULD keyword above and defer updating these >>>>> two modules to when it makes more sense to do so. >>>>> >>>>> >>>>> >>>>> OK -- good. >>>>> I think another sentence needs to be added. >>>>> >>>>> >>>>> NMDA compatibility conversion MAY be deferred if the module >>>>> does not contain any configuration datastore objects. >>>> I agree. >>> +1 >>> >>> >>>>> > 2) RD defines operational state to include config=false nodes >>>>> > such as counters, so these modules are properly named. >>>>> >>>>> module-name == top-level node name.  Either way, my point is that >>>>> the -state tree in these modules is not trying to provide the >>>>> opstate value for configured nodes (i.e. applied configuration). >>>>> >>>>> >>>>> So a data node naming convention is needed? >>>>> And a module naming convention? >>>>> >>>>> We need a rule that says the suffix "-state" is reserved for NMDA >>>>> compatibility >>>>> so module names and data nodes SHOULD NOT be named with an identifier >>>>> that >>>>> ends in this suffix. >>>> Also agree. >>> -1 >>> >>> There are cases where a -state suffix is natural, e.g. in >>> ietf-hardware we have admin-state, oper-state, usage-state etc. >>> >>> I prefer to have a recommendation that generated modules and top-level >>> nodes are called ...-state, but that should not be a reason for making >>> -state illegal in general. >> Sorry, it was specifically modules and top level data nodes that I >> think this restriction should apply to. > Even in this case I'd prefer to make a one-way recommendation. Is > there a technical reason for not allowing a normal module or top-level > node be called ...-state? IMO, *if* it is important to mark these > modules as being generated, we should use a formal way to convey this > information, not rely on a naming convention. (i.e., use a YANG > extension in the module). My logic is slightly different: I think that new top level containers shouldn't be called ...-state because either (i) they already contain config nodes, in which case they are misnamed, or (ii) they might be revised to contain config nodes in the future, in which case they would end up being misnamed. I basically, think that the suffix "-state" doesn't generally provide any useful extra information. Lower down the tree, I guess that using "state" or  "*-state" is OK if it can be known that the leaf/container will *always* only be state and never potentially be configurable in future.  But I still think that it is necessary to be very careful here. For example, If I designed a new routing protocol, then in v1 there might be no explicit neighbor configuration, and hence I put all of the neighbor information into a container call neighbor-state. However, if a v2 version of that protocol (or vendor extensions) wants to add some per neighbor configuration then it would hit the problem that the original container is poorly named to be updated to now also hold configuration.  So, generally avoiding "-state" in the name of containers seems to be good common sense to me.  I would suggest adding something to 6087bis, but my previous suggested additions to 6087bis didn't appear to be well received ;-) Thanks, Rob > > > /martin > . > From nobody Thu Sep 7 04:12:26 2017 Return-Path: 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 F3FFA1329AD; Thu, 7 Sep 2017 04:12:24 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCxT8KidL7Wj; Thu, 7 Sep 2017 04:12:23 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 41D33132EEA; Thu, 7 Sep 2017 04:12:23 -0700 (PDT) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 0F7DB1AE0312; Thu, 7 Sep 2017 13:12:21 +0200 (CEST) Date: Thu, 07 Sep 2017 13:10:48 +0200 (CEST) Message-Id: <20170907.131048.1841464922845786321.mbj@tail-f.com> To: rwilton@cisco.com Cc: andy@yumaworks.com, kwatsen@juniper.net, netconf-chairs@ietf.org, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <89b4053a-19de-a77b-8442-84c3d75e3457@cisco.com> References: <232e44d5-28b9-a017-ec10-54a597a66c7b@cisco.com> <20170907.121547.1207208093298972388.mbj@tail-f.com> <89b4053a-19de-a77b-8442-84c3d75e3457@cisco.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] upcoming adoptions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 11:12:25 -0000 Robert Wilton wrote: > = > = > On 07/09/2017 11:15, Martin Bjorklund wrote: > > Robert Wilton wrote: > >> > >> On 07/09/2017 11:05, Martin Bjorklund wrote: > >>> Robert Wilton wrote: > >>>> On 07/09/2017 03:36, Andy Bierman wrote: > >>>>> On Wed, Sep 6, 2017 at 10:57 AM, Kent Watsen >>>>> > wrote: > >>>>> > >>>>> > >>>>> > >>>>> >> /netconf-state and /restconf-state don't seem to follo= w the > >>>>> >> general > >>>>> >> pattern we're correcting with the various NMDA updates= .= > >>>>> Particularly, > >>>>> >> these -state trees are NOT for the purpose to providin= g the > >>>>> >> opstate > >>>>> >> value for configured nodes.=A0 These modules have the = misfortune > >>>>> >> of > >>>>> >> having "-state" in their name, but they're otherwise f= ine. > >>>>> > > >>>>> > > >>>>> > This contradicts some details we have been told about N= MDA > >>>>> > > >>>>> > 1) the transition guidelines say otherwise > >>>>> > > >>>>> > New modules and modules that are not concerned with the= > >>>>> > operational state of configuration information SHOULD > >>>>> > immediately be structured to be NMDA-compatible > >>>>> > >>>>> Yes, I'm suggesting we give ourselves some leeway, by tak= ing > >>>>> advantage of the SHOULD keyword above and defer updating = these > >>>>> two modules to when it makes more sense to do so. > >>>>> > >>>>> > >>>>> > >>>>> OK -- good. > >>>>> I think another sentence needs to be added. > >>>>> > >>>>> > >>>>> NMDA compatibility conversion MAY be deferred if the module > >>>>> does not contain any configuration datastore objects. > >>>> I agree. > >>> +1 > >>> > >>> > >>>>> > 2) RD defines operational state to include config=3Dfal= se nodes > >>>>> > such as counters, so these modules are properly named. > >>>>> > >>>>> module-name =3D=3D top-level node name.=A0 Either way, my= point is that > >>>>> the -state tree in these modules is not trying to provide= the > >>>>> opstate value for configured nodes (i.e. applied configur= ation). > >>>>> > >>>>> > >>>>> So a data node naming convention is needed? > >>>>> And a module naming convention? > >>>>> > >>>>> We need a rule that says the suffix "-state" is reserved for NM= DA > >>>>> compatibility > >>>>> so module names and data nodes SHOULD NOT be named with an iden= tifier > >>>>> that > >>>>> ends in this suffix. > >>>> Also agree. > >>> -1 > >>> > >>> There are cases where a -state suffix is natural, e.g. in > >>> ietf-hardware we have admin-state, oper-state, usage-state etc. > >>> > >>> I prefer to have a recommendation that generated modules and top-= level > >>> nodes are called ...-state, but that should not be a reason for m= aking > >>> -state illegal in general. > >> Sorry, it was specifically modules and top level data nodes that I= > >> think this restriction should apply to. > > Even in this case I'd prefer to make a one-way recommendation. Is > > there a technical reason for not allowing a normal module or top-le= vel > > node be called ...-state? IMO, *if* it is important to mark these > > modules as being generated, we should use a formal way to convey th= is > > information, not rely on a naming convention. (i.e., use a YANG > > extension in the module). > My logic is slightly different: > = > I think that new top level containers shouldn't be called ...-state > because either > (i) they already contain config nodes, in which case they are > misnamed, or > (ii) they might be revised to contain config nodes in the future, in > which case they would end up being misnamed. > = > I basically, think that the suffix "-state" doesn't generally provide= > any useful extra information. Sure. But there are many suffixes that don't generally provide useful extra information. I just think we should be careful with these kinds of rules. Bad names are hopefully catched during the review process. > Lower down the tree, I guess that using "state" or=A0 "*-state" is OK= if > it can be known that the leaf/container will *always* only be state > and never potentially be configurable in future.=A0 But I still think= > that it is necessary to be very careful here. > = > For example, If I designed a new routing protocol, then in v1 there > might be no explicit neighbor configuration, and hence I put all of > the neighbor information into a container call > neighbor-state. However, if a v2 version of that protocol (or vendor > extensions) wants to add some per neighbor configuration then it woul= d > hit the problem that the original container is poorly named to be > updated to now also hold configuration.=A0 So, generally avoiding > "-state" in the name of containers seems to be good common sense to > me. I agree. And avoid "*-config". /martin > =A0 I would suggest adding something to 6087bis, but my previous > suggested additions to 6087bis didn't appear to be well received ;-) From nobody Thu Sep 7 07:40:59 2017 Return-Path: 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 5D225132F1B for ; Thu, 7 Sep 2017 07:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hRa6gbAkpPd for ; Thu, 7 Sep 2017 07:40:55 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (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 85115132F2D for ; Thu, 7 Sep 2017 07:40:55 -0700 (PDT) Received: from cmgw4 (unknown [10.0.90.85]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id 0CC2F176200 for ; Thu, 7 Sep 2017 08:40:55 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id 6egs1w00S2SSUrH01egvG3; Thu, 07 Sep 2017 08:40:55 -0600 X-Authority-Analysis: v=2.2 cv=G8xsK5s5 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=2JCJgTwv5E4A:10 a=OUXY8nFuAAAA:8 a=sKA1r1qbxBcQxIsGX2kA:9 a=tdWI7_g2GW6xAXi9:21 a=eaqf0MCQBpGVAXKO:21 a=QEXdDO2ut3YA:10 a=cAcMbU7R10T-QSRYIcO_:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: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=qqb7G5T/s+5CxTL2VPlwuf9JAylDGPWjdnmXIDntbeM=; b=DbCq4fJ3n7bHqhR0mCGpXmHbhx jktkhOVrDHz3C8pRzYD+Z0l2d2Epj1BDGe+W5L3a5ditOHwqNRtoNHAd8M9xIkAwVAIrw3f6IvWl0 xdurD/gwTvNEvSWOS0km2R2xI; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:42006 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dpxz9-003f8p-Sq; Thu, 07 Sep 2017 08:40:51 -0600 To: Martin Bjorklund , kwatsen@juniper.net Cc: netmod@ietf.org References: <20170906.200545.1646568136744118938.mbj@tail-f.com> From: Lou Berger Message-ID: <9acc6055-c7b0-8c80-3468-72b090b9253f@labn.net> Date: Thu, 7 Sep 2017 10:40:48 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170906.200545.1646568136744118938.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.84.20 X-Exim-ID: 1dpxz9-003f8p-Sq X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:42006 X-Source-Auth: lberger@labn.net X-Email-Count: 6 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [netmod] two options for removing /foo-state trees? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 14:40:57 -0000 On 9/6/2017 2:05 PM, Martin Bjorklund wrote: > Kent Watsen wrote: >> ... >> 2) a new module name forces an update to other modules that >> importing it (e.g., to resolve XPaths), that otherwise may >> not need to be updated. > This is a major drawback! I think this is a compelling consideration. > >> 3) the approach doesn't follow what draft-dsdt-nmda-guidelines >> says in guideline (c), but this seems to be a minor point. >> 4) republishing the old module with all nodes deprecated seems >> off, but 7950 doesn't list 'status' as a substatement to >> the 'module' statement, so what else can we do? >> >> Any other pros or cons? I think a pro is that for models that are not widely implemented or referenced, they are more aligned with how we expect new NMDA-compatible models to be structured. >> >> >> Another question is if all the modules have to be updated the >> same way > In general I'd say no. An entirely new module might be the right > approach in some cases, but in the majority of cases not. I'd go the other way on this: the deprecate/obsolete/update approach should be followed for the few modules that are widely referenced.  All other modules should be replaced (via a name change) with NMDA structured modules. > For the routing modules, I don't think a new name is worth it. Do you see it as widely implemented?  Do others agree? > > /martin > > >> (which could block adoption of these drafts until we >> settled on an approach), or do we let each module update in a >> way that suites it best base on, e.g., how deployed it is, how >> often it's been imported by other drafts, etc. Thoughts? >> >> >> Kent // contributor >> >> >> ... From nobody Thu Sep 7 07:54:24 2017 Return-Path: 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 D773D132F43 for ; Thu, 7 Sep 2017 07:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 DbCmxMbU5Zr6 for ; Thu, 7 Sep 2017 07:54:20 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00BF3132F3E for ; Thu, 7 Sep 2017 07:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3326; q=dns/txt; s=iport; t=1504796059; x=1506005659; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rFkzQJs1/1CzTabnIw4ds/A5PJYz5E51fQkF0MguLNE=; b=W1nlIgTddsJgc5fXxNmQWEUU0IRYRMaWJ5DPHDjcBWXbdRXJMdFXBOwj LMgjNq2l34Vy7t9wd6cuYJkZ4UeP9dRp663RDOXEAU87Rvakt+yKD0kvC zBaspdhlYd3nD2OZnI/pFvwIWUcZmhw4ONSt5KmWoIk8b9bb8lBtRpUcs U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A5AQAJXbFZ/4ENJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbicHg3CKIZAggXGWKIISChgLhExPAhqDaT8YAQIBAQEBAQE?= =?us-ascii?q?BayiFGQEBAQMBASEROgsQAgEIDgoCAiYCAgIlCxUQAgQBDQWKMRCtSYIni0UBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEYBYENgh2CAoMxgyiEQYNHgmEFkSiPTAKUT4I?= =?us-ascii?q?TkF6JfIsCAhEZAYE4AR84gQ13FUmHG3aJe4EPAQEB?= X-IronPort-AV: E=Sophos;i="5.42,358,1500940800"; d="scan'208";a="290613002" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Sep 2017 14:54:18 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v87EsIhd020738 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Sep 2017 14:54:19 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 7 Sep 2017 10:54:18 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1263.000; Thu, 7 Sep 2017 10:54:18 -0400 From: "Acee Lindem (acee)" To: Lou Berger , Martin Bjorklund , "kwatsen@juniper.net" CC: "netmod@ietf.org" Thread-Topic: [netmod] two options for removing /foo-state trees? Thread-Index: AQHTJzZlKMfT3FTQbEyg9FUCwcWxgKKoaiaAgAFZEgD//8CXgA== Date: Thu, 7 Sep 2017 14:54:18 +0000 Message-ID: References: <20170906.200545.1646568136744118938.mbj@tail-f.com> <9acc6055-c7b0-8c80-3468-72b090b9253f@labn.net> In-Reply-To: <9acc6055-c7b0-8c80-3468-72b090b9253f@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="utf-8" Content-ID: <4ABAC7D418C1EA428E43B0C28EB308C5@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] two options for removing /foo-state trees? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 14:54:22 -0000 T2sgLSBpdCBpcyBsZXNzIHBhaW5mdWwgaWYgd2Ugb25seSBoYXZlIHRvIGRlcHJlY2F0ZSB0aGUg Ki1zdGF0ZSBub2Rlcy4NCkhvd2V2ZXIsIHdoYXQgYWJvdXQgc2Vjb25kYXJ5IGFuZCB0ZXJ0aWFy eSBpbXBsaWNhdGlvbnMgb2YgbW92aW5nIHRvIE5ETUE/DQpJZiB3ZSBjaGFuZ2UgYSBwYXRoIGZy b20g4oCcaW50ZXJmYWNlLXN0YXRlLXJlZuKAnSB0byDigJxpbnRlcmZhY2UtcmVm4oCdIHRvDQpy ZWZlcmVuY2UgYW4gaW50ZXJmYWNlLCBJ4oCZZCBob3BlIG5vIG9uZSB3b3VsZCBleHBlY3QgdGhl IG9sZCBzdGF0ZW1lbnQgdG8NCmJlIGtlcHQgYXJvdW5k4oCmIA0KDQpUaGFua3MsDQpBY2VlIA0K DQpPbiA5LzcvMTcsIDEwOjQwIEFNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBMb3UgQmVyZ2VyIg0K PG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBsYmVyZ2VyQGxhYm4ubmV0PiB3 cm90ZToNCg0KPg0KPg0KPk9uIDkvNi8yMDE3IDI6MDUgUE0sIE1hcnRpbiBCam9ya2x1bmQgd3Jv dGU6DQo+PiBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4gd3JvdGU6DQo+Pj4gLi4u DQo+DQo+Pj4gIDIpIGEgbmV3IG1vZHVsZSBuYW1lIGZvcmNlcyBhbiB1cGRhdGUgdG8gb3RoZXIg bW9kdWxlcyB0aGF0DQo+Pj4gICAgIGltcG9ydGluZyBpdCAoZS5nLiwgdG8gcmVzb2x2ZSBYUGF0 aHMpLCB0aGF0IG90aGVyd2lzZSBtYXkNCj4+PiAgICAgbm90IG5lZWQgdG8gYmUgdXBkYXRlZC4N Cj4+IFRoaXMgaXMgYSBtYWpvciBkcmF3YmFjayENCj5JIHRoaW5rIHRoaXMgaXMgYSBjb21wZWxs aW5nIGNvbnNpZGVyYXRpb24uDQo+DQo+Pg0KPj4+ICAzKSB0aGUgYXBwcm9hY2ggZG9lc24ndCBm b2xsb3cgd2hhdCBkcmFmdC1kc2R0LW5tZGEtZ3VpZGVsaW5lcw0KPj4+ICAgICBzYXlzIGluIGd1 aWRlbGluZSAoYyksIGJ1dCB0aGlzIHNlZW1zIHRvIGJlIGEgbWlub3IgcG9pbnQuDQo+Pj4gIDQp IHJlcHVibGlzaGluZyB0aGUgb2xkIG1vZHVsZSB3aXRoIGFsbCBub2RlcyBkZXByZWNhdGVkIHNl ZW1zDQo+Pj4gICAgIG9mZiwgYnV0IDc5NTAgZG9lc24ndCBsaXN0ICdzdGF0dXMnIGFzIGEgc3Vi c3RhdGVtZW50IHRvDQo+Pj4gICAgIHRoZSAnbW9kdWxlJyBzdGF0ZW1lbnQsIHNvIHdoYXQgZWxz ZSBjYW4gd2UgZG8/DQo+Pj4NCj4+PiBBbnkgb3RoZXIgcHJvcyBvciBjb25zPw0KPg0KPkkgdGhp bmsgYSBwcm8gaXMgdGhhdCBmb3IgbW9kZWxzIHRoYXQgYXJlIG5vdCB3aWRlbHkgaW1wbGVtZW50 ZWQgb3INCj5yZWZlcmVuY2VkLCB0aGV5IGFyZSBtb3JlIGFsaWduZWQgd2l0aCBob3cgd2UgZXhw ZWN0IG5ldyBOTURBLWNvbXBhdGlibGUNCj5tb2RlbHMgdG8gYmUgc3RydWN0dXJlZC4NCj4NCj4+ Pg0KPj4+DQo+Pj4gQW5vdGhlciBxdWVzdGlvbiBpcyBpZiBhbGwgdGhlIG1vZHVsZXMgaGF2ZSB0 byBiZSB1cGRhdGVkIHRoZQ0KPj4+IHNhbWUgd2F5DQo+PiBJbiBnZW5lcmFsIEknZCBzYXkgbm8u ICBBbiBlbnRpcmVseSBuZXcgbW9kdWxlIG1pZ2h0IGJlIHRoZSByaWdodA0KPj4gYXBwcm9hY2gg aW4gc29tZSBjYXNlcywgYnV0IGluIHRoZSBtYWpvcml0eSBvZiBjYXNlcyBub3QuDQo+SSdkIGdv IHRoZSBvdGhlciB3YXkgb24gdGhpczogdGhlIGRlcHJlY2F0ZS9vYnNvbGV0ZS91cGRhdGUgYXBw cm9hY2gNCj5zaG91bGQgYmUgZm9sbG93ZWQgZm9yIHRoZSBmZXcgbW9kdWxlcyB0aGF0IGFyZSB3 aWRlbHkgcmVmZXJlbmNlZC4gIEFsbA0KPm90aGVyIG1vZHVsZXMgc2hvdWxkIGJlIHJlcGxhY2Vk ICh2aWEgYSBuYW1lIGNoYW5nZSkgd2l0aCBOTURBDQo+c3RydWN0dXJlZCBtb2R1bGVzLg0KPg0K Pj4gRm9yIHRoZSByb3V0aW5nIG1vZHVsZXMsIEkgZG9uJ3QgdGhpbmsgYSBuZXcgbmFtZSBpcyB3 b3J0aCBpdC4NCj5EbyB5b3Ugc2VlIGl0IGFzIHdpZGVseSBpbXBsZW1lbnRlZD8gIERvIG90aGVy cyBhZ3JlZT8NCj4NCj4+DQo+PiAvbWFydGluDQo+Pg0KPj4NCj4+PiAod2hpY2ggY291bGQgYmxv Y2sgYWRvcHRpb24gb2YgdGhlc2UgZHJhZnRzIHVudGlsIHdlDQo+Pj4gc2V0dGxlZCBvbiBhbiBh cHByb2FjaCksIG9yIGRvIHdlIGxldCBlYWNoIG1vZHVsZSB1cGRhdGUgaW4gYQ0KPj4+IHdheSB0 aGF0IHN1aXRlcyBpdCBiZXN0IGJhc2Ugb24sIGUuZy4sIGhvdyBkZXBsb3llZCBpdCBpcywgaG93 DQo+Pj4gb2Z0ZW4gaXQncyBiZWVuIGltcG9ydGVkIGJ5IG90aGVyIGRyYWZ0cywgZXRjLiAgVGhv dWdodHM/DQo+Pj4NCj4+Pg0KPj4+IEtlbnQgIC8vIGNvbnRyaWJ1dG9yDQo+Pj4NCj4+Pg0KPj4+ DQo+Li4uDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj5uZXRtb2QgbWFpbGluZyBsaXN0DQo+bmV0bW9kQGlldGYub3JnDQo+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0K From nobody Thu Sep 7 10:52:02 2017 Return-Path: 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 14C88132F1B for ; Thu, 7 Sep 2017 10:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wT3bfbfhVVLp for ; Thu, 7 Sep 2017 10:51:56 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 9CC84132930 for ; Thu, 7 Sep 2017 10:51:56 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id g142so377085ita.0 for ; Thu, 07 Sep 2017 10:51:56 -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=V6lVKl2xb3kl1HFxVmFpbEiI3E0YtAasNzVllQOpOUs=; b=PGmDSG5aZrl/g0AjR+zvxoYj/O7hvcwGTdauzQPyw1NIPPWCJbFoLOX3XwVIqeJ8d2 RKfGWhZEfkWspcZftZF/PrglLcGEv2zPg+A5GL2+fo94mrh9W9VPopor0xM2+UxB8egV De9M+bz8++7EoUyk+BVzNaktvd7ryw/9v9mu82RmLattDHuFcI8ZmQQNmZytd9kzy4E0 x3h+nCvTblYOC7q/xY44rmLuuw/odNSpFKxlU+loxOsyOegIAekvCgwEUg5PrAzr3cW7 05Zf1H+fzz8sC0vdYiWDzl0ahXM23ZPjN37Q+HHBRWN48FHdD2Jk/xs9UfLe81avNr7r NL2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=V6lVKl2xb3kl1HFxVmFpbEiI3E0YtAasNzVllQOpOUs=; b=lqRX20EoAgt5Xtz769822Zfm6WOKW6Y+egfW94FzuMtn9NG1KsBhxRXip6WMOWVmlw aUXtHkSqCIEU1QBfAOjvAlFMAmTbgboGcetzyUqFKBOk2fm9c/C1xD/0wswXR5SWEry1 1anUxDbuAxqYmOFPmFlKBNnUf+UfM84RcJCarTMrhE4MyoJJJMHK46ozCm+8U0acLsxm nXgsejDuOmxesME082Z3+ggpVGneF1p3s3hkWGDzNJFESlk3HcFrYL2sBasPPTURNykh wlLXP9Hgu40POnt6Q1DfmuyyQG6FNYiptRjrebc1GqAKDqXxhBZfmDJoCd7ADBbEM3JG TebQ== X-Gm-Message-State: AHPjjUhUMXDRjNXMTCDZwdKEV4tFGS0WwGoyb/YFhIC5MNvpgetBvYrm HYKYGfut2Z4n6A2sduvl+s/f1zWJPAjd X-Google-Smtp-Source: ADKCNb65WMYaCOz5+ne9cYuY99EwAP6KNkU/Wael55m9aFY92QIW8pnrGdB/CaoNzcTZDR/ZjobV9KUyJYL/iraF8D8= X-Received: by 10.36.40.138 with SMTP id h132mr161264ith.26.1504806715808; Thu, 07 Sep 2017 10:51:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.6.206 with HTTP; Thu, 7 Sep 2017 10:51:54 -0700 (PDT) In-Reply-To: <20170907.131048.1841464922845786321.mbj@tail-f.com> References: <232e44d5-28b9-a017-ec10-54a597a66c7b@cisco.com> <20170907.121547.1207208093298972388.mbj@tail-f.com> <89b4053a-19de-a77b-8442-84c3d75e3457@cisco.com> <20170907.131048.1841464922845786321.mbj@tail-f.com> From: Andy Bierman Date: Thu, 7 Sep 2017 10:51:54 -0700 Message-ID: To: Martin Bjorklund Cc: Robert Wilton , Kent Watsen , NETCONF Working Group , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="001a113f62ecc090ff05589d1dd2" Archived-At: Subject: Re: [netmod] upcoming adoptions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 17:52:00 -0000 --001a113f62ecc090ff05589d1dd2 Content-Type: text/plain; charset="UTF-8" Hi, I suggested the naming guideline because the NMDA design team decided to add semantics to certain naming patterns, so authors have to be warned. But this is a really bad idea (and slippery slope). First we tell everybody "these are just identifiers, pick any string you want", then we want to change it 8 years later to "except these strings which mean special things". The proper deterministic way to identify that the module or subtree is special is to tag it with a YANG extension. Adding semantics to the user-selected identifier space 8 years after dozens of exceptions already exist is not a great plan. If anybody ever actually implements this NMDA stuff, I think they will find it useful to identify modules written for specific datastore usage, or if the module is an NMDA transition module, an I2RS-specific module, etc. The extension you suggested in another email would work. Andy On Thu, Sep 7, 2017 at 4:10 AM, Martin Bjorklund wrote: > Robert Wilton wrote: > > > > > > On 07/09/2017 11:15, Martin Bjorklund wrote: > > > Robert Wilton wrote: > > >> > > >> On 07/09/2017 11:05, Martin Bjorklund wrote: > > >>> Robert Wilton wrote: > > >>>> On 07/09/2017 03:36, Andy Bierman wrote: > > >>>>> On Wed, Sep 6, 2017 at 10:57 AM, Kent Watsen > >>>>> > wrote: > > >>>>> > > >>>>> > > >>>>> > > >>>>> >> /netconf-state and /restconf-state don't seem to follow > the > > >>>>> >> general > > >>>>> >> pattern we're correcting with the various NMDA updates. > > >>>>> Particularly, > > >>>>> >> these -state trees are NOT for the purpose to providing > the > > >>>>> >> opstate > > >>>>> >> value for configured nodes. These modules have the > misfortune > > >>>>> >> of > > >>>>> >> having "-state" in their name, but they're otherwise fine. > > >>>>> > > > >>>>> > > > >>>>> > This contradicts some details we have been told about NMDA > > >>>>> > > > >>>>> > 1) the transition guidelines say otherwise > > >>>>> > > > >>>>> > New modules and modules that are not concerned with the > > >>>>> > operational state of configuration information SHOULD > > >>>>> > immediately be structured to be NMDA-compatible > > >>>>> > > >>>>> Yes, I'm suggesting we give ourselves some leeway, by taking > > >>>>> advantage of the SHOULD keyword above and defer updating > these > > >>>>> two modules to when it makes more sense to do so. > > >>>>> > > >>>>> > > >>>>> > > >>>>> OK -- good. > > >>>>> I think another sentence needs to be added. > > >>>>> > > >>>>> > > >>>>> NMDA compatibility conversion MAY be deferred if the module > > >>>>> does not contain any configuration datastore objects. > > >>>> I agree. > > >>> +1 > > >>> > > >>> > > >>>>> > 2) RD defines operational state to include config=false > nodes > > >>>>> > such as counters, so these modules are properly named. > > >>>>> > > >>>>> module-name == top-level node name. Either way, my point is > that > > >>>>> the -state tree in these modules is not trying to provide the > > >>>>> opstate value for configured nodes (i.e. applied > configuration). > > >>>>> > > >>>>> > > >>>>> So a data node naming convention is needed? > > >>>>> And a module naming convention? > > >>>>> > > >>>>> We need a rule that says the suffix "-state" is reserved for NMDA > > >>>>> compatibility > > >>>>> so module names and data nodes SHOULD NOT be named with an > identifier > > >>>>> that > > >>>>> ends in this suffix. > > >>>> Also agree. > > >>> -1 > > >>> > > >>> There are cases where a -state suffix is natural, e.g. in > > >>> ietf-hardware we have admin-state, oper-state, usage-state etc. > > >>> > > >>> I prefer to have a recommendation that generated modules and > top-level > > >>> nodes are called ...-state, but that should not be a reason for > making > > >>> -state illegal in general. > > >> Sorry, it was specifically modules and top level data nodes that I > > >> think this restriction should apply to. > > > Even in this case I'd prefer to make a one-way recommendation. Is > > > there a technical reason for not allowing a normal module or top-level > > > node be called ...-state? IMO, *if* it is important to mark these > > > modules as being generated, we should use a formal way to convey this > > > information, not rely on a naming convention. (i.e., use a YANG > > > extension in the module). > > My logic is slightly different: > > > > I think that new top level containers shouldn't be called ...-state > > because either > > (i) they already contain config nodes, in which case they are > > misnamed, or > > (ii) they might be revised to contain config nodes in the future, in > > which case they would end up being misnamed. > > > > I basically, think that the suffix "-state" doesn't generally provide > > any useful extra information. > > Sure. But there are many suffixes that don't generally provide useful > extra information. I just think we should be careful with these kinds > of rules. Bad names are hopefully catched during the review process. > > > Lower down the tree, I guess that using "state" or "*-state" is OK if > > it can be known that the leaf/container will *always* only be state > > and never potentially be configurable in future. But I still think > > that it is necessary to be very careful here. > > > > For example, If I designed a new routing protocol, then in v1 there > > might be no explicit neighbor configuration, and hence I put all of > > the neighbor information into a container call > > neighbor-state. However, if a v2 version of that protocol (or vendor > > extensions) wants to add some per neighbor configuration then it would > > hit the problem that the original container is poorly named to be > > updated to now also hold configuration. So, generally avoiding > > "-state" in the name of containers seems to be good common sense to > > me. > > I agree. And avoid "*-config". > > > > /martin > > > > I would suggest adding something to 6087bis, but my previous > > suggested additions to 6087bis didn't appear to be well received ;-) > > --001a113f62ecc090ff05589d1dd2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I suggested the naming guideline be= cause the NMDA design team decided to
add semantics to certain na= ming patterns, so authors have to be warned.

But t= his is a really bad idea (and slippery slope).
First we tell ever= ybody "these are just identifiers, pick any string you want",
then we want to change it 8 years later to "except these string= s which mean special things".

The proper dete= rministic way to identify that the module or subtree is special
i= s to tag it with a YANG extension. Adding semantics to the user-selected id= entifier space=C2=A0
8 years after dozens of exceptions already e= xist is not a great plan.

If anybody ever actually= implements this NMDA stuff, I think they will find
it useful to = identify modules written for specific datastore usage, or
if the = module is an NMDA transition module, an I2RS-specific module, etc.
The extension you suggested in another email would work.


Andy


On Thu, Sep 7, 2017 at 4:10 AM, Martin= Bjorklund <mbj@tail-f.com> wrote:
Robert Wilton <rwilton@cisc= o.com> wrote:
>
>
> On 07/09/2017 11:15, Martin Bjorklund wrote:
> > Robert Wilton <rwilton@ci= sco.com> wrote:
> >>
> >> On 07/09/2017 11:05, Martin Bjorklund wrote:
> >>> Robert Wilton <rw= ilton@cisco.com> wrote:
> >>>> On 07/09/2017 03:36, Andy Bierman wrote:
> >>>>> On Wed, Sep 6, 2017 at 10:57 AM, Kent Watsen <= kwatsen@juniper.net
> >>>>> <mailto:kwatsen@juniper.net>> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0>> /netconf-state= and /restconf-state don't seem to follow the
> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0>> general
> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0>> pattern we'= ;re correcting with the various NMDA updates.
> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Particularly,
> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0>> these -state t= rees are NOT for the purpose to providing the
> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0>> opstate
> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0>> value for conf= igured nodes.=C2=A0 These modules have the misfortune
> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0>> of
> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0>> having "-= state" in their name, but they're otherwise fine.
> >>>>>=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 contradicts s= ome details we have been told about NMDA
> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0> 1) the transition = guidelines say otherwise
> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0> New modules and mo= dules that are not concerned with the
> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0> operational state = of configuration information SHOULD
> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0> immediately be str= uctured to be NMDA-compatible
> >>>>>
> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Yes, I'm suggesting= we give ourselves some leeway, by taking
> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0advantage of the SHOULD= keyword above and defer updating these
> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0two modules to when it = makes more sense to do so.
> >>>>>
> >>>>>
> >>>>>
> >>>>> OK -- good.
> >>>>> I think another sentence needs to be added.
> >>>>>
> >>>>>
> >>>>> NMDA compatibility conversion MAY be deferred if = the module
> >>>>> does not contain any configuration datastore obje= cts.
> >>>> I agree.
> >>> +1
> >>>
> >>>
> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0> 2) RD defines oper= ational state to include config=3Dfalse nodes
> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0> such as counters, = so these modules are properly named.
> >>>>>
> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0module-name =3D=3D top-= level node name.=C2=A0 Either way, my point is that
> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0the -state tree in thes= e modules is not trying to provide the
> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0opstate value for confi= gured nodes (i.e. applied configuration).
> >>>>>
> >>>>>
> >>>>> So a data node naming convention is needed?
> >>>>> And a module naming convention?
> >>>>>
> >>>>> We need a rule that says the suffix "-state&= quot; is reserved for NMDA
> >>>>> compatibility
> >>>>> so module names and data nodes SHOULD NOT be name= d with an identifier
> >>>>> that
> >>>>> ends in this suffix.
> >>>> Also agree.
> >>> -1
> >>>
> >>> There are cases where a -state suffix is natural, e.g. in=
> >>> ietf-hardware we have admin-state, oper-state, usage-stat= e etc.
> >>>
> >>> I prefer to have a recommendation that generated modules = and top-level
> >>> nodes are called ...-state, but that should not be a reas= on for making
> >>> -state illegal in general.
> >> Sorry, it was specifically modules and top level data nodes t= hat I
> >> think this restriction should apply to.
> > Even in this case I'd prefer to make a one-way recommendation= .=C2=A0 Is
> > there a technical reason for not allowing a normal module or top-= level
> > node be called ...-state?=C2=A0 IMO, *if* it is important to mark= these
> > modules as being generated, we should use a formal way to convey = this
> > information, not rely on a naming convention.=C2=A0 (i.e., use a = YANG
> > extension in the module).
> My logic is slightly different:
>
> I think that new top level containers shouldn't be called ...-stat= e
> because either
> (i) they already contain config nodes, in which case they are
> misnamed, or
> (ii) they might be revised to contain config nodes in the future, in > which case they would end up being misnamed.
>
> I basically, think that the suffix "-state" doesn't gene= rally provide
> any useful extra information.

Sure.=C2=A0 But there are many suffixes that don't generally provide us= eful
extra information.=C2=A0 I just think we should be careful with these kinds=
of rules.=C2=A0 Bad names are hopefully catched during the review process.<= br>
> Lower down the tree, I guess that using "state" or=C2=A0 &qu= ot;*-state" is OK if
> it can be known that the leaf/container will *always* only be state > and never potentially be configurable in future.=C2=A0 But I still thi= nk
> that it is necessary to be very careful here.
>
> For example, If I designed a new routing protocol, then in v1 there > might be no explicit neighbor configuration, and hence I put all of > the neighbor information into a container call
> neighbor-state. However, if a v2 version of that protocol (or vendor > extensions) wants to add some per neighbor configuration then it would=
> hit the problem that the original container is poorly named to be
> updated to now also hold configuration.=C2=A0 So, generally avoiding > "-state" in the name of containers seems to be good common s= ense to
> me.

I agree.=C2=A0 And avoid "*-config".



/martin


> =C2=A0 I would suggest adding something to 6087bis, but my previous > suggested additions to 6087bis didn't appear to be well received ;= -)


--001a113f62ecc090ff05589d1dd2-- From nobody Thu Sep 7 12:30:48 2017 Return-Path: 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 0E8C6132964 for ; Thu, 7 Sep 2017 12:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.011 X-Spam-Level: X-Spam-Status: No, score=-3.011 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 EpS9P51bXPl4 for ; Thu, 7 Sep 2017 12:30:46 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0131.outbound.protection.outlook.com [104.47.33.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CF76132811 for ; Thu, 7 Sep 2017 12:30:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8T8Hhmqo4YHy4i2to7AmXw4+ItBQj40Cujo6G2ixNQs=; b=L7lHIee3CcEvsUqCkTu2Vm0icXAtNhhWlaexbIb4vMZOF2+FCzAeEQZR2aZQNqbSlFqDhK/+deYgeD0onJlSZQ+fxpbZdTBUXdui60BkItxlIq8pFdyEGENrraT33Z+fBsd5ij5SQCC20kTYfg2rfKeyI5IZGoivPNWn6h1+Whs= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1251.namprd05.prod.outlook.com (10.160.183.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Thu, 7 Sep 2017 19:30:44 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.20.0056.003; Thu, 7 Sep 2017 19:30:44 +0000 From: Kent Watsen To: "Acee Lindem (acee)" , Lou Berger , Martin Bjorklund CC: "netmod@ietf.org" Thread-Topic: [netmod] two options for removing /foo-state trees? Thread-Index: AQHTJzZlKMfT3FTQbEyg9FUCwcWxgKKoJxiAgAFZEgCAAAPFAIAACi2A Date: Thu, 7 Sep 2017 19:30:44 +0000 Message-ID: References: <20170906.200545.1646568136744118938.mbj@tail-f.com> <9acc6055-c7b0-8c80-3468-72b090b9253f@labn.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.20.0.170309 x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1251; 6:PhVC6r6aB48HY2gCWiyXdmYUwDqdkjYKwOzpyjBDnckuMrl/8uwCYcecyZiKiOyNSr9WxaTexG7lcXh5buNY++Cd9CIXVByVnISpF4o9Z74pbd3g8BmSC61EE1+5TZMfX/VJahP4XF2SaVIF/oAxoU3kWGiG6Es/7h2t3p3achzVyY4TjndaWgTrzhLEkMWk6SQPXFgn5bUMF2AI6zo+cJd1tZ/zoeIB4cHIefcoyMLwZ/F05OFJhiALX7uWhcA/1jdFrmuzk5KL1q/nTL3UkSuMKMNf2B1xJ8NR6GEorXB6rkwuKnZDDfYkCJMkTxscfk9mYf5dDPXAWfB2oRE8iw==; 5:+B45SSgdY5pRtMeHLWlugYKFKy+t/VmMQOJbeUbZoSRnvNxpC6mmiykZFK77clY8WedUy4tZt5MmF5mEJ7z+mIf8BqgW8iSJnRmVx480B8ApKbgC2Dx0DYOO+QYS7RTqclgBR8YIoObcmMm1ni9fuw==; 24:09e6OWpLGGRDT7qcVOkKVlFqS3KSR7PPWLmoqsegK3o0WKDh0uaQcXVV18eAAOAuE1MGyYEN33CHDm9XV+2KBjpnXhxzVqO80fGsucQJ3kg=; 7:D362OPLq2X8N6J+G8H0nTwIX+fxducDyFm0DCA1jSOlAjGVuu3rQ4jd+jWtlz7wHFXyEw9s+Jv5aC50bP5t+oUxv6AKG6C2bf2cHnu4ZPvZBKG+dCxy+nI2NmwQ3f3BeCet5hqwH3sp4CnQL89enRpoRRDejdjMeN/5gg2CLYATjS51Nay4eJqR2x27aqUj+hkLTj3oLPGn74E7Yxi919SuELrZSVR2VMLDBmKKXdRI= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 93168d81-e9e8-4f98-e902-08d4f626eef7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1251; x-ms-traffictypediagnostic: BN3PR0501MB1251: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123560025)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1251; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1251; x-forefront-prvs: 04238CD941 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(189002)(199003)(6436002)(81156014)(8936002)(8676002)(305945005)(229853002)(81166006)(68736007)(7736002)(86362001)(83506001)(83716003)(6512007)(6246003)(6506006)(6486002)(77096006)(82746002)(2950100002)(97736004)(4001350100001)(99286003)(14454004)(36756003)(189998001)(53936002)(66066001)(3280700002)(25786009)(2900100001)(3846002)(105586002)(106356001)(101416001)(6116002)(3660700001)(33656002)(4326008)(102836003)(54356999)(478600001)(93886005)(50986999)(5660300001)(76176999)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1251; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <9B30A4EB3516AE4BAA7F12823C985F64@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Sep 2017 19:30:44.4028 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1251 Archived-At: Subject: Re: [netmod] two options for removing /foo-state trees? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 19:30:48 -0000 SGkgQWNlZSwNCg0KPiBPayAtIGl0IGlzIGxlc3MgcGFpbmZ1bCBpZiB3ZSBvbmx5IGhhdmUgdG8g ZGVwcmVjYXRlIHRoZSAqLXN0YXRlIG5vZGVzLg0KDQpEb2VzIHRoaXMgbWVhbiB5b3UncmUgb2th eSByZXBvc3RpbmcgeW91ciBJRCBzaW1pbGFyIHRvIE1hcnRpbidzPw0KSSBhc2sgYXMgYSBjaGFp ciBpbnRlcmVzdGVkIGluIHN0YXJ0aW5nIHRoZSBhZG9wdGlvbiBwcm9jZXNzIG9uDQp0aGVzZSBu bWRhLXVwZGF0ZSBkcmFmdHMuDQoNCj4gSG93ZXZlciwgd2hhdCBhYm91dCBzZWNvbmRhcnkgYW5k IHRlcnRpYXJ5IGltcGxpY2F0aW9ucyBvZiBtb3ZpbmcgdG8NCj4gTkRNQT8gSWYgd2UgY2hhbmdl IGEgcGF0aCBmcm9tIOKAnGludGVyZmFjZS1zdGF0ZS1yZWbigJ0gdG8g4oCcaW50ZXJmYWNlLXJl ZuKAnQ0KPiB0byByZWZlcmVuY2UgYW4gaW50ZXJmYWNlLCBJ4oCZZCBob3BlIG5vIG9uZSB3b3Vs ZCBleHBlY3QgdGhlIG9sZA0KPiBzdGF0ZW1lbnQgdG8gYmUga2VwdCBhcm91bmTigKYgDQoNCkJ1 dCB0aGUgb2xkIHN0YXRlbWVudCB3b3VsZCBiZSBrZXB0IGFyb3VuZCwgaW4gaXRzIGRlcHJlY2F0 ZWQgZm9ybS4NCk9mIGNvdXJzZSwgdGhlIG5tZGEtZ3VpZGVsaW5lcyBzaG91bGQgY2F1c2UgdGhv c2UgZG93bnN0cmVhbSBtb2R1bGVzDQp0byBiZSB1cGRhdGVkIHRvIE5NREEgYXMgd2VsbCwgc28g aG9wZWZ1bGx5IGp1c3QgYSBzaG9ydC1saXZlZCBpc3N1ZS4NCg0KDQpLZW50DQoNCg0K From nobody Thu Sep 7 12:43:52 2017 Return-Path: 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 C1499132FB2 for ; Thu, 7 Sep 2017 12:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 RPx3nNHWoJ_K for ; Thu, 7 Sep 2017 12:43:49 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62104132FAF for ; Thu, 7 Sep 2017 12:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1668; q=dns/txt; s=iport; t=1504813429; x=1506023029; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=l67uwaaLbGg5NxurFPeBMSRgOqz1My6awwmjExEb1RY=; b=UkI5614ZbX4GzX+xjODk9g+CITZTCbqFsv1wW4EY/uCyaG34LkulU9wY NH7PjAeIs6sQl3IYDF76iGQgxeorEb10xpDG/F40VTw8t/OZH59Uc8hsN oUcbXs3VvUpfoQDYbYzgyKtmabFpUoOogttCX9vdi1t5zYP+8nf0tnoB2 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AsAwAGobFZ/4QNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1qBUicHg3CaQporCoU+AhqDaVcBAgEBAQEBAmsohRkGIxFFEAI?= =?us-ascii?q?BCA4MAiYCAgIwFRACBAENBYoxrU+CJ4s8AQEBAQEBAQEBAQEBAQEBAQEBAQEBH?= =?us-ascii?q?YENgh2CAoMxgyiICIJhAQSRKI9MApRPghOQXol8iwICERkBgTgBV4ENdxWHZHa?= =?us-ascii?q?JGoEPAQEB?= X-IronPort-AV: E=Sophos;i="5.42,360,1500940800"; d="scan'208";a="367845" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Sep 2017 19:43:48 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v87Jhm9B032138 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Sep 2017 19:43:48 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 7 Sep 2017 15:43:47 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1263.000; Thu, 7 Sep 2017 15:43:47 -0400 From: "Acee Lindem (acee)" To: Kent Watsen , Lou Berger , "Martin Bjorklund" CC: "netmod@ietf.org" Thread-Topic: [netmod] two options for removing /foo-state trees? Thread-Index: AQHTJzZlKMfT3FTQbEyg9FUCwcWxgKKoaiaAgAFZEgD//8CXgIAAkGoA///AdoA= Date: Thu, 7 Sep 2017 19:43:47 +0000 Message-ID: References: <20170906.200545.1646568136744118938.mbj@tail-f.com> <9acc6055-c7b0-8c80-3468-72b090b9253f@labn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="utf-8" Content-ID: <2B13004F4F1DAF4690AD24ADE054D87E@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] two options for removing /foo-state trees? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 19:43:51 -0000 SGkgS2VudCwgDQoNCk9uIDkvNy8xNywgMzozMCBQTSwgIktlbnQgV2F0c2VuIiA8a3dhdHNlbkBq dW5pcGVyLm5ldD4gd3JvdGU6DQoNCj5IaSBBY2VlLA0KPg0KPj4gT2sgLSBpdCBpcyBsZXNzIHBh aW5mdWwgaWYgd2Ugb25seSBoYXZlIHRvIGRlcHJlY2F0ZSB0aGUgKi1zdGF0ZSBub2Rlcy4NCj4N Cj5Eb2VzIHRoaXMgbWVhbiB5b3UncmUgb2theSByZXBvc3RpbmcgeW91ciBJRCBzaW1pbGFyIHRv IE1hcnRpbidzPw0KPkkgYXNrIGFzIGEgY2hhaXIgaW50ZXJlc3RlZCBpbiBzdGFydGluZyB0aGUg YWRvcHRpb24gcHJvY2VzcyBvbg0KPnRoZXNlIG5tZGEtdXBkYXRlIGRyYWZ0cy4NCg0KSSB3b3Vs ZCBob3BlIHRoaXMgaXMgbm90IGEgcHJlcmVxdWlzaXRlPyBXZSBhcmUgZXZhbHVhdGluZyBob3cg YmFkIHRoaXMNCndpbGwgYmUuIEnigJlkIGFzayBob3cgbWFueSBpbXBsZW1lbnRhdGlvbnMgdGhl cmUgYXJlIG9mIGlldGYtcm91dGluZz8NCj4NCj4+IEhvd2V2ZXIsIHdoYXQgYWJvdXQgc2Vjb25k YXJ5IGFuZCB0ZXJ0aWFyeSBpbXBsaWNhdGlvbnMgb2YgbW92aW5nIHRvDQo+PiBORE1BPyBJZiB3 ZSBjaGFuZ2UgYSBwYXRoIGZyb20g4oCcaW50ZXJmYWNlLXN0YXRlLXJlZuKAnSB0byDigJxpbnRl cmZhY2UtcmVm4oCdDQo+PiB0byByZWZlcmVuY2UgYW4gaW50ZXJmYWNlLCBJ4oCZZCBob3BlIG5v IG9uZSB3b3VsZCBleHBlY3QgdGhlIG9sZA0KPj4gc3RhdGVtZW50IHRvIGJlIGtlcHQgYXJvdW5k 4oCmDQo+DQo+QnV0IHRoZSBvbGQgc3RhdGVtZW50IHdvdWxkIGJlIGtlcHQgYXJvdW5kLCBpbiBp dHMgZGVwcmVjYXRlZCBmb3JtLg0KPk9mIGNvdXJzZSwgdGhlIG5tZGEtZ3VpZGVsaW5lcyBzaG91 bGQgY2F1c2UgdGhvc2UgZG93bnN0cmVhbSBtb2R1bGVzDQo+dG8gYmUgdXBkYXRlZCB0byBOTURB IGFzIHdlbGwsIHNvIGhvcGVmdWxseSBqdXN0IGEgc2hvcnQtbGl2ZWQgaXNzdWUuDQoNClRoaXMg Y291bGQgYmUgcmVhbGx5IHVnbHkgYW5kIGNhc2NhZGUgaWYgd2UgYXJlIGp1c3QgdXNpbmcgYSBk aWZmZXJlbnQNCnBhdGggZm9yIGEgcmVmZXJlbmNlLiBIb3BlZnVsbHksIGFsbCB0aGUgb2xkIHJl ZmVyZW5jZXMgYXJlIGluIGRlcHJlY2F0ZWQNCnRyZWVzLiBPdGhlcndpc2UsIEkgZ3Vlc3MgdGhl IG5ldyBkYXRhIGxlYWYgd291bGQgbmVlZCBhIHVuaXF1ZSBuYW1lLg0KDQpUaGFua3MsDQpBY2Vl IA0KPg0KPktlbnQNCj4NCj4NCg0K From nobody Thu Sep 7 14:23:27 2017 Return-Path: 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 C749A132F60; Thu, 7 Sep 2017 14:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyADG6pCPMH5; Thu, 7 Sep 2017 14:23:23 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB095132F5C; Thu, 7 Sep 2017 14:23:23 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 7F87418; Thu, 7 Sep 2017 23:23:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id k04AFe0tAgvV; Thu, 7 Sep 2017 23:23:20 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 7 Sep 2017 23:23:22 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3D842200E3; Thu, 7 Sep 2017 23:23:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id g1NMciXZJupK; Thu, 7 Sep 2017 23:23:22 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DA735200E2; Thu, 7 Sep 2017 23:23:21 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 812F640EB9B7; Thu, 7 Sep 2017 23:23:19 +0200 (CEST) Date: Thu, 7 Sep 2017 23:23:17 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: Martin Bjorklund , NETCONF Working Group , "netmod@ietf.org" Message-ID: <20170907212317.56h64sm5lulnpu5n@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Andy Bierman , Martin Bjorklund , NETCONF Working Group , "netmod@ietf.org" References: <232e44d5-28b9-a017-ec10-54a597a66c7b@cisco.com> <20170907.121547.1207208093298972388.mbj@tail-f.com> <89b4053a-19de-a77b-8442-84c3d75e3457@cisco.com> <20170907.131048.1841464922845786321.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [netmod] upcoming adoptions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 21:23:26 -0000 On Thu, Sep 07, 2017 at 10:51:54AM -0700, Andy Bierman wrote: > > I suggested the naming guideline because the NMDA design team decided to > add semantics to certain naming patterns, so authors have to be warned. > > But this is a really bad idea (and slippery slope). I agree. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Sep 7 16:28:31 2017 Return-Path: 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 6AD1D133030 for ; Thu, 7 Sep 2017 16:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.011 X-Spam-Level: X-Spam-Status: No, score=-3.011 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 j1A17lfADJMM for ; Thu, 7 Sep 2017 16:28:27 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0108.outbound.protection.outlook.com [104.47.42.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EF2113302F for ; Thu, 7 Sep 2017 16:28:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6nnjfXdN0OO+kIBgCSvMqCxv4B/BmLHkn9n/RowhsEw=; b=E7si0g2h7nDkCzYopvinm7XI725dZVLz3BcDIjRm06o1XgDAqz2vjwslgvloHiykJw0TZSrvtzbQXQ2miUtJzj0YNglXXTqLGQuKQE3a162CbJTaLc5BxIJw6460Wfh3NpQGPZ24JP0LyJC8oATcDjMz2EJ9TTSyjYTfojbDii0= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1348.namprd05.prod.outlook.com (10.160.183.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Thu, 7 Sep 2017 23:28:26 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.20.0056.003; Thu, 7 Sep 2017 23:28:26 +0000 From: Kent Watsen To: "Acee Lindem (acee)" , Lou Berger , Martin Bjorklund CC: "netmod@ietf.org" Thread-Topic: [netmod] two options for removing /foo-state trees? Thread-Index: AQHTJzZlKMfT3FTQbEyg9FUCwcWxgKKoJxiAgAFZEgCAAAPFAIAACi2AgABGtYD///u2AA== Date: Thu, 7 Sep 2017 23:28:26 +0000 Message-ID: <6A207CF2-8130-477C-8A19-4285756490E2@juniper.net> References: <20170906.200545.1646568136744118938.mbj@tail-f.com> <9acc6055-c7b0-8c80-3468-72b090b9253f@labn.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.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1348; 6:9lrOdvACOpoh3tQiTZ8PsxPt1hG2kbJ2TFDup9UMnLKXWcT0Qi2lCYQEH4AxagU3+XmjWIOQXS+MB3pdUT5qo8kLxbId7WZoR7BPoZcBLQSOSyvp7XqhIuiNK1MFDYnWVP2iG6KZlJQ5fcWjuUx//YkFGMvpZH/J4Cabqm6Rtf2oxPuF3YQ+UClqPZwD+NtVepLfOo04wowHdkTbs8Al2LjOcBySJlFZzyngdtkZJ3fw1pbLzAcwNs5/MThWQXgHZSUaOuGttzDuUU/cEceVb0gwzAUJB3aAyARTf74Is+QV3tw5MUHc+aNwPax0S8ng4y+SE1YnPTz0Hn9Msx903g==; 5:fEz7osCBDvtiWNZNOjrlXiA77YRM+nFfvEcB7+L1cnvuOOuRLKF8HhO4hxcHhHVnjcNYfXqGfv1pMofXuyiIXXyfaKFwSWUjYbAZocoeQuEX4J97+WFN8LtUvzuBhYBxzCcrWFJhhn3UkjsrgJcabg==; 24:OGXQeFJ5JciuBxEyUP3yKEsR9k/YAN+miFiG6kY7Lx5qrmSe8CjPMPCv75JRjpZ9ALiAEKve3sh480clBdSaXclGkzdXkQdBtaQ0rAJHRc8=; 7:x7to+WVYcRWPY+JVLzTI2ZWCaZTx/bnq6zArgCzDx8oya7EYeDgvIPKlToGSC9jMv4giGS37txlOYyC1KREuuC2CJDa6GDWfu2if7+YUmiRvJB3GLped7cFWCyQkfWAF8HYBrUf8TckK9sWDv+MesEZ1f4U9PoUfk6KomJTXC49LpvOUveSKwKipuaAbCsYL4BXRhMw2SzkOSxCokeaGfM3IiCbcLXMgy5Rb8zaGICg= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 2d8aed29-7e84-4af3-ba7d-08d4f64823a1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1348; x-ms-traffictypediagnostic: BN3PR0501MB1348: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123562025)(20161123558100)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1348; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1348; x-forefront-prvs: 04238CD941 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(189002)(199003)(6512007)(3846002)(102836003)(6116002)(66066001)(8936002)(6506006)(83716003)(77096006)(93886005)(2950100002)(8676002)(99286003)(229853002)(83506001)(81166006)(81156014)(68736007)(6436002)(6486002)(478600001)(7736002)(82746002)(305945005)(97736004)(53936002)(4001350100001)(25786009)(4326008)(14454004)(6246003)(105586002)(189998001)(3280700002)(3660700001)(33656002)(2900100001)(86362001)(106356001)(5660300001)(50986999)(54356999)(101416001)(76176999)(2906002)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1348; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <7D7C198016B7084DA0C63103DBF1B87B@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Sep 2017 23:28:26.1024 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1348 Archived-At: Subject: Re: [netmod] two options for removing /foo-state trees? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 23:28:29 -0000 DQo+PkRvZXMgdGhpcyBtZWFuIHlvdSdyZSBva2F5IHJlcG9zdGluZyB5b3VyIElEIHNpbWlsYXIg dG8gTWFydGluJ3M/DQo+PkkgYXNrIGFzIGEgY2hhaXIgaW50ZXJlc3RlZCBpbiBzdGFydGluZyB0 aGUgYWRvcHRpb24gcHJvY2VzcyBvbg0KPj50aGVzZSBubWRhLXVwZGF0ZSBkcmFmdHMuDQo+DQo+ IEkgd291bGQgaG9wZSB0aGlzIGlzIG5vdCBhIHByZXJlcXVpc2l0ZT8gV2UgYXJlIGV2YWx1YXRp bmcgaG93IGJhZCB0aGlzDQo+IHdpbGwgYmUuIEnigJlkIGFzayBob3cgbWFueSBpbXBsZW1lbnRh dGlvbnMgdGhlcmUgYXJlIG9mIGlldGYtcm91dGluZz8NCg0KWWVzLCBwbGVhc2UgcHJvdmlkZSB0 aGlzIGluZm8gd2hlbiB5b3UgaGF2ZSBpdC4NCg0KDQo+Pj4gSG93ZXZlciwgd2hhdCBhYm91dCBz ZWNvbmRhcnkgYW5kIHRlcnRpYXJ5IGltcGxpY2F0aW9ucyBvZiBtb3ZpbmcgdG8NCj4+PiBORE1B PyBJZiB3ZSBjaGFuZ2UgYSBwYXRoIGZyb20g4oCcaW50ZXJmYWNlLXN0YXRlLXJlZuKAnSB0byDi gJxpbnRlcmZhY2UtcmVm4oCdDQo+Pj4gdG8gcmVmZXJlbmNlIGFuIGludGVyZmFjZSwgSeKAmWQg aG9wZSBubyBvbmUgd291bGQgZXhwZWN0IHRoZSBvbGQNCj4+PiBzdGF0ZW1lbnQgdG8gYmUga2Vw dCBhcm91bmTigKYNCj4+DQo+PkJ1dCB0aGUgb2xkIHN0YXRlbWVudCB3b3VsZCBiZSBrZXB0IGFy b3VuZCwgaW4gaXRzIGRlcHJlY2F0ZWQgZm9ybS4NCj4+T2YgY291cnNlLCB0aGUgbm1kYS1ndWlk ZWxpbmVzIHNob3VsZCBjYXVzZSB0aG9zZSBkb3duc3RyZWFtIG1vZHVsZXMNCj4+dG8gYmUgdXBk YXRlZCB0byBOTURBIGFzIHdlbGwsIHNvIGhvcGVmdWxseSBqdXN0IGEgc2hvcnQtbGl2ZWQgaXNz dWUuDQo+DQo+IFRoaXMgY291bGQgYmUgcmVhbGx5IHVnbHkgYW5kIGNhc2NhZGUgaWYgd2UgYXJl IGp1c3QgdXNpbmcgYSBkaWZmZXJlbnQNCj4gcGF0aCBmb3IgYSByZWZlcmVuY2UuIEhvcGVmdWxs eSwgYWxsIHRoZSBvbGQgcmVmZXJlbmNlcyBhcmUgaW4gZGVwcmVjYXRlZA0KPiB0cmVlcy4gT3Ro ZXJ3aXNlLCBJIGd1ZXNzIHRoZSBuZXcgZGF0YSBsZWFmIHdvdWxkIG5lZWQgYSB1bmlxdWUgbmFt ZS4NCg0KSW5kZWVkLiAgTGV0J3Mgc2VlIHdoYXQgdGhlIGFuYWx5c2lzIHJldmVhbHMuDQoNCktl bnQNCg0KDQoNCg== From nobody Fri Sep 8 02:21:02 2017 Return-Path: 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 0E6C1132ECD for ; Fri, 8 Sep 2017 02:21:01 -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 MeGPnKSsEiCp for ; Fri, 8 Sep 2017 02:20:59 -0700 (PDT) Received: from Mail2.SpriteLink.NET (Mail2.spritelink.net [195.182.5.83]) by ietfa.amsl.com (Postfix) with ESMTP id 22B9B132EC9 for ; Fri, 8 Sep 2017 02:20:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id 4E810261846; Fri, 8 Sep 2017 11:20:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at SpriteLink.NET Received: from Mail2.SpriteLink.NET ([195.182.5.83]) by localhost (Mail2.SpriteLink.NET [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5pkDMmhVL95; Fri, 8 Sep 2017 11:20:57 +0200 (CEST) Received: from localhost (Mission-Control.spritelink.net [195.182.5.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kristian@SpriteLink.NET) by Mail2.SpriteLink.NET (Postfix) with ESMTPSA id 13F8D261838; Fri, 8 Sep 2017 11:20:57 +0200 (CEST) Date: Fri, 8 Sep 2017 11:20:56 +0200 From: Kristian Larsson To: Dan Romascanu Cc: netmod@ietf.org Message-ID: <20170908092055.GA25608@spritelink.se> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [netmod] why is the alarm YANG work being done in CCAMP? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 09:21:01 -0000 I agree, I think this belongs in NETMOD. I'd also like to say that we, the TeraStream team of Deutsche Telekom, are currently implementing support for the alarm module. This work is happening in both our NMS (consisting partly of Tail-F NCS as well as other components producing / consuming the alarm module) and in devices, where our home grown lwAFTR will probably be the first implementation. It's using open source software in the form of Snabb (https://github.com/snabbco/snabb) for dataplane and the NETCONF / YANG stack consists of netopeer2 and sysrepo (another open source project we're involved with). Kind regards, Kristian. On Mon, Jul 17, 2017 at 04:16:16PM +0200, Dan Romascanu wrote: > Hi, > > I am sorry if I am late to observing this. Please feel free to bash me and > point to where this discussion already took place. I just heard in the NETMOD > WG meeting that draft-vallin-netmod-alarm-module is going to be undertaken by > the CCAMP WG. What is the reason? The problem space of Alarm management data > model seems IMO pretty generic, and on the other side I cannot see what is > CCAMP-ish or even RTG Area specific in this work. > > Thanks and Regards, > > Dan > (one of the authors of RFC 3877) > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Kristian Larsson KLL-RIPE +46 704 264511 kll@spritelink.net From nobody Fri Sep 8 03:17:18 2017 Return-Path: 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 94516132EDD; Fri, 8 Sep 2017 03:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 QbHZLG4c37qh; Fri, 8 Sep 2017 03:17:15 -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 13554132ED6; Fri, 8 Sep 2017 03:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1753; q=dns/txt; s=iport; t=1504865835; x=1506075435; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=q3KVGcUIceI4ozvz1KX+ftTjakU7vTnlV4FOpDdNTmU=; b=Vct1a97E0H2pl34YFltWuaL45JlLHlUVitjabjfrdEtKI/9nDGSmAGyZ iQqA34JcN5s+RjIaG1XyHLCC+DkVGymkePOZH0JXnVoBls0zJcMGFMXZr xP7K8erh8oF+bhg86GR8SZld/O+30hpxfj64O1ddBYeJTwEI3DlcAgfYQ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C2AwA9bbJZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhSyEHosVkHQrmDoKhT4ChEkVAQIBAQEBAQEBayiFGQEFIw8BBVE?= =?us-ascii?q?LGAICJgICVwYBDAgBAYotqzKCJ4s6AQEBAQEBAQMBAQEBAQEigQ2CHYNQgWMrg?= =?us-ascii?q?n2ICIJhBaB0lFGLVIcdjVeHVIE5NSKBDTIhCBwVh2U/ilQBAQE?= X-IronPort-AV: E=Sophos;i="5.42,360,1500940800"; d="scan'208";a="657318455" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Sep 2017 10:17:11 +0000 Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v88AHA4s000848; Fri, 8 Sep 2017 10:17:10 GMT To: Andy Bierman , Martin Bjorklund , NETCONF Working Group , "netmod@ietf.org" References: <232e44d5-28b9-a017-ec10-54a597a66c7b@cisco.com> <20170907.121547.1207208093298972388.mbj@tail-f.com> <89b4053a-19de-a77b-8442-84c3d75e3457@cisco.com> <20170907.131048.1841464922845786321.mbj@tail-f.com> <20170907212317.56h64sm5lulnpu5n@elstar.local> From: Robert Wilton Message-ID: <688377a1-f1bd-b870-bb34-fab54e417f0e@cisco.com> Date: Fri, 8 Sep 2017 11:17:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170907212317.56h64sm5lulnpu5n@elstar.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] upcoming adoptions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 10:17:17 -0000 On 07/09/2017 22:23, Juergen Schoenwaelder wrote: > On Thu, Sep 07, 2017 at 10:51:54AM -0700, Andy Bierman wrote: >> I suggested the naming guideline because the NMDA design team decided to >> add semantics to certain naming patterns, so authors have to be warned. >> >> But this is a really bad idea (and slippery slope). > I agree. I think that there are really a few aspects to this: 1)I think that it is a good goal to try and achieve a consistent style across the IETF YANG modules.  This helps both readers and implementors.  E.g. sticking child "config" and "state" containers in the tree in a similar style to OpenConfig may be in-congruent with how with how most IETF YANG modules are written. 2) I think that is also some common sense guidance here, which is to avoid using node names that may prevent a module for being sensibly updated in future.  Hence I think that names that related to the scope of the data (e.g. "state", "*-state", "config", and "*-config") should generally be avoided, because it is possible that the scope of that data may change.  Something that is only operational state in a standard model may become configurable by a future revision, or perhaps via vendor deviation. 3) The top level "*-state" containers seems to be an undocumented historical rule in the context of the pre NMDA IETF YANG modules. Hence, advising people not to create top level containers called "-state" also seems to help avoid a potential source of confusion. I don't know if these are necessarily rules, or just common sense. I don't know whether this guidance needs to be documented in rfc6087bis.  My view is that it would probably be helpful. Thanks, Rob > > /js > From nobody Fri Sep 8 03:56:55 2017 Return-Path: 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 748B21326F3; Fri, 8 Sep 2017 03:56:53 -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 YehrC8NbF0wC; Fri, 8 Sep 2017 03:56:51 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9506B13236D; Fri, 8 Sep 2017 03:56:51 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 6DB2D21; Fri, 8 Sep 2017 12:56:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id c_8XMxkbrPEt; Fri, 8 Sep 2017 12:56:47 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 8 Sep 2017 12:56:50 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4CF57200E3; Fri, 8 Sep 2017 12:56:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 2ORiuHUUI2iA; Fri, 8 Sep 2017 12:56:50 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 98E37200E2; Fri, 8 Sep 2017 12:56:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 98ADC40EC5E4; Fri, 8 Sep 2017 12:56:48 +0200 (CEST) Date: Fri, 8 Sep 2017 12:56:48 +0200 From: Juergen Schoenwaelder To: Robert Wilton Cc: Andy Bierman , Martin Bjorklund , NETCONF Working Group , "netmod@ietf.org" Message-ID: <20170908105648.ur5ihv3gvypd7d7f@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Robert Wilton , Andy Bierman , Martin Bjorklund , NETCONF Working Group , "netmod@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <688377a1-f1bd-b870-bb34-fab54e417f0e@cisco.com> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [netmod] upcoming adoptions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 10:56:53 -0000 On Fri, Sep 08, 2017 at 11:17:10AM +0100, Robert Wilton wrote: > > > On 07/09/2017 22:23, Juergen Schoenwaelder wrote: > > On Thu, Sep 07, 2017 at 10:51:54AM -0700, Andy Bierman wrote: > > > I suggested the naming guideline because the NMDA design team decided to > > > add semantics to certain naming patterns, so authors have to be warned. > > > > > > But this is a really bad idea (and slippery slope). > > I agree. > I think that there are really a few aspects to this: > [...] CLRs are always created with the best intention but then they become over time a problem. There is quite some experience with this. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Sep 8 05:19:11 2017 Return-Path: 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 92D7F132715; Fri, 8 Sep 2017 05:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 UWIl0eVij_V2; Fri, 8 Sep 2017 05:19:08 -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 C07DE1321B6; Fri, 8 Sep 2017 05:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1283; q=dns/txt; s=iport; t=1504873148; x=1506082748; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=0/Gfsl+31mtdxYF1M3bnCgh5xa7oE7CPuRyHFprGg7Y=; b=HwwpLmjog5uVQjJTdgaWCqSpy9AS+ZQP2Jsffl1Gje8evjtvUyo8lzR+ 3QT/UtQZ4wu2ck2cR3broWdXlgyI9I/srnxNxvXxypvyGldfI027OyTxU 9I95T4DBHYsKZzAex3CCki7T7tBy4euZD7nLUHfurfjWd48PhbZ5/ovrv s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DmBAAmirJZ/xbLJq1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBhSyEHosVkHMrmDoKhT4ChE4UAQIBAQEBAQEBayiFGQEFIw8BBVELGAI?= =?us-ascii?q?CJgICVwYBDAgBAYotq2eCJ4s5AQEBAQEBBAEBAQEBI4ENgh2DUIFjK4FwgQ2IC?= =?us-ascii?q?IJhBaB0lFGLVIcdjVeHVIE5NiGBDTIhCBwVSYccP4pUAQEB?= X-IronPort-AV: E=Sophos;i="5.42,361,1500940800"; d="scan'208";a="655500580" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Sep 2017 12:19:03 +0000 Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v88CJ37F020266; Fri, 8 Sep 2017 12:19:03 GMT To: Andy Bierman , Martin Bjorklund , NETCONF Working Group , "netmod@ietf.org" References: <20170908105648.ur5ihv3gvypd7d7f@elstar.local> From: Robert Wilton Message-ID: Date: Fri, 8 Sep 2017 13:19:03 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170908105648.ur5ihv3gvypd7d7f@elstar.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] upcoming adoptions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 12:19:09 -0000 On 08/09/2017 11:56, Juergen Schoenwaelder wrote: > On Fri, Sep 08, 2017 at 11:17:10AM +0100, Robert Wilton wrote: >> >> On 07/09/2017 22:23, Juergen Schoenwaelder wrote: >>> On Thu, Sep 07, 2017 at 10:51:54AM -0700, Andy Bierman wrote: >>>> I suggested the naming guideline because the NMDA design team decided to >>>> add semantics to certain naming patterns, so authors have to be warned. >>>> >>>> But this is a really bad idea (and slippery slope). >>> I agree. >> I think that there are really a few aspects to this: >> > [...] > > CLRs are always created with the best intention but then they become > over time a problem. There is quite some experience with this. In the same vane, I think that you could regard RFC 6087 and 6087bis as one long list of CLRs ... But giving people sensible advice on how to use to produce good YANG models generally seems helpful to me.  But with the understanding that it is just advice, is not set in stone, and it could reasonably change over time. I actually think that this sort of information (e.g. perhaps the bulk of 6087 content) may be better on wiki pages, where it is less formal and can change in a more fluid way.  Oops! I've just created another CLR ;-) Thanks, Rob > > /js > From nobody Fri Sep 8 05:19:43 2017 Return-Path: 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 50C95132D67 for ; Fri, 8 Sep 2017 05:19: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 YtNF6ijnBFv0 for ; Fri, 8 Sep 2017 05:19:40 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 3C660132713 for ; Fri, 8 Sep 2017 05:19:40 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id i14so5342558ioe.2 for ; Fri, 08 Sep 2017 05:19:40 -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; bh=m95ZgPEYaylLePE8GA93PGO3+E29h9Id1N8kBscwIpI=; b=y1xnij1p+7n3ra+ECxGH7Y4Kmq79DgOFsICB8gO3reLiVx886M4mFn76a1/eDZHpbB DVa02wRHPfmB8rKVDejDKJcSv/BECcmAuGmlmJQzsGNf3EhrVeFQbw5xGa077Fcqmd7i NrY1bwod99eUIeoCTXOc3Cs/z+0P33vqT0ZodxPPUkyNnFGKl4fgh2QzKucyVK8bxjG9 qLFjEzHKEy79Lq57hvLqjzNkNRM7Br4pNh/IVZCrhYSdqZebNHQKofwCmbHM1K89wWOl A8ZJxqE52odHHX80rNJ8uJQ+j0hUpDkxXI/hWFdzPuguUtaFt/Iucbd1g564ocKYmjG4 jSGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=m95ZgPEYaylLePE8GA93PGO3+E29h9Id1N8kBscwIpI=; b=LQw3WKtH/websYRd3WiHxP/R2CFpBBo80EM60poaNXBf9E2PaX9nTXcovkB3OK8j26 YdQzCBasYYg0RVDBH1dwavrbYhpQ3uJ8bd5Bc1Oe96FTi2OZYIxGYrT5KwO+nY1MCS7q gZ4fE91F59OwE7rPeTBT5fv746S0HwSyqSWLhHFkSxwurLU64Hbey/hmD64Ry9htEg5+ VqZapmUDSq1B2TsSzDa1DaVvv0j1HyJy8ewW05SOGwa5i8lblv5P9yS+Fgq7K4cuAZNb MZTvbWThmPGxRje2w0hIRsZof20p+JCFHChSL96Q1F/vtsohTH8gaox838hZuYgnEsDP yrpA== X-Gm-Message-State: AHPjjUi4hzKFBEEXYiCfldZpOyVaWercLy2sRGTg2M77lyPfVqFo+1v+ wkgzyXIj2QcLEUdFCUnK+//Q2Q4n+X4B X-Google-Smtp-Source: AOwi7QAF0ZeIRXMsKITom8QBkda3ocZ+AsVB+Qy1G7b8+HdIhHeyYQHULCSterG8uQX6R4Ockh4GGn03eEc9BwlGd1Q= X-Received: by 10.107.70.21 with SMTP id t21mr2908167ioa.50.1504873179521; Fri, 08 Sep 2017 05:19:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.6.206 with HTTP; Fri, 8 Sep 2017 05:19:38 -0700 (PDT) In-Reply-To: <20170908105648.ur5ihv3gvypd7d7f@elstar.local> References: <688377a1-f1bd-b870-bb34-fab54e417f0e@cisco.com> <20170908105648.ur5ihv3gvypd7d7f@elstar.local> From: Andy Bierman Date: Fri, 8 Sep 2017 05:19:38 -0700 Message-ID: To: Juergen Schoenwaelder , Robert Wilton , Andy Bierman , Martin Bjorklund , NETCONF Working Group , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="089e082689a04c3c910558ac9725" Archived-At: Subject: Re: [netmod] upcoming adoptions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 12:19:42 -0000 --089e082689a04c3c910558ac9725 Content-Type: text/plain; charset="UTF-8" On Fri, Sep 8, 2017 at 3:56 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Fri, Sep 08, 2017 at 11:17:10AM +0100, Robert Wilton wrote: > > > > > > On 07/09/2017 22:23, Juergen Schoenwaelder wrote: > > > On Thu, Sep 07, 2017 at 10:51:54AM -0700, Andy Bierman wrote: > > > > I suggested the naming guideline because the NMDA design team > decided to > > > > add semantics to certain naming patterns, so authors have to be > warned. > > > > > > > > But this is a really bad idea (and slippery slope). > > > I agree. > > I think that there are really a few aspects to this: > > > > [...] > > CLRs are always created with the best intention but then they become > over time a problem. There is quite some experience with this. > > yes -- naming conventions are fine but they cannot be used by automation tools. The YANG language says these strings have no meaning so tools cannot count on them to have any meaning. The issue here is whether there are standard extensions to tag YANG modules or whether each tool vendor will have their own extensions instead. It is not critical that the IETF provide these YANG extensions, but they will get used one way or another. CLRs always start out as clever little rules. They usually turn to something else only after some time. /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --089e082689a04c3c910558ac9725 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Sep 8, 2017 at 3:56 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Fri, Sep 08, 2017 at 11:17:10AM +0100, Robert Wilt= on wrote:
>
>
> On 07/09/2017 22:23, Juergen Schoenwaelder wrote:
> > On Thu, Sep 07, 2017 at 10:51:54AM -0700, Andy Bierman wrote:
> > > I suggested the naming guideline because the NMDA design tea= m decided to
> > > add semantics to certain naming patterns, so authors have to= be warned.
> > >
> > > But this is a really bad idea (and slippery slope).
> > I agree.
> I think that there are really a few aspects to this:
>

[...]

CLRs are always created with the best intention but then they become
over time a problem. There is quite some experience with this.


yes -- naming conventions are fine but they cannot b= e used by automation tools.
The YANG language says these strings = have no meaning so tools cannot count
on them to have any meaning= .

The issue here is whether there are standard ext= ensions to tag YANG modules
or whether each tool vendor will have= their own extensions instead.
It is not critical that the IETF p= rovide these YANG extensions, but they
will get used one way or a= nother.

CLRs always start out as clever little rul= es. They usually turn to something else only
after some time.

/js


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

--089e082689a04c3c910558ac9725-- From nobody Fri Sep 8 05:38:58 2017 Return-Path: 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 D45AD132EC4; Fri, 8 Sep 2017 05:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 fqJdgo5KkcvK; Fri, 8 Sep 2017 05:38:55 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FE2D1321A4; Fri, 8 Sep 2017 05:38:55 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 181F5FA7; Fri, 8 Sep 2017 14:38:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id OYnP4GFo0gWW; Fri, 8 Sep 2017 14:38:51 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 8 Sep 2017 14:38:54 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id EA974200E3; Fri, 8 Sep 2017 14:38:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id eKhBeHj2yQMQ; Fri, 8 Sep 2017 14:38:53 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 84EDD200E2; Fri, 8 Sep 2017 14:38:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5C29840EC939; Fri, 8 Sep 2017 14:38:53 +0200 (CEST) Date: Fri, 8 Sep 2017 14:38:53 +0200 From: Juergen Schoenwaelder To: Robert Wilton Cc: Andy Bierman , Martin Bjorklund , NETCONF Working Group , "netmod@ietf.org" Message-ID: <20170908123853.4jmy24gvbe2agiif@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Robert Wilton , Andy Bierman , Martin Bjorklund , NETCONF Working Group , "netmod@ietf.org" References: <20170908105648.ur5ihv3gvypd7d7f@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [netmod] upcoming adoptions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 12:38:57 -0000 On Fri, Sep 08, 2017 at 01:19:03PM +0100, Robert Wilton wrote: > > In the same vane, I think that you could regard RFC 6087 and 6087bis as one > long list of CLRs ... > No. There are guidelines that have a clear technical reason. An example: The 'preceding-sibling' and 'following-sibling' axes SHOULD NOT used. A server is only required to maintain the relative XML document order of all instances of a particular user-ordered list or leaf-list. This is very different from guidelines how things should be named that do not have a real technical reason. In SMIv2 land, we had this weird rule that names of counters should end with a plural 's' and tools started to implement this and to complain if there was no plural s. (Actually, tools checked whether the last character is an s, which of course does not mean there is a plural form.) And of course, there are irregular nouns in English wrt. plural forms. I do not want rules that say '-state' should not be used. There may be valid reasons to use '-state'. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Sep 8 06:41:51 2017 Return-Path: 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 49F4F12421A; Fri, 8 Sep 2017 06:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 m_BRm5-OFoNg; Fri, 8 Sep 2017 06:41:48 -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 268A6132153; Fri, 8 Sep 2017 06:41:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10574; q=dns/txt; s=iport; t=1504878108; x=1506087708; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=YOVV7nMujIRDY4INdBntoo9gHRdodxaQoMLRfTrWqsc=; b=aI5dUVdmVRN1QKjGmCwlkboZoui+ELWSe2pKENoE+tfrCSb18/Kg25RU frtb7/Rul9ZrLR3DChOI+Et0w6cnkGy9OgyRFzC/9IeRIE4BwIg5hAYwq D4Djotc5E4hoLzwGAeOFqYUyLdxgbjReQgN46sDsQO+VcZti6NZZh4Va2 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DoBAB9nbJZ/xbLJq1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm8+gX+EHosVkHMrkGmHUQqFPgKEThQBAgEBAQEBAQFrKIUYAQEBAwE?= =?us-ascii?q?jZgsYKgICVwYBDAgBAYolCKttgicnixMBAQEBAQEBAQEBAQEBAQEBAQEBH4Mqg?= =?us-ascii?q?1CCDoJ9hF+DKYJhBZEnAY9MizWJHIITiUEkhnmNV4dUgTk2IYENMiEIHBVJhxw?= =?us-ascii?q?/ilQBAQE?= X-IronPort-AV: E=Sophos;i="5.42,361,1500940800"; d="scan'208,217";a="657323023" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Sep 2017 13:41:43 +0000 Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v88DfhZa021397; Fri, 8 Sep 2017 13:41:43 GMT To: Andy Bierman , Martin Bjorklund , NETCONF Working Group , "netmod@ietf.org" References: <20170908105648.ur5ihv3gvypd7d7f@elstar.local> <20170908123853.4jmy24gvbe2agiif@elstar.local> From: Robert Wilton Message-ID: <2b11208e-a11e-c3ec-dca1-d686bc417a52@cisco.com> Date: Fri, 8 Sep 2017 14:41:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170908123853.4jmy24gvbe2agiif@elstar.local> Content-Type: multipart/alternative; boundary="------------FE742A098328E6ED03524D8B" Content-Language: en-US Archived-At: Subject: Re: [netmod] upcoming adoptions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 13:41:50 -0000 This is a multi-part message in MIME format. --------------FE742A098328E6ED03524D8B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 08/09/2017 13:38, Juergen Schoenwaelder wrote: > On Fri, Sep 08, 2017 at 01:19:03PM +0100, Robert Wilton wrote: >> In the same vane, I think that you could regard RFC 6087 and 6087bis as one >> long list of CLRs ... >> > No. There are guidelines that have a clear technical reason. An example: > > The 'preceding-sibling' and 'following-sibling' axes SHOULD NOT used. > A server is only required to maintain the relative XML document order > of all instances of a particular user-ordered list or leaf-list. Yes, but even this rule has problems.  Does this mean an implementation does not need to support "preceding-sibling and following-sibling"?  Given this is only a "SHOULD NOT", it means that there might be some modules may still use them.  Likewise for the rest of the XPath "SHOULD NOT" rules.  Will YANG implementations fragment on which subsets of Xpath they regard as sane and choose to implement? [As an aside: I actually think that it would be better to restrict the usage of Xpath to a much smaller subset that makes sense, but that should be done in 7950bis rather than 6087bis.] Besides, 6087bis has many softer rules as well, a few examples give below (I'm not even sure why the last one is a rule).  There don't obviously appear to be any technical reasons for any of these, but I don't object to any of these since they are provide sensible guidance, or try to encourage consistent modelling conventions in IETF YANG models. Ex1: Identifiers SHOULD follow a consistent naming pattern throughout the module. Only lower-case letters, numbers, and dashes SHOULD be used in identifier names. Ex2: Definitions for future use SHOULD NOT be specified in a module. Ex3: The signed numeric data types (i.e., 'int8', 'int16', 'int32', and 'int64') SHOULD NOT be used unless negative values are allowed for the desired semantics. > > This is very different from guidelines how things should be named that > do not have a real technical reason. In SMIv2 land, we had this weird > rule that names of counters should end with a plural 's' and tools > started to implement this and to complain if there was no plural s. > (Actually, tools checked whether the last character is an s, which of > course does not mean there is a plural form.) And of course, there are > irregular nouns in English wrt. plural forms. As per ex1 above, perhaps YANG tools will start to assume that identifiers cannot contain uppercase characters. It might be better if a lot of the guidance in 6087bis is changed to avoid using RFC 2119 language precisely so that it can't be subsequently interpreted as a formal rule. But I still see guidance on how to consistently name counters and list elements is good way of helping achieve consistency, and make the models read better.  This doesn't mean that tools should interpret these as rules. > > I do not want rules that say '-state' should not be used. There may > be valid reasons to use '-state'. Yes there might, but most likely when someone uses "-state" in the name of a container they will be doing the wrong thing, and it may cause them problems down the line.  Warning them of the potential problems now so that they make an informed decision seems generally helpful to humanity.  This does not mean that it needs to be a rule, or is even allowed to be interpreted as such. Thanks, Rob > > /js > --------------FE742A098328E6ED03524D8B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 08/09/2017 13:38, Juergen Schoenwaelder wrote:
On Fri, Sep 08, 2017 at 01:19:03PM +0100, Robert Wilton wrote:

In the same vane, I think that you could regard RFC 6087 and 6087bis as one
long list of CLRs ...


No. There are guidelines that have a clear technical reason. An example:

   The 'preceding-sibling' and 'following-sibling' axes SHOULD NOT used.
   A server is only required to maintain the relative XML document order
   of all instances of a particular user-ordered list or leaf-list.
Yes, but even this rule has problems.  Does this mean an implementation does not need to support "preceding-sibling and following-sibling"?  Given this is only a "SHOULD NOT", it means that there might be some modules may still use them.  Likewise for the rest of the XPath "SHOULD NOT" rules.  Will YANG implementations fragment on which subsets of Xpath they regard as sane and choose to implement?

[As an aside: I actually think that it would be better to restrict the usage of Xpath to a much smaller subset that makes sense, but that should be done in 7950bis rather than 6087bis.]

Besides, 6087bis has many softer rules as well, a few examples give below (I'm not even sure why the last one is a rule).  There don't obviously appear to be any technical reasons for any of these, but I don't object to any of these since they are provide sensible guidance, or try to encourage consistent modelling conventions in IETF YANG models.

Ex1:
 Identifiers SHOULD follow a consistent naming pattern throughout the
   module.  Only lower-case letters, numbers, and dashes SHOULD be used
   in identifier names.

Ex2:
 Definitions for future use SHOULD NOT be specified in a module.

Ex3:
   The signed numeric data types (i.e., 'int8', 'int16', 'int32', and
   'int64') SHOULD NOT be used unless negative values are allowed for
   the desired semantics.



This is very different from guidelines how things should be named that
do not have a real technical reason. In SMIv2 land, we had this weird
rule that names of counters should end with a plural 's' and tools
started to implement this and to complain if there was no plural s.
(Actually, tools checked whether the last character is an s, which of
course does not mean there is a plural form.) And of course, there are
irregular nouns in English wrt. plural forms.
As per ex1 above, perhaps YANG tools will start to assume that identifiers cannot contain uppercase characters.

It might be better if a lot of the guidance in 6087bis is changed to avoid using RFC 2119 language precisely so that it can't be subsequently interpreted as a formal rule.

But I still see guidance on how to consistently name counters and list elements is good way of helping achieve consistency, and make the models read better.  This doesn't mean that tools should interpret these as rules.



I do not want rules that say '-state' should not be used. There may
be valid reasons to use '-state'.
Yes there might, but most likely when someone uses "-state" in the name of a container they will be doing the wrong thing, and it may cause them problems down the line.  Warning them of the potential problems now so that they make an informed decision seems generally helpful to humanity.  This does not mean that it needs to be a rule, or is even allowed to be interpreted as such.

Thanks,
Rob


/js

--------------FE742A098328E6ED03524D8B-- From nobody Fri Sep 8 07:23:32 2017 Return-Path: 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 73123132925 for ; Fri, 8 Sep 2017 07:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] 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 3coiJPlMcAcz for ; Fri, 8 Sep 2017 07:23:27 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 9879C132153 for ; Fri, 8 Sep 2017 07:23:27 -0700 (PDT) Received: from birdie20 (unknown [IPv6:2001:1488:fffe:6:78e3:97ff:fea0:ae2b]) by mail.nic.cz (Postfix) with ESMTPSA id DBF2F622DC for ; Fri, 8 Sep 2017 16:23:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1504880605; bh=mbsKLNm66aINI+1LT90QBytuFMNtM5JaoNGNhXmPq3A=; h=From:To:Date; b=PCqy/b3eSqPsQr7yL6QLp487FvElVF/2EuWKbMXq7m64rhb8BTzZ1yYgZnnMfwjnf GH4MQ/PxF5m1ZGOYDahlbUqnz6abAr53GbB+i4id3QRlgK5bd1xc0qkby212hf7Obx WsDcR8FkHQlDisqKGzYIO3bzTmWUqudAySB1qYLU= Message-ID: <1504880639.21276.72.camel@nic.cz> From: Ladislav Lhotka To: netmod@ietf.org Date: Fri, 08 Sep 2017 16:23:59 +0200 In-Reply-To: <2b11208e-a11e-c3ec-dca1-d686bc417a52@cisco.com> References: <20170908105648.ur5ihv3gvypd7d7f@elstar.local> <20170908123853.4jmy24gvbe2agiif@elstar.local> <2b11208e-a11e-c3ec-dca1-d686bc417a52@cisco.com> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.5 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] upcoming adoptions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 14:23:31 -0000 Robert Wilton píše v Pá 08. 09. 2017 v 14:41 +0100: > > > On 08/09/2017 13:38, Juergen Schoenwaelder wrote: > > On Fri, Sep 08, 2017 at 01:19:03PM +0100, Robert Wilton wrote: > > > In the same vane, I think that you could regard RFC 6087 and 6087bis as > > > one > > > long list of CLRs ... > > > > > > > No. There are guidelines that have a clear technical reason. An example: > > > > The 'preceding-sibling' and 'following-sibling' axes SHOULD NOT used. > > A server is only required to maintain the relative XML document order > > of all instances of a particular user-ordered list or leaf-list. In fact, 6087bis has a different text: The 'preceding-sibling' and 'following-sibling' axes SHOULD NOT used, however they MAY be used if document order is not relevant to the outcome of the expression. The 'preceding-sibling' and 'following-sibling' axes do have their uses, certainly in user-ordered but also in system-ordered lists. In contrast, 'preceding' and 'following' are really useless in YANG context. > Yes, but even this rule has problems. Does this mean an implementation does > not need to support "preceding-sibling and following-sibling"? Given this is > only a "SHOULD NOT", it means that there might be some modules may still use > them. Likewise for the rest of the XPath "SHOULD NOT" rules. Will YANG > implementations fragment on which subsets of Xpath they regard as sane and > choose to implement? > [As an aside: I actually think that it would be better to restrict the usage > of Xpath to a much smaller subset that makes sense, but that should be done in > 7950bis rather than 6087bis.] I think it was a good decision to rely on an existing well-known standard without making YANG-specific modifications. Tool authors can make certain assumptions - for example, in my Yangson library 'preceding' and 'following' axes aren't supported and raise an exception. > Besides, 6087bis has many softer rules as well, a few examples give below (I'm not even sure why the last one is a rule). There don't obviously appear to be any technical reasons for any of these, but I don't object to any of these since they are provide sensible guidance, or try to encourage consistent modelling conventions in IETF YANG models. Ex1: Identifiers SHOULD follow a consistent naming pattern throughout the module. Only lower-case letters, numbers, and dashes SHOULD be used in identifier names. Ex2: Definitions for future use SHOULD NOT be specified in a module. Ex3: The signed numeric data types (i.e., 'int8', 'int16', 'int32', and 'int64') SHOULD NOT be used unless negative values are allowed for the desired semantics. This is very different from guidelines how things should be named that do not have a real technical reason. In SMIv2 land, we had this weird rule that names of counters should end with a plural 's' and tools started to implement this and to complain if there was no plural s. (Actually, tools checked whether the last character is an s, which of course does not mean there is a plural form.) And of course, there are irregular nouns in English wrt. plural forms. As per ex1 above, perhaps YANG tools will start to assume that identifiers cannot contain uppercase characters. > It might be better if a lot of the guidance in 6087bis is changed to avoid > using RFC 2119 language precisely so that it can't be subsequently interpreted > as a formal rule. I very much agree with this, the use of 2119 keywords sometimes makes things confusing. Lada > But I still see guidance on how to consistently name counters and list elements is good way of helping achieve consistency, and make the models read better. This doesn't mean that tools should interpret these as rules. I do not want rules that say '-state' should not be used. There may be valid reasons to use '-state'. Yes there might, but most likely when someone uses "-state" in the name of a container they will be doing the wrong thing, and it may cause them problems down the line. Warning them of the potential problems now so that they make an informed decision seems generally helpful to humanity. This does not mean that it needs to be a rule, or is even allowed to be interpreted as such. Thanks, Rob /js _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Sep 8 07:24:54 2017 Return-Path: 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 17AC913291C; Fri, 8 Sep 2017 07:24:53 -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 5SW-h57Zg-W3; Fri, 8 Sep 2017 07:24:50 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 961C6132339; Fri, 8 Sep 2017 07:24:50 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 6F17CF79; Fri, 8 Sep 2017 16:24:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id kTE7dK2O_pSo; Fri, 8 Sep 2017 16:24:46 +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 atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 8 Sep 2017 16:24:49 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4B35B200E2; Fri, 8 Sep 2017 16:24:49 +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 DRdEVDPjn0_4; Fri, 8 Sep 2017 16:24:48 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A0C15200E3; Fri, 8 Sep 2017 16:24:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 05E4840ECE6D; Fri, 8 Sep 2017 16:24:46 +0200 (CEST) Date: Fri, 8 Sep 2017 16:24:46 +0200 From: Juergen Schoenwaelder To: Robert Wilton Cc: Andy Bierman , Martin Bjorklund , NETCONF Working Group , "netmod@ietf.org" Message-ID: <20170908142446.f2cjahxvzcbwpn3f@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Robert Wilton , Andy Bierman , Martin Bjorklund , NETCONF Working Group , "netmod@ietf.org" References: <20170908105648.ur5ihv3gvypd7d7f@elstar.local> <20170908123853.4jmy24gvbe2agiif@elstar.local> <2b11208e-a11e-c3ec-dca1-d686bc417a52@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <2b11208e-a11e-c3ec-dca1-d686bc417a52@cisco.com> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [netmod] upcoming adoptions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 14:24:53 -0000 On Fri, Sep 08, 2017 at 02:41:43PM +0100, Robert Wilton wrote: > > > On 08/09/2017 13:38, Juergen Schoenwaelder wrote: > > On Fri, Sep 08, 2017 at 01:19:03PM +0100, Robert Wilton wrote: > > > In the same vane, I think that you could regard RFC 6087 and 6087bis as one > > > long list of CLRs ... > > > > > No. There are guidelines that have a clear technical reason. An example: > > > > The 'preceding-sibling' and 'following-sibling' axes SHOULD NOT used. > > A server is only required to maintain the relative XML document order > > of all instances of a particular user-ordered list or leaf-list. > Yes, but even this rule has problems.  Does this mean an implementation does > not need to support "preceding-sibling and following-sibling"?  Given this > is only a "SHOULD NOT", it means that there might be some modules may still > use them.  Likewise for the rest of the XPath "SHOULD NOT" rules.  Will YANG > implementations fragment on which subsets of Xpath they regard as sane and > choose to implement? > > [As an aside: I actually think that it would be better to restrict the usage > of Xpath to a much smaller subset that makes sense, but that should be done > in 7950bis rather than 6087bis.] RFC 7950 allows full xpath, RFC 6087 says some constructs may be surprising, so be careful. RFC 6087 does not change what RFC 7950 defines. You can be of the opinion that RFC 7950 should be changed but then this is not something RFC 6087 can do. > Besides, 6087bis has many softer rules as well, a few examples give below > (I'm not even sure why the last one is a rule).  There don't obviously > appear to be any technical reasons for any of these, but I don't object to > any of these since they are provide sensible guidance, or try to encourage > consistent modelling conventions in IETF YANG models. [...] I am not interested to discuss every rule there is. I am sure there are rules that are debatable endlessly. > Yes there might, but most likely when someone uses "-state" in the name of a > container they will be doing the wrong thing, and it may cause them problems > down the line. Inferring from the name of an identifier that someone is most likely doing something wrong scares be a lot. Perhaps I have more trust in module authors than you do. (And module authors who do things wrong will most likely not read your collection of CLRs either.) I step out of this discussion. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Sep 8 08:13:26 2017 Return-Path: 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 5A17B13291C for ; Fri, 8 Sep 2017 08:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 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=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxhEy8qq4GQ5 for ; Fri, 8 Sep 2017 08:13:23 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) (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 72FD8132EE9 for ; Fri, 8 Sep 2017 08:13:23 -0700 (PDT) Received: from CMOut01 (unknown [10.0.90.82]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id 2D02C1E3C4E for ; Fri, 8 Sep 2017 09:07:14 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id 737A1w00c2SSUrH0137Dts; Fri, 08 Sep 2017 09:07:14 -0600 X-Authority-Analysis: v=2.2 cv=fJ5J5dSe c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=2JCJgTwv5E4A:10 a=AUd_NHdVAAAA:8 a=uKRgO4BIgdL0fz_OgDgA:9 a=WVNO1HQdYXl3mB8E:21 a=ca_8yGLQMD-HRXHk:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:References:To:From:Subject:Sender:Reply-To:Cc: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=2K6KlKgFmZtC3Dqyo0BFXqT36RgiXTQ4r05lbYqQWUo=; b=LrYSINY8RBxUpfl1wjffYFj8jK yMAWHy549Azq50iJbwjFXbLzFBvyonQj9X3xvVnjydzTsOpOPMdPP7Q0GuKAyJufuw0WccuyZRd8d /TX2tzxcnjDuqKWZzjlafoKO3; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:36730 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dqKsA-003gcn-AU; Fri, 08 Sep 2017 09:07:10 -0600 From: Lou Berger To: Robert Wilton , Ladislav Lhotka , netmod@ietf.org References: <20170830102902.2n5q6rgq2x2dxfq2@elstar.local> <20170830123156.cssrg5kklpo67fie@elstar.local> <1504223854014.55228@Aviatnet.com> <847e5bf9-7b3d-9ff8-9954-970f32a2094c@cisco.com> <20170902073342.xoziwor4tdr5bipw@elstar.local> <20170902112832.ymorfgdthobeio6q@elstar.local> <1e95ba5d-7aa2-e08f-56f9-27aa70822a11@cisco.com> <1504537140.5874.38.camel@nic.cz> <1504629352.7175.40.camel@nic.cz> <8af6041d-7cd5-9608-70b4-7cffc4f884f8@cisco.com> <2a70ce5e-7727-d280-98e4-481d87314d14@labn.net> <15e58235480.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Message-ID: <7398f538-d092-429a-30d5-e5609096a48a@labn.net> Date: Fri, 8 Sep 2017 11:07:06 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <15e58235480.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.84.20 X-Exim-ID: 1dqKsA-003gcn-AU X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:36730 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 15:13:25 -0000 Kent and I discussed this.  We (as chairs) don't think there is currently WG consensus on RegEx guidelines.  We do think there is sufficient interest to continue the discussion, and would like to do so both on list and in our next meeting in Singapore. Thank you, Lou and Kent On 9/6/2017 1:01 PM, Lou Berger wrote: > Thanks Rob. I'll get with Kent and then one of us will get back to the wg > on next steps. > > Lou > > > On September 6, 2017 3:53:33 AM Robert Wilton wrote: > >> Hi Lou, >> >> This is the addition to 6087bis that I propose.   Note, this is the same >> text in my email on the 31st of August. >> >> I propose adding the following 2 paragraphs to 6087bis section on >> pattern and ranges: >> >> NEW: >> To ensure patterns are easy to read and implement, authors SHOULD >> restrict themselves to the parts of the XML schema regular expression >> language that are common across most regular expression languages.  In >> particular, pattern statements SHOULD avoid using 'character class >> subtraction' (e.g. '[a-z-[aeiou]]').  They SHOULD avoid matching >> unicode properties and blocks (e.g. '\p{L} or \p{IsBasic_Latin}'). >> They MAY use the '\d', '\w', '\s' character class shorthands and their >> negated versions, where appropriate, but SHOULD avoid other character >> class shorthands.  To match ASCII digits 0-9 the character class >> '[0-9]' MUST be used instead of the '\d' character class shorthand >> that matches Unicode digits in all scripts. >> >> Pattern statements do not have to strictly restrict numerical values, >> and a simple less specific pattern may be preferable over a more >> complex and precise pattern, e.g. as illustrated in the >> 'ipv4-address-no-zone' example pattern below. >> >> >> Or, put in context of the existing text 6087bis text: >> >> *** Patterns and Ranges >> >> For string data types, if a machine-readable pattern >> can be defined for the desired semantics, then >> one or more pattern statements SHOULD be present. >> A single quoted string SHOULD be used to specify the pattern, >> since a double-quoted string can modify the content. >> >> To ensure patterns are easy to read and implement, authors SHOULD >> restrict themselves to the parts of the XML schema regular expression >> language that are common across most regular expression languages.  In >> particular, pattern statements SHOULD avoid using 'character class >> subtraction' (e.g. '[a-z-[aeiou]]').  They SHOULD avoid matching >> unicode properties and blocks (e.g. '\p{L} or \p{IsBasic_Latin}'). >> They MAY use the '\d', '\w', '\s' character class shorthands and their >> negated versions, where appropriate, but SHOULD avoid other character >> class shorthands.  To match ASCII digits 0-9 the character class >> '[0-9]' MUST be used instead of the '\d' character class shorthand >> that also matches Unicode digits in all scripts. >> >> Pattern statements do not have to strictly restrict numerical values, >> and a simple less specific pattern may be preferable over a more >> complex and precise pattern, e.g. as illustrated in the >> 'ipv4-address-no-zone' example pattern below. >> >> The following typedef from ^RFC6991^ demonstrates the proper >> use of the "pattern" statement: >> >>     typedef ipv4-address-no-zone { >>       type inet:ipv4-address { >>         pattern '[0-9\.]*'; >>       } >>       ... >>     } >> >> For string data types, if the length of the string >> is required to be bounded in all implementations, >> then a length statement MUST be present. >> >> The following typedef from ^RFC6991^ demonstrates the proper >> use of the "length" statement: >> >>     typedef yang-identifier { >>       type string { >>         length "1..max"; >>         pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*'; >>         pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*'; >>       } >>       ... >>     } >> >> For numeric data types, if the values allowed >> by the intended semantics are different than >> those allowed by the unbounded intrinsic data >> type (e.g., 'int32'), then a range statement SHOULD be present. >> >> The following typedef from ^RFC6991^ demonstrates the proper >> use of the "range" statement: >> >>     typedef dscp { >>       type uint8 { >>          range "0..63"; >>       } >>       ... >>     } >> >> Thanks, >> Rob >> >> >> On 05/09/2017 22:37, Lou Berger wrote: >>> Rob, >>> >>> (as chair) >>> On 9/5/2017 1:17 PM, Robert Wilton wrote: >>>> However, I have thrown in the towel on my regex crusade. >>> I'm sorry, I've lost the thread here a bit. in order to guage consensus >>> on this topic, it would be helpful to send the latest text that you are >>> proposing for inclusion in the the bis.  If you are willing to do these, >>> we can poll to see if there is/is not support for inclusion of this >>> text.  Are you willing, i.e., can you send the current proposed text change? >>> >>> Thank you, >>> Lou >>> >>> . >>> >> From nobody Fri Sep 8 08:22:38 2017 Return-Path: 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 6C2CC132EE9 for ; Fri, 8 Sep 2017 08:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 alZr93EKxgTV for ; Fri, 8 Sep 2017 08:22:36 -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 CEDAE13292E for ; Fri, 8 Sep 2017 08:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4776; q=dns/txt; s=iport; t=1504884156; x=1506093756; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=1UC7QaPuCMpVScuUV/f1l5Ad3enq9mqPe6KLG30jdv0=; b=QaTxQ0sG3OOgFSsU3lZNdCR0A3q8tW4V3DNJY9qkAilneXtQhQctxdpd 74bXDDqmCD1BafR3ISIqBvOoI3fopQ9+WhKjYcQbhR60ztn5DHeoMSjyD tQ7XtwBBAbX4MrqbUaKu7Q78uBL5J+g7zoBe/ooT/aRrUjdtonvuW80yB c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C6AwB8tLJZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm8+gX+EHosVkHMrkGmHUQqFPgKEThQBAgEBAQEBAQFrKIUZAQU?= =?us-ascii?q?jZgkCGCoCAlcGAQwIAQGKLY1EnWaCJyeLFAEBAQEBAQEBAQEBAQEBAQEBAQEfg?= =?us-ascii?q?yqDUIIOgn2ICIJhBaB0lFGLVIcdjVeHVIE5NiGBDTIhCBwVh2U/ilQBAQE?= X-IronPort-AV: E=Sophos;i="5.42,362,1500940800"; d="scan'208,217";a="654481596" 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; 08 Sep 2017 15:22:31 +0000 Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v88FMVSo005222; Fri, 8 Sep 2017 15:22:31 GMT To: Ladislav Lhotka , netmod@ietf.org References: <20170908105648.ur5ihv3gvypd7d7f@elstar.local> <20170908123853.4jmy24gvbe2agiif@elstar.local> <2b11208e-a11e-c3ec-dca1-d686bc417a52@cisco.com> <1504880639.21276.72.camel@nic.cz> From: Robert Wilton Message-ID: <6851ec11-5abf-bbca-de5a-f5fc422df9aa@cisco.com> Date: Fri, 8 Sep 2017 16:22:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1504880639.21276.72.camel@nic.cz> Content-Type: multipart/alternative; boundary="------------7116347E38319F74D0A06125" Content-Language: en-US Archived-At: Subject: Re: [netmod] upcoming adoptions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 15:22:37 -0000 This is a multi-part message in MIME format. --------------7116347E38319F74D0A06125 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Pulling out this particular question to see if others have an opinion on this. Should we change 6087bis to reduce it reliance on RFC 2119 language? The reasoning for proposing this change is to avoid accidentally creating future CLRs, because tool implementations might regard the RFC 2119 language in 6087bis as defining rules rather than just offering guidance. An example change: Before: Prefix values SHOULD be short, but also likely to be unique. Prefix values SHOULD NOT conflict with known modules that have been previously published. After: Prefix values should be short, but also likely to be unique. Prefix values SHOULD NOT conflict with known modules that have been previously published. Thanks, Rob On 08/09/2017 15:23, Ladislav Lhotka wrote: > Robert Wilton píše v Pá 08. 09. 2017 v 14:41 +0100: > >> It might be better if a lot of the guidance in 6087bis is changed to avoid >> using RFC 2119 language precisely so that it can't be subsequently interpreted >> as a formal rule. > I very much agree with this, the use of 2119 keywords sometimes makes things > confusing. > > Lada > --------------7116347E38319F74D0A06125 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Pulling out this particular question to see if others have an opinion on this.

Should we change 6087bis to reduce it reliance on RFC 2119 language?

The reasoning for proposing this change is to avoid accidentally creating future CLRs, because tool implementations might regard the RFC 2119 language in 6087bis as defining rules rather than just offering guidance.

An example change:

Before:

   Prefix values SHOULD be short, but also likely to be unique.  Prefix
   values SHOULD NOT conflict with known modules that have been
   previously published.
After:
   Prefix values should be short, but also likely to be unique.  Prefix
   values SHOULD NOT conflict with known modules that have been
   previously published.

Thanks,
Rob


On 08/09/2017 15:23, Ladislav Lhotka wrote:
Robert Wilton píše v Pá 08. 09. 2017 v 14:41 +0100:



      

        
It might be better if a lot of the guidance in 6087bis is changed to avoid
using RFC 2119 language precisely so that it can't be subsequently interpreted
as a formal rule.


      

      
I very much agree with this, the use of 2119 keywords sometimes makes things
confusing.

Lada



    

    

  


--------------7116347E38319F74D0A06125--


From nobody Fri Sep  8 10:00:20 2017
Return-Path: 
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 957D2132D51 for ; Fri,  8 Sep 2017 10:00: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 yKGv5f0tNTHs for ; Fri,  8 Sep 2017 10:00:17 -0700 (PDT)
Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001: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 BBDF3132710 for ; Fri,  8 Sep 2017 10:00:17 -0700 (PDT)
Received: by mail-io0-x235.google.com with SMTP id j141so6934130ioj.4 for ; Fri, 08 Sep 2017 10:00:17 -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=KwPxhciKv9SrW+udXcevl8HbCFekDvF0yywvwv+QpZU=; b=BAUQOlohCwAtnL3KcjaeVGFVFbQCltRYYWJGK9W9l2WymjQtlS2ugj8ZeHcPhm/4nL mmA9Aa3EC9otdt6t/usv9qTzbqaYSTbi8r7KTdNYVjAhnnXutNSZ/0KUww8KVO3NxKZV EbS2YfY0WMXQOCS2X+eDJcGSprlTITFg3ceEVQyDB5F/5mFOk1v6sXEvgjfyAzuow/oz nR5S6M3+PKwNn/w8fy6TdEYFcnBl6eWmEiK9Zui1DlcLBzPcvtMJg0w/stsk9ixOuBxF 2YkwsnBy5ZdgOAQtME+7IGFn29g474i8X6e50PAnRVx4sIyn86IpUIYZCQLxNA1sM7wk PwMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KwPxhciKv9SrW+udXcevl8HbCFekDvF0yywvwv+QpZU=; b=qIchMuTSmoBpDZNKLGGbeyIRwbtdgIx5EhcgZB82VUtUDhXkK6EKR/ncw8nROslkFe ETXT+ueJZYHcjf0ZGQazLvw/+lyKMbATq+FUnDRt7k60jDqH2YYFfK10Uj2pfecFZIkw PaDQpsvW+r3yNgW941f1kZg4d87yvUAvpNSsimFIGkoFjjn6UAG7SJL9PzbBp5WTDTPA KLp/aB1u/+NLegtpTSvjUluAHmD3M+/h0jwrn2QN4ku1q7qDhkJUfTAzLuw/0TREZ8hR GH3ocIuUJ8O2x4sQFTGiynUvz9daEbY7Bt3nj/PfZrhdzpBEYUGb6IMeAtC0LauIlzHX ca+g==
X-Gm-Message-State: AHPjjUgdWqzDoqgG+5hxxtCBwg1XzJ68k5ze92VYHFV83ZFU40C7S6Q/ mdnpWCKkVv9vgT/OcZJXX7reifmbeqR+
X-Google-Smtp-Source: AOwi7QAxf6+lB1Dhk5dcW3B2/dYq9TWGLvzb0IwrWa1PkigrShRR0byXqyohHCmNK0BhqcJ4wt6QLgRnVO3wqRcu4eg=
X-Received: by 10.107.104.25 with SMTP id d25mr3978418ioc.90.1504890017055; Fri, 08 Sep 2017 10:00:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.36.6.206 with HTTP; Fri, 8 Sep 2017 10:00:16 -0700 (PDT)
In-Reply-To: <2b11208e-a11e-c3ec-dca1-d686bc417a52@cisco.com>
References: <20170908105648.ur5ihv3gvypd7d7f@elstar.local>  <20170908123853.4jmy24gvbe2agiif@elstar.local> <2b11208e-a11e-c3ec-dca1-d686bc417a52@cisco.com>
From: Andy Bierman 
Date: Fri, 8 Sep 2017 10:00:16 -0700
Message-ID: 
To: Robert Wilton 
Cc: Martin Bjorklund , NETCONF Working Group ,  "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="089e08260100e4b9520558b082b2"
Archived-At: 
Subject: Re: [netmod] upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Sep 2017 17:00:19 -0000

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

Hi,

There are many YANG guidelines that are for promoting a consistent structure
for all IETF modules.  YANG is just more source code.  Each organization
can have
different coding guidelines, yet they can all use the same compiler.

I should explain the use-case for identifying NMDA vs. NMDA-transition
modules.
I do not want to present both types (for a given module) to the user.
So the tools need to know in "NMDA mode" which modules are duplicates
for NMDA-transition purpose only, so those modules can be hidden from the
user.
In "legacy mode" the NMDA modules would be hidden and the transition modules
would be exposed to the user instead.

Guessing which is which will only cause unhappy customers so we will force
vendors to tag the modules with our own YANG extensions to tell them apart.

Andy


On Fri, Sep 8, 2017 at 6:41 AM, Robert Wilton  wrote:

>
>
> On 08/09/2017 13:38, Juergen Schoenwaelder wrote:
>
> On Fri, Sep 08, 2017 at 01:19:03PM +0100, Robert Wilton wrote:
>
> In the same vane, I think that you could regard RFC 6087 and 6087bis as one
> long list of CLRs ...
>
>
> No. There are guidelines that have a clear technical reason. An example:
>
>    The 'preceding-sibling' and 'following-sibling' axes SHOULD NOT used.
>    A server is only required to maintain the relative XML document order
>    of all instances of a particular user-ordered list or leaf-list.
>
> Yes, but even this rule has problems.  Does this mean an implementation
> does not need to support "preceding-sibling and following-sibling"?  Given
> this is only a "SHOULD NOT", it means that there might be some modules may
> still use them.  Likewise for the rest of the XPath "SHOULD NOT" rules.
> Will YANG implementations fragment on which subsets of Xpath they regard as
> sane and choose to implement?
>
> [As an aside: I actually think that it would be better to restrict the
> usage of Xpath to a much smaller subset that makes sense, but that should
> be done in 7950bis rather than 6087bis.]
>
> Besides, 6087bis has many softer rules as well, a few examples give below
> (I'm not even sure why the last one is a rule).  There don't obviously
> appear to be any technical reasons for any of these, but I don't object to
> any of these since they are provide sensible guidance, or try to encourage
> consistent modelling conventions in IETF YANG models.
>
> Ex1:
>
>  Identifiers SHOULD follow a consistent naming pattern throughout the
>    module.  Only lower-case letters, numbers, and dashes SHOULD be used
>    in identifier names.
>
>
> Ex2:
>
>  Definitions for future use SHOULD NOT be specified in a module.
>
>
> Ex3:
>
>    The signed numeric data types (i.e., 'int8', 'int16', 'int32', and
>    'int64') SHOULD NOT be used unless negative values are allowed for
>    the desired semantics.
>
>
>
>
> This is very different from guidelines how things should be named that
> do not have a real technical reason. In SMIv2 land, we had this weird
> rule that names of counters should end with a plural 's' and tools
> started to implement this and to complain if there was no plural s.
> (Actually, tools checked whether the last character is an s, which of
> course does not mean there is a plural form.) And of course, there are
> irregular nouns in English wrt. plural forms.
>
> As per ex1 above, perhaps YANG tools will start to assume that identifiers
> cannot contain uppercase characters.
>
> It might be better if a lot of the guidance in 6087bis is changed to avoid
> using RFC 2119 language precisely so that it can't be subsequently
> interpreted as a formal rule.
>
> But I still see guidance on how to consistently name counters and list
> elements is good way of helping achieve consistency, and make the models
> read better.  This doesn't mean that tools should interpret these as rules.
>
>
>
> I do not want rules that say '-state' should not be used. There may
> be valid reasons to use '-state'.
>
> Yes there might, but most likely when someone uses "-state" in the name of
> a container they will be doing the wrong thing, and it may cause them
> problems down the line.  Warning them of the potential problems now so that
> they make an informed decision seems generally helpful to humanity.  This
> does not mean that it needs to be a rule, or is even allowed to be
> interpreted as such.
>
> Thanks,
> Rob
>
>
> /js
>
>
>
>

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


Hi,

There are many YANG guidelines that=
 are for promoting a consistent structure
for all IETF modules.=
=C2=A0 YANG is just more source code.=C2=A0 Each organization can have
different coding guidelines, yet they can all use the same compiler.<=
/div>

I should explain the use-case for identifying NMDA=
 vs. NMDA-transition modules.
I do not want to present both types=
 (for a given module) to the user.
So the tools need to know in &=
quot;NMDA mode" which modules are duplicates
for NMDA-transi=
tion purpose only, so those modules can be hidden from the user.
=
In "legacy mode" the NMDA modules would be hidden and the transit=
ion modules
would be exposed to the user instead.

<=
/div>
Guessing which is which will only cause unhappy customers so we w=
ill force
vendors to tag the modules with our own YANG extensions=
 to tell them apart.

Andy


On Fri, Sep 8, =
2017 at 6:41 AM, Robert Wilton <rwilton@cisco.com> wrote:

 =20
   =20
 =20
  

    


    

    

    
On 08/09/2017 13:38=
, Juergen
      Schoenwaelder wrote:

    

    

      
On Fri, Sep 08, 2017 at 01:19:03PM +0100, Robert Wilton wrote:


      

        
In the same vane, I think that you could regard RFC 6087 and 6=
087bis as one
long list of CLRs ...



      

      
No. There are guidelines that have a clear technical reason. An =
example:

   The 'preceding-sibling' and 'following-sibling' axes SHO=
ULD NOT used.
   A server is only required to maintain the relative XML document order
   of all instances of a particular user-ordered list or leaf-list.

    

    Yes, but even this rule has problems.=C2=A0 Does this mean an
    implementation does not need to support "preceding-sibling and
    following-sibling"?=C2=A0 Given this is only a "SHOULD NOT&qu=
ot;, it means
    that there might be some modules may still use them.=C2=A0 Likewise for
    the rest of the XPath "SHOULD NOT" rules.=C2=A0 Will YANG imp=
lementations
    fragment on which subsets of Xpath they regard as sane and choose to
    implement?

    

    [As an aside: I actually think that it would be better to restrict
    the usage of Xpath to a much smaller subset that makes sense, but
    that should be done in 7950bis rather than 6087bis.]

    

    Besides, 6087bis has many softer rules as well, a few examples give
    below (I'm not even sure why the last one is a rule).=C2=A0 There d=
on't
    obviously appear to be any technical reasons for any of these, but I
    don't object to any of these since they are provide sensible
    guidance, or try to encourage consistent modelling conventions in
    IETF YANG models.

    

    Ex1:

    
 Identifiers SHOULD follo=
w a consistent naming pattern throughout the
   module.  Only lower-case letters, numbers, and dashes SHOULD be used
   in identifier names.

    

    Ex2:

    
 Definitions for future u=
se SHOULD NOT be specified in a module.

    

    Ex3:

    
   The signed numeric dat=
a types (i.e., 'int8', 'int16', 'int32', and
   'int64') SHOULD NOT be used unless negative values are allowed f=
or
   the desired semantics.

    

    

    

      
This is very different from guidelines how things should be named that
do not have a real technical reason. In SMIv2 land, we had this weird
rule that names of counters should end with a plural 's' and tools
started to implement this and to complain if there was no plural s.
(Actually, tools checked whether the last character is an s, which of
course does not mean there is a plural form.) And of course, there are
irregular nouns in English wrt. plural forms.

    

    As per ex1 above, perhaps YANG tools will start to assume that
    identifiers cannot contain uppercase characters.

    

    It might be better if a lot of the guidance in 6087bis is changed to
    avoid using RFC 2119 language precisely so that it can't be
    subsequently interpreted as a formal rule.

    

    But I still see guidance on how to consistently name counters and
    list elements is good way of helping achieve consistency, and make
    the models read better.=C2=A0 This doesn't mean that tools should
    interpret these as rules.

    

    

    

      
I do not want rules that say '-state' should not be used. There may
be valid reasons to use '-state'.

    

    Yes there might, but most likely when someone uses "-state" i=
n the
    name of a container they will be doing the wrong thing, and it may
    cause them problems down the line.=C2=A0 Warning them of the potential
    problems now so that they make an informed decision seems generally
    helpful to humanity.=C2=A0 This does not mean that it needs to be a rul=
e,
    or is even allowed to be interpreted as such.

    

    Thanks,

    Rob

    

    

      
/js



    

    

  






--089e08260100e4b9520558b082b2--


From nobody Fri Sep  8 10:22:02 2017
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB8D013219F; Fri,  8 Sep 2017 10:21:54 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.60.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150489131462.17204.1429487049430679869@ietfa.amsl.com>
Date: Fri, 08 Sep 2017 10:21:54 -0700
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-14.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Sep 2017 17:21:55 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

        Title           : Guidelines for Authors and Reviewers of YANG Data Model Documents
        Author          : Andy Bierman
	Filename        : draft-ietf-netmod-rfc6087bis-14.txt
	Pages           : 70
	Date            : 2017-09-08

Abstract:
   This memo provides guidelines for authors and reviewers of Standards
   Track specifications containing YANG data model modules.  Applicable
   portions may be used as a basis for reviews of other YANG data model
   documents.  Recommendations and procedures are defined, which are
   intended to increase interoperability and usability of Network
   Configuration Protocol (NETCONF) and RESTCONF protocol
   implementations that utilize YANG data model modules.  This document
   obsoletes RFC 6087.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-14
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6087bis-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6087bis-14


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Fri Sep  8 10:40:10 2017
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C99132CE9; Fri,  8 Sep 2017 10:40:03 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.60.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150489240326.17308.12485219722282605881@ietfa.amsl.com>
Date: Fri, 08 Sep 2017 10:40:03 -0700
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-syslog-model-17.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Sep 2017 17:40:03 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

        Title           : A YANG Data Model for Syslog Configuration
        Authors         : Clyde Wildes
                          Kiran Koushik
	Filename        : draft-ietf-netmod-syslog-model-17.txt
	Pages           : 33
	Date            : 2017-09-08

Abstract:
   This document defines a YANG data model for the configuration of a
   syslog process.  It is intended this model be used by vendors who
   implement syslog in their systems.

Editorial Note (To be removed by RFC Editor)

   This draft contains many placeholder values that need to be replaced
   with finalized values at the time of publication.  This note
   summarizes all of the substitutions that are needed.  No other RFC
   Editor instructions are specified elsewhere in this document.

   Artwork in this document contains shorthand references to drafts in
   progress.  Please apply the following replacements:

   o  "xxxx" --> the assigned RFC value for draft-ietf-netconf-keystore


   o  "yyyy" --> the assigned RFC value for draft-ietf-netconf-tls-
      client-server


   o  "zzzz" --> the assigned RFC value for this draft



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-17
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-syslog-model-17

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-17


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Fri Sep  8 13:13:11 2017
Return-Path: 
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 57AB4132F0F for ; Fri,  8 Sep 2017 13:13:10 -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 u0sT7Vc02myd for ; Fri,  8 Sep 2017 13:13:06 -0700 (PDT)
Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93806132F09 for ; Fri,  8 Sep 2017 13:13:00 -0700 (PDT)
Received: by mail-lf0-x22a.google.com with SMTP id c80so7898321lfh.0 for ; Fri, 08 Sep 2017 13:13:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=eNLpSXPD4WUGyy7kEA/LBli90NrAZl4BO000sCqSn9s=; b=KimBqP5OAqkNLydvj+ldY29vOWmz9+QIsuMCuXWpndr3gKeFuUu5tOcqAVJ293RwQD KpjLM+ymX2jK8lPwHnQTxQJHkNO89eTkN9lzn2tWAZ4qfED0BRACqNG4SKIi8wsn0DGk 4fy8OC14LRKeUx9NJeSgSTX2diKMj5zeT2MbcsIy4rR1ZpY7NPaOVndwxDFGhmXByv95 gr3AIWA6U7BHTzhZQe3V4rAfIa0dGpMtezX1U5ADp/F+rt6j72IN2G6NfnTXMhw6z5uk J3bquUvE+5N5q3w+HnPjXGKJAE+vgDMRf/qH0mEWnP+4Hlr2AalO2K6JCUKrstVqAooG UiWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=eNLpSXPD4WUGyy7kEA/LBli90NrAZl4BO000sCqSn9s=; b=lShNgVbIAHDv5mxJ4LPoh9hjHXeNu9pvC3ZYT+aRKm5o4eLhz6AiEIddyRd+u53tHm KYGzxP3Ag5I/0r8M24aodD513fAmNe8bL6gAQTiholNtousG0HjQHAUPEChfhmIuvRYZ EvC2L3tsZhJ504vsswA0X5WQsjx/JxmixeGG24JhSGvgAejUdFgdR4MEoUBZhHIl24Wl Ju313HU9EKE3TgYjsMPdXyb3MUpRajkyD1QKP19FSanklLHoHUvPMBLQAUJSkTUjJU0T aWTxXiR3jB2wQAWe2AMvb69Jo4tSXHv2fA9+ozWybTG6hq+ljG2o4GiSx2m0aQZnDG5C 4O3Q==
X-Gm-Message-State: AHPjjUj7tpB8auIy0mjYtRXuF3g+a5Afyr+CIy9FbC0phV3Ywb1e8iv5 QomEFFUjcWG1mg==
X-Google-Smtp-Source: AOwi7QD7i5hMG0xUHp7yiS4jeRq1mqsD8kStQ/V3QgkUHX4yQKKtRYefieRGlqrYG+uAQcQSZ7twKA==
X-Received: by 10.25.152.6 with SMTP id a6mr1200689lfe.171.1504901578677; Fri, 08 Sep 2017 13:12:58 -0700 (PDT)
Received: from xliuus (wsip-98-191-72-170.dc.dc.cox.net. [98.191.72.170]) by smtp.gmail.com with ESMTPSA id k184sm432990lfg.53.2017.09.08.13.12.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Sep 2017 13:12:57 -0700 (PDT)
From: "Xufeng Liu" 
To: "'Kent Watsen'" , "'Acee Lindem \(acee\)'" , "'Lou Berger'" , "'Martin Bjorklund'" 
Cc: 
References:  <20170906.200545.1646568136744118938.mbj@tail-f.com> <9acc6055-c7b0-8c80-3468-72b090b9253f@labn.net>    <6A207CF2-8130-477C-8A19-4285756490E2@juniper.net>
In-Reply-To: <6A207CF2-8130-477C-8A19-4285756490E2@juniper.net>
Date: Fri, 8 Sep 2017 16:12:53 -0400
Message-ID: <075501d328de$dcdd7cb0$96987610$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIfPr93bBhKKI6OBZkNVcz7tJHAsQEn1MPDAccctw8A+7iScAB3YJYUAmTm3XYBY450mKHR42Vg
Content-Language: en-us
x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5LnR4dCIgcD0iYzpcdXNlcnNceGxpdVxhcHBkYXRhXHJvYW1pbmdcMDlkODQ5YjYtMzJkMy00YTQwLTg1ZWUtNmI4NGJhMjllMzViXG1zZ3NcbXNnLTE3NWUxZDY4LTk0ZDItMTFlNy05YzI4LTE4NWUwZmUzYzQ1Y1xhbWUtdGVzdFwxNzVlMWQ2OS05NGQyLTExZTctOWMyOC0xODVlMGZlM2M0NWNib2R5LnR4dCIgc3o9IjI3NjkiIHQ9IjEzMTQ5Mzc1MTcyOTI3MDU3OCIgaD0iNmVOSVZxOEQwZXJwZXVvcGRjaDU0Y2dkWG5nPSIgaWQ9IiIgYmw9IjAiIGJvPSIxIi8+PC9tZXRhPg==
Archived-At: 
Subject: Re: [netmod] two options for removing /foo-state trees?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Sep 2017 20:13:10 -0000

A consequence of this discussion, I have a question about writing a =
model to augment RFC8022bis or RFC7223bis:

The new augmentation model is NMDA compliant, but also requires =
immediate support for "in use" and "system created" information, as =
described in Sec 1.3 of the guidelines =
(https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01).=20

In such a case, the relevant suggestions in the guidelines are:

(b) Write a non-NMDA module that mirror the NMDA module.=20
    -- This cannot be done because we are augmenting RFC8022bis or =
RFC7233bis, which do not have the non-NMDA modules.

(d) It is RECOMMENDED to augment only the "/foo" hierarchy of the base =
model. Where this recommendation cannot be followed, then any new =
"state" elements SHOULD be included in their own module.

The question is about the (d) above. We seem have to augment the =
deprecated "/foo-state" branch, right? We would also have to use the =
deprecated =E2=80=9Cinterface-state-ref=E2=80=9D?=20

Thanks,
- Xufeng

> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent Watsen
> Sent: Thursday, September 7, 2017 7:28 PM
> To: Acee Lindem (acee) ; Lou Berger =
;
> Martin Bjorklund 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] two options for removing /foo-state trees?
>=20
>=20
> >>Does this mean you're okay reposting your ID similar to Martin's?
> >>I ask as a chair interested in starting the adoption process on =
these
> >>nmda-update drafts.
> >
> > I would hope this is not a prerequisite? We are evaluating how bad
> > this will be. I=E2=80=99d ask how many implementations there are of =
ietf-routing?
>=20
> Yes, please provide this info when you have it.
>=20
>=20
> >>> However, what about secondary and tertiary implications of moving =
to
> >>> NDMA? If we change a path from =
=E2=80=9Cinterface-state-ref=E2=80=9D to =E2=80=9Cinterface-ref=E2=80=9D
> >>> to reference an interface, I=E2=80=99d hope no one would expect =
the old
> >>> statement to be kept around=E2=80=A6
> >>
> >>But the old statement would be kept around, in its deprecated form.
> >>Of course, the nmda-guidelines should cause those downstream modules
> >>to be updated to NMDA as well, so hopefully just a short-lived =
issue.
> >
> > This could be really ugly and cascade if we are just using a =
different
> > path for a reference. Hopefully, all the old references are in
> > deprecated trees. Otherwise, I guess the new data leaf would need a =
unique
> name.
>=20
> Indeed.  Let's see what the analysis reveals.
>=20
> Kent
>=20
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Fri Sep  8 13:18:05 2017
Return-Path: 
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 B0F8C132964 for ; Fri,  8 Sep 2017 13:18:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 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, 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 0n_eBU2aeoVS for ; Fri,  8 Sep 2017 13:18:01 -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 2A2C1132941 for ; Fri,  8 Sep 2017 13:18:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4172; q=dns/txt; s=iport; t=1504901881; x=1506111481; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uxAFijTGXTJlhlcX7J8pgQrmR6fXFUdfeGwi1iMOh/M=; b=XBKQbRvGZpjNnaYXmJ5gBstQA4khSUUikx7QDYMDAGuGq3JQk2Pg1diZ P6ZrkbWxbJg0Ew/TTD+kIVZHfddJyoz4zPwVnwkJqCuvKC2cwnhJnLC78 gQV3ZiKqh8V/MG1CEey2ypjPymODF8tt2mJftiLg/7JjVdPupTo5xEpKX 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BbAwCz+rJZ/5RdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbicHg3CaRIFxd4dCkAEKGAuETE8CGoNxVwECAQEBAQECayi?= =?us-ascii?q?FGAEBAQQBASEROgsMBAIBCBEEAQEDAiMDAgICHwYLFAEICAIEAQ0FihkDFRCrR?= =?us-ascii?q?IInhzgNg3sBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYENgh2CAoMxgnM1gleFMYJ?= =?us-ascii?q?hBZEojxA8AodZiACEdoIThWeKd4l8gleIKwIRGQGBOAFXgQ13FUmHG3YBiQ6BD?= =?us-ascii?q?wEBAQ?=
X-IronPort-AV: E=Sophos;i="5.42,363,1500940800";  d="scan'208";a="886714"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Sep 2017 20:18:00 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v88KHx3b017977 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Sep 2017 20:18:00 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 8 Sep 2017 16:17:59 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1263.000; Fri, 8 Sep 2017 16:17:59 -0400
From: "Acee Lindem (acee)" 
To: Xufeng Liu , "'Kent Watsen'" , "'Lou Berger'" , "'Martin Bjorklund'" 
CC: "netmod@ietf.org" , Yingzhen Qu 
Thread-Topic: [netmod] two options for removing /foo-state trees?
Thread-Index: AQHTJzZlKMfT3FTQbEyg9FUCwcWxgKKoaiaAgAFZEgD//8CXgIAAkGoA///AdoCAAIH0AIABW7KA//++U4A=
Date: Fri, 8 Sep 2017 20:17:59 +0000
Message-ID: 
References:  <20170906.200545.1646568136744118938.mbj@tail-f.com> <9acc6055-c7b0-8c80-3468-72b090b9253f@labn.net>    <6A207CF2-8130-477C-8A19-4285756490E2@juniper.net> <075501d328de$dcdd7cb0$96987610$@gmail.com>
In-Reply-To: <075501d328de$dcdd7cb0$96987610$@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.196]
Content-Type: text/plain; charset="utf-8"
Content-ID: <40A6734CBC8ED249A2592F87CE5EAA4C@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] two options for removing /foo-state trees?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Sep 2017 20:18:03 -0000

SGkgWHVmZW5nLCANCg0KSeKAmW0gaG9waW5nIGFsbCBvdXIgcmVmZXJlbmNlcyB0byDigJxpbnRl
cmZhY2Utc3RhdGUtcmVm4oCdIHdpbGwgYmUgaW4gc2NoZW1hDQpub2RlcyB0aGF0IGFyZSB0aGVt
c2VsdmVzIGJlaW5nIGRlcHJlY2F0ZWQuIFlpbmd6aGVuIGlzIGludmVzdGlnYXRpbmcuDQoNClRo
YW5rcywNCkFjZWUgDQoNCk9uIDkvOC8xNywgNDoxMiBQTSwgIlh1ZmVuZyBMaXUiIDx4dWZlbmcu
bGl1LmlldGZAZ21haWwuY29tPiB3cm90ZToNCg0KPkEgY29uc2VxdWVuY2Ugb2YgdGhpcyBkaXNj
dXNzaW9uLCBJIGhhdmUgYSBxdWVzdGlvbiBhYm91dCB3cml0aW5nIGEgbW9kZWwNCj50byBhdWdt
ZW50IFJGQzgwMjJiaXMgb3IgUkZDNzIyM2JpczoNCj4NCj5UaGUgbmV3IGF1Z21lbnRhdGlvbiBt
b2RlbCBpcyBOTURBIGNvbXBsaWFudCwgYnV0IGFsc28gcmVxdWlyZXMgaW1tZWRpYXRlDQo+c3Vw
cG9ydCBmb3IgImluIHVzZSIgYW5kICJzeXN0ZW0gY3JlYXRlZCIgaW5mb3JtYXRpb24sIGFzIGRl
c2NyaWJlZCBpbg0KPlNlYyAxLjMgb2YgdGhlIGd1aWRlbGluZXMNCj4oaHR0cHM6Ly90b29scy5p
ZXRmLm9yZy9odG1sL2RyYWZ0LWRzZHQtbm1kYS1ndWlkZWxpbmVzLTAxKS4NCj4NCj5JbiBzdWNo
IGEgY2FzZSwgdGhlIHJlbGV2YW50IHN1Z2dlc3Rpb25zIGluIHRoZSBndWlkZWxpbmVzIGFyZToN
Cj4NCj4oYikgV3JpdGUgYSBub24tTk1EQSBtb2R1bGUgdGhhdCBtaXJyb3IgdGhlIE5NREEgbW9k
dWxlLg0KPiAgICAtLSBUaGlzIGNhbm5vdCBiZSBkb25lIGJlY2F1c2Ugd2UgYXJlIGF1Z21lbnRp
bmcgUkZDODAyMmJpcyBvcg0KPlJGQzcyMzNiaXMsIHdoaWNoIGRvIG5vdCBoYXZlIHRoZSBub24t
Tk1EQSBtb2R1bGVzLg0KPg0KPihkKSBJdCBpcyBSRUNPTU1FTkRFRCB0byBhdWdtZW50IG9ubHkg
dGhlICIvZm9vIiBoaWVyYXJjaHkgb2YgdGhlIGJhc2UNCj5tb2RlbC4gV2hlcmUgdGhpcyByZWNv
bW1lbmRhdGlvbiBjYW5ub3QgYmUgZm9sbG93ZWQsIHRoZW4gYW55IG5ldyAic3RhdGUiDQo+ZWxl
bWVudHMgU0hPVUxEIGJlIGluY2x1ZGVkIGluIHRoZWlyIG93biBtb2R1bGUuDQo+DQo+VGhlIHF1
ZXN0aW9uIGlzIGFib3V0IHRoZSAoZCkgYWJvdmUuIFdlIHNlZW0gaGF2ZSB0byBhdWdtZW50IHRo
ZQ0KPmRlcHJlY2F0ZWQgIi9mb28tc3RhdGUiIGJyYW5jaCwgcmlnaHQ/IFdlIHdvdWxkIGFsc28g
aGF2ZSB0byB1c2UgdGhlDQo+ZGVwcmVjYXRlZCDigJxpbnRlcmZhY2Utc3RhdGUtcmVm4oCdPw0K
Pg0KPlRoYW5rcywNCj4tIFh1ZmVuZw0KPg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N
Cj4+IEZyb206IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh
bGYgT2YgS2VudCBXYXRzZW4NCj4+IFNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgNywgMjAxNyA3
OjI4IFBNDQo+PiBUbzogQWNlZSBMaW5kZW0gKGFjZWUpIDxhY2VlQGNpc2NvLmNvbT47IExvdSBC
ZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+Ow0KPj4gTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwt
Zi5jb20+DQo+PiBDYzogbmV0bW9kQGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW25ldG1vZF0g
dHdvIG9wdGlvbnMgZm9yIHJlbW92aW5nIC9mb28tc3RhdGUgdHJlZXM/DQo+PiANCj4+IA0KPj4g
Pj5Eb2VzIHRoaXMgbWVhbiB5b3UncmUgb2theSByZXBvc3RpbmcgeW91ciBJRCBzaW1pbGFyIHRv
IE1hcnRpbidzPw0KPj4gPj5JIGFzayBhcyBhIGNoYWlyIGludGVyZXN0ZWQgaW4gc3RhcnRpbmcg
dGhlIGFkb3B0aW9uIHByb2Nlc3Mgb24gdGhlc2UNCj4+ID4+bm1kYS11cGRhdGUgZHJhZnRzLg0K
Pj4gPg0KPj4gPiBJIHdvdWxkIGhvcGUgdGhpcyBpcyBub3QgYSBwcmVyZXF1aXNpdGU/IFdlIGFy
ZSBldmFsdWF0aW5nIGhvdyBiYWQNCj4+ID4gdGhpcyB3aWxsIGJlLiBJ4oCZZCBhc2sgaG93IG1h
bnkgaW1wbGVtZW50YXRpb25zIHRoZXJlIGFyZSBvZg0KPj5pZXRmLXJvdXRpbmc/DQo+PiANCj4+
IFllcywgcGxlYXNlIHByb3ZpZGUgdGhpcyBpbmZvIHdoZW4geW91IGhhdmUgaXQuDQo+PiANCj4+
IA0KPj4gPj4+IEhvd2V2ZXIsIHdoYXQgYWJvdXQgc2Vjb25kYXJ5IGFuZCB0ZXJ0aWFyeSBpbXBs
aWNhdGlvbnMgb2YgbW92aW5nIHRvDQo+PiA+Pj4gTkRNQT8gSWYgd2UgY2hhbmdlIGEgcGF0aCBm
cm9tIOKAnGludGVyZmFjZS1zdGF0ZS1yZWbigJ0gdG8NCj4+4oCcaW50ZXJmYWNlLXJlZuKAnQ0K
Pj4gPj4+IHRvIHJlZmVyZW5jZSBhbiBpbnRlcmZhY2UsIEnigJlkIGhvcGUgbm8gb25lIHdvdWxk
IGV4cGVjdCB0aGUgb2xkDQo+PiA+Pj4gc3RhdGVtZW50IHRvIGJlIGtlcHQgYXJvdW5k4oCmDQo+
PiA+Pg0KPj4gPj5CdXQgdGhlIG9sZCBzdGF0ZW1lbnQgd291bGQgYmUga2VwdCBhcm91bmQsIGlu
IGl0cyBkZXByZWNhdGVkIGZvcm0uDQo+PiA+Pk9mIGNvdXJzZSwgdGhlIG5tZGEtZ3VpZGVsaW5l
cyBzaG91bGQgY2F1c2UgdGhvc2UgZG93bnN0cmVhbSBtb2R1bGVzDQo+PiA+PnRvIGJlIHVwZGF0
ZWQgdG8gTk1EQSBhcyB3ZWxsLCBzbyBob3BlZnVsbHkganVzdCBhIHNob3J0LWxpdmVkIGlzc3Vl
Lg0KPj4gPg0KPj4gPiBUaGlzIGNvdWxkIGJlIHJlYWxseSB1Z2x5IGFuZCBjYXNjYWRlIGlmIHdl
IGFyZSBqdXN0IHVzaW5nIGEgZGlmZmVyZW50DQo+PiA+IHBhdGggZm9yIGEgcmVmZXJlbmNlLiBI
b3BlZnVsbHksIGFsbCB0aGUgb2xkIHJlZmVyZW5jZXMgYXJlIGluDQo+PiA+IGRlcHJlY2F0ZWQg
dHJlZXMuIE90aGVyd2lzZSwgSSBndWVzcyB0aGUgbmV3IGRhdGEgbGVhZiB3b3VsZCBuZWVkIGEN
Cj4+dW5pcXVlDQo+PiBuYW1lLg0KPj4gDQo+PiBJbmRlZWQuICBMZXQncyBzZWUgd2hhdCB0aGUg
YW5hbHlzaXMgcmV2ZWFscy4NCj4+IA0KPj4gS2VudA0KPj4gDQo+PiANCj4+IA0KPj4gX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IG5ldG1vZCBtYWls
aW5nIGxpc3QNCj4+IG5ldG1vZEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9uZXRtb2QNCj4NCg0K


From nobody Mon Sep 11 00:13:44 2017
Return-Path: 
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 ADAE2133016 for ; Mon, 11 Sep 2017 00:13:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.649
X-Spam-Level: 
X-Spam-Status: No, score=-4.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_20=1.546, HTML_IMAGE_RATIO_08=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7ZW_udKmmmq for ; Mon, 11 Sep 2017 00:13:41 -0700 (PDT)
Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92282133010 for ; Mon, 11 Sep 2017 00:13:39 -0700 (PDT)
Received: from epcas5p2.samsung.com (unknown [182.195.41.40]) by mailout3.samsung.com (KnoxPortal) with ESMTP id 20170911071337epoutp03ee0b8d05160591dee054e7d7206ba112~jPTmIuQVq2185321853epoutp031 for ; Mon, 11 Sep 2017 07:13:37 +0000 (GMT)
Received: from epsmges5p2new.samsung.com (unknown [182.195.42.74]) by epcas5p1.samsung.com (KnoxPortal) with ESMTP id 20170911071337epcas5p1a8b107d065bdba62d0f08287e5d84b9b~jPTl0Iyad1132011320epcas5p1e; Mon, 11 Sep 2017 07:13:37 +0000 (GMT)
X-AuditID: b6c32a4a-f79896d000000f29-39-59b637a11192
Received: from epcas5p1.samsung.com ( [182.195.41.39]) by epsmges5p2new.samsung.com (Symantec Messaging Gateway) with SMTP id 6E.A3.03881.1A736B95; Mon, 11 Sep 2017 16:13:37 +0900 (KST)
Mime-Version: 1.0
Reply-To: sk.srivastav@samsung.com
Sender: Sudhanshu Kumar Srivastav 
From: Sudhanshu Kumar Srivastav 
To: "netmod@ietf.org" 
CC: "cpgs ." 
X-Priority: 3
X-Content-Kind-Code: NORMAL
X-Drm-Type: N,general
X-EPLocale: en_US.EUC-KR
X-EPWebmail-Msg-Type: personal
X-Msg-Generator: Mail
X-Msg-Type: PERSONAL
X-Reply-Demand: N
X-Sender: =?utf-8?B?U2Ftc3VuZyBFbGVjdHJvbmljcxtTUkktQg==?= =?utf-8?B?YW5nYWxvcmUtQ1UbQ2hpZWYgRW5naW5lZXI=?=
X-Sender-IP: 107.110.12.116
X-Local-Sender: =?UTF-8?B?U3VkaGFuc2h1IEt1bWFyIFNyaXZhc3RhdhtTUkktQmFuZ2Fsb3JlLUNV?= =?UTF-8?B?G+yCvOyEseyghOyekBtDaGllZiBFbmdpbmVlcg==?=
X-Global-Sender: =?UTF-8?B?U3VkaGFuc2h1IEt1bWFyIFNyaXZhc3RhdhtTUkktQmFuZ2Fsb3JlLUNV?= =?UTF-8?B?G1NhbXN1bmcgRWxlY3Ryb25pY3MbQ2hpZWYgRW5naW5lZXI=?=
X-Sender-Code: =?UTF-8?B?QzEwGxtDMTBJRDAxSUQwMTA5MTU=?=
Message-ID: <20170911071336epcms5p6355cce397f545765e05637bbdf411b15@epcms5p6>
Date: Mon, 11 Sep 2017 07:13:36 +0000
X-CMS-MailID: 20170911071336epcms5p6355cce397f545765e05637bbdf411b15
Content-Type: multipart/related; boundary="----8Ar4uL8unNJNiDbl_JgorJ3NKJ1rOAqY7U1DC95_YQLdtYAr=_54384_"
X-CPGSPASS: Y
X-MTR: 20170911071336epcms5p6355cce397f545765e05637bbdf411b15
CMS-TYPE: 105P
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCKsWRmVeSWpSXmKPExsWy7bCmuu5C822RBsvXSFq8PKRpMf9iI6sD k8eSJT+ZPPq2rGIMYIrisklJzcksSy3St0vgyljzYR1TwfVfTBUfX81lbmB88YGpi5GTQ0LA ROJk1wdmCFtM4sK99WxdjFwcQgK7GSVmHrjM2MXIwcErICjxd4cwiCksoCSx9lQoSLkQkNm4 opcFxBYWsJE49P0YK4jNJmAl8aT/PJgtIqAuMXMnyEhODmYBeYlJx2ayQ6zilZjR/pQFwpaW 2L58KyOELSpxc/VbqBoJidULn7NB2HIS076uYYapeX9sPlS9iETrvbNQcUGJBz93Q8VzJTr2 tzPDzP/77wgjyFsSAt2MEq+u3IJypjBK7D/5BGqDucTl/l6wbl4BX4nmFa1gV7AIqEqsezIX aqqLxOITH1ghvsmSaHz9jBHmm4aNv6GutpVYsu4OC0QNn0Tv7yfQgFaTOHvnARtM/Y55T5gm MCrPQgTvLCRTIWwNidY5c9khbEWJKd0PoWwbidnXj7FgiqtK/DqwhHUBI/sqRsnUguLc9NRi 0wKjvNRyveLE3OLSvHS95PzcTYzg9KPltYNx2TmfQ4wCHIxKPLw7Jm2NFGJNLCuuzD3EqAI0 69GG1RcYpVjy8vNSlUR4Ww22RQrxpiRWVqUW5ccXleakFh9ilOZgURLnPbazNFJIID2xJDU7 NbUgtQgmy8TBKdXAaFMqf2di9Iqkr88NOr+nnpkku7Djj9hDt239bGn37Y5fPjX7B6PX3efx /96du3Fps2S97wpvIbePAR+T+aJ6Zpy9r1uyp2NmeZRsoUbjZVfxM+F/93/4JxWu/nKrx963 Xm/dY0/O/H3nzyHPWXYq+i9KFIofbeGuVZMpdc1TDUj72BZeUnb0nRJLcUaioRZzUXEiAJS8 7FVHAwAA
X-CMS-RootMailID: 20170911071336epcms5p6355cce397f545765e05637bbdf411b15
X-RootMTR: 20170911071336epcms5p6355cce397f545765e05637bbdf411b15
References: 
Archived-At: 
Subject: [netmod] [NETMOD] YANG Data Module
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Sep 2017 07:13:44 -0000

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

PEhUTUw+PEhFQUQ+DQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiIGh0
dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPFNUWUxFIGlkPW15c2luZ2xlX3N0eWxlIHR5cGU9dGV4
dC9jc3M+LnNlYXJjaC13b3JkIHsNCglCQUNLR1JPVU5ELUNPTE9SOiAjZmZlZTk0DQp9DQpQIHsN
CglNQVJHSU4tQk9UVE9NOiA1cHg7IEZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFs
LCBhcmlhbDsgTUFSR0lOLVRPUDogNXB4DQp9DQpURCB7DQoJTUFSR0lOLUJPVFRPTTogNXB4OyBG
T05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCwgYXJpYWw7IE1BUkdJTi1UT1A6IDVw
eA0KfQ0KTEkgew0KCU1BUkdJTi1CT1RUT006IDVweDsgRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZB
TUlMWTogQXJpYWwsIGFyaWFsOyBNQVJHSU4tVE9QOiA1cHgNCn0NCkJPRFkgew0KCUZPTlQtU0la
RTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsLCBhcmlhbA0KfQ0KPC9TVFlMRT4NCg0KPE1FVEEg
Y29udGVudD1JRT01IGh0dHAtZXF1aXY9WC1VQS1Db21wYXRpYmxlPg0KPE1FVEEgY29udGVudD1J
RT01IGh0dHAtZXF1aXY9WC1VQS1Db21wYXRpYmxlPg0KPFNUWUxFIGlkPWtub3hfc3R5bGUgdHlw
ZT10ZXh0L2Nzcz5QIHsNCglNQVJHSU4tQk9UVE9NOiA1cHg7IEZPTlQtU0laRTogMTBwdDsgRk9O
VC1GQU1JTFk6IEFyaWFsLCBhcmlhbDsgTUFSR0lOLVRPUDogNXB4DQp9DQo8L1NUWUxFPg0KDQo8
TUVUQSBjb250ZW50PUlFPTUgaHR0cC1lcXVpdj1YLVVBLUNvbXBhdGlibGU+DQo8TUVUQSBuYW1l
PUdFTkVSQVRPUiBjb250ZW50PSJNU0hUTUwgMTEuMDAuOTYwMC4xODczOSI+PC9IRUFEPg0KPEJP
RFk+DQo8UD5EZWFyIEFkbWluLDwvUD4NCjxQPiZuYnNwOzwvUD4NCjxQPk15c2VsZiBzdWRoYW5z
aHUga3VtYXIgc3JpdmFzdGF2LCB3b3JraW5nIG9uIFlBTkcgRGF0YSBNb2RlbHMgaW4gU2Ftc3Vu
ZzxCUj5vcmdhbml6YXRpb24uPEJSPjxCUj5JIHdhbnQgdG8gY29udHJpYnV0ZSB0byBZQU5HIHNw
YWNlIGluIElFVEYgYnkgdXNpbmcgbXkgb24gam9iIGxlYXJuaW5nLjxCUj48QlI+SSBoYXZlIGRl
dmVsb3BlZCBhIERSQUZUIGZvciBhIG5ldyBZQU5HIG1vZHVsZS4gSSB3YW50IHRvIGZsb2F0IHRo
YXQgWUFORzxCUj5tb2R1bGUgdG8gTkVUTU9EIGdyb3VwIGZvciB0aGVpciBvcGluaW9uIGFuZCBy
ZXZpZXdzLjxCUj48QlI+UmVxdWVzdCB5b3UgdG8ga2luZGx5IGxldCBtZSBrbm93IGhvdyBjYW4g
SSBkbyBpdC48QlI+PEJSPnJlZ2FyZHM8L1A+DQo8UD5TdWRoYW5zaHU8L1A+DQo8UD4mbmJzcDs8
L1A+DQo8UD4mbmJzcDs8L1A+PHRhYmxlIGlkPWNvbmZpZGVudGlhbHNpZ25pbWc+PHRyPjx0ZD4N
CjwhLS08cD4mIzEwOzxpbWcgYm9yZGVyPSIwIiBzcmM9Imh0dHA6Ly93d3cuc2Ftc3VuZy5uZXQv
cHRfaW1hZ2VzL1BDTC9zZWN1cml0eWltYWdlL01TSV8yMDE0MDUxOTAwMzczMjIxNC5naWYiLz48
L3A+JiMxMDstLT4NCjxwPjxpbWcgYm9yZGVyPSIwIiBzcmM9ImNpZDpYT0swTEs3Q1Q5U1pAbmFt
by5jby5rciIvPjwvcD4gDQo8L3RkPjwvdHI+PC90YWJsZT48L0JPRFk+PC9IVE1MPjxpbWcgc3Jj
PSdodHRwOi8vZXh0LnNhbXN1bmcubmV0L21haWwvZXh0L3YxL2V4dGVybmFsL3N0YXR1cy91cGRh
dGU/dXNlcmlkPXNrLnNyaXZhc3RhdiZkbz1iV0ZwYkVsRVBUSXdNVGN3T1RFeE1EY3hNek0yWlhC
amJYTTFjRFl6TlRWalkyVXpPVGRtTlRRMU56WTFaVEExTmpNM1ltSmtaalF4TVdJeE5TWnlaV05w
Y0dsbGJuUkJaR1J5WlhOelBXNWxkRzF2WkVCcFpYUm1MbTl5WndfXycgYm9yZGVyPTAgd2lkdGg9
MCBoZWlnaHQ9MCBzdHlsZT0nZGlzcGxheTpub25lJz4=
------8Ar4uL8unNJNiDbl_JgorJ3NKJ1rOAqY7U1DC95_YQLdtYAr=_54384_
Content-Type: image/png; name="201602111742151_N3WZA6X7.png"
Content-Transfer-Encoding: base64
Content-ID: 

iVBORw0KGgoAAAANSUhEUgAAAggAAADICAIAAAAC6Y6pAAAACXBIWXMAAAsTAAALEwEAmpwYAAAK
T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU
kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX
Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB
eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt
AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3
AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX
Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+
5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk
5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd
0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA
4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA
BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph
CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5
h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+
Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM
WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ
AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io
UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp
r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ
D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb
U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY
/R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir
SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u
p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh
lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1
mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO
k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry
FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I
veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B
Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/
0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p
DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q
PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs
OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5
hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ
rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9
rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d
T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX
Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7
vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S
PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa
RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO
32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21
e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV
P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i
/suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8
IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq
YAAAOpgAABdvkl/FRgAAeCJJREFUeNrsvU1sG8fWJtxjWzdqBjINMoEvDNIXNw4VYCCLeD0bAsRg
TC0GsLjwhgt5QS7DLCJAwAgCZF2tFEUYQcBooAzg9pJcSMDLjRdkgG8hevES4CxeYyhrMSHjzMRs
GPHnkGPKE7Zz9cn3WzxX55arqotNUvJPUgdBYNPd1adOVZ2/OvXUv/nb3/5maNKkSZMmTcd0RotA
kyZNmjRpw6BJkyZNmrRh0KRJkyZN2jBo0qRJkyZtGDRp0qRJkzYMmjRp0qRJGwZNmjRp0qQNgyZN
mjRp0oZBkyZNmjRpw6BJkyZNmrRh0KRJkyZN2jBo0qRJk6Z3mM7+3//7f/8fgUZGRnZ2dp4+ffpv
/+2/fcMMNRqNYDDY1yu2bY+MjIyMjAz2RcuydnZ2/vVf//Xf//t/L3JSrVY3Nzf/3b/7dz6fj/2n
tbU17sc3KSJ8/b//9/++s7PDsf3bpnK5/N/+23/7j//xP76taek4ztOnT8+fP+/xxUKhcO/evVMd
owGWzFuhVqv1X//rf713796//uu/3rt3T7qm/vznP/fVF1r78/Pz58+fD4VCivUy/GodjEmPWuh/
/+//rdC3w4yyd7bpyXMbGxv4aX5+PplMJhIJ/LVarb75qWNZVjAYjEQiffXZsqzFxUXTNAf4om3b
jUYjnU5Ho1FOAVWr1cXFRelbkUiE5Pbm6e1+/XdINBkcx/n666+TyaRUAb1d3t59Me7t7bVarZWV
lcGWqnrtv+8rIpvNnqxiHJLerVRSu90ewA0Z5ouO4xiGIa7zIZvV9FsimgzdbhcT5h3k7b2gYDB4
Ulbhd7VIB1CMQ9I5tTe9trbWarVM08xkMpFIxHGcXC7XaDSgTNPptBiblMvlYrGIB1KpVCgUqlar
xWIRKwpBSbVaLRQKsVgMcUkkEslms5ZltY4pm80Wi8VyuYzJlEqlIpFIoVCo1Wrj4+O1Wg1NhUKh
QqFgGMba2lo2m63X69wrHG9sm4lEIhgMWpaF11OpVCwWY70wRFGpVAoJAfQarJKr4jhOoVCwbdsw
jGg0mk6nRRmqH1hbWzNN03GcVqsFkebzedu2SbwkT3w9k8nYto2vS0etZ4NSlkRpSx8TmTFNkx3x
Vqs1NTWFIeYGneOzWq2Wy2WsbZoqYB5yo1nXarXQBakJh3XH3MBfE4lEMpkUZ0ssFlteXp6bm0Mj
GETOgRW5ajQaNBkoO+Q4DiYkuDJNE+0bhpHP5/FFyAfmZHNzE09CFOANY2GaZjabrVar1WpVvdBE
4di2TbytrKyo1yY7oMSwZVmO46DB27dv7+7uqldQo9EoFArQCWiBY9VtHG3bxiTBmioUCouLi8Fg
kMTFjuwAa9+yLCxhcYq6eYRe5gzmrZRJqdLjFmkoFLJtO5lMsrNFqgcQEyQSibW1tUgk0m63af1C
4H0pRgXb4uvSJ8+oDUMqldrY2AgGg+h2oVBot9uLi4sbGxumaebzeXHeFIvFZDK5srIC0WMmTU1N
bWxspFKpYrHIJqk2NjbS6XSj0ajVatlsNhgMxmKxbDZbLpfL5XI2m93Y2IjFYrlcDmsVC3JjYyOR
SBSLRUxEwzCgJcvlcjqd3tjYCIVCuVxOHDxqE9IMBAKI4BYXF8kqYJbEYrFgMMjGpyyrrJTxT3Nz
c7VaDRJnJ18+n0ecu7i4SGtDdHzS6fTi4mKr1bp7924qlcKfq9Uq5IlOsUqqpyfl1qCUpUajIYpO
7JqUGfyIeRIKhWAJoIMw6JjKrNAgmWKxODk5ifZbrRaJrtVqibPOMIyVlRU8Kfa3Wq3W63VMS6gG
rEButmBNEie1Wi0ajbJWQcoVOxkwzVKpFDW4sbGxsrJCrJbL5VqtNjc3Nzc312g0dnd30Ww0GiU2
ICLHcWKxGLoJDeJloXHCYXmrVqu2bS8uLmLplUol0SsSGUabeAtGUVx0rHxyuRxYHR8fh4HM5XJg
dWVlBSrGjdVkMglWyWKVy+V6vT43N4d3xXXqce2TAfO+XjzOGcdxpEyKSk/6UTQVi8W86AFWznNz
c7RmB1CMbmxLX5c+qTIM0WgUEo9Go7ZtO45Tq9UwEWGXbNuGNInq9ToUq2mai4uLc3Nz9XodltAw
jFgsFo1GSWrQxUjuc7ESFi2+jnf39vbg6eCt8fFxKCB6BSscnlc6nRZHEcyjzVQqZZqm932UZDIp
ZdXn87VarUKhgBnP+cX1er3VauFdDK30i+Pj46FQKBgM+ny+UCiEP0PJYrDxXdZ0qUnRoJQlqejE
rkmZqdfroVAIf4VUIWrTNCGNSCQSjUYxfOxgraysgA1w2O12WebZWddoNGKxmGma9CGOEokElB2N
EZSvOFsikQgNQa1Wm5yc9MiVNCk8NzeHt6LRKL5Yq9UikQje3djYQFMkCnbSEm/oLK0Fx3EUC40T
jqhQEO4sLi6KPqmUYbSJD7ktOnY+w54ZhgE9CLWI4Ns0zVQq1Wq1YHrVrLLLPBQKkYgGW/vc9puX
9eJ9zkiZ9PhR/OhRD7BvmaaJNct107twvMtW+qQqlcRlA7FIisUia+64lKvjOGIAGwgE2DbpFUW2
EWuDczOhrdxeCYVCyWSyVqsVCgXkqeBQsJywO8w+n897vtiN1enpaRiYarUKBtjoG+1vbm66RZ2I
V9jGxQ/BE4RABuCWa1DKklR00q6JzCBXwA0QtBvlXrB4xHgUy4PSiYpZR5PKrawCCpHzVMTZEo1G
2fCFqzhQcCWdohjHRqNBnrXjOGK2QTpp2R+5BxQLTbFkEolEt9ullBQSej0ZZtt0W3QcD+xyhrRp
UNBUT1al6oLkNsDaH2y9eJwzUiY9fpQVCLfoBtA2fQnHu2ylT57zvh2Bb4sFPFyXuPAzFAqxfofj
OF5mDGwXbCwRUgpqLwCLAXk0ilSIE5a3brc7/D4Y8nSpVArJk1wux0YqaF8sw5D6HW4TDpo6EAis
rKwsLy8PybCCJVF0XNeQhOWYCYVCyC+zSg3ePfxTt2TX5uYmPKPFxUUxJ8nNOjj7oiNCE6PRaCA0
SSQSitbgLGNCitPYO1dY5+hmKpWizS1x/g9AXhaaW1ybTCaR3ikWi4hd1Az3XHTi5Gm325weabVa
7Oh4X1amaZJSZv3FAdZ+v+ulrzkjMtnXR90W3WDr16NwvMu2VquJT57pi6dIJFIqlTD1C4XC8vIy
JykEMphz+Xx+eXkZ6hi/VKtVhC1unwgEAmgwGo0iqY235ufnWe3DqWb0h30MbLCuDdpETpz2DxWc
BINBRRqB3enF9jUCMc6fHR8fN00TKXvHcTY3N/Gwd7JtOxgMYsGLuyYDkJQlqejErkmZGR8fJy+7
XC5j+PAjBh0lDJwawrdge/b29txSDTTrqtUqNt+kMXij0YC+m5ycFPWdGDTUarV6vS6OvhtXNBlo
soGZaDSKqJS4ikajjUYDziMJcIDF33OhiRO1UChQqQgGkZ2NbgxzklEvOkweGuv5+XkYbLje2FMM
BoP4uhfCWOArFB4NsPYHWC/e54yUyb4W6fB6YADF6F220ifP9cVfJpPJ5XJra2sYFRSlcOm2ZDKJ
KBgPoMSC4mKqSnJTW8VisdVqzc3NdbtdEh/yGNLYEAn0zc3NdDqdSCTolUQiwa18xNp4AJ4+5+1y
HSkWizjboRAIagaQM6HdMHaFZ7NZxQM9KZFI2LYNHwQVIKgvGsbjEFkKBoOtVosTXTAY5B6DD8Ix
Q+UchUKBGItEIig0oC1fLkiKxWK1Wg3BNbw27E65zTrLsjDrpH1PpVK5XG5+fh4pFHHrixtZKBQx
TeTGFU2GlZUVJKO63S7Nc+x8YPcS44UWILSehmqwhSZOVFQl4RWk+9lXoLlEht0WCC06bvJkMhma
FXgA1Qo0Oul02rtfnEgkaOLRyErZ6Ln2+10v3ueMlMm+FunwemAAxehdtij84578N3/7298MTZpO
iLhjku8m5fP5QCCgNvmaNP2eSWMlaRqKKKVAKcQ3eT5zAELZjPcSL02afod0TotA0zAUi8Xq9TqS
J8hgvDtwESJhax3llXrsNGlyI51K0qRJkyZNr5FOJWnSpEmTpoEMQ6PRmJ+fd6vRLpfLKEvw0sj8
/PzJQreiWa6+SPrj26LnOzvfXbki/offn+/s9NVa27J+uH7d7V8Pm80frl//7sqVp0tLp9Sdo07n
5f6+YRjNTOb0vnJSNICEQU+XlhRydqOTkgnYVo/1iXBFnxhYUOrvNl3QitbW1uYFsiwLdbeDaRjj
uOb4jZFaMYo0jPaDcN5Aj4w3vMeAM7SKc0+/VbowM3NhZsYwjG6l0sxkwrmcLx6HEh+gtUA2G3AH
6X1RKh02m58+eHDW7z8lq/C/EomPFhZGJybCJ3G0QtMbIMVIqafT6RGhQKJQknCnpbqPDmD2VJ1v
GJ66Xwz8YeDBs6c/TITi/kZTSd1u913emfzN0Eg4fEpWwTCMVwcHR52OFrKmd5DePDz1b4wo9Dkn
RVdWYyZLgVsNwwDYDmFCENIkGfPGMS0uLnII2DhxU61WAXmfzWapWSlcsOECKiv+yDUrQnNLIY7F
PrpBjrtJwzu9KJUQ5o9OTFz65puRcPjl/v7TpSWka8ampy9tbXGx//Pt7U/u3//h+nUYgJf7+2f9
/ktbWy/395+tryMt8Mn9+79UKj+vr0OPf7ywEMhmEbKMTky83N//eGHh2fq6Lx7vVioIa/y3btmZ
zFGn44vH4WO2LQsNGobhi8cvbW0h7fB0aelVp/NLpfKHcPji6irH8MWvvnp1cPDD9eu+ePzw8ePD
ZpO6xiZqXnz7LTp71u8P5XKd7e3nOzvoiC8ef76z075zB0HV6MTExdXVw8ePn/7lL58+eEByeFEq
/enePTZlx70yOjFBgc6T2Vn01E3OF7/6SjSoz3d2fl5fNwzjo4UFhH34hZWqdFilj3UrlZ+Wlg6b
TRjvM35/OJdTsP2PGaLs+A/Xr49cvvzr/v5Rp0MtNDOZV50OxPvBxMQfwuGRy5d/qVQoemhmMh/G
44ZhYDqpOaeZMDoxcdhsIs7o2UfDMEYuXx7Ag+SAysmTVagmFrd/fHycXfUsoClgsaGsOOR/cY0j
5RWJRPBjLBYjrHIOgR8YqyxjUo0B1HF818tlBGI8hKOjbjpH+lFRybdaLRHfe29vj1Dcz0jRlRVA
2W64r8Yx+Awdw6tWq+zZY+j6WCy2uLgoImCjEYLqZbvqhm8sBZWVAuRSs8Bp4JgX8YqlMNRSJGSF
NLzT4ePHn9y//8n9+4fN5vPt7aNO58mXX57x+z979OiT+/dfPnxIqlnybrN5cXX1s0ePRsLhZ+vr
gWz244WFkXD4s0ePDh8/frq0FMhmP3v06OLq6rP1dcog++Lxzx49GpueNgzjVafz6YMHl7a2nu/s
PF1a+nO5fGlrq1upvCiVupXKs/X1S1tbaKFbqXR2dqBBLq6ukkI86nTsTAYM/+nevZcPH/58zPCr
TudP9+5R18SslP/WLTBvZzIfXL1KHTnqdH5eXx+bnkabh81m27LA8ItjQOnn29v4hVoTX6F/7ezs
/Lq//8n9+58+eHDU6eATbmyz4oV8Atns06Wlw2YTtgRSDedyz9bXXwgA1zDV4mMwTh/G4589ehT4
4gsYJDXbIHXH/65MK5WPFhY+e/TojN//5MsviX90GX/1z8x0KxVYoMNms1up+GdmvHCOmYCZNjox
AUvgpY+DJUulQOXGMQ4g4MpxkJs9rszCU7OrHjrEDYubhdN3gy53HGdlZSWdTkN33759m0PglzKm
AEL3fhmBdA9Acb+A+FEF+D+H782iuJ8R0ZUVQNlGL2xeQiizbbvVarkdI3JDwAbGmZhZk+Ibu4HK
igC51Kwb8xxesQhD7YaE3BOp2NMOxK1bI+HwSDj8wcTEy/19LN2PFxaQFLpw61bHfUvQF4/Duxyb
noaiIfqlUhkJh6G+L8zMjE1Pd45VM6tWxqanz/r9o1ev0p/xr0cHB6z9uCBoEFYlHXU6f1xdhTt5
4dat5zs70B1okLrGvXjW70ez6AL+PDY9fdTpnPX7P33wAEIYnZj44FgZjd248eLbb6GVDptNVq+5
vcJaDjjmn9y/D+PnxjablIMAA9nsWb//Ran0olQ66/fjR188PjY9DX7EKFB8DF/8aGGBRsQL238f
JveO0zhCgB8vLMCA4dNslIbBhYGBdREjJCnnv1QqoxMTaP/i6ireUvQx8MUX6CMX+ngkKVC5cYxG
B82YSCSgGRWNYNUrYLFF5H8pdDlwFQlFnFrmgKJFxtyA0Ae7jID9luJ+Ae6jCtBvBb73ORFdWQGU
bfTC5o1Go7hKSbwFhSUpArbP55Mi67rhG0tBZaUAudSslHkpXjEHQ03IoxwSck+kYi905vXFeXRw
YBjGjzdvenn3rPut9C/399ko/uz58y+PNQ6rDs64/JmyCr8+fHh0cCD1i8kthQ5lG8Enzii3Os4w
zJ8ROvJyfx+WDIEOtuvHpqebmczRV1+9KJVEvSZ9hbZYjzqdzs4OslUU7nBsvzo4YNtkBXjm/PnD
x49hYL67coW1zZKdmE5HfAyCovbPnj9Prrcb26zeV3ScnQmUXZROjwszM09mZwPZbGdn5+JXX3nk
/KjTeW2enD/v+uTBASvV0YmJv/YfNCgQtjOZzO7uLlYiILncziqyjahhsRWqADd2qIHx3RhTAKEP
dhkBaTbF/QLiR9GgFPRb8a1zInB0LBZTAGVLgVsJKQwIZWBLgUXTFwK2G76xFFRWDZDrBiws4hWL
MNSGDAm5J1LxAITFPHxZ0ejEBKvNj15XeV4IyaULMzMj4fCnDx58f+2a2143zAP+8KrTgfYchvnD
ZvPHmzfHpqfPnj//yf37lBuBC9zZ2ens7MD17vkK0ccLCx8vLCDX8Wx9HU46xzZnn14xvXh1cDBy
+TKS+Gx+383Yi49hOBAPkQfQk+2eHWf9CZI8N/psO2fOn4fbIeaj3Dh/tr6O7RkShbqPL/f3ESsQ
VydFAH2jfdBSqSReScRRX9j1oioYhjG31ga7jIDV/or7BbiPQjtxoN89M95nRHTl8fFxBVB2T9zX
WCyGGw0VoNbeEbAV+MZSUFk1QK6UeRGvmD0DQTDUUiRk7yi4fbhL8fhZv//J7CwW+Y83b7pVgqvp
w3icEtbPd3bgafbVwq8PH46Ewx8tLHy8sAB+yAywGhMM/7S0BI3glqPoi36pVODmX1xdfVEqsWmo
C7duoVNjN254fMU4PpRw2Gye9fux4+qfmenJ9sv9fXjxT5eWjjqdsenpD+Pxl/v7YODl/v4P16+3
ZRDK0scgKOxkYBenJ9tcylHacdLISOM8XVoaCYcVOZwLt2693N932zOXco4fIYq2ZcH2KPr47PU+
nmDNzPz8PEFy+Xw+Dlqf4Km5/IRHLG5RFXgnkTEFELpax/a0c4r7BcSP4vZDj6DfhOJ+TgSOxv85
oGzSd1LgVjY/NTk5iX2YnrdNeUHAdoMLdgOV7QmQKzLP4gYD7ScWi7GPAYZ6fHxcREKWNohCBbQz
SMTg94dyuadLSwjSRycmkAcfwMBcXF39eX0dq5Sqkry3gA1SBAoXZmZeHe8TjE1PPzuuRREZpqqk
YVTAhZmZF6USHFvkr4lzfP3CzAynxBWvoKbor7OzKKk66/cjUS6yLY5FZ3v76dLSWb8/nMthK4iV
6tj0tFTDcsKnxy5tbf20tPTdlStoqifbXDZJ2nEKEJ/MziKgCSuvGEI7bl6CG+cfLyw8XVp6urRE
JsftyVAu9+TLL9k+okzuwszMxYFmMqsNWNUUiUSmpqbYBwiemtWzUlhsaSgAy+EGXa4mKWNurXG4
9OrLCDiKxWIiSL66C95BvwnF/VSwkpaXl1OpVL/3T2nS5JG+v3bt4ldf9RsAvWvUzGRQmzt8x3+4
fv3DeHxIteudvrtyRVGnq+k3QCd/wK1arfp8Pm0VNJ0SPd/ZOXP+/PtoFV7u73935QpyL91KpVup
9FW08xY73ras765cQbwI/qU75Jp+M3TCkBg4ltJzO0iTpsHox5s3X+7v9+Vlvzs0OjERyGafHede
+sKieLsd98/M/FKpIN+FRNxgdaia3hfSsNuaNGnSpOk10rDbmjRp0qTpdcPQL5TrkOWYPV/HVZF9
IdlyjaOca4DXvdObwb99K2RZ1vz8vBrimCrz3P61Wq16x0k+vbnEEmpRUO84GO6x+kW0P3BfMO1P
9kkvAhweS7/fQSEw8zeAD3/YbJ4Glvgp0TCsYhNI+k8ocpNiyCtA3c/1BeU6JKqtl9d3d3cHOzJG
MFva2g9Mtm03Gg3xHN8A5BEneRhN6n24Hcf5+uuvUUw88BcVgMnU/vsFHqyGjB5gBPsalNPGh3/v
6LNHj068TQLclP6rYperv1TSkKi2Xl5nYS36olMNEX4nhMNB74V262u4gbJ5esycdvvvC/W7Bk8V
H16TYRgAcRmAzsGLTyQSIgorp6BZVFuKnYEnBSRtBJKWZWWzWdM0OaBX9nW3MAUxMl7ESQ3Cj8Uh
OADe4ru3b9+mAyNwVdACjm8UCgW8S+i1aixxwxtiLXfmpWebOI5PsL0IhvDj4uIiJDw/Pw9n07Is
oFnhTB+9BaBgAH6IzEgxeHuCgXOdTaVSjuPg1Mza2pp4Oq9cLuMwDms2FN3HiKRSqVwuRyOFw4lA
qeRexMwhMC9CgMfEAz4M1zhEt7Gx0XMUkBIpFApoBDgzhhKXWDo5aWpx2MjUvuM4ANnlZtHa2hok
gKmbyWQikUir1crn8/goi/clvi59UgzH2aWxu7srTgB2EGnEgXbcaDQwwQjZntx/KUtij4AnSoPS
05Nl8eFZpD8AhMCTxa1QF7/6auTyZREgnT29gQalTrcIay/inL/qdJ7Mzv65XIahalsWasCera+j
PHckHP7j6qpYpAuXHJeUhHO5XyoV8XnCIT/r9wO8XYqr/92VKzj9/mE8znY/lMuNhMMiaPxhs/nk
yy/RiLRIrG1ZyE3hdOGrgwPUthnHx10pnhDh089wyoJFYeU+I6LaAtxVOvAimjf3uiJaB3ZTLpcD
zDU+kT8+zEnfZRU0CxjLtkbotVj5wLnNZrPFYlFEvpMi1lqWBcTaubk5FrHWOL4oQt0mCXZlZSWb
zZJGU0f3gO5qt9sYjna7DcUnMiPF4PUCBi6Klyzo4uIiZxWANQ8QY1JMXroP7CwWiX1yclLxIrqP
OQNF32q1Go0Gl9pih1uNYAyC15JKpUiwi4uLNM8VuMTqzBLNLmo/kUhI4dkNBgWaoONhnFZWVubm
5miApK9Ln5Q67BhQ7PFwEwCDmEwmMb25TTK4gxsbG1NTUwSDr2BJ7JF0DboRiw/PWgUoSgLSAKCs
Lx7vCZCu9po5WHsR5xxQVASU+3x7e+zGjbZltS0rnMt99ujRhVu3nszOSlHED5vNi1999dmjRwAI
4Z4HNtfo1aufPXrki8eBraLA1b8wM0MA9biwZHRi4ulf/oJesLDqQHP59MED9EIqZACdwV4C0+Wz
R49QM03IBRCIf2bms0ePcEfLy/391wyDAoVVpPHxcUXOR0Tz7jen0Wg0EolEMBjEwe5WqwX1of4u
EXxDQq+t1WqE5RuJRAgeXPwuh1jrOA78RAByQI/gYY9tGsfQ4nhGvTvHasBYLBYKhWBNa7WalBkp
Bm9PMHCFeKUElGBYC/LcPXYfAFZ4vtvt4q9uL6L76DX0+97eXigUUmS31CjxUoL+onmuwCVWtGDI
sJHd4Nkxbwm3GUifjUYDyDEYTcXr4pPqJSmdAPV6HX81TXNxcZG7YRfTgB6gEfHeo5PKfgBAHo4t
bozwApCuIA7W3hXR/dggvSiVXh0c4K9j09Pw+uHCS6GfCKle+jyYB2I5rjZR4+qPTU+/OjhAcNDZ
3gYK/YtSCb2ARw/5dCsV/61bZ/3+0YkJvzsqPssnuAJW2K/HqFwIkrqVStuycLvG6MTEOW5yeB8/
9cMimndf+36YZ2QA8C1oZI9Mco8BIpst5xD5ERFr8TvHBkCmPLbJMWOaZqPRUIhCCvALVF4oII4Z
BP4cBm9PMHA38brBHTuOQ0BdcB28dx+girZt7+3tkfpze5G6DFuYSCR64oupUeI9zg3DBZe438mP
uSHCs4uv4EkaAvxB+jo3WAqviD4hnQDq3Tt26OHVKVjqayX2SyPhsC8ef1EqjYTDuKgOWlIESPfY
oIj9LsU598/MIIP04ttvoWePOp2XpdJ3vXAACZFX+vzfccgZ/PaeuPq4Gu+M3/9yfz+Uy6GndC6S
umAYxh+OZeLlmrwz7hD9l7a2WpaFT/ji8T+urp7AyedgMEheMClNEc3bLekkJXgirVYLKmP4iQhv
i/OSpHGGiFhLiwRs0BLy2KbBYIA7jgN3WPwn9VumaUL9icyIGLw9wcD7FS+LZ06j7LH72IVCBp8u
XBJf5AIpQDEiuac+SD8kgjF1nEtODkaYG17KuvAkobmxU4t7HWkf7smePRInANDlFPvn7J9pinrv
0QnS2PT0z+vruOJpdGICO6giQPpr2tZzAOGGc37W7x+7cQOpf2CJIxT4WAZy7uaSi88jyDh8/JgM
W09cfaAcHj5+zML9Xtra4u4rBKuwaq+GQ7n3xeNoB5sNz9bX+6tKkqLaQsUgOqbydhHNW/G6dGZH
IhFkdbAwgAeutk/s5BajbNzridW4trYmVuK7IdYiG4u9Nfb2IS9tsjsuwNeNRCJoAepMkc6uVqsQ
LL47Pj4uMlOr1UQM3p5g4P2Kd3x8nAa3XC5jEL13H6kGANl6fBFlzdiBl/q5NNxeEIxZUyrtnXdc
Yre5RzZJCs/uNsMxxLSlJ30dERX3pJqkEwDjC0Hl8/nl5WV2vdD4YgsdmzFuLLlJUr0G+zAMN25g
7/TCrVuGO677Wb//l0rlqNN5ub/vHd9bgXOOLBZ7K2LbshCvPN/Z+e7KFTU4sfR5ME+I5ThtoMbV
R8z0cn8fCaizfr8vHn+2vo6NhKdLSwA89sXjz7e3D5tN6b25FEn0DK1w2gN75h/G42fOnx8Jh/uL
GAjVlvWtYrFYvV5HJB6LxeBaimje7OvJZLInMHUmkyH8WNRCqB06AoyVesoczm00GhW3PXoi1tK1
EN7bpFWHFlDvgbQVXfbkFuCbpglm6LsiM6ZpSjF4RTDwYcSLnhYKBYCf99t99JH0tfRFcesF+zFu
jioN98rKiohgLNWV3BXBrJy94xIrdHGxWOx2u6xgCZ7dbYZblkVDII4LvS59UkFSNHj8AYJCy5wQ
arUa/gl1ItKpou4ROyjLy8vc5WLeCc77850duv1UCpCOi7i/v3aNnve05eCOc44taHLMcesfae2P
FxbU0IFuzxPWOn4cm55GkZUCV39sevrw8WP63KWtrSfHoPEj4fClrS3g8tqZDH4cnZiQ7j/DoqAq
SZG7Y+HTffF4IJt9a1hJlmVNTU0Nc+DovSCuMtUjtVotac3o74ps297c3DyRDI8mNaG2+506HNq2
LGww6NF5K/R2sJKwlfp+HRPV9OZtqvq6J02/YXq+ve2/dUvL4fdlGFAwp9e8Jje/YX5+HlVJWhq/
N3pRKn135cpZv/+ChxJMTadEGnZbkyZNmjS9AxGDJk2aNGl6pw3Dy/39o+HKYPulvgBmm5nMwMC8
7xHo7m+VupVKzzo/6VuGEhb4tLl9A58e7BOQDPiUFqIMw893V65wzbLFl9znPPKActI3OYh9aYxh
JDnMJBFXhLo10tJvSKf98i//8j8/+eSvjx//TZOmUyBMsF/+5V+8v/I4nf7p9u33hds3Sa07dx79
h/9wSo03/umf/t///J+ln/s/29uDaYn/7/nzxj/90//Z3tYLYZgZzmrp//nJJ29Anmf+eqJOhyZN
w9PAWMFaMsPQUafDISsM/znAjuqBG3Ic37yWPoOY64fr1xFS/XjzJk7BPd/Zwf1K+PHl/j4OyDUz
Gfz+482biL+e7+x8f+0ansTxOZw6QVPfX7sGjFn8GQEUoiEcBqFPoDUcx/juyhWwxAaGL/f30eZ3
V648mZ096nTcWOJSSQiEwQOe56QgdoGTBv25mclwbCNMbmYy1F/pSqA4nRqRMv9sfR1HIikoZgFS
frh+nWJkOkUpMu/2ozTV5tYvSPKH69ebmQyacussO2QU5D6ZncWPxD97hxSbX+pWKpDA99euPd/Z
aWYyh80m/kDBtVTmP1y//uPNm8QJF5v3NUwit/RpUZLcPKRIn/uRxhc/AsAATWEG0iekHWEbhGSw
KtEsmwAR5Y8FSJ0SJ4D4CubS06UldoLR5/DLT6+vIOJBMdnQwadLS23L4oRP7JHYpWyLgsVyJsHS
AqdXSGOIykRsbRhJKiYJmwLivsjOcFYmbCqJvtjMZAg2nHphGMaPN2/Sh446ne+vXWPPfg+8bP9h
GIBmTlf8+OLxzx498s/MiMi0f3cBOp0/3bvHYdhykK3g1X/rFjB17Uzmg6tX8WdWzXV2dn7d3//k
/v1PHzwAo8jtAoNw9OpVVkUedTpu0LscSwoz+NmjR5e2trqVCitE2C3ACoZzuWfr6/SvkAZdcoQH
nszOAgL30wcPDMMgrJXDZhM/ihAo3Url2fo6+nVxdbVbqRCeIsc8MB2hsw6bzW6lwgKkSL08Uf6K
HrmJJZzLSaF9wfxHCwvcj9TZzs4OQQ1/GI8/XVrCbOlWKn+6dw8iUvPPgRJf2toaCYcvzMyEczlW
cbvJ/OLqqji11K9ww6TgVipefAjz8EWp1LYsBZDyq07n0wcPLm1tPd/Zebq09OdyWZyB0o7QVz59
8GAkHP55fZ1DUSbmRfmDc5q9LMay2yto8+Lq6sXjU7jSz4kryE0DgKBYLq6uYhGx06ZbqWCyXThG
r5OyLUobLf8hHMZjP6+v//rwodhTqTJxa20wSXqRgPjFcC7HznCSCcsJDvcBQPDl/j5paToLLYKT
c4pigGXLbz6zRGfQpci0eADgVoRhawiQrWgBZcj4K/4MCFlOprgx45P79y9tbQEHES7Apa0tVlgK
6F2OJTcdhPMy6CArhRelEgHS4og8wbKzssafjzqdbqUS+OILXD51cXX1sNnECOE8vfTTmFhogavO
5pgfnZgYCYdhNl6USqMTE9IrOIik8lf0SCTqlxTaFw+A548XFg6bTfxInX1RKl2YmcF8vbi6etbv
f769/aJUGrtxY3RigthQbMFxoMSiWVXLnGBt2KHva5gU3ErFe9bvP2w2ny4tjRzrJgWQMsZ39OpV
+vPfBf46go3YkXAux0K5uSVkpPJnFyCHsax4pSehg9wKctMAbgsBwg9kszB41CBg4ES2RWmzy3nk
8mX4oPQKQQNJlYlba4NJ0osEFF/kZMJygvkwOjEBYyNdthw4ufhAv8tWZRhoWcLrRPqFDdJFDFso
dAQmiJKM1yFe3eBecePoi2+//fHmTURSoxMTHy8svOp08F22tADNctC74PaMt9sB3bAMX3U6R50O
RbXksHOv4Cu/vo52iwewyM+6o9pigj5dWkKE+NoACFxduHWLcOHV4YKb/BU9kiQTGRBjii6BJPP3
tXrcL3QWM4x+fLm/zyamz5w/j6/Tj9CJrhGDAEos0gAy7+sVNbeieD9eWAAyD/Kl3UqFgJQpMUIC
PyNMIfnklHGFBfjD9evP3O+lkcrfUGIsu70y8AqSaoCe3Wxb1tOlJQ5CTmRblLbIjJQxqTJxa20w
SXqRgOKLiqH/g4uLSUTg5HDpREUxwLJlc93ycwxApsV0/+T+fbXT6ovHEZJcXF399TjQ9kgfLyx8
+uDBpw8efDAxgRAskM3+6d49mFbkVUkQrJ+CMTuRfa0zfj8sM/3HJjE4+mBigt0LOnpddaqtAnrR
M7sCX+D5zs7L/X1uvKU4w6L8++oRuyDhs9N/cCjIt8UXuclAqMi02XjG7z/r95P/TnxKmYfo1Htx
A8i8r1ek3CqmN0DHkBxAzoqAlFnpDTktKTX8x+M8jJSk8le3PMArahpAAzxdWoKLShdbKjQgJ23v
jInKRNHaMGJRSGAA/s/6/V52m8empzs7O52dHYCTS12uvpYtqy7OwDRx60GBTCuaEBGy1aM04Q3h
KtQPjy9HpQAFv1BrbtC7wxuGD+Nx3MmHln+4fl2xWwsIXKS/4NPBdKs/8evDhyPh8EcLCx8vLPSc
GWjw5/V1McYUcYal8u+rR2y/OGhfzAq6hQqd5WbY2PT0850dDBmuLRybnkYCFD+yiwQh7VGnQ/yI
oMTdSmXk8mU20zKAzPt6xY1bN/FiZw+r64zfj5bVQMp9V600m4fN5tj0NJLLlJgSUZSl8u+pUDy+
4gW0GRvXbhqAvUGB0zCjV69eXF0FVLWicVHaHmXIAmWTMlG0NoAkvehA6Re5GS4OELYWjjodvC7V
0hw4uZhj7HfZvuYpfjAxMRIO/3jzJvtVpJ8QGv9SqYxNT//qYhtgD7Gkf7h+feTyZXVOmaWPFhZG
Ll9GRUrbsrBDFchmUW/QzGQC2SyxC+hdxDs/3rw5evUqoHeHJ188Tl1Ay+ouXNraAttARb/0zTec
fYJ5Yzf6A198cdbvR5HAH8LhUeVeCG3GiPMykM2iHTuTobkuyt+tR1x2zq1fGHRA+2JCP5mdRWfD
x/f9cvlADNkvlcrF1dXRiQnsW+JHUgr+40n1/bVrNE2BHvzy4UNkYIBU/GE8TsDIHmU+wDCxXRC5
VUzvS998Q3H3q04HKVqanPicCKTcF42Ew9jGhFiQQcZVAUgS0mqVyr+nH+3xFfqcOtek1gC4doaz
uH9cXaXCP8xztxUhStujDC/MzIjKRNHaAJL0ogOlXxRnODdAY9PTWCln/f4/rq6SlmZrFgA27mbA
Bli27AMaK+lUqJnJBLPZnpGEIgv8482bijueBiM4Nd4tN/ydD+Pxi8OpOU2aNJ0GuYGTD79sNVbS
ydNRp3P4+PEH3twNKXW2ty/MzJysVTCOqx30AGnS9Nug0wMnP6eFe+J01u+ncyEDGBXEj6dxRYm+
9kSTpt8GvSiVnszOjk5MnBI4uU4ladKkSZOm10inkjRp0qRJ0+uGgYXfIQLYCMqwRBgN+tE7oC4B
+7hRq9Wan5+vVquGYZTL5fn5+fn5+Var9VuStXjfPft7tVodrMuNRkP9om3bjuMMzLZlWVavatd+
n+xJ5XIZt8+7fahQKJyU/IeR7QnOjTc24efn58vl8pDThlbraawRGn1cfj4/P+9xuPF6oVBQTJ43
QxByv2+xavANkGKVyfcYCMRD+q84vHPU6fyvROKjhYXRIXZZpbS7u5tIJJLJ5G/JKliWFQwGI5GI
ODbVanWYe9gjkcjGxoZiqViW9d5dpJpIJBT3emb7KaxSy/8dIfUgvvkvvpVpQ2NEo7+3t9dqtVZW
Vryw8Y4P8XsWMQz85ukB6jqOEwwGf2OCbrfbbj7CqX73NxZ1nbj8Nb0700Y6RsFg0KNx0kN8gnTO
OD4cixPIl7a2fPE4ztoFvvjCMIxXnU4zk+lWKr54HIeevrty5eLqKhJQT5eWXnU6/pmZJ7OzOEc3
OjFx6ZtvRsLhw2bzyZdfItfkPaqYn59HMGjbdiqVot9rtVqhUFhZWSFHu1arzc3NVavVYrGImDeZ
TCYSiWq1WigUFhcXYV3m5+fxO2d7CoVCrVYj/zSZTMJLCoVCtm0nk0nTNLmWOVbxoVgshtAvEonA
kxVZsiyrdUyst4twAUyis4VCAeGwojU35+7u3btYQrZtm6aZyWTQoGEYa2tr2WzWNE0I1jCMaDSa
TqcRqkcikXa73Wq1QqFQOp0OBoONRqNQKLRaLcgwEAigWe51fF18UhxTSDUSiSSTSbERwzDy+TyG
IxKJZDKZarWKQGptbS0QCCCtEQqFUqlUKBSCb5hKpUSWpD0Ch6L8WYLkTdOE9JLJZCwWYydMLpfD
0JCUpLNIKqV+B9FxHGI+n8/bto0/YygjkQg4icVisVjMsizHcWjCFItFJDEgInjQ5XK5WCyCee6L
6AUYRseDwaB62hDbm5ub0WgU3XEc5+uvv06lUtFolDUw0gnGSSmVSuVyORqj8fHxarUai8XA8/z8
vGmaU1NTig+xSywYDHa73c3NTbRPApdKhsueeRk7t4UvCtlt6NkVIU5Ix3Esy2o0GlgLu7u77Xab
xA4dxSVUMAcwdW/fvr27u8v1VDG9par171d7/tEFu9gwjOfb239cXf3k/v3Dx49/Zv6VBdSVIjYD
vuLTBw8A3O3RMCC8TaVSrFXAOKEPJO5oNAqtNDU1tbGxkUqlisWix/RctVqt1+uLi4sbGxuxWKxc
LmM2UIgNUaLlbDZbLBbp01Ke0+l0o9Go1WpSlrLZbDAYjMVi3CRIJBKxWCwYDLJBPdsaZqpHNrAO
U6nUxsZGMBgsFouRSARiXFxcDIVC+XzeNM2NjY3FxUXbtjGJMRHn5uYWFxdbrVa1WoUShBwSiQSc
R8dxxNelTyqklMlkpDyQmZ+bm2s0Gru7u5zSTCaTGxsbpmnmmTOcUpakPXKTvyi9UCi0sbExNTUF
W8KajXa7jQlDbEhnEXjY2NiYm5ur1Wr4sd9BTKfTYP7u3bupVIo6Qr1bWVlJp9PQULdv36YJUy6X
y+VyNpsFS9C2jUajWCxiYrA6C0QMr6ys9DVtsCqpL/gDq6zZkeImmGVZaHNubg5timMEQ4vVMTU1
pf4Q97rjONFoFNMSE1UqGTdReBw7buGLQu75unRCVqtVDHq73S4WixAyTAtGUyrkVqu1uLi4srJS
rValPXWb3lLVesYwjLHpaZx74rCLQcAuBpiwFL3ZDbG5W6n4b9066/ePTkz4T6LYNhqN7u3tQdyt
VisWi9Xr9WAwCCMci8Wi0ahHw5BIJLAMSC60z0ZiMk0TLUciEfq0SDC8eKvdbg/MEgiOALXmnQ3Q
+Pg4JmU0GiVTB6rX661WC+1jCRFj0WjUNM1gMAgvpl6vO45DXUCD0telT7qNnYKHWq0WiURCoRAm
LucNRaNRCDmZTLZaLeqX9x55FL5pmlCIiUTCNE0SteM4tVoNJhxs2LZt27Z0Fvl8vlarVSgUoNES
icRggxgMBn0+H2SCjrBT1DRNGmjTNOnrtVotGo3CF6Y0PeYkyVDcsJmbm0P3o9Eot+GsELJhGJOT
kxAF7DcbY3EjKE4wiDoUCqFNdX2Exw+xQ4nuj4+PQ2NIJcO91dfYSRc+J2TF61LlTtopGAyitVqt
hgkAse/t7WFKSKcNpqJbT92mt1S1njN6AVX+gUG6xr1j4maDYRgcHMrL13GP1bjK3g2DZVmpVAo9
R1jE5i4Qg3tsrVwuQ8twigPZGMdxHMdBXosiCbcpyEWjA7MktuadDenrXFOI/b18FFoAfw2FQq1W
S/q69EkFY248IE3Us1OUKOu3Rx7J5/NxOgJcobViscg6y/i6OIump6dN00QqDCH/MIMo7YjiAdgG
LiJxHIfmJBQ096/oV6PREIdPIWQMfSQSqdVqwWAQMZ+XaYnNAGID/9rtdhUy8fgh6VAqJMNRX2Mn
Sl4UsvfXuc6y2gOaularwVC5WRRq0K2n4vSmD4mqtffJZ9phftXpnJWhGxJiM4vlBFQ/wH4ZMnjF
ASgSicByVqtV2ORQKMTaPcdxuHnvppSRcYMNTyQSeQFkCh5Zz/knkpSlgbs8MBtu84Yr8JDqcdK/
UIuQofR1TD7uyX55wO+KNBQ1iz+EQiF813uPPBKrm7rdLk0kfDedTnNrUjqLkNWl/Y9cLodY6kQG
0csoixV9xWKR9X44Fby5uYlplkql6vU6V2TpNmSsu1YsFn0+HwICL0xCgZJignhFVT78h3pKRtTI
XsZOmgOAn8oJebD1SwNECm1ychJJadu22T0e7z0tFApu01uqWntXJeHmQsA4A+j170HAMaCuFLHZ
MAxfPP58exsAwh6viOpJsVgMCWgs0fHx8VarhalcrVbJ3FH0xLp4XNoaK2FyclJabjw+Pm7bNv7J
tu21tTWPVclSlrAYpHoTG2WK1gZjg/M+HMcZHx83TTOXy+Gvm5ubbmcO8CR5kdDC0telT6qFI+UB
20XYYV5bW+MYQwIXe6SsUvDeI4X8OQsE8RYKBcdxJicnaaVFIpFSqQSrUygUlpeXHceRziLiPxQK
YVUPP4h9RdU4o2Acn4xpNBrj4+PUtXK5zMmh1Wph+5dVed6nDab37u5uz/QONw2wv23bNpLapmmq
x6jnh3q+LkqGe2aYsZMKebChx+u2be/u7qLXCJiw/dOzYtOtp27TW6paPWElkaLn4PoAqHvU6Vza
2noyO4ubrEfCYRQvXdrasjMZ/Dg6MQGz0basZ+vrn9y/7x1XnUs1FovFWCwG7Y9dMorxadMfO04K
OaIKgqodkApg3RCuZSq98BLWSFkaHx8vFoutVotzHzDeKJ3q2Zp3NtgIJhgMbm5uptPpbDZbKBQQ
2EKjuXkc2Ww2n8/Pz88j10k/cq9Ln1T7MlIeEomEbdvIV+BHNuoKhUK5XA7pps8//7xna27rFvJP
JpOImkX9YppmrVYrFovBYBCbmVQBmclkcrkcTgMFg8FMJoOMrTiLUATFsoT/DzOI3imRSHS7XdLd
yWQSuYtUKlUoFIrFouhrJ5NJ8IZ0P3ZcvU8b7ExUq1VO0XifBmSWaIyk2ZKeH6LXpfGEm2RY8jh2
0ogBS5UT8sDrd3l5mV4nde+27eylp9jt4Ka3QrUaf3vf6C9/+cv/+B//42+afh/09ddf//M///PJ
tnnnzp16vc79+M///M9ff/21FvgAtLu7+1/+y3/5LX3oHaRms/mf/tN/6na7g73uZXqzqvU9w0qq
Vqs+n8+L2dSkyS1f1G63B0hSa1KsSu95pPfiQ++skE/vIDqnWt8n2G2cWOm596JJkzqPMQwAiSZu
+yefzyMH9dv40LvpyiwvL5umeXr1C6Jq1bDbmjRp0qTpNdKw25o0adKk6Y0YBgJGPnEU2TeMTOud
1EC7wBLvKS438g4ZrQDxfpPYzu8miaPAymRIfHIao37beQMw0X1BjrMysSxrfn7+raNYa/qNGIZs
NquoHdTUr5XteUSAFJ/CwADU6LeHXDsMkUwajcbm5qb6/K2XMRqynVMyh31dX0EysW270WgAuElP
FW0YNL1b5B1PWINsDxOJnsgYvYNDMDBLdNRcT4/fG50zeqHRAlgY7gNOpuDkNICdI5EIi1VLgK4E
jCydbSyCMQEps7CxqMoizF5CogaUtHEMFWswGMgikG+32/UC+cuVOUmxlPsC2mUXJDCT2QekAM70
isgbB9mtGKyeIN6EtAwkSDcU6LW1NQXyM47Oc69LOyV9TJQtJ8ZWqwWAZTVUtXTWgXODAR6PRCLS
UWDTJjjvxgJNEzKEdEUAvRLalg5AYYAow4l2cAaefRIdJH5IAiJMdF/rTgE5vre3R7NiZWVFMfcU
MmHPA0oHEb+Mj4/jd3ShJyi3pnc3YvCCRus4TiwWQ3QJNHACdjZksL3qT+ZyOSAYAwGccIoINlaE
3AJmL0Bo6cfFxUU1kC8xz0H+KmCEDSUit+EBaJezqYZhrKyszM3NkVSlAM7EqsgbiyesHqyeIN70
FRxxBI4pB6RDY+GG/CxFEsbvGD7HcUqlkvQrUtlyYoQl6AlV7TbrOOBxt1EQkycENA1DlU6nwQ/Q
INgxKhaLk5OTmGlQ/TRGwFo3jgGrxSeNY0CClZWVZDIJvHFDBhOtXnfeIcfZWSEOkzqhBO9ncXGR
LRJ1WyC4E4LtgkdQbk3vomHwgkZrmiZmBtQf4c1i+qphe0Ub02g0gCsLUIFWq0VoPFL/BThWBEJL
PwKDoSeQrwj5q4ARNpSI3F6Adrme4kwK1V+7ATjjlZ68eRksljgQbxpNeIXlcjmRSEitmgL52Q1J
GEgssO7pdFr6Fals6/U6yQcwG4YH2HO3WccBj0tHQU1gAO55Op2mC0zoX6HTMdNCoZDbdoL0SZYf
iAVyEGGi1etuYMhxbpgGUBluC4S4pS70i5Wt6R1KJUkxWqlyA1hDHF6rONUUsL0cYZZwiLssfqfb
QjVeh7D2AuTL/p9Lm7rBCFNORoHIzTalQDOGvqAf8Qf8KAVw9sKbF+hgBcNEuBaK4KRSqRTHvBrY
WUQSBjwL5TqQC5J+RZQtUiXcBOsJVe026zhupaOgJuAtI1eJ/CGXEUXoYxxDzikwtMUnCXSTe1KK
LapYd4NBjkuHaQCtIV0gYhf6xcrW9A4ZBilGKztdetYzqGF7xVWHeB/LSW0SRL3p9qQUyFcau/SE
Ee6JyM02pUAzxjrB7X3G69jCIoAzcA178uYFOtgLRSIRcIU8fqlU8u48uiEJJ5NJ4NfncjlYAvEr
pmmKsg2FQmwxpUe8Yo+zTjoKXpxi9jJIunkJcwypc5ygVkwP6ZNk9oYcwYEhx8Vh6ndv2fsCMYbG
ytb01lJJXtBoFYQ9NxG2VzGhI5EIPA4CUkbs6UbVahXuCeB5pc+4Afm6PamAEe6JyM02pUAzRk/B
PG1LugE4q3kjPOGeg6UG8WYjQrAdiUR8Pp/0omZFr0UkYVTit1ot0zRpNMWvSGWLBiEfj3jF3med
dBSkRC4FK1j0hZUPfk8kEoCAJc+AxojakT5J/KDUQn32RT0K3iHHaVaIwzRA7bL3BWIMBMqt6Z2I
GLyg0SooGAxKYXsVr7AIxiiNUEcMpmniYSgCt7tlRCBfqYrsidUsxVKWcigF2uV6alkW9VTsPgE4
q3ljIbvVg6UG8Wb7SOmsSCQyNTXVV7QhIgnDA0WnsHXE4RXjK+Pj46JsqaylUCh4xCvua9ZJR0Ea
yxLQdCKRICEnEgnWHcFGF3I48Jrr9To7RtiIRjuRSER8MpVK5fN54CqjX30dMvA4jaWzAlVJ7DCZ
pmlZFqohPH5aukAUfHJY2f1+TtNboXcaKwnld1LofE2/VYJVO70bCzSJEcDu7q70VvoTIVRe6Q2G
9yyVpEWg6e0SYCrgdVLqSYvljVG9Xlfncoek3zNW9nucStIi0PR2KRaL1et1pFwoDaXF8sZo+FoG
N/o9Y2W/76RhtzVp0qRJ02ukU0maNGnSpEkbBk2aNGnSpA2DJk2aNGnShkGTJk2aNGnDoEmTJk2a
tGHQpEmTJk3aMGjSpEmTJm0YNGnSpEmTNgyaNGnSpEkbBk2aNGnSpA2DJk2aNGnShkGTJk2aNGnD
oEmTJk2atGHQpEmTJk3aMGjSpEmTpt8AvbWLehzH6Xa7Pp+Pbjyu1Wq4d5d9DDc8s49pchOmFpSm
t0jS9euFWq3WAG+9U+uOpfe0L3LDUC6XW60W3SderVZrtRqugW00GnQxOiibzUYiEcuyotGoeDeT
ZVmNRoP+uri4WC6Xg8Eghh93+ZbL5Wq1igdisRh+LJVKiUSCxFqtVnHRIygUCk1PT0uFXi6XcWU8
USwWS6VSxGGhUKDPgXCrcKFQIJbEZxYXF/f29ur1uvo6XFxMvbi4KOWN/QSEWSgU6Cb0YrGIPgaD
wVQqFYlE0NrGxoZhGLjnXcEzvl4ul1mBRyIRVowcVavVYrHoOI5hGIlEArd3cUPJ8iD+Vew7+8vK
yoppmiyTjuNYloWbO+kyZ5pgYgu44rtcLqslz44XmmUnrSjtarVaKBTYFiKRSDabZd9aW1uDIwJK
p9O4yB4PSBcC2p+fn8cEoD+wQ89Kg1sd1F/2RbWEsfpwF7r0DtR8Pl+r1dwmFbdeaESoQW6CiV1z
HAfX7RFNT09Ho1F2/arHwsvyofHCMNFjblORWyzBYHBxcVHUUVzvuL9yDFAXSICcJHO5XLvdZt/q
drvJZLKvG+u4Id7Y2GDnYSwWi0ajEB076GrVwc1k6bQR+85agd4RQyQSYUdifn4+EAioX8FsE+c0
TZHd3d25uTlYi7t374ZCIW6KNxqNYrGYyWTwu+M4xWKxUChINUUikUD33FZXKpVKpVIKBcctkr5o
b28P/+/33Wq1ure3Nzc3FwqFyuVyLpe7ffs29wyrZdwacRxnbm4OgYLjONCY0vsaW61WoVCAJoLk
fT4fyza7uujP4mJmlx/Js1arlctlMV4pFAqmaW5sbDQajVwuJ441FgN5Fd4FiLnu8eFYLIblqlCp
1FPHcZaXl7mbkLEQbNu2LGtlZQWztN/ZQs6WVEu6EclHuqBYKhaLrVYL5rlarYryxOqD6DAigUAg
Go167wJ85M8//xx/vXv3LvyMvsiyLFal3r17F38IBALZbBbrPZ1Oj4+Pb25ulsvlyclJjyIi8Sp8
R/x5+DtNY7EY13fWl/VOMH7iPCwWiz6fbwDVQc4QZ577jhjq9Tpn+qTUaDSCweCQsVKr1YpGo2gk
GAxGIpF6vc4t1Far5fP56EfTNEOhkHod9pydeB3/pwUzzOSwbbtYLLbb7WQyWa1W6/V6KpXihGPb
dqvVktqMWq0Wi8Vwv3EikajVarVazbumG4AwfNCP+APnVriFBV4aL5fLoqPkOE6tVsM0jUQisVis
Wq2q+1goFMhVHKCDoufI9aXVatm2HYlE6EnxQ7u7u7FYrFgsIihhH7Bt23Ecyn60Wi3ui6zudptd
Yv7hpMi27VgsBvMci8VojhFXtm1Ho1H0KBKJRKPRfD6fz+f7/VBPJaAei0wm0+12HcehRR2JREzT
hB6s1+vBYBDmKhaL2bbd0zCoQ1vyHcXJ5r0LXHeQ5AgEAmy/IpHICd5Y3mg0hlEdtm1juiJPIHUj
xFzLPwxDrVZrt9uRSKRYLNJUhlA4J7parfZ7rzdmJLtCTNNEYoGGU2wTITwiQeiXnp+G/rJtWzpl
kXIJhULFYjGbzWL2cNOCE5PC0tIt59FoFPJJJBLlcjmfz9u2jRQEHgNXtVqtL6esp1eIXkDVlstl
NrTHj26OCeIJmAQpVxSi9hVCWZaFUIAWD0YcCpRGJBgMskMvJTaVNKTnJXqOhUIhFArt7u5SHAyv
irNwjUYjm82applKpdgHHMcpl8uRSKRUKqXTaUpZsCpDGuSxQ2YYRrvdbrVajuOc+IZQMBisVqvR
aBQRQ6PR4NwpdB+2odFo1Go1TFfWnon6YgB3QT0WYK9arYZCIdM0aYFT+pHmjGmaUHx9uZ5iVsO2
7UKhgOkXCoVSqVRPDU5d4FJJPW3zidgG+JTRaHSAwBQCh3iLxWIqlaKEoSJHglTS3w0DcnlI7Gxu
blJugRtXaDfbtmkfwiNhj4FT+o1GY3NzMxQKQY+L6sk0zbm5uWq1ioEMBoPpdFotbjh3WBWijKAR
0um0ZVmWZaXTac5+IN3ExfhuWiwajYpf4bwSNJXJZKA32QCIGoGWQTyISeDFl6RMHbrM7fiZpgl1
EIlEuD4iHYmknNSNqtVqe3t7UG3INQUCAYh9fn5enBIQOOYfJobU4r4xUniprVYrn88j7QafgxKV
XKrNcRxYBdoPwGNoAbNobW2tUCh4N/aig4X/e7S7oq+qMKv5fH55eRl9hyli1VkkEpmammIjZrEX
LLfip+HUU/IHU26Akdrd3b19+za96zjO119/Lc00RiKRVCrVUyOLaUMKQDc2NjBec3Nz0IBQeqLN
9kjYdpZ6YKZpnsh2erFYnJqaopnJDkRP1YHUWTKZnJycvHv3rmVZ/SaUzpXL5Ww2i8X/+eef3717
VyqgRqORz+cplz0kQQWjP/Q5Co7YTWAyBgiL8ItoIaAl4baLjnC1Wg0EAnDxstmsZVluWfiTolqt
BquA3mWz2Vwux40NEpRw9oPBYCaTMU2TMwyKvITjOGrvW2pH2TXTc+r3zDLl8/lWq5VMJt0WFQwM
m3iR5kxPJJWk7hq2gj7//HPTNKH1isUiVAOtpd3d3ampKdKJGC+KGGAkYP8+//xzGAm3EFmRSqpW
q91uN5FI7O7uTk5OqjUIu4vjkdLpNKa6G7nlVTySaZqLi4tcQU6r1eIcEXUqCR49cnqsE4bfoVtp
HvZ0wNm9VvooJgMCUEW4owiLxS5w/hCygjSl2T+TqsQuYL8CL5fL7XabOEdgSlNLrToQflG/MFfd
0gOuqSR2BwyfFz1l2B+yHydCu7u74q4GEnY9sw0cG47j3L17FzU2Pp8Pu+3sM9w6IQVN0Q+bP6G5
Rel49USULubFxUV2GCKRiHS7Ur1E1RoBTjoFVdw/iZyLRTVihj0ajdq2TfMP7qSip5xgLcsaHx9n
e2SaJqrCUNUDL+REUkmhUIjSBT0DfFSpsYyR5MmcuI0FPcAanmAwCKOCX2ikpEPGBtlIaCB7Y9t2
Pp9HdOI9MYudc+8b1x6tS18NGi4FOeTvk6xQWyg2DnVGBXKYKplMBsZjfHy8UCjUarXx8fFqtTo9
PT0Y8+yET6VShUIBehBh3wB+BkkSs6VWqyFcBtvYZutp7MUIjCtzgI+inhgK1QHLzfJMDhD7O3Ik
FN9zqaBzUs0YjUbpOfjg2AHvKwneM7jmfFJE8Ujs2rbttvEiHf5IJALvjGpPRQXUarVKpRKbrIzF
Yslk0jTNZDIpde7cagxY+SrKVd1WBfuAumxAUU7nFhZgc1VqANjilkQiQfOeXT9uovASYeC7iUSC
nWTJZNKyLNhat9iCC5M9xgduik8tdm6qY+aQGFEPw8asSHyzg4t1S7M3FAqx/RKnGZUFw8tLpVLo
I4JXpIDVOVI2NUeDBWun8GdpGrCbYZyBkf7iZf1i95j9hU0uedwQmpubs217c3OTUy9YktgSR72m
lwoIt6JEEgIbIHrcq+B2s7lf2u026nch6kgkUqvVTNPsyzBQCEvJhmq12tML91JxhNpOmgamabIB
cY9UEuZBo9FgZYpCBcix38DTYzJLWghBFtK2be8ZWG681RUIqOSjlDG7LMWq5yGDbuliULtmPZ07
Thdgi0kRBPRL4mLwmM3I5XJTU1O2bZfLZS5oUCzIno2fVGUh6fRGo8GqIUx1GpRCodDtdmmSOI6T
y+VYPwN+Ertuy+UyCljxSj6fZztF0wwuCNdZL4uFXFeUPJCZcSMEJclkksSOohQufe9WGUyOpJq4
owxsel2M3ljDH4vFkGDk1Bw7JeC19Fvn0lMXiW6Wl54qNnjEYk7FHiHquXsaJ+n+5QBxIaZuLBaj
L2LXE7NU3AVkhyCVSr21k89IRHCxEpeAFt2E38apwhMk1HRxzkXPgyYnS3BMQqFQIpHAcTZp5e7A
jZ/qbpA09Ol2u+/UAXJEIbZtZ7PZYrG4ubmp2NfxrjS5iOFE1q9o/KQqkn2R087v2tF9MWKgv7bb
7enpaU5ruXn6KBR+F3rkxeiegztWLBbZDkej0Z45uCEpEAiIQQPVq2FyiMHpMLvfqVSqXC6jYINN
JXE+hWhL+93945a06HGwa1K6wcXumIlxPVsdhPJEUbaDnWpReEnSTTzj+BA7JaYQH5TL5bW1tX4r
PaQ6GruaJzXrEolEt9u1LIsSQdxUR9UWuxa4SUIHmNlUEpsOTqfTpVKJFWBPH79nbF2v12OxGPhE
VRUOsrFVPaxiwuYTTZtQKDQ1NcWJsa+zhP2u355O8SlpFdG8cQk3cTXRxuoAEUMgECiVSh6F0Gg0
+i3p7OkzKdYp9mx2d3fpGWyaeozD/s3f/vY37Xdr0qRJ0wkSi30yGKTC2yVtGDRp0qRJ02ukYbc1
adKkSdNwhmEAwCw1tY7pRFrjjs73dZL+fSQgW7x3bDuOc+ITSZN3elEqHTab7wgzR53Oqbb/cn//
5f7+722Ijzqdw2aT+0/xGDcK54xe+KssuVWIS9Fce9bgo9qaPeHitjfidjjLeH0jF8UbtLXF/VVk
1Xi99hkFXnTAFZy4iULE+kYdDouowW4N0R6Xm1jY36lIma1W5gApsQ+PU2PoY19IxXRGDwd/SJhu
ONXgXw0LKlbHu2GzQ3SiVFHcicpr2haWDgFXH0LQTIlEgusvxwMnf+omDj1hJrghsHIHGyETjj11
NT1HT2ZnX5RKhmGMhMN/XF31xeOHzeYP169/9ugRHmhb1rP1dfz544WFQDZrGMYP16/j4adLSyOX
LweOCw2+u3Llk/v3R8Jh+sNRp/PjzZvsFz9eWBibnn62vh744osLMzMK3qgR/JU+ahjGYbP55Msv
oW1HJyYuffPNSDj8fGfnRakUzuUMw2hmMt1KhZryxePhXK5bqfy0tPTJ/fvch368ebMnM4ZhdCuV
ZibD/hLO5XzxeDOTGZuexuvNTObw8WN64MKtW4FstrO9bRjG6Orq06Wl5zs7nDQC2SwrRk7+UlFw
xDY7Eg5/cv8+nm/fuUPNPt/Z+Xl9HcpXOo49GWPFSwKRypOkKv6I0cefD5vN9p07vzDD9GE8Hvji
C3Szd7kqB7/e7XbZk9kDb6rgJBGLVwMQYOB/cQ9z0N8KDom9QCDAqhJ2L4hsDFe6g3OYKysrrVYL
h+YUy5s74iC1W8Qz9CldITBYjQodKUJ/6/U6YEVYefaFVExAOsQqezCbNdIiGt1gwRyVcKAj9DkA
+huGAUSWubk5tvxf0SY7KwZAPEbJP90v4obr7uaIDEnP1tcPHz/+9MGDs37/850dTuth5bctC+qv
W6k8mZ0dCYfHeh0DZunVwYFhGOHj8qFmOn10cDA85z8tLZ3x+6E9m5nMky+//NO9e5zKpj+3LYtV
1hy1LevVwUH7zp0P43E3zUvWhdXX3125MnL5MvfM4ePHl7755qzfbxhG+84d7rsXV1cvrq5KVf8w
hGYRh3H6nVTw06Wli6urF2ZmMI6jExMwsafKmNrcPt/ePjo4+NO9exDXUafz9C9/eb69/fHCgsGe
fHYDzTBNE9jrtm2Tx8pi5Eo148meSxJ9PdZNA4ftdhsoNEDlC4VC7GETL+Wb8M0B8T01NcXaPy8s
icRFDDg6pNCw3CjgdVJD1WqVdVd9Ph+QKTEogyEVnziJBpIiNgwK7AHCRNM00TsYYNu2u90uxpSC
ziGnEE6luhl4wBeDh0wms7y8fFLQmB5THP5bt7AsL8zMvCiVLszMjF69+sP16/TA2I0b0CC+eHzs
xo0ns7PG7Gy/H1IrXDfeDMN4+fCh9N1upUKO6h9XV3+4fv27K1fApPjwL5WKaMwOm82XDx9Cjf7p
3r0XpVIznb5w6xanMRXRw0g4LOXtrN+v7i98ZAQ0ZIyhDVmrM9iAjk5MSBN3FNP44nH/zMyLUkns
Zk/GupUKx5i6p686HS595H0mnKNI3A1/FasUAT7BTFarVe4EE3lSbCpJ8WGceufAUnA6dLD1j5O3
gPDN5XI474cAApEN3F70S4QTAAwyKQWgiqIk38v+Bw7Hi7+zWQWKWtyUnXjBGYv5XK1WCYYFzAOY
lyQwDFKxNNHHpZK8vMU51KKdQPE75Izz7ad6YgYQ08CXJhNFgJpAmyehAd5g+I+K1fTSUyB/CIc7
29tjN24gYuhWKmz6BVmatmWNTU8jYnjx7beXtrbGpqfJciDsoFyTGw2wndC2LF88/mx93RePw3SR
tvrs0SNfPP7T0hLCgp+WlkYnJv507x5yHaKu/HV//9LWlhgtHXU6pC4D2ezY9PSLUunZ+vrF1VWp
en3N293ZuXDr1gA7FsifjE5MPFtfD+VycM+fLi1xj4mpJC9C6+zshJhQqS/ywhgyclwqydUbuHz5
+fb28+1tt1TShVu32nfusBmnD+Nxkqqnk8/lcrnb7bKZZaR9pOdrPGYVsALZK5AIjNA0TekRGBZB
kDubats2C99Wq9WAO+3z+T7//HOfz0eWA4DV+XyeQ24YkiAc5HbEeyzYqGWYnAxhd+PkFxsxiMm3
vpCKWQM5Pz8P0y7F2aYH+oVdQ9850B4AIOMroVAIGIi4bk96809PY8Ye9ysUCgDAQG6QpMca4CFD
IlEI3o9DXlxdfTI7+/21a3DlkDJCPoEUQSCbZZ1H0fWmhLVUf505fx4ZpH841OfP99y0fDI7i3RQ
27LsTAZbCJTTR5Tw5Msv8TnsMbi19nRpKZDNkmkhtX72/Pmz58//+vDh04cPOVvY2d4eWVjgXuEc
8JcPH1786iupNnzy5ZfsHgMXZ/y0tDR69eqlra1mJsN2bXhqW9YHExNk0jCI8PexqfM8HkcqqbOz
w1nKk2XsqNN5dXDwx9VVhZeA6OSDq1fZdNwZvx+/fxiP904lQSMjJIejR+E5q5o5IDY3TwoLCReV
uHVMikZH+pRNJZfLZfhikUgEIPsEw0IA5Wit0WjQVRM4AVir1djLKxYXF3GDEPrYbrdt20YyR1RP
nDdNokMUxSoLboNUbYrYURAT2YFAgBQfbdSTausXqVghfNp8Vj/QbyrJOL6ohy6oEfM8gAiG2KPR
aL95JISGkDmuDwHOdigUymQyBMHPipQgxmBr1Y4OOu5Wj+AFc5f78dLWliF4069xmM0GhjjEftbv
/+T+fWgKVjV8GI//wUXvtC2LNgkC2ezh48fP1tc5RTYSDnObClJqZjLs3jir/V/74p07Y9PTrIZS
WAXk6CkzzlE4lxM7Sy0/39kZuXwZfQnncs1MhlLqHPWbSnq5v/9sfZ2VCTafSVwXV1fbd+4gAvh4
YYHLI3lkzGMqqbOzwwUK/Kz75ptfX7fH4gCdM3rhr5Jfz56Ap+sN3PwmQwlQBVAdKYKjNJvE3bwh
Ng5oWdgMgIXh4kBSr9hyQJSAVBgpLMr24NJt1PPs7u7id2kqSVE9NZjzaLiAl7EfIued9pzZqzr7
RSo+DaJpwKG3sn0sFArcfXNsr1mI4CGJAyOTwhfGYrG1tTVcCpLL5Ya8l3GAEEq6H9Bz+9GtEMWN
nszOctuwrw4OPrh6VXozBqePLro4niJdmJmhrU6ULZ3x+y/JzN7oxASyZODq1cHBy/39V52OYRj+
W7cUeSTUaIVzOcUzolp8dXAwduPG383w61ZE7CPJH6GbohiJs1XqDBgrHImm9sAYtfB8Z6d9545i
DpAzcdTpdCsVlBuMMtGMYRijq6vPd3ZE8/DB1av4ilcQPRThABhHClgkbsOqN2bhx0lzVoOlp6DN
sR8uFqgAOYQA2aX1VMlkMpfLAUzJCwacm+fIedDcFQXqTAgHpcv9Arg6wvXFnay0A98vUjG8e6hv
aWwkgrEMvx+QSqXIJxh4S4mIZU8aXkhBsGk4UBEAOXjB6PfIkvdyVazzzvY2FdqPTkyMTU+zXjZb
Jyr+4mWP4dLW1qvXi5GavXoqflRkm6uepF8Om81mOj02PS11xlkVfMbvhzL6R47IZf8WVuFFqfSn
e/fUOxD+mRku4UaeOxmtZ+vr7HbIhZmZj5TJK/XewJPZ2Y8WFtTltl4qjk6WsbZlPd/eHr16FclD
1OyyGSpRjIePH//68KEBwyDCMLE5hGQyyeqXVqvV7XZZT5+9E0bMRylSAbg+l7e9MtBaLm8jMkk7
ez6fj7spgYXh6wl5bZrmkNhzXm5QURsSURezOSVspYo5eny0L6Ri7soO+joFPdLW3K6fpUpc9hd2
1AD9xu4JsSk4fI6NJLDP1Gq13NBVRbxuabmqAgRbHfyJtLm5yV50ge4obnPymIJ4urT08cICZSFQ
8M4V54iVrORRevHopSXtZ8+fP+p0vr92DfWyPRsRXVQxswGeUcvvxSKKcQx0+otSqW1ZXLbKY1bt
5/X1X17fw+c2G7BhS71GcPPz+vrF1dUfrl/nNurZfX6qFWYN3kg4/OmDB4ONPiclN8YCX3zBsiEm
uy7MzHDT4KjTaVtW6PXQ6snsLJuh6lYqYsbpw+NZd65nuoO7aJPbFma9fi6Hrt5lhQ0QtaToavWl
71gz9j6ereX2e7mr6oPBYL1ep8vLsBHyxsor+82DcePC8inyrIBrHuCAwmmQW47rDbBHu76itvJI
VN1PdOb8+W6lwhYd9UtckYy0KknlID9+/LHgDn8wMQF7OTZELvTCrVvc62d6bbl7zNH9ePOmOgw6
DfKSXeStvt8/Eg5jOCDhlw8fvnz4kJ1Fh48fXxASd7Qf0zuV5F0p9xUxIOcjGg8669T3NBXuKDdO
/2YCrgyGnHHWvPWF9KuOGACnTLeiBgIB73mqt0vBYPCt3KVx4iDYXshjuSrC+Yurq53tbUoHjU5M
BLJZLofjFjF41Syv1+qQ9jzqdD50TxaJH+U8U7eIwTtXYhIMZ5W7lYr3vQ2xWbFMc+TyZbJhf1xd
bd+5g2IwNmPTs2WgR/TVR4WbL4p0YMbcXIHn29tPl5ZQvzt69Sp33g2CEqUHQZ06uiqHZjHM3Qaa
NGnSpOkNkIbd1qRJkyZNr5GG3dakSZMmTYMaBm5nqa+NptMjQHa/rX3mdxk+Gie2OHrrXP3ecNHf
ynJg/9qXhKVzRgOkv3lSAGW/GTongtkSsbUQqLFlIVvZv4IUiNYcSDKR26YcbqzFEVlCYOXax6EK
eiUQCCSTSXWJDiFRqzdCi8UinZUDFDNeFDdIpPDRbg8T/yKKOKFlKKpdpc0qqubZ6k9Qt9tNJpOs
wMWTE8Sk4ziWZdm2TUOAgymtVkt6PMXtalyuVq1UKoVCIWKY/atYl4zTJJZlKWDDWRlGIhEpAjw9
wx098Y7yLfKG+jHuYe/A42yD7Al2g8GbUoOci9OjUChQVQJEx6Kye2FPWkzBHUIker6zI6IMUa2q
FCV75PJlrpz/sNn8aWmJQKJ88fgfV1fZM2VSvFI3KFaP2NTcKQ03VG0WDfvCzAzLCYuLfvj4sfet
cu5Ag8gezrUQ4tNZv99/6xZ3SIKDW+eAx0XAc/SRYHpFgYg/nuPAbDli8dxfHRygTm7k8mUWiMML
orVYdW64X0eO9YDlAaALUfcBJC6dThNKB1aa+tzs3t4e/q+o5CmXy3t7e/hioVC4e/euooII7hiO
zvZlkMXCJLcjAsMQd/y4L+gkKIiNjY1yuQxcLPXz6rICukyi2+1S5Zg4WCI6k5tYCLeDM2x9kXeU
b6qZdruqYQBiO1utVvs6FidSoVAIhUJokEWg6pcl7sihOmJQw7qJBxo4FxjqxRePo3gfyM8/3rz5
53KZsKDF07k4DOh2oKxfCFI1ERRVt1L5hcGUPSU66nR+Xl9nzx+83N+3MxkgLbKXcxiGgT9z5bPe
Ac97RAyiCWJt4Fm/P5zPHz5+/Hxn56jT+UM4PDY9/cHEBHuQcshDYSLZtk2qNhaL4dTVkMWOtm0X
i8V2u51MJqvVar1edzvbXK/XY7EYgZguLy9znqnjOPV6fW9vr9VqZTIZ0zSxJiORyPj4+JBHeXuS
m2M+TMbJLecD85lIJHZ3d72koarVaqPRgN9t23Y+nyfjl8lkgETSarUAZifqoMGGFeBLCDGlwZ8b
CNgAKN9Irdi2HQgE3FDZ1WhRp0d0Bt4wjMnJyd3dXenIqtnDAHHr4vQOyrz49tuRcJgAIc76/Ze2
tn68efPFt99C75/1+0Vn/Kk7pKjhDYL01cHBaV8bp1D9+L/i+Mgrhjf2z25H/MQDffT7wMdBznnp
yZPZ2UA2e8bvf9XpAMGKAgjUHasRrU+DotFou93m4Juk363Vavl8HkfzSNOVy2XkENLpdL/rFnZl
fHycEBRwrLdarbbb7dM+VSCmkhQPl8tl9viVeLBcoVhZHG+fz4fEVM8TAPQJUSvl8/lIJBKNRunQ
O9q/e/duIBCAe8Ed41DnBhuNRrVaDYVCxWIxlUqxkIhuiSyPIOoKrzwSiRSLRbo5SmywJ/B4v3sG
4hBLYwtc50c3W3AYl8Owd+J7DN9ducKpby8ZC1atE4rGABEDrrEc8gwdl7/i8l2Ks98Id7ouKvus
3//RwkIzkyGeD5vNi6urZEXYu/PEtBsnByngeX+G4YzfTyb0qNM5w1izl/v7gP/9u5EvlX6pVD6M
x8+cPx/O58+cP98XorUXfCGsPcJMrdVqHCQcIYwCjI8WBtRcKBRitQkHpkY5FjcOAUKHmw8KhYLP
5yPEVixUQgXnsrH4cRi94wXR2nvEMDc3J1oCVqFgZzIYDCI4kCpWVqH03MYECi9ZCFYxcQfdu90u
wUvQhZqUrmE3TtxSSbhaNZlMTk5O3r1717KsfiPXvlC+MbEhB6Q3ud2a04gY1BcXcpRKpfL5PMRl
27bbElOw12q13G4tFMOIYfI2lLseu3Hj5/X1J7OzF7/6ilJJh80mMO9gAw6bTRFL1e0rXpDmcCFS
Z2eHxQNHktwLZB5H/cLf4uvPd3bY/drvrlwhW4IjhzipDrvIHkLk7s6jWzFEg/rT0lIgm30yO9t1
iSfEzQ+WjXPsDlKbmTRty8JddB/G453t7WYm84dw+K/NJoYTqSQI0faAaC2dVQS/LK7YVCqVy+Xg
tGazWfZ1YDX3XPPD5OXpftBQKITb67x/HXckDPZptUmgfZqeW+jValXNJNDrSqUSDk5L7zEFjjck
2e12Q6GQwjCwxQWs6Zqfn0cEGQwGQ6HQ5uZmKBSCDCneMk2zX4khxKFoAGDd7FU8XlJJRj8o39id
wgV/dJeDaBj6Alil8IhqK0jFYxdd8a4Yl+NeKYxRKpWCSFkoMzV77MWr0hklQhKoEUNJ17DPB774
gnOQ/3Tv3k9LS3Tcd2x6WjQD3UrlzOu/nD1/nvO42Xss2NCE/frF1dWX+/tty/pzuQwVRwl6N5NA
GIW4KoMa/OT+/V8qFXVSC/rztXSfZeH3H65fx7VubHjBXljNnlQH4iHOJIt351F6jW4PPep07Exm
9OpV1mj1BBLnopxz7Oiin1xSD9jr6NIHV69+GI8jQ0d2zAuitdvyZi8H5ea9YtWlUilc/iWqTjEO
GAAlP5lMcjqClDKMFjIYrPlBsAKeT6MqVOwFqzi4XnB2sVarsYVA0MWoOJqbmwsGg1NTU/l8HlqP
dSRR0FIul93yEqJ8oETK5bIo1XQ6DThYWF8YHlymRBk/sXdSz9c0TbZ9FqybAwdU48l7R/nmQkwx
4hRhBNX5Hw5JHjivipyhF6rX68jRsfnDQCCA7ZOe7C0uLkpdCs66uGlhzmZcXF0Vq1rE+kvcUOTW
zpnz5y/MzEBdvvj22w8mJnCNhHjbsxdAIWzkIjr5aGHhx5s3z/r9Cn+fxSj84fp1TtH3tItixomQ
AS99882PN2+GX7d2BIILuGzaMoGZBNwTd3ceFVYRbwBh/GBiYuAkktc9Bgxn27LAGYdha3hDtHab
i+oHlpeXs9ks1BxXVyeidsOLFD/N4a16KVeForcsa2VlhTxf9i32thny/jjFzeV8OEvD5Y4hw2Fk
xa3kUChkWRb2xpFxZtd2q9Vqt9sUisGiI1PPaq5arYbU1kndvkk+KSmpbrcLIyHN+Bm9irWAQ066
zDRNpDRPaYPHzcAYAoyg240UfVFf5arIgnKeFvlPHtkTQ21stqu1sFveZvjb7dnNZ2ylqnUxW2Aq
+sKd7W3cIYqWL33zzZMvv/T3o9xF8liuetTpdLa3L21tIS4BRlbLsoKMWTrr95/1+4G8TW73k+1t
FsCcvTsPewzcV9p37vhnZtRIf2zogxtVRStyTgwxWMmSITpz/jw78IBcZ5OhiukreivcX6WaGnVy
8HbZ++Noxp8qqiVUP7ITlLdlmRQrvmlPT1qby/ZamjtmNSDdUy2ma7w7ku12G4l+LriRxkmisjNN
06M3LT2kwpo9Nu/x+eefs2LkXhS3oBR5dmxuxWIx4hOaFAZbDdWO+8bZzqpRvhWRxACzyzuSfF9U
q9WKxSJnG/rCkcR+vrjVcVLLirUoIsY192Tgiy/YWtVXBwcvSiX2F/GuAhGHnK1K4v5pdGJCUX4q
2hika+ivfW1IIGkmJuK4DYDDZhN3TlC/sM1w4dYtfEt9dx4u7FNzIjmfsLXFsvHjzZuBbPacd3vO
jmJfxV49MZmlaz6fz6fTaVTLoIB1b29vfHycLj0WI9yTKhWF1clms6hwRSDCncyKxWKTk5NsDvoE
M0gncheYcXyQFRIDez6f78QLat0MoYIl45TJC1S7oj7iXWBvMOKu6+iXWq1WLBbj3IhTgijuqcLo
8iKQWIk0MGC4F/J418XJErIyHWZrGgATHmHDhydCkD3nnV3u1icxzXdS5DjO119/nUwmkV7AjiVK
R+7evYsQGBkS0e2S3i43QPyOo3PZbHZ5eRnu2/j4OKWhgsGgGDGc0lJXeOJq7zIQCLBZe2LyLcJ0
S1niPFzp4VuuyJLNv+3u7pJMkDE71YGQsnd6mMHey1WN44pVMfnmfVFgYoujNsxZJTEnwV0v4Ubc
bZTvLPVVrtozsAjn88+3t0nZfhiPh/P5UzWBXICFXQ2NrqpJkyZNml4PBrQINGnSpEmTNgyaNGnS
pMmVzr0vjB51OixA09/N2vnzbyz79jvpC0oM3kHBSitYhsFHA0mPxb3j5DhOt9vlauROcGeFk4m0
WOBELmp1O+L6jkhY/P0EazdQdfkuXNguNwzc1tDF1VUcyfv14UPA6hGkH8GbiHVm4Vzu5f4+W89L
xV6AJwQcLmpmw7kcB9j7yf37L0qlw8ePP7h6lUPNJXoyO8shBb46OBi7cQNfZGvLsPMDKN32nTss
Pi1LbAEycGvR5TN+P/HAYdj+Y364I730lKdhGJ2dHfG2VeP1Oo2e8LxuWMEicdIenZhAxRsHPoxq
9H88dvXqxwsLbu0/mZ1FvQTKCi/MzLAMc6V+OO4kVrWLv7h16qjTaQpnKV4dHPzp3r2RcFhEeMYc
YIdYPNkLyJBSqUQAJyJQK1sizKIIG8fYqG6o2qzK5ppVnE5g95lRUgwwV+B2EJY42DBNM5lMRiIR
AG7T2XWqDicgcbdCZw643jCM6enpUChEMqF3OTPQarWkG+BuWOhScHi3g5Bidfvi4uLe3l69Xhf3
wLmHcaG32N9yucyiCnIIWtJRo2ZZOBCudoPDdVfIORAIQKQ445lIJBqNBodcIr7Ozi4UZ2Po6ToA
N3RhViwcqDu1r0Yn+nu5KqsjuBt4fqlUPnv0CAcX2pYVyGahnjjoc7a2rFupvPj220/u30cRrlha
QIcGjzqd769d86LdREXMKjuqLXtRKkkB3AcjLzhfHPWUpyHDV2GVMmta6M8DcCJK2ziG6hWpW6n8
vL5+aWsLPAP+1w2J5enS0uHjx4BKhtXh7pRnS/2amQxXaMidm6U+KiqnpQXa1AiVZrPA9KIPaBgG
C3BimqbUK1TQYMcL+iJCm5dWzWIxo8qoVquJOPPlcrnRaEDbqlHLjOOSa9u2S6USJMPCgrHEnj5x
u1vF6AcLHeBUYFjksKfiZkeEVBvKF6VCq9VqdK0LVTMqPkEn2wuFQrfbdbuRwntw0O12MQMHvvgI
99OsrKwAtqAnrDrJEIVq/VbAn/OoHEfC4Q89VJiRLfHPzIyEwyPh8Nj09Mv9/TMueYlupdJXRRqg
XhVa8uX+/smWuB02mz/evPnpgwf46/fXrsFLPZHGm5nMpa0tLmkj1Y8ekbB69qWzsyM9IPPXZvPM
+fMUPZz1+z+4etUNzvevzab/1i2wfWFmpn3njhtAAgJBztp5QS8YjF69JSxlNXGQscPkYVqtVjQa
RTYjGo2WSqV6vc5qQ8CU0YH2QqGgUH9AqSqXy8A05PC3xXORHokge4vFolj82mg0gFqfSCQikUip
VLIsa3x8HDXow6S/cJ2iWN0LIH0qd8b5J8Jzc+sCblsJhUK3b98uFoubm5u4C4CTiUffAgLh4g+Y
KDo4ghPmjUZDeqKwWq1S2XEmkxGvAzjhVBJF5S/391uWBQUkQsK+3N9/8e23rE45fPz419dPoLDr
k045nD1/njJREsXx7bcv9/ehNbwAj7w6OKCE0sjly6KC7uzshDw712wBsgKDlz3N5/FkX095kgxf
HRyc9fvPnj9/4dYtNs0FoQHLxQ3ORVTHIm4XaxWefPnlRwsLUvCvsRs3AJUIVl91Os+3t1mWWPpD
ONzZ3sblIc93dg6bTbjzHD/dSuXpX/6CW0co1yTt40cLC4rRl27J4MejTofdDjlsNt1uJsGKunv3
brfbxckJpE3egGHgbh9CKsmLDRB1HI7vsKn/8fFxVjfReUZowJ7OKSKMTCYDzErEQ4R9S/Khu5W8
WMFqtYr7/tLpNBxt6giuRYlGo3Nzc/V6HW4vXmERWTjow56nKBqNRqlUwtmjWCzGxTTASw4Gg3Qv
HovnJg0ukZpDpg5xCewZGCYD1hPNk+UB52HZk7BAJaDWAEpWLBY9Ig4MT+KhHMJEOIcFDIBySqxz
uXgs4AszM6wiflEqHXU6z3d2aElDz4or/OOFBSTuRS+4W6kgI6G4bOj5zg53Mp702uHjx91KhU7G
ty3rA+ZQDNSQAjYEuW+2y6INw+E+XKwBq9DzFKJCni/39zvM7sKrgwM2rf90acl/69arTqdtWXQP
35PZWWkM1JfT3bastmWR/sX/WTWNI/sk6pHLly99841b7HVxdfXJ7CwQMUfC4YurqyPhMLft9HRp
6cW3317a2hqdmOBunsLkEfvo9jlxe4mG5smXXwJ1EvPkqNPh4JSJCItpbW3t888/9/l8/eaR3KhQ
KGAPwC3LNFjEQHsM7I9TU1OWZVmWhWs74WUP3BHLshzHQZpobm4OZw8Ba0g6mjSF4zibm5vktEq7
ACz0VCqFc6mE1sUaNmx7dLvddrvdbrdbrVYgEACuPvaikR3idmIUKhibLrAKYEDMCxmv440rUPdB
BA5GSjwQCHBnJxEYGe6Y5OxQsiqYGmERzCzLAggNxle0hbFYjMxSLpfDltIw1z6qhXDOMIyWZX28
sNC2rMNmU/TB4bHC3wSyq3GMH/vxwkL7zh14jqyefba+/o/bHQ4OfOHwkczjA2J4z+oXTl+4nYx/
ub//bH2djWmw+dyXsDgbRtvsBAuMP6tPNirkiRSNui/dSmXsxg0YJ188PnbjBvJjBJhuuJToUKKG
5Q3bPCOXLysyYOyuDLH0cn8f+0ZSlX1pa8twgW98ub//482bF2Zm6IJGmkJkioC5T338YGJCkQP0
uL/SvnPnwszML5UKC6dMeQbaeWbvFj0RcED1xgNpE7e91r4IugNpE0oZ+Xy+WCyGMAjKgq7rUSdn
cA8SrqUjaTiOw16rzuUrWAeTAzMGiiVJA5Dm9XqdfHPHccTIg/2l32P5tm1vbm7GYjGSKpSduAvS
0xKwlMvlgAEsJToHXiwWcR9MPp9X+/jEFRvYmaZJ5mRzc9M0TTSLigYAAnGDVSgUlpeXjePN5557
ErCRKE8g12RxcbFnzJpKpc61LetVp4NkxZMvv3RDaBoJh/23bkHPdisVqODRiYlfKhUx6f9hPP5k
dvbCrVtHnc6LUuniV1+9+PZbMa3xIXP/j9owQGXg2lXkkUcuX/bPzJBRgdd5cXX1ZDcYSMNCqXmp
AlLLcyQchrcOtCw4wiOXL49NT1PLcLHHpqfhTcPvNgY9Zy9u23535QrGjiyHeK2u2ja7zRAEMaMT
E9Joht1aGAmH2T7+ur8fVM4EbIaLv1Ow+GR2FkicqFAauXyZjVyj0WgoFGLTI6g7ZJXgiVNf2ILe
yXEcGDnp7nQsFiuXy+hUqVSamppSNIVckyJNFAgEWNPCZdg5q6PAQucegAmBojRNkwDQoM7YfkFc
HDYwy78UjITAu6RghT2NOhS0ukgXW8EQL7aC1UMpve6Ces0JSpo6Q7Dl0ZVh9+RR2MZ2002er0UM
BBEeyGbhbXG+5OHjxx8vLAA29sN4/KjTaWYy4ePrqi9tbdmZDPcW/Fy4h+y9dP9IDnz5JYBnva+H
Z+vruA8PuxfdSuX5zZvhfB5JjCezs+o89TB7DN4J14Ao5Enfbd+5MzY9Dff88PHjH2/epIog3JeH
BBT2GKA9uUa8l6tyaS7jeM+fDAYuMOlWKt7vohIrRLkEl5g+Yh8Ym54+bDapjx8tLKjBc14dHDzf
2UE8x4YIgYMDIBUfPn6MvSVUEv+0tMQZs2AwCI1DVw+hUIQNxsWcD7fakTVinTh1AmEADCXKeLhl
J5Bs4fY/8/k8kHRjsZht2zBIXgD1TNMUr6IiPCvuNAPUnzpt0hPZHnfhUcYfe9TEqngVCsUu6p0S
tho1EolMTU1FIhEu+aNATfeix7vdLu4vwcYMbTbAx8fOiluDcE3YX0TYzZ5Q7Vx17JDUo1yV6m0o
ZmdrUcZu3LAzGWwOj01Pw0Fj/UGCk+U0oBqbUIEc6+YwYleZVvuFmRmU0gey2ZFwmO2F9PXvr13D
ZgaXInstLf664ywe12CT8ii44vYwRicm1PIEdba3cVc2K8bnOzukHPu9L9AjHTabqECF3mR18cv9
/efb2/1+VDyUoBBvzwd6EhtXGczVIFziyBePw+aJ1rRWq7mlZaXoe+zSlfpx9XqdciyFQkG0BF5q
N4m8GJJWq5XL5TjkwWAwSL/0BWYsPaYghVPF1mi5XB4gymH7hUxX+nXQ/nw+z+o78XSIIheEalS6
uAXufC6Xu337ds8yJ8dxlpeXUQMq3ZHiFLeUGQKoV5QJYXedG7WebnvPaSOdtOJBEM6h8XIhzbme
iYh+lfhp0Fm//4OJibZlXZiZQcTwolTy7uESZOBgeSQ3+vHmTfWFGAoF96JUGgmHR69eNQzj5cOH
ihKgkyLaf/bF47ii5MN4nDPe0gu2jHeGjoauRuWcaNY7HpJOG9X1Ncvn83FuvjEc5nw6nVa83mg0
dnd3kRoqFouWZcEfH+xb2CIul8uo0gGs/ZDlYShUHeDFer0eiUTezOnrIRHRvdMA1xz0bRjeHbq0
tdXZ2aFt7dGrV9kAomeGx/shDO9KCsDlA7wbyGbPoNBzfd0wjJHLl3F4uN92vJerNjOZV50OSQyH
n5/+5S/fX7uGLeKzMmR1xHYKg9rzItmTojPnz4+Ew+xFuPS790ZQHMJFDKd02QCnWL1DZ3uxCoas
flS8k9lja8FgULSO1Boql8js4V7bYrFIm6VSEjdX6LwVNk7p0DWuSBI1JufkKiIqvItyWwpBuHtq
3ci27fHx8TcwgT0ioou95mqdxTvMh5lLinJVDbutSZMmlTMu1bDvLMzRmxfFb5K0YdCkSZMmTa/H
4loEmjRp0qSJpbezx4DtexaW611GoH0zEuDAagwG+/dEII5/n8ThJ+P4wu9wvmnS1J9h4JBysfkg
FsxyVXdcDSwVSGGLCQ9Ho1EpjnGhUMDBwkAggLJoFoGWOxZEmyFsDTIHgEzEbdQoQHHdECLdTrHi
kAhbiSHFW240GuzJe5zkRFk3+2mpBMrlMhkGQMqwxy/Vh0I5WGPiluPHMAxwsri4ePfuXbZH6vEF
2pdt2yg0hEr1IgGW2HubRYRhGiyxBbwo/Rw7xNQmyzy3vQaYTA7xWBzcnvzggSGPMWvS9E5HDEOC
CQOGcHFxEWgqakesVCqFQiEsrXK5LILHsseC3MCH6RUsWulN8WqSHj5y02j9Elp2O3JZKBTUEsAz
UILY7IJeJkh37xSJRDY2Ntxg4kU9juKZSCTClWrk8/lIJDI3N1etVvP5vEIh4ousPPu9R55tASwN
UzjElpxXq1XvqGfcbOG6PAxGjSZNv51UkqJSGKi2cFej0agaocW27enjM8aTk5N0XpFDoOW0JJw+
znrhzGQymSwWi27VaScFlCY1G4Pd/NVut8lXZSUwjGE2js8N9fsup4WJWHts23a32wXPwCum4kuF
BKrVKgorFZeL9SzzQKeGyaRxd9GQA4GTboOVeGrS9Ps1DCiYJWccSXDpSnYch5auaZqE3CRtFvW8
BPIVDAbRICHQiqkknNfgHHAEE8gAhEKhzc1N8TT5YO6hG3FxiZfwQiwTVkiAy2hxWPaxWMxNhZF1
pDu8iD0ofTK9m5ub0hby+XytVjMMIxQKEdQwK0bWWgOmP5lMukkAqMXdbhexAvJ+qVSK7SaGhkVY
cxNgz1hWWtnNpi4jkQgFDXT0FLXzevNGkyZXw8CdqoBvyF6iBEiZaDRarVbZwFy6bpPJJK6Xkn4v
lUrl83k4uWyel3CdsOGhwAao1Wr5fD4ajdKtUpFI5PPPPy+VSoCAh67xCIqrBgwZMmKgPQYvEiCN
Cbaj0ShFElCpYtjkOA4QmDEoQGREZ1kzRiEFpModtoIEsEVRLpeBJTDwfNrc3MR5KJon2Wy2XC4D
P5LAwvb29sCSQoa1Wk2Uj0g0UVmXgp2ctm2zARBZ4iGtAhArxSyTJk2/BcMgndace44kz+Tk5Obm
5uTkJFYUYUMWi0XK2DiOEwgEFLmRUCgE3GCoSCxR9bYEl0qSwphgU5QFYPEOiusls0FS6gl01ZPc
JEBaTB3osEzu7u4SwD2UI64r4Z7f3d1NJpOsUXfLBKJwAAyQbo3FYqxLjsutoGrFgZCKmsOWwZ0n
gB6LRCJS29BoNDBwgx0posnJyRNYnvV6ffhYQZsETb+7VBLrphUKhVarBXUzNTV19+5dDqdlfHw8
l8vFYjHHcWq1WiqVcgsXSBPRda/sSnZ7nksliReOi8u1X1Bc0qEcypVxQohUXiQQCATI5Ig4+BAR
Z0E5HEpSvqzCglFPJBL1eh1JJ65Z3G+FNBRueQRCNQsK7fP5IMNqtdputxF5iCGUF5TjSCSSy+WQ
sMKwBoNBrl+4boWFRRvGDLdaLVy/rle7Jk19GIZWq1UqlVhtnkgkoEHgcJETiusmkAcggtOHKJ5L
JUtpfHyc07+2bXN6kE13cEVTrNaTYvwOAIortsyZpb5kSsy7WTupBFjzw+HgU15FVJRu5aFIJcHA
YPhSqdTdu3dF9zyRSBBQcygU4q7cAqXT6UKhgMyJAhHeC8rx8vJyMpnEY/g/V5cFsMy5uTmPVkG9
xwB7X6/X2U6JF7JzMmR3awzhlk3TNDMyyHFNmn5ThgHw6JTWB2A6vEvkPcRggqsi7Ut71mo1BQLt
YCj2isSFCIorBgHcX8UgQFrqLpJY5CMNbqQSYIsy4Ziz/9rtdqUpF2lZkRQfWJH66HkBiDgNBqaV
lRWFLTH6vGzL48RzHIdNKHHbTupsqlTCbLnq2tpav1ePadL0XqaSTpveGALtMNrkLUqg3W5PT09z
lkOf1B0mocRKW7wjZRjSOw2afpuGIZ1Ol0olNlimVNJpkEcE2neNxIzNYFczepFAIBAQL5DSbukJ
zrc3dneCJk3vI2l0VU2aNGnS9BppdFVNmjRp0qQNgyZNmjRp0oZBkyZNmjRpw6BJkyZNmrRh0KRJ
kyZN2jBo0qRJkyZtGDRp0qRJkzYMmjRp0qRJGwZNmjRp0qQNgyZNmjRpevv0/w8A+JHUmtyKrq8A
AAAASUVORK5CYII=

------8Ar4uL8unNJNiDbl_JgorJ3NKJ1rOAqY7U1DC95_YQLdtYAr=_54384_--


From nobody Mon Sep 11 06:30:48 2017
Return-Path: 
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 8E174133087 for ; Mon, 11 Sep 2017 06:30:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.018
X-Spam-Level: 
X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_RATIO_08=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 1ZHcipJM16nR for ; Mon, 11 Sep 2017 06:30:39 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0122.outbound.protection.outlook.com [104.47.42.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24CBC133084 for ; Mon, 11 Sep 2017 06:30:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tGyxne06+L5IAPC2vW1zmlx+aYzPo7qDUrA7Q2/6A2Q=; b=irhQS3U1WdeUx548daSTHLFOcUYQoQUxg20zsDjJONb+KhEbm7AOErzHlOEcPBTVjnS1sJD/0Sg0YPkAWvN51I4aW5Y2ENMwi6cRW51oNRWpLI2S2xdPjS6wOmzKQ5tcPO2W+fnzRS82/8ueKFbyQRhwe8Ro3wDZxdsRje+71AM=
Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB530.namprd05.prod.outlook.com (10.141.29.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Mon, 11 Sep 2017 13:30:38 +0000
Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0035.010; Mon, 11 Sep 2017 13:30:38 +0000
From: Kent Watsen 
To: "sk.srivastav@samsung.com" 
CC: "cpgs ." , "netmod@ietf.org" 
Thread-Topic: [netmod] [NETMOD] YANG Data Module
Thread-Index: AQHTKs2PhFXd7tYVc0GcXbfIQTIqO6Kva6YA
Date: Mon, 11 Sep 2017 13:30:38 +0000
Message-ID: 
References:  <20170911071336epcms5p6355cce397f545765e05637bbdf411b15@epcms5p6>
In-Reply-To: <20170911071336epcms5p6355cce397f545765e05637bbdf411b15@epcms5p6>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB530; 6:dmsD6mJoIUrovshOpqhed2ewxgpUdJImkXtVH+d6xBjhoEnxYlAfNK3MXCzTb8GeE8yvrcXJ8MVpzB9XWNfeoc3x8xvfRvmQ0ssFDRAiwn138T7LK5Sfw4IOoIPZP3K62ME5d/wLGGvsgWHxLyyMJJwi2lPOiJznFeFzEc2HclI+XpFfhUkQS/ZWOyS0Gva4M60xUeb+0ZXalegfzvDE8S+yEV0cNvaYWZlOmeXEkR+JXYsndcbmZSB2njAHKZGP9CFwC8f09+1KAC9P0vbu0hBSoecLgz/DKUdu4/2MIswOU22NCKnLyR+porQ/aeVKWYaoceshLUZzgSqJC3sFvw==; 5:I28Xn570Qvi3/RjIq4Nnomcu+yNR8FlVzoscqdHX32mlbCVho6OuQlg50p0qFKR0j/TTSnrnM6hJV4IgDpLTeDWh9avDR9vIuJE0EvVUxuzOesn7veDhdYnjTXxthF3WGsh2nMGQmFbRtRRIHY0WbQ==; 24:JmslpvLw+0GT5zxoUoH5eyAgw9RlGglY8WwMDXVeVXsl4nHfymbv4M6WYR9Ir60Czvin5rsV//WGAc4a2E2ATS17p4xTUcW75eLHdRBXnh8=; 7:ABl7mfzMI2D8m/n8Q/eN2BsfEfoA1jOtZMycJpJLDvVWdX+n5Cwl58jeV1Axeu43OJFOGLGcdeb3+8eB/lZjdP1kF4fYtNA60a5kohCKoOgfRR98RiQx4FsDMT5BhgONqkT8jjIinjybsMELraGRkUcB11EgB4HyyhtP+E1l8eOsyuA2K44R9vCYp9PC1NgeMmjLPLFoMVEAcLiLm0NK59zrdFO3rfnqcaZ6gwbDp/M=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: dc80f33d-3100-4ce3-9f48-08d4f9194a52
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(49563074)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR05MB530; 
x-ms-traffictypediagnostic: BLUPR05MB530:
x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155)(7411616537696); 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123562025)(20161123560025)(20161123558100)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB530; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB530; 
x-forefront-prvs: 04270EF89C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(199003)(377454003)(189002)(24454002)(2351001)(66066001)(9326002)(105586002)(53936002)(106356001)(4001350100001)(6246003)(110136004)(236005)(54556002)(6512007)(5640700003)(54906002)(54896002)(97736004)(99286003)(6306002)(25786009)(86362001)(4326008)(14454004)(3846002)(6116002)(478600001)(6916009)(102836003)(2950100002)(82746002)(33656002)(2501003)(50986999)(5660300001)(83506001)(3660700001)(99936001)(81156014)(6486002)(2900100001)(81166006)(77096006)(189998001)(2906002)(83716003)(7736002)(229853002)(36756003)(68736007)(8936002)(3280700002)(733005)(101416001)(6506006)(54356999)(76176999)(6436002)(8676002)(19607625011); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB530; H:BLUPR05MB275.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/related; boundary="_004_E49C5DFFCF0C4D2BBB1B6BE9D37190FFjunipernet_"; type="multipart/alternative"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2017 13:30:38.0947 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB530
Archived-At: 
Subject: Re: [netmod] [NETMOD] YANG Data Module
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Sep 2017 13:30:46 -0000

--_004_E49C5DFFCF0C4D2BBB1B6BE9D37190FFjunipernet_
Content-Type: multipart/alternative;
	boundary="_000_E49C5DFFCF0C4D2BBB1B6BE9D37190FFjunipernet_"

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

DQpIaSBTdWRoYW5zaHUsDQoNCldlbGNvbWUgdG8gTkVUTU9EISAgIEknbSBzdXJlIHRoZSBXRyBp
cyBsb29raW5nIGZvcndhcmQgdG8gbGVhcm5pbmcNCm1vcmUgYWJvdXQgeW91ciBpZGVhcy4NCg0K
SW4gb3JkZXIgdG8gYnJpbmcgYSBZQU5HIG1vZHVsZSB0byB0aGUgV0cncyBhdHRlbnRpb24sIHlv
dSBzaG91bGQgd3JpdGUNCmEgZHJhZnQgdGhhdCBkZXNjcmliZXMgeW91ciBZQU5HIG1vZHVsZSBh
bmQgc3VibWl0IGl0IHVzaW5nIHRoZSBkcmFmdC0NCnN1Ym1pc3Npb24gdG9vbCAoaHR0cHM6Ly9k
YXRhdHJhY2tlci5pZXRmLm9yZy9zdWJtaXQpLCBmb2xsb3dlZCB1cCBieSBhbg0KZW1haWwgdG8g
dGhlIG5ldG1vZCBtYWlsaW5nIGxpc3QgcG9pbnRpbmcgZm9sa3MgdG8gaXQgYW5kIGFza2luZyBm
b3IgY29tbWVudHMuDQoNClRoYW5rcywNCktlbnQNCg0KDQpPbiA5LzExLzE3LCAzOjEzIEFNLCAi
bmV0bW9kIG9uIGJlaGFsZiBvZiBTdWRoYW5zaHUgS3VtYXIgU3JpdmFzdGF2IiA8bmV0bW9kLWJv
dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYg
b2Ygc2suc3JpdmFzdGF2QHNhbXN1bmcuY29tPG1haWx0bzpzay5zcml2YXN0YXZAc2Ftc3VuZy5j
b20+PiB3cm90ZToNCg0KDQpEZWFyIEFkbWluLA0KDQoNCg0KTXlzZWxmIHN1ZGhhbnNodSBrdW1h
ciBzcml2YXN0YXYsIHdvcmtpbmcgb24gWUFORyBEYXRhIE1vZGVscyBpbiBTYW1zdW5nDQpvcmdh
bml6YXRpb24uDQoNCkkgd2FudCB0byBjb250cmlidXRlIHRvIFlBTkcgc3BhY2UgaW4gSUVURiBi
eSB1c2luZyBteSBvbiBqb2IgbGVhcm5pbmcuDQoNCkkgaGF2ZSBkZXZlbG9wZWQgYSBEUkFGVCBm
b3IgYSBuZXcgWUFORyBtb2R1bGUuIEkgd2FudCB0byBmbG9hdCB0aGF0IFlBTkcNCm1vZHVsZSB0
byBORVRNT0QgZ3JvdXAgZm9yIHRoZWlyIG9waW5pb24gYW5kIHJldmlld3MuDQoNClJlcXVlc3Qg
eW91IHRvIGtpbmRseSBsZXQgbWUga25vdyBob3cgY2FuIEkgZG8gaXQuDQoNCnJlZ2FyZHMNCg0K
U3VkaGFuc2h1DQoNCg0KDQoNCg0KW2NpZDppbWFnZTAwMS5wbmdAMDFEMzJBRTAuQTBFMDZERTBd
DQoNCltodHRwOi8vZXh0LnNhbXN1bmcubmV0L21haWwvZXh0L3YxL2V4dGVybmFsL3N0YXR1cy91
cGRhdGU/dXNlcmlkPXNrLnNyaXZhc3RhdiZkbz1iV0ZwYkVsRVBUSXdNVGN3T1RFeE1EY3hNek0y
WlhCamJYTTFjRFl6TlRWalkyVXpPVGRtTlRRMU56WTFaVEExTmpNM1ltSmtaalF4TVdJeE5TWnla
V05wY0dsbGJuUkJaR1J5WlhOelBXNWxkRzF2WkVCcFpYUm1MbTl5WndfX10NCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptdj0iaHR0cDovL21hY1ZtbFNj
aGVtYVVyaSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGhlYWQ+
DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh
cnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9
IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN
aWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0tW2lmICFtc29dPjxzdHls
ZSBpZD0ibXlzaW5nbGVfc3R5bGUiPnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30N
Cm9cOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgj
ZGVmYXVsdCNWTUwpO30NCi5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9z
dHlsZT48IVtlbmRpZl0tLT48c3R5bGUgaWQ9Imtub3hfc3R5bGUiPjwhLS0NCi8qIEZvbnQgRGVm
aW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6QXJpYWw7DQoJcGFub3NlLTE6
MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJp
YSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7
Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6bGluaywgc3Bh
bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ
dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r
Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0
LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1h
cmdpbi10b3A6My43NXB0Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTozLjc1
cHQ7DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6
QXJpYWw7fQ0KcC5zZWFyY2gtd29yZCwgbGkuc2VhcmNoLXdvcmQsIGRpdi5zZWFyY2gtd29yZA0K
CXttc28tc3R5bGUtbmFtZTpzZWFyY2gtd29yZDsNCgltYXJnaW4tdG9wOjMuNzVwdDsNCgltYXJn
aW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206My43NXB0Ow0KCW1hcmdpbi1sZWZ0OjBpbjsN
CgliYWNrZ3JvdW5kOiNGRkVFOTQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpB
cmlhbDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs
eTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFu
dDsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNv
cmF0aW9uOm5vbmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLm1zb0lu
cw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0
ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQN
Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn
ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu
IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K
LS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIg
bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5IaSBTdWRoYW5zaHUsPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGli
cmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5XZWxjb21lIHRvIE5FVE1PRCEmbmJzcDsm
bmJzcDsgSSdtIHN1cmUgdGhlIFdHIGlzIGxvb2tpbmcgZm9yd2FyZCB0byBsZWFybmluZzxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTpDYWxpYnJpIj5tb3JlIGFib3V0IHlvdXIgaWRlYXMuPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGli
cmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5JbiBvcmRlciB0byBicmluZyBhIFlBTkcg
bW9kdWxlIHRvIHRoZSBXRydzIGF0dGVudGlvbiwgeW91IHNob3VsZCB3cml0ZTxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls
eTpDYWxpYnJpIj5hIGRyYWZ0IHRoYXQgZGVzY3JpYmVzIHlvdXIgWUFORyBtb2R1bGUgYW5kIHN1
Ym1pdCBpdCB1c2luZyB0aGUgZHJhZnQtPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPnN1Ym1pc3Npb24g
dG9vbCAoaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9zdWJtaXQpLCBmb2xsb3dlZCB1cCBi
eSBhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5lbWFpbCB0byB0aGUgbmV0bW9kIG1haWxpbmcgbGlz
dCBwb2ludGluZyBmb2xrcyB0byBpdCBhbmQgYXNraW5nIGZvciBjb21tZW50cy48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPlRoYW5rcyw8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6Q2FsaWJyaSI+S2VudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5PbiA5LzExLzE3LCAzOjEzIEFNLCAmcXVvdDtuZXRtb2Qgb24gYmVo
YWxmIG9mIFN1ZGhhbnNodSBLdW1hciBTcml2YXN0YXYmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0
bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyI+bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IG9u
IGJlaGFsZiBvZg0KPGEgaHJlZj0ibWFpbHRvOnNrLnNyaXZhc3RhdkBzYW1zdW5nLmNvbSI+c2su
c3JpdmFzdGF2QHNhbXN1bmcuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8cD5EZWFyIEFkbWluLDxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8cD5NeXNlbGYgc3VkaGFuc2h1IGt1bWFyIHNyaXZhc3Rhdiwgd29ya2lu
ZyBvbiBZQU5HIERhdGEgTW9kZWxzIGluIFNhbXN1bmc8YnI+DQpvcmdhbml6YXRpb24uPGJyPg0K
PGJyPg0KSSB3YW50IHRvIGNvbnRyaWJ1dGUgdG8gWUFORyBzcGFjZSBpbiBJRVRGIGJ5IHVzaW5n
IG15IG9uIGpvYiBsZWFybmluZy48YnI+DQo8YnI+DQpJIGhhdmUgZGV2ZWxvcGVkIGEgRFJBRlQg
Zm9yIGEgbmV3IFlBTkcgbW9kdWxlLiBJIHdhbnQgdG8gZmxvYXQgdGhhdCBZQU5HPGJyPg0KbW9k
dWxlIHRvIE5FVE1PRCBncm91cCBmb3IgdGhlaXIgb3BpbmlvbiBhbmQgcmV2aWV3cy48YnI+DQo8
YnI+DQpSZXF1ZXN0IHlvdSB0byBraW5kbHkgbGV0IG1lIGtub3cgaG93IGNhbiBJIGRvIGl0Ljxi
cj4NCjxicj4NCnJlZ2FyZHM8bzpwPjwvbzpwPjwvcD4NCjxwPlN1ZGhhbnNodTxvOnA+PC9vOnA+
PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
Cjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAi
IGlkPSJjb25maWRlbnRpYWxzaWduaW1nIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFk
ZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cD48aW1nIGJvcmRlcj0iMCIgd2lkdGg9
IjUyMCIgaGVpZ2h0PSIyMDAiIGlkPSJfeDAwMDBfaTEwMjUiIHNyYz0iY2lkOmltYWdlMDAxLnBu
Z0AwMUQzMkFFMC5BMEUwNkRFMCI+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJv
ZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGltZyBib3JkZXI9IjAiIHdpZHRo
PSIzMiIgaGVpZ2h0PSIzMiIgaWQ9Il94MDAwMF9pMTAyNiIgc3JjPSJodHRwOi8vZXh0LnNhbXN1
bmcubmV0L21haWwvZXh0L3YxL2V4dGVybmFsL3N0YXR1cy91cGRhdGU/dXNlcmlkPXNrLnNyaXZh
c3RhdiZhbXA7ZG89YldGcGJFbEVQVEl3TVRjd09URXhNRGN4TXpNMlpYQmpiWE0xY0RZek5UVmpZ
MlV6T1RkbU5UUTFOelkxWlRBMU5qTTNZbUprWmpReE1XSXhOU1p5WldOcGNHbGxiblJCWkdSeVpY
TnpQVzVsZEcxdlpFQnBaWFJtTG05eVp3X18iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jv
ZHk+DQo8L2h0bWw+DQo=

--_000_E49C5DFFCF0C4D2BBB1B6BE9D37190FFjunipernet_--

--_004_E49C5DFFCF0C4D2BBB1B6BE9D37190FFjunipernet_
Content-Type: image/png; name="image001.png"
Content-Description: image001.png
Content-Disposition: inline; filename="image001.png"; size=33528;
	creation-date="Mon, 11 Sep 2017 13:30:37 GMT";
	modification-date="Mon, 11 Sep 2017 13:30:37 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAAggAAADICAIAAAAC6Y6pAAAACXBIWXMAAAsTAAALEwEAmpwYAAAK
T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU
kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX
Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB
eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt
AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3
AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX
Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+
5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk
5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd
0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA
4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA
BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph
CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5
h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+
Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM
WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ
AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io
UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp
r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ
D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb
U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY
/R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir
SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u
p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh
lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1
mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO
k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry
FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I
veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B
Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/
0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p
DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q
PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs
OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5
hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ
rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9
rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d
T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX
Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7
vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S
PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa
RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO
32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21
e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV
P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i
/suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8
IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq
YAAAOpgAABdvkl/FRgAAeCJJREFUeNrsvU1sG8fWJtxjWzdqBjINMoEvDNIXNw4VYCCLeD0bAsRg
TC0GsLjwhgt5QS7DLCJAwAgCZF2tFEUYQcBooAzg9pJcSMDLjRdkgG8hevES4CxeYyhrMSHjzMRs
GPHnkGPKE7Zz9cn3WzxX55arqotNUvJPUgdBYNPd1adOVZ2/OvXUv/nb3/5maNKkSZMmTcd0RotA
kyZNmjRpw6BJkyZNmrRh0KRJkyZN2jBo0qRJkyZtGDRp0qRJkzYMmjRp0qRJGwZNmjRp0qQNgyZN
mjRp0oZBkyZNmjRpw6BJkyZNmrRh0KRJkyZN2jBo0qRJk6Z3mM7+3//7f/8fgUZGRnZ2dp4+ffpv
/+2/fcMMNRqNYDDY1yu2bY+MjIyMjAz2RcuydnZ2/vVf//Xf//t/L3JSrVY3Nzf/3b/7dz6fj/2n
tbU17sc3KSJ8/b//9/++s7PDsf3bpnK5/N/+23/7j//xP76taek4ztOnT8+fP+/xxUKhcO/evVMd
owGWzFuhVqv1X//rf713796//uu/3rt3T7qm/vznP/fVF1r78/Pz58+fD4VCivUy/GodjEmPWuh/
/+//rdC3w4yyd7bpyXMbGxv4aX5+PplMJhIJ/LVarb75qWNZVjAYjEQiffXZsqzFxUXTNAf4om3b
jUYjnU5Ho1FOAVWr1cXFRelbkUiE5Pbm6e1+/XdINBkcx/n666+TyaRUAb1d3t59Me7t7bVarZWV
lcGWqnrtv+8rIpvNnqxiHJLerVRSu90ewA0Z5ouO4xiGIa7zIZvV9FsimgzdbhcT5h3k7b2gYDB4
Ulbhd7VIB1CMQ9I5tTe9trbWarVM08xkMpFIxHGcXC7XaDSgTNPptBiblMvlYrGIB1KpVCgUqlar
xWIRKwpBSbVaLRQKsVgMcUkkEslms5ZltY4pm80Wi8VyuYzJlEqlIpFIoVCo1Wrj4+O1Wg1NhUKh
QqFgGMba2lo2m63X69wrHG9sm4lEIhgMWpaF11OpVCwWY70wRFGpVAoJAfQarJKr4jhOoVCwbdsw
jGg0mk6nRRmqH1hbWzNN03GcVqsFkebzedu2SbwkT3w9k8nYto2vS0etZ4NSlkRpSx8TmTFNkx3x
Vqs1NTWFIeYGneOzWq2Wy2WsbZoqYB5yo1nXarXQBakJh3XH3MBfE4lEMpkUZ0ssFlteXp6bm0Mj
GETOgRW5ajQaNBkoO+Q4DiYkuDJNE+0bhpHP5/FFyAfmZHNzE09CFOANY2GaZjabrVar1WpVvdBE
4di2TbytrKyo1yY7oMSwZVmO46DB27dv7+7uqldQo9EoFArQCWiBY9VtHG3bxiTBmioUCouLi8Fg
kMTFjuwAa9+yLCxhcYq6eYRe5gzmrZRJqdLjFmkoFLJtO5lMsrNFqgcQEyQSibW1tUgk0m63af1C
4H0pRgXb4uvSJ8+oDUMqldrY2AgGg+h2oVBot9uLi4sbGxumaebzeXHeFIvFZDK5srIC0WMmTU1N
bWxspFKpYrHIJqk2NjbS6XSj0ajVatlsNhgMxmKxbDZbLpfL5XI2m93Y2IjFYrlcDmsVC3JjYyOR
SBSLRUxEwzCgJcvlcjqd3tjYCIVCuVxOHDxqE9IMBAKI4BYXF8kqYJbEYrFgMMjGpyyrrJTxT3Nz
c7VaDRJnJ18+n0ecu7i4SGtDdHzS6fTi4mKr1bp7924qlcKfq9Uq5IlOsUqqpyfl1qCUpUajIYpO
7JqUGfyIeRIKhWAJoIMw6JjKrNAgmWKxODk5ifZbrRaJrtVqibPOMIyVlRU8Kfa3Wq3W63VMS6gG
rEButmBNEie1Wi0ajbJWQcoVOxkwzVKpFDW4sbGxsrJCrJbL5VqtNjc3Nzc312g0dnd30Ww0GiU2
ICLHcWKxGLoJDeJloXHCYXmrVqu2bS8uLmLplUol0SsSGUabeAtGUVx0rHxyuRxYHR8fh4HM5XJg
dWVlBSrGjdVkMglWyWKVy+V6vT43N4d3xXXqce2TAfO+XjzOGcdxpEyKSk/6UTQVi8W86AFWznNz
c7RmB1CMbmxLX5c+qTIM0WgUEo9Go7ZtO45Tq9UwEWGXbNuGNInq9ToUq2mai4uLc3Nz9XodltAw
jFgsFo1GSWrQxUjuc7ESFi2+jnf39vbg6eCt8fFxKCB6BSscnlc6nRZHEcyjzVQqZZqm932UZDIp
ZdXn87VarUKhgBnP+cX1er3VauFdDK30i+Pj46FQKBgM+ny+UCiEP0PJYrDxXdZ0qUnRoJQlqejE
rkmZqdfroVAIf4VUIWrTNCGNSCQSjUYxfOxgraysgA1w2O12WebZWddoNGKxmGma9CGOEokElB2N
EZSvOFsikQgNQa1Wm5yc9MiVNCk8NzeHt6LRKL5Yq9UikQje3djYQFMkCnbSEm/oLK0Fx3EUC40T
jqhQEO4sLi6KPqmUYbSJD7ktOnY+w54ZhgE9CLWI4Ns0zVQq1Wq1YHrVrLLLPBQKkYgGW/vc9puX
9eJ9zkiZ9PhR/OhRD7BvmaaJNct107twvMtW+qQqlcRlA7FIisUia+64lKvjOGIAGwgE2DbpFUW2
EWuDczOhrdxeCYVCyWSyVqsVCgXkqeBQsJywO8w+n897vtiN1enpaRiYarUKBtjoG+1vbm66RZ2I
V9jGxQ/BE4RABuCWa1DKklR00q6JzCBXwA0QtBvlXrB4xHgUy4PSiYpZR5PKrawCCpHzVMTZEo1G
2fCFqzhQcCWdohjHRqNBnrXjOGK2QTpp2R+5BxQLTbFkEolEt9ullBQSej0ZZtt0W3QcD+xyhrRp
UNBUT1al6oLkNsDaH2y9eJwzUiY9fpQVCLfoBtA2fQnHu2ylT57zvh2Bb4sFPFyXuPAzFAqxfofj
OF5mDGwXbCwRUgpqLwCLAXk0ilSIE5a3brc7/D4Y8nSpVArJk1wux0YqaF8sw5D6HW4TDpo6EAis
rKwsLy8PybCCJVF0XNeQhOWYCYVCyC+zSg3ePfxTt2TX5uYmPKPFxUUxJ8nNOjj7oiNCE6PRaCA0
SSQSitbgLGNCitPYO1dY5+hmKpWizS1x/g9AXhaaW1ybTCaR3ikWi4hd1Az3XHTi5Gm325weabVa
7Oh4X1amaZJSZv3FAdZ+v+ulrzkjMtnXR90W3WDr16NwvMu2VquJT57pi6dIJFIqlTD1C4XC8vIy
JykEMphz+Xx+eXkZ6hi/VKtVhC1unwgEAmgwGo0iqY235ufnWe3DqWb0h30MbLCuDdpETpz2DxWc
BINBRRqB3enF9jUCMc6fHR8fN00TKXvHcTY3N/Gwd7JtOxgMYsGLuyYDkJQlqejErkmZGR8fJy+7
XC5j+PAjBh0lDJwawrdge/b29txSDTTrqtUqNt+kMXij0YC+m5ycFPWdGDTUarV6vS6OvhtXNBlo
soGZaDSKqJS4ikajjUYDziMJcIDF33OhiRO1UChQqQgGkZ2NbgxzklEvOkweGuv5+XkYbLje2FMM
BoP4uhfCWOArFB4NsPYHWC/e54yUyb4W6fB6YADF6F220ifP9cVfJpPJ5XJra2sYFRSlcOm2ZDKJ
KBgPoMSC4mKqSnJTW8VisdVqzc3NdbtdEh/yGNLYEAn0zc3NdDqdSCTolUQiwa18xNp4AJ4+5+1y
HSkWizjboRAIagaQM6HdMHaFZ7NZxQM9KZFI2LYNHwQVIKgvGsbjEFkKBoOtVosTXTAY5B6DD8Ix
Q+UchUKBGItEIig0oC1fLkiKxWK1Wg3BNbw27E65zTrLsjDrpH1PpVK5XG5+fh4pFHHrixtZKBQx
TeTGFU2GlZUVJKO63S7Nc+x8YPcS44UWILSehmqwhSZOVFQl4RWk+9lXoLlEht0WCC06bvJkMhma
FXgA1Qo0Oul02rtfnEgkaOLRyErZ6Ln2+10v3ueMlMm+FunwemAAxehdtij84578N3/7298MTZpO
iLhjku8m5fP5QCCgNvmaNP2eSWMlaRqKKKVAKcQ3eT5zAELZjPcSL02afod0TotA0zAUi8Xq9TqS
J8hgvDtwESJhax3llXrsNGlyI51K0qRJkyZNr5FOJWnSpEmTpoEMQ6PRmJ+fd6vRLpfLKEvw0sj8
/PzJQreiWa6+SPrj26LnOzvfXbki/offn+/s9NVa27J+uH7d7V8Pm80frl//7sqVp0tLp9Sdo07n
5f6+YRjNTOb0vnJSNICEQU+XlhRydqOTkgnYVo/1iXBFnxhYUOrvNl3QitbW1uYFsiwLdbeDaRjj
uOb4jZFaMYo0jPaDcN5Aj4w3vMeAM7SKc0+/VbowM3NhZsYwjG6l0sxkwrmcLx6HEh+gtUA2G3AH
6X1RKh02m58+eHDW7z8lq/C/EomPFhZGJybCJ3G0QtMbIMVIqafT6RGhQKJQknCnpbqPDmD2VJ1v
GJ66Xwz8YeDBs6c/TITi/kZTSd1u913emfzN0Eg4fEpWwTCMVwcHR52OFrKmd5DePDz1b4wo9Dkn
RVdWYyZLgVsNwwDYDmFCENIkGfPGMS0uLnII2DhxU61WAXmfzWapWSlcsOECKiv+yDUrQnNLIY7F
PrpBjrtJwzu9KJUQ5o9OTFz65puRcPjl/v7TpSWka8ampy9tbXGx//Pt7U/u3//h+nUYgJf7+2f9
/ktbWy/395+tryMt8Mn9+79UKj+vr0OPf7ywEMhmEbKMTky83N//eGHh2fq6Lx7vVioIa/y3btmZ
zFGn44vH4WO2LQsNGobhi8cvbW0h7fB0aelVp/NLpfKHcPji6irH8MWvvnp1cPDD9eu+ePzw8ePD
ZpO6xiZqXnz7LTp71u8P5XKd7e3nOzvoiC8ef76z075zB0HV6MTExdXVw8ePn/7lL58+eEByeFEq
/enePTZlx70yOjFBgc6T2Vn01E3OF7/6SjSoz3d2fl5fNwzjo4UFhH34hZWqdFilj3UrlZ+Wlg6b
TRjvM35/OJdTsP2PGaLs+A/Xr49cvvzr/v5Rp0MtNDOZV50OxPvBxMQfwuGRy5d/qVQoemhmMh/G
44ZhYDqpOaeZMDoxcdhsIs7o2UfDMEYuXx7Ag+SAysmTVagmFrd/fHycXfUsoClgsaGsOOR/cY0j
5RWJRPBjLBYjrHIOgR8YqyxjUo0B1HF818tlBGI8hKOjbjpH+lFRybdaLRHfe29vj1Dcz0jRlRVA
2W64r8Yx+Awdw6tWq+zZY+j6WCy2uLgoImCjEYLqZbvqhm8sBZWVAuRSs8Bp4JgX8YqlMNRSJGSF
NLzT4ePHn9y//8n9+4fN5vPt7aNO58mXX57x+z979OiT+/dfPnxIqlnybrN5cXX1s0ePRsLhZ+vr
gWz244WFkXD4s0ePDh8/frq0FMhmP3v06OLq6rP1dcog++Lxzx49GpueNgzjVafz6YMHl7a2nu/s
PF1a+nO5fGlrq1upvCiVupXKs/X1S1tbaKFbqXR2dqBBLq6ukkI86nTsTAYM/+nevZcPH/58zPCr
TudP9+5R18SslP/WLTBvZzIfXL1KHTnqdH5eXx+bnkabh81m27LA8ItjQOnn29v4hVoTX6F/7ezs
/Lq//8n9+58+eHDU6eATbmyz4oV8Atns06Wlw2YTtgRSDedyz9bXXwgA1zDV4mMwTh/G4589ehT4
4gsYJDXbIHXH/65MK5WPFhY+e/TojN//5MsviX90GX/1z8x0KxVYoMNms1up+GdmvHCOmYCZNjox
AUvgpY+DJUulQOXGMQ4g4MpxkJs9rszCU7OrHjrEDYubhdN3gy53HGdlZSWdTkN33759m0PglzKm
AEL3fhmBdA9Acb+A+FEF+D+H782iuJ8R0ZUVQNlGL2xeQiizbbvVarkdI3JDwAbGmZhZk+Ibu4HK
igC51Kwb8xxesQhD7YaE3BOp2NMOxK1bI+HwSDj8wcTEy/19LN2PFxaQFLpw61bHfUvQF4/Duxyb
noaiIfqlUhkJh6G+L8zMjE1Pd45VM6tWxqanz/r9o1ev0p/xr0cHB6z9uCBoEFYlHXU6f1xdhTt5
4dat5zs70B1okLrGvXjW70ez6AL+PDY9fdTpnPX7P33wAEIYnZj44FgZjd248eLbb6GVDptNVq+5
vcJaDjjmn9y/D+PnxjablIMAA9nsWb//Ran0olQ66/fjR188PjY9DX7EKFB8DF/8aGGBRsQL238f
JveO0zhCgB8vLMCA4dNslIbBhYGBdREjJCnnv1QqoxMTaP/i6ireUvQx8MUX6CMX+ngkKVC5cYxG
B82YSCSgGRWNYNUrYLFF5H8pdDlwFQlFnFrmgKJFxtyA0Ae7jID9luJ+Ae6jCtBvBb73ORFdWQGU
bfTC5o1Go7hKSbwFhSUpArbP55Mi67rhG0tBZaUAudSslHkpXjEHQ03IoxwSck+kYi905vXFeXRw
YBjGjzdvenn3rPut9C/399ko/uz58y+PNQ6rDs64/JmyCr8+fHh0cCD1i8kthQ5lG8Enzii3Os4w
zJ8ROvJyfx+WDIEOtuvHpqebmczRV1+9KJVEvSZ9hbZYjzqdzs4OslUU7nBsvzo4YNtkBXjm/PnD
x49hYL67coW1zZKdmE5HfAyCovbPnj9Prrcb26zeV3ScnQmUXZROjwszM09mZwPZbGdn5+JXX3nk
/KjTeW2enD/v+uTBASvV0YmJv/YfNCgQtjOZzO7uLlYiILncziqyjahhsRWqADd2qIHx3RhTAKEP
dhkBaTbF/QLiR9GgFPRb8a1zInB0LBZTAGVLgVsJKQwIZWBLgUXTFwK2G76xFFRWDZDrBiws4hWL
MNSGDAm5J1LxAITFPHxZ0ejEBKvNj15XeV4IyaULMzMj4fCnDx58f+2a2143zAP+8KrTgfYchvnD
ZvPHmzfHpqfPnj//yf37lBuBC9zZ2ens7MD17vkK0ccLCx8vLCDX8Wx9HU46xzZnn14xvXh1cDBy
+TKS+Gx+383Yi49hOBAPkQfQk+2eHWf9CZI8N/psO2fOn4fbIeaj3Dh/tr6O7RkShbqPL/f3ESsQ
VydFAH2jfdBSqSReScRRX9j1oioYhjG31ga7jIDV/or7BbiPQjtxoN89M95nRHTl8fFxBVB2T9zX
WCyGGw0VoNbeEbAV+MZSUFk1QK6UeRGvmD0DQTDUUiRk7yi4fbhL8fhZv//J7CwW+Y83b7pVgqvp
w3icEtbPd3bgafbVwq8PH46Ewx8tLHy8sAB+yAywGhMM/7S0BI3glqPoi36pVODmX1xdfVEqsWmo
C7duoVNjN254fMU4PpRw2Gye9fux4+qfmenJ9sv9fXjxT5eWjjqdsenpD+Pxl/v7YODl/v4P16+3
ZRDK0scgKOxkYBenJ9tcylHacdLISOM8XVoaCYcVOZwLt2693N932zOXco4fIYq2ZcH2KPr47PU+
nmDNzPz8PEFy+Xw+Dlqf4Km5/IRHLG5RFXgnkTEFELpax/a0c4r7BcSP4vZDj6DfhOJ+TgSOxv85
oGzSd1LgVjY/NTk5iX2YnrdNeUHAdoMLdgOV7QmQKzLP4gYD7ScWi7GPAYZ6fHxcREKWNohCBbQz
SMTg94dyuadLSwjSRycmkAcfwMBcXF39eX0dq5Sqkry3gA1SBAoXZmZeHe8TjE1PPzuuRREZpqqk
YVTAhZmZF6USHFvkr4lzfP3CzAynxBWvoKbor7OzKKk66/cjUS6yLY5FZ3v76dLSWb8/nMthK4iV
6tj0tFTDcsKnxy5tbf20tPTdlStoqifbXDZJ2nEKEJ/MziKgCSuvGEI7bl6CG+cfLyw8XVp6urRE
JsftyVAu9+TLL9k+okzuwszMxYFmMqsNWNUUiUSmpqbYBwiemtWzUlhsaSgAy+EGXa4mKWNurXG4
9OrLCDiKxWIiSL66C95BvwnF/VSwkpaXl1OpVL/3T2nS5JG+v3bt4ldf9RsAvWvUzGRQmzt8x3+4
fv3DeHxIteudvrtyRVGnq+k3QCd/wK1arfp8Pm0VNJ0SPd/ZOXP+/PtoFV7u73935QpyL91KpVup
9FW08xY73ras765cQbwI/qU75Jp+M3TCkBg4ltJzO0iTpsHox5s3X+7v9+Vlvzs0OjERyGafHede
+sKieLsd98/M/FKpIN+FRNxgdaia3hfSsNuaNGnSpOk10rDbmjRp0qTpdcPQL5TrkOWYPV/HVZF9
IdlyjaOca4DXvdObwb99K2RZ1vz8vBrimCrz3P61Wq16x0k+vbnEEmpRUO84GO6x+kW0P3BfMO1P
9kkvAhweS7/fQSEw8zeAD3/YbJ4Glvgp0TCsYhNI+k8ocpNiyCtA3c/1BeU6JKqtl9d3d3cHOzJG
MFva2g9Mtm03Gg3xHN8A5BEneRhN6n24Hcf5+uuvUUw88BcVgMnU/vsFHqyGjB5gBPsalNPGh3/v
6LNHj068TQLclP6rYperv1TSkKi2Xl5nYS36olMNEX4nhMNB74V262u4gbJ5esycdvvvC/W7Bk8V
H16TYRgAcRmAzsGLTyQSIgorp6BZVFuKnYEnBSRtBJKWZWWzWdM0OaBX9nW3MAUxMl7ESQ3Cj8Uh
OADe4ru3b9+mAyNwVdACjm8UCgW8S+i1aixxwxtiLXfmpWebOI5PsL0IhvDj4uIiJDw/Pw9n07Is
oFnhTB+9BaBgAH6IzEgxeHuCgXOdTaVSjuPg1Mza2pp4Oq9cLuMwDms2FN3HiKRSqVwuRyOFw4lA
qeRexMwhMC9CgMfEAz4M1zhEt7Gx0XMUkBIpFApoBDgzhhKXWDo5aWpx2MjUvuM4ANnlZtHa2hok
gKmbyWQikUir1crn8/goi/clvi59UgzH2aWxu7srTgB2EGnEgXbcaDQwwQjZntx/KUtij4AnSoPS
05Nl8eFZpD8AhMCTxa1QF7/6auTyZREgnT29gQalTrcIay/inL/qdJ7Mzv65XIahalsWasCera+j
PHckHP7j6qpYpAuXHJeUhHO5XyoV8XnCIT/r9wO8XYqr/92VKzj9/mE8znY/lMuNhMMiaPxhs/nk
yy/RiLRIrG1ZyE3hdOGrgwPUthnHx10pnhDh089wyoJFYeU+I6LaAtxVOvAimjf3uiJaB3ZTLpcD
zDU+kT8+zEnfZRU0CxjLtkbotVj5wLnNZrPFYlFEvpMi1lqWBcTaubk5FrHWOL4oQt0mCXZlZSWb
zZJGU0f3gO5qt9sYjna7DcUnMiPF4PUCBi6Klyzo4uIiZxWANQ8QY1JMXroP7CwWiX1yclLxIrqP
OQNF32q1Go0Gl9pih1uNYAyC15JKpUiwi4uLNM8VuMTqzBLNLmo/kUhI4dkNBgWaoONhnFZWVubm
5miApK9Ln5Q67BhQ7PFwEwCDmEwmMb25TTK4gxsbG1NTUwSDr2BJ7JF0DboRiw/PWgUoSgLSAKCs
Lx7vCZCu9po5WHsR5xxQVASU+3x7e+zGjbZltS0rnMt99ujRhVu3nszOSlHED5vNi1999dmjRwAI
4Z4HNtfo1aufPXrki8eBraLA1b8wM0MA9biwZHRi4ulf/oJesLDqQHP59MED9EIqZACdwV4C0+Wz
R49QM03IBRCIf2bms0ePcEfLy/391wyDAoVVpPHxcUXOR0Tz7jen0Wg0EolEMBjEwe5WqwX1of4u
EXxDQq+t1WqE5RuJRAgeXPwuh1jrOA78RAByQI/gYY9tGsfQ4nhGvTvHasBYLBYKhWBNa7WalBkp
Bm9PMHCFeKUElGBYC/LcPXYfAFZ4vtvt4q9uL6L76DX0+97eXigUUmS31CjxUoL+onmuwCVWtGDI
sJHd4Nkxbwm3GUifjUYDyDEYTcXr4pPqJSmdAPV6HX81TXNxcZG7YRfTgB6gEfHeo5PKfgBAHo4t
bozwApCuIA7W3hXR/dggvSiVXh0c4K9j09Pw+uHCS6GfCKle+jyYB2I5rjZR4+qPTU+/OjhAcNDZ
3gYK/YtSCb2ARw/5dCsV/61bZ/3+0YkJvzsqPssnuAJW2K/HqFwIkrqVStuycLvG6MTEOW5yeB8/
9cMimndf+36YZ2QA8C1oZI9Mco8BIpst5xD5ERFr8TvHBkCmPLbJMWOaZqPRUIhCCvALVF4oII4Z
BP4cBm9PMHA38brBHTuOQ0BdcB28dx+girZt7+3tkfpze5G6DFuYSCR64oupUeI9zg3DBZe438mP
uSHCs4uv4EkaAvxB+jo3WAqviD4hnQDq3Tt26OHVKVjqayX2SyPhsC8ef1EqjYTDuKgOWlIESPfY
oIj9LsU598/MIIP04ttvoWePOp2XpdJ3vXAACZFX+vzfccgZ/PaeuPq4Gu+M3/9yfz+Uy6GndC6S
umAYxh+OZeLlmrwz7hD9l7a2WpaFT/ji8T+urp7AyedgMEheMClNEc3bLekkJXgirVYLKmP4iQhv
i/OSpHGGiFhLiwRs0BLy2KbBYIA7jgN3WPwn9VumaUL9icyIGLw9wcD7FS+LZ06j7LH72IVCBp8u
XBJf5AIpQDEiuac+SD8kgjF1nEtODkaYG17KuvAkobmxU4t7HWkf7smePRInANDlFPvn7J9pinrv
0QnS2PT0z+vruOJpdGICO6giQPpr2tZzAOGGc37W7x+7cQOpf2CJIxT4WAZy7uaSi88jyDh8/JgM
W09cfaAcHj5+zML9Xtra4u4rBKuwaq+GQ7n3xeNoB5sNz9bX+6tKkqLaQsUgOqbydhHNW/G6dGZH
IhFkdbAwgAeutk/s5BajbNzridW4trYmVuK7IdYiG4u9Nfb2IS9tsjsuwNeNRCJoAepMkc6uVqsQ
LL47Pj4uMlOr1UQM3p5g4P2Kd3x8nAa3XC5jEL13H6kGANl6fBFlzdiBl/q5NNxeEIxZUyrtnXdc
Yre5RzZJCs/uNsMxxLSlJ30dERX3pJqkEwDjC0Hl8/nl5WV2vdD4YgsdmzFuLLlJUr0G+zAMN25g
7/TCrVuGO677Wb//l0rlqNN5ub/vHd9bgXOOLBZ7K2LbshCvPN/Z+e7KFTU4sfR5ME+I5ThtoMbV
R8z0cn8fCaizfr8vHn+2vo6NhKdLSwA89sXjz7e3D5tN6b25FEn0DK1w2gN75h/G42fOnx8Jh/uL
GAjVlvWtYrFYvV5HJB6LxeBaimje7OvJZLInMHUmkyH8WNRCqB06AoyVesoczm00GhW3PXoi1tK1
EN7bpFWHFlDvgbQVXfbkFuCbpglm6LsiM6ZpSjF4RTDwYcSLnhYKBYCf99t99JH0tfRFcesF+zFu
jioN98rKiohgLNWV3BXBrJy94xIrdHGxWOx2u6xgCZ7dbYZblkVDII4LvS59UkFSNHj8AYJCy5wQ
arUa/gl1ItKpou4ROyjLy8vc5WLeCc77850duv1UCpCOi7i/v3aNnve05eCOc44taHLMcesfae2P
FxbU0IFuzxPWOn4cm55GkZUCV39sevrw8WP63KWtrSfHoPEj4fClrS3g8tqZDH4cnZiQ7j/DoqAq
SZG7Y+HTffF4IJt9a1hJlmVNTU0Nc+DovSCuMtUjtVotac3o74ps297c3DyRDI8mNaG2+506HNq2
LGww6NF5K/R2sJKwlfp+HRPV9OZtqvq6J02/YXq+ve2/dUvL4fdlGFAwp9e8Jje/YX5+HlVJWhq/
N3pRKn135cpZv/+ChxJMTadEGnZbkyZNmjS9AxGDJk2aNGl6pw3Dy/39o+HKYPulvgBmm5nMwMC8
7xHo7m+VupVKzzo/6VuGEhb4tLl9A58e7BOQDPiUFqIMw893V65wzbLFl9znPPKActI3OYh9aYxh
JDnMJBFXhLo10tJvSKf98i//8j8/+eSvjx//TZOmUyBMsF/+5V+8v/I4nf7p9u33hds3Sa07dx79
h/9wSo03/umf/t///J+ln/s/29uDaYn/7/nzxj/90//Z3tYLYZgZzmrp//nJJ29Anmf+eqJOhyZN
w9PAWMFaMsPQUafDISsM/znAjuqBG3Ic37yWPoOY64fr1xFS/XjzJk7BPd/Zwf1K+PHl/j4OyDUz
Gfz+482biL+e7+x8f+0ansTxOZw6QVPfX7sGjFn8GQEUoiEcBqFPoDUcx/juyhWwxAaGL/f30eZ3
V648mZ096nTcWOJSSQiEwQOe56QgdoGTBv25mclwbCNMbmYy1F/pSqA4nRqRMv9sfR1HIikoZgFS
frh+nWJkOkUpMu/2ozTV5tYvSPKH69ebmQyacussO2QU5D6ZncWPxD97hxSbX+pWKpDA99euPd/Z
aWYyh80m/kDBtVTmP1y//uPNm8QJF5v3NUwit/RpUZLcPKRIn/uRxhc/AsAATWEG0iekHWEbhGSw
KtEsmwAR5Y8FSJ0SJ4D4CubS06UldoLR5/DLT6+vIOJBMdnQwadLS23L4oRP7JHYpWyLgsVyJsHS
AqdXSGOIykRsbRhJKiYJmwLivsjOcFYmbCqJvtjMZAg2nHphGMaPN2/Sh446ne+vXWPPfg+8bP9h
GIBmTlf8+OLxzx498s/MiMi0f3cBOp0/3bvHYdhykK3g1X/rFjB17Uzmg6tX8WdWzXV2dn7d3//k
/v1PHzwAo8jtAoNw9OpVVkUedTpu0LscSwoz+NmjR5e2trqVCitE2C3ACoZzuWfr6/SvkAZdcoQH
nszOAgL30wcPDMMgrJXDZhM/ihAo3Url2fo6+nVxdbVbqRCeIsc8MB2hsw6bzW6lwgKkSL08Uf6K
HrmJJZzLSaF9wfxHCwvcj9TZzs4OQQ1/GI8/XVrCbOlWKn+6dw8iUvPPgRJf2toaCYcvzMyEczlW
cbvJ/OLqqji11K9ww6TgVipefAjz8EWp1LYsBZDyq07n0wcPLm1tPd/Zebq09OdyWZyB0o7QVz59
8GAkHP55fZ1DUSbmRfmDc5q9LMay2yto8+Lq6sXjU7jSz4kryE0DgKBYLq6uYhGx06ZbqWCyXThG
r5OyLUobLf8hHMZjP6+v//rwodhTqTJxa20wSXqRgPjFcC7HznCSCcsJDvcBQPDl/j5paToLLYKT
c4pigGXLbz6zRGfQpci0eADgVoRhawiQrWgBZcj4K/4MCFlOprgx45P79y9tbQEHES7Apa0tVlgK
6F2OJTcdhPMy6CArhRelEgHS4og8wbKzssafjzqdbqUS+OILXD51cXX1sNnECOE8vfTTmFhogavO
5pgfnZgYCYdhNl6USqMTE9IrOIik8lf0SCTqlxTaFw+A548XFg6bTfxInX1RKl2YmcF8vbi6etbv
f769/aJUGrtxY3RigthQbMFxoMSiWVXLnGBt2KHva5gU3ErFe9bvP2w2ny4tjRzrJgWQMsZ39OpV
+vPfBf46go3YkXAux0K5uSVkpPJnFyCHsax4pSehg9wKctMAbgsBwg9kszB41CBg4ES2RWmzy3nk
8mX4oPQKQQNJlYlba4NJ0osEFF/kZMJygvkwOjEBYyNdthw4ufhAv8tWZRhoWcLrRPqFDdJFDFso
dAQmiJKM1yFe3eBecePoi2+//fHmTURSoxMTHy8svOp08F22tADNctC74PaMt9sB3bAMX3U6R50O
RbXksHOv4Cu/vo52iwewyM+6o9pigj5dWkKE+NoACFxduHWLcOHV4YKb/BU9kiQTGRBjii6BJPP3
tXrcL3QWM4x+fLm/zyamz5w/j6/Tj9CJrhGDAEos0gAy7+sVNbeieD9eWAAyD/Kl3UqFgJQpMUIC
PyNMIfnklHGFBfjD9evP3O+lkcrfUGIsu70y8AqSaoCe3Wxb1tOlJQ5CTmRblLbIjJQxqTJxa20w
SXqRgOKLiqH/g4uLSUTg5HDpREUxwLJlc93ycwxApsV0/+T+fbXT6ovHEZJcXF399TjQ9kgfLyx8
+uDBpw8efDAxgRAskM3+6d49mFbkVUkQrJ+CMTuRfa0zfj8sM/3HJjE4+mBigt0LOnpddaqtAnrR
M7sCX+D5zs7L/X1uvKU4w6L8++oRuyDhs9N/cCjIt8UXuclAqMi02XjG7z/r95P/TnxKmYfo1Htx
A8i8r1ek3CqmN0DHkBxAzoqAlFnpDTktKTX8x+M8jJSk8le3PMArahpAAzxdWoKLShdbKjQgJ23v
jInKRNHaMGJRSGAA/s/6/V52m8empzs7O52dHYCTS12uvpYtqy7OwDRx60GBTCuaEBGy1aM04Q3h
KtQPjy9HpQAFv1BrbtC7wxuGD+Nx3MmHln+4fl2xWwsIXKS/4NPBdKs/8evDhyPh8EcLCx8vLPSc
GWjw5/V1McYUcYal8u+rR2y/OGhfzAq6hQqd5WbY2PT0850dDBmuLRybnkYCFD+yiwQh7VGnQ/yI
oMTdSmXk8mU20zKAzPt6xY1bN/FiZw+r64zfj5bVQMp9V600m4fN5tj0NJLLlJgSUZSl8u+pUDy+
4gW0GRvXbhqAvUGB0zCjV69eXF0FVLWicVHaHmXIAmWTMlG0NoAkvehA6Re5GS4OELYWjjodvC7V
0hw4uZhj7HfZvuYpfjAxMRIO/3jzJvtVpJ8QGv9SqYxNT//qYhtgD7Gkf7h+feTyZXVOmaWPFhZG
Ll9GRUrbsrBDFchmUW/QzGQC2SyxC+hdxDs/3rw5evUqoHeHJ188Tl1Ay+ouXNraAttARb/0zTec
fYJ5Yzf6A198cdbvR5HAH8LhUeVeCG3GiPMykM2iHTuTobkuyt+tR1x2zq1fGHRA+2JCP5mdRWfD
x/f9cvlADNkvlcrF1dXRiQnsW+JHUgr+40n1/bVrNE2BHvzy4UNkYIBU/GE8TsDIHmU+wDCxXRC5
VUzvS998Q3H3q04HKVqanPicCKTcF42Ew9jGhFiQQcZVAUgS0mqVyr+nH+3xFfqcOtek1gC4doaz
uH9cXaXCP8xztxUhStujDC/MzIjKRNHaAJL0ogOlXxRnODdAY9PTWCln/f4/rq6SlmZrFgA27mbA
Bli27AMaK+lUqJnJBLPZnpGEIgv8482bijueBiM4Nd4tN/ydD+Pxi8OpOU2aNJ0GuYGTD79sNVbS
ydNRp3P4+PEH3twNKXW2ty/MzJysVTCOqx30AGnS9Nug0wMnP6eFe+J01u+ncyEDGBXEj6dxRYm+
9kSTpt8GvSiVnszOjk5MnBI4uU4ladKkSZOm10inkjRp0qRJ0+uGgYXfIQLYCMqwRBgN+tE7oC4B
+7hRq9Wan5+vVquGYZTL5fn5+fn5+Var9VuStXjfPft7tVodrMuNRkP9om3bjuMMzLZlWVavatd+
n+xJ5XIZt8+7fahQKJyU/IeR7QnOjTc24efn58vl8pDThlbraawRGn1cfj4/P+9xuPF6oVBQTJ43
QxByv2+xavANkGKVyfcYCMRD+q84vHPU6fyvROKjhYXRIXZZpbS7u5tIJJLJ5G/JKliWFQwGI5GI
ODbVanWYe9gjkcjGxoZiqViW9d5dpJpIJBT3emb7KaxSy/8dIfUgvvkvvpVpQ2NEo7+3t9dqtVZW
Vryw8Y4P8XsWMQz85ukB6jqOEwwGf2OCbrfbbj7CqX73NxZ1nbj8Nb0700Y6RsFg0KNx0kN8gnTO
OD4cixPIl7a2fPE4ztoFvvjCMIxXnU4zk+lWKr54HIeevrty5eLqKhJQT5eWXnU6/pmZJ7OzOEc3
OjFx6ZtvRsLhw2bzyZdfItfkPaqYn59HMGjbdiqVot9rtVqhUFhZWSFHu1arzc3NVavVYrGImDeZ
TCYSiWq1WigUFhcXYV3m5+fxO2d7CoVCrVYj/zSZTMJLCoVCtm0nk0nTNLmWOVbxoVgshtAvEonA
kxVZsiyrdUyst4twAUyis4VCAeGwojU35+7u3btYQrZtm6aZyWTQoGEYa2tr2WzWNE0I1jCMaDSa
TqcRqkcikXa73Wq1QqFQOp0OBoONRqNQKLRaLcgwEAigWe51fF18UhxTSDUSiSSTSbERwzDy+TyG
IxKJZDKZarWKQGptbS0QCCCtEQqFUqlUKBSCb5hKpUSWpD0Ch6L8WYLkTdOE9JLJZCwWYydMLpfD
0JCUpLNIKqV+B9FxHGI+n8/bto0/YygjkQg4icVisVjMsizHcWjCFItFJDEgInjQ5XK5WCyCee6L
6AUYRseDwaB62hDbm5ub0WgU3XEc5+uvv06lUtFolDUw0gnGSSmVSuVyORqj8fHxarUai8XA8/z8
vGmaU1NTig+xSywYDHa73c3NTbRPApdKhsueeRk7t4UvCtlt6NkVIU5Ix3Esy2o0GlgLu7u77Xab
xA4dxSVUMAcwdW/fvr27u8v1VDG9par171d7/tEFu9gwjOfb239cXf3k/v3Dx49/Zv6VBdSVIjYD
vuLTBw8A3O3RMCC8TaVSrFXAOKEPJO5oNAqtNDU1tbGxkUqlisWix/RctVqt1+uLi4sbGxuxWKxc
LmM2UIgNUaLlbDZbLBbp01Ke0+l0o9Go1WpSlrLZbDAYjMVi3CRIJBKxWCwYDLJBPdsaZqpHNrAO
U6nUxsZGMBgsFouRSARiXFxcDIVC+XzeNM2NjY3FxUXbtjGJMRHn5uYWFxdbrVa1WoUShBwSiQSc
R8dxxNelTyqklMlkpDyQmZ+bm2s0Gru7u5zSTCaTGxsbpmnmmTOcUpakPXKTvyi9UCi0sbExNTUF
W8KajXa7jQlDbEhnEXjY2NiYm5ur1Wr4sd9BTKfTYP7u3bupVIo6Qr1bWVlJp9PQULdv36YJUy6X
y+VyNpsFS9C2jUajWCxiYrA6C0QMr6ys9DVtsCqpL/gDq6zZkeImmGVZaHNubg5timMEQ4vVMTU1
pf4Q97rjONFoFNMSE1UqGTdReBw7buGLQu75unRCVqtVDHq73S4WixAyTAtGUyrkVqu1uLi4srJS
rValPXWb3lLVesYwjLHpaZx74rCLQcAuBpiwFL3ZDbG5W6n4b9066/ePTkz4T6LYNhqN7u3tQdyt
VisWi9Xr9WAwCCMci8Wi0ahHw5BIJLAMSC60z0ZiMk0TLUciEfq0SDC8eKvdbg/MEgiOALXmnQ3Q
+Pg4JmU0GiVTB6rX661WC+1jCRFj0WjUNM1gMAgvpl6vO45DXUCD0telT7qNnYKHWq0WiURCoRAm
LucNRaNRCDmZTLZaLeqX9x55FL5pmlCIiUTCNE0SteM4tVoNJhxs2LZt27Z0Fvl8vlarVSgUoNES
icRggxgMBn0+H2SCjrBT1DRNGmjTNOnrtVotGo3CF6Y0PeYkyVDcsJmbm0P3o9Eot+GsELJhGJOT
kxAF7DcbY3EjKE4wiDoUCqFNdX2Exw+xQ4nuj4+PQ2NIJcO91dfYSRc+J2TF61LlTtopGAyitVqt
hgkAse/t7WFKSKcNpqJbT92mt1S1njN6AVX+gUG6xr1j4maDYRgcHMrL13GP1bjK3g2DZVmpVAo9
R1jE5i4Qg3tsrVwuQ8twigPZGMdxHMdBXosiCbcpyEWjA7MktuadDenrXFOI/b18FFoAfw2FQq1W
S/q69EkFY248IE3Us1OUKOu3Rx7J5/NxOgJcobViscg6y/i6OIump6dN00QqDCH/MIMo7YjiAdgG
LiJxHIfmJBQ096/oV6PREIdPIWQMfSQSqdVqwWAQMZ+XaYnNAGID/9rtdhUy8fgh6VAqJMNRX2Mn
Sl4UsvfXuc6y2gOaularwVC5WRRq0K2n4vSmD4mqtffJZ9phftXpnJWhGxJiM4vlBFQ/wH4ZMnjF
ASgSicByVqtV2ORQKMTaPcdxuHnvppSRcYMNTyQSeQFkCh5Zz/knkpSlgbs8MBtu84Yr8JDqcdK/
UIuQofR1TD7uyX55wO+KNBQ1iz+EQiF813uPPBKrm7rdLk0kfDedTnNrUjqLkNWl/Y9cLodY6kQG
0csoixV9xWKR9X44Fby5uYlplkql6vU6V2TpNmSsu1YsFn0+HwICL0xCgZJignhFVT78h3pKRtTI
XsZOmgOAn8oJebD1SwNECm1ychJJadu22T0e7z0tFApu01uqWntXJeHmQsA4A+j170HAMaCuFLHZ
MAxfPP58exsAwh6viOpJsVgMCWgs0fHx8VarhalcrVbJ3FH0xLp4XNoaK2FyclJabjw+Pm7bNv7J
tu21tTWPVclSlrAYpHoTG2WK1gZjg/M+HMcZHx83TTOXy+Gvm5ubbmcO8CR5kdDC0telT6qFI+UB
20XYYV5bW+MYQwIXe6SsUvDeI4X8OQsE8RYKBcdxJicnaaVFIpFSqQSrUygUlpeXHceRziLiPxQK
YVUPP4h9RdU4o2Acn4xpNBrj4+PUtXK5zMmh1Wph+5dVed6nDab37u5uz/QONw2wv23bNpLapmmq
x6jnh3q+LkqGe2aYsZMKebChx+u2be/u7qLXCJiw/dOzYtOtp27TW6paPWElkaLn4PoAqHvU6Vza
2noyO4ubrEfCYRQvXdrasjMZ/Dg6MQGz0basZ+vrn9y/7x1XnUs1FovFWCwG7Y9dMorxadMfO04K
OaIKgqodkApg3RCuZSq98BLWSFkaHx8vFoutVotzHzDeKJ3q2Zp3NtgIJhgMbm5uptPpbDZbKBQQ
2EKjuXkc2Ww2n8/Pz88j10k/cq9Ln1T7MlIeEomEbdvIV+BHNuoKhUK5XA7pps8//7xna27rFvJP
JpOImkX9YppmrVYrFovBYBCbmVQBmclkcrkcTgMFg8FMJoOMrTiLUATFsoT/DzOI3imRSHS7XdLd
yWQSuYtUKlUoFIrFouhrJ5NJ8IZ0P3ZcvU8b7ExUq1VO0XifBmSWaIyk2ZKeH6LXpfGEm2RY8jh2
0ogBS5UT8sDrd3l5mV4nde+27eylp9jt4Ka3QrUaf3vf6C9/+cv/+B//42+afh/09ddf//M///PJ
tnnnzp16vc79+M///M9ff/21FvgAtLu7+1/+y3/5LX3oHaRms/mf/tN/6na7g73uZXqzqvU9w0qq
Vqs+n8+L2dSkyS1f1G63B0hSa1KsSu95pPfiQ++skE/vIDqnWt8n2G2cWOm596JJkzqPMQwAiSZu
+yefzyMH9dv40LvpyiwvL5umeXr1C6Jq1bDbmjRp0qTpNdKw25o0adKk6Y0YBgJGPnEU2TeMTOud
1EC7wBLvKS438g4ZrQDxfpPYzu8miaPAymRIfHIao37beQMw0X1BjrMysSxrfn7+raNYa/qNGIZs
NquoHdTUr5XteUSAFJ/CwADU6LeHXDsMkUwajcbm5qb6/K2XMRqynVMyh31dX0EysW270WgAuElP
FW0YNL1b5B1PWINsDxOJnsgYvYNDMDBLdNRcT4/fG50zeqHRAlgY7gNOpuDkNICdI5EIi1VLgK4E
jCydbSyCMQEps7CxqMoizF5CogaUtHEMFWswGMgikG+32/UC+cuVOUmxlPsC2mUXJDCT2QekAM70
isgbB9mtGKyeIN6EtAwkSDcU6LW1NQXyM47Oc69LOyV9TJQtJ8ZWqwWAZTVUtXTWgXODAR6PRCLS
UWDTJjjvxgJNEzKEdEUAvRLalg5AYYAow4l2cAaefRIdJH5IAiJMdF/rTgE5vre3R7NiZWVFMfcU
MmHPA0oHEb+Mj4/jd3ShJyi3pnc3YvCCRus4TiwWQ3QJNHACdjZksL3qT+ZyOSAYAwGccIoINlaE
3AJmL0Bo6cfFxUU1kC8xz0H+KmCEDSUit+EBaJezqYZhrKyszM3NkVSlAM7EqsgbiyesHqyeIN70
FRxxBI4pB6RDY+GG/CxFEsbvGD7HcUqlkvQrUtlyYoQl6AlV7TbrOOBxt1EQkycENA1DlU6nwQ/Q
INgxKhaLk5OTmGlQ/TRGwFo3jgGrxSeNY0CClZWVZDIJvHFDBhOtXnfeIcfZWSEOkzqhBO9ncXGR
LRJ1WyC4E4LtgkdQbk3vomHwgkZrmiZmBtQf4c1i+qphe0Ub02g0gCsLUIFWq0VoPFL/BThWBEJL
PwKDoSeQrwj5q4ARNpSI3F6Adrme4kwK1V+7ATjjlZ68eRksljgQbxpNeIXlcjmRSEitmgL52Q1J
GEgssO7pdFr6Fals6/U6yQcwG4YH2HO3WccBj0tHQU1gAO55Op2mC0zoX6HTMdNCoZDbdoL0SZYf
iAVyEGGi1etuYMhxbpgGUBluC4S4pS70i5Wt6R1KJUkxWqlyA1hDHF6rONUUsL0cYZZwiLssfqfb
QjVeh7D2AuTL/p9Lm7rBCFNORoHIzTalQDOGvqAf8Qf8KAVw9sKbF+hgBcNEuBaK4KRSqRTHvBrY
WUQSBjwL5TqQC5J+RZQtUiXcBOsJVe026zhupaOgJuAtI1eJ/CGXEUXoYxxDzikwtMUnCXSTe1KK
LapYd4NBjkuHaQCtIV0gYhf6xcrW9A4ZBilGKztdetYzqGF7xVWHeB/LSW0SRL3p9qQUyFcau/SE
Ee6JyM02pUAzxjrB7X3G69jCIoAzcA178uYFOtgLRSIRcIU8fqlU8u48uiEJJ5NJ4NfncjlYAvEr
pmmKsg2FQmwxpUe8Yo+zTjoKXpxi9jJIunkJcwypc5ygVkwP6ZNk9oYcwYEhx8Vh6ndv2fsCMYbG
ytb01lJJXtBoFYQ9NxG2VzGhI5EIPA4CUkbs6UbVahXuCeB5pc+4Afm6PamAEe6JyM02pUAzRk/B
PG1LugE4q3kjPOGeg6UG8WYjQrAdiUR8Pp/0omZFr0UkYVTit1ot0zRpNMWvSGWLBiEfj3jF3med
dBSkRC4FK1j0hZUPfk8kEoCAJc+AxojakT5J/KDUQn32RT0K3iHHaVaIwzRA7bL3BWIMBMqt6Z2I
GLyg0SooGAxKYXsVr7AIxiiNUEcMpmniYSgCt7tlRCBfqYrsidUsxVKWcigF2uV6alkW9VTsPgE4
q3ljIbvVg6UG8Wb7SOmsSCQyNTXVV7QhIgnDA0WnsHXE4RXjK+Pj46JsqaylUCh4xCvua9ZJR0Ea
yxLQdCKRICEnEgnWHcFGF3I48Jrr9To7RtiIRjuRSER8MpVK5fN54CqjX30dMvA4jaWzAlVJ7DCZ
pmlZFqohPH5aukAUfHJY2f1+TtNboXcaKwnld1LofE2/VYJVO70bCzSJEcDu7q70VvoTIVRe6Q2G
9yyVpEWg6e0SYCrgdVLqSYvljVG9Xlfncoek3zNW9nucStIi0PR2KRaL1et1pFwoDaXF8sZo+FoG
N/o9Y2W/76RhtzVp0qRJ02ukU0maNGnSpEkbBk2aNGnSpA2DJk2aNGnShkGTJk2aNGnDoEmTJk2a
tGHQpEmTJk3aMGjSpEmTJm0YNGnSpEmTNgyaNGnSpEkbBk2aNGnSpA2DJk2aNGnShkGTJk2aNGnD
oEmTJk2atGHQpEmTJk3aMGjSpEmTpt8AvbWLehzH6Xa7Pp+Pbjyu1Wq4d5d9DDc8s49pchOmFpSm
t0jS9euFWq3WAG+9U+uOpfe0L3LDUC6XW60W3SderVZrtRqugW00GnQxOiibzUYiEcuyotGoeDeT
ZVmNRoP+uri4WC6Xg8Eghh93+ZbL5Wq1igdisRh+LJVKiUSCxFqtVnHRIygUCk1PT0uFXi6XcWU8
USwWS6VSxGGhUKDPgXCrcKFQIJbEZxYXF/f29ur1uvo6XFxMvbi4KOWN/QSEWSgU6Cb0YrGIPgaD
wVQqFYlE0NrGxoZhGLjnXcEzvl4ul1mBRyIRVowcVavVYrHoOI5hGIlEArd3cUPJ8iD+Vew7+8vK
yoppmiyTjuNYloWbO+kyZ5pgYgu44rtcLqslz44XmmUnrSjtarVaKBTYFiKRSDabZd9aW1uDIwJK
p9O4yB4PSBcC2p+fn8cEoD+wQ89Kg1sd1F/2RbWEsfpwF7r0DtR8Pl+r1dwmFbdeaESoQW6CiV1z
HAfX7RFNT09Ho1F2/arHwsvyofHCMNFjblORWyzBYHBxcVHUUVzvuL9yDFAXSICcJHO5XLvdZt/q
drvJZLKvG+u4Id7Y2GDnYSwWi0ajEB076GrVwc1k6bQR+85agd4RQyQSYUdifn4+EAioX8FsE+c0
TZHd3d25uTlYi7t374ZCIW6KNxqNYrGYyWTwu+M4xWKxUChINUUikUD33FZXKpVKpVIKBcctkr5o
b28P/+/33Wq1ure3Nzc3FwqFyuVyLpe7ffs29wyrZdwacRxnbm4OgYLjONCY0vsaW61WoVCAJoLk
fT4fyza7uujP4mJmlx/Js1arlctlMV4pFAqmaW5sbDQajVwuJ441FgN5Fd4FiLnu8eFYLIblqlCp
1FPHcZaXl7mbkLEQbNu2LGtlZQWztN/ZQs6WVEu6EclHuqBYKhaLrVYL5rlarYryxOqD6DAigUAg
Go167wJ85M8//xx/vXv3LvyMvsiyLFal3r17F38IBALZbBbrPZ1Oj4+Pb25ulsvlyclJjyIi8Sp8
R/x5+DtNY7EY13fWl/VOMH7iPCwWiz6fbwDVQc4QZ577jhjq9Tpn+qTUaDSCweCQsVKr1YpGo2gk
GAxGIpF6vc4t1Far5fP56EfTNEOhkHod9pydeB3/pwUzzOSwbbtYLLbb7WQyWa1W6/V6KpXihGPb
dqvVktqMWq0Wi8Vwv3EikajVarVazbumG4AwfNCP+APnVriFBV4aL5fLoqPkOE6tVsM0jUQisVis
Wq2q+1goFMhVHKCDoufI9aXVatm2HYlE6EnxQ7u7u7FYrFgsIihhH7Bt23Ecyn60Wi3ui6zudptd
Yv7hpMi27VgsBvMci8VojhFXtm1Ho1H0KBKJRKPRfD6fz+f7/VBPJaAei0wm0+12HcehRR2JREzT
hB6s1+vBYBDmKhaL2bbd0zCoQ1vyHcXJ5r0LXHeQ5AgEAmy/IpHICd5Y3mg0hlEdtm1juiJPIHUj
xFzLPwxDrVZrt9uRSKRYLNJUhlA4J7parfZ7rzdmJLtCTNNEYoGGU2wTITwiQeiXnp+G/rJtWzpl
kXIJhULFYjGbzWL2cNOCE5PC0tIt59FoFPJJJBLlcjmfz9u2jRQEHgNXtVqtL6esp1eIXkDVlstl
NrTHj26OCeIJmAQpVxSi9hVCWZaFUIAWD0YcCpRGJBgMskMvJTaVNKTnJXqOhUIhFArt7u5SHAyv
irNwjUYjm82applKpdgHHMcpl8uRSKRUKqXTaUpZsCpDGuSxQ2YYRrvdbrVajuOc+IZQMBisVqvR
aBQRQ6PR4NwpdB+2odFo1Go1TFfWnon6YgB3QT0WYK9arYZCIdM0aYFT+pHmjGmaUHx9uZ5iVsO2
7UKhgOkXCoVSqVRPDU5d4FJJPW3zidgG+JTRaHSAwBQCh3iLxWIqlaKEoSJHglTS3w0DcnlI7Gxu
blJugRtXaDfbtmkfwiNhj4FT+o1GY3NzMxQKQY+L6sk0zbm5uWq1ioEMBoPpdFotbjh3WBWijKAR
0um0ZVmWZaXTac5+IN3ExfhuWiwajYpf4bwSNJXJZKA32QCIGoGWQTyISeDFl6RMHbrM7fiZpgl1
EIlEuD4iHYmknNSNqtVqe3t7UG3INQUCAYh9fn5enBIQOOYfJobU4r4xUniprVYrn88j7QafgxKV
XKrNcRxYBdoPwGNoAbNobW2tUCh4N/aig4X/e7S7oq+qMKv5fH55eRl9hyli1VkkEpmammIjZrEX
LLfip+HUU/IHU26Akdrd3b19+za96zjO119/Lc00RiKRVCrVUyOLaUMKQDc2NjBec3Nz0IBQeqLN
9kjYdpZ6YKZpnsh2erFYnJqaopnJDkRP1YHUWTKZnJycvHv3rmVZ/SaUzpXL5Ww2i8X/+eef3717
VyqgRqORz+cplz0kQQWjP/Q5Co7YTWAyBgiL8ItoIaAl4baLjnC1Wg0EAnDxstmsZVluWfiTolqt
BquA3mWz2Vwux40NEpRw9oPBYCaTMU2TMwyKvITjOGrvW2pH2TXTc+r3zDLl8/lWq5VMJt0WFQwM
m3iR5kxPJJWk7hq2gj7//HPTNKH1isUiVAOtpd3d3ampKdKJGC+KGGAkYP8+//xzGAm3EFmRSqpW
q91uN5FI7O7uTk5OqjUIu4vjkdLpNKa6G7nlVTySaZqLi4tcQU6r1eIcEXUqCR49cnqsE4bfoVtp
HvZ0wNm9VvooJgMCUEW4owiLxS5w/hCygjSl2T+TqsQuYL8CL5fL7XabOEdgSlNLrToQflG/MFfd
0gOuqSR2BwyfFz1l2B+yHydCu7u74q4GEnY9sw0cG47j3L17FzU2Pp8Pu+3sM9w6IQVN0Q+bP6G5
Rel49USULubFxUV2GCKRiHS7Ur1E1RoBTjoFVdw/iZyLRTVihj0ajdq2TfMP7qSip5xgLcsaHx9n
e2SaJqrCUNUDL+REUkmhUIjSBT0DfFSpsYyR5MmcuI0FPcAanmAwCKOCX2ikpEPGBtlIaCB7Y9t2
Pp9HdOI9MYudc+8b1x6tS18NGi4FOeTvk6xQWyg2DnVGBXKYKplMBsZjfHy8UCjUarXx8fFqtTo9
PT0Y8+yET6VShUIBehBh3wB+BkkSs6VWqyFcBtvYZutp7MUIjCtzgI+inhgK1QHLzfJMDhD7O3Ik
FN9zqaBzUs0YjUbpOfjg2AHvKwneM7jmfFJE8Ujs2rbttvEiHf5IJALvjGpPRQXUarVKpRKbrIzF
Yslk0jTNZDIpde7cagxY+SrKVd1WBfuAumxAUU7nFhZgc1VqANjilkQiQfOeXT9uovASYeC7iUSC
nWTJZNKyLNhat9iCC5M9xgduik8tdm6qY+aQGFEPw8asSHyzg4t1S7M3FAqx/RKnGZUFw8tLpVLo
I4JXpIDVOVI2NUeDBWun8GdpGrCbYZyBkf7iZf1i95j9hU0uedwQmpubs217c3OTUy9YktgSR72m
lwoIt6JEEgIbIHrcq+B2s7lf2u026nch6kgkUqvVTNPsyzBQCEvJhmq12tML91JxhNpOmgamabIB
cY9UEuZBo9FgZYpCBcix38DTYzJLWghBFtK2be8ZWG681RUIqOSjlDG7LMWq5yGDbuliULtmPZ07
Thdgi0kRBPRL4mLwmM3I5XJTU1O2bZfLZS5oUCzIno2fVGUh6fRGo8GqIUx1GpRCodDtdmmSOI6T
y+VYPwN+Ertuy+UyCljxSj6fZztF0wwuCNdZL4uFXFeUPJCZcSMEJclkksSOohQufe9WGUyOpJq4
owxsel2M3ljDH4vFkGDk1Bw7JeC19Fvn0lMXiW6Wl54qNnjEYk7FHiHquXsaJ+n+5QBxIaZuLBaj
L2LXE7NU3AVkhyCVSr21k89IRHCxEpeAFt2E38apwhMk1HRxzkXPgyYnS3BMQqFQIpHAcTZp5e7A
jZ/qbpA09Ol2u+/UAXJEIbZtZ7PZYrG4ubmp2NfxrjS5iOFE1q9o/KQqkn2R087v2tF9MWKgv7bb
7enpaU5ruXn6KBR+F3rkxeiegztWLBbZDkej0Z45uCEpEAiIQQPVq2FyiMHpMLvfqVSqXC6jYINN
JXE+hWhL+93945a06HGwa1K6wcXumIlxPVsdhPJEUbaDnWpReEnSTTzj+BA7JaYQH5TL5bW1tX4r
PaQ6GruaJzXrEolEt9u1LIsSQdxUR9UWuxa4SUIHmNlUEpsOTqfTpVKJFWBPH79nbF2v12OxGPhE
VRUOsrFVPaxiwuYTTZtQKDQ1NcWJsa+zhP2u355O8SlpFdG8cQk3cTXRxuoAEUMgECiVSh6F0Gg0
+i3p7OkzKdYp9mx2d3fpGWyaeozD/s3f/vY37Xdr0qRJ0wkSi30yGKTC2yVtGDRp0qRJ02ukYbc1
adKkSdNwhmEAwCw1tY7pRFrjjs73dZL+fSQgW7x3bDuOc+ITSZN3elEqHTab7wgzR53Oqbb/cn//
5f7+722Ijzqdw2aT+0/xGDcK54xe+KssuVWIS9Fce9bgo9qaPeHitjfidjjLeH0jF8UbtLXF/VVk
1Xi99hkFXnTAFZy4iULE+kYdDouowW4N0R6Xm1jY36lIma1W5gApsQ+PU2PoY19IxXRGDwd/SJhu
ONXgXw0LKlbHu2GzQ3SiVFHcicpr2haWDgFXH0LQTIlEgusvxwMnf+omDj1hJrghsHIHGyETjj11
NT1HT2ZnX5RKhmGMhMN/XF31xeOHzeYP169/9ugRHmhb1rP1dfz544WFQDZrGMYP16/j4adLSyOX
LweOCw2+u3Llk/v3R8Jh+sNRp/PjzZvsFz9eWBibnn62vh744osLMzMK3qgR/JU+ahjGYbP55Msv
oW1HJyYuffPNSDj8fGfnRakUzuUMw2hmMt1KhZryxePhXK5bqfy0tPTJ/fvch368ebMnM4ZhdCuV
ZibD/hLO5XzxeDOTGZuexuvNTObw8WN64MKtW4FstrO9bRjG6Orq06Wl5zs7nDQC2SwrRk7+UlFw
xDY7Eg5/cv8+nm/fuUPNPt/Z+Xl9HcpXOo49GWPFSwKRypOkKv6I0cefD5vN9p07vzDD9GE8Hvji
C3Szd7kqB7/e7XbZk9kDb6rgJBGLVwMQYOB/cQ9z0N8KDom9QCDAqhJ2L4hsDFe6g3OYKysrrVYL
h+YUy5s74iC1W8Qz9CldITBYjQodKUJ/6/U6YEVYefaFVExAOsQqezCbNdIiGt1gwRyVcKAj9DkA
+huGAUSWubk5tvxf0SY7KwZAPEbJP90v4obr7uaIDEnP1tcPHz/+9MGDs37/850dTuth5bctC+qv
W6k8mZ0dCYfHeh0DZunVwYFhGOHj8qFmOn10cDA85z8tLZ3x+6E9m5nMky+//NO9e5zKpj+3LYtV
1hy1LevVwUH7zp0P43E3zUvWhdXX3125MnL5MvfM4ePHl7755qzfbxhG+84d7rsXV1cvrq5KVf8w
hGYRh3H6nVTw06Wli6urF2ZmMI6jExMwsafKmNrcPt/ePjo4+NO9exDXUafz9C9/eb69/fHCgsGe
fHYDzTBNE9jrtm2Tx8pi5Eo148meSxJ9PdZNA4ftdhsoNEDlC4VC7GETL+Wb8M0B8T01NcXaPy8s
icRFDDg6pNCw3CjgdVJD1WqVdVd9Ph+QKTEogyEVnziJBpIiNgwK7AHCRNM00TsYYNu2u90uxpSC
ziGnEE6luhl4wBeDh0wms7y8fFLQmB5THP5bt7AsL8zMvCiVLszMjF69+sP16/TA2I0b0CC+eHzs
xo0ns7PG7Gy/H1IrXDfeDMN4+fCh9N1upUKO6h9XV3+4fv27K1fApPjwL5WKaMwOm82XDx9Cjf7p
3r0XpVIznb5w6xanMRXRw0g4LOXtrN+v7i98ZAQ0ZIyhDVmrM9iAjk5MSBN3FNP44nH/zMyLUkns
Zk/GupUKx5i6p686HS595H0mnKNI3A1/FasUAT7BTFarVe4EE3lSbCpJ8WGceufAUnA6dLD1j5O3
gPDN5XI474cAApEN3F70S4QTAAwyKQWgiqIk38v+Bw7Hi7+zWQWKWtyUnXjBGYv5XK1WCYYFzAOY
lyQwDFKxNNHHpZK8vMU51KKdQPE75Izz7ad6YgYQ08CXJhNFgJpAmyehAd5g+I+K1fTSUyB/CIc7
29tjN24gYuhWKmz6BVmatmWNTU8jYnjx7beXtrbGpqfJciDsoFyTGw2wndC2LF88/mx93RePw3SR
tvrs0SNfPP7T0hLCgp+WlkYnJv507x5yHaKu/HV//9LWlhgtHXU6pC4D2ezY9PSLUunZ+vrF1VWp
en3N293ZuXDr1gA7FsifjE5MPFtfD+VycM+fLi1xj4mpJC9C6+zshJhQqS/ywhgyclwqydUbuHz5
+fb28+1tt1TShVu32nfusBmnD+Nxkqqnk8/lcrnb7bKZZaR9pOdrPGYVsALZK5AIjNA0TekRGBZB
kDubats2C99Wq9WAO+3z+T7//HOfz0eWA4DV+XyeQ24YkiAc5HbEeyzYqGWYnAxhd+PkFxsxiMm3
vpCKWQM5Pz8P0y7F2aYH+oVdQ9850B4AIOMroVAIGIi4bk96809PY8Ye9ysUCgDAQG6QpMca4CFD
IlEI3o9DXlxdfTI7+/21a3DlkDJCPoEUQSCbZZ1H0fWmhLVUf505fx4ZpH841OfP99y0fDI7i3RQ
27LsTAZbCJTTR5Tw5Msv8TnsMbi19nRpKZDNkmkhtX72/Pmz58//+vDh04cPOVvY2d4eWVjgXuEc
8JcPH1786iupNnzy5ZfsHgMXZ/y0tDR69eqlra1mJsN2bXhqW9YHExNk0jCI8PexqfM8HkcqqbOz
w1nKk2XsqNN5dXDwx9VVhZeA6OSDq1fZdNwZvx+/fxiP904lQSMjJIejR+E5q5o5IDY3TwoLCReV
uHVMikZH+pRNJZfLZfhikUgEIPsEw0IA5Wit0WjQVRM4AVir1djLKxYXF3GDEPrYbrdt20YyR1RP
nDdNokMUxSoLboNUbYrYURAT2YFAgBQfbdSTausXqVghfNp8Vj/QbyrJOL6ohy6oEfM8gAiG2KPR
aL95JISGkDmuDwHOdigUymQyBMHPipQgxmBr1Y4OOu5Wj+AFc5f78dLWliF4069xmM0GhjjEftbv
/+T+fWgKVjV8GI//wUXvtC2LNgkC2ezh48fP1tc5RTYSDnObClJqZjLs3jir/V/74p07Y9PTrIZS
WAXk6CkzzlE4lxM7Sy0/39kZuXwZfQnncs1MhlLqHPWbSnq5v/9sfZ2VCTafSVwXV1fbd+4gAvh4
YYHLI3lkzGMqqbOzwwUK/Kz75ptfX7fH4gCdM3rhr5Jfz56Ap+sN3PwmQwlQBVAdKYKjNJvE3bwh
Ng5oWdgMgIXh4kBSr9hyQJSAVBgpLMr24NJt1PPs7u7id2kqSVE9NZjzaLiAl7EfIued9pzZqzr7
RSo+DaJpwKG3sn0sFArcfXNsr1mI4CGJAyOTwhfGYrG1tTVcCpLL5Ya8l3GAEEq6H9Bz+9GtEMWN
nszOctuwrw4OPrh6VXozBqePLro4niJdmJmhrU6ULZ3x+y/JzN7oxASyZODq1cHBy/39V52OYRj+
W7cUeSTUaIVzOcUzolp8dXAwduPG383w61ZE7CPJH6GbohiJs1XqDBgrHImm9sAYtfB8Z6d9545i
DpAzcdTpdCsVlBuMMtGMYRijq6vPd3ZE8/DB1av4ilcQPRThABhHClgkbsOqN2bhx0lzVoOlp6DN
sR8uFqgAOYQA2aX1VMlkMpfLAUzJCwacm+fIedDcFQXqTAgHpcv9Arg6wvXFnay0A98vUjG8e6hv
aWwkgrEMvx+QSqXIJxh4S4mIZU8aXkhBsGk4UBEAOXjB6PfIkvdyVazzzvY2FdqPTkyMTU+zXjZb
Jyr+4mWP4dLW1qvXi5GavXoqflRkm6uepF8Om81mOj02PS11xlkVfMbvhzL6R47IZf8WVuFFqfSn
e/fUOxD+mRku4UaeOxmtZ+vr7HbIhZmZj5TJK/XewJPZ2Y8WFtTltl4qjk6WsbZlPd/eHr16FclD
1OyyGSpRjIePH//68KEBwyDCMLE5hGQyyeqXVqvV7XZZT5+9E0bMRylSAbg+l7e9MtBaLm8jMkk7
ez6fj7spgYXh6wl5bZrmkNhzXm5QURsSURezOSVspYo5eny0L6Ri7soO+joFPdLW3K6fpUpc9hd2
1AD9xu4JsSk4fI6NJLDP1Gq13NBVRbxuabmqAgRbHfyJtLm5yV50ge4obnPymIJ4urT08cICZSFQ
8M4V54iVrORRevHopSXtZ8+fP+p0vr92DfWyPRsRXVQxswGeUcvvxSKKcQx0+otSqW1ZXLbKY1bt
5/X1X17fw+c2G7BhS71GcPPz+vrF1dUfrl/nNurZfX6qFWYN3kg4/OmDB4ONPiclN8YCX3zBsiEm
uy7MzHDT4KjTaVtW6PXQ6snsLJuh6lYqYsbpw+NZd65nuoO7aJPbFma9fi6Hrt5lhQ0QtaToavWl
71gz9j6ereX2e7mr6oPBYL1ep8vLsBHyxsor+82DcePC8inyrIBrHuCAwmmQW47rDbBHu76itvJI
VN1PdOb8+W6lwhYd9UtckYy0KknlID9+/LHgDn8wMQF7OTZELvTCrVvc62d6bbl7zNH9ePOmOgw6
DfKSXeStvt8/Eg5jOCDhlw8fvnz4kJ1Fh48fXxASd7Qf0zuV5F0p9xUxIOcjGg8669T3NBXuKDdO
/2YCrgyGnHHWvPWF9KuOGACnTLeiBgIB73mqt0vBYPCt3KVx4iDYXshjuSrC+Yurq53tbUoHjU5M
BLJZLofjFjF41Syv1+qQ9jzqdD50TxaJH+U8U7eIwTtXYhIMZ5W7lYr3vQ2xWbFMc+TyZbJhf1xd
bd+5g2IwNmPTs2WgR/TVR4WbL4p0YMbcXIHn29tPl5ZQvzt69Sp33g2CEqUHQZ06uiqHZjHM3Qaa
NGnSpOkNkIbd1qRJkyZNr5GG3dakSZMmTYMaBm5nqa+NptMjQHa/rX3mdxk+Gie2OHrrXP3ecNHf
ynJg/9qXhKVzRgOkv3lSAGW/GTongtkSsbUQqLFlIVvZv4IUiNYcSDKR26YcbqzFEVlCYOXax6EK
eiUQCCSTSXWJDiFRqzdCi8UinZUDFDNeFDdIpPDRbg8T/yKKOKFlKKpdpc0qqubZ6k9Qt9tNJpOs
wMWTE8Sk4ziWZdm2TUOAgymtVkt6PMXtalyuVq1UKoVCIWKY/atYl4zTJJZlKWDDWRlGIhEpAjw9
wx098Y7yLfKG+jHuYe/A42yD7Al2g8GbUoOci9OjUChQVQJEx6Kye2FPWkzBHUIker6zI6IMUa2q
FCV75PJlrpz/sNn8aWmJQKJ88fgfV1fZM2VSvFI3KFaP2NTcKQ03VG0WDfvCzAzLCYuLfvj4sfet
cu5Ag8gezrUQ4tNZv99/6xZ3SIKDW+eAx0XAc/SRYHpFgYg/nuPAbDli8dxfHRygTm7k8mUWiMML
orVYdW64X0eO9YDlAaALUfcBJC6dThNKB1aa+tzs3t4e/q+o5CmXy3t7e/hioVC4e/euooII7hiO
zvZlkMXCJLcjAsMQd/y4L+gkKIiNjY1yuQxcLPXz6rICukyi2+1S5Zg4WCI6k5tYCLeDM2x9kXeU
b6qZdruqYQBiO1utVvs6FidSoVAIhUJokEWg6pcl7sihOmJQw7qJBxo4FxjqxRePo3gfyM8/3rz5
53KZsKDF07k4DOh2oKxfCFI1ERRVt1L5hcGUPSU66nR+Xl9nzx+83N+3MxkgLbKXcxiGgT9z5bPe
Ac97RAyiCWJt4Fm/P5zPHz5+/Hxn56jT+UM4PDY9/cHEBHuQcshDYSLZtk2qNhaL4dTVkMWOtm0X
i8V2u51MJqvVar1edzvbXK/XY7EYgZguLy9znqnjOPV6fW9vr9VqZTIZ0zSxJiORyPj4+JBHeXuS
m2M+TMbJLecD85lIJHZ3d72koarVaqPRgN9t23Y+nyfjl8lkgETSarUAZifqoMGGFeBLCDGlwZ8b
CNgAKN9Irdi2HQgE3FDZ1WhRp0d0Bt4wjMnJyd3dXenIqtnDAHHr4vQOyrz49tuRcJgAIc76/Ze2
tn68efPFt99C75/1+0Vn/Kk7pKjhDYL01cHBaV8bp1D9+L/i+Mgrhjf2z25H/MQDffT7wMdBznnp
yZPZ2UA2e8bvf9XpAMGKAgjUHasRrU+DotFou93m4Juk363Vavl8HkfzSNOVy2XkENLpdL/rFnZl
fHycEBRwrLdarbbb7dM+VSCmkhQPl8tl9viVeLBcoVhZHG+fz4fEVM8TAPQJUSvl8/lIJBKNRunQ
O9q/e/duIBCAe8Ed41DnBhuNRrVaDYVCxWIxlUqxkIhuiSyPIOoKrzwSiRSLRbo5SmywJ/B4v3sG
4hBLYwtc50c3W3AYl8Owd+J7DN9ducKpby8ZC1atE4rGABEDrrEc8gwdl7/i8l2Ks98Id7ouKvus
3//RwkIzkyGeD5vNi6urZEXYu/PEtBsnByngeX+G4YzfTyb0qNM5w1izl/v7gP/9u5EvlX6pVD6M
x8+cPx/O58+cP98XorUXfCGsPcJMrdVqHCQcIYwCjI8WBtRcKBRitQkHpkY5FjcOAUKHmw8KhYLP
5yPEVixUQgXnsrH4cRi94wXR2nvEMDc3J1oCVqFgZzIYDCI4kCpWVqH03MYECi9ZCFYxcQfdu90u
wUvQhZqUrmE3TtxSSbhaNZlMTk5O3r1717KsfiPXvlC+MbEhB6Q3ud2a04gY1BcXcpRKpfL5PMRl
27bbElOw12q13G4tFMOIYfI2lLseu3Hj5/X1J7OzF7/6ilJJh80mMO9gAw6bTRFL1e0rXpDmcCFS
Z2eHxQNHktwLZB5H/cLf4uvPd3bY/drvrlwhW4IjhzipDrvIHkLk7s6jWzFEg/rT0lIgm30yO9t1
iSfEzQ+WjXPsDlKbmTRty8JddB/G453t7WYm84dw+K/NJoYTqSQI0faAaC2dVQS/LK7YVCqVy+Xg
tGazWfZ1YDX3XPPD5OXpftBQKITb67x/HXckDPZptUmgfZqeW+jValXNJNDrSqUSDk5L7zEFjjck
2e12Q6GQwjCwxQWs6Zqfn0cEGQwGQ6HQ5uZmKBSCDCneMk2zX4khxKFoAGDd7FU8XlJJRj8o39id
wgV/dJeDaBj6Alil8IhqK0jFYxdd8a4Yl+NeKYxRKpWCSFkoMzV77MWr0hklQhKoEUNJ17DPB774
gnOQ/3Tv3k9LS3Tcd2x6WjQD3UrlzOu/nD1/nvO42Xss2NCE/frF1dWX+/tty/pzuQwVRwl6N5NA
GIW4KoMa/OT+/V8qFXVSC/rztXSfZeH3H65fx7VubHjBXljNnlQH4iHOJIt351F6jW4PPep07Exm
9OpV1mj1BBLnopxz7Oiin1xSD9jr6NIHV69+GI8jQ0d2zAuitdvyZi8H5ea9YtWlUilc/iWqTjEO
GAAlP5lMcjqClDKMFjIYrPlBsAKeT6MqVOwFqzi4XnB2sVarsYVA0MWoOJqbmwsGg1NTU/l8HlqP
dSRR0FIul93yEqJ8oETK5bIo1XQ6DThYWF8YHlymRBk/sXdSz9c0TbZ9FqybAwdU48l7R/nmQkwx
4hRhBNX5Hw5JHjivipyhF6rX68jRsfnDQCCA7ZOe7C0uLkpdCs66uGlhzmZcXF0Vq1rE+kvcUOTW
zpnz5y/MzEBdvvj22w8mJnCNhHjbsxdAIWzkIjr5aGHhx5s3z/r9Cn+fxSj84fp1TtH3tItixomQ
AS99882PN2+GX7d2BIILuGzaMoGZBNwTd3ceFVYRbwBh/GBiYuAkktc9Bgxn27LAGYdha3hDtHab
i+oHlpeXs9ks1BxXVyeidsOLFD/N4a16KVeForcsa2VlhTxf9i32thny/jjFzeV8OEvD5Y4hw2Fk
xa3kUChkWRb2xpFxZtd2q9Vqt9sUisGiI1PPaq5arYbU1kndvkk+KSmpbrcLIyHN+Bm9irWAQ066
zDRNpDRPaYPHzcAYAoyg240UfVFf5arIgnKeFvlPHtkTQ21stqu1sFveZvjb7dnNZ2ylqnUxW2Aq
+sKd7W3cIYqWL33zzZMvv/T3o9xF8liuetTpdLa3L21tIS4BRlbLsoKMWTrr95/1+4G8TW73k+1t
FsCcvTsPewzcV9p37vhnZtRIf2zogxtVRStyTgwxWMmSITpz/jw78IBcZ5OhiukreivcX6WaGnVy
8HbZ++Noxp8qqiVUP7ITlLdlmRQrvmlPT1qby/ZamjtmNSDdUy2ma7w7ku12G4l+LriRxkmisjNN
06M3LT2kwpo9Nu/x+eefs2LkXhS3oBR5dmxuxWIx4hOaFAZbDdWO+8bZzqpRvhWRxACzyzuSfF9U
q9WKxSJnG/rCkcR+vrjVcVLLirUoIsY192Tgiy/YWtVXBwcvSiX2F/GuAhGHnK1K4v5pdGJCUX4q
2hika+ivfW1IIGkmJuK4DYDDZhN3TlC/sM1w4dYtfEt9dx4u7FNzIjmfsLXFsvHjzZuBbPacd3vO
jmJfxV49MZmlaz6fz6fTaVTLoIB1b29vfHycLj0WI9yTKhWF1clms6hwRSDCncyKxWKTk5NsDvoE
M0gncheYcXyQFRIDez6f78QLat0MoYIl45TJC1S7oj7iXWBvMOKu6+iXWq1WLBbj3IhTgijuqcLo
8iKQWIk0MGC4F/J418XJErIyHWZrGgATHmHDhydCkD3nnV3u1icxzXdS5DjO119/nUwmkV7AjiVK
R+7evYsQGBkS0e2S3i43QPyOo3PZbHZ5eRnu2/j4OKWhgsGgGDGc0lJXeOJq7zIQCLBZe2LyLcJ0
S1niPFzp4VuuyJLNv+3u7pJMkDE71YGQsnd6mMHey1WN44pVMfnmfVFgYoujNsxZJTEnwV0v4Ubc
bZTvLPVVrtozsAjn88+3t0nZfhiPh/P5UzWBXICFXQ2NrqpJkyZNml4PBrQINGnSpEmTNgyaNGnS
pMmVzr0vjB51OixA09/N2vnzbyz79jvpC0oM3kHBSitYhsFHA0mPxb3j5DhOt9vlauROcGeFk4m0
WOBELmp1O+L6jkhY/P0EazdQdfkuXNguNwzc1tDF1VUcyfv14UPA6hGkH8GbiHVm4Vzu5f4+W89L
xV6AJwQcLmpmw7kcB9j7yf37L0qlw8ePP7h6lUPNJXoyO8shBb46OBi7cQNfZGvLsPMDKN32nTss
Pi1LbAEycGvR5TN+P/HAYdj+Y364I730lKdhGJ2dHfG2VeP1Oo2e8LxuWMEicdIenZhAxRsHPoxq
9H88dvXqxwsLbu0/mZ1FvQTKCi/MzLAMc6V+OO4kVrWLv7h16qjTaQpnKV4dHPzp3r2RcFhEeMYc
YIdYPNkLyJBSqUQAJyJQK1sizKIIG8fYqG6o2qzK5ppVnE5g95lRUgwwV+B2EJY42DBNM5lMRiIR
AG7T2XWqDicgcbdCZw643jCM6enpUChEMqF3OTPQarWkG+BuWOhScHi3g5Bidfvi4uLe3l69Xhf3
wLmHcaG32N9yucyiCnIIWtJRo2ZZOBCudoPDdVfIORAIQKQ445lIJBqNBodcIr7Ozi4UZ2Po6ToA
N3RhViwcqDu1r0Yn+nu5KqsjuBt4fqlUPnv0CAcX2pYVyGahnjjoc7a2rFupvPj220/u30cRrlha
QIcGjzqd769d86LdREXMKjuqLXtRKkkB3AcjLzhfHPWUpyHDV2GVMmta6M8DcCJK2ziG6hWpW6n8
vL5+aWsLPAP+1w2J5enS0uHjx4BKhtXh7pRnS/2amQxXaMidm6U+KiqnpQXa1AiVZrPA9KIPaBgG
C3BimqbUK1TQYMcL+iJCm5dWzWIxo8qoVquJOPPlcrnRaEDbqlHLjOOSa9u2S6USJMPCgrHEnj5x
u1vF6AcLHeBUYFjksKfiZkeEVBvKF6VCq9VqdK0LVTMqPkEn2wuFQrfbdbuRwntw0O12MQMHvvgI
99OsrKwAtqAnrDrJEIVq/VbAn/OoHEfC4Q89VJiRLfHPzIyEwyPh8Nj09Mv9/TMueYlupdJXRRqg
XhVa8uX+/smWuB02mz/evPnpgwf46/fXrsFLPZHGm5nMpa0tLmkj1Y8ekbB69qWzsyM9IPPXZvPM
+fMUPZz1+z+4etUNzvevzab/1i2wfWFmpn3njhtAAgJBztp5QS8YjF69JSxlNXGQscPkYVqtVjQa
RTYjGo2WSqV6vc5qQ8CU0YH2QqGgUH9AqSqXy8A05PC3xXORHokge4vFolj82mg0gFqfSCQikUip
VLIsa3x8HDXow6S/cJ2iWN0LIH0qd8b5J8Jzc+sCblsJhUK3b98uFoubm5u4C4CTiUffAgLh4g+Y
KDo4ghPmjUZDeqKwWq1S2XEmkxGvAzjhVBJF5S/391uWBQUkQsK+3N9/8e23rE45fPz419dPoLDr
k045nD1/njJREsXx7bcv9/ehNbwAj7w6OKCE0sjly6KC7uzshDw712wBsgKDlz3N5/FkX095kgxf
HRyc9fvPnj9/4dYtNs0FoQHLxQ3ORVTHIm4XaxWefPnlRwsLUvCvsRs3AJUIVl91Os+3t1mWWPpD
ONzZ3sblIc93dg6bTbjzHD/dSuXpX/6CW0co1yTt40cLC4rRl27J4MejTofdDjlsNt1uJsGKunv3
brfbxckJpE3egGHgbh9CKsmLDRB1HI7vsKn/8fFxVjfReUZowJ7OKSKMTCYDzErEQ4R9S/Khu5W8
WMFqtYr7/tLpNBxt6giuRYlGo3Nzc/V6HW4vXmERWTjow56nKBqNRqlUwtmjWCzGxTTASw4Gg3Qv
HovnJg0ukZpDpg5xCewZGCYD1hPNk+UB52HZk7BAJaDWAEpWLBY9Ig4MT+KhHMJEOIcFDIBySqxz
uXgs4AszM6wiflEqHXU6z3d2aElDz4or/OOFBSTuRS+4W6kgI6G4bOj5zg53Mp702uHjx91KhU7G
ty3rA+ZQDNSQAjYEuW+2y6INw+E+XKwBq9DzFKJCni/39zvM7sKrgwM2rf90acl/69arTqdtWXQP
35PZWWkM1JfT3bastmWR/sX/WTWNI/sk6pHLly99841b7HVxdfXJ7CwQMUfC4YurqyPhMLft9HRp
6cW3317a2hqdmOBunsLkEfvo9jlxe4mG5smXXwJ1EvPkqNPh4JSJCItpbW3t888/9/l8/eaR3KhQ
KGAPwC3LNFjEQHsM7I9TU1OWZVmWhWs74WUP3BHLshzHQZpobm4OZw8Ba0g6mjSF4zibm5vktEq7
ACz0VCqFc6mE1sUaNmx7dLvddrvdbrdbrVYgEACuPvaikR3idmIUKhibLrAKYEDMCxmv440rUPdB
BA5GSjwQCHBnJxEYGe6Y5OxQsiqYGmERzCzLAggNxle0hbFYjMxSLpfDltIw1z6qhXDOMIyWZX28
sNC2rMNmU/TB4bHC3wSyq3GMH/vxwkL7zh14jqyefba+/o/bHQ4OfOHwkczjA2J4z+oXTl+4nYx/
ub//bH2djWmw+dyXsDgbRtvsBAuMP6tPNirkiRSNui/dSmXsxg0YJ188PnbjBvJjBJhuuJToUKKG
5Q3bPCOXLysyYOyuDLH0cn8f+0ZSlX1pa8twgW98ub//482bF2Zm6IJGmkJkioC5T338YGJCkQP0
uL/SvnPnwszML5UKC6dMeQbaeWbvFj0RcED1xgNpE7e91r4IugNpE0oZ+Xy+WCyGMAjKgq7rUSdn
cA8SrqUjaTiOw16rzuUrWAeTAzMGiiVJA5Dm9XqdfHPHccTIg/2l32P5tm1vbm7GYjGSKpSduAvS
0xKwlMvlgAEsJToHXiwWcR9MPp9X+/jEFRvYmaZJ5mRzc9M0TTSLigYAAnGDVSgUlpeXjePN5557
ErCRKE8g12RxcbFnzJpKpc61LetVp4NkxZMvv3RDaBoJh/23bkHPdisVqODRiYlfKhUx6f9hPP5k
dvbCrVtHnc6LUuniV1+9+PZbMa3xIXP/j9owQGXg2lXkkUcuX/bPzJBRgdd5cXX1ZDcYSMNCqXmp
AlLLcyQchrcOtCw4wiOXL49NT1PLcLHHpqfhTcPvNgY9Zy9u23535QrGjiyHeK2u2ja7zRAEMaMT
E9Joht1aGAmH2T7+ur8fVM4EbIaLv1Ow+GR2FkicqFAauXyZjVyj0WgoFGLTI6g7ZJXgiVNf2ILe
yXEcGDnp7nQsFiuXy+hUqVSamppSNIVckyJNFAgEWNPCZdg5q6PAQucegAmBojRNkwDQoM7YfkFc
HDYwy78UjITAu6RghT2NOhS0ukgXW8EQL7aC1UMpve6Ces0JSpo6Q7Dl0ZVh9+RR2MZ2002er0UM
BBEeyGbhbXG+5OHjxx8vLAA29sN4/KjTaWYy4ePrqi9tbdmZDPcW/Fy4h+y9dP9IDnz5JYBnva+H
Z+vruA8PuxfdSuX5zZvhfB5JjCezs+o89TB7DN4J14Ao5Enfbd+5MzY9Dff88PHjH2/epIog3JeH
BBT2GKA9uUa8l6tyaS7jeM+fDAYuMOlWKt7vohIrRLkEl5g+Yh8Ym54+bDapjx8tLKjBc14dHDzf
2UE8x4YIgYMDIBUfPn6MvSVUEv+0tMQZs2AwCI1DVw+hUIQNxsWcD7fakTVinTh1AmEADCXKeLhl
J5Bs4fY/8/k8kHRjsZht2zBIXgD1TNMUr6IiPCvuNAPUnzpt0hPZHnfhUcYfe9TEqngVCsUu6p0S
tho1EolMTU1FIhEu+aNATfeix7vdLu4vwcYMbTbAx8fOiluDcE3YX0TYzZ5Q7Vx17JDUo1yV6m0o
ZmdrUcZu3LAzGWwOj01Pw0Fj/UGCk+U0oBqbUIEc6+YwYleZVvuFmRmU0gey2ZFwmO2F9PXvr13D
ZgaXInstLf664ywe12CT8ii44vYwRicm1PIEdba3cVc2K8bnOzukHPu9L9AjHTabqECF3mR18cv9
/efb2/1+VDyUoBBvzwd6EhtXGczVIFziyBePw+aJ1rRWq7mlZaXoe+zSlfpx9XqdciyFQkG0BF5q
N4m8GJJWq5XL5TjkwWAwSL/0BWYsPaYghVPF1mi5XB4gymH7hUxX+nXQ/nw+z+o78XSIIheEalS6
uAXufC6Xu337ds8yJ8dxlpeXUQMq3ZHiFLeUGQKoV5QJYXedG7WebnvPaSOdtOJBEM6h8XIhzbme
iYh+lfhp0Fm//4OJibZlXZiZQcTwolTy7uESZOBgeSQ3+vHmTfWFGAoF96JUGgmHR69eNQzj5cOH
ihKgkyLaf/bF47ii5MN4nDPe0gu2jHeGjoauRuWcaNY7HpJOG9X1Ncvn83FuvjEc5nw6nVa83mg0
dnd3kRoqFouWZcEfH+xb2CIul8uo0gGs/ZDlYShUHeDFer0eiUTezOnrIRHRvdMA1xz0bRjeHbq0
tdXZ2aFt7dGrV9kAomeGx/shDO9KCsDlA7wbyGbPoNBzfd0wjJHLl3F4uN92vJerNjOZV50OSQyH
n5/+5S/fX7uGLeKzMmR1xHYKg9rzItmTojPnz4+Ew+xFuPS790ZQHMJFDKd02QCnWL1DZ3uxCoas
flS8k9lja8FgULSO1Boql8js4V7bYrFIm6VSEjdX6LwVNk7p0DWuSBI1JufkKiIqvItyWwpBuHtq
3ci27fHx8TcwgT0ioou95mqdxTvMh5lLinJVDbutSZMmlTMu1bDvLMzRmxfFb5K0YdCkSZMmTa/H
4loEmjRp0qSJpbezx4DtexaW611GoH0zEuDAagwG+/dEII5/n8ThJ+P4wu9wvmnS1J9h4JBysfkg
FsxyVXdcDSwVSGGLCQ9Ho1EpjnGhUMDBwkAggLJoFoGWOxZEmyFsDTIHgEzEbdQoQHHdECLdTrHi
kAhbiSHFW240GuzJe5zkRFk3+2mpBMrlMhkGQMqwxy/Vh0I5WGPiluPHMAxwsri4ePfuXbZH6vEF
2pdt2yg0hEr1IgGW2HubRYRhGiyxBbwo/Rw7xNQmyzy3vQaYTA7xWBzcnvzggSGPMWvS9E5HDEOC
CQOGcHFxEWgqakesVCqFQiEsrXK5LILHsseC3MCH6RUsWulN8WqSHj5y02j9Elp2O3JZKBTUEsAz
UILY7IJeJkh37xSJRDY2Ntxg4kU9juKZSCTClWrk8/lIJDI3N1etVvP5vEIh4ousPPu9R55tASwN
UzjElpxXq1XvqGfcbOG6PAxGjSZNv51UkqJSGKi2cFej0agaocW27enjM8aTk5N0XpFDoOW0JJw+
znrhzGQymSwWi27VaScFlCY1G4Pd/NVut8lXZSUwjGE2js8N9fsup4WJWHts23a32wXPwCum4kuF
BKrVKgorFZeL9SzzQKeGyaRxd9GQA4GTboOVeGrS9Ps1DCiYJWccSXDpSnYch5auaZqE3CRtFvW8
BPIVDAbRICHQiqkknNfgHHAEE8gAhEKhzc1N8TT5YO6hG3FxiZfwQiwTVkiAy2hxWPaxWMxNhZF1
pDu8iD0ofTK9m5ub0hby+XytVjMMIxQKEdQwK0bWWgOmP5lMukkAqMXdbhexAvJ+qVSK7SaGhkVY
cxNgz1hWWtnNpi4jkQgFDXT0FLXzevNGkyZXw8CdqoBvyF6iBEiZaDRarVbZwFy6bpPJJK6Xkn4v
lUrl83k4uWyel3CdsOGhwAao1Wr5fD4ajdKtUpFI5PPPPy+VSoCAh67xCIqrBgwZMmKgPQYvEiCN
Cbaj0ShFElCpYtjkOA4QmDEoQGREZ1kzRiEFpModtoIEsEVRLpeBJTDwfNrc3MR5KJon2Wy2XC4D
P5LAwvb29sCSQoa1Wk2Uj0g0UVmXgp2ctm2zARBZ4iGtAhArxSyTJk2/BcMgndace44kz+Tk5Obm
5uTkJFYUYUMWi0XK2DiOEwgEFLmRUCgE3GCoSCxR9bYEl0qSwphgU5QFYPEOiusls0FS6gl01ZPc
JEBaTB3osEzu7u4SwD2UI64r4Z7f3d1NJpOsUXfLBKJwAAyQbo3FYqxLjsutoGrFgZCKmsOWwZ0n
gB6LRCJS29BoNDBwgx0posnJyRNYnvV6ffhYQZsETb+7VBLrphUKhVarBXUzNTV19+5dDqdlfHw8
l8vFYjHHcWq1WiqVcgsXSBPRda/sSnZ7nksliReOi8u1X1Bc0qEcypVxQohUXiQQCATI5Ig4+BAR
Z0E5HEpSvqzCglFPJBL1eh1JJ65Z3G+FNBRueQRCNQsK7fP5IMNqtdputxF5iCGUF5TjSCSSy+WQ
sMKwBoNBrl+4boWFRRvGDLdaLVy/rle7Jk19GIZWq1UqlVhtnkgkoEHgcJETiusmkAcggtOHKJ5L
JUtpfHyc07+2bXN6kE13cEVTrNaTYvwOAIortsyZpb5kSsy7WTupBFjzw+HgU15FVJRu5aFIJcHA
YPhSqdTdu3dF9zyRSBBQcygU4q7cAqXT6UKhgMyJAhHeC8rx8vJyMpnEY/g/V5cFsMy5uTmPVkG9
xwB7X6/X2U6JF7JzMmR3awzhlk3TNDMyyHFNmn5ThgHw6JTWB2A6vEvkPcRggqsi7Ut71mo1BQLt
YCj2isSFCIorBgHcX8UgQFrqLpJY5CMNbqQSYIsy4Ziz/9rtdqUpF2lZkRQfWJH66HkBiDgNBqaV
lRWFLTH6vGzL48RzHIdNKHHbTupsqlTCbLnq2tpav1ePadL0XqaSTpveGALtMNrkLUqg3W5PT09z
lkOf1B0mocRKW7wjZRjSOw2afpuGIZ1Ol0olNlimVNJpkEcE2neNxIzNYFczepFAIBAQL5DSbukJ
zrc3dneCJk3vI2l0VU2aNGnS9BppdFVNmjRp0qQNgyZNmjRp0oZBkyZNmjRpw6BJkyZNmrRh0KRJ
kyZN2jBo0qRJkyZtGDRp0qRJkzYMmjRp0qRJGwZNmjRp0qQNgyZNmjRpevv0/w8A+JHUmtyKrq8A
AAAASUVORK5CYIIA

--_004_E49C5DFFCF0C4D2BBB1B6BE9D37190FFjunipernet_--


From nobody Mon Sep 11 07:16:47 2017
Return-Path: 
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 958AA13309D for ; Mon, 11 Sep 2017 07:16:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.601
X-Spam-Level: 
X-Spam-Status: No, score=-12.601 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 ebUnm11G6Lcw for ; Mon, 11 Sep 2017 07:16:45 -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 2B8E113309C for ; Mon, 11 Sep 2017 07:16:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2242; q=dns/txt; s=iport; t=1505139405; x=1506349005; h=to:from:subject:message-id:date:mime-version; bh=BdDw0vIVZ7b7tMu5uDVwFlvTMwm3mlXAbxvuxeztwZs=; b=IYGRs3uwz37peSFWaOy+7YGOhd34/jmSA5C0xJ6UepZNQagxbK5cBMCG 5SJPE+EjYigBtBdUL/IlokaLc2mUWy2csrt5E2XJ+SVR9mSbfdBEPEMI+ S+eanQuvZFyv7jf1/9iRBAQckrXoLfrFVBxDAPvsSNJfRlWPd96H9VGeb U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C8BgCbmbZZ/xbLJq1cGwEBAQMBAQEJA?= =?us-ascii?q?QEBhS2EHosVkHWRFYVNggQKiiQUAQIBAQEBAQEBayiFQnUBPQJfDQgBAYotrCW?= =?us-ascii?q?CJyeLDwELASWDK4NSgg6HPINLgmEFoHSUUYtUhx2NV4dUgTk2IYENMiEIHBWHZ?= =?us-ascii?q?z6JdQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.42,378,1500940800";  d="scan'208,217";a="697104588"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Sep 2017 14:16:43 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v8BEGgH1007076 for ; Mon, 11 Sep 2017 14:16:43 GMT
To: NETMOD Working Group 
From: Benoit Claise 
Message-ID: 
Date: Mon, 11 Sep 2017 16:16:41 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------76B3CE8ABD6C047ECD13EFCC"
Content-Language: en-US
Archived-At: 
Subject: [netmod] draft-ietf-netmod-rfc6087bis as a BCP?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Sep 2017 14:16:46 -0000

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

Dear all,

I'm wondering if it's not time to classify draft-ietf-netmod-rfc6087bis 
as a BCP, as opposed to informational

This text would need to change:

        This document is similar to the Structure of Management
        Information
        version 2 (SMIv2) usage guidelines specification [RFC4181] in intent
        and structure.  However, since that document was written a decade
        after SMIv2 modules had been in use, it was published as a 'Best
        Current Practice' (BCP).  This document is not a BCP, but rather an
        informational reference, intended to promote consistency in documents
        containing YANG modules.

Indeed, it seems to me that the consistency in YANG modules is a pretty 
important topic.

Feedback?

Regards, Benoit


--------------76B3CE8ABD6C047ECD13EFCC
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    Dear all,

    

    I'm wondering if it's not time to classify
    draft-ietf-netmod-rfc6087bis as a BCP, as opposed to informational

    

    This text would need to change:

    

      
   This document is similar to the Structure of Management
   Information
   version 2 (SMIv2) usage guidelines specification [RFC4181] in intent
   and structure.  However, since that document was written a decade
   after SMIv2 modules had been in use, it was published as a 'Best
   Current Practice' (BCP).  This document is not a BCP, but rather an
   informational reference, intended to promote consistency in documents
   containing YANG modules.



    

    Indeed, it seems to me that the consistency in YANG modules is a
    pretty important topic.

    

    Feedback?

    

    Regards, Benoit

    

    
 

  


--------------76B3CE8ABD6C047ECD13EFCC--


From nobody Mon Sep 11 07:17:11 2017
Return-Path: 
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 226B8133091; Mon, 11 Sep 2017 07:17:10 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQH2i4V7Vciw; Mon, 11 Sep 2017 07:17:09 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3231B132335; Mon, 11 Sep 2017 07:17:09 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id D81A31AE0403; Mon, 11 Sep 2017 16:17:07 +0200 (CEST)
Date: Mon, 11 Sep 2017 16:15:35 +0200 (CEST)
Message-Id: <20170911.161535.635117848226182945.mbj@tail-f.com>
To: lberger@labn.net
Cc: netmod@ietf.org, netmod-chairs@ietf.org, draft-ietf-netmod-revised-datastores@ietf.org
From: Martin Bjorklund 
In-Reply-To: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net>
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net>
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: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Sep 2017 14:17:10 -0000

Hi,

As one of the authors of this document, I believe it is ready for
publication.


/martin

Lou Berger  wrote:
> All,
> 
> This starts a two week working group last call on
> draft-ietf-netmod-revised-datastores-04.
> 
> The working group last call ends on September 17.
> Please send your comments to the netmod mailing list.
> 
> Positive comments, e.g., "I've reviewed this document and
> believe it is ready for publication", are welcome!
> This is useful and important, even from authors.
> 
> Thank you,
> Netmod Chairs
> 


From nobody Mon Sep 11 07:40:59 2017
Return-Path: 
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 753C8132D8A for ; Mon, 11 Sep 2017 07:40:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCTWmjfad-3U for ; Mon, 11 Sep 2017 07:40:56 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02D59132D54 for ; Mon, 11 Sep 2017 07:40:55 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id C30F3F69; Mon, 11 Sep 2017 16:40:54 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id aiquNfouYZ4U; Mon, 11 Sep 2017 16:40:49 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 11 Sep 2017 16:40:54 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 820DE200E8; Mon, 11 Sep 2017 16:40:54 +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 s_TxZOTF6jgk; Mon, 11 Sep 2017 16:40:54 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4ACAA200E2; Mon, 11 Sep 2017 16:40:54 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 2E25C40EFC6A; Mon, 11 Sep 2017 16:40:54 +0200 (CEST)
Date: Mon, 11 Sep 2017 16:40:53 +0200
From: Juergen Schoenwaelder 
To: Lou Berger 
Cc: netmod WG 
Message-ID: <20170911144053.yl3v7ckqfpfzeui6@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Lou Berger , netmod WG 
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Sep 2017 14:40:57 -0000

I believe the document is ready for publication.

/js

On Fri, Sep 01, 2017 at 05:02:24PM -0400, Lou Berger wrote:
> All,
> 
> This starts a two week working group last call on
> draft-ietf-netmod-revised-datastores-04.
> 
> The working group last call ends on September 17.
> Please send your comments to the netmod mailing list.
> 
> Positive comments, e.g., "I've reviewed this document and
> believe it is ready for publication", are welcome!
> This is useful and important, even from authors.
> 
> Thank you,
> Netmod Chairs

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


From nobody Mon Sep 11 08:22:19 2017
Return-Path: 
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 132441330AE; Mon, 11 Sep 2017 08:22:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 ybbvg5DLtU8U; Mon, 11 Sep 2017 08:22: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 4493C1330CE; Mon, 11 Sep 2017 08:22:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15945; q=dns/txt; s=iport; t=1505143324; x=1506352924; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=xZU6XyBm4wT8sTKOGN32CAjH0xF4o8YtFpA4MgcNHBY=; b=HYT76g7uzMXRohVipsJWRdvpSxnE5eG59U4rBmCI145nVQH+9pjHChuw +ymUT78EzCGaTsS9HR3ou3pOLBR9aS2a1NiT+OPiUH8RPzP9qkZjwesha UbLJvu/ZmJcpUnrIAPz0DaQG5v6DC8ahLOLuwg93F2iRZjCVlyhu0p6Wt A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AiBQDRqLZZ/xbLJq1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBhS2EHosVkHYrkGqHUQqFPgKEZBQBAgEBAQEBAQFrKIUZAQUjSwQXCQI?= =?us-ascii?q?OCioCAlcGAQwIAQGKLY5HnWaCJyeKbwEBAQEBAQEBAgEBAQEBAQEBAQEBHYMrg?= =?us-ascii?q?1KCDguCcogKgmEFoHSUUYIThWeDWiSGeY1Xh1SBOTYhgQ0yIQgcFUqFGByBaD+?= =?us-ascii?q?HNiuCFAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.42,378,1500940800";  d="scan'208,217";a="655560569"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Sep 2017 15:22:02 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8BFM1ZK013527; Mon, 11 Sep 2017 15:22:01 GMT
To: Lou Berger , netmod WG , "netmod-chairs@ietf.org" , draft-ietf-netmod-revised-datastores@ietf.org
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net>
From: Robert Wilton 
Message-ID: <10476e00-0169-4258-449f-22cc7ca978a8@cisco.com>
Date: Mon, 11 Sep 2017 16:22:01 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net>
Content-Type: multipart/alternative; boundary="------------44A82F8743FBA67D4478B43D"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Sep 2017 15:22:18 -0000

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

As one of the authors, I would like to see a few minor editorial 
updates, described below.  Otherwise I believe that the document is 
ready for publication.

Proposed changes:

1. I think that the document could further emphasis that the schema for 
all the conventional datastores must be the same.

*Old:*

4.5.  Conventional Configuration Datastores

    The conventional configuration datastores are a set of configuration
    datastores that share a common schema, allowing data to be copied
    between them.  The term is meant as a generic umbrella description of
    these datastores.  The set of datastores include:

*New:*

4.5.  Conventional Configuration Datastores

    The conventional configuration datastores are a set of configuration
    datastores that all share exactly the same schema, allowing data to 
be copied
    between them.  The term is meant as a generic umbrella description of
    these datastores.  The set of datastores include:


2. I think that the description of the intended datastore could be 
expanded to give a bit more clarity.

*OLD:*

4.4.  The Intended Configuration Datastore ()

    The intended configuration datastore () is a read-only
    configuration datastore.  It is tightly coupled to .  When
    data is written to , the data that is to be validated is
    also conceptually written to . Validation is performed on
    the contents of .

    For simple implementations,  and  are identical.

     does not persist across reboots; its relationship with
     makes that unnecessary.

    ...

*NEW:*

4.4.  The Intended Configuration Datastore ()

    The intended configuration datastore () is a read-only
    configuration datastore.  It represents the configuration after all
    configuration transformations to  are performed (e.g.
    template expansion, inactive configuration removal), and is the
    configuration that the system attempts to apply.

    It is tightly coupled to .  When data is written to
    , the data that is to be validated is also conceptually
    written to .  Validation is performed on the contents of
    .

    For simple implementations,  and  are identical.

    The contents of  is also related to the 'config true'
    subset of , and hence a client can determine to what
    extent the intended configuration is currently applied by checking
    whether the contents of  also appears in .

     does not persist across reboots; its relationship with
     makes that unnecessary.

    ...


3. I think that it may aid readability if the section on conventional 
configuration datastores was moved above the description of the 
individual conventional configuration datastores, which could then be 
intended one level.  Best illustrated via the change to the table of 
contents.

*E.g. current TOC: *

    4.  Architectural Model of Datastores . . . . . . . . . . . . . .   8
      4.1.  The Startup Configuration Datastore () . . . . .   9
      4.2.  The Candidate Configuration Datastore () . . .  10
      4.3.  The Running Configuration Datastore () . . . . .  10
      4.4.  The Intended Configuration Datastore () . . . .  10
      4.5.  Conventional Configuration Datastores . . . . . . . . . .  11
      4.6.  Dynamic Configuration Datastores  . . . . . . . . . . . .  11
      4.7.  The Operational State Datastore () . . . . .  11
        4.7.1.  Remnant Configuration . . . . . . . . . . . . . . . .  12
        4.7.2.  Missing Resources . . . . . . . . . . . . . . . . . .  13
        4.7.3.  System-controlled Resources . . . . . . . . . . . . .  13
        4.7.4.  Origin Metadata Annotation  . . . . . . . . . . . . .  13

*Proposed TOC: *

    4.  Architectural Model of Datastores . . . . . . . . . . . . . .   8
      4.1.  Conventional Configuration Datastores . . . . . . . . . .   9
        4.1.1.  The Startup Configuration Datastore () . . .  10
        4.1.2.  The Candidate Configuration Datastore () .  10
        4.1.3.  The Running Configuration Datastore () . . .  10
        4.1.4.  The Intended Configuration Datastore () . .  11
      4.2.  Dynamic Configuration Datastores  . . . . . . . . . . . .  12
      4.3.  The Operational State Datastore () . . . . .  12
        4.3.1.  Remnant Configuration . . . . . . . . . . . . . . . .  13
        4.3.2.  Missing Resources . . . . . . . . . . . . . . . . . .  13
        4.3.3.  System-controlled Resources . . . . . . . . . . . . .  14
        4.3.4.  Origin Metadata Annotation  . . . . . . . . . . . . .  14

4. Finally, I noticed one reference that could be improved, by changing 
it from "(described below)" to a proper section reference:

647,648c644,645
<    circumstances, e.g., an abnormal value is 'in use', or due to remnant
<    configuration (described below).  Note, that deviations are still
---
 >    circumstances, e.g., an abnormal value is "in use", or due to remnant
 >    configuration (see Section 4.7.1).  Note, that deviations are still

Thanks,
Rob



On 01/09/2017 22:02, Lou Berger wrote:
> All,
>
> This starts a two week working group last call on
> draft-ietf-netmod-revised-datastores-04.
>
> The working group last call ends on September 17.
> Please send your comments to the netmod mailing list.
>
> Positive comments, e.g., "I've reviewed this document and
> believe it is ready for publication", are welcome!
> This is useful and important, even from authors.
>
> Thank you,
> Netmod Chairs
> .
>


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


  
    
  
  
    
As one of the authors, I would like to see a few minor editorial
      updates, described below.  Otherwise I believe that the document
      is ready for publication.

    
Proposed changes:

    
1. I think that the document could further emphasis that the
      schema for all the conventional datastores must be the same.

    
Old:

    

    
4.5.  Conventional Configuration Datastores

       

         The conventional configuration datastores are a set of
        configuration

         datastores that share a common schema, allowing data
        to be copied

         between them.  The term is meant as a generic umbrella
        description of

         these datastores.  The set of datastores include:

      

      New:

      

      4.5.  Conventional Configuration Datastores

    
    The conventional configuration
        datastores are a set of configuration

           datastores that all share exactly the same schema, allowing
        data to be copied

           between them.  The term is meant as a generic umbrella
        description of

           these datastores.  The set of datastores include:

      

    


    

    
2. I think that the description of the intended datastore could
      be expanded to give a bit more clarity.

    
OLD:

    
4.4.  The Intended Configuration Datastore (<intended>)

      

    
   The intended configuration datastore (<intended>) is
        a read-only

         configuration datastore.  It is tightly coupled to
        <running>.  When

         data is written to <running>, the data that is
        to be validated is

         also conceptually written to <intended>. 
        Validation is performed on

         the contents of <intended>.

      

         For simple implementations, <running> and
        <intended> are identical.

      

         <intended> does not persist across reboots; its
        relationship with

         <running> makes that unnecessary.  

      

         ...

    

    
NEW:

    
4.4.  The Intended Configuration Datastore (<intended>)

      

         The intended configuration datastore
        (<intended>) is a read-only

         configuration datastore.  It represents the
        configuration after all

         configuration transformations to <running> are
        performed (e.g.

         template expansion, inactive configuration removal),
        and is the

         configuration that the system attempts to apply.

      

         It is tightly coupled to <running>.  When data
        is written to

         <running>, the data that is to be validated is
        also conceptually

         written to <intended>.  Validation is performed
        on the contents of

         <intended>.

      

         For simple implementations, <running> and
        <intended> are identical.

      

         The contents of <intended> is also related to
        the 'config true'

         subset of <operational>, and hence a client can
        determine to what

         extent the intended configuration is currently applied
        by checking

         whether the contents of <intended> also appears
        in <operational>.

      

         <intended> does not persist across reboots; its
        relationship with

         <running> makes that unnecessary.

    
   ...

    

    

    3. I think that it may aid readability if the section on
    conventional configuration datastores was moved above the
    description of the individual conventional configuration datastores,
    which could then be intended one level.  Best illustrated via the
    change to the table of contents.

    

    E.g. current TOC:
    

    

       4.  Architectural Model of Datastores . . . . . . . . . . . .
      . .   8
    

         4.1.  The Startup Configuration Datastore
      (<startup>) . . . . .   9
    

         4.2.  The Candidate Configuration Datastore
      (<candidate>) . . .  10
    

         4.3.  The Running Configuration Datastore
      (<running>) . . . . .  10
    

         4.4.  The Intended Configuration Datastore
      (<intended>) . . . .  10
    

         4.5.  Conventional Configuration Datastores . . . . .
      . . . . .  11
    

         4.6.  Dynamic Configuration Datastores  . . . . . . .
      . . . . .  11
    

         4.7.  The Operational State Datastore
      (<operational>) . . . . .  11
    

           4.7.1.  Remnant Configuration . . . . . . . . . . .
      . . . . .  12
    

           4.7.2.  Missing Resources . . . . . . . . . . . . .
      . . . . .  13
    

           4.7.3.  System-controlled Resources . . . . . . . .
      . . . . .  13
    

           4.7.4.  Origin Metadata Annotation  . . . . . . . .
      . . . . .  13
    

    

    Proposed TOC:
    

    

       4.  Architectural Model of Datastores . . . . . . . . . . . .
      . .   8
    

         4.1.  Conventional Configuration Datastores . . . . .
      . . . . .   9
    

           4.1.1.  The Startup Configuration Datastore
      (<startup>) . . .  10
    

           4.1.2.  The Candidate Configuration Datastore
      (<candidate>) .  10
    

           4.1.3.  The Running Configuration Datastore
      (<running>) . . .  10
    

           4.1.4.  The Intended Configuration Datastore
      (<intended>) . .  11
    

         4.2.  Dynamic Configuration Datastores  . . . . . . .
      . . . . .  12
    

         4.3.  The Operational State Datastore
      (<operational>) . . . . .  12
    

           4.3.1.  Remnant Configuration . . . . . . . . . . .
      . . . . .  13
    

           4.3.2.  Missing Resources . . . . . . . . . . . . .
      . . . . .  13
    

           4.3.3.  System-controlled Resources . . . . . . . .
      . . . . .  14
    

           4.3.4.  Origin Metadata Annotation  . . . . . . . .
      . . . . .  14
    

    

    4. Finally, I noticed one reference that could be improved, by
    changing it from "(described below)" to a proper section reference:

    

    647,648c644,645

    <    circumstances, e.g., an abnormal value is 'in use', or due
    to remnant

    <    configuration (described below).  Note, that deviations are
    still

    ---

    >    circumstances, e.g., an abnormal value is "in use", or due
    to remnant

    >    configuration (see Section 4.7.1).  Note, that deviations
    are still

    

    Thanks,

    Rob

    

    

    

    
On 01/09/2017 22:02, Lou Berger wrote:

    

    

      
All,

This starts a two week working group last call on
draft-ietf-netmod-revised-datastores-04.

The working group last call ends on September 17.
Please send your comments to the netmod mailing list.

Positive comments, e.g., "I've reviewed this document and
believe it is ready for publication", are welcome!
This is useful and important, even from authors.

Thank you,
Netmod Chairs
.



    

    

  


--------------44A82F8743FBA67D4478B43D--


From nobody Mon Sep 11 10:12:51 2017
Return-Path: 
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 CB90F132D97 for ; Mon, 11 Sep 2017 10:12:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.799
X-Spam-Level: 
X-Spam-Status: No, score=-4.799 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 mcVLkE8b7B1S for ; Mon, 11 Sep 2017 10:12:46 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0112.outbound.protection.outlook.com [104.47.36.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B70B13316A for ; Mon, 11 Sep 2017 10:12:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=AnoorilZOTVv7A3VxOvJzDnyr27K5MhisQQO/y3LORI=; b=b9iXx0E0slFTTaP1Y/4RQETjdfH8QS+Dq6YAe0rR0rQhqry6PtnsXiQWIaCCMrbHhY+1LnG047VuR4IzOakgUzCySJGR2Fcz9ijdUJi7/y+iQgPOstD0VnAYCKUhWGnRRBV/f//H/ZUbUJxyKHqi3zsUY8MIg22V2vVdrLzB5uQ=
Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB644.namprd05.prod.outlook.com (10.141.205.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Mon, 11 Sep 2017 17:12:43 +0000
Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0035.010; Mon, 11 Sep 2017 17:12:43 +0000
From: Kent Watsen 
To: Robert Wilton , Lou Berger , "netmod WG" 
Thread-Topic: WG Last Call: draft-ietf-netmod-revised-datastores-04
Thread-Index: AQHTI2WiK2FD9vRWGUCWyOwPy47k86Kv3KKA///b3oA=
Date: Mon, 11 Sep 2017 17:12:42 +0000
Message-ID: 
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <10476e00-0169-4258-449f-22cc7ca978a8@cisco.com>
In-Reply-To: <10476e00-0169-4258-449f-22cc7ca978a8@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB644; 6:tbG2u3hbdd1HzHJ2BJUAAJWtRZ5/9cdQ4km5sbc4bDy7h/NwuC3reKozqloEVVF9Wuwnen7uLrXiINS3fp+aY11d7YTnAiEDqfCmawmkT43Qr/HO2Ri1c5rQ/W3BXp78gD+vQIORwhMLar8r8BWmqZ3pal8Blx6XlnKJl4+ddESL5V5aVo8xf9wwmDCj+dOs2Pk6pVhs0ruRryve7KL1/OK96j2a/TUIBb0q8BfshZLhPYGmZAeZ0Qdx7GVN/zGwZn//NI5IQlKF0AmluosKhzBCAHuPcSeTRiQI8/m8oiDPscgVYbWAMykwj6ZnSBAjJTh8KYqZV/+7EqffjTav+g==; 5:8Q66i3r31d7BG7q8YQFq0wC4auvGimlZBXDwK+5HVD6dLIq8v36YtfTs7i1wskaPLB9BxUtMu0U7xr+K7bwPKNm8qPqIt3yeHx+CR8684c1PMkiPI+UdZ8mIctTwiHhdJO/LcDIyIB2pOBfVxx3QRw==; 24:ZBW4U2n+msYxCam0H/MhJKKlwqIJHJDGNUeNjD72UnEZCj5Ko6Wf0D1WOp7TwN8FnAtjawrfyjuRWVlZSMwfn2soRoKURIxOkyehxADE7Cg=; 7:OuEs1/shzxwTWL2YxSrwfzpaO/wYrgJecpm+VhdOtGdwvXwOvrERdo4ju6MfE6ZJe9UuF0o8ui2Z0J87svnDHguNcLn2jqAPLj0E1HGx4ctL5AYRw257PmOHyvS2Ty7GVa1sZpptpZmJAAiYFndN0+5XaRwEAWTNgLEkn22ebsLbj8eOurAbTKO0nnWCn8epL3jS5R+Hh4/AE8nP5MsOFVEwsUS30tmW5rGh8gbzGgA=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 3b9d030f-22e9-404c-0956-08d4f938508b
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR05MB644; 
x-ms-traffictypediagnostic: BLUPR05MB644:
x-exchange-antispam-report-test: UriScan:(95692535739014)(21748063052155);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB644; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB644; 
x-forefront-prvs: 04270EF89C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(199003)(377454003)(15374003)(24454002)(189002)(51444003)(105586002)(230783001)(6436002)(3660700001)(83506001)(6506006)(53936002)(86362001)(478600001)(8676002)(3280700002)(14454004)(6486002)(2906002)(83716003)(229853002)(53546010)(66066001)(6116002)(36756003)(102836003)(236005)(7736002)(2900100001)(5660300001)(8936002)(81156014)(82746002)(76176999)(4001350100001)(3846002)(68736007)(25786009)(106356001)(81166006)(2950100002)(33656002)(50986999)(54356999)(6246003)(99286003)(77096006)(189998001)(54896002)(101416001)(6306002)(6512007)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB644; H:BLUPR05MB275.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_E1A72908D7D64FDFBF778E6B0D2CFB4Bjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2017 17:12:43.0075 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB644
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Sep 2017 17:12:49 -0000

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

QXMgYW4gYXV0aG9yLCBJIGJlbGlldmUgdGhlIGRyYWZ0IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlv
bi4NCg0KUmVnYXJkaW5nIFJvYmVydCdzIGVkaXRvcmlhbCBzdWdnZXN0aW9uczoNCg0KMSkgaG93
IG1vdmluZyAiYWxsIiBsaWtlIHRoaXM/ICAoaS5lLiwgbXVzdCBoYXZlIHNhbWUgbW9kdWxlcywg
ZGV2aWF0aW9ucywgZXRjLikNCi0gICBkYXRhc3RvcmVzIHRoYXQgYWxsIHNoYXJlIGV4YWN0bHkg
dGhlIHNhbWUgc2NoZW1hLCBhbGxvd2luZyBkYXRhIHRvIGJlIGNvcGllZA0KKyAgZGF0YXN0b3Jl
cyB0aGF0IHNoYXJlIGV4YWN0bHkgdGhlIHNhbWUgc2NoZW1hLCBhbGxvd2luZyBhbGwgZGF0YSB0
byBiZSBjb3BpZWQNCg0KMikgYmV0dGVyLCBidXQgSSB0aGluayB3ZSBzaG91bGQgZXhwYW5kICJJ
dCIgaW4gdGhlIGJlZ2lubmluZyBvZiB0aGUgMm5kIHBhcmFncmFwaA0KdG8gIlRoZSBpbnRlbmRl
ZCBjb25maWd1cmF0aW9uIGRhdGFzdG9yZSIuICBBbHNvLCBob3cgYWJvdXQgdGhpcyBmb3IgdGhl
IDNyZA0KcGFyYWdyYXBoIGluc3RlYWQ/ICAoZml4ZXMgYSBjb3VwbGUgIHBsdXJhbGl0eSBpc3N1
ZXMgYW5kIG9uZSB0cmFuc2l0aW9uIGlzc3VlKToNCg0KICAgVGhlIGNvbnRlbnRzIG9mIDxpbnRl
bmRlZD4gYXJlIHJlbGF0ZWQgdG8gdGhlICdjb25maWcgdHJ1ZScNCiAgIHN1YnNldCBvZiA8b3Bl
cmF0aW9uYWw+LCBzdWNoIHRoYXQgYSBjbGllbnQgY2FuIGRldGVybWluZSB0byB3aGF0DQogICBl
eHRlbnQgdGhlIGludGVuZGVkIGNvbmZpZ3VyYXRpb24gaXMgY3VycmVudGx5IGFwcGxpZWQgYnkg
Y2hlY2tpbmcNCiAgIHdoZXRoZXIgdGhlIGNvbnRlbnRzIG9mIDxpbnRlbmRlZD4gYWxzbyBhcHBl
YXIgaW4gPG9wZXJhdGlvbmFsPi4NCg0KMykgSSdtIG9rYXkgd2l0aCB0aGlzLg0KDQo0KSBUaGlz
IGlzIGJldHRlci4NCg0KDQpUaGFua3MsDQpLZW50DQoNCg0KDQpPbiA5LzExLzE3LCAxMToyMiBB
TSwgIlJvYmVydCBXaWx0b24iIDxyd2lsdG9uQGNpc2NvLmNvbTxtYWlsdG86cndpbHRvbkBjaXNj
by5jb20+PiB3cm90ZToNCg0KDQpBcyBvbmUgb2YgdGhlIGF1dGhvcnMsIEkgd291bGQgbGlrZSB0
byBzZWUgYSBmZXcgbWlub3IgZWRpdG9yaWFsIHVwZGF0ZXMsIGRlc2NyaWJlZCBiZWxvdy4gIE90
aGVyd2lzZSBJIGJlbGlldmUgdGhhdCB0aGUgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0
aW9uLg0KDQpQcm9wb3NlZCBjaGFuZ2VzOg0KDQoxLiBJIHRoaW5rIHRoYXQgdGhlIGRvY3VtZW50
IGNvdWxkIGZ1cnRoZXIgZW1waGFzaXMgdGhhdCB0aGUgc2NoZW1hIGZvciBhbGwgdGhlIGNvbnZl
bnRpb25hbCBkYXRhc3RvcmVzIG11c3QgYmUgdGhlIHNhbWUuDQoNCk9sZDoNCg0KNC41LiAgQ29u
dmVudGlvbmFsIENvbmZpZ3VyYXRpb24gRGF0YXN0b3Jlcw0KDQogICBUaGUgY29udmVudGlvbmFs
IGNvbmZpZ3VyYXRpb24gZGF0YXN0b3JlcyBhcmUgYSBzZXQgb2YgY29uZmlndXJhdGlvbg0KICAg
ZGF0YXN0b3JlcyB0aGF0IHNoYXJlIGEgY29tbW9uIHNjaGVtYSwgYWxsb3dpbmcgZGF0YSB0byBi
ZSBjb3BpZWQNCiAgIGJldHdlZW4gdGhlbS4gIFRoZSB0ZXJtIGlzIG1lYW50IGFzIGEgZ2VuZXJp
YyB1bWJyZWxsYSBkZXNjcmlwdGlvbiBvZg0KICAgdGhlc2UgZGF0YXN0b3Jlcy4gIFRoZSBzZXQg
b2YgZGF0YXN0b3JlcyBpbmNsdWRlOg0KDQpOZXc6DQoNCjQuNS4gIENvbnZlbnRpb25hbCBDb25m
aWd1cmF0aW9uIERhdGFzdG9yZXMNCg0KICAgVGhlIGNvbnZlbnRpb25hbCBjb25maWd1cmF0aW9u
IGRhdGFzdG9yZXMgYXJlIGEgc2V0IG9mIGNvbmZpZ3VyYXRpb24NCiAgIGRhdGFzdG9yZXMgdGhh
dCBhbGwgc2hhcmUgZXhhY3RseSB0aGUgc2FtZSBzY2hlbWEsIGFsbG93aW5nIGRhdGEgdG8gYmUg
Y29waWVkDQogICBiZXR3ZWVuIHRoZW0uICBUaGUgdGVybSBpcyBtZWFudCBhcyBhIGdlbmVyaWMg
dW1icmVsbGEgZGVzY3JpcHRpb24gb2YNCiAgIHRoZXNlIGRhdGFzdG9yZXMuICBUaGUgc2V0IG9m
IGRhdGFzdG9yZXMgaW5jbHVkZToNCg0KDQoNCjIuIEkgdGhpbmsgdGhhdCB0aGUgZGVzY3JpcHRp
b24gb2YgdGhlIGludGVuZGVkIGRhdGFzdG9yZSBjb3VsZCBiZSBleHBhbmRlZCB0byBnaXZlIGEg
Yml0IG1vcmUgY2xhcml0eS4NCg0KT0xEOg0KDQo0LjQuICBUaGUgSW50ZW5kZWQgQ29uZmlndXJh
dGlvbiBEYXRhc3RvcmUgKDxpbnRlbmRlZD4pDQoNCiAgIFRoZSBpbnRlbmRlZCBjb25maWd1cmF0
aW9uIGRhdGFzdG9yZSAoPGludGVuZGVkPikgaXMgYSByZWFkLW9ubHkNCiAgIGNvbmZpZ3VyYXRp
b24gZGF0YXN0b3JlLiAgSXQgaXMgdGlnaHRseSBjb3VwbGVkIHRvIDxydW5uaW5nPi4gIFdoZW4N
CiAgIGRhdGEgaXMgd3JpdHRlbiB0byA8cnVubmluZz4sIHRoZSBkYXRhIHRoYXQgaXMgdG8gYmUg
dmFsaWRhdGVkIGlzDQogICBhbHNvIGNvbmNlcHR1YWxseSB3cml0dGVuIHRvIDxpbnRlbmRlZD4u
ICBWYWxpZGF0aW9uIGlzIHBlcmZvcm1lZCBvbg0KICAgdGhlIGNvbnRlbnRzIG9mIDxpbnRlbmRl
ZD4uDQoNCiAgIEZvciBzaW1wbGUgaW1wbGVtZW50YXRpb25zLCA8cnVubmluZz4gYW5kIDxpbnRl
bmRlZD4gYXJlIGlkZW50aWNhbC4NCg0KICAgPGludGVuZGVkPiBkb2VzIG5vdCBwZXJzaXN0IGFj
cm9zcyByZWJvb3RzOyBpdHMgcmVsYXRpb25zaGlwIHdpdGgNCiAgIDxydW5uaW5nPiBtYWtlcyB0
aGF0IHVubmVjZXNzYXJ5Lg0KDQogICAuLi4NCg0KTkVXOg0KDQo0LjQuICBUaGUgSW50ZW5kZWQg
Q29uZmlndXJhdGlvbiBEYXRhc3RvcmUgKDxpbnRlbmRlZD4pDQoNCiAgIFRoZSBpbnRlbmRlZCBj
b25maWd1cmF0aW9uIGRhdGFzdG9yZSAoPGludGVuZGVkPikgaXMgYSByZWFkLW9ubHkNCiAgIGNv
bmZpZ3VyYXRpb24gZGF0YXN0b3JlLiAgSXQgcmVwcmVzZW50cyB0aGUgY29uZmlndXJhdGlvbiBh
ZnRlciBhbGwNCiAgIGNvbmZpZ3VyYXRpb24gdHJhbnNmb3JtYXRpb25zIHRvIDxydW5uaW5nPiBh
cmUgcGVyZm9ybWVkIChlLmcuDQogICB0ZW1wbGF0ZSBleHBhbnNpb24sIGluYWN0aXZlIGNvbmZp
Z3VyYXRpb24gcmVtb3ZhbCksIGFuZCBpcyB0aGUNCiAgIGNvbmZpZ3VyYXRpb24gdGhhdCB0aGUg
c3lzdGVtIGF0dGVtcHRzIHRvIGFwcGx5Lg0KDQogICBJdCBpcyB0aWdodGx5IGNvdXBsZWQgdG8g
PHJ1bm5pbmc+LiAgV2hlbiBkYXRhIGlzIHdyaXR0ZW4gdG8NCiAgIDxydW5uaW5nPiwgdGhlIGRh
dGEgdGhhdCBpcyB0byBiZSB2YWxpZGF0ZWQgaXMgYWxzbyBjb25jZXB0dWFsbHkNCiAgIHdyaXR0
ZW4gdG8gPGludGVuZGVkPi4gIFZhbGlkYXRpb24gaXMgcGVyZm9ybWVkIG9uIHRoZSBjb250ZW50
cyBvZg0KICAgPGludGVuZGVkPi4NCg0KICAgRm9yIHNpbXBsZSBpbXBsZW1lbnRhdGlvbnMsIDxy
dW5uaW5nPiBhbmQgPGludGVuZGVkPiBhcmUgaWRlbnRpY2FsLg0KDQogICBUaGUgY29udGVudHMg
b2YgPGludGVuZGVkPiBpcyBhbHNvIHJlbGF0ZWQgdG8gdGhlICdjb25maWcgdHJ1ZScNCiAgIHN1
YnNldCBvZiA8b3BlcmF0aW9uYWw+LCBhbmQgaGVuY2UgYSBjbGllbnQgY2FuIGRldGVybWluZSB0
byB3aGF0DQogICBleHRlbnQgdGhlIGludGVuZGVkIGNvbmZpZ3VyYXRpb24gaXMgY3VycmVudGx5
IGFwcGxpZWQgYnkgY2hlY2tpbmcNCiAgIHdoZXRoZXIgdGhlIGNvbnRlbnRzIG9mIDxpbnRlbmRl
ZD4gYWxzbyBhcHBlYXJzIGluIDxvcGVyYXRpb25hbD4uDQoNCiAgIDxpbnRlbmRlZD4gZG9lcyBu
b3QgcGVyc2lzdCBhY3Jvc3MgcmVib290czsgaXRzIHJlbGF0aW9uc2hpcCB3aXRoDQogICA8cnVu
bmluZz4gbWFrZXMgdGhhdCB1bm5lY2Vzc2FyeS4NCg0KICAgLi4uDQoNCjMuIEkgdGhpbmsgdGhh
dCBpdCBtYXkgYWlkIHJlYWRhYmlsaXR5IGlmIHRoZSBzZWN0aW9uIG9uIGNvbnZlbnRpb25hbCBj
b25maWd1cmF0aW9uIGRhdGFzdG9yZXMgd2FzIG1vdmVkIGFib3ZlIHRoZSBkZXNjcmlwdGlvbiBv
ZiB0aGUgaW5kaXZpZHVhbCBjb252ZW50aW9uYWwgY29uZmlndXJhdGlvbiBkYXRhc3RvcmVzLCB3
aGljaCBjb3VsZCB0aGVuIGJlIGludGVuZGVkIG9uZSBsZXZlbC4gIEJlc3QgaWxsdXN0cmF0ZWQg
dmlhIHRoZSBjaGFuZ2UgdG8gdGhlIHRhYmxlIG9mIGNvbnRlbnRzLg0KDQpFLmcuIGN1cnJlbnQg
VE9DOg0KDQogICA0LiAgQXJjaGl0ZWN0dXJhbCBNb2RlbCBvZiBEYXRhc3RvcmVzIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAgIDgNCiAgICAgNC4xLiAgVGhlIFN0YXJ0dXAgQ29uZmlndXJh
dGlvbiBEYXRhc3RvcmUgKDxzdGFydHVwPikgLiAuIC4gLiAuICAgOQ0KICAgICA0LjIuICBUaGUg
Q2FuZGlkYXRlIENvbmZpZ3VyYXRpb24gRGF0YXN0b3JlICg8Y2FuZGlkYXRlPikgLiAuIC4gIDEw
DQogICAgIDQuMy4gIFRoZSBSdW5uaW5nIENvbmZpZ3VyYXRpb24gRGF0YXN0b3JlICg8cnVubmlu
Zz4pIC4gLiAuIC4gLiAgMTANCiAgICAgNC40LiAgVGhlIEludGVuZGVkIENvbmZpZ3VyYXRpb24g
RGF0YXN0b3JlICg8aW50ZW5kZWQ+KSAuIC4gLiAuICAxMA0KICAgICA0LjUuICBDb252ZW50aW9u
YWwgQ29uZmlndXJhdGlvbiBEYXRhc3RvcmVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDExDQogICAg
IDQuNi4gIER5bmFtaWMgQ29uZmlndXJhdGlvbiBEYXRhc3RvcmVzICAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAgMTENCiAgICAgNC43LiAgVGhlIE9wZXJhdGlvbmFsIFN0YXRlIERhdGFzdG9yZSAo
PG9wZXJhdGlvbmFsPikgLiAuIC4gLiAuICAxMQ0KICAgICAgIDQuNy4xLiAgUmVtbmFudCBDb25m
aWd1cmF0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEyDQogICAgICAgNC43
LjIuICBNaXNzaW5nIFJlc291cmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAgMTMNCiAgICAgICA0LjcuMy4gIFN5c3RlbS1jb250cm9sbGVkIFJlc291cmNlcyAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuICAxMw0KICAgICAgIDQuNy40LiAgT3JpZ2luIE1ldGFkYXRhIEFu
bm90YXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEzDQoNClByb3Bvc2VkIFRPQzoN
Cg0KICAgNC4gIEFyY2hpdGVjdHVyYWwgTW9kZWwgb2YgRGF0YXN0b3JlcyAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gICA4DQogICAgIDQuMS4gIENvbnZlbnRpb25hbCBDb25maWd1cmF0aW9u
IERhdGFzdG9yZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDkNCiAgICAgICA0LjEuMS4gIFRoZSBT
dGFydHVwIENvbmZpZ3VyYXRpb24gRGF0YXN0b3JlICg8c3RhcnR1cD4pIC4gLiAuICAxMA0KICAg
ICAgIDQuMS4yLiAgVGhlIENhbmRpZGF0ZSBDb25maWd1cmF0aW9uIERhdGFzdG9yZSAoPGNhbmRp
ZGF0ZT4pIC4gIDEwDQogICAgICAgNC4xLjMuICBUaGUgUnVubmluZyBDb25maWd1cmF0aW9uIERh
dGFzdG9yZSAoPHJ1bm5pbmc+KSAuIC4gLiAgMTANCiAgICAgICA0LjEuNC4gIFRoZSBJbnRlbmRl
ZCBDb25maWd1cmF0aW9uIERhdGFzdG9yZSAoPGludGVuZGVkPikgLiAuICAxMQ0KICAgICA0LjIu
ICBEeW5hbWljIENvbmZpZ3VyYXRpb24gRGF0YXN0b3JlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gIDEyDQogICAgIDQuMy4gIFRoZSBPcGVyYXRpb25hbCBTdGF0ZSBEYXRhc3RvcmUgKDxvcGVy
YXRpb25hbD4pIC4gLiAuIC4gLiAgMTINCiAgICAgICA0LjMuMS4gIFJlbW5hbnQgQ29uZmlndXJh
dGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMw0KICAgICAgIDQuMy4yLiAg
TWlzc2luZyBSZXNvdXJjZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEz
DQogICAgICAgNC4zLjMuICBTeXN0ZW0tY29udHJvbGxlZCBSZXNvdXJjZXMgLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAgMTQNCiAgICAgICA0LjMuNC4gIE9yaWdpbiBNZXRhZGF0YSBBbm5vdGF0
aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNA0KDQo0LiBGaW5hbGx5LCBJIG5vdGlj
ZWQgb25lIHJlZmVyZW5jZSB0aGF0IGNvdWxkIGJlIGltcHJvdmVkLCBieSBjaGFuZ2luZyBpdCBm
cm9tICIoZGVzY3JpYmVkIGJlbG93KSIgdG8gYSBwcm9wZXIgc2VjdGlvbiByZWZlcmVuY2U6DQoN
CjY0Nyw2NDhjNjQ0LDY0NQ0KPCAgICBjaXJjdW1zdGFuY2VzLCBlLmcuLCBhbiBhYm5vcm1hbCB2
YWx1ZSBpcyAnaW4gdXNlJywgb3IgZHVlIHRvIHJlbW5hbnQNCjwgICAgY29uZmlndXJhdGlvbiAo
ZGVzY3JpYmVkIGJlbG93KS4gIE5vdGUsIHRoYXQgZGV2aWF0aW9ucyBhcmUgc3RpbGwNCi0tLQ0K
PiAgICBjaXJjdW1zdGFuY2VzLCBlLmcuLCBhbiBhYm5vcm1hbCB2YWx1ZSBpcyAiaW4gdXNlIiwg
b3IgZHVlIHRvIHJlbW5hbnQNCj4gICAgY29uZmlndXJhdGlvbiAoc2VlIFNlY3Rpb24gNC43LjEp
LiAgTm90ZSwgdGhhdCBkZXZpYXRpb25zIGFyZSBzdGlsbA0KDQpUaGFua3MsDQpSb2INCg0KDQpP
biAwMS8wOS8yMDE3IDIyOjAyLCBMb3UgQmVyZ2VyIHdyb3RlOg0KDQpBbGwsDQoNCg0KDQpUaGlz
IHN0YXJ0cyBhIHR3byB3ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uDQoNCmRyYWZ0LWll
dGYtbmV0bW9kLXJldmlzZWQtZGF0YXN0b3Jlcy0wNC4NCg0KDQoNClRoZSB3b3JraW5nIGdyb3Vw
IGxhc3QgY2FsbCBlbmRzIG9uIFNlcHRlbWJlciAxNy4NCg0KUGxlYXNlIHNlbmQgeW91ciBjb21t
ZW50cyB0byB0aGUgbmV0bW9kIG1haWxpbmcgbGlzdC4NCg0KDQoNClBvc2l0aXZlIGNvbW1lbnRz
LCBlLmcuLCAiSSd2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFuZA0KDQpiZWxpZXZlIGl0IGlz
IHJlYWR5IGZvciBwdWJsaWNhdGlvbiIsIGFyZSB3ZWxjb21lIQ0KDQpUaGlzIGlzIHVzZWZ1bCBh
bmQgaW1wb3J0YW50LCBldmVuIGZyb20gYXV0aG9ycy4NCg0KDQoNClRoYW5rIHlvdSwNCg0KTmV0
bW9kIENoYWlycw0K

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

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg
MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0
aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt
ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5
bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt
YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy
LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNv
SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt
ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv
d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv
cmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt
ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7
DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47
DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p
bHk6IkNvdXJpZXIgTmV3Ijt9DQp0dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJZm9udC1m
YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1z
dHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6
OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpD
b3VyaWVyO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl
cGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJZm9udC12YXJpYW50Om5vcm1hbCAhaW1wb3J0
YW50Ow0KCWNvbG9yOndpbmRvd3RleHQ7DQoJdGV4dC10cmFuc2Zvcm06bm9uZTsNCgl0ZXh0LWRl
Y29yYXRpb246bm9uZSBub25lOw0KCXZlcnRpY2FsLWFsaWduOmJhc2VsaW5lO30NCnNwYW4ubXNv
SW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0K
CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVs
dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw
YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w
aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9
DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVT
IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+
QXMgYW4gYXV0aG9yLCBJIGJlbGlldmUgdGhlIGRyYWZ0IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlv
bi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPlJlZ2Fy
ZGluZyBSb2JlcnQncyBlZGl0b3JpYWwgc3VnZ2VzdGlvbnM6PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmki
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4xKSBob3cgbW92aW5nICZxdW90O2FsbCZxdW90
OyBsaWtlIHRoaXM/Jm5ic3A7IChpLmUuLCBtdXN0IGhhdmUgc2FtZSBtb2R1bGVzLCBkZXZpYXRp
b25zLCBldGMuKQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPi0mbmJzcDsmbmJzcDsgZGF0YXN0b3Jl
cyB0aGF0IGFsbCBzaGFyZSBleGFjdGx5IHRoZSBzYW1lIHNjaGVtYSwgYWxsb3dpbmcgZGF0YSB0
byBiZSBjb3BpZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+JiM0MzsmbmJzcDsgZGF0YXN0b3JlcyB0
aGF0IHNoYXJlIGV4YWN0bHkgdGhlIHNhbWUgc2NoZW1hLCBhbGxvd2luZyBhbGwgZGF0YSB0byBi
ZSBjb3BpZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmki
PjIpIGJldHRlciwgYnV0IEkgdGhpbmsgd2Ugc2hvdWxkIGV4cGFuZCAmcXVvdDtJdCZxdW90OyBp
biB0aGUgYmVnaW5uaW5nIG9mIHRoZSAybmQgcGFyYWdyYXBoPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmki
PnRvICZxdW90O1RoZSBpbnRlbmRlZCBjb25maWd1cmF0aW9uIGRhdGFzdG9yZSZxdW90Oy4mbmJz
cDsgQWxzbywgaG93IGFib3V0IHRoaXMgZm9yIHRoZSAzcmQNCjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJp
Ij5wYXJhZ3JhcGggaW5zdGVhZD8mbmJzcDsgKGZpeGVzIGEgY291cGxlJm5ic3A7IHBsdXJhbGl0
eSBpc3N1ZXMgYW5kIG9uZSB0cmFuc2l0aW9uIGlzc3VlKTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyBUaGUgY29udGVudHMgb2Yg
Jmx0O2ludGVuZGVkJmd0OyBhcmUgcmVsYXRlZCB0byB0aGUgJ2NvbmZpZyB0cnVlJzxicj4NCiZu
YnNwOyZuYnNwOyBzdWJzZXQgb2YgJmx0O29wZXJhdGlvbmFsJmd0Oywgc3VjaCB0aGF0IGEgY2xp
ZW50IGNhbiBkZXRlcm1pbmUgdG8gd2hhdDxicj4NCiZuYnNwOyZuYnNwOyBleHRlbnQgdGhlIGlu
dGVuZGVkIGNvbmZpZ3VyYXRpb24gaXMgY3VycmVudGx5IGFwcGxpZWQgYnkgY2hlY2tpbmc8YnI+
DQombmJzcDsmbmJzcDsgd2hldGhlciB0aGUgY29udGVudHMgb2YgJmx0O2ludGVuZGVkJmd0OyBh
bHNvIGFwcGVhciBpbiAmbHQ7b3BlcmF0aW9uYWwmZ3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+MykgSSdtIG9rYXkgd2l0aCB0aGlzLiA8bzpwPg0K
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+NCkgVGhpcyBpcyBi
ZXR0ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5L
ZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiA5LzExLzE3LCAxMToyMiBBTSwgJnF1
b3Q7Um9iZXJ0IFdpbHRvbiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ3aWx0b25AY2lzY28u
Y29tIj5yd2lsdG9uQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPHA+QXMgb25lIG9mIHRoZSBhdXRob3JzLCBJIHdvdWxkIGxpa2UgdG8g
c2VlIGEgZmV3IG1pbm9yIGVkaXRvcmlhbCB1cGRhdGVzLCBkZXNjcmliZWQgYmVsb3cuJm5ic3A7
IE90aGVyd2lzZSBJIGJlbGlldmUgdGhhdCB0aGUgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIHB1Ymxp
Y2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHA+UHJvcG9zZWQgY2hhbmdlczo8bzpwPjwvbzpwPjwv
cD4NCjxwPjEuIEkgdGhpbmsgdGhhdCB0aGUgZG9jdW1lbnQgY291bGQgZnVydGhlciBlbXBoYXNp
cyB0aGF0IHRoZSBzY2hlbWEgZm9yIGFsbCB0aGUgY29udmVudGlvbmFsIGRhdGFzdG9yZXMgbXVz
dCBiZSB0aGUgc2FtZS48bzpwPjwvbzpwPjwvcD4NCjxwPjxiPk9sZDo8L2I+PG86cD48L286cD48
L3A+DQo8cD48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjQuNS4mbmJzcDsgQ29u
dmVudGlvbmFsIENvbmZpZ3VyYXRpb24gRGF0YXN0b3Jlczwvc3Bhbj48L3R0PjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48
YnI+DQo8YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IFRoZSBjb252ZW50aW9uYWwgY29uZmlndXJhdGlv
biBkYXRhc3RvcmVzIGFyZSBhIHNldCBvZiBjb25maWd1cmF0aW9uPC90dD48YnI+DQo8dHQ+Jm5i
c3A7Jm5ic3A7IGRhdGFzdG9yZXMgdGhhdCBzaGFyZSBhIGNvbW1vbiBzY2hlbWEsIGFsbG93aW5n
IGRhdGEgdG8gYmUgY29waWVkPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGJldHdlZW4gdGhl
bS4mbmJzcDsgVGhlIHRlcm0gaXMgbWVhbnQgYXMgYSBnZW5lcmljIHVtYnJlbGxhIGRlc2NyaXB0
aW9uIG9mPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IHRoZXNlIGRhdGFzdG9yZXMuJm5ic3A7
IFRoZSBzZXQgb2YgZGF0YXN0b3JlcyBpbmNsdWRlOjwvdHQ+PC9zcGFuPjxicj4NCjxicj4NCjxi
Pk5ldzo8L2I+PGJyPg0KPGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij40
LjUuJm5ic3A7IENvbnZlbnRpb25hbCBDb25maWd1cmF0aW9uIERhdGFzdG9yZXM8L3NwYW4+PC90
dD48bzpwPjwvbzpwPjwvcD4NCjxwPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+
Jm5ic3A7Jm5ic3A7IFRoZSBjb252ZW50aW9uYWwgY29uZmlndXJhdGlvbiBkYXRhc3RvcmVzIGFy
ZSBhIHNldCBvZiBjb25maWd1cmF0aW9uPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD4m
bmJzcDsmbmJzcDsgZGF0YXN0b3JlcyB0aGF0IGFsbCBzaGFyZSBleGFjdGx5IHRoZSBzYW1lIHNj
aGVtYSwgYWxsb3dpbmcgZGF0YSB0byBiZSBjb3BpZWQ8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJz
cDsgYmV0d2VlbiB0aGVtLiZuYnNwOyBUaGUgdGVybSBpcyBtZWFudCBhcyBhIGdlbmVyaWMgdW1i
cmVsbGEgZGVzY3JpcHRpb24gb2Y8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgdGhlc2UgZGF0
YXN0b3Jlcy4mbmJzcDsgVGhlIHNldCBvZiBkYXRhc3RvcmVzIGluY2x1ZGU6PC90dD48L3NwYW4+
PG86cD48L286cD48L3A+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPjIuIEkgdGhpbmsg
dGhhdCB0aGUgZGVzY3JpcHRpb24gb2YgdGhlIGludGVuZGVkIGRhdGFzdG9yZSBjb3VsZCBiZSBl
eHBhbmRlZCB0byBnaXZlIGEgYml0IG1vcmUgY2xhcml0eS48bzpwPjwvbzpwPjwvcD4NCjxwPjxi
Pk9MRDo8L2I+PG86cD48L286cD48L3A+DQo8cD48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQiPjQuNC4mbmJzcDsgVGhlIEludGVuZGVkIENvbmZpZ3VyYXRpb24gRGF0YXN0b3JlICgm
bHQ7aW50ZW5kZWQmZ3Q7KTwvc3Bhbj48L3R0PjxvOnA+PC9vOnA+PC9wPg0KPHA+PHR0PjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDsmbmJzcDsgVGhlIGludGVuZGVkIGNvbmZp
Z3VyYXRpb24gZGF0YXN0b3JlICgmbHQ7aW50ZW5kZWQmZ3Q7KSBpcyBhIHJlYWQtb25seTwvc3Bh
bj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGNvbmZpZ3VyYXRpb24gZGF0
YXN0b3JlLiZuYnNwOyBJdCBpcyB0aWdodGx5IGNvdXBsZWQgdG8gJmx0O3J1bm5pbmcmZ3Q7LiZu
YnNwOyBXaGVuPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGRhdGEgaXMgd3JpdHRlbiB0byAm
bHQ7cnVubmluZyZndDssIHRoZSBkYXRhIHRoYXQgaXMgdG8gYmUgdmFsaWRhdGVkIGlzPC90dD48
YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGFsc28gY29uY2VwdHVhbGx5IHdyaXR0ZW4gdG8gJmx0O2lu
dGVuZGVkJmd0Oy4mbmJzcDsgVmFsaWRhdGlvbiBpcyBwZXJmb3JtZWQgb248L3R0Pjxicj4NCjx0
dD4mbmJzcDsmbmJzcDsgdGhlIGNvbnRlbnRzIG9mICZsdDtpbnRlbmRlZCZndDsuPC90dD48YnI+
DQo8YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IEZvciBzaW1wbGUgaW1wbGVtZW50YXRpb25zLCAmbHQ7
cnVubmluZyZndDsgYW5kICZsdDtpbnRlbmRlZCZndDsgYXJlIGlkZW50aWNhbC48L3R0Pjxicj4N
Cjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgJmx0O2ludGVuZGVkJmd0OyBkb2VzIG5vdCBwZXJzaXN0
IGFjcm9zcyByZWJvb3RzOyBpdHMgcmVsYXRpb25zaGlwIHdpdGg8L3R0Pjxicj4NCjx0dD4mbmJz
cDsmbmJzcDsgJmx0O3J1bm5pbmcmZ3Q7IG1ha2VzIHRoYXQgdW5uZWNlc3NhcnkuJm5ic3A7IDwv
dHQ+PGJyPg0KPGJyPg0KPHR0PiZuYnNwOyZuYnNwOyAuLi48L3R0Pjwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwPjxiPk5FVzo8L2I+PG86cD48L286cD48L3A+DQo8cD48dHQ+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQiPjQuNC4mbmJzcDsgVGhlIEludGVuZGVkIENvbmZpZ3VyYXRpb24g
RGF0YXN0b3JlICgmbHQ7aW50ZW5kZWQmZ3Q7KTwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8
YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IFRoZSBpbnRlbmRlZCBjb25maWd1cmF0aW9uIGRhdGFzdG9y
ZSAoJmx0O2ludGVuZGVkJmd0OykgaXMgYSByZWFkLW9ubHk8L3R0Pjxicj4NCjx0dD4mbmJzcDsm
bmJzcDsgY29uZmlndXJhdGlvbiBkYXRhc3RvcmUuJm5ic3A7IEl0IHJlcHJlc2VudHMgdGhlIGNv
bmZpZ3VyYXRpb24gYWZ0ZXIgYWxsPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGNvbmZpZ3Vy
YXRpb24gdHJhbnNmb3JtYXRpb25zIHRvICZsdDtydW5uaW5nJmd0OyBhcmUgcGVyZm9ybWVkIChl
LmcuPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IHRlbXBsYXRlIGV4cGFuc2lvbiwgaW5hY3Rp
dmUgY29uZmlndXJhdGlvbiByZW1vdmFsKSwgYW5kIGlzIHRoZTwvdHQ+PGJyPg0KPHR0PiZuYnNw
OyZuYnNwOyBjb25maWd1cmF0aW9uIHRoYXQgdGhlIHN5c3RlbSBhdHRlbXB0cyB0byBhcHBseS48
L3R0Pjxicj4NCjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgSXQgaXMgdGlnaHRseSBjb3VwbGVkIHRv
ICZsdDtydW5uaW5nJmd0Oy4mbmJzcDsgV2hlbiBkYXRhIGlzIHdyaXR0ZW4gdG88L3R0Pjxicj4N
Cjx0dD4mbmJzcDsmbmJzcDsgJmx0O3J1bm5pbmcmZ3Q7LCB0aGUgZGF0YSB0aGF0IGlzIHRvIGJl
IHZhbGlkYXRlZCBpcyBhbHNvIGNvbmNlcHR1YWxseTwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNw
OyB3cml0dGVuIHRvICZsdDtpbnRlbmRlZCZndDsuJm5ic3A7IFZhbGlkYXRpb24gaXMgcGVyZm9y
bWVkIG9uIHRoZSBjb250ZW50cyBvZjwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyAmbHQ7aW50
ZW5kZWQmZ3Q7LjwvdHQ+PGJyPg0KPGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBGb3Igc2ltcGxlIGlt
cGxlbWVudGF0aW9ucywgJmx0O3J1bm5pbmcmZ3Q7IGFuZCAmbHQ7aW50ZW5kZWQmZ3Q7IGFyZSBp
ZGVudGljYWwuPC90dD48YnI+DQo8YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IFRoZSBjb250ZW50cyBv
ZiAmbHQ7aW50ZW5kZWQmZ3Q7IGlzIGFsc28gcmVsYXRlZCB0byB0aGUgJ2NvbmZpZyB0cnVlJzwv
dHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBzdWJzZXQgb2YgJmx0O29wZXJhdGlvbmFsJmd0Oywg
YW5kIGhlbmNlIGEgY2xpZW50IGNhbiBkZXRlcm1pbmUgdG8gd2hhdDwvdHQ+PGJyPg0KPHR0PiZu
YnNwOyZuYnNwOyBleHRlbnQgdGhlIGludGVuZGVkIGNvbmZpZ3VyYXRpb24gaXMgY3VycmVudGx5
IGFwcGxpZWQgYnkgY2hlY2tpbmc8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgd2hldGhlciB0
aGUgY29udGVudHMgb2YgJmx0O2ludGVuZGVkJmd0OyBhbHNvIGFwcGVhcnMgaW4gJmx0O29wZXJh
dGlvbmFsJmd0Oy48L3R0Pjxicj4NCjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgJmx0O2ludGVuZGVk
Jmd0OyBkb2VzIG5vdCBwZXJzaXN0IGFjcm9zcyByZWJvb3RzOyBpdHMgcmVsYXRpb25zaGlwIHdp
dGg8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgJmx0O3J1bm5pbmcmZ3Q7IG1ha2VzIHRoYXQg
dW5uZWNlc3NhcnkuPC90dD48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48dHQ+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyAuLi48L3NwYW4+PC90dD48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw
dCI+PGJyPg0KMy4gSSB0aGluayB0aGF0IGl0IG1heSBhaWQgcmVhZGFiaWxpdHkgaWYgdGhlIHNl
Y3Rpb24gb24gY29udmVudGlvbmFsIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3JlcyB3YXMgbW92ZWQg
YWJvdmUgdGhlIGRlc2NyaXB0aW9uIG9mIHRoZSBpbmRpdmlkdWFsIGNvbnZlbnRpb25hbCBjb25m
aWd1cmF0aW9uIGRhdGFzdG9yZXMsIHdoaWNoIGNvdWxkIHRoZW4gYmUgaW50ZW5kZWQgb25lIGxl
dmVsLiZuYnNwOyBCZXN0IGlsbHVzdHJhdGVkIHZpYSB0aGUgY2hhbmdlDQogdG8gdGhlIHRhYmxl
IG9mIGNvbnRlbnRzLjxicj4NCjxicj4NCjxiPkUuZy4gY3VycmVudCBUT0M6IDwvYj48YnI+DQo8
YnI+DQo8dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyA0LiZu
YnNwOyBBcmNoaXRlY3R1cmFsIE1vZGVsIG9mIERhdGFzdG9yZXMgLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuJm5ic3A7Jm5ic3A7IDgNCjwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDQuMS4mbmJzcDsgVGhlIFN0YXJ0dXAgQ29uZmlndXJh
dGlvbiBEYXRhc3RvcmUgKCZsdDtzdGFydHVwJmd0OykgLiAuIC4gLiAuJm5ic3A7Jm5ic3A7IDkg
PC90dD4NCjxicj4NCjx0dD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNC4yLiZuYnNwOyBUaGUg
Q2FuZGlkYXRlIENvbmZpZ3VyYXRpb24gRGF0YXN0b3JlICgmbHQ7Y2FuZGlkYXRlJmd0OykgLiAu
IC4mbmJzcDsgMTAgPC90dD4NCjxicj4NCjx0dD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNC4z
LiZuYnNwOyBUaGUgUnVubmluZyBDb25maWd1cmF0aW9uIERhdGFzdG9yZSAoJmx0O3J1bm5pbmcm
Z3Q7KSAuIC4gLiAuIC4mbmJzcDsgMTAgPC90dD4NCjxicj4NCjx0dD4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgNC40LiZuYnNwOyBUaGUgSW50ZW5kZWQgQ29uZmlndXJhdGlvbiBEYXRhc3RvcmUg
KCZsdDtpbnRlbmRlZCZndDspIC4gLiAuIC4mbmJzcDsgMTAgPC90dD4NCjxicj4NCjx0dD4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgNC41LiZuYnNwOyBDb252ZW50aW9uYWwgQ29uZmlndXJhdGlv
biBEYXRhc3RvcmVzIC4gLiAuIC4gLiAuIC4gLiAuIC4mbmJzcDsgMTEgPC90dD4NCjxicj4NCjx0
dD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNC42LiZuYnNwOyBEeW5hbWljIENvbmZpZ3VyYXRp
b24gRGF0YXN0b3JlcyZuYnNwOyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiZuYnNwOyAxMSA8L3R0
Pg0KPGJyPg0KPHR0PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA0LjcuJm5ic3A7IFRoZSBPcGVy
YXRpb25hbCBTdGF0ZSBEYXRhc3RvcmUgKCZsdDtvcGVyYXRpb25hbCZndDspIC4gLiAuIC4gLiZu
YnNwOyAxMSA8L3R0Pg0KPGJyPg0KPHR0PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyA0LjcuMS4mbmJzcDsgUmVtbmFudCBDb25maWd1cmF0aW9uIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4mbmJzcDsgMTIgPC90dD4NCjxicj4NCjx0dD4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgNC43LjIuJm5ic3A7IE1pc3NpbmcgUmVzb3VyY2VzIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuJm5ic3A7IDEzIDwvdHQ+DQo8YnI+DQo8dHQ+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDQuNy4zLiZuYnNwOyBTeXN0ZW0t
Y29udHJvbGxlZCBSZXNvdXJjZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiZuYnNwOyAxMyA8
L3R0Pg0KPGJyPg0KPHR0PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA0Ljcu
NC4mbmJzcDsgT3JpZ2luIE1ldGFkYXRhIEFubm90YXRpb24mbmJzcDsgLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiZuYnNwOyAxMyA8L3R0Pg0KPC9zcGFuPjxicj4NCjxicj4NCjxiPlByb3Bvc2Vk
IFRPQzogPC9iPjxicj4NCjxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+
Jm5ic3A7Jm5ic3A7IDQuJm5ic3A7IEFyY2hpdGVjdHVyYWwgTW9kZWwgb2YgRGF0YXN0b3JlcyAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4mbmJzcDsmbmJzcDsgOA0KPC9zcGFuPjwvdHQ+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPjxicj4NCjx0dD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNC4xLiZuYnNwOyBDb252
ZW50aW9uYWwgQ29uZmlndXJhdGlvbiBEYXRhc3RvcmVzIC4gLiAuIC4gLiAuIC4gLiAuIC4mbmJz
cDsmbmJzcDsgOSA8L3R0Pg0KPGJyPg0KPHR0PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyA0LjEuMS4mbmJzcDsgVGhlIFN0YXJ0dXAgQ29uZmlndXJhdGlvbiBEYXRhc3RvcmUg
KCZsdDtzdGFydHVwJmd0OykgLiAuIC4mbmJzcDsgMTAgPC90dD4NCjxicj4NCjx0dD4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNC4xLjIuJm5ic3A7IFRoZSBDYW5kaWRhdGUg
Q29uZmlndXJhdGlvbiBEYXRhc3RvcmUgKCZsdDtjYW5kaWRhdGUmZ3Q7KSAuJm5ic3A7IDEwIDwv
dHQ+DQo8YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDQuMS4z
LiZuYnNwOyBUaGUgUnVubmluZyBDb25maWd1cmF0aW9uIERhdGFzdG9yZSAoJmx0O3J1bm5pbmcm
Z3Q7KSAuIC4gLiZuYnNwOyAxMCA8L3R0Pg0KPGJyPg0KPHR0PiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyA0LjEuNC4mbmJzcDsgVGhlIEludGVuZGVkIENvbmZpZ3VyYXRpb24g
RGF0YXN0b3JlICgmbHQ7aW50ZW5kZWQmZ3Q7KSAuIC4mbmJzcDsgMTEgPC90dD4NCjxicj4NCjx0
dD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNC4yLiZuYnNwOyBEeW5hbWljIENvbmZpZ3VyYXRp
b24gRGF0YXN0b3JlcyZuYnNwOyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiZuYnNwOyAxMiA8L3R0
Pg0KPGJyPg0KPHR0PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA0LjMuJm5ic3A7IFRoZSBPcGVy
YXRpb25hbCBTdGF0ZSBEYXRhc3RvcmUgKCZsdDtvcGVyYXRpb25hbCZndDspIC4gLiAuIC4gLiZu
YnNwOyAxMiA8L3R0Pg0KPGJyPg0KPHR0PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyA0LjMuMS4mbmJzcDsgUmVtbmFudCBDb25maWd1cmF0aW9uIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4mbmJzcDsgMTMgPC90dD4NCjxicj4NCjx0dD4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgNC4zLjIuJm5ic3A7IE1pc3NpbmcgUmVzb3VyY2VzIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuJm5ic3A7IDEzIDwvdHQ+DQo8YnI+DQo8dHQ+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDQuMy4zLiZuYnNwOyBTeXN0ZW0t
Y29udHJvbGxlZCBSZXNvdXJjZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiZuYnNwOyAxNCA8
L3R0Pg0KPGJyPg0KPHR0PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA0LjMu
NC4mbmJzcDsgT3JpZ2luIE1ldGFkYXRhIEFubm90YXRpb24mbmJzcDsgLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiZuYnNwOyAxNCA8L3R0Pg0KPC9zcGFuPjxicj4NCjxicj4NCjQuIEZpbmFsbHks
IEkgbm90aWNlZCBvbmUgcmVmZXJlbmNlIHRoYXQgY291bGQgYmUgaW1wcm92ZWQsIGJ5IGNoYW5n
aW5nIGl0IGZyb20gJnF1b3Q7KGRlc2NyaWJlZCBiZWxvdykmcXVvdDsgdG8gYSBwcm9wZXIgc2Vj
dGlvbiByZWZlcmVuY2U6PGJyPg0KPGJyPg0KNjQ3LDY0OGM2NDQsNjQ1PGJyPg0KJmx0OyZuYnNw
OyZuYnNwOyZuYnNwOyBjaXJjdW1zdGFuY2VzLCBlLmcuLCBhbiBhYm5vcm1hbCB2YWx1ZSBpcyAn
aW4gdXNlJywgb3IgZHVlIHRvIHJlbW5hbnQ8YnI+DQombHQ7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNv
bmZpZ3VyYXRpb24gKGRlc2NyaWJlZCBiZWxvdykuJm5ic3A7IE5vdGUsIHRoYXQgZGV2aWF0aW9u
cyBhcmUgc3RpbGw8YnI+DQotLS08YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNpcmN1bXN0
YW5jZXMsIGUuZy4sIGFuIGFibm9ybWFsIHZhbHVlIGlzICZxdW90O2luIHVzZSZxdW90Oywgb3Ig
ZHVlIHRvIHJlbW5hbnQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbmZpZ3VyYXRpb24g
KHNlZSBTZWN0aW9uIDQuNy4xKS4mbmJzcDsgTm90ZSwgdGhhdCBkZXZpYXRpb25zIGFyZSBzdGls
bDxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpSb2I8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpw
PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAwMS8wOS8yMDE3IDIyOjAyLCBM
b3UgQmVyZ2VyIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls
ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+QWxsLDxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRoaXMgc3Rh
cnRzIGEgdHdvIHdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb248bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT5kcmFmdC1pZXRmLW5ldG1vZC1yZXZpc2VkLWRhdGFzdG9yZXMtMDQuPG86cD48L286
cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhlIHdvcmtpbmcg
Z3JvdXAgbGFzdCBjYWxsIGVuZHMgb24gU2VwdGVtYmVyIDE3LjxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPlBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIG5ldG1vZCBtYWlsaW5nIGxpc3Qu
PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+UG9z
aXRpdmUgY29tbWVudHMsIGUuZy4sICZxdW90O0kndmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBh
bmQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5iZWxpZXZlIGl0IGlzIHJlYWR5IGZvciBwdWJsaWNh
dGlvbiZxdW90OywgYXJlIHdlbGNvbWUhPG86cD48L286cD48L3ByZT4NCjxwcmU+VGhpcyBpcyB1
c2VmdWwgYW5kIGltcG9ydGFudCwgZXZlbiBmcm9tIGF1dGhvcnMuPG86cD48L286cD48L3ByZT4N
CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhhbmsgeW91LDxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPk5ldG1vZCBDaGFpcnM8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3Rl
Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_E1A72908D7D64FDFBF778E6B0D2CFB4Bjunipernet_--


From nobody Mon Sep 11 10:27:51 2017
Return-Path: 
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 41F5D133183 for ; Mon, 11 Sep 2017 10:27:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_arSJK0pHDF for ; Mon, 11 Sep 2017 10:27:48 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16FA0132D97 for ; Mon, 11 Sep 2017 10:27:48 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id E3797F14; Mon, 11 Sep 2017 19:27:46 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id igcErrKIBOne; Mon, 11 Sep 2017 19:27:41 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 11 Sep 2017 19:27:46 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C014B200E8; Mon, 11 Sep 2017 19:27:46 +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 5XYKdky2JL48; Mon, 11 Sep 2017 19:27:46 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7AC22200E2; Mon, 11 Sep 2017 19:27:46 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 1D00540F01C6; Mon, 11 Sep 2017 19:27:45 +0200 (CEST)
Date: Mon, 11 Sep 2017 19:27:45 +0200
From: Juergen Schoenwaelder 
To: Kent Watsen 
Cc: Robert Wilton , Lou Berger , netmod WG 
Message-ID: <20170911172745.qzsvoluaodfcnb3c@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Kent Watsen , Robert Wilton , Lou Berger , netmod WG 
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <10476e00-0169-4258-449f-22cc7ca978a8@cisco.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Sep 2017 17:27:50 -0000

On Mon, Sep 11, 2017 at 05:12:42PM +0000, Kent Watsen wrote:
> 
>    The contents of  are related to the 'config true'
>    subset of , such that a client can determine to what
>    extent the intended configuration is currently applied by checking
>    whether the contents of  also appear in .
>

Editorial: Should this not be "The content of  is" and "the
content of "?

There are several possible pitfalls here since (i)  can
change anytime, (ii) it might not be easy/possible to obtain a
consistent snapshot of , and (iii) dynamic datastores can
provide values that "overwrite"  and hence comparing values
may not really be sufficient. As long as the text is understood as
additional explanation and not used to write naive code to determine
how much of  has been applied, it is fine. Otherwise, it
may be a source of future problems.

/js

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


From nobody Mon Sep 11 10:31:22 2017
Return-Path: 
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 F3D0A13318D for ; Mon, 11 Sep 2017 10:31:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJBmI9CMZ4pl for ; Mon, 11 Sep 2017 10:31: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 BE11613318C for ; Mon, 11 Sep 2017 10:31:17 -0700 (PDT)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id AD8A01AE0403; Mon, 11 Sep 2017 19:31:16 +0200 (CEST)
Date: Mon, 11 Sep 2017 19:31:24 +0200 (CEST)
Message-Id: <20170911.193124.713501339751798550.mbj@tail-f.com>
To: kwatsen@juniper.net
Cc: rwilton@cisco.com, lberger@labn.net, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <10476e00-0169-4258-449f-22cc7ca978a8@cisco.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Sep 2017 17:31:20 -0000

Kent Watsen  wrote:
> As an author, I believe the draft is ready for publication.
> 
> Regarding Robert's editorial suggestions:
> 
> 1) how moving "all" like this?  (i.e., must have same modules,
> deviations, etc.)
> -   datastores that all share exactly the same schema, allowing data to be
> -   copied
> + datastores that share exactly the same schema, allowing all data to
> be copied


Or just remove "all".

> 2) better, but I think we should expand "It" in the beginning of the
> 2nd paragraph
> to "The intended configuration datastore".  Also, how about this for
> the 3rd
> paragraph instead?  (fixes a couple plurality issues and one
> transition issue):
> 
>    The contents of  are related to the 'config true'
>    subset of , such that a client can determine to what
>    extent the intended configuration is currently applied by checking
>    whether the contents of  also appear in .

Ok.

> 3) I'm okay with this.

I agree that the proposed TOC changes are better.

> 4) This is better.

Agreed.


/martin


> 
> 
> Thanks,
> Kent
> 
> 
> 
> On 9/11/17, 11:22 AM, "Robert Wilton"
> > wrote:
> 
> 
> As one of the authors, I would like to see a few minor editorial
> updates, described below.  Otherwise I believe that the document is
> ready for publication.
> 
> Proposed changes:
> 
> 1. I think that the document could further emphasis that the schema
> for all the conventional datastores must be the same.
> 
> Old:
> 
> 4.5.  Conventional Configuration Datastores
> 
>    The conventional configuration datastores are a set of configuration
>    datastores that share a common schema, allowing data to be copied
>    between them.  The term is meant as a generic umbrella description of
>    these datastores.  The set of datastores include:
> 
> New:
> 
> 4.5.  Conventional Configuration Datastores
> 
>    The conventional configuration datastores are a set of configuration
>    datastores that all share exactly the same schema, allowing data to be
>    copied
>    between them.  The term is meant as a generic umbrella description of
>    these datastores.  The set of datastores include:
> 
> 
> 
> 2. I think that the description of the intended datastore could be
> expanded to give a bit more clarity.
> 
> OLD:
> 
> 4.4.  The Intended Configuration Datastore ()
> 
>    The intended configuration datastore () is a read-only
>    configuration datastore.  It is tightly coupled to .  When
>    data is written to , the data that is to be validated is
>    also conceptually written to .  Validation is performed on
>    the contents of .
> 
>    For simple implementations,  and  are identical.
> 
>     does not persist across reboots; its relationship with
>     makes that unnecessary.
> 
>    ...
> 
> NEW:
> 
> 4.4.  The Intended Configuration Datastore ()
> 
>    The intended configuration datastore () is a read-only
>    configuration datastore.  It represents the configuration after all
>    configuration transformations to  are performed (e.g.
>    template expansion, inactive configuration removal), and is the
>    configuration that the system attempts to apply.
> 
>    It is tightly coupled to .  When data is written to
>    , the data that is to be validated is also conceptually
>    written to .  Validation is performed on the contents of
>    .
> 
>    For simple implementations,  and  are identical.
> 
>    The contents of  is also related to the 'config true'
>    subset of , and hence a client can determine to what
>    extent the intended configuration is currently applied by checking
>    whether the contents of  also appears in .
> 
>     does not persist across reboots; its relationship with
>     makes that unnecessary.
> 
>    ...
> 
> 3. I think that it may aid readability if the section on conventional
> configuration datastores was moved above the description of the
> individual conventional configuration datastores, which could then be
> intended one level.  Best illustrated via the change to the table of
> contents.
> 
> E.g. current TOC:
> 
>    4.  Architectural Model of Datastores . . . . . . . . . . . . . .   8
>      4.1.  The Startup Configuration Datastore () . . . . .   9
>      4.2.  The Candidate Configuration Datastore () . . .  10
>      4.3.  The Running Configuration Datastore () . . . . .  10
>      4.4.  The Intended Configuration Datastore () . . . .  10
>      4.5.  Conventional Configuration Datastores . . . . . . . . . .  11
>      4.6.  Dynamic Configuration Datastores  . . . . . . . . . . . .  11
>      4.7.  The Operational State Datastore () . . . . .  11
>        4.7.1.  Remnant Configuration . . . . . . . . . . . . . . . .  12
>        4.7.2.  Missing Resources . . . . . . . . . . . . . . . . . .  13
>        4.7.3.  System-controlled Resources . . . . . . . . . . . . .  13
>        4.7.4.  Origin Metadata Annotation  . . . . . . . . . . . . .  13
> 
> Proposed TOC:
> 
>    4.  Architectural Model of Datastores . . . . . . . . . . . . . .   8
>      4.1.  Conventional Configuration Datastores . . . . . . . . . .   9
>        4.1.1.  The Startup Configuration Datastore () . . .  10
>        4.1.2.  The Candidate Configuration Datastore () .  10
>        4.1.3.  The Running Configuration Datastore () . . .  10
>        4.1.4.  The Intended Configuration Datastore () . .  11
>      4.2.  Dynamic Configuration Datastores  . . . . . . . . . . . .  12
>      4.3.  The Operational State Datastore () . . . . .  12
>        4.3.1.  Remnant Configuration . . . . . . . . . . . . . . . .  13
>        4.3.2.  Missing Resources . . . . . . . . . . . . . . . . . .  13
>        4.3.3.  System-controlled Resources . . . . . . . . . . . . .  14
>        4.3.4.  Origin Metadata Annotation  . . . . . . . . . . . . .  14
> 
> 4. Finally, I noticed one reference that could be improved, by
> changing it from "(described below)" to a proper section reference:
> 
> 647,648c644,645
> < circumstances, e.g., an abnormal value is 'in use', or due to
> remnant
> <    configuration (described below).  Note, that deviations are still
> ---
> >    circumstances, e.g., an abnormal value is "in use", or due to remnant
> >    configuration (see Section 4.7.1).  Note, that deviations are still
> 
> Thanks,
> Rob
> 
> 
> On 01/09/2017 22:02, Lou Berger wrote:
> 
> All,
> 
> 
> 
> This starts a two week working group last call on
> 
> draft-ietf-netmod-revised-datastores-04.
> 
> 
> 
> The working group last call ends on September 17.
> 
> Please send your comments to the netmod mailing list.
> 
> 
> 
> Positive comments, e.g., "I've reviewed this document and
> 
> believe it is ready for publication", are welcome!
> 
> This is useful and important, even from authors.
> 
> 
> 
> Thank you,
> 
> Netmod Chairs


From nobody Tue Sep 12 03:49:04 2017
Return-Path: 
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 F1BBB1333D2 for ; Tue, 12 Sep 2017 03:49:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 zdDw1XQpRZsu for ; Tue, 12 Sep 2017 03:49:01 -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 074001333AC for ; Tue, 12 Sep 2017 03:49:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7772; q=dns/txt; s=iport; t=1505213341; x=1506422941; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=IuryX5RCc09Apu9BpG3xEL8VtpVdvmgdG/pHXVvQJgI=; b=igOh+Xwc0Q3tAVUaQKq902hQVBxQ3y8KrPDJ+qApzNr+BAH/8Qz44Ljk 8Np5sp122DW4tS+pP9Sn1b7h3vbZadE5HdEvoqMqMmFIZlhUyN5w6TFLE jG8V3A5pwZH/b8gl5Oq9pz4/ZM9AhWghGClMHsCcHm9HLviJHimTbSjF2 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BKBAADu7dZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhS0ng3eLFZB3K5YpghIKhT4ChHYWAQIBAQEBAQEBayiFGAEBAQM?= =?us-ascii?q?BIxU2BAcQCw4KAgIjAwICRhEGAQwGAgEBiiUIqwGCJ4syAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEhgQ6CHYNSgg4LgWWBDYgKgmEFoHWUUoIThWiDWiSGeY1Yh1WBOSYKJ4E?= =?us-ascii?q?NMiEIHBVKhRgcgWg/NodOK4IUAQEB?=
X-IronPort-AV: E=Sophos;i="5.42,382,1500940800"; d="scan'208";a="654556579"
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; 12 Sep 2017 10:48:58 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8CAmwe7021097; Tue, 12 Sep 2017 10:48:58 GMT
To: Martin Bjorklund , kwatsen@juniper.net
Cc: lberger@labn.net, netmod@ietf.org
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <10476e00-0169-4258-449f-22cc7ca978a8@cisco.com>  <20170911.193124.713501339751798550.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: 
Date: Tue, 12 Sep 2017 11:48:58 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170911.193124.713501339751798550.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Sep 2017 10:49:03 -0000

On 11/09/2017 18:31, Martin Bjorklund wrote:
> Kent Watsen  wrote:
>> As an author, I believe the draft is ready for publication.
>>
>> Regarding Robert's editorial suggestions:
>>
>> 1) how moving "all" like this?  (i.e., must have same modules,
>> deviations, etc.)
>> -   datastores that all share exactly the same schema, allowing data to be
>> -   copied
>> + datastores that share exactly the same schema, allowing all data to
>> be copied
>
> Or just remove "all".
I also have a slight preference for just removing "all", but am also OK 
if it moves.

Thanks,
Rob


>
>> 2) better, but I think we should expand "It" in the beginning of the
>> 2nd paragraph
>> to "The intended configuration datastore".  Also, how about this for
>> the 3rd
>> paragraph instead?  (fixes a couple plurality issues and one
>> transition issue):
>>
>>     The contents of  are related to the 'config true'
>>     subset of , such that a client can determine to what
>>     extent the intended configuration is currently applied by checking
>>     whether the contents of  also appear in .
> Ok.
>
>> 3) I'm okay with this.
> I agree that the proposed TOC changes are better.
>
>> 4) This is better.
> Agreed.
>
>
> /martin
>
>
>>
>> Thanks,
>> Kent
>>
>>
>>
>> On 9/11/17, 11:22 AM, "Robert Wilton"
>> > wrote:
>>
>>
>> As one of the authors, I would like to see a few minor editorial
>> updates, described below.  Otherwise I believe that the document is
>> ready for publication.
>>
>> Proposed changes:
>>
>> 1. I think that the document could further emphasis that the schema
>> for all the conventional datastores must be the same.
>>
>> Old:
>>
>> 4.5.  Conventional Configuration Datastores
>>
>>     The conventional configuration datastores are a set of configuration
>>     datastores that share a common schema, allowing data to be copied
>>     between them.  The term is meant as a generic umbrella description of
>>     these datastores.  The set of datastores include:
>>
>> New:
>>
>> 4.5.  Conventional Configuration Datastores
>>
>>     The conventional configuration datastores are a set of configuration
>>     datastores that all share exactly the same schema, allowing data to be
>>     copied
>>     between them.  The term is meant as a generic umbrella description of
>>     these datastores.  The set of datastores include:
>>
>>
>>
>> 2. I think that the description of the intended datastore could be
>> expanded to give a bit more clarity.
>>
>> OLD:
>>
>> 4.4.  The Intended Configuration Datastore ()
>>
>>     The intended configuration datastore () is a read-only
>>     configuration datastore.  It is tightly coupled to .  When
>>     data is written to , the data that is to be validated is
>>     also conceptually written to .  Validation is performed on
>>     the contents of .
>>
>>     For simple implementations,  and  are identical.
>>
>>      does not persist across reboots; its relationship with
>>      makes that unnecessary.
>>
>>     ...
>>
>> NEW:
>>
>> 4.4.  The Intended Configuration Datastore ()
>>
>>     The intended configuration datastore () is a read-only
>>     configuration datastore.  It represents the configuration after all
>>     configuration transformations to  are performed (e.g.
>>     template expansion, inactive configuration removal), and is the
>>     configuration that the system attempts to apply.
>>
>>     It is tightly coupled to .  When data is written to
>>     , the data that is to be validated is also conceptually
>>     written to .  Validation is performed on the contents of
>>     .
>>
>>     For simple implementations,  and  are identical.
>>
>>     The contents of  is also related to the 'config true'
>>     subset of , and hence a client can determine to what
>>     extent the intended configuration is currently applied by checking
>>     whether the contents of  also appears in .
>>
>>      does not persist across reboots; its relationship with
>>      makes that unnecessary.
>>
>>     ...
>>
>> 3. I think that it may aid readability if the section on conventional
>> configuration datastores was moved above the description of the
>> individual conventional configuration datastores, which could then be
>> intended one level.  Best illustrated via the change to the table of
>> contents.
>>
>> E.g. current TOC:
>>
>>     4.  Architectural Model of Datastores . . . . . . . . . . . . . .   8
>>       4.1.  The Startup Configuration Datastore () . . . . .   9
>>       4.2.  The Candidate Configuration Datastore () . . .  10
>>       4.3.  The Running Configuration Datastore () . . . . .  10
>>       4.4.  The Intended Configuration Datastore () . . . .  10
>>       4.5.  Conventional Configuration Datastores . . . . . . . . . .  11
>>       4.6.  Dynamic Configuration Datastores  . . . . . . . . . . . .  11
>>       4.7.  The Operational State Datastore () . . . . .  11
>>         4.7.1.  Remnant Configuration . . . . . . . . . . . . . . . .  12
>>         4.7.2.  Missing Resources . . . . . . . . . . . . . . . . . .  13
>>         4.7.3.  System-controlled Resources . . . . . . . . . . . . .  13
>>         4.7.4.  Origin Metadata Annotation  . . . . . . . . . . . . .  13
>>
>> Proposed TOC:
>>
>>     4.  Architectural Model of Datastores . . . . . . . . . . . . . .   8
>>       4.1.  Conventional Configuration Datastores . . . . . . . . . .   9
>>         4.1.1.  The Startup Configuration Datastore () . . .  10
>>         4.1.2.  The Candidate Configuration Datastore () .  10
>>         4.1.3.  The Running Configuration Datastore () . . .  10
>>         4.1.4.  The Intended Configuration Datastore () . .  11
>>       4.2.  Dynamic Configuration Datastores  . . . . . . . . . . . .  12
>>       4.3.  The Operational State Datastore () . . . . .  12
>>         4.3.1.  Remnant Configuration . . . . . . . . . . . . . . . .  13
>>         4.3.2.  Missing Resources . . . . . . . . . . . . . . . . . .  13
>>         4.3.3.  System-controlled Resources . . . . . . . . . . . . .  14
>>         4.3.4.  Origin Metadata Annotation  . . . . . . . . . . . . .  14
>>
>> 4. Finally, I noticed one reference that could be improved, by
>> changing it from "(described below)" to a proper section reference:
>>
>> 647,648c644,645
>> < circumstances, e.g., an abnormal value is 'in use', or due to
>> remnant
>> <    configuration (described below).  Note, that deviations are still
>> ---
>>>     circumstances, e.g., an abnormal value is "in use", or due to remnant
>>>     configuration (see Section 4.7.1).  Note, that deviations are still
>> Thanks,
>> Rob
>>
>>
>> On 01/09/2017 22:02, Lou Berger wrote:
>>
>> All,
>>
>>
>>
>> This starts a two week working group last call on
>>
>> draft-ietf-netmod-revised-datastores-04.
>>
>>
>>
>> The working group last call ends on September 17.
>>
>> Please send your comments to the netmod mailing list.
>>
>>
>>
>> Positive comments, e.g., "I've reviewed this document and
>>
>> believe it is ready for publication", are welcome!
>>
>> This is useful and important, even from authors.
>>
>>
>>
>> Thank you,
>>
>> Netmod Chairs
> .
>


From nobody Tue Sep 12 04:10:02 2017
Return-Path: 
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 3E7D4133030 for ; Tue, 12 Sep 2017 04:10:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 CIe0IOoFJbEP for ; Tue, 12 Sep 2017 04:09:59 -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 508DC132D4A for ; Tue, 12 Sep 2017 04:09:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1590; q=dns/txt; s=iport; t=1505214599; x=1506424199; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=1LlKyFMdIeFZQcWpaGh27oyiyIeEgr+fCW8zMaGYlB8=; b=MZRLnNmptut2tiO8y8BhcE2wMgvYWJKCP2JYEY4pW/VGIUE0Kj0jq/Up EFLDQlUYu7MRKzQnMkVZ6/Fz2LZk0xxZkEE0KWdrNxa5Un0/sIW6KK9H4 brBpua5/ubiHYw0FgNV/LJiVtp4LKF5J+CkEF7y8YvHbttoTmufdoEo2H 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BLBACkv7dZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhS2EHosVkHcrmDsKhT4ChHgUAQIBAQEBAQEBayiFGAEBAQMBIw8?= =?us-ascii?q?BBVELDgoCAiYCAlcGAQwIAQGKJQiqaYInizIBAQEBAQEBAwEBAQEBASKBDoIdg?= =?us-ascii?q?1KCDoJ9iAqCYQWgdZRSi1WHHY1Yh1WBOTYhgQ0yIQgcFYdmP4pDAQEB?=
X-IronPort-AV: E=Sophos;i="5.42,382,1500940800"; d="scan'208";a="654557128"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Sep 2017 11:09:57 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v8CB9vEH001241; Tue, 12 Sep 2017 11:09:57 GMT
To: Kent Watsen , Lou Berger , netmod WG , "j.schoenwaelder@jacobs-university.de" 
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <10476e00-0169-4258-449f-22cc7ca978a8@cisco.com>  <20170911172745.qzsvoluaodfcnb3c@elstar.local>
From: Robert Wilton 
Message-ID: <845a704c-9e4c-73d1-583e-f521aeefe4b6@cisco.com>
Date: Tue, 12 Sep 2017 12:09:57 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170911172745.qzsvoluaodfcnb3c@elstar.local>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Sep 2017 11:10:01 -0000

On 11/09/2017 18:27, Juergen Schoenwaelder wrote:
> On Mon, Sep 11, 2017 at 05:12:42PM +0000, Kent Watsen wrote:
>>     The contents of  are related to the 'config true'
>>     subset of , such that a client can determine to what
>>     extent the intended configuration is currently applied by checking
>>     whether the contents of  also appear in .
>>
> Editorial: Should this not be "The content of  is" and "the
> content of "?
I think "contents of  are" is correct because the elements can 
be enumerated.  We also seem to use "contents" in other places in the draft.

>
> There are several possible pitfalls here since (i)  can
> change anytime, (ii) it might not be easy/possible to obtain a
> consistent snapshot of , and (iii) dynamic datastores can
> provide values that "overwrite"  and hence comparing values
> may not really be sufficient. As long as the text is understood as
> additional explanation and not used to write naive code to determine
> how much of  has been applied, it is fine. Otherwise, it
> may be a source of future problems.
One tweak could be to change "applied" to "in use":

    The contents of  are related to the 'config true'
    subset of , such that a client can determine to what
    extent the intended configuration is currently in use by checking
    whether the contents of  also appear in .

Is this better?

Thanks,
Rob

>
> /js
>


From nobody Tue Sep 12 04:18:14 2017
Return-Path: 
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 7B1DF1333C9 for ; Tue, 12 Sep 2017 04:18:13 -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 zrYcicYhZJpc for ; Tue, 12 Sep 2017 04:18:11 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35529133030 for ; Tue, 12 Sep 2017 04:18:11 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 0CB026AA; Tue, 12 Sep 2017 13:18:10 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id hkBnislM26Sv; Tue, 12 Sep 2017 13:18:03 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 12 Sep 2017 13:18:09 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E06A8200E8; Tue, 12 Sep 2017 13:18:09 +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 AL_QgP6rzmTt; Tue, 12 Sep 2017 13:18:09 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4A08D200E2; Tue, 12 Sep 2017 13:18:09 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id F31AE40F1136; Tue, 12 Sep 2017 13:18:07 +0200 (CEST)
Date: Tue, 12 Sep 2017 13:18:07 +0200
From: Juergen Schoenwaelder 
To: Robert Wilton 
Cc: Kent Watsen , Lou Berger , netmod WG 
Message-ID: <20170912111807.q24uqw26jhz6zba4@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Robert Wilton , Kent Watsen , Lou Berger , netmod WG 
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <10476e00-0169-4258-449f-22cc7ca978a8@cisco.com>  <20170911172745.qzsvoluaodfcnb3c@elstar.local> <845a704c-9e4c-73d1-583e-f521aeefe4b6@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <845a704c-9e4c-73d1-583e-f521aeefe4b6@cisco.com>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Sep 2017 11:18:13 -0000

On Tue, Sep 12, 2017 at 12:09:57PM +0100, Robert Wilton wrote:
> > 
> > There are several possible pitfalls here since (i)  can
> > change anytime, (ii) it might not be easy/possible to obtain a
> > consistent snapshot of , and (iii) dynamic datastores can
> > provide values that "overwrite"  and hence comparing values
> > may not really be sufficient. As long as the text is understood as
> > additional explanation and not used to write naive code to determine
> > how much of  has been applied, it is fine. Otherwise, it
> > may be a source of future problems.
> One tweak could be to change "applied" to "in use":
> 
>    The contents of  are related to the 'config true'
>    subset of , such that a client can determine to what
>    extent the intended configuration is currently in use by checking
>    whether the contents of  also appear in .
> 
> Is this better?
>

I think this is better but the change does not address (i)-(iii) in
case someone uses this text to go and write naive code. But perhaps
nobody is ever going to do that. ;-)

/js

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


From nobody Tue Sep 12 05:23:08 2017
Return-Path: 
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 14731133036; Tue, 12 Sep 2017 05:23:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 l2xYa2hFgVEj; Tue, 12 Sep 2017 05:23:04 -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 DB8C913243A; Tue, 12 Sep 2017 05:23:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5913; q=dns/txt; s=iport; t=1505218984; x=1506428584; h=from:subject:to:message-id:date:mime-version; bh=nTolxXLJzUCNiCh2yrFowSajreZvKWsWuwg2a14tuKk=; b=HZBRMgRlHeQ70oRYTtXNFqp+8xA+qpfBArxCa4yW4GERb4EGBH/dQaOG mUW7c5hpxG5lIqQMrE/I9SraUd0uu2gCswEgib1HjCRc+8O/tUDFTFysv zLKznY6KAL9YtU4wJ5Jj4BjBINiqX8LLOzzy/byhxd9jYOoqxIXJBpNbL 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DnBQA10bdZ/xbLJq1DEQkaAQEBAQIBA?= =?us-ascii?q?QEBCAEBAQGEP24ng3eLFZB4kRWFTYIECiWKGBUBAgEBAQEBAQFrKIVCb0QCXwE?= =?us-ascii?q?MCAEBii0QMoxsnGh+gicniwwBAQEBBgEBAQEBI4Mrg1KCDoJIg1yBFQMOFIMpg?= =?us-ascii?q?mEFig+WZodbg1qJHYITW4UNg1qHHY1YhDODIoE5NSIYdTIhCBwVSocdPjYBigw?= =?us-ascii?q?BAQE?=
X-IronPort-AV: E=Sophos;i="5.42,383,1500940800";  d="scan'208,217";a="654558821"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Sep 2017 12:23:01 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8CCMxqE023796; Tue, 12 Sep 2017 12:23:01 GMT
From: Benoit Claise 
To: NETMOD Working Group , draft-ietf-netmod-syslog-model@ietf.org
Message-ID: 
Date: Tue, 12 Sep 2017 14:23:00 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------BCA14E3A7A69EBEB1335AB34"
Content-Language: en-US
Archived-At: 
Subject: [netmod] AD review: draft-ietf-netmod-syslog-model-17
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Sep 2017 12:23:07 -0000

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

Dear all,

I understand that draft-ietf-netmod-syslog-model should be on my plate 
very soon (waiting for the WriteUp)
In order to speed up the process, here is my AD review.

- metadata: 
https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-syslog
     compilation status: passed
     (Note: Henrik is currently investigating why 
https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/# 
reports an error
     tree-type: nmda-compatible.
Note: metadata is a brand new tool under yangcatalog.org

-  Impact Analysis: 
https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-syslog
 From the impact analysis tool (this comes from the import statements), 
I see that this draft depends on:
draft-ietf-netconf-keystore-02.txt 

draft-ietf-netconf-tls-client-server-03.txt 

         and RFC7223 or RFC7223bis
         RFC 6691
Those drafts should be in normative reference section.

- Change the copyright date

   Copyright (c) 2016 IETF Trust

-
Should this type of identity ...
   identity kern {
       base syslog-facility;
       description
         "The facility for kernel messages (0) as defined inRFC 5424 .";
       }

... be
   identity kern {
       base syslog-facility;
       description
         "The facility for kernel messages (0)";
       reference
	"RFC 5424 : The Syslog Protocol";
       }

- Actually, I searched for RFC in the description: there are multiple instances that would benefit from the "reference"
Ex:
	feature structured-data,
	feature signed-messages,	
	typedef syslog-severity,

- Regarding the Security Considerations section, please follow exactly 
the template at 
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines and 
populate the  content.

- In terms of YANG doctor review 
, 
Kent, who is also the doc. shepherd, will review it.

Regards, Benoit

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


  

    
  
  
    Dear all,

    

    I understand that draft-ietf-netmod-syslog-model should be on my
    plate very soon (waiting for the WriteUp)

    In order to speed up the process, here is my AD review.

    

    - metadata: https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-syslog

        compilation status: passed

        (Note: Henrik is currently investigating why
    https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/#
    reports an error

        tree-type: nmda-compatible.

    Note: metadata is a brand new tool under yangcatalog.org

    

    -  Impact Analysis:
https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-syslog

    From the impact analysis tool (this comes from the import
    statements), I see that this draft depends on: 

            draft-ietf-netconf-keystore-02.txt

            draft-ietf-netconf-tls-client-server-03.txt

            and RFC7223 or RFC7223bis 

            RFC 6691

    Those drafts should be in normative reference section.

    

    - Change the copyright date   

    
  Copyright (c) 2016 IETF Trust

- 
Should this type of identity ...
  identity kern {
      base syslog-facility;
      description
        "The facility for kernel messages (0) as defined in RFC 5424.";
      }

... be
  identity kern {
      base syslog-facility;
      description
        "The facility for kernel messages (0)";
      reference
	"RFC 5424: The Syslog Protocol";
      }

- Actually, I searched for RFC in the description: there are multiple instances that would benefit from the "reference"
Ex: 
	feature structured-data, 
	feature signed-messages,	
	typedef syslog-severity,



    - Regarding the Security Considerations section, please follow
    exactly the template at
    https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines and
    populate the <list subtrees and data nodes and state why they are
    sensitive> 
    content.

    

    - In terms of YANG
      doctor review, Kent, who is also the doc. shepherd, will
    review it. 

    

    Regards, Benoit

  


--------------BCA14E3A7A69EBEB1335AB34--


From nobody Tue Sep 12 06:54:14 2017
Return-Path: 
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 52B1913305E; Tue, 12 Sep 2017 06:54:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level: 
X-Spam-Status: No, score=-2.02 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_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 BUa7jjjXZnYr; Tue, 12 Sep 2017 06:54:10 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0139.outbound.protection.outlook.com [104.47.40.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E592A13305D; Tue, 12 Sep 2017 06:54:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=AXTe2MHFF2iPRrvFamiXNLcJjCltp/wEfcioY1RytF0=; b=Et5OJPJT/JIO9DshpW3ASTrEmicecm0IVHqjvH1Fsk+MOheaxb329Xwazc27qv16IywwCP+isP+hWByK9YNRKWKQcQ5NiXv0pmInoLrCyjjWQdlkBGasIgn7txDBuHOc4JJdshc7VjE91ltodhXHMjKXf/7XS0g3h0l+afv6dnE=
Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB257.namprd05.prod.outlook.com (10.141.22.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Tue, 12 Sep 2017 13:54:08 +0000
Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0035.010; Tue, 12 Sep 2017 13:54:08 +0000
From: Kent Watsen 
To: Benoit Claise , NETMOD Working Group ,  "draft-ietf-netmod-syslog-model@ietf.org" 
Thread-Topic: [netmod] AD review: draft-ietf-netmod-syslog-model-17
Thread-Index: AQHTK8HnNZnzKUnV+UCAbJ+EObBeSqKxAqMA
Date: Tue, 12 Sep 2017 13:54:08 +0000
Message-ID: <61A75498-C335-48E6-B846-6F9BC4AA27D2@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.20.0.170309
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB257; 6:+IGH7oDEB1JtcviGKrYbCTXLzWRx4TxTOxlxGWzlbJThnlfZfoJABh/2pM0hmAus/8koE3My9KRg48xPIrdbsOdP7mNcfEoWd2JzawmL4/oOz9hnDYEwpKs5qNc9RF4weGfsKZpeTs3J6Li+zl6aBDfQf3OUxY3jvsMfkTWgPOEMgyV1PC3uCbNRZforEPXQZx+MfBmF28Of+QQtQbMEP5oswZWeYrKnlEeasTWC5NKm23z6R9cITlzVZgia51mqiHkn5YW9ZrJzzXEJ35AooFpm9jj535tXYNyINY7hSdrffFbD7JJ0LJECfpoYAT2xUuMI1TySr7iPAV5JKabLkA==; 5:fkjzOj48kyhmg05WSSLvzKTDX4UXRpTc9yUYIJInKzM2Vc2OXGNv6kdQPXlWjRweA7NCzsbOc7AawArgE1IpOlZKcpmruICD08mdABSw7wtth+T3vUfmxo6vDVfKbN2fkJBUl1Vu2fMqhophTj6Jvg==; 24:oILORYuB8bMZem9jwV1XaCCkCZ68TCSAFJ2rdxhCFUILnwc4KKSugsZUEKJKdPGXoSBKyRyxHbSiCbu/dOTBEaGAM4SCjnk2fmQfvgAZ2GE=; 7:dpIdC9aDVxYMaMX5EMLk2e5d0NUkC3abXo8DulpcT+95kinK0HcMkxCtTmg5TrArkAatemKORQIjwyxP1D3Guaj0xkf06U8X7zSU9ejlBTdAmdTo533V/BsfH3l2uS2fDjDvAOXfd1Fpb/1OQxN2S6XM6BDHeSecQAKWtZ/vFUrtsUILPbJBuRwHCIl6839JLhgUNm2nTsISSKSzDS7Kyf/5yRh+sC1DD6p6+/MDSco=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 4955903b-374d-4a4c-2e70-08d4f9e5bd25
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR05MB257; 
x-ms-traffictypediagnostic: BLUPR05MB257:
x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB257; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB257; 
x-forefront-prvs: 042857DBB5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(199003)(189002)(8936002)(81156014)(3280700002)(81166006)(8676002)(3660700001)(77096006)(14454004)(6506006)(6306002)(99286003)(5660300001)(6512007)(53936002)(6486002)(6436002)(105586002)(106356001)(76176999)(316002)(236005)(54896002)(50986999)(36756003)(230783001)(101416001)(25786009)(54356999)(189998001)(966005)(2900100001)(66066001)(33656002)(83716003)(2950100002)(229853002)(6116002)(4001350100001)(97736004)(83506001)(3846002)(82746002)(102836003)(7736002)(2501003)(478600001)(6246003)(606006)(2906002)(86362001)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB257; H:BLUPR05MB275.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_61A75498C33548E6B8466F9BC4AA27D2junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Sep 2017 13:54:08.0990 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB257
Archived-At: 
Subject: Re: [netmod] AD review: draft-ietf-netmod-syslog-model-17
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Sep 2017 13:54:12 -0000

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

DQoNCj4gSSB1bmRlcnN0YW5kIHRoYXQgZHJhZnQtaWV0Zi1uZXRtb2Qtc3lzbG9nLW1vZGVsIHNo
b3VsZCBiZSBvbiBteSBwbGF0ZSB2ZXJ5IHNvb24gKHdhaXRpbmcgZm9yIHRoZSBXcml0ZVVwKQ0K
DQpZZXAsIHRoaXMgb25lJ3Mgb24gbWUgLSBJJ20gbG9va2luZyBpbnRvIGl0IHRvZGF5Lg0KDQoN
Cj4gSW4gdGVybXMgb2YgWUFORyBkb2N0b3IgcmV2aWV3PGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0
Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0bW9kLXN5c2xvZy1tb2RlbC9yZXZpZXdyZXF1ZXN0Lzgz
MTcvPiwgS2VudCwgd2hvIGlzIGFsc28gdGhlIGRvYy4gc2hlcGhlcmQsIHdpbGwgcmV2aWV3IGl0
Lg0KDQpUaGlzIG9uZSBJIGFscmVhZHkgZGlkLiAgaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9y
Zy9hcmNoL21zZy9uZXRtb2QvMTBsbzQxVWQ0QTNaTjExcy0wZ09mQ2U4TlNFLiAgSSBqdXN0IG5l
dmVyIGVudGVyZWQgaXQgaW50byB0aGUgWUQgdG9vbC4gIEknbGwgZG8gaXQgcmV0cm9hY3RpdmVs
eSBub3figKYNCg0KDQpLLg0KDQo=

--_000_61A75498C33548E6B8466F9BC4AA27D2junipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: <4A25FDFFC247D448928313ABF403A13C@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg
MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0
aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt
ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5
bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt
YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy
LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNv
SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt
ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv
d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv
cmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z
dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp
bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy
aWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi
SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z
dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q291cmllcjt9DQpz
cGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250
LWZhbWlseTpDYWxpYnJpOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCgljb2xv
cjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9uOm5v
bmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLm1zb0lucw0KCXttc28t
c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y
YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0
eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj
dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu
MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls
ZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1
ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4mZ3Q7IEkgdW5kZXJzdGFuZCB0aGF0IGRyYWZ0LWlldGYtbmV0bW9kLXN5c2xv
Zy1tb2RlbCBzaG91bGQgYmUgb24gbXkgcGxhdGUgdmVyeSBzb29uICh3YWl0aW5nIGZvciB0aGUg
V3JpdGVVcCk8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PlllcCwgdGhpcyBvbmUncyBvbiBtZSAtIEknbSBsb29raW5nIGludG8gaXQgdG9kYXkuPG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+Jmd0OyBJbiB0ZXJtcyBvZiA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu
b3JnL2RvYy9kcmFmdC1pZXRmLW5ldG1vZC1zeXNsb2ctbW9kZWwvcmV2aWV3cmVxdWVzdC84MzE3
LyI+DQpZQU5HIGRvY3RvciByZXZpZXc8L2E+LCBLZW50LCB3aG8gaXMgYWxzbyB0aGUgZG9jLiBz
aGVwaGVyZCwgd2lsbCByZXZpZXcgaXQuIDxicj4NCjxicj4NClRoaXMgb25lIEkgYWxyZWFkeSBk
aWQuJm5ic3A7IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvbmV0bW9kLzEw
bG80MVVkNEEzWk4xMXMtMGdPZkNlOE5TRS4mbmJzcDsgSSBqdXN0IG5ldmVyIGVudGVyZWQgaXQg
aW50byB0aGUgWUQgdG9vbC4mbmJzcDsgSSdsbCBkbyBpdCByZXRyb2FjdGl2ZWx5IG5vd+KApjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPksuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_61A75498C33548E6B8466F9BC4AA27D2junipernet_--


From nobody Tue Sep 12 09:37:32 2017
Return-Path: 
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 C0176133083 for ; Tue, 12 Sep 2017 09:37:30 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irqCb9H0sVRd for ; Tue, 12 Sep 2017 09:37:29 -0700 (PDT)
Received: from outbound-ss-1812.hostmonster.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) (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 140A8132D8F for ; Tue, 12 Sep 2017 09:37:29 -0700 (PDT)
Received: from cmgw4 (cmgw5 [10.0.90.85]) by gproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id 9228A175C47 for ; Tue, 12 Sep 2017 10:37:28 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id 8gdQ1w01R2SSUrH01gdT2m; Tue, 12 Sep 2017 10:37:28 -0600
X-Authority-Analysis: v=2.2 cv=OZLoNlbY c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=2JCJgTwv5E4A:10 a=u07AKapRAAAA:8 a=wU2YTnxGAAAA:8 a=K52pD-1NwIsMUiPbzAMA:9 a=QEXdDO2ut3YA:10 a=SkebfZ6J2Mmvk2rLHZle:22 a=Yz9wTY_ffGCQnEDHKrcv:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:References:Cc:To:From:Subject:Sender:Reply-To: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=hHCh4wM2EYgUataQ5EOhwl1Z8UpPu9L1aH43iDolPvc=; b=ZHpXyS03lbBZnakNMRhyi0XiTt JJo5PUvpuVdZ2v4stlePh8gV4znXIaFudGRfj9jifdWYnfEnBvofX16R6grvaPoM/nCLEKpTwWKO0 2qMD5hwywhD+RzIpPi/JGLVWi;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:55654 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1droBg-003E3c-EA; Tue, 12 Sep 2017 10:37:24 -0600
From: Lou Berger 
To: Martin Bjorklund , lhotka@nic.cz
Cc: netmod@ietf.org
References: <1503929779.1715.65.camel@nic.cz> <81b138c6-9941-3313-979c-61edad7819a7@labn.net> <87shgacvrb.fsf@nic.cz> <20170830.094028.1809893324608957744.mbj@tail-f.com> <15e32791e40.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
Message-ID: 
Date: Tue, 12 Sep 2017 12:37:22 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <15e32791e40.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1droBg-003E3c-EA
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:55654
X-Source-Auth: lberger@labn.net
X-Email-Count: 3
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] schema mount open issue #1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Sep 2017 16:37:31 -0000

Hi,

The LNI/NI authors/RTG Area DT met yesterday and discussed the proposed
change as well as the other topics that came up in the subsequent
discussion.  The high order bit is that the proposed and current
definitions are adequate for our needs.  Read further if you care about
details, including confirming our understanding:

1) WRT xpath context change proposed by martin

Our understanding is that absolute paths continue to be allowed, for
example the following remains valid:

           "use-schema": [
             {
               "name": "ni-schema",
               "parent-reference": [
                 "/*[namespace-uri() = 'urn:ietf:...:ietf-interfaces']"
               ]
             }
           ]

Assuming yes, then we have no objection to the change (as it allows the
server implementor to choose how/if they support vrf name filtering.
Obviously, using the new syntax exposes the restriction to the client
which is probably desirable.)

2. parent-reference location is adequate for our needs. 
This said, we think parent-references are more appropriately contained
within the schema list and having them there will yield less complex
operational data. 

3. current mount point extension usage definition (must be in a list or
container).
Our use case is covered by always having a single mount point contained
in a container.  We don't see the need for mount point extensions within
lists or for there to ever be siblings of mount point extensions.

We don't see a need to discuss items 2 and 3 further at this time. 
Assuming  our understanding is correct, we will update the NI and LNE
draft as soon as schema mount is updated as proposed.

Lou
(as contributor and NI/LNE draft co-author)


On 8/30/2017 5:29 AM, Lou Berger wrote:
> FYI I've asked folks in the routing area, i.e., the ietf users of schema 
> mount, if they have an opinion on the node discussion. I will also do so on 
> the point I raised on parent reference location. (Which is independent from 
> your format change.) Clearly, if I'm the only one to be raising objections, 
> I'll be the one in the rough on these points.
>
> Thanks,
>
> Lou
> - as contributor
>
>
> On August 30, 2017 3:42:26 AM Martin Bjorklund  wrote:
>
>> Ladislav Lhotka  wrote:
>>> Lou Berger  writes:
>>>
>>>> Lada,
>>>>
>>>>
>>>> On 8/28/2017 10:16 AM, Ladislav Lhotka wrote:
>>>>> Lou Berger píše v Po 28. 08. 2017 v 09:40 -0400:
>> [...]
>>
>>>>>> PS is your view aligned with martin or our example?
>>>>> If you mean shifting the XPath context node to the mount point instance, 
>>> then
>>>>> yes.
>> So, going back to the original issue; does anyone have any objection
>> to changing the XPath context for parent-reference as describied in my
>> original post?
>>
>>
>> /martin
>>


From nobody Tue Sep 12 09:43:36 2017
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D56132403; Tue, 12 Sep 2017 09:43:35 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.61.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150523461503.17991.5118396528205610961@ietfa.amsl.com>
Date: Tue, 12 Sep 2017 09:43:35 -0700
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-acl-model-13.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Sep 2017 16:43:35 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

        Title           : Network Access Control List (ACL) YANG Data Model
        Authors         : Mahesh Jethanandani
                          Lisa Huang
                          Sonal Agarwal
                          Dana Blair
	Filename        : draft-ietf-netmod-acl-model-13.txt
	Pages           : 46
	Date            : 2017-09-12

Abstract:
   This document describes a data model of Access Control List (ACL)
   basic building blocks.

   Editorial Note (To be removed by RFC Editor)

   This draft contains many placeholder values that need to be replaced
   with finalized values at the time of publication.  This note
   summarizes all of the substitutions that are needed.  Please note
   that no other RFC Editor instructions are specified anywhere else in
   this document.

   Artwork in this document contains shorthand references to drafts in
   progress.  Please apply the following replacements

   o  "XXXX" --> the assigned RFC value for this draft both in this
      draft and in the YANG models under the revision statement.

   o  Revision date in model needs to get updated with the date the
      draft gets approved.  The date also needs to get reflected on the
      line with .


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-acl-model-13
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-model-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-13


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 Tue Sep 12 11:21:55 2017
Return-Path: 
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 B95E3132EBB; Tue, 12 Sep 2017 11:21:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 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_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 RrVFyzo33Mkt; Tue, 12 Sep 2017 11:21:52 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0101.outbound.protection.outlook.com [104.47.38.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C319126B6D; Tue, 12 Sep 2017 11:21:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gkLr86IDVnPcVZVKcG4VzNYaktiu15dGX1gKUmyFD0o=; b=FWEGcAvn9c+pMpX3b4xa6HJ1EjztsssZhT4qxcwYfqroaAq1xZFMsVWMWVlBdQj75QIJ9Sng6qySeaNQz5ZiXI63Tv5vZSSV0X57iymUS1QLonrIjS+w2Z4Xep3KW77Zrky7IkCWlXnbABWU8iRetYMEbcqmZQbB96QrvmNvek4=
Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB260.namprd05.prod.outlook.com (10.141.22.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Tue, 12 Sep 2017 18:21:50 +0000
Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0035.010; Tue, 12 Sep 2017 18:21:49 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
CC: "netmod-chairs@ietf.org" , "draft-ietf-netmod-rfc6087bis@ietf.org" 
Thread-Topic: WG Last Call: draft-ietf-netmod-rfc6087bis-14
Thread-Index: AQHTK/QA8+mcxSk5vUmECY2lUkQ4Og==
Date: Tue, 12 Sep 2017 18:21:49 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB260; 6:vVhXnetdueCrfHgc91i0ats/9Ix1uail7/WooDPb9S2K7FSDjZP+G6SnkP/sZfphLBnTg555+OTpiBJd2KlFxJEY0bRz1TH/RjCSMs42hj5UnbVAXX2OdhdkR6TejDJ7+GNOK7d/WJ+FqOEVMaKMmPnjUEkoB4RcK0wkeyX8sFWguVmpe8Px1yR8D60zIkePamTgoKWZpjPDqc8+YXGuIHeAUT60CpR/Z+37b7A3Fs0EPoCFr1wil444lI7V9yZRvp8DQAthP9SlZ0I7t7PEQD/B1dSGqvr+7iNppnDVnxHJP4GKQ04WOR4ST9IiT9o7d1DjN1cmHNrbNQ0PFPoXqQ==; 5:pRj/+mQ9niw8c/HzwgmS7DUnFN5YX5HVpLgy/mxhypHa3KWnDBmsM/7vKHBAdINmC6vrUDOTm7Bk+KItqvZF7UWxZJaM7+VHHgw7bZXxa5rZPyH3LY4U/iFQQE+bp4kuk/REtkRRrhIuLuWld7Pj2Q==; 24:m4U/Rv6gds1baWgQpOA1r12r/TvBpBeyP+C1XIJ9d8oPtb8sX9lmaZ01KePMFdlx/latE2dTba7R5uy6iEmxRrbC7NtOAPXbL3f2OswsLk4=; 7:3wR0QxZ6WiwZk+DIKVtRBWI7yuUa0/pZsJ3sMY3Kfzn8CBu2BWciy/e8oG/XsUdh1tUIae1BTdeGLomr5NzdLuJ0XL54xSo7tLqyFxHzO9Wt6uFknocsZGrcD/wLS+dE5x8KRFR2BUCMwOl958uDw0c7WoLg/M6YwLiHzg7aBR53DrN55CDW7k7ZMSy4weRChPxkEw1cy763Bbc0+5CK3FGORVVjPu/fGVeeOOij4P0=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 5b51adaa-a025-4b7f-9c99-08d4fa0b22b4
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR05MB260; 
x-ms-traffictypediagnostic: BLUPR05MB260:
x-exchange-antispam-report-test: UriScan:;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB260; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB260; 
x-forefront-prvs: 042857DBB5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(189002)(199003)(36756003)(478600001)(5660300001)(68736007)(33656002)(5640700003)(305945005)(54906002)(4326008)(14454004)(50986999)(2906002)(966005)(86362001)(189998001)(2900100001)(54356999)(3280700002)(6512007)(6306002)(3660700001)(101416001)(316002)(53936002)(99286003)(110136004)(2351001)(2501003)(8936002)(8676002)(25786009)(4001350100001)(450100002)(77096006)(66066001)(6486002)(97736004)(81156014)(1730700003)(81166006)(230783001)(6506006)(82746002)(7736002)(106356001)(6916009)(83506001)(102836003)(3846002)(83716003)(105586002)(6436002)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB260; H:BLUPR05MB275.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: <976E4D8BF0D634418C2F95CA11A5CE4C@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Sep 2017 18:21:49.9303 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB260
Archived-At: 
Subject: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Sep 2017 18:21:54 -0000

DQpUaGlzIHN0YXJ0cyBhIHR3by13ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uOg0KDQog
ICAgR3VpZGVsaW5lcyBmb3IgQXV0aG9ycyBhbmQgUmV2aWV3ZXJzIG9mIFlBTkcgRGF0YSBNb2Rl
bCBEb2N1bWVudHMNCiAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1u
ZXRtb2QtcmZjNjA4N2Jpcy0xNA0KDQpQbGVhc2Ugc2VuZCBlbWFpbCB0byB0aGUgbGlzdCBpbmRp
Y2F0aW5nIHlvdXIgc3VwcG9ydCBvciBjb25jZXJucy4NCg0KV2UgYXJlIHBhcnRpY3VsYXJseSBp
bnRlcmVzdGVkIGluIHN0YXRlbWVudHMgb2YgdGhlIGZvcm06DQogICogSSBoYXZlIHJldmlld2Vk
IHRoaXMgZHJhZnQgYW5kIGZvdW5kIG5vIGlzc3Vlcy4NCiAgKiBJIGhhdmUgcmV2aWV3ZWQgdGhp
cyBkcmFmdCBhbmQgZm91bmQgdGhlIGZvbGxvd2luZyBpc3N1ZXM6IC4uLg0KDQoNClRoYW5rIHlv
dSwNCk5FVE1PRCBXRyBDaGFpcnMNCg0KDQoNCg==


From nobody Tue Sep 12 11:30:04 2017
Return-Path: 
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 85C85132EC0 for ; Tue, 12 Sep 2017 11:30:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level: 
X-Spam-Status: No, score=-2.02 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 e39d-GwAlbmH for ; Tue, 12 Sep 2017 11:30:00 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0091.outbound.protection.outlook.com [104.47.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C144126B6D for ; Tue, 12 Sep 2017 11:29:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OUdH2fATtIaqLcgBKlHmAL8QxXv6qzKPa1hFrAKoaII=; b=Kd237XNxnTTTWrGZZYtotPtwCGtRp8HOQw/S1K1Q0r5aM3Iz2a+vIlIBGbqa9GuaYte3wI2IVRJGqq0uv34mWl7yPCUKXfm9Q5MIv3KLd+HWi/2NxitZx1fLGMNouoKgAvPvZM9GxZlVJVv6iozD1KZj0K2g5CrsPX80HRGvutE=
Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB945.namprd05.prod.outlook.com (10.141.204.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Tue, 12 Sep 2017 18:29:57 +0000
Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0035.010; Tue, 12 Sep 2017 18:29:57 +0000
From: Kent Watsen 
To: Benoit Claise , NETMOD Working Group 
Thread-Topic: [netmod] draft-ietf-netmod-rfc6087bis as a BCP?
Thread-Index: AQHTKwidsbGmXJI3xUq38jMsPZskJKKxUSYA
Date: Tue, 12 Sep 2017 18:29:57 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB945; 6:le8YDeMOGqvywvxyB7I0oJX7e0OiIA/42RevI1HNghZXPfn8JVXtBs3L4c+B5ROqfGVmA6+YYsbLVDLFdtyo0idIZJDviJj4IO7boVOzfe+NNKXr+CWRoTnBwV6yMrRwG9YH5SstAvR5XRjs9lAh92IT5Pv76qMw0vOtqYYt4fgie7/YBsi4fFfoPfH58lv7755Jyik1c5SvPD1uhdmNt138EpIwRacxFszsm2j2EX/rE88YOty+9NYE95NBZJMg4hS+8g72myT43GloIi+PILC2GPbFtPzl/+cSQ858ij3fzGetwoo6qCfz4HDIsQo1HPAY+8A1auELtyHK2h80+w==; 5:aMWaqYjjCHqyv6yHUeEiKmBImi6JxEVH5H8CkTJlNccxSwrd646w88ECHE+4bgbcUsZdVheAjlau3IBdNjU/t0IiXrUqt9vvWIfTxqwUGLIAKLMLU8a0CAcegppUDxDAp2MIgypsEfdkAKT8kcB5Qw==; 24:TlSixMovYMNpn6jmJI0wSnl1BJwFPIw5RTacNOR8klGYKSYVYEgbNGQFx8uE+1ym3c6BW5LEPhh7iPZTYWN9xmQt5z/PbgRBR4vkmENCvIo=; 7:BBo8vM53kaTlCZtKkyHI2+yWviIdL+HzDYQZjaqn0IOh2UcFZyBvyjBWbVXoykubE8nih66tPXdw4gbyZiMLY6A9b3eANqmbcwSJbcVbA6YmymVzXW1t3qmqt6mrh4+YF1PVWFRF+VgQFhm4ct/0B7JlLxUzNFQkI/Fv+AQMqjBtvrUwi5/GZ3poDQaneowCnqkpgltag51io0Sm5z1tDnsDD/DASXCadFOUr8bIB/4=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 4725e447-2777-4458-397b-08d4fa0c458e
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR05MB945; 
x-ms-traffictypediagnostic: BLUPR05MB945:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-exchange-antispam-report-test: UriScan:(95692535739014)(21748063052155);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB945; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB945; 
x-forefront-prvs: 042857DBB5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(199003)(54094003)(377454003)(189002)(24454002)(66066001)(229853002)(82746002)(36756003)(189998001)(97736004)(83506001)(6436002)(54896002)(86362001)(81166006)(8676002)(3660700001)(236005)(68736007)(81156014)(5660300001)(4001350100001)(83716003)(478600001)(77096006)(7736002)(2906002)(6512007)(6306002)(99286003)(9326002)(106356001)(6116002)(2900100001)(33656002)(53546010)(105586002)(101416001)(230783001)(102836003)(2950100002)(3846002)(3280700002)(8936002)(6506006)(6486002)(53936002)(76176999)(14454004)(54356999)(50986999)(25786009)(6246003)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB945; H:BLUPR05MB275.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_BF141879A1E4439F9AB252EC0B63155Fjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Sep 2017 18:29:57.8957 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB945
Archived-At: 
Subject: Re: [netmod] draft-ietf-netmod-rfc6087bis as a BCP?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Sep 2017 18:30:03 -0000

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

SGkgQmVub2l0LA0KDQpCQ1Agc2VlbXMgcmlnaHQsIGJ1dCBJIHdvbmRlciBpZiB0aGVyZSBpcyBz
b21lIHNvcnQgb2Ygc3RhYmlsaXR5IG1ldHJpYyB0aGF0IGFwcGxpZXMgdG8gQkNQcy4NCllBTkcg
c3RpbGwgc2VlbXMgdG8gYmUgZXZvbHZpbmcsIHNvIEkgY2FuIG9ubHkgaW1hZ2luZSB5ZXQgYW5v
dGhlciB1cGRhdGUgdG8gdGhpcyBkb2N1bWVudA0KaW4gdGhlIG5vdCB0b28gZGlzdGFudCBmdXR1
cmUuICBEb2VzIHRoYXQgZGlzcXVhbGlmeSBpdCBpbiBhbnkgd2F5Pw0KDQpLZW50DQoNCg0KT24g
OS8xMS8xNywgMTA6MTYgQU0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIEJlbm9pdCBDbGFpc2UiIDxu
ZXRtb2QtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+IG9u
IGJlaGFsZiBvZiBiY2xhaXNlQGNpc2NvLmNvbTxtYWlsdG86YmNsYWlzZUBjaXNjby5jb20+PiB3
cm90ZToNCg0KRGVhciBhbGwsDQoNCkknbSB3b25kZXJpbmcgaWYgaXQncyBub3QgdGltZSB0byBj
bGFzc2lmeSBkcmFmdC1pZXRmLW5ldG1vZC1yZmM2MDg3YmlzIGFzIGEgQkNQLCBhcyBvcHBvc2Vk
IHRvIGluZm9ybWF0aW9uYWwNCg0KVGhpcyB0ZXh0IHdvdWxkIG5lZWQgdG8gY2hhbmdlOg0KDQog
ICBUaGlzIGRvY3VtZW50IGlzIHNpbWlsYXIgdG8gdGhlIFN0cnVjdHVyZSBvZiBNYW5hZ2VtZW50
DQoNCiAgIEluZm9ybWF0aW9uDQoNCiAgIHZlcnNpb24gMiAoU01JdjIpIHVzYWdlIGd1aWRlbGlu
ZXMgc3BlY2lmaWNhdGlvbiBbUkZDNDE4MV0gaW4gaW50ZW50DQoNCiAgIGFuZCBzdHJ1Y3R1cmUu
ICBIb3dldmVyLCBzaW5jZSB0aGF0IGRvY3VtZW50IHdhcyB3cml0dGVuIGEgZGVjYWRlDQoNCiAg
IGFmdGVyIFNNSXYyIG1vZHVsZXMgaGFkIGJlZW4gaW4gdXNlLCBpdCB3YXMgcHVibGlzaGVkIGFz
IGEgJ0Jlc3QNCg0KICAgQ3VycmVudCBQcmFjdGljZScgKEJDUCkuICBUaGlzIGRvY3VtZW50IGlz
IG5vdCBhIEJDUCwgYnV0IHJhdGhlciBhbg0KDQogICBpbmZvcm1hdGlvbmFsIHJlZmVyZW5jZSwg
aW50ZW5kZWQgdG8gcHJvbW90ZSBjb25zaXN0ZW5jeSBpbiBkb2N1bWVudHMNCg0KICAgY29udGFp
bmluZyBZQU5HIG1vZHVsZXMuDQoNCg0KSW5kZWVkLCBpdCBzZWVtcyB0byBtZSB0aGF0IHRoZSBj
b25zaXN0ZW5jeSBpbiBZQU5HIG1vZHVsZXMgaXMgYSBwcmV0dHkgaW1wb3J0YW50IHRvcGljLg0K
DQpGZWVkYmFjaz8NCg0KUmVnYXJkcywgQmVub2l0DQo=

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

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg
MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0
aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt
ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5
bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt
YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy
LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNv
SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt
ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv
d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv
cmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z
dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp
bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy
aWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi
SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z
dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q291cmllcjt9DQpz
cGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250
LWZhbWlseTpDYWxpYnJpOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCgljb2xv
cjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9uOm5v
bmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLm1zb0lucw0KCXttc28t
c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y
YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0
eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj
dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu
MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls
ZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1
ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPkhpIEJlbm9pdCw8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPkJDUCBzZWVt
cyByaWdodCwgYnV0IEkgd29uZGVyIGlmIHRoZXJlIGlzIHNvbWUgc29ydCBvZiBzdGFiaWxpdHkg
bWV0cmljIHRoYXQgYXBwbGllcyB0byBCQ1BzLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmki
PllBTkcgc3RpbGwgc2VlbXMgdG8gYmUgZXZvbHZpbmcsIHNvIEkgY2FuIG9ubHkgaW1hZ2luZSB5
ZXQgYW5vdGhlciB1cGRhdGUgdG8gdGhpcyBkb2N1bWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5p
biB0aGUgbm90IHRvbyBkaXN0YW50IGZ1dHVyZS4mbmJzcDsgRG9lcyB0aGF0IGRpc3F1YWxpZnkg
aXQgaW4gYW55IHdheT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNh
bGlicmkiPktlbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGli
cmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+T24gOS8xMS8xNywgMTA6MTYgQU0sICZxdW90O25ldG1vZCBvbiBiZWhhbGYg
b2YgQmVub2l0IENsYWlzZSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZC1ib3VuY2Vz
QGlldGYub3JnIj5uZXRtb2QtYm91bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVoYWxmIG9mDQo8YSBo
cmVmPSJtYWlsdG86YmNsYWlzZUBjaXNjby5jb20iPmJjbGFpc2VAY2lzY28uY29tPC9hPiZndDsg
d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5EZWFyIGFsbCw8YnI+DQo8YnI+DQpJJ20gd29uZGVyaW5nIGlmIGl0J3Mgbm90IHRpbWUg
dG8gY2xhc3NpZnkgZHJhZnQtaWV0Zi1uZXRtb2QtcmZjNjA4N2JpcyBhcyBhIEJDUCwgYXMgb3Bw
b3NlZCB0byBpbmZvcm1hdGlvbmFsPGJyPg0KPGJyPg0KVGhpcyB0ZXh0IHdvdWxkIG5lZWQgdG8g
Y2hhbmdlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w
cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPiZuYnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50
IGlzIHNpbWlsYXIgdG8gdGhlIFN0cnVjdHVyZSBvZiBNYW5hZ2VtZW50PG86cD48L286cD48L3By
ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IEluZm9ybWF0aW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+
Jm5ic3A7Jm5ic3A7IHZlcnNpb24gMiAoU01JdjIpIHVzYWdlIGd1aWRlbGluZXMgc3BlY2lmaWNh
dGlvbiBbUkZDNDE4MV0gaW4gaW50ZW50PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i
c3A7IGFuZCBzdHJ1Y3R1cmUuJm5ic3A7IEhvd2V2ZXIsIHNpbmNlIHRoYXQgZG9jdW1lbnQgd2Fz
IHdyaXR0ZW4gYSBkZWNhZGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgYWZ0
ZXIgU01JdjIgbW9kdWxlcyBoYWQgYmVlbiBpbiB1c2UsIGl0IHdhcyBwdWJsaXNoZWQgYXMgYSAn
QmVzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBDdXJyZW50IFByYWN0aWNl
JyAoQkNQKS4mbmJzcDsgVGhpcyBkb2N1bWVudCBpcyBub3QgYSBCQ1AsIGJ1dCByYXRoZXIgYW48
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgaW5mb3JtYXRpb25hbCByZWZlcmVu
Y2UsIGludGVuZGVkIHRvIHByb21vdGUgY29uc2lzdGVuY3kgaW4gZG9jdW1lbnRzPG86cD48L286
cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGNvbnRhaW5pbmcgWUFORyBtb2R1bGVzLjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbmRlZWQsIGl0IHNlZW1zIHRvIG1lIHRoYXQgdGhlIGNv
bnNpc3RlbmN5IGluIFlBTkcgbW9kdWxlcyBpcyBhIHByZXR0eSBpbXBvcnRhbnQgdG9waWMuPGJy
Pg0KPGJyPg0KRmVlZGJhY2s/PGJyPg0KPGJyPg0KUmVnYXJkcywgQmVub2l0PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_BF141879A1E4439F9AB252EC0B63155Fjunipernet_--


From nobody Tue Sep 12 14:50:25 2017
Return-Path: 
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 3E89E12421A; Tue, 12 Sep 2017 14:50:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 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_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 oJpTltFUsmid; Tue, 12 Sep 2017 14:50:22 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0133.outbound.protection.outlook.com [104.47.33.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCBF3124205; Tue, 12 Sep 2017 14:50:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=r+j+FAlqzg4VuxfXNoOYnPJXAGrAq9MnJu4JnOBssQg=; b=CD8s0UbPsPt4Z5AdXee8NtgzWw3VDjOYtTKEUrUcM0hXcOyW22ul/2GJRUc3s1vGpnRQEtBJHoffpJ7hNDYUgV91vug2lXn1FgLtaSj08oVTgCFDAxhSU/xH2loBorqQXsEdR7N2cqfueR0FtCy3xncnL9iWMWua1enxDnOiIaI=
Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB594.namprd05.prod.outlook.com (10.141.203.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Tue, 12 Sep 2017 21:50:19 +0000
Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0035.010; Tue, 12 Sep 2017 21:50:19 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
CC: "draft-ietf-netmod-syslog-model@ietf.org" 
Thread-Topic: syslog-model-17 shepherd writeup issues
Thread-Index: AQHTLBEghRxUJgbMt0OysnDENPmNnw==
Date: Tue, 12 Sep 2017 21:50:19 +0000
Message-ID: <49B4BE2F-6912-49BE-9E4A-830146309AB2@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB594; 6:53OnLSRw0nR1BEHQ/vbQxQPcvngXaD/jcBehl3tLD/9S3RJMaOnpzUU1iOK0bkD17PYWQ/2zrtqEAlpCcHYeSnWCh1M5vLOZD5v2bmighfY83w9GFE5PNrskgHZY8Xvzoo5lWybKUtiwyi4zjq5YOO543j73ucpATCdIBWkCJ+Fr2F5eOTQ+Z4/miH2lWgZw2ihgGyHBSQ3HGc22L90DQRex55vL58xmQ/WT1kWyZI///MjLa9FZRdZVuBJkTL4y2taR7ipb3pv73bjVcyA0eB3Cw68bO0J4dYdQSRkoVcsUFtUPOnPMKyWBEjiG4kTIbGhm8J+1wlgTJAS0CoPr/w==; 5:7iA15UPInRssgxjkTx76q6LQRN6txhzKeUVBkI4027RSlkuK21zIFpZXYGl6doG7esG2kbUY+dYYy/oeYFtz3/tPrQaMlW0LCM4znKDD0tMCxoBXb19XeDC6rDoPnyoXVMVHZIrLX+M2vdS4+kC8Ag==; 24:Y8iq+4F+m0V3NbpmH13GCjUVUnQj4mzYY1YxzPRWmzcaLXF8aD0ht4TsQ9VS2tS3iTSKTjIVa4/k25A+NwK/F0dYU1Inb/BCcdIai8hbXO0=; 7:oU+cpWEBZ2Y9Y8doYPuMscLrcesci1w/wTtp9yJI0nvV4cpZ7K7BF/7W1tdNJhkLRWWgwa3hc+2LbWV8y3Ixw28nCe6ggRfCEcmfze+ED5leZpeGzxVAxqgdoW2rx18GWwEfbyJGJbpNXmCYUzPOl9dg09/vHrngg1wCpC6rdzPHulA5FaBIH37idD2bdECEqSeWlg3DX6BvR5tXxJU3MZKUOVBIRqQj9gD4LWRw3k8=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: c22b7af3-7dc3-4868-0265-08d4fa2842e8
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR05MB594; 
x-ms-traffictypediagnostic: BLUPR05MB594:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-exchange-antispam-report-test: UriScan:;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123555025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB594; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB594; 
x-forefront-prvs: 042857DBB5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(366002)(376002)(39860400002)(346002)(189002)(199003)(36756003)(450100002)(4326008)(3846002)(6486002)(6506006)(6306002)(83716003)(99286003)(83506001)(53936002)(25786009)(6512007)(5640700003)(110136004)(77096006)(6116002)(2501003)(6916009)(316002)(4001350100001)(97736004)(575784001)(966005)(102836003)(6436002)(50986999)(86362001)(478600001)(14454004)(101416001)(105586002)(7736002)(305945005)(8936002)(1730700003)(81156014)(54356999)(66066001)(3660700001)(3280700002)(5660300001)(33656002)(2906002)(81166006)(2900100001)(82746002)(8676002)(230783001)(2351001)(189998001)(68736007)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB594; H:BLUPR05MB275.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 Sep 2017 21:50:19.2969 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB594
Archived-At: 
Subject: [netmod] syslog-model-17 shepherd writeup issues
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Sep 2017 21:50:24 -0000

Q2x5ZGUsIGFsbCwNCiANCkluIHJldmlld2luZyB0aGUgZHJhZnQgZm9yIFNoZXBoZXJkIHdyaXRl
dXAsIEkgZm91bmQgdGhlIGZvbGxvd2luZyBpc3N1ZXMgdGhhdCBJIHRoaW5rIG5lZWQgdG8gYmUg
YWRkcmVzc2VkIGJlZm9yZSB0aGUgZG9jdW1lbnQgY2FuIGJlIHNlbnQgdG8gQmVub2l0IGZvciBB
RCByZXZpZXc6DQogDQogDQoxLiBJZG5pdHMgZm91bmQgdGhlIGZvbGxvd2luZzoNCg0KICBTdW1t
YXJ5OiAzIGVycm9ycyAoKiopLCAwIGZsYXdzICh+fiksIDMgd2FybmluZ3MgKD09KSwgMSBjb21t
ZW50ICgtLSkuDQoNCiAgICAqKiBUaGVyZSBhcmUgMiBpbnN0YW5jZXMgb2YgdG9vIGxvbmcgbGlu
ZXMgaW4gdGhlIGRvY3VtZW50LCB0aGUgbG9uZ2VzdCBvbmUNCiAgICAgICAgIGJlaW5nIDMgY2hh
cmFjdGVycyBpbiBleGNlc3Mgb2YgNzIuDQoNCiAgICAqKiBPYnNvbGV0ZSBub3JtYXRpdmUgcmVm
ZXJlbmNlOiBSRkMgNjAyMSAoT2Jzb2xldGVkIGJ5IFJGQyA2OTkxKQ0KDQogICAgKiogRG93bnJl
ZjogTm9ybWF0aXZlIHJlZmVyZW5jZSB0byBhbiBIaXN0b3JpYyBSRkM6IFJGQyA2NTg3DQogDQog
ICAgPT0gTWlzc2luZyBSZWZlcmVuY2U6ICdSRkM1NDI1JyBpcyBtZW50aW9uZWQgb24gbGluZSAz
NTksIGJ1dCBub3QgZGVmaW5lZA0KICAgICAgICAgJ1tSRkM1NDI1XSwgW1JGQzU0MjZdLCBbUkZD
NjU4N10sIGFuZCBbUkZDNTg0OF0uLi4uJw0KDQogICAgID09IFVudXNlZCBSZWZlcmVuY2U6ICdS
RkM3ODk1JyBpcyBkZWZpbmVkIG9uIGxpbmUgMTQwNiwgYnV0IG5vIGV4cGxpY2l0DQogICAgICAg
ICAgcmVmZXJlbmNlIHdhcyBmb3VuZCBpbiB0aGUgdGV4dA0KICAgICAgICAgICdbUkZDNzg5NV0g
IEJpZXJtYW4sIEEuLCBCam9ya2x1bmQsIE0uLCBhbmQgSy4gV2F0c2VuLCAiWUFORyBNb2R1bGUg
TC4uLicNCg0KICAgICA9PSBVbnVzZWQgUmVmZXJlbmNlOiAnUkZDNjI0MicgaXMgZGVmaW5lZCBv
biBsaW5lIDE0MzUsIGJ1dCBubyBleHBsaWNpdA0KICAgICAgICAgIHJlZmVyZW5jZSB3YXMgZm91
bmQgaW4gdGhlIHRleHQNCiAgICAgICAgICAnW1JGQzYyNDJdICBXYXNzZXJtYW4sIE0uLCAiVXNp
bmcgdGhlIE5FVENPTkYgUHJvdG9jb2wgb3ZlciBTZWN1cmUgU2guLi4nDQoNCg0KMi4gYHJmY3N0
cmlwYCBleHRyYWN0ZWQgImlldGYtc3lzbG9nLnlhbmciLCAgd2hpY2ggaXMgbWlzc2luZyAiQHl5
eXktbW0tZGQiIGluIGl0cyBuYW1lDQoNCjMuICBuZWl0aGVyIGBweWFuZ2Agbm9yIGB5YW5nbGlu
dGAgZm91bmQgYW55IGVycm9ycyB3aXRoIGlldGYtc3lzbG9nLnlhbmcuICAgIHB5YW5nIHNheXMg
DQogICAgICBmb3IgdmVuZG9yLXN5c2xvZy10eXBlcy1leGFtcGxlOiBzdGF0ZW1lbnQgImlkZW50
aXR5IiBtdXN0IGhhdmUgYSAiZGVzY3JpcHRpb24iIA0KICAgICAgc3Vic3RhdGVtZW50Lg0KDQo0
LiB0ZXN0aW5nIHRoZSBleGFtcGxlcyBpbiB0aGUgZHJhZnQgYWdhaW5zdCB5YW5nbGludDoNCiAg
ICAgIC0gZm9yIGJvdGggZXhhbXBsZXM6IE1pc3NpbmcgZWxlbWVudCdzICJuYW1lc3BhY2UiLiAo
L2NvbmZpZykNCiAgICAgIC0ganVzdCByZW1vdmluZyB0aGUgIjxjb25maWc+IiBlbGVtZW50IGVu
dmVsb3AgcmVzb2x2ZXMgdGhpcyBlcnJvci4NCg0KNS4gdGhlIDJuZCBleGFtcGxlIHVzZXMgSVAg
YWRkcmVzcyAiMjAwMTpkYjg6YTBiOjEyZjA6OjEiLCBidXQgdGhpcyBTSE9VTEQgYmUgYQ0KICAg
ICBkb21haW4gbmFtZSAoZS5nLiwgZm9vLmV4YW1wbGUuY29tKQ0KDQo2LiBpbiB0aGUgWUFORyBt
b2R1bGUsIGFueXdoZXJlIHlvdSBoYXZlIGFuIFJGQyBsaXN0ZWQgaW4gYSAnZGVzY3JpcHRpb24n
IHN0YXRlbWVudCwNCiAgICAgdGhlcmUgc2hvdWxkIGJlIGEgJ3JlZmVyZW5jZScgc3RhdGVtZW50
IGZvciB0aGF0IFJGQy4NCg0KNy4gaW4gdGhlIHRyZWUgZGlhZ3JhbSwgdGhlIGxlYWZyZWZzIG5v
IGxvbmdlciBpbmRpY2F0ZSB3aGF0IHRoZXkgcG9pbnQgYXQsIHRoZXkgbm93IGFsbA0KICAgICBq
dXN0IHNheSAibGVhZnJlZiIuICBEaWQgeW91IGRvIHRoaXMgb24gcHVycG9zZSwgb3IgYXJlIHlv
dSB1c2luZyBhIGRpZmZlcmVudCB0cmVlDQogICAgIG91dHB1dCBnZW5lcmF0b3IgZnJvbSAtMTU/
DQoNCjguIFJGQzY1MzYgaXMgbGlzdGVkIGFzIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSwgYnV0IGl0
IHByb2JhYmx5IHNob3VsZCBiZSBpbmZvcm1hdGl2ZS4NCg0KOS4gU3RkLTEwMDMuMS0yMDA4IGlz
IGxpc3RlZCBhcyBhIG5vcm1hdGl2ZSByZWZlcmVuY2UsIGJ1dCBpdCBpcyBub3QgdXNlZCBhbnl3
aGVyZSBpbiB0aGUgZG9jdW1lbnQuDQoNCjEwLiBSRkM2MjQyIGlzIGxpc3RlZCBhcyBhbiBpbmZv
cm1hdGl2ZSByZWZlcmVuY2UsIGJ1dCBpdCBpcyBub3QgdXNlZCBhbnl3aGVyZSBpbiB0aGUgZG9j
dW1lbnQuDQoNCjExLiB0aGUgZG9jdW1lbnQgZmFpbHMgdG8gZGVjbGFyZSBpdHMgbm9ybWF0aXZl
IHJlZmVyZW5jZXMgdG8gaWV0Zi1rZXlzdG9yZSBhbmQgaWV0Zi10bHMtY2xpZW50LXNlcnZlci4N
CiAgICAgICAgTm90ZTogeW91IG1hbnVhbGx5IGVudGVyZWQgdGhlICJbUkZDIHl5eXldLCBhbmQg
W1JGQyB4eHh4XSIgcmVmZXJlbmNlc+KApg0KDQoxMi4gIFRoZSBJQU5BIGNvbnNpZGVyYXRpb25z
IHNlY3Rpb24gc2VlbXMgYXN5bW1ldHJpYy4gIEVpdGhlciBwdXQgYm90aCByZWdpc3RyeSBpbnNl
cnRpb25zIGludG8NCiAgICAgICAgc3Vic2VjdGlvbnMsIG9yIGtlZXAgdGhlbSBib3RoIGF0IHRo
ZSB0b3AtbGV2ZWzigKYNCg0KMTMuIHJldmlld2luZyB0aGUgZmluYWwgZG9jdW1lbnQgYWdhaW5z
dCBteSBvcmlnaW5hbCBZRCByZXZpZXcsIEkgaGF2ZSB0aGUgZm9sbG93aW5nIHJlc3BvbnNlcy4g
IExldCdzIGJlIHN1cmUgdG8gY2xvc2Ugb3V0IHRoZXNlIGl0ZW1zIGFzIHdlbGwuICBSZWY6IGh0
dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvbmV0bW9kLzEwbG80MVVkNEEzWk4x
MXMtMGdPZkNlOE5TRQ0KDQoxLiBvaw0KMi4gYmV0dGVyDQozLiBzaG91bGQgYmU6IHMvdGhlIG1l
c3NhZ2UvdGhlc2UgbWVzc2FnZXMvICBbUkZDIEVkaXRvciBtaWdodCd2ZSBjYXVnaHQgdGhpc10N
CjQuIGJldHRlcg0KNS4gc3RpbGwgZmVlbCB0aGUgc2FtZSB3YXksIGJ1dCBubyBiaWdnZWUNCjYu
IGJldHRlciwgYnV0IGZyb20gODE3NCwgeW91IHNob3VsZCBhZGQgdGhlIHBhcnQgIndoZW4sIGFu
ZCBvbmx5IHdoZW4sIHRoZXkgYXBwZWFyIGluIGFsbCBjYXBpdGFscywgYXMgc2hvd24gaGVyZS4i
DQo3LiBmaXhlZA0KOC4gZml4ZWQNCjkuIHlvdSBkaWQgd2hhdCBJIGFza2VkLCBidXQgdGhlIHJl
c3VsdCBzdGlsbCBpc24ndCBzYXRpc2Z5aW5nLi4uDQoxMC4gc29tZSBpbXByb3ZlbWVudHMgbWFk
ZSBpbiB0aGlzIGFyZWEsIGJ1dCBteSBhc2sgd2Fzbid0IGFtb25nIHRoZW0NCjExLiBiZXR0ZXIN
CjEyLiBiZXR0ZXIsIGJ1dCBJIHRoaW5rIHRoZSA0dGggbGluZSBzaG91bGQgYmUgaW5kZW50ZWQg
dG9vLCByaWdodD8NCjEzLiBiZXR0ZXIsIGJ1dCBJIHdpc2ggeW91IGNhbGxlZCBTMS4zICJUcmVl
IERpYWdyYW0gTm90YXRpb24iDQoxNC4gZml4ZWQNCjE1LiBmaXhlZA0KMTYuIGZpeGVkDQoxNy4g
ZmluZQ0KMTguIHN0aWxsIGEgd2VpcmQgbGluZSBicmFrZSBoZXJlLiAgdHJ5IHB1dHRpbmcgdGhl
IHF1b3RlZCBzdHJpbmcgb24gdGhlIG5leHQgbGluZS4NCjE5LiBmaXhlZA0KMjAuIGZpeGVkDQoy
MS4gbm90IGZpeGVkIChyZTogeWFuZy1zZWN1cml0eS1ndWlkZWxpbmVzKQ0KMjIuIGZpbmUNCg0K
DQpQUzogcGxlYXNlIGFsc28gYmUgc3VyZSB0byBmb2xsb3ctdXAgd2l0aCBCZW5vaXQgb24gaGlz
IEFEIHJldmlldy4gDQoNClRoYW5rcywNCktlbnQgIC8vIHNoZXBoZXJkICYgeWFuZyBkb2N0b3IN
Cg0KDQoNCg==


From nobody Wed Sep 13 00:30:50 2017
Return-Path: 
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 134371341D8 for ; Wed, 13 Sep 2017 00:30:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.196
X-Spam-Level: 
X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqXhh6fl0tYl for ; Wed, 13 Sep 2017 00:30:37 -0700 (PDT)
Received: from mailout4.samsung.com (mailout4.samsung.com [203.254.224.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 480F21341DA for ; Wed, 13 Sep 2017 00:30:37 -0700 (PDT)
Received: from epcas5p4.samsung.com (unknown [182.195.41.42]) by mailout4.samsung.com (KnoxPortal) with ESMTP id 20170913073035epoutp0426ffb2be8aa5621ca40ef20db3b4b75c~j20_Hv0PM1635216352epoutp04w for ; Wed, 13 Sep 2017 07:30:35 +0000 (GMT)
Received: from epsmges5p2new.samsung.com (unknown [182.195.42.74]) by epcas5p2.samsung.com (KnoxPortal) with ESMTP id 20170913073034epcas5p23074a2128d3e4c77860b7ed6180e2664~j209yRUhj2711027110epcas5p2k; Wed, 13 Sep 2017 07:30:34 +0000 (GMT)
X-AuditID: b6c32a4a-f79896d000000f29-a1-59b8de9a0ba0
Received: from epcas5p3.samsung.com ( [182.195.41.41]) by epsmges5p2new.samsung.com (Symantec Messaging Gateway) with SMTP id 38.F4.03881.A9ED8B95; Wed, 13 Sep 2017 16:30:34 +0900 (KST)
Mime-Version: 1.0
Reply-To: sk.srivastav@samsung.com
Sender: Sudhanshu Kumar Srivastav 
From: Sudhanshu Kumar Srivastav 
To: "netmod@ietf.org" 
CC: KARTHIKEYAN SUBRAMANIAM , "cpgs ." 
X-Priority: 3
X-Content-Kind-Code: NORMAL
X-Drm-Type: N,general
X-EPLocale: en_US.EUC-KR
X-EPWebmail-Msg-Type: personal
X-Msg-Generator: Mail
X-Msg-Type: PERSONAL
X-Reply-Demand: N
X-Sender: =?utf-8?B?U2Ftc3VuZyBFbGVjdHJvbmljcxtTUkktQg==?= =?utf-8?B?YW5nYWxvcmUtQ1UbQ2hpZWYgRW5naW5lZXI=?=
X-Sender-IP: 107.110.12.116
X-Local-Sender: =?UTF-8?B?U3VkaGFuc2h1IEt1bWFyIFNyaXZhc3RhdhtTUkktQmFuZ2Fsb3JlLUNV?= =?UTF-8?B?G+yCvOyEseyghOyekBtDaGllZiBFbmdpbmVlcg==?=
X-Global-Sender: =?UTF-8?B?U3VkaGFuc2h1IEt1bWFyIFNyaXZhc3RhdhtTUkktQmFuZ2Fsb3JlLUNV?= =?UTF-8?B?G1NhbXN1bmcgRWxlY3Ryb25pY3MbQ2hpZWYgRW5naW5lZXI=?=
X-Sender-Code: =?UTF-8?B?QzEwGxtDMTBJRDAxSUQwMTA5MTU=?=
Message-ID: <20170913073034epcms5p3ba5e2a0c180d8cd9f4464d8e5921d106@epcms5p3>
Date: Wed, 13 Sep 2017 07:30:34 +0000
X-CMS-MailID: 20170913073034epcms5p3ba5e2a0c180d8cd9f4464d8e5921d106
Content-Type: multipart/related; boundary="----KDChRjkJxjrsvNJceTBzCOP9dW89Budi4PBY5VECe33LSM-3=_5db6d_"
X-CPGSPASS: Y
X-MTR: 20170913073034epcms5p3ba5e2a0c180d8cd9f4464d8e5921d106
CMS-TYPE: 105P
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBKsWRmVeSWpSXmKPExsWy7bCmpu6sezsiDb4u1rZ4eUjTYsGkH8wW 8y82sjoweyxZ8pPJo2/LKsYApigum5TUnMyy1CJ9uwSujKerN7IW3O5hrti+JrOBcUMTcxcj J4eEgInEsV+bmCBsMYkL99azdTFycQgJ7GaU+Pz0A3sXIwcHr4CgxN8dwiA1wgKmEjdmLmQD sYUElCQaV/SyQMRtJA59P8YKYrMJWEk86T8PZosIqEvM3LkerJ5ZIEzi0tVbUHt5JWa0P2WB sKUlti/fyghhi0rcXP2WHcKWkFi98DkbhC0nMe3rGmaYmvfH5kPVi0i03jsLFReUePBzN1Q8 V6JjfzszzPy//44wgvwlIdDNKPHqyi0oZwqjxP6TT6A2mEtc7u8F6+YV8JWYc7EbrJtFQFXi 5I4XrKCAkBBwkfi7TAHimSyJa1uus8A807DxN9TRthI3Z+5mgajhk+j9/QQauGoSZ+88YIOp 3zHvCdMERuVZiOCdhWQqhK0h0TpnLjuErSgxpfshlG0jMfv6MRZMcVWJXweWsC5gZF/FKJla UJybnlpsWmCUl1quV5yYW1yal66XnJ+7iRGchrS8djAuO+dziFGAg1GJhzfg1vZIIdbEsuLK 3EOMKkCzHm1YfYFRiiUvPy9VSYTX6faOSCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8x3aWRgoJ pCeWpGanphakFsFkmTg4pRoYg47tyvqtn+Gz171K99zij+5sk90TbykGzZ578sbLj5Xfz2fe 6JullnaS7xDzUf0D2xtTgqxFL6u1Wiw46eGun2wyt7SLoeT0joB5n8q8nuz/tojpPmeX9Jmv U65MSGX5fYZn/wLO5bFVt1c/81f+liGivaAovuH9tMZeZk71yVGvX7QyvfETUGIpzkg01GIu Kk4EADKMi1ZLAwAA
X-CMS-RootMailID: 20170913073034epcms5p3ba5e2a0c180d8cd9f4464d8e5921d106
X-RootMTR: 20170913073034epcms5p3ba5e2a0c180d8cd9f4464d8e5921d106
References: 
Archived-At: 
Subject: [netmod]   draft-srivastav-netmod-formulae-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Sep 2017 07:30:45 -0000

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

PEhUTUw+PEhFQUQ+DQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiIGh0
dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPFNUWUxFIGlkPW15c2luZ2xlX3N0eWxlIHR5cGU9dGV4
dC9jc3M+LnNlYXJjaC13b3JkIHsNCglCQUNLR1JPVU5ELUNPTE9SOiAjZmZlZTk0DQp9DQpQIHsN
CglNQVJHSU4tQk9UVE9NOiA1cHg7IEZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFs
LCBhcmlhbDsgTUFSR0lOLVRPUDogNXB4DQp9DQpURCB7DQoJTUFSR0lOLUJPVFRPTTogNXB4OyBG
T05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCwgYXJpYWw7IE1BUkdJTi1UT1A6IDVw
eA0KfQ0KTEkgew0KCU1BUkdJTi1CT1RUT006IDVweDsgRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZB
TUlMWTogQXJpYWwsIGFyaWFsOyBNQVJHSU4tVE9QOiA1cHgNCn0NCkJPRFkgew0KCUZPTlQtU0la
RTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsLCBhcmlhbA0KfQ0KPC9TVFlMRT4NCg0KPE1FVEEg
Y29udGVudD1JRT01IGh0dHAtZXF1aXY9WC1VQS1Db21wYXRpYmxlPg0KPE1FVEEgY29udGVudD1J
RT01IGh0dHAtZXF1aXY9WC1VQS1Db21wYXRpYmxlPg0KPFNUWUxFIGlkPWtub3hfc3R5bGUgdHlw
ZT10ZXh0L2Nzcz5QIHsNCglNQVJHSU4tQk9UVE9NOiA1cHg7IEZPTlQtU0laRTogMTBwdDsgRk9O
VC1GQU1JTFk6IEFyaWFsLCBhcmlhbDsgTUFSR0lOLVRPUDogNXB4DQp9DQo8L1NUWUxFPg0KDQo8
TUVUQSBjb250ZW50PUlFPTUgaHR0cC1lcXVpdj1YLVVBLUNvbXBhdGlibGU+DQo8TUVUQSBuYW1l
PUdFTkVSQVRPUiBjb250ZW50PSJNU0hUTUwgMTEuMDAuOTYwMC4xODczOSI+PC9IRUFEPg0KPEJP
RFk+DQo8UD48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6IENvdXJpZXIiPkRlYXIgTkVUTU9EIFRl
YW0sPC9TUEFOPjwvUD4NCjxQPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogQ291cmllciI+PC9T
UEFOPiZuYnNwOzwvUD4NCjxQPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogQ291cmllciI+Jm5i
c3A7Jm5ic3A7SSBoYXZlIHN1Ym1pdHRlZCBhJm5ic3A7ZHJhZnQmbmJzcDtmb3ImbmJzcDtuZXcg
WUFORyBtb2R1bGUmbmJzcDt0aGF0IGRlZmluZXMmbmJzcDtuZXcgWUFORyBleHRlbnNpb24mbmJz
cDtzdGF0ZW1lbnRzIGFuZCBtZXRob2QgdG8mbmJzcDttb2RlbCB0aGUmbmJzcDtmb3JtdWxhZS9L
UEkncy48L1NQQU4+PC9QPg0KPFA+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiBDb3VyaWVyIj4m
bmJzcDsgUmVxdWVzdCB5b3UmbmJzcDt0byBwbGVhc2UgY2hlY2sgYW5kIHByb3ZpZGUgeW91ciBj
b21tZW50cy48L1NQQU4+PC9QPg0KPFA+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiBDb3VyaWVy
Ij48L1NQQU4+Jm5ic3A7PC9QPg0KPFA+PFNUUk9ORz48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6
IENvdXJpZXIiPkRyYWZ0IERldGFpbHM6PC9TUEFOPjwvU1RST05HPjwvUD4NCjxQPjxTUEFOIHN0
eWxlPSJGT05ULUZBTUlMWTogQ291cmllciI+TmFtZTogZHJhZnQtc3JpdmFzdGF2LW5ldG1vZC1m
b3JtdWxhZTxCUj5SZXZpc2lvbjogMDA8QlI+VGl0bGU6IFlBTkcgZXh0ZW5zaW9uIFN0YXRlbWVu
dHMgZm9yIGZvcm11bGFlIG1vZGVsaW5nPEJSPkRvY3VtZW50IGRhdGU6IDIwMTctMDktMTI8QlI+
R3JvdXA6IEluZGl2aWR1YWwgU3VibWlzc2lvbjxCUj5QYWdlczogMjg8QlI+VVJMOiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyA8L1NQQU4+PEEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry
YWZ0LXNyaXZhc3Rhdi1uZXRtb2QtZm9ybXVsYWUtMDAudHh0Ij48U1BBTiBzdHlsZT0iRk9OVC1G
QU1JTFk6IENvdXJpZXIiPmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm
dC1zcml2YXN0YXYtbmV0bW9kLWZvcm11bGFlLTAwLnR4dDwvU1BBTj48L0E+PFNQQU4gc3R5bGU9
IkZPTlQtRkFNSUxZOiBDb3VyaWVyIj48QlI+U3RhdHVzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+PEEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh
Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc3JpdmFzdGF2LW5ldG1vZC1mb3JtdWxhZS8iPjxTUEFO
IHN0eWxlPSJGT05ULUZBTUlMWTogQ291cmllciI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y
Zy9kb2MvZHJhZnQtc3JpdmFzdGF2LW5ldG1vZC1mb3JtdWxhZS88L1NQQU4+PC9BPjxTUEFOIHN0
eWxlPSJGT05ULUZBTUlMWTogQ291cmllciI+PEJSPkh0bWxpemVkOiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+PEEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y
Zy9odG1sL2RyYWZ0LXNyaXZhc3Rhdi1uZXRtb2QtZm9ybXVsYWUtMDAiPjxTUEFOIHN0eWxlPSJG
T05ULUZBTUlMWTogQ291cmllciI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNy
aXZhc3Rhdi1uZXRtb2QtZm9ybXVsYWUtMDA8L1NQQU4+PC9BPjxTUEFOIHN0eWxlPSJGT05ULUZB
TUlMWTogQ291cmllciI+PEJSPkh0bWxpemVkOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyA8L1NQQU4+PEEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv
aHRtbC9kcmFmdC1zcml2YXN0YXYtbmV0bW9kLWZvcm11bGFlLTAwIj48U1BBTiBzdHlsZT0iRk9O
VC1GQU1JTFk6IENvdXJpZXIiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwv
ZHJhZnQtc3JpdmFzdGF2LW5ldG1vZC1mb3JtdWxhZS0wMDwvU1BBTj48L0E+PC9QPg0KPFA+PFNQ
QU4gc3R5bGU9IkZPTlQtRkFNSUxZOiBDb3VyaWVyIj48L1NQQU4+Jm5ic3A7PC9QPg0KPFA+PFNQ
QU4gc3R5bGU9IkZPTlQtRkFNSUxZOiBDb3VyaWVyIj5SZWdhcmRzPC9TUEFOPjwvUD4NCjxQPjxT
UEFOIHN0eWxlPSJGT05ULUZBTUlMWTogQ291cmllciI+U3VkaGFuc2h1PC9TUEFOPjwvUD48dGFi
bGUgaWQ9Y29uZmlkZW50aWFsc2lnbmltZz48dHI+PHRkPg0KPCEtLTxwPiYjMTA7PGltZyBib3Jk
ZXI9IjAiIHNyYz0iaHR0cDovL3d3dy5zYW1zdW5nLm5ldC9wdF9pbWFnZXMvUENML3NlY3VyaXR5
aW1hZ2UvTVNJXzIwMTQwNTE5MDAzNzMyMjE0LmdpZiIvPjwvcD4mIzEwOy0tPg0KPHA+PGltZyBi
b3JkZXI9IjAiIHNyYz0iY2lkOlhPSzBMSzdDVDlTWkBuYW1vLmNvLmtyIi8+PC9wPiANCjwvdGQ+
PC90cj48L3RhYmxlPjwvQk9EWT48L0hUTUw+PGltZyBzcmM9J2h0dHA6Ly9leHQuc2Ftc3VuZy5u
ZXQvbWFpbC9leHQvdjEvZXh0ZXJuYWwvc3RhdHVzL3VwZGF0ZT91c2VyaWQ9c2suc3JpdmFzdGF2
JmRvPWJXRnBiRWxFUFRJd01UY3dPVEV6TURjek1ETTBaWEJqYlhNMWNETmlZVFZsTW1Fd1l6RTRN
R1E0WTJRNVpqUTBOalJrT0dVMU9USXhaREV3TmlaeVpXTnBjR2xsYm5SQlpHUnlaWE56UFc1bGRH
MXZaRUJwWlhSbUxtOXlad19fJyBib3JkZXI9MCB3aWR0aD0wIGhlaWdodD0wIHN0eWxlPSdkaXNw
bGF5Om5vbmUnPg==
------KDChRjkJxjrsvNJceTBzCOP9dW89Budi4PBY5VECe33LSM-3=_5db6d_
Content-Type: image/png; name="201602111742151_N3WZA6X7.png"
Content-Transfer-Encoding: base64
Content-ID: 

iVBORw0KGgoAAAANSUhEUgAAAggAAADICAIAAAAC6Y6pAAAACXBIWXMAAAsTAAALEwEAmpwYAAAK
T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU
kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX
Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB
eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt
AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3
AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX
Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+
5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk
5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd
0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA
4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA
BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph
CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5
h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+
Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM
WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ
AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io
UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp
r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ
D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb
U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY
/R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir
SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u
p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh
lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1
mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO
k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry
FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I
veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B
Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/
0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p
DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q
PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs
OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5
hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ
rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9
rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d
T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX
Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7
vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S
PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa
RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO
32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21
e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV
P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i
/suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8
IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq
YAAAOpgAABdvkl/FRgAAeCJJREFUeNrsvU1sG8fWJtxjWzdqBjINMoEvDNIXNw4VYCCLeD0bAsRg
TC0GsLjwhgt5QS7DLCJAwAgCZF2tFEUYQcBooAzg9pJcSMDLjRdkgG8hevES4CxeYyhrMSHjzMRs
GPHnkGPKE7Zz9cn3WzxX55arqotNUvJPUgdBYNPd1adOVZ2/OvXUv/nb3/5maNKkSZMmTcd0RotA
kyZNmjRpw6BJkyZNmrRh0KRJkyZN2jBo0qRJkyZtGDRp0qRJkzYMmjRp0qRJGwZNmjRp0qQNgyZN
mjRp0oZBkyZNmjRpw6BJkyZNmrRh0KRJkyZN2jBo0qRJk6Z3mM7+3//7f/8fgUZGRnZ2dp4+ffpv
/+2/fcMMNRqNYDDY1yu2bY+MjIyMjAz2RcuydnZ2/vVf//Xf//t/L3JSrVY3Nzf/3b/7dz6fj/2n
tbU17sc3KSJ8/b//9/++s7PDsf3bpnK5/N/+23/7j//xP76taek4ztOnT8+fP+/xxUKhcO/evVMd
owGWzFuhVqv1X//rf713796//uu/3rt3T7qm/vznP/fVF1r78/Pz58+fD4VCivUy/GodjEmPWuh/
/+//rdC3w4yyd7bpyXMbGxv4aX5+PplMJhIJ/LVarb75qWNZVjAYjEQiffXZsqzFxUXTNAf4om3b
jUYjnU5Ho1FOAVWr1cXFRelbkUiE5Pbm6e1+/XdINBkcx/n666+TyaRUAb1d3t59Me7t7bVarZWV
lcGWqnrtv+8rIpvNnqxiHJLerVRSu90ewA0Z5ouO4xiGIa7zIZvV9FsimgzdbhcT5h3k7b2gYDB4
Ulbhd7VIB1CMQ9I5tTe9trbWarVM08xkMpFIxHGcXC7XaDSgTNPptBiblMvlYrGIB1KpVCgUqlar
xWIRKwpBSbVaLRQKsVgMcUkkEslms5ZltY4pm80Wi8VyuYzJlEqlIpFIoVCo1Wrj4+O1Wg1NhUKh
QqFgGMba2lo2m63X69wrHG9sm4lEIhgMWpaF11OpVCwWY70wRFGpVAoJAfQarJKr4jhOoVCwbdsw
jGg0mk6nRRmqH1hbWzNN03GcVqsFkebzedu2SbwkT3w9k8nYto2vS0etZ4NSlkRpSx8TmTFNkx3x
Vqs1NTWFIeYGneOzWq2Wy2WsbZoqYB5yo1nXarXQBakJh3XH3MBfE4lEMpkUZ0ssFlteXp6bm0Mj
GETOgRW5ajQaNBkoO+Q4DiYkuDJNE+0bhpHP5/FFyAfmZHNzE09CFOANY2GaZjabrVar1WpVvdBE
4di2TbytrKyo1yY7oMSwZVmO46DB27dv7+7uqldQo9EoFArQCWiBY9VtHG3bxiTBmioUCouLi8Fg
kMTFjuwAa9+yLCxhcYq6eYRe5gzmrZRJqdLjFmkoFLJtO5lMsrNFqgcQEyQSibW1tUgk0m63af1C
4H0pRgXb4uvSJ8+oDUMqldrY2AgGg+h2oVBot9uLi4sbGxumaebzeXHeFIvFZDK5srIC0WMmTU1N
bWxspFKpYrHIJqk2NjbS6XSj0ajVatlsNhgMxmKxbDZbLpfL5XI2m93Y2IjFYrlcDmsVC3JjYyOR
SBSLRUxEwzCgJcvlcjqd3tjYCIVCuVxOHDxqE9IMBAKI4BYXF8kqYJbEYrFgMMjGpyyrrJTxT3Nz
c7VaDRJnJ18+n0ecu7i4SGtDdHzS6fTi4mKr1bp7924qlcKfq9Uq5IlOsUqqpyfl1qCUpUajIYpO
7JqUGfyIeRIKhWAJoIMw6JjKrNAgmWKxODk5ifZbrRaJrtVqibPOMIyVlRU8Kfa3Wq3W63VMS6gG
rEButmBNEie1Wi0ajbJWQcoVOxkwzVKpFDW4sbGxsrJCrJbL5VqtNjc3Nzc312g0dnd30Ww0GiU2
ICLHcWKxGLoJDeJloXHCYXmrVqu2bS8uLmLplUol0SsSGUabeAtGUVx0rHxyuRxYHR8fh4HM5XJg
dWVlBSrGjdVkMglWyWKVy+V6vT43N4d3xXXqce2TAfO+XjzOGcdxpEyKSk/6UTQVi8W86AFWznNz
c7RmB1CMbmxLX5c+qTIM0WgUEo9Go7ZtO45Tq9UwEWGXbNuGNInq9ToUq2mai4uLc3Nz9XodltAw
jFgsFo1GSWrQxUjuc7ESFi2+jnf39vbg6eCt8fFxKCB6BSscnlc6nRZHEcyjzVQqZZqm932UZDIp
ZdXn87VarUKhgBnP+cX1er3VauFdDK30i+Pj46FQKBgM+ny+UCiEP0PJYrDxXdZ0qUnRoJQlqejE
rkmZqdfroVAIf4VUIWrTNCGNSCQSjUYxfOxgraysgA1w2O12WebZWddoNGKxmGma9CGOEokElB2N
EZSvOFsikQgNQa1Wm5yc9MiVNCk8NzeHt6LRKL5Yq9UikQje3djYQFMkCnbSEm/oLK0Fx3EUC40T
jqhQEO4sLi6KPqmUYbSJD7ktOnY+w54ZhgE9CLWI4Ns0zVQq1Wq1YHrVrLLLPBQKkYgGW/vc9puX
9eJ9zkiZ9PhR/OhRD7BvmaaJNct107twvMtW+qQqlcRlA7FIisUia+64lKvjOGIAGwgE2DbpFUW2
EWuDczOhrdxeCYVCyWSyVqsVCgXkqeBQsJywO8w+n897vtiN1enpaRiYarUKBtjoG+1vbm66RZ2I
V9jGxQ/BE4RABuCWa1DKklR00q6JzCBXwA0QtBvlXrB4xHgUy4PSiYpZR5PKrawCCpHzVMTZEo1G
2fCFqzhQcCWdohjHRqNBnrXjOGK2QTpp2R+5BxQLTbFkEolEt9ullBQSej0ZZtt0W3QcD+xyhrRp
UNBUT1al6oLkNsDaH2y9eJwzUiY9fpQVCLfoBtA2fQnHu2ylT57zvh2Bb4sFPFyXuPAzFAqxfofj
OF5mDGwXbCwRUgpqLwCLAXk0ilSIE5a3brc7/D4Y8nSpVArJk1wux0YqaF8sw5D6HW4TDpo6EAis
rKwsLy8PybCCJVF0XNeQhOWYCYVCyC+zSg3ePfxTt2TX5uYmPKPFxUUxJ8nNOjj7oiNCE6PRaCA0
SSQSitbgLGNCitPYO1dY5+hmKpWizS1x/g9AXhaaW1ybTCaR3ikWi4hd1Az3XHTi5Gm325weabVa
7Oh4X1amaZJSZv3FAdZ+v+ulrzkjMtnXR90W3WDr16NwvMu2VquJT57pi6dIJFIqlTD1C4XC8vIy
JykEMphz+Xx+eXkZ6hi/VKtVhC1unwgEAmgwGo0iqY235ufnWe3DqWb0h30MbLCuDdpETpz2DxWc
BINBRRqB3enF9jUCMc6fHR8fN00TKXvHcTY3N/Gwd7JtOxgMYsGLuyYDkJQlqejErkmZGR8fJy+7
XC5j+PAjBh0lDJwawrdge/b29txSDTTrqtUqNt+kMXij0YC+m5ycFPWdGDTUarV6vS6OvhtXNBlo
soGZaDSKqJS4ikajjUYDziMJcIDF33OhiRO1UChQqQgGkZ2NbgxzklEvOkweGuv5+XkYbLje2FMM
BoP4uhfCWOArFB4NsPYHWC/e54yUyb4W6fB6YADF6F220ifP9cVfJpPJ5XJra2sYFRSlcOm2ZDKJ
KBgPoMSC4mKqSnJTW8VisdVqzc3NdbtdEh/yGNLYEAn0zc3NdDqdSCTolUQiwa18xNp4AJ4+5+1y
HSkWizjboRAIagaQM6HdMHaFZ7NZxQM9KZFI2LYNHwQVIKgvGsbjEFkKBoOtVosTXTAY5B6DD8Ix
Q+UchUKBGItEIig0oC1fLkiKxWK1Wg3BNbw27E65zTrLsjDrpH1PpVK5XG5+fh4pFHHrixtZKBQx
TeTGFU2GlZUVJKO63S7Nc+x8YPcS44UWILSehmqwhSZOVFQl4RWk+9lXoLlEht0WCC06bvJkMhma
FXgA1Qo0Oul02rtfnEgkaOLRyErZ6Ln2+10v3ueMlMm+FunwemAAxehdtij84578N3/7298MTZpO
iLhjku8m5fP5QCCgNvmaNP2eSWMlaRqKKKVAKcQ3eT5zAELZjPcSL02afod0TotA0zAUi8Xq9TqS
J8hgvDtwESJhax3llXrsNGlyI51K0qRJkyZNr5FOJWnSpEmTpoEMQ6PRmJ+fd6vRLpfLKEvw0sj8
/PzJQreiWa6+SPrj26LnOzvfXbki/offn+/s9NVa27J+uH7d7V8Pm80frl//7sqVp0tLp9Sdo07n
5f6+YRjNTOb0vnJSNICEQU+XlhRydqOTkgnYVo/1iXBFnxhYUOrvNl3QitbW1uYFsiwLdbeDaRjj
uOb4jZFaMYo0jPaDcN5Aj4w3vMeAM7SKc0+/VbowM3NhZsYwjG6l0sxkwrmcLx6HEh+gtUA2G3AH
6X1RKh02m58+eHDW7z8lq/C/EomPFhZGJybCJ3G0QtMbIMVIqafT6RGhQKJQknCnpbqPDmD2VJ1v
GJ66Xwz8YeDBs6c/TITi/kZTSd1u913emfzN0Eg4fEpWwTCMVwcHR52OFrKmd5DePDz1b4wo9Dkn
RVdWYyZLgVsNwwDYDmFCENIkGfPGMS0uLnII2DhxU61WAXmfzWapWSlcsOECKiv+yDUrQnNLIY7F
PrpBjrtJwzu9KJUQ5o9OTFz65puRcPjl/v7TpSWka8ampy9tbXGx//Pt7U/u3//h+nUYgJf7+2f9
/ktbWy/395+tryMt8Mn9+79UKj+vr0OPf7ywEMhmEbKMTky83N//eGHh2fq6Lx7vVioIa/y3btmZ
zFGn44vH4WO2LQsNGobhi8cvbW0h7fB0aelVp/NLpfKHcPji6irH8MWvvnp1cPDD9eu+ePzw8ePD
ZpO6xiZqXnz7LTp71u8P5XKd7e3nOzvoiC8ef76z075zB0HV6MTExdXVw8ePn/7lL58+eEByeFEq
/enePTZlx70yOjFBgc6T2Vn01E3OF7/6SjSoz3d2fl5fNwzjo4UFhH34hZWqdFilj3UrlZ+Wlg6b
TRjvM35/OJdTsP2PGaLs+A/Xr49cvvzr/v5Rp0MtNDOZV50OxPvBxMQfwuGRy5d/qVQoemhmMh/G
44ZhYDqpOaeZMDoxcdhsIs7o2UfDMEYuXx7Ag+SAysmTVagmFrd/fHycXfUsoClgsaGsOOR/cY0j
5RWJRPBjLBYjrHIOgR8YqyxjUo0B1HF818tlBGI8hKOjbjpH+lFRybdaLRHfe29vj1Dcz0jRlRVA
2W64r8Yx+Awdw6tWq+zZY+j6WCy2uLgoImCjEYLqZbvqhm8sBZWVAuRSs8Bp4JgX8YqlMNRSJGSF
NLzT4ePHn9y//8n9+4fN5vPt7aNO58mXX57x+z979OiT+/dfPnxIqlnybrN5cXX1s0ePRsLhZ+vr
gWz244WFkXD4s0ePDh8/frq0FMhmP3v06OLq6rP1dcog++Lxzx49GpueNgzjVafz6YMHl7a2nu/s
PF1a+nO5fGlrq1upvCiVupXKs/X1S1tbaKFbqXR2dqBBLq6ukkI86nTsTAYM/+nevZcPH/58zPCr
TudP9+5R18SslP/WLTBvZzIfXL1KHTnqdH5eXx+bnkabh81m27LA8ItjQOnn29v4hVoTX6F/7ezs
/Lq//8n9+58+eHDU6eATbmyz4oV8Atns06Wlw2YTtgRSDedyz9bXXwgA1zDV4mMwTh/G4589ehT4
4gsYJDXbIHXH/65MK5WPFhY+e/TojN//5MsviX90GX/1z8x0KxVYoMNms1up+GdmvHCOmYCZNjox
AUvgpY+DJUulQOXGMQ4g4MpxkJs9rszCU7OrHjrEDYubhdN3gy53HGdlZSWdTkN33759m0PglzKm
AEL3fhmBdA9Acb+A+FEF+D+H782iuJ8R0ZUVQNlGL2xeQiizbbvVarkdI3JDwAbGmZhZk+Ibu4HK
igC51Kwb8xxesQhD7YaE3BOp2NMOxK1bI+HwSDj8wcTEy/19LN2PFxaQFLpw61bHfUvQF4/Duxyb
noaiIfqlUhkJh6G+L8zMjE1Pd45VM6tWxqanz/r9o1ev0p/xr0cHB6z9uCBoEFYlHXU6f1xdhTt5
4dat5zs70B1okLrGvXjW70ez6AL+PDY9fdTpnPX7P33wAEIYnZj44FgZjd248eLbb6GVDptNVq+5
vcJaDjjmn9y/D+PnxjablIMAA9nsWb//Ran0olQ66/fjR188PjY9DX7EKFB8DF/8aGGBRsQL238f
JveO0zhCgB8vLMCA4dNslIbBhYGBdREjJCnnv1QqoxMTaP/i6ireUvQx8MUX6CMX+ngkKVC5cYxG
B82YSCSgGRWNYNUrYLFF5H8pdDlwFQlFnFrmgKJFxtyA0Ae7jID9luJ+Ae6jCtBvBb73ORFdWQGU
bfTC5o1Go7hKSbwFhSUpArbP55Mi67rhG0tBZaUAudSslHkpXjEHQ03IoxwSck+kYi905vXFeXRw
YBjGjzdvenn3rPut9C/399ko/uz58y+PNQ6rDs64/JmyCr8+fHh0cCD1i8kthQ5lG8Enzii3Os4w
zJ8ROvJyfx+WDIEOtuvHpqebmczRV1+9KJVEvSZ9hbZYjzqdzs4OslUU7nBsvzo4YNtkBXjm/PnD
x49hYL67coW1zZKdmE5HfAyCovbPnj9Prrcb26zeV3ScnQmUXZROjwszM09mZwPZbGdn5+JXX3nk
/KjTeW2enD/v+uTBASvV0YmJv/YfNCgQtjOZzO7uLlYiILncziqyjahhsRWqADd2qIHx3RhTAKEP
dhkBaTbF/QLiR9GgFPRb8a1zInB0LBZTAGVLgVsJKQwIZWBLgUXTFwK2G76xFFRWDZDrBiws4hWL
MNSGDAm5J1LxAITFPHxZ0ejEBKvNj15XeV4IyaULMzMj4fCnDx58f+2a2143zAP+8KrTgfYchvnD
ZvPHmzfHpqfPnj//yf37lBuBC9zZ2ens7MD17vkK0ccLCx8vLCDX8Wx9HU46xzZnn14xvXh1cDBy
+TKS+Gx+383Yi49hOBAPkQfQk+2eHWf9CZI8N/psO2fOn4fbIeaj3Dh/tr6O7RkShbqPL/f3ESsQ
VydFAH2jfdBSqSReScRRX9j1oioYhjG31ga7jIDV/or7BbiPQjtxoN89M95nRHTl8fFxBVB2T9zX
WCyGGw0VoNbeEbAV+MZSUFk1QK6UeRGvmD0DQTDUUiRk7yi4fbhL8fhZv//J7CwW+Y83b7pVgqvp
w3icEtbPd3bgafbVwq8PH46Ewx8tLHy8sAB+yAywGhMM/7S0BI3glqPoi36pVODmX1xdfVEqsWmo
C7duoVNjN254fMU4PpRw2Gye9fux4+qfmenJ9sv9fXjxT5eWjjqdsenpD+Pxl/v7YODl/v4P16+3
ZRDK0scgKOxkYBenJ9tcylHacdLISOM8XVoaCYcVOZwLt2693N932zOXco4fIYq2ZcH2KPr47PU+
nmDNzPz8PEFy+Xw+Dlqf4Km5/IRHLG5RFXgnkTEFELpax/a0c4r7BcSP4vZDj6DfhOJ+TgSOxv85
oGzSd1LgVjY/NTk5iX2YnrdNeUHAdoMLdgOV7QmQKzLP4gYD7ScWi7GPAYZ6fHxcREKWNohCBbQz
SMTg94dyuadLSwjSRycmkAcfwMBcXF39eX0dq5Sqkry3gA1SBAoXZmZeHe8TjE1PPzuuRREZpqqk
YVTAhZmZF6USHFvkr4lzfP3CzAynxBWvoKbor7OzKKk66/cjUS6yLY5FZ3v76dLSWb8/nMthK4iV
6tj0tFTDcsKnxy5tbf20tPTdlStoqifbXDZJ2nEKEJ/MziKgCSuvGEI7bl6CG+cfLyw8XVp6urRE
JsftyVAu9+TLL9k+okzuwszMxYFmMqsNWNUUiUSmpqbYBwiemtWzUlhsaSgAy+EGXa4mKWNurXG4
9OrLCDiKxWIiSL66C95BvwnF/VSwkpaXl1OpVL/3T2nS5JG+v3bt4ldf9RsAvWvUzGRQmzt8x3+4
fv3DeHxIteudvrtyRVGnq+k3QCd/wK1arfp8Pm0VNJ0SPd/ZOXP+/PtoFV7u73935QpyL91KpVup
9FW08xY73ras765cQbwI/qU75Jp+M3TCkBg4ltJzO0iTpsHox5s3X+7v9+Vlvzs0OjERyGafHede
+sKieLsd98/M/FKpIN+FRNxgdaia3hfSsNuaNGnSpOk10rDbmjRp0qTpdcPQL5TrkOWYPV/HVZF9
IdlyjaOca4DXvdObwb99K2RZ1vz8vBrimCrz3P61Wq16x0k+vbnEEmpRUO84GO6x+kW0P3BfMO1P
9kkvAhweS7/fQSEw8zeAD3/YbJ4Glvgp0TCsYhNI+k8ocpNiyCtA3c/1BeU6JKqtl9d3d3cHOzJG
MFva2g9Mtm03Gg3xHN8A5BEneRhN6n24Hcf5+uuvUUw88BcVgMnU/vsFHqyGjB5gBPsalNPGh3/v
6LNHj068TQLclP6rYperv1TSkKi2Xl5nYS36olMNEX4nhMNB74V262u4gbJ5esycdvvvC/W7Bk8V
H16TYRgAcRmAzsGLTyQSIgorp6BZVFuKnYEnBSRtBJKWZWWzWdM0OaBX9nW3MAUxMl7ESQ3Cj8Uh
OADe4ru3b9+mAyNwVdACjm8UCgW8S+i1aixxwxtiLXfmpWebOI5PsL0IhvDj4uIiJDw/Pw9n07Is
oFnhTB+9BaBgAH6IzEgxeHuCgXOdTaVSjuPg1Mza2pp4Oq9cLuMwDms2FN3HiKRSqVwuRyOFw4lA
qeRexMwhMC9CgMfEAz4M1zhEt7Gx0XMUkBIpFApoBDgzhhKXWDo5aWpx2MjUvuM4ANnlZtHa2hok
gKmbyWQikUir1crn8/goi/clvi59UgzH2aWxu7srTgB2EGnEgXbcaDQwwQjZntx/KUtij4AnSoPS
05Nl8eFZpD8AhMCTxa1QF7/6auTyZREgnT29gQalTrcIay/inL/qdJ7Mzv65XIahalsWasCera+j
PHckHP7j6qpYpAuXHJeUhHO5XyoV8XnCIT/r9wO8XYqr/92VKzj9/mE8znY/lMuNhMMiaPxhs/nk
yy/RiLRIrG1ZyE3hdOGrgwPUthnHx10pnhDh089wyoJFYeU+I6LaAtxVOvAimjf3uiJaB3ZTLpcD
zDU+kT8+zEnfZRU0CxjLtkbotVj5wLnNZrPFYlFEvpMi1lqWBcTaubk5FrHWOL4oQt0mCXZlZSWb
zZJGU0f3gO5qt9sYjna7DcUnMiPF4PUCBi6Klyzo4uIiZxWANQ8QY1JMXroP7CwWiX1yclLxIrqP
OQNF32q1Go0Gl9pih1uNYAyC15JKpUiwi4uLNM8VuMTqzBLNLmo/kUhI4dkNBgWaoONhnFZWVubm
5miApK9Ln5Q67BhQ7PFwEwCDmEwmMb25TTK4gxsbG1NTUwSDr2BJ7JF0DboRiw/PWgUoSgLSAKCs
Lx7vCZCu9po5WHsR5xxQVASU+3x7e+zGjbZltS0rnMt99ujRhVu3nszOSlHED5vNi1999dmjRwAI
4Z4HNtfo1aufPXrki8eBraLA1b8wM0MA9biwZHRi4ulf/oJesLDqQHP59MED9EIqZACdwV4C0+Wz
R49QM03IBRCIf2bms0ePcEfLy/391wyDAoVVpPHxcUXOR0Tz7jen0Wg0EolEMBjEwe5WqwX1of4u
EXxDQq+t1WqE5RuJRAgeXPwuh1jrOA78RAByQI/gYY9tGsfQ4nhGvTvHasBYLBYKhWBNa7WalBkp
Bm9PMHCFeKUElGBYC/LcPXYfAFZ4vtvt4q9uL6L76DX0+97eXigUUmS31CjxUoL+onmuwCVWtGDI
sJHd4Nkxbwm3GUifjUYDyDEYTcXr4pPqJSmdAPV6HX81TXNxcZG7YRfTgB6gEfHeo5PKfgBAHo4t
bozwApCuIA7W3hXR/dggvSiVXh0c4K9j09Pw+uHCS6GfCKle+jyYB2I5rjZR4+qPTU+/OjhAcNDZ
3gYK/YtSCb2ARw/5dCsV/61bZ/3+0YkJvzsqPssnuAJW2K/HqFwIkrqVStuycLvG6MTEOW5yeB8/
9cMimndf+36YZ2QA8C1oZI9Mco8BIpst5xD5ERFr8TvHBkCmPLbJMWOaZqPRUIhCCvALVF4oII4Z
BP4cBm9PMHA38brBHTuOQ0BdcB28dx+girZt7+3tkfpze5G6DFuYSCR64oupUeI9zg3DBZe438mP
uSHCs4uv4EkaAvxB+jo3WAqviD4hnQDq3Tt26OHVKVjqayX2SyPhsC8ef1EqjYTDuKgOWlIESPfY
oIj9LsU598/MIIP04ttvoWePOp2XpdJ3vXAACZFX+vzfccgZ/PaeuPq4Gu+M3/9yfz+Uy6GndC6S
umAYxh+OZeLlmrwz7hD9l7a2WpaFT/ji8T+urp7AyedgMEheMClNEc3bLekkJXgirVYLKmP4iQhv
i/OSpHGGiFhLiwRs0BLy2KbBYIA7jgN3WPwn9VumaUL9icyIGLw9wcD7FS+LZ06j7LH72IVCBp8u
XBJf5AIpQDEiuac+SD8kgjF1nEtODkaYG17KuvAkobmxU4t7HWkf7smePRInANDlFPvn7J9pinrv
0QnS2PT0z+vruOJpdGICO6giQPpr2tZzAOGGc37W7x+7cQOpf2CJIxT4WAZy7uaSi88jyDh8/JgM
W09cfaAcHj5+zML9Xtra4u4rBKuwaq+GQ7n3xeNoB5sNz9bX+6tKkqLaQsUgOqbydhHNW/G6dGZH
IhFkdbAwgAeutk/s5BajbNzridW4trYmVuK7IdYiG4u9Nfb2IS9tsjsuwNeNRCJoAepMkc6uVqsQ
LL47Pj4uMlOr1UQM3p5g4P2Kd3x8nAa3XC5jEL13H6kGANl6fBFlzdiBl/q5NNxeEIxZUyrtnXdc
Yre5RzZJCs/uNsMxxLSlJ30dERX3pJqkEwDjC0Hl8/nl5WV2vdD4YgsdmzFuLLlJUr0G+zAMN25g
7/TCrVuGO677Wb//l0rlqNN5ub/vHd9bgXOOLBZ7K2LbshCvPN/Z+e7KFTU4sfR5ME+I5ThtoMbV
R8z0cn8fCaizfr8vHn+2vo6NhKdLSwA89sXjz7e3D5tN6b25FEn0DK1w2gN75h/G42fOnx8Jh/uL
GAjVlvWtYrFYvV5HJB6LxeBaimje7OvJZLInMHUmkyH8WNRCqB06AoyVesoczm00GhW3PXoi1tK1
EN7bpFWHFlDvgbQVXfbkFuCbpglm6LsiM6ZpSjF4RTDwYcSLnhYKBYCf99t99JH0tfRFcesF+zFu
jioN98rKiohgLNWV3BXBrJy94xIrdHGxWOx2u6xgCZ7dbYZblkVDII4LvS59UkFSNHj8AYJCy5wQ
arUa/gl1ItKpou4ROyjLy8vc5WLeCc77850duv1UCpCOi7i/v3aNnve05eCOc44taHLMcesfae2P
FxbU0IFuzxPWOn4cm55GkZUCV39sevrw8WP63KWtrSfHoPEj4fClrS3g8tqZDH4cnZiQ7j/DoqAq
SZG7Y+HTffF4IJt9a1hJlmVNTU0Nc+DovSCuMtUjtVotac3o74ps297c3DyRDI8mNaG2+506HNq2
LGww6NF5K/R2sJKwlfp+HRPV9OZtqvq6J02/YXq+ve2/dUvL4fdlGFAwp9e8Jje/YX5+HlVJWhq/
N3pRKn135cpZv/+ChxJMTadEGnZbkyZNmjS9AxGDJk2aNGl6pw3Dy/39o+HKYPulvgBmm5nMwMC8
7xHo7m+VupVKzzo/6VuGEhb4tLl9A58e7BOQDPiUFqIMw893V65wzbLFl9znPPKActI3OYh9aYxh
JDnMJBFXhLo10tJvSKf98i//8j8/+eSvjx//TZOmUyBMsF/+5V+8v/I4nf7p9u33hds3Sa07dx79
h/9wSo03/umf/t///J+ln/s/29uDaYn/7/nzxj/90//Z3tYLYZgZzmrp//nJJ29Anmf+eqJOhyZN
w9PAWMFaMsPQUafDISsM/znAjuqBG3Ic37yWPoOY64fr1xFS/XjzJk7BPd/Zwf1K+PHl/j4OyDUz
Gfz+482biL+e7+x8f+0ansTxOZw6QVPfX7sGjFn8GQEUoiEcBqFPoDUcx/juyhWwxAaGL/f30eZ3
V648mZ096nTcWOJSSQiEwQOe56QgdoGTBv25mclwbCNMbmYy1F/pSqA4nRqRMv9sfR1HIikoZgFS
frh+nWJkOkUpMu/2ozTV5tYvSPKH69ebmQyacussO2QU5D6ZncWPxD97hxSbX+pWKpDA99euPd/Z
aWYyh80m/kDBtVTmP1y//uPNm8QJF5v3NUwit/RpUZLcPKRIn/uRxhc/AsAATWEG0iekHWEbhGSw
KtEsmwAR5Y8FSJ0SJ4D4CubS06UldoLR5/DLT6+vIOJBMdnQwadLS23L4oRP7JHYpWyLgsVyJsHS
AqdXSGOIykRsbRhJKiYJmwLivsjOcFYmbCqJvtjMZAg2nHphGMaPN2/Sh446ne+vXWPPfg+8bP9h
GIBmTlf8+OLxzx498s/MiMi0f3cBOp0/3bvHYdhykK3g1X/rFjB17Uzmg6tX8WdWzXV2dn7d3//k
/v1PHzwAo8jtAoNw9OpVVkUedTpu0LscSwoz+NmjR5e2trqVCitE2C3ACoZzuWfr6/SvkAZdcoQH
nszOAgL30wcPDMMgrJXDZhM/ihAo3Url2fo6+nVxdbVbqRCeIsc8MB2hsw6bzW6lwgKkSL08Uf6K
HrmJJZzLSaF9wfxHCwvcj9TZzs4OQQ1/GI8/XVrCbOlWKn+6dw8iUvPPgRJf2toaCYcvzMyEczlW
cbvJ/OLqqji11K9ww6TgVipefAjz8EWp1LYsBZDyq07n0wcPLm1tPd/Zebq09OdyWZyB0o7QVz59
8GAkHP55fZ1DUSbmRfmDc5q9LMay2yto8+Lq6sXjU7jSz4kryE0DgKBYLq6uYhGx06ZbqWCyXThG
r5OyLUobLf8hHMZjP6+v//rwodhTqTJxa20wSXqRgPjFcC7HznCSCcsJDvcBQPDl/j5paToLLYKT
c4pigGXLbz6zRGfQpci0eADgVoRhawiQrWgBZcj4K/4MCFlOprgx45P79y9tbQEHES7Apa0tVlgK
6F2OJTcdhPMy6CArhRelEgHS4og8wbKzssafjzqdbqUS+OILXD51cXX1sNnECOE8vfTTmFhogavO
5pgfnZgYCYdhNl6USqMTE9IrOIik8lf0SCTqlxTaFw+A548XFg6bTfxInX1RKl2YmcF8vbi6etbv
f769/aJUGrtxY3RigthQbMFxoMSiWVXLnGBt2KHva5gU3ErFe9bvP2w2ny4tjRzrJgWQMsZ39OpV
+vPfBf46go3YkXAux0K5uSVkpPJnFyCHsax4pSehg9wKctMAbgsBwg9kszB41CBg4ES2RWmzy3nk
8mX4oPQKQQNJlYlba4NJ0osEFF/kZMJygvkwOjEBYyNdthw4ufhAv8tWZRhoWcLrRPqFDdJFDFso
dAQmiJKM1yFe3eBecePoi2+//fHmTURSoxMTHy8svOp08F22tADNctC74PaMt9sB3bAMX3U6R50O
RbXksHOv4Cu/vo52iwewyM+6o9pigj5dWkKE+NoACFxduHWLcOHV4YKb/BU9kiQTGRBjii6BJPP3
tXrcL3QWM4x+fLm/zyamz5w/j6/Tj9CJrhGDAEos0gAy7+sVNbeieD9eWAAyD/Kl3UqFgJQpMUIC
PyNMIfnklHGFBfjD9evP3O+lkcrfUGIsu70y8AqSaoCe3Wxb1tOlJQ5CTmRblLbIjJQxqTJxa20w
SXqRgOKLiqH/g4uLSUTg5HDpREUxwLJlc93ycwxApsV0/+T+fbXT6ovHEZJcXF399TjQ9kgfLyx8
+uDBpw8efDAxgRAskM3+6d49mFbkVUkQrJ+CMTuRfa0zfj8sM/3HJjE4+mBigt0LOnpddaqtAnrR
M7sCX+D5zs7L/X1uvKU4w6L8++oRuyDhs9N/cCjIt8UXuclAqMi02XjG7z/r95P/TnxKmYfo1Htx
A8i8r1ek3CqmN0DHkBxAzoqAlFnpDTktKTX8x+M8jJSk8le3PMArahpAAzxdWoKLShdbKjQgJ23v
jInKRNHaMGJRSGAA/s/6/V52m8empzs7O52dHYCTS12uvpYtqy7OwDRx60GBTCuaEBGy1aM04Q3h
KtQPjy9HpQAFv1BrbtC7wxuGD+Nx3MmHln+4fl2xWwsIXKS/4NPBdKs/8evDhyPh8EcLCx8vLPSc
GWjw5/V1McYUcYal8u+rR2y/OGhfzAq6hQqd5WbY2PT0850dDBmuLRybnkYCFD+yiwQh7VGnQ/yI
oMTdSmXk8mU20zKAzPt6xY1bN/FiZw+r64zfj5bVQMp9V600m4fN5tj0NJLLlJgSUZSl8u+pUDy+
4gW0GRvXbhqAvUGB0zCjV69eXF0FVLWicVHaHmXIAmWTMlG0NoAkvehA6Re5GS4OELYWjjodvC7V
0hw4uZhj7HfZvuYpfjAxMRIO/3jzJvtVpJ8QGv9SqYxNT//qYhtgD7Gkf7h+feTyZXVOmaWPFhZG
Ll9GRUrbsrBDFchmUW/QzGQC2SyxC+hdxDs/3rw5evUqoHeHJ188Tl1Ay+ouXNraAttARb/0zTec
fYJ5Yzf6A198cdbvR5HAH8LhUeVeCG3GiPMykM2iHTuTobkuyt+tR1x2zq1fGHRA+2JCP5mdRWfD
x/f9cvlADNkvlcrF1dXRiQnsW+JHUgr+40n1/bVrNE2BHvzy4UNkYIBU/GE8TsDIHmU+wDCxXRC5
VUzvS998Q3H3q04HKVqanPicCKTcF42Ew9jGhFiQQcZVAUgS0mqVyr+nH+3xFfqcOtek1gC4doaz
uH9cXaXCP8xztxUhStujDC/MzIjKRNHaAJL0ogOlXxRnODdAY9PTWCln/f4/rq6SlmZrFgA27mbA
Bli27AMaK+lUqJnJBLPZnpGEIgv8482bijueBiM4Nd4tN/ydD+Pxi8OpOU2aNJ0GuYGTD79sNVbS
ydNRp3P4+PEH3twNKXW2ty/MzJysVTCOqx30AGnS9Nug0wMnP6eFe+J01u+ncyEDGBXEj6dxRYm+
9kSTpt8GvSiVnszOjk5MnBI4uU4ladKkSZOm10inkjRp0qRJ0+uGgYXfIQLYCMqwRBgN+tE7oC4B
+7hRq9Wan5+vVquGYZTL5fn5+fn5+Var9VuStXjfPft7tVodrMuNRkP9om3bjuMMzLZlWVavatd+
n+xJ5XIZt8+7fahQKJyU/IeR7QnOjTc24efn58vl8pDThlbraawRGn1cfj4/P+9xuPF6oVBQTJ43
QxByv2+xavANkGKVyfcYCMRD+q84vHPU6fyvROKjhYXRIXZZpbS7u5tIJJLJ5G/JKliWFQwGI5GI
ODbVanWYe9gjkcjGxoZiqViW9d5dpJpIJBT3emb7KaxSy/8dIfUgvvkvvpVpQ2NEo7+3t9dqtVZW
Vryw8Y4P8XsWMQz85ukB6jqOEwwGf2OCbrfbbj7CqX73NxZ1nbj8Nb0700Y6RsFg0KNx0kN8gnTO
OD4cixPIl7a2fPE4ztoFvvjCMIxXnU4zk+lWKr54HIeevrty5eLqKhJQT5eWXnU6/pmZJ7OzOEc3
OjFx6ZtvRsLhw2bzyZdfItfkPaqYn59HMGjbdiqVot9rtVqhUFhZWSFHu1arzc3NVavVYrGImDeZ
TCYSiWq1WigUFhcXYV3m5+fxO2d7CoVCrVYj/zSZTMJLCoVCtm0nk0nTNLmWOVbxoVgshtAvEonA
kxVZsiyrdUyst4twAUyis4VCAeGwojU35+7u3btYQrZtm6aZyWTQoGEYa2tr2WzWNE0I1jCMaDSa
TqcRqkcikXa73Wq1QqFQOp0OBoONRqNQKLRaLcgwEAigWe51fF18UhxTSDUSiSSTSbERwzDy+TyG
IxKJZDKZarWKQGptbS0QCCCtEQqFUqlUKBSCb5hKpUSWpD0Ch6L8WYLkTdOE9JLJZCwWYydMLpfD
0JCUpLNIKqV+B9FxHGI+n8/bto0/YygjkQg4icVisVjMsizHcWjCFItFJDEgInjQ5XK5WCyCee6L
6AUYRseDwaB62hDbm5ub0WgU3XEc5+uvv06lUtFolDUw0gnGSSmVSuVyORqj8fHxarUai8XA8/z8
vGmaU1NTig+xSywYDHa73c3NTbRPApdKhsueeRk7t4UvCtlt6NkVIU5Ix3Esy2o0GlgLu7u77Xab
xA4dxSVUMAcwdW/fvr27u8v1VDG9par171d7/tEFu9gwjOfb239cXf3k/v3Dx49/Zv6VBdSVIjYD
vuLTBw8A3O3RMCC8TaVSrFXAOKEPJO5oNAqtNDU1tbGxkUqlisWix/RctVqt1+uLi4sbGxuxWKxc
LmM2UIgNUaLlbDZbLBbp01Ke0+l0o9Go1WpSlrLZbDAYjMVi3CRIJBKxWCwYDLJBPdsaZqpHNrAO
U6nUxsZGMBgsFouRSARiXFxcDIVC+XzeNM2NjY3FxUXbtjGJMRHn5uYWFxdbrVa1WoUShBwSiQSc
R8dxxNelTyqklMlkpDyQmZ+bm2s0Gru7u5zSTCaTGxsbpmnmmTOcUpakPXKTvyi9UCi0sbExNTUF
W8KajXa7jQlDbEhnEXjY2NiYm5ur1Wr4sd9BTKfTYP7u3bupVIo6Qr1bWVlJp9PQULdv36YJUy6X
y+VyNpsFS9C2jUajWCxiYrA6C0QMr6ys9DVtsCqpL/gDq6zZkeImmGVZaHNubg5timMEQ4vVMTU1
pf4Q97rjONFoFNMSE1UqGTdReBw7buGLQu75unRCVqtVDHq73S4WixAyTAtGUyrkVqu1uLi4srJS
rValPXWb3lLVesYwjLHpaZx74rCLQcAuBpiwFL3ZDbG5W6n4b9066/ePTkz4T6LYNhqN7u3tQdyt
VisWi9Xr9WAwCCMci8Wi0ahHw5BIJLAMSC60z0ZiMk0TLUciEfq0SDC8eKvdbg/MEgiOALXmnQ3Q
+Pg4JmU0GiVTB6rX661WC+1jCRFj0WjUNM1gMAgvpl6vO45DXUCD0telT7qNnYKHWq0WiURCoRAm
LucNRaNRCDmZTLZaLeqX9x55FL5pmlCIiUTCNE0SteM4tVoNJhxs2LZt27Z0Fvl8vlarVSgUoNES
icRggxgMBn0+H2SCjrBT1DRNGmjTNOnrtVotGo3CF6Y0PeYkyVDcsJmbm0P3o9Eot+GsELJhGJOT
kxAF7DcbY3EjKE4wiDoUCqFNdX2Exw+xQ4nuj4+PQ2NIJcO91dfYSRc+J2TF61LlTtopGAyitVqt
hgkAse/t7WFKSKcNpqJbT92mt1S1njN6AVX+gUG6xr1j4maDYRgcHMrL13GP1bjK3g2DZVmpVAo9
R1jE5i4Qg3tsrVwuQ8twigPZGMdxHMdBXosiCbcpyEWjA7MktuadDenrXFOI/b18FFoAfw2FQq1W
S/q69EkFY248IE3Us1OUKOu3Rx7J5/NxOgJcobViscg6y/i6OIump6dN00QqDCH/MIMo7YjiAdgG
LiJxHIfmJBQ096/oV6PREIdPIWQMfSQSqdVqwWAQMZ+XaYnNAGID/9rtdhUy8fgh6VAqJMNRX2Mn
Sl4UsvfXuc6y2gOaularwVC5WRRq0K2n4vSmD4mqtffJZ9phftXpnJWhGxJiM4vlBFQ/wH4ZMnjF
ASgSicByVqtV2ORQKMTaPcdxuHnvppSRcYMNTyQSeQFkCh5Zz/knkpSlgbs8MBtu84Yr8JDqcdK/
UIuQofR1TD7uyX55wO+KNBQ1iz+EQiF813uPPBKrm7rdLk0kfDedTnNrUjqLkNWl/Y9cLodY6kQG
0csoixV9xWKR9X44Fby5uYlplkql6vU6V2TpNmSsu1YsFn0+HwICL0xCgZJignhFVT78h3pKRtTI
XsZOmgOAn8oJebD1SwNECm1ychJJadu22T0e7z0tFApu01uqWntXJeHmQsA4A+j170HAMaCuFLHZ
MAxfPP58exsAwh6viOpJsVgMCWgs0fHx8VarhalcrVbJ3FH0xLp4XNoaK2FyclJabjw+Pm7bNv7J
tu21tTWPVclSlrAYpHoTG2WK1gZjg/M+HMcZHx83TTOXy+Gvm5ubbmcO8CR5kdDC0telT6qFI+UB
20XYYV5bW+MYQwIXe6SsUvDeI4X8OQsE8RYKBcdxJicnaaVFIpFSqQSrUygUlpeXHceRziLiPxQK
YVUPP4h9RdU4o2Acn4xpNBrj4+PUtXK5zMmh1Wph+5dVed6nDab37u5uz/QONw2wv23bNpLapmmq
x6jnh3q+LkqGe2aYsZMKebChx+u2be/u7qLXCJiw/dOzYtOtp27TW6paPWElkaLn4PoAqHvU6Vza
2noyO4ubrEfCYRQvXdrasjMZ/Dg6MQGz0basZ+vrn9y/7x1XnUs1FovFWCwG7Y9dMorxadMfO04K
OaIKgqodkApg3RCuZSq98BLWSFkaHx8vFoutVotzHzDeKJ3q2Zp3NtgIJhgMbm5uptPpbDZbKBQQ
2EKjuXkc2Ww2n8/Pz88j10k/cq9Ln1T7MlIeEomEbdvIV+BHNuoKhUK5XA7pps8//7xna27rFvJP
JpOImkX9YppmrVYrFovBYBCbmVQBmclkcrkcTgMFg8FMJoOMrTiLUATFsoT/DzOI3imRSHS7XdLd
yWQSuYtUKlUoFIrFouhrJ5NJ8IZ0P3ZcvU8b7ExUq1VO0XifBmSWaIyk2ZKeH6LXpfGEm2RY8jh2
0ogBS5UT8sDrd3l5mV4nde+27eylp9jt4Ka3QrUaf3vf6C9/+cv/+B//42+afh/09ddf//M///PJ
tnnnzp16vc79+M///M9ff/21FvgAtLu7+1/+y3/5LX3oHaRms/mf/tN/6na7g73uZXqzqvU9w0qq
Vqs+n8+L2dSkyS1f1G63B0hSa1KsSu95pPfiQ++skE/vIDqnWt8n2G2cWOm596JJkzqPMQwAiSZu
+yefzyMH9dv40LvpyiwvL5umeXr1C6Jq1bDbmjRp0qTpNdKw25o0adKk6Y0YBgJGPnEU2TeMTOud
1EC7wBLvKS438g4ZrQDxfpPYzu8miaPAymRIfHIao37beQMw0X1BjrMysSxrfn7+raNYa/qNGIZs
NquoHdTUr5XteUSAFJ/CwADU6LeHXDsMkUwajcbm5qb6/K2XMRqynVMyh31dX0EysW270WgAuElP
FW0YNL1b5B1PWINsDxOJnsgYvYNDMDBLdNRcT4/fG50zeqHRAlgY7gNOpuDkNICdI5EIi1VLgK4E
jCydbSyCMQEps7CxqMoizF5CogaUtHEMFWswGMgikG+32/UC+cuVOUmxlPsC2mUXJDCT2QekAM70
isgbB9mtGKyeIN6EtAwkSDcU6LW1NQXyM47Oc69LOyV9TJQtJ8ZWqwWAZTVUtXTWgXODAR6PRCLS
UWDTJjjvxgJNEzKEdEUAvRLalg5AYYAow4l2cAaefRIdJH5IAiJMdF/rTgE5vre3R7NiZWVFMfcU
MmHPA0oHEb+Mj4/jd3ShJyi3pnc3YvCCRus4TiwWQ3QJNHACdjZksL3qT+ZyOSAYAwGccIoINlaE
3AJmL0Bo6cfFxUU1kC8xz0H+KmCEDSUit+EBaJezqYZhrKyszM3NkVSlAM7EqsgbiyesHqyeIN70
FRxxBI4pB6RDY+GG/CxFEsbvGD7HcUqlkvQrUtlyYoQl6AlV7TbrOOBxt1EQkycENA1DlU6nwQ/Q
INgxKhaLk5OTmGlQ/TRGwFo3jgGrxSeNY0CClZWVZDIJvHFDBhOtXnfeIcfZWSEOkzqhBO9ncXGR
LRJ1WyC4E4LtgkdQbk3vomHwgkZrmiZmBtQf4c1i+qphe0Ub02g0gCsLUIFWq0VoPFL/BThWBEJL
PwKDoSeQrwj5q4ARNpSI3F6Adrme4kwK1V+7ATjjlZ68eRksljgQbxpNeIXlcjmRSEitmgL52Q1J
GEgssO7pdFr6Fals6/U6yQcwG4YH2HO3WccBj0tHQU1gAO55Op2mC0zoX6HTMdNCoZDbdoL0SZYf
iAVyEGGi1etuYMhxbpgGUBluC4S4pS70i5Wt6R1KJUkxWqlyA1hDHF6rONUUsL0cYZZwiLssfqfb
QjVeh7D2AuTL/p9Lm7rBCFNORoHIzTalQDOGvqAf8Qf8KAVw9sKbF+hgBcNEuBaK4KRSqRTHvBrY
WUQSBjwL5TqQC5J+RZQtUiXcBOsJVe026zhupaOgJuAtI1eJ/CGXEUXoYxxDzikwtMUnCXSTe1KK
LapYd4NBjkuHaQCtIV0gYhf6xcrW9A4ZBilGKztdetYzqGF7xVWHeB/LSW0SRL3p9qQUyFcau/SE
Ee6JyM02pUAzxjrB7X3G69jCIoAzcA178uYFOtgLRSIRcIU8fqlU8u48uiEJJ5NJ4NfncjlYAvEr
pmmKsg2FQmwxpUe8Yo+zTjoKXpxi9jJIunkJcwypc5ygVkwP6ZNk9oYcwYEhx8Vh6ndv2fsCMYbG
ytb01lJJXtBoFYQ9NxG2VzGhI5EIPA4CUkbs6UbVahXuCeB5pc+4Afm6PamAEe6JyM02pUAzRk/B
PG1LugE4q3kjPOGeg6UG8WYjQrAdiUR8Pp/0omZFr0UkYVTit1ot0zRpNMWvSGWLBiEfj3jF3med
dBSkRC4FK1j0hZUPfk8kEoCAJc+AxojakT5J/KDUQn32RT0K3iHHaVaIwzRA7bL3BWIMBMqt6Z2I
GLyg0SooGAxKYXsVr7AIxiiNUEcMpmniYSgCt7tlRCBfqYrsidUsxVKWcigF2uV6alkW9VTsPgE4
q3ljIbvVg6UG8Wb7SOmsSCQyNTXVV7QhIgnDA0WnsHXE4RXjK+Pj46JsqaylUCh4xCvua9ZJR0Ea
yxLQdCKRICEnEgnWHcFGF3I48Jrr9To7RtiIRjuRSER8MpVK5fN54CqjX30dMvA4jaWzAlVJ7DCZ
pmlZFqohPH5aukAUfHJY2f1+TtNboXcaKwnld1LofE2/VYJVO70bCzSJEcDu7q70VvoTIVRe6Q2G
9yyVpEWg6e0SYCrgdVLqSYvljVG9Xlfncoek3zNW9nucStIi0PR2KRaL1et1pFwoDaXF8sZo+FoG
N/o9Y2W/76RhtzVp0qRJ02ukU0maNGnSpEkbBk2aNGnSpA2DJk2aNGnShkGTJk2aNGnDoEmTJk2a
tGHQpEmTJk3aMGjSpEmTJm0YNGnSpEmTNgyaNGnSpEkbBk2aNGnSpA2DJk2aNGnShkGTJk2aNGnD
oEmTJk2atGHQpEmTJk3aMGjSpEmTpt8AvbWLehzH6Xa7Pp+Pbjyu1Wq4d5d9DDc8s49pchOmFpSm
t0jS9euFWq3WAG+9U+uOpfe0L3LDUC6XW60W3SderVZrtRqugW00GnQxOiibzUYiEcuyotGoeDeT
ZVmNRoP+uri4WC6Xg8Eghh93+ZbL5Wq1igdisRh+LJVKiUSCxFqtVnHRIygUCk1PT0uFXi6XcWU8
USwWS6VSxGGhUKDPgXCrcKFQIJbEZxYXF/f29ur1uvo6XFxMvbi4KOWN/QSEWSgU6Cb0YrGIPgaD
wVQqFYlE0NrGxoZhGLjnXcEzvl4ul1mBRyIRVowcVavVYrHoOI5hGIlEArd3cUPJ8iD+Vew7+8vK
yoppmiyTjuNYloWbO+kyZ5pgYgu44rtcLqslz44XmmUnrSjtarVaKBTYFiKRSDabZd9aW1uDIwJK
p9O4yB4PSBcC2p+fn8cEoD+wQ89Kg1sd1F/2RbWEsfpwF7r0DtR8Pl+r1dwmFbdeaESoQW6CiV1z
HAfX7RFNT09Ho1F2/arHwsvyofHCMNFjblORWyzBYHBxcVHUUVzvuL9yDFAXSICcJHO5XLvdZt/q
drvJZLKvG+u4Id7Y2GDnYSwWi0ajEB076GrVwc1k6bQR+85agd4RQyQSYUdifn4+EAioX8FsE+c0
TZHd3d25uTlYi7t374ZCIW6KNxqNYrGYyWTwu+M4xWKxUChINUUikUD33FZXKpVKpVIKBcctkr5o
b28P/+/33Wq1ure3Nzc3FwqFyuVyLpe7ffs29wyrZdwacRxnbm4OgYLjONCY0vsaW61WoVCAJoLk
fT4fyza7uujP4mJmlx/Js1arlctlMV4pFAqmaW5sbDQajVwuJ441FgN5Fd4FiLnu8eFYLIblqlCp
1FPHcZaXl7mbkLEQbNu2LGtlZQWztN/ZQs6WVEu6EclHuqBYKhaLrVYL5rlarYryxOqD6DAigUAg
Go167wJ85M8//xx/vXv3LvyMvsiyLFal3r17F38IBALZbBbrPZ1Oj4+Pb25ulsvlyclJjyIi8Sp8
R/x5+DtNY7EY13fWl/VOMH7iPCwWiz6fbwDVQc4QZ577jhjq9Tpn+qTUaDSCweCQsVKr1YpGo2gk
GAxGIpF6vc4t1Far5fP56EfTNEOhkHod9pydeB3/pwUzzOSwbbtYLLbb7WQyWa1W6/V6KpXihGPb
dqvVktqMWq0Wi8Vwv3EikajVarVazbumG4AwfNCP+APnVriFBV4aL5fLoqPkOE6tVsM0jUQisVis
Wq2q+1goFMhVHKCDoufI9aXVatm2HYlE6EnxQ7u7u7FYrFgsIihhH7Bt23Ecyn60Wi3ui6zudptd
Yv7hpMi27VgsBvMci8VojhFXtm1Ho1H0KBKJRKPRfD6fz+f7/VBPJaAei0wm0+12HcehRR2JREzT
hB6s1+vBYBDmKhaL2bbd0zCoQ1vyHcXJ5r0LXHeQ5AgEAmy/IpHICd5Y3mg0hlEdtm1juiJPIHUj
xFzLPwxDrVZrt9uRSKRYLNJUhlA4J7parfZ7rzdmJLtCTNNEYoGGU2wTITwiQeiXnp+G/rJtWzpl
kXIJhULFYjGbzWL2cNOCE5PC0tIt59FoFPJJJBLlcjmfz9u2jRQEHgNXtVqtL6esp1eIXkDVlstl
NrTHj26OCeIJmAQpVxSi9hVCWZaFUIAWD0YcCpRGJBgMskMvJTaVNKTnJXqOhUIhFArt7u5SHAyv
irNwjUYjm82applKpdgHHMcpl8uRSKRUKqXTaUpZsCpDGuSxQ2YYRrvdbrVajuOc+IZQMBisVqvR
aBQRQ6PR4NwpdB+2odFo1Go1TFfWnon6YgB3QT0WYK9arYZCIdM0aYFT+pHmjGmaUHx9uZ5iVsO2
7UKhgOkXCoVSqVRPDU5d4FJJPW3zidgG+JTRaHSAwBQCh3iLxWIqlaKEoSJHglTS3w0DcnlI7Gxu
blJugRtXaDfbtmkfwiNhj4FT+o1GY3NzMxQKQY+L6sk0zbm5uWq1ioEMBoPpdFotbjh3WBWijKAR
0um0ZVmWZaXTac5+IN3ExfhuWiwajYpf4bwSNJXJZKA32QCIGoGWQTyISeDFl6RMHbrM7fiZpgl1
EIlEuD4iHYmknNSNqtVqe3t7UG3INQUCAYh9fn5enBIQOOYfJobU4r4xUniprVYrn88j7QafgxKV
XKrNcRxYBdoPwGNoAbNobW2tUCh4N/aig4X/e7S7oq+qMKv5fH55eRl9hyli1VkkEpmammIjZrEX
LLfip+HUU/IHU26Akdrd3b19+za96zjO119/Lc00RiKRVCrVUyOLaUMKQDc2NjBec3Nz0IBQeqLN
9kjYdpZ6YKZpnsh2erFYnJqaopnJDkRP1YHUWTKZnJycvHv3rmVZ/SaUzpXL5Ww2i8X/+eef3717
VyqgRqORz+cplz0kQQWjP/Q5Co7YTWAyBgiL8ItoIaAl4baLjnC1Wg0EAnDxstmsZVluWfiTolqt
BquA3mWz2Vwux40NEpRw9oPBYCaTMU2TMwyKvITjOGrvW2pH2TXTc+r3zDLl8/lWq5VMJt0WFQwM
m3iR5kxPJJWk7hq2gj7//HPTNKH1isUiVAOtpd3d3ampKdKJGC+KGGAkYP8+//xzGAm3EFmRSqpW
q91uN5FI7O7uTk5OqjUIu4vjkdLpNKa6G7nlVTySaZqLi4tcQU6r1eIcEXUqCR49cnqsE4bfoVtp
HvZ0wNm9VvooJgMCUEW4owiLxS5w/hCygjSl2T+TqsQuYL8CL5fL7XabOEdgSlNLrToQflG/MFfd
0gOuqSR2BwyfFz1l2B+yHydCu7u74q4GEnY9sw0cG47j3L17FzU2Pp8Pu+3sM9w6IQVN0Q+bP6G5
Rel49USULubFxUV2GCKRiHS7Ur1E1RoBTjoFVdw/iZyLRTVihj0ajdq2TfMP7qSip5xgLcsaHx9n
e2SaJqrCUNUDL+REUkmhUIjSBT0DfFSpsYyR5MmcuI0FPcAanmAwCKOCX2ikpEPGBtlIaCB7Y9t2
Pp9HdOI9MYudc+8b1x6tS18NGi4FOeTvk6xQWyg2DnVGBXKYKplMBsZjfHy8UCjUarXx8fFqtTo9
PT0Y8+yET6VShUIBehBh3wB+BkkSs6VWqyFcBtvYZutp7MUIjCtzgI+inhgK1QHLzfJMDhD7O3Ik
FN9zqaBzUs0YjUbpOfjg2AHvKwneM7jmfFJE8Ujs2rbttvEiHf5IJALvjGpPRQXUarVKpRKbrIzF
Yslk0jTNZDIpde7cagxY+SrKVd1WBfuAumxAUU7nFhZgc1VqANjilkQiQfOeXT9uovASYeC7iUSC
nWTJZNKyLNhat9iCC5M9xgduik8tdm6qY+aQGFEPw8asSHyzg4t1S7M3FAqx/RKnGZUFw8tLpVLo
I4JXpIDVOVI2NUeDBWun8GdpGrCbYZyBkf7iZf1i95j9hU0uedwQmpubs217c3OTUy9YktgSR72m
lwoIt6JEEgIbIHrcq+B2s7lf2u026nch6kgkUqvVTNPsyzBQCEvJhmq12tML91JxhNpOmgamabIB
cY9UEuZBo9FgZYpCBcix38DTYzJLWghBFtK2be8ZWG681RUIqOSjlDG7LMWq5yGDbuliULtmPZ07
Thdgi0kRBPRL4mLwmM3I5XJTU1O2bZfLZS5oUCzIno2fVGUh6fRGo8GqIUx1GpRCodDtdmmSOI6T
y+VYPwN+Ertuy+UyCljxSj6fZztF0wwuCNdZL4uFXFeUPJCZcSMEJclkksSOohQufe9WGUyOpJq4
owxsel2M3ljDH4vFkGDk1Bw7JeC19Fvn0lMXiW6Wl54qNnjEYk7FHiHquXsaJ+n+5QBxIaZuLBaj
L2LXE7NU3AVkhyCVSr21k89IRHCxEpeAFt2E38apwhMk1HRxzkXPgyYnS3BMQqFQIpHAcTZp5e7A
jZ/qbpA09Ol2u+/UAXJEIbZtZ7PZYrG4ubmp2NfxrjS5iOFE1q9o/KQqkn2R087v2tF9MWKgv7bb
7enpaU5ruXn6KBR+F3rkxeiegztWLBbZDkej0Z45uCEpEAiIQQPVq2FyiMHpMLvfqVSqXC6jYINN
JXE+hWhL+93945a06HGwa1K6wcXumIlxPVsdhPJEUbaDnWpReEnSTTzj+BA7JaYQH5TL5bW1tX4r
PaQ6GruaJzXrEolEt9u1LIsSQdxUR9UWuxa4SUIHmNlUEpsOTqfTpVKJFWBPH79nbF2v12OxGPhE
VRUOsrFVPaxiwuYTTZtQKDQ1NcWJsa+zhP2u355O8SlpFdG8cQk3cTXRxuoAEUMgECiVSh6F0Gg0
+i3p7OkzKdYp9mx2d3fpGWyaeozD/s3f/vY37Xdr0qRJ0wkSi30yGKTC2yVtGDRp0qRJ02ukYbc1
adKkSdNwhmEAwCw1tY7pRFrjjs73dZL+fSQgW7x3bDuOc+ITSZN3elEqHTab7wgzR53Oqbb/cn//
5f7+722Ijzqdw2aT+0/xGDcK54xe+KssuVWIS9Fce9bgo9qaPeHitjfidjjLeH0jF8UbtLXF/VVk
1Xi99hkFXnTAFZy4iULE+kYdDouowW4N0R6Xm1jY36lIma1W5gApsQ+PU2PoY19IxXRGDwd/SJhu
ONXgXw0LKlbHu2GzQ3SiVFHcicpr2haWDgFXH0LQTIlEgusvxwMnf+omDj1hJrghsHIHGyETjj11
NT1HT2ZnX5RKhmGMhMN/XF31xeOHzeYP169/9ugRHmhb1rP1dfz544WFQDZrGMYP16/j4adLSyOX
LweOCw2+u3Llk/v3R8Jh+sNRp/PjzZvsFz9eWBibnn62vh744osLMzMK3qgR/JU+ahjGYbP55Msv
oW1HJyYuffPNSDj8fGfnRakUzuUMw2hmMt1KhZryxePhXK5bqfy0tPTJ/fvch368ebMnM4ZhdCuV
ZibD/hLO5XzxeDOTGZuexuvNTObw8WN64MKtW4FstrO9bRjG6Orq06Wl5zs7nDQC2SwrRk7+UlFw
xDY7Eg5/cv8+nm/fuUPNPt/Z+Xl9HcpXOo49GWPFSwKRypOkKv6I0cefD5vN9p07vzDD9GE8Hvji
C3Szd7kqB7/e7XbZk9kDb6rgJBGLVwMQYOB/cQ9z0N8KDom9QCDAqhJ2L4hsDFe6g3OYKysrrVYL
h+YUy5s74iC1W8Qz9CldITBYjQodKUJ/6/U6YEVYefaFVExAOsQqezCbNdIiGt1gwRyVcKAj9DkA
+huGAUSWubk5tvxf0SY7KwZAPEbJP90v4obr7uaIDEnP1tcPHz/+9MGDs37/850dTuth5bctC+qv
W6k8mZ0dCYfHeh0DZunVwYFhGOHj8qFmOn10cDA85z8tLZ3x+6E9m5nMky+//NO9e5zKpj+3LYtV
1hy1LevVwUH7zp0P43E3zUvWhdXX3125MnL5MvfM4ePHl7755qzfbxhG+84d7rsXV1cvrq5KVf8w
hGYRh3H6nVTw06Wli6urF2ZmMI6jExMwsafKmNrcPt/ePjo4+NO9exDXUafz9C9/eb69/fHCgsGe
fHYDzTBNE9jrtm2Tx8pi5Eo148meSxJ9PdZNA4ftdhsoNEDlC4VC7GETL+Wb8M0B8T01NcXaPy8s
icRFDDg6pNCw3CjgdVJD1WqVdVd9Ph+QKTEogyEVnziJBpIiNgwK7AHCRNM00TsYYNu2u90uxpSC
ziGnEE6luhl4wBeDh0wms7y8fFLQmB5THP5bt7AsL8zMvCiVLszMjF69+sP16/TA2I0b0CC+eHzs
xo0ns7PG7Gy/H1IrXDfeDMN4+fCh9N1upUKO6h9XV3+4fv27K1fApPjwL5WKaMwOm82XDx9Cjf7p
3r0XpVIznb5w6xanMRXRw0g4LOXtrN+v7i98ZAQ0ZIyhDVmrM9iAjk5MSBN3FNP44nH/zMyLUkns
Zk/GupUKx5i6p686HS595H0mnKNI3A1/FasUAT7BTFarVe4EE3lSbCpJ8WGceufAUnA6dLD1j5O3
gPDN5XI474cAApEN3F70S4QTAAwyKQWgiqIk38v+Bw7Hi7+zWQWKWtyUnXjBGYv5XK1WCYYFzAOY
lyQwDFKxNNHHpZK8vMU51KKdQPE75Izz7ad6YgYQ08CXJhNFgJpAmyehAd5g+I+K1fTSUyB/CIc7
29tjN24gYuhWKmz6BVmatmWNTU8jYnjx7beXtrbGpqfJciDsoFyTGw2wndC2LF88/mx93RePw3SR
tvrs0SNfPP7T0hLCgp+WlkYnJv507x5yHaKu/HV//9LWlhgtHXU6pC4D2ezY9PSLUunZ+vrF1VWp
en3N293ZuXDr1gA7FsifjE5MPFtfD+VycM+fLi1xj4mpJC9C6+zshJhQqS/ywhgyclwqydUbuHz5
+fb28+1tt1TShVu32nfusBmnD+Nxkqqnk8/lcrnb7bKZZaR9pOdrPGYVsALZK5AIjNA0TekRGBZB
kDubats2C99Wq9WAO+3z+T7//HOfz0eWA4DV+XyeQ24YkiAc5HbEeyzYqGWYnAxhd+PkFxsxiMm3
vpCKWQM5Pz8P0y7F2aYH+oVdQ9850B4AIOMroVAIGIi4bk96809PY8Ye9ysUCgDAQG6QpMca4CFD
IlEI3o9DXlxdfTI7+/21a3DlkDJCPoEUQSCbZZ1H0fWmhLVUf505fx4ZpH841OfP99y0fDI7i3RQ
27LsTAZbCJTTR5Tw5Msv8TnsMbi19nRpKZDNkmkhtX72/Pmz58//+vDh04cPOVvY2d4eWVjgXuEc
8JcPH1786iupNnzy5ZfsHgMXZ/y0tDR69eqlra1mJsN2bXhqW9YHExNk0jCI8PexqfM8HkcqqbOz
w1nKk2XsqNN5dXDwx9VVhZeA6OSDq1fZdNwZvx+/fxiP904lQSMjJIejR+E5q5o5IDY3TwoLCReV
uHVMikZH+pRNJZfLZfhikUgEIPsEw0IA5Wit0WjQVRM4AVir1djLKxYXF3GDEPrYbrdt20YyR1RP
nDdNokMUxSoLboNUbYrYURAT2YFAgBQfbdSTausXqVghfNp8Vj/QbyrJOL6ohy6oEfM8gAiG2KPR
aL95JISGkDmuDwHOdigUymQyBMHPipQgxmBr1Y4OOu5Wj+AFc5f78dLWliF4069xmM0GhjjEftbv
/+T+fWgKVjV8GI//wUXvtC2LNgkC2ezh48fP1tc5RTYSDnObClJqZjLs3jir/V/74p07Y9PTrIZS
WAXk6CkzzlE4lxM7Sy0/39kZuXwZfQnncs1MhlLqHPWbSnq5v/9sfZ2VCTafSVwXV1fbd+4gAvh4
YYHLI3lkzGMqqbOzwwUK/Kz75ptfX7fH4gCdM3rhr5Jfz56Ap+sN3PwmQwlQBVAdKYKjNJvE3bwh
Ng5oWdgMgIXh4kBSr9hyQJSAVBgpLMr24NJt1PPs7u7id2kqSVE9NZjzaLiAl7EfIued9pzZqzr7
RSo+DaJpwKG3sn0sFArcfXNsr1mI4CGJAyOTwhfGYrG1tTVcCpLL5Ya8l3GAEEq6H9Bz+9GtEMWN
nszOctuwrw4OPrh6VXozBqePLro4niJdmJmhrU6ULZ3x+y/JzN7oxASyZODq1cHBy/39V52OYRj+
W7cUeSTUaIVzOcUzolp8dXAwduPG383w61ZE7CPJH6GbohiJs1XqDBgrHImm9sAYtfB8Z6d9545i
DpAzcdTpdCsVlBuMMtGMYRijq6vPd3ZE8/DB1av4ilcQPRThABhHClgkbsOqN2bhx0lzVoOlp6DN
sR8uFqgAOYQA2aX1VMlkMpfLAUzJCwacm+fIedDcFQXqTAgHpcv9Arg6wvXFnay0A98vUjG8e6hv
aWwkgrEMvx+QSqXIJxh4S4mIZU8aXkhBsGk4UBEAOXjB6PfIkvdyVazzzvY2FdqPTkyMTU+zXjZb
Jyr+4mWP4dLW1qvXi5GavXoqflRkm6uepF8Om81mOj02PS11xlkVfMbvhzL6R47IZf8WVuFFqfSn
e/fUOxD+mRku4UaeOxmtZ+vr7HbIhZmZj5TJK/XewJPZ2Y8WFtTltl4qjk6WsbZlPd/eHr16FclD
1OyyGSpRjIePH//68KEBwyDCMLE5hGQyyeqXVqvV7XZZT5+9E0bMRylSAbg+l7e9MtBaLm8jMkk7
ez6fj7spgYXh6wl5bZrmkNhzXm5QURsSURezOSVspYo5eny0L6Ri7soO+joFPdLW3K6fpUpc9hd2
1AD9xu4JsSk4fI6NJLDP1Gq13NBVRbxuabmqAgRbHfyJtLm5yV50ge4obnPymIJ4urT08cICZSFQ
8M4V54iVrORRevHopSXtZ8+fP+p0vr92DfWyPRsRXVQxswGeUcvvxSKKcQx0+otSqW1ZXLbKY1bt
5/X1X17fw+c2G7BhS71GcPPz+vrF1dUfrl/nNurZfX6qFWYN3kg4/OmDB4ONPiclN8YCX3zBsiEm
uy7MzHDT4KjTaVtW6PXQ6snsLJuh6lYqYsbpw+NZd65nuoO7aJPbFma9fi6Hrt5lhQ0QtaToavWl
71gz9j6ereX2e7mr6oPBYL1ep8vLsBHyxsor+82DcePC8inyrIBrHuCAwmmQW47rDbBHu76itvJI
VN1PdOb8+W6lwhYd9UtckYy0KknlID9+/LHgDn8wMQF7OTZELvTCrVvc62d6bbl7zNH9ePOmOgw6
DfKSXeStvt8/Eg5jOCDhlw8fvnz4kJ1Fh48fXxASd7Qf0zuV5F0p9xUxIOcjGg8669T3NBXuKDdO
/2YCrgyGnHHWvPWF9KuOGACnTLeiBgIB73mqt0vBYPCt3KVx4iDYXshjuSrC+Yurq53tbUoHjU5M
BLJZLofjFjF41Syv1+qQ9jzqdD50TxaJH+U8U7eIwTtXYhIMZ5W7lYr3vQ2xWbFMc+TyZbJhf1xd
bd+5g2IwNmPTs2WgR/TVR4WbL4p0YMbcXIHn29tPl5ZQvzt69Sp33g2CEqUHQZ06uiqHZjHM3Qaa
NGnSpOkNkIbd1qRJkyZNr5GG3dakSZMmTYMaBm5nqa+NptMjQHa/rX3mdxk+Gie2OHrrXP3ecNHf
ynJg/9qXhKVzRgOkv3lSAGW/GTongtkSsbUQqLFlIVvZv4IUiNYcSDKR26YcbqzFEVlCYOXax6EK
eiUQCCSTSXWJDiFRqzdCi8UinZUDFDNeFDdIpPDRbg8T/yKKOKFlKKpdpc0qqubZ6k9Qt9tNJpOs
wMWTE8Sk4ziWZdm2TUOAgymtVkt6PMXtalyuVq1UKoVCIWKY/atYl4zTJJZlKWDDWRlGIhEpAjw9
wx098Y7yLfKG+jHuYe/A42yD7Al2g8GbUoOci9OjUChQVQJEx6Kye2FPWkzBHUIker6zI6IMUa2q
FCV75PJlrpz/sNn8aWmJQKJ88fgfV1fZM2VSvFI3KFaP2NTcKQ03VG0WDfvCzAzLCYuLfvj4sfet
cu5Ag8gezrUQ4tNZv99/6xZ3SIKDW+eAx0XAc/SRYHpFgYg/nuPAbDli8dxfHRygTm7k8mUWiMML
orVYdW64X0eO9YDlAaALUfcBJC6dThNKB1aa+tzs3t4e/q+o5CmXy3t7e/hioVC4e/euooII7hiO
zvZlkMXCJLcjAsMQd/y4L+gkKIiNjY1yuQxcLPXz6rICukyi2+1S5Zg4WCI6k5tYCLeDM2x9kXeU
b6qZdruqYQBiO1utVvs6FidSoVAIhUJokEWg6pcl7sihOmJQw7qJBxo4FxjqxRePo3gfyM8/3rz5
53KZsKDF07k4DOh2oKxfCFI1ERRVt1L5hcGUPSU66nR+Xl9nzx+83N+3MxkgLbKXcxiGgT9z5bPe
Ac97RAyiCWJt4Fm/P5zPHz5+/Hxn56jT+UM4PDY9/cHEBHuQcshDYSLZtk2qNhaL4dTVkMWOtm0X
i8V2u51MJqvVar1edzvbXK/XY7EYgZguLy9znqnjOPV6fW9vr9VqZTIZ0zSxJiORyPj4+JBHeXuS
m2M+TMbJLecD85lIJHZ3d72koarVaqPRgN9t23Y+nyfjl8lkgETSarUAZifqoMGGFeBLCDGlwZ8b
CNgAKN9Irdi2HQgE3FDZ1WhRp0d0Bt4wjMnJyd3dXenIqtnDAHHr4vQOyrz49tuRcJgAIc76/Ze2
tn68efPFt99C75/1+0Vn/Kk7pKjhDYL01cHBaV8bp1D9+L/i+Mgrhjf2z25H/MQDffT7wMdBznnp
yZPZ2UA2e8bvf9XpAMGKAgjUHasRrU+DotFou93m4Juk363Vavl8HkfzSNOVy2XkENLpdL/rFnZl
fHycEBRwrLdarbbb7dM+VSCmkhQPl8tl9viVeLBcoVhZHG+fz4fEVM8TAPQJUSvl8/lIJBKNRunQ
O9q/e/duIBCAe8Ed41DnBhuNRrVaDYVCxWIxlUqxkIhuiSyPIOoKrzwSiRSLRbo5SmywJ/B4v3sG
4hBLYwtc50c3W3AYl8Owd+J7DN9ducKpby8ZC1atE4rGABEDrrEc8gwdl7/i8l2Ks98Id7ouKvus
3//RwkIzkyGeD5vNi6urZEXYu/PEtBsnByngeX+G4YzfTyb0qNM5w1izl/v7gP/9u5EvlX6pVD6M
x8+cPx/O58+cP98XorUXfCGsPcJMrdVqHCQcIYwCjI8WBtRcKBRitQkHpkY5FjcOAUKHmw8KhYLP
5yPEVixUQgXnsrH4cRi94wXR2nvEMDc3J1oCVqFgZzIYDCI4kCpWVqH03MYECi9ZCFYxcQfdu90u
wUvQhZqUrmE3TtxSSbhaNZlMTk5O3r1717KsfiPXvlC+MbEhB6Q3ud2a04gY1BcXcpRKpfL5PMRl
27bbElOw12q13G4tFMOIYfI2lLseu3Hj5/X1J7OzF7/6ilJJh80mMO9gAw6bTRFL1e0rXpDmcCFS
Z2eHxQNHktwLZB5H/cLf4uvPd3bY/drvrlwhW4IjhzipDrvIHkLk7s6jWzFEg/rT0lIgm30yO9t1
iSfEzQ+WjXPsDlKbmTRty8JddB/G453t7WYm84dw+K/NJoYTqSQI0faAaC2dVQS/LK7YVCqVy+Xg
tGazWfZ1YDX3XPPD5OXpftBQKITb67x/HXckDPZptUmgfZqeW+jValXNJNDrSqUSDk5L7zEFjjck
2e12Q6GQwjCwxQWs6Zqfn0cEGQwGQ6HQ5uZmKBSCDCneMk2zX4khxKFoAGDd7FU8XlJJRj8o39id
wgV/dJeDaBj6Alil8IhqK0jFYxdd8a4Yl+NeKYxRKpWCSFkoMzV77MWr0hklQhKoEUNJ17DPB774
gnOQ/3Tv3k9LS3Tcd2x6WjQD3UrlzOu/nD1/nvO42Xss2NCE/frF1dWX+/tty/pzuQwVRwl6N5NA
GIW4KoMa/OT+/V8qFXVSC/rztXSfZeH3H65fx7VubHjBXljNnlQH4iHOJIt351F6jW4PPep07Exm
9OpV1mj1BBLnopxz7Oiin1xSD9jr6NIHV69+GI8jQ0d2zAuitdvyZi8H5ea9YtWlUilc/iWqTjEO
GAAlP5lMcjqClDKMFjIYrPlBsAKeT6MqVOwFqzi4XnB2sVarsYVA0MWoOJqbmwsGg1NTU/l8HlqP
dSRR0FIul93yEqJ8oETK5bIo1XQ6DThYWF8YHlymRBk/sXdSz9c0TbZ9FqybAwdU48l7R/nmQkwx
4hRhBNX5Hw5JHjivipyhF6rX68jRsfnDQCCA7ZOe7C0uLkpdCs66uGlhzmZcXF0Vq1rE+kvcUOTW
zpnz5y/MzEBdvvj22w8mJnCNhHjbsxdAIWzkIjr5aGHhx5s3z/r9Cn+fxSj84fp1TtH3tItixomQ
AS99882PN2+GX7d2BIILuGzaMoGZBNwTd3ceFVYRbwBh/GBiYuAkktc9Bgxn27LAGYdha3hDtHab
i+oHlpeXs9ks1BxXVyeidsOLFD/N4a16KVeForcsa2VlhTxf9i32thny/jjFzeV8OEvD5Y4hw2Fk
xa3kUChkWRb2xpFxZtd2q9Vqt9sUisGiI1PPaq5arYbU1kndvkk+KSmpbrcLIyHN+Bm9irWAQ066
zDRNpDRPaYPHzcAYAoyg240UfVFf5arIgnKeFvlPHtkTQ21stqu1sFveZvjb7dnNZ2ylqnUxW2Aq
+sKd7W3cIYqWL33zzZMvv/T3o9xF8liuetTpdLa3L21tIS4BRlbLsoKMWTrr95/1+4G8TW73k+1t
FsCcvTsPewzcV9p37vhnZtRIf2zogxtVRStyTgwxWMmSITpz/jw78IBcZ5OhiukreivcX6WaGnVy
8HbZ++Noxp8qqiVUP7ITlLdlmRQrvmlPT1qby/ZamjtmNSDdUy2ma7w7ku12G4l+LriRxkmisjNN
06M3LT2kwpo9Nu/x+eefs2LkXhS3oBR5dmxuxWIx4hOaFAZbDdWO+8bZzqpRvhWRxACzyzuSfF9U
q9WKxSJnG/rCkcR+vrjVcVLLirUoIsY192Tgiy/YWtVXBwcvSiX2F/GuAhGHnK1K4v5pdGJCUX4q
2hika+ivfW1IIGkmJuK4DYDDZhN3TlC/sM1w4dYtfEt9dx4u7FNzIjmfsLXFsvHjzZuBbPacd3vO
jmJfxV49MZmlaz6fz6fTaVTLoIB1b29vfHycLj0WI9yTKhWF1clms6hwRSDCncyKxWKTk5NsDvoE
M0gncheYcXyQFRIDez6f78QLat0MoYIl45TJC1S7oj7iXWBvMOKu6+iXWq1WLBbj3IhTgijuqcLo
8iKQWIk0MGC4F/J418XJErIyHWZrGgATHmHDhydCkD3nnV3u1icxzXdS5DjO119/nUwmkV7AjiVK
R+7evYsQGBkS0e2S3i43QPyOo3PZbHZ5eRnu2/j4OKWhgsGgGDGc0lJXeOJq7zIQCLBZe2LyLcJ0
S1niPFzp4VuuyJLNv+3u7pJMkDE71YGQsnd6mMHey1WN44pVMfnmfVFgYoujNsxZJTEnwV0v4Ubc
bZTvLPVVrtozsAjn88+3t0nZfhiPh/P5UzWBXICFXQ2NrqpJkyZNml4PBrQINGnSpEmTNgyaNGnS
pMmVzr0vjB51OixA09/N2vnzbyz79jvpC0oM3kHBSitYhsFHA0mPxb3j5DhOt9vlauROcGeFk4m0
WOBELmp1O+L6jkhY/P0EazdQdfkuXNguNwzc1tDF1VUcyfv14UPA6hGkH8GbiHVm4Vzu5f4+W89L
xV6AJwQcLmpmw7kcB9j7yf37L0qlw8ePP7h6lUPNJXoyO8shBb46OBi7cQNfZGvLsPMDKN32nTss
Pi1LbAEycGvR5TN+P/HAYdj+Y364I730lKdhGJ2dHfG2VeP1Oo2e8LxuWMEicdIenZhAxRsHPoxq
9H88dvXqxwsLbu0/mZ1FvQTKCi/MzLAMc6V+OO4kVrWLv7h16qjTaQpnKV4dHPzp3r2RcFhEeMYc
YIdYPNkLyJBSqUQAJyJQK1sizKIIG8fYqG6o2qzK5ppVnE5g95lRUgwwV+B2EJY42DBNM5lMRiIR
AG7T2XWqDicgcbdCZw643jCM6enpUChEMqF3OTPQarWkG+BuWOhScHi3g5Bidfvi4uLe3l69Xhf3
wLmHcaG32N9yucyiCnIIWtJRo2ZZOBCudoPDdVfIORAIQKQ445lIJBqNBodcIr7Ozi4UZ2Po6ToA
N3RhViwcqDu1r0Yn+nu5KqsjuBt4fqlUPnv0CAcX2pYVyGahnjjoc7a2rFupvPj220/u30cRrlha
QIcGjzqd769d86LdREXMKjuqLXtRKkkB3AcjLzhfHPWUpyHDV2GVMmta6M8DcCJK2ziG6hWpW6n8
vL5+aWsLPAP+1w2J5enS0uHjx4BKhtXh7pRnS/2amQxXaMidm6U+KiqnpQXa1AiVZrPA9KIPaBgG
C3BimqbUK1TQYMcL+iJCm5dWzWIxo8qoVquJOPPlcrnRaEDbqlHLjOOSa9u2S6USJMPCgrHEnj5x
u1vF6AcLHeBUYFjksKfiZkeEVBvKF6VCq9VqdK0LVTMqPkEn2wuFQrfbdbuRwntw0O12MQMHvvgI
99OsrKwAtqAnrDrJEIVq/VbAn/OoHEfC4Q89VJiRLfHPzIyEwyPh8Nj09Mv9/TMueYlupdJXRRqg
XhVa8uX+/smWuB02mz/evPnpgwf46/fXrsFLPZHGm5nMpa0tLmkj1Y8ekbB69qWzsyM9IPPXZvPM
+fMUPZz1+z+4etUNzvevzab/1i2wfWFmpn3njhtAAgJBztp5QS8YjF69JSxlNXGQscPkYVqtVjQa
RTYjGo2WSqV6vc5qQ8CU0YH2QqGgUH9AqSqXy8A05PC3xXORHokge4vFolj82mg0gFqfSCQikUip
VLIsa3x8HDXow6S/cJ2iWN0LIH0qd8b5J8Jzc+sCblsJhUK3b98uFoubm5u4C4CTiUffAgLh4g+Y
KDo4ghPmjUZDeqKwWq1S2XEmkxGvAzjhVBJF5S/391uWBQUkQsK+3N9/8e23rE45fPz419dPoLDr
k045nD1/njJREsXx7bcv9/ehNbwAj7w6OKCE0sjly6KC7uzshDw712wBsgKDlz3N5/FkX095kgxf
HRyc9fvPnj9/4dYtNs0FoQHLxQ3ORVTHIm4XaxWefPnlRwsLUvCvsRs3AJUIVl91Os+3t1mWWPpD
ONzZ3sblIc93dg6bTbjzHD/dSuXpX/6CW0co1yTt40cLC4rRl27J4MejTofdDjlsNt1uJsGKunv3
brfbxckJpE3egGHgbh9CKsmLDRB1HI7vsKn/8fFxVjfReUZowJ7OKSKMTCYDzErEQ4R9S/Khu5W8
WMFqtYr7/tLpNBxt6giuRYlGo3Nzc/V6HW4vXmERWTjow56nKBqNRqlUwtmjWCzGxTTASw4Gg3Qv
HovnJg0ukZpDpg5xCewZGCYD1hPNk+UB52HZk7BAJaDWAEpWLBY9Ig4MT+KhHMJEOIcFDIBySqxz
uXgs4AszM6wiflEqHXU6z3d2aElDz4or/OOFBSTuRS+4W6kgI6G4bOj5zg53Mp702uHjx91KhU7G
ty3rA+ZQDNSQAjYEuW+2y6INw+E+XKwBq9DzFKJCni/39zvM7sKrgwM2rf90acl/69arTqdtWXQP
35PZWWkM1JfT3bastmWR/sX/WTWNI/sk6pHLly99841b7HVxdfXJ7CwQMUfC4YurqyPhMLft9HRp
6cW3317a2hqdmOBunsLkEfvo9jlxe4mG5smXXwJ1EvPkqNPh4JSJCItpbW3t888/9/l8/eaR3KhQ
KGAPwC3LNFjEQHsM7I9TU1OWZVmWhWs74WUP3BHLshzHQZpobm4OZw8Ba0g6mjSF4zibm5vktEq7
ACz0VCqFc6mE1sUaNmx7dLvddrvdbrdbrVYgEACuPvaikR3idmIUKhibLrAKYEDMCxmv440rUPdB
BA5GSjwQCHBnJxEYGe6Y5OxQsiqYGmERzCzLAggNxle0hbFYjMxSLpfDltIw1z6qhXDOMIyWZX28
sNC2rMNmU/TB4bHC3wSyq3GMH/vxwkL7zh14jqyefba+/o/bHQ4OfOHwkczjA2J4z+oXTl+4nYx/
ub//bH2djWmw+dyXsDgbRtvsBAuMP6tPNirkiRSNui/dSmXsxg0YJ188PnbjBvJjBJhuuJToUKKG
5Q3bPCOXLysyYOyuDLH0cn8f+0ZSlX1pa8twgW98ub//482bF2Zm6IJGmkJkioC5T338YGJCkQP0
uL/SvnPnwszML5UKC6dMeQbaeWbvFj0RcED1xgNpE7e91r4IugNpE0oZ+Xy+WCyGMAjKgq7rUSdn
cA8SrqUjaTiOw16rzuUrWAeTAzMGiiVJA5Dm9XqdfHPHccTIg/2l32P5tm1vbm7GYjGSKpSduAvS
0xKwlMvlgAEsJToHXiwWcR9MPp9X+/jEFRvYmaZJ5mRzc9M0TTSLigYAAnGDVSgUlpeXjePN5557
ErCRKE8g12RxcbFnzJpKpc61LetVp4NkxZMvv3RDaBoJh/23bkHPdisVqODRiYlfKhUx6f9hPP5k
dvbCrVtHnc6LUuniV1+9+PZbMa3xIXP/j9owQGXg2lXkkUcuX/bPzJBRgdd5cXX1ZDcYSMNCqXmp
AlLLcyQchrcOtCw4wiOXL49NT1PLcLHHpqfhTcPvNgY9Zy9u23535QrGjiyHeK2u2ja7zRAEMaMT
E9Joht1aGAmH2T7+ur8fVM4EbIaLv1Ow+GR2FkicqFAauXyZjVyj0WgoFGLTI6g7ZJXgiVNf2ILe
yXEcGDnp7nQsFiuXy+hUqVSamppSNIVckyJNFAgEWNPCZdg5q6PAQucegAmBojRNkwDQoM7YfkFc
HDYwy78UjITAu6RghT2NOhS0ukgXW8EQL7aC1UMpve6Ces0JSpo6Q7Dl0ZVh9+RR2MZ2002er0UM
BBEeyGbhbXG+5OHjxx8vLAA29sN4/KjTaWYy4ePrqi9tbdmZDPcW/Fy4h+y9dP9IDnz5JYBnva+H
Z+vruA8PuxfdSuX5zZvhfB5JjCezs+o89TB7DN4J14Ao5Enfbd+5MzY9Dff88PHjH2/epIog3JeH
BBT2GKA9uUa8l6tyaS7jeM+fDAYuMOlWKt7vohIrRLkEl5g+Yh8Ym54+bDapjx8tLKjBc14dHDzf
2UE8x4YIgYMDIBUfPn6MvSVUEv+0tMQZs2AwCI1DVw+hUIQNxsWcD7fakTVinTh1AmEADCXKeLhl
J5Bs4fY/8/k8kHRjsZht2zBIXgD1TNMUr6IiPCvuNAPUnzpt0hPZHnfhUcYfe9TEqngVCsUu6p0S
tho1EolMTU1FIhEu+aNATfeix7vdLu4vwcYMbTbAx8fOiluDcE3YX0TYzZ5Q7Vx17JDUo1yV6m0o
ZmdrUcZu3LAzGWwOj01Pw0Fj/UGCk+U0oBqbUIEc6+YwYleZVvuFmRmU0gey2ZFwmO2F9PXvr13D
ZgaXInstLf664ywe12CT8ii44vYwRicm1PIEdba3cVc2K8bnOzukHPu9L9AjHTabqECF3mR18cv9
/efb2/1+VDyUoBBvzwd6EhtXGczVIFziyBePw+aJ1rRWq7mlZaXoe+zSlfpx9XqdciyFQkG0BF5q
N4m8GJJWq5XL5TjkwWAwSL/0BWYsPaYghVPF1mi5XB4gymH7hUxX+nXQ/nw+z+o78XSIIheEalS6
uAXufC6Xu337ds8yJ8dxlpeXUQMq3ZHiFLeUGQKoV5QJYXedG7WebnvPaSOdtOJBEM6h8XIhzbme
iYh+lfhp0Fm//4OJibZlXZiZQcTwolTy7uESZOBgeSQ3+vHmTfWFGAoF96JUGgmHR69eNQzj5cOH
ihKgkyLaf/bF47ii5MN4nDPe0gu2jHeGjoauRuWcaNY7HpJOG9X1Ncvn83FuvjEc5nw6nVa83mg0
dnd3kRoqFouWZcEfH+xb2CIul8uo0gGs/ZDlYShUHeDFer0eiUTezOnrIRHRvdMA1xz0bRjeHbq0
tdXZ2aFt7dGrV9kAomeGx/shDO9KCsDlA7wbyGbPoNBzfd0wjJHLl3F4uN92vJerNjOZV50OSQyH
n5/+5S/fX7uGLeKzMmR1xHYKg9rzItmTojPnz4+Ew+xFuPS790ZQHMJFDKd02QCnWL1DZ3uxCoas
flS8k9lja8FgULSO1Boql8js4V7bYrFIm6VSEjdX6LwVNk7p0DWuSBI1JufkKiIqvItyWwpBuHtq
3ci27fHx8TcwgT0ioou95mqdxTvMh5lLinJVDbutSZMmlTMu1bDvLMzRmxfFb5K0YdCkSZMmTa/H
4loEmjRp0qSJpbezx4DtexaW611GoH0zEuDAagwG+/dEII5/n8ThJ+P4wu9wvmnS1J9h4JBysfkg
FsxyVXdcDSwVSGGLCQ9Ho1EpjnGhUMDBwkAggLJoFoGWOxZEmyFsDTIHgEzEbdQoQHHdECLdTrHi
kAhbiSHFW240GuzJe5zkRFk3+2mpBMrlMhkGQMqwxy/Vh0I5WGPiluPHMAxwsri4ePfuXbZH6vEF
2pdt2yg0hEr1IgGW2HubRYRhGiyxBbwo/Rw7xNQmyzy3vQaYTA7xWBzcnvzggSGPMWvS9E5HDEOC
CQOGcHFxEWgqakesVCqFQiEsrXK5LILHsseC3MCH6RUsWulN8WqSHj5y02j9Elp2O3JZKBTUEsAz
UILY7IJeJkh37xSJRDY2Ntxg4kU9juKZSCTClWrk8/lIJDI3N1etVvP5vEIh4ousPPu9R55tASwN
UzjElpxXq1XvqGfcbOG6PAxGjSZNv51UkqJSGKi2cFej0agaocW27enjM8aTk5N0XpFDoOW0JJw+
znrhzGQymSwWi27VaScFlCY1G4Pd/NVut8lXZSUwjGE2js8N9fsup4WJWHts23a32wXPwCum4kuF
BKrVKgorFZeL9SzzQKeGyaRxd9GQA4GTboOVeGrS9Ps1DCiYJWccSXDpSnYch5auaZqE3CRtFvW8
BPIVDAbRICHQiqkknNfgHHAEE8gAhEKhzc1N8TT5YO6hG3FxiZfwQiwTVkiAy2hxWPaxWMxNhZF1
pDu8iD0ofTK9m5ub0hby+XytVjMMIxQKEdQwK0bWWgOmP5lMukkAqMXdbhexAvJ+qVSK7SaGhkVY
cxNgz1hWWtnNpi4jkQgFDXT0FLXzevNGkyZXw8CdqoBvyF6iBEiZaDRarVbZwFy6bpPJJK6Xkn4v
lUrl83k4uWyel3CdsOGhwAao1Wr5fD4ajdKtUpFI5PPPPy+VSoCAh67xCIqrBgwZMmKgPQYvEiCN
Cbaj0ShFElCpYtjkOA4QmDEoQGREZ1kzRiEFpModtoIEsEVRLpeBJTDwfNrc3MR5KJon2Wy2XC4D
P5LAwvb29sCSQoa1Wk2Uj0g0UVmXgp2ctm2zARBZ4iGtAhArxSyTJk2/BcMgndace44kz+Tk5Obm
5uTkJFYUYUMWi0XK2DiOEwgEFLmRUCgE3GCoSCxR9bYEl0qSwphgU5QFYPEOiusls0FS6gl01ZPc
JEBaTB3osEzu7u4SwD2UI64r4Z7f3d1NJpOsUXfLBKJwAAyQbo3FYqxLjsutoGrFgZCKmsOWwZ0n
gB6LRCJS29BoNDBwgx0posnJyRNYnvV6ffhYQZsETb+7VBLrphUKhVarBXUzNTV19+5dDqdlfHw8
l8vFYjHHcWq1WiqVcgsXSBPRda/sSnZ7nksliReOi8u1X1Bc0qEcypVxQohUXiQQCATI5Ig4+BAR
Z0E5HEpSvqzCglFPJBL1eh1JJ65Z3G+FNBRueQRCNQsK7fP5IMNqtdputxF5iCGUF5TjSCSSy+WQ
sMKwBoNBrl+4boWFRRvGDLdaLVy/rle7Jk19GIZWq1UqlVhtnkgkoEHgcJETiusmkAcggtOHKJ5L
JUtpfHyc07+2bXN6kE13cEVTrNaTYvwOAIortsyZpb5kSsy7WTupBFjzw+HgU15FVJRu5aFIJcHA
YPhSqdTdu3dF9zyRSBBQcygU4q7cAqXT6UKhgMyJAhHeC8rx8vJyMpnEY/g/V5cFsMy5uTmPVkG9
xwB7X6/X2U6JF7JzMmR3awzhlk3TNDMyyHFNmn5ThgHw6JTWB2A6vEvkPcRggqsi7Ut71mo1BQLt
YCj2isSFCIorBgHcX8UgQFrqLpJY5CMNbqQSYIsy4Ziz/9rtdqUpF2lZkRQfWJH66HkBiDgNBqaV
lRWFLTH6vGzL48RzHIdNKHHbTupsqlTCbLnq2tpav1ePadL0XqaSTpveGALtMNrkLUqg3W5PT09z
lkOf1B0mocRKW7wjZRjSOw2afpuGIZ1Ol0olNlimVNJpkEcE2neNxIzNYFczepFAIBAQL5DSbukJ
zrc3dneCJk3vI2l0VU2aNGnS9BppdFVNmjRp0qQNgyZNmjRp0oZBkyZNmjRpw6BJkyZNmrRh0KRJ
kyZN2jBo0qRJkyZtGDRp0qRJkzYMmjRp0qRJGwZNmjRp0qQNgyZNmjRpevv0/w8A+JHUmtyKrq8A
AAAASUVORK5CYII=

------KDChRjkJxjrsvNJceTBzCOP9dW89Budi4PBY5VECe33LSM-3=_5db6d_--


From nobody Wed Sep 13 02:41:38 2017
Return-Path: 
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 9C47C13301E for ; Wed, 13 Sep 2017 02:41:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 Gwg99vMfoPRz for ; Wed, 13 Sep 2017 02:41:35 -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 EA6661321A7 for ; Wed, 13 Sep 2017 02:41:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=60135; q=dns/txt; s=iport; t=1505295695; x=1506505295; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=K/ywVsKLk6/1wq2LCNcniSo/Kkgf0MKqRTSW9U7+vE4=; b=EhNUOSFYdtzPEl9RPFRGWgZZuRtDKBYGM7yFXJT7kgcK3TOOnsTBN6Nh 6Q1vJCB9L+9l1MPgKTX+buGTixsk8jbIsTyqeaNhlbR5uJgH44bC8aw3c z7/2hABoe3e2XYZuH2QEJQtCcAKnAT1iHkJHoK6awo5v5achguFUWKG98 o=;
X-Files: 201602111742151_N3WZA6X7.png : 33527
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BWBwBW/LhZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm8+gRFuJ4N3ixWQeSuQZ4VNggEDBwECGAEHhE9PAoUMFQECAQE?= =?us-ascii?q?BAQEBAWsohRkBAQQBAQMeCkELEAkCGAUBAQEiAgICFQEOATAGAQwFAQIBAQIVi?= =?us-ascii?q?hYQjxOdZoInJ4sPAQEBAQEBAQEBAQEBAQEBAQEBAQEBDg+BIYIKg1KCDguCcoM?= =?us-ascii?q?ngRgRES2CfBaCSwWRKYcNiEKGWgGBAIx3ghOFaINaJIZ7jVqHVYE5NSKBDTIhC?= =?us-ascii?q?BwVICqHHT82AYV4gkEBAQE?=
X-IronPort-AV: E=Sophos;i="5.42,387,1500940800";  d="png'150?scan'150,208,217,150";a="657429577"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Sep 2017 09:41:32 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v8D9fWgd012950; Wed, 13 Sep 2017 09:41:32 GMT
To: sk.srivastav@samsung.com, "netmod@ietf.org" 
Cc: KARTHIKEYAN SUBRAMANIAM , "cpgs ." 
References:  <20170913073034epcms5p3ba5e2a0c180d8cd9f4464d8e5921d106@epcms5p3>
From: Robert Wilton 
Message-ID: 
Date: Wed, 13 Sep 2017 10:41:32 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170913073034epcms5p3ba5e2a0c180d8cd9f4464d8e5921d106@epcms5p3>
Content-Type: multipart/alternative; boundary="------------10939D576D7DD9B32C2DC8F2"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] draft-srivastav-netmod-formulae-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Sep 2017 09:41:38 -0000

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

Hi Sudhanshu,


Thanks for posting this.


The premise of what you are trying to achieve here is interesting.  My 
interpretation is that your idea is to allow a NETCONF/RESTCONF 
server/device to take existing data in the operational state data tree 
and to construct new derived data (or perhaps just metadata) by 
executing a client defined algorithm that is described via extensions 
statements to YANG.


This broadly seems a reasonable idea to me, but I'm not sure that I 
would implement it in quite the same way, and I've put forward some 
other points or issues that you may want to consider.


1) In particular, rather than modeling the expression directly in YANG 
using YANG extensions, which effectively makes the expression look like 
quite a verbose abstract syntax tree, I think that you may be better off 
defining a separate expression language, similar to how Xpath is used 
today.  Probably it could be related to Xpath, perhaps it could be a 
superset.


E.g .to take your example in 3.10, I think that it would be better if 
the expression was written more like a normal mathematical expression.  
E.g. I think that the following would be easier to read/understand.  
Obviously an implementation needs to parse the expression, but that 
shouldn't be too difficult, and they would need to write code to 
interpret the expression anyway.

    container formula {
       leaf a {
          type int32;
       }
       ... leaves b to d defined similarly ...
       leaf e {
          type int32;
       }
       mt:math x {
         leaf x {
           type int32;
           mt:expression"((a+b) - (c-d)/(e*100))";
         }
       }

2) I think that there are some questions about how these expressions 
would get programmed into the device.  Are they statically included as 
part of the schema loaded by the NETCONF/RESTCONF server?  Or are they 
programmed dynamically via the NETCONF/RESTCONF client.  For the latter 
case it would be necessary to either define new RPC operations, or 
perhaps better a configuration and operational YANG data model to manage 
the expressions.


3) I think that it would also need to be considered whether the 
constructed expression values are represented as new nodes in the YANG 
schema (which would probably prevent them from be constructed 
dynamically), or perhaps they should make use of YANG metadata (RFC 
7952) instead so that the base underlying schema isn't changed.


4) Any solution should probably also consider how it would inter-operate 
with the work currently being doing in NETCONF on YANG push and related 
technologies.


5) They may be security implications of allowing a client to execute 
arbitrarily complex expressions would may degrade the performance of the 
system, although perhaps the memory and cpu available to execute the 
expressions could be limited.


I hope the brief feedback is useful.  I'm not sure how familiar you are 
with the IETF process, but please note that these comments just 
represent my personal opinion and do not necessarily reflect those of 
the wider participants in the NETMOD WG. Other opinions may, and in my 
experience probably will, differ :-)


Thanks,
Rob



On 13/09/2017 08:30, Sudhanshu Kumar Srivastav wrote:
>
> Dear NETMOD Team,
>
>   I have submitted a draft for new YANG module that defines new YANG 
> extension statements and method to model the formulae/KPI's.
>
>   Request you to please check and provide your comments.
>
> *Draft Details:*
>
> Name: draft-srivastav-netmod-formulae
> Revision: 00
> Title: YANG extension Statements for formulae modeling
> Document date: 2017-09-12
> Group: Individual Submission
> Pages: 28
> URL: 
> https://www.ietf.org/internet-drafts/draft-srivastav-netmod-formulae-00.txt
> Status: https://datatracker.ietf.org/doc/draft-srivastav-netmod-formulae/
> Htmlized: https://tools.ietf.org/html/draft-srivastav-netmod-formulae-00
> Htmlized: 
> https://datatracker.ietf.org/doc/html/draft-srivastav-netmod-formulae-00
>
> Regards
>
> Sudhanshu
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


--------------10939D576D7DD9B32C2DC8F2
Content-Type: multipart/related;
 boundary="------------540515D404FECD890DA94934"


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


  
    
  
  
    
Hi Sudhanshu,

    


    

    
Thanks for posting this.

    

    


    

    
The premise of what you are trying to achieve here is
      interesting.  My interpretation is that your idea is to allow a
      NETCONF/RESTCONF server/device to take existing data in the
      operational state data tree and to construct new derived data (or
      perhaps just metadata) by executing a client defined algorithm
      that is described via extensions statements to YANG.

    


    

    
This broadly seems a reasonable idea to me, but I'm not sure that
      I would implement it in quite the same way, and I've put forward
      some other points or issues that you may want to consider.

    

    


    

    
1) In particular, rather than modeling the expression directly in
      YANG using YANG extensions, which effectively makes the expression
      look like quite a verbose abstract syntax tree, I think that you
      may be better off defining a separate expression language, similar
      to how Xpath is used today.  Probably it could be related to
      Xpath, perhaps it could be a superset.

    


    

    
E.g .to take your example in 3.10, I think that it would be
      better if the expression was written more like a normal
      mathematical expression.  E.g. I think that the following would be
      easier to read/understand.  Obviously an implementation needs to
      parse the expression, but that shouldn't be too difficult, and
      they would need to write code to interpret the expression anyway.
      

    

    
   container formula {
      leaf a {
         type int32;
      }
      ... leaves b to d defined similarly ...
      leaf e {
         type int32;
      }
      mt:math x {
        leaf x {
          type int32;
          mt:expression"((a+b) - (c-d)/(e*100))";
        }
      }


    
2) I think that there are some questions about how these
      expressions would get programmed into the device.  Are they
      statically included as part of the schema loaded by the
      NETCONF/RESTCONF server?  Or are they programmed dynamically via
      the NETCONF/RESTCONF client.  For the latter case it would be
      necessary to either define new RPC operations, or perhaps better a
      configuration and operational YANG data model to manage the
      expressions.

    


    

    
3) I think that it would also need to be considered whether the
      constructed expression values are represented as new nodes in the
      YANG schema (which would probably prevent them from be constructed
      dynamically), or perhaps they should make use of YANG metadata
      (RFC 7952) instead so that the base underlying schema isn't
      changed.

    

    


    

    
4) Any solution should probably also consider how it would
      inter-operate with the work currently being doing in NETCONF on
      YANG push and related technologies.

    

    


    

    
5) They may be security implications of allowing a client to
      execute arbitrarily complex expressions would may degrade the
      performance of the system, although perhaps the memory and cpu
      available to execute the expressions could be limited.

    


    

    
I hope the brief feedback is useful.  I'm not sure how familiar
      you are with the IETF process, but please note that these comments
      just represent my personal opinion and do not necessarily reflect
      those of the wider participants in the NETMOD WG. Other opinions
      may, and in my experience probably will, differ :-)

    

    


    

    
Thanks,

      Rob

    


    

    

    
On 13/09/2017 08:30, Sudhanshu Kumar
      Srivastav wrote:

    

    

      
      
      
      
      
      
      
      
Dear NETMOD Team,

      
 

      
  I have submitted
          a draft for new YANG module that defines new YANG
          extension statements and method to model the formulae/KPI's.

      
  Request you to please
          check and provide your comments.

      
 

      
Draft Details:

      
Name:
          draft-srivastav-netmod-formulae

          Revision: 00

          Title: YANG extension Statements for formulae modeling

          Document date: 2017-09-12

          Group: Individual Submission

          Pages: 28

          URL:            https://www.ietf.org/internet-drafts/draft-srivastav-netmod-formulae-00.txt

          Status:         https://datatracker.ietf.org/doc/draft-srivastav-netmod-formulae/

          Htmlized:       https://tools.ietf.org/html/draft-srivastav-netmod-formulae-00

          Htmlized:       https://datatracker.ietf.org/doc/html/draft-srivastav-netmod-formulae-00

      
 

      
Regards

      
Sudhanshu

      

        
          

            
              
              

            		
          

        
      

      

      

      

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


    

    

  


--------------540515D404FECD890DA94934
Content-Type: image/png;
 name="201602111742151_N3WZA6X7.png"
Content-Transfer-Encoding: base64
Content-ID: 
Content-Disposition: inline;
 filename="201602111742151_N3WZA6X7.png"

iVBORw0KGgoAAAANSUhEUgAAAggAAADICAIAAAAC6Y6pAAAACXBIWXMAAAsTAAALEwEAmpwY
AAAKT2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUI
IFJCi4AUkSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuj
a9a89+bN/rXXPues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMB
APh+PDwrIsAHvgABeNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCd
mCZTAKAEAGDLY2LjAFAtAGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgw
ABRmS8Q5ANgtADBJV2ZIALC3AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88Suu
EOcqAAB4mbI8uSQ5RYFbCC1xB1dXLh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHg
g/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgug
dfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7i
JIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd0yLESWK5WCoU41EScY5EmozzMqUiiUKS
KcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA4vcAAPK7b8HUKAgDgGiD4c93/+8/
/UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzABhzBBdzBC/xgNoRCJMTCQhBC
CmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/phCJ7BKLyBCQRByAgTYSHa
iAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5h1xGupE7yAAygvyG
vEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+Q8cwwOgYBzPE
bDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhMWE7YSKgg
HCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQAkmx
pFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io
UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgX
aPdpr+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1Qw
NzHrmOeZD5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnU
lqtVqp1Q61MbU2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1
gTXEJrHN2Xx2KruY/R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIp
G6Y0TLkxZVxrqpaXllirSKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acK
pxZNPTr1ri6qa6UbobtEd79up+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsM
zhg8xTVxbzwdL8fb8VFDXcNAQ6VhlWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZL
TepN7ppSTbmmKaY7TDtMx83MzaLN1pk1mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnu
trxuhVo5WaVYVVpds0atna0l1rutu6cRp7lOk06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFn
Yhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7RyFDpWOt6azpzuP33F9JbpL2dYzxDP2DPj
thPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3IveRKdPVxXeF60vWdm7Obwu2o26/u
Nu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+BZ7XnIy9jL5FXrdewt6V3qvdh
7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/0QCngCUBZwOJgUGBWwL7
+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5pDoVQfujW0Adh5mGL
w34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5qPNo3ujS6P8Yu
ZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIsOpZATIhO
OJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5hCep
kLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ
rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0d
WOa9rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWF
fevc1+1dT1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebe
LZ5bDpaql+aXDm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ2
7tLdtWHX+G7R7ht7vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHt
xwPSA/0HIw6217nU1R3SPVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTra
dox7rOEH0x92HWcdL2pCmvKaRptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLT
k2fyz4ydlZ19fi753GDborZ752PO32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86
X23qdOo8/pPTT8e7nLuarrlca7nuer21e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/Xf
Ft1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfVP1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9D
BY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i/suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl
/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8IH8o/2j5sfVT0Kf7kxmTk/8EA5jz
/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADqYAAAOpgAABdvkl/FRgAAeCJJ
REFUeNrsvU1sG8fWJtxjWzdqBjINMoEvDNIXNw4VYCCLeD0bAsRgTC0GsLjwhgt5QS7DLCJA
wAgCZF2tFEUYQcBooAzg9pJcSMDLjRdkgG8hevES4CxeYyhrMSHjzMRsGPHnkGPKE7Zz9cn3
WzxX55arqotNUvJPUgdBYNPd1adOVZ2/OvXUv/nb3/5maNKkSZMmTcd0RotAkyZNmjRpw6BJ
kyZNmrRh0KRJkyZN2jBo0qRJkyZtGDRp0qRJkzYMmjRp0qRJGwZNmjRp0qQNgyZNmjRp0oZB
kyZNmjRpw6BJkyZNmrRh0KRJkyZN2jBo0qRJk6Z3mM7+3//7f/8fgUZGRnZ2dp4+ffpv/+2/
fcMMNRqNYDDY1yu2bY+MjIyMjAz2RcuydnZ2/vVf//Xf//t/L3JSrVY3Nzf/3b/7dz6fj/2n
tbU17sc3KSJ8/b//9/++s7PDsf3bpnK5/N/+23/7j//xP76taek4ztOnT8+fP+/xxUKhcO/e
vVMdowGWzFuhVqv1X//rf713796//uu/3rt3T7qm/vznP/fVF1r78/Pz58+fD4VCivUy/God
jEmPWuh//+//rdC3w4yyd7bpyXMbGxv4aX5+PplMJhIJ/LVarb75qWNZVjAYjEQiffXZsqzF
xUXTNAf4om3bjUYjnU5Ho1FOAVWr1cXFRelbkUiE5Pbm6e1+/XdINBkcx/n666+TyaRUAb1d
3t59Me7t7bVarZWVlcGWqnrtv+8rIpvNnqxiHJLerVRSu90ewA0Z5ouO4xiGIa7zIZvV9Fsi
mgzdbhcT5h3k7b2gYDB4Ulbhd7VIB1CMQ9I5tTe9trbWarVM08xkMpFIxHGcXC7XaDSgTNPp
tBiblMvlYrGIB1KpVCgUqlarxWIRKwpBSbVaLRQKsVgMcUkkEslms5ZltY4pm80Wi8VyuYzJ
lEqlIpFIoVCo1Wrj4+O1Wg1NhUKhQqFgGMba2lo2m63X69wrHG9sm4lEIhgMWpaF11OpVCwW
Y70wRFGpVAoJAfQarJKr4jhOoVCwbdswjGg0mk6nRRmqH1hbWzNN03GcVqsFkebzedu2Sbwk
T3w9k8nYto2vS0etZ4NSlkRpSx8TmTFNkx3xVqs1NTWFIeYGneOzWq2Wy2WsbZoqYB5yo1nX
arXQBakJh3XH3MBfE4lEMpkUZ0ssFlteXp6bm0MjGETOgRW5ajQaNBkoO+Q4DiYkuDJNE+0b
hpHP5/FFyAfmZHNzE09CFOANY2GaZjabrVar1WpVvdBE4di2TbytrKyo1yY7oMSwZVmO46DB
27dv7+7uqldQo9EoFArQCWiBY9VtHG3bxiTBmioUCouLi8FgkMTFjuwAa9+yLCxhcYq6eYRe
5gzmrZRJqdLjFmkoFLJtO5lMsrNFqgcQEyQSibW1tUgk0m63af1C4H0pRgXb4uvSJ8+oDUMq
ldrY2AgGg+h2oVBot9uLi4sbGxumaebzeXHeFIvFZDK5srIC0WMmTU1NbWxspFKpYrHIJqk2
NjbS6XSj0ajVatlsNhgMxmKxbDZbLpfL5XI2m93Y2IjFYrlcDmsVC3JjYyORSBSLRUxEwzCg
Jcvlcjqd3tjYCIVCuVxOHDxqE9IMBAKI4BYXF8kqYJbEYrFgMMjGpyyrrJTxT3Nzc7VaDRJn
J18+n0ecu7i4SGtDdHzS6fTi4mKr1bp7924qlcKfq9Uq5IlOsUqqpyfl1qCUpUajIYpO7JqU
GfyIeRIKhWAJoIMw6JjKrNAgmWKxODk5ifZbrRaJrtVqibPOMIyVlRU8Kfa3Wq3W63VMS6gG
rEButmBNEie1Wi0ajbJWQcoVOxkwzVKpFDW4sbGxsrJCrJbL5VqtNjc3Nzc312g0dnd30Ww0
GiU2ICLHcWKxGLoJDeJloXHCYXmrVqu2bS8uLmLplUol0SsSGUabeAtGUVx0rHxyuRxYHR8f
h4HM5XJgdWVlBSrGjdVkMglWyWKVy+V6vT43N4d3xXXqce2TAfO+XjzOGcdxpEyKSk/6UTQV
i8W86AFWznNzc7RmB1CMbmxLX5c+qTIM0WgUEo9Go7ZtO45Tq9UwEWGXbNuGNInq9ToUq2ma
i4uLc3Nz9XodltAwjFgsFo1GSWrQxUjuc7ESFi2+jnf39vbg6eCt8fFxKCB6BSscnlc6nRZH
EcyjzVQqZZqm932UZDIpZdXn87VarUKhgBnP+cX1er3VauFdDK30i+Pj46FQKBgM+ny+UCiE
P0PJYrDxXdZ0qUnRoJQlqejErkmZqdfroVAIf4VUIWrTNCGNSCQSjUYxfOxgraysgA1w2O12
WebZWddoNGKxmGma9CGOEokElB2NEZSvOFsikQgNQa1Wm5yc9MiVNCk8NzeHt6LRKL5Yq9Ui
kQje3djYQFMkCnbSEm/oLK0Fx3EUC40TjqhQEO4sLi6KPqmUYbSJD7ktOnY+w54ZhgE9CLWI
4Ns0zVQq1Wq1YHrVrLLLPBQKkYgGW/vc9puX9eJ9zkiZ9PhR/OhRD7BvmaaJNct107twvMtW
+qQqlcRlA7FIisUia+64lKvjOGIAGwgE2DbpFUW2EWuDczOhrdxeCYVCyWSyVqsVCgXkqeBQ
sJywO8w+n897vtiN1enpaRiYarUKBtjoG+1vbm66RZ2IV9jGxQ/BE4RABuCWa1DKklR00q6J
zCBXwA0QtBvlXrB4xHgUy4PSiYpZR5PKrawCCpHzVMTZEo1G2fCFqzhQcCWdohjHRqNBnrXj
OGK2QTpp2R+5BxQLTbFkEolEt9ullBQSej0ZZtt0W3QcD+xyhrRpUNBUT1al6oLkNsDaH2y9
eJwzUiY9fpQVCLfoBtA2fQnHu2ylT57zvh2Bb4sFPFyXuPAzFAqxfofjOF5mDGwXbCwRUgpq
LwCLAXk0ilSIE5a3brc7/D4Y8nSpVArJk1wux0YqaF8sw5D6HW4TDpo6EAisrKwsLy8PybCC
JVF0XNeQhOWYCYVCyC+zSg3ePfxTt2TX5uYmPKPFxUUxJ8nNOjj7oiNCE6PRaCA0SSQSitbg
LGNCitPYO1dY5+hmKpWizS1x/g9AXhaaW1ybTCaR3ikWi4hd1Az3XHTi5Gm325weabVa7Oh4
X1amaZJSZv3FAdZ+v+ulrzkjMtnXR90W3WDr16NwvMu2VquJT57pi6dIJFIqlTD1C4XC8vIy
JykEMphz+Xx+eXkZ6hi/VKtVhC1unwgEAmgwGo0iqY235ufnWe3DqWb0h30MbLCuDdpETpz2
DxWcBINBRRqB3enF9jUCMc6fHR8fN00TKXvHcTY3N/Gwd7JtOxgMYsGLuyYDkJQlqejErkmZ
GR8fJy+7XC5j+PAjBh0lDJwawrdge/b29txSDTTrqtUqNt+kMXij0YC+m5ycFPWdGDTUarV6
vS6OvhtXNBlosoGZaDSKqJS4ikajjUYDziMJcIDF33OhiRO1UChQqQgGkZ2NbgxzklEvOkwe
Guv5+XkYbLje2FMMBoP4uhfCWOArFB4NsPYHWC/e54yUyb4W6fB6YADF6F220ifP9cVfJpPJ
5XJra2sYFRSlcOm2ZDKJKBgPoMSC4mKqSnJTW8VisdVqzc3NdbtdEh/yGNLYEAn0zc3NdDqd
SCTolUQiwa18xNp4AJ4+5+1yHSkWizjboRAIagaQM6HdMHaFZ7NZxQM9KZFI2LYNHwQVIKgv
GsbjEFkKBoOtVosTXTAY5B6DD8IxQ+UchUKBGItEIig0oC1fLkiKxWK1Wg3BNbw27E65zTrL
sjDrpH1PpVK5XG5+fh4pFHHrixtZKBQxTeTGFU2GlZUVJKO63S7Nc+x8YPcS44UWILSehmqw
hSZOVFQl4RWk+9lXoLlEht0WCC06bvJkMhmaFXgA1Qo0Oul02rtfnEgkaOLRyErZ6Ln2+10v
3ueMlMm+FunwemAAxehdtij84578N3/7298MTZpOiLhjku8m5fP5QCCgNvmaNP2eSWMlaRqK
KKVAKcQ3eT5zAELZjPcSL02afod0TotA0zAUi8Xq9TqSJ8hgvDtwESJhax3llXrsNGlyI51K
0qRJkyZNr5FOJWnSpEmTpoEMQ6PRmJ+fd6vRLpfLKEvw0sj8/PzJQreiWa6+SPrj26LnOzvf
Xbki/offn+/s9NVa27J+uH7d7V8Pm80frl//7sqVp0tLp9Sdo07n5f6+YRjNTOb0vnJSNICE
QU+XlhRydqOTkgnYVo/1iXBFnxhYUOrvNl3QitbW1uYFsiwLdbeDaRjjuOb4jZFaMYo0jPaD
cN5Aj4w3vMeAM7SKc0+/VbowM3NhZsYwjG6l0sxkwrmcLx6HEh+gtUA2G3AH6X1RKh02m58+
eHDW7z8lq/C/EomPFhZGJybCJ3G0QtMbIMVIqafT6RGhQKJQknCnpbqPDmD2VJ1vGJ66Xwz8
YeDBs6c/TITi/kZTSd1u913emfzN0Eg4fEpWwTCMVwcHR52OFrKmd5DePDz1b4wo9DknRVdW
YyZLgVsNwwDYDmFCENIkGfPGMS0uLnII2DhxU61WAXmfzWapWSlcsOECKiv+yDUrQnNLIY7F
PrpBjrtJwzu9KJUQ5o9OTFz65puRcPjl/v7TpSWka8ampy9tbXGx//Pt7U/u3//h+nUYgJf7
+2f9/ktbWy/395+tryMt8Mn9+79UKj+vr0OPf7ywEMhmEbKMTky83N//eGHh2fq6Lx7vVioI
a/y3btmZzFGn44vH4WO2LQsNGobhi8cvbW0h7fB0aelVp/NLpfKHcPji6irH8MWvvnp1cPDD
9eu+ePzw8ePDZpO6xiZqXnz7LTp71u8P5XKd7e3nOzvoiC8ef76z075zB0HV6MTExdXVw8eP
n/7lL58+eEByeFEq/enePTZlx70yOjFBgc6T2Vn01E3OF7/6SjSoz3d2fl5fNwzjo4UFhH34
hZWqdFilj3UrlZ+Wlg6bTRjvM35/OJdTsP2PGaLs+A/Xr49cvvzr/v5Rp0MtNDOZV50OxPvB
xMQfwuGRy5d/qVQoemhmMh/G44ZhYDqpOaeZMDoxcdhsIs7o2UfDMEYuXx7Ag+SAysmTVagm
Frd/fHycXfUsoClgsaGsOOR/cY0j5RWJRPBjLBYjrHIOgR8YqyxjUo0B1HF818tlBGI8hKOj
bjpH+lFRybdaLRHfe29vj1Dcz0jRlRVA2W64r8Yx+Awdw6tWq+zZY+j6WCy2uLgoImCjEYLq
Zbvqhm8sBZWVAuRSs8Bp4JgX8YqlMNRSJGSFNLzT4ePHn9y//8n9+4fN5vPt7aNO58mXX57x
+z979OiT+/dfPnxIqlnybrN5cXX1s0ePRsLhZ+vrgWz244WFkXD4s0ePDh8/frq0FMhmP3v0
6OLq6rP1dcog++Lxzx49GpueNgzjVafz6YMHl7a2nu/sPF1a+nO5fGlrq1upvCiVupXKs/X1
S1tbaKFbqXR2dqBBLq6ukkI86nTsTAYM/+nevZcPH/58zPCrTudP9+5R18SslP/WLTBvZzIf
XL1KHTnqdH5eXx+bnkabh81m27LA8ItjQOnn29v4hVoTX6F/7ezs/Lq//8n9+58+eHDU6eAT
bmyz4oV8Atns06Wlw2YTtgRSDedyz9bXXwgA1zDV4mMwTh/G4589ehT44gsYJDXbIHXH/65M
K5WPFhY+e/TojN//5MsviX90GX/1z8x0KxVYoMNms1up+GdmvHCOmYCZNjoxAUvgpY+DJUul
QOXGMQ4g4MpxkJs9rszCU7OrHjrEDYubhdN3gy53HGdlZSWdTkN33759m0PglzKmAEL3fhmB
dA9Acb+A+FEF+D+H782iuJ8R0ZUVQNlGL2xeQiizbbvVarkdI3JDwAbGmZhZk+Ibu4HKigC5
1Kwb8xxesQhD7YaE3BOp2NMOxK1bI+HwSDj8wcTEy/19LN2PFxaQFLpw61bHfUvQF4/Duxyb
noaiIfqlUhkJh6G+L8zMjE1Pd45VM6tWxqanz/r9o1ev0p/xr0cHB6z9uCBoEFYlHXU6f1xd
hTt54dat5zs70B1okLrGvXjW70ez6AL+PDY9fdTpnPX7P33wAEIYnZj44FgZjd248eLbb6GV
DptNVq+5vcJaDjjmn9y/D+PnxjablIMAA9nsWb//Ran0olQ66/fjR188PjY9DX7EKFB8DF/8
aGGBRsQL238fJveO0zhCgB8vLMCA4dNslIbBhYGBdREjJCnnv1QqoxMTaP/i6ireUvQx8MUX
6CMX+ngkKVC5cYxGB82YSCSgGRWNYNUrYLFF5H8pdDlwFQlFnFrmgKJFxtyA0Ae7jID9luJ+
Ae6jCtBvBb73ORFdWQGUbfTC5o1Go7hKSbwFhSUpArbP55Mi67rhG0tBZaUAudSslHkpXjEH
Q03IoxwSck+kYi905vXFeXRwYBjGjzdvenn3rPut9C/399ko/uz58y+PNQ6rDs64/JmyCr8+
fHh0cCD1i8kthQ5lG8Enzii3Os4wzJ8ROvJyfx+WDIEOtuvHpqebmczRV1+9KJVEvSZ9hbZY
jzqdzs4OslUU7nBsvzo4YNtkBXjm/PnDx49hYL67coW1zZKdmE5HfAyCovbPnj9Prrcb26ze
V3ScnQmUXZROjwszM09mZwPZbGdn5+JXX3nk/KjTeW2enD/v+uTBASvV0YmJv/YfNCgQtjOZ
zO7uLlYiILncziqyjahhsRWqADd2qIHx3RhTAKEPdhkBaTbF/QLiR9GgFPRb8a1zInB0LBZT
AGVLgVsJKQwIZWBLgUXTFwK2G76xFFRWDZDrBiws4hWLMNSGDAm5J1LxAITFPHxZ0ejEBKvN
j15XeV4IyaULMzMj4fCnDx58f+2a2143zAP+8KrTgfYchvnDZvPHmzfHpqfPnj//yf37lBuB
C9zZ2ens7MD17vkK0ccLCx8vLCDX8Wx9HU46xzZnn14xvXh1cDBy+TKS+Gx+383Yi49hOBAP
kQfQk+2eHWf9CZI8N/psO2fOn4fbIeaj3Dh/tr6O7RkShbqPL/f3ESsQVydFAH2jfdBSqSRe
ScRRX9j1oioYhjG31ga7jIDV/or7BbiPQjtxoN89M95nRHTl8fFxBVB2T9zXWCyGGw0VoNbe
EbAV+MZSUFk1QK6UeRGvmD0DQTDUUiRk7yi4fbhL8fhZv//J7CwW+Y83b7pVgqvpw3icEtbP
d3bgafbVwq8PH46Ewx8tLHy8sAB+yAywGhMM/7S0BI3glqPoi36pVODmX1xdfVEqsWmoC7du
oVNjN254fMU4PpRw2Gye9fux4+qfmenJ9sv9fXjxT5eWjjqdsenpD+Pxl/v7YODl/v4P16+3
ZRDK0scgKOxkYBenJ9tcylHacdLISOM8XVoaCYcVOZwLt2693N932zOXco4fIYq2ZcH2KPr4
7PU+nmDNzPz8PEFy+Xw+Dlqf4Km5/IRHLG5RFXgnkTEFELpax/a0c4r7BcSP4vZDj6DfhOJ+
TgSOxv85oGzSd1LgVjY/NTk5iX2YnrdNeUHAdoMLdgOV7QmQKzLP4gYD7ScWi7GPAYZ6fHxc
REKWNohCBbQzSMTg94dyuadLSwjSRycmkAcfwMBcXF39eX0dq5Sqkry3gA1SBAoXZmZeHe8T
jE1PPzuuRREZpqqkYVTAhZmZF6USHFvkr4lzfP3CzAynxBWvoKbor7OzKKk66/cjUS6yLY5F
Z3v76dLSWb8/nMthK4iV6tj0tFTDcsKnxy5tbf20tPTdlStoqifbXDZJ2nEKEJ/MziKgCSuv
GEI7bl6CG+cfLyw8XVp6urREJsftyVAu9+TLL9k+okzuwszMxYFmMqsNWNUUiUSmpqbYBwie
mtWzUlhsaSgAy+EGXa4mKWNurXG49OrLCDiKxWIiSL66C95BvwnF/VSwkpaXl1OpVL/3T2nS
5JG+v3bt4ldf9RsAvWvUzGRQmzt8x3+4fv3DeHxIteudvrtyRVGnq+k3QCd/wK1arfp8Pm0V
NJ0SPd/ZOXP+/PtoFV7u73935QpyL91KpVup9FW08xY73ras765cQbwI/qU75Jp+M3TCkBg4
ltJzO0iTpsHox5s3X+7v9+Vlvzs0OjERyGafHede+sKieLsd98/M/FKpIN+FRNxgdaia3hfS
sNuaNGnSpOk10rDbmjRp0qTpdcPQL5TrkOWYPV/HVZF9IdlyjaOca4DXvdObwb99K2RZ1vz8
vBrimCrz3P61Wq16x0k+vbnEEmpRUO84GO6x+kW0P3BfMO1P9kkvAhweS7/fQSEw8zeAD3/Y
bJ4Glvgp0TCsYhNI+k8ocpNiyCtA3c/1BeU6JKqtl9d3d3cHOzJGMFva2g9Mtm03Gg3xHN8A
5BEneRhN6n24Hcf5+uuvUUw88BcVgMnU/vsFHqyGjB5gBPsalNPGh3/v6LNHj068TQLclP6r
Yperv1TSkKi2Xl5nYS36olMNEX4nhMNB74V262u4gbJ5esycdvvvC/W7Bk8VH16TYRgAcRmA
zsGLTyQSIgorp6BZVFuKnYEnBSRtBJKWZWWzWdM0OaBX9nW3MAUxMl7ESQ3Cj8UhOADe4ru3
b9+mAyNwVdACjm8UCgW8S+i1aixxwxtiLXfmpWebOI5PsL0IhvDj4uIiJDw/Pw9n07IsoFnh
TB+9BaBgAH6IzEgxeHuCgXOdTaVSjuPg1Mza2pp4Oq9cLuMwDms2FN3HiKRSqVwuRyOFw4lA
qeRexMwhMC9CgMfEAz4M1zhEt7Gx0XMUkBIpFApoBDgzhhKXWDo5aWpx2MjUvuM4ANnlZtHa
2hokgKmbyWQikUir1crn8/goi/clvi59UgzH2aWxu7srTgB2EGnEgXbcaDQwwQjZntx/KUti
j4AnSoPS05Nl8eFZpD8AhMCTxa1QF7/6auTyZREgnT29gQalTrcIay/inL/qdJ7Mzv65XIah
alsWasCera+jPHckHP7j6qpYpAuXHJeUhHO5XyoV8XnCIT/r9wO8XYqr/92VKzj9/mE8znY/
lMuNhMMiaPxhs/nkyy/RiLRIrG1ZyE3hdOGrgwPUthnHx10pnhDh089wyoJFYeU+I6LaAtxV
OvAimjf3uiJaB3ZTLpcDzDU+kT8+zEnfZRU0CxjLtkbotVj5wLnNZrPFYlFEvpMi1lqWBcTa
ubk5FrHWOL4oQt0mCXZlZSWbzZJGU0f3gO5qt9sYjna7DcUnMiPF4PUCBi6Klyzo4uIiZxWA
NQ8QY1JMXroP7CwWiX1yclLxIrqPOQNF32q1Go0Gl9pih1uNYAyC15JKpUiwi4uLNM8VuMTq
zBLNLmo/kUhI4dkNBgWaoONhnFZWVubm5miApK9Ln5Q67BhQ7PFwEwCDmEwmMb25TTK4gxsb
G1NTUwSDr2BJ7JF0DboRiw/PWgUoSgLSAKCsLx7vCZCu9po5WHsR5xxQVASU+3x7e+zGjbZl
tS0rnMt99ujRhVu3nszOSlHED5vNi1999dmjRwAI4Z4HNtfo1aufPXrki8eBraLA1b8wM0MA
9biwZHRi4ulf/oJesLDqQHP59MED9EIqZACdwV4C0+WzR49QM03IBRCIf2bms0ePcEfLy/39
1wyDAoVVpPHxcUXOR0Tz7jen0Wg0EolEMBjEwe5WqwX1of4uEXxDQq+t1WqE5RuJRAgeXPwu
h1jrOA78RAByQI/gYY9tGsfQ4nhGvTvHasBYLBYKhWBNa7WalBkpBm9PMHCFeKUElGBYC/Lc
PXYfAFZ4vtvt4q9uL6L76DX0+97eXigUUmS31CjxUoL+onmuwCVWtGDIsJHd4Nkxbwm3GUif
jUYDyDEYTcXr4pPqJSmdAPV6HX81TXNxcZG7YRfTgB6gEfHeo5PKfgBAHo4tbozwApCuIA7W
3hXR/dggvSiVXh0c4K9j09Pw+uHCS6GfCKle+jyYB2I5rjZR4+qPTU+/OjhAcNDZ3gYK/YtS
Cb2ARw/5dCsV/61bZ/3+0YkJvzsqPssnuAJW2K/HqFwIkrqVStuycLvG6MTEOW5yeB8/9cMi
mndf+36YZ2QA8C1oZI9Mco8BIpst5xD5ERFr8TvHBkCmPLbJMWOaZqPRUIhCCvALVF4oII4Z
BP4cBm9PMHA38brBHTuOQ0BdcB28dx+girZt7+3tkfpze5G6DFuYSCR64oupUeI9zg3DBZe4
38mPuSHCs4uv4EkaAvxB+jo3WAqviD4hnQDq3Tt26OHVKVjqayX2SyPhsC8ef1EqjYTDuKgO
WlIESPfYoIj9LsU598/MIIP04ttvoWePOp2XpdJ3vXAACZFX+vzfccgZ/PaeuPq4Gu+M3/9y
fz+Uy6GndC6SumAYxh+OZeLlmrwz7hD9l7a2WpaFT/ji8T+urp7AyedgMEheMClNEc3bLekk
JXgirVYLKmP4iQhvi/OSpHGGiFhLiwRs0BLy2KbBYIA7jgN3WPwn9VumaUL9icyIGLw9wcD7
FS+LZ06j7LH72IVCBp8uXBJf5AIpQDEiuac+SD8kgjF1nEtODkaYG17KuvAkobmxU4t7HWkf
7smePRInANDlFPvn7J9pinrv0QnS2PT0z+vruOJpdGICO6giQPpr2tZzAOGGc37W7x+7cQOp
f2CJIxT4WAZy7uaSi88jyDh8/JgMW09cfaAcHj5+zML9Xtra4u4rBKuwaq+GQ7n3xeNoB5sN
z9bX+6tKkqLaQsUgOqbydhHNW/G6dGZHIhFkdbAwgAeutk/s5BajbNzridW4trYmVuK7IdYi
G4u9Nfb2IS9tsjsuwNeNRCJoAepMkc6uVqsQLL47Pj4uMlOr1UQM3p5g4P2Kd3x8nAa3XC5j
EL13H6kGANl6fBFlzdiBl/q5NNxeEIxZUyrtnXdcYre5RzZJCs/uNsMxxLSlJ30dERX3pJqk
EwDjC0Hl8/nl5WV2vdD4YgsdmzFuLLlJUr0G+zAMN25g7/TCrVuGO677Wb//l0rlqNN5ub/v
Hd9bgXOOLBZ7K2LbshCvPN/Z+e7KFTU4sfR5ME+I5ThtoMbVR8z0cn8fCaizfr8vHn+2vo6N
hKdLSwA89sXjz7e3D5tN6b25FEn0DK1w2gN75h/G42fOnx8Jh/uLGAjVlvWtYrFYvV5HJB6L
xeBaimje7OvJZLInMHUmkyH8WNRCqB06AoyVesoczm00GhW3PXoi1tK1EN7bpFWHFlDvgbQV
XfbkFuCbpglm6LsiM6ZpSjF4RTDwYcSLnhYKBYCf99t99JH0tfRFcesF+zFujioN98rKiohg
LNWV3BXBrJy94xIrdHGxWOx2u6xgCZ7dbYZblkVDII4LvS59UkFSNHj8AYJCy5wQarUa/gl1
ItKpou4ROyjLy8vc5WLeCc77850duv1UCpCOi7i/v3aNnve05eCOc44taHLMcesfae2PFxbU
0IFuzxPWOn4cm55GkZUCV39sevrw8WP63KWtrSfHoPEj4fClrS3g8tqZDH4cnZiQ7j/DoqAq
SZG7Y+HTffF4IJt9a1hJlmVNTU0Nc+DovSCuMtUjtVotac3o74ps297c3DyRDI8mNaG2+506
HNq2LGww6NF5K/R2sJKwlfp+HRPV9OZtqvq6J02/YXq+ve2/dUvL4fdlGFAwp9e8Jje/YX5+
HlVJWhq/N3pRKn135cpZv/+ChxJMTadEGnZbkyZNmjS9AxGDJk2aNGl6pw3Dy/39o+HKYPul
vgBmm5nMwMC87xHo7m+VupVKzzo/6VuGEhb4tLl9A58e7BOQDPiUFqIMw893V65wzbLFl9zn
PPKActI3OYh9aYxhJDnMJBFXhLo10tJvSKf98i//8j8/+eSvjx//TZOmUyBMsF/+5V+8v/I4
nf7p9u33hds3Sa07dx79h/9wSo03/umf/t///J+ln/s/29uDaYn/7/nzxj/90//Z3tYLYZgZ
zmrp//nJJ29Anmf+eqJOhyZNw9PAWMFaMsPQUafDISsM/znAjuqBG3Ic37yWPoOY64fr1xFS
/XjzJk7BPd/Zwf1K+PHl/j4OyDUzGfz+482biL+e7+x8f+0ansTxOZw6QVPfX7sGjFn8GQEU
oiEcBqFPoDUcx/juyhWwxAaGL/f30eZ3V648mZ096nTcWOJSSQiEwQOe56QgdoGTBv25mclw
bCNMbmYy1F/pSqA4nRqRMv9sfR1HIikoZgFSfrh+nWJkOkUpMu/2ozTV5tYvSPKH69ebmQya
cussO2QU5D6ZncWPxD97hxSbX+pWKpDA99euPd/ZaWYyh80m/kDBtVTmP1y//uPNm8QJF5v3
NUwit/RpUZLcPKRIn/uRxhc/AsAATWEG0iekHWEbhGSwKtEsmwAR5Y8FSJ0SJ4D4CubS06Ul
doLR5/DLT6+vIOJBMdnQwadLS23L4oRP7JHYpWyLgsVyJsHSAqdXSGOIykRsbRhJKiYJmwLi
vsjOcFYmbCqJvtjMZAg2nHphGMaPN2/Sh446ne+vXWPPfg+8bP9hGIBmTlf8+OLxzx498s/M
iMi0f3cBOp0/3bvHYdhykK3g1X/rFjB17Uzmg6tX8WdWzXV2dn7d3//k/v1PHzwAo8jtAoNw
9OpVVkUedTpu0LscSwoz+NmjR5e2trqVCitE2C3ACoZzuWfr6/SvkAZdcoQHnszOAgL30wcP
DMMgrJXDZhM/ihAo3Url2fo6+nVxdbVbqRCeIsc8MB2hsw6bzW6lwgKkSL08Uf6KHrmJJZzL
SaF9wfxHCwvcj9TZzs4OQQ1/GI8/XVrCbOlWKn+6dw8iUvPPgRJf2toaCYcvzMyEczlWcbvJ
/OLqqji11K9ww6TgVipefAjz8EWp1LYsBZDyq07n0wcPLm1tPd/Zebq09OdyWZyB0o7QVz59
8GAkHP55fZ1DUSbmRfmDc5q9LMay2yto8+Lq6sXjU7jSz4kryE0DgKBYLq6uYhGx06ZbqWCy
XThGr5OyLUobLf8hHMZjP6+v//rwodhTqTJxa20wSXqRgPjFcC7HznCSCcsJDvcBQPDl/j5p
aToLLYKTc4pigGXLbz6zRGfQpci0eADgVoRhawiQrWgBZcj4K/4MCFlOprgx45P79y9tbQEH
ES7Apa0tVlgK6F2OJTcdhPMy6CArhRelEgHS4og8wbKzssafjzqdbqUS+OILXD51cXX1sNnE
COE8vfTTmFhogavO5pgfnZgYCYdhNl6USqMTE9IrOIik8lf0SCTqlxTaFw+A548XFg6bTfxI
nX1RKl2YmcF8vbi6etbvf769/aJUGrtxY3RigthQbMFxoMSiWVXLnGBt2KHva5gU3ErFe9bv
P2w2ny4tjRzrJgWQMsZ39OpV+vPfBf46go3YkXAux0K5uSVkpPJnFyCHsax4pSehg9wKctMA
bgsBwg9kszB41CBg4ES2RWmzy3nk8mX4oPQKQQNJlYlba4NJ0osEFF/kZMJygvkwOjEBYyNd
thw4ufhAv8tWZRhoWcLrRPqFDdJFDFsodAQmiJKM1yFe3eBecePoi2+//fHmTURSoxMTHy8s
vOp08F22tADNctC74PaMt9sB3bAMX3U6R50ORbXksHOv4Cu/vo52iwewyM+6o9pigj5dWkKE
+NoACFxduHWLcOHV4YKb/BU9kiQTGRBjii6BJPP3tXrcL3QWM4x+fLm/zyamz5w/j6/Tj9CJ
rhGDAEos0gAy7+sVNbeieD9eWAAyD/Kl3UqFgJQpMUICPyNMIfnklHGFBfjD9evP3O+lkcrf
UGIsu70y8AqSaoCe3Wxb1tOlJQ5CTmRblLbIjJQxqTJxa20wSXqRgOKLiqH/g4uLSUTg5HDp
REUxwLJlc93ycwxApsV0/+T+fbXT6ovHEZJcXF399TjQ9kgfLyx8+uDBpw8efDAxgRAskM3+
6d49mFbkVUkQrJ+CMTuRfa0zfj8sM/3HJjE4+mBigt0LOnpddaqtAnrRM7sCX+D5zs7L/X1u
vKU4w6L8++oRuyDhs9N/cCjIt8UXuclAqMi02XjG7z/r95P/TnxKmYfo1HtxA8i8r1ek3Cqm
N0DHkBxAzoqAlFnpDTktKTX8x+M8jJSk8le3PMArahpAAzxdWoKLShdbKjQgJ23vjInKRNHa
MGJRSGAA/s/6/V52m8empzs7O52dHYCTS12uvpYtqy7OwDRx60GBTCuaEBGy1aM04Q3hKtQP
jy9HpQAFv1BrbtC7wxuGD+Nx3MmHln+4fl2xWwsIXKS/4NPBdKs/8evDhyPh8EcLCx8vLPSc
GWjw5/V1McYUcYal8u+rR2y/OGhfzAq6hQqd5WbY2PT0850dDBmuLRybnkYCFD+yiwQh7VGn
Q/yIoMTdSmXk8mU20zKAzPt6xY1bN/FiZw+r64zfj5bVQMp9V600m4fN5tj0NJLLlJgSUZSl
8u+pUDy+4gW0GRvXbhqAvUGB0zCjV69eXF0FVLWicVHaHmXIAmWTMlG0NoAkvehA6Re5GS4O
ELYWjjodvC7V0hw4uZhj7HfZvuYpfjAxMRIO/3jzJvtVpJ8QGv9SqYxNT//qYhtgD7Gkf7h+
feTyZXVOmaWPFhZGLl9GRUrbsrBDFchmUW/QzGQC2SyxC+hdxDs/3rw5evUqoHeHJ188Tl1A
y+ouXNraAttARb/0zTecfYJ5Yzf6A198cdbvR5HAH8LhUeVeCG3GiPMykM2iHTuTobkuyt+t
R1x2zq1fGHRA+2JCP5mdRWfDx/f9cvlADNkvlcrF1dXRiQnsW+JHUgr+40n1/bVrNE2BHvzy
4UNkYIBU/GE8TsDIHmU+wDCxXRC5VUzvS998Q3H3q04HKVqanPicCKTcF42Ew9jGhFiQQcZV
AUgS0mqVyr+nH+3xFfqcOtek1gC4doazuH9cXaXCP8xztxUhStujDC/MzIjKRNHaAJL0ogOl
XxRnODdAY9PTWCln/f4/rq6SlmZrFgA27mbABli27AMaK+lUqJnJBLPZnpGEIgv8482bijue
BiM4Nd4tN/ydD+Pxi8OpOU2aNJ0GuYGTD79sNVbSydNRp3P4+PEH3twNKXW2ty/MzJysVTCO
qx30AGnS9Nug0wMnP6eFe+J01u+ncyEDGBXEj6dxRYm+9kSTpt8GvSiVnszOjk5MnBI4uU4l
adKkSZOm10inkjRp0qRJ0+uGgYXfIQLYCMqwRBgN+tE7oC4B+7hRq9Wan5+vVquGYZTL5fn5
+fn5+Var9VuStXjfPft7tVodrMuNRkP9om3bjuMMzLZlWVavatd+n+xJ5XIZt8+7fahQKJyU
/IeR7QnOjTc24efn58vl8pDThlbraawRGn1cfj4/P+9xuPF6oVBQTJ43QxByv2+xavANkGKV
yfcYCMRD+q84vHPU6fyvROKjhYXRIXZZpbS7u5tIJJLJ5G/JKliWFQwGI5GIODbVanWYe9gj
kcjGxoZiqViW9d5dpJpIJBT3emb7KaxSy/8dIfUgvvkvvpVpQ2NEo7+3t9dqtVZWVryw8Y4P
8XsWMQz85ukB6jqOEwwGf2OCbrfbbj7CqX73NxZ1nbj8Nb0700Y6RsFg0KNx0kN8gnTOOD4c
ixPIl7a2fPE4ztoFvvjCMIxXnU4zk+lWKr54HIeevrty5eLqKhJQT5eWXnU6/pmZJ7OzOEc3
OjFx6ZtvRsLhw2bzyZdfItfkPaqYn59HMGjbdiqVot9rtVqhUFhZWSFHu1arzc3NVavVYrGI
mDeZTCYSiWq1WigUFhcXYV3m5+fxO2d7CoVCrVYj/zSZTMJLCoVCtm0nk0nTNLmWOVbxoVgs
htAvEonAkxVZsiyrdUyst4twAUyis4VCAeGwojU35+7u3btYQrZtm6aZyWTQoGEYa2tr2WzW
NE0I1jCMaDSaTqcRqkcikXa73Wq1QqFQOp0OBoONRqNQKLRaLcgwEAigWe51fF18UhxTSDUS
iSSTSbERwzDy+TyGIxKJZDKZarWKQGptbS0QCCCtEQqFUqlUKBSCb5hKpUSWpD0Ch6L8WYLk
TdOE9JLJZCwWYydMLpfD0JCUpLNIKqV+B9FxHGI+n8/bto0/YygjkQg4icVisVjMsizHcWjC
FItFJDEgInjQ5XK5WCyCee6L6AUYRseDwaB62hDbm5ub0WgU3XEc5+uvv06lUtFolDUw0gnG
SSmVSuVyORqj8fHxarUai8XA8/z8vGmaU1NTig+xSywYDHa73c3NTbRPApdKhsueeRk7t4Uv
Ctlt6NkVIU5Ix3Esy2o0GlgLu7u77XabxA4dxSVUMAcwdW/fvr27u8v1VDG9par171d7/tEF
u9gwjOfb239cXf3k/v3Dx49/Zv6VBdSVIjYDvuLTBw8A3O3RMCC8TaVSrFXAOKEPJO5oNAqt
NDU1tbGxkUqlisWix/RctVqt1+uLi4sbGxuxWKxcLmM2UIgNUaLlbDZbLBbp01Ke0+l0o9Go
1WpSlrLZbDAYjMVi3CRIJBKxWCwYDLJBPdsaZqpHNrAOU6nUxsZGMBgsFouRSARiXFxcDIVC
+XzeNM2NjY3FxUXbtjGJMRHn5uYWFxdbrVa1WoUShBwSiQScR8dxxNelTyqklMlkpDyQmZ+b
m2s0Gru7u5zSTCaTGxsbpmnmmTOcUpakPXKTvyi9UCi0sbExNTUFW8KajXa7jQlDbEhnEXjY
2NiYm5ur1Wr4sd9BTKfTYP7u3bupVIo6Qr1bWVlJp9PQULdv36YJUy6Xy+VyNpsFS9C2jUaj
WCxiYrA6C0QMr6ys9DVtsCqpL/gDq6zZkeImmGVZaHNubg5timMEQ4vVMTU1pf4Q97rjONFo
FNMSE1UqGTdReBw7buGLQu75unRCVqtVDHq73S4WixAyTAtGUyrkVqu1uLi4srJSrValPXWb
3lLVesYwjLHpaZx74rCLQcAuBpiwFL3ZDbG5W6n4b9066/ePTkz4T6LYNhqN7u3tQdytVisW
i9Xr9WAwCCMci8Wi0ahHw5BIJLAMSC60z0ZiMk0TLUciEfq0SDC8eKvdbg/MEgiOALXmnQ3Q
+Pg4JmU0GiVTB6rX661WC+1jCRFj0WjUNM1gMAgvpl6vO45DXUCD0telT7qNnYKHWq0WiURC
oRAmLucNRaNRCDmZTLZaLeqX9x55FL5pmlCIiUTCNE0SteM4tVoNJhxs2LZt27Z0Fvl8vlar
VSgUoNESicRggxgMBn0+H2SCjrBT1DRNGmjTNOnrtVotGo3CF6Y0PeYkyVDcsJmbm0P3o9Eo
t+GsELJhGJOTkxAF7DcbY3EjKE4wiDoUCqFNdX2Exw+xQ4nuj4+PQ2NIJcO91dfYSRc+J2TF
61LlTtopGAyitVqthgkAse/t7WFKSKcNpqJbT92mt1S1njN6AVX+gUG6xr1j4maDYRgcHMrL
13GP1bjK3g2DZVmpVAo9R1jE5i4Qg3tsrVwuQ8twigPZGMdxHMdBXosiCbcpyEWjA7Mktuad
DenrXFOI/b18FFoAfw2FQq1WS/q69EkFY248IE3Us1OUKOu3Rx7J5/NxOgJcobViscg6y/i6
OIump6dN00QqDCH/MIMo7YjiAdgGLiJxHIfmJBQ096/oV6PREIdPIWQMfSQSqdVqwWAQMZ+X
aYnNAGID/9rtdhUy8fgh6VAqJMNRX2MnSl4UsvfXuc6y2gOaularwVC5WRRq0K2n4vSmD4mq
tffJZ9phftXpnJWhGxJiM4vlBFQ/wH4ZMnjFASgSicByVqtV2ORQKMTaPcdxuHnvppSRcYMN
TyQSeQFkCh5Zz/knkpSlgbs8MBtu84Yr8JDqcdK/UIuQofR1TD7uyX55wO+KNBQ1iz+EQiF8
13uPPBKrm7rdLk0kfDedTnNrUjqLkNWl/Y9cLodY6kQG0csoixV9xWKR9X44Fby5uYlplkql
6vU6V2TpNmSsu1YsFn0+HwICL0xCgZJignhFVT78h3pKRtTIXsZOmgOAn8oJebD1SwNECm1y
chJJadu22T0e7z0tFApu01uqWntXJeHmQsA4A+j170HAMaCuFLHZMAxfPP58exsAwh6viOpJ
sVgMCWgs0fHx8VarhalcrVbJ3FH0xLp4XNoaK2FyclJabjw+Pm7bNv7Jtu21tTWPVclSlrAY
pHoTG2WK1gZjg/M+HMcZHx83TTOXy+Gvm5ubbmcO8CR5kdDC0telT6qFI+UB20XYYV5bW+MY
QwIXe6SsUvDeI4X8OQsE8RYKBcdxJicnaaVFIpFSqQSrUygUlpeXHceRziLiPxQKYVUPP4h9
RdU4o2Acn4xpNBrj4+PUtXK5zMmh1Wph+5dVed6nDab37u5uz/QONw2wv23bNpLapmmqx6jn
h3q+LkqGe2aYsZMKebChx+u2be/u7qLXCJiw/dOzYtOtp27TW6paPWElkaLn4PoAqHvU6Vza
2noyO4ubrEfCYRQvXdrasjMZ/Dg6MQGz0basZ+vrn9y/7x1XnUs1FovFWCwG7Y9dMorxadMf
O04KOaIKgqodkApg3RCuZSq98BLWSFkaHx8vFoutVotzHzDeKJ3q2Zp3NtgIJhgMbm5uptPp
bDZbKBQQ2EKjuXkc2Ww2n8/Pz88j10k/cq9Ln1T7MlIeEomEbdvIV+BHNuoKhUK5XA7pps8/
/7xna27rFvJPJpOImkX9YppmrVYrFovBYBCbmVQBmclkcrkcTgMFg8FMJoOMrTiLUATFsoT/
DzOI3imRSHS7XdLdyWQSuYtUKlUoFIrFouhrJ5NJ8IZ0P3ZcvU8b7ExUq1VO0XifBmSWaIyk
2ZKeH6LXpfGEm2RY8jh20ogBS5UT8sDrd3l5mV4nde+27eylp9jt4Ka3QrUaf3vf6C9/+cv/
+B//42+afh/09ddf//M///PJtnnnzp16vc79+M///M9ff/21FvgAtLu7+1/+y3/5LX3oHaRm
s/mf/tN/6na7g73uZXqzqvU9w0qqVqs+n8+L2dSkyS1f1G63B0hSa1KsSu95pPfiQ++skE/v
IDqnWt8n2G2cWOm596JJkzqPMQwAiSZu+yefzyMH9dv40LvpyiwvL5umeXr1C6Jq1bDbmjRp
0qTpNdKw25o0adKk6Y0YBgJGPnEU2TeMTOud1EC7wBLvKS438g4ZrQDxfpPYzu8miaPAymRI
fHIao37beQMw0X1BjrMysSxrfn7+raNYa/qNGIZsNquoHdTUr5XteUSAFJ/CwADU6LeHXDsM
kUwajcbm5qb6/K2XMRqynVMyh31dX0EysW270WgAuElPFW0YNL1b5B1PWINsDxOJnsgYvYND
MDBLdNRcT4/fG50zeqHRAlgY7gNOpuDkNICdI5EIi1VLgK4EjCydbSyCMQEps7CxqMoizF5C
ogaUtHEMFWswGMgikG+32/UC+cuVOUmxlPsC2mUXJDCT2QekAM70isgbB9mtGKyeIN6EtAwk
SDcU6LW1NQXyM47Oc69LOyV9TJQtJ8ZWqwWAZTVUtXTWgXODAR6PRCLSUWDTJjjvxgJNEzKE
dEUAvRLalg5AYYAow4l2cAaefRIdJH5IAiJMdF/rTgE5vre3R7NiZWVFMfcUMmHPA0oHEb+M
j4/jd3ShJyi3pnc3YvCCRus4TiwWQ3QJNHACdjZksL3qT+ZyOSAYAwGccIoINlaE3AJmL0Bo
6cfFxUU1kC8xz0H+KmCEDSUit+EBaJezqYZhrKyszM3NkVSlAM7EqsgbiyesHqyeIN70FRxx
BI4pB6RDY+GG/CxFEsbvGD7HcUqlkvQrUtlyYoQl6AlV7TbrOOBxt1EQkycENA1DlU6nwQ/Q
INgxKhaLk5OTmGlQ/TRGwFo3jgGrxSeNY0CClZWVZDIJvHFDBhOtXnfeIcfZWSEOkzqhBO9n
cXGRLRJ1WyC4E4LtgkdQbk3vomHwgkZrmiZmBtQf4c1i+qphe0Ub02g0gCsLUIFWq0VoPFL/
BThWBEJLPwKDoSeQrwj5q4ARNpSI3F6Adrme4kwK1V+7ATjjlZ68eRksljgQbxpNeIXlcjmR
SEitmgL52Q1JGEgssO7pdFr6Fals6/U6yQcwG4YH2HO3WccBj0tHQU1gAO55Op2mC0zoX6HT
MdNCoZDbdoL0SZYfiAVyEGGi1etuYMhxbpgGUBluC4S4pS70i5Wt6R1KJUkxWqlyA1hDHF6r
ONUUsL0cYZZwiLssfqfbQjVeh7D2AuTL/p9Lm7rBCFNORoHIzTalQDOGvqAf8Qf8KAVw9sKb
F+hgBcNEuBaK4KRSqRTHvBrYWUQSBjwL5TqQC5J+RZQtUiXcBOsJVe026zhupaOgJuAtI1eJ
/CGXEUXoYxxDzikwtMUnCXSTe1KKLapYd4NBjkuHaQCtIV0gYhf6xcrW9A4ZBilGKztdetYz
qGF7xVWHeB/LSW0SRL3p9qQUyFcau/SEEe6JyM02pUAzxjrB7X3G69jCIoAzcA178uYFOtgL
RSIRcIU8fqlU8u48uiEJJ5NJ4NfncjlYAvErpmmKsg2FQmwxpUe8Yo+zTjoKXpxi9jJIunkJ
cwypc5ygVkwP6ZNk9oYcwYEhx8Vh6ndv2fsCMYbGytb01lJJXtBoFYQ9NxG2VzGhI5EIPA4C
Ukbs6UbVahXuCeB5pc+4Afm6PamAEe6JyM02pUAzRk/BPG1LugE4q3kjPOGeg6UG8WYjQrAd
iUR8Pp/0omZFr0UkYVTit1ot0zRpNMWvSGWLBiEfj3jF3meddBSkRC4FK1j0hZUPfk8kEoCA
Jc+AxojakT5J/KDUQn32RT0K3iHHaVaIwzRA7bL3BWIMBMqt6Z2IGLyg0SooGAxKYXsVr7AI
xiiNUEcMpmniYSgCt7tlRCBfqYrsidUsxVKWcigF2uV6alkW9VTsPgE4q3ljIbvVg6UG8Wb7
SOmsSCQyNTXVV7QhIgnDA0WnsHXE4RXjK+Pj46JsqaylUCh4xCvua9ZJR0EayxLQdCKRICEn
EgnWHcFGF3I48Jrr9To7RtiIRjuRSER8MpVK5fN54CqjX30dMvA4jaWzAlVJ7DCZpmlZFqoh
PH5aukAUfHJY2f1+TtNboXcaKwnld1LofE2/VYJVO70bCzSJEcDu7q70VvoTIVRe6Q2G9yyV
pEWg6e0SYCrgdVLqSYvljVG9Xlfncoek3zNW9nucStIi0PR2KRaL1et1pFwoDaXF8sZo+FoG
N/o9Y2W/76RhtzVp0qRJ02ukU0maNGnSpEkbBk2aNGnSpA2DJk2aNGnShkGTJk2aNGnDoEmT
Jk2atGHQpEmTJk3aMGjSpEmTJm0YNGnSpEmTNgyaNGnSpEkbBk2aNGnSpA2DJk2aNGnShkGT
Jk2aNGnDoEmTJk2atGHQpEmTJk3aMGjSpEmTpt8AvbWLehzH6Xa7Pp+Pbjyu1Wq4d5d9DDc8
s49pchOmFpSmt0jS9euFWq3WAG+9U+uOpfe0L3LDUC6XW60W3SderVZrtRqugW00GnQxOiib
zUYiEcuyotGoeDeTZVmNRoP+uri4WC6Xg8Eghh93+ZbL5Wq1igdisRh+LJVKiUSCxFqtVnHR
IygUCk1PT0uFXi6XcWU8USwWS6VSxGGhUKDPgXCrcKFQIJbEZxYXF/f29ur1uvo6XFxMvbi4
KOWN/QSEWSgU6Cb0YrGIPgaDwVQqFYlE0NrGxoZhGLjnXcEzvl4ul1mBRyIRVowcVavVYrHo
OI5hGIlEArd3cUPJ8iD+Vew7+8vKyoppmiyTjuNYloWbO+kyZ5pgYgu44rtcLqslz44XmmUn
rSjtarVaKBTYFiKRSDabZd9aW1uDIwJKp9O4yB4PSBcC2p+fn8cEoD+wQ89Kg1sd1F/2RbWE
sfpwF7r0DtR8Pl+r1dwmFbdeaESoQW6CiV1zHAfX7RFNT09Ho1F2/arHwsvyofHCMNFjblOR
WyzBYHBxcVHUUVzvuL9yDFAXSICcJHO5XLvdZt/qdrvJZLKvG+u4Id7Y2GDnYSwWi0ajEB07
6GrVwc1k6bQR+85agd4RQyQSYUdifn4+EAioX8FsE+c0TZHd3d25uTlYi7t374ZCIW6KNxqN
YrGYyWTwu+M4xWKxUChINUUikUD33FZXKpVKpVIKBcctkr5ob28P/+/33Wq1ure3Nzc3FwqF
yuVyLpe7ffs29wyrZdwacRxnbm4OgYLjONCY0vsaW61WoVCAJoLkfT4fyza7uujP4mJmlx/J
s1arlctlMV4pFAqmaW5sbDQajVwuJ441FgN5Fd4FiLnu8eFYLIblqlCp1FPHcZaXl7mbkLEQ
bNu2LGtlZQWztN/ZQs6WVEu6EclHuqBYKhaLrVYL5rlarYryxOqD6DAigUAgGo167wJ85M8/
/xx/vXv3LvyMvsiyLFal3r17F38IBALZbBbrPZ1Oj4+Pb25ulsvlyclJjyIi8Sp8R/x5+DtN
Y7EY13fWl/VOMH7iPCwWiz6fbwDVQc4QZ577jhjq9Tpn+qTUaDSCweCQsVKr1YpGo2gkGAxG
IpF6vc4t1Far5fP56EfTNEOhkHod9pydeB3/pwUzzOSwbbtYLLbb7WQyWa1W6/V6KpXihGPb
dqvVktqMWq0Wi8Vwv3EikajVarVazbumG4AwfNCP+APnVriFBV4aL5fLoqPkOE6tVsM0jUQi
sVisWq2q+1goFMhVHKCDoufI9aXVatm2HYlE6EnxQ7u7u7FYrFgsIihhH7Bt23Ecyn60Wi3u
i6zudptdYv7hpMi27VgsBvMci8VojhFXtm1Ho1H0KBKJRKPRfD6fz+f7/VBPJaAei0wm0+12
HcehRR2JREzThB6s1+vBYBDmKhaL2bbd0zCoQ1vyHcXJ5r0LXHeQ5AgEAmy/IpHICd5Y3mg0
hlEdtm1juiJPIHUjxFzLPwxDrVZrt9uRSKRYLNJUhlA4J7parfZ7rzdmJLtCTNNEYoGGU2wT
ITwiQeiXnp+G/rJtWzplkXIJhULFYjGbzWL2cNOCE5PC0tIt59FoFPJJJBLlcjmfz9u2jRQE
HgNXtVqtL6esp1eIXkDVlstlNrTHj26OCeIJmAQpVxSi9hVCWZaFUIAWD0YcCpRGJBgMskMv
JTaVNKTnJXqOhUIhFArt7u5SHAyvirNwjUYjm82applKpdgHHMcpl8uRSKRUKqXTaUpZsCpD
GuSxQ2YYRrvdbrVajuOc+IZQMBisVqvRaBQRQ6PR4NwpdB+2odFo1Go1TFfWnon6YgB3QT0W
YK9arYZCIdM0aYFT+pHmjGmaUHx9uZ5iVsO27UKhgOkXCoVSqVRPDU5d4FJJPW3zidgG+JTR
aHSAwBQCh3iLxWIqlaKEoSJHglTS3w0DcnlI7GxublJugRtXaDfbtmkfwiNhj4FT+o1GY3Nz
MxQKQY+L6sk0zbm5uWq1ioEMBoPpdFotbjh3WBWijKAR0um0ZVmWZaXTac5+IN3ExfhuWiwa
jYpf4bwSNJXJZKA32QCIGoGWQTyISeDFl6RMHbrM7fiZpgl1EIlEuD4iHYmknNSNqtVqe3t7
UG3INQUCAYh9fn5enBIQOOYfJobU4r4xUniprVYrn88j7QafgxKVXKrNcRxYBdoPwGNoAbNo
bW2tUCh4N/aig4X/e7S7oq+qMKv5fH55eRl9hyli1VkkEpmammIjZrEXLLfip+HUU/IHU26A
kdrd3b19+za96zjO119/Lc00RiKRVCrVUyOLaUMKQDc2NjBec3Nz0IBQeqLN9kjYdpZ6YKZp
nsh2erFYnJqaopnJDkRP1YHUWTKZnJycvHv3rmVZ/SaUzpXL5Ww2i8X/+eef3717VyqgRqOR
z+cplz0kQQWjP/Q5Co7YTWAyBgiL8ItoIaAl4baLjnC1Wg0EAnDxstmsZVluWfiTolqtBquA
3mWz2Vwux40NEpRw9oPBYCaTMU2TMwyKvITjOGrvW2pH2TXTc+r3zDLl8/lWq5VMJt0WFQwM
m3iR5kxPJJWk7hq2gj7//HPTNKH1isUiVAOtpd3d3ampKdKJGC+KGGAkYP8+//xzGAm3EFmR
SqpWq91uN5FI7O7uTk5OqjUIu4vjkdLpNKa6G7nlVTySaZqLi4tcQU6r1eIcEXUqCR49cnqs
E4bfoVtpHvZ0wNm9VvooJgMCUEW4owiLxS5w/hCygjSl2T+TqsQuYL8CL5fL7XabOEdgSlNL
rToQflG/MFfd0gOuqSR2BwyfFz1l2B+yHydCu7u74q4GEnY9sw0cG47j3L17FzU2Pp8Pu+3s
M9w6IQVN0Q+bP6G5Rel49USULubFxUV2GCKRiHS7Ur1E1RoBTjoFVdw/iZyLRTVihj0ajdq2
TfMP7qSip5xgLcsaHx9ne2SaJqrCUNUDL+REUkmhUIjSBT0DfFSpsYyR5MmcuI0FPcAanmAw
CKOCX2ikpEPGBtlIaCB7Y9t2Pp9HdOI9MYudc+8b1x6tS18NGi4FOeTvk6xQWyg2DnVGBXKY
KplMBsZjfHy8UCjUarXx8fFqtTo9PT0Y8+yET6VShUIBehBh3wB+BkkSs6VWqyFcBtvYZutp
7MUIjCtzgI+inhgK1QHLzfJMDhD7O3IkFN9zqaBzUs0YjUbpOfjg2AHvKwneM7jmfFJE8Ujs
2rbttvEiHf5IJALvjGpPRQXUarVKpRKbrIzFYslk0jTNZDIpde7cagxY+SrKVd1WBfuAumxA
UU7nFhZgc1VqANjilkQiQfOeXT9uovASYeC7iUSCnWTJZNKyLNhat9iCC5M9xgduik8tdm6q
Y+aQGFEPw8asSHyzg4t1S7M3FAqx/RKnGZUFw8tLpVLoI4JXpIDVOVI2NUeDBWun8GdpGrCb
YZyBkf7iZf1i95j9hU0uedwQmpubs217c3OTUy9YktgSR72mlwoIt6JEEgIbIHrcq+B2s7lf
2u026nch6kgkUqvVTNPsyzBQCEvJhmq12tML91JxhNpOmgamabIBcY9UEuZBo9FgZYpCBcix
38DTYzJLWghBFtK2be8ZWG681RUIqOSjlDG7LMWq5yGDbuliULtmPZ07Thdgi0kRBPRL4mLw
mM3I5XJTU1O2bZfLZS5oUCzIno2fVGUh6fRGo8GqIUx1GpRCodDtdmmSOI6Ty+VYPwN+Ertu
y+UyCljxSj6fZztF0wwuCNdZL4uFXFeUPJCZcSMEJclkksSOohQufe9WGUyOpJq4owxsel2M
3ljDH4vFkGDk1Bw7JeC19Fvn0lMXiW6Wl54qNnjEYk7FHiHquXsaJ+n+5QBxIaZuLBajL2LX
E7NU3AVkhyCVSr21k89IRHCxEpeAFt2E38apwhMk1HRxzkXPgyYnS3BMQqFQIpHAcTZp5e7A
jZ/qbpA09Ol2u+/UAXJEIbZtZ7PZYrG4ubmp2NfxrjS5iOFE1q9o/KQqkn2R087v2tF9MWKg
v7bb7enpaU5ruXn6KBR+F3rkxeiegztWLBbZDkej0Z45uCEpEAiIQQPVq2FyiMHpMLvfqVSq
XC6jYINNJXE+hWhL+93945a06HGwa1K6wcXumIlxPVsdhPJEUbaDnWpReEnSTTzj+BA7JaYQ
H5TL5bW1tX4rPaQ6GruaJzXrEolEt9u1LIsSQdxUR9UWuxa4SUIHmNlUEpsOTqfTpVKJFWBP
H79nbF2v12OxGPhEVRUOsrFVPaxiwuYTTZtQKDQ1NcWJsa+zhP2u355O8SlpFdG8cQk3cTXR
xuoAEUMgECiVSh6F0Gg0+i3p7OkzKdYp9mx2d3fpGWyaeozD/s3f/vY37Xdr0qRJ0wkSi30y
GKTC2yVtGDRp0qRJ02ukYbc1adKkSdNwhmEAwCw1tY7pRFrjjs73dZL+fSQgW7x3bDuOc+IT
SZN3elEqHTab7wgzR53Oqbb/cn//5f7+722Ijzqdw2aT+0/xGDcK54xe+KssuVWIS9Fce9bg
o9qaPeHitjfidjjLeH0jF8UbtLXF/VVk1Xi99hkFXnTAFZy4iULE+kYdDouowW4N0R6Xm1jY
36lIma1W5gApsQ+PU2PoY19IxXRGDwd/SJhuONXgXw0LKlbHu2GzQ3SiVFHcicpr2haWDgFX
H0LQTIlEgusvxwMnf+omDj1hJrghsHIHGyETjj11NT1HT2ZnX5RKhmGMhMN/XF31xeOHzeYP
169/9ugRHmhb1rP1dfz544WFQDZrGMYP16/j4adLSyOXLweOCw2+u3Llk/v3R8Jh+sNRp/Pj
zZvsFz9eWBibnn62vh744osLMzMK3qgR/JU+ahjGYbP55MsvoW1HJyYuffPNSDj8fGfnRakU
zuUMw2hmMt1KhZryxePhXK5bqfy0tPTJ/fvch368ebMnM4ZhdCuVZibD/hLO5XzxeDOTGZue
xuvNTObw8WN64MKtW4FstrO9bRjG6Orq06Wl5zs7nDQC2SwrRk7+UlFwxDY7Eg5/cv8+nm/f
uUPNPt/Z+Xl9HcpXOo49GWPFSwKRypOkKv6I0cefD5vN9p07vzDD9GE8HvjiC3Szd7kqB7/e
7XbZk9kDb6rgJBGLVwMQYOB/cQ9z0N8KDom9QCDAqhJ2L4hsDFe6g3OYKysrrVYLh+YUy5s7
4iC1W8Qz9CldITBYjQodKUJ/6/U6YEVYefaFVExAOsQqezCbNdIiGt1gwRyVcKAj9DkA+huG
AUSWubk5tvxf0SY7KwZAPEbJP90v4obr7uaIDEnP1tcPHz/+9MGDs37/850dTuth5bctC+qv
W6k8mZ0dCYfHeh0DZunVwYFhGOHj8qFmOn10cDA85z8tLZ3x+6E9m5nMky+//NO9e5zKpj+3
LYtV1hy1LevVwUH7zp0P43E3zUvWhdXX3125MnL5MvfM4ePHl7755qzfbxhG+84d7rsXV1cv
rq5KVf8whGYRh3H6nVTw06Wli6urF2ZmMI6jExMwsafKmNrcPt/ePjo4+NO9exDXUafz9C9/
eb69/fHCgsGefHYDzTBNE9jrtm2Tx8pi5Eo148meSxJ9PdZNA4ftdhsoNEDlC4VC7GETL+Wb
8M0B8T01NcXaPy8sicRFDDg6pNCw3CjgdVJD1WqVdVd9Ph+QKTEogyEVnziJBpIiNgwK7AHC
RNM00TsYYNu2u90uxpSCziGnEE6luhl4wBeDh0wms7y8fFLQmB5THP5bt7AsL8zMvCiVLszM
jF69+sP16/TA2I0b0CC+eHzsxo0ns7PG7Gy/H1IrXDfeDMN4+fCh9N1upUKO6h9XV3+4fv27
K1fApPjwL5WKaMwOm82XDx9Cjf7p3r0XpVIznb5w6xanMRXRw0g4LOXtrN+v7i98ZAQ0ZIyh
DVmrM9iAjk5MSBN3FNP44nH/zMyLUknsZk/GupUKx5i6p686HS595H0mnKNI3A1/FasUAT7B
TFarVe4EE3lSbCpJ8WGceufAUnA6dLD1j5O3gPDN5XI474cAApEN3F70S4QTAAwyKQWgiqIk
38v+Bw7Hi7+zWQWKWtyUnXjBGYv5XK1WCYYFzAOYlyQwDFKxNNHHpZK8vMU51KKdQPE75Izz
7ad6YgYQ08CXJhNFgJpAmyehAd5g+I+K1fTSUyB/CIc729tjN24gYuhWKmz6BVmatmWNTU8j
Ynjx7beXtrbGpqfJciDsoFyTGw2wndC2LF88/mx93RePw3SRtvrs0SNfPP7T0hLCgp+WlkYn
Jv507x5yHaKu/HV//9LWlhgtHXU6pC4D2ezY9PSLUunZ+vrF1VWpen3N293ZuXDr1gA7Fsif
jE5MPFtfD+VycM+fLi1xj4mpJC9C6+zshJhQqS/ywhgyclwqydUbuHz5+fb28+1tt1TShVu3
2nfusBmnD+Nxkqqnk8/lcrnb7bKZZaR9pOdrPGYVsALZK5AIjNA0TekRGBZBkDubats2C99W
q9WAO+3z+T7//HOfz0eWA4DV+XyeQ24YkiAc5HbEeyzYqGWYnAxhd+PkFxsxiMm3vpCKWQM5
Pz8P0y7F2aYH+oVdQ9850B4AIOMroVAIGIi4bk96809PY8Ye9ysUCgDAQG6QpMca4CFDIlEI
3o9DXlxdfTI7+/21a3DlkDJCPoEUQSCbZZ1H0fWmhLVUf505fx4ZpH841OfP99y0fDI7i3RQ
27LsTAZbCJTTR5Tw5Msv8TnsMbi19nRpKZDNkmkhtX72/Pmz58//+vDh04cPOVvY2d4eWVjg
XuEc8JcPH1786iupNnzy5ZfsHgMXZ/y0tDR69eqlra1mJsN2bXhqW9YHExNk0jCI8PexqfM8
HkcqqbOzw1nKk2XsqNN5dXDwx9VVhZeA6OSDq1fZdNwZvx+/fxiP904lQSMjJIejR+E5q5o5
IDY3TwoLCReVuHVMikZH+pRNJZfLZfhikUgEIPsEw0IA5Wit0WjQVRM4AVir1djLKxYXF3GD
EPrYbrdt20YyR1RPnDdNokMUxSoLboNUbYrYURAT2YFAgBQfbdSTausXqVghfNp8Vj/QbyrJ
OL6ohy6oEfM8gAiG2KPRaL95JISGkDmuDwHOdigUymQyBMHPipQgxmBr1Y4OOu5Wj+AFc5f7
8dLWliF4069xmM0GhjjEftbv/+T+fWgKVjV8GI//wUXvtC2LNgkC2ezh48fP1tc5RTYSDnOb
ClJqZjLs3jir/V/74p07Y9PTrIZSWAXk6CkzzlE4lxM7Sy0/39kZuXwZfQnncs1MhlLqHPWb
Snq5v/9sfZ2VCTafSVwXV1fbd+4gAvh4YYHLI3lkzGMqqbOzwwUK/Kz75ptfX7fH4gCdM3rh
r5Jfz56Ap+sN3PwmQwlQBVAdKYKjNJvE3bwhNg5oWdgMgIXh4kBSr9hyQJSAVBgpLMr24NJt
1PPs7u7id2kqSVE9NZjzaLiAl7EfIued9pzZqzr7RSo+DaJpwKG3sn0sFArcfXNsr1mI4CGJ
AyOTwhfGYrG1tTVcCpLL5Ya8l3GAEEq6H9Bz+9GtEMWNnszOctuwrw4OPrh6VXozBqePLro4
niJdmJmhrU6ULZ3x+y/JzN7oxASyZODq1cHBy/39V52OYRj+W7cUeSTUaIVzOcUzolp8dXAw
duPG383w61ZE7CPJH6GbohiJs1XqDBgrHImm9sAYtfB8Z6d9545iDpAzcdTpdCsVlBuMMtGM
YRijq6vPd3ZE8/DB1av4ilcQPRThABhHClgkbsOqN2bhx0lzVoOlp6DNsR8uFqgAOYQA2aX1
VMlkMpfLAUzJCwacm+fIedDcFQXqTAgHpcv9Arg6wvXFnay0A98vUjG8e6hvaWwkgrEMvx+Q
SqXIJxh4S4mIZU8aXkhBsGk4UBEAOXjB6PfIkvdyVazzzvY2FdqPTkyMTU+zXjZbJyr+4mWP
4dLW1qvXi5GavXoqflRkm6uepF8Om81mOj02PS11xlkVfMbvhzL6R47IZf8WVuFFqfSne/fU
OxD+mRku4UaeOxmtZ+vr7HbIhZmZj5TJK/XewJPZ2Y8WFtTltl4qjk6WsbZlPd/eHr16FclD
1OyyGSpRjIePH//68KEBwyDCMLE5hGQyyeqXVqvV7XZZT5+9E0bMRylSAbg+l7e9MtBaLm8j
Mkk7ez6fj7spgYXh6wl5bZrmkNhzXm5QURsSURezOSVspYo5eny0L6Ri7soO+joFPdLW3K6f
pUpc9hd21AD9xu4JsSk4fI6NJLDP1Gq13NBVRbxuabmqAgRbHfyJtLm5yV50ge4obnPymIJ4
urT08cICZSFQ8M4V54iVrORRevHopSXtZ8+fP+p0vr92DfWyPRsRXVQxswGeUcvvxSKKcQx0
+otSqW1ZXLbKY1bt5/X1X17fw+c2G7BhS71GcPPz+vrF1dUfrl/nNurZfX6qFWYN3kg4/OmD
B4ONPiclN8YCX3zBsiEmuy7MzHDT4KjTaVtW6PXQ6snsLJuh6lYqYsbpw+NZd65nuoO7aJPb
Fma9fi6Hrt5lhQ0QtaToavWl71gz9j6ereX2e7mr6oPBYL1ep8vLsBHyxsor+82DcePC8iny
rIBrHuCAwmmQW47rDbBHu76itvJIVN1PdOb8+W6lwhYd9UtckYy0KknlID9+/LHgDn8wMQF7
OTZELvTCrVvc62d6bbl7zNH9ePOmOgw6DfKSXeStvt8/Eg5jOCDhlw8fvnz4kJ1Fh48fXxAS
d7Qf0zuV5F0p9xUxIOcjGg8669T3NBXuKDdO/2YCrgyGnHHWvPWF9KuOGACnTLeiBgIB73mq
t0vBYPCt3KVx4iDYXshjuSrC+Yurq53tbUoHjU5MBLJZLofjFjF41Syv1+qQ9jzqdD50TxaJ
H+U8U7eIwTtXYhIMZ5W7lYr3vQ2xWbFMc+TyZbJhf1xdbd+5g2IwNmPTs2WgR/TVR4WbL4p0
YMbcXIHn29tPl5ZQvzt69Sp33g2CEqUHQZ06uiqHZjHM3QaaNGnSpOkNkIbd1qRJkyZNr5GG
3dakSZMmTYMaBm5nqa+NptMjQHa/rX3mdxk+Gie2OHrrXP3ecNHfynJg/9qXhKVzRgOkv3lS
AGW/GTongtkSsbUQqLFlIVvZv4IUiNYcSDKR26YcbqzFEVlCYOXax6EKeiUQCCSTSXWJDiFR
qzdCi8UinZUDFDNeFDdIpPDRbg8T/yKKOKFlKKpdpc0qqubZ6k9Qt9tNJpOswMWTE8Sk4ziW
Zdm2TUOAgymtVkt6PMXtalyuVq1UKoVCIWKY/atYl4zTJJZlKWDDWRlGIhEpAjw9wx098Y7y
LfKG+jHuYe/A42yD7Al2g8GbUoOci9OjUChQVQJEx6Kye2FPWkzBHUIker6zI6IMUa2qFCV7
5PJlrpz/sNn8aWmJQKJ88fgfV1fZM2VSvFI3KFaP2NTcKQ03VG0WDfvCzAzLCYuLfvj4sfet
cu5Ag8gezrUQ4tNZv99/6xZ3SIKDW+eAx0XAc/SRYHpFgYg/nuPAbDli8dxfHRygTm7k8mUW
iMMLorVYdW64X0eO9YDlAaALUfcBJC6dThNKB1aa+tzs3t4e/q+o5CmXy3t7e/hioVC4e/eu
ooII7hiOzvZlkMXCJLcjAsMQd/y4L+gkKIiNjY1yuQxcLPXz6rICukyi2+1S5Zg4WCI6k5tY
CLeDM2x9kXeUb6qZdruqYQBiO1utVvs6FidSoVAIhUJokEWg6pcl7sihOmJQw7qJBxo4Fxjq
xRePo3gfyM8/3rz553KZsKDF07k4DOh2oKxfCFI1ERRVt1L5hcGUPSU66nR+Xl9nzx+83N+3
MxkgLbKXcxiGgT9z5bPeAc97RAyiCWJt4Fm/P5zPHz5+/Hxn56jT+UM4PDY9/cHEBHuQcshD
YSLZtk2qNhaL4dTVkMWOtm0Xi8V2u51MJqvVar1edzvbXK/XY7EYgZguLy9znqnjOPV6fW9v
r9VqZTIZ0zSxJiORyPj4+JBHeXuSm2M+TMbJLecD85lIJHZ3d72koarVaqPRgN9t23Y+nyfj
l8lkgETSarUAZifqoMGGFeBLCDGlwZ8bCNgAKN9Irdi2HQgE3FDZ1WhRp0d0Bt4wjMnJyd3d
XenIqtnDAHHr4vQOyrz49tuRcJgAIc76/Ze2tn68efPFt99C75/1+0Vn/Kk7pKjhDYL01cHB
aV8bp1D9+L/i+Mgrhjf2z25H/MQDffT7wMdBznnpyZPZ2UA2e8bvf9XpAMGKAgjUHasRrU+D
otFou93m4Juk363Vavl8HkfzSNOVy2XkENLpdL/rFnZlfHycEBRwrLdarbbb7dM+VSCmkhQP
l8tl9viVeLBcoVhZHG+fz4fEVM8TAPQJUSvl8/lIJBKNRunQO9q/e/duIBCAe8Ed41DnBhuN
RrVaDYVCxWIxlUqxkIhuiSyPIOoKrzwSiRSLRbo5SmywJ/B4v3sG4hBLYwtc50c3W3AYl8Ow
d+J7DN9ducKpby8ZC1atE4rGABEDrrEc8gwdl7/i8l2Ks98Id7ouKvus3//RwkIzkyGeD5vN
i6urZEXYu/PEtBsnByngeX+G4YzfTyb0qNM5w1izl/v7gP/9u5EvlX6pVD6Mx8+cPx/O58+c
P98XorUXfCGsPcJMrdVqHCQcIYwCjI8WBtRcKBRitQkHpkY5FjcOAUKHmw8KhYLP5yPEVixU
QgXnsrH4cRi94wXR2nvEMDc3J1oCVqFgZzIYDCI4kCpWVqH03MYECi9ZCFYxcQfdu90uwUvQ
hZqUrmE3TtxSSbhaNZlMTk5O3r1717KsfiPXvlC+MbEhB6Q3ud2a04gY1BcXcpRKpfL5PMRl
27bbElOw12q13G4tFMOIYfI2lLseu3Hj5/X1J7OzF7/6ilJJh80mMO9gAw6bTRFL1e0rXpDm
cCFSZ2eHxQNHktwLZB5H/cLf4uvPd3bY/drvrlwhW4IjhzipDrvIHkLk7s6jWzFEg/rT0lIg
m30yO9t1iSfEzQ+WjXPsDlKbmTRty8JddB/G453t7WYm84dw+K/NJoYTqSQI0faAaC2dVQS/
LK7YVCqVy+XgtGazWfZ1YDX3XPPD5OXpftBQKITb67x/HXckDPZptUmgfZqeW+jValXNJNDr
SqUSDk5L7zEFjjck2e12Q6GQwjCwxQWs6Zqfn0cEGQwGQ6HQ5uZmKBSCDCneMk2zX4khxKFo
AGDd7FU8XlJJRj8o39idwgV/dJeDaBj6Alil8IhqK0jFYxdd8a4Yl+NeKYxRKpWCSFkoMzV7
7MWr0hklQhKoEUNJ17DPB774gnOQ/3Tv3k9LS3Tcd2x6WjQD3UrlzOu/nD1/nvO42Xss2NCE
/frF1dWX+/tty/pzuQwVRwl6N5NAGIW4KoMa/OT+/V8qFXVSC/rztXSfZeH3H65fx7VubHjB
XljNnlQH4iHOJIt351F6jW4PPep07Exm9OpV1mj1BBLnopxz7Oiin1xSD9jr6NIHV69+GI8j
Q0d2zAuitdvyZi8H5ea9YtWlUilc/iWqTjEOGAAlP5lMcjqClDKMFjIYrPlBsAKeT6MqVOwF
qzi4XnB2sVarsYVA0MWoOJqbmwsGg1NTU/l8HlqPdSRR0FIul93yEqJ8oETK5bIo1XQ6DThY
WF8YHlymRBk/sXdSz9c0TbZ9FqybAwdU48l7R/nmQkwx4hRhBNX5Hw5JHjivipyhF6rX68jR
sfnDQCCA7ZOe7C0uLkpdCs66uGlhzmZcXF0Vq1rE+kvcUOTWzpnz5y/MzEBdvvj22w8mJnCN
hHjbsxdAIWzkIjr5aGHhx5s3z/r9Cn+fxSj84fp1TtH3tItixomQAS99882PN2+GX7d2BIIL
uGzaMoGZBNwTd3ceFVYRbwBh/GBiYuAkktc9Bgxn27LAGYdha3hDtHabi+oHlpeXs9ks1BxX
VyeidsOLFD/N4a16KVeForcsa2VlhTxf9i32thny/jjFzeV8OEvD5Y4hw2Fkxa3kUChkWRb2
xpFxZtd2q9Vqt9sUisGiI1PPaq5arYbU1kndvkk+KSmpbrcLIyHN+Bm9irWAQ066zDRNpDRP
aYPHzcAYAoyg240UfVFf5arIgnKeFvlPHtkTQ21stqu1sFveZvjb7dnNZ2ylqnUxW2Aq+sKd
7W3cIYqWL33zzZMvv/T3o9xF8liuetTpdLa3L21tIS4BRlbLsoKMWTrr95/1+4G8TW73k+1t
FsCcvTsPewzcV9p37vhnZtRIf2zogxtVRStyTgwxWMmSITpz/jw78IBcZ5OhiukreivcX6Wa
GnVy8HbZ++Noxp8qqiVUP7ITlLdlmRQrvmlPT1qby/ZamjtmNSDdUy2ma7w7ku12G4l+LriR
xkmisjNN06M3LT2kwpo9Nu/x+eefs2LkXhS3oBR5dmxuxWIx4hOaFAZbDdWO+8bZzqpRvhWR
xACzyzuSfF9Uq9WKxSJnG/rCkcR+vrjVcVLLirUoIsY192Tgiy/YWtVXBwcvSiX2F/GuAhGH
nK1K4v5pdGJCUX4q2hika+ivfW1IIGkmJuK4DYDDZhN3TlC/sM1w4dYtfEt9dx4u7FNzIjmf
sLXFsvHjzZuBbPacd3vOjmJfxV49MZmlaz6fz6fTaVTLoIB1b29vfHycLj0WI9yTKhWF1clm
s6hwRSDCncyKxWKTk5NsDvoEM0gncheYcXyQFRIDez6f78QLat0MoYIl45TJC1S7oj7iXWBv
MOKu6+iXWq1WLBbj3IhTgijuqcLo8iKQWIk0MGC4F/J418XJErIyHWZrGgATHmHDhydCkD3n
nV3u1icxzXdS5DjO119/nUwmkV7AjiVKR+7evYsQGBkS0e2S3i43QPyOo3PZbHZ5eRnu2/j4
OKWhgsGgGDGc0lJXeOJq7zIQCLBZe2LyLcJ0S1niPFzp4VuuyJLNv+3u7pJMkDE71YGQsnd6
mMHey1WN44pVMfnmfVFgYoujNsxZJTEnwV0v4UbcbZTvLPVVrtozsAjn88+3t0nZfhiPh/P5
UzWBXICFXQ2NrqpJkyZNml4PBrQINGnSpEmTNgyaNGnSpMmVzr0vjB51OixA09/N2vnzbyz7
9jvpC0oM3kHBSitYhsFHA0mPxb3j5DhOt9vlauROcGeFk4m0WOBELmp1O+L6jkhY/P0EazdQ
dfkuXNguNwzc1tDF1VUcyfv14UPA6hGkH8GbiHVm4Vzu5f4+W89LxV6AJwQcLmpmw7kcB9j7
yf37L0qlw8ePP7h6lUPNJXoyO8shBb46OBi7cQNfZGvLsPMDKN32nTssPi1LbAEycGvR5TN+
P/HAYdj+Y364I730lKdhGJ2dHfG2VeP1Oo2e8LxuWMEicdIenZhAxRsHPoxq9H88dvXqxwsL
bu0/mZ1FvQTKCi/MzLAMc6V+OO4kVrWLv7h16qjTaQpnKV4dHPzp3r2RcFhEeMYcYIdYPNkL
yJBSqUQAJyJQK1sizKIIG8fYqG6o2qzK5ppVnE5g95lRUgwwV+B2EJY42DBNM5lMRiIRAG7T
2XWqDicgcbdCZw643jCM6enpUChEMqF3OTPQarWkG+BuWOhScHi3g5Bidfvi4uLe3l69Xhf3
wLmHcaG32N9yucyiCnIIWtJRo2ZZOBCudoPDdVfIORAIQKQ445lIJBqNBodcIr7Ozi4UZ2Po
6ToAN3RhViwcqDu1r0Yn+nu5KqsjuBt4fqlUPnv0CAcX2pYVyGahnjjoc7a2rFupvPj220/u
30cRrlhaQIcGjzqd769d86LdREXMKjuqLXtRKkkB3AcjLzhfHPWUpyHDV2GVMmta6M8DcCJK
2ziG6hWpW6n8vL5+aWsLPAP+1w2J5enS0uHjx4BKhtXh7pRnS/2amQxXaMidm6U+KiqnpQXa
1AiVZrPA9KIPaBgGC3BimqbUK1TQYMcL+iJCm5dWzWIxo8qoVquJOPPlcrnRaEDbqlHLjOOS
a9u2S6USJMPCgrHEnj5xu1vF6AcLHeBUYFjksKfiZkeEVBvKF6VCq9VqdK0LVTMqPkEn2wuF
QrfbdbuRwntw0O12MQMHvvgI99OsrKwAtqAnrDrJEIVq/VbAn/OoHEfC4Q89VJiRLfHPzIyE
wyPh8Nj09Mv9/TMueYlupdJXRRqgXhVa8uX+/smWuB02mz/evPnpgwf46/fXrsFLPZHGm5nM
pa0tLmkj1Y8ekbB69qWzsyM9IPPXZvPM+fMUPZz1+z+4etUNzvevzab/1i2wfWFmpn3njhtA
AgJBztp5QS8YjF69JSxlNXGQscPkYVqtVjQaRTYjGo2WSqV6vc5qQ8CU0YH2QqGgUH9AqSqX
y8A05PC3xXORHokge4vFolj82mg0gFqfSCQikUipVLIsa3x8HDXow6S/cJ2iWN0LIH0qd8b5
J8Jzc+sCblsJhUK3b98uFoubm5u4C4CTiUffAgLh4g+YKDo4ghPmjUZDeqKwWq1S2XEmkxGv
AzjhVBJF5S/391uWBQUkQsK+3N9/8e23rE45fPz419dPoLDrk045nD1/njJREsXx7bcv9/eh
NbwAj7w6OKCE0sjly6KC7uzshDw712wBsgKDlz3N5/FkX095kgxfHRyc9fvPnj9/4dYtNs0F
oQHLxQ3ORVTHIm4XaxWefPnlRwsLUvCvsRs3AJUIVl91Os+3t1mWWPpDONzZ3sblIc93dg6b
TbjzHD/dSuXpX/6CW0co1yTt40cLC4rRl27J4MejTofdDjlsNt1uJsGKunv3brfbxckJpE3e
gGHgbh9CKsmLDRB1HI7vsKn/8fFxVjfReUZowJ7OKSKMTCYDzErEQ4R9S/Khu5W8WMFqtYr7
/tLpNBxt6giuRYlGo3Nzc/V6HW4vXmERWTjow56nKBqNRqlUwtmjWCzGxTTASw4Gg3QvHovn
Jg0ukZpDpg5xCewZGCYD1hPNk+UB52HZk7BAJaDWAEpWLBY9Ig4MT+KhHMJEOIcFDIBySqxz
uXgs4AszM6wiflEqHXU6z3d2aElDz4or/OOFBSTuRS+4W6kgI6G4bOj5zg53Mp702uHjx91K
hU7Gty3rA+ZQDNSQAjYEuW+2y6INw+E+XKwBq9DzFKJCni/39zvM7sKrgwM2rf90acl/69ar
TqdtWXQP35PZWWkM1JfT3bastmWR/sX/WTWNI/sk6pHLly99841b7HVxdfXJ7CwQMUfC4Yur
qyPhMLft9HRp6cW3317a2hqdmOBunsLkEfvo9jlxe4mG5smXXwJ1EvPkqNPh4JSJCItpbW3t
888/9/l8/eaR3KhQKGAPwC3LNFjEQHsM7I9TU1OWZVmWhWs74WUP3BHLshzHQZpobm4OZw8B
a0g6mjSF4zibm5vktEq7ACz0VCqFc6mE1sUaNmx7dLvddrvdbrdbrVYgEACuPvaikR3idmIU
KhibLrAKYEDMCxmv440rUPdBBA5GSjwQCHBnJxEYGe6Y5OxQsiqYGmERzCzLAggNxle0hbFY
jMxSLpfDltIw1z6qhXDOMIyWZX28sNC2rMNmU/TB4bHC3wSyq3GMH/vxwkL7zh14jqyefba+
/o/bHQ4OfOHwkczjA2J4z+oXTl+4nYx/ub//bH2djWmw+dyXsDgbRtvsBAuMP6tPNirkiRSN
ui/dSmXsxg0YJ188PnbjBvJjBJhuuJToUKKG5Q3bPCOXLysyYOyuDLH0cn8f+0ZSlX1pa8tw
gW98ub//482bF2Zm6IJGmkJkioC5T338YGJCkQP0uL/SvnPnwszML5UKC6dMeQbaeWbvFj0R
cED1xgNpE7e91r4IugNpE0oZ+Xy+WCyGMAjKgq7rUSdncA8SrqUjaTiOw16rzuUrWAeTAzMG
iiVJA5Dm9XqdfHPHccTIg/2l32P5tm1vbm7GYjGSKpSduAvS0xKwlMvlgAEsJToHXiwWcR9M
Pp9X+/jEFRvYmaZJ5mRzc9M0TTSLigYAAnGDVSgUlpeXjePN5557ErCRKE8g12RxcbFnzJpK
pc61LetVp4NkxZMvv3RDaBoJh/23bkHPdisVqODRiYlfKhUx6f9hPP5kdvbCrVtHnc6LUuni
V1+9+PZbMa3xIXP/j9owQGXg2lXkkUcuX/bPzJBRgdd5cXX1ZDcYSMNCqXmpAlLLcyQchrcO
tCw4wiOXL49NT1PLcLHHpqfhTcPvNgY9Zy9u23535QrGjiyHeK2u2ja7zRAEMaMTE9Joht1a
GAmH2T7+ur8fVM4EbIaLv1Ow+GR2FkicqFAauXyZjVyj0WgoFGLTI6g7ZJXgiVNf2ILeyXEc
GDnp7nQsFiuXy+hUqVSamppSNIVckyJNFAgEWNPCZdg5q6PAQucegAmBojRNkwDQoM7YfkFc
HDYwy78UjITAu6RghT2NOhS0ukgXW8EQL7aC1UMpve6Ces0JSpo6Q7Dl0ZVh9+RR2MZ2002e
r0UMBBEeyGbhbXG+5OHjxx8vLAA29sN4/KjTaWYy4ePrqi9tbdmZDPcW/Fy4h+y9dP9IDnz5
JYBnva+HZ+vruA8PuxfdSuX5zZvhfB5JjCezs+o89TB7DN4J14Ao5Enfbd+5MzY9Dff88PHj
H2/epIog3JeHBBT2GKA9uUa8l6tyaS7jeM+fDAYuMOlWKt7vohIrRLkEl5g+Yh8Ym54+bDap
jx8tLKjBc14dHDzf2UE8x4YIgYMDIBUfPn6MvSVUEv+0tMQZs2AwCI1DVw+hUIQNxsWcD7fa
kTVinTh1AmEADCXKeLhlJ5Bs4fY/8/k8kHRjsZht2zBIXgD1TNMUr6IiPCvuNAPUnzpt0hPZ
HnfhUcYfe9TEqngVCsUu6p0Stho1EolMTU1FIhEu+aNATfeix7vdLu4vwcYMbTbAx8fOiluD
cE3YX0TYzZ5Q7Vx17JDUo1yV6m0oZmdrUcZu3LAzGWwOj01Pw0Fj/UGCk+U0oBqbUIEc6+Yw
YleZVvuFmRmU0gey2ZFwmO2F9PXvr13DZgaXInstLf664ywe12CT8ii44vYwRicm1PIEdba3
cVc2K8bnOzukHPu9L9AjHTabqECF3mR18cv9/efb2/1+VDyUoBBvzwd6EhtXGczVIFziyBeP
w+aJ1rRWq7mlZaXoe+zSlfpx9XqdciyFQkG0BF5qN4m8GJJWq5XL5TjkwWAwSL/0BWYsPaYg
hVPF1mi5XB4gymH7hUxX+nXQ/nw+z+o78XSIIheEalS6uAXufC6Xu337ds8yJ8dxlpeXUQMq
3ZHiFLeUGQKoV5QJYXedG7WebnvPaSOdtOJBEM6h8XIhzbmeiYh+lfhp0Fm//4OJibZlXZiZ
QcTwolTy7uESZOBgeSQ3+vHmTfWFGAoF96JUGgmHR69eNQzj5cOHihKgkyLaf/bF47ii5MN4
nDPe0gu2jHeGjoauRuWcaNY7HpJOG9X1Ncvn83FuvjEc5nw6nVa83mg0dnd3kRoqFouWZcEf
H+xb2CIul8uo0gGs/ZDlYShUHeDFer0eiUTezOnrIRHRvdMA1xz0bRjeHbq0tdXZ2aFt7dGr
V9kAomeGx/shDO9KCsDlA7wbyGbPoNBzfd0wjJHLl3F4uN92vJerNjOZV50OSQyHn5/+5S/f
X7uGLeKzMmR1xHYKg9rzItmTojPnz4+Ew+xFuPS790ZQHMJFDKd02QCnWL1DZ3uxCoasflS8
k9lja8FgULSO1Boql8js4V7bYrFIm6VSEjdX6LwVNk7p0DWuSBI1JufkKiIqvItyWwpBuHtq
3ci27fHx8TcwgT0ioou95mqdxTvMh5lLinJVDbutSZMmlTMu1bDvLMzRmxfFb5K0YdCkSZMm
Ta/H4loEmjRp0qSJpbezx4DtexaW611GoH0zEuDAagwG+/dEII5/n8ThJ+P4wu9wvmnS1J9h
4JBysfkgFsxyVXdcDSwVSGGLCQ9Ho1EpjnGhUMDBwkAggLJoFoGWOxZEmyFsDTIHgEzEbdQo
QHHdECLdTrHikAhbiSHFW240GuzJe5zkRFk3+2mpBMrlMhkGQMqwxy/Vh0I5WGPiluPHMAxw
sri4ePfuXbZH6vEF2pdt2yg0hEr1IgGW2HubRYRhGiyxBbwo/Rw7xNQmyzy3vQaYTA7xWBzc
nvzggSGPMWvS9E5HDEOCCQOGcHFxEWgqakesVCqFQiEsrXK5LILHsseC3MCH6RUsWulN8WqS
Hj5y02j9Elp2O3JZKBTUEsAzUILY7IJeJkh37xSJRDY2Ntxg4kU9juKZSCTClWrk8/lIJDI3
N1etVvP5vEIh4ousPPu9R55tASwNUzjElpxXq1XvqGfcbOG6PAxGjSZNv51UkqJSGKi2cFej
0agaocW27enjM8aTk5N0XpFDoOW0JJw+znrhzGQymSwWi27VaScFlCY1G4Pd/NVut8lXZSUw
jGE2js8N9fsup4WJWHts23a32wXPwCum4kuFBKrVKgorFZeL9SzzQKeGyaRxd9GQA4GTboOV
eGrS9Ps1DCiYJWccSXDpSnYch5auaZqE3CRtFvW8BPIVDAbRICHQiqkknNfgHHAEE8gAhEKh
zc1N8TT5YO6hG3FxiZfwQiwTVkiAy2hxWPaxWMxNhZF1pDu8iD0ofTK9m5ub0hby+XytVjMM
IxQKEdQwK0bWWgOmP5lMukkAqMXdbhexAvJ+qVSK7SaGhkVYcxNgz1hWWtnNpi4jkQgFDXT0
FLXzevNGkyZXw8CdqoBvyF6iBEiZaDRarVbZwFy6bpPJJK6Xkn4vlUrl83k4uWyel3CdsOGh
wAao1Wr5fD4ajdKtUpFI5PPPPy+VSoCAh67xCIqrBgwZMmKgPQYvEiCNCbaj0ShFElCpYtjk
OA4QmDEoQGREZ1kzRiEFpModtoIEsEVRLpeBJTDwfNrc3MR5KJon2Wy2XC4DP5LAwvb29sCS
Qoa1Wk2Uj0g0UVmXgp2ctm2zARBZ4iGtAhArxSyTJk2/BcMgndace44kz+Tk5Obm5uTkJFYU
YUMWi0XK2DiOEwgEFLmRUCgE3GCoSCxR9bYEl0qSwphgU5QFYPEOiusls0FS6gl01ZPcJEBa
TB3osEzu7u4SwD2UI64r4Z7f3d1NJpOsUXfLBKJwAAyQbo3FYqxLjsutoGrFgZCKmsOWwZ0n
gB6LRCJS29BoNDBwgx0posnJyRNYnvV6ffhYQZsETb+7VBLrphUKhVarBXUzNTV19+5dDqdl
fHw8l8vFYjHHcWq1WiqVcgsXSBPRda/sSnZ7nksliReOi8u1X1Bc0qEcypVxQohUXiQQCATI
5Ig4+BARZ0E5HEpSvqzCglFPJBL1eh1JJ65Z3G+FNBRueQRCNQsK7fP5IMNqtdputxF5iCGU
F5TjSCSSy+WQsMKwBoNBrl+4boWFRRvGDLdaLVy/rle7Jk19GIZWq1UqlVhtnkgkoEHgcJET
iusmkAcggtOHKJ5LJUtpfHyc07+2bXN6kE13cEVTrNaTYvwOAIortsyZpb5kSsy7WTupBFjz
w+HgU15FVJRu5aFIJcHAYPhSqdTdu3dF9zyRSBBQcygU4q7cAqXT6UKhgMyJAhHeC8rx8vJy
MpnEY/g/V5cFsMy5uTmPVkG9xwB7X6/X2U6JF7JzMmR3awzhlk3TNDMyyHFNmn5ThgHw6JTW
B2A6vEvkPcRggqsi7Ut71mo1BQLtYCj2isSFCIorBgHcX8UgQFrqLpJY5CMNbqQSYIsy4Ziz
/9rtdqUpF2lZkRQfWJH66HkBiDgNBqaVlRWFLTH6vGzL48RzHIdNKHHbTupsqlTCbLnq2tpa
v1ePadL0XqaSTpveGALtMNrkLUqg3W5PT09zlkOf1B0mocRKW7wjZRjSOw2afpuGIZ1Ol0ol
NlimVNJpkEcE2neNxIzNYFczepFAIBAQL5DSbukJzrc3dneCJk3vI2l0VU2aNGnS9BppdFVN
mjRp0qQNgyZNmjRp0oZBkyZNmjRpw6BJkyZNmrRh0KRJkyZN2jBo0qRJkyZtGDRp0qRJkzYM
mjRp0qRJGwZNmjRp0qQNgyZNmjRpevv0/w8A+JHUmtyKrq8AAAAASUVORK5CYII=
--------------540515D404FECD890DA94934--

--------------10939D576D7DD9B32C2DC8F2--


From nobody Wed Sep 13 03:01:02 2017
Return-Path: 
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 0516E1341FE; Wed, 13 Sep 2017 03:01:00 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 Vi5Y1CoGIhlZ; Wed, 13 Sep 2017 03:00:57 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10130.outbound.protection.outlook.com [40.107.1.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B423134202; Wed, 13 Sep 2017 03:00:56 -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=IDlAj9DpRTR6SJtpW5MXmD1mH+3CIw2aXr6qRIPE/yQ=; b=H9iSroT2fOuLZyWfvPMDCoGF0z/RHdub5QN87WtUIlpbsKR9fochSuLs62jTxDCZAHSAfQXuHSugX56Wt6KEoqz/CkDtNZwL4RCqQ8fHBSUmKSPbwbJk5I5Gyo8qpS1ivI93OoIW3v/iDHpj0uX672gL9mJnLU51BJqUxpFNnMw=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (86.185.245.5) by VI1PR0701MB3005.eurprd07.prod.outlook.com (2603:10a6:800:87::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Wed, 13 Sep 2017 10:00:53 +0000
Message-ID: <019b01d32c76$fa7dfc40$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Kent Watsen" , 
Cc: 
References: <49B4BE2F-6912-49BE-9E4A-830146309AB2@juniper.net>
Date: Wed, 13 Sep 2017 10:40:06 +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: [86.185.245.5]
X-ClientProxiedBy: VI1PR0701CA0041.eurprd07.prod.outlook.com (2603:10a6:800:90::27) To VI1PR0701MB3005.eurprd07.prod.outlook.com (2603:10a6:800:87::19)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 19a03edc-727f-44b8-cfaf-08d4fa8e5229
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:VI1PR0701MB3005; 
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3005; 3:kxCsU7RJBkJS641HUfT+xz8SL5Rn4zIes8AXr4sbchtflNgryrW6+GEQ92WsZKHtLaeGWZSsTdQDIegeQv8tTvNRBi0SC+1P+ui8FLR+Zu2spS++SkhN62xztLDWf1N1svxYL5+r2CqPrFeRKUuEmUyk7n0JZIzlddxo9JJXjL0LMVsKtStxTKDnDnIvQMAIyJ2ee1lL6ic82EpK0i8QkDAkxI5DkN/YT99+Z6uf/jWSbPP7WmpYWie0xY++YzGP; 25:ceztQ+60zHA8asq89XmxcL1pbUFhBveFauuBaezwRCqEQM02VqU5cj3eMstjhvAV31pp8Mfkl8I+wc48jb5KDVgyZVaV17TRHVz6/pOcV30UF/hTHM8utL//ZQ2hapPdfeqR2HyhpE2KHrGo3Qs798pQgBVQs3Fbr69m6JMiWOW3wcvBFrxg11NoWKxhwB/xlbojdtD6zEventDr736Pa8HIep2DGgvr5qt+7TILMJO7vIzYVPEmBWEgga+S3VacRf63iZmngdvxL50OqrTPfR0v3A6V6Im8HRTIGdgVQld5zsv91J/KaZkVOVXXNJsYepUVafzKwBY4tBXu0/jW2Q==; 31:IOL1PvUj/9nQoiZDLDm5osVRPVqOPYfsamjmYAibE6AXfqP9beOJqSJLDldOolek2q75hBajwiuuAgMnDd6PMEStP8bok1t1+VOLfTnTQ54MwXDCuA/3UV/69v6YbEnw0Dzycd3vogMvNuIft/MbCuEAZ7PA9ajVsSjcDG2r/8stilEZatRVgTneWp1tpKW3nAw6cTG3C9/tDZ5tIdcOraMOCO69v3J/2PolGJ9duAY=
X-MS-TrafficTypeDiagnostic: VI1PR0701MB3005:
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3005; 20:fhDgIUgxmz6noXtHHUX4CmwHaC1lAJ+fQoc6uouoEKtsrfM57uWaq/Xe/ca+hCSevF4r0ZBerX8gd0qgzNzwH/jfeqyjKcNE+x3o6p2iN9yYIE6johbLs+g4AK60FrG4D+VwJ8tD5tgZUFABGWgyXVmUBz+y8TG3rUA05UCiGDnDFrpdJZUf/4P9Et/Yhx/3zqpNAX6jVMfZ5ooUyltzoobEmkEizlyh9utJ0pQ36BNNLnXnC6bAASRhpeIkbC1K; 4:oM6di8xMAKjkkCTLe/o5oNviin9qZNRbKb+b8mcclJrzggQh52TR/geRTv6Q2esw8x4arhYub5Lcs2fSgJTrhDJ4GF4e6HjBysf8F4X4yU/LLpL0hRtYknTCNNqgKghmh8k+eVmEgJgIiW9LcAAdsYqviZOOPrRRekdSYYFl+DIC6l0Ss/Y7gfw87ynxCO8iuxB3sO+kQyNg2200c45Y8GxYQ4sS0x3VKwZ1IoeuWz4Opdf4gTmrMA2g294ntXL8KSqAw8CTEA238qjj9NhnYSWh+my89EsWrz3CrmfiGSE=
X-Exchange-Antispam-Report-Test: UriScan:(138986009662008);
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6041248)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR0701MB3005; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR0701MB3005; 
X-Forefront-PRVS: 042957ACD7
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6009001)(39860400002)(346002)(366002)(376002)(377454003)(13464003)(199003)(189002)(116806002)(61296003)(97736004)(105586002)(8666007)(6116002)(9686003)(53936002)(6306002)(3846002)(25786009)(33646002)(101416001)(1456003)(81686999)(14496001)(76176999)(50986999)(81816999)(106356001)(50466002)(230783001)(7350300001)(84392002)(6246003)(1556002)(2870700001)(81156014)(2906002)(81166006)(8676002)(316002)(68736007)(189998001)(23676002)(4326008)(50226002)(305945005)(62236002)(44716002)(6666003)(4720700003)(229853002)(47776003)(966005)(5660300001)(7736002)(86362001)(575784001)(478600001)(1941001)(66066001)(6496005)(6486002)(44736005)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB3005; 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?MTtWSTFQUjA3MDFNQjMwMDU7MjM6RVJZa01aYmhLUEZFUWxvN3V5dG02VXV4?= =?utf-8?B?RDFSakpoZFA4Z29iOVBVRzVObmdrT3ZDaUMzQWpycUJTUVlFSzEwWGFFc2dO?= =?utf-8?B?eEFGRC9Tak1JN1Zpb3VRWm5BSEJDclYyOG1qR3UvVmJZQzFXTDEvRGZjR2o0?= =?utf-8?B?UVhDbVJIMG5SS042SWpQWkppT25aR0hrWHNhanJkRXU5emE3RUZnRWJjTzZH?= =?utf-8?B?cXBoUlB4ejAvN1g3dVBHZXhpZklHNUg5VXIrSXFLK0hJUkJDZWQxTUFkcnNo?= =?utf-8?B?WWVXaE1mMmZNUTB2NjJLU0d0dmRSdHg1bDh5M2dpMlBEeDl6MmgwdkU5UnFR?= =?utf-8?B?eTFaYlNRWnNOSGIxY0xmNTk4bFpuMnpBcmpzRTV4N202ZStEdkhFUnFCdlVV?= =?utf-8?B?RWlGN3dndW1tK1JtT2JUUkNIeDdEeE1zWDRPZUI2cjk4QjBOU1I2d0tjazk4?= =?utf-8?B?Zitnb25ZWG5jcTFVRDFPVlFMb2UveC84Z21EUUR1QmY5L1llRDFSbFdKTVBC?= =?utf-8?B?aXE1M3FGbHMvc3RNdG1wb3ZzaW5sTk9McEkyaVd2YUQ4Umk4R25TVyt1NlN5?= =?utf-8?B?U3JqZDBGTzJ1ekZjQ1o2bWlJeWpSTHV6dnBKdkhaK211bU12S1hDL2RzUG5a?= =?utf-8?B?ZUlyT3B5Ykxoc0d4bHNzcWZFd1hPcTc2OGk2bUVzL1FVZlB5LzlMblIvdWwy?= =?utf-8?B?MHQrQlZycVZ0SThZeThyaE1hSGtZUm4rTDRZQ0FUcE9jT01TWXRXeEl1OUIy?= =?utf-8?B?ZUFUWU1kYTRpV3N4UFJydVIzWm1MRTV2QTd1YTQxTXlKeFhJSkZIRU92UVI3?= =?utf-8?B?WDFtWC95YjgwTGtHZVRBUEZ1ckVXS1FVcVU4OXVYejNuejlGMWUrVFBGa0dZ?= =?utf-8?B?MFZWRWRTUE14SmNJUlZYS1BldWFnM0VyR0VzdXFhVUp1WGxYSnJEZDNJYi93?= =?utf-8?B?K3pZODF4bEtpcmtpTWZ5L0Zaamx1aG5zL1U5R3FwdE9hTFhSUDNMNFpNZjJq?= =?utf-8?B?TU1scWd0dk9wZHh0Q3V6Mmk0M2Vzd2I0TUtQaUlPREJrSXI5dXRXWmY0Q296?= =?utf-8?B?RGg2cno3MUNIaGtPOTZLQjZ5YVZnbHkyN05vUGtTYTNzRDU5ZHdKTDVEdkl0?= =?utf-8?B?M21ISHIrd3FZVnBpbzVBWWNzeG9tUzZydnd4ZUExc3NaK0JNWDlLL3BINjN2?= =?utf-8?B?MkRPMDFIUHlheEg4TEtMTFJUam1Jd3UrTEcwYXRySHF3VnFsMXNqZDNKQmZM?= =?utf-8?B?dXRnVnh4S2prb0M4Mk9sVDI3YTJEcmNwbk84Ti9qTng1MjUrbDhCZXFkTnZ1?= =?utf-8?B?NFNyTC96WHpvSVNSQ3VLbFRWdmoxUEFUTVVLcFd4dzNRQzBaYVZIK0dxT2hQ?= =?utf-8?B?RmhpTFNIdDBrVDBEelZaWWpPaERTOE9EREpNdFBQSnl5QytZUlBsTjd5VVVX?= =?utf-8?B?NU1nWHNpNjR2M0k3K1J2eVhEQjRxTDhzaXlrTmJTQ3haZHVsVEl1ZHdkNDhU?= =?utf-8?B?SjZ4NlY4OHJnRlZueVYySS9pT1c1OVorV2RsVWRkbjFuM3BRaHJON3NyRElW?= =?utf-8?B?ZG9hMXpqczRJNjExMmlnVndzZWp4QjAxTFZFTFVEcGdvb0dhMzJWTlJUNWhz?= =?utf-8?B?OFl0UlB0U0hxeXJESzZ4RWsyTVNCUmt4amIzTWVCRzdxRHBuNjVraDFTQXpK?= =?utf-8?B?dU1jNjNRSjNjMlBNL3Rqd2tCTUppdmlGMktmRVcwQy9PNEVJUnB6eU5rdWhI?= =?utf-8?B?eUhiOEx4MXk2Q2xvTlJZVVhyUE0vTnhqOENBL0hxb3JLTGViWjVxNVVPcm9M?= =?utf-8?B?WXRoeldIZGovc2tLNjFacTZJVFM4amJCRHFYdllGNStzNXhnVmx6cWVta0Qx?= =?utf-8?B?YXdCa2xES1d6b0hRQkJQRlcxYndLYzNkM041Y0pNR3M5eVFZVHJtNXhqWUVX?= =?utf-8?B?cllqSG93YndCRjZwYXNVVzIybzdoTmkxUS8vYVIwV3BRTUFYMW10ZjBJRHBx?= =?utf-8?B?ZnB5VlQ5alFmOFJxSG1GSVViNzM1VGk1aURacHA2Wm1jS3FXN0xlaSs2Ukt0?= =?utf-8?B?UnpoVGtsY1NydG8yZXlyM0l6eEhja2tpRWRKeWdWeGlLbk91NkkzNXBFelU3?= =?utf-8?B?Sms5UT09?=
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3005; 6:Lj1FdyDCEcmAosC5W/SLnrvapmgV1Lkc6vO7oYbtG9V8C7MnH7u0r+BlLIZDefL/fjR0ZIGSyq89VKrt4uWNP0B/lTZSYTvq4O/hI09cahSR5BuJP2weUL56VGkBvMus0S89QAw+Tfj3eH3Cv69PtvOr2MW1sm+ywp/ZFzk54k5EpBOE+IRD4uSJuKymCYEeLjICQnbRySN6Hex5MPz5POBVKBXEulugoEwRpq4eg1NdlQUfP2xKggUFN+D5irAbX6tX8W+IIndiWFdjdQSelNtPcwjtDg9oiRYtFXfh7/pY6lGsxhdFqcyHKv6lsa563AGxowPzJ8AeQG8mhiI9zw==; 5:03BKlnnqno2EekgOVN/NyX7SbRqwmfz3hWAUkcUZDn5/KLhi9zEULaEWQcDACxe3+PWL2o5Lt0y7Of3QkXbKnP/GPw56wNfgdPfXaCMxAQvHm8/JIdN2cTTmcAygZoCLHrMSnP8mRBbPfSd/6nFYgg==; 24:Pu7Xic9PtrOuICX/5JidfhGHoo5kPupKlZ/FPa+5Bw37G25X11b4IYIQRv/iB2w8/U6cR9DQ0Ly0o+OhoCRC8k6la+PjVoR3m41jBN8aE9Q=; 7:81Y0HZVYjdban1mDK+t34aquNmVc3S44HestBsGiQY2JUUqsZr5IX4sBrIYSvBbQkHCcqQexlSEMtjCIx6ur5HhSLLFfd6h1RBfycpYhEEZXV/vnYv2e7br0yYBkAkHm58MLrCR+xXALco4ohxllsMgvkhPrxlo9k6oDeEAHLkfoDqnjOWgC2IBBTengNy/xRd67sljR7wN6Jtsh9v7bagONxRZIq/B5BB+47xwFqvo=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Sep 2017 10:00:53.3260 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB3005
Archived-At: 
Subject: Re: [netmod] syslog-model-17 shepherd writeup issues -references
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Sep 2017 10:01:00 -0000

Kent

You flag Std-1003.1-2008 as listed as a normative reference but not used
anywhere in the document.  In the Descriptions, but not in the s.4.1
references, I see

This leaf describes a Posix 1003.2 regular expression ...

twice, which may, or may not, relate to this issue.

Back in July, clyde said
"I will insert a normative reference to POSIX 1003.2 in the next
revision of the draft."

In a similar vein, RFC6991 appears in a reference statement but nowhere
else.

As you point out, RFC6021 is referenced but is obsoleted by RFC6991 so
should not be.

And in a slightly different vein,

   registry [RFC7895]/>.  Following the format in [RFC7950]/>, the the

looks odd for plain text and for the repetition of 'the'..

Tom Petch

----- Original Message -----
From: "Kent Watsen" 
To: 
Cc: 
Sent: Tuesday, September 12, 2017 10:50 PM
Subject: [netmod] syslog-model-17 shepherd writeup issues


> Clyde, all,
>
> In reviewing the draft for Shepherd writeup, I found the following
issues that I think need to be addressed before the document can be sent
to Benoit for AD review:
>
>
> 1. Idnits found the following:
>
>   Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment
(--).
>
>     ** There are 2 instances of too long lines in the document, the
longest one
>          being 3 characters in excess of 72.
>
>     ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991)
>
>     ** Downref: Normative reference to an Historic RFC: RFC 6587
>
>     == Missing Reference: 'RFC5425' is mentioned on line 359, but not
defined
>          '[RFC5425], [RFC5426], [RFC6587], and [RFC5848]....'
>
>      == Unused Reference: 'RFC7895' is defined on line 1406, but no
explicit
>           reference was found in the text
>           '[RFC7895]  Bierman, A., Bjorklund, M., and K. Watsen, "YANG
Module L...'
>
>      == Unused Reference: 'RFC6242' is defined on line 1435, but no
explicit
>           reference was found in the text
>           '[RFC6242]  Wasserman, M., "Using the NETCONF Protocol over
Secure Sh...'
>
>
> 2. `rfcstrip` extracted "ietf-syslog.yang",  which is missing
"@yyyy-mm-dd" in its name
>
> 3.  neither `pyang` nor `yanglint` found any errors with
ietf-syslog.yang.    pyang says
>       for vendor-syslog-types-example: statement "identity" must have
a "description"
>       substatement.
>
> 4. testing the examples in the draft against yanglint:
>       - for both examples: Missing element's "namespace". (/config)
>       - just removing the "" element envelop resolves this
error.
>
> 5. the 2nd example uses IP address "2001:db8:a0b:12f0::1", but this
SHOULD be a
>      domain name (e.g., foo.example.com)
>
> 6. in the YANG module, anywhere you have an RFC listed in a
'description' statement,
>      there should be a 'reference' statement for that RFC.
>
> 7. in the tree diagram, the leafrefs no longer indicate what they
point at, they now all
>      just say "leafref".  Did you do this on purpose, or are you using
a different tree
>      output generator from -15?
>
> 8. RFC6536 is listed as a normative reference, but it probably should
be informative.
>
> 9. Std-1003.1-2008 is listed as a normative reference, but it is not
used anywhere in the document.
>
> 10. RFC6242 is listed as an informative reference, but it is not used
anywhere in the document.
>
> 11. the document fails to declare its normative references to
ietf-keystore and ietf-tls-client-server.
>         Note: you manually entered the "[RFC yyyy], and [RFC xxxx]"
references…
>
> 12.  The IANA considerations section seems asymmetric.  Either put
both registry insertions into
>         subsections, or keep them both at the top-level…
>
> 13. reviewing the final document against my original YD review, I have
the following responses.  Let's be sure to close out these items as
well.  Ref: https://mailarchive.ietf.org/arch/msg/netmod/10lo41Ud4A3ZN11
s-0gOfCe8NSE
>
> 1. ok
> 2. better
> 3. should be: s/the message/these messages/  [RFC Editor might've
caught this]
> 4. better
> 5. still feel the same way, but no biggee
> 6. better, but from 8174, you should add the part "when, and only
when, they appear in all capitals, as shown here."
> 7. fixed
> 8. fixed
> 9. you did what I asked, but the result still isn't satisfying...
> 10. some improvements made in this area, but my ask wasn't among them
> 11. better
> 12. better, but I think the 4th line should be indented too, right?
> 13. better, but I wish you called S1.3 "Tree Diagram Notation"
> 14. fixed
> 15. fixed
> 16. fixed
> 17. fine
> 18. still a weird line brake here.  try putting the quoted string on
the next line.
> 19. fixed
> 20. fixed
> 21. not fixed (re: yang-security-guidelines)
> 22. fine
>
>
> PS: please also be sure to follow-up with Benoit on his AD review.
>
> Thanks,
> Kent  // shepherd & yang doctor
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>


From nobody Wed Sep 13 04:22:09 2017
Return-Path: 
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 8479C132355 for ; Wed, 13 Sep 2017 04:22:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkBzPf5ykLEy for ; Wed, 13 Sep 2017 04:22: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 EF9B91252BA for ; Wed, 13 Sep 2017 04:22:05 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 6569D1AE0352; Wed, 13 Sep 2017 13:22:03 +0200 (CEST)
Date: Wed, 13 Sep 2017 13:20:31 +0200 (CEST)
Message-Id: <20170913.132031.1474514593050589478.mbj@tail-f.com>
To: lberger@labn.net
Cc: lhotka@nic.cz, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <20170830.094028.1809893324608957744.mbj@tail-f.com> <15e32791e40.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] schema mount open issue #1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Sep 2017 11:22:07 -0000

Hi,

Lou Berger  wrote:
> Hi,
> =

> The LNI/NI authors/RTG Area DT met yesterday and discussed the propos=
ed
> change as well as the other topics that came up in the subsequent
> discussion.=A0 The high order bit is that the proposed and current
> definitions are adequate for our needs.=A0 Read further if you care a=
bout
> details, including confirming our understanding:
> =

> 1) WRT xpath context change proposed by martin
> =

> Our understanding is that absolute paths continue to be allowed

Yes, this is correct.

> , for
> example the following remains valid:
> =

> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "use-schema": [
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 {
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "name": "ni-schema",
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "parent-reference": [
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "/*[namespace-uri() =
=3D 'urn:ietf:...:ietf-interfaces']"
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ]
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 }
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ]
> =

> Assuming yes, then we have no objection to the change (as it allows t=
he
> server implementor to choose how/if they support vrf name filtering.
> Obviously, using the new syntax exposes the restriction to the client=

> which is probably desirable.)
> =

> 2. parent-reference location is adequate for our needs.=A0
> This said, we think parent-references are more appropriately containe=
d
> within the schema list and having them there will yield less complex
> operational data.=A0
> =

> 3. current mount point extension usage definition (must be in a list =
or
> container).
> Our use case is covered by always having a single mount point contain=
ed
> in a container.=A0 We don't see the need for mount point extensions w=
ithin
> lists or for there to ever be siblings of mount point extensions.
> =

> We don't see a need to discuss items 2 and 3 further at this time.=A0=

> Assuming=A0 our understanding is correct, we will update the NI and L=
NE
> draft as soon as schema mount is updated as proposed.

Ok, since we haven't seen any objections to the proposal, I will
update the schema mount draft accordingly.


/martin


> =

> Lou
> (as contributor and NI/LNE draft co-author)
> =

> =

> On 8/30/2017 5:29 AM, Lou Berger wrote:
> > FYI I've asked folks in the routing area, i.e., the ietf users of s=
chema =

> > mount, if they have an opinion on the node discussion. I will also =
do so on =

> > the point I raised on parent reference location. (Which is independ=
ent from =

> > your format change.) Clearly, if I'm the only one to be raising obj=
ections, =

> > I'll be the one in the rough on these points.
> >
> > Thanks,
> >
> > Lou
> > - as contributor
> >
> >
> > On August 30, 2017 3:42:26 AM Martin Bjorklund  wro=
te:
> >
> >> Ladislav Lhotka  wrote:
> >>> Lou Berger  writes:
> >>>
> >>>> Lada,
> >>>>
> >>>>
> >>>> On 8/28/2017 10:16 AM, Ladislav Lhotka wrote:
> >>>>> Lou Berger p=ED=A8e v Po 28. 08. 2017 v 09:40 -0400:
> >> [...]
> >>
> >>>>>> PS is your view aligned with martin or our example?
> >>>>> If you mean shifting the XPath context node to the mount point =
instance, =

> >>> then
> >>>>> yes.
> >> So, going back to the original issue; does anyone have any objecti=
on
> >> to changing the XPath context for parent-reference as describied i=
n my
> >> original post?
> >>
> >>
> >> /martin
> >>
> =


From nobody Wed Sep 13 09:44:15 2017
Return-Path: 
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 B76B713306A; Wed, 13 Sep 2017 09:44:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.91
X-Spam-Level: 
X-Spam-Status: No, score=-2.91 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 y3fwq7bamAKC; Wed, 13 Sep 2017 09:44:10 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0109.outbound.protection.outlook.com [104.47.1.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 099311326FE; Wed, 13 Sep 2017 09:44:09 -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=+XDdzeVjOK5qFk5vr/GSfW0S9SBqudP9q/oCToZ6rGU=; b=apyetCvfwKNtOBUri9gy5TEnKkKQsebvArPBHpBrjSDiOdgLB27RYKzKu97X+d3p0mfHf2rn9uUDQPynCRYAw0BsQX3T3uN7bKdEOzDoYtQ2rYD5fHZHknfbyN6IMX8Q5+FWIVdlVNDHPN6abEZ3svu3lm1QvpytmePNh+Z8XD4=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (86.185.245.5) by AM5PR0701MB2995.eurprd07.prod.outlook.com (2603:10a6:203:48::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Wed, 13 Sep 2017 16:44:07 +0000
Message-ID: <00bd01d32caf$4eb28e60$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Lou Berger" , "netmod WG" 
Cc: , 
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net>
Date: Wed, 13 Sep 2017 17:42:30 +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: [86.185.245.5]
X-ClientProxiedBy: AM3PR07CA0106.eurprd07.prod.outlook.com (2603:10a6:207:7::16) To AM5PR0701MB2995.eurprd07.prod.outlook.com (2603:10a6:203:48::17)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 35e20f18-3f8d-4bc2-18e2-08d4fac6a6de
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM5PR0701MB2995; 
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 3:x0FoEDJbSHcKvCPUfwz2hIcJFgHkF9cRj7EDCNuRIupHhHZxASfRUmj/v1HnDagpyQoxpGDfh8fXrEE2wwjsJFV66eqsk52aMc1w9+78pLeB/cQyw3MpvCl8RctpQFnLwbbfUo+QsQ4BVCN7uuwGpdyskDYIzJVg2N93zBIqTTosyJAg/y7vTpszDtwFWW/H4doxHUNVmfQU2xA6f4fyZ2xiL2UcJOiFIzZ8poDzvcMYuF5s6c050HgFLl1atCJn; 25:Ksv/D47yFmMFEV2RrXm1SH+aA7ICxJp/94n9FfQETIPQ+G4q1LdqYnBHJiwKv4QXFqwBuEo5KwoAfG6np712uvQ4UnXpAoa34legjuD9jJY7JZf346ngktQ1MFEyQPwHMoz1PtHisIPT0Iko71xTEow7w3M0HvVrpmC3ceXTL88Lv2tDoG/6db+QXhUEKThv6zwvtmE47pQiNc41RRgk35ddR0/eOkJAeCYWGnbtZDFO+jtb3Uh6TtGppkL+szN2GJvENx6yJy/e6RxX3+SfD9ehwaZsEXhiM1w2pfkHYNlO8h3PnIIETbaMGUu8GZI9vMU8PZ7FOW4JHeWDw7/t8w==; 31:DvJz7czDBDklFQromv1wbdnapShyggM/No8KBB+A8sFJUR4dFL60MmyDK3UcGeG19OyQKBOv9X0ttcF9rXcbkMGNr80KLy1ehczuwlSJAekppQcuZk3gqH83tO8yZOKn7BcwgdU2XEhhFXDn514azPwfr4m956V2oldObmwBDMWBJrMKyS1hJ8rw9AhneICoLEQ6iUc0ENkeBw8Yxz2a6vR//z+hNOXlP+e7ekwhfyQ=
X-MS-TrafficTypeDiagnostic: AM5PR0701MB2995:
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 20:Idp+WryxFpOUOJFTuOsV4lvzoUXu0h2cFzyQWSoeaCAHSsNdEw1yaFnN/7Fo1SaQc9FaXe1vBJYYQqWAuDFjGt0n2GTJ7/VXlv1ubjsqmYaXR1z/S/JeNDqsf72/3qdqqDW8CNHrOzxTVb3MQGOzjAfadeyUZT46u1HJmGeWZP/D8YWz9Jd64oiAffgAC7N52+xL38iM2CT4T4b8L6JKSveDd/4paIPKYpv3Q8g3MB8r86ty2tDYVMkKAK2k3ooV; 4:q50Rujcy3am1qCHDvMrSXyvUyglX7WwA1MFFTlDDoQLkL6xj1mLsa0Gp/yBrUH1eTXjtQH9Gralo1qPRiDXYl+wBPqfzjbk60MpingYDoIcVB8H9Z4a/g8/n7QS+o9s85ZiwZp1pi83eaYkp+Xk5TAkTK6n7t6giJltxfn6eLEz8F59PSKzRb79nmOrW16QHIltZx0C1bEMS38zYE+jaLsmLxfIIPmcpwj64oqsELKCX4HSWkb4NWl2AnkpErHT9
X-Exchange-Antispam-Report-Test: UriScan:;
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123562025)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2995; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2995; 
X-Forefront-PRVS: 042957ACD7
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(7370300001)(4630300001)(6009001)(376002)(39860400002)(366002)(346002)(189002)(377454003)(51444003)(199003)(13464003)(3846002)(6306002)(54906002)(23756003)(7736002)(478600001)(50986999)(101416001)(76176999)(81686999)(81816999)(105586002)(6116002)(106356001)(61296003)(966005)(81166006)(50226002)(9686003)(305945005)(81156014)(8676002)(62236002)(66066001)(44716002)(316002)(33646002)(47776003)(68736007)(97736004)(25786009)(84392002)(230783001)(116806002)(4720700003)(86362001)(44736005)(7350300001)(6666003)(5660300001)(4326008)(229853002)(1556002)(230700001)(2906002)(6246003)(53936002)(1456003)(14496001)(6496005)(6486002)(50466002)(189998001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2995; 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: =?iso-8859-1?Q?1; AM5PR0701MB2995; 23:7du+VY6lrewMe7TY2IN39DusIIqhzWK8LzXYz?= =?iso-8859-1?Q?vzjEiKep0P+5I6mXqPXkMUF4dJr0K8KiI3Lmh9gpU3i/MX9enyn6iKJ7wK?= =?iso-8859-1?Q?3e4F31xw9MV2e0SkArFnrAKJF3fkGdwu5VyxRIGSAFLf1d7sE/cHhbLHEb?= =?iso-8859-1?Q?mxuYoK2z9MRWP3qeWnewX/6yt0e40g3hN7tGn1t09kc7KTme/lIrWosKLS?= =?iso-8859-1?Q?trPPifR173hyMv6dm1lKTVFABEXCcLjGGL7h/RTVwic8NzVSvaex06FegB?= =?iso-8859-1?Q?695bC88/lCgJJEasfs9h8u4a/ZeDhDl9H7xEifMnSfgm+M3alSGpb6RSMy?= =?iso-8859-1?Q?JboIDDwSb5+E29T27vChqs3qq1wr/YvsML5plReWzkAZGI70TOuJltl2BQ?= =?iso-8859-1?Q?B/V86PNzK7omRCqvIEtr67iVcEAlpu46wq101h5TgJRNNFU+cf/DcXJVpS?= =?iso-8859-1?Q?VQPHmNHzK7IR/RlOAHCMzcw7kXre63AUKjklpQdDr184btUSor443RiECN?= =?iso-8859-1?Q?oO0rJO8CTCtrvecHTo9F3v7B2gqUSPyrq1C/+J/Bj/ZShHza/ixCeYQ/QS?= =?iso-8859-1?Q?SNGhNuk+QFHwFChVhE8Ry5P58Y2+XNRHBR9XDf1QrP5nl/EAvOTuuaf5Bb?= =?iso-8859-1?Q?/NsghzZ6c2BQ/5UlqN1nYAtBK+AaYT8zfIIkyCVtQF675QRqO7cjsqsbtr?= =?iso-8859-1?Q?ZxTpNnf/wG6m1MkK0AzFImJW34NyHay9pxzg9xCQE80ixptFUf66wed8kN?= =?iso-8859-1?Q?IPBVl/KXW+4GYT1iMYbqhJ9xX1hVbgB63X1Ul9KCst91D8ihDGqhhn36Di?= =?iso-8859-1?Q?CBG4UeigmNMgt6sLAuHyAknRkJfz53lHEnLeXhuu5EyZY40b2Ax6Jv0dnK?= =?iso-8859-1?Q?Q1uWSWsmPPK3u8sdhY+ouB3b8k3yYxZb0K/1qVtOcc6vHuEbzERxzkcO7s?= =?iso-8859-1?Q?9hLI7uY1Qk/GCW2Gct/QjDdJDsJV8kQcFhwX+/7YuL5ZsBSe28J+eNAIxU?= =?iso-8859-1?Q?8wJnQQ6CkO3UOq03gK1TAeThJkxq2jYrF2O97SbUQpvsfOlNpMgyDhgpNY?= =?iso-8859-1?Q?jhg8w9q9iXjb8tWv5nqsreh8R/Jy7kqO9ezwrD+1DIpufRyTOO0X19w5pZ?= =?iso-8859-1?Q?nXkuhttPnVmeHOf90lGm4Cqnn5CClVd1bwE3BQVozuOb7D4MMU/4h7taDO?= =?iso-8859-1?Q?O7V+3LaDfYwiEUxewXAvAJZdE1UhUyU7dFN74c16ZCQB/pb6CwXme6uvsM?= =?iso-8859-1?Q?d0mDIxl2FY6L6w3wJ5EBD1xuzc0125etPRara38oFLk2Hf3QrNJbS6srI7?= =?iso-8859-1?Q?mEUmkRSSRbF8hfeIzT3LHD0We8cxdevB3oxkJbLimbh3OfSszeJhdFK70D?= =?iso-8859-1?Q?qdwQJxePIbGhPKEL9IvOkFp/zmbYVLGSxArzvp7eCe4nTSx8heLsXmvbxy?= =?iso-8859-1?Q?6/QO/ruKqHg0BtlCa3iFBmuaHfU8mVKDKU/Vs0c6pEIKGvhlOXyYnrIAgT?= =?iso-8859-1?Q?ODc/e/dgoWEGKC49Sz5sAKA9hu6DMWHfwrjL6cWd3k1idjCDJY5uVTXWNt?= =?iso-8859-1?Q?fK/ppiAZv6UXzfDGz5sVwjkbZF7SMGCpzZyACT2VAOJffGA6S?=
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2995; 6:rINoaOvZz34DO0DJR2n0Phf1ynjg+CKAnjSzFz2SR9ex6pxnE6bBO1rgB4jI90tkw7k3EY9aelPSJxY49Ly1C+oUHlzDi8sWSAdLOuaXM716aYr7Vk+1/Ii2VzzqeC4T13Mp4Yb1xpQlP2LOR+M/eySW5DOYA0f3qjqCIpZqUTPYgtN3E7PSHJPjyq7SvrD7d9mtWm3wJtbcsEN29VaEKQXRHE/KWxGl7SDZFqLWuXeQB+PUIjIC2rWh+DjwMZsYVvVxZD1ftmRUBdQUiCbQ3Mz57iPJIFEcXTHLDv8EEWcaBFUZ5bsgh8e8k+CQ4hepRYInVtL4KxvvmLSvUgJEsQ==; 5:PG6Q1ZSJjkuoaGML8JJiArR19sLPn6S2EFK+w6RuY8VI/Iff9DsUdXdzsOEK5Mg8xsqdS0uu1mSbikKr9iwjIC+hd9Yr6xPf5pG+ZKncVngK3xsp00vh9fSHVLoYGsK/hfrxznx/5EoVdox0S8Z5fg==; 24:waK+mUjvsIET993E0VySBDH84TM7R8Mg6WCCDGtAUQdXwe5Ixfy7RWIZo7zVM4OJ36AIQEp2BDc9vVA0GpjG8I/TURe5AQWaGZghZsP3w/I=; 7:ZI0wrJAtihYVDjs4UkV4JI34pOEFpdvlZKKFOcoovtEvag5HcKWJpI4LI8tqKgqJcaLbBUksQYljHWuaByf8bYjAByK20ca8a9ldTpkjpg3zos7P8cNlt8ftKWOizofKf5p+q4WxIhz7bgwfi0O++xGsIoRONHPjfzx+ODe3RVYjLeJjvbF8C3h4UMwLOUKZEFEkWAKc6oWRouwkCpd3BQka0Exsa31KnXJURVgxMFs=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Sep 2017 16:44:07.3155 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2995
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 duplicaiton
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Sep 2017 16:44:14 -0000

I think that in one respect, perhaps the key respect, this I-D fails to
state the obvious (or at least what is likely obvious to those who have
been at this for a while:-).

The problem that is hinted at but never explicitly stated is that data
objects can appear both as configuration and as state, e.g. when learned
by other means or at other times.  The original model of datastores
required these data objects to be modelled twice, as configuration false
and as configuration true, and since there could be many of them, and
the rules of YANG require them to be in separate trees, this led to a
twin-trees approach such as can be seen in RFC7277 or RFC7223.

Amongst other problems, this separation of operational state from
configuration in a
   separate branch in the data model has been found to be operationally
   complicated and impacts the readability of module
   definitions.  The relationship between
   the branches is not machine readable and filter expressions operating
   on configuration and on related operational state are different.

With revised datastores, there is a single data object to model both
values  but this now appears in two datastores, one for the
configuration value, one for the operational state value.

Instead of two YANG data nodes there is one data node in two datastores,
a more elegant and simpler solution to the problem.


I believe that text such as this would make the I-D much easier to
follow.  As it stands, you have to read between the lines and speculate.

Tom Petch


----- Original Message -----
From: "Lou Berger" 
To: "netmod WG" 
Cc: ;

Sent: Friday, September 01, 2017 10:02 PM

> All,
>
> This starts a two week working group last call on
> draft-ietf-netmod-revised-datastores-04.
>
> The working group last call ends on September 17.
> Please send your comments to the netmod mailing list.
>
> Positive comments, e.g., "I've reviewed this document and
> believe it is ready for publication", are welcome!
> This is useful and important, even from authors.
>
> Thank you,
> Netmod Chairs
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Sep 13 09:56:42 2017
Return-Path: 
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 6F0851321DF for ; Wed, 13 Sep 2017 09:56:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZs48VU1CzFq for ; Wed, 13 Sep 2017 09:56:38 -0700 (PDT)
Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (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 147251321B6 for ; Wed, 13 Sep 2017 09:56:38 -0700 (PDT)
Received: from cmgw3 (unknown [10.0.90.84]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id B4C2D14058C for ; Wed, 13 Sep 2017 10:56:36 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with  id 94wZ1w00o2SSUrH014wcqV; Wed, 13 Sep 2017 10:56:36 -0600
X-Authority-Analysis: v=2.2 cv=K/VSJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=2JCJgTwv5E4A:10 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=riEW31MorCH5E5iC0eoA:9 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: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=g933hkqaWeCdIFzm2OdA6ATgmhDhBtx7+IOVn+Qssxc=; b=x5S/weKNxdNgOLnND4oSn0a8XL +fH/PDA65pYnyAFqAXHng8Vf/miS3cYleAbtG9bbWzIG4nkUkHWnKEvMt+Dxjm6YeRCd13gvj3rvJ 1bPv1vtihmP3a43tu7v1DKoB3;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:40716 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dsAxl-0049nF-FO; Wed, 13 Sep 2017 10:56:33 -0600
To: "t.petch" , netmod WG 
Cc: netmod-chairs@ietf.org, draft-ietf-netmod-revised-datastores@ietf.org
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <00bd01d32caf$4eb28e60$4001a8c0@gateway.2wire.net>
From: Lou Berger 
Message-ID: <92a410a9-e479-2321-7420-4bd2d9dbed38@labn.net>
Date: Wed, 13 Sep 2017 12:56:31 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <00bd01d32caf$4eb28e60$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dsAxl-0049nF-FO
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:40716
X-Source-Auth: lberger@labn.net
X-Email-Count: 4
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 duplicaiton
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Sep 2017 16:56:40 -0000

> I believe that text such as this would make the I-D much easier to
> follow.  As it stands, you have to read between the lines and speculate.
Tom,

    Thank you for the comments.  Do you have a specific change in mind,
or could your propose text, that would address this?

Thanks,
Lou

On 9/13/2017 12:42 PM, t.petch wrote:
> I think that in one respect, perhaps the key respect, this I-D fails to
> state the obvious (or at least what is likely obvious to those who have
> been at this for a while:-).
>
> The problem that is hinted at but never explicitly stated is that data
> objects can appear both as configuration and as state, e.g. when learned
> by other means or at other times.  The original model of datastores
> required these data objects to be modelled twice, as configuration false
> and as configuration true, and since there could be many of them, and
> the rules of YANG require them to be in separate trees, this led to a
> twin-trees approach such as can be seen in RFC7277 or RFC7223.
>
> Amongst other problems, this separation of operational state from
> configuration in a
>    separate branch in the data model has been found to be operationally
>    complicated and impacts the readability of module
>    definitions.  The relationship between
>    the branches is not machine readable and filter expressions operating
>    on configuration and on related operational state are different.
>
> With revised datastores, there is a single data object to model both
> values  but this now appears in two datastores, one for the
> configuration value, one for the operational state value.
>
> Instead of two YANG data nodes there is one data node in two datastores,
> a more elegant and simpler solution to the problem.
>
>
> I believe that text such as this would make the I-D much easier to
> follow.  As it stands, you have to read between the lines and speculate.
>
> Tom Petch
>
>
> ----- Original Message -----
> From: "Lou Berger" 
> To: "netmod WG" 
> Cc: ;
> 
> Sent: Friday, September 01, 2017 10:02 PM
>
>> All,
>>
>> This starts a two week working group last call on
>> draft-ietf-netmod-revised-datastores-04.
>>
>> The working group last call ends on September 17.
>> Please send your comments to the netmod mailing list.
>>
>> Positive comments, e.g., "I've reviewed this document and
>> believe it is ready for publication", are welcome!
>> This is useful and important, even from authors.
>>
>> Thank you,
>> Netmod Chairs
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>


From nobody Wed Sep 13 10:08:32 2017
Return-Path: 
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 340CE13292D; Wed, 13 Sep 2017 10:08:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level: 
X-Spam-Status: No, score=-2.02 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 yR15wYeQhXnY; Wed, 13 Sep 2017 10:08:29 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0123.outbound.protection.outlook.com [104.47.34.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 195751252BA; Wed, 13 Sep 2017 10:08:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RTSeF5xf/29ilgkyV7G2WkszRQxXSA7tYE6TIXkMv9A=; b=bATcBK5a456PTGbsh+7rFEdDkLye1g/Ea8rNI1AES4us4y5xeNrshWbBlKR6Vx3qKdyNSPH4/Rt/v31Myb6wks5bpPj59WpJEW63rpLGgUF+f2NeUOEYF4nUwI9ZLoUmVoq9Ecoty47aPcu4/9nJYWHPvV/nDfin1QvRGnKfMUo=
Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB1906.namprd05.prod.outlook.com (10.162.215.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Wed, 13 Sep 2017 17:08:28 +0000
Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0035.010; Wed, 13 Sep 2017 17:08:27 +0000
From: Kent Watsen 
To: t.petch , "netmod@ietf.org" 
CC: "draft-ietf-netmod-syslog-model@ietf.org" 
Thread-Topic: [netmod] syslog-model-17 shepherd writeup issues -references
Thread-Index: AQHTLHc0HPi1rZXCNUadzeG98awlR6KyydeA
Date: Wed, 13 Sep 2017 17:08:27 +0000
Message-ID: <8CF097E4-CEB7-4C4E-AC7D-F7F896CD1BB7@juniper.net>
References: <49B4BE2F-6912-49BE-9E4A-830146309AB2@juniper.net> <019b01d32c76$fa7dfc40$4001a8c0@gateway.2wire.net>
In-Reply-To: <019b01d32c76$fa7dfc40$4001a8c0@gateway.2wire.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB1906; 6:Gku8RojjYQUV/FtP8mHRF75zU/pp4S1aSiRlrAwAIinuQaQw0Q6RrpjZxi/yUegsn9yLiOijLX0jDOtpZDYA+k2N15Du/HkfHWszzfQaK8zutYBqfBXYyGXVunFQaHkwpFfRAesEieiaNwe5hB6TwX02wcxn2ljdMhGZnIiMGnbK90BXMGDHYh4C7phWrS20oCkYL8b/0G8uMwhC03CvI9mr1LArJyRq/33eyhaMH/vImgDPjSqVtw4x6ICxZzbqEZaj84STl/6rFYd2jKLzeQEDRhjdkoyTC8jZSONlQqYXNp1LnUNuBz5rZWc1CDKIY5qvJk+x/ph8p+A9y2cAwQ==; 5:zNPxhJE3n58sweEx2ZNpzrH227uKsQhi/yo4tcg0EseOEj4SvC5KIDRmsdDtQD56/FG6RnrD3bmcCqZnY10OJJgUwO2lg3jXUOCNzKYjFxnHTpnOBNf7alW3FkQ7JS8guVPZcwyuYL/Nc2bZKJPROA==; 24:LX7rLlWyK/J7tyVFODzZZT7r4RCJQcDeUdwbtdEI4U5aoI+AY6lr4D0EBz9NnFKvrRR3anP66ntpz59SN5l5Fhl93hNUGdWYsEcfgvx9gyo=; 7:wqvVG3uQtPlToCH9wScsVfD6mOtJS3K5YzCd2DQ9ai5k8qI/QzSjEswVkq/JMeSzQZxZQS1w77ZDshbbY+UI+2c6t1w6WZeuPNycy/ldAYd1UP4YrAYNETE7CaeuPqYt4FGlcdMD4eObbNc9pIzNfbmoDmzqeQp8D9g3sYCCFhe4Ava3wO7VlX3duJghoWG6r+m8xuYATyKf8kxWMds5aS7U15pxex7jAAEbmj3AqiA=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 9e4d68f3-2da5-4702-a32f-08d4faca0d4a
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR05MB1906; 
x-ms-traffictypediagnostic: BLUPR05MB1906:
x-exchange-antispam-report-test: UriScan:(138986009662008);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123558100)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB1906; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB1906; 
x-forefront-prvs: 042957ACD7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(39860400002)(346002)(189002)(199003)(377454003)(13464003)(8676002)(81156014)(66066001)(6506006)(83716003)(189998001)(8936002)(106356001)(4001350100001)(105586002)(50986999)(7736002)(81166006)(83506001)(54356999)(76176999)(305945005)(33656002)(82746002)(230783001)(478600001)(3280700002)(6436002)(3846002)(6116002)(102836003)(3660700001)(2501003)(2906002)(2900100001)(2950100002)(6306002)(316002)(99286003)(8666007)(14454004)(4326008)(53936002)(6246003)(6512007)(36756003)(25786009)(966005)(6486002)(101416001)(97736004)(575784001)(86362001)(5660300001)(68736007)(77096006)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB1906; H:BLUPR05MB275.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: <2BA50B20A506E843A2371F184C30A094@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Sep 2017 17:08:27.8790 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB1906
Archived-At: 
Subject: Re: [netmod] syslog-model-17 shepherd writeup issues -references
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Sep 2017 17:08:31 -0000

SGkgVG9tLA0KDQpUaGFua3MuICBUaGUgZml4IEknbSBsb29raW5nIGZvciBpcyBmb3IgdGhlICdw
YXR0ZXJuLW1hdGNoJyBsZWFmDQp0byBoYXZlIGEgJ3JlZmVyZW5jZScgc3RhdGVtZW50IHRvIFN0
ZC0xMDAzLjEtMjAwOCwgYW5kIGZvciBTNC4xDQp0byBhbHNvIGxpc3QgU3RkLTEwMDMuMS0yMDA4
IGFzIGEgZHJhZnQtbGV2ZWwgcmVmZXJlbmNlLg0KDQpJIHdhcyBnb2luZyB0byBwb2ludCBvdXQg
dGhlIHR5cG8gInRoZSB0aGUiIGFzIHdlbGwsIGJ1dCBmaWd1cmVkDQp0aGF0IHRoZSBSRkMgRWRp
dG9yIHdvdWxkIGdldCBpdC4NCg0KSy4gLy8gc2hlcGhlcmQNCg0KDQotLQ0KDQpLZW50DQoNCllv
dSBmbGFnIFN0ZC0xMDAzLjEtMjAwOCBhcyBsaXN0ZWQgYXMgYSBub3JtYXRpdmUgcmVmZXJlbmNl
IGJ1dCBub3QgdXNlZA0KYW55d2hlcmUgaW4gdGhlIGRvY3VtZW50LiAgSW4gdGhlIERlc2NyaXB0
aW9ucywgYnV0IG5vdCBpbiB0aGUgcy40LjENCnJlZmVyZW5jZXMsIEkgc2VlDQoNClRoaXMgbGVh
ZiBkZXNjcmliZXMgYSBQb3NpeCAxMDAzLjIgcmVndWxhciBleHByZXNzaW9uIC4uLg0KDQp0d2lj
ZSwgd2hpY2ggbWF5LCBvciBtYXkgbm90LCByZWxhdGUgdG8gdGhpcyBpc3N1ZS4NCg0KQmFjayBp
biBKdWx5LCBjbHlkZSBzYWlkDQoiSSB3aWxsIGluc2VydCBhIG5vcm1hdGl2ZSByZWZlcmVuY2Ug
dG8gUE9TSVggMTAwMy4yIGluIHRoZSBuZXh0DQpyZXZpc2lvbiBvZiB0aGUgZHJhZnQuIg0KDQpJ
biBhIHNpbWlsYXIgdmVpbiwgUkZDNjk5MSBhcHBlYXJzIGluIGEgcmVmZXJlbmNlIHN0YXRlbWVu
dCBidXQgbm93aGVyZQ0KZWxzZS4NCg0KQXMgeW91IHBvaW50IG91dCwgUkZDNjAyMSBpcyByZWZl
cmVuY2VkIGJ1dCBpcyBvYnNvbGV0ZWQgYnkgUkZDNjk5MSBzbw0Kc2hvdWxkIG5vdCBiZS4NCg0K
QW5kIGluIGEgc2xpZ2h0bHkgZGlmZmVyZW50IHZlaW4sDQoNCiAgIHJlZ2lzdHJ5IFtSRkM3ODk1
XS8+LiAgRm9sbG93aW5nIHRoZSBmb3JtYXQgaW4gW1JGQzc5NTBdLz4sIHRoZSB0aGUNCg0KbG9v
a3Mgb2RkIGZvciBwbGFpbiB0ZXh0IGFuZCBmb3IgdGhlIHJlcGV0aXRpb24gb2YgJ3RoZScuLg0K
DQpUb20gUGV0Y2gNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIktlbnQg
V2F0c2VuIiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4NClRvOiA8bmV0bW9kQGlldGYub3JnPg0KQ2M6
IDxkcmFmdC1pZXRmLW5ldG1vZC1zeXNsb2ctbW9kZWxAaWV0Zi5vcmc+DQpTZW50OiBUdWVzZGF5
LCBTZXB0ZW1iZXIgMTIsIDIwMTcgMTA6NTAgUE0NClN1YmplY3Q6IFtuZXRtb2RdIHN5c2xvZy1t
b2RlbC0xNyBzaGVwaGVyZCB3cml0ZXVwIGlzc3Vlcw0KDQoNCj4gQ2x5ZGUsIGFsbCwNCj4NCj4g
SW4gcmV2aWV3aW5nIHRoZSBkcmFmdCBmb3IgU2hlcGhlcmQgd3JpdGV1cCwgSSBmb3VuZCB0aGUg
Zm9sbG93aW5nDQppc3N1ZXMgdGhhdCBJIHRoaW5rIG5lZWQgdG8gYmUgYWRkcmVzc2VkIGJlZm9y
ZSB0aGUgZG9jdW1lbnQgY2FuIGJlIHNlbnQNCnRvIEJlbm9pdCBmb3IgQUQgcmV2aWV3Og0KPg0K
Pg0KPiAxLiBJZG5pdHMgZm91bmQgdGhlIGZvbGxvd2luZzoNCj4NCj4gICBTdW1tYXJ5OiAzIGVy
cm9ycyAoKiopLCAwIGZsYXdzICh+fiksIDMgd2FybmluZ3MgKD09KSwgMSBjb21tZW50DQooLS0p
Lg0KPg0KPiAgICAgKiogVGhlcmUgYXJlIDIgaW5zdGFuY2VzIG9mIHRvbyBsb25nIGxpbmVzIGlu
IHRoZSBkb2N1bWVudCwgdGhlDQpsb25nZXN0IG9uZQ0KPiAgICAgICAgICBiZWluZyAzIGNoYXJh
Y3RlcnMgaW4gZXhjZXNzIG9mIDcyLg0KPg0KPiAgICAgKiogT2Jzb2xldGUgbm9ybWF0aXZlIHJl
ZmVyZW5jZTogUkZDIDYwMjEgKE9ic29sZXRlZCBieSBSRkMgNjk5MSkNCj4NCj4gICAgICoqIERv
d25yZWY6IE5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gYW4gSGlzdG9yaWMgUkZDOiBSRkMgNjU4Nw0K
Pg0KPiAgICAgPT0gTWlzc2luZyBSZWZlcmVuY2U6ICdSRkM1NDI1JyBpcyBtZW50aW9uZWQgb24g
bGluZSAzNTksIGJ1dCBub3QNCmRlZmluZWQNCj4gICAgICAgICAgJ1tSRkM1NDI1XSwgW1JGQzU0
MjZdLCBbUkZDNjU4N10sIGFuZCBbUkZDNTg0OF0uLi4uJw0KPg0KPiAgICAgID09IFVudXNlZCBS
ZWZlcmVuY2U6ICdSRkM3ODk1JyBpcyBkZWZpbmVkIG9uIGxpbmUgMTQwNiwgYnV0IG5vDQpleHBs
aWNpdA0KPiAgICAgICAgICAgcmVmZXJlbmNlIHdhcyBmb3VuZCBpbiB0aGUgdGV4dA0KPiAgICAg
ICAgICAgJ1tSRkM3ODk1XSAgQmllcm1hbiwgQS4sIEJqb3JrbHVuZCwgTS4sIGFuZCBLLiBXYXRz
ZW4sICJZQU5HDQpNb2R1bGUgTC4uLicNCj4NCj4gICAgICA9PSBVbnVzZWQgUmVmZXJlbmNlOiAn
UkZDNjI0MicgaXMgZGVmaW5lZCBvbiBsaW5lIDE0MzUsIGJ1dCBubw0KZXhwbGljaXQNCj4gICAg
ICAgICAgIHJlZmVyZW5jZSB3YXMgZm91bmQgaW4gdGhlIHRleHQNCj4gICAgICAgICAgICdbUkZD
NjI0Ml0gIFdhc3Nlcm1hbiwgTS4sICJVc2luZyB0aGUgTkVUQ09ORiBQcm90b2NvbCBvdmVyDQpT
ZWN1cmUgU2guLi4nDQo+DQo+DQo+IDIuIGByZmNzdHJpcGAgZXh0cmFjdGVkICJpZXRmLXN5c2xv
Zy55YW5nIiwgIHdoaWNoIGlzIG1pc3NpbmcNCiJAeXl5eS1tbS1kZCIgaW4gaXRzIG5hbWUNCj4N
Cj4gMy4gIG5laXRoZXIgYHB5YW5nYCBub3IgYHlhbmdsaW50YCBmb3VuZCBhbnkgZXJyb3JzIHdp
dGgNCmlldGYtc3lzbG9nLnlhbmcuICAgIHB5YW5nIHNheXMNCj4gICAgICAgZm9yIHZlbmRvci1z
eXNsb2ctdHlwZXMtZXhhbXBsZTogc3RhdGVtZW50ICJpZGVudGl0eSIgbXVzdCBoYXZlDQphICJk
ZXNjcmlwdGlvbiINCj4gICAgICAgc3Vic3RhdGVtZW50Lg0KPg0KPiA0LiB0ZXN0aW5nIHRoZSBl
eGFtcGxlcyBpbiB0aGUgZHJhZnQgYWdhaW5zdCB5YW5nbGludDoNCj4gICAgICAgLSBmb3IgYm90
aCBleGFtcGxlczogTWlzc2luZyBlbGVtZW50J3MgIm5hbWVzcGFjZSIuICgvY29uZmlnKQ0KPiAg
ICAgICAtIGp1c3QgcmVtb3ZpbmcgdGhlICI8Y29uZmlnPiIgZWxlbWVudCBlbnZlbG9wIHJlc29s
dmVzIHRoaXMNCmVycm9yLg0KPg0KPiA1LiB0aGUgMm5kIGV4YW1wbGUgdXNlcyBJUCBhZGRyZXNz
ICIyMDAxOmRiODphMGI6MTJmMDo6MSIsIGJ1dCB0aGlzDQpTSE9VTEQgYmUgYQ0KPiAgICAgIGRv
bWFpbiBuYW1lIChlLmcuLCBmb28uZXhhbXBsZS5jb20pDQo+DQo+IDYuIGluIHRoZSBZQU5HIG1v
ZHVsZSwgYW55d2hlcmUgeW91IGhhdmUgYW4gUkZDIGxpc3RlZCBpbiBhDQonZGVzY3JpcHRpb24n
IHN0YXRlbWVudCwNCj4gICAgICB0aGVyZSBzaG91bGQgYmUgYSAncmVmZXJlbmNlJyBzdGF0ZW1l
bnQgZm9yIHRoYXQgUkZDLg0KPg0KPiA3LiBpbiB0aGUgdHJlZSBkaWFncmFtLCB0aGUgbGVhZnJl
ZnMgbm8gbG9uZ2VyIGluZGljYXRlIHdoYXQgdGhleQ0KcG9pbnQgYXQsIHRoZXkgbm93IGFsbA0K
PiAgICAgIGp1c3Qgc2F5ICJsZWFmcmVmIi4gIERpZCB5b3UgZG8gdGhpcyBvbiBwdXJwb3NlLCBv
ciBhcmUgeW91IHVzaW5nDQphIGRpZmZlcmVudCB0cmVlDQo+ICAgICAgb3V0cHV0IGdlbmVyYXRv
ciBmcm9tIC0xNT8NCj4NCj4gOC4gUkZDNjUzNiBpcyBsaXN0ZWQgYXMgYSBub3JtYXRpdmUgcmVm
ZXJlbmNlLCBidXQgaXQgcHJvYmFibHkgc2hvdWxkDQpiZSBpbmZvcm1hdGl2ZS4NCj4NCj4gOS4g
U3RkLTEwMDMuMS0yMDA4IGlzIGxpc3RlZCBhcyBhIG5vcm1hdGl2ZSByZWZlcmVuY2UsIGJ1dCBp
dCBpcyBub3QNCnVzZWQgYW55d2hlcmUgaW4gdGhlIGRvY3VtZW50Lg0KPg0KPiAxMC4gUkZDNjI0
MiBpcyBsaXN0ZWQgYXMgYW4gaW5mb3JtYXRpdmUgcmVmZXJlbmNlLCBidXQgaXQgaXMgbm90IHVz
ZWQNCmFueXdoZXJlIGluIHRoZSBkb2N1bWVudC4NCj4NCj4gMTEuIHRoZSBkb2N1bWVudCBmYWls
cyB0byBkZWNsYXJlIGl0cyBub3JtYXRpdmUgcmVmZXJlbmNlcyB0bw0KaWV0Zi1rZXlzdG9yZSBh
bmQgaWV0Zi10bHMtY2xpZW50LXNlcnZlci4NCj4gICAgICAgICBOb3RlOiB5b3UgbWFudWFsbHkg
ZW50ZXJlZCB0aGUgIltSRkMgeXl5eV0sIGFuZCBbUkZDIHh4eHhdIg0KcmVmZXJlbmNlc+KApg0K
Pg0KPiAxMi4gIFRoZSBJQU5BIGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gc2VlbXMgYXN5bW1ldHJp
Yy4gIEVpdGhlciBwdXQNCmJvdGggcmVnaXN0cnkgaW5zZXJ0aW9ucyBpbnRvDQo+ICAgICAgICAg
c3Vic2VjdGlvbnMsIG9yIGtlZXAgdGhlbSBib3RoIGF0IHRoZSB0b3AtbGV2ZWzigKYNCj4NCj4g
MTMuIHJldmlld2luZyB0aGUgZmluYWwgZG9jdW1lbnQgYWdhaW5zdCBteSBvcmlnaW5hbCBZRCBy
ZXZpZXcsIEkgaGF2ZQ0KdGhlIGZvbGxvd2luZyByZXNwb25zZXMuICBMZXQncyBiZSBzdXJlIHRv
IGNsb3NlIG91dCB0aGVzZSBpdGVtcyBhcw0Kd2VsbC4gIFJlZjogaHR0cHM6Ly9tYWlsYXJjaGl2
ZS5pZXRmLm9yZy9hcmNoL21zZy9uZXRtb2QvMTBsbzQxVWQ0QTNaTjExDQpzLTBnT2ZDZThOU0UN
Cj4NCj4gMS4gb2sNCj4gMi4gYmV0dGVyDQo+IDMuIHNob3VsZCBiZTogcy90aGUgbWVzc2FnZS90
aGVzZSBtZXNzYWdlcy8gIFtSRkMgRWRpdG9yIG1pZ2h0J3ZlDQpjYXVnaHQgdGhpc10NCj4gNC4g
YmV0dGVyDQo+IDUuIHN0aWxsIGZlZWwgdGhlIHNhbWUgd2F5LCBidXQgbm8gYmlnZ2VlDQo+IDYu
IGJldHRlciwgYnV0IGZyb20gODE3NCwgeW91IHNob3VsZCBhZGQgdGhlIHBhcnQgIndoZW4sIGFu
ZCBvbmx5DQp3aGVuLCB0aGV5IGFwcGVhciBpbiBhbGwgY2FwaXRhbHMsIGFzIHNob3duIGhlcmUu
Ig0KPiA3LiBmaXhlZA0KPiA4LiBmaXhlZA0KPiA5LiB5b3UgZGlkIHdoYXQgSSBhc2tlZCwgYnV0
IHRoZSByZXN1bHQgc3RpbGwgaXNuJ3Qgc2F0aXNmeWluZy4uLg0KPiAxMC4gc29tZSBpbXByb3Zl
bWVudHMgbWFkZSBpbiB0aGlzIGFyZWEsIGJ1dCBteSBhc2sgd2Fzbid0IGFtb25nIHRoZW0NCj4g
MTEuIGJldHRlcg0KPiAxMi4gYmV0dGVyLCBidXQgSSB0aGluayB0aGUgNHRoIGxpbmUgc2hvdWxk
IGJlIGluZGVudGVkIHRvbywgcmlnaHQ/DQo+IDEzLiBiZXR0ZXIsIGJ1dCBJIHdpc2ggeW91IGNh
bGxlZCBTMS4zICJUcmVlIERpYWdyYW0gTm90YXRpb24iDQo+IDE0LiBmaXhlZA0KPiAxNS4gZml4
ZWQNCj4gMTYuIGZpeGVkDQo+IDE3LiBmaW5lDQo+IDE4LiBzdGlsbCBhIHdlaXJkIGxpbmUgYnJh
a2UgaGVyZS4gIHRyeSBwdXR0aW5nIHRoZSBxdW90ZWQgc3RyaW5nIG9uDQp0aGUgbmV4dCBsaW5l
Lg0KPiAxOS4gZml4ZWQNCj4gMjAuIGZpeGVkDQo+IDIxLiBub3QgZml4ZWQgKHJlOiB5YW5nLXNl
Y3VyaXR5LWd1aWRlbGluZXMpDQo+IDIyLiBmaW5lDQo+DQo+DQo+IFBTOiBwbGVhc2UgYWxzbyBi
ZSBzdXJlIHRvIGZvbGxvdy11cCB3aXRoIEJlbm9pdCBvbiBoaXMgQUQgcmV2aWV3Lg0KPg0KPiBU
aGFua3MsDQo+IEtlbnQgIC8vIHNoZXBoZXJkICYgeWFuZyBkb2N0b3INCj4NCj4NCj4NCj4gX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0bW9kIG1h
aWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9uZXRtb2QNCj4NCg0KDQoNCg==


From nobody Wed Sep 13 15:58:48 2017
Return-Path: 
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 ABDF3132025; Wed, 13 Sep 2017 15:58:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level: 
X-Spam-Status: No, score=-2.02 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 qzEqMhpd2fvs; Wed, 13 Sep 2017 15:58:44 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0115.outbound.protection.outlook.com [104.47.42.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17325124205; Wed, 13 Sep 2017 15:58:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=V4v6iTLSKV7LyjjC6Jo9IeuDgPW3Eufy3rU4k+MU3g0=; b=dkJ8CaN4jsIXV5JngNQqEsLprs0g6IdEVK9ds8NCW9n8MVfV8lF5HQfbzxpu5GS1TwkHiTK5Hdr8HpNThQSjej/2LqpRnfYQk2d0hPK/cxKf6IbTUlembjyabjogWVh95xhKdmlsbSJUN0ts4ujeAhkIKcu+BNI8tNlbTV30xEQ=
Received: from SN1PR05CA0002.namprd05.prod.outlook.com (10.163.68.140) by MWHPR05MB3616.namprd05.prod.outlook.com (10.174.251.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Wed, 13 Sep 2017 22:58:42 +0000
Received: from CO1NAM05FT040.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e50::204) by SN1PR05CA0002.outlook.office365.com (2a01:111:e400:5197::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5 via Frontend Transport; Wed, 13 Sep 2017 22:58:42 +0000
Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=juniper.net;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender)
Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by CO1NAM05FT040.mail.protection.outlook.com (10.152.96.153) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.20.56.11 via Frontend Transport; Wed, 13 Sep 2017 22:58:42 +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, 13 Sep 2017 15:58:35 -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 v8DMwYKM006051; Wed, 13 Sep 2017 15:58:34 -0700	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.15.2/8.15.2) with ESMTP id v8DMwX9k073880; Wed, 13 Sep 2017 18:58:33 -0400 (EDT)	(envelope-from phil@juniper.net)
Message-ID: <201709132258.v8DMwX9k073880@idle.juniper.net>
From: Phil Shafer 
To: Lou Berger 
CC: netmod WG , "netmod-chairs@ietf.org" , 
In-Reply-To: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <73878.1505343512.1@idle.juniper.net>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 13 Sep 2017 18:58:32 -0400
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(2980300002)(189002)(199003)(54356999)(77096006)(47776003)(50986999)(81156014)(6916009)(81166006)(2950100002)(8746002)(8936002)(8676002)(69596002)(356003)(7696004)(68736007)(229853002)(7126002)(5660300001)(106466001)(105596002)(966005)(189998001)(478600001)(8276002)(4326008)(305945005)(230783001)(53416004)(76506005)(575784001)(86362001)(316002)(6246003)(1076002)(97736004)(97756001)(2906002)(2810700001)(110136004)(23726003)(6306002)(50466002)(54906002)(53936002)(46406003); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB3616; H:p-emfe01a-sac.jnpr.net; FPR:;  SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; CO1NAM05FT040; 1:h4Z4K0K8ovQqrAymUp3fidcrTbXlvo1/oxE+T300PaZ7AT7bQ0FbAv1k/OofLud8H3REZFjB4VuA3AErb8Ib9GkWNFSujqPJ34Ei5c10vkRXTidp4vqD0xkDKtYH8N9x
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: d34c5222-04bd-4470-25e0-08d4fafafae4
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR05MB3616; 
X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3616; 3:gk9ebD4jbMoPj8E09NvruORQ0TzRuK6CPKKvzPK6QfVSz0O/HFw4T9+oPQVm/MV45wxIpMni8VlYwJevqnnB+INfjetWftgMabooEQ7c0cnRH1bbIMbQYaHYO+3qqhapneHnFgzbN9w2b0vYyhVp8s34S9Af8ulmSuaUjkfeiy+1M2zgAmh0HWwsrOhAhVoVgSC5MoQ6kA01tyPcNlfiGB+BPR0T4NM7YMsgkuwSdZDU72vxVO0nJvXaxaBrKFnZXSylvq0jl72fB34mpu/xVCDy5fPu+74r8KRcB/qOnz8vJVT4zRxJkwZoM5j2IBbrES3jaw5mpGR54Y7rlnF0oKjI0Jw74lP+MbtF6su+u4Y=; 25:8DjU9GrbUAEHagBYyDM1/fugtkt1fg3uoL4JMfKzjNh9v8L2trMChDiMdCdGNut+920Lstd/gSQc83qONdnOebIGEJkJkTGSGk117INT+xnhLse5E9IMsKzEWoNbT8zb0/5PSHQh1G/EOu8nQon3by/aQKTYgq9viNEG8TzNNBXwAtvjOpZxkMHf5rp2yyoRN/QucQ65VsnUa1A+qWYiCC48AURdjr2LtEY3qKUNMqDJiuiv2zLRcRxJWWubBtChUFC2Pb2XQT4yOr2yl5jyZLWVLmQynuCYKnKnkCzM4bmRNH3zojHDpvVtOudcTF7a/4F4D8ihceAX/TUwsN3F1Q==
X-MS-TrafficTypeDiagnostic: MWHPR05MB3616:
X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3616; 31:evVxXaQHwBSHUv0wee+EgeKCqpFd/zL6+qDBXb7uUlbPyMKckPQQ37R0TpWGaEeO2wBmpsjURuoCsEuQtvXB2pZ+s6P4+hAteS+FmWsY6nbKtVxIHZDvlcIN303CnHhL+DRHoNRwC9RQnKfEnqR2XuWBuR365Ay7F2rmueBW9oX0qoF+iw6/pdL6mwUPZ9kEI4iE7IKPwjRod9jhG/yi7A1GGDocxd5OGKGEceSk+ZE=; 20:jEsvbTnoLTlrK6Ku8h++vodFgg1AiArXiKSeZdsi9GMXt3pknklMlIbcGW1KQrj+KqrKRybCRukjIl7TQ7rlEgjk8yDNDjR0jrT+OSVu7m7sdD0cnLLvkcJNtDV3uNqkeSRws+WGA1mCVjVEddjkL9rr8xKb/vMyLLcbycEUWqqu/mtSe1d6bJjEVByO0QnXiM7GbRGsNbIprdyjCh2JOXOTg0aZmue1U8xvFhH599YErRRXqbec+YQ1dGDTLEoX5aoSmHoIgeG/B4mvbhVXTh5EqbycnXJ3jfNqukIPoDIVreh9TqZ3gp0v2NK0NEDxgyBBLHj1K0BapqRVe8yXCHVGhaIXm12cjaBYq6H3oI9OdBGj/pJJwpr4ShAdE+b94uyixGx+Cn7d3/yIdjfHnxXmiSTdOJ8oVtpetDlxK1Eg7ORt6NYN2jGLrZDuaJ8lAvyGSzRuhsHHZT/8BwvGWF7vs1oEf4IzGXfpTCdvFouv8K5ABapc+ZiHHZb+FCbH
X-Exchange-Antispam-Report-Test: UriScan:(254730959083279)(91638250987450);
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93003095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR05MB3616; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR05MB3616; 
X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3616; 4:fLfmH2/EloiLo5Nip4BiKdtiWmaxqljyWqUA+ZNQuqBVFzmZeno6p/BWTw/YguLrebwymUrJzsOypNyx5frFwo4Jd3EgZkTXufuBTfNZ7JwmSCGkNBrVWltIg+gkmqGydvn8V46E6OKdsOv2eeCqdtcNiKNaF9AFGq+w/rA5mKQT0wcYWSVTdSCgOCye2XkxDdKK4MWtakax/Lb8hXb0Lgf+g+qz72uWEPtZ9mbBewlk8XRrEbzCT8Y3V4nyVOfgmbbF0TbO0TCKg5ycZdo62njjNz1Q9ylgTug5AEMjlwl1adlNXAtaS81GL01M8dL8c1/P0OYjZ/QUE78KX0gGzQ==
X-Forefront-PRVS: 042957ACD7
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; MWHPR05MB3616; 23:F+04Ms2RGcW/Rl0UoTPB7Hs25DTuPRXVolsK2KpoY?= =?us-ascii?Q?6n7/1VKNWKzNnzLRkuXREYuIzGZHpBxsuCMzbuiUQbuwr56PMVECox6ZWmyC?= =?us-ascii?Q?BBvBGfczhaB1wEIgm+JZ7FlrjXZGQt5YLEDGjiJ4RZ2V+6e06T0BdzsoM5/7?= =?us-ascii?Q?yEV2lyyqsV4hlCsJpfV+Jx+jbhblmI6pYfTjSPJlN1sYz0o7fgwR8b5JjdfG?= =?us-ascii?Q?IGfJAaxDvZ1oVBB+Ca2cPpHhayWF2rxWFbSIEth3RGfJ6o6ubmHX/q1gv8vN?= =?us-ascii?Q?Gf9uy/gkfxabwsSSKIQHFpGGxyb7qLCtFgravGrrnKcwX5xQnhmw6S+Lm/O5?= =?us-ascii?Q?ebQ7FvObwAHVcKii5jlDyM9dTGKD2Kb+G7+T6thGbq3wI5SMNaw4E6XVMUMA?= =?us-ascii?Q?nU6LkYQ9UHAyMgkEAGAjOPjtZLEHGj2Q9NUyodb6NrDlC8LfZiLBgcz0AWm4?= =?us-ascii?Q?AHAS8wR8k3LMg/TnWr94rAfRQ/4WQqHGhTrdtQqA005HJf6C7B4Ss0afCn5D?= =?us-ascii?Q?i2t9ps6EKQAQ09yRvbP9EWPG9a2vrphYUAbmb0vZRuNxh2tsjH0/ktgGm0px?= =?us-ascii?Q?j+fSHxldzVTqn7BXhhh9sjsTeFZ/P7noa3mW+qV2BJ6ukFTynerBr5fsR2Ly?= =?us-ascii?Q?do/FvHm2h3nrC3btLMXAJRqg+H0IGJCZZ1Us4ElRQBOqNqKW0fUtqMd4HTcA?= =?us-ascii?Q?KezuwjkEcy/dlcbCecCwmINLBAuC6xmZFSxty9K4VFW6agKRRRJC7I3MlW/R?= =?us-ascii?Q?8RAbzHSK/6LzYK443Q/YwwDYiUoSQBhjngHVc7hy5tBjYE0yBYykIhc4fuRd?= =?us-ascii?Q?I4lPSqYLLLeqVxXIjBKLsqArwHmEX3smuC1CKiFKnnzCL+VlLEWuzqOcFcKl?= =?us-ascii?Q?HLPBJWHIogouz+3bRXUrl24k6W2bGEDl+qn6WBSvFkVfpy6On3EUfNYdslC1?= =?us-ascii?Q?bTi/NHNcZo+gQ0Qb/mV3Ing91xtsqrYQCxdPHC4IdHW6+w7XB05ybLHccw9z?= =?us-ascii?Q?C3NChz7OYDKQMzpHb+wRzRl6rCDxEO620OrrvXpWNnj8yipzSEI3/5PrCFXm?= =?us-ascii?Q?Ox/P1QH6W4QvVC5m+iPExO5XHfIclBKjg4xpUknCiwZXcT5aK51HM/O5kid6?= =?us-ascii?Q?JdYs3vl7+/tKPK1O9NhjgWsb7VKrDO0boqqF523uJi1SixO0D9pnmN18DAcz?= =?us-ascii?Q?qsBCf/vFhbYEUeJ86AztBVD/76PIpBk7ZqM?=
X-Microsoft-Exchange-Diagnostics: 1; MWHPR05MB3616; 6:h9x8TW8zuM0IcqEIaPNGWkCgHTYJ6wVDausTpZwkHFKfOGXozYQh86sU9NTE3PieTE5QXAOZMlVHgmdtAzSnCcKSg4TTRAA6hxCcLFHk121EEtzv6cbDyamBVeizQM2R83K+XvqAPra3E5akDacTfGrl9BCeE1bqmWXw3CFTw6NSwIOREAmJtkX20ieEPl/lisahiojnAuyXBA4JHDqoWc6Y9EhEDeFEW6/eGDjw0tmMEOnFuxr8epvX+Li7hHBRgwHQL7T16SqHHP1djUNtP025UhE3Yvrm4+rGI7uRj0h3qa38joIyBrqSYXvhWo6JYFmVmXA5pm6uyOUWA2nl3g==; 5:xHsogxKsKuka24mE+G50iTtihNJ0tg3obVFFOZcRwCv6DkPpxt575HM+sid93lAmnUBEMNUBspRFpyBFt2VDHbzCahlbfsSZ/LLY0SJJeRrQo+1bdHM37rxz68rMvB36rj9gXGBPdKtGwVz4rNV2Tg==; 24:uOAfEoPk0sgT1UlPt4HxoYuLvob45cF8Nf8nvi6FohzDUk7DFpcF3cXODjGM9b7rMPuZMpeM5ZKn08pxElMVp+x3h93+OyNEWFSRzvi0sk0=; 7:kqe7emRBL5Tp3tLAQ0GZoe9OxXvqXpsws4i3BhC7IvhaFsKUbzW7eURLIohUTWJYmqftnDRxiGo6uKbOJ2l5Jq039yohmiNT86/25kkceIZfcDgAm4aoEjrwMqeBbmeE+rkt/8De3Fj1gUV+nshl1RLvuhKf9v30j4YkG9QV+nbqQq+GFUksZsIA6pJfb94s1H8acg0A02NzxY2YQdd8qHzSfOZQMGLB92acIhJzmI0=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Sep 2017 22:58:42.2231 (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.12];  Helo=[p-emfe01a-sac.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB3616
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Sep 2017 22:58:46 -0000

Lou Berger writes:
>This starts a two week working group last call on
>draft-ietf-netmod-revised-datastores-04.

I have reviewed this document and have several minor recommendations.
In addition, there were comments at the mic at the last IETF during
the NETCONF WG meeting regarding the draft-dsdt-nmda-netconf-00.txt
draft that refer to the architecture rather than the NETCONF mapping
of that architecture, specifically on validation, and restraints on
templating mechanisms.  The video is:

https://www.youtube.com/watch?v=3DwTlyEqTSuqo&feature=3Dyoutu.be&list=3DPL=
C86T-6ZTP5jdbiwi5ggLNnwLn1-r0M4h&t=3D4726

I'm submitting these comments as a "diff" against the text source
of the draft.   Hopefully this is clear and precise.

Thanks,
 Phil



diff --git a/draft-ietf-netmod-revised-datastores.org b/draft-ietf-netmod-=
revised-datastores.org
index b859760..be3b3b8 100644
--- a/draft-ietf-netmod-revised-datastores.org
+++ b/draft-ietf-netmod-revised-datastores.org
@@ -210,8 +210,8 @@ Some observations:
 - Operational state has not been defined as a datastore although there
   were proposals in the past to introduce an operational state
   datastore.
-- The NETCONF  operation returns the content of the running
-  configuration datastore together with the operational state.  It is
+- The NETCONF  operation returns the content of 
+  together with the operational state.  It is
   therefore necessary that "config false" data is in a different branch
   than the "config true" data if the operational state can have a
   different lifetime compared to configuration or if
@@ -318,6 +318,26 @@ If a device does not have a distinct  and no=
n-volatile is
 available, the device will typically use that non-volatile storage to
 allow  to persist across reboots.

+*** Validation
+
+The process of "validation" examines a datastore to ensure the
+resulting configuration data will satisfy all data models constraints
+given in ^YANG^ section 8.1.   All constraints in all supported
+data models must be satisfied for the data to be considered "valid".
+
+Validation will examine the data after any locally-defined templating
+mechanism is performed and any inactive configuration is removed.
+
+While the operation of any specific templating mechanism is outside
+the scope of this document, such mechanisms are constrained by the
+rules of any data models, and cannot break the constraints given in
+^YANG^.
+
+The implication of the existence of templating mechanisms is that
+ is now explicitly allowed to be invalid, since the
+templating mechanism may be supplying additional data that satisfies
+constraints that may be satisfied by  itself.
+
 ** The Intended Configuration Datastore ()

 The intended configuration datastore () is a read-only
@@ -422,6 +442,7 @@ error.
  does not persist across reboots.

 *** Remnant Configuration @remnant@
+
 Changes to configuration may take time to percolate through to
 .  During this period,  may contain
 nodes for both the previous and current configuration, as closely as
@@ -709,12 +730,14 @@ This example defines a dynamic configuration datasto=
re called
 "ephemeral", which is loosely modeled after the work done in the I2RS
 working group.

-  1. Name            : ephemeral
-  2. YANG modules    : all (default)
-  3. YANG data nodes : all "config true" data nodes
-  4. How applied     : automatic
-  5. Protocols       : NC/RC (default)
-  6. YANG Module     : (see below)
+| Name            | Value                        |
+|-----------------+------------------------------|
+| Name            | ephemeral                    |
+| YANG modules    | all (default)                |
+| YANG data nodes | all "config true" data nodes |
+| How applied     | automatic                    |
+| Protocols       | NC/RC (default)              |
+| YANG Module     | (see below)                  |

 !! include-figure example-ds-ephemeral.yang


From nobody Thu Sep 14 04:09:39 2017
Return-Path: 
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 123891321A7; Thu, 14 Sep 2017 04:09:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 ghcqBbh3glu3; Thu, 14 Sep 2017 04:09:36 -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 3A430120724; Thu, 14 Sep 2017 04:09:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6328; q=dns/txt; s=iport; t=1505387375; x=1506596975; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=GovQD+BVTKJQxeKtkS0WR87SVYqVfUPUMlp+ksZaM+E=; b=hgSzx3O43PiGJoVbzvuioVJ79XDSTGyfcb7tYD1WafCAtcg+HVMUg4O1 R8KkOIbAnLIqnbxprnRDql6PCVCxMUVYQWM9vaKcG7e9ykOMWATkxryew 2SmIhxwsxqrXHBuZgTNzDI4RNpnxRefmphMkOw6towRIGnzFXBWC9RJim U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ChAQAxYrpZ/xbLJq1TCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQ+bieDd4sUjwKBegkilUFmghIKGAuESk8ChGAWAQIBAQEBAQE?= =?us-ascii?q?BayiFGAEBAQEDAQEhDwEFNgsMBAsOAwQBAQECAiYCAicoCAYBDAYCAQGKLhCsH?= =?us-ascii?q?4InizUBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgQ6CHYNSgWMrC4JygkCCDhSDKYJ?= =?us-ascii?q?gBZEpj1CHWox4ghOFaINahyGNW4QcgzmBOSYHKoENMiEIHBVKhRkcgWg/NgGJA?= =?us-ascii?q?QEBAQ?=
X-IronPort-AV: E=Sophos;i="5.42,392,1500940800"; d="scan'208";a="697182907"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Sep 2017 11:09:30 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8EB9UOk030675; Thu, 14 Sep 2017 11:09:30 GMT
To: Kent Watsen , "t.petch" , "netmod@ietf.org" 
Cc: "draft-ietf-netmod-syslog-model@ietf.org" 
References: <49B4BE2F-6912-49BE-9E4A-830146309AB2@juniper.net> <019b01d32c76$fa7dfc40$4001a8c0@gateway.2wire.net> <8CF097E4-CEB7-4C4E-AC7D-F7F896CD1BB7@juniper.net>
From: Robert Wilton 
Message-ID: <516d3881-4fbb-fad0-5413-404f644ea63b@cisco.com>
Date: Thu, 14 Sep 2017 12:09:30 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <8CF097E4-CEB7-4C4E-AC7D-F7F896CD1BB7@juniper.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] syslog-model-17 shepherd writeup issues -references
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Sep 2017 11:09:38 -0000

Hi Kent, Clyde,

Does the "pattern-match" leaf need to be explicitly pulled out in 
security considerations?  Allowing a client to provide an arbitrary 
regex could potentially cause a regex engine to overflow its stack and 
crash.

An example of an regex overflow is described here: 
http://www.regular-expressions.info/catastrophic.html

Thanks,
Rob


On 13/09/2017 18:08, Kent Watsen wrote:
> Hi Tom,
>
> Thanks.  The fix I'm looking for is for the 'pattern-match' leaf
> to have a 'reference' statement to Std-1003.1-2008, and for S4.1
> to also list Std-1003.1-2008 as a draft-level reference.
>
> I was going to point out the typo "the the" as well, but figured
> that the RFC Editor would get it.
>
> K. // shepherd
>
>
> --
>
> Kent
>
> You flag Std-1003.1-2008 as listed as a normative reference but not used
> anywhere in the document.  In the Descriptions, but not in the s.4.1
> references, I see
>
> This leaf describes a Posix 1003.2 regular expression ...
>
> twice, which may, or may not, relate to this issue.
>
> Back in July, clyde said
> "I will insert a normative reference to POSIX 1003.2 in the next
> revision of the draft."
>
> In a similar vein, RFC6991 appears in a reference statement but nowhere
> else.
>
> As you point out, RFC6021 is referenced but is obsoleted by RFC6991 so
> should not be.
>
> And in a slightly different vein,
>
>     registry [RFC7895]/>.  Following the format in [RFC7950]/>, the the
>
> looks odd for plain text and for the repetition of 'the'..
>
> Tom Petch
>
> ----- Original Message -----
> From: "Kent Watsen" 
> To: 
> Cc: 
> Sent: Tuesday, September 12, 2017 10:50 PM
> Subject: [netmod] syslog-model-17 shepherd writeup issues
>
>
>> Clyde, all,
>>
>> In reviewing the draft for Shepherd writeup, I found the following
> issues that I think need to be addressed before the document can be sent
> to Benoit for AD review:
>>
>> 1. Idnits found the following:
>>
>>    Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment
> (--).
>>      ** There are 2 instances of too long lines in the document, the
> longest one
>>           being 3 characters in excess of 72.
>>
>>      ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991)
>>
>>      ** Downref: Normative reference to an Historic RFC: RFC 6587
>>
>>      == Missing Reference: 'RFC5425' is mentioned on line 359, but not
> defined
>>           '[RFC5425], [RFC5426], [RFC6587], and [RFC5848]....'
>>
>>       == Unused Reference: 'RFC7895' is defined on line 1406, but no
> explicit
>>            reference was found in the text
>>            '[RFC7895]  Bierman, A., Bjorklund, M., and K. Watsen, "YANG
> Module L...'
>>       == Unused Reference: 'RFC6242' is defined on line 1435, but no
> explicit
>>            reference was found in the text
>>            '[RFC6242]  Wasserman, M., "Using the NETCONF Protocol over
> Secure Sh...'
>>
>> 2. `rfcstrip` extracted "ietf-syslog.yang",  which is missing
> "@yyyy-mm-dd" in its name
>> 3.  neither `pyang` nor `yanglint` found any errors with
> ietf-syslog.yang.    pyang says
>>        for vendor-syslog-types-example: statement "identity" must have
> a "description"
>>        substatement.
>>
>> 4. testing the examples in the draft against yanglint:
>>        - for both examples: Missing element's "namespace". (/config)
>>        - just removing the "" element envelop resolves this
> error.
>> 5. the 2nd example uses IP address "2001:db8:a0b:12f0::1", but this
> SHOULD be a
>>       domain name (e.g., foo.example.com)
>>
>> 6. in the YANG module, anywhere you have an RFC listed in a
> 'description' statement,
>>       there should be a 'reference' statement for that RFC.
>>
>> 7. in the tree diagram, the leafrefs no longer indicate what they
> point at, they now all
>>       just say "leafref".  Did you do this on purpose, or are you using
> a different tree
>>       output generator from -15?
>>
>> 8. RFC6536 is listed as a normative reference, but it probably should
> be informative.
>> 9. Std-1003.1-2008 is listed as a normative reference, but it is not
> used anywhere in the document.
>> 10. RFC6242 is listed as an informative reference, but it is not used
> anywhere in the document.
>> 11. the document fails to declare its normative references to
> ietf-keystore and ietf-tls-client-server.
>>          Note: you manually entered the "[RFC yyyy], and [RFC xxxx]"
> references…
>> 12.  The IANA considerations section seems asymmetric.  Either put
> both registry insertions into
>>          subsections, or keep them both at the top-level…
>>
>> 13. reviewing the final document against my original YD review, I have
> the following responses.  Let's be sure to close out these items as
> well.  Ref: https://mailarchive.ietf.org/arch/msg/netmod/10lo41Ud4A3ZN11
> s-0gOfCe8NSE
>> 1. ok
>> 2. better
>> 3. should be: s/the message/these messages/  [RFC Editor might've
> caught this]
>> 4. better
>> 5. still feel the same way, but no biggee
>> 6. better, but from 8174, you should add the part "when, and only
> when, they appear in all capitals, as shown here."
>> 7. fixed
>> 8. fixed
>> 9. you did what I asked, but the result still isn't satisfying...
>> 10. some improvements made in this area, but my ask wasn't among them
>> 11. better
>> 12. better, but I think the 4th line should be indented too, right?
>> 13. better, but I wish you called S1.3 "Tree Diagram Notation"
>> 14. fixed
>> 15. fixed
>> 16. fixed
>> 17. fine
>> 18. still a weird line brake here.  try putting the quoted string on
> the next line.
>> 19. fixed
>> 20. fixed
>> 21. not fixed (re: yang-security-guidelines)
>> 22. fine
>>
>>
>> PS: please also be sure to follow-up with Benoit on his AD review.
>>
>> Thanks,
>> Kent  // shepherd & yang doctor
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Thu Sep 14 06:37:52 2017
Return-Path: 
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 22FED132D49 for ; Thu, 14 Sep 2017 06:37:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 K0_RiqKKaIKe for ; Thu, 14 Sep 2017 06:37:49 -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 345E31321CB for ; Thu, 14 Sep 2017 06:37:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1094; q=dns/txt; s=iport; t=1505396269; x=1506605869; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=tzn0WQKDZlhR4EumOSbcv9kLk5SGtkeCgmllIhewiwo=; b=JThwvdWxAl8Q0ULcawc8M0m4um+9sjfOYWkbP1v98y8iJNe40f//1I8M KXj3VMA86bBnd4txSkKFhrixgsGsthM7PWHvOMnq1wmI+T3qQo6PHNy/d 6U0yetXuilpBdhNS2wP7oQIPnIDlm6z8CKHvJ2ZUjped5n8QnsCjEw58g s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CQAQCDhbpZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD5uJ4N3ixSQRwkimDoKGAuESk8ChGcUAQIBAQEBAQEBayiFGQE?= =?us-ascii?q?BAQMBASEPAQU2GwsOCgICJgICJzAGAQwGAgEBii4QrAWCJ4s0AQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARoFgQ6CHYNSgWMrC4JyiAuCYAWhAodajHiCE4Vog1qHIY1ch1W?= =?us-ascii?q?BOTYhgQ0yIQgcFUqHHT82iG0BAQE?=
X-IronPort-AV: E=Sophos;i="5.42,393,1500940800"; d="scan'208";a="697186385"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Sep 2017 13:37:45 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8EDbiTZ013741; Thu, 14 Sep 2017 13:37:45 GMT
To: Kent Watsen , "netmod@ietf.org" , Lou Berger 
References: <14299503-509D-43BE-A938-0B7B88C3B249@juniper.net>
From: Robert Wilton 
Message-ID: <36ba3d4b-1ae1-0666-12cf-db41e172924b@cisco.com>
Date: Thu, 14 Sep 2017 14:37:44 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <14299503-509D-43BE-A938-0B7B88C3B249@juniper.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Sep 2017 13:37:51 -0000

Hi Kent & Lou,

When do you think that it will be possible to start the adoption process 
on these drafts?

I think that the first two at least would seem to be ready for 
adoption.  For the 3rd draft, there still seems to be an open question 
of what to do with the old state tree, but presumably that could be 
solved after the draft has been adopted?

Thanks,
Rob


On 30/08/2017 00:46, Kent Watsen wrote:
> Hey folks,
>
> As discussed at the last meeting, we are heading to revising existing RFCs to align them with NMDA.  The first batch have been published as individual drafts:
>
> 1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00
> 2. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00
> 3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00
>
> Please take a look (comments welcome!) and stay tuned for the related adoption calls.
>
> Thanks,
> Kent (and Lou)
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


From nobody Thu Sep 14 06:53:43 2017
Return-Path: 
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 1542B132A1A for ; Thu, 14 Sep 2017 06:53:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level: 
X-Spam-Status: No, score=-4.701 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=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isfpwJOHD_ju for ; Thu, 14 Sep 2017 06:53:39 -0700 (PDT)
Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) (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 A75C71326DF for ; Thu, 14 Sep 2017 06:53:39 -0700 (PDT)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id E62E72199A2 for ; Thu, 14 Sep 2017 07:49:54 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id 9Rpq1w00W2SSUrH01RptF3; Thu, 14 Sep 2017 07:49:54 -0600
X-Authority-Analysis: v=2.2 cv=K4VSJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=2JCJgTwv5E4A:10 a=48vgC7mUAAAA:8 a=t9dDAhW7IYLHEqmpU88A:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: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=Mu2MFYMmrFUgTP85RfiuP8TlbJ/RxPXsOprx8nFnZuQ=; b=XpL6lr8FYG/F+HJMSt3Nccu6rX TvKIsVwZbtzutPLTiUkg1kJkGTCevsQXjPoef1UeBa8Cg/Ee53lV3h6G2IlSyuxUpydn5l++DDcl+ s4VVrcL/GO7GzF+KIY1FohllF;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:52572 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dsUWc-000dzh-OZ; Thu, 14 Sep 2017 07:49:50 -0600
To: Robert Wilton , Kent Watsen , "netmod@ietf.org" 
References: <14299503-509D-43BE-A938-0B7B88C3B249@juniper.net> <36ba3d4b-1ae1-0666-12cf-db41e172924b@cisco.com>
From: Lou Berger 
Message-ID: <75739d75-da96-b340-2403-d0949ac54ed7@labn.net>
Date: Thu, 14 Sep 2017 09:49:48 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <36ba3d4b-1ae1-0666-12cf-db41e172924b@cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dsUWc-000dzh-OZ
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:52572
X-Source-Auth: lberger@labn.net
X-Email-Count: 3
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Sep 2017 13:53:42 -0000

Hi Rob,

On 9/14/2017 9:37 AM, Robert Wilton wrote:
> Hi Kent & Lou,
>
> When do you think that it will be possible to start the adoption process 
> on these drafts?
>
> I think that the first two at least would seem to be ready for 
> adoption.  For the 3rd draft, there still seems to be an open question 
> of what to do with the old state tree, but presumably that could be 
> solved after the draft has been adopted?
I see an update for the third was published yesterday
(https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-02)  that
clarifies the intent is to replace the current modules, and presumably
obsolete 8022.  And now that this intended direction is clear in the
draft we could poll it.

I think this still doesn't address if we need to indicate that the
rfc8022 defined modules are deprecated by some other mechanisms than
just replacing the RFC, e.g., by updating the old modules with all nodes
marked as deprecated.  I think you're right that this could be done post
adoption.  Of course others are free to disagree.

I check with Kent and see what he thinks.

Thanks,
Lou

>
> Thanks,
> Rob
>
>
> On 30/08/2017 00:46, Kent Watsen wrote:
>> Hey folks,
>>
>> As discussed at the last meeting, we are heading to revising existing RFCs to align them with NMDA.  The first batch have been published as individual drafts:
>>
>> 1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00
>> 2. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00
>> 3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00
>>
>> Please take a look (comments welcome!) and stay tuned for the related adoption calls.
>>
>> Thanks,
>> Kent (and Lou)
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>> .
>>
>


From nobody Thu Sep 14 07:04:27 2017
Return-Path: 
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 6C45E132355 for ; Thu, 14 Sep 2017 07:04:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.111
X-Spam-Level: 
X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ericsson.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 0mqqEmFPnDqY for ; Thu, 14 Sep 2017 07:04:23 -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 85BAA132335 for ; Thu, 14 Sep 2017 07:04:23 -0700 (PDT)
X-AuditID: c1b4fb30-66bff70000007145-ed-59ba8c6508b6
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D7.ED.28997.56C8AB95; Thu, 14 Sep 2017 16:04:21 +0200 (CEST)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.24) with Microsoft SMTP Server (TLS) id 14.3.352.0; Thu, 14 Sep 2017 16:04:20 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=q36J//X3V2SgP1Q9qbfXa8oOY2gCqSfWibXS0+1gEXU=; b=OIUWTBUtOUJVZQDe9ri/mmv6Np4jd96VyOqjX/xfpUphbaeH/WABxp982l0qQcvLg7bRDU+lXjbVgI6i879fKgYO+wFr1CH63lnK7bf8Yf8JnWmYPR3G/4QKSJONRnMuejhjVzKDpKVnb9ifzaH3sI6kgt1NPgtJWcs2VsN11rQ=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
Received: from [159.107.197.117] (91.82.100.59) by AM4PR07MB3425.eurprd07.prod.outlook.com (2603:10a6:205:b::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Thu, 14 Sep 2017 14:04:19 +0000
From: Balazs Lengyel 
To: "netmod@ietf.org" 
Message-ID: <9ec6b2e4-36a7-87e6-59fa-828855235835@ericsson.com>
Date: Thu, 14 Sep 2017 16:04:14 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [91.82.100.59]
X-ClientProxiedBy: HE1PR02CA0096.eurprd02.prod.outlook.com (2603:10a6:7:29::25) To AM4PR07MB3425.eurprd07.prod.outlook.com (2603:10a6:205:b::10)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 38d64f76-48fa-4a99-99fb-08d4fb797e90
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM4PR07MB3425; 
X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3425; 3:uJh6vTU7rTl3AHloHLUU8I9gL8ErOAWKCbl729GvboXu7KyhGkqX9vbMUDrVMe2RWPjm3Y/Qx/igiq9tUJnv4bChlSocbe2AHREhT6lKmcA0iAyUXpkTvWUf/hZdSdenJ0HiAFvbUlG1e2omhAMTfOOkFF1p9eFTwK2xznCHeMoeWzvQpqy7CdyPge+hrMnk1XYQp/LHnmaHYVDb2WXxsEi8fTZEBLI3pCYhkqS7JPjmUVXr2pDy4k4SbzAc4Flr; 25:SJHXPtrtj7pUDqAOFDUsMfksNpHjsicB+QV2fMYUvHDU1jKskGGLA+ltExNwuKtEAusHJwi0JArPHBDjcKtsU5guPxqoKufAfYNZbPig1OWSnDLivLjs1uYNnOeW3WHxlTL8gZy3IAWvi91OT+bGs05JoO4/xCJosNDyvsd34Fhc/YriL7bs3eDeKIHeXmWxGRclh/Wzl0hnhYQKlGmi+cQmUbyXMlybZtuAL0XlI+wfZyEkEK9fgKtZqB6XTx4wJ83D2VqCjt/bUFpVTTMGIY1DLcv3+u2F+KO+KGlm0q3pNWe+f5U/xrfDS6Gg5PQBfj00wAaP2HmxAbp6cnFEpg==; 31:fa8ju9ndka/1i+VJ5H+9lZXpQUFJnCdT0q3k+PfCiMsaBrPItDW4u7I8Ug1CMV7l2voOYgdrInEo7gwB4PSAO08y19m1POwIyr1XIYVc7KtMMvd++Ge86CUMtCVEXGMSpee3v8NopxO3Xng08ETtRLKTMyXY3ymJbzGM1yXxUmOX4XE/cZITe1ZvR11k9ri3R9Lh9olYGPhYaOIeyyDve+TjwZxl8YxUHGENIUgB2hE=
X-MS-TrafficTypeDiagnostic: AM4PR07MB3425:
X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3425; 20:JjqOzsyDw0MLKKMQmBIQbVc4/eEkHGZyf8iR9RX1fuRemS1XsryrxRiaJSSnMD1pCKYiPtXMPM2AX2AQS6yJN5H5ZVnZTxtcVZRXaepBAdgfphMMKhkVu/PRxeNUCUXEcRE7Ozfmys6zjLb+ZJQZ/WbZhhzYWl4JOChm8uATvQZC7PnqVtg56JXPW8D/qmfZHLIOU31g9wg6V+iI5z5HNlxdwlOuMTTVPtYfQu3b0EUibrMBSh3GEeaUiCTzDA+DSvXIGLpszcmfrcxcYrg7BtRSiSzpuU+cbhbn86miDUYUPnBiCN0oi137ZHZunnlFCto8ERy4fMV+jHakyZJelVOxU5xTAObCv6loQgjVKfgne4VXyQT7+CqUStiV3109C0BN3jU3aPp8EokCgGHc4No/0in7v+rhMDJXj4vDb4721L8VQ4bjUvGFsLWDbEqHQyF+72sviGuoiPSna4LT1JlQ83jLFL61BrwTeu2G1Upu6eA9YowXFv9KINfvmhPk; 4:h9Okt/AM/Yb/XrkL4yyiQ9fnMPgoIau0fu04EFjLqJ9nciGiOAlhauRbBgQfq9iM97BaAFgdhdhnlxIh4DGVVHNmn51h3b8NDzEhdFvL7loW0OcwwGVt13KquwE67PTEQmYWdm/Q/vNOb0jZMOM+mxF/erOeL7YKoNQ4YwP4FQKZH1c256eT/UEnAQ1gnV/QVyaK+GMAHcdQEL92F6mdrooR6/1Bh/PIxARTsrzDXhaJYDjy+mJnHfEN3mmNDAUCzXCp7yN+y+q6QSDcoWBLae7PLiVBZlU/ZP2zQMueS5kezwy4SdDxm31flZIA5TRklRUzDFqlL8NdnO0qAOra2g==
X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(158342451672863);
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR07MB3425; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR07MB3425; 
X-Forefront-PRVS: 0430FA5CB7
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(7370300001)(6009001)(6049001)(376002)(346002)(51444003)(189002)(252514010)(199003)(64126003)(3846002)(25786009)(83506001)(2906002)(6116002)(5640700003)(31696002)(23676002)(110136004)(86362001)(6486002)(6916009)(6666003)(53936002)(50466002)(68736007)(230700001)(65956001)(66066001)(31686004)(5660300001)(7736002)(47776003)(33646002)(7350300001)(65826007)(2351001)(305945005)(81156014)(81166006)(106356001)(105586002)(54356999)(478600001)(49976008)(2501003)(101416001)(561944003)(36756003)(4001350100001)(316002)(65806001)(50986999)(16526017)(16576012)(97736004)(189998001)(1730700003)(8676002)(78286006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB3425; H:[159.107.197.117]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTRQUjA3TUIzNDI1OzIzOnVLWFJZSjF0TGRLbVhjUTVab0pNSit2YU9W?= =?utf-8?B?NXh4dnRUOXdaMTJ4Y3kyVGk3ZHNDNjgzM2VJaG1qVXl0OUJ2WVNlditZVEVz?= =?utf-8?B?VXRJUVJtQlZOOUJVR1NyL1h2QTdjOVdnTnBFMlFobEc4cnZGemJnWjBVOW03?= =?utf-8?B?ZHp5TXNnUVAwVCsyNFhPUkUwNUgxSWZWRWxwaEE0Wlp5bHNXWHc4NVBLK1Nu?= =?utf-8?B?dlF6UXVjYmZGNmlrSXRXcXRVa1BCNlFsR014ZUwydWdrRXdYTHVydEpZbW55?= =?utf-8?B?SklZRlcxS2ZyQ0JIVWpCbTVPQ0oyZURxejdXandWK0V5L0FuUEl1ZlU1WUpw?= =?utf-8?B?ZlU5K1psd2FNcU9MV2J0Sll0QzU2UERPZjRPUXMyRU96Z1JUT1NiSk9MRUVu?= =?utf-8?B?WUtpY3h0MnY0YWRWYWNMbk4vRm5qWjFlbE5kZTRNem1JcTluZkcrdFpORHR3?= =?utf-8?B?SGNVZXhwWmo2cEljVEVKSlpVenlITDhNMkMrZU9HNzdVWG1SWTRlTHljdkR1?= =?utf-8?B?QkJmMURLbmdQY0gzOS9xNG5mVnlxNVJwbjdNQWlCbGhiTndjYUlWaXEwams1?= =?utf-8?B?VnhNbWRIWVV6SWJuZmRRZVFheEdzSHUva0xNbERIR0xCOHhHV3ZMWmtRQmhq?= =?utf-8?B?OFhIRXFWL1VxRWxNb0JLbVNPWGtVWWIwYTk3TlBQWHF3Rno4d2U4cXl0SGJ3?= =?utf-8?B?bWJnZ0Z0YlRYdUNDejhSbWdndHBudXpxT3BlNG16SWRCa0FOSWZCUkJMYmdm?= =?utf-8?B?c1prdDJIa2tOYlo2bDVua20rZG1yaWhqNFEvSGIzMWlFa1gzanpEODcyZzdp?= =?utf-8?B?WVhtYmJyWTg1YTZSdUoxWDVUK2MxMVNPWkdLaG1nZG8zZ20wVnVRaDBjdFNj?= =?utf-8?B?ZEZEYTZxa2ZibFo0eWpYdDFBQzlRVDZsL2xGWkRtTytRMXd1d1VLSVpEV0Rr?= =?utf-8?B?ZTBDeDY4S2dZUjgvMGd3Wk5Dd2NRbzMxYk5ydUZxZ3Evb2twZHcrT3dyblJk?= =?utf-8?B?WVp6NVIrVUcwV2tlVTRSakFBRDhjT1doSEcxdGw0OExxaTBMazBvV2Z4RjNL?= =?utf-8?B?Y3o0V0VxQm1Zb0FYVnoyYlJKN0drNkFjOWxLdWlMWDBKTlppTXpDSjZ4Rm13?= =?utf-8?B?NVF1WXFOV282ZTIyN1Z6WXltYUdjdzdpbXdGRGh1Q0t3bmtodTluQ2lSdnUy?= =?utf-8?B?aHdoZS9iV05lZndkd3NTdVVUc01hem5JdGxSeHgvc2pkalNoZHhHaVNuRExE?= =?utf-8?B?dEdDTDNkdU1BM0dacWREZStqM3RwMExld0ltTi9IM0g1N2hJTDFTa1RWM0Zm?= =?utf-8?B?WXFzaGFBZENWYWduL0Z3TFU0QWw4UmhGK2xNb3JuSWF1TG0wUlVKcWVWVTRE?= =?utf-8?B?NERmUE9LVExTeVVKVWNjTG9SMC9vWEVHSlBPVzIxNnlqV0RKTXFaZlRyK2pK?= =?utf-8?B?ei9zRC9TbGRoaW9td01oYUpKS1ZFWk9BNmlZaWQ1dW9ucXlleU82MU1zYWRn?= =?utf-8?B?a3I3eHJDT04wV0Q4Qml1SkNKK0RGRDI4eTNJMjNhZXVtckpSNzR1M24vTTA0?= =?utf-8?B?eHVGcG1NR05OVkQ2MnAwRk1EMWFUb0s0MWNsSUcyV1ZCVjRBZzh5dUtkck5Y?= =?utf-8?B?d2ZwYnFqR0FMVGlPLzAveHlFRmxIQUd6UmpWOUJBS1VWd3hEQnY3NDh3VnhP?= =?utf-8?B?WUpieFJBNDdSWTRUdTNLRlRrVEJzVFBERDhmK2VHVWQvbElTZXc1R0tCVEQ4?= =?utf-8?B?VE00NVFQMGRxNlk5ZkE5UjRmdTIxMXBpRDk3Vll1MlpMRFZOdU9wd0Y4UXVX?= =?utf-8?B?SkY5RHNBcSs3NUVZSDRQeTRjVEJQSTdOL1dLcGJWOG0wTHdJS0pLQmd2SGUx?= =?utf-8?B?WDBoUTdwZ01vM1RKaVp1RUgvWnY5NE9zd2drTXNtemhuSzQ1VlpHb0ZNUnlB?= =?utf-8?Q?erRl6uwSrsqQ9zLU3SU9/oP3dVUIZ0=3D?=
X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3425; 6:QclK1lXPlpy+gQULTj3XI3GZv0H5La2MdtZEcbW1/ZcxboX8WZlnJHn1Fq9UtYYRjuGQaFEXbdYPwmJKRaQsxrMSYn++KZYlhwuVDRAykh1wg9qmGlTYPgOk8dZsnwJtaPkysDkIb8sSnDFE7yWc1/+S3gKrE5SjERnq1YziwXYK+T5kQhzd2CZgf3YCgJf7Isxzeq4tfMuOhADYpl59820U+vRi7P3EP7hkwW/WZJGerbuR6DvwQNbgIQuE5Fs73VNVTFieSPT/8gNqbbccH4mnujbxWtMgQjf4vWq8u/Wjv+r4WCAU3E725sNakFoV7GesjVhIlunX9dfOTZjDNA==; 5:UXGhywTwntnPeCgstRcU8nikyvJu4FmE7V9qPRifyBieF2FPNXygE8dBOjHjJMSP6PKHzo6oBEnNxPzHfexfqaP8Enj2RYHfVtYGw5pjB/IISfeCSwRYKPfw1N8U+M1ZtldAMAAWiWp0juU7xytAlg==; 24:xii50pLKT1aoxzSvy7iQHigC8nRUxMZtw6ZYC+oewyWb4EzeX79F0a6+V1FqSahtHyr9MnJqSM5mZFb4BRpyqTrPQI3/FfMOI2lqreUIOtc=; 7:fcrfOezQXgHHiUL+x6ApTiWyr1ThJMCMXw7YuKbQj0F/J7ZG5L5DhuXeoV0DN+vM8h4F6/1qykFjviSWBertNl0PTwm1BRT3v7BYP/BiZY4o1Rkp4hb0whsLrMbkkh7W/Cmcj1hcnbDUpD/DpbsriaNgVXxL79aLLIjB5lXBnmkbvvYx1cRSL+IxhTV4ywukwFo+5NA65fvw+jpxUUjSF0DQmg5UKZ6HVyuanuSrJRQ=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2017 14:04:19.6759 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3425
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCIsWRmVeSWpSXmKPExsUyM2K7hG5qz65Ig1dfJS3mX2xkdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtLTLYwF88Qq7j35w9jAeFqwi5GTQ0LARKJ17SXGLkYuDiGB I4wSZy/OZoVwTjBKnHz+DizDItDLLHFsYhMjSAujQJzEzjULoaramCSmtU1mA0mwCRhJTO0/ zwJiCwvISFxrWMMMYosIqEvM3LkerIZXwF5i95pTQDYH0FRViXkHY0DCogIxEi1LPjBClAhK nJz5BGwMs4CFxMz55xkhbHmJ7W/nMEOcrSBxffN1FpAbJASmMErcfPoerEFIQEPi4YW/rBBF shJHz85hgbB9JWa8X8IM0XCZSWLr/x1sEE4Du8T93zBVWhIzjiyDSkxgl+hb2c8EkfCWaH92 mR3CzpY4/GMCK0TRaVaJ17dmQB0lI/Hx10NGiEQ3m0Tz1SNQR6VKbLnRAjV2vbBE89mX7BBO G7vE+pfvGScwqs1C8vosJK/PQvL6AkbmVYyixanFSbnpRkZ6qUWZycXF+Xl6eaklmxiBaeHg lt8GOxhfPnc8xCjAwajEw/u4bFekEGtiWXFl7iFGCQ5mJRHerkqgEG9KYmVValF+fFFpTmrx IUZpDhYlcV7HfRcihATSE0tSs1NTC1KLYLJMHJxSDYySF/rOV2ezvjfYsIrZ3D5L93t+/IvC 8Gn+WzZ8eBY/m/PSKaNNU340861UnHLFedmr9GDvZYvL8mTWJE367nTfwoU5X1kyoFBx9bft 55P+mtdI3Vvcz6Mf/KjpyJemWTGzOZRkprRGJe7/mbI8If/bei4Lk18vvt633H5j5u8ramt2 LX2fIhmvxFKckWioxVxUnAgA0iEzowcDAAA=
Archived-At: 
Subject: [netmod] Comments on NMDA-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Sep 2017 14:04:25 -0000

Hello,

Reading the draft-ietf-netmod-revised-datastores-04 some comments:

General) The system often adds data to the  or  
datastore already not just to : e.g.

UC1: I have a server configured in running. I need to bind it to an 
ip-address. The ip-address might be the local loopback address, however 
if that is only added to the , validation will fail 
indicating that the server is bound to a non-existent address. How to 
handle this?

UC2: I have a set of capabilities set by the system e.g. 
supported-reporting-intervals. I need to configure a job that MUST use 
one of these intervals. If the supported-reporting-intervals are only 
added to  I can not validate the selected-interval in my 
configured job.

My proposal is to allow the system to add data to running as well. 
Actually I think that is a more relevant case then adding configuration 
just to .

CH 4.4.)  "Validation is performed on  the contents of ." This 
to me means that default data is not considered at validation which 
would be a backwards incompatible change. Also if validation does not 
consider system configured data that would allow cases like multiple 
interfaces named lo0. One from  one from system configuration. 
IMHO while it is OK to violate uniqueness because of remnant data, the 
above violation of uniqueness seems a bad idea.

Ch. 4.7) Is it allowed to violate uniqueness of key values? IMHO it 
should not be.

Ch 5.1) IMHO actions and rpcs should be allowed to include other 
datastores in their XPath evaluation. My suggestion is that they need to 
specify it somehow. (Yang extension?)

UC1) I want to define a convinience action that allows me to do a big 
modification in  in one step. I wan't to validate what it is 
doing based on the current contents of running. E.g. configure the OAM 
settings for the system including SNMP/Netconf/FTP in one step, but for 
each step I need to check that I am putting the relevant server on an 
existing interface.
If specifying the datastore is an overkill, I would still rather chose 
runing as the accessible datastore. XPath is mostly use for checks. 
Checks are done against configuration.

Appendix B)

"4. How applied     : automatic"    This is definitely not enough to 
understand what happens even as an example. I propose:
Changes are automatically propagated to 

C.1)  During the example the
     2001:db8::10
      32
is changed to 64 its. Is that intentional? It is not mentioned in the text.

regards Balazs


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


From nobody Thu Sep 14 07:26:45 2017
Return-Path: 
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 493FB132D44; Thu, 14 Sep 2017 07:26:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 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_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 zQeKAq-MRpdP; Thu, 14 Sep 2017 07:26:40 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0119.outbound.protection.outlook.com [104.47.38.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 690AB132713; Thu, 14 Sep 2017 07:26:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4zTHqvLBUBCwh9xb+MBZQ32hixjAVkgHA1nuLBKDD8U=; b=ARhF1fSyb4qIAGv1eN0IApxA2ubrBx4NW9bvIEpP03EXxmXfAxyGYw1jw8+6HySdCzm1MUyKpFIm80W44vIZxsNWsMNGlBf+o9auV/MAhQnKePtHd98zFNM3mfj+4Bc8G9EFLUf08fqwbtGMSH4ov0OiDtU0cA24np5mxlRTfns=
Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB274.namprd05.prod.outlook.com (10.141.22.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.3; Thu, 14 Sep 2017 14:26:38 +0000
Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0035.010; Thu, 14 Sep 2017 14:26:37 +0000
From: Kent Watsen 
To: Robert Wilton , t.petch , "netmod@ietf.org" 
CC: "draft-ietf-netmod-syslog-model@ietf.org" 
Thread-Topic: [netmod] syslog-model-17 shepherd writeup issues -references
Thread-Index: AQHTLHc0HPi1rZXCNUadzeG98awlR6KyydeAgAFxGQD///QHgA==
Date: Thu, 14 Sep 2017 14:26:37 +0000
Message-ID: <47A12DBB-BEF6-41D2-BC38-E08AB7AFB44B@juniper.net>
References: <49B4BE2F-6912-49BE-9E4A-830146309AB2@juniper.net> <019b01d32c76$fa7dfc40$4001a8c0@gateway.2wire.net> <8CF097E4-CEB7-4C4E-AC7D-F7F896CD1BB7@juniper.net> <516d3881-4fbb-fad0-5413-404f644ea63b@cisco.com>
In-Reply-To: <516d3881-4fbb-fad0-5413-404f644ea63b@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB274; 6:V/QpotJFGpv12JdiMhYihCPVXuduUDuYTFoXS5yQpVdbF7kAuVS1FoFUO6DNcizKCffJipMEB3kVFl21Xc4bfa91zDOUwwGCrQlQfQ1yudtZibCrzVd7PdCHUby/Ilnx3mGK94YurstjtyNQODjjgFmbAQwQelZ7knCms7bWOvdbpJChsiNGhSDclxRe9viQ4I/fnFGeIlx5xJBgdWj20jbqri5YDuoM0b8bt95yrfza7HOl39J10fX9nlM1HdG5bzjlj20oqDVv0ahTrRQLljBf696FhqQiAZ07p2B52OwdfFW4HlMb5jheykUUxV7uqhGszWgq+cIBYRelXAunmA==; 5:K8ggcuXlyCiGeFuGXGPTFVq/p813nJvORdAOPIVx6HWhBtd7HlYsR5cqL1SIqTI+9RVf+ggRZ6RgEhMJZCTNIkdczGLmVJxvVn8el8UQufvBjtZP8jkdXZjUFO3hP7CtsCTSMkhsUYTFeAV0H2RKfw==; 24:H7Wb6X8RbAOImQq9VATCULcWpiLutY3IhCCi6c8/k9nIWIr5eoYmtePingPh3N7ptoGpeO6cuRd49w0CUog9MjfNh3KkGAhmRgOWTYCVAV0=; 7:66ruO6+7H+pdU2q4JCByMkMwFxrA3I9lO0mtBH0E3PwDGgg3gyG7pL+liBpl19SlZ3OJD3HhiRoqSqlcXGurKFrENRn+adVfn41tyFX2Hh79N6J3HAWvLDLvbOvze2CgQUcCvHK/2n/4m2Q66+yxKWkRCrSk1Ni3YuI0fe3px1sVUXe+Q9OuLytRercdPRRFO95pzt7ldVusP0P0N5wCeGqcL9IYcqQnunaV2vfZwrk=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 0417c828-1d74-4411-a402-08d4fb7c9bf8
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR05MB274; 
x-ms-traffictypediagnostic: BLUPR05MB274:
x-exchange-antispam-report-test: UriScan:(192374486261705)(138986009662008);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB274; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB274; 
x-forefront-prvs: 0430FA5CB7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(209900001)(199003)(24454002)(377454003)(13464003)(189002)(189998001)(478600001)(230783001)(86362001)(2950100002)(4326008)(6506006)(106356001)(101416001)(25786009)(81166006)(68736007)(54356999)(575784001)(8676002)(6116002)(102836003)(8936002)(229853002)(3846002)(81156014)(66066001)(5660300001)(76176999)(83716003)(99286003)(2906002)(2501003)(8666007)(83506001)(3660700001)(3280700002)(36756003)(4001350100001)(53936002)(77096006)(7736002)(2900100001)(53546010)(33656002)(6486002)(97736004)(93886005)(82746002)(305945005)(6246003)(6436002)(6512007)(50986999)(14454004)(6306002)(316002)(105586002)(966005)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB274; H:BLUPR05MB275.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: 14 Sep 2017 14:26:37.5487 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB274
Archived-At: 
Subject: Re: [netmod] syslog-model-17 shepherd writeup issues -references
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Sep 2017 14:26:43 -0000

R29vZCBzdWdnZXN0aW9uLCBSb2IuICBUaGlzIG1pZ2h0IGFsc28gaGF2ZSBjb21lIHVwIGluIHRo
ZSBTZWNEaXIgcmV2aWV3Lg0KDQpTZXBhcmF0ZWx5LCBKdWVyZ2VuIGhhZCBhIHN1Z2dlc3Rpb24g
dG8gYWRkIGFuICJvYnNlcnZhdGlvbiIgKHNpbmNlIGEgIndhcm5pbmciIHNlZW1zIHRvbyBzdHJv
bmcpIHRoYXQgdXNlIG9mIFBPU0lYIHJlZ2V4IHByZWNsdWRlcyBVVEY4IHN1cHBvcnQuICBNYWtl
cyBzZW5zZT8gIEZXSVcsIHRoZSBtb2R1bGUgaXMgZmluZSBhcyBpcywgc2luY2UgdGhlIHJlZ2V4
IGlzIHVuZGVyIGEgZmVhdHVyZSBzdGF0ZW1lbnQsIHdoaWNoIGFsbG93cyBhIGZ1dHVyZSBlZmZv
cnQgYWRkIGFub3RoZXIgcmVnZXgtZmVhdHVyZSBpZiBldmVyIG5lZWRlZC4NCg0KQ2x5ZGUsIHNp
bmNlIHRoZXNlIGFyZSBub3QgdGVjaG5pY2FsIGNoYW5nZXMsIGFuZCBhc3N1bWluZyB0aGF0IHRo
ZXJlIGlzIG5vIG9iamVjdGlvbiwgeW91IGNhbiBtYWtlIHRoZXNlIHR3byB0d2Vha3MgYXMgd2Vs
bC4gIE90aGVyd2lzZSwgSSBjYW4gYWRkIG5vdGVzIGFib3V0IHRoZXNlIGluIHRoZSBzaGVwaGVy
ZCB3cml0ZXVwLg0KDQpLZW50DQoNCi0tDQoNCkhpIEtlbnQsIENseWRlLA0KDQpEb2VzIHRoZSAi
cGF0dGVybi1tYXRjaCIgbGVhZiBuZWVkIHRvIGJlIGV4cGxpY2l0bHkgcHVsbGVkIG91dCBpbiAN
CnNlY3VyaXR5IGNvbnNpZGVyYXRpb25zPyAgQWxsb3dpbmcgYSBjbGllbnQgdG8gcHJvdmlkZSBh
biBhcmJpdHJhcnkgDQpyZWdleCBjb3VsZCBwb3RlbnRpYWxseSBjYXVzZSBhIHJlZ2V4IGVuZ2lu
ZSB0byBvdmVyZmxvdyBpdHMgc3RhY2sgYW5kIA0KY3Jhc2guDQoNCkFuIGV4YW1wbGUgb2YgYW4g
cmVnZXggb3ZlcmZsb3cgaXMgZGVzY3JpYmVkIGhlcmU6IA0KaHR0cDovL3d3dy5yZWd1bGFyLWV4
cHJlc3Npb25zLmluZm8vY2F0YXN0cm9waGljLmh0bWwNCg0KVGhhbmtzLA0KUm9iDQoNCg0KT24g
MTMvMDkvMjAxNyAxODowOCwgS2VudCBXYXRzZW4gd3JvdGU6DQo+IEhpIFRvbSwNCj4NCj4gVGhh
bmtzLiAgVGhlIGZpeCBJJ20gbG9va2luZyBmb3IgaXMgZm9yIHRoZSAncGF0dGVybi1tYXRjaCcg
bGVhZg0KPiB0byBoYXZlIGEgJ3JlZmVyZW5jZScgc3RhdGVtZW50IHRvIFN0ZC0xMDAzLjEtMjAw
OCwgYW5kIGZvciBTNC4xDQo+IHRvIGFsc28gbGlzdCBTdGQtMTAwMy4xLTIwMDggYXMgYSBkcmFm
dC1sZXZlbCByZWZlcmVuY2UuDQo+DQo+IEkgd2FzIGdvaW5nIHRvIHBvaW50IG91dCB0aGUgdHlw
byAidGhlIHRoZSIgYXMgd2VsbCwgYnV0IGZpZ3VyZWQNCj4gdGhhdCB0aGUgUkZDIEVkaXRvciB3
b3VsZCBnZXQgaXQuDQo+DQo+IEsuIC8vIHNoZXBoZXJkDQo+DQo+DQo+IC0tDQo+DQo+IEtlbnQN
Cj4NCj4gWW91IGZsYWcgU3RkLTEwMDMuMS0yMDA4IGFzIGxpc3RlZCBhcyBhIG5vcm1hdGl2ZSBy
ZWZlcmVuY2UgYnV0IG5vdCB1c2VkDQo+IGFueXdoZXJlIGluIHRoZSBkb2N1bWVudC4gIEluIHRo
ZSBEZXNjcmlwdGlvbnMsIGJ1dCBub3QgaW4gdGhlIHMuNC4xDQo+IHJlZmVyZW5jZXMsIEkgc2Vl
DQo+DQo+IFRoaXMgbGVhZiBkZXNjcmliZXMgYSBQb3NpeCAxMDAzLjIgcmVndWxhciBleHByZXNz
aW9uIC4uLg0KPg0KPiB0d2ljZSwgd2hpY2ggbWF5LCBvciBtYXkgbm90LCByZWxhdGUgdG8gdGhp
cyBpc3N1ZS4NCj4NCj4gQmFjayBpbiBKdWx5LCBjbHlkZSBzYWlkDQo+ICJJIHdpbGwgaW5zZXJ0
IGEgbm9ybWF0aXZlIHJlZmVyZW5jZSB0byBQT1NJWCAxMDAzLjIgaW4gdGhlIG5leHQNCj4gcmV2
aXNpb24gb2YgdGhlIGRyYWZ0LiINCj4NCj4gSW4gYSBzaW1pbGFyIHZlaW4sIFJGQzY5OTEgYXBw
ZWFycyBpbiBhIHJlZmVyZW5jZSBzdGF0ZW1lbnQgYnV0IG5vd2hlcmUNCj4gZWxzZS4NCj4NCj4g
QXMgeW91IHBvaW50IG91dCwgUkZDNjAyMSBpcyByZWZlcmVuY2VkIGJ1dCBpcyBvYnNvbGV0ZWQg
YnkgUkZDNjk5MSBzbw0KPiBzaG91bGQgbm90IGJlLg0KPg0KPiBBbmQgaW4gYSBzbGlnaHRseSBk
aWZmZXJlbnQgdmVpbiwNCj4NCj4gICAgIHJlZ2lzdHJ5IFtSRkM3ODk1XS8+LiAgRm9sbG93aW5n
IHRoZSBmb3JtYXQgaW4gW1JGQzc5NTBdLz4sIHRoZSB0aGUNCj4NCj4gbG9va3Mgb2RkIGZvciBw
bGFpbiB0ZXh0IGFuZCBmb3IgdGhlIHJlcGV0aXRpb24gb2YgJ3RoZScuLg0KPg0KPiBUb20gUGV0
Y2gNCj4NCj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiBGcm9tOiAiS2VudCBXYXRz
ZW4iIDxrd2F0c2VuQGp1bmlwZXIubmV0Pg0KPiBUbzogPG5ldG1vZEBpZXRmLm9yZz4NCj4gQ2M6
IDxkcmFmdC1pZXRmLW5ldG1vZC1zeXNsb2ctbW9kZWxAaWV0Zi5vcmc+DQo+IFNlbnQ6IFR1ZXNk
YXksIFNlcHRlbWJlciAxMiwgMjAxNyAxMDo1MCBQTQ0KPiBTdWJqZWN0OiBbbmV0bW9kXSBzeXNs
b2ctbW9kZWwtMTcgc2hlcGhlcmQgd3JpdGV1cCBpc3N1ZXMNCj4NCj4NCj4+IENseWRlLCBhbGws
DQo+Pg0KPj4gSW4gcmV2aWV3aW5nIHRoZSBkcmFmdCBmb3IgU2hlcGhlcmQgd3JpdGV1cCwgSSBm
b3VuZCB0aGUgZm9sbG93aW5nDQo+IGlzc3VlcyB0aGF0IEkgdGhpbmsgbmVlZCB0byBiZSBhZGRy
ZXNzZWQgYmVmb3JlIHRoZSBkb2N1bWVudCBjYW4gYmUgc2VudA0KPiB0byBCZW5vaXQgZm9yIEFE
IHJldmlldzoNCj4+DQo+PiAxLiBJZG5pdHMgZm91bmQgdGhlIGZvbGxvd2luZzoNCj4+DQo+PiAg
ICBTdW1tYXJ5OiAzIGVycm9ycyAoKiopLCAwIGZsYXdzICh+fiksIDMgd2FybmluZ3MgKD09KSwg
MSBjb21tZW50DQo+ICgtLSkuDQo+PiAgICAgICoqIFRoZXJlIGFyZSAyIGluc3RhbmNlcyBvZiB0
b28gbG9uZyBsaW5lcyBpbiB0aGUgZG9jdW1lbnQsIHRoZQ0KPiBsb25nZXN0IG9uZQ0KPj4gICAg
ICAgICAgIGJlaW5nIDMgY2hhcmFjdGVycyBpbiBleGNlc3Mgb2YgNzIuDQo+Pg0KPj4gICAgICAq
KiBPYnNvbGV0ZSBub3JtYXRpdmUgcmVmZXJlbmNlOiBSRkMgNjAyMSAoT2Jzb2xldGVkIGJ5IFJG
QyA2OTkxKQ0KPj4NCj4+ICAgICAgKiogRG93bnJlZjogTm9ybWF0aXZlIHJlZmVyZW5jZSB0byBh
biBIaXN0b3JpYyBSRkM6IFJGQyA2NTg3DQo+Pg0KPj4gICAgICA9PSBNaXNzaW5nIFJlZmVyZW5j
ZTogJ1JGQzU0MjUnIGlzIG1lbnRpb25lZCBvbiBsaW5lIDM1OSwgYnV0IG5vdA0KPiBkZWZpbmVk
DQo+PiAgICAgICAgICAgJ1tSRkM1NDI1XSwgW1JGQzU0MjZdLCBbUkZDNjU4N10sIGFuZCBbUkZD
NTg0OF0uLi4uJw0KPj4NCj4+ICAgICAgID09IFVudXNlZCBSZWZlcmVuY2U6ICdSRkM3ODk1JyBp
cyBkZWZpbmVkIG9uIGxpbmUgMTQwNiwgYnV0IG5vDQo+IGV4cGxpY2l0DQo+PiAgICAgICAgICAg
IHJlZmVyZW5jZSB3YXMgZm91bmQgaW4gdGhlIHRleHQNCj4+ICAgICAgICAgICAgJ1tSRkM3ODk1
XSAgQmllcm1hbiwgQS4sIEJqb3JrbHVuZCwgTS4sIGFuZCBLLiBXYXRzZW4sICJZQU5HDQo+IE1v
ZHVsZSBMLi4uJw0KPj4gICAgICAgPT0gVW51c2VkIFJlZmVyZW5jZTogJ1JGQzYyNDInIGlzIGRl
ZmluZWQgb24gbGluZSAxNDM1LCBidXQgbm8NCj4gZXhwbGljaXQNCj4+ICAgICAgICAgICAgcmVm
ZXJlbmNlIHdhcyBmb3VuZCBpbiB0aGUgdGV4dA0KPj4gICAgICAgICAgICAnW1JGQzYyNDJdICBX
YXNzZXJtYW4sIE0uLCAiVXNpbmcgdGhlIE5FVENPTkYgUHJvdG9jb2wgb3Zlcg0KPiBTZWN1cmUg
U2guLi4nDQo+Pg0KPj4gMi4gYHJmY3N0cmlwYCBleHRyYWN0ZWQgImlldGYtc3lzbG9nLnlhbmci
LCAgd2hpY2ggaXMgbWlzc2luZw0KPiAiQHl5eXktbW0tZGQiIGluIGl0cyBuYW1lDQo+PiAzLiAg
bmVpdGhlciBgcHlhbmdgIG5vciBgeWFuZ2xpbnRgIGZvdW5kIGFueSBlcnJvcnMgd2l0aA0KPiBp
ZXRmLXN5c2xvZy55YW5nLiAgICBweWFuZyBzYXlzDQo+PiAgICAgICAgZm9yIHZlbmRvci1zeXNs
b2ctdHlwZXMtZXhhbXBsZTogc3RhdGVtZW50ICJpZGVudGl0eSIgbXVzdCBoYXZlDQo+IGEgImRl
c2NyaXB0aW9uIg0KPj4gICAgICAgIHN1YnN0YXRlbWVudC4NCj4+DQo+PiA0LiB0ZXN0aW5nIHRo
ZSBleGFtcGxlcyBpbiB0aGUgZHJhZnQgYWdhaW5zdCB5YW5nbGludDoNCj4+ICAgICAgICAtIGZv
ciBib3RoIGV4YW1wbGVzOiBNaXNzaW5nIGVsZW1lbnQncyAibmFtZXNwYWNlIi4gKC9jb25maWcp
DQo+PiAgICAgICAgLSBqdXN0IHJlbW92aW5nIHRoZSAiPGNvbmZpZz4iIGVsZW1lbnQgZW52ZWxv
cCByZXNvbHZlcyB0aGlzDQo+IGVycm9yLg0KPj4gNS4gdGhlIDJuZCBleGFtcGxlIHVzZXMgSVAg
YWRkcmVzcyAiMjAwMTpkYjg6YTBiOjEyZjA6OjEiLCBidXQgdGhpcw0KPiBTSE9VTEQgYmUgYQ0K
Pj4gICAgICAgZG9tYWluIG5hbWUgKGUuZy4sIGZvby5leGFtcGxlLmNvbSkNCj4+DQo+PiA2LiBp
biB0aGUgWUFORyBtb2R1bGUsIGFueXdoZXJlIHlvdSBoYXZlIGFuIFJGQyBsaXN0ZWQgaW4gYQ0K
PiAnZGVzY3JpcHRpb24nIHN0YXRlbWVudCwNCj4+ICAgICAgIHRoZXJlIHNob3VsZCBiZSBhICdy
ZWZlcmVuY2UnIHN0YXRlbWVudCBmb3IgdGhhdCBSRkMuDQo+Pg0KPj4gNy4gaW4gdGhlIHRyZWUg
ZGlhZ3JhbSwgdGhlIGxlYWZyZWZzIG5vIGxvbmdlciBpbmRpY2F0ZSB3aGF0IHRoZXkNCj4gcG9p
bnQgYXQsIHRoZXkgbm93IGFsbA0KPj4gICAgICAganVzdCBzYXkgImxlYWZyZWYiLiAgRGlkIHlv
dSBkbyB0aGlzIG9uIHB1cnBvc2UsIG9yIGFyZSB5b3UgdXNpbmcNCj4gYSBkaWZmZXJlbnQgdHJl
ZQ0KPj4gICAgICAgb3V0cHV0IGdlbmVyYXRvciBmcm9tIC0xNT8NCj4+DQo+PiA4LiBSRkM2NTM2
IGlzIGxpc3RlZCBhcyBhIG5vcm1hdGl2ZSByZWZlcmVuY2UsIGJ1dCBpdCBwcm9iYWJseSBzaG91
bGQNCj4gYmUgaW5mb3JtYXRpdmUuDQo+PiA5LiBTdGQtMTAwMy4xLTIwMDggaXMgbGlzdGVkIGFz
IGEgbm9ybWF0aXZlIHJlZmVyZW5jZSwgYnV0IGl0IGlzIG5vdA0KPiB1c2VkIGFueXdoZXJlIGlu
IHRoZSBkb2N1bWVudC4NCj4+IDEwLiBSRkM2MjQyIGlzIGxpc3RlZCBhcyBhbiBpbmZvcm1hdGl2
ZSByZWZlcmVuY2UsIGJ1dCBpdCBpcyBub3QgdXNlZA0KPiBhbnl3aGVyZSBpbiB0aGUgZG9jdW1l
bnQuDQo+PiAxMS4gdGhlIGRvY3VtZW50IGZhaWxzIHRvIGRlY2xhcmUgaXRzIG5vcm1hdGl2ZSBy
ZWZlcmVuY2VzIHRvDQo+IGlldGYta2V5c3RvcmUgYW5kIGlldGYtdGxzLWNsaWVudC1zZXJ2ZXIu
DQo+PiAgICAgICAgICBOb3RlOiB5b3UgbWFudWFsbHkgZW50ZXJlZCB0aGUgIltSRkMgeXl5eV0s
IGFuZCBbUkZDIHh4eHhdIg0KPiByZWZlcmVuY2Vz4oCmDQo+PiAxMi4gIFRoZSBJQU5BIGNvbnNp
ZGVyYXRpb25zIHNlY3Rpb24gc2VlbXMgYXN5bW1ldHJpYy4gIEVpdGhlciBwdXQNCj4gYm90aCBy
ZWdpc3RyeSBpbnNlcnRpb25zIGludG8NCj4+ICAgICAgICAgIHN1YnNlY3Rpb25zLCBvciBrZWVw
IHRoZW0gYm90aCBhdCB0aGUgdG9wLWxldmVs4oCmDQo+Pg0KPj4gMTMuIHJldmlld2luZyB0aGUg
ZmluYWwgZG9jdW1lbnQgYWdhaW5zdCBteSBvcmlnaW5hbCBZRCByZXZpZXcsIEkgaGF2ZQ0KPiB0
aGUgZm9sbG93aW5nIHJlc3BvbnNlcy4gIExldCdzIGJlIHN1cmUgdG8gY2xvc2Ugb3V0IHRoZXNl
IGl0ZW1zIGFzDQo+IHdlbGwuICBSZWY6IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJj
aC9tc2cvbmV0bW9kLzEwbG80MVVkNEEzWk4xMQ0KPiBzLTBnT2ZDZThOU0UNCj4+IDEuIG9rDQo+
PiAyLiBiZXR0ZXINCj4+IDMuIHNob3VsZCBiZTogcy90aGUgbWVzc2FnZS90aGVzZSBtZXNzYWdl
cy8gIFtSRkMgRWRpdG9yIG1pZ2h0J3ZlDQo+IGNhdWdodCB0aGlzXQ0KPj4gNC4gYmV0dGVyDQo+
PiA1LiBzdGlsbCBmZWVsIHRoZSBzYW1lIHdheSwgYnV0IG5vIGJpZ2dlZQ0KPj4gNi4gYmV0dGVy
LCBidXQgZnJvbSA4MTc0LCB5b3Ugc2hvdWxkIGFkZCB0aGUgcGFydCAid2hlbiwgYW5kIG9ubHkN
Cj4gd2hlbiwgdGhleSBhcHBlYXIgaW4gYWxsIGNhcGl0YWxzLCBhcyBzaG93biBoZXJlLiINCj4+
IDcuIGZpeGVkDQo+PiA4LiBmaXhlZA0KPj4gOS4geW91IGRpZCB3aGF0IEkgYXNrZWQsIGJ1dCB0
aGUgcmVzdWx0IHN0aWxsIGlzbid0IHNhdGlzZnlpbmcuLi4NCj4+IDEwLiBzb21lIGltcHJvdmVt
ZW50cyBtYWRlIGluIHRoaXMgYXJlYSwgYnV0IG15IGFzayB3YXNuJ3QgYW1vbmcgdGhlbQ0KPj4g
MTEuIGJldHRlcg0KPj4gMTIuIGJldHRlciwgYnV0IEkgdGhpbmsgdGhlIDR0aCBsaW5lIHNob3Vs
ZCBiZSBpbmRlbnRlZCB0b28sIHJpZ2h0Pw0KPj4gMTMuIGJldHRlciwgYnV0IEkgd2lzaCB5b3Ug
Y2FsbGVkIFMxLjMgIlRyZWUgRGlhZ3JhbSBOb3RhdGlvbiINCj4+IDE0LiBmaXhlZA0KPj4gMTUu
IGZpeGVkDQo+PiAxNi4gZml4ZWQNCj4+IDE3LiBmaW5lDQo+PiAxOC4gc3RpbGwgYSB3ZWlyZCBs
aW5lIGJyYWtlIGhlcmUuICB0cnkgcHV0dGluZyB0aGUgcXVvdGVkIHN0cmluZyBvbg0KPiB0aGUg
bmV4dCBsaW5lLg0KPj4gMTkuIGZpeGVkDQo+PiAyMC4gZml4ZWQNCj4+IDIxLiBub3QgZml4ZWQg
KHJlOiB5YW5nLXNlY3VyaXR5LWd1aWRlbGluZXMpDQo+PiAyMi4gZmluZQ0KPj4NCj4+DQo+PiBQ
UzogcGxlYXNlIGFsc28gYmUgc3VyZSB0byBmb2xsb3ctdXAgd2l0aCBCZW5vaXQgb24gaGlzIEFE
IHJldmlldy4NCj4+DQo+PiBUaGFua3MsDQo+PiBLZW50ICAvLyBzaGVwaGVyZCAmIHlhbmcgZG9j
dG9yDQo+Pg0KPj4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KPj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4gbmV0bW9kQGlldGYub3JnDQo+
PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPj4NCj4NCj4N
Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0
bW9kIG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0KDQoNCg==


From nobody Thu Sep 14 07:34:16 2017
Return-Path: 
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 5A9C513302D for ; Thu, 14 Sep 2017 07:34:14 -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 cS_wuJCX6bbf for ; Thu, 14 Sep 2017 07:34: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 B087A13302B for ; Thu, 14 Sep 2017 07:34:12 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 5F7441AE0383; Thu, 14 Sep 2017 16:34:11 +0200 (CEST)
Date: Thu, 14 Sep 2017 16:32:39 +0200 (CEST)
Message-Id: <20170914.163239.143365521945928900.mbj@tail-f.com>
To: balazs.lengyel@ericsson.com
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <9ec6b2e4-36a7-87e6-59fa-828855235835@ericsson.com>
References: <9ec6b2e4-36a7-87e6-59fa-828855235835@ericsson.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: [netmod] Comments on NMDA-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Sep 2017 14:34:14 -0000

Hi Balazs,

Thanks for your review.  Comments inline.

Balazs Lengyel  wrote:
> Hello,
> 
> Reading the draft-ietf-netmod-revised-datastores-04 some comments:
> 
> General) The system often adds data to the  or 
> datastore already not just to : e.g.
> 
> UC1: I have a server configured in running. I need to bind it to an
> ip-address. The ip-address might be the local loopback address,
> however if that is only added to the , validation will
> fail indicating that the server is bound to a non-existent
> address. How to handle this?
> 
> UC2: I have a set of capabilities set by the system
> e.g. supported-reporting-intervals. I need to configure a job that
> MUST use one of these intervals. If the supported-reporting-intervals
> are only added to  I can not validate the
> selected-interval in my configured job.
> 
> My proposal is to allow the system to add data to running as
> well. Actually I think that is a more relevant case then adding
> configuration just to .

I think the consensus is that in general it is a bad idea if servers
(spontaneously) add data to .  However, there is nothing in
the new or old architectures that prohibits this.

Also note that the draft says:

  Currently there are no standard mechanisms defined that affect
   so that it would have different contents than ,
  but this architecture allows for such mechanisms to be defined.

which means that you can also define your own mechanisms for adding
things to , before validation.

> CH 4.4.)  "Validation is performed on the contents of ."
> This to me means that default data is not considered at validation

Note that RFC 7950, section 6.4.1, says:

   In the accessible tree, all leafs and leaf-lists with default values
   in use exist (see Sections 7.6.1 and 7.7.2).

So defaults are taken into account when intended is validated.

> which would be a backwards incompatible change. Also if validation
> does not consider system configured data that would allow cases like
> multiple interfaces named lo0. One from  one from system
> configuration. IMHO while it is OK to violate uniqueness because of
> remnant data, the above violation of uniqueness seems a bad idea.

If your system adds data to , or to , it will be
validated.

> Ch. 4.7) Is it allowed to violate uniqueness of key values? IMHO it
> should not be.

Agreed.  Note that the draft explicitly lists the constraints that can
be violated, and uniqueness of keys is not listed.

> Ch 5.1) IMHO actions and rpcs should be allowed to include other
> datastores in their XPath evaluation. My suggestion is that they need
> to specify it somehow. (Yang extension?)

This is something that the WG has discussed in the past as well, but
so far no concrete proposal has been made.  I think such extensions
can be done in a separate document in the future, or maybe if we do a
new version of YANG.

But note that for rpc and action, this section only talks about
XPath in input/output parameters.

> UC1) I want to define a convinience action that allows me to do a big
> modification in  in one step. I wan't to validate what it is
> doing based on the current contents of running. E.g. configure the OAM
> settings for the system including SNMP/Netconf/FTP in one step, but
> for each step I need to check that I am putting the relevant server on
> an existing interface.

I think this is covered.  If you have an rpc that modifies ,
the result will be valdiated according to the must expression in the
data models.

> If specifying the datastore is an overkill, I would still rather chose
> runing as the accessible datastore. XPath is mostly use for
> checks. Checks are done against configuration.
> 
> Appendix B)
> 
> "4. How applied : automatic" This is definitely not enough to
> understand what happens even as an example. I propose:
> Changes are automatically propagated to 

I agree this is better.

> C.1)  During the example the
>     2001:db8::10
>      32
> is changed to 64 its. Is that intentional? It is not mentioned in the
> text.

No this is a bug, will be fixed!


/martin


From nobody Thu Sep 14 07:52:38 2017
Return-Path: 
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 B4349132D17 for ; Thu, 14 Sep 2017 07:52:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 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_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 f1UQYETv-O5R for ; Thu, 14 Sep 2017 07:52:34 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0130.outbound.protection.outlook.com [104.47.41.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B578132A1A for ; Thu, 14 Sep 2017 07:52:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1HQ41vmcbmQ4GGQ7x8xvXKkanD9+48XjuDQzp6MMnl8=; b=ekXtDmc6ZtbfUjrDQ/dsUyxuisleXReCQuRuG4lhAfKOKdVTuPwu1Nvo4HdVBVwASK3LT6xJf66HnwAkE85eRUQtzzYCa/yv8gJQSCEKJ0/Tf9zwf5sUe082fU/v1aFiGwy5rsDYFVgUNj+S+ZWzf9Ox4s/J6mZFwJ91KJzUWx4=
Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB449.namprd05.prod.outlook.com (10.141.28.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Thu, 14 Sep 2017 14:52:32 +0000
Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0035.010; Thu, 14 Sep 2017 14:52:32 +0000
From: Kent Watsen 
To: Lou Berger , Robert Wilton , "netmod@ietf.org" 
Thread-Topic: [netmod] upcoming adoptions
Thread-Index: AQHTISEQvmg9jr+3gUCv+5ltP9XhHqK0ewcAgAADXwD//857AA==
Date: Thu, 14 Sep 2017 14:52:32 +0000
Message-ID: <19134054-D52E-4A6D-992A-A47F365557AD@juniper.net>
References: <14299503-509D-43BE-A938-0B7B88C3B249@juniper.net> <36ba3d4b-1ae1-0666-12cf-db41e172924b@cisco.com> <75739d75-da96-b340-2403-d0949ac54ed7@labn.net>
In-Reply-To: <75739d75-da96-b340-2403-d0949ac54ed7@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB449; 6:fsWgxo3MBxVORgiXP3/rCPixoyuhNupv8qPizzEx8XPPFkPayWcYLfdQQykkegiWUZDzKrLVKisMR2b3GyABrJvRsDusH92WjNC/PqL9IDyeKPJhkZwVv8b+xKkF13xlMfrEEyCyg2E4c18pfT2WNY0Rm2oGMeCqvvnV+V4D6MZ8+OTJUPJH1mt0uLyul+jRlYj/xTVUfre85deZCVajCrfKLqwkynTbVoOv036geMrZRJNra2E3Hmt0nQisQkgRubhUfD2WwJ6Ii5qe/V/iRnVzn346gbMVHyEaYZXYOa3SokEas1pxx2m4K6QjA8BfFV5dFPdV0oy9K3IE4HKwHg==; 5:I8IorgH+nEfZvWihv0URmKCYSGHcVvjpEKt0GAaQJi6doJdfTtgeS4pTHjS8t71WjHHAdg5/EpRL6ke5MOT8JVtp3WGF+pyYsP5oOmJhNml2rDDcE1oZIbJGOQH1yZemnQUDWKK+CtTjb1FuFPPt8A==; 24:c78om2ficgev31blq1Y2gjdqxA7leJHVu9ZPusGhNJl9FuOnrXWNZzOA1Fo+ruX+AT4n02kmLpvzbcx6nXSsLRbBdbiRYnwSiVQUmOh/K2U=; 7:s3vx2/dCsUgmDpl3NIV66rR1z3GRaoJ1sM93Sc/zFasXubyVoWSAqjPmaEpPo02t8unBzIWGEghMCVT6UgTVZOMIgyBD7n/I05uYXclaVErl+f/lJl3HZbh5huNJATm/ucENltCV6ZVatsbdm16CVLxcS9fUtcc7o7rWEV2jg64KxZukkAyTGGb2o5trfv5asSBOoWaexxruo9lnDkEUldvs83sdQVl7O6CqZPH3Z2o=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: d143ad69-17c8-4f49-bd7d-08d4fb803acc
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR05MB449; 
x-ms-traffictypediagnostic: BLUPR05MB449:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-exchange-antispam-report-test: UriScan:(788757137089);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB449; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB449; 
x-forefront-prvs: 0430FA5CB7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(199003)(51444003)(377454003)(189002)(24454002)(82746002)(99286003)(966005)(14454004)(53546010)(6306002)(6246003)(53936002)(105586002)(66066001)(6512007)(25786009)(102836003)(478600001)(33656002)(2900100001)(6116002)(3846002)(305945005)(36756003)(2950100002)(86362001)(77096006)(6486002)(76176999)(54356999)(97736004)(2906002)(83716003)(106356001)(229853002)(50986999)(7736002)(189998001)(83506001)(68736007)(4001350100001)(2501003)(5660300001)(3280700002)(6506006)(101416001)(316002)(8936002)(3660700001)(81156014)(8676002)(81166006)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB449; H:BLUPR05MB275.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: <07B3B8779302714DAD1D3C57B7EBE551@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Sep 2017 14:52:32.6183 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB449
Archived-At: 
Subject: Re: [netmod] upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Sep 2017 14:52:37 -0000

DQpyZmM4MDIyYmlzLTAyIHNpZ25hbHMgdGhlIGludGVudCB0byBkaXRjaCB0aGUgY3VycmVudC9z
b29uLXRvLWJlLWxlZ2FjeSBtb2R1bGUsIGJ1dCBkb2VzIGl0IGFjdHVhbGx5IHNheSBpdD8gIChJ
IGNhbid0IGZpbmQgaXQpDQoNClRoZSBkcmFmdCBkb2VzIHNheSB0aGF0IGl0IG9ic29sZXRlcyA4
MDIyLCBidXQgSSdtIHVuc3VyZSBpZiB0aGF0J3MgZ29pbmcgdG8gaGF2ZSBhIG1lYW5pbmdmdWwg
aW1wYWN0IGluIHRoZSB3aWxkLiAgSSB0aGluayBKdWVyZ2VuIHNhaWQgdGhleSBoYWQgdGhpcyBp
c3N1ZSB3aXRoIE1JQjIgYW5kIG9ubHkgYWZ0ZXIgYSBjb3VwbGUgeWVhcnMgb2YgbWlzdXNlIGRp
ZCB0aGV5IHJlcHVibGlzaCB0aGUgbGVnYWN5IE1JQnMgd2l0aCBkZXByZWNhdGVkIHN0YXR1cy4N
Cg0KSSdtIG9rYXkgd2l0aCB0aGlzIGNoYW5nZSBiZWluZyBtYWRlIGFmdGVyIGFkb3B0aW9uLCBz
byBsb25nIGFzIHRoZXJlJ3MgZ2VuZXJhbCBhZ3JlZW1lbnQgdG8gZG8gaXQuICBBcmUgdGhlIGF1
dGhvcnMgb2theSB3aXRoIGl0LCBvciBhcmUgdGhlcmUgYW55IGJldHRlciBzdWdnZXN0aW9ucz8N
Cg0KUFM6IFNhZGx5LCB0aGUgJ21vZHVsZScgc3RhdGVtZW50IGRvZXMgbm90IGhhdmUgJ3N0YXR1
cycgYXMgYSBzdWJzdGF0ZW1lbnQgW0kganVzdCBhZGRlZCB0aGlzIG9taXNzaW9uIHRvIHRoZSB5
YW5nLW5leHQgdHJhY2tlcl0uICBJIHRoaW5rIHRoZSBvbmx5IHdheSB0byAiZGVwcmVjYXRlIGEg
bW9kdWxlIiBpcyB0byBpbnN0ZWFkIGRlcHJlY2F0ZSB0aGUgYWxsIHRoZSBub2Rlcy9ycGNzL25v
dGlmaWNhdGlvbnMgaW4gdGhlIG1vZHVsZS4gIEtpbmQgb2YgdWdseSwgYnV0IGl0J3MgZm9yIGEg
ZGVwcmVjYXRlZCBtb2R1bGUsIHNvIHdobyBjYXJlLCByaWdodD8gIDspDQoNCktlbnQNCg0KDQot
LQ0KDQpIaSBSb2IsDQoNCk9uIDkvMTQvMjAxNyA5OjM3IEFNLCBSb2JlcnQgV2lsdG9uIHdyb3Rl
Og0KPiBIaSBLZW50ICYgTG91LA0KPg0KPiBXaGVuIGRvIHlvdSB0aGluayB0aGF0IGl0IHdpbGwg
YmUgcG9zc2libGUgdG8gc3RhcnQgdGhlIGFkb3B0aW9uIHByb2Nlc3MgDQo+IG9uIHRoZXNlIGRy
YWZ0cz8NCj4NCj4gSSB0aGluayB0aGF0IHRoZSBmaXJzdCB0d28gYXQgbGVhc3Qgd291bGQgc2Vl
bSB0byBiZSByZWFkeSBmb3IgDQo+IGFkb3B0aW9uLiAgRm9yIHRoZSAzcmQgZHJhZnQsIHRoZXJl
IHN0aWxsIHNlZW1zIHRvIGJlIGFuIG9wZW4gcXVlc3Rpb24gDQo+IG9mIHdoYXQgdG8gZG8gd2l0
aCB0aGUgb2xkIHN0YXRlIHRyZWUsIGJ1dCBwcmVzdW1hYmx5IHRoYXQgY291bGQgYmUgDQo+IHNv
bHZlZCBhZnRlciB0aGUgZHJhZnQgaGFzIGJlZW4gYWRvcHRlZD8NCkkgc2VlIGFuIHVwZGF0ZSBm
b3IgdGhlIHRoaXJkIHdhcyBwdWJsaXNoZWQgeWVzdGVyZGF5DQooaHR0cHM6Ly90b29scy5pZXRm
Lm9yZy9odG1sL2RyYWZ0LWFjZWUtbmV0bW9kLXJmYzgwMjJiaXMtMDIpICB0aGF0DQpjbGFyaWZp
ZXMgdGhlIGludGVudCBpcyB0byByZXBsYWNlIHRoZSBjdXJyZW50IG1vZHVsZXMsIGFuZCBwcmVz
dW1hYmx5DQpvYnNvbGV0ZSA4MDIyLiAgQW5kIG5vdyB0aGF0IHRoaXMgaW50ZW5kZWQgZGlyZWN0
aW9uIGlzIGNsZWFyIGluIHRoZQ0KZHJhZnQgd2UgY291bGQgcG9sbCBpdC4NCg0KSSB0aGluayB0
aGlzIHN0aWxsIGRvZXNuJ3QgYWRkcmVzcyBpZiB3ZSBuZWVkIHRvIGluZGljYXRlIHRoYXQgdGhl
DQpyZmM4MDIyIGRlZmluZWQgbW9kdWxlcyBhcmUgZGVwcmVjYXRlZCBieSBzb21lIG90aGVyIG1l
Y2hhbmlzbXMgdGhhbg0KanVzdCByZXBsYWNpbmcgdGhlIFJGQywgZS5nLiwgYnkgdXBkYXRpbmcg
dGhlIG9sZCBtb2R1bGVzIHdpdGggYWxsIG5vZGVzDQptYXJrZWQgYXMgZGVwcmVjYXRlZC4gIEkg
dGhpbmsgeW91J3JlIHJpZ2h0IHRoYXQgdGhpcyBjb3VsZCBiZSBkb25lIHBvc3QNCmFkb3B0aW9u
LiAgT2YgY291cnNlIG90aGVycyBhcmUgZnJlZSB0byBkaXNhZ3JlZS4NCg0KSSBjaGVjayB3aXRo
IEtlbnQgYW5kIHNlZSB3aGF0IGhlIHRoaW5rcy4NCg0KVGhhbmtzLA0KTG91DQoNCj4NCj4gVGhh
bmtzLA0KPiBSb2INCj4NCj4NCj4gT24gMzAvMDgvMjAxNyAwMDo0NiwgS2VudCBXYXRzZW4gd3Jv
dGU6DQo+PiBIZXkgZm9sa3MsDQo+Pg0KPj4gQXMgZGlzY3Vzc2VkIGF0IHRoZSBsYXN0IG1lZXRp
bmcsIHdlIGFyZSBoZWFkaW5nIHRvIHJldmlzaW5nIGV4aXN0aW5nIFJGQ3MgdG8gYWxpZ24gdGhl
bSB3aXRoIE5NREEuICBUaGUgZmlyc3QgYmF0Y2ggaGF2ZSBiZWVuIHB1Ymxpc2hlZCBhcyBpbmRp
dmlkdWFsIGRyYWZ0czoNCj4+DQo+PiAxLiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh
ZnQtYmpvcmtsdW5kLW5ldG1vZC1yZmM3MjIzYmlzLTAwDQo+PiAyLiBodHRwczovL3Rvb2xzLmll
dGYub3JnL2h0bWwvZHJhZnQtYmpvcmtsdW5kLW5ldG1vZC1yZmM3Mjc3YmlzLTAwDQo+PiAzLiBo
dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYWNlZS1uZXRtb2QtcmZjODAyMmJpcy0w
MA0KPj4NCj4+IFBsZWFzZSB0YWtlIGEgbG9vayAoY29tbWVudHMgd2VsY29tZSEpIGFuZCBzdGF5
IHR1bmVkIGZvciB0aGUgcmVsYXRlZCBhZG9wdGlvbiBjYWxscy4NCj4+DQo+PiBUaGFua3MsDQo+
PiBLZW50IChhbmQgTG91KQ0KPj4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KPj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4gbmV0bW9kQGll
dGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K
Pj4gLg0KPj4NCj4NCg0KDQoNCg==


From nobody Thu Sep 14 08:02:51 2017
Return-Path: 
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 D8BB0132D43 for ; Thu, 14 Sep 2017 08:02:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 Iw15-USJ7kZW for ; Thu, 14 Sep 2017 08:02:43 -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 5744913291C for ; Thu, 14 Sep 2017 08:02:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3237; q=dns/txt; s=iport; t=1505401363; x=1506610963; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=rBQjYfRN5P15rhtiaSSWnI3j47nG19YwmXHPHZ2iJyU=; b=YEpscymMPelSf15lpzJSd7pUA3gb+zn+K08K8LqojgTs8lsiL2UGTrEP JVPEupLdtuApO51ZVqxzcEnBrDdBbuCwvFzbXsZTbjajpeMbEwILygj7Q vWcobNLwdzwlQ8qsAt9l43ogGst7QTg5Bis0OIa895vBHPQiCeucoia0B s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CPAQCJmLpZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD5uJ4N3ixSQRgkiliiCEgoYC4RKTwKEZRYBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQEBAQIBAQEhFTYbCw4KAgImAgInMAYBDAYCAQGKJggQrAeCJ4syAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBGAWBDoIdg1KBYysLgnKIC4JgBaECh1qMeIIThWiDWoc?= =?us-ascii?q?hiX+DXYdVgTkmByqBDTIhCBwVSoUZHIFoPzaIbQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.42,393,1500940800"; d="scan'208";a="655643006"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Sep 2017 15:02:39 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8EF2cJp000804; Thu, 14 Sep 2017 15:02:38 GMT
To: Kent Watsen , Lou Berger , "netmod@ietf.org" 
References: <14299503-509D-43BE-A938-0B7B88C3B249@juniper.net> <36ba3d4b-1ae1-0666-12cf-db41e172924b@cisco.com> <75739d75-da96-b340-2403-d0949ac54ed7@labn.net> <19134054-D52E-4A6D-992A-A47F365557AD@juniper.net>
From: Robert Wilton 
Message-ID: <2891bd09-0e0d-415c-2714-15141a293e42@cisco.com>
Date: Thu, 14 Sep 2017 16:02:38 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <19134054-D52E-4A6D-992A-A47F365557AD@juniper.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Sep 2017 15:02:50 -0000

On 14/09/2017 15:52, Kent Watsen wrote:
> rfc8022bis-02 signals the intent to ditch the current/soon-to-be-legacy module, but does it actually say it?  (I can't find it)
>
> The draft does say that it obsoletes 8022, but I'm unsure if that's going to have a meaningful impact in the wild.  I think Juergen said they had this issue with MIB2 and only after a couple years of misuse did they republish the legacy MIBs with deprecated status.
So rfc8022bis-02 publishes the v2 module, and the the deprecated version 
of the v1 module as an appendix?

>
> I'm okay with this change being made after adoption, so long as there's general agreement to do it.  Are the authors okay with it, or are there any better suggestions?
>
> PS: Sadly, the 'module' statement does not have 'status' as a substatement [I just added this omission to the yang-next tracker].  I think the only way to "deprecate a module" is to instead deprecate the all the nodes/rpcs/notifications in the module.  Kind of ugly, but it's for a deprecated module, so who care, right?  ;)
I see "kind of ugly" as a feature in the this case, someone looking at 
the updated v1 module isn't going to be able to miss that whatever they 
are looking at is deprecated. ;-)

Rob


>
> Kent
>
>
> --
>
> Hi Rob,
>
> On 9/14/2017 9:37 AM, Robert Wilton wrote:
>> Hi Kent & Lou,
>>
>> When do you think that it will be possible to start the adoption process
>> on these drafts?
>>
>> I think that the first two at least would seem to be ready for
>> adoption.  For the 3rd draft, there still seems to be an open question
>> of what to do with the old state tree, but presumably that could be
>> solved after the draft has been adopted?
> I see an update for the third was published yesterday
> (https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-02)  that
> clarifies the intent is to replace the current modules, and presumably
> obsolete 8022.  And now that this intended direction is clear in the
> draft we could poll it.
>
> I think this still doesn't address if we need to indicate that the
> rfc8022 defined modules are deprecated by some other mechanisms than
> just replacing the RFC, e.g., by updating the old modules with all nodes
> marked as deprecated.  I think you're right that this could be done post
> adoption.  Of course others are free to disagree.
>
> I check with Kent and see what he thinks.
>
> Thanks,
> Lou
>
>> Thanks,
>> Rob
>>
>>
>> On 30/08/2017 00:46, Kent Watsen wrote:
>>> Hey folks,
>>>
>>> As discussed at the last meeting, we are heading to revising existing RFCs to align them with NMDA.  The first batch have been published as individual drafts:
>>>
>>> 1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00
>>> 2. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00
>>> 3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00
>>>
>>> Please take a look (comments welcome!) and stay tuned for the related adoption calls.
>>>
>>> Thanks,
>>> Kent (and Lou)
>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>> .
>>>
>
>


From nobody Thu Sep 14 08:11:46 2017
Return-Path: 
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 3A833132FA7 for ; Thu, 14 Sep 2017 08:11:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 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_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 tE2DubeUqlVy for ; Thu, 14 Sep 2017 08:11:32 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0135.outbound.protection.outlook.com [104.47.36.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A93AB132F7A for ; Thu, 14 Sep 2017 08:11:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+H92+oDe11PMi1NSUMgFPPLgw2tdz3fHXgwK7i4bBck=; b=S0O4IyVJoidQpFULXIIrez4IQdQF2U59x0Iu0Kc17m250IK5I2VD8c2jObYCpmgMfNJSC60o+TRQw16wbPxtpzKXgdBhgTirfRzA4F0YH8S5CuPN7V3vh3c4x26bYogzm6c7T8B+XJVBKvLjI+JvptgQjG7E7IaQ3xDUHXABJk4=
Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB404.namprd05.prod.outlook.com (10.141.26.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Thu, 14 Sep 2017 15:11:31 +0000
Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0035.010; Thu, 14 Sep 2017 15:11:31 +0000
From: Kent Watsen 
To: Robert Wilton , Lou Berger , "netmod@ietf.org" 
Thread-Topic: [netmod] upcoming adoptions
Thread-Index: AQHTISEQvmg9jr+3gUCv+5ltP9XhHqK0ewcAgAADXwD//857AIAARd8A//+/bgA=
Date: Thu, 14 Sep 2017 15:11:31 +0000
Message-ID: 
References: <14299503-509D-43BE-A938-0B7B88C3B249@juniper.net> <36ba3d4b-1ae1-0666-12cf-db41e172924b@cisco.com> <75739d75-da96-b340-2403-d0949ac54ed7@labn.net> <19134054-D52E-4A6D-992A-A47F365557AD@juniper.net> <2891bd09-0e0d-415c-2714-15141a293e42@cisco.com>
In-Reply-To: <2891bd09-0e0d-415c-2714-15141a293e42@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB404; 6:Vs/Mm7WHKm/gY5VGhgi0ogfQlxsgosOICb6nzTmZzpzqdUeONsBZr4cltBEppg8UHZvCMjIZaRfFPO3eiytDdI+NPp7x3Zr9Ax/ZImUed5r1GLjY2nmTLJeJ//xKfhULWB2M3T5P0HhgaZ0/WRF/HZqZ3+BJ/ouQRo3PE+6/IFHheNj/+HD9a7+so9rJWwe/2smHYwAT5tyitHKRSW5GqrX5uaW0Gw3ZP9b5NuZoWIHyjt8jFfEBJ68cjPKPoT2izjzZcl5lteXsDok2ehONaykcdQ5j8W3QNMOi006TwRBcNhR9CWYnvk8yOybqKVyORPB6Q/7q3hXDCvQ+8R4pMA==; 5:W73lw2t4ae4Gyc6LR0daO7uqw8VqnmRUjyG3nDgt6RSpSTfOUtbvihYdO3+jfrcOpVmFljEXk3phxMnfrenoBv1yCEs6rBErYsE5zK874aGKb9QCDPuknK0VEt9Vt1veaHnewVR35gZcTfJ632zYlw==; 24:RNAMHUXn46h4wtiivC6GBJIpy/JyI7Zq+Ejohc981deNfs06CO7C7yrS16FZVtzHbDXRVB4LG+xdIlLraMNnvN9Ha1a6GYXGNQ3K2ygxVC0=; 7:453CqT40jYkhaD6T3EhPXu+65AZTqzn5mfV8Jp+NAOTn9Gbr92txXTSIUNiXwpjiSpJB3GIgKPvZg6b/1PzPEv8gpczPosxVuagxxjDooCJ8RW5FaMny68GMyuboJ2E6I0Si1Yr4VzZFeubHbuVHX6/3wppESzMsEUCniHgQ3hY6VP8jyvSbzmjSYIMYg7d4W2CiGFyH2KRhaPgU4/exTVfXXgDpjGrYlti4FwbL87U=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 2e15962a-41de-44df-f02c-08d4fb82e177
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR05MB404; 
x-ms-traffictypediagnostic: BLUPR05MB404:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-exchange-antispam-report-test: UriScan:;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123555025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB404; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB404; 
x-forefront-prvs: 0430FA5CB7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(376002)(346002)(39860400002)(199003)(189002)(8936002)(3660700001)(478600001)(3280700002)(83506001)(2906002)(83716003)(33656002)(229853002)(68736007)(316002)(2900100001)(6512007)(82746002)(86362001)(7736002)(66066001)(54356999)(36756003)(3846002)(8676002)(6116002)(4001350100001)(102836003)(81166006)(99286003)(50986999)(97736004)(77096006)(5660300001)(6486002)(2950100002)(25786009)(81156014)(2501003)(76176999)(93886005)(6506006)(14454004)(53936002)(105586002)(106356001)(305945005)(189998001)(101416001)(6246003)(6436002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB404; H:BLUPR05MB275.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: <70477A54DFB47E41A6B385F9C9584BB8@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Sep 2017 15:11:31.0949 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB404
Archived-At: 
Subject: Re: [netmod] upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Sep 2017 15:11:34 -0000

DQoNCg0KPiBTbyByZmM4MDIyYmlzLTAyIHB1Ymxpc2hlcyB0aGUgdjIgbW9kdWxlLCBhbmQgdGhl
IHRoZSBkZXByZWNhdGVkIHZlcnNpb24gDQo+IG9mIHRoZSB2MSBtb2R1bGUgYXMgYW4gYXBwZW5k
aXg/DQoNCkxvdSBhbmQgSSB3ZXJlIGp1c3QgZGlzY3Vzc2luZyBpZiBhcHBlbmRpeCBjYW4gYmUg
bm9ybWF0aXZlIG9yIG5vdC4gIEkgYWx3YXlzDQp0aG91Z2h0IG5vLCBidXQgSSBoYXZlbid0IGNo
ZWNrZWQuICBUaGlzIGlzIGEgZ3JleSBhcmVhLCBpbiB0aGF0IHVuZGVyc3RhbmRpbmcNCnRoYXQg
dGhlIG9sZCBtb2R1bGUgaXMgZGVwcmVjYXRpbmcgaXMgbm90IG5lZWRlZCBpbiBvcmRlciB0byB1
bmRlcnN0YW5kIHRoZQ0KbmV3IG1vZHVsZSwgYW5kIHdlIHJlYWxseSBqdXN0IHRvIGVuc3VyZSBl
eHRyYWN0aW9uIHRvb2xzIHdvcmsuLi4NCg0KDQo+IEkgc2VlICJraW5kIG9mIHVnbHkiIGFzIGEg
ZmVhdHVyZSBpbiB0aGUgdGhpcyBjYXNlLCBzb21lb25lIGxvb2tpbmcgYXQgDQo+IHRoZSB1cGRh
dGVkIHYxIG1vZHVsZSBpc24ndCBnb2luZyB0byBiZSBhYmxlIHRvIG1pc3MgdGhhdCB3aGF0ZXZl
ciB0aGV5IA0KPiBhcmUgbG9va2luZyBhdCBpcyBkZXByZWNhdGVkLiA7LSkNCg0KRnVubnksIGFu
ZCB0cnVlDQoNCg0KSy4NCg0KDQo=


From nobody Thu Sep 14 08:34:01 2017
Return-Path: 
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 8FF49132D67 for ; Thu, 14 Sep 2017 08:33:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 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, 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 EYWtgcGh9npn for ; Thu, 14 Sep 2017 08:33:58 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 398DD124239 for ; Thu, 14 Sep 2017 08:33:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1240; q=dns/txt; s=iport; t=1505403238; x=1506612838; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=QyGord9g/E4N8E9QMc4Cz5nwbTvPpy7U586F8Qss7V4=; b=iR8A51Ir1lid/m2Vu5Jko3e2EFtmg5gRW6ywjN/cjq/KMLKqVlAchjfb zUb7ugsRrWnaJC7ZDh534FDl/iWBxdJCKcNhlh3mDTtbMBpfaZU28dxzB ZrgHDMesisJ9RgXMzPOKrVrfy4+bG9Qz6U/p0BZVCnpZVbZw6J+CnafJ2 A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AMAwBHoLpZ/4sNJK1dGwEBAQMBAQEJA?= =?us-ascii?q?QEBg1pkbieDd5tamGUKG4lHQxQBAgEBAQEBAQFrHQuFQgQLAXsCJgJfDQgBAYo?= =?us-ascii?q?urCKBbTqLMgEBCAImgQ6CHYICgVCCDosIgmAFjCeFB4cPiEWBbIVujHiCbohnh?= =?us-ascii?q?yGVMYE5NiGBDVMkFYgCJDaIbQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.42,393,1500940800"; d="scan'208";a="77420358"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Sep 2017 15:33:57 +0000
Received: from [10.118.87.94] (rtp-jclarke-nitro13.cisco.com [10.118.87.94]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v8EFXvMm002844 for ; Thu, 14 Sep 2017 15:33:57 GMT
To: "netmod@ietf.org" 
From: Joe Clarke 
Organization: Cisco
Message-ID: <9d84d068-29ba-8e89-394f-b7f6a5272adc@cisco.com>
Date: Thu, 14 Sep 2017 11:33:56 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Sep 2017 15:33:59 -0000

I've been hacking on pyang, and I changed tree.py to add the enum values
for enumeration types and identiyref bases for identityref types.  Here
is an example:

module: yang-catalog
    +--rw catalog
       +--rw modules
       |  +--rw module* [name revision organization]
       |     +--rw name                     yang:yang-identifier
       |     +--rw revision                 union
       |     +--rw organization             string
       |     +--rw ietf
       |     |  +--rw ietf-wg?   string
       |     +--rw namespace                inet:uri
       |     +--rw schema?                  inet:uri
       |     +--rw generated-from?          enumeration [mib, code,
not-applicable, native]
       |     +--rw maturity-level?          enumeration [ratified,
adopted, initial, not-applicable]
...
                               +--rw protocols
                               |  +--rw protocol* [name]
                               |     +--rw name
identityref -> protocol
...

My questions are:

1. Is this useful?

2. If so, can this be added to pyang (happy to submit a PR) and
draft-ietf-netmod-yang-tree-diagrams?

3. What changes to the output format would you recommend?

Thanks.

Joe


From nobody Thu Sep 14 08:36:06 2017
Return-Path: 
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 6B285124319 for ; Thu, 14 Sep 2017 08:36:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.387
X-Spam-Level: 
X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, 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, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ericsson.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 kwLYlo7hk2Tc for ; Thu, 14 Sep 2017 08:36:01 -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 660A9124239 for ; Thu, 14 Sep 2017 08:36:01 -0700 (PDT)
X-AuditID: c1b4fb3a-617ff700000051a3-1e-59baa1dfde53
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A0.A3.20899.FD1AAB95; Thu, 14 Sep 2017 17:35:59 +0200 (CEST)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.57) with Microsoft SMTP Server (TLS) id 14.3.352.0; Thu, 14 Sep 2017 17:35:58 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jodVCqBkWsx0DxLynnE6dgoA+3DyzI6DkYiVFyyUGnQ=; b=GjWINBMqE1EXa/Csq003sAHpVUVA6tu3/ZiTc1ThL0++v4jAgmO334pfQ0+to6NaytOc1BdORSgdYb3pWmM9Jc6CpObT1GR10kGoTmRZu9opyb7mEOndtEyyx6COyn10st3JQ9AWgtViOQxv+cbcTqRuyoclXevYxShYQxpmmIw=
Received: from [159.107.197.117] (91.82.100.59) by AM4PR07MB3428.eurprd07.prod.outlook.com (2603:10a6:205:b::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Thu, 14 Sep 2017 15:35:57 +0000
To: Martin Bjorklund 
References: <9ec6b2e4-36a7-87e6-59fa-828855235835@ericsson.com> <20170914.163239.143365521945928900.mbj@tail-f.com>
CC: 
From: Balazs Lengyel 
Message-ID: <4ce3efcd-6e88-9390-1241-21fb89985a9a@ericsson.com>
Date: Thu, 14 Sep 2017 17:35:51 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <20170914.163239.143365521945928900.mbj@tail-f.com>
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [91.82.100.59]
X-ClientProxiedBy: HE1PR05CA0142.eurprd05.prod.outlook.com (2603:10a6:7:28::29) To AM4PR07MB3428.eurprd07.prod.outlook.com (2603:10a6:205:b::13)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: c7a213a3-87e7-4bcf-75e7-08d4fb864b8b
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM4PR07MB3428; 
X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3428; 3:z/ow5tDM5IhPisHbzcPQBXGi11TMoHoe8iGQmKGX5vm3cZdrTmiYCS/wk5siwa273jXmujBsrA86cdSYrd9HlgxIDfUcgl3/pwBg+PU9WOz6DsGGl5Kqh1HcIx7U3sDSwfNQXPesz5BKiXzUL5+UqwEdFQ/3kBDboBLvvM0m0Mx38CI8l7pcFMen/QLQGKvKxQZLiSh9NAIl+Rm1t9zGP7OTFpJDfbgNBXYTR7owL/uqvZKq7bh5Ms0SegYNOYpM; 25:JaqzcUo19XKflDgxHW+w7NhOar1rWoLvULHu+wPuCCEWEBb4IFe1oZZbfY+OtbhDPVCK+8U6zcXpJ8RGb3aOzzri9Pb3XbGP+ryB/6KJAZXbov/fftonS78GDphrEKF8nJdVswWmuwKi+tATZen4Lxmp7+gcasl4G8uz/kxPc/IyE+biB+ncTWYsVbXcuRZow83rPsYoHsBLrrZRQMryLQgNjzZvWl0e7DXk1tzENjJYNoUST52DXfMSnmFD+hAp4pPUpslgt6JAy86S3lRrP6aKJdhpWT8VEMERMotKVPlOyf8Z5Cz6ZwCKkQPJocWy6uBzdHDWMqUVY/jPva+MdQ==; 31:7QyMMNUYaXV0NWFZLk5wfOtYBTHqSKc3iVRrjoAtWgBtkyjzImujYsWRblot+BgJ8ohgHeUs+5lOLT0krD06PDLEx/e1SAZWGjdOmr6kU3djY7xqbqwWOmAGO8olQwcQClyCK9YUjNe2yTEg243/i3/Na8QqZbuG2WpTPKavN8lefO5L1daKOCqHZwq8UPpEB5K1KVtTHz6Fi6UyogY3u/+0TfSYyQkEd91fXnKldxw=
X-MS-TrafficTypeDiagnostic: AM4PR07MB3428:
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3428; 20:dmpRv33t5gNQz5BdwTR688PxoS6S/NTJk+apt5uAtwp+7hAQhPX12OsGgDTBRMshXZb8X1rkVQxtbnA/QCw8qx05IVQcyteVEzN1wleH9yGx/kGtt6liAm7qN04xOu3bozoCx9vJyb441+VTciGzgV9Q5bQEC0i+62byYdLosCg61xkVo/+qJO9qrEu3CVjn5Bvz7pewx1ix7UPIfwFQtHFpGpzU+z/JdwEAVYjwz9ZoiPSLSJyiKyyVhFYeAqv7LiS5k4MnlRyRWtlgqd0xBygaaFuShiKGrGXmgEcQmcqynrmn4it4oK3NC9mC9/5zAaYSydMaYmGhElg/C+gO4XCS8fH8ehkgJt+A9i3Ej+7sfKvrFD3e5ZFkZCn5KYy71cY7moA2iLrezhxUEUzBcF98SJiUZmcETQldf6GSFakOwF10sX0vaCxadFpNDSXUNbxo994UmD5VGIk3Nra54xUNeVjwuxMvctaYvXsS3CWqDzFHS3xP0kucrrKmhS0Q; 4:tdW4QNsZaM3LKuFghajXISqiFFtiHNC2mWwadd1gjg4FERWX5OCKfWzSZu5w47aC0HEcGHg+Y5iLFsqzU5nU2o6pfE7+njoXJgEzkK4YpGGFkEiRq+CSapCCMxXYSRMRt/HEd5PV0qdIpXk4QNNVNIAPM67Hl3HqCh/bCq/Hmxxshm9hTFVWX0rCM5TvlKMpDnK7uI7F1Nt0I7Y7aUQb0suYu6d/dRQkcXy3oIoic6PzcKH01kgZEZPtCPkvZSjZ7K0xOUTgScvoPZSznMtBaetmNh21gadG10RMLhE1+zmp0uwPhBaUKqO90HMRX1B9osoirHcXUZ//PjCUJJfpR7ZVzI/grVMXHGMnIeN1HzprrXdux9g2gM4La9+13rPu
X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(158342451672863)(100405760836317); 
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR07MB3428; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR07MB3428; 
X-Forefront-PRVS: 0430FA5CB7
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(7370300001)(6049001)(39860400002)(346002)(376002)(199003)(51444003)(377424004)(189002)(24454002)(252514010)(36756003)(83506001)(189998001)(7350300001)(6486002)(53936002)(16526017)(2906002)(236005)(86362001)(16576012)(6116002)(53546010)(3846002)(2870700001)(316002)(2950100002)(6916009)(31696002)(25786009)(8676002)(101416001)(68736007)(4001350100001)(105586002)(50466002)(31686004)(23846002)(6666003)(50986999)(81166006)(81156014)(110136004)(49976008)(478600001)(64126003)(66066001)(76176999)(54356999)(65956001)(7736002)(65806001)(65826007)(5660300001)(97736004)(33646002)(106356001)(4326008)(561944003)(23746002)(78286006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB3428; H:[159.107.197.117]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; AM4PR07MB3428; 23:/yms2apVoANdfafnKy5QyHfyMI57NlFvEQN1L?= =?Windows-1252?Q?dmMWWO8uP28Cb6t0D+2AtHx2WK4nIDg5PDAYNA/bE9b6VLy3n4WoX4Xd?= =?Windows-1252?Q?2BsPB46aspO4oqR6DVq9G8hm+ZVJ42Q6zr/ax8CW9XR6ucOrIEa374zF?= =?Windows-1252?Q?0ORDbOe8aMQQWNep1R4c7du4n47tY3FUyQkPRkyzz3EN8i/WyMSr+IyA?= =?Windows-1252?Q?OxOGZrqKV6Ck4zTNrRA33qE+MtoLziyfBCPUOahlYDrEJqNqhPxyF6Cq?= =?Windows-1252?Q?J1pEWe31dtJTlU1fpubh5N/bmswXWrVhcbj7cl975/yjVIw2VQL30a65?= =?Windows-1252?Q?X6fiWdz71ylqdKtWKLIGmVn0pL0EyBFtzeh9s4SOLQdOEW5IdX9WFKof?= =?Windows-1252?Q?XlLY9QMpIi89yTAzre3gy96KW+nZdwHKarUlsSA2NFSWXkSRe5ieBr8O?= =?Windows-1252?Q?8GBd1QKfTD8RlCyDBF8lNlQKAwlBiolAuXbKIcx7Xc1QeyceiFMFnSRK?= =?Windows-1252?Q?Ut6/5kiNxXjwSI07o7LJv6OGUNLeXKZNbNhv+Q2pvuMOIU0DHlM18ZrP?= =?Windows-1252?Q?O7FqaUYTv9SlhirMJTOAVIc1xLH3mBQdUtlEBFgoU9yqluK3RS+2kWSn?= =?Windows-1252?Q?ellcOrV/WCEzXEs/sBI/FyBcdzj/wJacAC7K4kRMG3ftHvPk+NMesgQO?= =?Windows-1252?Q?Y2rhrePJiCOIBlDEw2r5+5wX8rH2WEzuSbEFXkXO90sWzYjpHIXeHttY?= =?Windows-1252?Q?D7+NEvquvQOxa2YX6aw5euA7ptRPLHp1Q7EZYA5uKIh9mEMrcK1ZDKdg?= =?Windows-1252?Q?pkKMnynTxTe8p9sLrCz/a7Vs4CnjO64hXSc+cNxFXEiM9WPkl/QxNaaH?= =?Windows-1252?Q?MLBBVH2ohDDCW/RD/HMyQfa0X+H4knJGOovAXErhmCwlUeTv1w8gxf2O?= =?Windows-1252?Q?vszw1Ny3+dI047FDPASirA84ut0JHtgy9Enb/1Pm8fZFwOqcnC3iDrE+?= =?Windows-1252?Q?OkMbSprbKVMZdpkeueYm7kB07TRKhba9sSLZ9ViDFY0CU6ysqJz/6q3P?= =?Windows-1252?Q?+3uImyyEool/VqQqL7ynXQvS4TxP0WWxDBCVYmfukVgNusEQfRLxDt79?= =?Windows-1252?Q?S3yw/zmCUvUd5xT+gRsRVHBpUjbnMdCigkrLPEElruAxWngiIQwhwRsf?= =?Windows-1252?Q?CGtA/9JEsCQmsc3TrKnFYAn7sb/6gvEA2wrb8L0zF5pmDpLTexzOhBCD?= =?Windows-1252?Q?3VneCgTn2EWKx3INCNApWLbdR8pUwhzOKOc7ZHRIKI6e53H4q7nz63P1?= =?Windows-1252?Q?tTAs5M+goSr5C75DoOb/sXlQbsLv+pHCSyQAcXwMe4T0UyFI7NARWaPB?= =?Windows-1252?Q?/1LRrxxpMvn7wxcODOGw3cXBl35oEuoG0zMyqaKVfQ589sMNWUazq0W/?= =?Windows-1252?Q?3k3cq6Schysy/2X3o5an75F1NvG3B+CoxuSDAmXIOrwTTdfSI70wmzZY?= =?Windows-1252?Q?qtQSnwpwXvdDm5PsCoYcxHdXcg7K2ftT5s9oW6tdt2ibN4/FzSva1ewC?= =?Windows-1252?Q?k6yrFB1K63uNnLbxJAgvq2GALbOsBWlC5p8QX1vztWscAbawTb3XOcxN?= =?Windows-1252?B?dz09?=
X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3428; 6:Z0DrktQuGVifVBG5d13TVH2QtMRcNCzGtrNhyjnhkL2cuREbMpNYDGMWi10IfozzUAibLfOxPm6yyOTfLz0+gHb8G79orowOqNao+98xVbvHFAysOxEaAEHWGf4qvu/2OUuCuGgapUD166SIw2zGpeh7uASpgy7MvPNPQ7At7CcJo271DhTOWBLqkAoa26T9H2YMo0amZrOmbFcypY8ht8P2qPkYvdus/otfsxSTqaI7JiBTiP4hvqyZYJd0WWfAbm+bzWW27a8R+zrX2Zs/jssYB8J8hN8njJ+FyUJBZr+/tKhBdHT6nHSotFpkwtAv0Q8KC6vVAYq5/wQ6tTZUag==; 5:fVRAJR0kYUOb64LrD6Tfz+7G5dMtK0jwU/OB3YVmzGpCTprawhXeWOl2K3PKpN8XHTUPkdx5JdGrTQtzlDlr9g2yXMQVUAIjsOcxn+kFBl3p1lW/24OZqx5UQMKGQB/fRRs6o5G2wYDnVDexamkoVg==; 24:Rh9Ykmd40cd0i1hKNO97DLbN303piB6iMU8p2lTJwliOrGrOB4ksbtn4Xwx0BAJtDQRSINfA28etai319ju49EeI6Itcy5X/hTRkslbAxCA=; 7:ggLbQvpCEGCuXEkihNCSGcdeApdiZOQXn54ZtWuKxGBqiEjCRJxoUyE+ULD3eNbSgAD6WZu7tD3P/9iT11YRW6bkPmBCXw6QfogbYsaPqoI71jQ7QgXlW/vM63mhGSf2N+U6l9XBesaLCmj9Bn3RQRopFWvSp0fN/85wgiVOavK+tZUolq6y77Fg7kdKTzk3r/ytff2I8HPdhoLSWgx6NuQyQ/aDgzZPS60Glzoks+s=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2017 15:35:57.3952 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3428
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHec9tx+HwtCY9qGEMRJNSG1FakhMqBAv6qCLmyJOKbto5ai6Q FpnMibXArC3BTVeRmmklXspgo4smmiYmkimGLbwQDg2vXTw7C/z2e9/n9395/vDSuHyDCKJz dUUsp9PkKykpYUnpjDs4be9JjVlbgdiqKrcktn7kGqnGkhyOdSypfaOROIelSeOz2PzcEpaL PpEpzbEvqQrLFaXGtW7MgFYDTMiPBuYwNBnrcROS0nLmDQKbyYqJhz4EleZXlHAgmGocFse+ +rQKDP4OtpJCfjeTCg3mMUxgBRMGs91PCIHlTDFsDdVSAuNMIDwd+eR1KEYFd2599DoyJgHc i2ZcYGI7O9W7gAQOZNKh3LGERGcX9Ftmvb4fo4ZNdwcuvhkN45PTpMihcL3jPi722Qfjz8cJ YVFgahDMWDt9C0XAzPBvUpT2wtvBOkLks/C42enjUQx6PAoxbJBAeasHEweRYLzb5t0IMRnQ 3WInRalLAj+bjb50Ojg/GyUi58Hk6hQl8gAJlqEMkUPAszGDxLCdgjbDd8qM9lt3VLXuqGfd Uc+G8CYUyLM8r81WqaJYLvcCzxfoonRs0TO0/SOcLzaPdSHnj0QXYmik9JdFWHtS5aSmhNdr XQhoXKmQnbq9fSXL0uivsFzBea44n+VdKJgmlHtk6tfDKXImW1PE5rFsIcv9n2K0X5ABXfoV 4KirWro8bw3HbfcUX1a02Sf7Y2pu2AbCo5ePShta5jIfOUfX2dabKLHieNmUhZ9bbpckc2l5 Dz64ar91TNjLWG1p7zwppzqrq8Obipv/8J6FZcf7sKuFcf59Ew9D3RkhekflZrB9y3Rm5Ijm 5cV4ZeNp/3cJyV3qtQOEkuBzNIcicY7X/APqafO2DQMAAA==
Archived-At: 
Subject: [netmod] Adding system configuration to running [was: Re: Comments on NMDA-04]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Sep 2017 15:36:04 -0000


  
    
  
  
    
See below!

    

    
On 2017-09-14 16:32, Martin Bjorklund
      wrote:

    

    

      
Hi Balazs,

Thanks for your review.  Comments inline.

Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:


      

        
Hello,

Reading the draft-ietf-netmod-revised-datastores-04 some comments:

General) The system often adds data to the <running> or <intended>
datastore already not just to <operational>: e.g.

UC1: I have a server configured in running. I need to bind it to an
ip-address. The ip-address might be the local loopback address,
however if that is only added to <operational>, validation will
fail indicating that the server is bound to a non-existent
address. How to handle this?

UC2: I have a set of capabilities set by the system
e.g. supported-reporting-intervals. I need to configure a job that
MUST use one of these intervals. If the supported-reporting-intervals
are only added to <operational> I can not validate the
selected-interval in my configured job.

My proposal is to allow the system to add data to running as
well. Actually I think that is a more relevant case then adding
configuration just to <operation>.


      

      
I think the consensus is that in general it is a bad idea if servers
(spontaneously) add data to <running>.  However, there is nothing in
the new or old architectures that prohibits this.

    

    BALAZS: I strongly disagree.  I know others are also adding stuff to
    running as well. 

    IMHO the above use cases are real and used and actually important
    for us. 

    I would like to see them included in some way.

    

    regards Balazs

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


  



From nobody Thu Sep 14 08:39:32 2017
Return-Path: 
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 5DECE13208E for ; Thu, 14 Sep 2017 08:39:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 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, 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 RQCRXG7oN_gb for ; Thu, 14 Sep 2017 08:39:28 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2491124239 for ; Thu, 14 Sep 2017 08:39:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2406; q=dns/txt; s=iport; t=1505403568; x=1506613168; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=pOdvRJYdt9DXfuJEPDcVK7TKi8wiLfLfdgdnK37Ii6o=; b=KfePw5OwE+9uPz7SZBi4hY+l42BMZmcWANmFSC88BCSf13zgh+RTSPSA fXXMJlRrPS5wrKy1Nd/ZgbfXqiumsmTyA+uMQ4NFb3hO4MciwyXu5r5RU jFMivICwLdPPfVrwyP6zbTNdpeFhOWcVT/0uGhibhyUqRVdj2oPauHqth E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CSAQC6obpZ/5NdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy0tZG4nB4NwnAWWKIISChgLhEpPAhqECkAXAQIBAQEBAQEBayi?= =?us-ascii?q?FGQEBAQMBASEROhsCAQgYAgImAgICJQsVEAIEARKKMhCrfYInizIBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARkFgQ6CHYICgzODKIRRJxeCfIJgBaECAodYjHiCE4Voinu?= =?us-ascii?q?VBAIRGQGBOAEgATaBDXcVSoccdoYsgTKBDwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.42,393,1500940800"; d="scan'208";a="295412781"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Sep 2017 15:39:27 +0000
Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v8EFdRjI022061 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Sep 2017 15:39:27 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 14 Sep 2017 11:39:26 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1263.000; Thu, 14 Sep 2017 11:39:26 -0400
From: "Acee Lindem (acee)" 
To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" ,  Kent Watsen , "netmod@ietf.org" , Lou Berger 
Thread-Topic: [netmod] upcoming adoptions
Thread-Index: AQHTISEQvmg9jr+3gUCv+5ltP9XhHqK0vhUA///cBYA=
Date: Thu, 14 Sep 2017 15:39:26 +0000
Message-ID: 
References: <14299503-509D-43BE-A938-0B7B88C3B249@juniper.net> <36ba3d4b-1ae1-0666-12cf-db41e172924b@cisco.com>
In-Reply-To: <36ba3d4b-1ae1-0666-12cf-db41e172924b@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.80.219]
Content-Type: text/plain; charset="utf-8"
Content-ID: <0AB302FD720BF54C8E790AC6B45513B0@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Sep 2017 15:39:30 -0000

SGkgUm9iLCANCg0KT24gOS8xNC8xNywgOTozNyBBTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgUm9i
ZXJ0IFdpbHRvbiAtWCAocndpbHRvbiAtDQpFTlNPRlQgTElNSVRFRCBhdCBDaXNjbykiIDxuZXRt
b2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YNCnJ3aWx0b25AY2lzY28uY29tPiB3cm90
ZToNCg0KPkhpIEtlbnQgJiBMb3UsDQo+DQo+V2hlbiBkbyB5b3UgdGhpbmsgdGhhdCBpdCB3aWxs
IGJlIHBvc3NpYmxlIHRvIHN0YXJ0IHRoZSBhZG9wdGlvbiBwcm9jZXNzDQo+b24gdGhlc2UgZHJh
ZnRzPw0KPg0KPkkgdGhpbmsgdGhhdCB0aGUgZmlyc3QgdHdvIGF0IGxlYXN0IHdvdWxkIHNlZW0g
dG8gYmUgcmVhZHkgZm9yDQo+YWRvcHRpb24uICBGb3IgdGhlIDNyZCBkcmFmdCwgdGhlcmUgc3Rp
bGwgc2VlbXMgdG8gYmUgYW4gb3BlbiBxdWVzdGlvbg0KPm9mIHdoYXQgdG8gZG8gd2l0aCB0aGUg
b2xkIHN0YXRlIHRyZWUsIGJ1dCBwcmVzdW1hYmx5IHRoYXQgY291bGQgYmUNCj5zb2x2ZWQgYWZ0
ZXIgdGhlIGRyYWZ0IGhhcyBiZWVuIGFkb3B0ZWQ/DQoNClRoaXMgaXMgcHJlZmVjdCB0aW1pbmcu
IFdlIGRpc2N1c3NlZCB0aGlzIGlzc3VlIGF0IHNvbWUgbGVuZ3RoIGluIHRoZSBZQU5HDQpSb3V0
aW5nIERlc2lnbiBUZWFtIGFuZCB0aGUgY291cnNlIHdlIG9uIGlzIHB1Ymxpc2hpbmcgYSBuZXcg
bW9kZWwgd2hpY2gNCmlzIHVuZW5jdW1iZXJlZCBmcm9tIHRoZSBjdXJyZW50IGlldGYtcm91dGlu
ZyBtb2RlbC4gUmVmZXIgdG86DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry
YWZ0LWFjZWUtbmV0bW9kLXJmYzgwMjJiaXMvDQoNClRoYW5rcywNCkFjZWUgDQoNCg0KPg0KPlRo
YW5rcywNCj5Sb2INCj4NCj4NCj5PbiAzMC8wOC8yMDE3IDAwOjQ2LCBLZW50IFdhdHNlbiB3cm90
ZToNCj4+IEhleSBmb2xrcywNCj4+DQo+PiBBcyBkaXNjdXNzZWQgYXQgdGhlIGxhc3QgbWVldGlu
Zywgd2UgYXJlIGhlYWRpbmcgdG8gcmV2aXNpbmcgZXhpc3RpbmcNCj4+UkZDcyB0byBhbGlnbiB0
aGVtIHdpdGggTk1EQS4gIFRoZSBmaXJzdCBiYXRjaCBoYXZlIGJlZW4gcHVibGlzaGVkIGFzDQo+
PmluZGl2aWR1YWwgZHJhZnRzOg0KPj4NCj4+IDEuIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9kcmFmdC1iam9ya2x1bmQtbmV0bW9kLXJmYzcyMjNiaXMtMDANCj4+IDIuIGh0dHBzOi8vdG9v
bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iam9ya2x1bmQtbmV0bW9kLXJmYzcyNzdiaXMtMDANCj4+
IDMuIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hY2VlLW5ldG1vZC1yZmM4MDIy
YmlzLTAwDQo+Pg0KPj4gUGxlYXNlIHRha2UgYSBsb29rIChjb21tZW50cyB3ZWxjb21lISkgYW5k
IHN0YXkgdHVuZWQgZm9yIHRoZSByZWxhdGVkDQo+PmFkb3B0aW9uIGNhbGxzLg0KPj4NCj4+IFRo
YW5rcywNCj4+IEtlbnQgKGFuZCBMb3UpDQo+Pg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+PiBu
ZXRtb2RAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
bmV0bW9kDQo+PiAuDQo+Pg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQo+bmV0bW9kIG1haWxpbmcgbGlzdA0KPm5ldG1vZEBpZXRmLm9yZw0KPmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg==


From nobody Thu Sep 14 08:43:29 2017
Return-Path: 
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 339E013208E for ; Thu, 14 Sep 2017 08:43:27 -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 LMvyGgSLUyuz for ; Thu, 14 Sep 2017 08:43:25 -0700 (PDT)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 119AB124239 for ; Thu, 14 Sep 2017 08:43:25 -0700 (PDT)
Received: by mail-lf0-x231.google.com with SMTP id q132so8173054lfe.5 for ; Thu, 14 Sep 2017 08:43: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=FH1FCeocC/gz5+8HMkcSovGdrASfnuX1Nx4m7QDzoRA=; b=ht1XJ1+KC3QhRjM4rMAtAe2Yn4u/NNRyajU4eAVdeRugi2om1juE6OaHtc3dwS56pP Stl8byZcqXgCSLvCfvDF9UAAoNJ2TDUlssPhEg7UxxfQc93H/aJR0rY+m2ws4sqh/Vfa GG8GiRpC92/y3b6Do91NLlg60G9aM6srJwtZupX79NVVnmMtmCmX3Wxg7DPFA6KNsqJ7 VVHNsdLwjm3fcExHWwhD+P3eSOJM7UnfWwhYWVhwSnRzqi0Y3ngkvBPcjQKstVagZ51B e/jYNhQue3MHSeANtssK3XBKJkeAU18/BTGO4rauFJ4QnA/vlQFy81394c0i7nkmR10G mfuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FH1FCeocC/gz5+8HMkcSovGdrASfnuX1Nx4m7QDzoRA=; b=EUTN6yhMh7rKhYspxKXAOhfD6Z1pvWuBokMgZlHjdPrDuUUhPYb+eykLA8xUHPIelJ EDUJlaLLJa2Rn0s350di22xOhBl58Op5tT6mggtqzghPxpiroe6J8fG6mne4JX6w6eVy rd0dslxhaZEm3G3eF+MQgtg0kvUKgRUFjeD6PziRzHkK39pmTLVcoWJXTUDM2GAI9SV9 G3fwU5wVipqp12mHKs0Q57YDXfFZMD1gRyZOWg+ayDUojwMuX4pAvSA0p6AjOLzMPQJN 7nab6vBmlpBUawLQapn9QaU/BLjQUXi1iug/pJWQH1+x+v+JpmOtbsUCYAxtcimAbkWH T/IA==
X-Gm-Message-State: AHPjjUgNwia37cBl5NSgB/0pyfSD+2/028QD6Re2hq1K14PLmVc0lLvl P4JoBFI+YH6WclIgjq87b3d/EqzOKjyV3cc6RXRZjg==
X-Google-Smtp-Source: AOwi7QDBO00Q5KYuxhxQLsELjhM3WNHnIG+QxPyj3dGRt7IChPEVdzQqSRZsTH3HDRdfvAkZ0pshR6v8apxq32gMvYw=
X-Received: by 10.25.211.14 with SMTP id k14mr8511902lfg.51.1505403803301; Thu, 14 Sep 2017 08:43:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.18.41 with HTTP; Thu, 14 Sep 2017 08:43:22 -0700 (PDT)
In-Reply-To: <9d84d068-29ba-8e89-394f-b7f6a5272adc@cisco.com>
References: <9d84d068-29ba-8e89-394f-b7f6a5272adc@cisco.com>
From: Andy Bierman 
Date: Thu, 14 Sep 2017 08:43:22 -0700
Message-ID: 
To: Joe Clarke 
Cc: "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="001a11400d72f08a3005592822fb"
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Sep 2017 15:43:27 -0000

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

Hi,


Actually I liked the early pyang output that was concise and easy to
remember.
The current format gets very cluttered and there are too many little symbols
to remember them all.


Andy


On Thu, Sep 14, 2017 at 8:33 AM, Joe Clarke  wrote:

> I've been hacking on pyang, and I changed tree.py to add the enum values
> for enumeration types and identiyref bases for identityref types.  Here
> is an example:
>
> module: yang-catalog
>     +--rw catalog
>        +--rw modules
>        |  +--rw module* [name revision organization]
>        |     +--rw name                     yang:yang-identifier
>        |     +--rw revision                 union
>        |     +--rw organization             string
>        |     +--rw ietf
>        |     |  +--rw ietf-wg?   string
>        |     +--rw namespace                inet:uri
>        |     +--rw schema?                  inet:uri
>        |     +--rw generated-from?          enumeration [mib, code,
> not-applicable, native]
>        |     +--rw maturity-level?          enumeration [ratified,
> adopted, initial, not-applicable]
> ...
>                                +--rw protocols
>                                |  +--rw protocol* [name]
>                                |     +--rw name
> identityref -> protocol
> ...
>
> My questions are:
>
> 1. Is this useful?
>
> 2. If so, can this be added to pyang (happy to submit a PR) and
> draft-ietf-netmod-yang-tree-diagrams?
>
> 3. What changes to the output format would you recommend?
>
> Thanks.
>
> Joe
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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


Hi,


Actually I liked the=
 early pyang output that was concise and easy to remember.
The cu=
rrent format gets very cluttered and there are too many little symbols
to remember them all.


Andy


On Thu, Sep 14, 2017 at 8:33 AM, Joe Clarke <jclarke@cisco.com&=
gt; wrote:
I've been hacking o=
n pyang, and I changed tree.py to add the enum values

for enumeration types and identiyref bases for identityref types.=C2=A0 Her=
e

is an example:



module: yang-catalog

=C2=A0 =C2=A0 +--rw catalog

=C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw modules

=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw module* [name revision organizatio=
n]

=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw name=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:yang-identi=
fier

=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw revision=C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0union

=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw organization=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0string

=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw ietf

=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw ietf-wg?=C2=
=A0 =C2=A0string

=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw namespace=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet:uri

=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw schema?=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet:uri

=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw generated-from?=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enumeration [mib, code,

not-applicable, native]

=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw maturity-level?=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enumeration [ratified,

adopted, initial, not-applicable]

...

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw protocols

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw protocol* [name]

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw name

identityref -> protocol

...



My questions are:



1. Is this useful?



2. If so, can this be added to pyang (happy to submit a PR) and

draft-ietf-netmod-yang-tree-diagrams?



3. What changes to the output format would you recommend?



Thanks.



Joe



_______________________________________________

netmod mailing list

netmod@ietf.org

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




--001a11400d72f08a3005592822fb--


From nobody Thu Sep 14 08:44:14 2017
Return-Path: 
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 60646132D17 for ; Thu, 14 Sep 2017 08:44:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.111
X-Spam-Level: 
X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ericsson.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 8BhO7aSozPEi for ; Thu, 14 Sep 2017 08:44:10 -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 4851F1326F3 for ; Thu, 14 Sep 2017 08:44:10 -0700 (PDT)
X-AuditID: c1b4fb2d-a65ff700000019be-aa-59baa3c893e5
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 68.19.06590.8C3AAB95; Thu, 14 Sep 2017 17:44:08 +0200 (CEST)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.39) with Microsoft SMTP Server (TLS) id 14.3.352.0; Thu, 14 Sep 2017 17:44:07 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zrjlmH+WQ65EdIspqmln3N2haSi2H3lyL1NkKYnfmpY=; b=EYxsmCvq8uPF8jMftl6PIBjxDY932ocMJZ5ygqKRTQ0kKWqtkTzjqUDI6/JbnN+l8GUxyBrw5dUAt1YjW+4zx0gkoXVCX5JAe3dvkYH2yiIFt8U2vUZ/c7z/bVAGxTzdTVD4zGqrmM0MNoHf+0BgnsYhGaDQRBFTmgXcLrTjImU=
Received: from [159.107.197.117] (91.82.100.59) by AM4PR07MB3426.eurprd07.prod.outlook.com (2603:10a6:205:b::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Thu, 14 Sep 2017 15:44:06 +0000
To: Martin Bjorklund 
References: <9ec6b2e4-36a7-87e6-59fa-828855235835@ericsson.com> <20170914.163239.143365521945928900.mbj@tail-f.com>
CC: 
From: Balazs Lengyel 
Message-ID: <0605fab0-f879-e02d-4858-52a247571cb8@ericsson.com>
Date: Thu, 14 Sep 2017 17:44:00 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <20170914.163239.143365521945928900.mbj@tail-f.com>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [91.82.100.59]
X-ClientProxiedBy: HE1PR0802CA0015.eurprd08.prod.outlook.com (2603:10a6:3:bd::25) To AM4PR07MB3426.eurprd07.prod.outlook.com (2603:10a6:205:b::11)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 12188cac-d2e3-496f-ead4-08d4fb876f0b
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM4PR07MB3426; 
X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3426; 3:DzZnE6QkEQwKR9XT8yrDtxMCYd1WmHwEDkTzyMU/NQ/CNri0MM+UHBC+Uq0Cuo2pDceQS8/daZ2cJ2Fa67D+Wxomj99XJZ14NZiF6D0KQ2xe6VHLI1hpaNSNHRh7s5K32K1j0O/z7iivHUCjz4WC+U5ZIhxItbuOVqHcrieOCKYj4dtm0+rC+Q2VVYLmngpCBjIFgjLE26IDFZj3B7b3j9+0GZZdEr0q3mFF+fK0qpcALQiEAd6UwP1A82KrrKc4; 25:ljT5nSaOlu80CHm0qc5KT/GyxSIsTBwqUg5cYGDxHpSGsEwNpTGCPxxuVCVTPIOGg1TdFkx/jSO84nm6Exh07XvOn9MjQq1a+3p2zb4X4LFBCiBZ64JFCH64pkzzlK679Aisl8uouvgXaH9ltwuc47KnViIz6WXl/jiTmFrLPvUzTLKMPHKA7LNZit5x8fPS9Y8PSaNY6+yl9Inxa2BWQJWDwhnPOCoUWIozlrWwBDa29Xi7yu+mpVYy8GnQmGrX5YRMsKibWfAbQV76fdP6Tulzno36b3xzC/d0INGkisc6V6mwL3pFYhjkCqs8CkYl2OpID58I8JXdXKrgF+S36Q==; 31:gbXHwBdP1HwD3Ux825VmWNZhLzXXrm0G48hxvUCZSU++b32i0foV7vrfgq8KMtHGEVPV+j+zMSt0t42TfKhUaQWCe7iOMH1qe1gZocLDCOeEkNV99F/Jl7L0q8sFfMYWy4NWQyvUgDRo3VQj46EVwqIVhtpFvah3BNJgmf1ZA1++PGG6GnaKwbAak12gC7i+apmRiMY6b+JU9nCEx2DCCDy8GpcqWzTNmPvVIKcp+ok=
X-MS-TrafficTypeDiagnostic: AM4PR07MB3426:
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3426; 20:5VbCkC0t9G9Rpq0RXFzWqvi93VvwC7LhzWPskCWp8bc9Iee7K6Mt+KqN6j34MGfwa0VZbNC8FRRNkH1CogyhLEF0a2PMBQ2KbhscoVPoazk9rkBY3rjsmXoDm+l8HebjpcyPN0vlyCDexPFDEO8f7UIqGgVrvfE/p3T2C8tfW4NKPP1ScDo5qTy9cnwVXjP7YKf1P8axv/nMsSk+ARhPcQ6bjFqTwOwkenChMmZXM/nG27g4rtGLLUaZ+YDPHUZvYB/4XnKhHz5tdxu8tL/1vv0Z0oK7ex6UmpxeqJum5zew+Qg1vP0mxIiSMgR4+cNtGiUV9c33gUxwITu4hwIuAtnk5C2JwKwGEgN/DrgijQzQYqxpzENYl10QXI3phVBkBIAmH64fNb7la7Vvme5pfWGJqSm7dlqLBoL8rrN+96DCaCO4U0zHCZu0rnMriYPKRnvObblkM2PLT84QydrIy7NQ0FWwuGhdCikRI4IOfBWmpDAGoDVPHKEdt6jW1TND; 4:tRofQkUnDKV3bg/YvG+9AZutJyc7dUHsbzCO3xV0aAER15LSviJmwNXkSRFx1rIdoKVm5tGJR9g3qlvGvmQ659EJ07jwXBorqS40rt8j6zXHVee0ck7HIOCrN/IRK89vfep37PQDtyh4vNr2QW6bJ89qUfwgTKoEyVJiRXa2Q0+xjbC774jPkMj5tGREL87TtG0oEfsKBsM0myl1/pfvsO9MMw/qXrrT5IaA0SSUxXMbsNvxsHwlNTIzP6JB8TIx7x87KWsK0f14doThcwQDvDn1UXmr0qY5t1o2Cyd3yXk=
X-Exchange-Antispam-Report-Test: UriScan:(37575265505322);
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR07MB3426; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR07MB3426; 
X-Forefront-PRVS: 0430FA5CB7
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(7370300001)(4630300001)(6009001)(6049001)(39860400002)(376002)(346002)(199003)(189002)(24454002)(252514010)(377424004)(54356999)(50986999)(76176999)(101416001)(106356001)(105586002)(5660300001)(316002)(53546010)(65826007)(33646002)(68736007)(36756003)(3846002)(47776003)(66066001)(23746002)(6116002)(65806001)(65956001)(64126003)(16526017)(31686004)(53936002)(49976008)(478600001)(16576012)(25786009)(230700001)(110136004)(305945005)(4326008)(6246003)(7736002)(7350300001)(50466002)(86362001)(2906002)(6486002)(4001350100001)(97736004)(2950100002)(6666003)(81156014)(81166006)(31696002)(8676002)(189998001)(6916009)(83506001)(229853002)(78286006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB3426; H:[159.107.197.117]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; AM4PR07MB3426; 23:9vCDyypn7u823jNG8/ZD/7eNsQion9zcqpzfV?= =?Windows-1252?Q?Bar0U6Ljn9aqGptM8fM+Qbo+cb7suUD37gtN5y5ZxwL3httxd5O8I3FF?= =?Windows-1252?Q?nXgpijnrl8xOXN90DHlQGi1AMj/vSe304k+WMp71/jpm/G9AZNbIE1jl?= =?Windows-1252?Q?qXhepDTpebWAUSn2Jh4gv9oU7JrrWHDKxwlylEKSBgD7EjMOblbzbTjb?= =?Windows-1252?Q?xXhT0pYmChAH/jokgcyzSkwzrMYBAIrJEMlZwpZXJPNRBeZwNFpVWvem?= =?Windows-1252?Q?8Cw/OIu8ahKlKMJY5/RTvJUyIYFHkW/pHIMYWiY7hevXIa8Y1+Zd8HGS?= =?Windows-1252?Q?5uKSFsUmq/fcd/a166vONyMWu60OG4GJCNrdJEI3O6gsugzPbbqedcsE?= =?Windows-1252?Q?n/TWiSBOpaPjA1pYoV/okpHdUduF+dC2YeUFaGuiY2ZaMUxcHsODVqvR?= =?Windows-1252?Q?kcXeffXOlH1jTXiKhuvH/fUD3MgOwK5Sl/xmb/h6/S9pwHAUXnZ/dskv?= =?Windows-1252?Q?kzDNDpbV7dONf8CadtS689vzxsaqcXSbJL4GWqiApvjJWPOcWgE9FUDZ?= =?Windows-1252?Q?1Fppk4jnuXKqXmyZlUvic8tUrw6YRiuHhVh5B5kG+y3ot15HgMD5NHef?= =?Windows-1252?Q?aDZUzsSZaGS3YaCqCqZFpvoBjHBHv3XqCnYWfU1I8ZkbGawFA4y086su?= =?Windows-1252?Q?zUhRpwQzzb4IW6+iDfUabCvwfYCVV8oVpQujI0FFL52WpY5G6cvuYgZZ?= =?Windows-1252?Q?vows+TcHQOG1TbU8v82OG3KrQcBNdocEB4IkoSH+qJ5tOI3R6HR42smx?= =?Windows-1252?Q?l+JBApnJRXz+XbB58UiJKnGobET6bGDyzRcYXv+Vs3OXYkLPDbZqyPxM?= =?Windows-1252?Q?e3l7YXki121Wcc6oEurb24zwjeFQR/hByiFSv5gl9G9Qvq8Hhsw/8QE2?= =?Windows-1252?Q?m7DSPus1u9zRnk1pwUZdgG4yVDS/fPbjGwFSaZSjy88sYUnMxI/ZGdLK?= =?Windows-1252?Q?jhzsaZAo2o9nxTwiKEX1ONppFP6jOkbuFu0X2Ar/+g9mUPJ8o7sCkUoV?= =?Windows-1252?Q?WAe1mA2Rn802vR6oY2/HCwU+V5RphhILCAZrAo1BZK6MtrszSbzFHq7N?= =?Windows-1252?Q?KTpNBsECnvK3n+Mnq3LYZF46Zv4AOBJ9/kV+KX6CEwe5SSZ2SkHi4IAY?= =?Windows-1252?Q?W1jhTZh4wGFKzlZshPW8fdtbv73SNO8mpmWOnVD4yPK9SDDlm4E/KY3j?= =?Windows-1252?Q?DKekguM1C8/CDjaAOy4gZvAKOvhAVSt3ohmoYkSRe0Ed7ui3yxzjzkFE?= =?Windows-1252?Q?+0iamxNKEQu7vJV5yyxmeTXAg6660aXlP6h2ybF9Vx8bTR/63q3AVGUk?= =?Windows-1252?Q?fKihCryu4eXQQSyvF/HIVyIU2NXvyDuEaRSAozNNDKxU86uVvfg3zY3s?= =?Windows-1252?Q?EXYmJnqq5bEgRn7wP7/jPDcLyuj2PcreqVqlpThqN7gHwFV3OcazTx35?= =?Windows-1252?Q?8OwlW72GvmWuBZp+dOu7WP0pJHUOYVnKexJwR8V3hn4tTbcHz6iHDz+F?= =?Windows-1252?Q?FcCCYu/Dm1UhX/t3aPTMTi5FhlQeFn/0sSIR3GEUIWHcu5+plTTP9eSM?= =?Windows-1252?Q?Y4pQZfMPGzJr+Stmafs5eQ=3D?=
X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3426; 6:LwzJ6DqRqGZXM6iFPl/T21RaBhrNxVZ52qDGLiS37ZhJZvRsKaPNA+RDCa1thE0lQ6dS2/0JrpIzOmLFbcEJhBLRS8hID76pppqlWpWYyAH9bEjuDuPOzBVs1O2lwXBW7/IwJVrHDueTsFP+UqYiM4otzd31cKlygXhhbMsIvu1SbkDjp/35yXYl+c2cpAcutae2GLbFiT/ViWJjMPNXD2DU587L6LogFhGXHLHZ1bXOhJsVmFptOHFHHVvN8rqETSzPG1hX3GjD+Vco/pdSE9mhIChKh5oNZfKY5DjH7zsOrdQmFai+7kn0+DSJHtcs4A9XfvMj6mXwkpX0jhL/XA==; 5:fTxWAwrNzVApy08/Q/danw1Zowloi82tsbttyLhJ6nb05tZN2MCveiWu1a+wkK5CqFHtWiqE9dVAfrJKbnkKMoUGV5JngtCx5Izv2fM0LWCC/b0yMIC+nMA9WuYTzjV8GdpOS/T4Qji7oeFCvZmDOg==; 24:XTLBSNA8Ovx3lAJfQYYFfAcMw+vTF/cRVv3dGiWuLNPT2GCTDLY9jFZaje498GfBa3CDIjrGH+oL+PBYOx+qfP02qEYgZCr0kxQKIOOXAGE=; 7:JoBZkcVBeZUluXTwcmv9k539nZq7h/LcbvkgiG5zcX9rytQMpOmkWXhgMlPRdTPgjjbVu5l6HWxwOCXmVgpgrbCV4rFmdaGvP+9R5hKN2bLS8UfgtpUZPnThIKDU7TyTMFZ2i9uGVujOG8nXm0XuQw5oY8b/YPYl87Jfl2TW4+O6Xk4tnEVs/iW19aMLBUQgETQl5gvAIhDQ4cHIKHps5HIVPFgbUNE/C3mmZrrdVYM=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2017 15:44:06.5166 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3426
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUyM2K7uu6JxbsiDS6tV7To7n7GbjH/YiOr A5PHkiU/mTw2/lrMEsAUxWWTkpqTWZZapG+XwJXRfKus4IZAxZ9HS9kbGLt4uxg5OSQETCR+ Xu5i6WLk4hASOMIo8XjReSYI5wSjxKHPz1hBHBaBXmaJjp9zmSEybUwS7979Zeti5OAQFtCU 6LlrDDJKREBV4snOtSwgtpBAqcSfc9PYQGxmAVGJ9RcvMYHYbAJGElP7z4PV8ArYS/xfdY8R xGYB6t2yYicriC0qECPRsuQDI0SNoMTJmU/A6jkFHCR+P9vKDLKWGaj3wdYyiPHyEtvfzmGG +EZB4vrm62DfSAhMY5SYe/Y0G8Q9GhIPL/xlhSiSlTh6dg4LhO0rsfTwVWaIhstMEhMeH4Jy GtglZkzZA7ZNQkBL4vp7RZAGRoE4iZ1rFrJC1Dxhkzjcfo4dYpKVxOtf3xkh7GyJ1sPToAad ZpWY/fw6VJGMxMdfDxkhEqvZJM7++cU+gVFzFpJXZyG8NwvJewsYmVcxihanFhfnphsZ66UW ZSYXF+fn6eWllmxiBKaHg1t+6+5gXP3a8RCjAAejEg+v4axdkUKsiWXFlbmHGCU4mJVEeF0n AoV4UxIrq1KL8uOLSnNSiw8xSnOwKInzOuy7ECEkkJ5YkpqdmlqQWgSTZeLglGpgNFe5U2x0 tFL4yOUpdRbKJkKH7M94Z4ecN/05caGH9FeThA8i/6T+Phd4P3NRCFfC6zfvf6usVV4+736g xIlT7qW5l08/b3eLKzTN+13JotaQdaYmdMlpw73tL0sXr3idq3lKWFDw8uE4cdO/mtsVLr9r 3VB/6OJubRbzmT0X7RZvPrc/euV6TiWW4oxEQy3mouJEAAY1MDQLAwAA
Archived-At: 
Subject: Re: [netmod] Comments on NMDA-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Sep 2017 15:44:12 -0000

See below !


On 2017-09-14 16:32, Martin Bjorklund wrote:

>> CH 4.4.)  "Validation is performed on the contents of ."
>> This to me means that default data is not considered at validation
> Note that RFC 7950, section 6.4.1, says:
>
>     In the accessible tree, all leafs and leaf-lists with default values
>     in use exist (see Sections 7.6.1 and 7.7.2).
>
> So defaults are taken into account when intended is validated.
BALAZS: Yes the two seem to contradict each other. This can be 
understood in your way, however the current text is not clear enough. I 
would add:
Validation is performed on the contents of  (EXTENDED WITH 
DEFAULT CONFIGURATION).
>> which would be a backwards incompatible change. Also if validation
>> does not consider system configured data that would allow cases like
>> multiple interfaces named lo0. One from  one from system
>> configuration. IMHO while it is OK to violate uniqueness because of
>> remnant data, the above violation of uniqueness seems a bad idea.
> If your system adds data to , or to , it will be
> validated.
>
>> Ch. 4.7) Is it allowed to violate uniqueness of key values? IMHO it
>> should not be.
> Agreed.  Note that the draft explicitly lists the constraints that can
> be violated, and uniqueness of keys is not listed.
BALAZS: If that is the intent I would propose to explicitly state it. 
For me it was non-trivial.
Can a a choice statement be violated? Having to existing branches at the 
same time? It seems a semantic constraint to me. IMHO yes.
Can an if-feature be violated? If  support has just changed and we have 
some remnant config, I can very well imagine it violated.

Also here could you change
If a node in   does not meet the syntactic constraints then 
it cannot   be returned
to
If a node in   does not meet the syntactic constraints then 
it MUST NOT be returned
> /martin

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


From nobody Thu Sep 14 08:58:51 2017
Return-Path: 
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 81CAE132F7D for ; Thu, 14 Sep 2017 08:58:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 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, 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 T0ALZAUxRpJq for ; Thu, 14 Sep 2017 08:58:48 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DBED1326F3 for ; Thu, 14 Sep 2017 08:58:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2443; q=dns/txt; s=iport; t=1505404728; x=1506614328; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=TtlBENLpeXdxpzOZSzI00szQ1yJJFibYWmyD7zFUI/Q=; b=ifmYzfUETcoZ8tGppWkveAKSdJVPrjhTVq6O0iQn3hoDIDNWzAdV4JeS r/aCHuuBZInm0oHaGrrBKweGFWtx27KBYnOps9AYoRqiL9bTB1f/BAdsY vf31hIdL91ixnMXAt8WUKl4mK9DWM4MF8T2JQ0hy4e55+g1YdmitN/DjV 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CxAQBrprpZ/5RdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbieDd5taK5g6ChgLhEpPAoQkQxQBAgEBAQEBAQFrKIUYAQE?= =?us-ascii?q?BAQIBAQEhBAsBOwsQCQIYAgIjAwICJx8RBg0GAgEBiiYIEI4jnWaBbTqLLwEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEfgQ6CHYICgVCCDoJ9iAuCYAWMJ4UHj1SHWox4gm6?= =?us-ascii?q?IZ4chlTGBOTYhgQ1TJBVKhzgkNohtAQEB?=
X-IronPort-AV: E=Sophos;i="5.42,393,1500940800"; d="scan'208";a="295420183"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Sep 2017 15:58:47 +0000
Received: from [10.118.87.94] (rtp-jclarke-nitro13.cisco.com [10.118.87.94]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v8EFwk4O031948; Thu, 14 Sep 2017 15:58:46 GMT
To: Andy Bierman 
Cc: "netmod@ietf.org" 
References: <9d84d068-29ba-8e89-394f-b7f6a5272adc@cisco.com> 
From: Joe Clarke 
Organization: Cisco
Message-ID: 
Date: Thu, 14 Sep 2017 11:58:46 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Sep 2017 15:58:50 -0000

On 9/14/17 11:43, Andy Bierman wrote:
> Hi,
> 
> 
> Actually I liked the early pyang output that was concise and easy to
> remember.
> The current format gets very cluttered and there are too many little symbols
> to remember them all.

I just went with text for these changes.  Yes, it adds more verbiage to
the output, but it doesn't add any cryptic symbols; plus I think it
makes it easier to comprehend the types.

Joe

> 
> 
> Andy
> 
> 
> On Thu, Sep 14, 2017 at 8:33 AM, Joe Clarke  > wrote:
> 
>     I've been hacking on pyang, and I changed tree.py to add the enum values
>     for enumeration types and identiyref bases for identityref types.  Here
>     is an example:
> 
>     module: yang-catalog
>         +--rw catalog
>            +--rw modules
>            |  +--rw module* [name revision organization]
>            |     +--rw name                     yang:yang-identifier
>            |     +--rw revision                 union
>            |     +--rw organization             string
>            |     +--rw ietf
>            |     |  +--rw ietf-wg?   string
>            |     +--rw namespace                inet:uri
>            |     +--rw schema?                  inet:uri
>            |     +--rw generated-from?          enumeration [mib, code,
>     not-applicable, native]
>            |     +--rw maturity-level?          enumeration [ratified,
>     adopted, initial, not-applicable]
>     ...
>                                    +--rw protocols
>                                    |  +--rw protocol* [name]
>                                    |     +--rw name
>     identityref -> protocol
>     ...
> 
>     My questions are:
> 
>     1. Is this useful?
> 
>     2. If so, can this be added to pyang (happy to submit a PR) and
>     draft-ietf-netmod-yang-tree-diagrams?
> 
>     3. What changes to the output format would you recommend?
> 
>     Thanks.
> 
>     Joe
> 
>     _______________________________________________
>     netmod mailing list
>     netmod@ietf.org 
>     https://www.ietf.org/mailman/listinfo/netmod
>     
> 
> 


From nobody Thu Sep 14 09:13:27 2017
Return-Path: 
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 BD423133046 for ; Thu, 14 Sep 2017 09:13:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.111
X-Spam-Level: 
X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ericsson.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 p0CCb4itO0Tp for ; Thu, 14 Sep 2017 09:13:23 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.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 C4ECA132D89 for ; Thu, 14 Sep 2017 09:13:20 -0700 (PDT)
X-AuditID: c1b4fb25-94fff70000005333-18-59baaa9ec056
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 5C.9E.21299.E9AAAB95; Thu, 14 Sep 2017 18:13:18 +0200 (CEST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.39) with Microsoft SMTP Server (TLS) id 14.3.352.0; Thu, 14 Sep 2017 18:13:17 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Jh8n7ril5GMs7q8/5bKbwNzF4wSpQbsGvJclW52G/Jw=; b=KNMHwlHpKqYpqEKN33RmZ4dd+RXzRYfRJ7ymR9G+G/JE+qJVllMmuPq7kczVZ1Dp9bSoYXzJIGauEIwwdnCbGz+IbkYKCM/v3dktkMFyTn+ODkSXjWxLnRnS52Hz9C68/yi9d1wSXNXxbmLfbdZTad6Z4gJ6XfS22bVfXfFqpZs=
Received: from [159.107.197.117] (91.82.100.59) by HE1PR07MB3433.eurprd07.prod.outlook.com (2603:10a6:7:2c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Thu, 14 Sep 2017 16:13:16 +0000
To: Joe Clarke , Andy Bierman 
References: <9d84d068-29ba-8e89-394f-b7f6a5272adc@cisco.com>  
CC: "netmod@ietf.org" 
From: Balazs Lengyel 
Message-ID: <996db3ee-c3f0-a8f3-8c94-8471a4ce8dc0@ericsson.com>
Date: Thu, 14 Sep 2017 18:13:11 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [91.82.100.59]
X-ClientProxiedBy: HE1PR07CA0039.eurprd07.prod.outlook.com (2603:10a6:7:66::25) To HE1PR07MB3433.eurprd07.prod.outlook.com (2603:10a6:7:2c::12)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 66300c3d-d2bb-4829-cea0-08d4fb8b81ee
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:HE1PR07MB3433; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB3433; 3:0ATLJPnZCoAQaWuq8Hl8pUZ9jvSREqc+zINYzNU+6JlPyG6XHhk87RPAnXCZPyftP2Ad1+J83XdfY2zkqCBO4oIvjID0grlGx2Ozuu1htt8dCQakFWF/6lSL5gUQ23Tdryk5ocui7Uls0jEotHSg+BAcfnZ35pNhGyjgZiByq1RKhF0/XhK2Ihg2YHDzkP3PBzRc4vESyM+cDz9sBUeAFIAiOTYWOHIdMnXs94b3nVoOyARTrWXSf13DyJeCs5aE; 25:2f2P01H8YkRJ+CVyB1o+/7zoH70yZlF/gxGFQxqPi/gu8h9RccnFguRY5HXXTKsqwnWVpp0GmPVdcT8gaNNnytOzb31DWHkOYbPh/w1P5AwvWqJ47fhsufv6sGv3yMNLO7ZcLToaIIRCMCmEXRmuY7+atvTPf27ef6GY8XlTs/rxpZmQMpZXgEh8UjhdRnqjEkKHo+xt2D/Isjf21zuGQb4YjVWwVlYguamQG4I0TJQqEoam8TcPuBZsiH7ygjdAjIeLkWNrQPw3e4ulJtnjCqP2FTsMW9Fr/du226VPpsje4GSCXegTdHXacc5KalylqQicT+wP6UJNTlB2GxWPKQ==; 31:doLRSPaDwhfoSK6tMGi8s2zDFhi+Bcy3uqdvJ5EXtIidI4Qwr4z8pxwGE8urIPyTCO2YPSCesYAvfjKZbVvAROgk5u1ZzDKpnKBmtbJ9eDoOp3bQ/pox1anqZCRBarvLR6LasXEaLM6xRtKxd6QjJZegvwJOsyZMas0QEyBwiUvveiumvx+w1Gx36PWRl40bDhP1h2n+KRbAwddQiexWeOmQbUp5C5w0/YunOAA/jjg=
X-MS-TrafficTypeDiagnostic: HE1PR07MB3433:
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB3433; 20:HuIZPd79gdoKV42B9+1/xOHT4+t5Yd/u90AXtsID82OqHBT6iZADjYSX/bJa/Ur/1QWoCPRBMbm+ouYikJDtwQvFU8+Twr46quZSYMFUWbtBMxn3QcSk2klBv6p4BRJPgrsO7oRIM5qLAGDBZ+x44qfhOXgSdQV6aGqusZ0vBM42wEdQdvMsOY1p8okEkc4JU+JMRBVaRe0dU1WBeVi1uPUOyNv1UTzjXBR+9sV10kLh0eQuLlyrnJDTEKgPowFIvxp5XGWtGlRnBpSl+4dbJytGi6jIUMh/dH8voqwkEWYVECXRHb6Kpos/fR9gJzSjSCGV//s1zDyv2BIonhRC5S2ao5Si5p0/r3Q9IgixcSlUKYq4b2fQKVphpBjABr3ETXkka5+wjDBE1xjWw4LbSCLcJia7JFavrOq4S9cSAE+w4c2XUyetRp9ywH8yFI390j2nSSOzYs/HRljKHLpF+dIU+3GtNo/ViCFjcwT7JN09KziFhQokYa151TEp6Nm4; 4:fJ/m0lXoPAFvOnWFHfojxcZW1jqZf6tfjz2Y9cOxXHDu6hVgIIu6DPst706pjXkr6Wrx3Wq/okUC1UrwUCJ48diBf74YjwTspcBRLPN0OCBykajtUA79We5cvxFnqofYkdKQ4vqKq6UOPLpPirwwtGazLyawzjokfmCyY2Y4acO0H2A8yn1eFvfD3qsXEpai92PMT8ttwSb2n7aLGLkwbMxXRdOEBPp0uatAhttzBZz++2+ExI4j+JtQ6H43iIQMRMEj0g9EKqZv2PCn46+k3d2CxVQY/gA74qZKfLTMxz1/JUc3MhcaEeBPZt0vGcpNY/KkCDi9sYBq+fyUqRPaoQ==
X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(95692535739014);
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6041248)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR07MB3433; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR07MB3433; 
X-Forefront-PRVS: 0430FA5CB7
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(7370300001)(4630300001)(6009001)(6049001)(376002)(346002)(377454003)(199003)(252514010)(24454002)(377424004)(189002)(65956001)(97736004)(65806001)(66066001)(31696002)(68736007)(53546010)(36756003)(53936002)(189998001)(966005)(2906002)(4001350100001)(86362001)(316002)(31686004)(16526017)(16576012)(47776003)(305945005)(4326008)(6306002)(83506001)(7736002)(5660300001)(76176999)(54356999)(50986999)(25786009)(6246003)(6486002)(50466002)(3846002)(65826007)(6116002)(101416001)(229853002)(8676002)(49976008)(478600001)(105586002)(2950100002)(7350300001)(23676002)(81156014)(33646002)(230700001)(81166006)(106356001)(6666003)(64126003)(78286006); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3433; H:[159.107.197.117]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3TUIzNDMzOzIzOnBMNUxKZkd3ZUZ2dHorTnZ1VVN5YkhvdGJZ?= =?utf-8?B?VmRnN055SmpESmNWek1iUGk2dzMwdjgwZEtxbEl4dE56N04rVy85WmpOTFkr?= =?utf-8?B?bXJPa2VxR1B4T3p2U2pjMmZMRFR4K2RxZ2FKdkVyUmtjelJkTHVrRWw3Sjlr?= =?utf-8?B?WGpKWVRIZjU3ekI2Umw5Y1RWUng5aVNucnBIejRLT3BJaE1lMUpnUWFEMjBB?= =?utf-8?B?MW5PazErNXJ0eS94dEZFZHBEaWF5Nm95Tzhpb0NVa1FFZGVuSUJsQks4U0tW?= =?utf-8?B?a2ovem9KdUp1U2JWUEpaNkYwQ212Mnl2cU5ESXlYZi92eEdadFlzVVJCTjVt?= =?utf-8?B?ZDE4VDlBOWRQUitjNkdkMlVUNS93WndocGlsVXBuK1d5YStYZjdId2NDRThh?= =?utf-8?B?YVFxZWcyNmpTRGg3bmNNcHppU21yYlVWT0Qxa09GS3BxMmxEcFJGamJ3RWla?= =?utf-8?B?bkJwcE1EUEUxSk1RWG13ZUVIUkRsU0lxN0tsV3BJN2hCaDFPVEFOTnQ0VGFD?= =?utf-8?B?djY0d25MaDkxbDJhcHBoSzN0UTVVajBSYTR3R2J2M09IOHhjQ0ZIOVl5OUR3?= =?utf-8?B?NVQ3WVdaTmgxSmhGazgwanU5Nk1tNVh0bEhuRVVucnRrUnRQSVdaSVFMYXZz?= =?utf-8?B?Sks3c0JINnVjRW5LQnYyYVJuQ2NPSGZIZUYzd3RKWW9sZGhqWXRRUFZLNCsz?= =?utf-8?B?VS92YXNyMmVQc3Y2UTdoWDZsMVpBRTEybEFuNkZDT2Z6ZjQycGN6ZE5TTTBo?= =?utf-8?B?YWRaOFdMZ2pmdHBDV2JtakFLYXBiUmZXT3p5bG1CK0VQUnlZWm9EcDlXaGlL?= =?utf-8?B?UVhkY2MxYUtWZTFRcWZ2RGVxNDdWeXgyaThvRGVMSHRGazVFUGpKeFFsSVVo?= =?utf-8?B?MWNuajFUK25keS9RK3dKMGtiSW12WitaWHNRU0FucEF5NDJzT2RXTUVYYmk3?= =?utf-8?B?WG9HcU9jdW5QRGk4UlV6RnprSXdxVXZwb29leE1FVjRyQTgrc3hiZnJ1V0No?= =?utf-8?B?ZTlhbHdtZFVlTlBTeURBYnlHek1YNks5SnFNQ3BYNmNsY3RaRjdBWkRUaExh?= =?utf-8?B?WURpOHYxckVhSFZtWGVrLy9QRUx5TS9JMmlKSGFiUDR0djZ6eTBmZGdzVnFX?= =?utf-8?B?d1AxYWMvSENVd2xRY1ZmMll0eXZ2eE9vRFR6dUZEOXZhTVdiS1lMY0hZUVc4?= =?utf-8?B?ZzkyUFFxWXE1eWlZZHhxR215SnJsaXRFWURrMkMwM2U5VDFkODhvVmFsby9U?= =?utf-8?B?SGdqbktrRFp0clR6WXJWMHVFUks1MjBISGRWRFlEeHpGSUZwcHhjU3lYS1JQ?= =?utf-8?B?aHRjbzlVS2JJUGhubGJ1OC9PZE1BbENoaUZPU012VGhEZFZXZE5CQUVMMWlp?= =?utf-8?B?ZkRlUlJqQ0RtUGxTYURpSzdZUE55TmViZTBaWE8wc1JEOXNGZW9YR3Z4R3R1?= =?utf-8?B?WGFORDd6TEhZbFluN3FEemFEQkRxOVJnRkZqY0k4WmJEczMwdE1aQ3ljUit5?= =?utf-8?B?cWxXQnZxaGJTRGNGMTRyQzFoalc5U2FTTlpCdTRETkxCMnJyNEMvWUNEeCsw?= =?utf-8?B?dktUMU5JTFovN2o1RGdLdzdlUGxBMHhZbkl2WGJOZXE1NldrYm1PVE9CVGwy?= =?utf-8?B?Q1VSMlNSbXVEcUdDczdCbTIzRzE0M0padWtlMFE0K1BvY0E4NzR6UXZMelB1?= =?utf-8?B?UkVqT09mTDl4RXExelB0a0lpVGluZmFTdENpeXF3MjBreXBjNlM0Z20xSlNs?= =?utf-8?B?QzFaZW5Hd2twM1lIZyt1YmhrYXZEWkNKZk5qVEQwSDRDWlhyUTk0S0hVMzdv?= =?utf-8?B?T1NLQ0ZmV1Z6YndXNnJuNGp4dXpYQ2IzaXFTSDlnUWxwd0VBSnl3SGFSUDU4?= =?utf-8?B?YjZBYzVUT1hSdFRqYTRGbW1JcWZDR3VxeVgwaGdOR1BIOU9RRnlFR0dGZDRk?= =?utf-8?B?Zkc2Y0l5RFFmK2NJNVBOejNyclNEQkFTS1drZXlQYldBcXhKbWszR29hRVZ1?= =?utf-8?B?dUg2STdPVklSSmYxQlVick5MbnlxaFlTclVrdz09?=
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB3433; 6:VyAyf07imRSE6F1FCLvaEYuR5PLGcSjT18aV+evowQKshF5tfBHUd0bWDELoHMe1cEyvmoYu2OYRuvM1Y2L5F0QY9gnFJFVf0axsIm3eFca2GWFgicBpdUh+HQYzEzhRtPEUF4Ndz56byaxFPRJvwaF2bNyJCRgtC2uB3e2+jVFFhxbrOG85xJG/1GNZ3prZGQqC9aCXPyQSonmC/6T5IungFBC6c9EUjodhiTaiKHOzDe+SDwBNSDwZ2rA7xLEK2M/gUGp3dgoo+HPBUYa//9UxdiITpFKb0U4Pde8bvk7ycwF06K8EoDSD1UmNXHC0IHhRKnQQY64VWKYB8tx8kg==; 5:kfvRE7kDL4dnCeAxPUman6H9vdSGj8h6SRN7LKbvauXnEuJGRsSOeb4Zg6xZq1BS/ZZ6yvUBFd/CfEgz/ubkflPp1fqpX6l31Zlfi/VZXRQGNEKGEqC2P+XviyMBalPYjvl26mBkuHEAeZuIFtmf0w==; 24:XJF2u8r+M4Ad5fdDpQghrkIqrPd3kUmTiUZKv2YfpInzkFrO4B2NxPPeMet4CCLrQeZkGVfp3NbLFtO+SFBJNjLBUxFeGNebIZ1zq8+4rGo=; 7:NGybzDyuPxW1fAYfxIyaNooaCZkKAqeEnnq20Il6ebg6D4DxZApABH6yJPVQtanT0me8eJ5szuvj7XaG5ctSn6O4StDEYQQ7QCp9n5dI06dkIuV0fPaWruVHBGpMaJF7OqyLbn7K73MeH4hJSsylHyltwNBCCKM74d1ZSQF5qutCHot9wjWulRLcT8ewvHzNx7XOjDwCOfFtCKs+fWi6huNWP02xlhbpeOHzINyC9+o=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2017 16:13:16.2519 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3433
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjleLIzCtJLcpLzFFi42KZGbFdXXfeql2RBmtmKVs8ODKL3WLf1T+M FvMvNrI6MHtM+b2R1WPJkp9MHi39F1kCmKO4bFJSczLLUov07RK4MubdO81e8Ea0YvKpVUwN jMv5uhg5OSQETCTebrzP3sXIxSEkcIRRYt/fI6wQzglGicYJL5lAHBaBXmaJU6+eQpW1Mkms +3mHHaRfWMBO4t/OxWwgtoiAq8TNDwuhirYxSpzr/gZWxCygLnHn1GOwIjYBI4mp/edZQGxe AXuJl7cXs4LYLAKqErNu3wSrFxWIkWhZ8oERokZQ4uTMJ0D1HBycArYSLRN4IEZaSMycf54R wpaX2P52DjPEPwoS1zdfZwG5QUJgMqPEgoVdYHuFBDQkHl74ywpRJCtx9OwcsJkSAr4Sq38W Q9RfZpK49vIgO4TTwC7x+c9HFogGLYnJE9vABjEKxEnsXLOQFaJoArvE9I9NUKu9JNqOL4Oy syV2TJoBVXSaVWLqo6NMEAkZiY+/HjJCJJaxSfTMms04gVFzFpJXZyH5bxaS/xYwMq9iFC1O LU7KTTcy1kstykwuLs7P08tLLdnECEwdB7f8Vt3BePmN4yFGAQ5GJR7enbN3RQqxJpYVV+Ye YpTgYFYS4XWdCBTiTUmsrEotyo8vKs1JLT7EKM3BoiTO67jvQoSQQHpiSWp2ampBahFMlomD U6qBMY5lJe8KjwmWJQ0h2/muSqzkLE9oyNYs4b99aU8E//KLVybvuxZ5xfNE2Xn2JfMeL91Y NEXS5fuUit+8x+7l1N0W53huXBd9WWjjcS17XzW3XQb+f6ROLBWSeDjpRWmpi/9TthXrDpV6 Gp9zf3v0c4hYJFt80ZkGDS/uuJt3z0xe/10v79tVbSWW4oxEQy3mouJEACDdvUEZAwAA
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Sep 2017 16:13:26 -0000

Did you consider to have a concise and a verbose tree output selected by 
an option?

regards Balazs


On 2017-09-14 17:58, Joe Clarke wrote:
> On 9/14/17 11:43, Andy Bierman wrote:
>> Hi,
>>
>>
>> Actually I liked the early pyang output that was concise and easy to
>> remember.
>> The current format gets very cluttered and there are too many little symbols
>> to remember them all.
> I just went with text for these changes.  Yes, it adds more verbiage to
> the output, but it doesn't add any cryptic symbols; plus I think it
> makes it easier to comprehend the types.
>
> Joe
>
>>
>> Andy
>>
>>
>> On Thu, Sep 14, 2017 at 8:33 AM, Joe Clarke > > wrote:
>>
>>      I've been hacking on pyang, and I changed tree.py to add the enum values
>>      for enumeration types and identiyref bases for identityref types.  Here
>>      is an example:
>>
>>      module: yang-catalog
>>          +--rw catalog
>>             +--rw modules
>>             |  +--rw module* [name revision organization]
>>             |     +--rw name                     yang:yang-identifier
>>             |     +--rw revision                 union
>>             |     +--rw organization             string
>>             |     +--rw ietf
>>             |     |  +--rw ietf-wg?   string
>>             |     +--rw namespace                inet:uri
>>             |     +--rw schema?                  inet:uri
>>             |     +--rw generated-from?          enumeration [mib, code,
>>      not-applicable, native]
>>             |     +--rw maturity-level?          enumeration [ratified,
>>      adopted, initial, not-applicable]
>>      ...
>>                                     +--rw protocols
>>                                     |  +--rw protocol* [name]
>>                                     |     +--rw name
>>      identityref -> protocol
>>      ...
>>
>>      My questions are:
>>
>>      1. Is this useful?
>>
>>      2. If so, can this be added to pyang (happy to submit a PR) and
>>      draft-ietf-netmod-yang-tree-diagrams?
>>
>>      3. What changes to the output format would you recommend?
>>
>>      Thanks.
>>
>>      Joe
>>
>>      _______________________________________________
>>      netmod mailing list
>>      netmod@ietf.org 
>>      https://www.ietf.org/mailman/listinfo/netmod
>>      
>>
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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


From nobody Thu Sep 14 09:14:23 2017
Return-Path: 
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 E17F9133041; Thu, 14 Sep 2017 09:14: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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_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 32KQf5WIi-0T; Thu, 14 Sep 2017 09:14:14 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0091.outbound.protection.outlook.com [104.47.1.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05781132D89; Thu, 14 Sep 2017 09:14:13 -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=zVrEgPhO0sIqbVsvzG2uo5wDBZGwluqwTFENtjT3tos=; b=cS/aXJOHY/QatbXGI8xhLtX6oc3Fz/DW16bSbJqKPzhsalR1B7Vyar4wi01wZuLEjKm+Cth2dHiM/TSgQVHthRARP7f+t5kwp5yvGwuglD+tzO0tLU/A2816viBmfViK3w6HIj2qv0J68d/eqijoptzWAf3ETEV2yY3Zywd7juE=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (86.185.245.5) by DB6PR0701MB2997.eurprd07.prod.outlook.com (2603:10a6:4:73::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Thu, 14 Sep 2017 16:14:11 +0000
Message-ID: <00ae01d32d74$49e24c20$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Kent Watsen" , 
Cc: 
References: <49B4BE2F-6912-49BE-9E4A-830146309AB2@juniper.net> <019b01d32c76$fa7dfc40$4001a8c0@gateway.2wire.net> <8CF097E4-CEB7-4C4E-AC7D-F7F896CD1BB7@juniper.net>
Date: Thu, 14 Sep 2017 17:12:33 +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: [86.185.245.5]
X-ClientProxiedBy: DB6PR07CA0161.eurprd07.prod.outlook.com (2603:10a6:6:43::15) To DB6PR0701MB2997.eurprd07.prod.outlook.com (2603:10a6:4:73::7)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 0b527d05-379e-4f18-b64f-08d4fb8ba29e
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB6PR0701MB2997; 
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2997; 3:GEuT21Huy+QKPbW4r5t3l7DEBCBin2oLZKkSS6378zvvDUBSZCMzXIt5mRpdn0RJgFxNtCtEk818uIm0z6v3bNjbf1DQRPvjNBdw8u1Gg+4bTp3bPikZI/UalfWfcurIZn1uYR8Ggwlalw3xQv/7cwApGtK9WNgMMJW4LLvNmpPnv4zh0K2tn+XZiC+W1wBnakPQmwSbaSAzbeYZmBXWgv36yMTuQw2W/F0Hd5dNMGsGYAS+cO/qjOdnL6hq5Uyq; 25:yblxAFu+w7Y9HfdaSUET+mBnAEEDnCjsNyrh+N0QqXTBKB6ayu8NkRTnfzJukjn/suU2ON3aqaNlmWTLCGEPWfO1y93WZe9tMNwPe9BNBW2EhR09OIqG7mpVL0wgYuzk6n/d8/czCIOchF/8cC3qKY4mH/0LUPCNvQ2sK22zPyy5aIZod9VlwGA7v9H1UTc0q9Da8vDQq6pdKQr1j6Gx2IdDqgRcK8C1UGJ517ui+gCBB4tD5BjnnNFVVc+kKVbfuiPN1fU7wlF1Xj8ljY2K9JvpvYg7ed+AtXXaysK4DZomh78ORD7GidW/ndcXkSOw/EIbzwOfxWxT7tGyQrEJZQ==; 31:XS6XNXDLTutJr+wCCyInwkzE9ztNE4eBbU16+JZqRjoV+GBmEugMtnDkXPf3DF9cApmgB2DFlhqIlIT+/PA+hs6BhFvXqEhsCJlD7W0k4HpB5a7lnGoQRhIP+oKs1fjoKMjr5XPR17Qxi6/vCF8SnvEE4WiEaWRrsGN7cmbgse8+Lv/zqTC8yg3+vKvWiqvgTCUlBigyqAhHDN+Na5ZzbhRRkaMoJtFWSYYg7hPTQxo=
X-MS-TrafficTypeDiagnostic: DB6PR0701MB2997:
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2997; 20:kL//z9dr6Tbv3+GEYNB//MQ+SiNg7lC6vebFI4/xPDwywp1XIcTRmik/rAG6omr4ZmwT8wrwoBpgAMq5hLwhVk3bLWD2y6+o/2nMvdoCz0ai0Ae/G/0BOopBBMhof2oxJwPwy8IXeggW/JkZwnwzDAk7r1AIfcQV7U3+o14XKjF5WhKirFYc+GJcPSihc6ZkpMpHAgqgAAEX6Jd+rSjSzNW1Tm3E0IdG3t69771iC9x6MZgDRoMQQpFmzIxEl2eP; 4:QwBwNG56eIRfL9ojCo/QyTGmERYOQaliMKwBrnF5WAa+9wEJIPuQ6ANl0ay3qioCt1YHJO2zklyZJQr1Moyrpujo9iEgEZo5WNnkfbqGKYUqOS9iqCzI5qwg6ikIGDJQ+ulN5uH8LaLsi8EhhpRVYPpwWQuZHwvAv3WFOWL/PrsymfsfP374bhk4FrC2+PI1oAXlTv+Dgo98sQIczX6fefmHal62jWfQATnl1EZIjH3V9V1Wy7x/rBE3TndzOjA1dz+54UeKFjEqKfnFjPN1M0P6BJblM0l+GIyEO/NO/gI=
X-Exchange-Antispam-Report-Test: UriScan:(138986009662008);
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB6PR0701MB2997; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB6PR0701MB2997; 
X-Forefront-PRVS: 0430FA5CB7
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(7370300001)(4630300001)(6009001)(376002)(39860400002)(346002)(13464003)(57704003)(199003)(189002)(377454003)(1556002)(575784001)(50226002)(2870700001)(966005)(53936002)(86362001)(229853002)(25786009)(230783001)(101416001)(6246003)(8666007)(23676002)(84392002)(2906002)(61296003)(9686003)(6306002)(66066001)(106356001)(44736005)(50986999)(76176999)(1941001)(6496005)(4326008)(6486002)(105586002)(81816999)(81686999)(1456003)(68736007)(97736004)(50466002)(5660300001)(316002)(14496001)(6666003)(47776003)(7736002)(4720700003)(305945005)(8676002)(81166006)(7350300001)(33646002)(3846002)(478600001)(62236002)(6116002)(116806002)(189998001)(81156014)(44716002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2997; 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?MTtEQjZQUjA3MDFNQjI5OTc7MjM6MW1jQ3hEYnRnM1ZMTk1Tbm9yTTBSZ2ox?= =?utf-8?B?OWtDU0hBMTFQOWxSTlQvWmY0enJFcVMxbmRaSkpUL0EvNjFXdnpyWkJOaHR2?= =?utf-8?B?VkN5VXRYVVlrbFRpdGUzNVNPV08xNHg5WUVkUUtzdjBCZjF4STlLOFY3enhx?= =?utf-8?B?MUNWN29HclgzbnZuck9lUG1DaFQ1bTJmOFQvZUFXR3RyTlB6Z0lnV3FMVGZF?= =?utf-8?B?UXZKU2RkckR3OWhxQnFWYUJnZ3hGMjdtVXlQQmNFV2s2bWN0MkFDb2lMeTN6?= =?utf-8?B?WnpOMStGS1pqQmRaYjZuSHZnSVQwWU5WcTFzN3liMG96UGM5N1ZiZ05UTjJz?= =?utf-8?B?QjV2Y0JGclR2NThqN1JTL1FTZVBMRWhCSVVBRHgwY3p5cW9PMUhVUUp1azFx?= =?utf-8?B?Y1p2M2dqbUhFalpibGh2T0JpL2NKaU1nTXg0STlXNGRmSE0xRVI3dFF3a0sy?= =?utf-8?B?bEtKK1FPYnVuUkJxd0c1QVFqSUhaZmhuOXoyTllaYVRNeUtkTlBzQ3dUUEQx?= =?utf-8?B?Vzd2ZnQ1V3VRcVZQOE5uSE5hS3QxWEZ3Ykh0ODhxWTNWeFF0Z0FiYVV4WG9W?= =?utf-8?B?bytKeWp6Tm5UbmR4aDhoUWpxekR6anJrSWZhRjc0ZlVkU2xscmxRU0tLbit2?= =?utf-8?B?UDJZQTB4N1puWVJkRS8rWUtIejJSbjREUDVDTnZjeDkwZDVMWTBaMENibDVr?= =?utf-8?B?em96eEJjdVRTckg3TlR0MzJPMWl0TGxwTzlLZytZSnJCbGFReTVjNnFhR0Yw?= =?utf-8?B?S081cXV1OUkzLzBNNitjbXJ5T1NTRHMrVXQrNUMycTcyMGx6alRQc2tTYlFY?= =?utf-8?B?MU51b1ZFc2ZINVVrMDhGb0I1MS9VOG5BRTRJbVpFTktOSm9rWE5oT0plK3VZ?= =?utf-8?B?T245UFFwNnNyQS9laGgzeEM3ZC82bHhsM1pXc09IQWdwMjVSNHRTdTFEb05m?= =?utf-8?B?dmF6SDVwZWtBazl6TytjTGI3NDVxdUxZWkZQVXJJOXpCemovQnFDTXZPaFdn?= =?utf-8?B?WWp1UGl1c1ZGd0QyT0NtRnFvaXpXSElNa1dxTzdiWE5pY2hGbzZNZHZib3Fp?= =?utf-8?B?N2pvdVFjTExleG0zYkFvQVY2NGVDbDh0eWlWY1N5YUlmbEVJK29lRnJrWFhU?= =?utf-8?B?ejRlUkdYYXVURVp3VmoyQk14MlZ1cSs3VW00elhMSDZLVmFaK0laQnZGTllX?= =?utf-8?B?UStXbGFtdFJSdkxCNE9FK3FDdmFGZ3BJLzBHRU42bDZOL2xlODlJVDN5Vi9F?= =?utf-8?B?a2xCc3ZnRThlVTB5bVVVZFhGU1BFekFsS2ZiRy9UR0ZHVW5TM1NDYVpDMTN5?= =?utf-8?B?elFvQ3Zmd0dZTk9QSUVYUTNSTUN6Wk5VT2kwMWlEMENmWmNhMEZFbHFkSFVq?= =?utf-8?B?Ly96ZVM5N3pmQ0FzL3MyQVBlOEdTTm95Slp5eGFkVmhwNzZCZm4xUHRnazl4?= =?utf-8?B?amxxZXRvV3FKYnAxWVk0NGEweWR6RzNBWmpYb3djTjNLRkdUNWNTQXVVb1Jk?= =?utf-8?B?VmlTV0NjNDhpeTJrencvcnJqTVNqLzdCaTNYYWNyeE00V0VtYW1OOGlRc3Rv?= =?utf-8?B?Qk9LRWRLeHNxZnhNYUhFVmhkZ2plSFpBdUpibzNvc1dFN002UVpoaU0yUVM5?= =?utf-8?B?eXloZnFuU0s2bWsvNXE1SUE1ZTd6TUJlZHV6MFNUcWRnOE1FRDFZK01YWk9E?= =?utf-8?B?T3E4VFc3bXV5eVB0dHVubnVUMWc5a2ZIekhiWWtBM010TG55ZHdDbm9rc1hR?= =?utf-8?B?RWlBLzZITC80R0NqTkx1RlZDbDFQby9PWlRjTWRqS2o4SHJ5Y2ZEV1hqbysx?= =?utf-8?B?VlZTUm1xZ3Rwb2tEdTA1MGtzeWNqd2RIbEJaY2tneGhJNWRMakJVdmYwcTEv?= =?utf-8?B?RE5CU3hVc09pdlpIU2Q4eHJQejh5REhoL3lvdTBSRWpFU0lTZ01rTjZLYUx1?= =?utf-8?B?OGsrZVBFdGZxeVB0MXFjOEtMZ1RWRWdhMlE0aTlMN1dIY1psT1MyNEdlcWtw?= =?utf-8?B?L3hkMnZlSFBiMXJ5a1IyZmxMNjloczd1YTlKTDdHb2VSZnRsWFZnd0o1dWFL?= =?utf-8?B?TXg2bG14OTZJUzJLblB6bnBuMU9pTjB3UFhVb1htZ1RrOW1lRkRoeGphTUdU?= =?utf-8?B?bXp4QT09?=
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2997; 6:g9egoPGkAV2IYpfZlYDcMdYm9J0WmzP+6eCVmuXTCExfQ/WGBroG398MsOxChFl2QwOlXyrYS4b6R2WIbgipDB5PJgda4wKYu74IqlH9znx+IuN9BXIFu0FIxeSminBaD18jSaktVjFDbhPonuJHzuKA4gVVzuyvQ/PxIINQBOz/ejzJ9BkB2sFd4uZmJExzkEqb836Jv+N+cYVKmacHTZo4R0LtXL1p2o5MfhkNX33aks0ueDCAonJFzldDpD1a6lchOY1tmMc2L/GFRyj8BFWi3tjwsCCggbHy+rMzxA6qVmB/nQvRILp0ImbCxz76m+3wtcJDiqQHrKmQD6itBg==; 5:OQGYAT71i4Ii8u8GBUr6jlBaorxXU+m39c5jFbwYOzpihBWgvtkgqMsd43i1lMOugPF9tQWAX7SK4iiTVDm/414CMvcPu0s6RZXYRh912MBoYEbjNt6uu9CLOiO0B69kVfuQ+Krok3ysejParMpOYQ==; 24:2vbaYmF9MtDFQmKNitSPaR2YCZ/ukOKeng6XTvey3ISH9v53RXc+fYNAD++hC5fsaFeU7z9iRYHfbYeLaU33G4t0jD3GyAv85CtMUmI9Fhc=; 7:ysAtVJVKf2P4LvreajNDew8GcrUSJmAbKqyx1YSLGrORimb6es9esKXnDzYu+tVJAADEkPrkB4B0oU177tDZlLuuM8E5UBtQfs+wX134dYTuxgzMYVd8DyTdJHL2wlGroZJaWvjZ5LiTNP3DPi9nEDhxDpbPBKuH53e6XbrodBMo02JhjQitcZE57GQ35mKWdhDpKcoe5EbGyU4oSWC57YPdT0VAgdHQ2nKQtvryhsc=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2017 16:14:11.0137 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2997
Archived-At: 
Subject: Re: [netmod] syslog-model-17 shepherd writeup issues -references
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Sep 2017 16:14:18 -0000

----- Original Message -----
From: "Kent Watsen" 
Sent: Wednesday, September 13, 2017 6:08 PM

> Hi Tom,
>
> Thanks.  The fix I'm looking for is for the 'pattern-match' leaf
> to have a 'reference' statement to Std-1003.1-2008, and for S4.1
> to also list Std-1003.1-2008 as a draft-level reference.

and I am unfamiliar with that standards body so am looking for a little
more.

Is STD-nnnn always Posix or do we need to say Posix 1003 or Posix
Std-1003 or is Std-1003 completely unrelated to Posix 1003?

Is there a difference between Std-1003.1-2008 and Posix 1003.2 ie is the
.1 or .2 significant?  You want Std-1003.1; the description contains
Posix 1003.2; the normative Reference is to Std-1003.1-2008.

You pointed out that the Normative Reference is not used; well if we can
sort out what the standard is and get the right label in Normative
References then we can - must - include this in Section 4.1 which will
resolve that comment of yours.

The discussions last July had Clyde saying he wants Posix 1003.2 so if
Std-1003 and Posix 1003 are the same but .1 and.2 are different, then
you are asking for a semantic change against Clyde's wishes.

I hope my confusion is sufficiently clear, at least to Clyde!

Tom Petch

>
> I was going to point out the typo "the the" as well, but figured
> that the RFC Editor would get it.
>
> K. // shepherd
>
>
> --
>
> Kent
>
> You flag Std-1003.1-2008 as listed as a normative reference but not
used
> anywhere in the document.  In the Descriptions, but not in the s.4.1
> references, I see
>
> This leaf describes a Posix 1003.2 regular expression ...
>
> twice, which may, or may not, relate to this issue.
>
> Back in July, clyde said
> "I will insert a normative reference to POSIX 1003.2 in the next
> revision of the draft."
>
> In a similar vein, RFC6991 appears in a reference statement but
nowhere
> else.
>
> As you point out, RFC6021 is referenced but is obsoleted by RFC6991 so
> should not be.
>
> And in a slightly different vein,
>
>    registry [RFC7895]/>.  Following the format in [RFC7950]/>, the the
>
> looks odd for plain text and for the repetition of 'the'..
>
> Tom Petch
>
> ----- Original Message -----
> From: "Kent Watsen" 
> To: 
> Cc: 
> Sent: Tuesday, September 12, 2017 10:50 PM
> Subject: [netmod] syslog-model-17 shepherd writeup issues
>
>
> > Clyde, all,
> >
> > In reviewing the draft for Shepherd writeup, I found the following
> issues that I think need to be addressed before the document can be
sent
> to Benoit for AD review:
> >
> >
> > 1. Idnits found the following:
> >
> >   Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment
> (--).
> >
> >     ** There are 2 instances of too long lines in the document, the
> longest one
> >          being 3 characters in excess of 72.
> >
> >     ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC
6991)
> >
> >     ** Downref: Normative reference to an Historic RFC: RFC 6587
> >
> >     == Missing Reference: 'RFC5425' is mentioned on line 359, but
not
> defined
> >          '[RFC5425], [RFC5426], [RFC6587], and [RFC5848]....'
> >
> >      == Unused Reference: 'RFC7895' is defined on line 1406, but no
> explicit
> >           reference was found in the text
> >           '[RFC7895]  Bierman, A., Bjorklund, M., and K. Watsen,
"YANG
> Module L...'
> >
> >      == Unused Reference: 'RFC6242' is defined on line 1435, but no
> explicit
> >           reference was found in the text
> >           '[RFC6242]  Wasserman, M., "Using the NETCONF Protocol
over
> Secure Sh...'
> >
> >
> > 2. `rfcstrip` extracted "ietf-syslog.yang",  which is missing
> "@yyyy-mm-dd" in its name
> >
> > 3.  neither `pyang` nor `yanglint` found any errors with
> ietf-syslog.yang.    pyang says
> >       for vendor-syslog-types-example: statement "identity" must
have
> a "description"
> >       substatement.
> >
> > 4. testing the examples in the draft against yanglint:
> >       - for both examples: Missing element's "namespace". (/config)
> >       - just removing the "" element envelop resolves this
> error.
> >
> > 5. the 2nd example uses IP address "2001:db8:a0b:12f0::1", but this
> SHOULD be a
> >      domain name (e.g., foo.example.com)
> >
> > 6. in the YANG module, anywhere you have an RFC listed in a
> 'description' statement,
> >      there should be a 'reference' statement for that RFC.
> >
> > 7. in the tree diagram, the leafrefs no longer indicate what they
> point at, they now all
> >      just say "leafref".  Did you do this on purpose, or are you
using
> a different tree
> >      output generator from -15?
> >
> > 8. RFC6536 is listed as a normative reference, but it probably
should
> be informative.
> >
> > 9. Std-1003.1-2008 is listed as a normative reference, but it is not
> used anywhere in the document.
> >
> > 10. RFC6242 is listed as an informative reference, but it is not
used
> anywhere in the document.
> >
> > 11. the document fails to declare its normative references to
> ietf-keystore and ietf-tls-client-server.
> >         Note: you manually entered the "[RFC yyyy], and [RFC xxxx]"
> references…
> >
> > 12.  The IANA considerations section seems asymmetric.  Either put
> both registry insertions into
> >         subsections, or keep them both at the top-level…
> >
> > 13. reviewing the final document against my original YD review, I
have
> the following responses.  Let's be sure to close out these items as
> well.  Ref:
https://mailarchive.ietf.org/arch/msg/netmod/10lo41Ud4A3ZN11
> s-0gOfCe8NSE
> >
> > 1. ok
> > 2. better
> > 3. should be: s/the message/these messages/  [RFC Editor might've
> caught this]
> > 4. better
> > 5. still feel the same way, but no biggee
> > 6. better, but from 8174, you should add the part "when, and only
> when, they appear in all capitals, as shown here."
> > 7. fixed
> > 8. fixed
> > 9. you did what I asked, but the result still isn't satisfying...
> > 10. some improvements made in this area, but my ask wasn't among
them
> > 11. better
> > 12. better, but I think the 4th line should be indented too, right?
> > 13. better, but I wish you called S1.3 "Tree Diagram Notation"
> > 14. fixed
> > 15. fixed
> > 16. fixed
> > 17. fine
> > 18. still a weird line brake here.  try putting the quoted string on
> the next line.
> > 19. fixed
> > 20. fixed
> > 21. not fixed (re: yang-security-guidelines)
> > 22. fine
> >
> >
> > PS: please also be sure to follow-up with Benoit on his AD review.
> >
> > Thanks,
> > Kent  // shepherd & yang doctor
> >
> >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
>
>
>
>


From nobody Thu Sep 14 09:15:14 2017
Return-Path: 
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 02554133041; Thu, 14 Sep 2017 09:15:13 -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 YpKVJn5S6OVb; Thu, 14 Sep 2017 09:15:11 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id BF38A133036; Thu, 14 Sep 2017 09:15:10 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id 6B9171820E78; Thu, 14 Sep 2017 18:17:48 +0200 (CEST)
Received: from localhost (cst-prg-18-212.cust.vodafone.cz [46.135.18.212]) by trail.lhotka.name (Postfix) with ESMTPSA id 3F4DC1820E71; Thu, 14 Sep 2017 18:17:45 +0200 (CEST)
From: Ladislav Lhotka 
To: Phil Shafer , Lou Berger 
Cc: "netmod-chairs\@ietf.org" , draft-ietf-netmod-revised-datastores@ietf.org, netmod WG 
In-Reply-To: <201709132258.v8DMwX9k073880@idle.juniper.net>
References: <201709132258.v8DMwX9k073880@idle.juniper.net>
Mail-Followup-To: Phil Shafer , Lou Berger , "netmod-chairs\@ietf.org" , draft-ietf-netmod-revised-datastores@ietf.org, netmod WG 
Date: Thu, 14 Sep 2017 18:15:40 +0200
Message-ID: <871sn9cl3n.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Sep 2017 16:15:13 -0000

Phil Shafer  writes:

> +
> +The implication of the existence of templating mechanisms is that
> + is now explicitly allowed to be invalid, since the
> +templating mechanism may be supplying additional data that satisfies
> +constraints that may be satisfied by  itself.
> +

Section 8.1 in RFC 7950 identifies some constraints that "are true in
all data trees". If they are violated in , it means that the
content is not a data tree as defined by YANG.

The same section also says that  MUST always be valid. This is
probably intended to be removed, but constraints that are supposed to
hold in all data trees should IMO stay no matter what.

Lada

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


From nobody Thu Sep 14 09:20:25 2017
Return-Path: 
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 67A33133036; Thu, 14 Sep 2017 09:20:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 HOb43lmFzdy6; Thu, 14 Sep 2017 09:20:20 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0135.outbound.protection.outlook.com [104.47.42.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 832D6132D47; Thu, 14 Sep 2017 09:20:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=u4D7SfJtsK+sqgi0aPYAEgfWywahctvUlq4ZZeVghFs=; b=V0E7RmZL41Ts/y4rIxKPrxjhS0ozd8XG0y/3n98Sy5exvEcWHmGpKZvzgcSbVZyXqmfc981vLPA9My0cZpC7AiMCttDhcOP5vnXRjszF4mFpeqHTSG6b3JC0sfqvxPaXUiWm6bx14RLA4Igbmpp4FRiyoafxeTzcG/R+kzJKdZA=
Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB321.namprd05.prod.outlook.com (10.141.24.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Thu, 14 Sep 2017 16:20:18 +0000
Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0035.010; Thu, 14 Sep 2017 16:20:18 +0000
From: Kent Watsen 
To: t.petch , "netmod@ietf.org" 
CC: "draft-ietf-netmod-syslog-model@ietf.org" 
Thread-Topic: [netmod] syslog-model-17 shepherd writeup issues -references
Thread-Index: AQHTLHc0HPi1rZXCNUadzeG98awlR6KyydeAgAHGQp7//76jgA==
Date: Thu, 14 Sep 2017 16:20:18 +0000
Message-ID: <5CE9EE07-D75D-4E5C-BC70-1F969732A526@juniper.net>
References: <49B4BE2F-6912-49BE-9E4A-830146309AB2@juniper.net> <019b01d32c76$fa7dfc40$4001a8c0@gateway.2wire.net> <8CF097E4-CEB7-4C4E-AC7D-F7F896CD1BB7@juniper.net> <00ae01d32d74$49e24c20$4001a8c0@gateway.2wire.net>
In-Reply-To: <00ae01d32d74$49e24c20$4001a8c0@gateway.2wire.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB321; 6:qa12//zmGWzJe733HNXXLM12Ge8mOVXpVLNNibjHEAr87y7JrU6Nws9VdHsu3L9T+3wFH5/hdOjmsyEaGX/I7TFnOqjg3wR4EbcqHjnPrMwyuG3ccotyuZYUQbX3r+BaebeE2LHC4hMskqRNbYBi5+KyhgjmOYLMTzb4pT/fnjbwXqPDLdPs/8LZCEuDd7AObg2SEiPJNQzBzCcfahwhjl1DhmhNDbfEAdk5TOYDffrPwalGwFikBDBHxEJYA+MLbZo9QWEr1u2f1tTXmQgbDiGW2KoWmVc6XWn35vJjSNbjEYpbq+JBEDdiuClPP5M9xH3TBtyo1HkadJzeWa6HtA==; 5:yMgrQjssxbjGgnw87kgYu0P29yHIyK0jDpcn/txQJsq6ZIM0OoJY00u/pZTY5KpioZFU9PgomaygwEnXqhldZf1bvh4TowJydA25pSVlFdMV2wtO7WQhhCtMTOJ+//h66xG/kG3YVTA+4AOYLek7aw==; 24:anZp8MfRMmAz3TFaSZ6zeoKIpyK4SaMr/3QlphLvfm6MGHDmpLlGrcvErJDrKA24eO0zmh5l/yvbVH9RuRWB4kEz8W0ZYbmdjCzhkk/4OYs=; 7:2p2RvSPXyt/2/wYCoujncVcvrhnOTraWcga3SI9pJdK86WeiO6NrJR7kTM7kpSJK23tWBiJTGUvRzNawAMhlbXh/wORtpw2yq2IiKfGDNIsNpsu9dhevWYfm4gRVkfnIkBX9e0yeqWu42UQZpGOlsMRBn4RYK+Jzv5GICj/yDRgx9koeyU3q87PaErMx3i2uehkF7Mt8kNYCFFEWRH0CWggPQdrpv2iXyNpqZwOC+w0=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: cbdf5bd3-654d-402c-ea19-08d4fb8c7dc0
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR05MB321; 
x-ms-traffictypediagnostic: BLUPR05MB321:
x-exchange-antispam-report-test: UriScan:(138986009662008);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB321; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB321; 
x-forefront-prvs: 0430FA5CB7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39860400002)(199003)(13464003)(57704003)(377454003)(189002)(7736002)(2906002)(8676002)(3660700001)(8936002)(2501003)(105586002)(36756003)(3280700002)(305945005)(66066001)(76176999)(50986999)(6436002)(101416001)(83506001)(6306002)(54356999)(83716003)(6246003)(5660300001)(53936002)(230783001)(6506006)(316002)(93886005)(99286003)(33656002)(25786009)(6512007)(68736007)(77096006)(14454004)(97736004)(4001350100001)(4326008)(2950100002)(81156014)(229853002)(2900100001)(189998001)(82746002)(478600001)(106356001)(81166006)(966005)(575784001)(86362001)(102836003)(6486002)(6116002)(8666007)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB321; H:BLUPR05MB275.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: 14 Sep 2017 16:20:18.8308 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB321
Archived-At: 
Subject: Re: [netmod] syslog-model-17 shepherd writeup issues -references
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Sep 2017 16:20:23 -0000

SSBtZWFudCB0byBzYXkgc29tZXRoaW5nIGFib3V0IHRoZSAuMSB2cyAuMiBkaWZmZXJlbmNlLiAg
TXkgY29tbWVudA0KYXNzdW1lcyB0aGF0IGl0J3Mgc3VwcG9zZWQgdG8gYmUgLjEsIGJ1dCB3ZSBv
ZiBjb3Vyc2Ugc2hvdWxkIHVzZQ0Kd2hhdGV2ZXIgaXMgY29ycmVjdC4NCg0KSSBhbHNvIGRvbid0
IGtub3cgbXVjaCBhYm91dCB0aGF0IHN0YW5kYXJkcyBib2R5Lg0KDQpLLg0KDQoNCg0KLS0tLS0g
T3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIktlbnQgV2F0c2VuIiA8a3dhdHNlbkBqdW5p
cGVyLm5ldD4NClNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDEzLCAyMDE3IDY6MDggUE0NCg0K
PiBIaSBUb20sDQo+DQo+IFRoYW5rcy4gIFRoZSBmaXggSSdtIGxvb2tpbmcgZm9yIGlzIGZvciB0
aGUgJ3BhdHRlcm4tbWF0Y2gnIGxlYWYNCj4gdG8gaGF2ZSBhICdyZWZlcmVuY2UnIHN0YXRlbWVu
dCB0byBTdGQtMTAwMy4xLTIwMDgsIGFuZCBmb3IgUzQuMQ0KPiB0byBhbHNvIGxpc3QgU3RkLTEw
MDMuMS0yMDA4IGFzIGEgZHJhZnQtbGV2ZWwgcmVmZXJlbmNlLg0KDQphbmQgSSBhbSB1bmZhbWls
aWFyIHdpdGggdGhhdCBzdGFuZGFyZHMgYm9keSBzbyBhbSBsb29raW5nIGZvciBhIGxpdHRsZQ0K
bW9yZS4NCg0KSXMgU1RELW5ubm4gYWx3YXlzIFBvc2l4IG9yIGRvIHdlIG5lZWQgdG8gc2F5IFBv
c2l4IDEwMDMgb3IgUG9zaXgNClN0ZC0xMDAzIG9yIGlzIFN0ZC0xMDAzIGNvbXBsZXRlbHkgdW5y
ZWxhdGVkIHRvIFBvc2l4IDEwMDM/DQoNCklzIHRoZXJlIGEgZGlmZmVyZW5jZSBiZXR3ZWVuIFN0
ZC0xMDAzLjEtMjAwOCBhbmQgUG9zaXggMTAwMy4yIGllIGlzIHRoZQ0KLjEgb3IgLjIgc2lnbmlm
aWNhbnQ/ICBZb3Ugd2FudCBTdGQtMTAwMy4xOyB0aGUgZGVzY3JpcHRpb24gY29udGFpbnMNClBv
c2l4IDEwMDMuMjsgdGhlIG5vcm1hdGl2ZSBSZWZlcmVuY2UgaXMgdG8gU3RkLTEwMDMuMS0yMDA4
Lg0KDQpZb3UgcG9pbnRlZCBvdXQgdGhhdCB0aGUgTm9ybWF0aXZlIFJlZmVyZW5jZSBpcyBub3Qg
dXNlZDsgd2VsbCBpZiB3ZSBjYW4NCnNvcnQgb3V0IHdoYXQgdGhlIHN0YW5kYXJkIGlzIGFuZCBn
ZXQgdGhlIHJpZ2h0IGxhYmVsIGluIE5vcm1hdGl2ZQ0KUmVmZXJlbmNlcyB0aGVuIHdlIGNhbiAt
IG11c3QgLSBpbmNsdWRlIHRoaXMgaW4gU2VjdGlvbiA0LjEgd2hpY2ggd2lsbA0KcmVzb2x2ZSB0
aGF0IGNvbW1lbnQgb2YgeW91cnMuDQoNClRoZSBkaXNjdXNzaW9ucyBsYXN0IEp1bHkgaGFkIENs
eWRlIHNheWluZyBoZSB3YW50cyBQb3NpeCAxMDAzLjIgc28gaWYNClN0ZC0xMDAzIGFuZCBQb3Np
eCAxMDAzIGFyZSB0aGUgc2FtZSBidXQgLjEgYW5kLjIgYXJlIGRpZmZlcmVudCwgdGhlbg0KeW91
IGFyZSBhc2tpbmcgZm9yIGEgc2VtYW50aWMgY2hhbmdlIGFnYWluc3QgQ2x5ZGUncyB3aXNoZXMu
DQoNCkkgaG9wZSBteSBjb25mdXNpb24gaXMgc3VmZmljaWVudGx5IGNsZWFyLCBhdCBsZWFzdCB0
byBDbHlkZSENCg0KVG9tIFBldGNoDQoNCj4NCj4gSSB3YXMgZ29pbmcgdG8gcG9pbnQgb3V0IHRo
ZSB0eXBvICJ0aGUgdGhlIiBhcyB3ZWxsLCBidXQgZmlndXJlZA0KPiB0aGF0IHRoZSBSRkMgRWRp
dG9yIHdvdWxkIGdldCBpdC4NCj4NCj4gSy4gLy8gc2hlcGhlcmQNCj4NCj4NCj4gLS0NCj4NCj4g
S2VudA0KPg0KPiBZb3UgZmxhZyBTdGQtMTAwMy4xLTIwMDggYXMgbGlzdGVkIGFzIGEgbm9ybWF0
aXZlIHJlZmVyZW5jZSBidXQgbm90DQp1c2VkDQo+IGFueXdoZXJlIGluIHRoZSBkb2N1bWVudC4g
IEluIHRoZSBEZXNjcmlwdGlvbnMsIGJ1dCBub3QgaW4gdGhlIHMuNC4xDQo+IHJlZmVyZW5jZXMs
IEkgc2VlDQo+DQo+IFRoaXMgbGVhZiBkZXNjcmliZXMgYSBQb3NpeCAxMDAzLjIgcmVndWxhciBl
eHByZXNzaW9uIC4uLg0KPg0KPiB0d2ljZSwgd2hpY2ggbWF5LCBvciBtYXkgbm90LCByZWxhdGUg
dG8gdGhpcyBpc3N1ZS4NCj4NCj4gQmFjayBpbiBKdWx5LCBjbHlkZSBzYWlkDQo+ICJJIHdpbGwg
aW5zZXJ0IGEgbm9ybWF0aXZlIHJlZmVyZW5jZSB0byBQT1NJWCAxMDAzLjIgaW4gdGhlIG5leHQN
Cj4gcmV2aXNpb24gb2YgdGhlIGRyYWZ0LiINCj4NCj4gSW4gYSBzaW1pbGFyIHZlaW4sIFJGQzY5
OTEgYXBwZWFycyBpbiBhIHJlZmVyZW5jZSBzdGF0ZW1lbnQgYnV0DQpub3doZXJlDQo+IGVsc2Uu
DQo+DQo+IEFzIHlvdSBwb2ludCBvdXQsIFJGQzYwMjEgaXMgcmVmZXJlbmNlZCBidXQgaXMgb2Jz
b2xldGVkIGJ5IFJGQzY5OTEgc28NCj4gc2hvdWxkIG5vdCBiZS4NCj4NCj4gQW5kIGluIGEgc2xp
Z2h0bHkgZGlmZmVyZW50IHZlaW4sDQo+DQo+ICAgIHJlZ2lzdHJ5IFtSRkM3ODk1XS8+LiAgRm9s
bG93aW5nIHRoZSBmb3JtYXQgaW4gW1JGQzc5NTBdLz4sIHRoZSB0aGUNCj4NCj4gbG9va3Mgb2Rk
IGZvciBwbGFpbiB0ZXh0IGFuZCBmb3IgdGhlIHJlcGV0aXRpb24gb2YgJ3RoZScuLg0KPg0KPiBU
b20gUGV0Y2gNCj4NCj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiBGcm9tOiAiS2Vu
dCBXYXRzZW4iIDxrd2F0c2VuQGp1bmlwZXIubmV0Pg0KPiBUbzogPG5ldG1vZEBpZXRmLm9yZz4N
Cj4gQ2M6IDxkcmFmdC1pZXRmLW5ldG1vZC1zeXNsb2ctbW9kZWxAaWV0Zi5vcmc+DQo+IFNlbnQ6
IFR1ZXNkYXksIFNlcHRlbWJlciAxMiwgMjAxNyAxMDo1MCBQTQ0KPiBTdWJqZWN0OiBbbmV0bW9k
XSBzeXNsb2ctbW9kZWwtMTcgc2hlcGhlcmQgd3JpdGV1cCBpc3N1ZXMNCj4NCj4NCj4gPiBDbHlk
ZSwgYWxsLA0KPiA+DQo+ID4gSW4gcmV2aWV3aW5nIHRoZSBkcmFmdCBmb3IgU2hlcGhlcmQgd3Jp
dGV1cCwgSSBmb3VuZCB0aGUgZm9sbG93aW5nDQo+IGlzc3VlcyB0aGF0IEkgdGhpbmsgbmVlZCB0
byBiZSBhZGRyZXNzZWQgYmVmb3JlIHRoZSBkb2N1bWVudCBjYW4gYmUNCnNlbnQNCj4gdG8gQmVu
b2l0IGZvciBBRCByZXZpZXc6DQo+ID4NCj4gPg0KPiA+IDEuIElkbml0cyBmb3VuZCB0aGUgZm9s
bG93aW5nOg0KPiA+DQo+ID4gICBTdW1tYXJ5OiAzIGVycm9ycyAoKiopLCAwIGZsYXdzICh+fiks
IDMgd2FybmluZ3MgKD09KSwgMSBjb21tZW50DQo+ICgtLSkuDQo+ID4NCj4gPiAgICAgKiogVGhl
cmUgYXJlIDIgaW5zdGFuY2VzIG9mIHRvbyBsb25nIGxpbmVzIGluIHRoZSBkb2N1bWVudCwgdGhl
DQo+IGxvbmdlc3Qgb25lDQo+ID4gICAgICAgICAgYmVpbmcgMyBjaGFyYWN0ZXJzIGluIGV4Y2Vz
cyBvZiA3Mi4NCj4gPg0KPiA+ICAgICAqKiBPYnNvbGV0ZSBub3JtYXRpdmUgcmVmZXJlbmNlOiBS
RkMgNjAyMSAoT2Jzb2xldGVkIGJ5IFJGQw0KNjk5MSkNCj4gPg0KPiA+ICAgICAqKiBEb3ducmVm
OiBOb3JtYXRpdmUgcmVmZXJlbmNlIHRvIGFuIEhpc3RvcmljIFJGQzogUkZDIDY1ODcNCj4gPg0K
PiA+ICAgICA9PSBNaXNzaW5nIFJlZmVyZW5jZTogJ1JGQzU0MjUnIGlzIG1lbnRpb25lZCBvbiBs
aW5lIDM1OSwgYnV0DQpub3QNCj4gZGVmaW5lZA0KPiA+ICAgICAgICAgICdbUkZDNTQyNV0sIFtS
RkM1NDI2XSwgW1JGQzY1ODddLCBhbmQgW1JGQzU4NDhdLi4uLicNCj4gPg0KPiA+ICAgICAgPT0g
VW51c2VkIFJlZmVyZW5jZTogJ1JGQzc4OTUnIGlzIGRlZmluZWQgb24gbGluZSAxNDA2LCBidXQg
bm8NCj4gZXhwbGljaXQNCj4gPiAgICAgICAgICAgcmVmZXJlbmNlIHdhcyBmb3VuZCBpbiB0aGUg
dGV4dA0KPiA+ICAgICAgICAgICAnW1JGQzc4OTVdICBCaWVybWFuLCBBLiwgQmpvcmtsdW5kLCBN
LiwgYW5kIEsuIFdhdHNlbiwNCiJZQU5HDQo+IE1vZHVsZSBMLi4uJw0KPiA+DQo+ID4gICAgICA9
PSBVbnVzZWQgUmVmZXJlbmNlOiAnUkZDNjI0MicgaXMgZGVmaW5lZCBvbiBsaW5lIDE0MzUsIGJ1
dCBubw0KPiBleHBsaWNpdA0KPiA+ICAgICAgICAgICByZWZlcmVuY2Ugd2FzIGZvdW5kIGluIHRo
ZSB0ZXh0DQo+ID4gICAgICAgICAgICdbUkZDNjI0Ml0gIFdhc3Nlcm1hbiwgTS4sICJVc2luZyB0
aGUgTkVUQ09ORiBQcm90b2NvbA0Kb3Zlcg0KPiBTZWN1cmUgU2guLi4nDQo+ID4NCj4gPg0KPiA+
IDIuIGByZmNzdHJpcGAgZXh0cmFjdGVkICJpZXRmLXN5c2xvZy55YW5nIiwgIHdoaWNoIGlzIG1p
c3NpbmcNCj4gIkB5eXl5LW1tLWRkIiBpbiBpdHMgbmFtZQ0KPiA+DQo+ID4gMy4gIG5laXRoZXIg
YHB5YW5nYCBub3IgYHlhbmdsaW50YCBmb3VuZCBhbnkgZXJyb3JzIHdpdGgNCj4gaWV0Zi1zeXNs
b2cueWFuZy4gICAgcHlhbmcgc2F5cw0KPiA+ICAgICAgIGZvciB2ZW5kb3Itc3lzbG9nLXR5cGVz
LWV4YW1wbGU6IHN0YXRlbWVudCAiaWRlbnRpdHkiIG11c3QNCmhhdmUNCj4gYSAiZGVzY3JpcHRp
b24iDQo+ID4gICAgICAgc3Vic3RhdGVtZW50Lg0KPiA+DQo+ID4gNC4gdGVzdGluZyB0aGUgZXhh
bXBsZXMgaW4gdGhlIGRyYWZ0IGFnYWluc3QgeWFuZ2xpbnQ6DQo+ID4gICAgICAgLSBmb3IgYm90
aCBleGFtcGxlczogTWlzc2luZyBlbGVtZW50J3MgIm5hbWVzcGFjZSIuICgvY29uZmlnKQ0KPiA+
ICAgICAgIC0ganVzdCByZW1vdmluZyB0aGUgIjxjb25maWc+IiBlbGVtZW50IGVudmVsb3AgcmVz
b2x2ZXMgdGhpcw0KPiBlcnJvci4NCj4gPg0KPiA+IDUuIHRoZSAybmQgZXhhbXBsZSB1c2VzIElQ
IGFkZHJlc3MgIjIwMDE6ZGI4OmEwYjoxMmYwOjoxIiwgYnV0IHRoaXMNCj4gU0hPVUxEIGJlIGEN
Cj4gPiAgICAgIGRvbWFpbiBuYW1lIChlLmcuLCBmb28uZXhhbXBsZS5jb20pDQo+ID4NCj4gPiA2
LiBpbiB0aGUgWUFORyBtb2R1bGUsIGFueXdoZXJlIHlvdSBoYXZlIGFuIFJGQyBsaXN0ZWQgaW4g
YQ0KPiAnZGVzY3JpcHRpb24nIHN0YXRlbWVudCwNCj4gPiAgICAgIHRoZXJlIHNob3VsZCBiZSBh
ICdyZWZlcmVuY2UnIHN0YXRlbWVudCBmb3IgdGhhdCBSRkMuDQo+ID4NCj4gPiA3LiBpbiB0aGUg
dHJlZSBkaWFncmFtLCB0aGUgbGVhZnJlZnMgbm8gbG9uZ2VyIGluZGljYXRlIHdoYXQgdGhleQ0K
PiBwb2ludCBhdCwgdGhleSBub3cgYWxsDQo+ID4gICAgICBqdXN0IHNheSAibGVhZnJlZiIuICBE
aWQgeW91IGRvIHRoaXMgb24gcHVycG9zZSwgb3IgYXJlIHlvdQ0KdXNpbmcNCj4gYSBkaWZmZXJl
bnQgdHJlZQ0KPiA+ICAgICAgb3V0cHV0IGdlbmVyYXRvciBmcm9tIC0xNT8NCj4gPg0KPiA+IDgu
IFJGQzY1MzYgaXMgbGlzdGVkIGFzIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSwgYnV0IGl0IHByb2Jh
Ymx5DQpzaG91bGQNCj4gYmUgaW5mb3JtYXRpdmUuDQo+ID4NCj4gPiA5LiBTdGQtMTAwMy4xLTIw
MDggaXMgbGlzdGVkIGFzIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSwgYnV0IGl0IGlzIG5vdA0KPiB1
c2VkIGFueXdoZXJlIGluIHRoZSBkb2N1bWVudC4NCj4gPg0KPiA+IDEwLiBSRkM2MjQyIGlzIGxp
c3RlZCBhcyBhbiBpbmZvcm1hdGl2ZSByZWZlcmVuY2UsIGJ1dCBpdCBpcyBub3QNCnVzZWQNCj4g
YW55d2hlcmUgaW4gdGhlIGRvY3VtZW50Lg0KPiA+DQo+ID4gMTEuIHRoZSBkb2N1bWVudCBmYWls
cyB0byBkZWNsYXJlIGl0cyBub3JtYXRpdmUgcmVmZXJlbmNlcyB0bw0KPiBpZXRmLWtleXN0b3Jl
IGFuZCBpZXRmLXRscy1jbGllbnQtc2VydmVyLg0KPiA+ICAgICAgICAgTm90ZTogeW91IG1hbnVh
bGx5IGVudGVyZWQgdGhlICJbUkZDIHl5eXldLCBhbmQgW1JGQyB4eHh4XSINCj4gcmVmZXJlbmNl
c+KApg0KPiA+DQo+ID4gMTIuICBUaGUgSUFOQSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIHNlZW1z
IGFzeW1tZXRyaWMuICBFaXRoZXIgcHV0DQo+IGJvdGggcmVnaXN0cnkgaW5zZXJ0aW9ucyBpbnRv
DQo+ID4gICAgICAgICBzdWJzZWN0aW9ucywgb3Iga2VlcCB0aGVtIGJvdGggYXQgdGhlIHRvcC1s
ZXZlbOKApg0KPiA+DQo+ID4gMTMuIHJldmlld2luZyB0aGUgZmluYWwgZG9jdW1lbnQgYWdhaW5z
dCBteSBvcmlnaW5hbCBZRCByZXZpZXcsIEkNCmhhdmUNCj4gdGhlIGZvbGxvd2luZyByZXNwb25z
ZXMuICBMZXQncyBiZSBzdXJlIHRvIGNsb3NlIG91dCB0aGVzZSBpdGVtcyBhcw0KPiB3ZWxsLiAg
UmVmOg0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9uZXRtb2QvMTBsbzQx
VWQ0QTNaTjExDQo+IHMtMGdPZkNlOE5TRQ0KPiA+DQo+ID4gMS4gb2sNCj4gPiAyLiBiZXR0ZXIN
Cj4gPiAzLiBzaG91bGQgYmU6IHMvdGhlIG1lc3NhZ2UvdGhlc2UgbWVzc2FnZXMvICBbUkZDIEVk
aXRvciBtaWdodCd2ZQ0KPiBjYXVnaHQgdGhpc10NCj4gPiA0LiBiZXR0ZXINCj4gPiA1LiBzdGls
bCBmZWVsIHRoZSBzYW1lIHdheSwgYnV0IG5vIGJpZ2dlZQ0KPiA+IDYuIGJldHRlciwgYnV0IGZy
b20gODE3NCwgeW91IHNob3VsZCBhZGQgdGhlIHBhcnQgIndoZW4sIGFuZCBvbmx5DQo+IHdoZW4s
IHRoZXkgYXBwZWFyIGluIGFsbCBjYXBpdGFscywgYXMgc2hvd24gaGVyZS4iDQo+ID4gNy4gZml4
ZWQNCj4gPiA4LiBmaXhlZA0KPiA+IDkuIHlvdSBkaWQgd2hhdCBJIGFza2VkLCBidXQgdGhlIHJl
c3VsdCBzdGlsbCBpc24ndCBzYXRpc2Z5aW5nLi4uDQo+ID4gMTAuIHNvbWUgaW1wcm92ZW1lbnRz
IG1hZGUgaW4gdGhpcyBhcmVhLCBidXQgbXkgYXNrIHdhc24ndCBhbW9uZw0KdGhlbQ0KPiA+IDEx
LiBiZXR0ZXINCj4gPiAxMi4gYmV0dGVyLCBidXQgSSB0aGluayB0aGUgNHRoIGxpbmUgc2hvdWxk
IGJlIGluZGVudGVkIHRvbywgcmlnaHQ/DQo+ID4gMTMuIGJldHRlciwgYnV0IEkgd2lzaCB5b3Ug
Y2FsbGVkIFMxLjMgIlRyZWUgRGlhZ3JhbSBOb3RhdGlvbiINCj4gPiAxNC4gZml4ZWQNCj4gPiAx
NS4gZml4ZWQNCj4gPiAxNi4gZml4ZWQNCj4gPiAxNy4gZmluZQ0KPiA+IDE4LiBzdGlsbCBhIHdl
aXJkIGxpbmUgYnJha2UgaGVyZS4gIHRyeSBwdXR0aW5nIHRoZSBxdW90ZWQgc3RyaW5nIG9uDQo+
IHRoZSBuZXh0IGxpbmUuDQo+ID4gMTkuIGZpeGVkDQo+ID4gMjAuIGZpeGVkDQo+ID4gMjEuIG5v
dCBmaXhlZCAocmU6IHlhbmctc2VjdXJpdHktZ3VpZGVsaW5lcykNCj4gPiAyMi4gZmluZQ0KPiA+
DQo+ID4NCj4gPiBQUzogcGxlYXNlIGFsc28gYmUgc3VyZSB0byBmb2xsb3ctdXAgd2l0aCBCZW5v
aXQgb24gaGlzIEFEIHJldmlldy4NCj4gPg0KPiA+IFRoYW5rcywNCj4gPiBLZW50ICAvLyBzaGVw
aGVyZCAmIHlhbmcgZG9jdG9yDQo+ID4NCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+
ID4gbmV0bW9kQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9uZXRtb2QNCj4gPg0KPg0KPg0KPg0KPg0KDQoNCg0K


From nobody Thu Sep 14 09:32:28 2017
Return-Path: 
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 BB118133045 for ; Thu, 14 Sep 2017 09:32:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 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, 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 cHfu-4YpQ8UW for ; Thu, 14 Sep 2017 09:32:25 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDF05132D47 for ; Thu, 14 Sep 2017 09:32:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3390; q=dns/txt; s=iport; t=1505406744; x=1506616344; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=LjkFH+70vODQgL2GQevfXdqAWZvwZfv940IoDh5SsU8=; b=M0mUSa1T6ueMQHJX0LppmfxB+40UsVLAE6Tpjtyw3vFU0nnZ2Vy5U3Of jXesePO8lKK0a53OXhAjFm0b0W9YjRg6Pg4IINFhT5UAlQkeyHXfMkfr3 wDJ14Mk42pMBqSp6VSb46P4vusHlWc6btnHGnhZ0PVNnfbD4jNo9uE6j2 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CxAQBtrrpZ/4gNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbieDd5taCSKYOgoYC4RKTwKEJEMUAQIBAQEBAQEBayiFGAE?= =?us-ascii?q?BAQECAQEBIQQLATsLEAkCGAICIwMCAicfEQYBDAYCAQGKJggQjjCdZoFtOosyA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBHYEOgh2CAoFQgg4LgnKIC4JgBYwnhQePVId?= =?us-ascii?q?ajHiCbohnhyGVMYE5NiGBDVMkFUqFGRyCAyQ2iG0BAQE?=
X-IronPort-AV: E=Sophos;i="5.42,394,1500940800"; d="scan'208";a="298420297"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Sep 2017 16:32:23 +0000
Received: from [10.118.87.94] (rtp-jclarke-nitro13.cisco.com [10.118.87.94]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v8EGWNqV032095; Thu, 14 Sep 2017 16:32:23 GMT
To: Balazs Lengyel , Andy Bierman 
Cc: "netmod@ietf.org" 
References: <9d84d068-29ba-8e89-394f-b7f6a5272adc@cisco.com>   <996db3ee-c3f0-a8f3-8c94-8471a4ce8dc0@ericsson.com>
From: Joe Clarke 
Organization: Cisco
Message-ID: 
Date: Thu, 14 Sep 2017 12:32:23 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <996db3ee-c3f0-a8f3-8c94-8471a4ce8dc0@ericsson.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Sep 2017 16:32:27 -0000

On 9/14/17 12:13, Balazs Lengyel wrote:
> Did you consider to have a concise and a verbose tree output selected by
> an option?

I did.  I wanted to get some broader feedback, but I figured people
would want something like --tree-print-expanded-types or the like.

Joe

> 
> regards Balazs
> 
> 
> On 2017-09-14 17:58, Joe Clarke wrote:
>> On 9/14/17 11:43, Andy Bierman wrote:
>>> Hi,
>>>
>>>
>>> Actually I liked the early pyang output that was concise and easy to
>>> remember.
>>> The current format gets very cluttered and there are too many little
>>> symbols
>>> to remember them all.
>> I just went with text for these changes.  Yes, it adds more verbiage to
>> the output, but it doesn't add any cryptic symbols; plus I think it
>> makes it easier to comprehend the types.
>>
>> Joe
>>
>>>
>>> Andy
>>>
>>>
>>> On Thu, Sep 14, 2017 at 8:33 AM, Joe Clarke >> > wrote:
>>>
>>>      I've been hacking on pyang, and I changed tree.py to add the
>>> enum values
>>>      for enumeration types and identiyref bases for identityref
>>> types.  Here
>>>      is an example:
>>>
>>>      module: yang-catalog
>>>          +--rw catalog
>>>             +--rw modules
>>>             |  +--rw module* [name revision organization]
>>>             |     +--rw name                     yang:yang-identifier
>>>             |     +--rw revision                 union
>>>             |     +--rw organization             string
>>>             |     +--rw ietf
>>>             |     |  +--rw ietf-wg?   string
>>>             |     +--rw namespace                inet:uri
>>>             |     +--rw schema?                  inet:uri
>>>             |     +--rw generated-from?          enumeration [mib, code,
>>>      not-applicable, native]
>>>             |     +--rw maturity-level?          enumeration [ratified,
>>>      adopted, initial, not-applicable]
>>>      ...
>>>                                     +--rw protocols
>>>                                     |  +--rw protocol* [name]
>>>                                     |     +--rw name
>>>      identityref -> protocol
>>>      ...
>>>
>>>      My questions are:
>>>
>>>      1. Is this useful?
>>>
>>>      2. If so, can this be added to pyang (happy to submit a PR) and
>>>      draft-ietf-netmod-yang-tree-diagrams?
>>>
>>>      3. What changes to the output format would you recommend?
>>>
>>>      Thanks.
>>>
>>>      Joe
>>>
>>>      _______________________________________________
>>>      netmod mailing list
>>>      netmod@ietf.org 
>>>      https://www.ietf.org/mailman/listinfo/netmod
>>>      
>>>
>>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Thu Sep 14 09:39:20 2017
Return-Path: 
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 575BF13305C for ; Thu, 14 Sep 2017 09:39:18 -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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_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 rPZnkGBu8wp4 for ; Thu, 14 Sep 2017 09:39:16 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0126.outbound.protection.outlook.com [104.47.2.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC195132924 for ; Thu, 14 Sep 2017 09:39:15 -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=JbtF7pexBm0o7dQpvm3wCME0QEEK9ZYphN7nBzEdsmc=; b=Z9aE81YkMn2YSrB3LJNyk2/DFRpMsgK1z4rQOe4XxbzQ7+PCNSP7qlgvi+fibrDYvGo6WjjoZw0btwuSye/cWQLIjDPaVRT9JemUlavc8VkBg50/f9Zme/LJbwMODLBjDA+CjWq6A0uTuk2t2VwTy4xA3uog9/f9XkM/32wCioA=
Received: from pc6 (86.185.245.5) by VI1PR0701MB3007.eurprd07.prod.outlook.com (2603:10a6:800:87::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Thu, 14 Sep 2017 16:39:12 +0000
Message-ID: <011d01d32d77$c8e0a500$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Kent Watsen" , "Robert Wilton" ,  "Lou Berger" , 
References: <14299503-509D-43BE-A938-0B7B88C3B249@juniper.net> <36ba3d4b-1ae1-0666-12cf-db41e172924b@cisco.com> <75739d75-da96-b340-2403-d0949ac54ed7@labn.net> <19134054-D52E-4A6D-992A-A47F365557AD@juniper.net> <2891bd09-0e0d-415c-2714-15141a293e42@cisco.com> 
Date: Thu, 14 Sep 2017 17:36:12 +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: [86.185.245.5]
X-ClientProxiedBy: DB6PR07CA0180.eurprd07.prod.outlook.com (2603:10a6:6:43::34) To VI1PR0701MB3007.eurprd07.prod.outlook.com (2603:10a6:800:87::21)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 304a9f2e-28b5-4df9-00ef-08d4fb8f21a9
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:VI1PR0701MB3007; 
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 3:2SZoNn7glOqB5/zfbnl9aC/GHZPDg26Ay0+EXMo6e9nPbbXMz64LmgJUqbwl2lMMMpxG7HtcaWbE58rU1ZCLoTogkqnCrO1wuO04Iajx9JzRMn/5NklHgeByimzkBouJZbQHnhAWn9Tdkkasi0R5D9hEVOLjNJLSBDgVLS74YPir7snPBSsSJvr5YnT85dUFJ1FiPocK+BOV+vxKnzQY40eD6Q3EsKZyJ4uQZ6r2Vf2DBBaTHKnUXMADL14ZEH+r; 25:9PUjGEnwIlyTi4NCDAhlgKmPuBy6kUNGbMTTppUilhvDc4v//DY8ebY7au54NDE7xQo/e5MzKe3hNXH6+UeVCmBsT9EnuGraVTskYAhDjuyN8M57All3AH6iWJqUVTjmrb+jpHoGXuhrSVQXBNXPiQNl6TEtjO95LCg3+ynd6ITSueHtH/lgqKhUCRafPRKPgwrwRGwP3yFGzY4JHmWcVj4Y0un00lTfd2LIOfMSpHslkB6BsIh5fc+8+BqFVrU3+A2Q1VY1J+9dBb8Q98iDxZ+c5N7CzMlVXMV3UPDmpfbNG++bxbVKHif3L9RVi3g0n6mACRR8W1DcqJyoRxY8ZA==; 31:mzhHKOHVFYcux8BPzmKzYXPnfRYk9kPGEARn2o8UoShspjTPEJU0BsBjiFrtQm5cZMVQ1TwLz+f69zjNySHPU5l+H9Wox4ESbecyxSX1SntpmLlhH5CkfLaa51RE+HTjzZWefon0T14K0FWqeEL5GAxI5/GXw/mBMP48hNo6bHYNRZEATZTO/bDTkSxwcEw2iYM4i0oZBs5Zk0IBViUmOg+CSglEo65DgxksjBH0rqU=
X-MS-TrafficTypeDiagnostic: VI1PR0701MB3007:
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 20:qQqkf+tO9zQQzBup6Yx21n+JzKFUBvrF9me4Q8CpHuy90Ler+vvcApXHlbYOUEGu3ptPMoWB0jVE177zcyDRoCbuaIu78HZHPW0Aj/c4IIUK5E9Op9Ilx+T8u/4afUz4F5tHDVv7SevdMSxhmGtLTw3eA9mv0JDeBXKxFYbkJBU0R4NUtYYYV/XE7dren5NBFrxeP4o3DP8HBSkvc9nu5cXA8BL/9FwPaNtWIxnZBcCQKTcYEjfA0X+vD4Ch/0JN; 4:m6TRV1QkqTXf1UQ7nsu2/8zv/aZpLfTgneE0WKBgYiWzlZbnszskn4mQVHVhIKRTEK9treDWihsn8HD4BevbccCC3XXQkl+u2tJvW32313ApFJlx89T3zi8o3PSlOix7Ty+jl1dkI2PO7Nf7OoDCuZoSL+SGD2FlKn1XYjY+r6MSG4v4DLI+zsN7o15VYvh+1X97tf/ApRgLIs1EM3Si+yZ2qPq7sKOOf7KVq29+lWaq3GifFzLIa+/RKCmmWkVjMpzDjFCTPvYzk2ty+3o6ZJtn1DbigQ9ZPodmdt3Xv30=
X-Exchange-Antispam-Report-Test: UriScan:(138986009662008);
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6041248)(20161123564025)(20161123558100)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR0701MB3007; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR0701MB3007; 
X-Forefront-PRVS: 0430FA5CB7
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6009001)(39860400002)(376002)(346002)(13464003)(199003)(189002)(44716002)(62236002)(478600001)(101416001)(305945005)(1941001)(7736002)(105586002)(106356001)(47776003)(23756003)(61296003)(6496005)(93886005)(7350300001)(33646002)(6246003)(14496001)(66066001)(50226002)(6486002)(9686003)(44736005)(6306002)(25786009)(189998001)(8666007)(229853002)(4720700003)(68736007)(116806002)(50466002)(966005)(8676002)(53936002)(2906002)(5660300001)(3846002)(81156014)(6116002)(81166006)(230700001)(316002)(1456003)(1556002)(76176999)(50986999)(86362001)(81686999)(97736004)(84392002)(81816999)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB3007; 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; VI1PR0701MB3007; 23:njVdWKZwCUV9O/y83Ix+7QCoGFpAK20Upyxze?= =?iso-8859-1?Q?VscgDHM37A/GHoIvBeotk0qM+5HfPtsLpMDPyHpvWFzQYHd4FRlHitSzmv?= =?iso-8859-1?Q?7hLmb1UEUqMu2E5V9d3DOUNbk8RrjZSDK1JeEeS4NkJk8AWnQqtWnzW8L6?= =?iso-8859-1?Q?BYcyFl4QK9vxkj0Ks6Aytq7WxSyMJq5p1FN/1RLptEh8BA0Kf2KKaMEZ5h?= =?iso-8859-1?Q?0sHA2yLUIeZJAQ07vY8kkljUlcW277xc4QufXYSl5TO5Iw+Cba9eut2YYW?= =?iso-8859-1?Q?+1Z5HjXPYdhLobOWgmZ6WXS9DhKcN9iOwFuNQrKEcU9dndjqj/KaokhyR9?= =?iso-8859-1?Q?wrx53+u4nbQHKhpunmxQjjBePHff6XDlbDxQS0commelvkS5RidCouYrnv?= =?iso-8859-1?Q?cujzu6tOSyNZj8Y4cQAfP9KfVq0kwyHQpBfCCu3yrQKhfx6XDcVHlGFphK?= =?iso-8859-1?Q?/wnUC0XRd+NgFqGSbEDFKwixp6P4GJSMey3oxX7WQ3kWN5nlaeE/7JdC3W?= =?iso-8859-1?Q?+3LQs2mx/q2LgZHddMD1VzaqKPYZ0uFlldAxnjdkkWqS1cKgrF3KThtveY?= =?iso-8859-1?Q?5bl6XLYCLT3e6eQO1CmHVHWE9uXwiIy/+kLk7O6b/pvwclMRcTfF6yoXen?= =?iso-8859-1?Q?e5wSXpKvZjYnPEYIJ20xdD0gh4uHiGBhuBTKQjQf9nICtIU5qYgyO2iFqF?= =?iso-8859-1?Q?6cZk7J/je7MvtW2mqOwJSzyWCTTSXFG03bDFHFgwOi3vqzab6K4sii0Gr2?= =?iso-8859-1?Q?bkYxyPqO4MjAOcZdPshfTrLB8tn6lKMapdVruGceKYutB1LdImEbVP1O5f?= =?iso-8859-1?Q?nlYk8IwFOQFy3PESuuDRBm4T82B+Cf6jcKCFukWYqT6yqjP941B5SIgqQo?= =?iso-8859-1?Q?veTEMqZ2Md59feEFtqQ4MGOmFPKdNpamqjwiCbc6uN6B0Eu4beBFJgQfW9?= =?iso-8859-1?Q?agkQRyMf1/gsP8fumRAb1LrUPmDEVm/izKxyywUD22JGs883ENM6zfSn5Y?= =?iso-8859-1?Q?b5M3GHSeJyNLEkkG7J+KX/1Vm1WTciMdlhpCbsUr72AobnLBhWcHjTCsmu?= =?iso-8859-1?Q?2qj+t97090Zyutyw0WGNwgm3pFf5WOIMk4cRuYHaQTZ+Yz47XLwZjO/EQ8?= =?iso-8859-1?Q?GErq/gZMqa1uLmhcoek6PhUTXIZJBD6ZYUKo8kCMuyIWEI09qWANxijpk9?= =?iso-8859-1?Q?dLbVmfd41cGGXzxoB4tMpt3RrE166sLMXKKqxQyzW2nLzAiSNJZz3zFOTk?= =?iso-8859-1?Q?KjnAqaoziqFdJpafiCMdbqORc/WLXm1IQo8XgaTJim9XylRMtwXYKzPi5O?= =?iso-8859-1?Q?iVDoNuxnXMlIbfUl9YvqoZu4FABrKGpe0kRBnv2Fy9Unj06ASv1nWEA43t?= =?iso-8859-1?Q?qJhUShiSdcWB0JPTrKKS2BchUIJaISYvsEqH4HKtkl0vZTER6IC7vsRbAb?= =?iso-8859-1?Q?VaV6r3Kx9/qzzMQItpTPtGD0IyD6CwC6s1zLXp4J1pAuoPgzRkG8vDgiZ0?= =?iso-8859-1?Q?SKK4rNUWo4WT9SdVgIE7NQ=3D?=
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 6:dBAutac66eIQT1bK06ckURgLcAemYmryqGQodLQTDG2wQL+7rUZvsp8nf7tELqeN4hUUQdG0S4mAppWBJGoY+4DQbYGqkqFC10uVEMGC4icBX4Pm/fMHPiAbY8kysdZGxqhWo4t2on8vL5eesaHZYLniZu3bldVN5YMeCAOXztCtsC2A2i5rIrW3ekJYmyxnOEllardBdded8odwyiM0Drfy+Zt4k+HLlb3FPRMJED+Nap0ltbk56+njjKqJVKjAJjNiKmmM1Hj/EK+aU8hw9apgaABkd3SPed+qRU5gMY2Ql1aPK+DWgT1b4LhexOY/OsAoWkgoxVdMju4eK9NvJw==; 5:T5WzjA2a6UOJsFBJyewYeLzYkUgLldLVh34L9PG08uSjjjCAAnZpnzr7NrmCP0JO0bUS3gKEQF/cikDZ7YHdHO0fIr4X4XtMG38l3ZvO2f27zH3k/CR0VF8tfmC56P6w4YXVvZLq9Xms2vxiq5735Q==; 24:SCTpqTZ+6CTi7WDwbJz/LT8jBkFxzzHQkVmLTQxpLObp+qvNMazeyL3radnDup4NYkndatn0SCKZzyfKNPQctSxJXpGX2b5Te9sDEdNV9II=; 7:2cOU4zD1XUd+pCXudaXQtUZWL0hQz9OQY3eOfoGrv7aqV+QxEcj952THINCXcelvCeLbQ7ghvSj6ZB1qsT33o0rZNDXlMTVbl88SBCVbNex32hQGK7RkytbSbtpQrEg6NxDpY1NGWbZO8m2Xcduhd7tOBsfnfnpyYL6mNGAGXkOFLY+ssjZpgbbABwNZ4rnjGPWY2uT02XLTk/unItIRKaf7IWn6OTSOu1m23oIJ9xI=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2017 16:39:12.4232 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB3007
Archived-At: 
Subject: Re: [netmod] upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Sep 2017 16:39:18 -0000

----- Original Message -----
From: "Kent Watsen" 
Subject: Re: [netmod] upcoming adoptions


> > So rfc8022bis-02 publishes the v2 module, and the the deprecated
version
> > of the v1 module as an appendix?
>
> Lou and I were just discussing if appendix can be normative or not.  I
always
> thought no, but I haven't checked.  This is a grey area, in that
understanding
> that the old module is deprecating is not needed in order to
understand the
> new module, and we really just to ensure extraction tools work...

Appendices are Normative if they say that they are Normative.  The
default is that they are not so say that they are and they are.  This is
well established practice.

Toim Petch









>
>
> > I see "kind of ugly" as a feature in the this case, someone looking
at
> > the updated v1 module isn't going to be able to miss that whatever
they
> > are looking at is deprecated. ;-)
>
> Funny, and true
>
>
> K.
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Thu Sep 14 09:39:31 2017
Return-Path: 
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 3B54C132924; Thu, 14 Sep 2017 09:39:19 -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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_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 MG308JTkemjU; Thu, 14 Sep 2017 09:39:17 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0126.outbound.protection.outlook.com [104.47.2.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 754DA13305A; Thu, 14 Sep 2017 09:39:16 -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=Izoydb1LHpFHgHpjzc6DK0PicFIczr47s0fUchK8VTo=; b=RC5zTLb9c9yZeIExsljuXnUPwsJZfYhbUhE+z6NkAkSr4D4WXBMyZ3TcOQvEy72WXLi/OT2O1WZCJJlrwZITW+wWIDY3h5G6BCDMuyqlikbViVxMiPQZdHLWfgJSYNdcEy81zh5xevO4OiBCZZnrKEDQPWBeqBsVhza37Ji45Wc=
Received: from pc6 (86.185.245.5) by VI1PR0701MB3007.eurprd07.prod.outlook.com (2603:10a6:800:87::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Thu, 14 Sep 2017 16:39:13 +0000
Message-ID: <011e01d32d77$c980dca0$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "netmod WG" , "Lou Berger" 
Cc: , 
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <00bd01d32caf$4eb28e60$4001a8c0@gateway.2wire.net> <92a410a9-e479-2321-7420-4bd2d9dbed38@labn.net>
Date: Thu, 14 Sep 2017 17:37:21 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [86.185.245.5]
X-ClientProxiedBy: DB6PR07CA0180.eurprd07.prod.outlook.com (2603:10a6:6:43::34) To VI1PR0701MB3007.eurprd07.prod.outlook.com (2603:10a6:800:87::21)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 4ed8d627-7fec-4e1c-e5f2-08d4fb8f224f
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:VI1PR0701MB3007; 
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 3:/Zsuo048TJPoEkrz0B6pdUrLIAtjt4UbmBwYklh3kW9njzLmDlSQBiIhxqwQFwwOBNN/SW3F/twqz44ML/Bo7mvuV8f3jJnM6KNctzojz8ccs69bDxnd3+9Bwa+22pJxKAo9Zdl228/6eCA3/36/KAzX4cmNnXy9ODdkxoN857JsvoXpcLcudURAzvajt+BhdHI7Myh2rjLYEUqH5LLgh+jUS7T+9i36eac0RWZ6K7Qy7cBKaDgy6iGkpraGTTvR; 25:I/hhdWATVVEUasLFJJZAZ6dc2b8QdNMBa0JZ5AJAyNGUOwV2sJOBoTk6WBbnFxdgFUYTPdpkTePxC6LDxuF8fRi5p429pCmts+rVn5rw/V7qE4tM095WiofftuUTzET+CkIgGfcz+MHn7GHEcVl4dXrKwFHgCE0H/G4/94kUN8I3AGTElcsDe78XhRkzk5fFg8uk7t/ssZkdaBqRgyV5dL9bmJxxFm2rHpPnG9InW2ltrWaiML11SfeoXVQyS43eCx6cogVH4BpAyn/axsyGXgPdaTv+KBze8hIWRpwthUg2S2JIlpwZVojbk6rzj7xUHvoBjVHwYInU+4vbV56CmA==; 31:FcZltyFClVYvhX4I2rC3nbH/gPP+qbd6qtgPlI7ImKA6KR3jDwgRE8YDNftn/pz75CQcO6QCstdQMkzv6F3/eZYu5MtWa+8AgG2OP0eZG5qjaqdfoDs8ZBs5DlQVCBrKbd5RQ8w39q7vEJA/cbY4dcwLU9DZ6rDvpTMjYdsXR/mLR5pd7taChMWcyUkS0kT9wqOBIVz0r36FYG/rcn/9u0/EfuA0/yhHjYeOtyB1+Fg=
X-MS-TrafficTypeDiagnostic: VI1PR0701MB3007:
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 20:mTAOXf/gqSOTfY2baEVOunt7BajLshUMzsMUEHxn2NMj95I2h2UIIxMFnT1zJ0D9pHWcX2rI7vvwJp5wVehBQoYWOv4Ng0zFUyGVQ409Dbp3NAPC66JMWw9fHW51uTZbuHBg6G1QfQvya0d82wzdaf1qcjvChZ8S4OGg7vYY/G4UFJlvTqzASaMia5uyIgPBAmSknGhHmaSwSZwntjtdyQras6CerxPT9oB5irwHu5xghehMVk/LoKUoEIAW36my; 4:q+XKPOUnEfYt4DHBx/L7lehDsGb/3V6v+nA3Z+x/4oPtj8KUmKoFTgpgX9JUmcmUg5TvcGALPMvkA9LU2szraWn1bX/N5SeW84ke+rRtpEvt9KdyACijMmw9bY/gUpCCvfZQN9of7EZc80X07Z0dBKJ8K3pBFDBfohazapC3LffiX/bjyIpgLoJO8ECvryo+rrNFeIujDwDjBY5e3shUpu1xpcgWOYqXIKq7OF+k2V5d6PSQuH1u1lIP7hfA1TPki9P5QzxcoIQs4HPZ7/kDzNPwbGXJ9ILFmlHqBYLE/UY=
X-Exchange-Antispam-Report-Test: UriScan:(178726229863574);
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6041248)(20161123564025)(20161123558100)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR0701MB3007; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR0701MB3007; 
X-Forefront-PRVS: 0430FA5CB7
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6009001)(39860400002)(376002)(346002)(13464003)(24454002)(51444003)(377454003)(199003)(189002)(44716002)(62236002)(478600001)(101416001)(305945005)(7736002)(105586002)(106356001)(53546010)(47776003)(61296003)(6496005)(7350300001)(33646002)(4326008)(6246003)(14496001)(66066001)(50226002)(6486002)(54906002)(9686003)(44736005)(6306002)(25786009)(189998001)(229853002)(4720700003)(6666003)(68736007)(116806002)(230783001)(23676002)(50466002)(966005)(8676002)(53936002)(2906002)(5660300001)(3846002)(81156014)(6116002)(81166006)(230700001)(316002)(1456003)(1556002)(76176999)(50986999)(345774005)(86362001)(81686999)(97736004)(84392002)(81816999)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB3007; 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?MTtWSTFQUjA3MDFNQjMwMDc7MjM6WDhjTVczQ1h3Nmk4Q0NYbElQZGVoYVhX?= =?utf-8?B?aW90SzlPU1ZPRlkyQ0gyZUczVmtmamZWUEQ4cnFQeWMxcVI0dDRhZnVKMzd3?= =?utf-8?B?RlFwVXF2bTM4SkhwcXVaRUd2WS9SOUswY3FmbndxaS81ZENBdnRhaUtldmVO?= =?utf-8?B?U2NUTlFsY29QUmtCWnhhUDcxRkl6VEdld0JYOWxNcGtIV1daTzdyOFg2MWpm?= =?utf-8?B?ZDFlL1Z1c3h1NTN5WStHa2l4ZDhzbTUvZzNUYkRZZXppTFdQZU5WWjF1THRu?= =?utf-8?B?MDRKeFFESVRvSUVJU0JIRTJJRzAwbEhnaUdvODliYWtTcnJhRVFCMjRFWmFn?= =?utf-8?B?NERqZDZaSkpobW5QeVJIN2xFRlA4WVcyaTFHemZIK25hbkFYU0JsSWxwc0tz?= =?utf-8?B?QlNRTkY0cmMyL3RRT1ExeG0rSWlONXJacUVnVzI2N2drOFhqaHpjeS94SDZU?= =?utf-8?B?d0J1R1ZNYWlpdEtTOWZweDZKcGh3amJscmw5QW1iSEFFUTlUTUllakhMNjZx?= =?utf-8?B?YkpGd3N1YW04ZUswYm12WXFBZDk1d09WTHBwOWxjMStpMCtiUC9yM0hRTkZ3?= =?utf-8?B?SzA5RUxmdWNUakJudUwrT3U5Z0xlN2JacldsZ3ZDT0lMdTFuaEhjcXdMdWdy?= =?utf-8?B?UFNHdGkvZFA0WlVmcmFIVWpRY2NnczFsaFZ6ZTNVUEhyaFUzQnl4Z25vcEpr?= =?utf-8?B?Z2ZDYk9qcDJveEREUFRxTTQ4S3BaMGFRWCthRTBuR21Gc0pqTHJuTHd1U2VI?= =?utf-8?B?UUpVdVdJK3UxVlFtM280TjV1Wm02SE5UcVVFOHdTditMOHNzVFViREpCSE9o?= =?utf-8?B?bW53aU8yWG1SS3JMSDM2OXBGRE5lOVFiQ3RhamN2YkNqdEVkL2xGTHY4YWZE?= =?utf-8?B?MHBieldSbmFCS2FiK2IwZVpFcWNXSkxIUVZyTUlNQnZUZnBRMlZpU25WK1Z1?= =?utf-8?B?RFVuejhhV1pmRGVJbWVZNGRvYjBWdnEzZDV4SCtKcGt6Sk5nczE5VUZUOW5L?= =?utf-8?B?WmhUMVF2N0wyRWZLdkNkd1Q4dVFEUDFTM0U4QU40UWZvWTZCeWdneWVJbWFu?= =?utf-8?B?bmhMSTdiTkhTZDR3YVlNanM0b1JZSFo0OWpqRDNad3JYckZGc1hYZG5sSDEx?= =?utf-8?B?RUhDRlUraWk5UnRJaDNTdHBrQXFpY29HYXd2MDJGUkFUSG5ieXdhaW9rbVZD?= =?utf-8?B?YnNoLzF4R1lDVzhJejVZeVJHelR1RDJDSU1EeFNsUk8rYlYzRFJwdll1c1lR?= =?utf-8?B?RW5zNG9QVGtBRVRZTnc5ZDJoY3FhQUNaNmlhTmRrMmIwNmRJT1VHTDI0dGxv?= =?utf-8?B?NjBuZk5HcVRoQzBCVzdpc3JzWWhCejVwbnVadythYjh2MllnT29mWWJHNFkw?= =?utf-8?B?YzhqdEx4bW1QUTNCZVdYSlNQQll4NU5hNkdKT080alRRb2poZmlzWkVqSUFJ?= =?utf-8?B?NVVnL2tESktsdDluUFp3MnBMbXpUT214OFVpMUpNR2V1L245bzczR1lhc3dD?= =?utf-8?B?MjArS0VmY0hGQmtVOXF3b09DQitDN0t2azlOYWRZY2JNV0svQ3ZJeGUyTmda?= =?utf-8?B?NGxQTTFkZTRGMzQ0bmhlRjROOFlyeGEreHJlZUpzRXJDRzVjRmRNWGRhZDZI?= =?utf-8?B?QndYNDlUL25pN0lWVkYxTVhZMlBIcWdQbzE4Szd1Nm5EckpiZWtpb2c2aXpZ?= =?utf-8?B?RzRWZk5RRE5Xck5nVjFsWExQQ3BDMjFEaXFic1hrWDlDbXRpZWZuallaRGlI?= =?utf-8?B?dDM1M1NyTHZiaVphaytIZU1VK0RpaWYzTHJ2NE9sMjRoYm01WXNGVGdMZngz?= =?utf-8?B?dlE2Z0JrYkVBcmREVGlsNjMzcG9MMnpxRUp5OFpjNkRncENqbkNYMHdvNWhR?= =?utf-8?B?cm5nRWovVS8vWDhsdjQ3WHE4YUhGeitaMTNuQUcwVk9KbFZnTjdDdDd2anU4?= =?utf-8?B?NzNkZHlxb09tV204aFYzdjBZdUJ3Wms5c0F2RnZOU05tN1ZwaE0vT3Naekh3?= =?utf-8?B?aThsb0xMNXdlMU84azY2RnhxYmVwbE42ZkZ3eUZndk0rSUxGQ0ZteG16c1VF?= =?utf-8?B?blVGQjNqb2JkTHg0Y1g5eHZ6QlM4aVpzTDZQY1FubnVZTmRqdnJqb0NPTzEv?= =?utf-8?Q?taaTpwlkdqYbONuAC0YMPip4+Qn8+Po5FIw+C+txZ4H2Af?=
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 6:YJYpQC2OilQkYYl1WLHbvC6+YSKwKewcG7ezotYRgtJVInDar3J+h9gXUkQte7fM5mU4MMn2K1oZUCNbEkkL+yAlLCnBK0HJRK7h7RH8aGIyTjs537FRQK23TgLSC+cw2FHGqVn6BJOM+OcHPYRLyIs7idT4sc+qXJIXq/hNneM9eoRrEQnKfsiXJw65KWxmSEaxBiNvhAekCseKZT+U2jXTzf7ybKminR0uhP7JL6L5D4iW83hrw6Yp03uq0fHW8JcO3Q1ZrtMuT4ohVxLy+vb/hUzjLoaH+G7Tgx00LHgHXSpm+L4asuok55fEdD4LfLNWIUs139HYORSjfFR92A==; 5:kfYgSkx24LjCTwZePT8vmUkXKgSCJeyqtWzBdwI2UIkXgZQTNaN2eenPdTDR8Io+8FGDZKP3AtvcWn8getZ5ZZx+enGYasX/xdLCOtIIQM8ywecmmKZ1mBeC7LejyaRi9iSnMeVp5lFdksgRy+w7dg==; 24:i3bqjjRbjv5gsRpYu+tXqTin/l8zIwHAcUlhYViM3c3GvztZQRQUqXIZBhhbQ6Ghf0/c1EkEfBgJERNFmeR6rvZ+MPNYb+G/IwuHeEWyO3g=; 7:ARtmClvqgw8pPGSlJmPslDg23yJfIvb/q13qaeXK0fhvUfIr2gmjeyGpsnPioH/izN1Kjq5bjV0icr4YmeaJv2Uo1MSaKeVA4tZ5yYFYihPHvllTE6NyC7lAP9PIfrNSDr3h7DiLjOIcuqBZ7UvD1JlyweZjArceJ+v47uuAlcJpm8U4HkgVYHIBeB6j9km4jKBmnJGlPF+R9Wdj4IXnP+H9CbPqnzHbf9qMfTOlxFg=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2017 16:39:13.4545 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB3007
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 duplicaiton
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Sep 2017 16:39:19 -0000

Lou

I am proposing that the text I included would go more or less as is into
the beginning of section 3.  I think that it makes sense even before we
get into the historic definitions of configuration etc.  I want to spell
out the problem - two different values of the one conceptual object,
originally handled with two schema nodes in one store of data, now
handled with one schema node in two datastores.  Thus start section 3
with

NEW

Some data objects can take two different values, the one configured by
the user (configuration), the other the one that the device is using
(operational state),
perhaps as a result of interactions with hardware, with protocols, with
other devices and so on.

 The original model of datastores
required these data objects to be modelled twice, as configuration false
and as configuration true, and, since there could be many of them, and
the rules of YANG require them to be in separate trees, this led to a
twin-trees approach, such as can be seen in RFC7277 or RFC7223.

This duplication of definitions and separation of operationsl state from
configuration leads to a number of problems.  Having them in
 separate branches in the data model is operationally
complicated and impacts the readability of module
 definitions.  The relationship between
 the branches is not machine readable and filter expressions operating
on configuration and on related operational state are different.

With revised datastores,  the data object appears once in the model
but can appear in two datastores, one for the
configured value, one for the operational state value.

 Instead of two YANG data nodes there is one data node in two
datastores, a more elegant and simpler solution to the problem.

/NEW

I would make minor changes to the last three paragraphs of Section 3
mostly excising where I have already included that material

Tom Petch

> >
> > The problem that is hinted at but never explicitly stated is that
data
> > objects can appear both as configuration and as state, e.g. when
learned
> > by other means or at other times.  The original model of datastores
> > required these data objects to be modelled twice, as configuration
false
> > and as configuration true, and since there could be many of them,
and
> > the rules of YANG require them to be in separate trees, this led to
a
> > twin-trees approach such as can be seen in RFC7277 or RFC7223.
> >
> > Amongst other problems, this separation of operational state from
> > configuration in a
> >    separate branch in the data model has been found to be
operationally
> >    complicated and impacts the readability of module
> >    definitions.  The relationship between
> >    the branches is not machine readable and filter expressions
operating
> >    on configuration and on related operational state are different.
> >
> > With revised datastores, there is a single data object to model both
> > values  but this now appears in two datastores, one for the
> > configuration value, one for the operational state value.
> >
> > Instead of two YANG data nodes there is one data node in two
datastores,
> > a more elegant and simpler solution to the problem.
> >
> >
ta
> > objects can appear both as configuration and as state, e.g. when
learned
> > by other means or at other times.  The original model of datastores
> > required these data objects to be modelled twice, as configuration
false
> > and as configuration true, and since there could be many of them,
and
> > the rules of YANG require them to be in separate trees, this led to
a
> > twin-trees approach such as can be seen in RFC7277 or RFC7223.
> >
> > Amongst other problems, this separation of operational state from
> > configuration in a
> >    separate branch in the data model has been found to be
operationally
> >    complicated and impacts the readability of module
> >    definitions.  The relationship between
> >    the branches is not machine readable and filter expressions
operating
> >    on configuration and on related operational state are different.
> >
> > With revised datastores, there is a single data object to model both
> > values  but this now appears in two datastores, one for the
> > configuration value, one for the operational state value.
> >
> > Instead of two YANG data nodes there is one data node in two
datastores,
> > a more elegant and simpler solution to the problem.
> >
> >

Tom Petch

----- Original Message -----
From: "Lou Berger" 
To: "t.petch" ; "netmod WG" 
Cc: ;

Sent: Wednesday, September 13, 2017 5:56 PM
Subject: Re: [netmod] WG Last Call:
draft-ietf-netmod-revised-datastores-04 duplicaiton


> > I believe that text such as this would make the I-D much easier to
> > follow.  As it stands, you have to read between the lines and
speculate.
> Tom,
>
> Thank you for the comments. Do you have a specific change in mind,
> or could your propose text, that would address this?
>
> Thanks,
> Lou
>
> On 9/13/2017 12:42 PM, t.petch wrote:
> > I think that in one respect, perhaps the key respect, this I-D fails
to
> > state the obvious (or at least what is likely obvious to those who
have
> > been at this for a while:-).
> >
> > The problem that is hinted at but never explicitly stated is that
data
> > objects can appear both as configuration and as state, e.g. when
learned
> > by other means or at other times.  The original model of datastores
> > required these data objects to be modelled twice, as configuration
false
> > and as configuration true, and since there could be many of them,
and
> > the rules of YANG require them to be in separate trees, this led to
a
> > twin-trees approach such as can be seen in RFC7277 or RFC7223.
> >
> > Amongst other problems, this separation of operational state from
> > configuration in a
> >    separate branch in the data model has been found to be
operationally
> >    complicated and impacts the readability of module
> >    definitions.  The relationship between
> >    the branches is not machine readable and filter expressions
operating
> >    on configuration and on related operational state are different.
> >
> > With revised datastores, there is a single data object to model both
> > values  but this now appears in two datastores, one for the
> > configuration value, one for the operational state value.
> >
> > Instead of two YANG data nodes there is one data node in two
datastores,
> > a more elegant and simpler solution to the problem.
> >
> >
> > I believe that text such as this would make the I-D much easier to
> > follow.  As it stands, you have to read between the lines and
speculate.
> >
> > Tom Petch
> >
> >
> > ----- Original Message -----
> > From: "Lou Berger" 
> > To: "netmod WG" 
> > Cc: ;
> > 
> > Sent: Friday, September 01, 2017 10:02 PM
> >
> >> All,
> >>
> >> This starts a two week working group last call on
> >> draft-ietf-netmod-revised-datastores-04.
> >>
> >> The working group last call ends on September 17.
> >> Please send your comments to the netmod mailing list.
> >>
> >> Positive comments, e.g., "I've reviewed this document and
> >> believe it is ready for publication", are welcome!
> >> This is useful and important, even from authors.
> >>
> >> Thank you,
> >> Netmod Chairs
> >>
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >
>


From nobody Thu Sep 14 10:02:02 2017
Return-Path: 
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 462921326F6 for ; Thu, 14 Sep 2017 10:02:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 CgYyDmaDr1pK for ; Thu, 14 Sep 2017 10:01:58 -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 39B001321AC for ; Thu, 14 Sep 2017 10:01:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7392; q=dns/txt; s=iport; t=1505408518; x=1506618118; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=h9zs8bX73N6EgIvMqODoFCop0MdktlQPdP4tDkK0b1A=; b=LvupxnW08F3k3NCHnTlSR5yVIwbDBdJP67bRWkQVd/Rd39Vv68unRI5l TrqUouD2U3kH1MOAXzIKPMhiwbB8eBfHMz5o3mCXzj6PYObyoB8xnAiPI Ny3lv/gmJR35AUZ0X9Y1IsZlVJkTtrSDvBe0dXvT2VdPbTsVeiR4k+Kkl c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAQDJtLpZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm+CPYQeixSQRiuQaIVOggQKhTwChGYVAQIBAQEBAQEBayiFGAE?= =?us-ascii?q?BAQECASNWEAsYFRUCAlcGAQwIAQGKJgisKYInJ4sKAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBHYMrg1KBYyuCfYQzgQSCVIJgBZg9iEWUUotVhyGNXIdVgTk1IoENMiE?= =?us-ascii?q?IHBWHZz+GZCuCFAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.42,394,1500940800";  d="scan'208,217";a="697190565"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Sep 2017 17:01:53 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v8EH1reD011340; Thu, 14 Sep 2017 17:01:53 GMT
To: Balazs Lengyel , Martin Bjorklund 
Cc: netmod@ietf.org
References: <9ec6b2e4-36a7-87e6-59fa-828855235835@ericsson.com> <20170914.163239.143365521945928900.mbj@tail-f.com> <0605fab0-f879-e02d-4858-52a247571cb8@ericsson.com>
From: Robert Wilton 
Message-ID: <9892a9b1-139c-71d3-328e-ad91e0590f6b@cisco.com>
Date: Thu, 14 Sep 2017 18:01:52 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <0605fab0-f879-e02d-4858-52a247571cb8@ericsson.com>
Content-Type: multipart/alternative; boundary="------------B837B40E197B6DC0871E35E7"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Comments on NMDA-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Sep 2017 17:02:01 -0000

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

Hi Balazs,

Thanks for the review and comments.


On 14/09/2017 16:44, Balazs Lengyel wrote:
> See below !
>
>
> On 2017-09-14 16:32, Martin Bjorklund wrote:
>
>>> CH 4.4.)  "Validation is performed on the contents of ."
>>> This to me means that default data is not considered at validation
>> Note that RFC 7950, section 6.4.1, says:
>>
>>     In the accessible tree, all leafs and leaf-lists with default values
>>     in use exist (see Sections 7.6.1 and 7.7.2).
>>
>> So defaults are taken into account when intended is validated.
> BALAZS: Yes the two seem to contradict each other. This can be 
> understood in your way, however the current text is not clear enough. 
> I would add:
> Validation is performed on the contents of  (EXTENDED WITH 
> DEFAULT CONFIGURATION).
As an alternative suggestion, rather than saying contents of , 
we could instead say something like "must always be a valid 
configuration data tree.". Is that better?  I would rather not talk 
about "defaults for  since that may imply that they are not 
applicable to other configuration datastores".  E.g. if  is 
validated then you would also expect defaults to be considered. Ditto 
for startup, candidate.

Thanks,
Rob


>>> which would be a backwards incompatible change. Also if validation
>>> does not consider system configured data that would allow cases like
>>> multiple interfaces named lo0. One from  one from system
>>> configuration. IMHO while it is OK to violate uniqueness because of
>>> remnant data, the above violation of uniqueness seems a bad idea.
>> If your system adds data to , or to , it will be
>> validated.
>>
>>> Ch. 4.7) Is it allowed to violate uniqueness of key values? IMHO it
>>> should not be.
>> Agreed.  Note that the draft explicitly lists the constraints that can
>> be violated, and uniqueness of keys is not listed.
> BALAZS: If that is the intent I would propose to explicitly state it. 
> For me it was non-trivial.
> Can a a choice statement be violated? Having to existing branches at 
> the same time? It seems a semantic constraint to me. IMHO yes.
> Can an if-feature be violated? If  support has just changed and we 
> have some remnant config, I can very well imagine it violated.
>
> Also here could you change
> If a node in   does not meet the syntactic constraints 
> then it cannot   be returned
> to
> If a node in   does not meet the syntactic constraints 
> then it MUST NOT be returned
>> /martin
>


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


  
    
  
  
    
Hi Balazs,

    
Thanks for the review and comments.

    

    

    
On 14/09/2017 16:44, Balazs Lengyel
      wrote:

    

    
See
      below !
      

      

      

      On 2017-09-14 16:32, Martin Bjorklund wrote:
      

      

      

        
CH 4.4.)  "Validation is performed on
          the contents of <intended>."
          

          This to me means that default data is not considered at
          validation
          

        

        Note that RFC 7950, section 6.4.1, says:
        

        

            In the accessible tree, all leafs and leaf-lists with
        default values
        

            in use exist (see Sections 7.6.1 and 7.7.2).
        

        

        So defaults are taken into account when intended is validated.
        

      

      BALAZS: Yes the two seem to contradict each other. This can be
      understood in your way, however the current text is not clear
      enough. I would add:
      

      Validation is performed on the contents of <intended>
      (EXTENDED WITH DEFAULT CONFIGURATION).
      

    

    As an alternative suggestion, rather than saying contents of
    <intended>, we could instead say something like "<intended>
        must always be a valid configuration data tree.". 
    Is that better?  I would rather not talk about "defaults for
    <intended> since that may imply that they are not applicable
    to other configuration datastores".  E.g. if <running> is
    validated then you would also expect defaults to be considered. 
    Ditto for startup, candidate.

    

    Thanks,

    Rob

    

    

    

      

        
which would be a backwards incompatible
          change. Also if validation
          

          does not consider system configured data that would allow
          cases like
          

          multiple interfaces named lo0. One from <intended> one
          from system
          

          configuration. IMHO while it is OK to violate uniqueness
          because of
          

          remnant data, the above violation of uniqueness seems a bad
          idea.
          

        

        If your system adds data to <running>, or to
        <intended>, it will be
        

        validated.
        

        

        
Ch. 4.7) Is it allowed to violate
          uniqueness of key values? IMHO it
          

          should not be.
          

        

        Agreed.  Note that the draft explicitly lists the constraints
        that can
        

        be violated, and uniqueness of keys is not listed.
        

      

      BALAZS: If that is the intent I would propose to explicitly state
      it. For me it was non-trivial.
      

      Can a a choice statement be violated? Having to existing branches
      at the same time? It seems a semantic constraint to me. IMHO yes.
      

      Can an if-feature be violated? If  support has just changed and we
      have some remnant config, I can very well imagine it violated.
      

      

      Also here could you change
      

      If a node in  <operational> does not meet the syntactic
      constraints then it cannot   be returned
      

      to
      

      If a node in  <operational> does not meet the syntactic
      constraints then it MUST NOT be returned
      

      
/martin
        

      

      

    

    

  


--------------B837B40E197B6DC0871E35E7--


From nobody Thu Sep 14 10:06:39 2017
Return-Path: 
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 E06F2133025 for ; Thu, 14 Sep 2017 10:06:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level: 
X-Spam-Status: No, score=-4.701 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=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y_1vnPwfw1ND for ; Thu, 14 Sep 2017 10:06:34 -0700 (PDT)
Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (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 DE633132924 for ; Thu, 14 Sep 2017 10:06:34 -0700 (PDT)
Received: from cmgw4 (unknown [10.0.90.85]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id 6456914054A for ; Thu, 14 Sep 2017 11:06:34 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id 9V6W1w0162SSUrH01V6ZZV; Thu, 14 Sep 2017 11:06:34 -0600
X-Authority-Analysis: v=2.2 cv=OZLoNlbY c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=2JCJgTwv5E4A:10 a=ZRBybLNu9Ib41AI41nMA:9 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: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=22C0ARzW1nO8lcG2Q5ly0FQIxyuGbxoIqckfjV+wm1g=; b=07JBpR49GkcjGcLIPNfU/WA0X2 Ztij4WEb9wprrhrrToH+cPQeEMrWbV4zFy/GLokGtodxIZsN5gMlArRnCVq0d8jqV8NLennuDiPvF n+6MnrNMeOwtMQerlj1W5viSA;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:54510 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dsXaw-001NgW-8c; Thu, 14 Sep 2017 11:06:30 -0600
To: "t.petch" , Kent Watsen , Robert Wilton , netmod@ietf.org
References: <14299503-509D-43BE-A938-0B7B88C3B249@juniper.net> <36ba3d4b-1ae1-0666-12cf-db41e172924b@cisco.com> <75739d75-da96-b340-2403-d0949ac54ed7@labn.net> <19134054-D52E-4A6D-992A-A47F365557AD@juniper.net> <2891bd09-0e0d-415c-2714-15141a293e42@cisco.com>  <011d01d32d77$c8e0a500$4001a8c0@gateway.2wire.net>
From: Lou Berger 
Message-ID: <9c0d8394-b2a4-180a-2454-8955c1721423@labn.net>
Date: Thu, 14 Sep 2017 13:06:28 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <011d01d32d77$c8e0a500$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dsXaw-001NgW-8c
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:54510
X-Source-Auth: lberger@labn.net
X-Email-Count: 9
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Sep 2017 17:06:37 -0000

On 9/14/2017 12:36 PM, t.petch wrote:
> Appendices are Normative if they say that they are Normative.  The
> default is that they are not so say that they are and they are.  This is
> well established practice.

Hi Tom,
    My memory (I haven't checked recently) is there is nothing in or
defined process that says if an Appendix is normative or not.  Other
SDOs certainly have formal definitions here.  Within the IETF, my view
has been that if an appendix includes RFC2119 language, it is
normative.  Actually, strictly speaking, any text in a Standards Track
RFC that doesn't include RFC2119 language is just informative.

Lou
 


From nobody Thu Sep 14 10:08:49 2017
Return-Path: 
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 641BF133063 for ; Thu, 14 Sep 2017 10:08:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 X--_e75zmHNc for ; Thu, 14 Sep 2017 10:08:46 -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 0CD4D132924 for ; Thu, 14 Sep 2017 10:08:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7079; q=dns/txt; s=iport; t=1505408926; x=1506618526; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=9gcc3Z9yZFaOgEsbNuDHcFJbWroMqNqIcgG0BiSjLoA=; b=Oa2EBN2GQB3cn3CR+zuUFhrpeO6Ifjf5fjkVfcBi8uYU3YlapPqNQ2G8 rFuJSfCYu3z8bT2bNE8yKFeYiU3iWIVJEAu5Ne/IZDkNPdH9HFbl3rMD0 TWo03H4wyjG1q780HxqXSvrv+KOWxr8idEcuA4QmxGCA+jd1oz3GBUn8S o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAQBVt7pZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD5uJ48LkEcJIpBohUAOggQKGAEKhEpPAoRkFwECAQEBAQEBAWs?= =?us-ascii?q?ohRgBAQEBAgEBAWwLEAsSBi4nIg4GAQwGAgEBiiYIEK4sJ4sLAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBGAWDK4NSgWMrC4JyhEUBEgEJhgkFmD2IRZRSi1WHIY1ch1W?= =?us-ascii?q?BOSEDM4ECCzIhCBwVSoVOgU8/NoYuDRcHghQBAQE?=
X-IronPort-AV: E=Sophos;i="5.42,394,1500940800";  d="scan'208,217";a="654622292"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Sep 2017 17:08:41 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v8EH8avI025099; Thu, 14 Sep 2017 17:08:41 GMT
To: Balazs Lengyel , Martin Bjorklund 
Cc: netmod@ietf.org
References: <9ec6b2e4-36a7-87e6-59fa-828855235835@ericsson.com> <20170914.163239.143365521945928900.mbj@tail-f.com> <4ce3efcd-6e88-9390-1241-21fb89985a9a@ericsson.com>
From: Robert Wilton 
Message-ID: <4dc2014b-0355-ac0b-f9a0-06a2d73033c4@cisco.com>
Date: Thu, 14 Sep 2017 18:08:36 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <4ce3efcd-6e88-9390-1241-21fb89985a9a@ericsson.com>
Content-Type: multipart/alternative; boundary="------------A4607966B5D2EB4AA3DADE38"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Adding system configuration to running [was: Re: Comments on NMDA-04]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Sep 2017 17:08:48 -0000

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



On 14/09/2017 16:35, Balazs Lengyel wrote:
>
> See below!
>
> On 2017-09-14 16:32, Martin Bjorklund wrote:
>> Hi Balazs,
>>
>> Thanks for your review.  Comments inline.
>>
>> Balazs Lengyel  wrote:
>>> Hello,
>>>
>>> Reading the draft-ietf-netmod-revised-datastores-04 some comments:
>>>
>>> General) The system often adds data to the  or 
>>> datastore already not just to : e.g.
>>>
>>> UC1: I have a server configured in running. I need to bind it to an
>>> ip-address. The ip-address might be the local loopback address,
>>> however if that is only added to , validation will
>>> fail indicating that the server is bound to a non-existent
>>> address. How to handle this?
>>>
>>> UC2: I have a set of capabilities set by the system
>>> e.g. supported-reporting-intervals. I need to configure a job that
>>> MUST use one of these intervals. If the supported-reporting-intervals
>>> are only added to  I can not validate the
>>> selected-interval in my configured job.
>>>
>>> My proposal is to allow the system to add data to running as
>>> well. Actually I think that is a more relevant case then adding
>>> configuration just to .
>> I think the consensus is that in general it is a bad idea if servers
>> (spontaneously) add data to .  However, there is nothing in
>> the new or old architectures that prohibits this.
> BALAZS: I strongly disagree.  I know others are also adding stuff to 
> running as well.
> IMHO the above use cases are real and used and actually important for us.
> I would like to see them included in some way.
I basically agree with Martin here.

The architecture is cleaner if  is only written by the client.  
This avoid requiring clients tracking unexpected changes to running, and 
opens up the possibility of validating configuration off the box.  
Ideally extra stuff should be added into  and then become 
visible in .

I understand that some systems add data to , and this is fine.  
But I think that it is better for an architecture document to be silent 
on this point.

Thanks,
Rob


>
> regards Balazs
> -- 
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909              email:Balazs.Lengyel@ericsson.com  
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


--------------A4607966B5D2EB4AA3DADE38
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    

    
On 14/09/2017 16:35, Balazs Lengyel
      wrote:

    

    

      
      
See below!

      

      
On 2017-09-14 16:32, Martin Bjorklund
        wrote:

      

      

        
Hi Balazs,

Thanks for your review.  Comments inline.

Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:


        

          
Hello,

Reading the draft-ietf-netmod-revised-datastores-04 some comments:

General) The system often adds data to the <running> or <intended>
datastore already not just to <operational>: e.g.

UC1: I have a server configured in running. I need to bind it to an
ip-address. The ip-address might be the local loopback address,
however if that is only added to <operational>, validation will
fail indicating that the server is bound to a non-existent
address. How to handle this?

UC2: I have a set of capabilities set by the system
e.g. supported-reporting-intervals. I need to configure a job that
MUST use one of these intervals. If the supported-reporting-intervals
are only added to <operational> I can not validate the
selected-interval in my configured job.

My proposal is to allow the system to add data to running as
well. Actually I think that is a more relevant case then adding
configuration just to <operation>.


        

        
I think the consensus is that in general it is a bad idea if servers
(spontaneously) add data to <running>.  However, there is nothing in
the new or old architectures that prohibits this.

      

      BALAZS: I strongly disagree.  I know others are also adding stuff
      to running as well. 

      IMHO the above use cases are real and used and actually important
      for us. 

      I would like to see them included in some way.

    

    I basically agree with Martin here.

    

    The architecture is cleaner if <running> is only written by
    the client.  This avoid requiring clients tracking unexpected
    changes to running, and opens up the possibility of validating
    configuration off the box.  Ideally extra stuff should be added into
    <intended> and then become visible in <operational>.

    

    I understand that some systems add data to <running>, and this
    is fine.  But I think that it is better for an architecture document
    to be silent on this point.  

    

    Thanks,

    Rob

    

    

    
 

      regards Balazs

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


      

      

      

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


    

    

  


--------------A4607966B5D2EB4AA3DADE38--


From nobody Thu Sep 14 10:23:06 2017
Return-Path: 
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 8D91B1321B6 for ; Thu, 14 Sep 2017 10:23:04 -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 w8XnTFz_yKKB for ; Thu, 14 Sep 2017 10:23:01 -0700 (PDT)
Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 369C9126BF0 for ; Thu, 14 Sep 2017 10:23:01 -0700 (PDT)
Received: by mail-lf0-x22a.google.com with SMTP id r17so17896lff.6 for ; Thu, 14 Sep 2017 10:23:01 -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=Os14RY0bSzLrFAwh4aAa3jHVG1Y5wAUIbeeZUco0ovQ=; b=ECgxdWoiyZ5gy9QBURT512GAP2WzlnSZ/we8N6xL61bGbvGbhEfg1WmeZA6FeSXnLz fgWxew64xiunDjnYDS7E5EeFI5HwIBYW+8zLipsh4pMsJHngUYg0gbaScWKX/OsUxIU7 PT7UcraNnK2sxrRRTXswLQ6ey+ofxymjiM3Qo0c6d+Qu81NiRR0wdDsTp+whK3kDldWl X1aCnDzoyzLpQoAFYaMz4WLloosz+EZGh9JGv2F72XBjUPcBV0k+RCP5mQcnnqb2cx0h uxWk8ahBAV0XzUSt0AyQHbE0RU0mcnqZzA5fP4st3FI8YdvWxL7Jf/25f8PhsBUl+QqF rQMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Os14RY0bSzLrFAwh4aAa3jHVG1Y5wAUIbeeZUco0ovQ=; b=MQa0325CeEIw7+N19nLPNz7HZC3eTtZWphy17rT8faKHKU8Jj9z8wHqrBzDS2NNpPA CWaIH+lfce7gSJR8lB5hDViTy5IPzIbkQOOzhjGp/tPsLFTfx12t0MMw1QRtFnRF28yT Rja6PmCnLaUZaaeazRu34t4V4hRsB8pFptCpFZvRZz1zjgl05reHr94noiegVN972KEI NvNgsFCktGdRHXaBjKamf93kNi3R/vGR+oIWIc6eSFUR6PiFIlEkvVr5H988Kd/YACCJ kF1F7fSo+pTzlfpYvTFPkkGAsZIZA8FqSg07DS09n5Z+b4jgH7E7jQQX6+5XtbsS2EUf xh8A==
X-Gm-Message-State: AHPjjUg0rRnhT2nTl4NPFuVoIupYyrSqpJEwSpefNzF1BbqcMcckpCUN fzPVWL6lQJ41uZNQmoH8E+HWigBqh0NGA5OUWQ7VkQ==
X-Google-Smtp-Source: AOwi7QC30pn5ndlO8nylWVBB6Iufk+EsqWAiITgaW5//HTWy74wH8ErbcWQc1QiSR56EPHFTAIkDtRMG3llOfwN55jU=
X-Received: by 10.25.223.86 with SMTP id q22mr8543525lfj.45.1505409779503; Thu, 14 Sep 2017 10:22:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.18.41 with HTTP; Thu, 14 Sep 2017 10:22:58 -0700 (PDT)
In-Reply-To: <4dc2014b-0355-ac0b-f9a0-06a2d73033c4@cisco.com>
References: <9ec6b2e4-36a7-87e6-59fa-828855235835@ericsson.com> <20170914.163239.143365521945928900.mbj@tail-f.com> <4ce3efcd-6e88-9390-1241-21fb89985a9a@ericsson.com> <4dc2014b-0355-ac0b-f9a0-06a2d73033c4@cisco.com>
From: Andy Bierman 
Date: Thu, 14 Sep 2017 10:22:58 -0700
Message-ID: 
To: Robert Wilton 
Cc: Balazs Lengyel , Martin Bjorklund , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="f403045e58a426364c05592987d7"
Archived-At: 
Subject: Re: [netmod] Adding system configuration to running [was: Re: Comments on NMDA-04]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Sep 2017 17:23:04 -0000

--f403045e58a426364c05592987d7
Content-Type: text/plain; charset="UTF-8"

On Thu, Sep 14, 2017 at 10:08 AM, Robert Wilton  wrote:

>
>
> On 14/09/2017 16:35, Balazs Lengyel wrote:
>
> See below!
> On 2017-09-14 16:32, Martin Bjorklund wrote:
>
> Hi Balazs,
>
> Thanks for your review.  Comments inline.
>
> Balazs Lengyel   wrote:
>
> Hello,
>
> Reading the draft-ietf-netmod-revised-datastores-04 some comments:
>
> General) The system often adds data to the  or 
> datastore already not just to : e.g.
>
> UC1: I have a server configured in running. I need to bind it to an
> ip-address. The ip-address might be the local loopback address,
> however if that is only added to , validation will
> fail indicating that the server is bound to a non-existent
> address. How to handle this?
>
> UC2: I have a set of capabilities set by the system
> e.g. supported-reporting-intervals. I need to configure a job that
> MUST use one of these intervals. If the supported-reporting-intervals
> are only added to  I can not validate the
> selected-interval in my configured job.
>
> My proposal is to allow the system to add data to running as
> well. Actually I think that is a more relevant case then adding
> configuration just to .
>
> I think the consensus is that in general it is a bad idea if servers
> (spontaneously) add data to .  However, there is nothing in
> the new or old architectures that prohibits this.
>
> BALAZS: I strongly disagree.  I know others are also adding stuff to
> running as well.
> IMHO the above use cases are real and used and actually important for us.
> I would like to see them included in some way.
>
> I basically agree with Martin here.
>
> The architecture is cleaner if  is only written by the client.
> This avoid requiring clients tracking unexpected changes to running, and
> opens up the possibility of validating configuration off the box.  Ideally
> extra stuff should be added into  and then become visible in
> .
>
> I understand that some systems add data to , and this is fine.
> But I think that it is better for an architecture document to be silent on
> this point.
>
>
I agree with Balazs that system-created nodes in running are quite common
and
the vendors doing it have no intention of changing it.

If the added nodes need to be saved in non-volatile storage then then
definitely belong in .

IMO the architecture is rather opaque wrt/ the interactions between
datastores,
especially the interactions between  and . Now it not
only
prunes inactive nodes, it adds system nodes?

Maybe it is too early for NMDA to be making lots of rules about how YANG
works
with new (and unimplemented) datastores.



Thanks,
> Rob
>
>
Andy


>
>
> regards Balazs
>
> --
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
>
>
>
> _______________________________________________
> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>

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




On Thu, Sep 14, 2017 at 10:08 AM, Robert Wilton <<=
a href=3D"mailto:rwilton@cisco.com" target=3D"_blank">rwilton@cisco.com=
> wrote:

 =20
   =20
 =20
  

    


    

    

    
On 14/09/2017 16:35=
, Balazs Lengyel
      wrote:

    

    

     =20
      
See below!

      

      
On 2017-09-14 16:=
32, Martin Bjorklund
        wrote:

      

      

        
Hi Balazs,

Thanks for your review.  Comments inline.

Balazs Lengyel <balazs.lengye=
l@ericsson.com> wrote:


        

          
Hello,

Reading the draft-ietf-netmod-revised-datastores-04 some comments:

General) The system often adds data to the <running> or <intended&=
gt;
datastore already not just to <operational>: e.g.

UC1: I have a server configured in running. I need to bind it to an
ip-address. The ip-address might be the local loopback address,
however if that is only added to <operational>, validation will
fail indicating that the server is bound to a non-existent
address. How to handle this?

UC2: I have a set of capabilities set by the system
e.g. supported-reporting-intervals. I need to configure a job that
MUST use one of these intervals. If the supported-reporting-intervals
are only added to <operational> I can not validate the
selected-interval in my configured job.

My proposal is to allow the system to add data to running as
well. Actually I think that is a more relevant case then adding
configuration just to <operation>.


        

        
I think the consensus is that in general it is a bad idea if s=
ervers
(spontaneously) add data to <running>.  However, there is nothing in
the new or old architectures that prohibits this.

      

      BALAZS: I strongly disagree.=C2=A0 I know others are also adding stuf=
f
      to running as well. 

      IMHO the above use cases are real and used and actually important
      for us. 

      I would like to see them included in some way.

    

    I basically agree with Martin here.

    

    The architecture is cleaner if <running> is only written by
    the client.=C2=A0 This avoid requiring clients tracking unexpected
    changes to running, and opens up the possibility of validating
    configuration off the box.=C2=A0 Ideally extra stuff should be added in=
to
    <intended> and then become visible in <operational>.

    

    I understand that some systems add data to <running>, and this
    is fine.=C2=A0 But I think that it is better for an architecture docume=
nt
    to be silent on this point.=C2=A0 

    

I agree with Balazs that sys=
tem-created nodes in running are quite common and
the vendors doi=
ng it have no intention of changing it.

If the add=
ed nodes need to be saved in non-volatile storage then then definitely belo=
ng in <running>.

IMO the architecture is rat=
her opaque wrt/ the interactions between datastores,
especially t=
he interactions between <running> and <intended>. Now it not on=
ly
prunes inactive nodes, it adds system nodes?

Maybe it is too early for NMDA to be making lots of rules about how=
 YANG works
with new (and unimplemented) datastores.



    Thanks,

    Rob

    

Andy
=C2=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">

    

    
 

      regards Balazs

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


      

      

      

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


    

    

  



_______________________________________________

netmod mailing list

netmod@ietf.org

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




--f403045e58a426364c05592987d7--


From nobody Thu Sep 14 10:50:02 2017
Return-Path: 
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 A91701323B8 for ; Thu, 14 Sep 2017 10:50:00 -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 L86__RLUT7vY for ; Thu, 14 Sep 2017 10:49:59 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E725B1321DF for ; Thu, 14 Sep 2017 10:49:58 -0700 (PDT)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 32DB91AE0383; Thu, 14 Sep 2017 19:49:58 +0200 (CEST)
Date: Thu, 14 Sep 2017 19:50:37 +0200 (CEST)
Message-Id: <20170914.195037.593298963545596882.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: jclarke@cisco.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <9d84d068-29ba-8e89-394f-b7f6a5272adc@cisco.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Sep 2017 17:50:01 -0000

Andy Bierman  wrote:
> Hi,
> 
> 
> Actually I liked the early pyang output that was concise and easy to
> remember.
> The current format gets very cluttered and there are too many little symbols
> to remember them all.

I agree with Andy.  I also did some experiments with printing
enumerations, and they work ok for small enums.  But once you have
more than a handful they do tend to clutter the output.  Even worse so
for trees that go into RFCs (where lines need to be < 70 characters).

Lada is sometimes using a format with even less information, where he
has removed all type information, focusing more on the structure.


/martin



> 
> 
> Andy
> 
> 
> On Thu, Sep 14, 2017 at 8:33 AM, Joe Clarke  wrote:
> 
> > I've been hacking on pyang, and I changed tree.py to add the enum values
> > for enumeration types and identiyref bases for identityref types.  Here
> > is an example:
> >
> > module: yang-catalog
> >     +--rw catalog
> >        +--rw modules
> >        |  +--rw module* [name revision organization]
> >        |     +--rw name                     yang:yang-identifier
> >        |     +--rw revision                 union
> >        |     +--rw organization             string
> >        |     +--rw ietf
> >        |     |  +--rw ietf-wg?   string
> >        |     +--rw namespace                inet:uri
> >        |     +--rw schema?                  inet:uri
> >        |     +--rw generated-from?          enumeration [mib, code,
> > not-applicable, native]
> >        |     +--rw maturity-level?          enumeration [ratified,
> > adopted, initial, not-applicable]
> > ...
> >                                +--rw protocols
> >                                |  +--rw protocol* [name]
> >                                |     +--rw name
> > identityref -> protocol
> > ...
> >
> > My questions are:
> >
> > 1. Is this useful?
> >
> > 2. If so, can this be added to pyang (happy to submit a PR) and
> > draft-ietf-netmod-yang-tree-diagrams?
> >
> > 3. What changes to the output format would you recommend?
> >
> > Thanks.
> >
> > Joe
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >


From nobody Thu Sep 14 11:03:23 2017
Return-Path: 
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 70C321323B4 for ; Thu, 14 Sep 2017 11:03:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 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, 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 sPo065TgfqNm for ; Thu, 14 Sep 2017 11:03:19 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDC3D126BF0 for ; Thu, 14 Sep 2017 11:03:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2573; q=dns/txt; s=iport; t=1505412199; x=1506621799; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=I2BJxnohu8hVZDxXPQapMTycSBjJNqWwvnajd+tIBao=; b=iSVUxuj4fXYcSAKfsGpCq9TpZKLsNlPXTpEN4JHNNpz0lwsyt7ChPaCE 7V9SaU7hLZ3ZdS7AugwTFt3e90+8cDlQOVo7cAKMscwM8Sh+3KEzpF21O ZJL045lAPPncuXmDhT8RjNz1xzjLfqwLSIfdTYckZfgVik/uBRIYvBrZC s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CwAQAmw7pZ/5NdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbieDd5tbK5Y2ggQKGAuESk8ChCRXAQIBAQEBAQJrKIUYAQE?= =?us-ascii?q?BAQIBAQEhBEcLEAsOCgICJgICJzAGAQwGAgEBiiYIEKwGgW06izIBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEdgQ6CHYICgVCCDoJ9hGCDK4JgBYwnhQePVIdajHiCboh?= =?us-ascii?q?nhyGVMYE5V4ENUyQVSoUZHIIDJDaIbQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.42,394,1500940800";  d="scan'208";a="3565722"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Sep 2017 18:03:18 +0000
Received: from [10.118.87.94] (rtp-jclarke-nitro13.cisco.com [10.118.87.94]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v8EI3Imi026552; Thu, 14 Sep 2017 18:03:18 GMT
To: Martin Bjorklund , andy@yumaworks.com
Cc: netmod@ietf.org
References: <9d84d068-29ba-8e89-394f-b7f6a5272adc@cisco.com>  <20170914.195037.593298963545596882.mbj@tail-f.com>
From: Joe Clarke 
Organization: Cisco
Message-ID: <5721c564-48e9-299e-5ada-b272b00716cf@cisco.com>
Date: Thu, 14 Sep 2017 14:03:18 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170914.195037.593298963545596882.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Sep 2017 18:03:21 -0000

On 9/14/17 13:50, Martin Bjorklund wrote:
> Andy Bierman  wrote:
>> Hi,
>>
>>
>> Actually I liked the early pyang output that was concise and easy to
>> remember.
>> The current format gets very cluttered and there are too many little symbols
>> to remember them all.
> 
> I agree with Andy.  I also did some experiments with printing
> enumerations, and they work ok for small enums.  But once you have
> more than a handful they do tend to clutter the output.  Even worse so
> for trees that go into RFCs (where lines need to be < 70 characters).

What about protecting this with an optional parameter?  I certainly
appreciate the output could be large, but I think it does have its uses
sometimes.

Joe

> 
> Lada is sometimes using a format with even less information, where he
> has removed all type information, focusing more on the structure.
> 
> 
> /martin
> 
> 
> 
>>
>>
>> Andy
>>
>>
>> On Thu, Sep 14, 2017 at 8:33 AM, Joe Clarke  wrote:
>>
>>> I've been hacking on pyang, and I changed tree.py to add the enum values
>>> for enumeration types and identiyref bases for identityref types.  Here
>>> is an example:
>>>
>>> module: yang-catalog
>>>     +--rw catalog
>>>        +--rw modules
>>>        |  +--rw module* [name revision organization]
>>>        |     +--rw name                     yang:yang-identifier
>>>        |     +--rw revision                 union
>>>        |     +--rw organization             string
>>>        |     +--rw ietf
>>>        |     |  +--rw ietf-wg?   string
>>>        |     +--rw namespace                inet:uri
>>>        |     +--rw schema?                  inet:uri
>>>        |     +--rw generated-from?          enumeration [mib, code,
>>> not-applicable, native]
>>>        |     +--rw maturity-level?          enumeration [ratified,
>>> adopted, initial, not-applicable]
>>> ...
>>>                                +--rw protocols
>>>                                |  +--rw protocol* [name]
>>>                                |     +--rw name
>>> identityref -> protocol
>>> ...
>>>
>>> My questions are:
>>>
>>> 1. Is this useful?
>>>
>>> 2. If so, can this be added to pyang (happy to submit a PR) and
>>> draft-ietf-netmod-yang-tree-diagrams?
>>>
>>> 3. What changes to the output format would you recommend?
>>>
>>> Thanks.
>>>
>>> Joe
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>


From nobody Thu Sep 14 12:51:19 2017
Return-Path: 
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 7BDFF13207A for ; Thu, 14 Sep 2017 12:51:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 zFoD5JgzfpME for ; Thu, 14 Sep 2017 12:51:16 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54E631241F3 for ; Thu, 14 Sep 2017 12:51:16 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 86DB1F37; Thu, 14 Sep 2017 21:51:14 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id H6V53JlnBlgj; Thu, 14 Sep 2017 21:51:12 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 14 Sep 2017 21:51:14 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 654B5200E8; Thu, 14 Sep 2017 21:51:14 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 0Dc6jvfZTOpF; Thu, 14 Sep 2017 21:51:14 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 96755200EE; Thu, 14 Sep 2017 21:51:13 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 6657340F4D9B; Thu, 14 Sep 2017 21:51:12 +0200 (CEST)
Date: Thu, 14 Sep 2017 21:51:12 +0200
From: Juergen Schoenwaelder 
To: Lou Berger 
Cc: "t.petch" , Kent Watsen , Robert Wilton , netmod@ietf.org
Message-ID: <20170914195112.3o4vyjnbnkieruaw@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Lou Berger , "t.petch" , Kent Watsen , Robert Wilton , netmod@ietf.org
References: <14299503-509D-43BE-A938-0B7B88C3B249@juniper.net> <36ba3d4b-1ae1-0666-12cf-db41e172924b@cisco.com> <75739d75-da96-b340-2403-d0949ac54ed7@labn.net> <19134054-D52E-4A6D-992A-A47F365557AD@juniper.net> <2891bd09-0e0d-415c-2714-15141a293e42@cisco.com>  <011d01d32d77$c8e0a500$4001a8c0@gateway.2wire.net> <9c0d8394-b2a4-180a-2454-8955c1721423@labn.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9c0d8394-b2a4-180a-2454-8955c1721423@labn.net>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Sep 2017 19:51:18 -0000

On Thu, Sep 14, 2017 at 01:06:28PM -0400, Lou Berger wrote:
> 
> Actually, strictly speaking, any text in a Standards Track
> RFC that doesn't include RFC2119 language is just informative.
>

I very doubt this is true. But then, I have seen so many different
interpretations of RFC 2119 language over the years that I personally
believe that RFC 2119 usage is to a large extend random and in most
cases practically pointless.

/js

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


From nobody Thu Sep 14 13:31:00 2017
Return-Path: 
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 148E813208E for ; Thu, 14 Sep 2017 13:31:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level: 
X-Spam-Status: No, score=-2.02 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 7Gr5xDMzi--p for ; Thu, 14 Sep 2017 13:30:57 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0114.outbound.protection.outlook.com [104.47.38.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44A6313207A for ; Thu, 14 Sep 2017 13:30:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6NDRP6H2g5BBdpChS3jTg0qf9iWDW/jk11qTsEWa2Pw=; b=YR7ZZuTFpZGT7ITklKwHbmmBgq8bZ19GOpr8jVj7Y7sZlcMMbdEeoCNshbcjwBnrYN9LiFR2i+CeEMhSdajdYyV6NvHzp6I4569Lq5YZL2vrfdlNaDQfMCxTYVGrC0lt6r6PAMU8z7f/LpWmU8HgATSoaNWCY30uy7n1vR0/f9w=
Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB1969.namprd05.prod.outlook.com (10.162.224.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Thu, 14 Sep 2017 20:30:54 +0000
Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0035.010; Thu, 14 Sep 2017 20:30:54 +0000
From: Kent Watsen 
To: Andy Bierman , Robert Wilton 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] Adding system configuration to running [was: Re: Comments on NMDA-04]
Thread-Index: AQHTLW8wucbTAKlDCUqNcTBQjUSYW6K0nVUAgAAEBAD///F1gA==
Date: Thu, 14 Sep 2017 20:30:54 +0000
Message-ID: 
References: <9ec6b2e4-36a7-87e6-59fa-828855235835@ericsson.com> <20170914.163239.143365521945928900.mbj@tail-f.com> <4ce3efcd-6e88-9390-1241-21fb89985a9a@ericsson.com> <4dc2014b-0355-ac0b-f9a0-06a2d73033c4@cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB1969; 6:52PAH/9g51iqznZUvSZQF4BfWRxt/PiJDa5D7Ahklmg+fLHxI3fP+q8s4nrKrJ5HnA2sRpeYKNv53wLF6eBgdyE6CWX2k1MxEW1/jpidHb+gy9zUct5csyNcasIAIMsR2xzey2oQoVPHaLkxQsZj+EQdIq/Sz9cRLhxb9MM2ZwgvL63uq5dILKoL7QpH14EGkTsENn/Y2UaS85GgH+Hidho1teqxczrFYlFFKJJXofguCj44R43WhQuiAjjQqAfv0zC5qKrBKOJXfiJSp8nBzmL/w/W+bLEMjUsPkPN3dONyiUTXLTSHGotAifbpMAjw7e7NB3SGss58xbfnZVolwQ==; 5:/n18LDSjCBQpBE9aqC7XLHkmQI5Jp7XtYB/J53SOdviET/uWqc+aYrqBy4335EDr3jWEY7vKsh17RZmJRpV3NCuGxPsW4H7dT4w3iiY2IUlr0vBSQvpW/qnyyJsyISTg5mgpoAh9lQ4STpMPAwYbyQ==; 24:5/SyzScG/Jqhz2h+5Q3tVeQ8w9dbyfommdBCLseGuaAjzIFNSYUp1OxUmerFDAvIBXUmhS+fT4/m5XaRX0MFkKvmTw7tzqiFVJ7R++ANBUc=; 7:cEFyZZzaJItwN7xgPoueKRTOUMP/LFGQs7YXQSF6a1P7b5CM1FqQ/ZrC+S3jj/V+XfoIXM4YD0+N1WXBiLqBODjJuwDK8YwQQmZuHxJG/lh3mPHaJpgS/oUKVBhE3p3kvqK4TouU1qzlrFSGb6qvZ0U+aK5+8kcYAg1/qoGAbGHQU9fIZwFql49aXtfBO6Dq8QfK4GEVFEEaxEXHzb0dwcXPRIfv3kjjiNzFLP+DpXw=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 60a35cde-cf3a-4418-837f-08d4fbaf7fc8
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR05MB1969; 
x-ms-traffictypediagnostic: BLUPR05MB1969:
x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123560025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB1969; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB1969; 
x-forefront-prvs: 0430FA5CB7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(199003)(189002)(33656002)(3280700002)(14454004)(2900100001)(101416001)(50986999)(7736002)(54356999)(76176999)(54896002)(478600001)(99286003)(229853002)(77096006)(8936002)(58126008)(6512007)(53936002)(68736007)(6486002)(6506006)(3660700001)(36756003)(66066001)(6306002)(189998001)(82746002)(4326008)(25786009)(102836003)(2906002)(6116002)(3846002)(106356001)(81156014)(8676002)(6436002)(83716003)(81166006)(105586002)(6246003)(2950100002)(5660300001)(86362001)(83506001)(97736004)(93886005)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB1969; H:BLUPR05MB275.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_DF1AFB0F53CB40D2B46F2E5166705573junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Sep 2017 20:30:54.6528 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB1969
Archived-At: 
Subject: Re: [netmod] Adding system configuration to running [was: Re: Comments on NMDA-04]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Sep 2017 20:31:00 -0000

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

DQoNCg0KPiBJIGFncmVlIHdpdGggQmFsYXpzIHRoYXQgc3lzdGVtLWNyZWF0ZWQgbm9kZXMgaW4g
cnVubmluZyBhcmUgcXVpdGUgY29tbW9uIGFuZA0KPiB0aGUgdmVuZG9ycyBkb2luZyBpdCBoYXZl
IG5vIGludGVudGlvbiBvZiBjaGFuZ2luZyBpdC4NCg0KT2YgY291cnNlLCB3aGF0IGVsc2Ugd2Vy
ZSB0aGV5IGdvaW5nIHRvIGRvIHByZS1OTURB4oCmYW5kIGFsc28gYmVmb3JlIHJlcXVpcmUtaW5z
dGFuY2UNCmZhbHNlPyAgR3JlZW4tZmllbGQgZGVwbG95bWVudHMgd291bGRuJ3QgYmUgZW5jdW1i
ZXJlZCB3aXRoIGJhY2t3YXJkcy1jb21wYXRpYmlsaXR5Lg0KRXhpc3RpbmcgaW1wbGVtZW50YXRp
b25zIGFyZSBpbiBhIGJpbmQsIGJ1dCBJJ2QgcmVjb21tZW5kIGZvbGxvd2luZyBubWRhLWd1aWRl
bGluZXMuDQoNCkZvciBVQzE6IHRoZSBsb29wYmFjayB3b3VsZCBvbmx5IHNob3cgaW4gPG9wZXJh
dGlvbmFsPiAoYXMgYW4gYXBwbGllZCBpbnN0YW5jZSBvZiBhDQpjb25maWcgdHJ1ZSBsZWFmKSwg
YW5kIHRoZSBsZWFmcmVmIHdvdWxkIGJlIHJlcXVpcmUtaW5zdGFuY2UgZmFsc2UuICBXaGVuIGNv
bW1pdHRpbmcNCmNvbmZpZ3VyYXRpb24gdGhhdCByZWZlcmVuY2VkIGxvb3BiYWNrLCB0aGUgc2Vy
dmVyIHNlZXMgdGhhdCB0aGUgcmVmZXJlbmNlZCBsZWFmIGlzIG5vdCBpbg0KPHJ1bm5pbmc+Lzxp
bnRlbmRlZD4sIGJ1dCBpdCBjb3VsZCBzZWUgdGhhdCBpdCBpcyBvciBpcy1ub3QgaW4gPG9wZXJh
dGlvbmFsPi4gIEFuZCwgaWYgaXQNCmlzIG5vdCBpbiA8b3BlcmF0aW9uYWw+LCB0aGUgc2VydmVy
IG1pZ2h0IHJldHVybiBhIHdhcm5pbmcgdG8gdGhlIGNsaWVudCwgb3Igbm90LCBhc3N1bWluZw0K
dGhlICBjbGllbnQgd2lsbCB1c2Ugb3RoZXIgbWVjaGFuaXNtcyB0byBkaXNjb3ZlciB3aGF0IGNv
bmZpZ3VyYXRpb24gd2FzIG5vdCBhcHBsaWVkLg0KDQpGb3IgVUMyOiBzaW1pbGFyIHJlc3BvbnNl
LiAgVGhlIHNlcnZlciBjb3VsZCByZXR1cm4gYSB3YXJuaW5nIChlLmcuLCBhIHN5bmNocm9ub3Vz
DQp1cGRhdGUpIG9yIHRoZSBjbGllbnQgY2FuIGRpc2NvdmVyIHRoZSB1bmFwcGxpZWQgY29uZmln
IGFmdGVyd2FyZHMgdXNpbmcgb3RoZXINCm1lY2hhbmlzbXMuDQoNCg0KPiBJZiB0aGUgYWRkZWQg
bm9kZXMgbmVlZCB0byBiZSBzYXZlZCBpbiBub24tdm9sYXRpbGUgc3RvcmFnZSB0aGVuIHRoZW4g
ZGVmaW5pdGVseQ0KPiBiZWxvbmcgaW4gPHJ1bm5pbmc+Lg0KDQpOZWl0aGVyIG9mIEJhbGF6cydz
IHVzZS1jYXNlcyByZWdhcmQgcGVyc2lzdGVkIGRhdGEsIGF0IGxlYXN0IEkgZGlkbid0IHJlYWQg
aXQgdGhhdCB3YXkuDQoNCg0KPiBJTU8gdGhlIGFyY2hpdGVjdHVyZSBpcyByYXRoZXIgb3BhcXVl
IHdydC8gdGhlIGludGVyYWN0aW9ucyBiZXR3ZWVuIGRhdGFzdG9yZXMsDQo+IGVzcGVjaWFsbHkg
dGhlIGludGVyYWN0aW9ucyBiZXR3ZWVuIDxydW5uaW5nPiBhbmQgPGludGVuZGVkPi4gTm93IGl0
IG5vdCBvbmx5DQo+IHBydW5lcyBpbmFjdGl2ZSBub2RlcywgaXQgYWRkcyBzeXN0ZW0gbm9kZXM/
DQoNCkEgdGVtcGxhdGUgaW4gPHJ1bm5pbmc+IGNvdWxkIGJlIGZsYXR0ZW5lZCwgd2hpY2ggaGFz
IHRoZSBhcHBhcmVudCBzaWRlLWVmZmVjdA0Kb2YgY3JlYXRpbmcgbm9kZXMsIGJ1dCBub3QgYW55
IG5vZGVzLCBqdXN0IHRob3NlIHBlciB0aGUgaW5wdXQgZnJvbSA8cnVubmluZz4uDQpBcyB0aGUg
ZHJhZnQgc2F5czogPGludGVuZGVkPiBkb2VzIG5vdCBwZXJzaXN0IGFjcm9zcyByZWJvb3RzOyBp
dHMgcmVsYXRpb25zaGlwDQp3aXRoIDxydW5uaW5nPiBtYWtlcyB0aGF0IHVubmVjZXNzYXJ5LiAg
IEdlbmVyaWNhbGx5IHNwZWFraW5nLCA8cnVubmluZz4NCmNhbiBjb250YWluIHByb2Nlc3Npbmcg
aW5zdHJ1Y3Rpb25zIHRoYXQgYXJlIGNvbnN1bWVkIGF0IGNvbW1pdCB0aW1lIHRvDQpzaW11bHRh
bmVvdXNseSBjcmVhdGUgdGhlIDxpbnRlbmRlZD4gdmlldywgYW5kIHRoZXNlIFBJcyBhcmUgdGhl
IG9ubHkgdGhpbmcNCnRoYXQgY2FuIGNhdXNlIGEgZGV2aWF0aW9uIGJldHdlZW4gdGhlIHR3byBk
YXRhc3RvcmVzLg0KDQoNCj4gTWF5YmUgaXQgaXMgdG9vIGVhcmx5IGZvciBOTURBIHRvIGJlIG1h
a2luZyBsb3RzIG9mIHJ1bGVzIGFib3V0IGhvdw0KPiBZQU5HIHdvcmtzIHdpdGggbmV3IChhbmQg
dW5pbXBsZW1lbnRlZCkgZGF0YXN0b3Jlcy4NCg0KSnVuaXBlciBoYXMgdGhlIGVxdWl2YWxlbnQg
b2YgPGludGVuZGVkPiBhbHJlYWR5LiAgSSB0aGluayBvdGhlcnMgc2FpZCB0aGV5IGhhZA0Kc29t
ZXRoaW5nIGxpa2UgaXQgYXMgd2VsbC4NCg0KDQpLZW50IC8vIGNvbnRyaWJ1dG9yDQoNCg0K

--_000_DF1AFB0F53CB40D2B46F2E5166705573junipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: <52E4AC8C078C694687DFE74A0F2D24BF@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg
MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0
aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt
ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5
bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt
YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy
LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNv
SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt
ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv
d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv
cmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt
ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7
DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47
DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p
bHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHls
ZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7
DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb3Vy
aWVyO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWls
U3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpD
YWxpYnJpOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCgljb2xvcjp3aW5kb3d0
ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTsN
Cgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlw
ZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6
ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7
c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp
di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVh
ZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9
InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD
YWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IEkgYWdyZWUgd2l0aCBCYWxhenMg
dGhhdCBzeXN0ZW0tY3JlYXRlZCBub2RlcyBpbiBydW5uaW5nIGFyZSBxdWl0ZSBjb21tb24gYW5k
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7
IHRoZSB2ZW5kb3JzIGRvaW5nIGl0IGhhdmUgbm8gaW50ZW50aW9uIG9mIGNoYW5naW5nIGl0Ljxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PZiBjb3Vyc2UsIHdoYXQgZWxz
ZSB3ZXJlIHRoZXkgZ29pbmcgdG8gZG8gcHJlLU5NREHigKZhbmQgYWxzbyBiZWZvcmUgcmVxdWly
ZS1pbnN0YW5jZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZmFsc2U/Jm5i
c3A7IEdyZWVuLWZpZWxkIGRlcGxveW1lbnRzIHdvdWxkbid0IGJlIGVuY3VtYmVyZWQgd2l0aCBi
YWNrd2FyZHMtY29tcGF0aWJpbGl0eS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBhcmUgaW4gYSBiaW5kLCBidXQgSSdkIHJlY29t
bWVuZCBmb2xsb3dpbmcgbm1kYS1ndWlkZWxpbmVzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5G
b3IgVUMxOiB0aGUgbG9vcGJhY2sgd291bGQgb25seSBzaG93IGluICZsdDtvcGVyYXRpb25hbCZn
dDsgKGFzIGFuIGFwcGxpZWQgaW5zdGFuY2Ugb2YgYQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5jb25maWcgdHJ1ZSBsZWFmKSwgYW5kIHRoZSBsZWFmcmVmIHdvdWxkIGJl
IHJlcXVpcmUtaW5zdGFuY2UgZmFsc2UuJm5ic3A7IFdoZW4gY29tbWl0dGluZw0KPG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5jb25maWd1cmF0aW9uIHRoYXQgcmVmZXJlbmNl
ZCBsb29wYmFjaywgdGhlIHNlcnZlciBzZWVzIHRoYXQgdGhlIHJlZmVyZW5jZWQgbGVhZiBpcyBu
b3QgaW4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmx0O3J1bm5pbmcm
Z3Q7LyZsdDtpbnRlbmRlZCZndDssIGJ1dCBpdCBjb3VsZCBzZWUgdGhhdCBpdCBpcyBvciBpcy1u
b3QgaW4gJmx0O29wZXJhdGlvbmFsJmd0Oy4mbmJzcDsgQW5kLCBpZiBpdDxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aXMgbm90IGluICZsdDtvcGVyYXRpb25hbCZndDssIHRo
ZSBzZXJ2ZXIgbWlnaHQgcmV0dXJuIGEgd2FybmluZyB0byB0aGUgY2xpZW50LCBvciBub3QsIGFz
c3VtaW5nPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGUgJm5ic3A7Y2xp
ZW50IHdpbGwgdXNlIG90aGVyIG1lY2hhbmlzbXMgdG8gZGlzY292ZXIgd2hhdCBjb25maWd1cmF0
aW9uIHdhcyBub3QgYXBwbGllZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIFVDMjogc2lt
aWxhciByZXNwb25zZS4mbmJzcDsgVGhlIHNlcnZlciBjb3VsZCByZXR1cm4gYSB3YXJuaW5nIChl
LmcuLCBhIHN5bmNocm9ub3VzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj51
cGRhdGUpIG9yIHRoZSBjbGllbnQgY2FuIGRpc2NvdmVyIHRoZSB1bmFwcGxpZWQgY29uZmlnIGFm
dGVyd2FyZHMgdXNpbmcgb3RoZXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pm1lY2hhbmlzbXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBJZiB0aGUgYWRkZWQg
bm9kZXMgbmVlZCB0byBiZSBzYXZlZCBpbiBub24tdm9sYXRpbGUgc3RvcmFnZSB0aGVuIHRoZW4g
ZGVmaW5pdGVseQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IGJl
bG9uZyBpbiAmbHQ7cnVubmluZyZndDsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPk5laXRoZXIgb2YgQmFsYXpzJ3MgdXNlLWNhc2VzIHJlZ2FyZCBwZXJzaXN0ZWQgZGF0
YSwgYXQgbGVhc3QgSSBkaWRuJ3QgcmVhZCBpdCB0aGF0IHdheS48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4mZ3Q7IElNTyB0aGUgYXJjaGl0ZWN0dXJlIGlzIHJhdGhlciBvcGFxdWUgd3J0LyB0
aGUgaW50ZXJhY3Rpb25zIGJldHdlZW4gZGF0YXN0b3Jlcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgZXNwZWNpYWxseSB0aGUgaW50ZXJh
Y3Rpb25zIGJldHdlZW4gJmx0O3J1bm5pbmcmZ3Q7IGFuZCAmbHQ7aW50ZW5kZWQmZ3Q7LiBOb3cg
aXQgbm90IG9ubHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPiZndDsgcHJ1bmVzIGluYWN0aXZlIG5vZGVzLCBpdCBhZGRzIHN5c3RlbSBub2Rlcz88
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSB0ZW1wbGF0ZSBpbiAmbHQ7
cnVubmluZyZndDsgY291bGQgYmUgZmxhdHRlbmVkLCB3aGljaCBoYXMgdGhlIGFwcGFyZW50IHNp
ZGUtZWZmZWN0DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm9mIGNyZWF0
aW5nIG5vZGVzLCBidXQgbm90IGFueSBub2RlcywganVzdCB0aG9zZSBwZXIgdGhlIGlucHV0IGZy
b20gJmx0O3J1bm5pbmcmZ3Q7LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
QXMgdGhlIGRyYWZ0IHNheXM6ICZsdDtpbnRlbmRlZCZndDsgZG9lcyBub3QgcGVyc2lzdCBhY3Jv
c3MgcmVib290czsgaXRzIHJlbGF0aW9uc2hpcDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+d2l0aCAmbHQ7cnVubmluZyZndDsgbWFrZXMgdGhhdCB1bm5lY2Vzc2FyeS4mbmJz
cDsmbmJzcDsgR2VuZXJpY2FsbHkgc3BlYWtpbmcsICZsdDtydW5uaW5nJmd0OzxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Y2FuIGNvbnRhaW4gcHJvY2Vzc2luZyBpbnN0cnVj
dGlvbnMgdGhhdCBhcmUgY29uc3VtZWQgYXQgY29tbWl0IHRpbWUgdG8NCjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c2ltdWx0YW5lb3VzbHkgY3JlYXRlIHRoZSAmbHQ7aW50
ZW5kZWQmZ3Q7IHZpZXcsIGFuZCB0aGVzZSBQSXMgYXJlIHRoZSBvbmx5IHRoaW5nPG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGF0IGNhbiBjYXVzZSBhIGRldmlhdGlvbiBi
ZXR3ZWVuIHRoZSB0d28gZGF0YXN0b3Jlcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7
IE1heWJlIGl0IGlzIHRvbyBlYXJseSBmb3IgTk1EQSB0byBiZSBtYWtpbmcgbG90cyBvZiBydWxl
cyBhYm91dCBob3cNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBZ
QU5HIHdvcmtzIHdpdGggbmV3IChhbmQgdW5pbXBsZW1lbnRlZCkgZGF0YXN0b3Jlcy48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVuaXBlciBoYXMgdGhlIGVxdWl2YWxl
bnQgb2YgJmx0O2ludGVuZGVkJmd0OyBhbHJlYWR5LiZuYnNwOyBJIHRoaW5rIG90aGVycyBzYWlk
IHRoZXkgaGFkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zb21ldGhpbmcg
bGlrZSBpdCBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPktlbnQgLy8gY29udHJp
YnV0b3I8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_DF1AFB0F53CB40D2B46F2E5166705573junipernet_--


From nobody Thu Sep 14 14:27:21 2017
Return-Path: 
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 1D71313208E for ; Thu, 14 Sep 2017 14:27:20 -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 Q5F42LNh5AYB for ; Thu, 14 Sep 2017 14:27:17 -0700 (PDT)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 C92EA120724 for ; Thu, 14 Sep 2017 14:27:16 -0700 (PDT)
Received: by mail-lf0-x22c.google.com with SMTP id q132so618258lfe.5 for ; Thu, 14 Sep 2017 14:27:16 -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=EfQ1OOmStXdkXJH7J7FO9NS2id2mlrQP4ErKMAhjeV0=; b=wWQ4kTgQBUcA3b6ihzRRLZmwf0fYv/8I76gukldctS3j1nee50uoY+wE5uQRKCA6Dj ikGrNgAgrwOn5cfhfu9EPnSKkHShw66E5rj0ubtMlO8wCBp+2NUCgmUEYwdOnNB+ARnP /0MIZbX9WgI8g8AuOThaQlMXPPfGeI0QUtZQo9PD9/XvhYqJu8KQJ6yTEAO9HxqqEPzG sWAnv4gRE9cSNphPAHPypDTRFihX/m+fjPUU12LSx7MHK7BFUOLx2ruwnE93OtqUNYz/ 3WAU7nTf5NNBcJ6MfvDipYbApRWdMCA4vaFnjgzOUtPImq6nsl4dvCEZCaByfA4GxsQ/ yqdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EfQ1OOmStXdkXJH7J7FO9NS2id2mlrQP4ErKMAhjeV0=; b=NlSKRGtHzeuaOM88H0DIGQ16EVFl7AvE5/h4Fqf9dT3pAYCPjo2Lobu5HRlCMtPZKQ ixPJKUAP9hsffPmgw6BOKKpUaVu01bNZzLeNnNVRW9hIrRDibECBbFRxytWNkdHXR5gc Nfrmw2aNz5D7r3CMNKFgSHVu1nXnwOHWonZFJZI372UWmlHvHrzOYVIyBtzEIVRLoWQ6 aC1OEh69WpJFRNePT6rGE6xJYFzU3rpPOhVMjP29zPnYq3AJWilrnJa/bdyZAP20SvCf sfePtC03tDqZYauGXYccZVSSHBAEr1ejl0QbI+NnizyVbGWkg3DzQtF/U5vMZPojfof2 2cbQ==
X-Gm-Message-State: AHPjjUijFYYf45HWQkHnfBnt7EZZHDUnrvRVtfN//cFmLPvZW4Y1SxHZ 9jN9yv+Va0inS1fd1QwYok+s9cqYDQByEpDUhyrDOA==
X-Google-Smtp-Source: AOwi7QBoTGkSHssxdpXH9vMtVg8AdqKlM3CYdUpmZ6deaPfz6CuPR1UgNB8eBHp/IBrJ/n+HY9s6/sbfSzlDqlBZZGk=
X-Received: by 10.25.22.228 with SMTP id 97mr8704075lfw.205.1505424434753; Thu, 14 Sep 2017 14:27:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.18.41 with HTTP; Thu, 14 Sep 2017 14:27:14 -0700 (PDT)
In-Reply-To: 
References: <9ec6b2e4-36a7-87e6-59fa-828855235835@ericsson.com> <20170914.163239.143365521945928900.mbj@tail-f.com> <4ce3efcd-6e88-9390-1241-21fb89985a9a@ericsson.com> <4dc2014b-0355-ac0b-f9a0-06a2d73033c4@cisco.com>  
From: Andy Bierman 
Date: Thu, 14 Sep 2017 14:27:14 -0700
Message-ID: 
To: Kent Watsen 
Cc: Robert Wilton , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="001a1140260cab85cc05592cf01b"
Archived-At: 
Subject: Re: [netmod] Adding system configuration to running [was: Re: Comments on NMDA-04]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Sep 2017 21:27:20 -0000

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

On Thu, Sep 14, 2017 at 1:30 PM, Kent Watsen  wrote:

>
>
>
>
>
>
> > I agree with Balazs that system-created nodes in running are quite
> common and
>
> > the vendors doing it have no intention of changing it.
>
>
>
> Of course, what else were they going to do pre-NMDA=E2=80=A6and also befo=
re
> require-instance
>
> false?  Green-field deployments wouldn't be encumbered with
> backwards-compatibility.
>
> Existing implementations are in a bind, but I'd recommend following
> nmda-guidelines.
>
>
>


This might break non-NMDA clients expecting to see the system-created confi=
g
in retrieval responses. I think vendors will decide their own transition
plans
and decide how much disruption at once is OK.



> For UC1: the loopback would only show in  (as an applied
> instance of a
>
> config true leaf), and the leafref would be require-instance false.  When
> committing
>
> configuration that referenced loopback, the server sees that the
> referenced leaf is not in
>
> /, but it could see that it is or is-not in
> .  And, if it
>
> is not in , the server might return a warning to the client,
> or not, assuming
>
> the  client will use other mechanisms to discover what configuration was
> not applied.
>
>
>
> For UC2: similar response.  The server could return a warning (e.g., a
> synchronous
>
> update) or the client can discover the unapplied config afterwards using
> other
>
> mechanisms.
>
>
>
>
>
> > If the added nodes need to be saved in non-volatile storage then then
> definitely
>
> > belong in .
>
>
>
> Neither of Balazs's use-cases regard persisted data, at least I didn't
> read it that way.
>
>
>
>
>
> > IMO the architecture is rather opaque wrt/ the interactions between
> datastores,
>
> > especially the interactions between  and . Now it no=
t
> only
>
> > prunes inactive nodes, it adds system nodes?
>
>
>
> A template in  could be flattened, which has the apparent
> side-effect
>
> of creating nodes, but not any nodes, just those per the input from
> .
>
> As the draft says:  does not persist across reboots; its
> relationship
>
> with  makes that unnecessary.   Generically speaking, 
>
> can contain processing instructions that are consumed at commit time to
>
> simultaneously create the  view, and these PIs are the only thi=
ng
>
> that can cause a deviation between the two datastores.
>
>
>
>
>
> > Maybe it is too early for NMDA to be making lots of rules about how
>
> > YANG works with new (and unimplemented) datastores.
>
>
>
> Juniper has the equivalent of  already.  I think others said
> they had
>
> something like it as well.
>
>
>
>
>

If I can only do YANG validation on expanded templates in , does
that mean
it is impossible to do YANG validation on the templates themselves in
?
The template subtree can only use YANG constraints on external structures
in 
and not refer to itself in anyway (in )?

The RD draft sure has a lot of normative details for something that does
not use RFC 2119
terminology at all. I didn't know a Standards Track document could omit
these terms.
Architecture documents are usually Informational.

IMO the RD draft should not mention YANG or XPath at all.
That should be moved to an update to RFC 7950.
Those parts need more work anyway. The ARCH can move forward
without any dependence on YANG details.



> Kent // contributor
>
>
>
>
>

Andy

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




On Thu, Sep 14, 2017 at 1:30 PM, Kent Watsen <kwatsen@juniper.net> wrote:













=C2=A0=



=C2=A0=











=C2=A0






> I agree with Balazs that system-created nodes i=
n running are quite common and






> the vendors doing it have no intention of chang=
ing it.






=C2=A0


Of course, what else were they going to do pre-NMDA=
=E2=80=A6and also before require-instance


false?=C2=A0 Green-field deployments wouldn't be=
 encumbered with backwards-compatibility.


Existing implementations are in a bind, but I'd =
recommend following nmda-guidelines.


=C2=A0


This might break non-NMDA =
clients expecting to see the system-created config
in retrieval r=
esponses. I think vendors will decide their own transition plans
=
and decide how much disruption at once is OK.

=C2=
=A0


For UC1: the loopback would only show in <operati=
onal> (as an applied instance of a



config true leaf), and the leafref would be require-=
instance false.=C2=A0 When committing



configuration that referenced loopback, the server s=
ees that the referenced leaf is not in



<running>/<intended>, but it could see t=
hat it is or is-not in <operational>.=C2=A0 And, if it<=
/p>

is not in <operational>, the server might retu=
rn a warning to the client, or not, assuming


the =C2=A0client will use other mechanisms to discov=
er what configuration was not applied.


=C2=A0


For UC2: similar response.=C2=A0 The server could re=
turn a warning (e.g., a synchronous


update) or the client can discover the unapplied con=
fig afterwards using other


mechanisms.


=C2=A0


=C2=A0






> If the added nodes need to be saved in non-vola=
tile storage then then definitely



> belong in <running>.






=C2=A0


Neither of Balazs's use-cases regard persisted d=
ata, at least I didn't read it that way.


=C2=A0


=C2=A0






> IMO the architecture is rather opaque wrt/ the =
interactions between datastores,






> especially the interactions between <running=
> and <intended>. Now it not only






> prunes inactive nodes, it adds system nodes?=







=C2=A0


A template in <running> could be flattened, wh=
ich has the apparent side-effect



of creating nodes, but not any nodes, just those per=
 the input from <running>.


As the draft says: <intended> does not persist=
 across reboots; its relationship


with <running> makes that unnecessary.=C2=A0=
=C2=A0 Generically speaking, <running>


can contain processing instructions that are consume=
d at commit time to



simultaneously create the <intended> view, and=
 these PIs are the only thing


that can cause a deviation between the two datastore=
s.


=C2=A0


=C2=A0






> Maybe it is too early for NMDA to be making lot=
s of rules about how



> YANG works with new (and unimplemented) datasto=
res.






=C2=A0


Juniper has the equivalent of <intended> alrea=
dy.=C2=A0 I think others said they had


something like it as well.


=C2=A0






=C2=A0

If I can only do YANG validation on expan=
ded templates in <intended>, does that mean
it is impossibl=
e to do YANG validation on the templates themselves in <running>?
The template subtree can only use YANG constraints on external struc=
tures in <intended>
and not refer to itself in anyway (in &=
lt;running>)?

The RD draft sure has a lot of no=
rmative details for something that does not use RFC 2119
terminol=
ogy at all. I didn't know a Standards Track document could omit these t=
erms.
Architecture documents are usually Informational.

IMO the RD draft should not mention YANG or XPath at all.
That should be moved to an update to RFC 7950.
Those par=
ts need more work anyway. The ARCH can move forward
without any d=
ependence on YANG details.

=C2=A0


Kent // contributor


=C2=A0






=C2=A0












Andy



--001a1140260cab85cc05592cf01b--


From nobody Thu Sep 14 18:42:30 2017
Return-Path: 
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 16116132D44; Thu, 14 Sep 2017 18:42:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAmCChzKHA0p; Thu, 14 Sep 2017 18:42:26 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9867313219A; Thu, 14 Sep 2017 18:42:25 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML710-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DOP37172; Fri, 15 Sep 2017 01:42:23 +0000 (GMT)
Received: from DGGEML404-HUB.china.huawei.com (10.3.17.39) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 15 Sep 2017 02:42:22 +0100
Received: from DGGEML507-MBX.china.huawei.com ([169.254.2.7]) by DGGEML404-HUB.china.huawei.com ([fe80::b177:a243:7a69:5ab8%31]) with mapi id 14.03.0301.000; Fri, 15 Sep 2017 09:42:17 +0800
From: Jiangyuanlong 
To: "netmod@ietf.org" 
CC: "tictoc@ietf.org" 
Thread-Topic: WGLC for draft-ietf-tictoc-1588v2-yang
Thread-Index: AQHTLMS9I02w6VlOokuuR++M6yrZg6K1JzgQ
Date: Fri, 15 Sep 2017 01:42:16 +0000
Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5A2CBD@dggeml507-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.74.202.215]
Content-Type: text/plain; charset="utf-7"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59BB2FFF.0139, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.2.7, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: a1108938c80d53acc52f230d9e9147d9
Archived-At: 
Subject: [netmod] FW: WGLC for draft-ietf-tictoc-1588v2-yang
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 01:42:28 -0000

Hi netmoders,

This draft does not tackle the general YANG problem, but provide a generic =
time synchronization module of 1588.
Some of you may have interests in time synchronization, some definitely not=
. But as experts in YANG, could you please have a review of this YANG modul=
e and give an expert opinion?

Thanks,
Yuanlong

-----Original Message-----
From: TICTOC +AFs-mailto:tictoc-bounces+AEA-ietf.org+AF0- On Behalf Of Kare=
n O'Donoghue
Sent: Thursday, September 14, 2017 3:16 AM
To: tictoc+AEA-ietf.org
Cc: ntp+AEA-ietf.org
Subject: +AFs-TICTOC+AF0- WGLC for draft-ietf-tictoc-1588v2-yang

Folks,

This message begins a 2 week working group last call (WGLC) for the followi=
ng document:=20

YANG Data Model for IEEE 1588v2
https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588v2-yang/

Please review the referenced document and send any comments to the mailing =
list including your assessment of whether this document is mature enough to=
 proceed to the IESG. Please note that these messages of support for progre=
ssion to the mailing list are important and will be used to determine WG co=
nsensus to proceed.=20

Please send all comments in by Thursday 28 September 2017. =20

Thank you+ACE-
Karen
+AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF=
8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw-
TICTOC mailing list
TICTOC+AEA-ietf.org
https://www.ietf.org/mailman/listinfo/tictoc


From nobody Thu Sep 14 22:27:28 2017
Return-Path: 
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 4B277132403; Thu, 14 Sep 2017 22:27:27 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMTEuPoI6GBM; Thu, 14 Sep 2017 22:27:25 -0700 (PDT)
Received: from mail-send.aviatnet.com (mail-send.aviatnet.com [192.147.115.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD5A1132335; Thu, 14 Sep 2017 22:27:25 -0700 (PDT)
From: Alex Campbell 
To: Jiangyuanlong , "netmod@ietf.org" 
CC: "tictoc@ietf.org" 
Thread-Topic: WGLC for draft-ietf-tictoc-1588v2-yang
Thread-Index: AQHTLMS9I02w6VlOokuuR++M6yrZg6K1JzgQgAA51/0=
Date: Fri, 15 Sep 2017 05:27:23 +0000
Message-ID: <1505453243090.91370@Aviatnet.com>
References: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5A2CBD@dggeml507-mbx.china.huawei.com>
In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5A2CBD@dggeml507-mbx.china.huawei.com>
Accept-Language: en-NZ, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.15.6.10]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] WGLC for draft-ietf-tictoc-1588v2-yang
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 05:27:27 -0000

Hi,=0A=
I've reviewed the draft and found the following issues.=0A=
=0A=
* YANG enumeration values are conventionally lowercase, but the delay-mecha=
nism-enumeration and port-state-enumeration types in the draft have upperca=
se values.=0A=
* Similarly, hyphens should be used rather than underscores (pre-master ins=
tead of PRE_MASTER)=0A=
* number-ports doesn't read naturally in English; I suggest renaming it to =
number-of-ports.=0A=
* The description of port-ds-list contains a typo - "memer" instead of "mem=
ber".=0A=
* There's no need to have groupings that are only used once (such as parent=
-ds-entry, current-ds-entry, default-ds-entry, transparent-clock-default-ds=
-entry, port-ds-entry, transparent-clock-default-ds-entry, and so on) unles=
s this is for futureproofing or some other reason I'm not aware of.=0A=
* Is it necessary to include -ds in the name of every leaf, container and g=
rouping?=0A=
=0A=
Note I'm not familiar with IEEE 1588, apart from a brief look through it ju=
st now.=0A=
=0A=
Alex=0A=
=0A=
=0A=
________________________________________=0A=
From: netmod  on behalf of Jiangyuanlong =0A=
Sent: Friday, 15 September 2017 1:42 p.m.=0A=
To: netmod@ietf.org=0A=
Cc: tictoc@ietf.org=0A=
Subject: [netmod] FW: WGLC for draft-ietf-tictoc-1588v2-yang=0A=
=0A=
Hi netmoders,=0A=
=0A=
This draft does not tackle the general YANG problem, but provide a generic =
time synchronization module of 1588.=0A=
Some of you may have interests in time synchronization, some definitely not=
. But as experts in YANG, could you please have a review of this YANG modul=
e and give an expert opinion?=0A=
=0A=
Thanks,=0A=
Yuanlong=0A=
=0A=
-----Original Message-----=0A=
From: TICTOC [mailto:tictoc-bounces@ietf.org] On Behalf Of Karen O'Donoghue=
=0A=
Sent: Thursday, September 14, 2017 3:16 AM=0A=
To: tictoc@ietf.org=0A=
Cc: ntp@ietf.org=0A=
Subject: [TICTOC] WGLC for draft-ietf-tictoc-1588v2-yang=0A=
=0A=
Folks,=0A=
=0A=
This message begins a 2 week working group last call (WGLC) for the followi=
ng document:=0A=
=0A=
YANG Data Model for IEEE 1588v2=0A=
https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588v2-yang/=0A=
=0A=
Please review the referenced document and send any comments to the mailing =
list including your assessment of whether this document is mature enough to=
 proceed to the IESG. Please note that these messages of support for progre=
ssion to the mailing list are important and will be used to determine WG co=
nsensus to proceed.=0A=
=0A=
Please send all comments in by Thursday 28 September 2017.=0A=
=0A=
Thank you!=0A=
Karen=0A=
_______________________________________________=0A=
TICTOC mailing list=0A=
TICTOC@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/tictoc=0A=
=0A=
_______________________________________________=0A=
netmod mailing list=0A=
netmod@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/netmod=0A=


From nobody Thu Sep 14 22:37:15 2017
Return-Path: 
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 6F98F132335 for ; Thu, 14 Sep 2017 22:37:13 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfLdvGdFEyuP for ; Thu, 14 Sep 2017 22:37: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 20E3312422F for ; Thu, 14 Sep 2017 22:37:12 -0700 (PDT)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 79B5F1AE00A0; Fri, 15 Sep 2017 07:37:10 +0200 (CEST)
Date: Fri, 15 Sep 2017 07:37:54 +0200 (CEST)
Message-Id: <20170915.073754.2218390958448188581.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: kwatsen@juniper.net, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References:   
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Adding system configuration to running
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 05:37:13 -0000

Andy Bierman  wrote:
> On Thu, Sep 14, 2017 at 1:30 PM, Kent Watsen  wrote:
> > > Maybe it is too early for NMDA to be making lots of rules about how
> >
> > > YANG works with new (and unimplemented) datastores.
> >
> >
> >
> > Juniper has the equivalent of  already.  I think others said
> > they had
> >
> > something like it as well.

Yes, we have that as well.  (No template expansion, but removal of
inactive nodes).

> If I can only do YANG validation on expanded templates in , does
> that mean
> it is impossible to do YANG validation on the templates themselves in
> ?
> The template subtree can only use YANG constraints on external structures
> in 
> and not refer to itself in anyway (in )?

Note that the architecture draft does not specify any templating
mechanism, it merely points out that templating is a mechanism that
_can_ influence intended.  When/if such a mechanism is designed, it
needs to work out all these details.


/martin


> 
> The RD draft sure has a lot of normative details for something that does
> not use RFC 2119
> terminology at all. I didn't know a Standards Track document could omit
> these terms.
> Architecture documents are usually Informational.
> 
> IMO the RD draft should not mention YANG or XPath at all.
> That should be moved to an update to RFC 7950.
> Those parts need more work anyway. The ARCH can move forward
> without any dependence on YANG details.
> 
> 
> 
> > Kent // contributor
> >
> >
> >
> >
> >
> 
> Andy


From nobody Fri Sep 15 01:11:10 2017
Return-Path: 
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 D1625133070 for ; Fri, 15 Sep 2017 01:11:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 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, URIBL_BLOCKED=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 CsLsSRYU8JUe for ; Fri, 15 Sep 2017 01:11:07 -0700 (PDT)
Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 AAB76133078 for ; Fri, 15 Sep 2017 01:11:06 -0700 (PDT)
Received: by mail-lf0-x236.google.com with SMTP id d17so1638908lfe.2 for ; Fri, 15 Sep 2017 01:11:06 -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=jEHdHmiTWjmMTsebAy4/uozESasUuMLD8qqiEEeyNjc=; b=MIj9c2e0vhdZuDlnSf8G3m8s0IWuOKco8ki9WdJB7ty/ddLzayxia2vK7/uEFAVjyg 09ErofpezXagAAO+eHkfwJRRnOICNbGE6oS5BBTmtrpotfkAzxVJtdXeEO9EZeDkwHTP 0VEjmJoSH0cEHWw/+OPmV7Zqr9fFFNNEH8VLfWMVD3SsXI4yB8IMf/yftiahslpcUaF0 R72t21QLDNIVi3jLvN0dnek545M0wwaZjCwvmkzQ3ejPhBob9Uoz3t78VLfqU2HxRMqx 2264R811MEn2Jc2xj6Up8NDx/LJGCJBLxG9EEcS9RWFbPsO/dRu+i+fL2tJOLIx5YBSP HdEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jEHdHmiTWjmMTsebAy4/uozESasUuMLD8qqiEEeyNjc=; b=Dy4iAuTme25bT22dVJnpEF4si+N4fgV2aAZU3fzkV7cCyxUpW4v9NuZa/pb7V94i3e Vplf2u5RRA3dny+0y6E8JQz2TxQvI0LraCL0nkWKLm4cOI5chANwbXDxaunPa7wtA5sg DMKfuW19a+gy2Q0le1uPpa5L7Zl9w9UEy+4BB2TkBkCu3KVNNYMgn3YzyNmAZC3OMii/ 6+jhsPZ694jY64UCpnsesVD8DRaF3RN3ElnM/MYCvFwUp6FUa7Ni93jLaVkKeQOHSKPW tXYvhjHdYOPq53LDuigrhGq3LXkmvXGrvjf4IyAxnqIGucZOINpp/Dax30pY13CmcP52 GJew==
X-Gm-Message-State: AHPjjUhkOb4EtCUNtqsrSr4PTKWQ3RUoM4Q2sIZufjYzB2yOmkPlFsAk aZ1F20QpldNGJo8ZR1m09giCtn9VtHst30zvV2AnMQ==
X-Google-Smtp-Source: AOwi7QCydF1ct2FqygC/61wUXP7kBn+wk56nRXcPHd1i9EM08VZh/MYByxdw4wSooBxfhCIvlv32kIblcKkS4hlXm2I=
X-Received: by 10.46.4.129 with SMTP id a1mr10441913ljf.6.1505463064929; Fri, 15 Sep 2017 01:11:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.18.41 with HTTP; Fri, 15 Sep 2017 01:11:04 -0700 (PDT)
In-Reply-To: <20170915.073754.2218390958448188581.mbj@tail-f.com>
References:    <20170915.073754.2218390958448188581.mbj@tail-f.com>
From: Andy Bierman 
Date: Fri, 15 Sep 2017 01:11:04 -0700
Message-ID: 
To: Martin Bjorklund 
Cc: Kent Watsen , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114a1690353bbc055935ef6d"
Archived-At: 
Subject: Re: [netmod] Adding system configuration to running
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 08:11:09 -0000

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

On Thu, Sep 14, 2017 at 10:37 PM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > On Thu, Sep 14, 2017 at 1:30 PM, Kent Watsen 
> wrote:
> > > > Maybe it is too early for NMDA to be making lots of rules about how
> > >
> > > > YANG works with new (and unimplemented) datastores.
> > >
> > >
> > >
> > > Juniper has the equivalent of  already.  I think others said
> > > they had
> > >
> > > something like it as well.
>
> Yes, we have that as well.  (No template expansion, but removal of
> inactive nodes).
>
> > If I can only do YANG validation on expanded templates in ,
> does
> > that mean
> > it is impossible to do YANG validation on the templates themselves in
> > ?
> > The template subtree can only use YANG constraints on external structures
> > in 
> > and not refer to itself in anyway (in )?
>
> Note that the architecture draft does not specify any templating
> mechanism, it merely points out that templating is a mechanism that
> _can_ influence intended.  When/if such a mechanism is designed, it
> needs to work out all these details.
>
>
Doesn't it say YANG validation is done on  and not on ?
If so, then how are YANG validation statements inside the template objects
evaluated?
Do they exist in both datastores, yet YANG validation is done in only 1
datastore?



>
> /martin
>
>
Andy


>
> >
> > The RD draft sure has a lot of normative details for something that does
> > not use RFC 2119
> > terminology at all. I didn't know a Standards Track document could omit
> > these terms.
> > Architecture documents are usually Informational.
> >
> > IMO the RD draft should not mention YANG or XPath at all.
> > That should be moved to an update to RFC 7950.
> > Those parts need more work anyway. The ARCH can move forward
> > without any dependence on YANG details.
> >
> >
> >
> > > Kent // contributor
> > >
> > >
> > >
> > >
> > >
> >
> > Andy
>

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




On Thu, Sep 14, 2017 at 10:37 PM, Martin Bjorklund &l=
t;mbj@tail-f.com>=
; wrote:
Andy Bierman <andy@yumaworks.com> wrote:

> On Thu, Sep 14, 2017 at 1:30 PM, Kent Watsen <kwatsen@juniper.net> wrote:

> > > Maybe it is too early for NMDA to be making lots of rules ab=
out how

> >

> > > YANG works with new (and unimplemented) datastores.

> >

> >

> >

> > Juniper has the equivalent of <intended> already.=C2=A0 I t=
hink others said

> > they had

> >

> > something like it as well.



Yes, we have that as well.=C2=A0 (No template expansion, but removal of

inactive nodes).



> If I can only do YANG validation on expanded templates in <intended=
>, does

> that mean

> it is impossible to do YANG validation on the templates themselves in<=
br>
> <running>?

> The template subtree can only use YANG constraints on external structu=
res

> in <intended>

> and not refer to itself in anyway (in <running>)?



Note that the architecture draft does not specify any templating

mechanism, it merely points out that templating is a mechanism that

_can_ influence intended.=C2=A0 When/if such a mechanism is designed, it
needs to work out all these details.



Doesn't it say YANG validation is =
done on <intended> and not on <running>?
If so, then =
how are YANG validation statements inside the template objects evaluated?
Do they exist in both datastores, yet YANG validation is done in o=
nly 1 datastore?

=C2=A0



/martin



Andy
=C2=A0



>

> The RD draft sure has a lot of normative details for something that do=
es

> not use RFC 2119

> terminology at all. I didn't know a Standards Track document could=
 omit

> these terms.

> Architecture documents are usually Informational.

>

> IMO the RD draft should not mention YANG or XPath at all.

> That should be moved to an update to RFC 7950.

> Those parts need more work anyway. The ARCH can move forward

> without any dependence on YANG details.

>

>

>

> > Kent // contributor

> >

> >

> >

> >

> >

>

> Andy





--001a114a1690353bbc055935ef6d--


From nobody Fri Sep 15 01:19:39 2017
Return-Path: 
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 1F7F5132F2E for ; Fri, 15 Sep 2017 01:19:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jznBcyAt9JPX for ; Fri, 15 Sep 2017 01:19:35 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FE1F1201F8 for ; Fri, 15 Sep 2017 01:19:35 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 2A58EF14; Fri, 15 Sep 2017 10:19:33 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id TDIEZvrvDBOn; Fri, 15 Sep 2017 10:19:30 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 15 Sep 2017 10:19:33 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0A931200E9; Fri, 15 Sep 2017 10:19:33 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id lxqqaeoqcGhk; Fri, 15 Sep 2017 10:19:32 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 959C3200E8; Fri, 15 Sep 2017 10:19:32 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 7E28140F5940; Fri, 15 Sep 2017 10:19:31 +0200 (CEST)
Date: Fri, 15 Sep 2017 10:19:31 +0200
From: Juergen Schoenwaelder 
To: Andy Bierman 
Cc: Martin Bjorklund , "netmod@ietf.org" 
Message-ID: <20170915081931.hgha4wmfdhktvbog@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" 
References:    <20170915.073754.2218390958448188581.mbj@tail-f.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] Adding system configuration to running
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 08:19:37 -0000

On Fri, Sep 15, 2017 at 01:11:04AM -0700, Andy Bierman wrote:
>
> Doesn't it say YANG validation is done on  and not on ?
> If so, then how are YANG validation statements inside the template objects
> evaluated?
> Do they exist in both datastores, yet YANG validation is done in only 1
> datastore?
>

What I have understood so far is that template mechanisms differ quite
a bit in the details how they work. Ideally, both the template content
and the expansion resulting from the template content should be valid.
But until someone tries to work out a standard template mechanism, we
simply won't know the details. (And whether a standard for templates
is feasible, I do not know.)

/js

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


From nobody Fri Sep 15 03:21:11 2017
Return-Path: 
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 390721330A6 for ; Fri, 15 Sep 2017 03:21:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level: 
X-Spam-Status: No, score=-6.999 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, URIBL_BLOCKED=0.001] 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 ePClcaJAUWUE for ; Fri, 15 Sep 2017 03:21:06 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 B4CDB1330A3 for ; Fri, 15 Sep 2017 03:21:05 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 9949D60912 for ; Fri, 15 Sep 2017 12:21:03 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1505470863; bh=g7IWG41AG+55Pc8e0f2BVzyVNxz5PMTHFb31uFEIec0=; h=From:To:Date; b=vcKur0HKm11LpJuuzp++DyVtk/M0ZJ71Dr89aV8srXmoNzH20TaX6pFDvt4uWQBbj HoVynjvhEiXoXl5P7N6Cejp5tCwOk0EvlIuMfHrNPvU/KWemyB89AJbjHlRmpmhVpb m3OqHeaiyGsvsUMDBc20qRaZDoOidb7ZQz/PG/aQ=
Message-ID: <1505470900.18681.0.camel@nic.cz>
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Fri, 15 Sep 2017 12:21:40 +0200
In-Reply-To: 
References: <9d84d068-29ba-8e89-394f-b7f6a5272adc@cisco.com> 
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.24.5 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 10:21:09 -0000

Andy Bierman píše v Čt 14. 09. 2017 v 08:43 -0700:
> Hi,
> 
> 
> Actually I liked the early pyang output that was concise and easy to remember.
> The current format gets very cluttered and there are too many little symbols
> to remember them all.

I agree.

Lada

> 
> 
> Andy
> 
> 
> On Thu, Sep 14, 2017 at 8:33 AM, Joe Clarke  wrote:
> > I've been hacking on pyang, and I changed tree.py to add the enum values
> > for enumeration types and identiyref bases for identityref types.  Here
> > is an example:
> > 
> > module: yang-catalog
> >     +--rw catalog
> >        +--rw modules
> >        |  +--rw module* [name revision organization]
> >        |     +--rw name                     yang:yang-identifier
> >        |     +--rw revision                 union
> >        |     +--rw organization             string
> >        |     +--rw ietf
> >        |     |  +--rw ietf-wg?   string
> >        |     +--rw namespace                inet:uri
> >        |     +--rw schema?                  inet:uri
> >        |     +--rw generated-from?          enumeration [mib, code,
> > not-applicable, native]
> >        |     +--rw maturity-level?          enumeration [ratified,
> > adopted, initial, not-applicable]
> > ...
> >                                +--rw protocols
> >                                |  +--rw protocol* [name]
> >                                |     +--rw name
> > identityref -> protocol
> > ...
> > 
> > My questions are:
> > 
> > 1. Is this useful?
> > 
> > 2. If so, can this be added to pyang (happy to submit a PR) and
> > draft-ietf-netmod-yang-tree-diagrams?
> > 
> > 3. What changes to the output format would you recommend?
> > 
> > Thanks.
> > 
> > Joe
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Fri Sep 15 03:29:35 2017
Return-Path: 
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 438171320BD for ; Fri, 15 Sep 2017 03:29:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 HpThNRqz0_3a for ; Fri, 15 Sep 2017 03:29:33 -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 8FCFF12895E for ; Fri, 15 Sep 2017 03:29:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2284; q=dns/txt; s=iport; t=1505471372; x=1506680972; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=+qnr2ieRPfO9gaXarXwhGjOnW/6Q/CERz7dNlHQEkOw=; b=MATZ4dlyUrHRshbqiZtYVcW6DQfzERRHGm/6xAB71/g22rt3nOa+mWuE NghP5FDfnXuzGf9MMvmatPU4FGfZU2Jkj9qpJnNAzgcphHWgKdA/CoVwM EEKv0xOWxbuvl6WuCYe+slwAgLHsS7cOOPmj5SusCrQ8kgPm7kMjHMwNC s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C/AQAeq7tZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD5uJ4N1ixSQSiuYOQoYC4RKTwKEbRUBAgEBAQEBAQFrKIUYAQE?= =?us-ascii?q?BAQIBAQEhBAsBBTYbCQIYAgImAgInMAYBDAYCAQGKJwgQjU6dZoFtOosyAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAR+BDoIdg1KCDguCcogLgmAFjCiFB49Vh1uMeoJuiGm?= =?us-ascii?q?HIY1dh1WBOTUigQ0yIQgcFUmHHT82iREBAQE?=
X-IronPort-AV: E=Sophos;i="5.42,396,1500940800"; d="scan'208";a="654638873"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Sep 2017 10:29:30 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v8FATTOV025317; Fri, 15 Sep 2017 10:29:30 GMT
To: Ladislav Lhotka , netmod@ietf.org
References: <9d84d068-29ba-8e89-394f-b7f6a5272adc@cisco.com>  <1505470900.18681.0.camel@nic.cz>
From: Robert Wilton 
Message-ID: <5b512435-cebd-3534-eeb3-649154450d81@cisco.com>
Date: Fri, 15 Sep 2017 11:29:29 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <1505470900.18681.0.camel@nic.cz>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 10:29:34 -0000

On 15/09/2017 11:21, Ladislav Lhotka wrote:
> Andy Bierman píše v Čt 14. 09. 2017 v 08:43 -0700:
>> Hi,
>>
>>
>> Actually I liked the early pyang output that was concise and easy to remember.
>> The current format gets very cluttered and there are too many little symbols
>> to remember them all.
> I agree.
I definitely think that "x" is a bit confusing since it both means "RPC" 
and also "status deprecated" depending on where it is.

Thanks,
Rob


>
> Lada
>
>>
>> Andy
>>
>>
>> On Thu, Sep 14, 2017 at 8:33 AM, Joe Clarke  wrote:
>>> I've been hacking on pyang, and I changed tree.py to add the enum values
>>> for enumeration types and identiyref bases for identityref types.  Here
>>> is an example:
>>>
>>> module: yang-catalog
>>>      +--rw catalog
>>>         +--rw modules
>>>         |  +--rw module* [name revision organization]
>>>         |     +--rw name                     yang:yang-identifier
>>>         |     +--rw revision                 union
>>>         |     +--rw organization             string
>>>         |     +--rw ietf
>>>         |     |  +--rw ietf-wg?   string
>>>         |     +--rw namespace                inet:uri
>>>         |     +--rw schema?                  inet:uri
>>>         |     +--rw generated-from?          enumeration [mib, code,
>>> not-applicable, native]
>>>         |     +--rw maturity-level?          enumeration [ratified,
>>> adopted, initial, not-applicable]
>>> ...
>>>                                 +--rw protocols
>>>                                 |  +--rw protocol* [name]
>>>                                 |     +--rw name
>>> identityref -> protocol
>>> ...
>>>
>>> My questions are:
>>>
>>> 1. Is this useful?
>>>
>>> 2. If so, can this be added to pyang (happy to submit a PR) and
>>> draft-ietf-netmod-yang-tree-diagrams?
>>>
>>> 3. What changes to the output format would you recommend?
>>>
>>> Thanks.
>>>
>>> Joe
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod


From nobody Fri Sep 15 03:37:55 2017
Return-Path: 
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 25B7D1330AF for ; Fri, 15 Sep 2017 03:37:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level: 
X-Spam-Status: No, score=-6.999 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, URIBL_BLOCKED=0.001] 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 23diKkiw2K4z for ; Fri, 15 Sep 2017 03:37:54 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 A62461330A3 for ; Fri, 15 Sep 2017 03:37:53 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 603A0617DD for ; Fri, 15 Sep 2017 12:37:52 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1505471872; bh=flZ6kAKTv1tbIeOxZ33hZUTdd6peCviEyrAfY7Vysuw=; h=From:To:Date; b=lkUcJ40YhNHHTt+TMa+ucLb9tYTgvvkRJvdsl+gWRS22eTc9BVfC+3w+2WWh6WLGJ ZGLC0urFfgvsiQx9dkhoFSOikb3Z3wLudvVAJt9wI+quxtLNmI9QEWQYBYy0R7hbtl T13bsoePUU1gWJaDOnszcVpMSEvKr5AfrcOmbqvg=
Message-ID: <1505471909.18681.7.camel@nic.cz>
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Fri, 15 Sep 2017 12:38:29 +0200
In-Reply-To: <19134054-D52E-4A6D-992A-A47F365557AD@juniper.net>
References: <14299503-509D-43BE-A938-0B7B88C3B249@juniper.net> <36ba3d4b-1ae1-0666-12cf-db41e172924b@cisco.com> <75739d75-da96-b340-2403-d0949ac54ed7@labn.net> <19134054-D52E-4A6D-992A-A47F365557AD@juniper.net>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.24.5 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 10:37:55 -0000

Kent Watsen píše v Čt 14. 09. 2017 v 14:52 +0000:
> rfc8022bis-02 signals the intent to ditch the current/soon-to-be-legacy
> module, but does it actually say it?  (I can't find it)

The modules contained therein have different names and namespaces, so there is
no formal ancestry. I would prefer to keep the modules from RFC 8022 as they are
- some weirdos may still want to use them.

> 
> The draft does say that it obsoletes 8022, but I'm unsure if that's going to
> have a meaningful impact in the wild.  I think Juergen said they had this
> issue with MIB2 and only after a couple years of misuse did they republish the
> legacy MIBs with deprecated status.
> 
> I'm okay with this change being made after adoption, so long as there's
> general agreement to do it.  Are the authors okay with it, or are there any
> better suggestions?
> 
> PS: Sadly, the 'module' statement does not have 'status' as a substatement [I
> just added this omission to the yang-next tracker].  I think the only way to
> "deprecate a module" is to instead deprecate the all the
> nodes/rpcs/notifications in the module.  Kind of ugly, but it's for a
> deprecated module, so who care, right?  ;)

I think it is unnecessary. If somebody needs adding such a module to the data
model, he/she should probably have a reason to do so, such as data implemented
on the server.

Lada  

> 
> Kent
> 
> 
> --
> 
> Hi Rob,
> 
> On 9/14/2017 9:37 AM, Robert Wilton wrote:
> > Hi Kent & Lou,
> > 
> > When do you think that it will be possible to start the adoption process 
> > on these drafts?
> > 
> > I think that the first two at least would seem to be ready for 
> > adoption.  For the 3rd draft, there still seems to be an open question 
> > of what to do with the old state tree, but presumably that could be 
> > solved after the draft has been adopted?
> 
> I see an update for the third was published yesterday
> (https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-02)  that
> clarifies the intent is to replace the current modules, and presumably
> obsolete 8022.  And now that this intended direction is clear in the
> draft we could poll it.
> 
> I think this still doesn't address if we need to indicate that the
> rfc8022 defined modules are deprecated by some other mechanisms than
> just replacing the RFC, e.g., by updating the old modules with all nodes
> marked as deprecated.  I think you're right that this could be done post
> adoption.  Of course others are free to disagree.
> 
> I check with Kent and see what he thinks.
> 
> Thanks,
> Lou
> 
> > 
> > Thanks,
> > Rob
> > 
> > 
> > On 30/08/2017 00:46, Kent Watsen wrote:
> > > Hey folks,
> > > 
> > > As discussed at the last meeting, we are heading to revising existing RFCs
> > > to align them with NMDA.  The first batch have been published as
> > > individual drafts:
> > > 
> > > 1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00
> > > 2. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00
> > > 3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00
> > > 
> > > Please take a look (comments welcome!) and stay tuned for the related
> > > adoption calls.
> > > 
> > > Thanks,
> > > Kent (and Lou)
> > > 
> > > 
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> > > .
> > > 
> 
> 
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Fri Sep 15 04:07:28 2017
Return-Path: 
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 65382133020 for ; Fri, 15 Sep 2017 04:07:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 PAA3u7nsSHCG for ; Fri, 15 Sep 2017 04:07:25 -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 BC6A21330B0 for ; Fri, 15 Sep 2017 04:07:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4964; q=dns/txt; s=iport; t=1505473644; x=1506683244; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=rKDpZk3dBUYfxUaqKHY3e+wCuRCpk2lWlEhxOhHvI+g=; b=Z/IXLBwE2Ke05XZ0hFqmHvJj4Wdef9ZgDN8JSLupi7e+7zpwBm40CB+U nYZw7UGW7xzaEfAB2fRyllYlXufqlKTWwezlh3R/TdK9WuabQorIERWM1 4S3129gPA+qRp0t23SqxJO2VwTnS1X4dnkduj5XrsLvJ0u0G3fumgGIxG Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BNAgBWs7tZ/xbLJq1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBhSyEHIsUkEorljWCBAqFPAKEbRUBAgEBAQEBAQFrKIUYAQEBAQIBIw8?= =?us-ascii?q?BBVEJAhIGAgIRFQICSQ4GAQwIAQGKJwiNZp1mgieLMgEBAQEBAQEDAQEBAQEBI?= =?us-ascii?q?oEOgh2DUoFjKwuCcoQzLQJVglSCYAWhBJRVghOFaoNahyGNXYdVgTk1IoENMiE?= =?us-ascii?q?IHBWHZj+HCCuCFAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.42,396,1500940800"; d="scan'208";a="655662662"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Sep 2017 11:07:22 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8FB7M3i027295; Fri, 15 Sep 2017 11:07:22 GMT
To: Balazs Lengyel , "netmod@ietf.org" 
References: <9ec6b2e4-36a7-87e6-59fa-828855235835@ericsson.com>
From: Robert Wilton 
Message-ID: <53c34593-7749-a257-b7ea-1fce99acf844@cisco.com>
Date: Fri, 15 Sep 2017 12:07:22 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <9ec6b2e4-36a7-87e6-59fa-828855235835@ericsson.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Comments on NMDA-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 11:07:26 -0000

Hi Balazs,

I also wanted to comment on validation.  Please see inline below ...

On 14/09/2017 15:04, Balazs Lengyel wrote:
> Hello,
>
> Reading the draft-ietf-netmod-revised-datastores-04 some comments:
>
> General) The system often adds data to the  or  
> datastore already not just to : e.g.
>
> UC1: I have a server configured in running. I need to bind it to an 
> ip-address. The ip-address might be the local loopback address, 
> however if that is only added to the , validation will 
> fail indicating that the server is bound to a non-existent address. 
> How to handle this?
>
> UC2: I have a set of capabilities set by the system e.g. 
> supported-reporting-intervals. I need to configure a job that MUST use 
> one of these intervals. If the supported-reporting-intervals are only 
> added to  I can not validate the selected-interval in my 
> configured job.
>
> My proposal is to allow the system to add data to running as well. 
> Actually I think that is a more relevant case then adding 
> configuration just to .
>
> CH 4.4.)  "Validation is performed on  the contents of ." 
> This to me means that default data is not considered at validation 
> which would be a backwards incompatible change. Also if validation 
> does not consider system configured data that would allow cases like 
> multiple interfaces named lo0. One from  one from system 
> configuration. IMHO while it is OK to violate uniqueness because of 
> remnant data, the above violation of uniqueness seems a bad idea.
When we have been previously discussed this as part of the design team, 
we wanted the invariant that / should not be able to 
become invalid due to an external change in the system (e.g. a linecard 
is removed or changed, or the device has run out of some resource).  I 
think that the corollary to this is that when the existing NETCONF 
validation is performed, the validation must not take into account 
anything specific to the device that could change due to some external 
event (e.g. linecard is changed etc).  So this means that a valid 
configuration just represents what could be applied to the device, if 
enough resources were available, and the correct types of linecards had 
been populated and were working, etc.

But often, clients want more than this.  They don't want to just know 
whether the configuration could theoretically work, but actually want to 
know whether the device anticipates that it will be able to enact the 
configuration successfully.  So, I think that NETCONF actually also 
needs a separate "should apply ok" extension RPC.  This "should apply 
ok" RPC would do everything that validate does today, but can also do 
many more checks to try and ensure that the configuration change is 
likely to be successful applied to  (e.g. check that the 
necessary hardware is present and working, licenses have been enabled, 
resources are available, etc).  Obviously, this "should apply ok" 
invariant would not necessarily always hold for the configuration 
datastores.  An engineer may pull out a linecard that means that 
configuration currently in / is valid (as is required 
in RFC 7950), but would not be applied successfully due to the missing 
hardware.

But I also think that this is beyond the scope of the current NMDA 
architecture, but perhaps something that could be specified by a 
separate draft, if others also think that this would be useful to 
standardize?

Thanks,
Rob


>
> Ch. 4.7) Is it allowed to violate uniqueness of key values? IMHO it 
> should not be.
>
> Ch 5.1) IMHO actions and rpcs should be allowed to include other 
> datastores in their XPath evaluation. My suggestion is that they need 
> to specify it somehow. (Yang extension?)
>
> UC1) I want to define a convinience action that allows me to do a big 
> modification in  in one step. I wan't to validate what it is 
> doing based on the current contents of running. E.g. configure the OAM 
> settings for the system including SNMP/Netconf/FTP in one step, but 
> for each step I need to check that I am putting the relevant server on 
> an existing interface.
> If specifying the datastore is an overkill, I would still rather chose 
> runing as the accessible datastore. XPath is mostly use for checks. 
> Checks are done against configuration.
>
> Appendix B)
>
> "4. How applied     : automatic"    This is definitely not enough to 
> understand what happens even as an example. I propose:
> Changes are automatically propagated to 
>
> C.1)  During the example the
>     2001:db8::10
>      32
> is changed to 64 its. Is that intentional? It is not mentioned in the 
> text.
>
> regards Balazs
>
>


From nobody Fri Sep 15 04:21:32 2017
Return-Path: 
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 1680A1331BA; Fri, 15 Sep 2017 04:21:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.91
X-Spam-Level: 
X-Spam-Status: No, score=-2.91 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 TSwmO0MEvwKp; Fri, 15 Sep 2017 04:21:27 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0109.outbound.protection.outlook.com [104.47.1.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE72E13318C; Fri, 15 Sep 2017 04:21:26 -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=WBk/SmNS8ES2Mkys2Sqf5SDVgG7Vx7U0NTx3tYQzDnw=; b=D1216GLHcmYvbN4rgFqyin5dBbYRsIc/FZ3kJXnIgZdyZSLKRUTA8m5PFV7GCcwmNz/g4F1Qe9JR+chm/Xm+2hpE2vFCJmOJrpk5vt+QmCf2fkb/VP2OHzbgfBhkLvM8WqSR/H15yzlC4LoJ0cbd6JyV5Yotp+1IG0fJH5NxwkI=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (86.185.245.5) by DB6PR0701MB2998.eurprd07.prod.outlook.com (2603:10a6:4:73::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Fri, 15 Sep 2017 11:21:24 +0000
Message-ID: <022001d32e14$8d5d4540$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Lou Berger" , "netmod WG" 
Cc: , 
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net>
Date: Fri, 15 Sep 2017 12:19:42 +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: [86.185.245.5]
X-ClientProxiedBy: AM5PR06CA0016.eurprd06.prod.outlook.com (2603:10a6:206:2::29) To DB6PR0701MB2998.eurprd07.prod.outlook.com (2603:10a6:4:73::8)
X-MS-Office365-Filtering-Correlation-Id: a46df1db-a1be-46f0-27cc-08d4fc2be68c
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB6PR0701MB2998; 
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2998; 3:8tbNSH740vVuLSJman0nsHpGKLfxht0rlR7rbZ5686RFw3f8JFflLwe2CjcuVZNY430QGrDIY4fydagUrm56kwc7ftI3Byu/89DWm+GlNJR+TUSZNFS/RwnQaE8AzfoJhZYyqlO2kvtfq6TwJgEAb+oooOaSdGX/8LWcWTQUS5PQzjvkSVeO4e0st0v2cVqXhHCosI3a0iDDqLazqoXWXOvhFRYux+G8EI01I1APi6WunejNwNEqjk228qf5+C0t; 25:kQuMK/t9JAS6W7PPoLAbWCyVbJm3HklJbKPucjkohY+MPcepZG32Ku5nnqjwj/yY16E1AwDBbKW+SUIjWRa9CUndg+D/y2ybt9x8aDEeKj5f6kagchBO7s9wlC1cpG7qs1B3gI7LwQeEQ9Oi08A0dYAFkxBH65y7/nab5AQKy5EydK129L/+gAdavTX58ORYijM3m/je8YiWfSyYFnUmuvQWR1WRZJ3u9YTxFD/FD7dZ6PBVAf0ihHF48oHCx+kMRc4rP8bkA+GMZufMyQwl7cooOx7Yv2sRIQZ59nFxSkMKhIA+nXgd/5zGJufzu8uIlrjl/3lL1DOipBB2wHm1Ig==; 31:pmInZdfcd0QHWohM1V6WjD6hX40scDuqepyUDfBbMvTCZ8wsgtCMxKB/JjyJKL7zePe8+0O+JH0T3L6vSN+rZL/8ywgPEZwiVnHL5C3u2sbJD2+TT7T6t9ABxEnRILTLhJn44OFVbNRuZaeferImb19nvezNpneGy9AUgAjLFGhaXFcqzhgQlqX3T9DOtLHvJsbfUr+sum0mPfXUw3XHkeZPruNeDt2P+Fyf+dtBZ+M=
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DB6PR0701MB2998:
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2998; 20:Yi00fYekbdWEg41s9Ftd1plEyg4m8OCCHU/CaYeybYJ+RN0/EdYYGtLo2jLTuw1Tr58rolKMiQsTZx/Nlw6oyfBabkin4Eq+eMJRJVVE9UQCrpXojuqcRj5tJf86R5RGoOsptJ1h7TI1vnrpCECtxByFSPvEDZTPwuOvFbvrWuKoXNKMY4A/V6eOrGa6Kwc/YlItOIWtBON/x7rWYek9tVvjxPCyLr8DE/O70mrBzLw0BaxSJO/7IPjT21yOOSWs; 4:3vUFFw018ssmJ6+EmdWYGcqJjxL0wbiWgKILHQNva6UXQflYMjzcdNxLGAzbpHGl2FaZtlfE8o+OZmhyWRvgnwTc9KhN6xusohqHq9iEV7SgvtLFmvTYlZUhTi/jp8fTC+rxrFYm2KcvycN1tU5PHjdP1TzTEy0sXOZb+hkmO1rPdUmOralOwrBtbLBkrUuESx2QnspdTvfC8keODxkhLs59IAk7WCY/u+Zs1TG7+uhIUsISI5h5ou5Ml+Oiazy1
X-Exchange-Antispam-Report-Test: UriScan:;
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(61426038)(61427038)(6041248)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB6PR0701MB2998; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB6PR0701MB2998; 
X-Forefront-PRVS: 0431F981D8
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(39860400002)(376002)(199003)(189002)(51444003)(13464003)(377454003)(966005)(189998001)(5660300001)(44716002)(62236002)(47776003)(61296003)(4326008)(230783001)(229853002)(4720700003)(6666003)(50466002)(116806002)(33646002)(53936002)(97736004)(478600001)(1556002)(7736002)(316002)(230700001)(6486002)(305945005)(1456003)(44736005)(86362001)(84392002)(9686003)(106356001)(25786009)(54906002)(6306002)(6246003)(105586002)(8676002)(50226002)(6116002)(3846002)(14496001)(6496005)(8936002)(81166006)(50986999)(81156014)(23756003)(81686999)(76176999)(68736007)(2906002)(101416001)(81816999)(15650500001)(66066001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2998; 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; DB6PR0701MB2998; 23:sEkpzKk7HfxLXnqbPBd54rRMaKc8x/bM9/sHF?= =?iso-8859-1?Q?WYv3F9z6VYuhD1BYf+rFn/X82+Fy6W4DeiYtOT2fVT6yLCtSVkHkGXNaVZ?= =?iso-8859-1?Q?tI3phMyUEKkzDJACbZcr/LkzQxGRPisDnXI21mqbNRNakU9VVSeqiV7Xzh?= =?iso-8859-1?Q?sWukg7JEkZ9URnq2723mJRvBj3eiqwdjqULbniepV5BRO/voejp+8YzNhX?= =?iso-8859-1?Q?YbJjXDro1DlJCe0NbOBZGyhbwushaFLpyssfOTlEe+aN3Af9zUDQo8p7fO?= =?iso-8859-1?Q?hIt1ggTqPJljSwJmlgHiF8Vwoud8YCRXWJLdyg+t8LYqBczRimtNaKBbuk?= =?iso-8859-1?Q?bbQw2lfCVU4lEhjemcKId0IQJXbGcfl8a5AogkPzDg3tOhcTrg0vrnvaRm?= =?iso-8859-1?Q?mB6Ujux8ZoRBbBt8XcCMsNNRfhmpj1+If/65/S3THQMNV+/BK907WLDYVL?= =?iso-8859-1?Q?gXS/BcThQ717WCKoYVlaFOIqDNhWOH63Gcj5983T7fOdUT1mXPVX/vqHJm?= =?iso-8859-1?Q?8EF/tKEx6WRuU1ik+auKr6VS2DiwRVjCrw2wTonBurztv3I+PRyEk6oTSs?= =?iso-8859-1?Q?DZ8eyKSSENqgJ8sNJ0d1xpPa9+guPyWxId93uyCjUiL6rRf4aWIyeLTZqc?= =?iso-8859-1?Q?RkVKBFyNC093LuzbobwfQQO0LUUq8fwgxk+pHnb3V/7u787WXUfjax92vA?= =?iso-8859-1?Q?IAsZPSnyi1qyA5dcVePVt/+r91Tce97V+FBdvCFmDSMgw3BNRrLjYozB34?= =?iso-8859-1?Q?L1i7N6izDDy8uRziFtNxerkcE0x+BEkrjhWPt8pYreWI4S1BGfQtilinsU?= =?iso-8859-1?Q?SUcED22PpAQtx15eBFuc4TmBEKmC03NcFu47QO8A2Uk+yplx6I5h0tp5ZC?= =?iso-8859-1?Q?7IdJ4QJEO8FLxo+c0tlt3aPUtZg58rnrfEX/Mcu2RHzjXnm3cDyoesrgxF?= =?iso-8859-1?Q?82wJRr+EBlyuj+qPVdRNeH26hFqsY7WB9QbIKjCNeCgdT6371vmfGvVE/d?= =?iso-8859-1?Q?7ao1tMDLBbOPfxv/kysxMG6yWgDzZa/yY3RrRyqaPTw0yIsvSlm6nkgSHo?= =?iso-8859-1?Q?eSqOV0mC4/9piSiQPIfRoW9MQXZUFKyM7XjaKR9qIsFHGUsCQDAGpV5Khc?= =?iso-8859-1?Q?7WDUWAdzloMq46mfhV0pRP5w/bG7qWbBeTvSqyv7aZnwsnD8YjbERDdurL?= =?iso-8859-1?Q?iZW1IqehtK4bCwO6WVsA5V2M+wFMDXp+X+n6Pm+YINmZ7XYsQ1hBGLVeOV?= =?iso-8859-1?Q?D1M1SUdoNe4EvBDtR2PYagnKKDASSPerSVyed0TU1hqbJd1Vur32cC0TDe?= =?iso-8859-1?Q?+QlTtj6aNGtp6j7AMB9x0s/szGFNEs0OP557fdLxGFMl8IO/ij2NxiW61l?= =?iso-8859-1?Q?PqYp8mlFble6A30M7ktz6vRp6MbypHD1+S2ajZ64+bp8Q+ZsMpObyS8Sfu?= =?iso-8859-1?Q?CuX0ImJL6JaNR65tnsKl0tSxCof2UnQ+3DX0k67Tn8oNL2nbSL7G/IPuiA?= =?iso-8859-1?Q?Id6a8xOVDBTLDNFhj8nuYoRsDyLZWw4CWM763Pu5RIAPnDiNtiqO8ZzhIW?= =?iso-8859-1?Q?X8d3TPA=3D=3D?=
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2998; 6:b+dlvSMwnywtoFg3thdNXMcqMzv0UElk2z25s5unFSKS3sPA0hULFM+FbYCflVuDdCwUIIQwS+oilvM6Ck6+a+mWlQbFr7H/UYG9BB8guo2wHcOpJDX38yMDPvVB3Htdblj6bIIBcGItcovAQmym09kj1ectTBt5Eub5LsFRBBz+BfaGISPqRSFkV9l6yo+/C1JgqJeF/4w+an/2yrWwZL3IxBw85xrSWo2OItBKgNXPjhUT80V3xWu8SQPnGZOQOEeeog9/uef/47QWeYztPfV6ibubjqqoozBtmJZH8jX0hUJHOQrApdfVHiGLAs1s8WvIQTNPL1MFYl2V4Lcthw==; 5:Mk9zhMWQnft999UNFKRL49f5MMYYcKzAcpR2ZCg4pDc2905qmGQuEkAItpjbsK14Ek8Yj3L+DSWm9Fk2PxIHelYkSjNwRDrBvmJ29FO0C9byqqjxwSxV6VYWhSJ5W34PAFX4MJUT4iAIqGh2V2sr7w==; 24:KFjts/5fvqgbpmaSLQxknbney0OH8taoag1k4XXK1REPfChaSKsDywdujMVSrE2+cGRZXbES3iCDUgcLQKaY4OxUltGjC+Ex1dWCG1LJZHA=; 7:XK4Yf3wEa4Zm/qiap6etwjqmEQmFb4CPxvzl12i5qXcmnE0rgWMEi68KNdVsvCj5HJXMEOkM0xrN/YVF6PNB/D/U8EsQPKFmMbKrRy+VT/0aPT79muH3rdmmmDBfbPsFkQyKU0o4+rkwQzDb9bz9E0q7ITiVNKJWav930LLEoNqajgL+CiZCAoS0e3vmpLzTZO6/Fttr82xR1U2I3KsPGzZ1nklMHHdPFrhu+yWX5A8=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Sep 2017 11:21:24.3758 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2998
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 updates
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 11:21:30 -0000

This I-D updates RFC7950, since it changes the XPath context that YANG
uses, yet there is no mention of 'Updates'

Well, a purist will say that people can create and use  models using
RFC7950 with no need to have any understanding of this I-D so
technically no 'Updates' is needed.

But a practical engineer will say that the expectation is that many, if
not most, future models will rely on this I-D and its updates to RFC7950
so to say that you do not need to know about it is just misleading.

I am in the latter camp.

I thought of alternatives.  It is true that new models will have a
Normative Reference to this I-D but I suspect that that will not be
enough to alert users.

RFC6087bis could mention it but that is aimed at producers rather than
consumers who are the ones affected.

So. pragmatically, I think that this I-D needs an 'Updates'.

Tom Petch

----- Original Message -----
From: "Lou Berger" 
To: "netmod WG" 
Cc: ;

Sent: Friday, September 01, 2017 10:02 PM
Subject: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04


> All,
>
> This starts a two week working group last call on
> draft-ietf-netmod-revised-datastores-04.
>
> The working group last call ends on September 17.
> Please send your comments to the netmod mailing list.
>
> Positive comments, e.g., "I've reviewed this document and
> believe it is ready for publication", are welcome!
> This is useful and important, even from authors.
>
> Thank you,
> Netmod Chairs
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Fri Sep 15 04:39:26 2017
Return-Path: 
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 E5ADE13301C for ; Fri, 15 Sep 2017 04:39:24 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHLaFxBRRuFd for ; Fri, 15 Sep 2017 04:39:23 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2285C13217D for ; Fri, 15 Sep 2017 04:39:23 -0700 (PDT)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 75BEF1AE00A0; Fri, 15 Sep 2017 13:39:21 +0200 (CEST)
Date: Fri, 15 Sep 2017 13:40:07 +0200 (CEST)
Message-Id: <20170915.134007.262763963470255554.mbj@tail-f.com>
To: rwilton@cisco.com
Cc: lhotka@nic.cz, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <5b512435-cebd-3534-eeb3-649154450d81@cisco.com>
References:  <1505470900.18681.0.camel@nic.cz> <5b512435-cebd-3534-eeb3-649154450d81@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 11:39:25 -0000

Um9iZXJ0IFdpbHRvbiA8cndpbHRvbkBjaXNjby5jb20+IHdyb3RlOg0KPiANCj4gDQo+IE9uIDE1
LzA5LzIwMTcgMTE6MjEsIExhZGlzbGF2IExob3RrYSB3cm90ZToNCj4gPiBBbmR5IEJpZXJtYW4g
cMOtxaFlIHYgxIx0IDE0LiAwOS4gMjAxNyB2IDA4OjQzIC0wNzAwOg0KPiA+PiBIaSwNCj4gPj4N
Cj4gPj4NCj4gPj4gQWN0dWFsbHkgSSBsaWtlZCB0aGUgZWFybHkgcHlhbmcgb3V0cHV0IHRoYXQg
d2FzIGNvbmNpc2UgYW5kIGVhc3kgdG8NCj4gPj4gcmVtZW1iZXIuDQo+ID4+IFRoZSBjdXJyZW50
IGZvcm1hdCBnZXRzIHZlcnkgY2x1dHRlcmVkIGFuZCB0aGVyZSBhcmUgdG9vIG1hbnkgbGl0dGxl
DQo+ID4+IHN5bWJvbHMNCj4gPj4gdG8gcmVtZW1iZXIgdGhlbSBhbGwuDQo+ID4gSSBhZ3JlZS4N
Cg0KTWUgdG9vLiAgVGhlIGN1cnJlbnQgZHJhZnQgYWRkcyB0aHJlZSBuZXcgbWFnaWMgc3ltYm9s
czogIm1wIiAiQCIgYW5kDQoiLyIuDQoNCiJtcCIgaXMgZm9yIGEgbW91bnQgcG9pbnQsIGFuZCBp
dCBjYW4gYmUgZ2VuZXJhdGVkIGRpcmVjdGx5IGZyb20gdGhlDQpZQU5HIG1vZHVsZXMuDQoNCkRp
cmVjdGx5IHVuZGVyIGEgIm1wIiwgIi8iIGFuZCAiQCIgYXJlIHVzZWQgdG8gaW5kaWNhdGUgdGhh
dCBhIG5vZGUgaXMgbW91bnRlZA0Kb3IgYXZhaWxhYmxlIHRocm91Z2ggYSBwYXJlbnQgcmVmZXJl
bmNlLCByZXNwZWN0aXZlbHkuDQoNCkkgYWN0dWFsbHkgcXVlc3Rpb24gdGhlIHVzYWJpbGl0eSBv
ZiAiLyIgYW5kICJAIi4gIFNpbmNlIGEgcGFyZW50DQpyZWZlcmVuY2UgY2FuIGJlIHZlcnkgc3Bl
Y2lmaWMsIGUuZy4gb25lIHNwZWNpZmljIGludGVyZmFjZSwgaXQgaXNuJ3QNCnJlYWxseSBhY2N1
cmF0ZSB0byBzaG93Og0KDQogICAgICAgICAgICAgICAgICArLS1tcCB2cmYtcm9vdA0KICAgICAg
ICAgICAgICAgICAgICAgKy0tcncgcnQ6cm91dGluZy8NCiAgICAgICAgICAgICAgICAgICAgIHwg
IC4uLg0KICAgICAgICAgICAgICAgICAgICAgKy0tcm8gaWY6aW50ZXJmYWNlc0ANCg0KQW5kIHRo
ZSB0cmFpbGluZyAiLyIgb24gcnQ6cm91dGluZyBkb2Vzbid0IGFkZCBhbnkgaW5mb3JtYXRpb24g
d2UNCmRvbid0IGFscmVhZHkga25vdy4gIFNpbmNlIHZyZi1yb290IGlzIGEgbW91bnQgcG9pbnQs
IGl0IGZvbGxvd3MgdGhhdA0KaXRzIGNoaWxkcmVuIGFyZSBtb3VudGVkLg0KDQpBbHNvLCB3aGF0
IGlzIG1vdW50ZWQgdW5kZXIgYSBtb3VudCBwb2ludCBpcyBub3QgZGVmaW5lZCBpbiB0aGUNCnNj
aGVtYSwgc28gYSB0b29sIGNhbm5vdCBnZW5lcmF0ZSB0aGlzIGZyb20gdGhlIFlBTkcgbW9kdWxl
cy4NCg0KDQpTbyBtYXliZSB3ZSBzaG91bGQgcmVtb3ZlICIvIiBhbmQgIkAiLCBhbmQganVzdCBr
ZWVwICJtcCIuDQoNCj4gSSBkZWZpbml0ZWx5IHRoaW5rIHRoYXQgIngiIGlzIGEgYml0IGNvbmZ1
c2luZyBzaW5jZSBpdCBib3RoIG1lYW5zDQo+ICJSUEMiIGFuZCBhbHNvICJzdGF0dXMgZGVwcmVj
YXRlZCIgZGVwZW5kaW5nIG9uIHdoZXJlIGl0IGlzLg0KDQpQb3NzaWJseS4gICJ4IiBmb3IgImRl
cHJlY2F0ZWQiIGNvbWVzIGZyb20gc21pZHVtcC4gICJ4IiBmb3IgImV4ZWN1dGUiDQoocnd4KSBp
cyBvZiBjb3Vyc2UgY29tbW9uLiAgU28gaWYgd2Ugc2hvdWxkIGNoYW5nZSBzb21ldGhpbmcgaXQg
aXMNCnByb2JhYmx5ICJ4IiBmb3IgImRlcHJlY2F0ZWQiLiAgQnV0ICJ4IiBsb29rcyBiZXR0ZXIg
dGhhbiAiZCIuLi4NCg0KDQovbWFydGluDQoNCg0KDQo+IA0KPiBUaGFua3MsDQo+IFJvYg0KPiAN
Cj4gDQo+ID4NCj4gPiBMYWRhDQo+ID4NCj4gPj4NCj4gPj4gQW5keQ0KPiA+Pg0KPiA+Pg0KPiA+
PiBPbiBUaHUsIFNlcCAxNCwgMjAxNyBhdCA4OjMzIEFNLCBKb2UgQ2xhcmtlIDxqY2xhcmtlQGNp
c2NvLmNvbT4gd3JvdGU6DQo+ID4+PiBJJ3ZlIGJlZW4gaGFja2luZyBvbiBweWFuZywgYW5kIEkg
Y2hhbmdlZCB0cmVlLnB5IHRvIGFkZCB0aGUgZW51bQ0KPiA+Pj4gdmFsdWVzDQo+ID4+PiBmb3Ig
ZW51bWVyYXRpb24gdHlwZXMgYW5kIGlkZW50aXlyZWYgYmFzZXMgZm9yIGlkZW50aXR5cmVmIHR5
cGVzLg0KPiA+Pj4gSGVyZQ0KPiA+Pj4gaXMgYW4gZXhhbXBsZToNCj4gPj4+DQo+ID4+PiBtb2R1
bGU6IHlhbmctY2F0YWxvZw0KPiA+Pj4gICAgICArLS1ydyBjYXRhbG9nDQo+ID4+PiAgICAgICAg
ICstLXJ3IG1vZHVsZXMNCj4gPj4+ICAgICAgICAgfCAgKy0tcncgbW9kdWxlKiBbbmFtZSByZXZp
c2lvbiBvcmdhbml6YXRpb25dDQo+ID4+PiAgICAgICAgIHwgICAgICstLXJ3IG5hbWUgICAgICAg
ICAgICAgICAgICAgICB5YW5nOnlhbmctaWRlbnRpZmllcg0KPiA+Pj4gICAgICAgICB8ICAgICAr
LS1ydyByZXZpc2lvbiAgICAgICAgICAgICAgICAgdW5pb24NCj4gPj4+ICAgICAgICAgfCAgICAg
Ky0tcncgb3JnYW5pemF0aW9uICAgICAgICAgICAgIHN0cmluZw0KPiA+Pj4gICAgICAgICB8ICAg
ICArLS1ydyBpZXRmDQo+ID4+PiAgICAgICAgIHwgICAgIHwgICstLXJ3IGlldGYtd2c/ICAgc3Ry
aW5nDQo+ID4+PiAgICAgICAgIHwgICAgICstLXJ3IG5hbWVzcGFjZSAgICAgICAgICAgICAgICBp
bmV0OnVyaQ0KPiA+Pj4gICAgICAgICB8ICAgICArLS1ydyBzY2hlbWE/ICAgICAgICAgICAgICAg
ICAgaW5ldDp1cmkNCj4gPj4+ICAgICAgICAgfCAgICAgKy0tcncgZ2VuZXJhdGVkLWZyb20/ICAg
ICAgICAgIGVudW1lcmF0aW9uIFttaWIsIGNvZGUsDQo+ID4+PiBub3QtYXBwbGljYWJsZSwgbmF0
aXZlXQ0KPiA+Pj4gICAgICAgICB8ICAgICArLS1ydyBtYXR1cml0eS1sZXZlbD8gICAgICAgICAg
ZW51bWVyYXRpb24gW3JhdGlmaWVkLA0KPiA+Pj4gYWRvcHRlZCwgaW5pdGlhbCwgbm90LWFwcGxp
Y2FibGVdDQo+ID4+PiAuLi4NCj4gPj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Ky0tcncgcHJvdG9jb2xzDQo+ID4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg
ICstLXJ3IHByb3RvY29sKiBbbmFtZV0NCj4gPj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgfCAgICAgKy0tcncgbmFtZQ0KPiA+Pj4gaWRlbnRpdHlyZWYgLT4gcHJvdG9jb2wNCj4g
Pj4+IC4uLg0KPiA+Pj4NCj4gPj4+IE15IHF1ZXN0aW9ucyBhcmU6DQo+ID4+Pg0KPiA+Pj4gMS4g
SXMgdGhpcyB1c2VmdWw/DQo+ID4+Pg0KPiA+Pj4gMi4gSWYgc28sIGNhbiB0aGlzIGJlIGFkZGVk
IHRvIHB5YW5nIChoYXBweSB0byBzdWJtaXQgYSBQUikgYW5kDQo+ID4+PiBkcmFmdC1pZXRmLW5l
dG1vZC15YW5nLXRyZWUtZGlhZ3JhbXM/DQo+ID4+Pg0KPiA+Pj4gMy4gV2hhdCBjaGFuZ2VzIHRv
IHRoZSBvdXRwdXQgZm9ybWF0IHdvdWxkIHlvdSByZWNvbW1lbmQ/DQo+ID4+Pg0KPiA+Pj4gVGhh
bmtzLg0KPiA+Pj4NCj4gPj4+IEpvZQ0KPiA+Pj4NCj4gPj4+IF9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+
ID4+PiBuZXRtb2RAaWV0Zi5vcmcNCj4gPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vbmV0bW9kDQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQo+ID4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPj4gbmV0bW9kQGlldGYu
b3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+
IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBu
ZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K


From nobody Fri Sep 15 04:45:17 2017
Return-Path: 
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 13AD5132D53; Fri, 15 Sep 2017 04:45:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.91
X-Spam-Level: 
X-Spam-Status: No, score=-2.91 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 HLJ9S9k9pd5F; Fri, 15 Sep 2017 04:45:14 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0128.outbound.protection.outlook.com [104.47.2.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A07C313217D; Fri, 15 Sep 2017 04:45:13 -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=RkMn2EqhVfSIymO2C3G+RlBkSpZF4q59Q2CHXeMji3Q=; b=W9DyguXTYC2EVfJHVBRNqS9Eq5Me9szHa4/XSf8KokRE/SsVDkysGTDaQ85aIOySTYS9GK9EaGOYUgJArRfzrqs0LPzPGoe1BTHtCRJ+j31Ux27NbOIqi3sDwIRRgCNA5b8R2RaPSstJCdrWrW+576ukBSI7QmnDXDmSCZZKcZ0=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (86.185.245.5) by AM5PR0701MB2993.eurprd07.prod.outlook.com (2603:10a6:203:48::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Fri, 15 Sep 2017 11:45:11 +0000
Message-ID: <022e01d32e17$dfd54d60$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Lou Berger" , "netmod WG" 
Cc: , 
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net>
Date: Fri, 15 Sep 2017 12:29:01 +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: [86.185.245.5]
X-ClientProxiedBy: AM5PR06CA0013.eurprd06.prod.outlook.com (2603:10a6:206:2::26) To AM5PR0701MB2993.eurprd07.prod.outlook.com (2603:10a6:203:48::15)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: e76b87b4-ce55-4230-b3e0-08d4fc2f38f6
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM5PR0701MB2993; 
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 3:SzQb9LI7QnKSP3wdwgeyvG4tNDNmhEaMhcDxMGA2MYWkeQdZAhr+hSXIo1S1sq2Vx1NRIA7I61mnYv9nNIXFWWv+jehUgIPohJqFPm/mFZaJeCm2JSQ00naX0KrOJUn7Ly6R9V+iv3lGJJfAKV/d3KWZBMrCw8A4OvAeMNisa/x2vFDJ0AxtG5bxeF70w/W6I6w9nSet/55jpGR4jj0jG2CPsdW2bQLDNPex5dtDNFGkTSxnIlhfOL16lsIeun6p; 25:CHRjm7ad2HOBYEndpeNvM3MoQuL8T0Fvk8HGfwSN12XgFAF+U3kXhVkB6M8gSBxMfv2g+EDAe/auF47arKQONorT65jesb22vjOVUaQ8DzTOAZbpa4ge6NledWx1y52PNBbUZXwOVHmtFJwYxAuvw3RWLqfCGu0On9vjQ0b6sSxDhGl161GYaayvXXJs31ZwJgK+r9TeIVp89P7OWnhpvYfaI5DlNvnQQBWYB/dc4zfcQat+IgSvtv4s3aYGlKesacmUhsqfDbQXob3VfyrNvjEF8ZF1J2Abwty7HayXLLF7lcvc7fmHHY/x75QsXFCZQwdtp61P12nrIk2ow1sgmQ==; 31:DrWwzIJKIrE6wsVCvWUb9xZZvu/+/JCAUPezgRHIAlYDC9AOdQHljbR0GUqpS86m+nNM3Z9EYO+xHizW6zpTBe+IvGSUamtjtuYMFsl2+nFNkedwTnui/wsNvPTJ52XO2/aefZidPxcXpZQz5joDCXZSzcVNSptTulcyuf03Tk2AhR9NM36uY6uX8P/F1c5OP9nNa5NEZvuxVOy6lATFnWXnOQSQUtlEk9dcsJianI4=
X-MS-TrafficTypeDiagnostic: AM5PR0701MB2993:
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 20:rN7gjtNabwXz9dygal8KXw5/34BdN7TV/U9Yj/KXrGBWIlNAJRKi7ZpM2vTIDzHnKqF5KkHrGKoFVKgCA6uynSx3C8Vn4nUx4HZe91BYTRzZWSovUGAjIZhwXkPmMC+BJRMBAPKDhWpSufPA3Yf8Q5tNEHVgZy/2FQcGNIwp17QkJjg0xybyd95Ho6C2Ha2LTQ9D3KYrr6wGg/RdeVeglsv8BaEbbOsqj3Vg3LBhUpEWSb1ETp0Og1MDWoi3XyLk; 4:roS1pOZJkGuxp9oDieXH9nREbWpdNgKaPgm1RTm+XcfhlX48VfTdou68rU448wYRtnYGeXIh9W0f+H+6cd2VTW/Jb7qxEjds9BxmFLjozVfFX5oDeJTl8AaKKLfOEahLxHhQuKDKq1QZfpRu31umEnh0A2FWfe45PAOT4Z3UeJ8va6MTSYYMJHHD5uf33AedNcW+phjBQXnifRJrkYgjxDNOgP5xHjum/F6QsnhI7+3v4IjFxIDwZvsmq6ottHg3
X-Exchange-Antispam-Report-Test: UriScan:;
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(61426038)(61427038)(6041248)(20161123562025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2993; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2993; 
X-Forefront-PRVS: 0431F981D8
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(346002)(39860400002)(376002)(51444003)(377454003)(13464003)(199003)(189002)(316002)(230783001)(1556002)(50466002)(50986999)(23756003)(6246003)(50226002)(86362001)(6496005)(7736002)(4326008)(47776003)(2906002)(61296003)(33646002)(478600001)(97736004)(84392002)(116806002)(81686999)(44716002)(81816999)(62236002)(189998001)(305945005)(76176999)(81166006)(6666003)(25786009)(44736005)(966005)(229853002)(101416001)(1456003)(106356001)(230700001)(4720700003)(68736007)(53936002)(14496001)(6486002)(5660300001)(6116002)(8936002)(3846002)(54906002)(6306002)(8676002)(105586002)(81156014)(9686003)(66066001)(74416001)(7726001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2993; 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; AM5PR0701MB2993; 23:orddfSRyglVDA3r0BT6zJ2ROHFVrMaK59GAAC?= =?iso-8859-1?Q?GiXDaQWO0MuKh8OBpTECOut7maxnYO7w+KD9TNmdKp5fsXeKwB+v/4hKX6?= =?iso-8859-1?Q?JCXo7ZwSMTZwnnCHGp7u61c5R/oxmNxDo4gqCIOXg+hIKYwtSr540IR8vH?= =?iso-8859-1?Q?8AhUP8AUZ02nE4n6+X4E77ZoGfy4wJiqJYJJre5+1/uS5ZyxXJGAmZRzqt?= =?iso-8859-1?Q?tgyL4mcOg7kjJ+pvCfzEAS6jVn62kLxSTYuyVx9EH5KoT/EOEqXFobS9oL?= =?iso-8859-1?Q?5VUpz/W26+3+cMZvvmM2CdmhzW6EJm50Ox1LhRlcGuvHK0Bb/12lqJcsTb?= =?iso-8859-1?Q?onFnNM/Ta2tfVFhp4Yq3RbG77ZKyE8S5cXgI3MNYyxhn/I1oxMJCRYXygI?= =?iso-8859-1?Q?0Dwf4dEjiUJzG04WDKtbVXjHlOaprDtWWI2850pb/rbLSdvSGVfngV3rhn?= =?iso-8859-1?Q?WUES1vXaElm0p59hWLI7GWUyWgErxutfDdzNkR/SHso+pkHIci8kt9hGfO?= =?iso-8859-1?Q?8vFd9a9JRploIPMdLmoQ0JIU2oaC9qJnNoeFN8p4rpKUZAibk1hbetBVJ2?= =?iso-8859-1?Q?q4rKVo2Osi9VSfO0jp+zaaZ7IMOmn6uucmPc3WBcj5kxSzmUgnqxn08QUf?= =?iso-8859-1?Q?BY8NjOqE9v2BZFPI8Ag3deL1MrfZ9RcqFM8Gkr0AgZv6bXwAUXTEMNKlny?= =?iso-8859-1?Q?soGyz0OXdUgL7Gg28IPqJ9afw7K9sZ2lQBVrqriz55ndp+icexP86QrQ0l?= =?iso-8859-1?Q?8EVhfwM18h8QBJZCzQdBntRSuvt5geGCNYdFlhD/Yqc0vuBn2MWPsxZqq3?= =?iso-8859-1?Q?aT1CwLgulOeLJhFnTDhqw8Vg765COTBhimUEOYvPKc6GTOT7uH0y1uCz2I?= =?iso-8859-1?Q?ntfDu0v/RWl8W3hMghBd2nCyaFO2Q3yQXIfjuhz5pdLdk13X1FDjTRCZlQ?= =?iso-8859-1?Q?qMJLLVbWN6j7nuJdx+r32FiAgXLGKMDB5fTzFSTCip6GDxHLlKlFzsuA47?= =?iso-8859-1?Q?iTMcc4zr3U4HLQhOMuAxYOz8oLcxtIck9AUr9/2pg0n+BSWQ+o8OF/YUTw?= =?iso-8859-1?Q?wYMScjju4FpctbeUvMFzDIq/SEKPqS8nhFg1Jh7aeGlpKlDPiNRIvuECB+?= =?iso-8859-1?Q?SUhgbWHZriXJNt1p06QEsNp6XJtWzf0QBx7zXMLV85eNmjnA7qlTPHpakQ?= =?iso-8859-1?Q?25NMPMz7/WNjHAEmfsAlG1vNu229larhqn6kEJGzxj4sSl/eGtn5+UP2Sz?= =?iso-8859-1?Q?JWnbMGRf8OdWVdlC9MiW56/ZNQqCiPQ6ctd1E4o76Z76HAQYZAXurgAPg3?= =?iso-8859-1?Q?YXDETTfBJKcqBHCsWqGmiO5WuJ3TBuGPqELofN/WCrQFAJRyPpJpAVvJO9?= =?iso-8859-1?Q?hDwNPicrchl2gg0mTB+nuQ9HBluW5LKFtN6z7A5o+gABrD622GryLlPDBf?= =?iso-8859-1?Q?E+oRgPE6Nuu55Jp5wX9YnajWY1k0CHgcxwVJJcEwOTFpwfiYcUFF5WV61P?= =?iso-8859-1?Q?QwQ+am92CpQiF0Q/Pz01IhiO/NTFT59+DmvxNDJk3bSuAgTs3hYT7cj5vA?= =?iso-8859-1?Q?diVMeZYGQJR8pwzwdrvtKtSDFlB3X7s3vbrYMJ8v+0MJidy1mZtlYFt6VK?= =?iso-8859-1?Q?ePDnMitEumlIg=3D=3D?=
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 6:K0rSXY7687wSFqpxVJ8yBI5SmjZRFFmRQReU6YkQxKBFh00h7MivJnk90oYCuaV0N2ZkCFs+QXCusR0FxDoRA+aA+qrCf2A5JA6zNpUFNnD+eY11FBx2Wahm5R6H+qJYKTPMUetL8BOCXLKXEXBwtfwTa0+GeEeHk75PGFHKaD0dXU3KgGA1zIDTPPuhvSHG/pR4Cs5ZANkWPywtB5onrL16rijyw0AsFvAOPpn6eQ1vPsVW3n95OCjLUbqWW8jGtn5mK/JhOygWcglZn65ljlw8vQ87VyFSNHklkx0nM8ES4FZhorPkGqyCYLiVe8aYj9BzRL34phPCDbuHUzUwiQ==; 5:eCVBw/dgyuUJZLy8c2fgc0uaPZa3Ijatt7ni/oPsR+QoZVG3J5gKcluspRdpYykWF5u75YkaBzUo65XOABzXWRaL4MUx9texOMsc5n9161NWJ+uorcgzyHnQbG9nJBuPcW97LR8g18MkXKef4T7pew==; 24:xqhfdkpzi1qgTv6ajgiDeyBRMTlnR3kiNO48qM0Uc3sdzL0A/8Hk+sD7f3AzMq43454eEPSCz3ZuYceazLCLqxh9nfko8JWwWNlIqzU8OAg=; 7:G+6yqXqADkyf92S8ZZeSWc1aFg2+G66akfv14TXNioKy3ql/rFj6SDFTV6c3G9s6CzZmis+/DJ1WxNm8v6LRLzo1w1wcxW7s/e4wPH6Ynn2RUoHTUrP5W/2nNA22ygguRYaS64nKDmSnRObpGNdqFN5AC8QEqi0En79kBRyLOzR4zeKtKkSdZiUuM0nheby9gxUhp1T+omWwfvIMoRZ7fPQAirmMz+R3+3vZisgeF9U=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Sep 2017 11:45:11.2624 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2993
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 guessing
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 11:45:16 -0000

Looking at a YANG module in future, how can I tell whether or not it is
written to work with revised datastores?

If the module is written assuming revised datastores and the environment
does not support this in some regard, then we have a management
malfunction, which could be disastrous.

I think that there should be some mechanistic way, something that can be
automated, for a system to check whether or not a module is assuming
revised datastores or not.  This is a bit like the change from YANG 1.0
to YANG 1.1; there needs to be a way of telling what environment the
module is written for, and so we have the

yang-version 1.1;

statement.

Revised datastores needs something similar in the module.

Tom Petch


----- Original Message -----
From: "Lou Berger" 
Sent: Friday, September 01, 2017 10:02 PM


> All,
>
> This starts a two week working group last call on
> draft-ietf-netmod-revised-datastores-04.
>
> The working group last call ends on September 17.
> Please send your comments to the netmod mailing list.
>
> Positive comments, e.g., "I've reviewed this document and
> believe it is ready for publication", are welcome!
> This is useful and important, even from authors.
>
> Thank you,
> Netmod Chairs
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Fri Sep 15 04:48:49 2017
Return-Path: 
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 4BEF9133071 for ; Fri, 15 Sep 2017 04:48:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level: 
X-Spam-Status: No, score=-6.999 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, URIBL_BLOCKED=0.001] 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 JHaYLYx05VKF for ; Fri, 15 Sep 2017 04:48:45 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 46CFB13217D for ; Fri, 15 Sep 2017 04:48:45 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 8300461282; Fri, 15 Sep 2017 13:48:43 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1505476123; bh=2z95ncU5K2zZ+HwGbDx53gOTt+wDp2/bn87O2+CYE/Q=; h=From:To:Date; b=YyQGpohxI3MH+svIX80hscARdR6cJajCALKHxQtjwzmDoFZ25NyIQadISOAv7B2Ti HAaFUG/Bf+9vdudAaJFVZMlvTDPviuWc0ucc9GN5GphTFSuD6U2hFjuBmEend65nkL zGzKi3Bv9n6h6ZyQ4lX0Jaoipm5fpL25C63HWaFI=
Message-ID: <1505476160.18681.23.camel@nic.cz>
From: Ladislav Lhotka 
To: Martin Bjorklund , rwilton@cisco.com
Cc: netmod@ietf.org
Date: Fri, 15 Sep 2017 13:49:20 +0200
In-Reply-To: <20170915.134007.262763963470255554.mbj@tail-f.com>
References:  <1505470900.18681.0.camel@nic.cz> <5b512435-cebd-3534-eeb3-649154450d81@cisco.com> <20170915.134007.262763963470255554.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.24.5 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 11:48:48 -0000

Martin Bjorklund píše v Pá 15. 09. 2017 v 13:40 +0200:
> Robert Wilton  wrote:
> > 
> 
> > 
> 
> > On 15/09/2017 11:21, Ladislav Lhotka wrote:
> 
> > > Andy Bierman píše v Čt 14. 09. 2017 v 08:43 -0700:
> 
> > >> Hi,
> 
> > >>
> 
> > >>
> 
> > >> Actually I liked the early pyang output that was concise and easy to
> 
> > >> remember.
> 
> > >> The current format gets very cluttered and there are too many little
> 
> > >> symbols
> 
> > >> to remember them all.
> 
> > > I agree.
> 
> 
> Me too.  The current draft adds three new magic symbols: "mp" "@" and
> "/".
> 
> "mp" is for a mount point, and it can be generated directly from the
> YANG modules.
> 
> Directly under a "mp", "/" and "@" are used to indicate that a node is mounted
> or available through a parent reference, respectively.
> 
> I actually question the usability of "/" and "@".  Since a parent
> reference can be very specific, e.g. one specific interface, it isn't
> really accurate to show:

Right, it is yet another example of confusing schema nodes with instances: the
tree diagram is a visualisation of the schema whereas parent references are
about concrete instances. Oh well...

Lada

> 
>                   +--mp vrf-root
>                      +--rw rt:routing/
>                      |  ...
>                      +--ro if:interfaces@
> 
> And the trailing "/" on rt:routing doesn't add any information we
> don't already know.  Since vrf-root is a mount point, it follows that
> its children are mounted.
> 
> Also, what is mounted under a mount point is not defined in the
> schema, so a tool cannot generate this from the YANG modules.
> 
> 
> So maybe we should remove "/" and "@", and just keep "mp".
> 
> > I definitely think that "x" is a bit confusing since it both means
> 
> > "RPC" and also "status deprecated" depending on where it is.
> 
> 
> Possibly.  "x" for "deprecated" comes from smidump.  "x" for "execute"
> (rwx) is of course common.  So if we should change something it is
> probably "x" for "deprecated".  But "x" looks better than "d"...
> 
> 
> /martin
> 
> 
> 
> > 
> 
> > Thanks,
> 
> > Rob
> 
> > 
> 
> > 
> 
> > >
> 
> > > Lada
> 
> > >
> 
> > >>
> 
> > >> Andy
> 
> > >>
> 
> > >>
> 
> > >> On Thu, Sep 14, 2017 at 8:33 AM, Joe Clarke  wrote:
> 
> > >>> I've been hacking on pyang, and I changed tree.py to add the enum
> 
> > >>> values
> 
> > >>> for enumeration types and identiyref bases for identityref types.
> 
> > >>> Here
> 
> > >>> is an example:
> 
> > >>>
> 
> > >>> module: yang-catalog
> 
> > >>>      +--rw catalog
> 
> > >>>         +--rw modules
> 
> > >>>         |  +--rw module* [name revision organization]
> 
> > >>>         |     +--rw name                     yang:yang-identifier
> 
> > >>>         |     +--rw revision                 union
> 
> > >>>         |     +--rw organization             string
> 
> > >>>         |     +--rw ietf
> 
> > >>>         |     |  +--rw ietf-wg?   string
> 
> > >>>         |     +--rw namespace                inet:uri
> 
> > >>>         |     +--rw schema?                  inet:uri
> 
> > >>>         |     +--rw generated-from?          enumeration [mib, code,
> 
> > >>> not-applicable, native]
> 
> > >>>         |     +--rw maturity-level?          enumeration [ratified,
> 
> > >>> adopted, initial, not-applicable]
> 
> > >>> ...
> 
> > >>>                                 +--rw protocols
> 
> > >>>                                 |  +--rw protocol* [name]
> 
> > >>>                                 |     +--rw name
> 
> > >>> identityref -> protocol
> 
> > >>> ...
> 
> > >>>
> 
> > >>> My questions are:
> 
> > >>>
> 
> > >>> 1. Is this useful?
> 
> > >>>
> 
> > >>> 2. If so, can this be added to pyang (happy to submit a PR) and
> 
> > >>> draft-ietf-netmod-yang-tree-diagrams?
> 
> > >>>
> 
> > >>> 3. What changes to the output format would you recommend?
> 
> > >>>
> 
> > >>> Thanks.
> 
> > >>>
> 
> > >>> Joe
> 
> > >>>
> 
> > >>> _______________________________________________
> 
> > >>> netmod mailing list
> 
> > >>> netmod@ietf.org
> 
> > >>> https://www.ietf.org/mailman/listinfo/netmod
> 
> > >> _______________________________________________
> 
> > >> netmod mailing list
> 
> > >> netmod@ietf.org
> 
> > >> https://www.ietf.org/mailman/listinfo/netmod
> 
> > 
> 
> > _______________________________________________
> 
> > netmod mailing list
> 
> > netmod@ietf.org
> 
> > https://www.ietf.org/mailman/listinfo/netmod
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Fri Sep 15 04:57:02 2017
Return-Path: 
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 5DF0B1331D7 for ; Fri, 15 Sep 2017 04:57:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level: 
X-Spam-Status: No, score=-6.999 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, URIBL_BLOCKED=0.001] 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 RxBubGffDciy for ; Fri, 15 Sep 2017 04:56:59 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 180F41331D2 for ; Fri, 15 Sep 2017 04:56:59 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 9B48762029 for ; Fri, 15 Sep 2017 13:56:57 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1505476617; bh=3ETyF/6aPDd/YOq3RKl1GdTV6KqLRJYDQOZv9J2724c=; h=From:To:Date; b=yE+3WizdAu0baTT41LQlyP1d57kG2X1+5Gy+JGNNXc58O4OhjxFbmj3jAzmkVvVs2 X/S94R4A2dDHXmvx7f/G0+8c4EBLkFcZ7r2JeLqQu/qP1LMxwhJTlQ8Yu+00YDnARW blxduKQptGmjWcCqKjK/n6i/Mjw7aLXik9sUXxJE=
Message-ID: <1505476654.18681.29.camel@nic.cz>
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Fri, 15 Sep 2017 13:57:34 +0200
In-Reply-To: <022e01d32e17$dfd54d60$4001a8c0@gateway.2wire.net>
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <022e01d32e17$dfd54d60$4001a8c0@gateway.2wire.net>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.24.5 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 guessing
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 11:57:00 -0000

t.petch píše v Pá 15. 09. 2017 v 12:29 +0100:
> Looking at a YANG module in future, how can I tell whether or not it is
> written to work with revised datastores?

Ideally, this ought to be a wrong question. A YANG module (or rather a YANG data
model) should specify constraints for a data tree, no matter where the tree
happens to reside.

Coupling a data modelling language with rather specific aspects of an NM
application is a bad design.

Lada 

> 
> If the module is written assuming revised datastores and the environment
> does not support this in some regard, then we have a management
> malfunction, which could be disastrous.
> 
> I think that there should be some mechanistic way, something that can be
> automated, for a system to check whether or not a module is assuming
> revised datastores or not.  This is a bit like the change from YANG 1.0
> to YANG 1.1; there needs to be a way of telling what environment the
> module is written for, and so we have the
> 
> yang-version 1.1;
> 
> statement.
> 
> Revised datastores needs something similar in the module.
> 
> Tom Petch
> 
> 
> ----- Original Message -----
> From: "Lou Berger" 
> Sent: Friday, September 01, 2017 10:02 PM
> 
> 
> > All,
> > 
> > This starts a two week working group last call on
> > draft-ietf-netmod-revised-datastores-04.
> > 
> > The working group last call ends on September 17.
> > Please send your comments to the netmod mailing list.
> > 
> > Positive comments, e.g., "I've reviewed this document and
> > believe it is ready for publication", are welcome!
> > This is useful and important, even from authors.
> > 
> > Thank you,
> > Netmod Chairs
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Fri Sep 15 05:15:58 2017
Return-Path: 
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 E60DE133207 for ; Fri, 15 Sep 2017 05:15:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWvfT5sCkaS4 for ; Fri, 15 Sep 2017 05:15:55 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6011133205 for ; Fri, 15 Sep 2017 05:15:54 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 9FCDC6A2; Fri, 15 Sep 2017 14:15:53 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id m3DwHy7rlXTS; Fri, 15 Sep 2017 14:15:51 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 15 Sep 2017 14:15:53 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7F93C200E9; Fri, 15 Sep 2017 14:15:53 +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 6lJhn6Qt_kXN; Fri, 15 Sep 2017 14:15:53 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A64B1200E8; Fri, 15 Sep 2017 14:15:52 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 80DCE40F5F16; Fri, 15 Sep 2017 14:15:52 +0200 (CEST)
Date: Fri, 15 Sep 2017 14:15:52 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Cc: rwilton@cisco.com, netmod@ietf.org
Message-ID: <20170915121552.7hjqodubjgkvvr7i@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Martin Bjorklund , rwilton@cisco.com, netmod@ietf.org
References:  <1505470900.18681.0.camel@nic.cz> <5b512435-cebd-3534-eeb3-649154450d81@cisco.com> <20170915.134007.262763963470255554.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170915.134007.262763963470255554.mbj@tail-f.com>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 12:15:57 -0000

On Fri, Sep 15, 2017 at 01:40:07PM +0200, Martin Bjorklund wrote:
> 
> Also, what is mounted under a mount point is not defined in the
> schema, so a tool cannot generate this from the YANG modules.
>

This sounds broken. Manually edited tree diagrams will be a source of
pain.
 
> > I definitely think that "x" is a bit confusing since it both means
> > "RPC" and also "status deprecated" depending on where it is.
> 
> Possibly.  "x" for "deprecated" comes from smidump.  "x" for "execute"
> (rwx) is of course common.  So if we should change something it is
> probably "x" for "deprecated".  But "x" looks better than "d"...
>

Yep, I am probably guilty for the deprecated 'x'. For obsolete,
smidump creates an 'o', so you have

        +--- foo
        x--- bar
        o--- baz

and I guess I visually liked it (and there was no execute in SNMP
land). I guess I still kind of like this. If I would start from
scratch for YANG, I would probably not use

       rw  for configuration data
       ro  for non-configuration data
       -x  for rpcs and actions
       -n  for notifications
       mp   for schema mount points

but rather single letters, e.g.

       c  for configuration data
       s  for non-configuration data
       r  for rpcs and actions
       n  for notifications
       m  for schema mount points

but this is a significant change to what we have done so far and
finding agreement on a new notation is likely difficult.

/js

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


From nobody Fri Sep 15 05:20:48 2017
Return-Path: 
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 1EEFA133200 for ; Fri, 15 Sep 2017 05:20:47 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pv-4fQJpu8JG for ; Fri, 15 Sep 2017 05:20: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 AA0461331F1 for ; Fri, 15 Sep 2017 05:20:45 -0700 (PDT)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 1BB5B1AE00A0; Fri, 15 Sep 2017 14:20:44 +0200 (CEST)
Date: Fri, 15 Sep 2017 14:21:30 +0200 (CEST)
Message-Id: <20170915.142130.250716263736500205.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <1505476654.18681.29.camel@nic.cz>
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <022e01d32e17$dfd54d60$4001a8c0@gateway.2wire.net> <1505476654.18681.29.camel@nic.cz>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 guessing
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 12:20:47 -0000

Ladislav Lhotka  wrote:
> t.petch p=ED=A8e v P=E1 15. 09. 2017 v 12:29 +0100:
> > Looking at a YANG module in future, how can I tell whether or not i=
t is
> > written to work with revised datastores?
> =

> Ideally, this ought to be a wrong question. A YANG module (or rather =
a YANG data
> model) should specify constraints for a data tree, no matter where th=
e tree
> happens to reside.

I agree, and an old module can be implemented in an NMDA-compatible
server (with some redundant info), and a new modules can be implemented=
 in a
non-NMDA-compatible server (with limited functionality).

But the truth is that modules are and will be designed to fit into
some environment (or "meta model").  For example, with NMDA, there
will be a single tree.  If we had an annotation for "comments" on
nodes, you wouldn't see any leafs called "description".  If we didn't
have the ability to create things in the protocol, our models would
have objects of type "RowStatus".  Etc.


/martin


> =

> Coupling a data modelling language with rather specific aspects of an=
 NM
> application is a bad design.
> =

> Lada =

> =

> > =

> > If the module is written assuming revised datastores and the enviro=
nment
> > does not support this in some regard, then we have a management
> > malfunction, which could be disastrous.
> > =

> > I think that there should be some mechanistic way, something that c=
an be
> > automated, for a system to check whether or not a module is assumin=
g
> > revised datastores or not.  This is a bit like the change from YANG=
 1.0
> > to YANG 1.1; there needs to be a way of telling what environment th=
e
> > module is written for, and so we have the
> > =

> > yang-version 1.1;
> > =

> > statement.
> > =

> > Revised datastores needs something similar in the module.
> > =

> > Tom Petch
> > =

> > =

> > ----- Original Message -----
> > From: "Lou Berger" 
> > Sent: Friday, September 01, 2017 10:02 PM
> > =

> > =

> > > All,
> > > =

> > > This starts a two week working group last call on
> > > draft-ietf-netmod-revised-datastores-04.
> > > =

> > > The working group last call ends on September 17.
> > > Please send your comments to the netmod mailing list.
> > > =

> > > Positive comments, e.g., "I've reviewed this document and
> > > believe it is ready for publication", are welcome!
> > > This is useful and important, even from authors.
> > > =

> > > Thank you,
> > > Netmod Chairs
> > > =

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

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

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

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


From nobody Fri Sep 15 05:34:54 2017
Return-Path: 
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 DABF3133210; Fri, 15 Sep 2017 05:34:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpZL3ICJf33T; Fri, 15 Sep 2017 05:34:47 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE9B4133211; Fri, 15 Sep 2017 05:34:46 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 9B975F7A; Fri, 15 Sep 2017 14:34:45 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id wAJEzMRRD4_C; Fri, 15 Sep 2017 14:34:43 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 15 Sep 2017 14:34:45 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7AACE200E9; Fri, 15 Sep 2017 14:34:45 +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 G6sNAL3hmqCk; Fri, 15 Sep 2017 14:34:45 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 049E0200E8; Fri, 15 Sep 2017 14:34:45 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id C8D1940F6029; Fri, 15 Sep 2017 14:34:43 +0200 (CEST)
Date: Fri, 15 Sep 2017 14:34:43 +0200
From: Juergen Schoenwaelder 
To: "t.petch" 
Cc: Lou Berger , netmod WG , netmod-chairs@ietf.org, draft-ietf-netmod-revised-datastores@ietf.org
Message-ID: <20170915123443.kvagu7dut7oaqoo2@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: "t.petch" , Lou Berger , netmod WG , netmod-chairs@ietf.org, draft-ietf-netmod-revised-datastores@ietf.org
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <022001d32e14$8d5d4540$4001a8c0@gateway.2wire.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <022001d32e14$8d5d4540$4001a8c0@gateway.2wire.net>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 updates
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 12:34:53 -0000

On Fri, Sep 15, 2017 at 12:19:42PM +0100, t.petch wrote:
> This I-D updates RFC7950, since it changes the XPath context that YANG
> uses, yet there is no mention of 'Updates'

I think the editors of the document reached the conclusion that the
xpath context rules stated in section 5.1. are the only meaningful
interpretation which is consistent with what RFC 7950 says.

The question is whether the text 'changes' the xpath context, or
'refines' the xpath context, or 'clarifies' the xpath context.  On a
synchronous system (where intended config and applied config never
differ), there is no change at all.

That said, I have no strong opinion about the question whether section
5.1 requires an 'Updates: RFC 7950' or not. I do not think section 5.1
is relevant for a system that uses RFC 7950 without implementing NMDA
and hence the value of having a forward pointer from RFC 7950 to NMDA
is likely not critical to have.

/js

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


From nobody Fri Sep 15 05:48:44 2017
Return-Path: 
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 3E763133211; Fri, 15 Sep 2017 05:48:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 rmH-N2iB9YJS; Fri, 15 Sep 2017 05:48: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 ACBEE133210; Fri, 15 Sep 2017 05:48:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5857; q=dns/txt; s=iport; t=1505479713; x=1506689313; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=vPf/5J1bsaQ7e6xhM2KvWqz5DjnxUfO+NA7/esny96I=; b=OVFWKnYnA/AMp/menxF6sRbh0v7D/xypjdfEG+Inz+/QNzXRZ5AFtKAr TvRxx86XhA+nHQani737SsFpyBEgzBtwf/ifTA6uOaB0pJKJNc+nI2dKE yoKytf4KxeV2YieKFY2ju2m7fc/1qsU/fd++nudMqpW8v9susIp0WzLJU s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAgCtyrtZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD5uJ4N1ixSQSCuQaIdRChgBCoRKTwKEbBUBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQEBAQMBASFIAwsMBAsRBAEBKAMCAicfCQgGAQwGAgEBii8Qq1mCJyeLCwEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAR2DK4NSgWMrC4JyiAuCYAWhBIdbjHqCE4Vqg1q?= =?us-ascii?q?FWIFJjV2HVYE5NSKBDTIhCBwVSYcePjYBiRABAQE?=
X-IronPort-AV: E=Sophos;i="5.42,396,1500940800";  d="scan'208,217";a="654642358"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Sep 2017 12:48:31 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v8FCmQ3K016002; Fri, 15 Sep 2017 12:48:26 GMT
To: Jiangyuanlong , "netmod@ietf.org" , Mehmet 
Cc: "tictoc@ietf.org" 
References: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5A2CBD@dggeml507-mbx.china.huawei.com>
From: Benoit Claise 
Message-ID: <331b6b30-8089-5411-9a33-88014b7d66c9@cisco.com>
Date: Fri, 15 Sep 2017 14:48:26 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5A2CBD@dggeml507-mbx.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------5AEF9A81F38D39980B3F49C8"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] FW: WGLC for draft-ietf-tictoc-1588v2-yang
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 12:48:36 -0000

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

Hi Yuanong,

There is pyang error.
http://www.claise.be/IETFYANGPageCompilation.html

    ietf-ptp-dataset@2017-04-20.yang:294: error: the value "0xFFFF" does
    not match its base type - not an integer

However, this is a pyang problem. See 
https://github.com/mbj4668/pyang/issues/329

Mehmet, can you please a YANG doctor. The YANG doctor review is normally 
done during IETF LC, but nothing prevents an early review.

Regards, Benoit
> Hi netmoders,
>
> This draft does not tackle the general YANG problem, but provide a generic time synchronization module of 1588.
> Some of you may have interests in time synchronization, some definitely not. But as experts in YANG, could you please have a review of this YANG module and give an expert opinion?
>
> Thanks,
> Yuanlong
>
> -----Original Message-----
> From: TICTOC [mailto:tictoc-bounces@ietf.org] On Behalf Of Karen O'Donoghue
> Sent: Thursday, September 14, 2017 3:16 AM
> To: tictoc@ietf.org
> Cc: ntp@ietf.org
> Subject: [TICTOC] WGLC for draft-ietf-tictoc-1588v2-yang
>
> Folks,
>
> This message begins a 2 week working group last call (WGLC) for the following document:
>
> YANG Data Model for IEEE 1588v2
> https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588v2-yang/
>
> Please review the referenced document and send any comments to the mailing list including your assessment of whether this document is mature enough to proceed to the IESG. Please note that these messages of support for progression to the mailing list are important and will be used to determine WG consensus to proceed.
>
> Please send all comments in by Thursday 28 September 2017.
>
> Thank you!
> Karen
> _______________________________________________
> TICTOC mailing list
> TICTOC@ietf.org
> https://www.ietf.org/mailman/listinfo/tictoc
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


--------------5AEF9A81F38D39980B3F49C8
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Hi Yuanong,

      

      There is pyang error.

      http://www.claise.be/IETFYANGPageCompilation.html

      

        

          
            

              ietf-ptp-dataset@2017-04-20.yang:294: error: the value
                "0xFFFF" does not match its base type - not an integer

              		
            

          
        

      

      However, this is a pyang problem. See
      https://github.com/mbj4668/pyang/issues/329

      

      Mehmet, can you please a YANG doctor. The YANG doctor review is
      normally done during IETF LC, but nothing prevents an early
      review.

      

      Regards, Benoit

    

    

      
Hi netmoders,

This draft does not tackle the general YANG problem, but provide a generic time synchronization module of 1588.
Some of you may have interests in time synchronization, some definitely not. But as experts in YANG, could you please have a review of this YANG module and give an expert opinion?

Thanks,
Yuanlong

-----Original Message-----
From: TICTOC [mailto:tictoc-bounces@ietf.org] On Behalf Of Karen O'Donoghue
Sent: Thursday, September 14, 2017 3:16 AM
To: tictoc@ietf.org
Cc: ntp@ietf.org
Subject: [TICTOC] WGLC for draft-ietf-tictoc-1588v2-yang

Folks,

This message begins a 2 week working group last call (WGLC) for the following document: 

YANG Data Model for IEEE 1588v2
https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588v2-yang/

Please review the referenced document and send any comments to the mailing list including your assessment of whether this document is mature enough to proceed to the IESG. Please note that these messages of support for progression to the mailing list are important and will be used to determine WG consensus to proceed. 

Please send all comments in by Thursday 28 September 2017.  

Thank you!
Karen
_______________________________________________
TICTOC mailing list
TICTOC@ietf.org
https://www.ietf.org/mailman/listinfo/tictoc

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



    

    

  


--------------5AEF9A81F38D39980B3F49C8--


From nobody Fri Sep 15 05:54:42 2017
Return-Path: 
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 707FE1332C8 for ; Fri, 15 Sep 2017 05:54:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 kwFJA0Z6MpFH for ; Fri, 15 Sep 2017 05:54:38 -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 64730133211 for ; Fri, 15 Sep 2017 05:54:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3050; q=dns/txt; s=iport; t=1505480078; x=1506689678; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=QYQkByvhXvk7b//oXxQIWLKdpiFxWMgenYxUexm9bRI=; b=NuU4nRGI4yiYukBwRFsRDXpzAxEgHssfxuw36bKtlipeP6N+Mv5BfJ/6 lYEDjvUUVehywsHvnRCgOva14rz+Kc77vtq9MN8ni1KEB1ch0hsdfQtNV 3lwvZnjk3iR0hZyxH2No2e4nSUstI/MQptSOC7TngxmmjSDfr8NyKm2Kb U=;
X-IronPort-AV: E=Sophos;i="5.42,396,1500940800"; d="scan'208";a="655665276"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Sep 2017 12:54:36 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v8FCsVsJ017256; Fri, 15 Sep 2017 12:54:31 GMT
To: Joe Clarke , Martin Bjorklund , andy@yumaworks.com
Cc: netmod@ietf.org
References: <9d84d068-29ba-8e89-394f-b7f6a5272adc@cisco.com>  <20170914.195037.593298963545596882.mbj@tail-f.com> <5721c564-48e9-299e-5ada-b272b00716cf@cisco.com>
From: Benoit Claise 
Message-ID: <748ca881-2180-3096-750d-44d28aa1b7ce@cisco.com>
Date: Fri, 15 Sep 2017 14:54:31 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <5721c564-48e9-299e-5ada-b272b00716cf@cisco.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 12:54:40 -0000

Hi Joe,
> On 9/14/17 13:50, Martin Bjorklund wrote:
>> Andy Bierman  wrote:
>>> Hi,
>>>
>>>
>>> Actually I liked the early pyang output that was concise and easy to
>>> remember.
>>> The current format gets very cluttered and there are too many little symbols
>>> to remember them all.
>> I agree with Andy.  I also did some experiments with printing
>> enumerations, and they work ok for small enums.  But once you have
>> more than a handful they do tend to clutter the output.  Even worse so
>> for trees that go into RFCs (where lines need to be < 70 characters).
> What about protecting this with an optional parameter?  I certainly
> appreciate the output could be large, but I think it does have its uses
> sometimes.
I would agree it has its uses sometimes.
And it helps the broader community with understanding YANG, this is good.
Now, if you are already a YANG expert, I guess you don't use the tree 
output much.

Regards, Benoit (as a contributor)
>
> Joe
>
>> Lada is sometimes using a format with even less information, where he
>> has removed all type information, focusing more on the structure.
>>
>>
>> /martin
>>
>>
>>
>>>
>>> Andy
>>>
>>>
>>> On Thu, Sep 14, 2017 at 8:33 AM, Joe Clarke  wrote:
>>>
>>>> I've been hacking on pyang, and I changed tree.py to add the enum values
>>>> for enumeration types and identiyref bases for identityref types.  Here
>>>> is an example:
>>>>
>>>> module: yang-catalog
>>>>      +--rw catalog
>>>>         +--rw modules
>>>>         |  +--rw module* [name revision organization]
>>>>         |     +--rw name                     yang:yang-identifier
>>>>         |     +--rw revision                 union
>>>>         |     +--rw organization             string
>>>>         |     +--rw ietf
>>>>         |     |  +--rw ietf-wg?   string
>>>>         |     +--rw namespace                inet:uri
>>>>         |     +--rw schema?                  inet:uri
>>>>         |     +--rw generated-from?          enumeration [mib, code,
>>>> not-applicable, native]
>>>>         |     +--rw maturity-level?          enumeration [ratified,
>>>> adopted, initial, not-applicable]
>>>> ...
>>>>                                 +--rw protocols
>>>>                                 |  +--rw protocol* [name]
>>>>                                 |     +--rw name
>>>> identityref -> protocol
>>>> ...
>>>>
>>>> My questions are:
>>>>
>>>> 1. Is this useful?
>>>>
>>>> 2. If so, can this be added to pyang (happy to submit a PR) and
>>>> draft-ietf-netmod-yang-tree-diagrams?
>>>>
>>>> 3. What changes to the output format would you recommend?
>>>>
>>>> Thanks.
>>>>
>>>> Joe
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


From nobody Fri Sep 15 06:00:36 2017
Return-Path: 
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 19DD11332CD for ; Fri, 15 Sep 2017 06:00:35 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQ3J0-3R0DFp for ; Fri, 15 Sep 2017 06:00:34 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B84ED133211 for ; Fri, 15 Sep 2017 06:00:33 -0700 (PDT)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id CCB861AE00A0; Fri, 15 Sep 2017 15:00:32 +0200 (CEST)
Date: Fri, 15 Sep 2017 15:01:19 +0200 (CEST)
Message-Id: <20170915.150119.392876131973300261.mbj@tail-f.com>
To: bclaise@cisco.com
Cc: jclarke@cisco.com, andy@yumaworks.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <748ca881-2180-3096-750d-44d28aa1b7ce@cisco.com>
References: <20170914.195037.593298963545596882.mbj@tail-f.com> <5721c564-48e9-299e-5ada-b272b00716cf@cisco.com> <748ca881-2180-3096-750d-44d28aa1b7ce@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 13:00:35 -0000

Benoit Claise  wrote:
> Hi Joe,
> > On 9/14/17 13:50, Martin Bjorklund wrote:
> >> Andy Bierman  wrote:
> >>> Hi,
> >>>
> >>>
> >>> Actually I liked the early pyang output that was concise and easy to
> >>> remember.
> >>> The current format gets very cluttered and there are too many little
> >>> symbols
> >>> to remember them all.
> >> I agree with Andy.  I also did some experiments with printing
> >> enumerations, and they work ok for small enums.  But once you have
> >> more than a handful they do tend to clutter the output.  Even worse so
> >> for trees that go into RFCs (where lines need to be < 70 characters).
> > What about protecting this with an optional parameter?  I certainly
> > appreciate the output could be large, but I think it does have its
> > uses
> > sometimes.
> I would agree it has its uses sometimes.
> And it helps the broader community with understanding YANG, this is
> good.
> Now, if you are already a YANG expert, I guess you don't use the tree
> output much.

Personally, I use it all the time, it is extremely useful for
understanding the module.  But if it has too much details it becomes
less useful.


/martin


From nobody Fri Sep 15 06:21:34 2017
Return-Path: 
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 E99C9133211 for ; Fri, 15 Sep 2017 06:21:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JB6r0QmY5-OC for ; Fri, 15 Sep 2017 06:21:31 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4109C120720 for ; Fri, 15 Sep 2017 06:21:31 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 16EE7F14; Fri, 15 Sep 2017 15:21:30 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id Ea0XONFYtTa9; Fri, 15 Sep 2017 15:21:27 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 15 Sep 2017 15:21:30 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E7222200E9; Fri, 15 Sep 2017 15:21:29 +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 wpstlTA5wcyf; Fri, 15 Sep 2017 15:21:29 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3BF97200E8; Fri, 15 Sep 2017 15:21:29 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 7BA3F40F63C1; Fri, 15 Sep 2017 15:21:28 +0200 (CEST)
Date: Fri, 15 Sep 2017 15:21:28 +0200
From: Juergen Schoenwaelder 
To: Benoit Claise 
Cc: Joe Clarke , Martin Bjorklund , andy@yumaworks.com, netmod@ietf.org
Message-ID: <20170915132128.diib4wxp2vg6yqi4@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Benoit Claise , Joe Clarke , Martin Bjorklund , andy@yumaworks.com, netmod@ietf.org
References: <9d84d068-29ba-8e89-394f-b7f6a5272adc@cisco.com>  <20170914.195037.593298963545596882.mbj@tail-f.com> <5721c564-48e9-299e-5ada-b272b00716cf@cisco.com> <748ca881-2180-3096-750d-44d28aa1b7ce@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <748ca881-2180-3096-750d-44d28aa1b7ce@cisco.com>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 13:21:33 -0000

On Fri, Sep 15, 2017 at 02:54:31PM +0200, Benoit Claise wrote:

> Now, if you are already a YANG expert, I guess you don't use the
> tree output much.

I think this has nothing to do with YANG experience. The intention of
the tree format was to provide a concise overview of the structure of
the schema tree. If we start to include type specifics that can get
very detailed, the diagrams loose their value.

/js

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


From nobody Fri Sep 15 06:34:03 2017
Return-Path: 
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 A454B1332E3 for ; Fri, 15 Sep 2017 06:34:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 567FOLiwWIZW for ; Fri, 15 Sep 2017 06:34:00 -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 EDEF01332CD for ; Fri, 15 Sep 2017 06:33:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1691; q=dns/txt; s=iport; t=1505482440; x=1506692040; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=bWlwR1OuLwlOuchfmfAkGG8RiUxwcwda4mvn5yNcL18=; b=IEiOId77uKtZegVk/2qktVatx3R7izczqbZx0g0DtMVrgeSXvJ9S1FJo ett9AcVYovUazARzHGMNfSYsQN6jUhMTY1DNjXaMVM6wqbQHkQ/V/JZdY LKRWi4izB6VCm3hk1dM0zHL9M0KYjkx/n+BF/oA3BgSaZRdU1CSAIGKXD c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C+AQB41rtZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhSyEHIsUkEgrmDkKhTwChG0UAQIBAQEBAQEBayiFGQEFIxVRCw4?= =?us-ascii?q?KAgImAgJXBgEMCAEBii+rf4InizIBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgQ6CH?= =?us-ascii?q?YNSgg4LgnKIC4JgBZEuj1aUVYtXhyGNXYdVgTk2IYENMiEIHBWHZj+JRwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.42,396,1500940800"; d="scan'208";a="657486739"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Sep 2017 13:33:58 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8FDXv5T018675; Fri, 15 Sep 2017 13:33:58 GMT
To: Martin Bjorklund , netmod@ietf.org
References:  <1505470900.18681.0.camel@nic.cz> <5b512435-cebd-3534-eeb3-649154450d81@cisco.com> <20170915.134007.262763963470255554.mbj@tail-f.com> <20170915121552.7hjqodubjgkvvr7i@elstar.local>
From: Robert Wilton 
Message-ID: <4f5edcd1-ed53-4877-1f1f-8c17535550e3@cisco.com>
Date: Fri, 15 Sep 2017 14:33:57 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170915121552.7hjqodubjgkvvr7i@elstar.local>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 13:34:01 -0000

Perhaps "-X" could be used for "execute" instead?

Thanks,
Rob


On 15/09/2017 13:15, Juergen Schoenwaelder wrote:
> On Fri, Sep 15, 2017 at 01:40:07PM +0200, Martin Bjorklund wrote:
>> Also, what is mounted under a mount point is not defined in the
>> schema, so a tool cannot generate this from the YANG modules.
>>
> This sounds broken. Manually edited tree diagrams will be a source of
> pain.
>   
>>> I definitely think that "x" is a bit confusing since it both means
>>> "RPC" and also "status deprecated" depending on where it is.
>> Possibly.  "x" for "deprecated" comes from smidump.  "x" for "execute"
>> (rwx) is of course common.  So if we should change something it is
>> probably "x" for "deprecated".  But "x" looks better than "d"...
>>
> Yep, I am probably guilty for the deprecated 'x'. For obsolete,
> smidump creates an 'o', so you have
>
>          +--- foo
>          x--- bar
>          o--- baz
>
> and I guess I visually liked it (and there was no execute in SNMP
> land). I guess I still kind of like this. If I would start from
> scratch for YANG, I would probably not use
>
>         rw  for configuration data
>         ro  for non-configuration data
>         -x  for rpcs and actions
>         -n  for notifications
>         mp   for schema mount points
>
> but rather single letters, e.g.
>
>         c  for configuration data
>         s  for non-configuration data
>         r  for rpcs and actions
>         n  for notifications
>         m  for schema mount points
>
> but this is a significant change to what we have done so far and
> finding agreement on a new notation is likely difficult.
>
> /js
>


From nobody Fri Sep 15 06:42:03 2017
Return-Path: 
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 298DE1332CD for ; Fri, 15 Sep 2017 06:42:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aXWwc9l2U2E for ; Fri, 15 Sep 2017 06:41:59 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FA0C1331C2 for ; Fri, 15 Sep 2017 06:41:59 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 4B6E46AA; Fri, 15 Sep 2017 15:41:58 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id VvPeA_-V4k2d; Fri, 15 Sep 2017 15:41:55 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 15 Sep 2017 15:41:58 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2CE06200E9; Fri, 15 Sep 2017 15:41:58 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id sJXQ9JuBsGxA; Fri, 15 Sep 2017 15:41:57 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E51AC200E8; Fri, 15 Sep 2017 15:41:57 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id BDC9440F64A0; Fri, 15 Sep 2017 15:41:56 +0200 (CEST)
Date: Fri, 15 Sep 2017 15:41:56 +0200
From: Juergen Schoenwaelder 
To: Robert Wilton 
Cc: Martin Bjorklund , netmod@ietf.org
Message-ID: <20170915134156.vlq7o2qzyafzje5v@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Robert Wilton , Martin Bjorklund , netmod@ietf.org
References:  <1505470900.18681.0.camel@nic.cz> <5b512435-cebd-3534-eeb3-649154450d81@cisco.com> <20170915.134007.262763963470255554.mbj@tail-f.com> <20170915121552.7hjqodubjgkvvr7i@elstar.local> <4f5edcd1-ed53-4877-1f1f-8c17535550e3@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4f5edcd1-ed53-4877-1f1f-8c17535550e3@cisco.com>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 13:42:01 -0000

On Fri, Sep 15, 2017 at 02:33:57PM +0100, Robert Wilton wrote:

> Perhaps "-X" could be used for "execute" instead?

A single uppercase letter? Looks ugly to my eyes. This is all very
subjective and perhaps things were easier as long as there was just
a tool. ;-)

/js

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


From nobody Fri Sep 15 06:50:07 2017
Return-Path: 
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 B17AF132396 for ; Fri, 15 Sep 2017 06:50:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.021
X-Spam-Level: 
X-Spam-Status: No, score=-14.021 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, RCVD_IN_SORBS_SPAM=0.5, 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 uD70moeuctCv for ; Fri, 15 Sep 2017 06:50:05 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78C4612421A for ; Fri, 15 Sep 2017 06:50:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=918; q=dns/txt; s=iport; t=1505483405; x=1506693005; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=x/eyxUqmPqY1ZxajzgqXjdr2SYXq7IdT0ym8MH9B/iY=; b=FlKfndHUqN8hQj0iAsh1d9kh6Ogl5Hz6d4wtfujd3RybBd8FvVxZnmPb BLDTbi559rOOk+xele4iVCED0ut9RuHDWXYu3e8zcb/1JXpACYHclXYJo 5j21AlugKRhdSnp+qGUpK8D0itEjcDJ0Bz6kCpsz9vy1WUNCwLZ3MwCmM 4=;
X-IronPort-AV: E=Sophos;i="5.42,397,1500940800";  d="scan'208";a="3968425"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Sep 2017 13:50:04 +0000
Received: from [10.118.87.94] (rtp-jclarke-nitro13.cisco.com [10.118.87.94]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v8FDo4gB009447; Fri, 15 Sep 2017 13:50:04 GMT
To: Benoit Claise , Martin Bjorklund , andy@yumaworks.com, netmod@ietf.org
References: <9d84d068-29ba-8e89-394f-b7f6a5272adc@cisco.com>  <20170914.195037.593298963545596882.mbj@tail-f.com> <5721c564-48e9-299e-5ada-b272b00716cf@cisco.com> <748ca881-2180-3096-750d-44d28aa1b7ce@cisco.com> <20170915132128.diib4wxp2vg6yqi4@elstar.local>
From: Joe Clarke 
Organization: Cisco
Message-ID: <694e1d93-5cf8-2aca-a1a8-8df0e1d0aa15@cisco.com>
Date: Fri, 15 Sep 2017 09:50:04 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170915132128.diib4wxp2vg6yqi4@elstar.local>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 13:50:07 -0000

On 9/15/17 09:21, Juergen Schoenwaelder wrote:
> On Fri, Sep 15, 2017 at 02:54:31PM +0200, Benoit Claise wrote:
> 
>> Now, if you are already a YANG expert, I guess you don't use the
>> tree output much.
> 
> I think this has nothing to do with YANG experience. The intention of
> the tree format was to provide a concise overview of the structure of
> the schema tree. If we start to include type specifics that can get
> very detailed, the diagrams loose their value.

I agree that clutter is bad.  I had the same reservation, but I am also
working with models and sharing information with people where a tree
that has a _bit_ more information would be useful.

I agree that showing this by default will be messy in some cases.  And
maybe this has moved to a question more for you, Martin, in pyang's
GitHub channel.  But if this output were put behind an option, would you
entertain a PR?

Joe


From nobody Fri Sep 15 06:51:03 2017
Return-Path: 
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 378D312421A for ; Fri, 15 Sep 2017 06:51:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 tWj5ygS8ZKyz for ; Fri, 15 Sep 2017 06:51:01 -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 96D1E1332E1 for ; Fri, 15 Sep 2017 06:51:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1045; q=dns/txt; s=iport; t=1505483460; x=1506693060; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=omCo2OZNYZnlSb96bBLznryOJ8qa6YuHcJHJJbK3l18=; b=jkcnH6qWQKB3l/+ncCSOwhApWtulYo07XFIscBhidPR0KlvDrrXEB3L/ dacTlsVQBFQbrP8YR+xqvd5ZqB+mjbnf5NeQEvXn+JwE+70EDW1W2IeP/ FfnBgbx/Yk432X8XMTkF3RMCBwVnGDIBIXrUhBZYIQrrJUguJz+hgl/fb E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C+AQD52btZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhSyEHIsUkEgrmDkKhTwChG0UAQIBAQEBAQEBayiFGQEFIw8BBVE?= =?us-ascii?q?LDgoCAiYCAlcGAQwIAQGKL6wFgieLMgEBAQEBAQEDAQEBAQEBIoEOgh2DUoIOC?= =?us-ascii?q?4JyhESDR4JgBYc/mUWPD4VGi1eHIY1dh1WBOTYhgQ0yIQgcFYdmP4lHAQEB?=
X-IronPort-AV: E=Sophos;i="5.42,397,1500940800"; d="scan'208";a="655666180"
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; 15 Sep 2017 13:50:58 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v8FDowwa003493; Fri, 15 Sep 2017 13:50:58 GMT
To: Martin Bjorklund , netmod@ietf.org
References:  <1505470900.18681.0.camel@nic.cz> <5b512435-cebd-3534-eeb3-649154450d81@cisco.com> <20170915.134007.262763963470255554.mbj@tail-f.com> <20170915121552.7hjqodubjgkvvr7i@elstar.local> <4f5edcd1-ed53-4877-1f1f-8c17535550e3@cisco.com> <20170915134156.vlq7o2qzyafzje5v@elstar.local>
From: Robert Wilton 
Message-ID: <0e372f5b-60a5-bcb6-4439-427c4ce38718@cisco.com>
Date: Fri, 15 Sep 2017 14:50:58 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170915134156.vlq7o2qzyafzje5v@elstar.local>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 13:51:02 -0000

On 15/09/2017 14:41, Juergen Schoenwaelder wrote:
> On Fri, Sep 15, 2017 at 02:33:57PM +0100, Robert Wilton wrote:
>
>> Perhaps "-X" could be used for "execute" instead?
> A single uppercase letter? Looks ugly to my eyes. This is all very
> subjective and perhaps things were easier as long as there was just
> a tool. ;-)
My rational was that there aren't too many RPCs or Actions defined hence 
changing it would be OK. :-)

I thought about suggesting "X" and "O" for deprecated and obsolete, but 
that would seem to draw attention to those nodes, which is probably the 
reverse of what is wanted.

I guess another alternative could be to leave deprecated and obsolete 
nodes out of the YANG tree output all together ... Personally, I like 
the idea of leaving out obsolete nodes since they are just noise, but 
I'm less sure about leaving out the deprecated nodes.  However, I know 
that Martin has left out the deprecated -state tree in 7223bis to make 
the tree diagram more concise.

Thanks,
Rob

>
> /js
>


From nobody Fri Sep 15 06:54:52 2017
Return-Path: 
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 A2B561332CE for ; Fri, 15 Sep 2017 06:54: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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGmcdlhyjXCh for ; Fri, 15 Sep 2017 06:54:49 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3C52D12421A for ; Fri, 15 Sep 2017 06:54:49 -0700 (PDT)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id D75371AE00A0; Fri, 15 Sep 2017 15:54:47 +0200 (CEST)
Date: Fri, 15 Sep 2017 15:55:34 +0200 (CEST)
Message-Id: <20170915.155534.171587236450641060.mbj@tail-f.com>
To: jclarke@cisco.com
Cc: bclaise@cisco.com, andy@yumaworks.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <694e1d93-5cf8-2aca-a1a8-8df0e1d0aa15@cisco.com>
References: <748ca881-2180-3096-750d-44d28aa1b7ce@cisco.com> <20170915132128.diib4wxp2vg6yqi4@elstar.local> <694e1d93-5cf8-2aca-a1a8-8df0e1d0aa15@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 13:54:50 -0000

Joe Clarke  wrote:
> On 9/15/17 09:21, Juergen Schoenwaelder wrote:
> > On Fri, Sep 15, 2017 at 02:54:31PM +0200, Benoit Claise wrote:
> > 
> >> Now, if you are already a YANG expert, I guess you don't use the
> >> tree output much.
> > 
> > I think this has nothing to do with YANG experience. The intention of
> > the tree format was to provide a concise overview of the structure of
> > the schema tree. If we start to include type specifics that can get
> > very detailed, the diagrams loose their value.
> 
> I agree that clutter is bad.  I had the same reservation, but I am also
> working with models and sharing information with people where a tree
> that has a _bit_ more information would be useful.
> 
> I agree that showing this by default will be messy in some cases.  And
> maybe this has moved to a question more for you, Martin, in pyang's
> GitHub channel.  But if this output were put behind an option, would you
> entertain a PR?

Right, there are two issues here, what do we specify in the draft and
what extensions will tools do.  It seems we agree that we shouldn't
put this into the specification.

(as for pyang, I'll send you a private email)


/martin


From nobody Fri Sep 15 06:55:11 2017
Return-Path: 
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 024471332E3 for ; Fri, 15 Sep 2017 06:55:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glK3tQYDEX4S for ; Fri, 15 Sep 2017 06:55:08 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C5F61332CE for ; Fri, 15 Sep 2017 06:55:07 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 5B84C4C3; Fri, 15 Sep 2017 15:55:06 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 4T2A-gdKRfgV; Fri, 15 Sep 2017 15:55:03 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 15 Sep 2017 15:55:06 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1DB63200E9; Fri, 15 Sep 2017 15:55:06 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id j-u9fL9mBkiT; Fri, 15 Sep 2017 15:55:05 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BBCFF200E8; Fri, 15 Sep 2017 15:55:05 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 9515B40F6507; Fri, 15 Sep 2017 15:55:05 +0200 (CEST)
Date: Fri, 15 Sep 2017 15:55:05 +0200
From: Juergen Schoenwaelder 
To: Robert Wilton 
Cc: Martin Bjorklund , netmod@ietf.org
Message-ID: <20170915135505.svq2chubilwzugdo@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Robert Wilton , Martin Bjorklund , netmod@ietf.org
References:  <1505470900.18681.0.camel@nic.cz> <5b512435-cebd-3534-eeb3-649154450d81@cisco.com> <20170915.134007.262763963470255554.mbj@tail-f.com> <20170915121552.7hjqodubjgkvvr7i@elstar.local> <4f5edcd1-ed53-4877-1f1f-8c17535550e3@cisco.com> <20170915134156.vlq7o2qzyafzje5v@elstar.local> <0e372f5b-60a5-bcb6-4439-427c4ce38718@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <0e372f5b-60a5-bcb6-4439-427c4ce38718@cisco.com>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 13:55:10 -0000

On Fri, Sep 15, 2017 at 02:50:58PM +0100, Robert Wilton wrote:
> 
> I guess another alternative could be to leave deprecated and obsolete nodes
> out of the YANG tree output all together ... Personally, I like the idea of
> leaving out obsolete nodes since they are just noise, but I'm less sure
> about leaving out the deprecated nodes.  However, I know that Martin has
> left out the deprecated -state tree in 7223bis to make the tree diagram more
> concise.
>

Well, in code, this is just a simple option. ;-)

/js

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


From nobody Fri Sep 15 06:56:27 2017
Return-Path: 
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 24A941332DA for ; Fri, 15 Sep 2017 06:56:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 eElIt3HIjUKU for ; Fri, 15 Sep 2017 06:56:24 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46B951332D7 for ; Fri, 15 Sep 2017 06:56:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3614; q=dns/txt; s=iport; t=1505483784; x=1506693384; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=CbD7QImOE21vobEc2szvpHyqS1HajHfvhP8BOIzypdg=; b=HZHn6q78REdfuME1lQxf/LdfIsjiF1MZVVcu+W95rz/t3VtSzFMlSP5f aGiNLIGYpTfCPa+zbK32NqmsfxOOZMB6Z6vrnpu84mgsGU6HriJkWr1tO GMskMOM/CXKoaySCGGmOhkHZvBB5CN7sYEi20f1dgrXzKcLHABs5XjWOt Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CrAACt2rtZ/5hdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbicHg26KII9zgXSWJ4ISChgLhEpPAhqEED8YAQIBAQEBAQE?= =?us-ascii?q?BayiFGQEBAQMBASEEDTobAgEGAhgCAiYCAgIlCxUQAgQBEoozEI4RnWaBbTqLM?= =?us-ascii?q?gEBAQEBAQEBAQEBAQEBAQEBAQEBAR2BDoIdggKGW4R4gxOCYAWMKIUHj1UCh1m?= =?us-ascii?q?MeoJukAqVBQIRGQGBOAEfOIENdxVJhxx2iAKBDwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.42,397,1500940800"; d="scan'208";a="285420734"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Sep 2017 13:56:23 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8FDuNQ8021128 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 15 Sep 2017 13:56:23 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 15 Sep 2017 09:56:22 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1263.000; Fri, 15 Sep 2017 09:56:22 -0400
From: "Acee Lindem (acee)" 
To: Ladislav Lhotka , "netmod@ietf.org" 
Thread-Topic: [netmod] Proposal to enhance the YANG tree output
Thread-Index: AQHTLW7ooMSJJm/gdkGnL0U2wTeGA6K0yJQAgAE4cwD///jZAA==
Date: Fri, 15 Sep 2017 13:56:22 +0000
Message-ID: 
References: <9d84d068-29ba-8e89-394f-b7f6a5272adc@cisco.com>  <1505470900.18681.0.camel@nic.cz>
In-Reply-To: <1505470900.18681.0.camel@nic.cz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.117.47]
Content-Type: text/plain; charset="utf-8"
Content-ID: <8F9AB2F8BD42CA438B287F2E8313F806@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 13:56:26 -0000

KzEgLSBBbHNvIGl0IGlzIGhhcmQgZW5vdWdoIHRvIGZvcm1hdCB0aGUgdHJlZSBvdXRwdXQgdG8g
Zml0IGluIGEgZHJhZnQNCncvbyBmdXJ0aGVyIGFubm90YXRpb25zIChldmVuIHdpdGgg4oCULXRy
ZWUtbGluZS1sZW5ndGgpLg0KVGhhbmtzLA0KQWNlZQ0KDQoNCk9uIDkvMTUvMTcsIDY6MjEgQU0s
ICJuZXRtb2Qgb24gYmVoYWxmIG9mIExhZGlzbGF2IExob3RrYSINCjxuZXRtb2QtYm91bmNlc0Bp
ZXRmLm9yZyBvbiBiZWhhbGYgb2YgbGhvdGthQG5pYy5jej4gd3JvdGU6DQoNCj5BbmR5IEJpZXJt
YW4gcMOtxaFlIHYgxIx0IDE0LiAwOS4gMjAxNyB2IDA4OjQzIC0wNzAwOg0KPj4gSGksDQo+PiAN
Cj4+IA0KPj4gQWN0dWFsbHkgSSBsaWtlZCB0aGUgZWFybHkgcHlhbmcgb3V0cHV0IHRoYXQgd2Fz
IGNvbmNpc2UgYW5kIGVhc3kgdG8NCj4+cmVtZW1iZXIuDQo+PiBUaGUgY3VycmVudCBmb3JtYXQg
Z2V0cyB2ZXJ5IGNsdXR0ZXJlZCBhbmQgdGhlcmUgYXJlIHRvbyBtYW55IGxpdHRsZQ0KPj5zeW1i
b2xzDQo+PiB0byByZW1lbWJlciB0aGVtIGFsbC4NCj4NCj5JIGFncmVlLg0KPg0KPkxhZGENCj4N
Cj4+IA0KPj4gDQo+PiBBbmR5DQo+PiANCj4+IA0KPj4gT24gVGh1LCBTZXAgMTQsIDIwMTcgYXQg
ODozMyBBTSwgSm9lIENsYXJrZSA8amNsYXJrZUBjaXNjby5jb20+IHdyb3RlOg0KPj4gPiBJJ3Zl
IGJlZW4gaGFja2luZyBvbiBweWFuZywgYW5kIEkgY2hhbmdlZCB0cmVlLnB5IHRvIGFkZCB0aGUg
ZW51bQ0KPj52YWx1ZXMNCj4+ID4gZm9yIGVudW1lcmF0aW9uIHR5cGVzIGFuZCBpZGVudGl5cmVm
IGJhc2VzIGZvciBpZGVudGl0eXJlZiB0eXBlcy4NCj4+SGVyZQ0KPj4gPiBpcyBhbiBleGFtcGxl
Og0KPj4gPiANCj4+ID4gbW9kdWxlOiB5YW5nLWNhdGFsb2cNCj4+ID4gICAgICstLXJ3IGNhdGFs
b2cNCj4+ID4gICAgICAgICstLXJ3IG1vZHVsZXMNCj4+ID4gICAgICAgIHwgICstLXJ3IG1vZHVs
ZSogW25hbWUgcmV2aXNpb24gb3JnYW5pemF0aW9uXQ0KPj4gPiAgICAgICAgfCAgICAgKy0tcncg
bmFtZSAgICAgICAgICAgICAgICAgICAgIHlhbmc6eWFuZy1pZGVudGlmaWVyDQo+PiA+ICAgICAg
ICB8ICAgICArLS1ydyByZXZpc2lvbiAgICAgICAgICAgICAgICAgdW5pb24NCj4+ID4gICAgICAg
IHwgICAgICstLXJ3IG9yZ2FuaXphdGlvbiAgICAgICAgICAgICBzdHJpbmcNCj4+ID4gICAgICAg
IHwgICAgICstLXJ3IGlldGYNCj4+ID4gICAgICAgIHwgICAgIHwgICstLXJ3IGlldGYtd2c/ICAg
c3RyaW5nDQo+PiA+ICAgICAgICB8ICAgICArLS1ydyBuYW1lc3BhY2UgICAgICAgICAgICAgICAg
aW5ldDp1cmkNCj4+ID4gICAgICAgIHwgICAgICstLXJ3IHNjaGVtYT8gICAgICAgICAgICAgICAg
ICBpbmV0OnVyaQ0KPj4gPiAgICAgICAgfCAgICAgKy0tcncgZ2VuZXJhdGVkLWZyb20/ICAgICAg
ICAgIGVudW1lcmF0aW9uIFttaWIsIGNvZGUsDQo+PiA+IG5vdC1hcHBsaWNhYmxlLCBuYXRpdmVd
DQo+PiA+ICAgICAgICB8ICAgICArLS1ydyBtYXR1cml0eS1sZXZlbD8gICAgICAgICAgZW51bWVy
YXRpb24gW3JhdGlmaWVkLA0KPj4gPiBhZG9wdGVkLCBpbml0aWFsLCBub3QtYXBwbGljYWJsZV0N
Cj4+ID4gLi4uDQo+PiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS1ydyBwcm90
b2NvbHMNCj4+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICstLXJ3IHByb3Rv
Y29sKiBbbmFtZV0NCj4+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICst
LXJ3IG5hbWUNCj4+ID4gaWRlbnRpdHlyZWYgLT4gcHJvdG9jb2wNCj4+ID4gLi4uDQo+PiA+IA0K
Pj4gPiBNeSBxdWVzdGlvbnMgYXJlOg0KPj4gPiANCj4+ID4gMS4gSXMgdGhpcyB1c2VmdWw/DQo+
PiA+IA0KPj4gPiAyLiBJZiBzbywgY2FuIHRoaXMgYmUgYWRkZWQgdG8gcHlhbmcgKGhhcHB5IHRv
IHN1Ym1pdCBhIFBSKSBhbmQNCj4+ID4gZHJhZnQtaWV0Zi1uZXRtb2QteWFuZy10cmVlLWRpYWdy
YW1zPw0KPj4gPiANCj4+ID4gMy4gV2hhdCBjaGFuZ2VzIHRvIHRoZSBvdXRwdXQgZm9ybWF0IHdv
dWxkIHlvdSByZWNvbW1lbmQ/DQo+PiA+IA0KPj4gPiBUaGFua3MuDQo+PiA+IA0KPj4gPiBKb2UN
Cj4+ID4gDQo+PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQo+PiA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4+ID4gbmV0bW9kQGlldGYub3JnDQo+PiA+
IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+PiANCj4+IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBuZXRtb2Qg
bWFpbGluZyBsaXN0DQo+PiBuZXRtb2RAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+LS0gDQo+TGFkaXNsYXYgTGhvdGthDQo+SGVhZCwg
Q1ouTklDIExhYnMNCj5QR1AgS2V5IElEOiAweEI4RjkyQjA4QTlGNzZDNjcNCj4NCj5fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPm5ldG1vZCBtYWlsaW5n
IGxpc3QNCj5uZXRtb2RAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL25ldG1vZA0KDQo=


From nobody Fri Sep 15 07:29:08 2017
Return-Path: 
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 CE5A9133343 for ; Fri, 15 Sep 2017 07:29:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.196
X-Spam-Level: 
X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B_vh_uDmWwnR for ; Fri, 15 Sep 2017 07:29:03 -0700 (PDT)
Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8237C12421A for ; Fri, 15 Sep 2017 07:29:03 -0700 (PDT)
Received: from epcas5p3.samsung.com (unknown [182.195.41.41]) by mailout1.samsung.com (KnoxPortal) with ESMTP id 20170915142900epoutp01029a9339c2a3d8cc61e38830512aed85~kj04U1lMs0861308613epoutp015 for ; Fri, 15 Sep 2017 14:29:00 +0000 (GMT)
Received: from epsmges5p2new.samsung.com (unknown [182.195.42.74]) by epcas5p4.samsung.com (KnoxPortal) with ESMTP id 20170915142900epcas5p457e07281b289c633c28ccba2cce51808~kj03wtNsV1992119921epcas5p4z; Fri, 15 Sep 2017 14:29:00 +0000 (GMT)
X-AuditID: b6c32a4a-f79896d000000f29-8c-59bbe3ac4494
Received: from epcas5p2.samsung.com ( [182.195.41.40]) by epsmges5p2new.samsung.com (Symantec Messaging Gateway) with SMTP id E7.3F.03881.CA3EBB95; Fri, 15 Sep 2017 23:29:00 +0900 (KST)
Mime-Version: 1.0
Reply-To: sk.srivastav@samsung.com
Sender: Sudhanshu Kumar Srivastav 
From: Sudhanshu Kumar Srivastav 
To: Robert Wilton , "netmod@ietf.org" 
CC: KARTHIKEYAN SUBRAMANIAM , "cpgs ." , Surendra Pal Sharma 
X-Priority: 3
X-Content-Kind-Code: NORMAL
In-Reply-To: 
X-Drm-Type: N,general
X-EPLocale: en_US.EUC-KR
X-EPWebmail-Msg-Type: personal
X-Msg-Generator: Mail
X-Msg-Type: PERSONAL
X-Reply-Demand: N
X-Sender: =?utf-8?B?U2Ftc3VuZyBFbGVjdHJvbmljcxtTUkktQg==?= =?utf-8?B?YW5nYWxvcmUtQ1UbQ2hpZWYgRW5naW5lZXI=?=
X-Sender-IP: 107.110.12.116
X-Local-Sender: =?UTF-8?B?U3VkaGFuc2h1IEt1bWFyIFNyaXZhc3RhdhtTUkktQmFuZ2Fsb3JlLUNV?= =?UTF-8?B?G+yCvOyEseyghOyekBtDaGllZiBFbmdpbmVlcg==?=
X-Global-Sender: =?UTF-8?B?U3VkaGFuc2h1IEt1bWFyIFNyaXZhc3RhdhtTUkktQmFuZ2Fsb3JlLUNV?= =?UTF-8?B?G1NhbXN1bmcgRWxlY3Ryb25pY3MbQ2hpZWYgRW5naW5lZXI=?=
X-Sender-Code: =?UTF-8?B?QzEwGxtDMTBJRDAxSUQwMTA5MTU=?=
Message-ID: <20170915142859epcms5p526b9d21b55ddd8f0eb13edfec62efcff@epcms5p5>
Date: Fri, 15 Sep 2017 14:28:59 +0000
X-CMS-MailID: 20170915142859epcms5p526b9d21b55ddd8f0eb13edfec62efcff
Content-Type: multipart/related; boundary="=_NamoWEC-i81mnnsa33"
X-CPGSPASS: Y
X-MTR: 20170915142859epcms5p526b9d21b55ddd8f0eb13edfec62efcff
CMS-TYPE: 105P
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBKsWRmVeSWpSXmKPExsWy7bCmhu6ax7sjDT7+EbZ4eUjTYsGkH8wW 8y82slqcONfHbPHz/w52B1aPKb83snosWfKTyaNvyyrGAOYoLpuU1JzMstQifbsEroz/326w FDy9wFzx9uExtgbGG0eYuxg5OSQETCSaz65ngbDFJC7cW8/WxcjFISSwm1Hixbnt7F2MHBy8 AoISf3cIg9QIC9hI3OyfDFYvJKAk0biilwUmfuj7MVYQm03ASuJJ/3kwW0TAS2L1mTssIDOZ BVoYJbZ9usoGsYxXYkb7U6jF0hLbl29lBNnFKWArsfFvMkRYVOLm6rfsELaExOqFz6Fa5SSm fV3DDFPz/th8RghbRKL13lmouKDEg5+7oeK5Eh3725lhVv39d4QR5B4JgW5GiVdXbkE5Uxgl 9p98ArXBXOJyfy9YN6+Ar8T66U/AulkEVCX6p02Hmuoi8f70XSYQm1nAQeLG573sMI81bPwN DjgJoGdePBCCKOGT6P39hAmiRE3i7J0HbBMYVWYhgncWkkEQtqLElO6HULaGROucuVC2jcTs 68dYMNWoSvw6sIR1ASP7KkbJ1ILi3PTUYtMCo7zUcr3ixNzi0rx0veT83E2M4DSl5bWDcdk5 n0OMAhyMSjy8Ghd3RwqxJpYVV+YeYlQBmvVow+oLjFIsefl5qUoivLvvA6V5UxIrq1KL8uOL SnNSiw8xSnOwKInzHttZGikkkJ5YkpqdmlqQWgSTZeLglGpgXBStpyXt0qbxsHz7ycfL8m7t Dzyt+7N7mcxng9cTnrzIqDkuUuvKvmjLUialTWKJKpH1aaK7S+9JXmSPXrvommf/2frZ63l+ N+2+88R26poTt6r0vqT3ROV+cVx5Z57GjEfLfC5NZDSONnjyY6bNmp0s19qOqTZVMPXsDpI9 9Et3u6Bv1sX77UosxRmJhlrMRcWJALnjSoZbAwAA
X-CMS-RootMailID: 20170913073034epcms5p3ba5e2a0c180d8cd9f4464d8e5921d106
X-RootMTR: 20170913073034epcms5p3ba5e2a0c180d8cd9f4464d8e5921d106
References:  <20170913073034epcms5p3ba5e2a0c180d8cd9f4464d8e5921d106@epcms5p3> 
Archived-At: 
Subject: Re: [netmod] draft-srivastav-netmod-formulae-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 14:29:07 -0000

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

PEhUTUw+PEhFQUQ+DQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiIGh0
dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPFNUWUxFIGlkPW15c2luZ2xlX3N0eWxlIHR5cGU9dGV4
dC9jc3M+LnNlYXJjaC13b3JkIHsNCglCQUNLR1JPVU5ELUNPTE9SOiAjZmZlZTk0DQp9DQpQIHsN
CglNQVJHSU4tQk9UVE9NOiA1cHg7IEZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFs
LCBhcmlhbDsgTUFSR0lOLVRPUDogNXB4DQp9DQpURCB7DQoJTUFSR0lOLUJPVFRPTTogNXB4OyBG
T05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCwgYXJpYWw7IE1BUkdJTi1UT1A6IDVw
eA0KfQ0KTEkgew0KCU1BUkdJTi1CT1RUT006IDVweDsgRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZB
TUlMWTogQXJpYWwsIGFyaWFsOyBNQVJHSU4tVE9QOiA1cHgNCn0NCkJPRFkgew0KCUZPTlQtU0la
RTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsLCBhcmlhbA0KfQ0KPC9TVFlMRT4NCg0KPE1FVEEg
Y29udGVudD1JRT01IGh0dHAtZXF1aXY9WC1VQS1Db21wYXRpYmxlPg0KPE1FVEEgY29udGVudD1J
RT01IGh0dHAtZXF1aXY9WC1VQS1Db21wYXRpYmxlPg0KPFNUWUxFIGlkPWtub3hfc3R5bGUgdHlw
ZT10ZXh0L2Nzcz5QIHsNCglNQVJHSU4tQk9UVE9NOiA1cHg7IEZPTlQtU0laRTogMTBwdDsgRk9O
VC1GQU1JTFk6IEFyaWFsLCBhcmlhbDsgTUFSR0lOLVRPUDogNXB4DQp9DQo8L1NUWUxFPg0KDQo8
TUVUQSBjb250ZW50PUlFPTUgaHR0cC1lcXVpdj1YLVVBLUNvbXBhdGlibGU+DQo8TUVUQSBuYW1l
PUdFTkVSQVRPUiBjb250ZW50PSJNU0hUTUwgMTEuMDAuOTYwMC4xODczOSI+PC9IRUFEPg0KPEJP
RFkgYmdDb2xvcj0jZmZmZmZmIHRleHQ9IzAwMDAwMD4NCjxQPjwvUD4NCjxQPkRlYXImbmJzcDsg
Um9iZXJ0LDwvUD4NCjxQPiZuYnNwOzwvUD4NCjxQPiZuYnNwOyZuYnNwOyBUaGFua3MgYSBsb3Qg
Zm9yIHlvdXIgZmVlZGJhY2suIEl0IGdhdmUgbWUmbmJzcDtvdGhlciBrZXkgYXJlYXMgdG8gYmUg
Y29uc2lkZXJlZCB3aGljaCBjYW4gYmUmbmJzcDtpbXBhY3RlZCBkdWUgdG8gdGhlIHN1Z2dlc3Rl
ZCBpZGVhLjwvUD4NCjxQPiZuYnNwOzwvUD4NCjxQPiZuYnNwOyZuYnNwOyBXaXRoIHJlc3BlY3Qg
dG8mbmJzcDtmaXJzdCBmZWVkYmFjaywgSSB0aGluayB0aGVyZSBpcyBzbGlnaHQgZGlmZmVyZW5j
ZSBpbiZuYnNwO3N1Z2dlc3RlZCBpZGVhJm5ic3A7YW5kIHRoYXQmbmJzcDtpcyZuYnNwOyI8U1RS
T05HPk1vZGVsIHRoZSBmb3JtdWxhIGFzIHNjaGVtYSwgbm90IGFzIERhdGE8L1NUUk9ORz4iLiZu
YnNwOyZuYnNwO1NvIGl0J3MgZ2V0dGluZyBzdGF0aWNhbGx5IGluY2x1ZGVkIGF0IHNlcnZlciBh
bmQgbm90IHByb2dyYW1tZWQgZHluYW1pY2FsbHkuPC9QPg0KPFA+Jm5ic3A7Jm5ic3A7IEFzIEkg
dGhpbmsgPFNUUk9ORz4iTW9kZWxpbmcgZm9ybXVsYSI8L1NUUk9ORz4gYXMgRGF0YSBtYXkgaGF2
ZSBzZWN1cml0eSBpbXBsaWNhdGlvbnMuJm5ic3A7IDwvUD4NCjxQPiZuYnNwOzwvUD4NCjxQPiZu
YnNwOyZuYnNwOyZuYnNwO0kmbmJzcDthbSBnb2luZyB0aHJvdWdoIHRoZSZuYnNwO2ZlZWRiYWNr
cyBwcm92aWRlZCBpbiBkZXRhaWxzLCBJIHdpbGwmbmJzcDtjaGVjayBhbmQgY29tZSBiYWNrIHRv
IHRoaXMuPC9QPg0KPFA+Jm5ic3A7PC9QPg0KPFA+UmVnYXJkczwvUD4NCjxQPlN1ZGhhbnNodTwv
UD4NCjxQPiZuYnNwOzwvUD4NCjxQPi0tLS0tLS0tLSA8Qj5PcmlnaW5hbCBNZXNzYWdlPC9CPiAt
LS0tLS0tLS08L1A+DQo8UD48Qj5TZW5kZXI8L0I+IDogUm9iZXJ0IFdpbHRvbiZuYnNwOyZsdDty
d2lsdG9uQGNpc2NvLmNvbSZndDs8L1A+DQo8UD48Qj5EYXRlPC9CPiA6IDIwMTctMDktMTMgMTU6
MTEgKEdNVCs1OjMwKTwvUD4NCjxQPjxCPlRpdGxlPC9CPiA6IFJlOiBbbmV0bW9kXSBkcmFmdC1z
cml2YXN0YXYtbmV0bW9kLWZvcm11bGFlLTAwPC9QPg0KPFA+PEI+VG8gOiA8L0I+U3VkaGFuc2h1
IEt1bWFyIFNyaXZhc3RhdiZsdDtzay5zcml2YXN0YXZAc2Ftc3VuZy5jb20mZ3Q7LCBudWxsJmx0
O25ldG1vZEBpZXRmLm9yZyZndDs8L1A+DQo8UD48Qj5DQyA6IDwvQj5LQVJUSElLRVlBTiBTVUJS
QU1BTklBTSZsdDtrYXJ0aGlrZXlhbi5zQHNhbXN1bmcuY29tJmd0OywgY3BncyAuJmx0O2NwZ3NA
c2Ftc3VuZy5jb20mZ3Q7PC9QPg0KPFA+Jm5ic3A7PC9QPg0KPFA+SGkgU3VkaGFuc2h1LDwvUD4N
CjxQPjxCUj48L1A+DQo8UD5UaGFua3MgZm9yIHBvc3RpbmcgdGhpcy48QlI+PC9QPg0KPFA+PEJS
PjwvUD4NCjxQPlRoZSBwcmVtaXNlIG9mIHdoYXQgeW91IGFyZSB0cnlpbmcgdG8gYWNoaWV2ZSBo
ZXJlIGlzIGludGVyZXN0aW5nLiZuYnNwOyBNeSBpbnRlcnByZXRhdGlvbiBpcyB0aGF0IHlvdXIg
aWRlYSBpcyB0byBhbGxvdyBhIE5FVENPTkYvUkVTVENPTkYgc2VydmVyL2RldmljZSB0byB0YWtl
IGV4aXN0aW5nIGRhdGEgaW4gdGhlIG9wZXJhdGlvbmFsIHN0YXRlIGRhdGEgdHJlZSBhbmQgdG8g
Y29uc3RydWN0IG5ldyBkZXJpdmVkIGRhdGEgKG9yIHBlcmhhcHMganVzdCBtZXRhZGF0YSkgYnkg
ZXhlY3V0aW5nIGEgY2xpZW50IGRlZmluZWQgYWxnb3JpdGhtIHRoYXQgaXMgZGVzY3JpYmVkIHZp
YSBleHRlbnNpb25zIHN0YXRlbWVudHMgdG8gWUFORy48L1A+DQo8UD48QlI+PC9QPg0KPFA+VGhp
cyBicm9hZGx5IHNlZW1zIGEgcmVhc29uYWJsZSBpZGVhIHRvIG1lLCBidXQgSSdtIG5vdCBzdXJl
IHRoYXQgSSB3b3VsZCBpbXBsZW1lbnQgaXQgaW4gcXVpdGUgdGhlIHNhbWUgd2F5LCBhbmQgSSd2
ZSBwdXQgZm9yd2FyZCBzb21lIG90aGVyIHBvaW50cyBvciBpc3N1ZXMgdGhhdCB5b3UgbWF5IHdh
bnQgdG8gY29uc2lkZXIuPEJSPjwvUD4NCjxQPjxCUj48L1A+DQo8UD4xKSBJbiBwYXJ0aWN1bGFy
LCByYXRoZXIgdGhhbiBtb2RlbGluZyB0aGUgZXhwcmVzc2lvbiBkaXJlY3RseSBpbiBZQU5HIHVz
aW5nIFlBTkcgZXh0ZW5zaW9ucywgd2hpY2ggZWZmZWN0aXZlbHkgbWFrZXMgdGhlIGV4cHJlc3Np
b24gbG9vayBsaWtlIHF1aXRlIGEgdmVyYm9zZSBhYnN0cmFjdCBzeW50YXggdHJlZSwgSSB0aGlu
ayB0aGF0IHlvdSBtYXkgYmUgYmV0dGVyIG9mZiBkZWZpbmluZyBhIHNlcGFyYXRlIGV4cHJlc3Np
b24gbGFuZ3VhZ2UsIHNpbWlsYXIgdG8gaG93IFhwYXRoIGlzIHVzZWQgdG9kYXkuJm5ic3A7IFBy
b2JhYmx5IGl0IGNvdWxkIGJlIHJlbGF0ZWQgdG8gWHBhdGgsIHBlcmhhcHMgaXQgY291bGQgYmUg
YSBzdXBlcnNldC48L1A+DQo8UD48QlI+PC9QPg0KPFA+RS5nIC50byB0YWtlIHlvdXIgZXhhbXBs
ZSBpbiAzLjEwLCBJIHRoaW5rIHRoYXQgaXQgd291bGQgYmUgYmV0dGVyIGlmIHRoZSBleHByZXNz
aW9uIHdhcyB3cml0dGVuIG1vcmUgbGlrZSBhIG5vcm1hbCBtYXRoZW1hdGljYWwgZXhwcmVzc2lv
bi4mbmJzcDsgRS5nLiBJIHRoaW5rIHRoYXQgdGhlIGZvbGxvd2luZyB3b3VsZCBiZSBlYXNpZXIg
dG8gcmVhZC91bmRlcnN0YW5kLiZuYnNwOyBPYnZpb3VzbHkgYW4gaW1wbGVtZW50YXRpb24gbmVl
ZHMgdG8gcGFyc2UgdGhlIGV4cHJlc3Npb24sIGJ1dCB0aGF0IHNob3VsZG4ndCBiZSB0b28gZGlm
ZmljdWx0LCBhbmQgdGhleSB3b3VsZCBuZWVkIHRvIHdyaXRlIGNvZGUgdG8gaW50ZXJwcmV0IHRo
ZSBleHByZXNzaW9uIGFueXdheS4gPEJSPjwvUD48UFJFIHN0eWxlPSJXT1JELVdSQVA6IGJyZWFr
LXdvcmQ7IFdISVRFLVNQQUNFOiBwcmUtd3JhcDsgV09SRC1TUEFDSU5HOiAwcHg7IFRFWFQtVFJB
TlNGT1JNOiBub25lOyBGT05ULVdFSUdIVDogbm9ybWFsOyBDT0xPUjogcmdiKDAsMCwwKTsgRk9O
VC1TVFlMRTogbm9ybWFsOyBPUlBIQU5TOiAyOyBXSURPV1M6IDI7IExFVFRFUi1TUEFDSU5HOiBu
b3JtYWw7IFRFWFQtSU5ERU5UOiAwcHg7IGZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsg
Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4
OyB0ZXh0LWRlY29yYXRpb24tc3R5bGU6IGluaXRpYWw7IHRleHQtZGVjb3JhdGlvbi1jb2xvcjog
aW5pdGlhbCI+ICAgY29udGFpbmVyIGZvcm11bGEgew0KICAgICAgbGVhZiBhIHsNCiAgICAgICAg
IHR5cGUgaW50MzI7DQogICAgICB9DQogICAgICAuLi4gbGVhdmVzIGIgdG8gZCBkZWZpbmVkIHNp
bWlsYXJseSAuLi4NCiAgICAgIGxlYWYgZSB7DQogICAgICAgICB0eXBlIGludDMyOw0KICAgICAg
fQ0KICAgICAmbmJzcDttdDptYXRoIHggew0KICAgICAgICBsZWFmIHggew0KICAgICAgICAgIHR5
cGUgaW50MzI7DQogICAgICAgICAgbXQ6ZXhwcmVzc2lvbiIoKGErYikgLSAoYy1kKS8oZSoxMDAp
KSI7DQogICAgICAgIH0NCiAgICAgIH0NCjwvUFJFPg0KPFA+MikgSSB0aGluayB0aGF0IHRoZXJl
IGFyZSBzb21lIHF1ZXN0aW9ucyBhYm91dCBob3cgdGhlc2UgZXhwcmVzc2lvbnMgd291bGQgZ2V0
IHByb2dyYW1tZWQgaW50byB0aGUgZGV2aWNlLiZuYnNwOyBBcmUgdGhleSBzdGF0aWNhbGx5IGlu
Y2x1ZGVkIGFzIHBhcnQgb2YgdGhlIHNjaGVtYSBsb2FkZWQgYnkgdGhlIE5FVENPTkYvUkVTVENP
TkYgc2VydmVyPyZuYnNwOyBPciBhcmUgdGhleSBwcm9ncmFtbWVkIGR5bmFtaWNhbGx5IHZpYSB0
aGUgTkVUQ09ORi9SRVNUQ09ORiBjbGllbnQuJm5ic3A7IEZvciB0aGUgbGF0dGVyIGNhc2UgaXQg
d291bGQgYmUgbmVjZXNzYXJ5IHRvIGVpdGhlciBkZWZpbmUgbmV3IFJQQyBvcGVyYXRpb25zLCBv
ciBwZXJoYXBzIGJldHRlciBhIGNvbmZpZ3VyYXRpb24gYW5kIG9wZXJhdGlvbmFsIFlBTkcgZGF0
YSBtb2RlbCB0byBtYW5hZ2UgdGhlIGV4cHJlc3Npb25zLjwvUD4NCjxQPjxCUj48L1A+DQo8UD4z
KSBJIHRoaW5rIHRoYXQgaXQgd291bGQgYWxzbyBuZWVkIHRvIGJlIGNvbnNpZGVyZWQgd2hldGhl
ciB0aGUgY29uc3RydWN0ZWQgZXhwcmVzc2lvbiB2YWx1ZXMgYXJlIHJlcHJlc2VudGVkIGFzIG5l
dyBub2RlcyBpbiB0aGUgWUFORyBzY2hlbWEgKHdoaWNoIHdvdWxkIHByb2JhYmx5IHByZXZlbnQg
dGhlbSBmcm9tIGJlIGNvbnN0cnVjdGVkIGR5bmFtaWNhbGx5KSwgb3IgcGVyaGFwcyB0aGV5IHNo
b3VsZCBtYWtlIHVzZSBvZiBZQU5HIG1ldGFkYXRhIChSRkMgNzk1MikgaW5zdGVhZCBzbyB0aGF0
IHRoZSBiYXNlIHVuZGVybHlpbmcgc2NoZW1hIGlzbid0IGNoYW5nZWQuPEJSPjwvUD4NCjxQPjxC
Uj48L1A+DQo8UD40KSBBbnkgc29sdXRpb24gc2hvdWxkIHByb2JhYmx5IGFsc28gY29uc2lkZXIg
aG93IGl0IHdvdWxkIGludGVyLW9wZXJhdGUgd2l0aCB0aGUgd29yayBjdXJyZW50bHkgYmVpbmcg
ZG9pbmcgaW4gTkVUQ09ORiBvbiBZQU5HIHB1c2ggYW5kIHJlbGF0ZWQgdGVjaG5vbG9naWVzLjxC
Uj48L1A+DQo8UD48QlI+PC9QPg0KPFA+NSkgVGhleSBtYXkgYmUgc2VjdXJpdHkgaW1wbGljYXRp
b25zIG9mIGFsbG93aW5nIGEgY2xpZW50IHRvIGV4ZWN1dGUgYXJiaXRyYXJpbHkgY29tcGxleCBl
eHByZXNzaW9ucyB3b3VsZCBtYXkgZGVncmFkZSB0aGUgcGVyZm9ybWFuY2Ugb2YgdGhlIHN5c3Rl
bSwgYWx0aG91Z2ggcGVyaGFwcyB0aGUgbWVtb3J5IGFuZCBjcHUgYXZhaWxhYmxlIHRvIGV4ZWN1
dGUgdGhlIGV4cHJlc3Npb25zIGNvdWxkIGJlIGxpbWl0ZWQuPC9QPg0KPFA+PEJSPjwvUD4NCjxQ
PkkgaG9wZSB0aGUgYnJpZWYgZmVlZGJhY2sgaXMgdXNlZnVsLiZuYnNwOyBJJ20gbm90IHN1cmUg
aG93IGZhbWlsaWFyIHlvdSBhcmUgd2l0aCB0aGUgSUVURiBwcm9jZXNzLCBidXQgcGxlYXNlIG5v
dGUgdGhhdCB0aGVzZSBjb21tZW50cyBqdXN0IHJlcHJlc2VudCBteSBwZXJzb25hbCBvcGluaW9u
IGFuZCBkbyBub3QgbmVjZXNzYXJpbHkgcmVmbGVjdCB0aG9zZSBvZiB0aGUgd2lkZXIgcGFydGlj
aXBhbnRzIGluIHRoZSBORVRNT0QgV0cuIE90aGVyIG9waW5pb25zIG1heSwgYW5kIGluIG15IGV4
cGVyaWVuY2UgcHJvYmFibHkgd2lsbCwgZGlmZmVyIDotKTxCUj48L1A+DQo8UD48QlI+PC9QPg0K
PFA+VGhhbmtzLDxCUj5Sb2I8L1A+DQo8UD48QlI+PC9QPjxCUj4NCjxESVYgY2xhc3M9bW96LWNp
dGUtcHJlZml4Pk9uIDEzLzA5LzIwMTcgMDg6MzAsIFN1ZGhhbnNodSBLdW1hciBTcml2YXN0YXYg
d3JvdGU6PEJSPjwvRElWPg0KPEJMT0NLUVVPVEUgY2l0ZT1taWQ6MjAxNzA5MTMwNzMwMzRlcGNt
czVwM2JhNWUyYTBjMTgwZDhjZDlmNDQ2NGQ4ZTU5MjFkMTA2QGVwY21zNXAzIHR5cGU9ImNpdGUi
Pg0KPE1FVEEgY29udGVudD1JRT01IGh0dHAtZXF1aXY9WC1VQS1Db21wYXRpYmxlPg0KPE1FVEEg
Y29udGVudD1JRT01IGh0dHAtZXF1aXY9WC1VQS1Db21wYXRpYmxlPg0KPFNUWUxFIGlkPWtub3hf
c3R5bGUgdHlwZT10ZXh0L2Nzcz5QIHsNCglNQVJHSU4tQk9UVE9NOiA1cHg7IEZPTlQtU0laRTog
MTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsLCBhcmlhbDsgTUFSR0lOLVRPUDogNXB4DQp9DQo8L1NU
WUxFPg0KDQo8TUVUQSBjb250ZW50PUlFPTUgaHR0cC1lcXVpdj1YLVVBLUNvbXBhdGlibGU+DQo8
TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250ZW50PUFjdGl2ZVNxdWFyZT4NCjxQPjxTUEFOIHN0eWxl
PSJGT05ULUZBTUlMWTogQ291cmllciI+RGVhciBORVRNT0QgVGVhbSw8L1NQQU4+PC9QPg0KPFA+
PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiBDb3VyaWVyIj48L1NQQU4+Jm5ic3A7PC9QPg0KPFA+
PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiBDb3VyaWVyIj4mbmJzcDsmbmJzcDtJIGhhdmUgc3Vi
bWl0dGVkIGEmbmJzcDtkcmFmdCZuYnNwO2ZvciZuYnNwO25ldyBZQU5HIG1vZHVsZSZuYnNwO3Ro
YXQgZGVmaW5lcyZuYnNwO25ldyBZQU5HIGV4dGVuc2lvbiZuYnNwO3N0YXRlbWVudHMgYW5kIG1l
dGhvZCB0byZuYnNwO21vZGVsIHRoZSZuYnNwO2Zvcm11bGFlL0tQSSdzLjwvU1BBTj48L1A+DQo8
UD48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6IENvdXJpZXIiPiZuYnNwOyBSZXF1ZXN0IHlvdSZu
YnNwO3RvIHBsZWFzZSBjaGVjayBhbmQgcHJvdmlkZSB5b3VyIGNvbW1lbnRzLjwvU1BBTj48L1A+
DQo8UD48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6IENvdXJpZXIiPjwvU1BBTj4mbmJzcDs8L1A+
DQo8UD48U1RST05HPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogQ291cmllciI+RHJhZnQgRGV0
YWlsczo8L1NQQU4+PC9TVFJPTkc+PC9QPg0KPFA+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiBD
b3VyaWVyIj5OYW1lOiBkcmFmdC1zcml2YXN0YXYtbmV0bW9kLWZvcm11bGFlPEJSPlJldmlzaW9u
OiAwMDxCUj5UaXRsZTogWUFORyBleHRlbnNpb24gU3RhdGVtZW50cyBmb3IgZm9ybXVsYWUgbW9k
ZWxpbmc8QlI+RG9jdW1lbnQgZGF0ZTogMjAxNy0wOS0xMjxCUj5Hcm91cDogSW5kaXZpZHVhbCBT
dWJtaXNzaW9uPEJSPlBhZ2VzOiAyODxCUj5VUkw6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvU1BBTj48QSBocmVmPSJo
dHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc3JpdmFzdGF2LW5ldG1v
ZC1mb3JtdWxhZS0wMC50eHQiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+PFNQQU4gc3R5bGU9IkZP
TlQtRkFNSUxZOiBDb3VyaWVyIj5odHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv
ZHJhZnQtc3JpdmFzdGF2LW5ldG1vZC1mb3JtdWxhZS0wMC50eHQ8L1NQQU4+PC9BPjxTUEFOIHN0
eWxlPSJGT05ULUZBTUlMWTogQ291cmllciI+PEJSPlN0YXR1czombmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9TUEFOPjxBIGhyZWY9Imh0dHBzOi8vZGF0
YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNyaXZhc3Rhdi1uZXRtb2QtZm9ybXVsYWUvIiBt
b3otZG8tbm90LXNlbmQ9InRydWUiPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogQ291cmllciI+
aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc3JpdmFzdGF2LW5ldG1vZC1m
b3JtdWxhZS88L1NQQU4+PC9BPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogQ291cmllciI+PEJS
Pkh0bWxpemVkOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+PEEg
aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNyaXZhc3Rhdi1uZXRtb2Qt
Zm9ybXVsYWUtMDAiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+PFNQQU4gc3R5bGU9IkZPTlQtRkFN
SUxZOiBDb3VyaWVyIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc3JpdmFzdGF2
LW5ldG1vZC1mb3JtdWxhZS0wMDwvU1BBTj48L0E+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiBD
b3VyaWVyIj48QlI+SHRtbGl6ZWQ6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IDwvU1BBTj48QSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2Ry
YWZ0LXNyaXZhc3Rhdi1uZXRtb2QtZm9ybXVsYWUtMDAiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+
PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiBDb3VyaWVyIj5odHRwczovL2RhdGF0cmFja2VyLmll
dGYub3JnL2RvYy9odG1sL2RyYWZ0LXNyaXZhc3Rhdi1uZXRtb2QtZm9ybXVsYWUtMDA8L1NQQU4+
PC9BPjwvUD4NCjxQPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogQ291cmllciI+PC9TUEFOPiZu
YnNwOzwvUD4NCjxQPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogQ291cmllciI+UmVnYXJkczwv
U1BBTj48L1A+DQo8UD48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6IENvdXJpZXIiPlN1ZGhhbnNo
dTwvU1BBTj48L1A+DQo8SU1HIHN0eWxlPSJESVNQTEFZOiBub25lIiBib3JkZXI9MCBzcmM9Imh0
dHA6Ly9leHQuc2Ftc3VuZy5uZXQvbWFpbC9leHQvdjEvZXh0ZXJuYWwvc3RhdHVzL3VwZGF0ZT91
c2VyaWQ9c2suc3JpdmFzdGF2JmFtcDtkbz1iV0ZwYkVsRVBUSXdNVGN3T1RFek1EY3pNRE0wWlhC
amJYTTFjRE5pWVRWbE1tRXdZekU0TUdRNFkyUTVaalEwTmpSa09HVTFPVEl4WkRFd05pWnlaV05w
Y0dsbGJuUkJaR1J5WlhOelBXNWxkRzF2WkVCcFpYUm1MbTl5WndfXyIgd2lkdGg9MCBoZWlnaHQ9
MCBtb3otZG8tbm90LXNlbmQ9InRydWUiPjxCUj4NCjxGSUVMRFNFVCBjbGFzcz1taW1lQXR0YWNo
bWVudEhlYWRlcj48L0ZJRUxEU0VUPiA8QlI+PFBSRSB3cmFwPSIiPl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQo8QSBj
bGFzcz1tb3otdHh0LWxpbmstYWJicmV2aWF0ZWQgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9y
ZyI+bmV0bW9kQGlldGYub3JnPC9BPg0KPEEgY2xhc3M9bW96LXR4dC1saW5rLWZyZWV0ZXh0IGhy
ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIj5odHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvQT4NCjwvUFJFPjwvQkxPQ0tR
VU9URT48QlI+PHRhYmxlIGlkPWNvbmZpZGVudGlhbHNpZ25pbWc+PHRyPjx0ZD4NCjwhLS08cD4m
IzEwOzxpbWcgYm9yZGVyPSIwIiBzcmM9Imh0dHA6Ly93d3cuc2Ftc3VuZy5uZXQvcHRfaW1hZ2Vz
L1BDTC9zZWN1cml0eWltYWdlL01TSV8yMDE0MDUxOTAwMzczMjIxNC5naWYiLz48L3A+JiMxMDst
LT4NCjxwPjxpbWcgYm9yZGVyPSIwIiBzcmM9ImNpZDpYT0swTEs3Q1Q5U1pAbmFtby5jby5rciIv
PjwvcD4gDQo8L3RkPjwvdHI+PC90YWJsZT48L0JPRFk+PC9IVE1MPjxpbWcgc3JjPSdodHRwOi8v
ZXh0LnNhbXN1bmcubmV0L21haWwvZXh0L3YxL2V4dGVybmFsL3N0YXR1cy91cGRhdGU/dXNlcmlk
PXNrLnNyaXZhc3RhdiZkbz1iV0ZwYkVsRVBUSXdNVGN3T1RFMU1UUXlPRFU1WlhCamJYTTFjRFV5
Tm1JNVpESXhZalUxWkdSa09HWXdaV0l4TTJWa1ptVmpOakpsWm1ObVppWnlaV05wY0dsbGJuUkJa
R1J5WlhOelBXNWxkRzF2WkVCcFpYUm1MbTl5WndfXycgYm9yZGVyPTAgd2lkdGg9MCBoZWlnaHQ9
MCBzdHlsZT0nZGlzcGxheTpub25lJz4=
--=_NamoWEC-i81mnnsa33
Content-Type: image/png; name="201602111742151_N3WZA6X7.png"
Content-Transfer-Encoding: base64
Content-ID: 

iVBORw0KGgoAAAANSUhEUgAAAggAAADICAIAAAAC6Y6pAAAACXBIWXMAAAsTAAALEwEAmpwYAAAK
T2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AU
kSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXX
Pues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgAB
eNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAt
AGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3
AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dX
Lh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+
5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk
5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd
0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA
4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzA
BhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph
CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5
h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+
Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhM
WE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQ
AkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+Io
UspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdp
r+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZ
D5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61Mb
U2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY
/R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllir
SKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79u
p+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6Vh
lWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1
mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lO
k06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7Ry
FDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3I
veRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+B
Z7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/
0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5p
DoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5q
PNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIs
OpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5
hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQ
rAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9
rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1d
T1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aX
Dm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7
vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3S
PVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKa
RptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO
32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21
e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfV
P1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i
/suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8
IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADq
YAAAOpgAABdvkl/FRgAAeCJJREFUeNrsvU1sG8fWJtxjWzdqBjINMoEvDNIXNw4VYCCLeD0bAsRg
TC0GsLjwhgt5QS7DLCJAwAgCZF2tFEUYQcBooAzg9pJcSMDLjRdkgG8hevES4CxeYyhrMSHjzMRs
GPHnkGPKE7Zz9cn3WzxX55arqotNUvJPUgdBYNPd1adOVZ2/OvXUv/nb3/5maNKkSZMmTcd0RotA
kyZNmjRpw6BJkyZNmrRh0KRJkyZN2jBo0qRJkyZtGDRp0qRJkzYMmjRp0qRJGwZNmjRp0qQNgyZN
mjRp0oZBkyZNmjRpw6BJkyZNmrRh0KRJkyZN2jBo0qRJk6Z3mM7+3//7f/8fgUZGRnZ2dp4+ffpv
/+2/fcMMNRqNYDDY1yu2bY+MjIyMjAz2RcuydnZ2/vVf//Xf//t/L3JSrVY3Nzf/3b/7dz6fj/2n
tbU17sc3KSJ8/b//9/++s7PDsf3bpnK5/N/+23/7j//xP76taek4ztOnT8+fP+/xxUKhcO/evVMd
owGWzFuhVqv1X//rf713796//uu/3rt3T7qm/vznP/fVF1r78/Pz58+fD4VCivUy/GodjEmPWuh/
/+//rdC3w4yyd7bpyXMbGxv4aX5+PplMJhIJ/LVarb75qWNZVjAYjEQiffXZsqzFxUXTNAf4om3b
jUYjnU5Ho1FOAVWr1cXFRelbkUiE5Pbm6e1+/XdINBkcx/n666+TyaRUAb1d3t59Me7t7bVarZWV
lcGWqnrtv+8rIpvNnqxiHJLerVRSu90ewA0Z5ouO4xiGIa7zIZvV9FsimgzdbhcT5h3k7b2gYDB4
Ulbhd7VIB1CMQ9I5tTe9trbWarVM08xkMpFIxHGcXC7XaDSgTNPptBiblMvlYrGIB1KpVCgUqlar
xWIRKwpBSbVaLRQKsVgMcUkkEslms5ZltY4pm80Wi8VyuYzJlEqlIpFIoVCo1Wrj4+O1Wg1NhUKh
QqFgGMba2lo2m63X69wrHG9sm4lEIhgMWpaF11OpVCwWY70wRFGpVAoJAfQarJKr4jhOoVCwbdsw
jGg0mk6nRRmqH1hbWzNN03GcVqsFkebzedu2SbwkT3w9k8nYto2vS0etZ4NSlkRpSx8TmTFNkx3x
Vqs1NTWFIeYGneOzWq2Wy2WsbZoqYB5yo1nXarXQBakJh3XH3MBfE4lEMpkUZ0ssFlteXp6bm0Mj
GETOgRW5ajQaNBkoO+Q4DiYkuDJNE+0bhpHP5/FFyAfmZHNzE09CFOANY2GaZjabrVar1WpVvdBE
4di2TbytrKyo1yY7oMSwZVmO46DB27dv7+7uqldQo9EoFArQCWiBY9VtHG3bxiTBmioUCouLi8Fg
kMTFjuwAa9+yLCxhcYq6eYRe5gzmrZRJqdLjFmkoFLJtO5lMsrNFqgcQEyQSibW1tUgk0m63af1C
4H0pRgXb4uvSJ8+oDUMqldrY2AgGg+h2oVBot9uLi4sbGxumaebzeXHeFIvFZDK5srIC0WMmTU1N
bWxspFKpYrHIJqk2NjbS6XSj0ajVatlsNhgMxmKxbDZbLpfL5XI2m93Y2IjFYrlcDmsVC3JjYyOR
SBSLRUxEwzCgJcvlcjqd3tjYCIVCuVxOHDxqE9IMBAKI4BYXF8kqYJbEYrFgMMjGpyyrrJTxT3Nz
c7VaDRJnJ18+n0ecu7i4SGtDdHzS6fTi4mKr1bp7924qlcKfq9Uq5IlOsUqqpyfl1qCUpUajIYpO
7JqUGfyIeRIKhWAJoIMw6JjKrNAgmWKxODk5ifZbrRaJrtVqibPOMIyVlRU8Kfa3Wq3W63VMS6gG
rEButmBNEie1Wi0ajbJWQcoVOxkwzVKpFDW4sbGxsrJCrJbL5VqtNjc3Nzc312g0dnd30Ww0GiU2
ICLHcWKxGLoJDeJloXHCYXmrVqu2bS8uLmLplUol0SsSGUabeAtGUVx0rHxyuRxYHR8fh4HM5XJg
dWVlBSrGjdVkMglWyWKVy+V6vT43N4d3xXXqce2TAfO+XjzOGcdxpEyKSk/6UTQVi8W86AFWznNz
c7RmB1CMbmxLX5c+qTIM0WgUEo9Go7ZtO45Tq9UwEWGXbNuGNInq9ToUq2mai4uLc3Nz9XodltAw
jFgsFo1GSWrQxUjuc7ESFi2+jnf39vbg6eCt8fFxKCB6BSscnlc6nRZHEcyjzVQqZZqm932UZDIp
ZdXn87VarUKhgBnP+cX1er3VauFdDK30i+Pj46FQKBgM+ny+UCiEP0PJYrDxXdZ0qUnRoJQlqejE
rkmZqdfroVAIf4VUIWrTNCGNSCQSjUYxfOxgraysgA1w2O12WebZWddoNGKxmGma9CGOEokElB2N
EZSvOFsikQgNQa1Wm5yc9MiVNCk8NzeHt6LRKL5Yq9UikQje3djYQFMkCnbSEm/oLK0Fx3EUC40T
jqhQEO4sLi6KPqmUYbSJD7ktOnY+w54ZhgE9CLWI4Ns0zVQq1Wq1YHrVrLLLPBQKkYgGW/vc9puX
9eJ9zkiZ9PhR/OhRD7BvmaaJNct107twvMtW+qQqlcRlA7FIisUia+64lKvjOGIAGwgE2DbpFUW2
EWuDczOhrdxeCYVCyWSyVqsVCgXkqeBQsJywO8w+n897vtiN1enpaRiYarUKBtjoG+1vbm66RZ2I
V9jGxQ/BE4RABuCWa1DKklR00q6JzCBXwA0QtBvlXrB4xHgUy4PSiYpZR5PKrawCCpHzVMTZEo1G
2fCFqzhQcCWdohjHRqNBnrXjOGK2QTpp2R+5BxQLTbFkEolEt9ullBQSej0ZZtt0W3QcD+xyhrRp
UNBUT1al6oLkNsDaH2y9eJwzUiY9fpQVCLfoBtA2fQnHu2ylT57zvh2Bb4sFPFyXuPAzFAqxfofj
OF5mDGwXbCwRUgpqLwCLAXk0ilSIE5a3brc7/D4Y8nSpVArJk1wux0YqaF8sw5D6HW4TDpo6EAis
rKwsLy8PybCCJVF0XNeQhOWYCYVCyC+zSg3ePfxTt2TX5uYmPKPFxUUxJ8nNOjj7oiNCE6PRaCA0
SSQSitbgLGNCitPYO1dY5+hmKpWizS1x/g9AXhaaW1ybTCaR3ikWi4hd1Az3XHTi5Gm325weabVa
7Oh4X1amaZJSZv3FAdZ+v+ulrzkjMtnXR90W3WDr16NwvMu2VquJT57pi6dIJFIqlTD1C4XC8vIy
JykEMphz+Xx+eXkZ6hi/VKtVhC1unwgEAmgwGo0iqY235ufnWe3DqWb0h30MbLCuDdpETpz2DxWc
BINBRRqB3enF9jUCMc6fHR8fN00TKXvHcTY3N/Gwd7JtOxgMYsGLuyYDkJQlqejErkmZGR8fJy+7
XC5j+PAjBh0lDJwawrdge/b29txSDTTrqtUqNt+kMXij0YC+m5ycFPWdGDTUarV6vS6OvhtXNBlo
soGZaDSKqJS4ikajjUYDziMJcIDF33OhiRO1UChQqQgGkZ2NbgxzklEvOkweGuv5+XkYbLje2FMM
BoP4uhfCWOArFB4NsPYHWC/e54yUyb4W6fB6YADF6F220ifP9cVfJpPJ5XJra2sYFRSlcOm2ZDKJ
KBgPoMSC4mKqSnJTW8VisdVqzc3NdbtdEh/yGNLYEAn0zc3NdDqdSCTolUQiwa18xNp4AJ4+5+1y
HSkWizjboRAIagaQM6HdMHaFZ7NZxQM9KZFI2LYNHwQVIKgvGsbjEFkKBoOtVosTXTAY5B6DD8Ix
Q+UchUKBGItEIig0oC1fLkiKxWK1Wg3BNbw27E65zTrLsjDrpH1PpVK5XG5+fh4pFHHrixtZKBQx
TeTGFU2GlZUVJKO63S7Nc+x8YPcS44UWILSehmqwhSZOVFQl4RWk+9lXoLlEht0WCC06bvJkMhma
FXgA1Qo0Oul02rtfnEgkaOLRyErZ6Ln2+10v3ueMlMm+FunwemAAxehdtij84578N3/7298MTZpO
iLhjku8m5fP5QCCgNvmaNP2eSWMlaRqKKKVAKcQ3eT5zAELZjPcSL02afod0TotA0zAUi8Xq9TqS
J8hgvDtwESJhax3llXrsNGlyI51K0qRJkyZNr5FOJWnSpEmTpoEMQ6PRmJ+fd6vRLpfLKEvw0sj8
/PzJQreiWa6+SPrj26LnOzvfXbki/offn+/s9NVa27J+uH7d7V8Pm80frl//7sqVp0tLp9Sdo07n
5f6+YRjNTOb0vnJSNICEQU+XlhRydqOTkgnYVo/1iXBFnxhYUOrvNl3QitbW1uYFsiwLdbeDaRjj
uOb4jZFaMYo0jPaDcN5Aj4w3vMeAM7SKc0+/VbowM3NhZsYwjG6l0sxkwrmcLx6HEh+gtUA2G3AH
6X1RKh02m58+eHDW7z8lq/C/EomPFhZGJybCJ3G0QtMbIMVIqafT6RGhQKJQknCnpbqPDmD2VJ1v
GJ66Xwz8YeDBs6c/TITi/kZTSd1u913emfzN0Eg4fEpWwTCMVwcHR52OFrKmd5DePDz1b4wo9Dkn
RVdWYyZLgVsNwwDYDmFCENIkGfPGMS0uLnII2DhxU61WAXmfzWapWSlcsOECKiv+yDUrQnNLIY7F
PrpBjrtJwzu9KJUQ5o9OTFz65puRcPjl/v7TpSWka8ampy9tbXGx//Pt7U/u3//h+nUYgJf7+2f9
/ktbWy/395+tryMt8Mn9+79UKj+vr0OPf7ywEMhmEbKMTky83N//eGHh2fq6Lx7vVioIa/y3btmZ
zFGn44vH4WO2LQsNGobhi8cvbW0h7fB0aelVp/NLpfKHcPji6irH8MWvvnp1cPDD9eu+ePzw8ePD
ZpO6xiZqXnz7LTp71u8P5XKd7e3nOzvoiC8ef76z075zB0HV6MTExdXVw8ePn/7lL58+eEByeFEq
/enePTZlx70yOjFBgc6T2Vn01E3OF7/6SjSoz3d2fl5fNwzjo4UFhH34hZWqdFilj3UrlZ+Wlg6b
TRjvM35/OJdTsP2PGaLs+A/Xr49cvvzr/v5Rp0MtNDOZV50OxPvBxMQfwuGRy5d/qVQoemhmMh/G
44ZhYDqpOaeZMDoxcdhsIs7o2UfDMEYuXx7Ag+SAysmTVagmFrd/fHycXfUsoClgsaGsOOR/cY0j
5RWJRPBjLBYjrHIOgR8YqyxjUo0B1HF818tlBGI8hKOjbjpH+lFRybdaLRHfe29vj1Dcz0jRlRVA
2W64r8Yx+Awdw6tWq+zZY+j6WCy2uLgoImCjEYLqZbvqhm8sBZWVAuRSs8Bp4JgX8YqlMNRSJGSF
NLzT4ePHn9y//8n9+4fN5vPt7aNO58mXX57x+z979OiT+/dfPnxIqlnybrN5cXX1s0ePRsLhZ+vr
gWz244WFkXD4s0ePDh8/frq0FMhmP3v06OLq6rP1dcog++Lxzx49GpueNgzjVafz6YMHl7a2nu/s
PF1a+nO5fGlrq1upvCiVupXKs/X1S1tbaKFbqXR2dqBBLq6ukkI86nTsTAYM/+nevZcPH/58zPCr
TudP9+5R18SslP/WLTBvZzIfXL1KHTnqdH5eXx+bnkabh81m27LA8ItjQOnn29v4hVoTX6F/7ezs
/Lq//8n9+58+eHDU6eATbmyz4oV8Atns06Wlw2YTtgRSDedyz9bXXwgA1zDV4mMwTh/G4589ehT4
4gsYJDXbIHXH/65MK5WPFhY+e/TojN//5MsviX90GX/1z8x0KxVYoMNms1up+GdmvHCOmYCZNjox
AUvgpY+DJUulQOXGMQ4g4MpxkJs9rszCU7OrHjrEDYubhdN3gy53HGdlZSWdTkN33759m0PglzKm
AEL3fhmBdA9Acb+A+FEF+D+H782iuJ8R0ZUVQNlGL2xeQiizbbvVarkdI3JDwAbGmZhZk+Ibu4HK
igC51Kwb8xxesQhD7YaE3BOp2NMOxK1bI+HwSDj8wcTEy/19LN2PFxaQFLpw61bHfUvQF4/Duxyb
noaiIfqlUhkJh6G+L8zMjE1Pd45VM6tWxqanz/r9o1ev0p/xr0cHB6z9uCBoEFYlHXU6f1xdhTt5
4dat5zs70B1okLrGvXjW70ez6AL+PDY9fdTpnPX7P33wAEIYnZj44FgZjd248eLbb6GVDptNVq+5
vcJaDjjmn9y/D+PnxjablIMAA9nsWb//Ran0olQ66/fjR188PjY9DX7EKFB8DF/8aGGBRsQL238f
JveO0zhCgB8vLMCA4dNslIbBhYGBdREjJCnnv1QqoxMTaP/i6ireUvQx8MUX6CMX+ngkKVC5cYxG
B82YSCSgGRWNYNUrYLFF5H8pdDlwFQlFnFrmgKJFxtyA0Ae7jID9luJ+Ae6jCtBvBb73ORFdWQGU
bfTC5o1Go7hKSbwFhSUpArbP55Mi67rhG0tBZaUAudSslHkpXjEHQ03IoxwSck+kYi905vXFeXRw
YBjGjzdvenn3rPut9C/399ko/uz58y+PNQ6rDs64/JmyCr8+fHh0cCD1i8kthQ5lG8Enzii3Os4w
zJ8ROvJyfx+WDIEOtuvHpqebmczRV1+9KJVEvSZ9hbZYjzqdzs4OslUU7nBsvzo4YNtkBXjm/PnD
x49hYL67coW1zZKdmE5HfAyCovbPnj9Prrcb26zeV3ScnQmUXZROjwszM09mZwPZbGdn5+JXX3nk
/KjTeW2enD/v+uTBASvV0YmJv/YfNCgQtjOZzO7uLlYiILncziqyjahhsRWqADd2qIHx3RhTAKEP
dhkBaTbF/QLiR9GgFPRb8a1zInB0LBZTAGVLgVsJKQwIZWBLgUXTFwK2G76xFFRWDZDrBiws4hWL
MNSGDAm5J1LxAITFPHxZ0ejEBKvNj15XeV4IyaULMzMj4fCnDx58f+2a2143zAP+8KrTgfYchvnD
ZvPHmzfHpqfPnj//yf37lBuBC9zZ2ens7MD17vkK0ccLCx8vLCDX8Wx9HU46xzZnn14xvXh1cDBy
+TKS+Gx+383Yi49hOBAPkQfQk+2eHWf9CZI8N/psO2fOn4fbIeaj3Dh/tr6O7RkShbqPL/f3ESsQ
VydFAH2jfdBSqSReScRRX9j1oioYhjG31ga7jIDV/or7BbiPQjtxoN89M95nRHTl8fFxBVB2T9zX
WCyGGw0VoNbeEbAV+MZSUFk1QK6UeRGvmD0DQTDUUiRk7yi4fbhL8fhZv//J7CwW+Y83b7pVgqvp
w3icEtbPd3bgafbVwq8PH46Ewx8tLHy8sAB+yAywGhMM/7S0BI3glqPoi36pVODmX1xdfVEqsWmo
C7duoVNjN254fMU4PpRw2Gye9fux4+qfmenJ9sv9fXjxT5eWjjqdsenpD+Pxl/v7YODl/v4P16+3
ZRDK0scgKOxkYBenJ9tcylHacdLISOM8XVoaCYcVOZwLt2693N932zOXco4fIYq2ZcH2KPr47PU+
nmDNzPz8PEFy+Xw+Dlqf4Km5/IRHLG5RFXgnkTEFELpax/a0c4r7BcSP4vZDj6DfhOJ+TgSOxv85
oGzSd1LgVjY/NTk5iX2YnrdNeUHAdoMLdgOV7QmQKzLP4gYD7ScWi7GPAYZ6fHxcREKWNohCBbQz
SMTg94dyuadLSwjSRycmkAcfwMBcXF39eX0dq5Sqkry3gA1SBAoXZmZeHe8TjE1PPzuuRREZpqqk
YVTAhZmZF6USHFvkr4lzfP3CzAynxBWvoKbor7OzKKk66/cjUS6yLY5FZ3v76dLSWb8/nMthK4iV
6tj0tFTDcsKnxy5tbf20tPTdlStoqifbXDZJ2nEKEJ/MziKgCSuvGEI7bl6CG+cfLyw8XVp6urRE
JsftyVAu9+TLL9k+okzuwszMxYFmMqsNWNUUiUSmpqbYBwiemtWzUlhsaSgAy+EGXa4mKWNurXG4
9OrLCDiKxWIiSL66C95BvwnF/VSwkpaXl1OpVL/3T2nS5JG+v3bt4ldf9RsAvWvUzGRQmzt8x3+4
fv3DeHxIteudvrtyRVGnq+k3QCd/wK1arfp8Pm0VNJ0SPd/ZOXP+/PtoFV7u73935QpyL91KpVup
9FW08xY73ras765cQbwI/qU75Jp+M3TCkBg4ltJzO0iTpsHox5s3X+7v9+Vlvzs0OjERyGafHede
+sKieLsd98/M/FKpIN+FRNxgdaia3hfSsNuaNGnSpOk10rDbmjRp0qTpdcPQL5TrkOWYPV/HVZF9
IdlyjaOca4DXvdObwb99K2RZ1vz8vBrimCrz3P61Wq16x0k+vbnEEmpRUO84GO6x+kW0P3BfMO1P
9kkvAhweS7/fQSEw8zeAD3/YbJ4Glvgp0TCsYhNI+k8ocpNiyCtA3c/1BeU6JKqtl9d3d3cHOzJG
MFva2g9Mtm03Gg3xHN8A5BEneRhN6n24Hcf5+uuvUUw88BcVgMnU/vsFHqyGjB5gBPsalNPGh3/v
6LNHj068TQLclP6rYperv1TSkKi2Xl5nYS36olMNEX4nhMNB74V262u4gbJ5esycdvvvC/W7Bk8V
H16TYRgAcRmAzsGLTyQSIgorp6BZVFuKnYEnBSRtBJKWZWWzWdM0OaBX9nW3MAUxMl7ESQ3Cj8Uh
OADe4ru3b9+mAyNwVdACjm8UCgW8S+i1aixxwxtiLXfmpWebOI5PsL0IhvDj4uIiJDw/Pw9n07Is
oFnhTB+9BaBgAH6IzEgxeHuCgXOdTaVSjuPg1Mza2pp4Oq9cLuMwDms2FN3HiKRSqVwuRyOFw4lA
qeRexMwhMC9CgMfEAz4M1zhEt7Gx0XMUkBIpFApoBDgzhhKXWDo5aWpx2MjUvuM4ANnlZtHa2hok
gKmbyWQikUir1crn8/goi/clvi59UgzH2aWxu7srTgB2EGnEgXbcaDQwwQjZntx/KUtij4AnSoPS
05Nl8eFZpD8AhMCTxa1QF7/6auTyZREgnT29gQalTrcIay/inL/qdJ7Mzv65XIahalsWasCera+j
PHckHP7j6qpYpAuXHJeUhHO5XyoV8XnCIT/r9wO8XYqr/92VKzj9/mE8znY/lMuNhMMiaPxhs/nk
yy/RiLRIrG1ZyE3hdOGrgwPUthnHx10pnhDh089wyoJFYeU+I6LaAtxVOvAimjf3uiJaB3ZTLpcD
zDU+kT8+zEnfZRU0CxjLtkbotVj5wLnNZrPFYlFEvpMi1lqWBcTaubk5FrHWOL4oQt0mCXZlZSWb
zZJGU0f3gO5qt9sYjna7DcUnMiPF4PUCBi6Klyzo4uIiZxWANQ8QY1JMXroP7CwWiX1yclLxIrqP
OQNF32q1Go0Gl9pih1uNYAyC15JKpUiwi4uLNM8VuMTqzBLNLmo/kUhI4dkNBgWaoONhnFZWVubm
5miApK9Ln5Q67BhQ7PFwEwCDmEwmMb25TTK4gxsbG1NTUwSDr2BJ7JF0DboRiw/PWgUoSgLSAKCs
Lx7vCZCu9po5WHsR5xxQVASU+3x7e+zGjbZltS0rnMt99ujRhVu3nszOSlHED5vNi1999dmjRwAI
4Z4HNtfo1aufPXrki8eBraLA1b8wM0MA9biwZHRi4ulf/oJesLDqQHP59MED9EIqZACdwV4C0+Wz
R49QM03IBRCIf2bms0ePcEfLy/391wyDAoVVpPHxcUXOR0Tz7jen0Wg0EolEMBjEwe5WqwX1of4u
EXxDQq+t1WqE5RuJRAgeXPwuh1jrOA78RAByQI/gYY9tGsfQ4nhGvTvHasBYLBYKhWBNa7WalBkp
Bm9PMHCFeKUElGBYC/LcPXYfAFZ4vtvt4q9uL6L76DX0+97eXigUUmS31CjxUoL+onmuwCVWtGDI
sJHd4Nkxbwm3GUifjUYDyDEYTcXr4pPqJSmdAPV6HX81TXNxcZG7YRfTgB6gEfHeo5PKfgBAHo4t
bozwApCuIA7W3hXR/dggvSiVXh0c4K9j09Pw+uHCS6GfCKle+jyYB2I5rjZR4+qPTU+/OjhAcNDZ
3gYK/YtSCb2ARw/5dCsV/61bZ/3+0YkJvzsqPssnuAJW2K/HqFwIkrqVStuycLvG6MTEOW5yeB8/
9cMimndf+36YZ2QA8C1oZI9Mco8BIpst5xD5ERFr8TvHBkCmPLbJMWOaZqPRUIhCCvALVF4oII4Z
BP4cBm9PMHA38brBHTuOQ0BdcB28dx+girZt7+3tkfpze5G6DFuYSCR64oupUeI9zg3DBZe438mP
uSHCs4uv4EkaAvxB+jo3WAqviD4hnQDq3Tt26OHVKVjqayX2SyPhsC8ef1EqjYTDuKgOWlIESPfY
oIj9LsU598/MIIP04ttvoWePOp2XpdJ3vXAACZFX+vzfccgZ/PaeuPq4Gu+M3/9yfz+Uy6GndC6S
umAYxh+OZeLlmrwz7hD9l7a2WpaFT/ji8T+urp7AyedgMEheMClNEc3bLekkJXgirVYLKmP4iQhv
i/OSpHGGiFhLiwRs0BLy2KbBYIA7jgN3WPwn9VumaUL9icyIGLw9wcD7FS+LZ06j7LH72IVCBp8u
XBJf5AIpQDEiuac+SD8kgjF1nEtODkaYG17KuvAkobmxU4t7HWkf7smePRInANDlFPvn7J9pinrv
0QnS2PT0z+vruOJpdGICO6giQPpr2tZzAOGGc37W7x+7cQOpf2CJIxT4WAZy7uaSi88jyDh8/JgM
W09cfaAcHj5+zML9Xtra4u4rBKuwaq+GQ7n3xeNoB5sNz9bX+6tKkqLaQsUgOqbydhHNW/G6dGZH
IhFkdbAwgAeutk/s5BajbNzridW4trYmVuK7IdYiG4u9Nfb2IS9tsjsuwNeNRCJoAepMkc6uVqsQ
LL47Pj4uMlOr1UQM3p5g4P2Kd3x8nAa3XC5jEL13H6kGANl6fBFlzdiBl/q5NNxeEIxZUyrtnXdc
Yre5RzZJCs/uNsMxxLSlJ30dERX3pJqkEwDjC0Hl8/nl5WV2vdD4YgsdmzFuLLlJUr0G+zAMN25g
7/TCrVuGO677Wb//l0rlqNN5ub/vHd9bgXOOLBZ7K2LbshCvPN/Z+e7KFTU4sfR5ME+I5ThtoMbV
R8z0cn8fCaizfr8vHn+2vo6NhKdLSwA89sXjz7e3D5tN6b25FEn0DK1w2gN75h/G42fOnx8Jh/uL
GAjVlvWtYrFYvV5HJB6LxeBaimje7OvJZLInMHUmkyH8WNRCqB06AoyVesoczm00GhW3PXoi1tK1
EN7bpFWHFlDvgbQVXfbkFuCbpglm6LsiM6ZpSjF4RTDwYcSLnhYKBYCf99t99JH0tfRFcesF+zFu
jioN98rKiohgLNWV3BXBrJy94xIrdHGxWOx2u6xgCZ7dbYZblkVDII4LvS59UkFSNHj8AYJCy5wQ
arUa/gl1ItKpou4ROyjLy8vc5WLeCc77850duv1UCpCOi7i/v3aNnve05eCOc44taHLMcesfae2P
FxbU0IFuzxPWOn4cm55GkZUCV39sevrw8WP63KWtrSfHoPEj4fClrS3g8tqZDH4cnZiQ7j/DoqAq
SZG7Y+HTffF4IJt9a1hJlmVNTU0Nc+DovSCuMtUjtVotac3o74ps297c3DyRDI8mNaG2+506HNq2
LGww6NF5K/R2sJKwlfp+HRPV9OZtqvq6J02/YXq+ve2/dUvL4fdlGFAwp9e8Jje/YX5+HlVJWhq/
N3pRKn135cpZv/+ChxJMTadEGnZbkyZNmjS9AxGDJk2aNGl6pw3Dy/39o+HKYPulvgBmm5nMwMC8
7xHo7m+VupVKzzo/6VuGEhb4tLl9A58e7BOQDPiUFqIMw893V65wzbLFl9znPPKActI3OYh9aYxh
JDnMJBFXhLo10tJvSKf98i//8j8/+eSvjx//TZOmUyBMsF/+5V+8v/I4nf7p9u33hds3Sa07dx79
h/9wSo03/umf/t///J+ln/s/29uDaYn/7/nzxj/90//Z3tYLYZgZzmrp//nJJ29Anmf+eqJOhyZN
w9PAWMFaMsPQUafDISsM/znAjuqBG3Ic37yWPoOY64fr1xFS/XjzJk7BPd/Zwf1K+PHl/j4OyDUz
Gfz+482biL+e7+x8f+0ansTxOZw6QVPfX7sGjFn8GQEUoiEcBqFPoDUcx/juyhWwxAaGL/f30eZ3
V648mZ096nTcWOJSSQiEwQOe56QgdoGTBv25mclwbCNMbmYy1F/pSqA4nRqRMv9sfR1HIikoZgFS
frh+nWJkOkUpMu/2ozTV5tYvSPKH69ebmQyacussO2QU5D6ZncWPxD97hxSbX+pWKpDA99euPd/Z
aWYyh80m/kDBtVTmP1y//uPNm8QJF5v3NUwit/RpUZLcPKRIn/uRxhc/AsAATWEG0iekHWEbhGSw
KtEsmwAR5Y8FSJ0SJ4D4CubS06UldoLR5/DLT6+vIOJBMdnQwadLS23L4oRP7JHYpWyLgsVyJsHS
AqdXSGOIykRsbRhJKiYJmwLivsjOcFYmbCqJvtjMZAg2nHphGMaPN2/Sh446ne+vXWPPfg+8bP9h
GIBmTlf8+OLxzx498s/MiMi0f3cBOp0/3bvHYdhykK3g1X/rFjB17Uzmg6tX8WdWzXV2dn7d3//k
/v1PHzwAo8jtAoNw9OpVVkUedTpu0LscSwoz+NmjR5e2trqVCitE2C3ACoZzuWfr6/SvkAZdcoQH
nszOAgL30wcPDMMgrJXDZhM/ihAo3Url2fo6+nVxdbVbqRCeIsc8MB2hsw6bzW6lwgKkSL08Uf6K
HrmJJZzLSaF9wfxHCwvcj9TZzs4OQQ1/GI8/XVrCbOlWKn+6dw8iUvPPgRJf2toaCYcvzMyEczlW
cbvJ/OLqqji11K9ww6TgVipefAjz8EWp1LYsBZDyq07n0wcPLm1tPd/Zebq09OdyWZyB0o7QVz59
8GAkHP55fZ1DUSbmRfmDc5q9LMay2yto8+Lq6sXjU7jSz4kryE0DgKBYLq6uYhGx06ZbqWCyXThG
r5OyLUobLf8hHMZjP6+v//rwodhTqTJxa20wSXqRgPjFcC7HznCSCcsJDvcBQPDl/j5paToLLYKT
c4pigGXLbz6zRGfQpci0eADgVoRhawiQrWgBZcj4K/4MCFlOprgx45P79y9tbQEHES7Apa0tVlgK
6F2OJTcdhPMy6CArhRelEgHS4og8wbKzssafjzqdbqUS+OILXD51cXX1sNnECOE8vfTTmFhogavO
5pgfnZgYCYdhNl6USqMTE9IrOIik8lf0SCTqlxTaFw+A548XFg6bTfxInX1RKl2YmcF8vbi6etbv
f769/aJUGrtxY3RigthQbMFxoMSiWVXLnGBt2KHva5gU3ErFe9bvP2w2ny4tjRzrJgWQMsZ39OpV
+vPfBf46go3YkXAux0K5uSVkpPJnFyCHsax4pSehg9wKctMAbgsBwg9kszB41CBg4ES2RWmzy3nk
8mX4oPQKQQNJlYlba4NJ0osEFF/kZMJygvkwOjEBYyNdthw4ufhAv8tWZRhoWcLrRPqFDdJFDFso
dAQmiJKM1yFe3eBecePoi2+//fHmTURSoxMTHy8svOp08F22tADNctC74PaMt9sB3bAMX3U6R50O
RbXksHOv4Cu/vo52iwewyM+6o9pigj5dWkKE+NoACFxduHWLcOHV4YKb/BU9kiQTGRBjii6BJPP3
tXrcL3QWM4x+fLm/zyamz5w/j6/Tj9CJrhGDAEos0gAy7+sVNbeieD9eWAAyD/Kl3UqFgJQpMUIC
PyNMIfnklHGFBfjD9evP3O+lkcrfUGIsu70y8AqSaoCe3Wxb1tOlJQ5CTmRblLbIjJQxqTJxa20w
SXqRgOKLiqH/g4uLSUTg5HDpREUxwLJlc93ycwxApsV0/+T+fbXT6ovHEZJcXF399TjQ9kgfLyx8
+uDBpw8efDAxgRAskM3+6d49mFbkVUkQrJ+CMTuRfa0zfj8sM/3HJjE4+mBigt0LOnpddaqtAnrR
M7sCX+D5zs7L/X1uvKU4w6L8++oRuyDhs9N/cCjIt8UXuclAqMi02XjG7z/r95P/TnxKmYfo1Htx
A8i8r1ek3CqmN0DHkBxAzoqAlFnpDTktKTX8x+M8jJSk8le3PMArahpAAzxdWoKLShdbKjQgJ23v
jInKRNHaMGJRSGAA/s/6/V52m8empzs7O52dHYCTS12uvpYtqy7OwDRx60GBTCuaEBGy1aM04Q3h
KtQPjy9HpQAFv1BrbtC7wxuGD+Nx3MmHln+4fl2xWwsIXKS/4NPBdKs/8evDhyPh8EcLCx8vLPSc
GWjw5/V1McYUcYal8u+rR2y/OGhfzAq6hQqd5WbY2PT0850dDBmuLRybnkYCFD+yiwQh7VGnQ/yI
oMTdSmXk8mU20zKAzPt6xY1bN/FiZw+r64zfj5bVQMp9V600m4fN5tj0NJLLlJgSUZSl8u+pUDy+
4gW0GRvXbhqAvUGB0zCjV69eXF0FVLWicVHaHmXIAmWTMlG0NoAkvehA6Re5GS4OELYWjjodvC7V
0hw4uZhj7HfZvuYpfjAxMRIO/3jzJvtVpJ8QGv9SqYxNT//qYhtgD7Gkf7h+feTyZXVOmaWPFhZG
Ll9GRUrbsrBDFchmUW/QzGQC2SyxC+hdxDs/3rw5evUqoHeHJ188Tl1Ay+ouXNraAttARb/0zTec
fYJ5Yzf6A198cdbvR5HAH8LhUeVeCG3GiPMykM2iHTuTobkuyt+tR1x2zq1fGHRA+2JCP5mdRWfD
x/f9cvlADNkvlcrF1dXRiQnsW+JHUgr+40n1/bVrNE2BHvzy4UNkYIBU/GE8TsDIHmU+wDCxXRC5
VUzvS998Q3H3q04HKVqanPicCKTcF42Ew9jGhFiQQcZVAUgS0mqVyr+nH+3xFfqcOtek1gC4doaz
uH9cXaXCP8xztxUhStujDC/MzIjKRNHaAJL0ogOlXxRnODdAY9PTWCln/f4/rq6SlmZrFgA27mbA
Bli27AMaK+lUqJnJBLPZnpGEIgv8482bijueBiM4Nd4tN/ydD+Pxi8OpOU2aNJ0GuYGTD79sNVbS
ydNRp3P4+PEH3twNKXW2ty/MzJysVTCOqx30AGnS9Nug0wMnP6eFe+J01u+ncyEDGBXEj6dxRYm+
9kSTpt8GvSiVnszOjk5MnBI4uU4ladKkSZOm10inkjRp0qRJ0+uGgYXfIQLYCMqwRBgN+tE7oC4B
+7hRq9Wan5+vVquGYZTL5fn5+fn5+Var9VuStXjfPft7tVodrMuNRkP9om3bjuMMzLZlWVavatd+
n+xJ5XIZt8+7fahQKJyU/IeR7QnOjTc24efn58vl8pDThlbraawRGn1cfj4/P+9xuPF6oVBQTJ43
QxByv2+xavANkGKVyfcYCMRD+q84vHPU6fyvROKjhYXRIXZZpbS7u5tIJJLJ5G/JKliWFQwGI5GI
ODbVanWYe9gjkcjGxoZiqViW9d5dpJpIJBT3emb7KaxSy/8dIfUgvvkvvpVpQ2NEo7+3t9dqtVZW
Vryw8Y4P8XsWMQz85ukB6jqOEwwGf2OCbrfbbj7CqX73NxZ1nbj8Nb0700Y6RsFg0KNx0kN8gnTO
OD4cixPIl7a2fPE4ztoFvvjCMIxXnU4zk+lWKr54HIeevrty5eLqKhJQT5eWXnU6/pmZJ7OzOEc3
OjFx6ZtvRsLhw2bzyZdfItfkPaqYn59HMGjbdiqVot9rtVqhUFhZWSFHu1arzc3NVavVYrGImDeZ
TCYSiWq1WigUFhcXYV3m5+fxO2d7CoVCrVYj/zSZTMJLCoVCtm0nk0nTNLmWOVbxoVgshtAvEonA
kxVZsiyrdUyst4twAUyis4VCAeGwojU35+7u3btYQrZtm6aZyWTQoGEYa2tr2WzWNE0I1jCMaDSa
TqcRqkcikXa73Wq1QqFQOp0OBoONRqNQKLRaLcgwEAigWe51fF18UhxTSDUSiSSTSbERwzDy+TyG
IxKJZDKZarWKQGptbS0QCCCtEQqFUqlUKBSCb5hKpUSWpD0Ch6L8WYLkTdOE9JLJZCwWYydMLpfD
0JCUpLNIKqV+B9FxHGI+n8/bto0/YygjkQg4icVisVjMsizHcWjCFItFJDEgInjQ5XK5WCyCee6L
6AUYRseDwaB62hDbm5ub0WgU3XEc5+uvv06lUtFolDUw0gnGSSmVSuVyORqj8fHxarUai8XA8/z8
vGmaU1NTig+xSywYDHa73c3NTbRPApdKhsueeRk7t4UvCtlt6NkVIU5Ix3Esy2o0GlgLu7u77Xab
xA4dxSVUMAcwdW/fvr27u8v1VDG9par171d7/tEFu9gwjOfb239cXf3k/v3Dx49/Zv6VBdSVIjYD
vuLTBw8A3O3RMCC8TaVSrFXAOKEPJO5oNAqtNDU1tbGxkUqlisWix/RctVqt1+uLi4sbGxuxWKxc
LmM2UIgNUaLlbDZbLBbp01Ke0+l0o9Go1WpSlrLZbDAYjMVi3CRIJBKxWCwYDLJBPdsaZqpHNrAO
U6nUxsZGMBgsFouRSARiXFxcDIVC+XzeNM2NjY3FxUXbtjGJMRHn5uYWFxdbrVa1WoUShBwSiQSc
R8dxxNelTyqklMlkpDyQmZ+bm2s0Gru7u5zSTCaTGxsbpmnmmTOcUpakPXKTvyi9UCi0sbExNTUF
W8KajXa7jQlDbEhnEXjY2NiYm5ur1Wr4sd9BTKfTYP7u3bupVIo6Qr1bWVlJp9PQULdv36YJUy6X
y+VyNpsFS9C2jUajWCxiYrA6C0QMr6ys9DVtsCqpL/gDq6zZkeImmGVZaHNubg5timMEQ4vVMTU1
pf4Q97rjONFoFNMSE1UqGTdReBw7buGLQu75unRCVqtVDHq73S4WixAyTAtGUyrkVqu1uLi4srJS
rValPXWb3lLVesYwjLHpaZx74rCLQcAuBpiwFL3ZDbG5W6n4b9066/ePTkz4T6LYNhqN7u3tQdyt
VisWi9Xr9WAwCCMci8Wi0ahHw5BIJLAMSC60z0ZiMk0TLUciEfq0SDC8eKvdbg/MEgiOALXmnQ3Q
+Pg4JmU0GiVTB6rX661WC+1jCRFj0WjUNM1gMAgvpl6vO45DXUCD0telT7qNnYKHWq0WiURCoRAm
LucNRaNRCDmZTLZaLeqX9x55FL5pmlCIiUTCNE0SteM4tVoNJhxs2LZt27Z0Fvl8vlarVSgUoNES
icRggxgMBn0+H2SCjrBT1DRNGmjTNOnrtVotGo3CF6Y0PeYkyVDcsJmbm0P3o9Eot+GsELJhGJOT
kxAF7DcbY3EjKE4wiDoUCqFNdX2Exw+xQ4nuj4+PQ2NIJcO91dfYSRc+J2TF61LlTtopGAyitVqt
hgkAse/t7WFKSKcNpqJbT92mt1S1njN6AVX+gUG6xr1j4maDYRgcHMrL13GP1bjK3g2DZVmpVAo9
R1jE5i4Qg3tsrVwuQ8twigPZGMdxHMdBXosiCbcpyEWjA7MktuadDenrXFOI/b18FFoAfw2FQq1W
S/q69EkFY248IE3Us1OUKOu3Rx7J5/NxOgJcobViscg6y/i6OIump6dN00QqDCH/MIMo7YjiAdgG
LiJxHIfmJBQ096/oV6PREIdPIWQMfSQSqdVqwWAQMZ+XaYnNAGID/9rtdhUy8fgh6VAqJMNRX2Mn
Sl4UsvfXuc6y2gOaularwVC5WRRq0K2n4vSmD4mqtffJZ9phftXpnJWhGxJiM4vlBFQ/wH4ZMnjF
ASgSicByVqtV2ORQKMTaPcdxuHnvppSRcYMNTyQSeQFkCh5Zz/knkpSlgbs8MBtu84Yr8JDqcdK/
UIuQofR1TD7uyX55wO+KNBQ1iz+EQiF813uPPBKrm7rdLk0kfDedTnNrUjqLkNWl/Y9cLodY6kQG
0csoixV9xWKR9X44Fby5uYlplkql6vU6V2TpNmSsu1YsFn0+HwICL0xCgZJignhFVT78h3pKRtTI
XsZOmgOAn8oJebD1SwNECm1ychJJadu22T0e7z0tFApu01uqWntXJeHmQsA4A+j170HAMaCuFLHZ
MAxfPP58exsAwh6viOpJsVgMCWgs0fHx8VarhalcrVbJ3FH0xLp4XNoaK2FyclJabjw+Pm7bNv7J
tu21tTWPVclSlrAYpHoTG2WK1gZjg/M+HMcZHx83TTOXy+Gvm5ubbmcO8CR5kdDC0telT6qFI+UB
20XYYV5bW+MYQwIXe6SsUvDeI4X8OQsE8RYKBcdxJicnaaVFIpFSqQSrUygUlpeXHceRziLiPxQK
YVUPP4h9RdU4o2Acn4xpNBrj4+PUtXK5zMmh1Wph+5dVed6nDab37u5uz/QONw2wv23bNpLapmmq
x6jnh3q+LkqGe2aYsZMKebChx+u2be/u7qLXCJiw/dOzYtOtp27TW6paPWElkaLn4PoAqHvU6Vza
2noyO4ubrEfCYRQvXdrasjMZ/Dg6MQGz0basZ+vrn9y/7x1XnUs1FovFWCwG7Y9dMorxadMfO04K
OaIKgqodkApg3RCuZSq98BLWSFkaHx8vFoutVotzHzDeKJ3q2Zp3NtgIJhgMbm5uptPpbDZbKBQQ
2EKjuXkc2Ww2n8/Pz88j10k/cq9Ln1T7MlIeEomEbdvIV+BHNuoKhUK5XA7pps8//7xna27rFvJP
JpOImkX9YppmrVYrFovBYBCbmVQBmclkcrkcTgMFg8FMJoOMrTiLUATFsoT/DzOI3imRSHS7XdLd
yWQSuYtUKlUoFIrFouhrJ5NJ8IZ0P3ZcvU8b7ExUq1VO0XifBmSWaIyk2ZKeH6LXpfGEm2RY8jh2
0ogBS5UT8sDrd3l5mV4nde+27eylp9jt4Ka3QrUaf3vf6C9/+cv/+B//42+afh/09ddf//M///PJ
tnnnzp16vc79+M///M9ff/21FvgAtLu7+1/+y3/5LX3oHaRms/mf/tN/6na7g73uZXqzqvU9w0qq
Vqs+n8+L2dSkyS1f1G63B0hSa1KsSu95pPfiQ++skE/vIDqnWt8n2G2cWOm596JJkzqPMQwAiSZu
+yefzyMH9dv40LvpyiwvL5umeXr1C6Jq1bDbmjRp0qTpNdKw25o0adKk6Y0YBgJGPnEU2TeMTOud
1EC7wBLvKS438g4ZrQDxfpPYzu8miaPAymRIfHIao37beQMw0X1BjrMysSxrfn7+raNYa/qNGIZs
NquoHdTUr5XteUSAFJ/CwADU6LeHXDsMkUwajcbm5qb6/K2XMRqynVMyh31dX0EysW270WgAuElP
FW0YNL1b5B1PWINsDxOJnsgYvYNDMDBLdNRcT4/fG50zeqHRAlgY7gNOpuDkNICdI5EIi1VLgK4E
jCydbSyCMQEps7CxqMoizF5CogaUtHEMFWswGMgikG+32/UC+cuVOUmxlPsC2mUXJDCT2QekAM70
isgbB9mtGKyeIN6EtAwkSDcU6LW1NQXyM47Oc69LOyV9TJQtJ8ZWqwWAZTVUtXTWgXODAR6PRCLS
UWDTJjjvxgJNEzKEdEUAvRLalg5AYYAow4l2cAaefRIdJH5IAiJMdF/rTgE5vre3R7NiZWVFMfcU
MmHPA0oHEb+Mj4/jd3ShJyi3pnc3YvCCRus4TiwWQ3QJNHACdjZksL3qT+ZyOSAYAwGccIoINlaE
3AJmL0Bo6cfFxUU1kC8xz0H+KmCEDSUit+EBaJezqYZhrKyszM3NkVSlAM7EqsgbiyesHqyeIN70
FRxxBI4pB6RDY+GG/CxFEsbvGD7HcUqlkvQrUtlyYoQl6AlV7TbrOOBxt1EQkycENA1DlU6nwQ/Q
INgxKhaLk5OTmGlQ/TRGwFo3jgGrxSeNY0CClZWVZDIJvHFDBhOtXnfeIcfZWSEOkzqhBO9ncXGR
LRJ1WyC4E4LtgkdQbk3vomHwgkZrmiZmBtQf4c1i+qphe0Ub02g0gCsLUIFWq0VoPFL/BThWBEJL
PwKDoSeQrwj5q4ARNpSI3F6Adrme4kwK1V+7ATjjlZ68eRksljgQbxpNeIXlcjmRSEitmgL52Q1J
GEgssO7pdFr6Fals6/U6yQcwG4YH2HO3WccBj0tHQU1gAO55Op2mC0zoX6HTMdNCoZDbdoL0SZYf
iAVyEGGi1etuYMhxbpgGUBluC4S4pS70i5Wt6R1KJUkxWqlyA1hDHF6rONUUsL0cYZZwiLssfqfb
QjVeh7D2AuTL/p9Lm7rBCFNORoHIzTalQDOGvqAf8Qf8KAVw9sKbF+hgBcNEuBaK4KRSqRTHvBrY
WUQSBjwL5TqQC5J+RZQtUiXcBOsJVe026zhupaOgJuAtI1eJ/CGXEUXoYxxDzikwtMUnCXSTe1KK
LapYd4NBjkuHaQCtIV0gYhf6xcrW9A4ZBilGKztdetYzqGF7xVWHeB/LSW0SRL3p9qQUyFcau/SE
Ee6JyM02pUAzxjrB7X3G69jCIoAzcA178uYFOtgLRSIRcIU8fqlU8u48uiEJJ5NJ4NfncjlYAvEr
pmmKsg2FQmwxpUe8Yo+zTjoKXpxi9jJIunkJcwypc5ygVkwP6ZNk9oYcwYEhx8Vh6ndv2fsCMYbG
ytb01lJJXtBoFYQ9NxG2VzGhI5EIPA4CUkbs6UbVahXuCeB5pc+4Afm6PamAEe6JyM02pUAzRk/B
PG1LugE4q3kjPOGeg6UG8WYjQrAdiUR8Pp/0omZFr0UkYVTit1ot0zRpNMWvSGWLBiEfj3jF3med
dBSkRC4FK1j0hZUPfk8kEoCAJc+AxojakT5J/KDUQn32RT0K3iHHaVaIwzRA7bL3BWIMBMqt6Z2I
GLyg0SooGAxKYXsVr7AIxiiNUEcMpmniYSgCt7tlRCBfqYrsidUsxVKWcigF2uV6alkW9VTsPgE4
q3ljIbvVg6UG8Wb7SOmsSCQyNTXVV7QhIgnDA0WnsHXE4RXjK+Pj46JsqaylUCh4xCvua9ZJR0Ea
yxLQdCKRICEnEgnWHcFGF3I48Jrr9To7RtiIRjuRSER8MpVK5fN54CqjX30dMvA4jaWzAlVJ7DCZ
pmlZFqohPH5aukAUfHJY2f1+TtNboXcaKwnld1LofE2/VYJVO70bCzSJEcDu7q70VvoTIVRe6Q2G
9yyVpEWg6e0SYCrgdVLqSYvljVG9Xlfncoek3zNW9nucStIi0PR2KRaL1et1pFwoDaXF8sZo+FoG
N/o9Y2W/76RhtzVp0qRJ02ukU0maNGnSpEkbBk2aNGnSpA2DJk2aNGnShkGTJk2aNGnDoEmTJk2a
tGHQpEmTJk3aMGjSpEmTJm0YNGnSpEmTNgyaNGnSpEkbBk2aNGnSpA2DJk2aNGnShkGTJk2aNGnD
oEmTJk2atGHQpEmTJk3aMGjSpEmTpt8AvbWLehzH6Xa7Pp+Pbjyu1Wq4d5d9DDc8s49pchOmFpSm
t0jS9euFWq3WAG+9U+uOpfe0L3LDUC6XW60W3SderVZrtRqugW00GnQxOiibzUYiEcuyotGoeDeT
ZVmNRoP+uri4WC6Xg8Eghh93+ZbL5Wq1igdisRh+LJVKiUSCxFqtVnHRIygUCk1PT0uFXi6XcWU8
USwWS6VSxGGhUKDPgXCrcKFQIJbEZxYXF/f29ur1uvo6XFxMvbi4KOWN/QSEWSgU6Cb0YrGIPgaD
wVQqFYlE0NrGxoZhGLjnXcEzvl4ul1mBRyIRVowcVavVYrHoOI5hGIlEArd3cUPJ8iD+Vew7+8vK
yoppmiyTjuNYloWbO+kyZ5pgYgu44rtcLqslz44XmmUnrSjtarVaKBTYFiKRSDabZd9aW1uDIwJK
p9O4yB4PSBcC2p+fn8cEoD+wQ89Kg1sd1F/2RbWEsfpwF7r0DtR8Pl+r1dwmFbdeaESoQW6CiV1z
HAfX7RFNT09Ho1F2/arHwsvyofHCMNFjblORWyzBYHBxcVHUUVzvuL9yDFAXSICcJHO5XLvdZt/q
drvJZLKvG+u4Id7Y2GDnYSwWi0ajEB076GrVwc1k6bQR+85agd4RQyQSYUdifn4+EAioX8FsE+c0
TZHd3d25uTlYi7t374ZCIW6KNxqNYrGYyWTwu+M4xWKxUChINUUikUD33FZXKpVKpVIKBcctkr5o
b28P/+/33Wq1ure3Nzc3FwqFyuVyLpe7ffs29wyrZdwacRxnbm4OgYLjONCY0vsaW61WoVCAJoLk
fT4fyza7uujP4mJmlx/Js1arlctlMV4pFAqmaW5sbDQajVwuJ441FgN5Fd4FiLnu8eFYLIblqlCp
1FPHcZaXl7mbkLEQbNu2LGtlZQWztN/ZQs6WVEu6EclHuqBYKhaLrVYL5rlarYryxOqD6DAigUAg
Go167wJ85M8//xx/vXv3LvyMvsiyLFal3r17F38IBALZbBbrPZ1Oj4+Pb25ulsvlyclJjyIi8Sp8
R/x5+DtNY7EY13fWl/VOMH7iPCwWiz6fbwDVQc4QZ577jhjq9Tpn+qTUaDSCweCQsVKr1YpGo2gk
GAxGIpF6vc4t1Far5fP56EfTNEOhkHod9pydeB3/pwUzzOSwbbtYLLbb7WQyWa1W6/V6KpXihGPb
dqvVktqMWq0Wi8Vwv3EikajVarVazbumG4AwfNCP+APnVriFBV4aL5fLoqPkOE6tVsM0jUQisVis
Wq2q+1goFMhVHKCDoufI9aXVatm2HYlE6EnxQ7u7u7FYrFgsIihhH7Bt23Ecyn60Wi3ui6zudptd
Yv7hpMi27VgsBvMci8VojhFXtm1Ho1H0KBKJRKPRfD6fz+f7/VBPJaAei0wm0+12HcehRR2JREzT
hB6s1+vBYBDmKhaL2bbd0zCoQ1vyHcXJ5r0LXHeQ5AgEAmy/IpHICd5Y3mg0hlEdtm1juiJPIHUj
xFzLPwxDrVZrt9uRSKRYLNJUhlA4J7parfZ7rzdmJLtCTNNEYoGGU2wTITwiQeiXnp+G/rJtWzpl
kXIJhULFYjGbzWL2cNOCE5PC0tIt59FoFPJJJBLlcjmfz9u2jRQEHgNXtVqtL6esp1eIXkDVlstl
NrTHj26OCeIJmAQpVxSi9hVCWZaFUIAWD0YcCpRGJBgMskMvJTaVNKTnJXqOhUIhFArt7u5SHAyv
irNwjUYjm82applKpdgHHMcpl8uRSKRUKqXTaUpZsCpDGuSxQ2YYRrvdbrVajuOc+IZQMBisVqvR
aBQRQ6PR4NwpdB+2odFo1Go1TFfWnon6YgB3QT0WYK9arYZCIdM0aYFT+pHmjGmaUHx9uZ5iVsO2
7UKhgOkXCoVSqVRPDU5d4FJJPW3zidgG+JTRaHSAwBQCh3iLxWIqlaKEoSJHglTS3w0DcnlI7Gxu
blJugRtXaDfbtmkfwiNhj4FT+o1GY3NzMxQKQY+L6sk0zbm5uWq1ioEMBoPpdFotbjh3WBWijKAR
0um0ZVmWZaXTac5+IN3ExfhuWiwajYpf4bwSNJXJZKA32QCIGoGWQTyISeDFl6RMHbrM7fiZpgl1
EIlEuD4iHYmknNSNqtVqe3t7UG3INQUCAYh9fn5enBIQOOYfJobU4r4xUniprVYrn88j7QafgxKV
XKrNcRxYBdoPwGNoAbNobW2tUCh4N/aig4X/e7S7oq+qMKv5fH55eRl9hyli1VkkEpmammIjZrEX
LLfip+HUU/IHU26Akdrd3b19+za96zjO119/Lc00RiKRVCrVUyOLaUMKQDc2NjBec3Nz0IBQeqLN
9kjYdpZ6YKZpnsh2erFYnJqaopnJDkRP1YHUWTKZnJycvHv3rmVZ/SaUzpXL5Ww2i8X/+eef3717
VyqgRqORz+cplz0kQQWjP/Q5Co7YTWAyBgiL8ItoIaAl4baLjnC1Wg0EAnDxstmsZVluWfiTolqt
BquA3mWz2Vwux40NEpRw9oPBYCaTMU2TMwyKvITjOGrvW2pH2TXTc+r3zDLl8/lWq5VMJt0WFQwM
m3iR5kxPJJWk7hq2gj7//HPTNKH1isUiVAOtpd3d3ampKdKJGC+KGGAkYP8+//xzGAm3EFmRSqpW
q91uN5FI7O7uTk5OqjUIu4vjkdLpNKa6G7nlVTySaZqLi4tcQU6r1eIcEXUqCR49cnqsE4bfoVtp
HvZ0wNm9VvooJgMCUEW4owiLxS5w/hCygjSl2T+TqsQuYL8CL5fL7XabOEdgSlNLrToQflG/MFfd
0gOuqSR2BwyfFz1l2B+yHydCu7u74q4GEnY9sw0cG47j3L17FzU2Pp8Pu+3sM9w6IQVN0Q+bP6G5
Rel49USULubFxUV2GCKRiHS7Ur1E1RoBTjoFVdw/iZyLRTVihj0ajdq2TfMP7qSip5xgLcsaHx9n
e2SaJqrCUNUDL+REUkmhUIjSBT0DfFSpsYyR5MmcuI0FPcAanmAwCKOCX2ikpEPGBtlIaCB7Y9t2
Pp9HdOI9MYudc+8b1x6tS18NGi4FOeTvk6xQWyg2DnVGBXKYKplMBsZjfHy8UCjUarXx8fFqtTo9
PT0Y8+yET6VShUIBehBh3wB+BkkSs6VWqyFcBtvYZutp7MUIjCtzgI+inhgK1QHLzfJMDhD7O3Ik
FN9zqaBzUs0YjUbpOfjg2AHvKwneM7jmfFJE8Ujs2rbttvEiHf5IJALvjGpPRQXUarVKpRKbrIzF
Yslk0jTNZDIpde7cagxY+SrKVd1WBfuAumxAUU7nFhZgc1VqANjilkQiQfOeXT9uovASYeC7iUSC
nWTJZNKyLNhat9iCC5M9xgduik8tdm6qY+aQGFEPw8asSHyzg4t1S7M3FAqx/RKnGZUFw8tLpVLo
I4JXpIDVOVI2NUeDBWun8GdpGrCbYZyBkf7iZf1i95j9hU0uedwQmpubs217c3OTUy9YktgSR72m
lwoIt6JEEgIbIHrcq+B2s7lf2u026nch6kgkUqvVTNPsyzBQCEvJhmq12tML91JxhNpOmgamabIB
cY9UEuZBo9FgZYpCBcix38DTYzJLWghBFtK2be8ZWG681RUIqOSjlDG7LMWq5yGDbuliULtmPZ07
Thdgi0kRBPRL4mLwmM3I5XJTU1O2bZfLZS5oUCzIno2fVGUh6fRGo8GqIUx1GpRCodDtdmmSOI6T
y+VYPwN+Ertuy+UyCljxSj6fZztF0wwuCNdZL4uFXFeUPJCZcSMEJclkksSOohQufe9WGUyOpJq4
owxsel2M3ljDH4vFkGDk1Bw7JeC19Fvn0lMXiW6Wl54qNnjEYk7FHiHquXsaJ+n+5QBxIaZuLBaj
L2LXE7NU3AVkhyCVSr21k89IRHCxEpeAFt2E38apwhMk1HRxzkXPgyYnS3BMQqFQIpHAcTZp5e7A
jZ/qbpA09Ol2u+/UAXJEIbZtZ7PZYrG4ubmp2NfxrjS5iOFE1q9o/KQqkn2R087v2tF9MWKgv7bb
7enpaU5ruXn6KBR+F3rkxeiegztWLBbZDkej0Z45uCEpEAiIQQPVq2FyiMHpMLvfqVSqXC6jYINN
JXE+hWhL+93945a06HGwa1K6wcXumIlxPVsdhPJEUbaDnWpReEnSTTzj+BA7JaYQH5TL5bW1tX4r
PaQ6GruaJzXrEolEt9u1LIsSQdxUR9UWuxa4SUIHmNlUEpsOTqfTpVKJFWBPH79nbF2v12OxGPhE
VRUOsrFVPaxiwuYTTZtQKDQ1NcWJsa+zhP2u355O8SlpFdG8cQk3cTXRxuoAEUMgECiVSh6F0Gg0
+i3p7OkzKdYp9mx2d3fpGWyaeozD/s3f/vY37Xdr0qRJ0wkSi30yGKTC2yVtGDRp0qRJ02ukYbc1
adKkSdNwhmEAwCw1tY7pRFrjjs73dZL+fSQgW7x3bDuOc+ITSZN3elEqHTab7wgzR53Oqbb/cn//
5f7+722Ijzqdw2aT+0/xGDcK54xe+KssuVWIS9Fce9bgo9qaPeHitjfidjjLeH0jF8UbtLXF/VVk
1Xi99hkFXnTAFZy4iULE+kYdDouowW4N0R6Xm1jY36lIma1W5gApsQ+PU2PoY19IxXRGDwd/SJhu
ONXgXw0LKlbHu2GzQ3SiVFHcicpr2haWDgFXH0LQTIlEgusvxwMnf+omDj1hJrghsHIHGyETjj11
NT1HT2ZnX5RKhmGMhMN/XF31xeOHzeYP169/9ugRHmhb1rP1dfz544WFQDZrGMYP16/j4adLSyOX
LweOCw2+u3Llk/v3R8Jh+sNRp/PjzZvsFz9eWBibnn62vh744osLMzMK3qgR/JU+ahjGYbP55Msv
oW1HJyYuffPNSDj8fGfnRakUzuUMw2hmMt1KhZryxePhXK5bqfy0tPTJ/fvch368ebMnM4ZhdCuV
ZibD/hLO5XzxeDOTGZuexuvNTObw8WN64MKtW4FstrO9bRjG6Orq06Wl5zs7nDQC2SwrRk7+UlFw
xDY7Eg5/cv8+nm/fuUPNPt/Z+Xl9HcpXOo49GWPFSwKRypOkKv6I0cefD5vN9p07vzDD9GE8Hvji
C3Szd7kqB7/e7XbZk9kDb6rgJBGLVwMQYOB/cQ9z0N8KDom9QCDAqhJ2L4hsDFe6g3OYKysrrVYL
h+YUy5s74iC1W8Qz9CldITBYjQodKUJ/6/U6YEVYefaFVExAOsQqezCbNdIiGt1gwRyVcKAj9DkA
+huGAUSWubk5tvxf0SY7KwZAPEbJP90v4obr7uaIDEnP1tcPHz/+9MGDs37/850dTuth5bctC+qv
W6k8mZ0dCYfHeh0DZunVwYFhGOHj8qFmOn10cDA85z8tLZ3x+6E9m5nMky+//NO9e5zKpj+3LYtV
1hy1LevVwUH7zp0P43E3zUvWhdXX3125MnL5MvfM4ePHl7755qzfbxhG+84d7rsXV1cvrq5KVf8w
hGYRh3H6nVTw06Wli6urF2ZmMI6jExMwsafKmNrcPt/ePjo4+NO9exDXUafz9C9/eb69/fHCgsGe
fHYDzTBNE9jrtm2Tx8pi5Eo148meSxJ9PdZNA4ftdhsoNEDlC4VC7GETL+Wb8M0B8T01NcXaPy8s
icRFDDg6pNCw3CjgdVJD1WqVdVd9Ph+QKTEogyEVnziJBpIiNgwK7AHCRNM00TsYYNu2u90uxpSC
ziGnEE6luhl4wBeDh0wms7y8fFLQmB5THP5bt7AsL8zMvCiVLszMjF69+sP16/TA2I0b0CC+eHzs
xo0ns7PG7Gy/H1IrXDfeDMN4+fCh9N1upUKO6h9XV3+4fv27K1fApPjwL5WKaMwOm82XDx9Cjf7p
3r0XpVIznb5w6xanMRXRw0g4LOXtrN+v7i98ZAQ0ZIyhDVmrM9iAjk5MSBN3FNP44nH/zMyLUkns
Zk/GupUKx5i6p686HS595H0mnKNI3A1/FasUAT7BTFarVe4EE3lSbCpJ8WGceufAUnA6dLD1j5O3
gPDN5XI474cAApEN3F70S4QTAAwyKQWgiqIk38v+Bw7Hi7+zWQWKWtyUnXjBGYv5XK1WCYYFzAOY
lyQwDFKxNNHHpZK8vMU51KKdQPE75Izz7ad6YgYQ08CXJhNFgJpAmyehAd5g+I+K1fTSUyB/CIc7
29tjN24gYuhWKmz6BVmatmWNTU8jYnjx7beXtrbGpqfJciDsoFyTGw2wndC2LF88/mx93RePw3SR
tvrs0SNfPP7T0hLCgp+WlkYnJv507x5yHaKu/HV//9LWlhgtHXU6pC4D2ezY9PSLUunZ+vrF1VWp
en3N293ZuXDr1gA7FsifjE5MPFtfD+VycM+fLi1xj4mpJC9C6+zshJhQqS/ywhgyclwqydUbuHz5
+fb28+1tt1TShVu32nfusBmnD+Nxkqqnk8/lcrnb7bKZZaR9pOdrPGYVsALZK5AIjNA0TekRGBZB
kDubats2C99Wq9WAO+3z+T7//HOfz0eWA4DV+XyeQ24YkiAc5HbEeyzYqGWYnAxhd+PkFxsxiMm3
vpCKWQM5Pz8P0y7F2aYH+oVdQ9850B4AIOMroVAIGIi4bk96809PY8Ye9ysUCgDAQG6QpMca4CFD
IlEI3o9DXlxdfTI7+/21a3DlkDJCPoEUQSCbZZ1H0fWmhLVUf505fx4ZpH841OfP99y0fDI7i3RQ
27LsTAZbCJTTR5Tw5Msv8TnsMbi19nRpKZDNkmkhtX72/Pmz58//+vDh04cPOVvY2d4eWVjgXuEc
8JcPH1786iupNnzy5ZfsHgMXZ/y0tDR69eqlra1mJsN2bXhqW9YHExNk0jCI8PexqfM8HkcqqbOz
w1nKk2XsqNN5dXDwx9VVhZeA6OSDq1fZdNwZvx+/fxiP904lQSMjJIejR+E5q5o5IDY3TwoLCReV
uHVMikZH+pRNJZfLZfhikUgEIPsEw0IA5Wit0WjQVRM4AVir1djLKxYXF3GDEPrYbrdt20YyR1RP
nDdNokMUxSoLboNUbYrYURAT2YFAgBQfbdSTausXqVghfNp8Vj/QbyrJOL6ohy6oEfM8gAiG2KPR
aL95JISGkDmuDwHOdigUymQyBMHPipQgxmBr1Y4OOu5Wj+AFc5f78dLWliF4069xmM0GhjjEftbv
/+T+fWgKVjV8GI//wUXvtC2LNgkC2ezh48fP1tc5RTYSDnObClJqZjLs3jir/V/74p07Y9PTrIZS
WAXk6CkzzlE4lxM7Sy0/39kZuXwZfQnncs1MhlLqHPWbSnq5v/9sfZ2VCTafSVwXV1fbd+4gAvh4
YYHLI3lkzGMqqbOzwwUK/Kz75ptfX7fH4gCdM3rhr5Jfz56Ap+sN3PwmQwlQBVAdKYKjNJvE3bwh
Ng5oWdgMgIXh4kBSr9hyQJSAVBgpLMr24NJt1PPs7u7id2kqSVE9NZjzaLiAl7EfIued9pzZqzr7
RSo+DaJpwKG3sn0sFArcfXNsr1mI4CGJAyOTwhfGYrG1tTVcCpLL5Ya8l3GAEEq6H9Bz+9GtEMWN
nszOctuwrw4OPrh6VXozBqePLro4niJdmJmhrU6ULZ3x+y/JzN7oxASyZODq1cHBy/39V52OYRj+
W7cUeSTUaIVzOcUzolp8dXAwduPG383w61ZE7CPJH6GbohiJs1XqDBgrHImm9sAYtfB8Z6d9545i
DpAzcdTpdCsVlBuMMtGMYRijq6vPd3ZE8/DB1av4ilcQPRThABhHClgkbsOqN2bhx0lzVoOlp6DN
sR8uFqgAOYQA2aX1VMlkMpfLAUzJCwacm+fIedDcFQXqTAgHpcv9Arg6wvXFnay0A98vUjG8e6hv
aWwkgrEMvx+QSqXIJxh4S4mIZU8aXkhBsGk4UBEAOXjB6PfIkvdyVazzzvY2FdqPTkyMTU+zXjZb
Jyr+4mWP4dLW1qvXi5GavXoqflRkm6uepF8Om81mOj02PS11xlkVfMbvhzL6R47IZf8WVuFFqfSn
e/fUOxD+mRku4UaeOxmtZ+vr7HbIhZmZj5TJK/XewJPZ2Y8WFtTltl4qjk6WsbZlPd/eHr16FclD
1OyyGSpRjIePH//68KEBwyDCMLE5hGQyyeqXVqvV7XZZT5+9E0bMRylSAbg+l7e9MtBaLm8jMkk7
ez6fj7spgYXh6wl5bZrmkNhzXm5QURsSURezOSVspYo5eny0L6Ri7soO+joFPdLW3K6fpUpc9hd2
1AD9xu4JsSk4fI6NJLDP1Gq13NBVRbxuabmqAgRbHfyJtLm5yV50ge4obnPymIJ4urT08cICZSFQ
8M4V54iVrORRevHopSXtZ8+fP+p0vr92DfWyPRsRXVQxswGeUcvvxSKKcQx0+otSqW1ZXLbKY1bt
5/X1X17fw+c2G7BhS71GcPPz+vrF1dUfrl/nNurZfX6qFWYN3kg4/OmDB4ONPiclN8YCX3zBsiEm
uy7MzHDT4KjTaVtW6PXQ6snsLJuh6lYqYsbpw+NZd65nuoO7aJPbFma9fi6Hrt5lhQ0QtaToavWl
71gz9j6ereX2e7mr6oPBYL1ep8vLsBHyxsor+82DcePC8inyrIBrHuCAwmmQW47rDbBHu76itvJI
VN1PdOb8+W6lwhYd9UtckYy0KknlID9+/LHgDn8wMQF7OTZELvTCrVvc62d6bbl7zNH9ePOmOgw6
DfKSXeStvt8/Eg5jOCDhlw8fvnz4kJ1Fh48fXxASd7Qf0zuV5F0p9xUxIOcjGg8669T3NBXuKDdO
/2YCrgyGnHHWvPWF9KuOGACnTLeiBgIB73mqt0vBYPCt3KVx4iDYXshjuSrC+Yurq53tbUoHjU5M
BLJZLofjFjF41Syv1+qQ9jzqdD50TxaJH+U8U7eIwTtXYhIMZ5W7lYr3vQ2xWbFMc+TyZbJhf1xd
bd+5g2IwNmPTs2WgR/TVR4WbL4p0YMbcXIHn29tPl5ZQvzt69Sp33g2CEqUHQZ06uiqHZjHM3Qaa
NGnSpOkNkIbd1qRJkyZNr5GG3dakSZMmTYMaBm5nqa+NptMjQHa/rX3mdxk+Gie2OHrrXP3ecNHf
ynJg/9qXhKVzRgOkv3lSAGW/GTongtkSsbUQqLFlIVvZv4IUiNYcSDKR26YcbqzFEVlCYOXax6EK
eiUQCCSTSXWJDiFRqzdCi8UinZUDFDNeFDdIpPDRbg8T/yKKOKFlKKpdpc0qqubZ6k9Qt9tNJpOs
wMWTE8Sk4ziWZdm2TUOAgymtVkt6PMXtalyuVq1UKoVCIWKY/atYl4zTJJZlKWDDWRlGIhEpAjw9
wx098Y7yLfKG+jHuYe/A42yD7Al2g8GbUoOci9OjUChQVQJEx6Kye2FPWkzBHUIker6zI6IMUa2q
FCV75PJlrpz/sNn8aWmJQKJ88fgfV1fZM2VSvFI3KFaP2NTcKQ03VG0WDfvCzAzLCYuLfvj4sfet
cu5Ag8gezrUQ4tNZv99/6xZ3SIKDW+eAx0XAc/SRYHpFgYg/nuPAbDli8dxfHRygTm7k8mUWiMML
orVYdW64X0eO9YDlAaALUfcBJC6dThNKB1aa+tzs3t4e/q+o5CmXy3t7e/hioVC4e/euooII7hiO
zvZlkMXCJLcjAsMQd/y4L+gkKIiNjY1yuQxcLPXz6rICukyi2+1S5Zg4WCI6k5tYCLeDM2x9kXeU
b6qZdruqYQBiO1utVvs6FidSoVAIhUJokEWg6pcl7sihOmJQw7qJBxo4FxjqxRePo3gfyM8/3rz5
53KZsKDF07k4DOh2oKxfCFI1ERRVt1L5hcGUPSU66nR+Xl9nzx+83N+3MxkgLbKXcxiGgT9z5bPe
Ac97RAyiCWJt4Fm/P5zPHz5+/Hxn56jT+UM4PDY9/cHEBHuQcshDYSLZtk2qNhaL4dTVkMWOtm0X
i8V2u51MJqvVar1edzvbXK/XY7EYgZguLy9znqnjOPV6fW9vr9VqZTIZ0zSxJiORyPj4+JBHeXuS
m2M+TMbJLecD85lIJHZ3d72koarVaqPRgN9t23Y+nyfjl8lkgETSarUAZifqoMGGFeBLCDGlwZ8b
CNgAKN9Irdi2HQgE3FDZ1WhRp0d0Bt4wjMnJyd3dXenIqtnDAHHr4vQOyrz49tuRcJgAIc76/Ze2
tn68efPFt99C75/1+0Vn/Kk7pKjhDYL01cHBaV8bp1D9+L/i+Mgrhjf2z25H/MQDffT7wMdBznnp
yZPZ2UA2e8bvf9XpAMGKAgjUHasRrU+DotFou93m4Juk363Vavl8HkfzSNOVy2XkENLpdL/rFnZl
fHycEBRwrLdarbbb7dM+VSCmkhQPl8tl9viVeLBcoVhZHG+fz4fEVM8TAPQJUSvl8/lIJBKNRunQ
O9q/e/duIBCAe8Ed41DnBhuNRrVaDYVCxWIxlUqxkIhuiSyPIOoKrzwSiRSLRbo5SmywJ/B4v3sG
4hBLYwtc50c3W3AYl8Owd+J7DN9ducKpby8ZC1atE4rGABEDrrEc8gwdl7/i8l2Ks98Id7ouKvus
3//RwkIzkyGeD5vNi6urZEXYu/PEtBsnByngeX+G4YzfTyb0qNM5w1izl/v7gP/9u5EvlX6pVD6M
x8+cPx/O58+cP98XorUXfCGsPcJMrdVqHCQcIYwCjI8WBtRcKBRitQkHpkY5FjcOAUKHmw8KhYLP
5yPEVixUQgXnsrH4cRi94wXR2nvEMDc3J1oCVqFgZzIYDCI4kCpWVqH03MYECi9ZCFYxcQfdu90u
wUvQhZqUrmE3TtxSSbhaNZlMTk5O3r1717KsfiPXvlC+MbEhB6Q3ud2a04gY1BcXcpRKpfL5PMRl
27bbElOw12q13G4tFMOIYfI2lLseu3Hj5/X1J7OzF7/6ilJJh80mMO9gAw6bTRFL1e0rXpDmcCFS
Z2eHxQNHktwLZB5H/cLf4uvPd3bY/drvrlwhW4IjhzipDrvIHkLk7s6jWzFEg/rT0lIgm30yO9t1
iSfEzQ+WjXPsDlKbmTRty8JddB/G453t7WYm84dw+K/NJoYTqSQI0faAaC2dVQS/LK7YVCqVy+Xg
tGazWfZ1YDX3XPPD5OXpftBQKITb67x/HXckDPZptUmgfZqeW+jValXNJNDrSqUSDk5L7zEFjjck
2e12Q6GQwjCwxQWs6Zqfn0cEGQwGQ6HQ5uZmKBSCDCneMk2zX4khxKFoAGDd7FU8XlJJRj8o39id
wgV/dJeDaBj6Alil8IhqK0jFYxdd8a4Yl+NeKYxRKpWCSFkoMzV77MWr0hklQhKoEUNJ17DPB774
gnOQ/3Tv3k9LS3Tcd2x6WjQD3UrlzOu/nD1/nvO42Xss2NCE/frF1dWX+/tty/pzuQwVRwl6N5NA
GIW4KoMa/OT+/V8qFXVSC/rztXSfZeH3H65fx7VubHjBXljNnlQH4iHOJIt351F6jW4PPep07Exm
9OpV1mj1BBLnopxz7Oiin1xSD9jr6NIHV69+GI8jQ0d2zAuitdvyZi8H5ea9YtWlUilc/iWqTjEO
GAAlP5lMcjqClDKMFjIYrPlBsAKeT6MqVOwFqzi4XnB2sVarsYVA0MWoOJqbmwsGg1NTU/l8HlqP
dSRR0FIul93yEqJ8oETK5bIo1XQ6DThYWF8YHlymRBk/sXdSz9c0TbZ9FqybAwdU48l7R/nmQkwx
4hRhBNX5Hw5JHjivipyhF6rX68jRsfnDQCCA7ZOe7C0uLkpdCs66uGlhzmZcXF0Vq1rE+kvcUOTW
zpnz5y/MzEBdvvj22w8mJnCNhHjbsxdAIWzkIjr5aGHhx5s3z/r9Cn+fxSj84fp1TtH3tItixomQ
AS99882PN2+GX7d2BIILuGzaMoGZBNwTd3ceFVYRbwBh/GBiYuAkktc9Bgxn27LAGYdha3hDtHab
i+oHlpeXs9ks1BxXVyeidsOLFD/N4a16KVeForcsa2VlhTxf9i32thny/jjFzeV8OEvD5Y4hw2Fk
xa3kUChkWRb2xpFxZtd2q9Vqt9sUisGiI1PPaq5arYbU1kndvkk+KSmpbrcLIyHN+Bm9irWAQ066
zDRNpDRPaYPHzcAYAoyg240UfVFf5arIgnKeFvlPHtkTQ21stqu1sFveZvjb7dnNZ2ylqnUxW2Aq
+sKd7W3cIYqWL33zzZMvv/T3o9xF8liuetTpdLa3L21tIS4BRlbLsoKMWTrr95/1+4G8TW73k+1t
FsCcvTsPewzcV9p37vhnZtRIf2zogxtVRStyTgwxWMmSITpz/jw78IBcZ5OhiukreivcX6WaGnVy
8HbZ++Noxp8qqiVUP7ITlLdlmRQrvmlPT1qby/ZamjtmNSDdUy2ma7w7ku12G4l+LriRxkmisjNN
06M3LT2kwpo9Nu/x+eefs2LkXhS3oBR5dmxuxWIx4hOaFAZbDdWO+8bZzqpRvhWRxACzyzuSfF9U
q9WKxSJnG/rCkcR+vrjVcVLLirUoIsY192Tgiy/YWtVXBwcvSiX2F/GuAhGHnK1K4v5pdGJCUX4q
2hika+ivfW1IIGkmJuK4DYDDZhN3TlC/sM1w4dYtfEt9dx4u7FNzIjmfsLXFsvHjzZuBbPacd3vO
jmJfxV49MZmlaz6fz6fTaVTLoIB1b29vfHycLj0WI9yTKhWF1clms6hwRSDCncyKxWKTk5NsDvoE
M0gncheYcXyQFRIDez6f78QLat0MoYIl45TJC1S7oj7iXWBvMOKu6+iXWq1WLBbj3IhTgijuqcLo
8iKQWIk0MGC4F/J418XJErIyHWZrGgATHmHDhydCkD3nnV3u1icxzXdS5DjO119/nUwmkV7AjiVK
R+7evYsQGBkS0e2S3i43QPyOo3PZbHZ5eRnu2/j4OKWhgsGgGDGc0lJXeOJq7zIQCLBZe2LyLcJ0
S1niPFzp4VuuyJLNv+3u7pJMkDE71YGQsnd6mMHey1WN44pVMfnmfVFgYoujNsxZJTEnwV0v4Ubc
bZTvLPVVrtozsAjn88+3t0nZfhiPh/P5UzWBXICFXQ2NrqpJkyZNml4PBrQINGnSpEmTNgyaNGnS
pMmVzr0vjB51OixA09/N2vnzbyz79jvpC0oM3kHBSitYhsFHA0mPxb3j5DhOt9vlauROcGeFk4m0
WOBELmp1O+L6jkhY/P0EazdQdfkuXNguNwzc1tDF1VUcyfv14UPA6hGkH8GbiHVm4Vzu5f4+W89L
xV6AJwQcLmpmw7kcB9j7yf37L0qlw8ePP7h6lUPNJXoyO8shBb46OBi7cQNfZGvLsPMDKN32nTss
Pi1LbAEycGvR5TN+P/HAYdj+Y364I730lKdhGJ2dHfG2VeP1Oo2e8LxuWMEicdIenZhAxRsHPoxq
9H88dvXqxwsLbu0/mZ1FvQTKCi/MzLAMc6V+OO4kVrWLv7h16qjTaQpnKV4dHPzp3r2RcFhEeMYc
YIdYPNkLyJBSqUQAJyJQK1sizKIIG8fYqG6o2qzK5ppVnE5g95lRUgwwV+B2EJY42DBNM5lMRiIR
AG7T2XWqDicgcbdCZw643jCM6enpUChEMqF3OTPQarWkG+BuWOhScHi3g5Bidfvi4uLe3l69Xhf3
wLmHcaG32N9yucyiCnIIWtJRo2ZZOBCudoPDdVfIORAIQKQ445lIJBqNBodcIr7Ozi4UZ2Po6ToA
N3RhViwcqDu1r0Yn+nu5KqsjuBt4fqlUPnv0CAcX2pYVyGahnjjoc7a2rFupvPj220/u30cRrlha
QIcGjzqd769d86LdREXMKjuqLXtRKkkB3AcjLzhfHPWUpyHDV2GVMmta6M8DcCJK2ziG6hWpW6n8
vL5+aWsLPAP+1w2J5enS0uHjx4BKhtXh7pRnS/2amQxXaMidm6U+KiqnpQXa1AiVZrPA9KIPaBgG
C3BimqbUK1TQYMcL+iJCm5dWzWIxo8qoVquJOPPlcrnRaEDbqlHLjOOSa9u2S6USJMPCgrHEnj5x
u1vF6AcLHeBUYFjksKfiZkeEVBvKF6VCq9VqdK0LVTMqPkEn2wuFQrfbdbuRwntw0O12MQMHvvgI
99OsrKwAtqAnrDrJEIVq/VbAn/OoHEfC4Q89VJiRLfHPzIyEwyPh8Nj09Mv9/TMueYlupdJXRRqg
XhVa8uX+/smWuB02mz/evPnpgwf46/fXrsFLPZHGm5nMpa0tLmkj1Y8ekbB69qWzsyM9IPPXZvPM
+fMUPZz1+z+4etUNzvevzab/1i2wfWFmpn3njhtAAgJBztp5QS8YjF69JSxlNXGQscPkYVqtVjQa
RTYjGo2WSqV6vc5qQ8CU0YH2QqGgUH9AqSqXy8A05PC3xXORHokge4vFolj82mg0gFqfSCQikUip
VLIsa3x8HDXow6S/cJ2iWN0LIH0qd8b5J8Jzc+sCblsJhUK3b98uFoubm5u4C4CTiUffAgLh4g+Y
KDo4ghPmjUZDeqKwWq1S2XEmkxGvAzjhVBJF5S/391uWBQUkQsK+3N9/8e23rE45fPz419dPoLDr
k045nD1/njJREsXx7bcv9/ehNbwAj7w6OKCE0sjly6KC7uzshDw712wBsgKDlz3N5/FkX095kgxf
HRyc9fvPnj9/4dYtNs0FoQHLxQ3ORVTHIm4XaxWefPnlRwsLUvCvsRs3AJUIVl91Os+3t1mWWPpD
ONzZ3sblIc93dg6bTbjzHD/dSuXpX/6CW0co1yTt40cLC4rRl27J4MejTofdDjlsNt1uJsGKunv3
brfbxckJpE3egGHgbh9CKsmLDRB1HI7vsKn/8fFxVjfReUZowJ7OKSKMTCYDzErEQ4R9S/Khu5W8
WMFqtYr7/tLpNBxt6giuRYlGo3Nzc/V6HW4vXmERWTjow56nKBqNRqlUwtmjWCzGxTTASw4Gg3Qv
HovnJg0ukZpDpg5xCewZGCYD1hPNk+UB52HZk7BAJaDWAEpWLBY9Ig4MT+KhHMJEOIcFDIBySqxz
uXgs4AszM6wiflEqHXU6z3d2aElDz4or/OOFBSTuRS+4W6kgI6G4bOj5zg53Mp702uHjx91KhU7G
ty3rA+ZQDNSQAjYEuW+2y6INw+E+XKwBq9DzFKJCni/39zvM7sKrgwM2rf90acl/69arTqdtWXQP
35PZWWkM1JfT3bastmWR/sX/WTWNI/sk6pHLly99841b7HVxdfXJ7CwQMUfC4YurqyPhMLft9HRp
6cW3317a2hqdmOBunsLkEfvo9jlxe4mG5smXXwJ1EvPkqNPh4JSJCItpbW3t888/9/l8/eaR3KhQ
KGAPwC3LNFjEQHsM7I9TU1OWZVmWhWs74WUP3BHLshzHQZpobm4OZw8Ba0g6mjSF4zibm5vktEq7
ACz0VCqFc6mE1sUaNmx7dLvddrvdbrdbrVYgEACuPvaikR3idmIUKhibLrAKYEDMCxmv440rUPdB
BA5GSjwQCHBnJxEYGe6Y5OxQsiqYGmERzCzLAggNxle0hbFYjMxSLpfDltIw1z6qhXDOMIyWZX28
sNC2rMNmU/TB4bHC3wSyq3GMH/vxwkL7zh14jqyefba+/o/bHQ4OfOHwkczjA2J4z+oXTl+4nYx/
ub//bH2djWmw+dyXsDgbRtvsBAuMP6tPNirkiRSNui/dSmXsxg0YJ188PnbjBvJjBJhuuJToUKKG
5Q3bPCOXLysyYOyuDLH0cn8f+0ZSlX1pa8twgW98ub//482bF2Zm6IJGmkJkioC5T338YGJCkQP0
uL/SvnPnwszML5UKC6dMeQbaeWbvFj0RcED1xgNpE7e91r4IugNpE0oZ+Xy+WCyGMAjKgq7rUSdn
cA8SrqUjaTiOw16rzuUrWAeTAzMGiiVJA5Dm9XqdfHPHccTIg/2l32P5tm1vbm7GYjGSKpSduAvS
0xKwlMvlgAEsJToHXiwWcR9MPp9X+/jEFRvYmaZJ5mRzc9M0TTSLigYAAnGDVSgUlpeXjePN5557
ErCRKE8g12RxcbFnzJpKpc61LetVp4NkxZMvv3RDaBoJh/23bkHPdisVqODRiYlfKhUx6f9hPP5k
dvbCrVtHnc6LUuniV1+9+PZbMa3xIXP/j9owQGXg2lXkkUcuX/bPzJBRgdd5cXX1ZDcYSMNCqXmp
AlLLcyQchrcOtCw4wiOXL49NT1PLcLHHpqfhTcPvNgY9Zy9u23535QrGjiyHeK2u2ja7zRAEMaMT
E9Joht1aGAmH2T7+ur8fVM4EbIaLv1Ow+GR2FkicqFAauXyZjVyj0WgoFGLTI6g7ZJXgiVNf2ILe
yXEcGDnp7nQsFiuXy+hUqVSamppSNIVckyJNFAgEWNPCZdg5q6PAQucegAmBojRNkwDQoM7YfkFc
HDYwy78UjITAu6RghT2NOhS0ukgXW8EQL7aC1UMpve6Ces0JSpo6Q7Dl0ZVh9+RR2MZ2002er0UM
BBEeyGbhbXG+5OHjxx8vLAA29sN4/KjTaWYy4ePrqi9tbdmZDPcW/Fy4h+y9dP9IDnz5JYBnva+H
Z+vruA8PuxfdSuX5zZvhfB5JjCezs+o89TB7DN4J14Ao5Enfbd+5MzY9Dff88PHjH2/epIog3JeH
BBT2GKA9uUa8l6tyaS7jeM+fDAYuMOlWKt7vohIrRLkEl5g+Yh8Ym54+bDapjx8tLKjBc14dHDzf
2UE8x4YIgYMDIBUfPn6MvSVUEv+0tMQZs2AwCI1DVw+hUIQNxsWcD7fakTVinTh1AmEADCXKeLhl
J5Bs4fY/8/k8kHRjsZht2zBIXgD1TNMUr6IiPCvuNAPUnzpt0hPZHnfhUcYfe9TEqngVCsUu6p0S
tho1EolMTU1FIhEu+aNATfeix7vdLu4vwcYMbTbAx8fOiluDcE3YX0TYzZ5Q7Vx17JDUo1yV6m0o
ZmdrUcZu3LAzGWwOj01Pw0Fj/UGCk+U0oBqbUIEc6+YwYleZVvuFmRmU0gey2ZFwmO2F9PXvr13D
ZgaXInstLf664ywe12CT8ii44vYwRicm1PIEdba3cVc2K8bnOzukHPu9L9AjHTabqECF3mR18cv9
/efb2/1+VDyUoBBvzwd6EhtXGczVIFziyBePw+aJ1rRWq7mlZaXoe+zSlfpx9XqdciyFQkG0BF5q
N4m8GJJWq5XL5TjkwWAwSL/0BWYsPaYghVPF1mi5XB4gymH7hUxX+nXQ/nw+z+o78XSIIheEalS6
uAXufC6Xu337ds8yJ8dxlpeXUQMq3ZHiFLeUGQKoV5QJYXedG7WebnvPaSOdtOJBEM6h8XIhzbme
iYh+lfhp0Fm//4OJibZlXZiZQcTwolTy7uESZOBgeSQ3+vHmTfWFGAoF96JUGgmHR69eNQzj5cOH
ihKgkyLaf/bF47ii5MN4nDPe0gu2jHeGjoauRuWcaNY7HpJOG9X1Ncvn83FuvjEc5nw6nVa83mg0
dnd3kRoqFouWZcEfH+xb2CIul8uo0gGs/ZDlYShUHeDFer0eiUTezOnrIRHRvdMA1xz0bRjeHbq0
tdXZ2aFt7dGrV9kAomeGx/shDO9KCsDlA7wbyGbPoNBzfd0wjJHLl3F4uN92vJerNjOZV50OSQyH
n5/+5S/fX7uGLeKzMmR1xHYKg9rzItmTojPnz4+Ew+xFuPS790ZQHMJFDKd02QCnWL1DZ3uxCoas
flS8k9lja8FgULSO1Boql8js4V7bYrFIm6VSEjdX6LwVNk7p0DWuSBI1JufkKiIqvItyWwpBuHtq
3ci27fHx8TcwgT0ioou95mqdxTvMh5lLinJVDbutSZMmlTMu1bDvLMzRmxfFb5K0YdCkSZMmTa/H
4loEmjRp0qSJpbezx4DtexaW611GoH0zEuDAagwG+/dEII5/n8ThJ+P4wu9wvmnS1J9h4JBysfkg
FsxyVXdcDSwVSGGLCQ9Ho1EpjnGhUMDBwkAggLJoFoGWOxZEmyFsDTIHgEzEbdQoQHHdECLdTrHi
kAhbiSHFW240GuzJe5zkRFk3+2mpBMrlMhkGQMqwxy/Vh0I5WGPiluPHMAxwsri4ePfuXbZH6vEF
2pdt2yg0hEr1IgGW2HubRYRhGiyxBbwo/Rw7xNQmyzy3vQaYTA7xWBzcnvzggSGPMWvS9E5HDEOC
CQOGcHFxEWgqakesVCqFQiEsrXK5LILHsseC3MCH6RUsWulN8WqSHj5y02j9Elp2O3JZKBTUEsAz
UILY7IJeJkh37xSJRDY2Ntxg4kU9juKZSCTClWrk8/lIJDI3N1etVvP5vEIh4ousPPu9R55tASwN
UzjElpxXq1XvqGfcbOG6PAxGjSZNv51UkqJSGKi2cFej0agaocW27enjM8aTk5N0XpFDoOW0JJw+
znrhzGQymSwWi27VaScFlCY1G4Pd/NVut8lXZSUwjGE2js8N9fsup4WJWHts23a32wXPwCum4kuF
BKrVKgorFZeL9SzzQKeGyaRxd9GQA4GTboOVeGrS9Ps1DCiYJWccSXDpSnYch5auaZqE3CRtFvW8
BPIVDAbRICHQiqkknNfgHHAEE8gAhEKhzc1N8TT5YO6hG3FxiZfwQiwTVkiAy2hxWPaxWMxNhZF1
pDu8iD0ofTK9m5ub0hby+XytVjMMIxQKEdQwK0bWWgOmP5lMukkAqMXdbhexAvJ+qVSK7SaGhkVY
cxNgz1hWWtnNpi4jkQgFDXT0FLXzevNGkyZXw8CdqoBvyF6iBEiZaDRarVbZwFy6bpPJJK6Xkn4v
lUrl83k4uWyel3CdsOGhwAao1Wr5fD4ajdKtUpFI5PPPPy+VSoCAh67xCIqrBgwZMmKgPQYvEiCN
Cbaj0ShFElCpYtjkOA4QmDEoQGREZ1kzRiEFpModtoIEsEVRLpeBJTDwfNrc3MR5KJon2Wy2XC4D
P5LAwvb29sCSQoa1Wk2Uj0g0UVmXgp2ctm2zARBZ4iGtAhArxSyTJk2/BcMgndace44kz+Tk5Obm
5uTkJFYUYUMWi0XK2DiOEwgEFLmRUCgE3GCoSCxR9bYEl0qSwphgU5QFYPEOiusls0FS6gl01ZPc
JEBaTB3osEzu7u4SwD2UI64r4Z7f3d1NJpOsUXfLBKJwAAyQbo3FYqxLjsutoGrFgZCKmsOWwZ0n
gB6LRCJS29BoNDBwgx0posnJyRNYnvV6ffhYQZsETb+7VBLrphUKhVarBXUzNTV19+5dDqdlfHw8
l8vFYjHHcWq1WiqVcgsXSBPRda/sSnZ7nksliReOi8u1X1Bc0qEcypVxQohUXiQQCATI5Ig4+BAR
Z0E5HEpSvqzCglFPJBL1eh1JJ65Z3G+FNBRueQRCNQsK7fP5IMNqtdputxF5iCGUF5TjSCSSy+WQ
sMKwBoNBrl+4boWFRRvGDLdaLVy/rle7Jk19GIZWq1UqlVhtnkgkoEHgcJETiusmkAcggtOHKJ5L
JUtpfHyc07+2bXN6kE13cEVTrNaTYvwOAIortsyZpb5kSsy7WTupBFjzw+HgU15FVJRu5aFIJcHA
YPhSqdTdu3dF9zyRSBBQcygU4q7cAqXT6UKhgMyJAhHeC8rx8vJyMpnEY/g/V5cFsMy5uTmPVkG9
xwB7X6/X2U6JF7JzMmR3awzhlk3TNDMyyHFNmn5ThgHw6JTWB2A6vEvkPcRggqsi7Ut71mo1BQLt
YCj2isSFCIorBgHcX8UgQFrqLpJY5CMNbqQSYIsy4Ziz/9rtdqUpF2lZkRQfWJH66HkBiDgNBqaV
lRWFLTH6vGzL48RzHIdNKHHbTupsqlTCbLnq2tpav1ePadL0XqaSTpveGALtMNrkLUqg3W5PT09z
lkOf1B0mocRKW7wjZRjSOw2afpuGIZ1Ol0olNlimVNJpkEcE2neNxIzNYFczepFAIBAQL5DSbukJ
zrc3dneCJk3vI2l0VU2aNGnS9BppdFVNmjRp0qQNgyZNmjRp0oZBkyZNmjRpw6BJkyZNmrRh0KRJ
kyZN2jBo0qRJkyZtGDRp0qRJkzYMmjRp0qRJGwZNmjRp0qQNgyZNmjRpevv0/w8A+JHUmtyKrq8A
AAAASUVORK5CYII=

--=_NamoWEC-i81mnnsa33--


From nobody Fri Sep 15 07:52:51 2017
Return-Path: 
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 6B3381331C2 for ; Fri, 15 Sep 2017 07:52:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 ftGvrryfqAqW for ; Fri, 15 Sep 2017 07:52:47 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D5C513243A for ; Fri, 15 Sep 2017 07:52:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6220; q=dns/txt; s=iport; t=1505487167; x=1506696767; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=BU63Wq70yBAOPtICjbbEXFQ0XanEGIH7Ybur0uY/oAw=; b=bllhuF4lqhPMU3/HErOr62B1qoVSYiatg7snfHNIBUXxpO2I8QCEf12K kcCwM9Xov/sGVsGZOMmE9i70OZvC2eYFALVwOD99g0p1xELbFLA5oCfmU BEm40mdJzF9aQhQr4WbEZcSjtdZ3GKbr1GOBRhoY4fEFRF4bPilCLE9n+ E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CrAAAD6btZ/4oNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbicHg26KII9zgXSWJ4ISChgLhEpPAhqEED8YAQIBAQEBAQE?= =?us-ascii?q?BayiFGQEBAQMBASEROhsCAQYCGAICJgICAiULFRACBAESijMQjh2dZoInizEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEYBYEOgh2CAoMzgyiEYi2CfIJgBaEEAodZjHq?= =?us-ascii?q?CE4VqinuJf4sGAhEZAYE4AR84gQ13FUmFGRyBZ3aIAoEPAQEB?=
X-IronPort-AV: E=Sophos;i="5.42,397,1500940800"; d="scan'208";a="298851638"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Sep 2017 14:52:46 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v8FEqkPF006494 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 15 Sep 2017 14:52:46 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 15 Sep 2017 10:52:45 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1263.000; Fri, 15 Sep 2017 10:52:45 -0400
From: "Acee Lindem (acee)" 
To: Ladislav Lhotka , "netmod@ietf.org" 
Thread-Topic: [netmod] upcoming adoptions
Thread-Index: AQHTISEQvmg9jr+3gUCv+5ltP9XhHqK0vhUAgAADXwCAABGHAIABS1qAgAAC5wA=
Date: Fri, 15 Sep 2017 14:52:45 +0000
Message-ID: 
References: <14299503-509D-43BE-A938-0B7B88C3B249@juniper.net> <36ba3d4b-1ae1-0666-12cf-db41e172924b@cisco.com> <75739d75-da96-b340-2403-d0949ac54ed7@labn.net> <19134054-D52E-4A6D-992A-A47F365557AD@juniper.net> <1505471909.18681.7.camel@nic.cz>
In-Reply-To: <1505471909.18681.7.camel@nic.cz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.117.47]
Content-Type: text/plain; charset="utf-8"
Content-ID: <72EF2FB874DBFD418A12CC827CED427B@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 14:52:49 -0000

SGksIA0KDQpXaXRoIHJlc3BlY3QgdG8gV0cgYWRvcHRpb24sIHdlIHdpbGwgZG8gd2hhdGV2ZXIg
dGhlIFdHIGRlY2lkZXMgZm9yIHRoZQ0KUkZDIDgwMjIgbW9kZWwuIFdlIGhhdmUgYSBzdHJvbmcg
cHJlZmVyZW5jZSB0b3dhcmQgbm90IGNhcnJ5aW5nIHRoZQ0KZGVwcmVjYXRlZCBub2RlcyBmb3J3
YXJkIGFuZCBuZXcgbW9kdWxlIHZlcnNpb25zIGFwcGVhcnMgdG8gYmUgYSBnb29kIHdheQ0KdG8g
YWNoaWV2ZSB0aGlzLiANCg0KSSBhZ3JlZSB3aXRoIExhZGEgdGhhdCBkZXByZWNhdGluZyBhbGwg
dGhlIHNjaGVtYSBub2RlcyBpcyB1bm5lY2Vzc2FyeS4NCkhvd2V2ZXIsIHdl4oCZbGwgZG8gd2hh
dCBpdCB0YWtlcyB0byByZWFjaCBjb25zZW5zdXMgYW5kIHNhdGlzZnkgdGhlIG1vc3QNCnBlZGFu
dGljIGFtb25nIHVzLiANCg0KVGhhbmtzLA0KQWNlZSANCg0KT24gOS8xNS8xNywgNjozOCBBTSwg
Im5ldG1vZCBvbiBiZWhhbGYgb2YgTGFkaXNsYXYgTGhvdGthIg0KPG5ldG1vZC1ib3VuY2VzQGll
dGYub3JnIG9uIGJlaGFsZiBvZiBsaG90a2FAbmljLmN6PiB3cm90ZToNCg0KPktlbnQgV2F0c2Vu
IHDDrcWhZSB2IMSMdCAxNC4gMDkuIDIwMTcgdiAxNDo1MiArMDAwMDoNCj4+IHJmYzgwMjJiaXMt
MDIgc2lnbmFscyB0aGUgaW50ZW50IHRvIGRpdGNoIHRoZSBjdXJyZW50L3Nvb24tdG8tYmUtbGVn
YWN5DQo+PiBtb2R1bGUsIGJ1dCBkb2VzIGl0IGFjdHVhbGx5IHNheSBpdD8gIChJIGNhbid0IGZp
bmQgaXQpDQo+DQo+VGhlIG1vZHVsZXMgY29udGFpbmVkIHRoZXJlaW4gaGF2ZSBkaWZmZXJlbnQg
bmFtZXMgYW5kIG5hbWVzcGFjZXMsIHNvDQo+dGhlcmUgaXMNCj5ubyBmb3JtYWwgYW5jZXN0cnku
IEkgd291bGQgcHJlZmVyIHRvIGtlZXAgdGhlIG1vZHVsZXMgZnJvbSBSRkMgODAyMiBhcw0KPnRo
ZXkgYXJlDQo+LSBzb21lIHdlaXJkb3MgbWF5IHN0aWxsIHdhbnQgdG8gdXNlIHRoZW0uDQo+DQo+
PiANCj4+IFRoZSBkcmFmdCBkb2VzIHNheSB0aGF0IGl0IG9ic29sZXRlcyA4MDIyLCBidXQgSSdt
IHVuc3VyZSBpZiB0aGF0J3MNCj4+Z29pbmcgdG8NCj4+IGhhdmUgYSBtZWFuaW5nZnVsIGltcGFj
dCBpbiB0aGUgd2lsZC4gIEkgdGhpbmsgSnVlcmdlbiBzYWlkIHRoZXkgaGFkDQo+PnRoaXMNCj4+
IGlzc3VlIHdpdGggTUlCMiBhbmQgb25seSBhZnRlciBhIGNvdXBsZSB5ZWFycyBvZiBtaXN1c2Ug
ZGlkIHRoZXkNCj4+cmVwdWJsaXNoIHRoZQ0KPj4gbGVnYWN5IE1JQnMgd2l0aCBkZXByZWNhdGVk
IHN0YXR1cy4NCj4+IA0KPj4gSSdtIG9rYXkgd2l0aCB0aGlzIGNoYW5nZSBiZWluZyBtYWRlIGFm
dGVyIGFkb3B0aW9uLCBzbyBsb25nIGFzIHRoZXJlJ3MNCj4+IGdlbmVyYWwgYWdyZWVtZW50IHRv
IGRvIGl0LiAgQXJlIHRoZSBhdXRob3JzIG9rYXkgd2l0aCBpdCwgb3IgYXJlIHRoZXJlDQo+PmFu
eQ0KPj4gYmV0dGVyIHN1Z2dlc3Rpb25zPw0KPj4gDQo+PiBQUzogU2FkbHksIHRoZSAnbW9kdWxl
JyBzdGF0ZW1lbnQgZG9lcyBub3QgaGF2ZSAnc3RhdHVzJyBhcyBhDQo+PnN1YnN0YXRlbWVudCBb
SQ0KPj4ganVzdCBhZGRlZCB0aGlzIG9taXNzaW9uIHRvIHRoZSB5YW5nLW5leHQgdHJhY2tlcl0u
ICBJIHRoaW5rIHRoZSBvbmx5DQo+PndheSB0bw0KPj4gImRlcHJlY2F0ZSBhIG1vZHVsZSIgaXMg
dG8gaW5zdGVhZCBkZXByZWNhdGUgdGhlIGFsbCB0aGUNCj4+IG5vZGVzL3JwY3Mvbm90aWZpY2F0
aW9ucyBpbiB0aGUgbW9kdWxlLiAgS2luZCBvZiB1Z2x5LCBidXQgaXQncyBmb3IgYQ0KPj4gZGVw
cmVjYXRlZCBtb2R1bGUsIHNvIHdobyBjYXJlLCByaWdodD8gIDspDQo+DQo+SSB0aGluayBpdCBp
cyB1bm5lY2Vzc2FyeS4gSWYgc29tZWJvZHkgbmVlZHMgYWRkaW5nIHN1Y2ggYSBtb2R1bGUgdG8g
dGhlDQo+ZGF0YQ0KPm1vZGVsLCBoZS9zaGUgc2hvdWxkIHByb2JhYmx5IGhhdmUgYSByZWFzb24g
dG8gZG8gc28sIHN1Y2ggYXMgZGF0YQ0KPmltcGxlbWVudGVkDQo+b24gdGhlIHNlcnZlci4NCj4N
Cj5MYWRhICANCj4NCj4+IA0KPj4gS2VudA0KPj4gDQo+PiANCj4+IC0tDQo+PiANCj4+IEhpIFJv
YiwNCj4+IA0KPj4gT24gOS8xNC8yMDE3IDk6MzcgQU0sIFJvYmVydCBXaWx0b24gd3JvdGU6DQo+
PiA+IEhpIEtlbnQgJiBMb3UsDQo+PiA+IA0KPj4gPiBXaGVuIGRvIHlvdSB0aGluayB0aGF0IGl0
IHdpbGwgYmUgcG9zc2libGUgdG8gc3RhcnQgdGhlIGFkb3B0aW9uDQo+PnByb2Nlc3MgDQo+PiA+
IG9uIHRoZXNlIGRyYWZ0cz8NCj4+ID4gDQo+PiA+IEkgdGhpbmsgdGhhdCB0aGUgZmlyc3QgdHdv
IGF0IGxlYXN0IHdvdWxkIHNlZW0gdG8gYmUgcmVhZHkgZm9yDQo+PiA+IGFkb3B0aW9uLiAgRm9y
IHRoZSAzcmQgZHJhZnQsIHRoZXJlIHN0aWxsIHNlZW1zIHRvIGJlIGFuIG9wZW4NCj4+cXVlc3Rp
b24gDQo+PiA+IG9mIHdoYXQgdG8gZG8gd2l0aCB0aGUgb2xkIHN0YXRlIHRyZWUsIGJ1dCBwcmVz
dW1hYmx5IHRoYXQgY291bGQgYmUNCj4+ID4gc29sdmVkIGFmdGVyIHRoZSBkcmFmdCBoYXMgYmVl
biBhZG9wdGVkPw0KPj4gDQo+PiBJIHNlZSBhbiB1cGRhdGUgZm9yIHRoZSB0aGlyZCB3YXMgcHVi
bGlzaGVkIHllc3RlcmRheQ0KPj4gKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1h
Y2VlLW5ldG1vZC1yZmM4MDIyYmlzLTAyKSAgdGhhdA0KPj4gY2xhcmlmaWVzIHRoZSBpbnRlbnQg
aXMgdG8gcmVwbGFjZSB0aGUgY3VycmVudCBtb2R1bGVzLCBhbmQgcHJlc3VtYWJseQ0KPj4gb2Jz
b2xldGUgODAyMi4gIEFuZCBub3cgdGhhdCB0aGlzIGludGVuZGVkIGRpcmVjdGlvbiBpcyBjbGVh
ciBpbiB0aGUNCj4+IGRyYWZ0IHdlIGNvdWxkIHBvbGwgaXQuDQo+PiANCj4+IEkgdGhpbmsgdGhp
cyBzdGlsbCBkb2Vzbid0IGFkZHJlc3MgaWYgd2UgbmVlZCB0byBpbmRpY2F0ZSB0aGF0IHRoZQ0K
Pj4gcmZjODAyMiBkZWZpbmVkIG1vZHVsZXMgYXJlIGRlcHJlY2F0ZWQgYnkgc29tZSBvdGhlciBt
ZWNoYW5pc21zIHRoYW4NCj4+IGp1c3QgcmVwbGFjaW5nIHRoZSBSRkMsIGUuZy4sIGJ5IHVwZGF0
aW5nIHRoZSBvbGQgbW9kdWxlcyB3aXRoIGFsbCBub2Rlcw0KPj4gbWFya2VkIGFzIGRlcHJlY2F0
ZWQuICBJIHRoaW5rIHlvdSdyZSByaWdodCB0aGF0IHRoaXMgY291bGQgYmUgZG9uZSBwb3N0DQo+
PiBhZG9wdGlvbi4gIE9mIGNvdXJzZSBvdGhlcnMgYXJlIGZyZWUgdG8gZGlzYWdyZWUuDQo+PiAN
Cj4+IEkgY2hlY2sgd2l0aCBLZW50IGFuZCBzZWUgd2hhdCBoZSB0aGlua3MuDQo+PiANCj4+IFRo
YW5rcywNCj4+IExvdQ0KPj4gDQo+PiA+IA0KPj4gPiBUaGFua3MsDQo+PiA+IFJvYg0KPj4gPiAN
Cj4+ID4gDQo+PiA+IE9uIDMwLzA4LzIwMTcgMDA6NDYsIEtlbnQgV2F0c2VuIHdyb3RlOg0KPj4g
PiA+IEhleSBmb2xrcywNCj4+ID4gPiANCj4+ID4gPiBBcyBkaXNjdXNzZWQgYXQgdGhlIGxhc3Qg
bWVldGluZywgd2UgYXJlIGhlYWRpbmcgdG8gcmV2aXNpbmcNCj4+ZXhpc3RpbmcgUkZDcw0KPj4g
PiA+IHRvIGFsaWduIHRoZW0gd2l0aCBOTURBLiAgVGhlIGZpcnN0IGJhdGNoIGhhdmUgYmVlbiBw
dWJsaXNoZWQgYXMNCj4+ID4gPiBpbmRpdmlkdWFsIGRyYWZ0czoNCj4+ID4gPiANCj4+ID4gPiAx
LiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmpvcmtsdW5kLW5ldG1vZC1yZmM3
MjIzYmlzLTAwDQo+PiA+ID4gMi4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJq
b3JrbHVuZC1uZXRtb2QtcmZjNzI3N2Jpcy0wMA0KPj4gPiA+IDMuIGh0dHBzOi8vdG9vbHMuaWV0
Zi5vcmcvaHRtbC9kcmFmdC1hY2VlLW5ldG1vZC1yZmM4MDIyYmlzLTAwDQo+PiA+ID4gDQo+PiA+
ID4gUGxlYXNlIHRha2UgYSBsb29rIChjb21tZW50cyB3ZWxjb21lISkgYW5kIHN0YXkgdHVuZWQg
Zm9yIHRoZQ0KPj5yZWxhdGVkDQo+PiA+ID4gYWRvcHRpb24gY2FsbHMuDQo+PiA+ID4gDQo+PiA+
ID4gVGhhbmtzLA0KPj4gPiA+IEtlbnQgKGFuZCBMb3UpDQo+PiA+ID4gDQo+PiA+ID4gDQo+PiA+
ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4g
PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+PiA+ID4gbmV0bW9kQGlldGYub3JnDQo+PiA+ID4gaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4+ID4gPiAuDQo+PiA+
ID4gDQo+PiANCj4+IA0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KPj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4gbmV0bW9kQGlldGYub3Jn
DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPi0tIA0K
PkxhZGlzbGF2IExob3RrYQ0KPkhlYWQsIENaLk5JQyBMYWJzDQo+UEdQIEtleSBJRDogMHhCOEY5
MkIwOEE5Rjc2QzY3DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCj5uZXRtb2QgbWFpbGluZyBsaXN0DQo+bmV0bW9kQGlldGYub3JnDQo+aHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0K


From nobody Fri Sep 15 08:02:06 2017
Return-Path: 
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 996A71333AC for ; Fri, 15 Sep 2017 08:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 BP2Q0fZRZPXi for ; Fri, 15 Sep 2017 08:02:01 -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 E0DC41333DD for ; Fri, 15 Sep 2017 08:02:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5402; q=dns/txt; s=iport; t=1505487721; x=1506697321; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=olAQiD52vrxnJiCnA+yHErb3gKeoDGONZg83ByyLWVo=; b=Th1JkUDe/Qt9v5nxLqs1rP836HjvEcn8aV6iOi2wT+jZfoJ5Rk4G9NFA AKvUMefLhesJlXwOAdOLUrplgeA5Qb0lgehXdawL03PKv1XD+M/kSy+fQ 18WW8bjjup28cYFJ2coIqGPYgZv4hVedR53cB3Z6kHaQOBtYh7s+4oOgh 4=;
X-IronPort-AV: E=Sophos;i="5.42,397,1500940800"; d="scan'208";a="654645127"
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; 15 Sep 2017 15:01:59 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8FF1wpJ027793; Fri, 15 Sep 2017 15:01:58 GMT
To: "Acee Lindem (acee)" , Ladislav Lhotka , "netmod@ietf.org" 
References: <14299503-509D-43BE-A938-0B7B88C3B249@juniper.net> <36ba3d4b-1ae1-0666-12cf-db41e172924b@cisco.com> <75739d75-da96-b340-2403-d0949ac54ed7@labn.net> <19134054-D52E-4A6D-992A-A47F365557AD@juniper.net> <1505471909.18681.7.camel@nic.cz> 
From: Robert Wilton 
Message-ID: <8326bb01-63a6-9746-098b-d693b12a2396@cisco.com>
Date: Fri, 15 Sep 2017 16:01:58 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 15:02:04 -0000

On 15/09/2017 15:52, Acee Lindem (acee) wrote:
> Hi,
>
> With respect to WG adoption, we will do whatever the WG decides for the
> RFC 8022 model. We have a strong preference toward not carrying the
> deprecated nodes forward and new module versions appears to be a good way
> to achieve this.
Can we not adopt regardless?  We know that we are going to bis 8022, and 
having an adopted draft gives it a bit more legitimacy and helps other 
folks to migrate.

Or perhaps we can start the call for adoption and continue to try and 
resolve this issue at the same time ;-).  I think that it would be good 
to try and get the updated model drafts to WG LC by Singapore.

I know that it hasn't been asked yet, but I support adoption of any 8022 
bis draft that (i) provides the correct NDMA combined tree (ii) removes 
or deprecates the old state nodes :-)

Sorry, if I'm being pushy :-)
Rob


>
> I agree with Lada that deprecating all the schema nodes is unnecessary.
> However, we’ll do what it takes to reach consensus and satisfy the most
> pedantic among us.
>
> Thanks,
> Acee
>
> On 9/15/17, 6:38 AM, "netmod on behalf of Ladislav Lhotka"
>  wrote:
>
>> Kent Watsen píše v Čt 14. 09. 2017 v 14:52 +0000:
>>> rfc8022bis-02 signals the intent to ditch the current/soon-to-be-legacy
>>> module, but does it actually say it?  (I can't find it)
>> The modules contained therein have different names and namespaces, so
>> there is
>> no formal ancestry. I would prefer to keep the modules from RFC 8022 as
>> they are
>> - some weirdos may still want to use them.
>>
>>> The draft does say that it obsoletes 8022, but I'm unsure if that's
>>> going to
>>> have a meaningful impact in the wild.  I think Juergen said they had
>>> this
>>> issue with MIB2 and only after a couple years of misuse did they
>>> republish the
>>> legacy MIBs with deprecated status.
>>>
>>> I'm okay with this change being made after adoption, so long as there's
>>> general agreement to do it.  Are the authors okay with it, or are there
>>> any
>>> better suggestions?
>>>
>>> PS: Sadly, the 'module' statement does not have 'status' as a
>>> substatement [I
>>> just added this omission to the yang-next tracker].  I think the only
>>> way to
>>> "deprecate a module" is to instead deprecate the all the
>>> nodes/rpcs/notifications in the module.  Kind of ugly, but it's for a
>>> deprecated module, so who care, right?  ;)
>> I think it is unnecessary. If somebody needs adding such a module to the
>> data
>> model, he/she should probably have a reason to do so, such as data
>> implemented
>> on the server.
>>
>> Lada
>>
>>> Kent
>>>
>>>
>>> --
>>>
>>> Hi Rob,
>>>
>>> On 9/14/2017 9:37 AM, Robert Wilton wrote:
>>>> Hi Kent & Lou,
>>>>
>>>> When do you think that it will be possible to start the adoption
>>> process
>>>> on these drafts?
>>>>
>>>> I think that the first two at least would seem to be ready for
>>>> adoption.  For the 3rd draft, there still seems to be an open
>>> question
>>>> of what to do with the old state tree, but presumably that could be
>>>> solved after the draft has been adopted?
>>> I see an update for the third was published yesterday
>>> (https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-02)  that
>>> clarifies the intent is to replace the current modules, and presumably
>>> obsolete 8022.  And now that this intended direction is clear in the
>>> draft we could poll it.
>>>
>>> I think this still doesn't address if we need to indicate that the
>>> rfc8022 defined modules are deprecated by some other mechanisms than
>>> just replacing the RFC, e.g., by updating the old modules with all nodes
>>> marked as deprecated.  I think you're right that this could be done post
>>> adoption.  Of course others are free to disagree.
>>>
>>> I check with Kent and see what he thinks.
>>>
>>> Thanks,
>>> Lou
>>>
>>>> Thanks,
>>>> Rob
>>>>
>>>>
>>>> On 30/08/2017 00:46, Kent Watsen wrote:
>>>>> Hey folks,
>>>>>
>>>>> As discussed at the last meeting, we are heading to revising
>>> existing RFCs
>>>>> to align them with NMDA.  The first batch have been published as
>>>>> individual drafts:
>>>>>
>>>>> 1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00
>>>>> 2. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00
>>>>> 3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00
>>>>>
>>>>> Please take a look (comments welcome!) and stay tuned for the
>>> related
>>>>> adoption calls.
>>>>>
>>>>> Thanks,
>>>>> Kent (and Lou)
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> netmod@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>> .
>>>>>
>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> -- 
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Fri Sep 15 08:23:46 2017
Return-Path: 
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 CD51813344F for ; Fri, 15 Sep 2017 08:23:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 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, URIBL_BLOCKED=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 nKiMzNWJqy1W for ; Fri, 15 Sep 2017 08:23:42 -0700 (PDT)
Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 84024133425 for ; Fri, 15 Sep 2017 08:23:41 -0700 (PDT)
Received: by mail-lf0-x236.google.com with SMTP id d17so2777653lfe.2 for ; Fri, 15 Sep 2017 08:23:41 -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=2jkuusvy1kzaMyklSKIWA6vpK2G4w3x0upumbYGhY3g=; b=gfWmpmgzuDLRqDwCMGgoBwRWArK4FK7GICqHnlmCAihqKV3d8om29p0F8OgcalwdbK c/DeEDBv574TW11izc5MqyquE9bfv4YFYSS/Ye6tr5L3CwjmnmngUzJ21QCy9MQU7fxi lv3VqJs9XZRx8X27oaQtbK5SOeRte2BAgFvTXdfF6U9XVD1cqcU8IutdmxjRGYK0E47C cvR3u2MVHN0B6vBUpiEps0KU+9c3rQTnjkDLr8uw+a7+SX8Jd/itAT7cMr+IGlowM8Bt wCBNA9sUWU4Y55y+BoItznp3u632wjMue6jWlABUzghj1Aq9DSNfXmly0nWg1yIcszty lLCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2jkuusvy1kzaMyklSKIWA6vpK2G4w3x0upumbYGhY3g=; b=b8q51IBwvRvxD98aD/nstdmv2fwoKx/5XEwJpcmYA3fPVTJqHnd6CpHNzqsYugyQ/e Tg4uMGC4KbXjqRd04Rc3YjRgsJdzmn5DSrJEiTexSQVsLIgNRLZ/QZ2MgvnuDICMVTMz qwEz1iCgOiAO9NJEub4/jOg/6LS9RmsTclY4yxYNokDzeua55IDOFKKZ7pOe6Q0MJi0b cc15IOirsmA2KJ/akN5dTZ5tC0T8FITIrqn45OdMUqH+SJyw3KFLvPRcLv9bpPFEGqRJ oztbe1BeIZV0Xq3J9Q8nRnlH8byVAisKwq6yuVHRrxFYx2C8zywuC4Q7Tpe4tgjJHPHP nCYA==
X-Gm-Message-State: AHPjjUh3KLPyFHSuFHImxNAo1n+srSuS2j1qgrq/X9AUQVcL5JKDmw1S rVAZ0hWFJKgdCaQWKCeIEqCqUtuk+KcjYGCrtfq7SA==
X-Google-Smtp-Source: AOwi7QBy7M7GpPh2lVaguC/XVMG0BrNDIJVjwOplfgWFFU1gcwA8/lArZf42QRm0tRKDhnsAvTtRdO3HnauSPLxz02A=
X-Received: by 10.46.83.17 with SMTP id h17mr2663955ljb.158.1505489019722; Fri, 15 Sep 2017 08:23:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.18.41 with HTTP; Fri, 15 Sep 2017 08:23:38 -0700 (PDT)
In-Reply-To: <8326bb01-63a6-9746-098b-d693b12a2396@cisco.com>
References: <14299503-509D-43BE-A938-0B7B88C3B249@juniper.net> <36ba3d4b-1ae1-0666-12cf-db41e172924b@cisco.com> <75739d75-da96-b340-2403-d0949ac54ed7@labn.net> <19134054-D52E-4A6D-992A-A47F365557AD@juniper.net> <1505471909.18681.7.camel@nic.cz>  <8326bb01-63a6-9746-098b-d693b12a2396@cisco.com>
From: Andy Bierman 
Date: Fri, 15 Sep 2017 08:23:38 -0700
Message-ID: 
To: Robert Wilton 
Cc: "Acee Lindem (acee)" , Ladislav Lhotka , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c1ced703c00f005593bfabd"
Archived-At: 
Subject: Re: [netmod] upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 15:23:45 -0000

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

Hi,

So are you saying the NMDA transition strategy should be ignored?
What is the problem with deprecated nodes?
Why aren't you following your own transition strategy?


Andy

On Fri, Sep 15, 2017 at 8:01 AM, Robert Wilton  wrote:

>
>
> On 15/09/2017 15:52, Acee Lindem (acee) wrote:
>
>> Hi,
>>
>> With respect to WG adoption, we will do whatever the WG decides for the
>> RFC 8022 model. We have a strong preference toward not carrying the
>> deprecated nodes forward and new module versions appears to be a good wa=
y
>> to achieve this.
>>
> Can we not adopt regardless?  We know that we are going to bis 8022, and
> having an adopted draft gives it a bit more legitimacy and helps other
> folks to migrate.
>
> Or perhaps we can start the call for adoption and continue to try and
> resolve this issue at the same time ;-).  I think that it would be good t=
o
> try and get the updated model drafts to WG LC by Singapore.
>
> I know that it hasn't been asked yet, but I support adoption of any 8022
> bis draft that (i) provides the correct NDMA combined tree (ii) removes o=
r
> deprecates the old state nodes :-)
>
> Sorry, if I'm being pushy :-)
> Rob
>
>
>
>> I agree with Lada that deprecating all the schema nodes is unnecessary.
>> However, we=E2=80=99ll do what it takes to reach consensus and satisfy t=
he most
>> pedantic among us.
>>
>> Thanks,
>> Acee
>>
>> On 9/15/17, 6:38 AM, "netmod on behalf of Ladislav Lhotka"
>>  wrote:
>>
>> Kent Watsen p=C3=AD=C5=A1e v =C4=8Ct 14. 09. 2017 v 14:52 +0000:
>>>
>>>> rfc8022bis-02 signals the intent to ditch the current/soon-to-be-legac=
y
>>>> module, but does it actually say it?  (I can't find it)
>>>>
>>> The modules contained therein have different names and namespaces, so
>>> there is
>>> no formal ancestry. I would prefer to keep the modules from RFC 8022 as
>>> they are
>>> - some weirdos may still want to use them.
>>>
>>> The draft does say that it obsoletes 8022, but I'm unsure if that's
>>>> going to
>>>> have a meaningful impact in the wild.  I think Juergen said they had
>>>> this
>>>> issue with MIB2 and only after a couple years of misuse did they
>>>> republish the
>>>> legacy MIBs with deprecated status.
>>>>
>>>> I'm okay with this change being made after adoption, so long as there'=
s
>>>> general agreement to do it.  Are the authors okay with it, or are ther=
e
>>>> any
>>>> better suggestions?
>>>>
>>>> PS: Sadly, the 'module' statement does not have 'status' as a
>>>> substatement [I
>>>> just added this omission to the yang-next tracker].  I think the only
>>>> way to
>>>> "deprecate a module" is to instead deprecate the all the
>>>> nodes/rpcs/notifications in the module.  Kind of ugly, but it's for a
>>>> deprecated module, so who care, right?  ;)
>>>>
>>> I think it is unnecessary. If somebody needs adding such a module to th=
e
>>> data
>>> model, he/she should probably have a reason to do so, such as data
>>> implemented
>>> on the server.
>>>
>>> Lada
>>>
>>> Kent
>>>>
>>>>
>>>> --
>>>>
>>>> Hi Rob,
>>>>
>>>> On 9/14/2017 9:37 AM, Robert Wilton wrote:
>>>>
>>>>> Hi Kent & Lou,
>>>>>
>>>>> When do you think that it will be possible to start the adoption
>>>>>
>>>> process
>>>>
>>>>> on these drafts?
>>>>>
>>>>> I think that the first two at least would seem to be ready for
>>>>> adoption.  For the 3rd draft, there still seems to be an open
>>>>>
>>>> question
>>>>
>>>>> of what to do with the old state tree, but presumably that could be
>>>>> solved after the draft has been adopted?
>>>>>
>>>> I see an update for the third was published yesterday
>>>> (https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-02)  that
>>>> clarifies the intent is to replace the current modules, and presumably
>>>> obsolete 8022.  And now that this intended direction is clear in the
>>>> draft we could poll it.
>>>>
>>>> I think this still doesn't address if we need to indicate that the
>>>> rfc8022 defined modules are deprecated by some other mechanisms than
>>>> just replacing the RFC, e.g., by updating the old modules with all nod=
es
>>>> marked as deprecated.  I think you're right that this could be done po=
st
>>>> adoption.  Of course others are free to disagree.
>>>>
>>>> I check with Kent and see what he thinks.
>>>>
>>>> Thanks,
>>>> Lou
>>>>
>>>> Thanks,
>>>>> Rob
>>>>>
>>>>>
>>>>> On 30/08/2017 00:46, Kent Watsen wrote:
>>>>>
>>>>>> Hey folks,
>>>>>>
>>>>>> As discussed at the last meeting, we are heading to revising
>>>>>>
>>>>> existing RFCs
>>>>
>>>>> to align them with NMDA.  The first batch have been published as
>>>>>> individual drafts:
>>>>>>
>>>>>> 1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00
>>>>>> 2. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00
>>>>>> 3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00
>>>>>>
>>>>>> Please take a look (comments welcome!) and stay tuned for the
>>>>>>
>>>>> related
>>>>
>>>>> adoption calls.
>>>>>>
>>>>>> Thanks,
>>>>>> Kent (and Lou)
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> netmod mailing list
>>>>>> netmod@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>> .
>>>>>>
>>>>>>
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>
>>> --
>>> Ladislav Lhotka
>>> Head, CZ.NIC Labs
>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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


Hi,

So are you saying the NMDA transiti=
on strategy should be ignored?
What is the problem with deprecate=
d nodes?
Why aren't you following your own transition str=
ategy?


Andy

On Fri, Sep 1=
5, 2017 at 8:01 AM, Robert Wilton <rwilton@cisco.com> wrote:=





On 15/09/2017 15:52, Acee Lindem (acee) wrote:



Hi,



With respect to WG adoption, we will do whatever the WG decides for the

RFC 8022 model. We have a strong preference toward not carrying the

deprecated nodes forward and new module versions appears to be a good way
to achieve this.



Can we not adopt regardless?=C2=A0 We know that we are going to bis 8022, a=
nd having an adopted draft gives it a bit more legitimacy and helps other f=
olks to migrate.



Or perhaps we can start the call for adoption and continue to try and resol=
ve this issue at the same time ;-).=C2=A0 I think that it would be good to =
try and get the updated model drafts to WG LC by Singapore.



I know that it hasn't been asked yet, but I support adoption of any 802=
2 bis draft that (i) provides the correct NDMA combined tree (ii) removes o=
r deprecates the old state nodes :-)



Sorry, if I'm being pushy :-)

Rob









I agree with Lada that deprecating all the schema nodes is unnecessary.

However, we=E2=80=99ll do what it takes to reach consensus and satisfy the =
most

pedantic among us.



Thanks,

Acee



On 9/15/17, 6:38 AM, "netmod on behalf of Ladislav Lhotka"

<netmod-bou=
nces@ietf.org on behalf of lhotka@nic.cz> wrote:





Kent Watsen p=C3=AD=C5=A1e v =C4=8Ct 14. 09. 2017 v 14:52 +0000:



rfc8022bis-02 signals the intent to ditch the current/soon-to-be-legacy

module, but does it actually say it?=C2=A0 (I can't find it)



The modules contained therein have different names and namespaces, so

there is

no formal ancestry. I would prefer to keep the modules from RFC 8022 as

they are

- some weirdos may still want to use them.





The draft does say that it obsoletes 8022, but I'm unsure if that's=


going to

have a meaningful impact in the wild.=C2=A0 I think Juergen said they had
this

issue with MIB2 and only after a couple years of misuse did they

republish the

legacy MIBs with deprecated status.



I'm okay with this change being made after adoption, so long as there&#=
39;s

general agreement to do it.=C2=A0 Are the authors okay with it, or are ther=
e

any

better suggestions?



PS: Sadly, the 'module' statement does not have 'status' as=
 a

substatement [I

just added this omission to the yang-next tracker].=C2=A0 I think the only<=
br>
way to

"deprecate a module" is to instead deprecate the all the

nodes/rpcs/notifications in the module.=C2=A0 Kind of ugly, but it's fo=
r a

deprecated module, so who care, right?=C2=A0 ;)



I think it is unnecessary. If somebody needs adding such a module to the
data

model, he/she should probably have a reason to do so, such as data

implemented

on the server.



Lada





Kent





--



Hi Rob,



On 9/14/2017 9:37 AM, Robert Wilton wrote:



Hi Kent & Lou,



When do you think that it will be possible to start the adoption



process



on these drafts?



I think that the first two at least would seem to be ready for

adoption.=C2=A0 For the 3rd draft, there still seems to be an open



question



of what to do with the old state tree, but presumably that could be

solved after the draft has been adopted?



I see an update for the third was published yesterday

(https://tools.ietf.org/html/draft-a=
cee-netmod-rfc8022bis-02)=C2=A0 that

clarifies the intent is to replace the current modules, and presumably

obsolete 8022.=C2=A0 And now that this intended direction is clear in the
draft we could poll it.



I think this still doesn't address if we need to indicate that the

rfc8022 defined modules are deprecated by some other mechanisms than

just replacing the RFC, e.g., by updating the old modules with all nodes
marked as deprecated.=C2=A0 I think you're right that this could be don=
e post

adoption.=C2=A0 Of course others are free to disagree.



I check with Kent and see what he thinks.



Thanks,

Lou





Thanks,

Rob





On 30/08/2017 00:46, Kent Watsen wrote:



Hey folks,



As discussed at the last meeting, we are heading to revising



existing RFCs



to align them with NMDA.=C2=A0 The first batch have been published as

individual drafts:



1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00

2. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00

3. https://tools.ietf.org/html/draft=
-acee-netmod-rfc8022bis-00



Please take a look (comments welcome!) and stay tuned for the



related



adoption calls.



Thanks,

Kent (and Lou)





_______________________________________________

netmod mailing list

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









_______________________________________________

netmod mailing list

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


-- 

Ladislav Lhotka

Head, CZ.NIC Labs

PGP Key ID: 0xB8F92B08A9F76C67



_______________________________________________

netmod mailing list

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


_______________________________________________

netmod mailing list

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




_______________________________________________

netmod mailing list

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




--94eb2c1ced703c00f005593bfabd--


From nobody Fri Sep 15 09:02:47 2017
Return-Path: 
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 706D6133527 for ; Fri, 15 Sep 2017 09:02:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 96fG_2RlpxlZ for ; Fri, 15 Sep 2017 09:02:36 -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 C8A1D132D4B for ; Fri, 15 Sep 2017 09:02:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29019; q=dns/txt; s=iport; t=1505491355; x=1506700955; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=6Nq8Mt5HAwKJE4Vgcjp3hQNagPFtdGgHc554S6XzTJI=; b=NAAu6RBlrlndjto9k5KG09uZ71xOLMtRx7qiEBuUDwEcSlD99FIKEMAe YgsfLYePCAg6PL+4PLMLMo3hWw7y67rNM78urCnq65Mtqk8E8Wsqi4TXr aNjJlgXhQWBsYhqaQFR456oGmNpsycuy4k3lWwvJPYxgp6jhz3TcQaNDB o=;
X-IronPort-AV: E=Sophos;i="5.42,397,1500940800";  d="scan'208,217";a="657490033"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Sep 2017 16:02:33 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v8FG2XkI025112; Fri, 15 Sep 2017 16:02:33 GMT
To: Andy Bierman 
Cc: "Acee Lindem (acee)" , Ladislav Lhotka , "netmod@ietf.org" 
References: <14299503-509D-43BE-A938-0B7B88C3B249@juniper.net> <36ba3d4b-1ae1-0666-12cf-db41e172924b@cisco.com> <75739d75-da96-b340-2403-d0949ac54ed7@labn.net> <19134054-D52E-4A6D-992A-A47F365557AD@juniper.net> <1505471909.18681.7.camel@nic.cz>  <8326bb01-63a6-9746-098b-d693b12a2396@cisco.com> 
From: Robert Wilton 
Message-ID: 
Date: Fri, 15 Sep 2017 17:02:33 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------0040993E14D25652F20C8D5A"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 16:02:44 -0000

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



On 15/09/2017 16:23, Andy Bierman wrote:
> Hi,
>
> So are you saying the NMDA transition strategy should be ignored?
My personal preference for the routing modules would be to keep the same 
module name and deprecate the old nodes.

However, I doubt that there are many implementations of this 8022 yet, 
and if the authors prefer to use a new namespace without the old nodes 
then I'm fine with that also.  Are you opposed to this approach?

E.g. For ietf-interfaces, and ietf-ip, which are older, and hence 
probably much more widely implemented then I think that the modules 
should be updated in place with the existing state tree deprecated. I.e. 
I support what Martin has done in his IDs, and don't want this to change.

> What is the problem with deprecated nodes?
Nothing really, but I guess that they are likely to be baggage that is 
going to be around for a long time even if very few people ever 
implement the deprecated nodes.


> Why aren't you following your own transition strategy?
Really because I'm not an author, both solutions seem valid, and I 
actually think just reaching a conclusion quickly is more important than 
which particular solution is chosen.  I don't see any advantage is 
pushing back the adoption call - it seems like it will probably just 
delay when we can do WG LC.

I actually think that the bigger question that needs to be resolved is 
whether we need an optional extension to mark a module as NMDA 
compatible, or for the extra NMDA state module, as I think that both you 
and Tom have been asking for.

Thanks,
Rob


>
>
> Andy
>
> On Fri, Sep 15, 2017 at 8:01 AM, Robert Wilton  > wrote:
>
>
>
>     On 15/09/2017 15:52, Acee Lindem (acee) wrote:
>
>         Hi,
>
>         With respect to WG adoption, we will do whatever the WG
>         decides for the
>         RFC 8022 model. We have a strong preference toward not
>         carrying the
>         deprecated nodes forward and new module versions appears to be
>         a good way
>         to achieve this.
>
>     Can we not adopt regardless?  We know that we are going to bis
>     8022, and having an adopted draft gives it a bit more legitimacy
>     and helps other folks to migrate.
>
>     Or perhaps we can start the call for adoption and continue to try
>     and resolve this issue at the same time ;-).  I think that it
>     would be good to try and get the updated model drafts to WG LC by
>     Singapore.
>
>     I know that it hasn't been asked yet, but I support adoption of
>     any 8022 bis draft that (i) provides the correct NDMA combined
>     tree (ii) removes or deprecates the old state nodes :-)
>
>     Sorry, if I'm being pushy :-)
>     Rob
>
>
>
>         I agree with Lada that deprecating all the schema nodes is
>         unnecessary.
>         However, we’ll do what it takes to reach consensus and satisfy
>         the most
>         pedantic among us.
>
>         Thanks,
>         Acee
>
>         On 9/15/17, 6:38 AM, "netmod on behalf of Ladislav Lhotka"
>          on
>         behalf of lhotka@nic.cz > wrote:
>
>             Kent Watsen píše v Čt 14. 09. 2017 v 14:52 +0000:
>
>                 rfc8022bis-02 signals the intent to ditch the
>                 current/soon-to-be-legacy
>                 module, but does it actually say it?  (I can't find it)
>
>             The modules contained therein have different names and
>             namespaces, so
>             there is
>             no formal ancestry. I would prefer to keep the modules
>             from RFC 8022 as
>             they are
>             - some weirdos may still want to use them.
>
>                 The draft does say that it obsoletes 8022, but I'm
>                 unsure if that's
>                 going to
>                 have a meaningful impact in the wild.  I think Juergen
>                 said they had
>                 this
>                 issue with MIB2 and only after a couple years of
>                 misuse did they
>                 republish the
>                 legacy MIBs with deprecated status.
>
>                 I'm okay with this change being made after adoption,
>                 so long as there's
>                 general agreement to do it.  Are the authors okay with
>                 it, or are there
>                 any
>                 better suggestions?
>
>                 PS: Sadly, the 'module' statement does not have
>                 'status' as a
>                 substatement [I
>                 just added this omission to the yang-next tracker]. I
>                 think the only
>                 way to
>                 "deprecate a module" is to instead deprecate the all the
>                 nodes/rpcs/notifications in the module.  Kind of ugly,
>                 but it's for a
>                 deprecated module, so who care, right?  ;)
>
>             I think it is unnecessary. If somebody needs adding such a
>             module to the
>             data
>             model, he/she should probably have a reason to do so, such
>             as data
>             implemented
>             on the server.
>
>             Lada
>
>                 Kent
>
>
>                 --
>
>                 Hi Rob,
>
>                 On 9/14/2017 9:37 AM, Robert Wilton wrote:
>
>                     Hi Kent & Lou,
>
>                     When do you think that it will be possible to
>                     start the adoption
>
>                 process
>
>                     on these drafts?
>
>                     I think that the first two at least would seem to
>                     be ready for
>                     adoption.  For the 3rd draft, there still seems to
>                     be an open
>
>                 question
>
>                     of what to do with the old state tree, but
>                     presumably that could be
>                     solved after the draft has been adopted?
>
>                 I see an update for the third was published yesterday
>                 (https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-02
>                 )
>                 that
>                 clarifies the intent is to replace the current
>                 modules, and presumably
>                 obsolete 8022.  And now that this intended direction
>                 is clear in the
>                 draft we could poll it.
>
>                 I think this still doesn't address if we need to
>                 indicate that the
>                 rfc8022 defined modules are deprecated by some other
>                 mechanisms than
>                 just replacing the RFC, e.g., by updating the old
>                 modules with all nodes
>                 marked as deprecated.  I think you're right that this
>                 could be done post
>                 adoption.  Of course others are free to disagree.
>
>                 I check with Kent and see what he thinks.
>
>                 Thanks,
>                 Lou
>
>                     Thanks,
>                     Rob
>
>
>                     On 30/08/2017 00:46, Kent Watsen wrote:
>
>                         Hey folks,
>
>                         As discussed at the last meeting, we are
>                         heading to revising
>
>                 existing RFCs
>
>                         to align them with NMDA.  The first batch have
>                         been published as
>                         individual drafts:
>
>                         1.
>                         https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00
>                         
>                         2.
>                         https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00
>                         
>                         3.
>                         https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00
>                         
>
>                         Please take a look (comments welcome!) and
>                         stay tuned for the
>
>                 related
>
>                         adoption calls.
>
>                         Thanks,
>                         Kent (and Lou)
>
>
>                         _______________________________________________
>                         netmod mailing list
>                         netmod@ietf.org 
>                         https://www.ietf.org/mailman/listinfo/netmod
>                         
>                         .
>
>
>
>                 _______________________________________________
>                 netmod mailing list
>                 netmod@ietf.org 
>                 https://www.ietf.org/mailman/listinfo/netmod
>                 
>
>             -- 
>             Ladislav Lhotka
>             Head, CZ.NIC Labs
>             PGP Key ID: 0xB8F92B08A9F76C67
>
>             _______________________________________________
>             netmod mailing list
>             netmod@ietf.org 
>             https://www.ietf.org/mailman/listinfo/netmod
>             
>
>         _______________________________________________
>         netmod mailing list
>         netmod@ietf.org 
>         https://www.ietf.org/mailman/listinfo/netmod
>         
>
>
>     _______________________________________________
>     netmod mailing list
>     netmod@ietf.org 
>     https://www.ietf.org/mailman/listinfo/netmod
>     
>
>


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


  
    
  
  
    


    

    

    
On 15/09/2017 16:23, Andy Bierman
      wrote:

    

    

      
      
Hi,
        


        

        
So are you saying the NMDA transition strategy should be
          ignored?

      

    

    My personal preference for the routing modules would be to keep the
    same module name and deprecate the old nodes.

    

    However, I doubt that there are many implementations of this 8022
    yet, and if the authors prefer to use a new namespace without the
    old nodes then I'm fine with that also.  Are you opposed to this
    approach?

    

    E.g. For ietf-interfaces, and ietf-ip, which are older, and hence
    probably much more widely implemented then I think that the modules
    should be updated in place with the existing state tree deprecated. 
    I.e. I support what Martin has done in his IDs, and don't want this
    to change.

    

    

      

        
What is the problem with deprecated nodes?

        

      

    

    Nothing really, but I guess that they are likely to be baggage that
    is going to be around for a long time even if very few people ever
    implement the deprecated nodes.

    

    

    

      

        
Why aren't you following your own transition strategy?

      

    

    Really because I'm not an author, both solutions seem valid, and I
    actually think just reaching a conclusion quickly is more important
    than which particular solution is chosen.  I don't see any advantage
    is pushing back the adoption call - it seems like it will probably
    just delay when we can do WG LC.

    

    I actually think that the bigger question that needs to be resolved
    is whether we need an optional extension to mark a module as NMDA
    compatible, or for the extra NMDA state module, as I think that both
    you and Tom have been asking for.

    

    Thanks,

    Rob

    

    

    

      

        


        

        


        

        
Andy

        


          
On Fri, Sep 15, 2017 at 8:01 AM,
            Robert Wilton <rwilton@cisco.com>
            wrote:

            


              

              On 15/09/2017 15:52, Acee Lindem (acee) wrote:

              

                Hi,

                

                With respect to WG adoption, we will do whatever the WG
                decides for the

                RFC 8022 model. We have a strong preference toward not
                carrying the

                deprecated nodes forward and new module versions appears
                to be a good way

                to achieve this.

              

              Can we not adopt regardless?  We know that we are going to
              bis 8022, and having an adopted draft gives it a bit more
              legitimacy and helps other folks to migrate.

              

              Or perhaps we can start the call for adoption and continue
              to try and resolve this issue at the same time ;-).  I
              think that it would be good to try and get the updated
              model drafts to WG LC by Singapore.

              

              I know that it hasn't been asked yet, but I support
              adoption of any 8022 bis draft that (i) provides the
              correct NDMA combined tree (ii) removes or deprecates the
              old state nodes :-)

              

              Sorry, if I'm being pushy :-)

              Rob

              

              

              

                

                I agree with Lada that deprecating all the schema nodes
                is unnecessary.

                However, we’ll do what it takes to reach consensus and
                satisfy the most

                pedantic among us.

                

                Thanks,

                Acee

                

                On 9/15/17, 6:38 AM, "netmod on behalf of Ladislav
                Lhotka"

                <netmod-bounces@ietf.org
                on behalf of lhotka@nic.cz>
                wrote:

                

                

                  Kent Watsen píše v Čt 14. 09. 2017 v 14:52 +0000:

                  

                    rfc8022bis-02 signals the intent to ditch the
                    current/soon-to-be-legacy

                    module, but does it actually say it?  (I can't find
                    it)

                  

                  The modules contained therein have different names and
                  namespaces, so

                  there is

                  no formal ancestry. I would prefer to keep the modules
                  from RFC 8022 as

                  they are

                  - some weirdos may still want to use them.

                  

                  

                    The draft does say that it obsoletes 8022, but I'm
                    unsure if that's

                    going to

                    have a meaningful impact in the wild.  I think
                    Juergen said they had

                    this

                    issue with MIB2 and only after a couple years of
                    misuse did they

                    republish the

                    legacy MIBs with deprecated status.

                    

                    I'm okay with this change being made after adoption,
                    so long as there's

                    general agreement to do it.  Are the authors okay
                    with it, or are there

                    any

                    better suggestions?

                    

                    PS: Sadly, the 'module' statement does not have
                    'status' as a

                    substatement [I

                    just added this omission to the yang-next tracker]. 
                    I think the only

                    way to

                    "deprecate a module" is to instead deprecate the all
                    the

                    nodes/rpcs/notifications in the module.  Kind of
                    ugly, but it's for a

                    deprecated module, so who care, right?  ;)

                  

                  I think it is unnecessary. If somebody needs adding
                  such a module to the

                  data

                  model, he/she should probably have a reason to do so,
                  such as data

                  implemented

                  on the server.

                  

                  Lada

                  

                  

                    Kent

                    

                    

                    --

                    

                    Hi Rob,

                    

                    On 9/14/2017 9:37 AM, Robert Wilton wrote:

                    

                      Hi Kent & Lou,

                      

                      When do you think that it will be possible to
                      start the adoption

                    

                    process

                    

                      on these drafts?

                      

                      I think that the first two at least would seem to
                      be ready for

                      adoption.  For the 3rd draft, there still seems to
                      be an open

                    

                    question

                    

                      of what to do with the old state tree, but
                      presumably that could be

                      solved after the draft has been adopted?

                    

                    I see an update for the third was published
                    yesterday

                    (https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-02) 
                    that

                    clarifies the intent is to replace the current
                    modules, and presumably

                    obsolete 8022.  And now that this intended direction
                    is clear in the

                    draft we could poll it.

                    

                    I think this still doesn't address if we need to
                    indicate that the

                    rfc8022 defined modules are deprecated by some other
                    mechanisms than

                    just replacing the RFC, e.g., by updating the old
                    modules with all nodes

                    marked as deprecated.  I think you're right that
                    this could be done post

                    adoption.  Of course others are free to disagree.

                    

                    I check with Kent and see what he thinks.

                    

                    Thanks,

                    Lou

                    

                    

                      Thanks,

                      Rob

                      

                      

                      On 30/08/2017 00:46, Kent Watsen wrote:

                      

                        Hey folks,

                        

                        As discussed at the last meeting, we are heading
                        to revising

                      

                    

                    existing RFCs

                    

                      

                        to align them with NMDA.  The first batch have
                        been published as

                        individual drafts:

                        

                        1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00

                        2. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00

                        3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00

                        

                        Please take a look (comments welcome!) and stay
                        tuned for the

                      

                    

                    related

                    

                      

                        adoption calls.

                        

                        Thanks,

                        Kent (and Lou)

                        

                        

                        _______________________________________________

                        netmod mailing list

                        netmod@ietf.org

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

                        .

                        

                      

                    

                    

                    

                    _______________________________________________

                    netmod mailing list

                    netmod@ietf.org

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

                  

                  -- 

                  Ladislav Lhotka

                  Head, CZ.NIC Labs

                  PGP Key ID: 0xB8F92B08A9F76C67

                  

                  _______________________________________________

                  netmod mailing list

                  netmod@ietf.org

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

                

                _______________________________________________

                netmod mailing list

                netmod@ietf.org

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

              

              

              _______________________________________________

              netmod mailing list

              netmod@ietf.org

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

            

          

          

        

      

    

    

  


--------------0040993E14D25652F20C8D5A--


From nobody Fri Sep 15 09:22:02 2017
Return-Path: 
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 D527613301E; Fri, 15 Sep 2017 09:22:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.91
X-Spam-Level: 
X-Spam-Status: No, score=-2.91 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 BgT22-5AVxNm; Fri, 15 Sep 2017 09:21:58 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30098.outbound.protection.outlook.com [40.107.3.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06B881243F6; Fri, 15 Sep 2017 09:21: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=Ul20a7rwD4TqWteBxF2TfkBhHePy77bS6DsqB82TqLo=; b=h7Pt3dj3QupY8so7eq9ndNzrFmcp9bvNF3ANerj2Ab5usTphRko1IhqEdFD0fkdgS5v4ZOfTGN9O2t4oSCVZyl+3L73oJu87ii19W6umsDNpQiVv8bG3ZFAqYwqD/jvIDTDbGDCe9Y/Lp2svV2gUPAiTu+O1Q2Yg3HzuCLJsyMY=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (86.185.245.5) by DB6PR0701MB3000.eurprd07.prod.outlook.com (2603:10a6:4:73::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Fri, 15 Sep 2017 16:21:55 +0000
Message-ID: <000901d32e3e$883fa9c0$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Lou Berger" , "netmod WG" 
Cc: , 
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net>
Date: Fri, 15 Sep 2017 17:20:15 +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: [86.185.245.5]
X-ClientProxiedBy: DB6P190CA0031.EURP190.PROD.OUTLOOK.COM (2603:10a6:6:2f::44) To DB6PR0701MB3000.eurprd07.prod.outlook.com (2603:10a6:4:73::10)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: b390c499-4b20-4111-b61b-08d4fc55e1fc
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB6PR0701MB3000; 
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB3000; 3:B7G/riNAx97jesaumQLf7J0BJXGx9Oaat069rH83inW960zB3Q1AKITYwUVsAOvx4fT+ZczsTkEsj4Eu+tEl6lcNwT6DoNxfgGr5BugIP5IcdMnAclblTcL9P++0DfSEVtwiSZVHY4DhcJqfM6wgdhtGrxmCvIxaRHxfhFVUQ5qbPg+fqAbmXhG6LAd2cHgO4pPpsvEfUzqZdSotNy0hJT+OkNEy5YUJwBGyzoFeWhe7p5vR5vmTxTrPGLSFtbzB; 25:i98OHJkBvYZfK32TShL8ZPWg6rG7gRXNg8DiHwhdOtKhcxtrPxne4ytIM9s9+yYMwlZt0H+A7rSh503su+bldjHNEVym5ObMSx0b0ipIQaQ2KE2Q7U9OCuU2FZh30vByzrd0KiQ+L6BIm55kgJfxG50BW+k187Kt5OHne8QB1fF4HwByOx6HSW43VZA0MpFtnaBFy8wOmszTb9F8OGXJFzYZywD8RNPyCsu795TWbLEbS5Ae2A0jUkgKyfxR6J+bTNpYqKoLTBt8WVLqop4keKblKFEoSkIQ5rPuEfqB0GTxPNhjqt9uY26YScN/nZpPgcC3ie3MsQpBbKWrpt6qGQ==; 31:w5Cko1uYsy6vhEIXiQGZymI5CsoZGQBRee6LPJiutwH5gvPAEXP679cNUlOOWb3QCZJgMx7gWvtM9kdKw3hHcTyhzCTMqjax7oJTZN97ainnYw/Fuk5uOHBKsR24wiQXfRthXy7dMbFb5SPuCu4phA2VyP0i2eNYn8lAo6zVK72o1Whjza8KYnsFIPi9B37J3hzf1k3Uj5LxuIek68yBAALasd9Sm/9OBYUfWu63K7c=
X-MS-TrafficTypeDiagnostic: DB6PR0701MB3000:
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB3000; 20:YYCmYjuhDFFJPRzxfSkiZ93zqtSCh5/F/HKwpevbTa/bbMBTNf8dK83sfXvWVVxiTL5AidnhJmFJnwZLKrSnXDLQHp+XCZ/wFzSIOEoBI0YbjotO21MQQMO25GkTSQLneDv1d9GSYVnpqG1zg0Vrzq6AjNLkA1WRWE+Xv7fUD6rICBAjZ5+4ULlJciKi/EglTPBxnAU1hL9a5huvU50jnEZeFSGgYKyMc+nRKoeEZYV6l2xo+BExA23PxjJT7hwj; 4:/LAq5WG33Eq7VAWpJ+wLQ23sAQHDnWIiAdeAnAw8v1SQhpGDJ7h1MghVe5QNMS01PnTXpyphUAZs4+P9KW6ERj44nridIQ0nRDfek1IlPfD3l3El0lsu5NDZCgF0Ooy6VNLl2ZUNOXH529Iiq+rMGpxOP62nVgI2rZLFL7Ulh8nQOBXWk1yTaOn7yseMMPNb29vCBfIn8OJWUURTb1ulQhmzhnx9UZMo2Zvm8zT0EndJt0AuMb/ZfoRbjnDECUrJ
X-Exchange-Antispam-Report-Test: UriScan:;
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB6PR0701MB3000; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB6PR0701MB3000; 
X-Forefront-PRVS: 0431F981D8
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(13464003)(377454003)(189002)(199003)(6486002)(81156014)(4326008)(966005)(97736004)(61296003)(3846002)(6116002)(81166006)(8676002)(316002)(305945005)(33646002)(7736002)(5660300001)(189998001)(66066001)(47776003)(23756003)(44716002)(86362001)(53936002)(6496005)(6246003)(84392002)(229853002)(101416001)(4720700003)(76176999)(50986999)(1556002)(478600001)(54906002)(81816999)(2906002)(81686999)(9686003)(62236002)(25786009)(6666003)(6306002)(44736005)(68736007)(106356001)(50466002)(230700001)(50226002)(105586002)(1456003)(230783001)(8936002)(116806002)(14496001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB3000; 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: =?iso-8859-1?Q?1; DB6PR0701MB3000; 23:B5QUPuJXhoaR+pOghMwKaofzN8uvm7o7goRD1?= =?iso-8859-1?Q?VDEnlg1xCd+xdTG9nhCkMrGiDQwQ1Chb63p1+5kPdDTIWNLa99zMi5sOy1?= =?iso-8859-1?Q?tAN8mL2VWDmPHE+9TxbdB5GSypEp58ufyW9KAOZZ+zrLFYvMM8eSDPWGXx?= =?iso-8859-1?Q?b8YxWD40cpVhPCCnbD6UX/PFbydsjbK1Cpo1tIEGT+03JVsKIF3T8xlx+y?= =?iso-8859-1?Q?e3YHhYFjLhdOlp5I+tk6i+QLabH48KJ4JmsVBmKVsy074suLorg0oz2Ggm?= =?iso-8859-1?Q?tNzuMDCXiyA2Qg8LbR/EqZ4iogLKUIpo/tuH+kUm19HsZdMPVBcsqXXmCZ?= =?iso-8859-1?Q?nF+/rf1O00uM7P9FgTLMeQjvViGdmMgTwIM1fOONUk2tj2cuPixCN2xyzt?= =?iso-8859-1?Q?X0Xb+sTt3KIuvV1zbw1+0hLQ+mg9D/XaJpXrx+umnQrZ/ssQuPYrHH7/6z?= =?iso-8859-1?Q?2ywd5O+SOXY4NhGJJIuIkCYse4bK0LwVcdbMj68CnRExOpqVQnqoZlmeBM?= =?iso-8859-1?Q?uiJOooMCXH9r11aSMyZZMuyNhaYVsoTFpC3E7V3WGg1bJuZDvt4v9B8lL9?= =?iso-8859-1?Q?0quxTiq+fqbw6dDixF5kiuABxXakH4T9oOvAFiCSO4dIIZ2sTZ/dUAK72V?= =?iso-8859-1?Q?hERUvg4awEhaW6qOGYtimoMYSXFM6X8ytn5VYXBc0Amh+Ss8ZZyjcrniMe?= =?iso-8859-1?Q?X7w4CbBFQ/n85jyswn4jSpBy1jQqWGmOPyDynAH0ikWNn8QUCBdhQjPXjL?= =?iso-8859-1?Q?vJlhRReWxvccoADfxYpYbgXYMqPLf3sDl4PgWcEvwUCpEPjHLuw4LcKp2/?= =?iso-8859-1?Q?TwSAxuGUqe201HGF6i1a5TiRDwLp9uG8q5yq2ufr/7PWV4d902u/tJFGN1?= =?iso-8859-1?Q?RYFCo3AylF/oVmxcqAL3MIalwtl6PGf1noEtbi5cnBDTNKkWvsVuIGGUkS?= =?iso-8859-1?Q?j5Rcuk1m/Jq1w6xd7PuGw1arGdOBG0TNEqBrjk+PbBYu0W85szM+WX8ItN?= =?iso-8859-1?Q?QvDIniWuJbTno65mAcAQoschduszHVeRdul0263xkN0tteXdcZI4TcView?= =?iso-8859-1?Q?/biMp8kZl5AWvxW4SU371/MOMUl5A4C5o/L5qpbr9rF7mDVVrIN2aSldgx?= =?iso-8859-1?Q?zdSVIc8AjBDJf8+5nHTwoeavL7/2NuE+Vjbt168mZyuiyIQSq0CfJ1sdx6?= =?iso-8859-1?Q?bpgtD+jizEE2sVDvy0VxzdJkWpkugoKmfqXyQsM2cGt2qdhn7+Lqsdq+r5?= =?iso-8859-1?Q?DAaG3pIqQYf3jV9OGfDa1Z6J2+0pwj9Y/PpLlAGvg5ex3HZCJ0IcjZ0QWs?= =?iso-8859-1?Q?BxNGEhUN34TOlsXMBkfu9wwv69/E0GyFlp94Xac0eUyhFHC7YWXbUVVdAW?= =?iso-8859-1?Q?FP6h6iUDvURP0Ig7FRh/i+0XrJebYikkZ7fATu5i9XwFIPSo7MSfp2vyQ5?= =?iso-8859-1?Q?d6+Zj2LfH1PjKTGYghp0seiCzos/lSXBSHYe1HN4ePIu6WksZW9fqOYXuU?= =?iso-8859-1?Q?HvSg5gn1wj8I6Mhj4fgjIA=3D?=
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB3000; 6:cl35YLF4l9Yz370ysJ5TYKwznXC0cqwG1R14dtcR0ReqBaQ3HyUC9SR4k9xNpT8qOru5eftit93shx3NFyaLXWiG69BfZzkj2ctoHbsfuqTm3jW0sCptQRHS+rTgDr1viI1Ak2E1UpezItavNhlZjniIY5BwLmj9oUWwv+Bc1zANgoDZ2io0pkbTTd5bEOEUT+znLPNQjNW9kt75l2wH0q4SG8tcVOJHk6FSu21JkPit3JV9A9yhgorsMCpxvc8hh5nPxEa9cdHJqYxxfiOwk3+ndg1qF0FOQWzibg6x2LazpJGntZpyDJtRCp9dOMEFai1cv41U9kKC8WKecL7OWA==; 5:+FbmsFuWpkx/uRQdKxptBI6GgcszZYpDWKeo0pVxE8izFXeWCmLHANRIfd/azPu06vjBVmtwxtBQgZjwpmNHtDsgcH3PQ2NJq9V76o/1FbMK+bVmB8SsvEMMkwGAaCNG7xk6sjyDc25RoOrB1gbW1A==; 24:P7wQEH32+uIFzkbJfq2aTQU22CrbIlpiZkb6k9SO0RLZn2dzN16v4acbXv2Khfl9NY+6lMu2/MymJg++MBXSOS5dHeE3JzKuW6actt7sy9U=; 7:1BJn7m0GKlABplIuhxy3MO/SMwHiJTaoLP+enPn9bLN6oPXYbN5uym5teoRRAerV7NjLRCvQE1BafazblNmxbkc/Uv1kQuEiJao3FGiphzvv1ydfMzQNWuoeUFGYtepj/4QNnu3rR+8xsvVX0v6Ujh/wjFCnK66eKN4YxueYq1iF4gM3BMNgPK6IX52JkRtX/sZHAg6ppMCAi3hNibP6sV4i+uoadzo+lg1nV/I7eHs=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Sep 2017 16:21:55.6656 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB3000
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 inactive
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 16:22:01 -0000

Inactive appears a dozen times but is not defined, except in the course
of those appearances it effectively is, but is sometimes 'inactive',
sometimes 'inactive configuration', sometimes 'inactive data'.

I would find it clearer if the term was used consistently and if there
was an explicit definition amongst the other definitions in section 2
such as

inactve configuration: Configuration that is present in  which
is not in use by the device and which plays no part in validation.  It
cannot appear in any other datastore.  The protocols that are currently
standardised do not support inactive configuration but a number of
proprietary protocols do. Inactive configuration is only exposed to
clients that indicate support for inactive configuration; clients not
indicating support for  inactive configuration receive the contents of
 with the inactive configuration removed.

This would put a stake in the ground for as and when the concept is
standardised and may reduce the proliferation of the term with multiple
meanings.

Tom Petch


----- Original Message -----
From: "Lou Berger" 
Sent: Friday, September 01, 2017 10:02 PM

> This starts a two week working group last call on
> draft-ietf-netmod-revised-datastores-04.
>
> The working group last call ends on September 17.
> Please send your comments to the netmod mailing list.
>
> Positive comments, e.g., "I've reviewed this document and
> believe it is ready for publication", are welcome!
> This is useful and important, even from authors.
>
> Thank you,
> Netmod Chairs
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Fri Sep 15 09:30:35 2017
Return-Path: 
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 C773413209C for ; Fri, 15 Sep 2017 09:30:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.91
X-Spam-Level: 
X-Spam-Status: No, score=-2.91 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 uIoaGimXICbe for ; Fri, 15 Sep 2017 09:30:32 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0131.outbound.protection.outlook.com [104.47.2.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C293F126BF3 for ; Fri, 15 Sep 2017 09:30:31 -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=bF6n4q5xqn2Y0X+RMFLl3QBOZW2hodQN1SsnyX9JitY=; b=fDKJdmyed4Vam1gkX7GGWk0UIFcFWw8HQQILmnOR4nfUQOg1hGAn6kLaoNsrpl2WyPx9jfFPet4+i8eoxzkbOWwpIll6VPWG0bWHklwQUv98qsmupHaNcTXSvrMdVSNtoC15F6oDKTx662PeV9y2NtPaKTWOcxBzS3rWZM1Ra30=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (86.185.245.5) by VI1PR0701MB3008.eurprd07.prod.outlook.com (2603:10a6:800:87::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Fri, 15 Sep 2017 16:30:29 +0000
Message-ID: <003801d32e3f$ba625460$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Kent Watsen" , "Robert Wilton" ,  , "Lou Berger" 
References: <14299503-509D-43BE-A938-0B7B88C3B249@juniper.net> <36ba3d4b-1ae1-0666-12cf-db41e172924b@cisco.com> <75739d75-da96-b340-2403-d0949ac54ed7@labn.net> <19134054-D52E-4A6D-992A-A47F365557AD@juniper.net> <2891bd09-0e0d-415c-2714-15141a293e42@cisco.com>  <011d01d32d77$c8e0a500$4001a8c0@gateway.2wire.net> <9c0d8394-b2a4-180a-2454-8955c1721423@labn.net>
Date: Fri, 15 Sep 2017 17:28:50 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [86.185.245.5]
X-ClientProxiedBy: DB6P190CA0033.EURP190.PROD.OUTLOOK.COM (2603:10a6:6:2f::46) To VI1PR0701MB3008.eurprd07.prod.outlook.com (2603:10a6:800:87::22)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: de1b5fd2-8c7c-44db-655a-08d4fc571424
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:VI1PR0701MB3008; 
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3008; 3:Y3a52tJQldahyYL6f5cIS7Z8gTEJGE7LlNcGwVJ66F2fsIJdumTSWuU6+aTZ6Yd7pgo3LNrM7RSgEn4lyPB+pkjAfLJfqMV/eUQQXqavQSXK1RS5kI45Vw7Fh5No49OFU+U9Lpj+i+BMBwqQJ00wK0uzVA35vshBOCXfZNMKGoJNdSdoO0FsuGbZx/8BPsUiuZyoYMJ+J4U543BZp98Ng0M9Qdfdwa+BUa4IyJNPp9XQUYvWw+r7QIknl/E6cHm+; 25:1TFwrb6yR8eT1IM6yhxTiesqGYXDL6viSzdk12JIeAOw/fMB8NnZY0WcsddfCWVDC/9gll4zI68h57hPGsFsCU0EESGDHl2TlFQeB5stqIWBulwam5aS2xx6XPGCt9iGRCKqeNDMa2cePze6Vac/tL0oviX2FzDocc6j7WmusmmvB2r73vl2DQ0tBHTTSw6Eq9C0BtMM3zivfwS2Rua5n3434Tikw0GuSCZzQq7etu43+8gZgA3orhwXjtOxLR8rEYJ0UkfnJ53o0q4qLK+WEGJkXhRltDV/QU36u746C0P1HDvMuatewDZ+PIuckEseX3HKyWGdO0ad6GdjjFTkqg==; 31:yN7KcTkAScU+3jiUyinrGNn39U1JJND0UZmTqVU8v250gc/23NhvIKlUf5VH55pYdHObVvnu9kvjqulqSbOIyLcPUiBmI35T6PG0YdbnMP9hPC9QuqYeE/5Rcq2lE8JFWlo1V30Z/9y4zMwDuwhgDpsim3FcDvQTjDhFGDpoB0RKU8l7XmR0oyPHQDsijfj3EE3UeNImHXoK4FRo8CDN6oVhk9iOOXsN8KcYVJJ0O8A=
X-MS-TrafficTypeDiagnostic: VI1PR0701MB3008:
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3008; 20:NGzolz7Ns84veCd5z3sfUt5v4f/ynjJ9s3CW26tqnwiPBpFBV44j1rWsQfsWUYZKcDNbMh+JVP0VfuDt7JZ7qSuVC41JnNvazaGLwG8eIvtqKqZlJrty2uDRSUaZzRz3eaZgpKILMfZNL7XUodqFBvU+8+mWqtI/aPk7elQz4lGLzgXl4UZyGsRi/ipg1tGnRboKEtZSL9Q8e6mUiqUDjcy6YhK0224riBec/VPchBoZQOL7EbxweZaBW3puQ7hV; 4:KVQqKH3bX4tIHWmiH6FJN8KcVYkaC2TnRHWVVa48dh+VFE+h6ptTJVe1n0d+QPRsRhNqLDScf8rv7MfJj8unUoNUqoYKKK6hZjUa1EWe669M31Glli8Cq7MQXmcjLmJ0XbfHNiQCM5exjTD1R1RzwXWub9GwvnCbe1KrDxBZMWksmiqN795Wv65+1Z7ZTIyhGRiirsCEyqHj2SrRoxnmKbcKgBp27MmPvVfzrWA0AHNg/psQfZxbuAU/dzjry8GL
X-Exchange-Antispam-Report-Test: UriScan:;
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR0701MB3008; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR0701MB3008; 
X-Forefront-PRVS: 0431F981D8
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6009001)(39860400002)(376002)(346002)(199003)(189002)(24454002)(377454003)(13464003)(316002)(305945005)(47776003)(7736002)(97736004)(116806002)(1941001)(50466002)(44716002)(62236002)(9686003)(84392002)(1456003)(53546010)(6496005)(229853002)(1556002)(44736005)(6486002)(2906002)(7350300001)(53936002)(23676002)(66066001)(6246003)(81156014)(50226002)(81166006)(230700001)(8676002)(101416001)(478600001)(33646002)(106356001)(105586002)(5660300001)(4720700003)(81686999)(76176999)(3846002)(6116002)(50986999)(93886005)(86362001)(14496001)(8666007)(61296003)(25786009)(6666003)(189998001)(81816999)(68736007)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB3008; 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?MTtWSTFQUjA3MDFNQjMwMDg7MjM6cWVZTXFHQ29vL1Zhcnh2czdHMVlzeVlK?= =?utf-8?B?bWp6bVV6M3NYSzBFR3luNG1IQ3JVSTUzTkg1NHVNcGRRVFVzOVErbFN6aTNQ?= =?utf-8?B?a2FTeXYxTXhhbW1hL2R2aTRSNG5GWGtlOGN3M2Y4Q3grMWh1T2s3NzMycFMv?= =?utf-8?B?UmJyaTQrSmNZbWxoeU5KVUl2V2tlTFdLTTQ5VGpxQ0s0VVZrTmN4WDUzMnZr?= =?utf-8?B?RGk4aWdMV01tR0VTV2dWYVpka2FGTkp5dm1nbk03aXd5dkJnaVVhZk53WC93?= =?utf-8?B?R1ZROEUrN1dLdzlDYzNGZm0ycEc3cXpYNFpOaDJucjRHaXpBZ1lsZ1VTRU5B?= =?utf-8?B?ZDNkblRoZC9KZ0JPMW5QRmxuaDYwdTRjckVNaUZVWktDcEErcDhnUU5zWmJI?= =?utf-8?B?UTN5NUlYc0NVRVhqQW5ZTXV2WGhlYkd4TTlLeUVUTThESlh5aXhYWndLN0s4?= =?utf-8?B?RWJhYStzTWNvbjBTZVdEOWRBczlnTDlseHp4QnloTzdLQlpMV1hLZldsdEpp?= =?utf-8?B?OEtRQ2dHZjhOQjU4WTFiYnlXN2E0YjVWYmtNZExQOWJOSTVYOERranI4TFEz?= =?utf-8?B?aldDWDJQd3J4MllCM2pCTFFxZHRhUWxPTUZBd1RUUzVJaUx0eDlRRllBOUJH?= =?utf-8?B?dmY3cXJSVEY3c1ZsVVR5WkdiS2QwM0Y4Q0NrM2ttdDV4L09ENDZmMjRXNFNu?= =?utf-8?B?MFJWRmxYWUcrVlhBKzN0UnVoNWdUekRMNXpyR0lRWldYekhNRkplSlBVWGdS?= =?utf-8?B?Ti9yZFF4VERIWEk4TXJnMElVa3QzOW8yOEN4M1luVXJQRXVKanVzckF1YjNB?= =?utf-8?B?T05wZTUzSjZXK04zS1ZzLzVnM1FyUUpKR1F5Nk01YkhMSzhseHF5Nncxc0ZQ?= =?utf-8?B?blhONWdrSlJ3Z05URXNURU1SQXVZSFZjNTJ1Vkw0dlhaY2I4Z3lOa0JsVjhW?= =?utf-8?B?UUZOTzZUSkNwSXBGQUorRkdzbkNKWjQzR1hqWkpaU2dMSXFpSURhcmxtcHAv?= =?utf-8?B?V2xUZWVhZDBwV3lBNlZtUDc0Qjl0U2FucGJLVHBZZlVTSXpIYzhkZnpBMkVK?= =?utf-8?B?Nk9EeVdRdHV1VmpuNlg2dWtFZDhwS2srdmYxeFZ2WGtOK2YxOWRGajU4K3Ri?= =?utf-8?B?REtlMFg0MGU4eGwxZU1YTVFqQkJvTUdybkw5a2taekpST3Q5Y3pJV01tT2l6?= =?utf-8?B?cG54SnVudW9Sazc1eFNzS0V2SzNDa1R2V283eFRTTjlra3M4RXpvQUYwWXk0?= =?utf-8?B?S01lM21VS05YamVnSWNOQThzNkRqcDRVSWlUMzhOMXgwWWI3anl1aHBsWjBW?= =?utf-8?B?NVg5VE56Z3gyMW51QWtTVnJNSE9lSmN1ZWdCVldaYTZLSE9LMUN0ZW1JWVZP?= =?utf-8?B?WnZ4c2M5WWFqRy9aTkFPbHUyVnlmMnI2UUo0VWg4T0JvQ0hzTjA0dFliRmFH?= =?utf-8?B?QkJVblBCUjFXcEFvdU9nZWpoMnZoNVhnQm9lTmtTYlBiNXltdzEyUW9HRG40?= =?utf-8?B?OXNlcWVOZXlxWjM5VmxmRWs4NUNQUm1EZXUvekwxeDJrRUNsUzQxVmtVQUFI?= =?utf-8?B?aVhVa0J5TTNudWgxQUZ5Z2pZU3k5YWxFQkJ3NWNMd0NPT0dTSUdIYnBEenNN?= =?utf-8?B?L3dZT2JaSW11clA3SGU3L3pERFdVNkh6WFlrbE9pTkI2NzB6Yy9LWDYrbUdK?= =?utf-8?B?VWZoZXJJOTA3STVQRGJJSUhaMVd3TzZhbE1hdC8xVG1sNC9Sa214OE1LL2dk?= =?utf-8?B?a29wWHF1U0RPcVVEM1c5RDFhUnNyb3ZXUTVVcE5jYjdMd1NUR3Z2SmdLZ0s3?= =?utf-8?B?dHBvZERxSnBQc1VTWGluQ3Vqb3ZWRzd4OXpqQ3ZjSE95SzlrL0pGaTFSMmlU?= =?utf-8?B?OCtENVZGNWprdTROdlNxZ29HK0ZxQzU0THdtazRLWFZSWE4xcDhoSFBXKzdV?= =?utf-8?B?SU43VURad28yS3RxWnVNUEd2VnJBYTYrTHVFR0J3d1V4Vys0YUtXU0VrdUt6?= =?utf-8?B?QmNiUUZpMGZHZUYvaytLenBoTUdVcTFCemlaaFp0T1k1Kys5czZQYmFuSmNu?= =?utf-8?Q?DQl56Y=3D?=
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3008; 6:0meV4Hs2UGGqjviFbOp7+Ymvw75FO7SUHUcxxOsCexU2948bBWVP0OXEQ219/QdclSc53d3uL8jcuSTiSWXZxBcfoCI5LKdYVLYcgWEhHx8OBw2nHJNkkB3dxGmM6+xdwXoPN9c+HhkD41FuRovJhM63qWyTvNdCwuca417QwSdJNyEr9D2ucJt1V7LpC0IKm79yyM94UCyyqAaVqTaDrmgFm4TCx0HUiYEYCtFoqLdQJON8OKS8qtbdSZUa5z4CH0vLLC9M7qG8Z30N149M99G1sc6xFoL1mzt6oed1ey0eyiF6XF+Ywy9rps3zzdukpeSK08QwI9Qtxo3rsTY/gw==; 5:MtjSBU0NbNP9RDNTLZceb1JVUDDTllXGKmy8bK0GD+UBGg1dyAPrsmGdxxoP94urWmwK0NZHevRyRB2Fek9H4l/FYTzsOjnvcyUFdHT+EEJLcuoQU4OmVF78r3Ya1VjmXBrjUL1Pvh0Q5gDYjUnuRQ==; 24:7FEAs9JnlFKCa6ir5sU+zHTu6InUN9TeBZFYbVlNoAGRC/aGkOfRFGiZxm2z/LMauUL4ZGkUUF8dmlH0TwPDhUHkHZYdqnF9heID9gg8L2Y=; 7:VN9xu+yMProSg37XFagtAJcB1RlyXUMeJyU8UFjOCdFVTKrCufd5R5hTwHedn8q2hB0ETD/ZhyC2scwVBKRrhMPbKWL8U5muickNkBKodEHC59xBnVyCR6FXXhSMp9LQFeBzXcK1vpDkbhbcgPmySa9dz8FFBJ9WO6PKlF/tiSfE2Uk1i3iYNEoKZOt8uv5W93+gMxI8HhJfzX6sszdYbsJ2KiFB/0K3csmEmgjYErI=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Sep 2017 16:30:29.1210 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB3008
Archived-At: 
Subject: Re: [netmod] upcoming adoptions - this appendix is normative
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 16:30:34 -0000

----- Original Message -----
From: "Lou Berger" 
Sent: Thursday, September 14, 2017 6:06 PM

> On 9/14/2017 12:36 PM, t.petch wrote:
> > Appendices are Normative if they say that they are Normative.  The
> > default is that they are not so say that they are and they are.
This is
> > well established practice.
>
> Hi Tom,
> My memory (I haven't checked recently) is there is nothing in or
> defined process that says if an Appendix is normative or not. Other
> SDOs certainly have formal definitions here. Within the IETF, my view
> has been that if an appendix includes RFC2119 language, it is
> normative. Actually, strictly speaking, any text in a Standards Track
> RFC that doesn't include RFC2119 language is just informative.

Lou

Try RFC4910.

'   This appendix is normative. '

and not a SHOULD or a MUST in sight.

Tom Petch

> Lou
>


From nobody Fri Sep 15 09:31:03 2017
Return-Path: 
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 81CB313209C for ; Fri, 15 Sep 2017 09:31:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Rk4r2sk9TY0K for ; Fri, 15 Sep 2017 09:30:58 -0700 (PDT)
Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::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 47B2C126BF3 for ; Fri, 15 Sep 2017 09:30:58 -0700 (PDT)
Received: by mail-lf0-x230.google.com with SMTP id u21so2929447lfk.12 for ; Fri, 15 Sep 2017 09:30:58 -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=pjOF4IWuyu/uVM63gBZkDd2QLqtpepwgn6SsZw8f2aA=; b=QCfOL3Et1VIvxus22II1DWcGqBEjU1O5MgKeDBX1Lh62b6kMS83HtNev9rOJoRTjad sOzeTWGBkmy2fNh35EifrfQkLKUaehPdh/a7yp9RiwWyO8wcCoc/fBUfUwy5o5tKrYNJ t+YiUYBv6o5fUlCor/ayMuABHhiWiJxSdluprS6EJfvTNkER9f2EQLt/knUmtYnRnUWs AROzfa/fMpS+ijbe8JafUbrrUOpsTcFv5bw+D4Tnigpjy7YtSuo+oiDw2x0vCQkdfQp1 E35UfGn9g/tCabx1gByV6VaqBpBVSLrXypeKr9N+Of268URHhI9lTKcy461xKl+30AGP s/MQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pjOF4IWuyu/uVM63gBZkDd2QLqtpepwgn6SsZw8f2aA=; b=G7PIhlavOwCVaL9xRWG3nwiS4HCpmyl+uoDrcufy4q82cS7Hh0F23SxBnKFsWJY6yp EUHXGPPYX622SboaVqKoK0pjjtU5L8jh5Ax/DcMmAOMIBNgwhIo9vP24kzKQ+CUPZOp3 p33UKXdkVPZcB/WAr4bZVyxict0AmHlwsAfm8OhiQ+zX756qUST47jgPEWn38lTEF1EN hC1ZGP74m+B+GqSoe5etGj5JbzjAb0Nuzq8ycKZT/57zzxKWzJQ865B7UhPgdtKQdQ+x wUXsKx4dSrgC1XUUxZL0v73y6GAfkLcUgsgizJ4tiEsdl2bntYC85uC+0msfxlVyr/ej +e7A==
X-Gm-Message-State: AHPjjUh0Ydb1KKZ5QOp74CdTtMLU26xr6B81sPpZso0JU1ykdi36Bun0 yRxF4RyVSPfoECPT7g/gTr9kODDjU8S9Fqahf2C0sg==
X-Google-Smtp-Source: AOwi7QDeDJ9JBB7T3BxeoOerY5YOl9RBG6iwY6C1TCgm+tm6dOXQf9w/YLT1SIcBeYNihwksRbhf4UAWbCN/R2XSpSA=
X-Received: by 10.25.235.220 with SMTP id f89mr868570lfk.194.1505493055433; Fri, 15 Sep 2017 09:30:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.18.41 with HTTP; Fri, 15 Sep 2017 09:30:54 -0700 (PDT)
In-Reply-To: 
References: <14299503-509D-43BE-A938-0B7B88C3B249@juniper.net> <36ba3d4b-1ae1-0666-12cf-db41e172924b@cisco.com> <75739d75-da96-b340-2403-d0949ac54ed7@labn.net> <19134054-D52E-4A6D-992A-A47F365557AD@juniper.net> <1505471909.18681.7.camel@nic.cz>  <8326bb01-63a6-9746-098b-d693b12a2396@cisco.com>  
From: Andy Bierman 
Date: Fri, 15 Sep 2017 09:30:54 -0700
Message-ID: 
To: Robert Wilton 
Cc: "Acee Lindem (acee)" , Ladislav Lhotka , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="001a113c1796c82ef305593ceab7"
Archived-At: 
Subject: Re: [netmod] upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 16:31:01 -0000

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

On Fri, Sep 15, 2017 at 9:02 AM, Robert Wilton  wrote:

>
>
> On 15/09/2017 16:23, Andy Bierman wrote:
>
> Hi,
>
> So are you saying the NMDA transition strategy should be ignored?
>
> My personal preference for the routing modules would be to keep the same
> module name and deprecate the old nodes.
>
> However, I doubt that there are many implementations of this 8022 yet, an=
d
> if the authors prefer to use a new namespace without the old nodes then I=
'm
> fine with that also.  Are you opposed to this approach?
>
>

A new module name mandates a new namespace, so they go together.
Abandoning the old module is fine, except leaving that module with status
"current" is not fine.
IMO you need to republish the old module as well, with everything status
obsolete.



> E.g. For ietf-interfaces, and ietf-ip, which are older, and hence probabl=
y
> much more widely implemented then I think that the modules should be
> updated in place with the existing state tree deprecated.  I.e. I support
> what Martin has done in his IDs, and don't want this to change.
>
> What is the problem with deprecated nodes?
>
> Nothing really, but I guess that they are likely to be baggage that is
> going to be around for a long time even if very few people ever implement
> the deprecated nodes.
>
>
> Why aren't you following your own transition strategy?
>
> Really because I'm not an author, both solutions seem valid, and I
> actually think just reaching a conclusion quickly is more important than
> which particular solution is chosen.  I don't see any advantage is pushin=
g
> back the adoption call - it seems like it will probably just delay when w=
e
> can do WG LC.
>
> I actually think that the bigger question that needs to be resolved is
> whether we need an optional extension to mark a module as NMDA compatible=
,
> or for the extra NMDA state module, as I think that both you and Tom have
> been asking for.
>

I am no fan of YANG conformance.
The WG does not seem to understand the difference between
   (A) what a server is supposed to do
   (B) what a server claims to do

There is no way to express (A) in a YANG module, just (B) in the new
yang-library.


Andy



>
> Thanks,
> Rob
>
>
>
>
> Andy
>
> On Fri, Sep 15, 2017 at 8:01 AM, Robert Wilton  wrote:
>
>>
>>
>> On 15/09/2017 15:52, Acee Lindem (acee) wrote:
>>
>>> Hi,
>>>
>>> With respect to WG adoption, we will do whatever the WG decides for the
>>> RFC 8022 model. We have a strong preference toward not carrying the
>>> deprecated nodes forward and new module versions appears to be a good w=
ay
>>> to achieve this.
>>>
>> Can we not adopt regardless?  We know that we are going to bis 8022, and
>> having an adopted draft gives it a bit more legitimacy and helps other
>> folks to migrate.
>>
>> Or perhaps we can start the call for adoption and continue to try and
>> resolve this issue at the same time ;-).  I think that it would be good =
to
>> try and get the updated model drafts to WG LC by Singapore.
>>
>> I know that it hasn't been asked yet, but I support adoption of any 8022
>> bis draft that (i) provides the correct NDMA combined tree (ii) removes =
or
>> deprecates the old state nodes :-)
>>
>> Sorry, if I'm being pushy :-)
>> Rob
>>
>>
>>
>>> I agree with Lada that deprecating all the schema nodes is unnecessary.
>>> However, we=E2=80=99ll do what it takes to reach consensus and satisfy =
the most
>>> pedantic among us.
>>>
>>> Thanks,
>>> Acee
>>>
>>> On 9/15/17, 6:38 AM, "netmod on behalf of Ladislav Lhotka"
>>>  wrote:
>>>
>>> Kent Watsen p=C3=AD=C5=A1e v =C4=8Ct 14. 09. 2017 v 14:52 +0000:
>>>>
>>>>> rfc8022bis-02 signals the intent to ditch the current/soon-to-be-lega=
cy
>>>>> module, but does it actually say it?  (I can't find it)
>>>>>
>>>> The modules contained therein have different names and namespaces, so
>>>> there is
>>>> no formal ancestry. I would prefer to keep the modules from RFC 8022 a=
s
>>>> they are
>>>> - some weirdos may still want to use them.
>>>>
>>>> The draft does say that it obsoletes 8022, but I'm unsure if that's
>>>>> going to
>>>>> have a meaningful impact in the wild.  I think Juergen said they had
>>>>> this
>>>>> issue with MIB2 and only after a couple years of misuse did they
>>>>> republish the
>>>>> legacy MIBs with deprecated status.
>>>>>
>>>>> I'm okay with this change being made after adoption, so long as there=
's
>>>>> general agreement to do it.  Are the authors okay with it, or are the=
re
>>>>> any
>>>>> better suggestions?
>>>>>
>>>>> PS: Sadly, the 'module' statement does not have 'status' as a
>>>>> substatement [I
>>>>> just added this omission to the yang-next tracker].  I think the only
>>>>> way to
>>>>> "deprecate a module" is to instead deprecate the all the
>>>>> nodes/rpcs/notifications in the module.  Kind of ugly, but it's for a
>>>>> deprecated module, so who care, right?  ;)
>>>>>
>>>> I think it is unnecessary. If somebody needs adding such a module to t=
he
>>>> data
>>>> model, he/she should probably have a reason to do so, such as data
>>>> implemented
>>>> on the server.
>>>>
>>>> Lada
>>>>
>>>> Kent
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Hi Rob,
>>>>>
>>>>> On 9/14/2017 9:37 AM, Robert Wilton wrote:
>>>>>
>>>>>> Hi Kent & Lou,
>>>>>>
>>>>>> When do you think that it will be possible to start the adoption
>>>>>>
>>>>> process
>>>>>
>>>>>> on these drafts?
>>>>>>
>>>>>> I think that the first two at least would seem to be ready for
>>>>>> adoption.  For the 3rd draft, there still seems to be an open
>>>>>>
>>>>> question
>>>>>
>>>>>> of what to do with the old state tree, but presumably that could be
>>>>>> solved after the draft has been adopted?
>>>>>>
>>>>> I see an update for the third was published yesterday
>>>>> (https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-02)  that
>>>>> clarifies the intent is to replace the current modules, and presumabl=
y
>>>>> obsolete 8022.  And now that this intended direction is clear in the
>>>>> draft we could poll it.
>>>>>
>>>>> I think this still doesn't address if we need to indicate that the
>>>>> rfc8022 defined modules are deprecated by some other mechanisms than
>>>>> just replacing the RFC, e.g., by updating the old modules with all
>>>>> nodes
>>>>> marked as deprecated.  I think you're right that this could be done
>>>>> post
>>>>> adoption.  Of course others are free to disagree.
>>>>>
>>>>> I check with Kent and see what he thinks.
>>>>>
>>>>> Thanks,
>>>>> Lou
>>>>>
>>>>> Thanks,
>>>>>> Rob
>>>>>>
>>>>>>
>>>>>> On 30/08/2017 00:46, Kent Watsen wrote:
>>>>>>
>>>>>>> Hey folks,
>>>>>>>
>>>>>>> As discussed at the last meeting, we are heading to revising
>>>>>>>
>>>>>> existing RFCs
>>>>>
>>>>>> to align them with NMDA.  The first batch have been published as
>>>>>>> individual drafts:
>>>>>>>
>>>>>>> 1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00
>>>>>>> 2. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00
>>>>>>> 3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00
>>>>>>>
>>>>>>> Please take a look (comments welcome!) and stay tuned for the
>>>>>>>
>>>>>> related
>>>>>
>>>>>> adoption calls.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Kent (and Lou)
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> netmod mailing list
>>>>>>> netmod@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>> .
>>>>>>>
>>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> netmod@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>
>>>> --
>>>> Ladislav Lhotka
>>>> Head, CZ.NIC Labs
>>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>
>

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




On Fri, Sep 15, 2017 at 9:02 AM, Robert Wilton <rwilton@cisco.com&=
gt; wrote:

 =20
   =20
 =20
  

    


    

    

    
On 15/09/2017 16:23=
, Andy Bierman
      wrote:

    

    

     =20
      
Hi,
        


        

        
So are you saying the NMDA transition strategy should be
          ignored?

      

    

    My personal preference for the routing modules would be to keep the
    same module name and deprecate the old nodes.

    

    However, I doubt that there are many implementations of this 8022
    yet, and if the authors prefer to use a new namespace without the
    old nodes then I'm fine with that also.=C2=A0 Are you opposed to th=
is
    approach?

    


A new module =
name mandates a new namespace, so they go together.
Abandoning th=
e old module is fine, except leaving that module with status "current&=
quot; is not fine.
IMO you need to republish the old module as we=
ll, with everything status obsolete.

=C2=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">

    E.g. For ietf-interfaces, and ietf-ip, which are older, and hence
    probably much more widely implemented then I think that the modules
    should be updated in place with the existing state tree deprecated.=C2=
=A0
    I.e. I support what Martin has done in his IDs, and don't want this
    to change.

    

    

      

        
What is the problem with deprecated nodes?

        

      

    

    Nothing really, but I guess that they are likely to be baggage that
    is going to be around for a long time even if very few people ever
    implement the deprecated nodes.

    

    

    

      

        
Why aren't you following your own transition strategy?
      

    

    Really because I'm not an author, both solutions seem valid, and I
    actually think just reaching a conclusion quickly is more important
    than which particular solution is chosen.=C2=A0 I don't see any adv=
antage
    is pushing back the adoption call - it seems like it will probably
    just delay when we can do WG LC.

    

    I actually think that the bigger question that needs to be resolved
    is whether we need an optional extension to mark a module as NMDA
    compatible, or for the extra NMDA state module, as I think that both
    you and Tom have been asking for.

=

I am no fan of YANG conformance.
The WG does not seem to und=
erstand the difference between
=C2=A0 =C2=A0(A) what a server is =
supposed to do
=C2=A0 =C2=A0(B) what a server claims to do
<=
div>
There is no way to express (A) in a YANG module, just (B=
) in the new yang-library.


Andy

=C2=A0

    

    Thanks,

    Rob

    

    

    

      

        


        

        


        

        
Andy

        


          
On Fri, Sep 15, 2017 at 8:01 AM,
            Robert Wilton <rwilton@cisco.com>
            wrote:

            


              

              On 15/09/2017 15:52, Acee Lindem (acee) wrote:

              

                Hi,

                

                With respect to WG adoption, we will do whatever the WG
                decides for the

                RFC 8022 model. We have a strong preference toward not
                carrying the

                deprecated nodes forward and new module versions appears
                to be a good way

                to achieve this.

              

              Can we not adopt regardless?=C2=A0 We know that we are going =
to
              bis 8022, and having an adopted draft gives it a bit more
              legitimacy and helps other folks to migrate.

              

              Or perhaps we can start the call for adoption and continue
              to try and resolve this issue at the same time ;-).=C2=A0 I
              think that it would be good to try and get the updated
              model drafts to WG LC by Singapore.

              

              I know that it hasn't been asked yet, but I support
              adoption of any 8022 bis draft that (i) provides the
              correct NDMA combined tree (ii) removes or deprecates the
              old state nodes :-)

              

              Sorry, if I'm being pushy :-)

              Rob

              

              

              

                

                I agree with Lada that deprecating all the schema nodes
                is unnecessary.

                However, we=E2=80=99ll do what it takes to reach consensus =
and
                satisfy the most

                pedantic among us.

                

                Thanks,

                Acee

                

                On 9/15/17, 6:38 AM, "netmod on behalf of Ladislav
                Lhotka"

                <netmod-bounces@ietf.org
                on behalf of lhotka@nic.cz>
                wrote:

                

                

                  Kent Watsen p=C3=AD=C5=A1e v =C4=8Ct 14. 09. 2017 v 14:52=
 +0000:

                  

                    rfc8022bis-02 signals the intent to ditch the
                    current/soon-to-be-legacy

                    module, but does it actually say it?=C2=A0 (I can't=
 find
                    it)

                  

                  The modules contained therein have different names and
                  namespaces, so

                  there is

                  no formal ancestry. I would prefer to keep the modules
                  from RFC 8022 as

                  they are

                  - some weirdos may still want to use them.

                  

                  

                    The draft does say that it obsoletes 8022, but I'm
                    unsure if that's

                    going to

                    have a meaningful impact in the wild.=C2=A0 I think
                    Juergen said they had

                    this

                    issue with MIB2 and only after a couple years of
                    misuse did they

                    republish the

                    legacy MIBs with deprecated status.

                    

                    I'm okay with this change being made after adoption=
,
                    so long as there's

                    general agreement to do it.=C2=A0 Are the authors okay
                    with it, or are there

                    any

                    better suggestions?

                    

                    PS: Sadly, the 'module' statement does not have
                    'status' as a

                    substatement [I

                    just added this omission to the yang-next tracker].=C2=
=A0
                    I think the only

                    way to

                    "deprecate a module" is to instead deprecate =
the all
                    the

                    nodes/rpcs/notifications in the module.=C2=A0 Kind of
                    ugly, but it's for a

                    deprecated module, so who care, right?=C2=A0 ;)

                  

                  I think it is unnecessary. If somebody needs adding
                  such a module to the

                  data

                  model, he/she should probably have a reason to do so,
                  such as data

                  implemented

                  on the server.

                  

                  Lada

                  

                  

                    Kent

                    

                    

                    --

                    

                    Hi Rob,

                    

                    On 9/14/2017 9:37 AM, Robert Wilton wrote:

                    

                      Hi Kent & Lou,

                      

                      When do you think that it will be possible to
                      start the adoption

                    

                    process

                    

                      on these drafts?

                      

                      I think that the first two at least would seem to
                      be ready for

                      adoption.=C2=A0 For the 3rd draft, there still seems =
to
                      be an open

                    

                    question

                    

                      of what to do with the old state tree, but
                      presumably that could be

                      solved after the draft has been adopted?

                    

                    I see an update for the third was published
                    yesterday

                    (https://tools.ietf.o=
rg/html/draft-acee-netmod-rfc8022bis-02)=C2=A0
                    that

                    clarifies the intent is to replace the current
                    modules, and presumably

                    obsolete 8022.=C2=A0 And now that this intended directi=
on
                    is clear in the

                    draft we could poll it.

                    

                    I think this still doesn't address if we need to
                    indicate that the

                    rfc8022 defined modules are deprecated by some other
                    mechanisms than

                    just replacing the RFC, e.g., by updating the old
                    modules with all nodes

                    marked as deprecated.=C2=A0 I think you're right th=
at
                    this could be done post

                    adoption.=C2=A0 Of course others are free to disagree.<=
br>
                    

                    I check with Kent and see what he thinks.

                    

                    Thanks,

                    Lou

                    

                    

                      Thanks,

                      Rob

                      

                      

                      On 30/08/2017 00:46, Kent Watsen wrote:

                      

                        Hey folks,

                        

                        As discussed at the last meeting, we are heading
                        to revising

                      

                    

                    existing RFCs

                    

                      

                        to align them with NMDA.=C2=A0 The first batch have
                        been published as

                        individual drafts:

                        

                        1. https://t=
ools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00

                        2. https://t=
ools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00

                        3. https://tools.=
ietf.org/html/draft-acee-netmod-rfc8022bis-00

                        

                        Please take a look (comments welcome!) and stay
                        tuned for the

                      

                    

                    related

                    

                      

                        adoption calls.

                        

                        Thanks,

                        Kent (and Lou)

                        

                        

                        ______________________________________________=
_

                        netmod mailing list

                        netmod@ietf.org

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

                        .

                        

                      

                    

                    

                    

                    _______________________________________________
                    netmod mailing list

                    ne=
tmod@ietf.org

                    https://www.ietf.org/mailman/li=
stinfo/netmod

                  

                  -- 

                  Ladislav Lhotka

                  Head, CZ.NIC Labs

                  PGP Key ID: 0xB8F92B08A9F76C67

                  

                  _______________________________________________

                  netmod mailing list

                  netm=
od@ietf.org

                  https://www.ietf.org/mailman/list=
info/netmod

                

                _______________________________________________

                netmod mailing list

                netmod=
@ietf.org

                https://www.ietf.org/mailman/listin=
fo/netmod

              

              

              _______________________________________________

              netmod mailing list

              netmod@i=
etf.org

              https://www.ietf.org/mailman/listinf=
o/netmod

            

          

          

        

      

    

    

  






--001a113c1796c82ef305593ceab7--


From nobody Fri Sep 15 09:44:07 2017
Return-Path: 
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 A26DD132D89 for ; Fri, 15 Sep 2017 09:44:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level: 
X-Spam-Status: No, score=-2.02 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 HgesVWa3Hs-y for ; Fri, 15 Sep 2017 09:44:04 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0094.outbound.protection.outlook.com [104.47.41.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90AE413209C for ; Fri, 15 Sep 2017 09:44:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bTuDrgouDbk5VnPI8y3+ip7JNm5RsAnZ4pH5/iHJXJU=; b=gEAeqDv782OSzBIzzGzI80N7zy9Wrg/SOMykTW7ZSBWfSchVXG4zu5kY8P0W5PbWnSM/B3REJUlnnvMruBNjPHb4+Ygw624TxTGngJrrMBSQKvAPjLydk0b22wlc9PvHYMSQr0nN2U8XhQzh+GyMB6JeAJPJLvBcuVYiFVPhmx8=
Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB258.namprd05.prod.outlook.com (10.141.22.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Fri, 15 Sep 2017 16:44:03 +0000
Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0035.010; Fri, 15 Sep 2017 16:44:03 +0000
From: Kent Watsen 
To: Andy Bierman , Robert Wilton 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] upcoming adoptions
Thread-Index: AQHTISEQvmg9jr+3gUCv+5ltP9XhHqK0ewcAgAADXwD//857AIABjmaAgABHC4CAAAKTAIAABg0AgAAK4ICAAAfsAP//wJ0A
Date: Fri, 15 Sep 2017 16:44:02 +0000
Message-ID: <112D5C5E-F2F2-481B-A1B4-7156DC3477C5@juniper.net>
References: <14299503-509D-43BE-A938-0B7B88C3B249@juniper.net> <36ba3d4b-1ae1-0666-12cf-db41e172924b@cisco.com> <75739d75-da96-b340-2403-d0949ac54ed7@labn.net> <19134054-D52E-4A6D-992A-A47F365557AD@juniper.net> <1505471909.18681.7.camel@nic.cz>  <8326bb01-63a6-9746-098b-d693b12a2396@cisco.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB258; 6:CVrbKe8PMpWhMRXf4LNsoBTeyBlrPRC39s6WbW0vnoV8m1wpNZWrI0vfRa6W4YgR1b2urS+uALbpls5Mmnd4LFTqu1ept/JOjiJdszuy7w3ntXT7hX9FbIjwkgkiOAi77fy3rw6JqbzSJmqPCN5MLqvCs0Jd6OibiUoyZPRbMTezxWQ48j1WwnYfSeZzOYGI5kJHg18x0/uUjOhDML6iYcwxXYNq50MlZndtCkGYdaXzcqoaQWc1UaaLJ9V7VYIxkZMHclQrRq+KCdATHtfJSLGs3eWArIkqZjd0W+VoAGlR4x4vuSQfGtVoqoHcBkfE+CVVA5ZvEEQWdwKFoyA/hA==; 5:JX+XipEpWfwMUfrKaLpOaMWcrjNrGLIBcwV4H5JoxE9226Qs48+5ZgYznuxEmu7KfJYgBET8nGU76WSSZlfgras9/HBlHuFOPkevlNeb/njEgxw4B6YY1VAzc4Y4WczihSA33Y4TP68cTC8ooM+aHw==; 24:ifBQQIF9m7BFCFhBqFt0jWxlmB2NFryZvMudkcAnsk+9OqIOqT5btyh+40mNx5itb0RqpRqgwHis09IpP9IflJW5EOIMpXqY9Uh+SPpALhk=; 7:JaSBtVBTjTFcD9J983CysGDvGV4M3yBEICbG1Bq9lsYPPB50WDME8hVtoQJ4mbm3Gkthder5eyrr2PTfyhqCLRYVs1uko1aFxMR3s1XQKE6T9FAvC+fkgvT3OvCw4xhNn2YOh9TRG8LSUQezY+YG/eAcK4/S2sISFAqfTKFHbtaIVe5I6G2KUFyNvLaSYBRSKqt3F9SNKc28p47CsTHPYuJ/eZ6b+7nmGQikg4fNgRo=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 59395e1b-4c82-4300-5e81-08d4fc58f8fa
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR05MB258; 
x-ms-traffictypediagnostic: BLUPR05MB258:
x-exchange-antispam-report-test: UriScan:(21748063052155);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB258; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB258; 
x-forefront-prvs: 0431F981D8
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(189002)(199003)(97736004)(81166006)(8936002)(50986999)(82746002)(53936002)(58126008)(3660700001)(68736007)(33656002)(3280700002)(81156014)(8676002)(478600001)(7736002)(2906002)(189998001)(99286003)(105586002)(3846002)(102836003)(5660300001)(25786009)(76176999)(54356999)(66066001)(106356001)(36756003)(2950100002)(101416001)(14454004)(86362001)(54896002)(6306002)(2900100001)(6116002)(229853002)(83506001)(6512007)(4326008)(6436002)(6246003)(6506006)(6486002)(93886005)(83716003)(77096006)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB258; H:BLUPR05MB275.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_112D5C5EF2F2481BA1B47156DC3477C5junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Sep 2017 16:44:02.9311 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB258
Archived-At: 
Subject: Re: [netmod] upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 16:44:07 -0000

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

PiBBIG5ldyBtb2R1bGUgbmFtZSBtYW5kYXRlcyBhIG5ldyBuYW1lc3BhY2UsIHNvIHRoZXkgZ28g
dG9nZXRoZXIuDQo+IEFiYW5kb25pbmcgdGhlIG9sZCBtb2R1bGUgaXMgZmluZSwgZXhjZXB0IGxl
YXZpbmcgdGhhdCBtb2R1bGUgd2l0aA0KPiBzdGF0dXMgImN1cnJlbnQiIGlzIG5vdCBmaW5lLiAg
SU1PIHlvdSBuZWVkIHRvIHJlcHVibGlzaCB0aGUgb2xkIG1vZHVsZQ0KPiBhcyB3ZWxsLCB3aXRo
IGV2ZXJ5dGhpbmcgc3RhdHVzIG9ic29sZXRlLg0KDQpBZ3JlZWQuDQoNCklmIGEgbmV3IG1vZHVs
ZS1uYW1lIGlzIHVzZWQgKGUuZy4sIHJvdXRpbmctY2ZnLTIpLCB0aGVuIHRoZSBvbGQgbW9kdWxl
DQpuYW1lIHNob3VsZCBiZSByZXB1Ymxpc2hlZCBhbHNvLCBqdXN0IHRvIGRlcHJlY2F0ZSAob2Jz
b2xldGU/KSB0aGUgb2xkDQptb2R1bGUuICAgVGhlIGRlcHJlY2F0ZWQgbW9kdWxlIGNvdWxkIGJl
IHB1Ymxpc2hlZCBpbiB0aGlzIGRyYWZ0IG9yDQphbm90aGVyIGRyYWZ0IChrZWVwIHJmYzgwMjJi
aXMgY2xlYW4/KQ0KDQpBcyBjby1jaGFpciwgSSdtIG9rYXkgd2l0aCBhZG9wdGlvbiBzdGFydGlu
ZyBldmVuIHdpdGhvdXQgdGhpcyBkZXRhaWwNCmZpbmFsaXplZCB1cCBmcm9udC4NCg0KSy4NCg0K

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

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0
ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K
CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo
dDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0K
CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0Kc3Bh
bi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m
YW1pbHk6Q2FsaWJyaTsNCglmb250LXZhcmlhbnQ6bm9ybWFsICFpbXBvcnRhbnQ7DQoJY29sb3I6
d2luZG93dGV4dDsNCgl0ZXh0LXRyYW5zZm9ybTpub25lOw0KCXRleHQtZGVjb3JhdGlvbjpub25l
IG5vbmU7DQoJdmVydGljYWwtYWxpZ246YmFzZWxpbmU7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0
eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0
aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls
ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp
b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp
bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+
DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi
IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZndDsgQSBuZXcgbW9kdWxlIG5hbWUgbWFuZGF0ZXMgYSBuZXcgbmFtZXNwYWNl
LCBzbyB0aGV5IGdvIHRvZ2V0aGVyLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZndDsgQWJhbmRvbmluZyB0aGUgb2xkIG1vZHVsZSBpcyBmaW5lLCBleGNlcHQg
bGVhdmluZyB0aGF0IG1vZHVsZSB3aXRoDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPiZndDsgc3RhdHVzICZxdW90O2N1cnJlbnQmcXVvdDsgaXMgbm90IGZpbmUuICZuYnNw
O0lNTyB5b3UgbmVlZCB0byByZXB1Ymxpc2ggdGhlIG9sZCBtb2R1bGU8bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgYXMgd2VsbCwgd2l0aCBldmVyeXRoaW5nIHN0YXR1
cyBvYnNvbGV0ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWdyZWVk
LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBhIG5ldyBtb2R1bGUtbmFtZSBpcyB1c2VkIChl
LmcuLCByb3V0aW5nLWNmZy0yKSwgdGhlbiB0aGUgb2xkIG1vZHVsZQ0KPG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5uYW1lIHNob3VsZCBiZSByZXB1Ymxpc2hlZCBhbHNvLCBq
dXN0IHRvIGRlcHJlY2F0ZSAob2Jzb2xldGU/KSB0aGUgb2xkDQo8bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPm1vZHVsZS4mbmJzcDsmbmJzcDsgVGhlIGRlcHJlY2F0ZWQgbW9k
dWxlIGNvdWxkIGJlIHB1Ymxpc2hlZCBpbiB0aGlzIGRyYWZ0IG9yDQo8bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFub3RoZXIgZHJhZnQgKGtlZXAgcmZjODAyMmJpcyBjbGVh
bj8pPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIGNvLWNoYWlyLCBJJ20gb2theSB3aXRoIGFk
b3B0aW9uIHN0YXJ0aW5nIGV2ZW4gd2l0aG91dCB0aGlzIGRldGFpbA0KPG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5maW5hbGl6ZWQgdXAgZnJvbnQuPG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPksuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8
L2h0bWw+DQo=

--_000_112D5C5EF2F2481BA1B47156DC3477C5junipernet_--


From nobody Fri Sep 15 09:58:14 2017
Return-Path: 
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 1029A132FA7 for ; Fri, 15 Sep 2017 09:58:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.91
X-Spam-Level: 
X-Spam-Status: No, score=-2.91 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 bflD7N_Y_hvs for ; Fri, 15 Sep 2017 09:58:12 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0103.outbound.protection.outlook.com [104.47.2.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5848B132D89 for ; Fri, 15 Sep 2017 09:58:12 -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=dVlFk7zBwqb78P+vjt7+pZzA8ax7+AifW9lf8E8nPXI=; b=K9P/GOd4Rd7UNMt6kpajDhgMd24exVYBi874WlwxM7kuHdO/15uXUr10tJGEZfiGJ/mdaGk91eUJQyJpCmoy3kGJNoUwsB3AXJJeqlngZWw2elM61Ghddb0I7fD++0c2yniofSfz05e/xum4o788ik/ikKBEY2l2dRmDdYXyIec=
Received: from pc6 (86.185.245.5) by VI1PR0701MB3007.eurprd07.prod.outlook.com (2603:10a6:800:87::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Fri, 15 Sep 2017 16:58:09 +0000
Message-ID: <018a01d32e43$982f4e80$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Benoit Claise" , "Martin Bjorklund" ,  , , "Joe Clarke" 
References: <9d84d068-29ba-8e89-394f-b7f6a5272adc@cisco.com>  <20170914.195037.593298963545596882.mbj@tail-f.com> <5721c564-48e9-299e-5ada-b272b00716cf@cisco.com> <748ca881-2180-3096-750d-44d28aa1b7ce@cisco.com> <20170915132128.diib4wxp2vg6yqi4@elstar.local> <694e1d93-5cf8-2aca-a1a8-8df0e1d0aa15@cisco.com>
Date: Fri, 15 Sep 2017 17:51:09 +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: [86.185.245.5]
X-ClientProxiedBy: DB6P190CA0004.EURP190.PROD.OUTLOOK.COM (2603:10a6:6:2f::17) To VI1PR0701MB3007.eurprd07.prod.outlook.com (2603:10a6:800:87::21)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 37a6c253-0d56-4b0d-3456-08d4fc5af1fb
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:VI1PR0701MB3007; 
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 3:etGhe9tQSKbQdSevesWYJoSti1bDigdKiQZE0wqOHcvphmslercTg+6+rhRFcqf2VsUkGTmmUh17v+Yxb9Iqa2U1i5W5tt0rwJGOcLzG1uaqeY7k57iCZIDII9dPH50qCg4xPw5qVeF8rPBc+ijVTEyKqmAX7yBYG6DgYVcBzu2hpz+CgDsmhNaYMYlZHkWCpeLlbK5O3+nZ4oxpkdZyWEgrVr/DmNVgMdtSpAcrDcBuri1i/8nyNt/+9yR/VXII; 25:BOJFhAzhK0YcLBlqsddRze69lIN49ROrHZ8TOQjFO58BrCzG8gBFt8pxNBO+EWT8mgI9dqRZdN98Vw8xKTssW9pFYF47frmxm1qND+6kEQFHpKGtunP2dBpxzCM51EciXi6KcE97SV/h+Louq2qYum0CZPikyauZuz8eWz73jnEwRtwMgrREfMgvEAMQwlwnTZ9MEsFyNBZrwGgzafy+A73l+WECzxt+AG4pjcilABdzXF6L//HNBfZFlOfZcULT0ZzYDyhOiMBuesvbMA+/A4XMzi4drpKJMIV7TzMlvzIC0R2y3nJY3qNFrzeM69AGDHEvxnWg4rpRAXTWr4GH8g==; 31:0vJYf8jlhbIhX5ixvCoFk+2kOUetIw1VIS+VWTX/KUsuHv8EYfsrO4llISKp1yIEAvppmVMYcURAnmFVBit6auqEFW2ASX26kpaGJHsdmOTBYpJw9YDYZ/KT0j8yRBmKyIypRDli6UmYzMjH240tScK+rBx1k7oyeM2kTILa2qGiBNKU3I99f7Dw6deoReoFWp9Zs7pNpQaJNd8KIXtJx2YYiH8crZg5FovlRfErDtg=
X-MS-TrafficTypeDiagnostic: VI1PR0701MB3007:
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 20:dsKN5LZoZWk5KfcXAY3xBpLbXzAAzihAGV0Xd0qQxaLLI+q0XC/EawhhBm/jj8Rf4weJDQE1Fpb7FTSkzh0nVAaAhPRJqsiRwXUqsaXTsImvRNu8yZQkinm2UQT6E6p97OkZ0mYB/9nBZ6OqqOSjYESfFQ1pzIRJLwzIyYfBIWmf7eZSusjO7PG3H0f4mkw73iFhN0LpWwRLxxIAhNPtq0u4/p9SBH8tShIP6rg1hbVBx5AQYlKooHpWge2/BOlN; 4:KK8FRy9Ds+4/2Bf76A7QuNtC11a5tr9JzBe+7vbR5pVIbqoPXC7RpPYz+ktvzgqCTbxV4PLfBGQimI0H2p3OonijQ5e+HqiC5teE4/KWH/g4wRzBNHdGtIQrj4PyrW6/tMILi4lWgus/krSEbxqgNUTfbeIYDxJdXr5qsBycuQjaLdAWW8gBwslZSxvrbvgriJilvY/2kRSBC7MuiL4gN6e3Txo1eRXKnsHPf0VM303rS+gUzA6djlNwv+gSnPPizkj3W4Kg6XuTdfgRu+q55e/XYoX5S4RNhh9zCRfABV8=
X-Exchange-Antispam-Report-Test: UriScan:(95692535739014);
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6041248)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR0701MB3007; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR0701MB3007; 
X-Forefront-PRVS: 0431F981D8
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(7370300001)(4630300001)(6009001)(39860400002)(346002)(376002)(13464003)(199003)(24454002)(377454003)(189002)(50466002)(4720700003)(62236002)(44716002)(76176999)(50986999)(106356001)(81686999)(81816999)(105586002)(23756003)(68736007)(66066001)(9686003)(229853002)(478600001)(53936002)(61296003)(101416001)(47776003)(6306002)(3846002)(6116002)(6496005)(6246003)(230700001)(44736005)(6486002)(93886005)(7736002)(5660300001)(1456003)(50226002)(33646002)(1556002)(8676002)(81166006)(305945005)(116806002)(189998001)(81156014)(316002)(97736004)(86362001)(53546010)(2906002)(84392002)(966005)(25786009)(2201001)(7350300001)(14496001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB3007; 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; VI1PR0701MB3007; 23:Ird7cKUSQnu5IyQ2BCOANxkOAz19jeQ2qKdgd?= =?iso-8859-1?Q?fyIchWWiOxFUD8MapiGQ0zZF3cm17j6OYHdnkdfBdmVqJlQBu3EbIl5M4I?= =?iso-8859-1?Q?x8TriWFSrQBwyeSLdcny0wqWQDJpo8N2vGfWyhuXjSUOxfGxVI8y90Vy4I?= =?iso-8859-1?Q?7PPB3Dy7+Eba3uAl53rOEkJI70cKPwDI0meaKBUlZSgPhc8umzPx4UK/rd?= =?iso-8859-1?Q?3F17p1hIh1BO6TscBqsYPQkL9wmXYmX3SclnP5nZoI3E8AEBMHIpKEsbiv?= =?iso-8859-1?Q?f5T3Nbrlk3+dYLjs1KmKiSaZUepwttMvb3meG4CQsIuDCWSXZ3NBnkohxZ?= =?iso-8859-1?Q?0eiOErDpQaAZ1M9zGu92FIxT48K9j4L/C8bp8eg1KBZEglHuYEQTmkmcAv?= =?iso-8859-1?Q?j8rsyloh0dOIc3Gcw/0MvfdKOUgk1rJBrWS77mWwTKZGYHE6xqg+T0zRsZ?= =?iso-8859-1?Q?L6bf7IS5CB1UCYfXWTkqkvLYvg/dAvuTHUDsLhabixDZB7//eJwEibu+KU?= =?iso-8859-1?Q?VAfT7ms63YmWGO3UNSLNQgZoGdTnnI2lTw5y+6xBb9kZ+16Fxx8s+NmFbL?= =?iso-8859-1?Q?lrIcMDd9NMXgHN6T2vmaf9wEB88FK1XuHOX8CN676t9rVK75W+/+kM8m2S?= =?iso-8859-1?Q?0105VhS0TRkHtszVwNjiY1Rtp4Jq4N2Vx2RzgBZ83b3h8fH1hbGNjmMRqC?= =?iso-8859-1?Q?AFyjRjBeBLa/Yv576W3MjYeTF5D95VaYu/8DaOJb8g8KUyWD8Ilqf8/cUn?= =?iso-8859-1?Q?3hsQrfAWTz1W/CU/K082VEyY4+7LhiqgJiXOQ/xhv//z7V+eVhkHAv0Ke/?= =?iso-8859-1?Q?bli9CpWQJEcz8174QxMf9E5JMGw+uaCisPiumwF6x6j5yd/IooJ+i0BsYp?= =?iso-8859-1?Q?51mTyjy3ANhmQQk8Kdj4fEFpHIZQ2s/IGWaZvADWFjvaf46NHRYbBxO5Tl?= =?iso-8859-1?Q?uN/V4cK2d2yryEszCHVlDVTuViX6uXQk74ziODWzy85mpGVqpTFMtZELR/?= =?iso-8859-1?Q?OIldr/icTMr0/EQiEA2Y6gzXFsN+II6V5TcZxz8toUFjn2XCgInY59ng5x?= =?iso-8859-1?Q?K9+FAl/1Z/OtQTKH5v3aGtoWmLHp7bx5vf+Pbmmlv9OI9xQiP7w+OrNDp5?= =?iso-8859-1?Q?0FoYDwSm3KD+Ws0D3ipUyc/2QltZ4CarOzgxPHcG3Rnc0KtaeuTqkYnUJZ?= =?iso-8859-1?Q?zt1J1hFAD+cLdlGML3zDJS0BvaKWcRr8p8ExIjj9dqzgLHfmaL7g4QnQhv?= =?iso-8859-1?Q?hMc4MZsiptDa9I6NSaaY307X+MyLpoQqM53ZkUNVOJIeRHuNsw+P0bpdRd?= =?iso-8859-1?Q?H4M5DPgiFe6kHiw7mo/aDl3mSDuK3cFZII2z+whz/8hUu6Fm7p9/mz5Gy3?= =?iso-8859-1?Q?vGr38PQ/EII9P5TVBLCEFpSYXi0L3xF5q9/tVOCbFV4pAinyBAJ0LWiJgU?= =?iso-8859-1?Q?hpmEpkHdLy/txfjmaRqRQHMkw4yMCBpf+x+UKlra40DBwHNLBwOdDhs8TV?= =?iso-8859-1?Q?RNa/m+QcN96A9GYFT0ybEHcpWwlcIv6s7XTPcIqRim230cu7lfRwzhmY80?= =?iso-8859-1?Q?bXvu8EkOScmagUphXBiEZg0ZZh3Q=3D?=
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 6:jp5RTuRctNXaaoVXfnSxfaZpjzX2tL7SMT1tDI8+t/FChLOcCYcGbla29m1CCIjsQpeCLML5R2ajjB6Iywhhxt+wcYI3DTTdGOssuUjQLPnp++shic/6bMOxhm/0akU4FytwUDYXbb7M+h8VIXQBepfhJkVNYdOjhkLU7TOn6A9F/Dv+FKtFtpegf9sw5j8PdbsMQrToImuwSUMmGbRddSni4nq+9ynNeRDocVmRZQBDvK346C4VECyAB3dYvHtn9zUhRcVk2ewkVdV6exK+/EVV8qpu6YhDf5yUvDmHrHI/uIDiNE1Q5ifWikF5n0rxxK5j3gBfqTIqT3czW4lnSg==; 5:XgpJTUDliPX1WnPSAamMbbMXA7D4c9sDguA4B9aGRph/3uYbxPuSIxfQZJyvpiIvEHnINWQkOmzkR0o9E3zhVl6H6Soue0CVvnTY1IHQ1bKzC5ziNAnxWoygoto1v0gHHVFdM7ZSqztGFEuUdXcq/Q==; 24:oVYfm8gIZJEhMnkTqE7E76Wfv4Kl3WVAn8pt/L7UY5HUuekwI3YQqINCiYe5hQYiJdmPYkgcyv8z4IyjAQoAo58MesXq/7yt0NI7Mzp0w/8=; 7:qBg2CnRQQdb5M0xlllpZAgKU7O6V23mKs63qiIxZTC2zqNLSX65pkTrqgW5FMif6vCJBtmVO7sTEO8PtysbZqzVygP2i+W8T8CW9l67wIIcRYanYeKsTOtB3XtaRM1BQDQLVge/SxyZeLoqOc75/l1XeNzzrdu08Xy37MpBWcf1C2MRtPR5CcgexS5mpcsohFDXuJJTahZctWswTQvD5hpfswgkgniS7Ss99MoLUbf4=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Sep 2017 16:58:09.7016 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB3007
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 16:58:14 -0000

----- Original Message -----
From: "Joe Clarke" 
Sent: Friday, September 15, 2017 2:50 PM

> On 9/15/17 09:21, Juergen Schoenwaelder wrote:
> > On Fri, Sep 15, 2017 at 02:54:31PM +0200, Benoit Claise wrote:
> >
> >> Now, if you are already a YANG expert, I guess you don't use the
> >> tree output much.
> >
> > I think this has nothing to do with YANG experience. The intention
of
> > the tree format was to provide a concise overview of the structure
of
> > the schema tree. If we start to include type specifics that can get
> > very detailed, the diagrams loose their value.
>
> I agree that clutter is bad.  I had the same reservation, but I am
also
> working with models and sharing information with people where a tree
> that has a _bit_ more information would be useful.
>
> I agree that showing this by default will be messy in some cases.  And
> maybe this has moved to a question more for you, Martin, in pyang's
> GitHub channel.  But if this output were put behind an option, would
you
> entertain a PR?

Joe

Less is more.

I agree with Andy, Martin and Lada that it has got too cluttered.

And as for line length, I cannot recall when last I read an I-D that did
not break the rules for RFC.

Tom Petch





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


From nobody Fri Sep 15 10:10:05 2017
Return-Path: 
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 46D79133039; Fri, 15 Sep 2017 10:10:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMSScxzp3hwq; Fri, 15 Sep 2017 10:10:01 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7643D133050; Fri, 15 Sep 2017 10:10:01 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 4CAAECD7; Fri, 15 Sep 2017 19:10:00 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id dluTYPsYPrOu; Fri, 15 Sep 2017 19:09:57 +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 atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 15 Sep 2017 19:10:00 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2A1A5200E9; Fri, 15 Sep 2017 19:10: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 CoxMrPlk_iwC; Fri, 15 Sep 2017 19:09: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 7A75C200E8; Fri, 15 Sep 2017 19:09:59 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 603F040F69EF; Fri, 15 Sep 2017 19:09:59 +0200 (CEST)
Date: Fri, 15 Sep 2017 19:09:59 +0200
From: Juergen Schoenwaelder 
To: "t.petch" 
Cc: Lou Berger , netmod WG , netmod-chairs@ietf.org, draft-ietf-netmod-revised-datastores@ietf.org
Message-ID: <20170915170959.q5bfwoqoaqaq4o5b@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: "t.petch" , Lou Berger , netmod WG , netmod-chairs@ietf.org, draft-ietf-netmod-revised-datastores@ietf.org
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <000901d32e3e$883fa9c0$4001a8c0@gateway.2wire.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <000901d32e3e$883fa9c0$4001a8c0@gateway.2wire.net>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 inactive
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 17:10:04 -0000

Two comments:

- Obviously, inactive can be in  and I would not rule out
  that inactive configuration can be in any other or future
  configuration datastores.

- Whether protocols support inactive or not does not belong into a
  definition of what inactive configuration is. The same for backwards
  compatibility considerations etc.

So if we define inactive configuration, the definition should be
something like this:

* inactive configuration: Configuration held in a configuration
  datastore that is marked to be inactive. Inactive configuration is
  ignored during validation and never applied and actively used by
  a device.

Yes, we should use 'inactive configuration' everywhere to be consistent.

/js

On Fri, Sep 15, 2017 at 05:20:15PM +0100, t.petch wrote:
> Inactive appears a dozen times but is not defined, except in the course
> of those appearances it effectively is, but is sometimes 'inactive',
> sometimes 'inactive configuration', sometimes 'inactive data'.
> 
> I would find it clearer if the term was used consistently and if there
> was an explicit definition amongst the other definitions in section 2
> such as
> 
> inactve configuration: Configuration that is present in  which
> is not in use by the device and which plays no part in validation.  It
> cannot appear in any other datastore.  The protocols that are currently
> standardised do not support inactive configuration but a number of
> proprietary protocols do. Inactive configuration is only exposed to
> clients that indicate support for inactive configuration; clients not
> indicating support for  inactive configuration receive the contents of
>  with the inactive configuration removed.
> 
> This would put a stake in the ground for as and when the concept is
> standardised and may reduce the proliferation of the term with multiple
> meanings.
> 
> Tom Petch
> 
> 
> ----- Original Message -----
> From: "Lou Berger" 
> Sent: Friday, September 01, 2017 10:02 PM
> 
> > This starts a two week working group last call on
> > draft-ietf-netmod-revised-datastores-04.
> >
> > The working group last call ends on September 17.
> > Please send your comments to the netmod mailing list.
> >
> > Positive comments, e.g., "I've reviewed this document and
> > believe it is ready for publication", are welcome!
> > This is useful and important, even from authors.
> >
> > Thank you,
> > Netmod Chairs
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 

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


From nobody Fri Sep 15 12:41:11 2017
Return-Path: 
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 1157E1331F5; Fri, 15 Sep 2017 12:41:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 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_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 s69HTCmGBsTj; Fri, 15 Sep 2017 12:41:08 -0700 (PDT)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0137.outbound.protection.outlook.com [104.47.37.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A212E13292F; Fri, 15 Sep 2017 12:41:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yQR+ynLdTSwK7gyp3diDfHNvZlopEp3CeMlXa+Hd5aI=; b=FJBBMP+tAAjxYYOwvsc2q8zXw7wJcP76VQX0ixtxqos/JXhOHlXqMJHSP6/8IxnMJsJSfOcXEC2omS3lAYNYqHPceFW8Zeuc+JOSAdZdXHo4PmGaymPa3bGQMThePVK9YeHDyn4lyRCdRe98yH3jsly3326Qv8daYBA8e78zMlY=
Received: from BY1PR0501CA0020.namprd05.prod.outlook.com (10.162.139.30) by BN6PR05MB3602.namprd05.prod.outlook.com (10.174.235.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Fri, 15 Sep 2017 19:41:06 +0000
Received: from DM3NAM05FT056.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::208) by BY1PR0501CA0020.outlook.office365.com (2a01:111:e400:4821::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.77.5 via Frontend Transport; Fri, 15 Sep 2017 19:41:06 +0000
Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=juniper.net;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender)
Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by DM3NAM05FT056.mail.protection.outlook.com (10.152.98.170) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.20.56.11 via Frontend Transport; Fri, 15 Sep 2017 19:41:05 +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; Fri, 15 Sep 2017 12:40:55 -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 v8FJeqNe030770; Fri, 15 Sep 2017 12:40:53 -0700	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.15.2/8.15.2) with ESMTP id v8FJeoib092135; Fri, 15 Sep 2017 15:40:51 -0400 (EDT)	(envelope-from phil@juniper.net)
Message-ID: <201709151940.v8FJeoib092135@idle.juniper.net>
From: Phil Shafer 
To: t.petch , , , , 
CC: Lou Berger , netmod WG , , 
In-Reply-To: <000901d32e3e$883fa9c0$4001a8c0@gateway.2wire.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <92133.1505504449.1@idle.juniper.net>
Date: Fri, 15 Sep 2017 15:40:49 -0400
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(346002)(39860400002)(376002)(2980300002)(199003)(189002)(54906002)(1076002)(47776003)(8936002)(2906002)(316002)(50466002)(23726003)(16586007)(189998001)(8666007)(81156014)(305945005)(81166006)(46406003)(8276002)(68736007)(7126002)(97736004)(8676002)(356003)(2810700001)(5660300001)(2201001)(4326008)(229853002)(86362001)(7696004)(77096006)(106466001)(97756001)(54356999)(50986999)(6246003)(76506005)(53416004)(53936002)(105596002)(69596002)(230783001)(2950100002)(1941001)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR05MB3602; H:p-emfe01a-sac.jnpr.net; FPR:;  SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT056; 1:6LsKs75uGI8l83khI9cKuB1kr77yaUNv+rZoQQLM6Mcy4AIfxOnK2a/JWd8//Z8UYwPLyMFlx1FxHNUQ0Z5aIjnj06MfKwJhJgzhDmHdbmGe/+s1ee4icI/gY3LfYNZ7
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 73e8fcc5-c438-4558-253d-08d4fc71b4d5
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN6PR05MB3602; 
X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3602; 3:rp6D0Ug2IIi12EhOhfPmPW2RuCOeOxyVPDtkiNacNhEn6tyU3wAtVZpx10mY7jfE18s4Q1aIse97CqSN8TcFzS4HXDT0RjSZH5cCvfDaZZtzcse0mDeAFwNefvScRkO90tyaBhOQ5GkETZDE5UE20yJCNxaKEQfKK9mngeq1Dev9Epa5Fbm0xPACOaooJYGhKYsRY/9URM6cYdYHJHrQzLTFih1G1f3nmF0USz6nwvxsCHkvkYO1D/kTDUNMDWCHxZhVOTiptwCQOpODzEYvQivBNS/p/a5Rv1WbTcXNPW1EzCfHebsyFFBwqMa1D/VaWxU0ib7onHY7N5x38PMfiieTy6fCStyuCQA2a8OiJKY=; 25:JzML80jW5xcGmUWpQptGVHoZ841qecrzfT+J2V88fECczCDsRjbLjlDSbSlEe+gbPGmodyFVBUIyUxdebfiEy+XvhepGju+X+layBt2yHnTHCmJWAtZmm4+I53P82CkydBZ2u0a0X+AKa9cA6Ob7Zy6gAVjouU3P/JCWOBI1ffistKY281EIjGZYwuBdy+F1ESsyUkNCLh58xAQc3CphwFU09mLmqqXGOLMJz1Zz6ovhVaurS/iwOjFnwbYKPZou8ie/FSMidyQ32xSDvo2zrnauKc0NRys12hRNaqztQA4PuT5dgCg2Ge+b5l+DpYcLzMU2qYq0xcOcn9WluMkDNw==
X-MS-TrafficTypeDiagnostic: BN6PR05MB3602:
X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3602; 31:kpD0ED8M8+cuJAwdih8OiuzSI+BWtnY46vBkIDUz8M+NxLwGI1jnNOcZuEbKaVbYyqbDOsttqyfzw+u9Czezh2PlHByOE+fYat2E1VK9LEFsWV6FHHre0cMMDq7lYSz9S2IpHzjAbeE48l41D1vs7TtEtLku6T1oWyW6DOtPBj4V3EF844ciV//HX5t9sJzpK7B8lGZnnPgUxibU6vB1q/SuZ5bVzx3Y5XuU3mHW3gc=; 20:5PlyNZ2hIGfIK+NuesX7wC6YT9qkZdxLJJnjY4KEsCXgeY0Q6x43zsq+lx6BG5z/ZLcCYXXkxr/z90oDDE3esMjQKBPhTxLPLohICXUt6PKkT/nDGvX1MsIInY7HyLtXfLGUr1CeMLaN7lA/edmhiRbinVZQd4SBJgrlokp8edFRSx+aY03cOURTKRoXpm4CpVWjNJc80mpIwOvDnKV1OG30BHtdrO1S2RJxKGoTxg+O+IBJwzKfDxZVT5m59rpI1nIfRMHi+GB1Xp5yYdsiUXGLuZVjvHW6u4vsSPJbMRNCQdI/s834WTP6iRJOJpLJ60XdLWB1wNzyfe0G9GRylz/Y2BIskwV4MWvKbGK/pXpldce3mKyP00oEKz+Q7j4C22MDUmS9uNJc0s+zZQdlZD24iavJd1kR8JU9r1tAYzg74kLQRN0/Pfgovxh/iNHNceWYWkKej10NBguCgwixBOUrkRfiz2op0db1dd1k2k5mWP5qKi89ALhVtqqIEOYN
X-Exchange-Antispam-Report-Test: UriScan:;
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93003095)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR05MB3602; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR05MB3602; 
X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3602; 4:R5tWQoJaDl5XXkFd4OHBcyIQw8RIluhzbJMkVlC2Bx9kdAFGxnIoH6091EcnY4KhaidiHKchx9F+Sf1gAtcrdhDlu8zqYi2k3VRUdmncyTve0s5TtaLS0Elwgg41FNPfnhee/bhu60KXYF3xLv0PkLucag3U42WomYmDD36lEIakmKZeayaD6a11yiMCh5YBWBzwqFdyneCUFJC/biULy6fk1D10D2+wIOTj3+BuzvixoZOkfREoNpq+Fa4tXVeW
X-Forefront-PRVS: 0431F981D8
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN6PR05MB3602; 23:cmwDegjuzgyV+/7x7SzKJqGBeMxN9adXxpg3QZrtc?= =?us-ascii?Q?OF7HGZjzOUQ7NiyC5XDIN4VjnJTBBExP42GFZV3NLeVmNxAsJ4OvsU2MpU2F?= =?us-ascii?Q?ialYNiBh8cngulaSOrMSD2trN2OKn1TcpLJ9fBoTKii9ka82oQUW1810qzz9?= =?us-ascii?Q?B73YBzWC0fMCUZBJOmGUDByttdILLfPx51Xf0BrZoO/OLP6EdGbSs/et9z2J?= =?us-ascii?Q?APYa5aFRN2SxGATGMe79SxDFIR1K+59b47TIfCcdOkzQuUWnuOe6ijtOdE/R?= =?us-ascii?Q?PoHUMTabZ/Ws79yXfOrFfOE9ILHh080fJE8nRtshabMjr/2MfvXDg1GpW3wA?= =?us-ascii?Q?rJOziA4c+83qCNfMThMSDPLnGddbP1pRogZmylorl/8Xz+YcRNI/M74TO/6b?= =?us-ascii?Q?GZlzJzt0IaE5m0C6zfU9rUxBbmRkn3s5AMnF2fBxG0Cv/jfd3DpeSGlkr0Z7?= =?us-ascii?Q?rktnofEWyTg2yQ+ItNnlD2BmJ8tChiJEy1vroER2LHaqbNQHaEm+L7RqoeNW?= =?us-ascii?Q?0dcAQTK37YkVVmlldR19+T90VlkDPWf0LpYVn3Wq+n2/k1itkTAHEPkGafgG?= =?us-ascii?Q?x/3z4+JEmNNPswBnxJ+H6rBy5UqJzZgDgaQszyxA0PZNpvpXA+JUwXfvkrQI?= =?us-ascii?Q?wAqcE3tsfnelR6mL5xay81jvktd7eKMn2iZUNVz0ZuzBI2lomn65emRTzNO6?= =?us-ascii?Q?6XTT28Ux8zrERpAvVjsHP2NJGSi+1htln8U9Kt+JCKQPTxL8Npc4prYCxipb?= =?us-ascii?Q?a66aItw7wfHmgEiavQy463dCDgocWjpTkEBODJtw5Ip/7eauYw3fj30zVLVc?= =?us-ascii?Q?P2EOsp0+vK5/XbPgYQT+l18OUEozn+aIg2v3WxdRrxrdWDl12Nna0mURGc+m?= =?us-ascii?Q?TxVjRSrtORZUdM7i0Wb2SPbRaZriGHI8geN7A6Sm97dU7D2Vqb85OU9kfPYb?= =?us-ascii?Q?kolirxIOjmZVPEZCR3vq0cKMjmTUWM5yHnyLhzLxEuzU/LCb+RAeN5dUlgzi?= =?us-ascii?Q?/9CiXMd/K0lcrw1TBAvPsbAMYR0EsuyHSw2SjZrowclN4hs6HvLE9i26kQ2f?= =?us-ascii?Q?CR2T3qkXSGBjEVSRqKJNK/LOtkwj0T3QU0xjypJvp+Plvf3Ny7EDBXzS3N6M?= =?us-ascii?Q?mDg99Iv4FKT8K53L5EVx48sXj5SGqx0M12ka5MYECLFj4vLOBRuIA=3D=3D?=
X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3602; 6:ukM0IUvpqYTm4WbszKR1eDcHrgd/ra6VfJNUs26rpmMIX9jUQNnBw2zICuqS3guK2xyVjsYe4TDnfUzYL5vqnpRFS6dZm5tRnh4e4XSse+PVCJ0mskpZBqy0DvF/Fc/dNkQ5KuQCmE2+XsjefnWbSM5/rtsNyjU1ImjtM2lpmDLjEAJJtZgIDu341iDsCQuzy1+5FubeezCD+ANNA++oi8KfRJy0FfRwjYFbiyH+NjC2OQooY+EFqksgm2SUwFz5QBfhoAPXdGGG9UHQdU82Qv1N618lL7YfwCzb2c6S6/YI+aONqmAV4hEUvd8QC51eu1vUaqq8o0f+4WILn/DnyA==; 5:e0LXSQDeqc5tlDchTeormeacgHJGaSZSvScGy/NW4O8acwOwvsK+51snIPSrKvco3Gt49eSZOL9EAkiHKW/nzRRnm5A1HFT7oakuuCy+/WHkzKdKC6phEY8NGK/mh9BT0CIg6uInVUu+91+qm6lkWg==; 24:z8CWtDnh96W1qrt1Q2mEEIwGp2QWpU2WRa0CTkAKyiR9+romNuVJdAoTFfdqzX2ShIirVtpLTBPLYAgysvlEXhf/9r+70C8wTVRMXIXJAKo=; 7:2miMIJgIYCSV5ZM56QVt/EvA4C4/mJY9wxQLWTciXss0kqnJSGArgLp0CtmkjDJjVnrsVaVOQyjIUgy1u+ubP7rLUuhdT2fBrE0stVL00E6OkZBzFCiQBE7gH7rlqkubGZfAvo7zIzNG9icc7ey+X1RD2/DFchhgO6wnWiwbX5LyI+rHOUG5szbGb2go3aYCHOyZDJQs/RavLkjBPhexh3gBIjgJSKPRLcdCh46r5N4=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Sep 2017 19:41:05.6922 (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.12];  Helo=[p-emfe01a-sac.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR05MB3602
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 inactive
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 19:41:10 -0000

"t.petch" writes:
>Inactive appears a dozen times but is not defined, except in the course
>of those appearances it effectively is, but is sometimes 'inactive',
>sometimes 'inactive configuration', sometimes 'inactive data'.

Agree.  Consistent terms are good things.

>I would find it clearer if the term was used consistently and if there
>was an explicit definition amongst the other definitions in section 2
>such as
>
>inactve configuration: Configuration that is present in  which
>is not in use by the device and which plays no part in validation.  It
>cannot appear in any other datastore.

Inactive configuration should be allowed in  and ,
as well as in dynamic datastores.  It's hard to put constraints on
a facility that we're really not defining.

>The protocols that are currently
>standardised do not support inactive configuration but a number of
>proprietary protocols do.

In JUNOS, we use the standard protocols but encoded these as
non-standard attributes.

>Inactive configuration is only exposed to
>clients that indicate support for inactive configuration; clients not
>indicating support for  inactive configuration receive the contents of
> with the inactive configuration removed.

This is also not true for our implementation.  If you 
on any datastore that contains inactive data, you'll receive
that data.

Thanks,
 Phil


From nobody Fri Sep 15 13:31:29 2017
Return-Path: 
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 DAD631341FD; Fri, 15 Sep 2017 13:31:26 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nio365.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 2gXBhCJpJAeT; Fri, 15 Sep 2017 13:31:24 -0700 (PDT)
Received: from mx0b-00010702.pphosted.com (mx0a-00010702.pphosted.com [148.163.156.75]) (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 AEBE21341EB; Fri, 15 Sep 2017 13:31:24 -0700 (PDT)
Received: from pps.filterd (m0098781.ppops.net [127.0.0.1]) by mx0a-00010702.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v8FKQBVI002799; Fri, 15 Sep 2017 15:31:16 -0500
Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0050.outbound.protection.outlook.com [207.46.163.50]) by mx0a-00010702.pphosted.com with ESMTP id 2d0k2u8k5s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 15 Sep 2017 15:31:16 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nio365.onmicrosoft.com; s=selector1-ni-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2bzShSTPdKc8menrS2jZbh+0QT6LsHNi1IN5I7vQAq8=; b=OetIJfLgtZVzGKdrm1Kter/cX1uNHvdbKejQA95a0TtVpP+zP6CdOpH6b7EusxXxepVmvJHvsAbtFQaSQ1cQkrqSdnz1CMcgB7ysYiEKZchmifyj1WWiwJHOdBBPm5qrMTKps+0nvIzO/Z8Sk0p7ckoDGsf7CW0qFIGjFfddc+0=
Received: from DM2PR0401MB1389.namprd04.prod.outlook.com (10.160.219.156) by DM2PR0401MB1182.namprd04.prod.outlook.com (10.160.216.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.12; Fri, 15 Sep 2017 20:31:14 +0000
Received: from DM2PR0401MB1389.namprd04.prod.outlook.com ([fe80::2002:caad:4d86:98da]) by DM2PR0401MB1389.namprd04.prod.outlook.com ([fe80::2002:caad:4d86:98da%13]) with mapi id 15.20.0035.021; Fri, 15 Sep 2017 20:31:14 +0000
From: Rodney Cummings 
To: Alex Campbell , Jiangyuanlong , "netmod@ietf.org" 
CC: "tictoc@ietf.org" 
Thread-Topic: WGLC for draft-ietf-tictoc-1588v2-yang
Thread-Index: AQHTLMS9I02w6VlOokuuR++M6yrZg6K1JzgQgAA51/2AAQHXgA==
Date: Fri, 15 Sep 2017 20:31:13 +0000
Message-ID: 
References: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5A2CBD@dggeml507-mbx.china.huawei.com> <1505453243090.91370@Aviatnet.com>
In-Reply-To: <1505453243090.91370@Aviatnet.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.164.62.43]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM2PR0401MB1182; 6:N/YB9oxTusw8AGpUTE6nn1rt/dDeVg5rMiff+ydEqkbx0LAh1gk1CWVybC1KWxXXB7PEA2323CN3+dwB6vjlQjnIe7wbF/HJ4023BXREvLfIONwZTVrt0QUJjwaiVtb05dFoWm5VupLOXZhtLvR6HWltfUZIGjBCZUUBmPTa+4miSYQDHJiOO0pSoBIVVx57z2eygs5gKJww0vU/DZNK+6e7KVXI0+JB728JMrmDMUS+OrMEBm+7R6Iz2wpweVIIGwrSNyEjVmH7c9hpTYksS8TBLzqAQtW8uChrV0fc6HVqQ7YtlhAOJ/P+PdWEXp2icLccawG3Fgu2BssECMSe+w==; 5:cKTXCRYf1okHM3dZqW5Ys4p53cUiLGI2rrqE3xFT7DlLhiSB6gwDMRUJ1o/VTXiobK7eyBrZGmPDqh4i/DjFdL8HrKpxljZn5usKbsz4+L5KmzNeEZjRARnrtUThapavxUXPL7YsEDKFNgw3+NuYLg==; 24:PGVYQDuXWsgPj8UZj8yvWyEbvFBkNKeZ53iYx/pnHjOh7JKRa5bBnDJ92fASha3WukFvNVgVLSddEC+pU5sR4iJtRaxQOsVa47593Gp2xHM=; 7:eEdM0ukyckv+ZtN4G5b7LOXtXGTpO9+IVVe/2hurz9lCJbwRlZUZ5WMpr8XVhgSsWo9pBNQJ7g/S3wJwHLgx0FFTbq059xSAjnms1T5/idNAT0dxlExH0YvUYTOF7VMMMDnjRvHmrUtBma2TnL77OYVcFB3bYHwg7S8otBIz6VwEcryUwN6THQ/XFuZ5t74eqnPbwakOlf+ovOaN6l3jv4N33P+XIM+WjKf048ZUZ8g=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 94ca96e1-14d0-4b58-0021-08d4fc78b5ab
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM2PR0401MB1182; 
x-ms-traffictypediagnostic: DM2PR0401MB1182:
x-exchange-antispam-report-test: UriScan:(10436049006162)(50582790962513)(100405760836317); 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0401MB1182; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0401MB1182; 
x-forefront-prvs: 0431F981D8
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(377454003)(13464003)(199003)(189002)(25786009)(106356001)(101416001)(2900100001)(2906002)(76176999)(7696004)(5660300001)(54356999)(50986999)(66066001)(478600001)(189998001)(3280700002)(105586002)(68736007)(966005)(3660700001)(230783001)(6506006)(2501003)(4326008)(53936002)(102836003)(86362001)(6436002)(53546010)(7736002)(74316002)(55016002)(99286003)(33656002)(3846002)(2950100002)(316002)(305945005)(8936002)(97736004)(5250100002)(81156014)(6116002)(14454004)(8676002)(229853002)(6306002)(6246003)(9686003)(81166006)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0401MB1182; H:DM2PR0401MB1389.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: ni.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: ni.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Sep 2017 20:31:13.8834 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 87ba1f9a-44cd-43a6-b008-6fdb45a5204e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0401MB1182
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-15_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=30 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=30 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709150300
Archived-At: 
Subject: Re: [netmod] WGLC for draft-ietf-tictoc-1588v2-yang
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 20:31:27 -0000

Thanks Alex,

Good feedback.

As an overall point, most of these names have a 1-1 association to a name f=
rom the IEEE Std 1588-2008 standard. The 1588 document uses "DS" as an abbr=
eviation for its "data set", which is essentially an information model for =
a collection of nodes. Beyond that, 1588 uses camel-case for its names, suc=
h as:
	DefaultDS.numberPorts
The co-authors of this I-D used the following approach:
	Change names to the typical YANG convention (lowercase dashed), but otherw=
ise strive to keep the 1-1 relationship with the 1588 name.
We were trying to avoid someone getting confused, and thinking that the YAN=
G name is something new, not specified in 1588.
This means that you will see names like:
	default-ds.number-ports
I'd prefer to avoid changing to "number-of-ports", because for whatever rea=
son, 1588 uses numberPorts, and it'd be best to keep the 1-1 relationship.

Other than that, all of your comments seem fine with me.

Rodney

> -----Original Message-----
> From: TICTOC [mailto:tictoc-bounces@ietf.org] On Behalf Of Alex Campbell
> Sent: Friday, September 15, 2017 12:27 AM
> To: Jiangyuanlong ; netmod@ietf.org
> Cc: tictoc@ietf.org
> Subject: Re: [TICTOC] WGLC for draft-ietf-tictoc-1588v2-yang
>=20
> Hi,
> I've reviewed the draft and found the following issues.
>=20
> * YANG enumeration values are conventionally lowercase, but the delay-
> mechanism-enumeration and port-state-enumeration types in the draft have
> uppercase values.
> * Similarly, hyphens should be used rather than underscores (pre-master
> instead of PRE_MASTER)
> * number-ports doesn't read naturally in English; I suggest renaming it t=
o
> number-of-ports.
> * The description of port-ds-list contains a typo - "memer" instead of
> "member".
> * There's no need to have groupings that are only used once (such as
> parent-ds-entry, current-ds-entry, default-ds-entry, transparent-clock-
> default-ds-entry, port-ds-entry, transparent-clock-default-ds-entry, and
> so on) unless this is for futureproofing or some other reason I'm not
> aware of.
> * Is it necessary to include -ds in the name of every leaf, container and
> grouping?
>=20
> Note I'm not familiar with IEEE 1588, apart from a brief look through it
> just now.
>=20
> Alex
>=20
>=20
> ________________________________________
> From: netmod  on behalf of Jiangyuanlong
> 
> Sent: Friday, 15 September 2017 1:42 p.m.
> To: netmod@ietf.org
> Cc: tictoc@ietf.org
> Subject: [netmod] FW: WGLC for draft-ietf-tictoc-1588v2-yang
>=20
> Hi netmoders,
>=20
> This draft does not tackle the general YANG problem, but provide a generi=
c
> time synchronization module of 1588.
> Some of you may have interests in time synchronization, some definitely
> not. But as experts in YANG, could you please have a review of this YANG
> module and give an expert opinion?
>=20
> Thanks,
> Yuanlong
>=20
> -----Original Message-----
> From: TICTOC [mailto:tictoc-bounces@ietf.org] On Behalf Of Karen
> O'Donoghue
> Sent: Thursday, September 14, 2017 3:16 AM
> To: tictoc@ietf.org
> Cc: ntp@ietf.org
> Subject: [TICTOC] WGLC for draft-ietf-tictoc-1588v2-yang
>=20
> Folks,
>=20
> This message begins a 2 week working group last call (WGLC) for the
> following document:
>=20
> YANG Data Model for IEEE 1588v2
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dtictoc-2D1588v2-
> 2Dyang_&d=3DDwICAg&c=3DI_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=3DWA=
71sf2o7
> Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=3DKYy1NqCkT9fELXGg7ARrUez4toujzAfPIB=
Gxu
> 4O-IwA&s=3DJeFM02MFCMdOI1qLRL6vF-Db7NDdjIn4sLd9_HuDPio&e=3D
>=20
> Please review the referenced document and send any comments to the mailin=
g
> list including your assessment of whether this document is mature enough
> to proceed to the IESG. Please note that these messages of support for
> progression to the mailing list are important and will be used to
> determine WG consensus to proceed.
>=20
> Please send all comments in by Thursday 28 September 2017.
>=20
> Thank you!
> Karen
> _______________________________________________
> TICTOC mailing list
> TICTOC@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
> 3A__www.ietf.org_mailman_listinfo_tictoc&d=3DDwICAg&c=3DI_0YwoKy7z5LMTVdy=
O6YCi
> E2uzI1jjZZuIPelcSjixA&r=3DWA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=
=3DKYy1
> NqCkT9fELXGg7ARrUez4toujzAfPIBGxu4O-
> IwA&s=3DzEhnTQKhHxNWCB1MNgv1Oulcl78Y4yP3S5Zfb7m9dPY&e=3D
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
> 3A__www.ietf.org_mailman_listinfo_netmod&d=3DDwICAg&c=3DI_0YwoKy7z5LMTVdy=
O6YCi
> E2uzI1jjZZuIPelcSjixA&r=3DWA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=
=3DKYy1
> NqCkT9fELXGg7ARrUez4toujzAfPIBGxu4O-IwA&s=3DcEawQxd1IoW8ewaY4Q822u-
> yKPhzvQSiK12nIyg39cA&e=3D
>=20
> _______________________________________________
> TICTOC mailing list
> TICTOC@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
> 3A__www.ietf.org_mailman_listinfo_tictoc&d=3DDwICAg&c=3DI_0YwoKy7z5LMTVdy=
O6YCi
> E2uzI1jjZZuIPelcSjixA&r=3DWA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=
=3DKYy1
> NqCkT9fELXGg7ARrUez4toujzAfPIBGxu4O-
> IwA&s=3DzEhnTQKhHxNWCB1MNgv1Oulcl78Y4yP3S5Zfb7m9dPY&e=3D


From nobody Fri Sep 15 14:08:05 2017
Return-Path: 
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 C9675134216 for ; Fri, 15 Sep 2017 14:08:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 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, URIBL_BLOCKED=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 5Kjaed-wvX2c for ; Fri, 15 Sep 2017 14:08:01 -0700 (PDT)
Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8378F134217 for ; Fri, 15 Sep 2017 14:08:01 -0700 (PDT)
Received: by mail-lf0-x22a.google.com with SMTP id l196so3577592lfl.1 for ; Fri, 15 Sep 2017 14:08:01 -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; bh=HXcSx/iYWeU/rN8chXlg+BtltZtTCVTeJ3FsiOExbPE=; b=HwVjBYMzBGEdpxIJh49MMIA6DRO+vDfijvqbcnx69AuPV1kXHmYm/nHjaVjRac+bXV tTOKgltqsbl9P1cXXD22gBZZTWTSu99T/hXSgaghhz5BYWhspOrAFQnKISV6t0au1SdE a/X+T//8/Q7e9/F354dw63lEWZpGxZVAzMTTbaDLYEdq+c0gRDJjCBx/XWsXpwr4jN+n /KV54VAuR0esTdGusSCW+C1GyVspkJJtdzyl7JHb+fIb7qPiRnxKoxF4L7VTZATAUTIu LVJRuzHmADlK8dtT8pBVBzQdHyrRjTkNbhlV6V88GDLlIZmalT7Bovm/JgZN+WZLLSZl iPiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=HXcSx/iYWeU/rN8chXlg+BtltZtTCVTeJ3FsiOExbPE=; b=Ys/eGGQPqhIJ3cnzJfyu+hCzYrUeukdRqE0/dhI/eINfNKv3KGPgaWpSYg4OaRE3y3 9TQiDfDfrzJVMxs2qd0Q9cush9cxSnAT2rbjjop+fvsxZ+LGzFO4ISwneUg+ivFX5h+f ZMbZMMK8Zjc/DfT5ye07SP+RUd3y1QkEWhJiE2m+EGG487XYfnHGpHMF5VDy4/9ZmZ+4 OL6O9zfv810W6zGMTDGrOJVfAxwts6P4JyzZJLEHGDLs9CfJcvLsbTVyZQ1t6Fyayk6y 7GWYPQGcv0WSHEOpAROr65av0Ypdz4c/wne67CY+6fj7F5GyX1l2NVpn8FlGLAeaNuk0 hmqQ==
X-Gm-Message-State: AHPjjUipbrINcCrqcCd7QVrOai8ABJL5i1I6YWaU6EI+AnIfLEFHsUsA BQEY4qooGRQgpV69ns+RrsTg82Wwa0kBlDYXD7UJSQ==
X-Google-Smtp-Source: AOwi7QD4jyuUFgJ2RxVgwROUHCtN6uMR3pgxb00cLVMupech9K/YbufIvksKiAHvvmULTaE9uI3igJ5LMHBO50nZ8Eg=
X-Received: by 10.46.77.157 with SMTP id c29mr1284900ljd.14.1505509679729; Fri, 15 Sep 2017 14:07:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.18.41 with HTTP; Fri, 15 Sep 2017 14:07:58 -0700 (PDT)
In-Reply-To: <20170915123443.kvagu7dut7oaqoo2@elstar.local>
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <022001d32e14$8d5d4540$4001a8c0@gateway.2wire.net> <20170915123443.kvagu7dut7oaqoo2@elstar.local>
From: Andy Bierman 
Date: Fri, 15 Sep 2017 14:07:58 -0700
Message-ID: 
To: Juergen Schoenwaelder , "t.petch" ,  Lou Berger , netmod WG ,  NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c1aba68ab08e9055940c95a"
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 updates
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 21:08:04 -0000

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

Hi,

I strongly agree with Tom that the current draft is an update to RFC 7950.
I also strongly disagree with the decision to omit RFC 2119 in a standards
track document. IMO RFC 2119 terms need to be used in normative text,
especially when dealing with XPath and YANG compiler behavior.


Andy


On Fri, Sep 15, 2017 at 5:34 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Fri, Sep 15, 2017 at 12:19:42PM +0100, t.petch wrote:
> > This I-D updates RFC7950, since it changes the XPath context that YANG
> > uses, yet there is no mention of 'Updates'
>
> I think the editors of the document reached the conclusion that the
> xpath context rules stated in section 5.1. are the only meaningful
> interpretation which is consistent with what RFC 7950 says.
>
> The question is whether the text 'changes' the xpath context, or
> 'refines' the xpath context, or 'clarifies' the xpath context.  On a
> synchronous system (where intended config and applied config never
> differ), there is no change at all.
>
> That said, I have no strong opinion about the question whether section
> 5.1 requires an 'Updates: RFC 7950' or not. I do not think section 5.1
> is relevant for a system that uses RFC 7950 without implementing NMDA
> and hence the value of having a forward pointer from RFC 7950 to NMDA
> is likely not critical to have.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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


Hi,

I strongly agree with Tom that the =
current draft is an update to RFC 7950.
I also strongly disagree =
with the decision to omit RFC 2119 in a standards
track document.=
 IMO RFC 2119 terms need to be used in normative text,
especially=
 when dealing with XPath and YANG compiler behavior.


Andy

=

On Fri, Sep 15, 2017 at 5:34 AM, Juergen Sch=
oenwaelder <j.schoenwaelder@jacobs-university.de>=
; wrote:
On Fri, Sep 15, 2017 at 1=
2:19:42PM +0100, t.petch wrote:

> This I-D updates RFC7950, since it changes the XPath context that YANG=


> uses, yet there is no mention of 'Updates'



I think the editors of the document reached the conclusion that the

xpath context rules stated in section 5.1. are the only meaningful

interpretation which is consistent with what RFC 7950 says.



The question is whether the text 'changes' the xpath context, or
'refines' the xpath context, or 'clarifies' the xpath conte=
xt.=C2=A0 On a

synchronous system (where intended config and applied config never

differ), there is no change at all.



That said, I have no strong opinion about the question whether section

5.1 requires an 'Updates: RFC 7950' or not. I do not think section =
5.1

is relevant for a system that uses RFC 7950 without implementing NMDA

and hence the value of having a forward pointer from RFC 7950 to NMDA

is likely not critical to have.



/js



--

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28=
759 Bremen | Germany

Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>



_______________________________________________

netmod mailing list

netmod@ietf.org

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




--94eb2c1aba68ab08e9055940c95a--


From nobody Fri Sep 15 14:41:46 2017
Return-Path: 
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 14C88132620 for ; Fri, 15 Sep 2017 14:41:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jicVhpvQqK2C for ; Fri, 15 Sep 2017 14:41:42 -0700 (PDT)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1161A134225 for ; Fri, 15 Sep 2017 14:41:40 -0700 (PDT)
Received: by mail-lf0-x22d.google.com with SMTP id l196so3633610lfl.1 for ; Fri, 15 Sep 2017 14:41:39 -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=HLl/yhioKA/sovGYTXFEaJceF8gAT2DlDHIs1sHk/kI=; b=grGK5ymuRyrDbeUCnFgsiOgVujDxJ1syOX2usm6wf0DJPEzagxDU1RTw4iKPjxVoQy PcMBUDXyxJ2WDco0fhwezRvSYZdxyV+2jf4SkDr8THKYjm9woUK1oklz+j9Xa5pu9hRB kf2FLPnGT9wdMza7hcyJMNXUYw/ECloewsZmQuEHqqnpxgutkVlFSF9Y/7q+3C5RIVnI w6/t+f5T6VJ5cyQe8f77HdWaA+1ydSkAdau43FsqvfJV13v7Y82yN77AEiX3vu6Gsm9C OQx47UiYJHFeF8w+Y2ImzQkx/q/cXR+8Pyk8LXRf2wWZwOdqpHfJ8HHrDlamY3Hhajur KdPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HLl/yhioKA/sovGYTXFEaJceF8gAT2DlDHIs1sHk/kI=; b=HzVW3dmWXWeKP1eB31hm5FmC69l+K1VYr81EzGfgpMIIEbiQRyaUVzWHuFs2K4AsrH WADCP5y3E5oc0IiZXYX/or0mXxzb63Xli6Pq+evCJhJVQ5XxuJu4PSFOQh1lrNM0VPDp ZV3TLPjv0hbI9NHpG4FH0jI+BtAqFDR17aISsy7dhArTVGBMKusiYuuI69IfXE/pyagR 0LMuqqO1v2eCDd2R7myH3jGxRUFUYy8dgm7+mA9oEGM4PE9igPCY/LI9Kz0lXyNXTDb4 DYkuvzKQsgxZxC2O+bPde2EO8wYxTyM8LSqPpX96SaUtCISN+Qbig3dM/YWJl3ZYFEqj TIcA==
X-Gm-Message-State: AHPjjUho/aq5M0/Jrog1vAh2/dYjFYFAn3MZDTSHYT+r285M7wiOs6ra I2ZR+KpebkxgEz3gCJ985EIoehhW6t7DMzgBRLn7qg==
X-Google-Smtp-Source: AOwi7QC1Go29dMAJZEQ0CbiqjH//PbuSDVDCYOOUf/t1o9bxFYXbCEaAF0kiMzOLnilKbTAofCi00qyaMuYOxlEYekw=
X-Received: by 10.46.83.17 with SMTP id h17mr3032151ljb.158.1505511697975; Fri, 15 Sep 2017 14:41:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.18.41 with HTTP; Fri, 15 Sep 2017 14:41:37 -0700 (PDT)
In-Reply-To: <201709151940.v8FJeoib092135@idle.juniper.net>
References: <000901d32e3e$883fa9c0$4001a8c0@gateway.2wire.net> <201709151940.v8FJeoib092135@idle.juniper.net>
From: Andy Bierman 
Date: Fri, 15 Sep 2017 14:41:37 -0700
Message-ID: 
To: Phil Shafer 
Cc: "t.petch" , Martin Bjorklund ,  Juergen Schoenwaelder , Kent Watsen ,  Robert Wilton , NetMod WG Chairs ,  draft-ietf-netmod-revised-datastores@ietf.org, netmod WG 
Content-Type: multipart/alternative; boundary="94eb2c1ced70f6ac5c05594141f1"
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 inactive
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Sep 2017 21:41:44 -0000

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

On Fri, Sep 15, 2017 at 12:40 PM, Phil Shafer  wrote:

> "t.petch" writes:
> >Inactive appears a dozen times but is not defined, except in the course
> >of those appearances it effectively is, but is sometimes 'inactive',
> >sometimes 'inactive configuration', sometimes 'inactive data'.
>
> Agree.  Consistent terms are good things.
>
> >I would find it clearer if the term was used consistently and if there
> >was an explicit definition amongst the other definitions in section 2
> >such as
> >
> >inactve configuration: Configuration that is present in  which
> >is not in use by the device and which plays no part in validation.  It
> >cannot appear in any other datastore.
>
> Inactive configuration should be allowed in  and ,
> as well as in dynamic datastores.  It's hard to put constraints on
> a facility that we're really not defining.
>
> >The protocols that are currently
> >standardised do not support inactive configuration but a number of
> >proprietary protocols do.
>
> In JUNOS, we use the standard protocols but encoded these as
> non-standard attributes.
>
> >Inactive configuration is only exposed to
> >clients that indicate support for inactive configuration; clients not
> >indicating support for  inactive configuration receive the contents of
> > with the inactive configuration removed.
>
> This is also not true for our implementation.  If you 
> on any datastore that contains inactive data, you'll receive
> that data.
>
>

But this means if any clients use the disable-node feature then all clients
need to know about the feature as well, or they will mistake these nodes
for enabled nodes (i.e., plain configuration according to the standard) .

I am in favor of waiting, and not defining new YANG rules that conflict
with real deployment. Better to wait until standard protocols need to
support
inactive vs. active configuration.



Thanks,
>  Phil
>

Andy


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

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




On Fri, Sep 15, 2017 at 12:40 PM, Phil Shafer <phil@juniper.net>=
 wrote:
"t.petch" writes=
:

>Inactive appears a dozen times but is not defined, except in the course=


>of those appearances it effectively is, but is sometimes 'inactive&=
#39;,

>sometimes 'inactive configuration', sometimes 'inactive dat=
a'.



Agree.=C2=A0 Consistent terms are good things.



>I would find it clearer if the term was used consistently and if there<=
br>
>was an explicit definition amongst the other definitions in section 2
>such as

>

>inactve configuration: Configuration that is present in <running>=
 which

>is not in use by the device and which plays no part in validation.=C2=
=A0 It

>cannot appear in any other datastore.



Inactive configuration should be allowed in <candidate> and <start=
up>,

as well as in dynamic datastores.=C2=A0 It's hard to put constraints on=


a facility that we're really not defining.



>The protocols that are currently

>standardised do not support inactive configuration but a number of

>proprietary protocols do.



In JUNOS, we use the standard protocols but encoded these as

non-standard attributes.



>Inactive configuration is only exposed to

>clients that indicate support for inactive configuration; clients not
>indicating support for=C2=A0 inactive configuration receive the content=
s of

><running> with the inactive configuration removed.



This is also not true for our implementation.=C2=A0 If you <get-config&g=
t;

on any datastore that contains inactive data, you'll receive

that data.




But this means if any c=
lients use the disable-node feature then all clients
need to know=
 about the feature as well, or they will mistake these nodes
for =
enabled nodes (i.e., plain configuration according to the standard) .
=


I am in favor of waiting, and not defining new YANG rul=
es that conflict
with real deployment. Better to wait until stand=
ard protocols need to support
inactive vs. active configuration.<=
/div>




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


_______________________________________________

netmod mailing list

netmod@ietf.org

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




--94eb2c1ced70f6ac5c05594141f1--


From nobody Fri Sep 15 17:40:10 2017
Return-Path: 
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 1F1F3134239; Fri, 15 Sep 2017 17:40:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.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 w9o-Rhv9BAzN; Fri, 15 Sep 2017 17:40:07 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0099.outbound.protection.outlook.com [104.47.33.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0065B13421E; Fri, 15 Sep 2017 17:40:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=steGySKRgEFf69z0Hfyx7mkyLseOu7T2nEya7S3bBxk=; b=hagDfQ08Gh96mApz4kJjg4cAwa8w97yZcK3b1gld2SPWH6Vsa8UQ7WWtf2V//HtUwB4cu/1EnMgh9A58lyfcm3cS6CRu4Nt4//7ssJ6kqbFaPPb2wcdpFNVIOPbrplCwPvVDQGyzZ+nWFKVDHYJqrCopPeAMXZVr834nV+RHwKU=
Received: from BLUPR05CA0062.namprd05.prod.outlook.com (10.141.20.32) by CY4PR05MB3605.namprd05.prod.outlook.com (10.171.244.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Sat, 16 Sep 2017 00:40:05 +0000
Received: from BY2NAM05FT038.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::205) by BLUPR05CA0062.outlook.office365.com (2a01:111:e400:855::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.77.5 via Frontend Transport; Sat, 16 Sep 2017 00:40:04 +0000
Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=juniper.net;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender)
Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by BY2NAM05FT038.mail.protection.outlook.com (10.152.100.175) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.20.56.11 via Frontend Transport; Sat, 16 Sep 2017 00:40:03 +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; Fri, 15 Sep 2017 17:40:03 -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 v8G0e0ZH029621; Fri, 15 Sep 2017 17:40:01 -0700	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.15.2/8.15.2) with ESMTP id v8G0dwQK094022; Fri, 15 Sep 2017 20:39:58 -0400 (EDT)	(envelope-from phil@juniper.net)
Message-ID: <201709160039.v8G0dwQK094022@idle.juniper.net>
From: Phil Shafer 
To: Andy Bierman 
CC: t.petch , Martin Bjorklund , "Juergen Schoenwaelder" , Kent Watsen , Robert Wilton , NetMod WG Chairs , , netmod WG 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <94020.1505522397.1@idle.juniper.net>
Date: Fri, 15 Sep 2017 20:39:57 -0400
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(2980300002)(189002)(199003)(4326008)(2906002)(46406003)(81156014)(53416004)(81166006)(8936002)(54356999)(50986999)(97736004)(69596002)(2810700001)(110136004)(68736007)(316002)(16586007)(6246003)(53936002)(50466002)(2950100002)(6916009)(77096006)(305945005)(478600001)(1076002)(7126002)(5660300001)(23726003)(8666007)(54906002)(86362001)(8276002)(356003)(97756001)(229853002)(105596002)(189998001)(47776003)(8676002)(106466001)(76506005)(7696004)(230783001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR05MB3605; H:p-emfe01a-sac.jnpr.net; FPR:;  SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT038; 1:QKfflJU1vxV453HwvSBuVJOfnD9LnxlnhSSA03amTL5zg68zjVz/7v1zjZaJmA3vl9Znw7bB0oq5QS2xj+prMAfDFKmsQVu0qDJygEvHoVyhgCF6cQbEAMTtB8Fhh+nY
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 829ca6bc-2dd5-438c-ec1a-08d4fc9b78df
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR05MB3605; 
X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3605; 3:/EkguJOGmSr2/70DycWYH1YYfs2T3TwpqhFsQZabM2AYTqJNzzlTv1XT7vPRJ2heXr/BKcj8Sk4ocu1jceqLzcwHujKSe7uovhVOCsn1J00aT9Hack5dyX0Gu016w/eRt9DLe+sp/VhHClwaS/JAmV5H9LYT/RkcOz6Ln/IxdrQD33nIsYHx/bLyKfj9QV+Y6iijNXQqFONOAcvxDvPTmDaLCd0atG9h5hXYEs+cH5i4HxmcDgCM3DQCnUVVyAQtQdPhgykMlPZexsYPqbP0aUge+RLhlABPJ03wsQi4YMnkmolMbTP5Aqg1S9M6Ejz9Sc1dgMwewPv3YKcexyqIYEPoSca/rjgfJqMnjfw38ro=; 25:bfMfwc3xf4dHtN4C+YI2C5GrwQ8XRQ6uoY5LBmJqyjAX8kkiu7UrPhURHMPYev7afGo9p0tqMGHhzlk3SwZxowAORsJ6YiSpArl1cm6yjMaaGp8XfFB4ai21zdlBOx5jGI0iC8eulkHhHOW21976c/ROBTsm8Ud+IC6mw3+D4XyEfLjCVowhFpYRCohsv1iPiZLDU50xXrF50Tlfoi4h5QZPsVHSHzEPTSEidVB92VTAdTbPumhLcAbWR9c/j+UlW3TnP7gFcxa6/vrdmCGqN1bnxlAvl57WYwjsbM5V7tlFGLcpeVjJUCBCdl+U+rg5W5fL+52bYKOCAOENhYOjoQ==
X-MS-TrafficTypeDiagnostic: CY4PR05MB3605:
X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3605; 31:WgabK2Xn8tboMeGn4UWFykZgExPrp+MX7WL/UqQmyTfU6yqfUeBsSyfjL/1gBhZen+6nkXK/OTeaXi4HAxDZTb922pQqG2MxKTFrz681NFY5CtgfKwFnqpcmU2H8UJS4Fougw/2mlY53sGz5fXk1M2Nrc4Lgut8T4LdRFqrxa7XeVhbwetek/LOK4ArW9bzyWT11Z/qxaPVO4BRZru0gnayv37GF4WkCuiHStioYE+g=; 20:lwqX7vZ92Xd8uoszkCExFQtvasPi7CgnjxlgTpEeiXL6mYgxAfi+Me/31UZPJRLtL6NGDxVDkVNPNSD65O+6UAPe4Rbb3cRA1WxdAjvAu+RqDWIlUDIszNu2nJQ3nafCVNsMI4eCsf9wa2q+aGsjwI8gAzCKcv7+sAguLsHzF5nu1FAgVBDjVfgr77IOuXG75cPApFmQKlYtM47JykmaWa4LVIgXusrMwtBDhs3dsEjZcUOwhg2zYFcW8hWO2j7sxkhkCUuXIhJ1KCM3vdhyqhNM86+OxXSMlhdFvp+w0+BC+iwy+Y3b7xqbJp3QSsSkPMkUH5H5HL47o/IgCnY6onc3IIskRDFVlnX7WiGqSNcMWmYoGhGYmZqs625rUVbJ1fE8zgr8bmeHedSOllziwfDuTI38pDPGlRM0nk9m5NdunW45kZ7AAqNBsnr53A1nqBpjZAtgzd0BDQS3ABsOveW7uh+6Y+H8dIKaWitEKmd3FAAQp1OBApwSZsydVCvr
X-Exchange-Antispam-Report-Test: UriScan:;
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93003095)(3002001)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123558100)(20161123564025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR05MB3605; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR05MB3605; 
X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3605; 4:/4v2xpEnJlyaXYyYYHWKW3taEqSO1uAm7/MYTZLkay2lP9mbSFHVgrtpaowstcHeuGneoRGBOzgrjFkCZRZufyQXYNimKMHtJvkfKZuQ3AEVOffnd6TrJWO2MR9SBcnNtX8uPaCDoYrejHzb7FEMGE6eGvO51czCq9td7ieKekXbfrvswCNj//64CgbooXZz+HcLe+eHGEe4/HQVNJqINm8WsRRYBSW97K3wQyCrwYPhD298OwZpifJAWIE5Zdy9
X-Forefront-PRVS: 0432A04947
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY4PR05MB3605; 23:3Z8F0cHigGFPMoVDiblhJiqK0LF1mS5eIGsx+Ej7B?= =?us-ascii?Q?CQ2oRFHO0uIAEGrpBWrOsFaJUjgQuF0aBA7AhH5gzxB6sw9iS08uYoGhUqVV?= =?us-ascii?Q?1Q/XC9x/j9EK3H75gRxuKPPXzbpaWVi89cCj15ttoiAddLpHGRpHZt0CtYBP?= =?us-ascii?Q?CkUQYFZWG7a7RMIOT+l1ZfbO/ilmoEgPy+LxSXwwKcXwr9Nl4df5P9RMOIVh?= =?us-ascii?Q?b+rJq9Q4R0DbEbVPmhl/n8fO6rbx1kFi5zVKfDqnYIEr6xos8/LDBUQRHiFP?= =?us-ascii?Q?+gw3RPcBXM28rtZnRw9b/296Kwntps7QIlgvZR88t7JrmRcr+YOpABF/ABcq?= =?us-ascii?Q?ajk4BoSonv65jo/TEuMxhH4u/VeG4b+H79k0HRgSfFKr+nTOnfepz2jteL2x?= =?us-ascii?Q?iEOtK9vkdbZXXPEUqUP7FmEyeWbw/vXP8j38PKTAUxd13Tl5bzdvAgNRfhqX?= =?us-ascii?Q?/9ez5gfxqYGEZHgSBfXXzwzID5476bzkule467xR5LHPpLTaWk52Tl3lYxUy?= =?us-ascii?Q?MJ9mGzHuy35Kjb6mJW/ptriYNy8HktrhlC69ajlFTP5VK08DnDHorMPwL6LP?= =?us-ascii?Q?Db3xC5BS6I+l7gkK72kVt/2xV7aWSnlYuyt8JwABg4YHKhtFf62eNPShvCFb?= =?us-ascii?Q?wEzsjL4a9dN7xQci/ihO9Z7Z3Mms3YpAL8oSogN7bcya8rRmgHG/3KwdmkD+?= =?us-ascii?Q?DDdjtauadE61RJ+Jsgtj+zs0vO9TEpWntmZmGmV6MX6gRgxQGenFjTbOXQJD?= =?us-ascii?Q?hb/A3djSqyEFfoFaBu6hLWHg4GUyvf8jUSzahjhZdl+plyFS3NQLXuV0v104?= =?us-ascii?Q?GPYQNS2ITcXm+hKHtDLXOjot6oBkgST6REHXS2lMn7JzEyQPkgRxdoe9YPPx?= =?us-ascii?Q?sLiJQK942cwCiJv8CiKEHehW9D41SavJJA2DjwsARepeKD1k+AUt6ByLVk4s?= =?us-ascii?Q?ynJfcgihhE//O0aGQ8HfukuYpSn316vhRbauPtrLPmjle0jAT21erakP6opu?= =?us-ascii?Q?u+6rCHhx6SI07tgDNof6e16SUanzwlil9Wzmp9DI8uNrjZKzRZIgBpDtRIlO?= =?us-ascii?Q?hyT/+uU7SKNSETS+7im9R1OgH/i/ChTu23atMUuMr/0xREfuQkEmw1NI/8Uy?= =?us-ascii?Q?WeLEP+3NWtIOXDNFTTE6+/Lw5Zr376/VxVR6zdWFbIB3QlKoAhGqA=3D=3D?=
X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3605; 6:A/oqg/yDZxC/TJguQfgGZ2ctp3/w0GeFhLrzPBthEoLV+zP/5n8qSf8eAnzhg9CAKfKDJpD5gIrwRuWQdUkqNO237VDBLpUfyHqnotHkQZid16cGS9BoXg9SqqYiV4OoyutkYBTOcf5cyfPHbgs5wkaH1OFK277zo8UivviR4bIVRU9V83VrVizQ84iLr8FnsChFZd56qcLVLpMfKfzZVM17JI+N4Z/yhDUfxK+wO+WE1M19txbNUxzV1KzsyyujAFjiYUx1Swa6fWM35W4Mxp09tDrjw98OTzFt8HZaIoG4peWjEKIgxPCM3npPMc1u64rOmBF5y1SeM/NcxYncEg==; 5:yGQHbQ7LrooZn7TotaV0rtp1HMZRiLEznh6oE/r/CewEIKr9yog9WZNHS6jwA5hQikIoDMG5HmXUoE8bdN1me81xxFpVh9X6wxNdvu3HVyqyHFCN1uZVR6GEU0YqpXV3mSGdvHomgiDNUSlMyyR6pw==; 24:jg4vgx6ViX4HoLzdccKlp8MKYNGJSsK64Tu4oS6UQDDb1QfRqOX0dUU8K/5HqGijs+k4H3DcOuJ2P91Uf6qM7owpS7ou9OzORHIESQGvmos=; 7:qsBQIeKoWlsfrckRki4eBwb/0eoH9RBIezt2K69/fm/TDhRr/IKfk4lw4X8dZPHJIcVNh+PcaWXKBMQbZdpxWhnqDZh6HaC1p1ohG2J98TsyI6DVIu+I1TDCV6uIhG3lHFrAAArM5vskleGiqzQ2prfVBRjXoYl3PVrWJo8okfWXB8lUaIXnkk94q3jccFtPl2yh8dtCWFKAWgjGL09UFHMs3bdljmh+A/hpI9V8gkg=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Sep 2017 00:40:03.7434 (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.12];  Helo=[p-emfe01a-sac.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3605
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 inactive
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Sep 2017 00:40:09 -0000

Andy Bierman writes:
>But this means if any clients use the disable-node feature then all clients
>need to know about the feature as well, or they will mistake these nodes
>for enabled nodes (i.e., plain configuration according to the standard) .

The alternative would be removing inactive config from normal
 results, which means that a save/restore would be
discarding inactive config, which isn't acceptable.  Better to give
all data than to risk discarding anything.

Thanks,
 Phil


From nobody Fri Sep 15 18:39:54 2017
Return-Path: 
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 DB1E2132C2A for ; Fri, 15 Sep 2017 18:39:52 -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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDt4OMwVMhQC for ; Fri, 15 Sep 2017 18:39:51 -0700 (PDT)
Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8994613213D for ; Fri, 15 Sep 2017 18:39:50 -0700 (PDT)
Received: by mail-lf0-x22a.google.com with SMTP id k23so3867979lfi.11 for ; Fri, 15 Sep 2017 18:39:50 -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=WGGdWWHRbt08nVhxHyV1NCeCs6Vtt+WrSDrWxLsFD4Q=; b=Hu2NqkKNA7QaOVvr7vc8jbQYi04Hu7oVtZs3Q232V7Ld8OZxELudAM1gxTFFNi6tlG kYMdNbx6pdY2nedc+FHVQuDpbH6RdbrhIWr5vI0w8CA6keNFZcssC2uMEO6jFzJHrchK 4iaMTEEeH+TlUnM7N5I8PdjxgRT4NBSf0dAUQxwz8vqUpuRyR2aOhmdVpcZQGpWhzuc/ p3XUCaGnJteddYmMbUKVx049plOvfKwEOZbvdrWn1W/GJzaYji56v8phDrvt9s5XvTA+ ruURn10lDDqKJ5Jkj2YBnrE7L/U+E4nAKyDzHbEKKLBIUxH6/azM7UUrm2SSmxFRNh0M RBPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WGGdWWHRbt08nVhxHyV1NCeCs6Vtt+WrSDrWxLsFD4Q=; b=PDM2InChI5pOcUvdpuAPFg+TAG4WkP4m1rFUToiua4ctq74ZReeb83uItXNItRBZtd rpzHO3VScHw0u7xt2xZqNr5Drj0WnD8kJVYTg04JXKiWDM0ztgLzl1zOAdkZ8Lbzg6nc VmAYb9yEzZVDhMGKR1xziVSYC4wrLMIc0U7Ch/gLYjk5P51D/n4LT9VCWKTbl9aPB9Yq pBG+lc1beRqd6J6Yq4Xj/bQ/ayJVzQBiBkAgFYrSNlqSQiFNe3gunOQC5OIPGaH15pZO 62sfmh9vBzRifD0DyspN8lFIzowjgXnrZIpJUeVS2QOnlBaao/jj6vUq3oK1+KPmeR7V U77Q==
X-Gm-Message-State: AHPjjUgQvO9bypmWrj9fc5oQPgDOynuF3wC8Y2/ajlEq2EMhIGupMmD1 L3XODCPCQn/HOBnYeevfEki5N9dNudWWEreVSND3sA==
X-Google-Smtp-Source: AOwi7QAqCGrgymrrDqy3YeUzFsPzLYIj9aL+bddOFdftqLKGvSEHSnhhJt13CEr6F+plYMTZee4U7kbHpx3F/yjVvZc=
X-Received: by 10.25.235.220 with SMTP id f89mr1231347lfk.194.1505525988787; Fri, 15 Sep 2017 18:39:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.18.41 with HTTP; Fri, 15 Sep 2017 18:39:47 -0700 (PDT)
In-Reply-To: <201709160039.v8G0dwQK094022@idle.juniper.net>
References:  <201709160039.v8G0dwQK094022@idle.juniper.net>
From: Andy Bierman 
Date: Fri, 15 Sep 2017 18:39:47 -0700
Message-ID: 
To: Phil Shafer 
Cc: "t.petch" , Martin Bjorklund ,  Juergen Schoenwaelder , Kent Watsen ,  Robert Wilton , NetMod WG Chairs ,  draft-ietf-netmod-revised-datastores@ietf.org, netmod WG 
Content-Type: multipart/alternative; boundary="001a113c1796c3238d05594495e9"
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 inactive
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Sep 2017 01:39:53 -0000

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

On Fri, Sep 15, 2017 at 5:39 PM, Phil Shafer  wrote:

> Andy Bierman writes:
> >But this means if any clients use the disable-node feature then all
> clients
> >need to know about the feature as well, or they will mistake these nodes
> >for enabled nodes (i.e., plain configuration according to the standard) .
>
> The alternative would be removing inactive config from normal
>  results, which means that a save/restore would be
> discarding inactive config, which isn't acceptable.  Better to give
> all data than to risk discarding anything.
>
>
It might get set to "active" if the client preserves the
special attribute it doesn't know about.

This looks like 1 issue where each client cannot opt-in when ready.
Too bad it can't be standardized, even in a simplified form.





> Thanks,
>  Phil
>


Andy

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




On Fri, Sep 15, 2017 at 5:39 PM, Phil Shafer <phil@juniper.net><=
/span> wrote:
Andy Bierman writes:

>But this means if any clients use the disable-node feature then all cli=
ents

>need to know about the feature as well, or they will mistake these node=
s

>for enabled nodes (i.e., plain configuration according to the standard)=
 .



The alternative would be removing inactive config from normal

<get-data> results, which means that a save/restore would be

discarding inactive config, which isn't acceptable.=C2=A0 Better to giv=
e

all data than to risk discarding anything.



It might get set to "active"=
 if the client preserves the
special attribute it doesn't kno=
w about.

This looks like 1 issue where each client=
 cannot opt-in when ready.
Too bad it can't be standardized, =
even in a simplified form.



=C2=A0

Thanks,

=C2=A0Phil




Andy



--001a113c1796c3238d05594495e9--


From nobody Sat Sep 16 00:24:11 2017
Return-Path: 
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 9D2FB1320D8; Sat, 16 Sep 2017 00:24: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 FQBSfg-JFoYq; Sat, 16 Sep 2017 00:24:06 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E99C128D0D; Sat, 16 Sep 2017 00:24:06 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id DF9EAF4B; Sat, 16 Sep 2017 09:24:04 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 50uWQWQhlnF2; Sat, 16 Sep 2017 09:24:01 +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 atlas5.jacobs-university.de (Postfix) with ESMTPS; Sat, 16 Sep 2017 09:24:04 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 99AC4200E9; Sat, 16 Sep 2017 09:24:04 +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 WzCyl3CBYzIU; Sat, 16 Sep 2017 09:24:04 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CD498200E8; Sat, 16 Sep 2017 09:24:03 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id B8CC540F7359; Sat, 16 Sep 2017 09:24:03 +0200 (CEST)
Date: Sat, 16 Sep 2017 09:24:03 +0200
From: Juergen Schoenwaelder 
To: Andy Bierman 
Cc: "t.petch" , Lou Berger , netmod WG , NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org
Message-ID: <20170916072403.xp37556z6g7b42gr@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Andy Bierman , "t.petch" , Lou Berger , netmod WG , NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <022001d32e14$8d5d4540$4001a8c0@gateway.2wire.net> <20170915123443.kvagu7dut7oaqoo2@elstar.local> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 updates
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Sep 2017 07:24:09 -0000

On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
> Hi,
> 
> I strongly agree with Tom that the current draft is an update to RFC 7950.
> I also strongly disagree with the decision to omit RFC 2119 in a standards
> track document. IMO RFC 2119 terms need to be used in normative text,
> especially when dealing with XPath and YANG compiler behavior.
>

RFC 8174:

   o  These words can be used as defined here, but using them is not
      required.  Specifically, normative text does not require the use
      of these key words.  They are used for clarity and consistency
      when that is what's wanted, but a lot of normative text does not
      use them and is still normative.

/js

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


From nobody Sat Sep 16 02:56:51 2017
Return-Path: 
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 425A713306C for ; Sat, 16 Sep 2017 02:56:50 -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 GadHwr5JwLH8 for ; Sat, 16 Sep 2017 02:56:48 -0700 (PDT)
Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52D0713306A for ; Sat, 16 Sep 2017 02:56:48 -0700 (PDT)
Received: by mail-lf0-x233.google.com with SMTP id d4so4383336lfj.7 for ; Sat, 16 Sep 2017 02:56:48 -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; bh=AeO6MySOXK+lJ1xOzNCWdnRITgq15Z+2Y12HzH/UQA8=; b=I46o0nFBJmX+09m3JHZ1JCE2arGvgiHgoR/R5MujztJ9N/bXcqEvIgbf1Z74gBSc3j dfteKYydrpcvVNZU2iPPT3sAD1VD0+fHUY7HdkFqbbIAp8m7a2/8GOKyMESMHih/y9Rm SnbTsB5MMsITaFncZgsm1g8geYP2hFkCwXKXxd0TToEsJA6zncVtCWOhnPgenbmTdreZ I1KnsqET+VSkf/1x+F3GG014mG+qw2J90ZOmYExVEuA5xBiLvjeaLtx7Ba+sx/gqFL3i TcUqPSBqFLEhtbd1sH0hSoRDQgsxwT9QX+pJ2iQXT1O+vX1YmhGnwj0TY9K2NH1MEZTA gxwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=AeO6MySOXK+lJ1xOzNCWdnRITgq15Z+2Y12HzH/UQA8=; b=GdUddGzbQ0jwDPoClCmWCuJ8G75hPtE0WiOwluGgNWrgL0VeY8TE4WEBzZvmz+KCSS QtyEYKhgLFg1ke6CCGNeYZgVIcwezPqFKAskEAkGFNEi1J597a0ej93OfxxFaxuhArXv 1ObatUM4ATOgbPT4kskvvkZz1GWRVspAPb2IE2WonAEMyjYZv0aHRYTaArF1LlbYpuNC Zbm3FmxeCJBal28bBn8vMvXpVxcs6hmNONBbSuy1OpzlVg5ohIqcivp/g+V239nfy3Ub wrmXQcEa/7/BVEbu15PVIevT7ohJmx4iY8Mi7oi0LxW6kixdmmV4nK8a7bYCAnnLsYdc XFog==
X-Gm-Message-State: AHPjjUiMsryasWBeSCMNDtCUsu95XRp2wMHsAF7vnfj/t4fThVd0kok6 sTgvLeGyy2VrTHaTFluTlihsiPtzxqnyxfsbGYS7ag==
X-Google-Smtp-Source: AOwi7QDiGzfJXx4ca9UtUNkV+6SFoPGZXapuLVOAUZJQQeDkIl8oF38IDeVnOnzsxIm12sbNtdiMiU4syG3hWadAGHM=
X-Received: by 10.25.211.14 with SMTP id k14mr1596185lfg.51.1505555806396; Sat, 16 Sep 2017 02:56:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.18.41 with HTTP; Sat, 16 Sep 2017 02:56:45 -0700 (PDT)
In-Reply-To: <20170916072403.xp37556z6g7b42gr@elstar.local>
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <022001d32e14$8d5d4540$4001a8c0@gateway.2wire.net> <20170915123443.kvagu7dut7oaqoo2@elstar.local>  <20170916072403.xp37556z6g7b42gr@elstar.local>
From: Andy Bierman 
Date: Sat, 16 Sep 2017 02:56:45 -0700
Message-ID: 
To: Juergen Schoenwaelder , Andy Bierman ,  "t.petch" , Lou Berger , netmod WG , NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org
Content-Type: multipart/alternative; boundary="001a11400d7207bef205594b8778"
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 updates
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Sep 2017 09:56:50 -0000

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

On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
> > Hi,
> >
> > I strongly agree with Tom that the current draft is an update to RFC
> 7950.
> > I also strongly disagree with the decision to omit RFC 2119 in a
> standards
> > track document. IMO RFC 2119 terms need to be used in normative text,
> > especially when dealing with XPath and YANG compiler behavior.
> >
>
> RFC 8174:
>
>    o  These words can be used as defined here, but using them is not
>       required.  Specifically, normative text does not require the use
>       of these key words.  They are used for clarity and consistency
>       when that is what's wanted, but a lot of normative text does not
>       use them and is still normative.
>
>
So what?
Existing YANG specifications use RFC 2119 terms.
This draft uses those terms, just with lower-case.
Either way, the new YANG rules seem half-baked and not ready
for standardization.



> /js
>
>
Andy


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

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




On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bier=
man wrote:

> Hi,

>

> I strongly agree with Tom that the current draft is an update to RFC 7=
950.

> I also strongly disagree with the decision to omit RFC 2119 in a stand=
ards

> track document. IMO RFC 2119 terms need to be used in normative text,<=
br>
> especially when dealing with XPath and YANG compiler behavior.

>



RFC 8174:



=C2=A0 =C2=A0o=C2=A0 These words can be used as defined here, but using the=
m is not

=C2=A0 =C2=A0 =C2=A0 required.=C2=A0 Specifically, normative text does not =
require the use

=C2=A0 =C2=A0 =C2=A0 of these key words.=C2=A0 They are used for clarity an=
d consistency

=C2=A0 =C2=A0 =C2=A0 when that is what's wanted, but a lot of normative=
 text does not

=C2=A0 =C2=A0 =C2=A0 use them and is still normative.



So what?
Existing YANG specifications use =
RFC 2119 terms.
This draft uses those terms, just with lower-case=
.
Either way, the new YANG rules seem half-baked and not ready
for standardization.

=C2=A0

/js



Andy
=C2=A0

--

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28=
759 Bremen | Germany

Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>





--001a11400d7207bef205594b8778--


From nobody Sat Sep 16 03:14:13 2017
Return-Path: 
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 37BB2132D44; Sat, 16 Sep 2017 03:14:12 -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 C2YJnftVeyVY; Sat, 16 Sep 2017 03:14:11 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E880313219C; Sat, 16 Sep 2017 03:14:10 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id BB2BACD7; Sat, 16 Sep 2017 12:14:09 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id TF4RNfheAQrJ; Sat, 16 Sep 2017 12:14:06 +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 atlas5.jacobs-university.de (Postfix) with ESMTPS; Sat, 16 Sep 2017 12:14:09 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7409E200E9; Sat, 16 Sep 2017 12:14:09 +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 aZwGYs4OzYGj; Sat, 16 Sep 2017 12:14:09 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EAF5E200E8; Sat, 16 Sep 2017 12:14:08 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id E1F6140F74ED; Sat, 16 Sep 2017 12:14:08 +0200 (CEST)
Date: Sat, 16 Sep 2017 12:14:08 +0200
From: Juergen Schoenwaelder 
To: Andy Bierman 
Cc: "t.petch" , Lou Berger , netmod WG , NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org
Message-ID: <20170916101408.v7kimhqkrgxo65m3@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Andy Bierman , "t.petch" , Lou Berger , netmod WG , NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <022001d32e14$8d5d4540$4001a8c0@gateway.2wire.net> <20170915123443.kvagu7dut7oaqoo2@elstar.local>  <20170916072403.xp37556z6g7b42gr@elstar.local> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 updates
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Sep 2017 10:14:12 -0000

On Sat, Sep 16, 2017 at 02:56:45AM -0700, Andy Bierman wrote:

> Either way, the new YANG rules seem half-baked and not ready
> for standardization.

OK. Then please tell us where you see problems. The usage of must vs
MUST does not seem to be the issue.

/js

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


From nobody Sat Sep 16 09:59:39 2017
Return-Path: 
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 51B02133066 for ; Sat, 16 Sep 2017 09:59:37 -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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuqnO-WYvVuu for ; Sat, 16 Sep 2017 09:59:36 -0700 (PDT)
Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3CDA1326ED for ; Sat, 16 Sep 2017 09:59:33 -0700 (PDT)
Received: by mail-lf0-x22a.google.com with SMTP id u21so4790760lfk.12 for ; Sat, 16 Sep 2017 09:59:33 -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; bh=PNls2MqxKv87w+0gmjenYs1ZJ3HXwiN4+U4kgtyshV4=; b=OnYnRzXNWMa+n0wFLHTPVPwo29X4tvMUov9yT2U9VpH+JdWl70S2xatznX07QK81di UpAvAhN0IbZHDFM6ynvLmbSwXTuLjZpJB0SbubsVoT7SWvepApEOtQJNL1Oj3T6lB7B9 j2Et1JX/SPVCoKB0Lz2nCCzAuQ3/4lPMr+AJqG7wF4f088bx0Sgwu8ZkLbmf3uXQcb/R PgSeiMgvYUUHhJiMfrqeSrJLFZfppcwMdxTpCAq/CxuK9tz2xADp3j/ur/5TRej3dx8x TR0nrweX+QXruY6ZsDVfhDlePKvyt4DunHcqhSTco97JN8oyBBgS/JCa2gAzsM0vvqlQ nw9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=PNls2MqxKv87w+0gmjenYs1ZJ3HXwiN4+U4kgtyshV4=; b=kwdUX5eeNySZgxJ2liHYJPKyB54MoerxVTbYswFyCuiDHnXYvNugQ32bZTZLDirPbz Ad9UpxmgCbDjuiUDh/ZEwcUeX+lwi7pDkmBxRBs1BkXQEFdDRLOCvnYgUUSa3VNKdToo vLQLCc2/Zi5crqK/9I12WjXw4yAs/mk8r4YRfB7iztsz8HlSy6yDRTU2DWlFuKSYW1On Aqe5lBTpaLFjrARkxdMtipzCafpdBMROYd/unO0wZuA4mn+8YCMk1LfuiWzLCK/rEnXX sCQeo211YqQLm+K4MU2bFyibL8nr9K1vrGafqqGPDuagALfGAgHTNjaxi4BeiPqPQyqC Pybw==
X-Gm-Message-State: AHPjjUgUmXUG3xbbReFNklYsF4P15WYInIOAqJ08KN3XCjlWqcSSv1s2 qKGkacmplBWrAG97OHfjzFECVZPafoGVbk7picZEyw==
X-Google-Smtp-Source: AOwi7QCR+arj9jBCtOYG1QBc0AD4VdEb52yJTfCZGgNPeqCxIbAPqSiafTNWCe644mtVbVnqIG0DZLT7O4S3prCfwDs=
X-Received: by 10.25.142.9 with SMTP id q9mr1528865lfd.89.1505581171808; Sat, 16 Sep 2017 09:59:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.18.41 with HTTP; Sat, 16 Sep 2017 09:59:30 -0700 (PDT)
In-Reply-To: <20170916101408.v7kimhqkrgxo65m3@elstar.local>
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <022001d32e14$8d5d4540$4001a8c0@gateway.2wire.net> <20170915123443.kvagu7dut7oaqoo2@elstar.local>  <20170916072403.xp37556z6g7b42gr@elstar.local>  <20170916101408.v7kimhqkrgxo65m3@elstar.local>
From: Andy Bierman 
Date: Sat, 16 Sep 2017 09:59:30 -0700
Message-ID: 
To: Juergen Schoenwaelder , Andy Bierman ,  "t.petch" , Lou Berger , netmod WG , NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org
Content-Type: multipart/alternative; boundary="f403045f5070ed2fa60559516efa"
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 updates
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Sep 2017 16:59:37 -0000

--f403045f5070ed2fa60559516efa
Content-Type: text/plain; charset="UTF-8"

On Sat, Sep 16, 2017 at 3:14 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Sat, Sep 16, 2017 at 02:56:45AM -0700, Andy Bierman wrote:
>
> > Either way, the new YANG rules seem half-baked and not ready
> > for standardization.
>
> OK. Then please tell us where you see problems. The usage of must vs
> MUST does not seem to be the issue.
>
>

sec 4.4:

    Validation is performed on the contents of .


Does this mean validation is not done on ?
The draft does not say.  If so, then this seems to break all
existing clients that validate . Standard operations
such as  or  with :writable-running capability work
this way.

What happens if a client does validation on ? It now can fail even
though RFC 7950, sec. 8.1 says:

   *The running configuration datastore MUST always be valid.*

The motivation is clear in the RD draft, sec 4.3:

   The running configuration datastore () holds the complete
   current configuration on the device.  It may include inactive
   configuration or template-mechanism-oriented configuration that
   require further expansion.


This forces a client to accept unspecified proprietary inactive
configuration and proprietary templates
that apparently are not subject to YANG validation.

   Currently there are no standard mechanisms defined that affect
    so that it would have different contents than ,
   but this architecture allows for such mechanisms to be defined.


This is a significant change in the NETCONF/RESTCONF standards which is
completely unrelated to operational state. The client MUST understand
unspecified
proprietary differences between  and .  The client
can now
assume that  is always valid, but this draft breaks that.

IMO, only the  datastore work is standards-ready.


Andy



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

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




On Sat, Sep 16, 2017 at 3:14 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Sat, Sep 16, 2017 at 02:56:45A=
M -0700, Andy Bierman wrote:



> Either way, the new YANG rules seem half-baked and not ready

> for standardization.



OK. Then please tell us where you see problems. The usage of must vs

MUST does not seem to be the issue.




sec 4.4:
    Validation is performed on the contents of <=
intended>.

Does this mean validation is n=
ot done on <running>?
The draft does not say.=C2=A0 If so, =
then this seems to break all
existing clients that validate <r=
unning>. Standard operations
such as <commit> or <edi=
t-config> with :writable-running capability work this way.
What happens if a client does validation on <running>? It=
 now can fail even
though RFC 7950, sec. 8.1 says:

=

=C2=A0 =C2=
=A0The running configuration datastore MUST always be valid.<=
b>=C2=A0

The motivation is clear in the RD dra=
ft, sec 4.3:

   =
The running configuration datastore (<running>) holds the complete
   current configuration on the device.  It may include inactive
   configuration or template-mechanism-oriented configuration that
   require further expansion.


This forces a client to accept unspecified =
proprietary inactive configuration and proprietary templates
that=
 apparently are not subject to YANG validation.

   Currently there are no standard mechanis=
ms defined that affect
   <intended> so that it would have different contents than <runni=
ng>,
   but this architecture allows for such mechanisms to be defined.

This is a significant change in the NETCONF/RESTCONF=
 standards which is
completely unrelated to operational state. Th=
e client MUST understand unspecified
proprietary differences betw=
een <running> and <intentional>.=C2=A0 The client can now
=

assume that <running> is always valid, but this draft breaks tha=
t.

IMO, only the <operational> datastore wor=
k is standards-ready.


Andy




/js



--

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28=
759 Bremen | Germany

Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>





--f403045f5070ed2fa60559516efa--


From nobody Sun Sep 17 06:40:19 2017
Return-Path: 
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 7CB2E132F84; Sun, 17 Sep 2017 06:40: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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdEebcbCAT2v; Sun, 17 Sep 2017 06:40: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 B152D13306A; Sun, 17 Sep 2017 06:40:12 -0700 (PDT)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 083B01AE0383; Sun, 17 Sep 2017 15:40:10 +0200 (CEST)
Date: Sun, 17 Sep 2017 15:41:15 +0200 (CEST)
Message-Id: <20170917.154115.791964858062115650.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: j.schoenwaelder@jacobs-university.de, ietfc@btconnect.com, lberger@labn.net, netmod@ietf.org, netmod-chairs@ietf.org, draft-ietf-netmod-revised-datastores@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References:  <20170916072403.xp37556z6g7b42gr@elstar.local> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 updates
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Sep 2017 13:40:17 -0000

Andy Bierman  wrote:
> On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> 
> > On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
> > > Hi,
> > >
> > > I strongly agree with Tom that the current draft is an update to RFC
> > 7950.
> > > I also strongly disagree with the decision to omit RFC 2119 in a
> > standards
> > > track document. IMO RFC 2119 terms need to be used in normative text,
> > > especially when dealing with XPath and YANG compiler behavior.
> > >
> >
> > RFC 8174:
> >
> >    o  These words can be used as defined here, but using them is not
> >       required.  Specifically, normative text does not require the use
> >       of these key words.  They are used for clarity and consistency
> >       when that is what's wanted, but a lot of normative text does not
> >       use them and is still normative.
> >
> >
> So what?
> Existing YANG specifications use RFC 2119 terms.
> This draft uses those terms, just with lower-case.

Actually, section 5.1 XPath Context in the revised datastore draft
uses the same language as section 6.4.1 XPath Context in RFC 7950.  In
fact, the text in the draft is copied (and adjusted) from RFC 7950.


/martin


From nobody Sun Sep 17 08:31:56 2017
Return-Path: 
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 3BE02133065 for ; Sun, 17 Sep 2017 08:31:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmCVYmVzMKeq for ; Sun, 17 Sep 2017 08:31:49 -0700 (PDT)
Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35FDE1252BA for ; Sun, 17 Sep 2017 08:31:49 -0700 (PDT)
Received: by mail-lf0-x232.google.com with SMTP id l196so5935326lfl.1 for ; Sun, 17 Sep 2017 08:31: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=ZI+Tvsakcd9d5mI+Q0+BsADLMORSbhnCkoKK2ZIBpTA=; b=Gq2y+NnqZK03AuLWfT0r+3Di9KBAuJRtBc/+vw/tyMQvrlb6wfnOktRaHPl1WIeEtp w9W/QOuBY2B6QujCkj62hH51PAmqhBQxkKjXn9tfwqU4a2HPW4/uGxgy99ZXLMDGLRnx D1L6ATplKTgG+u1auNH4hj8+EHTN/QeJKBeRaTn1bAMk7CDDIBz6+WnfILVswyzdFmSP lGQznFH6eluxAbCz3OIvv8sPcGuvY5Zs/PAQ8AI+qevranD3fg4kPf3QsGY77ov1YjT7 CzyhWP+rVUTSXQ6lo27CSq2UVvxtVBYvLTaxZorolGcqURnzajWiru5WslUJ3T+rGLEH 8dXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZI+Tvsakcd9d5mI+Q0+BsADLMORSbhnCkoKK2ZIBpTA=; b=H69VUP8OXun7yE85ioUjpwBkBe3IGBgoTxwvvF4w76P1nsVmisME5jmxGuKwp81SYX zl7Shk5w+SdG/j8sTBHoUiUK6eP44NP4hFe0TCzBt9W5x0Alcw57rhTquN+98XNpUQwt DoNSn93Z9EDpgVeu9v4eRkhwBv3U05gk6nE3qIfJRyc8+VlYVRznU7OPVosb5xduJfF6 zUEnpyueTIDMj/hWYFPQoLPJCWd3Mrtnoju8Mvp9Z1mzNlm4kNe2eggPIasMcpbmY7uF Gbo+Sp79st9LtZ0sDtBE1speHz8Vuxdm2SqhBYSzv0ec88yoNbXIcsMVgSHy3brOOrCk hWKA==
X-Gm-Message-State: AHPjjUjXtLem1Di5850+M/uWcokqP1Fbg5KV4lBYdfVzfgDgnfp+sHil PTN45nCaW/oj4gyX/OHKe/T/McL2A0gJTc/4ukShNw==
X-Google-Smtp-Source: AOwi7QBy9it5jV9S9W7r0/7mWgihRd1A0hkKT4UVi+Oz6b4fjj62UkZ0zafGpsz/tg13qau24FJIYKYgpFTQr4lJ4pM=
X-Received: by 10.25.142.9 with SMTP id q9mr2097377lfd.89.1505662307361; Sun, 17 Sep 2017 08:31:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.18.41 with HTTP; Sun, 17 Sep 2017 08:31:46 -0700 (PDT)
In-Reply-To: <20170917.154115.791964858062115650.mbj@tail-f.com>
References:  <20170916072403.xp37556z6g7b42gr@elstar.local>  <20170917.154115.791964858062115650.mbj@tail-f.com>
From: Andy Bierman 
Date: Sun, 17 Sep 2017 08:31:46 -0700
Message-ID: 
To: Martin Bjorklund 
Cc: Juergen Schoenwaelder , "t.petch" ,  Berger Lou , "netmod@ietf.org" ,  NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org
Content-Type: multipart/alternative; boundary="f403045f5070fb7de1055964528e"
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 updates
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Sep 2017 15:31:55 -0000

--f403045f5070fb7de1055964528e
Content-Type: text/plain; charset="UTF-8"

Hi,

My concern is that the definition of  is being changed to
include undefined and undeclared proprietary extensions.
This is counter-productive to the IETF's stated goal of interoperability.


Andy


On Sun, Sep 17, 2017 at 6:41 AM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder <
> > j.schoenwaelder@jacobs-university.de> wrote:
> >
> > > On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
> > > > Hi,
> > > >
> > > > I strongly agree with Tom that the current draft is an update to RFC
> > > 7950.
> > > > I also strongly disagree with the decision to omit RFC 2119 in a
> > > standards
> > > > track document. IMO RFC 2119 terms need to be used in normative text,
> > > > especially when dealing with XPath and YANG compiler behavior.
> > > >
> > >
> > > RFC 8174:
> > >
> > >    o  These words can be used as defined here, but using them is not
> > >       required.  Specifically, normative text does not require the use
> > >       of these key words.  They are used for clarity and consistency
> > >       when that is what's wanted, but a lot of normative text does not
> > >       use them and is still normative.
> > >
> > >
> > So what?
> > Existing YANG specifications use RFC 2119 terms.
> > This draft uses those terms, just with lower-case.
>
> Actually, section 5.1 XPath Context in the revised datastore draft
> uses the same language as section 6.4.1 XPath Context in RFC 7950.  In
> fact, the text in the draft is copied (and adjusted) from RFC 7950.
>
>
> /martin
>

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


Hi,

My concern is that the definition o=
f <running> is being changed to
include undefined and undec=
lared proprietary extensions.
This is counter-productive to the I=
ETF's stated goal of interoperability.


Andy


On Sun, Sep 17, 2017 at 6:41 AM, Martin Bjorklund <mbj@=
tail-f.com> wrote:
Andy Bie=
rman <andy@yumaworks.com> w=
rote:

> On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder <

> j.schoenwaelde=
r@jacobs-university.de> wrote:

>

> > On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:

> > > Hi,

> > >

> > > I strongly agree with Tom that the current draft is an updat=
e to RFC

> > 7950.

> > > I also strongly disagree with the decision to omit RFC 2119 =
in a

> > standards

> > > track document. IMO RFC 2119 terms need to be used in normat=
ive text,

> > > especially when dealing with XPath and YANG compiler behavio=
r.

> > >

> >

> > RFC 8174:

> >

> >=C2=A0 =C2=A0 o=C2=A0 These words can be used as defined here, but=
 using them is not

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0required.=C2=A0 Specifically, normative=
 text does not require the use

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0of these key words.=C2=A0 They are used=
 for clarity and consistency

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0when that is what's wanted, but a l=
ot of normative text does not

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0use them and is still normative.

> >

> >

> So what?

> Existing YANG specifications use RFC 2119 terms.

> This draft uses those terms, just with lower-case.



Actually, section 5.1 XPath Context in the revised datastore draft

uses the same language as section 6.4.1 XPath Context in RFC 7950.=C2=A0 In=


fact, the text in the draft is copied (and adjusted) from RFC 7950.





/martin





--f403045f5070fb7de1055964528e--


From nobody Sun Sep 17 10:33:03 2017
Return-Path: 
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 34B221332CD for ; Sun, 17 Sep 2017 10:33:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ggxj41Fm6XA2 for ; Sun, 17 Sep 2017 10:32:57 -0700 (PDT)
Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::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 A57ED133224 for ; Sun, 17 Sep 2017 10:32:52 -0700 (PDT)
Received: by mail-lf0-x235.google.com with SMTP id d4so6092366lfj.7 for ; Sun, 17 Sep 2017 10:32:52 -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=ejF4j43Cg9+ntKEdgKeutZMMPYYIKJumrxDovA5aJPU=; b=dmsaZUSBswv2V+1esahhl8ir9ChYzoNwHFnE6LChq55IyAKlJ1Qvjcu6QUmJOlWf/Q /zSZO6+HH0ou4lLRvpPXwGaxE2T5082YIce20Xvnbrhc4+U6Kh9Xfm+NiHYR6eI6h1tP MjBm287a+7VwZ7o19Gp6dPpgJudIX+lIAdblHBPsx/9QYGH0eH5+G8wXX7XQ6ainsHwv MTaLThJK1Df5W0cUq062EJyydh7he6wMJk4IoCJQzBVK9d8uQEh1we4ydX/bDn3M01Jc zmzwn+1PXT/UGgHWfwUea5+Hk8KXevsf/eH54RtmADtscMCPuazz9o4EVw+rrAFUyWcY YvKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ejF4j43Cg9+ntKEdgKeutZMMPYYIKJumrxDovA5aJPU=; b=jOvHbpBtODAJZWvsow3bVGh9jPQ7B5Nhmi26lW4xU6pkWNXFOYLeN4LXHK4atrpfnV bkKWbo6lk98JtA1ZgF5cbjtPYOhTFXICGTvOezSPhyDBzeFkDcp23FRS3O8ZfEeQ3ReL FQ+U8HZ2sFKom7HQVc4A9b/Et7Twr8vNeGV9W7UtpgnCfIrLDLBiFdBTHHLUcf5Vd2KJ K/hZvXy4dNhr4FwhUYlmV5yEMXAUJY/VIC/G4MvTT0hcJO/vp6I1OJpgWQjPTyZgNDb5 azg6aVvrNNroJQTJ274Nnkf3MHc2z/VWipvhFcZtVVaGNtIwDLB3wQ241lY1JNIVw4Or ZL7A==
X-Gm-Message-State: AHPjjUhcwvl/smuNhXZg6fxLw0rf4QLS6ztDZEyXV6+NHMlPXUOUwH1C g48LTEA83pZdzOrs8f8kQHtmr7mtYxafCIRnpHWdzQ==
X-Google-Smtp-Source: AOwi7QDWLv0SXdZyLKKW8LlztFc1wFa3FEn3LdvOd3CUTQwcYwYWAkcnGgSQNmloXz2ZZgtXBgU5joPBChUQ5B8h8UE=
X-Received: by 10.25.59.138 with SMTP id d10mr2618032lfl.202.1505669570772; Sun, 17 Sep 2017 10:32:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.18.41 with HTTP; Sun, 17 Sep 2017 10:32:49 -0700 (PDT)
In-Reply-To: 
References:  <20170916072403.xp37556z6g7b42gr@elstar.local>  <20170917.154115.791964858062115650.mbj@tail-f.com> 
From: Andy Bierman 
Date: Sun, 17 Sep 2017 10:32:49 -0700
Message-ID: 
To: Martin Bjorklund 
Cc: Juergen Schoenwaelder , "t.petch" ,  Berger Lou , "netmod@ietf.org" ,  NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c14ae58ea55ec055966030e"
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 updates
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Sep 2017 17:33:02 -0000

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

On Sun, Sep 17, 2017 at 8:31 AM, Andy Bierman  wrote:

> Hi,
>
> My concern is that the definition of  is being changed to
> include undefined and undeclared proprietary extensions.
> This is counter-productive to the IETF's stated goal of interoperability.
>
>

I would prefer to solve this problem by making disabled nodes part of the
standard:
https://tools.ietf.org/html/draft-kwatsen-conditional-enablement-00
Bring back Kent's draft -- define a simple boolean for enabled/disabled.

I don't understand why templates are mentioned in the draft.
since they are not really defined.  Isn't it good enough to say that
the server can add configuration nodes to the  datastore,
without getting specific about non-standard mechanisms?
There are many other ways the server can inject configuration that are not
mentioned.


Andy




> Andy
>
>
> On Sun, Sep 17, 2017 at 6:41 AM, Martin Bjorklund  wrote:
>
>> Andy Bierman  wrote:
>> > On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder <
>> > j.schoenwaelder@jacobs-university.de> wrote:
>> >
>> > > On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
>> > > > Hi,
>> > > >
>> > > > I strongly agree with Tom that the current draft is an update to RFC
>> > > 7950.
>> > > > I also strongly disagree with the decision to omit RFC 2119 in a
>> > > standards
>> > > > track document. IMO RFC 2119 terms need to be used in normative
>> text,
>> > > > especially when dealing with XPath and YANG compiler behavior.
>> > > >
>> > >
>> > > RFC 8174:
>> > >
>> > >    o  These words can be used as defined here, but using them is not
>> > >       required.  Specifically, normative text does not require the use
>> > >       of these key words.  They are used for clarity and consistency
>> > >       when that is what's wanted, but a lot of normative text does not
>> > >       use them and is still normative.
>> > >
>> > >
>> > So what?
>> > Existing YANG specifications use RFC 2119 terms.
>> > This draft uses those terms, just with lower-case.
>>
>> Actually, section 5.1 XPath Context in the revised datastore draft
>> uses the same language as section 6.4.1 XPath Context in RFC 7950.  In
>> fact, the text in the draft is copied (and adjusted) from RFC 7950.
>>
>>
>> /martin
>>
>
>

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




On Sun, Sep 17, 2017 at 8:31 AM, Andy Bierman <andy@yumaworks.com=
> wrote:
Hi,

My concern is that the definition of &=
lt;running> is being changed to
include undefined and undeclar=
ed proprietary extensions.
This is counter-productive to the IETF=
's stated goal of interoperability.



I would prefer to solve this problem=
 by making disabled nodes part of the standard:
Bring=
 back Kent's draft -- define a simple boolean for enabled/disabled.

I don't understand why templates are mentioned in=
 the draft.
since they are not really defined.=C2=A0 Isn't it=
 good enough to say that
the server can add configuration nod=
es to the <intended> datastore,
without getting specific ab=
out non-standard mechanisms?
There are many other ways the server=
 can inject configuration that are not mentioned.

=

Andy




Andy


On Sun, Sep 17, 2017 at 6:41 AM, Martin Bjo=
rklund <mbj@tail-f.com> wrote:
Andy Bierman <andy@yumaworks.com> wrote:

> On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder <

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

>

> > On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:

> > > Hi,

> > >

> > > I strongly agree with Tom that the current draft is an updat=
e to RFC

> > 7950.

> > > I also strongly disagree with the decision to omit RFC 2119 =
in a

> > standards

> > > track document. IMO RFC 2119 terms need to be used in normat=
ive text,

> > > especially when dealing with XPath and YANG compiler behavio=
r.

> > >

> >

> > RFC 8174:

> >

> >=C2=A0 =C2=A0 o=C2=A0 These words can be used as defined here, but=
 using them is not

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0required.=C2=A0 Specifically, normative=
 text does not require the use

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0of these key words.=C2=A0 They are used=
 for clarity and consistency

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0when that is what's wanted, but a l=
ot of normative text does not

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0use them and is still normative.

> >

> >

> So what?

> Existing YANG specifications use RFC 2119 terms.

> This draft uses those terms, just with lower-case.



Actually, section 5.1 XPath Context in the revised datastore draft

uses the same language as section 6.4.1 XPath Context in RFC 7950.=C2=A0 In=


fact, the text in the draft is copied (and adjusted) from RFC 7950.

=




/martin








--94eb2c14ae58ea55ec055966030e--


From nobody Sun Sep 17 13:35:06 2017
Return-Path: 
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 2EB8F132A89; Sun, 17 Sep 2017 13:35:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level: 
X-Spam-Status: No, score=-4.7 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=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=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 nFTw0Tfm3QoW; Sun, 17 Sep 2017 13:35:00 -0700 (PDT)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20106.outbound.protection.outlook.com [40.107.2.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E69BE132D8A; Sun, 17 Sep 2017 13:34: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=ghJY69GIAcGbuSSCOI3cY2fOeeKJ6x2lju5CBT0bmsA=; b=X1IBt0eOCeURea5F9wY+3IekXRFWyhI0TIfR94HETnK9BoQNNwpejgZeZ8SeIdm+BBil7cgktcSd+3PYuOGuKomuLk7VXv9YnFZebTk1f4d8np+TG4tzM248i20TmjcM7TunrZZye93SSQciX0nphmrEamiJXbCKd3QZohA5UDE=
Received: from pc6 (109.146.128.123) by HE1PR0701MB3002.eurprd07.prod.outlook.com (2603:10a6:3:4d::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Sun, 17 Sep 2017 20:34:56 +0000
Message-ID: <009e01d32ff4$345b4a00$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Juergen Schoenwaelder" 
Cc: "Lou Berger" , "netmod WG" , , 
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <000901d32e3e$883fa9c0$4001a8c0@gateway.2wire.net> <20170915170959.q5bfwoqoaqaq4o5b@elstar.local>
Date: Sun, 17 Sep 2017 21:21:07 +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: [109.146.128.123]
X-ClientProxiedBy: VI1PR0602CA0018.eurprd06.prod.outlook.com (2603:10a6:800:bc::28) To HE1PR0701MB3002.eurprd07.prod.outlook.com (2603:10a6:3:4d::8)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: c6f48943-0b77-4a72-7559-08d4fe0b8fab
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:HE1PR0701MB3002; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 3:OYfInOFGuPNs2zCA0RG/LdSC0yy8Nvr+uWuP5xP7YG0nm2e3mgbraQrpSM5VvphzGmufYBgtuigpfAPYql7qRY3QQYNe2zT6dpktKznjlSos/T66kwtYObr4DLLp7VUdbh4l4WfxioCDRpNP7bXQooutPoLARyVM/ziXUX8VY6SREWrOzNvyDJH+/+lZJzxdy9JOwF0Qd0KNWbeQk8HfW6Gmz6H6Esx5FufXXFuEWmOEIfIbGTtw8iAz6lNPjmFA; 25:3+Qmgkl5h6Kr7d4irpSCoijYpwTTR17oxsBL7T0DJ8F/df+q6jxjR17d18z05cTOadAFunYi1WAEZPmclbh8exZZKu7WM9nv/7X8a3kKSoPD+1sRUdPXkasafS3gX5otZo90SlqSuhAxd0FcnRrwPm0qMFZX690+naWJg7SIzGs9lSMUQJ/dynAowiMLWodGEI3gQJgD8IexKvGB5ZbD+RkFoYXoxZIaDJUSj0t28n56hDZdkZTjtB2IZDgGpUyKd/cJzqvISX6xihepZtsXTbgu7EXaxOr57ftDUqbvw1wE+FZibsXx/2PMpDaeV7vlIHhR+w4MtnH/xl3juwz2eg==; 31:D6JdSb82uYqazDJ6JHXAIHfRi4RSSuQ0AxgS298sPtrlSu3ZC4mzSJqmTDJHl6szZKt04duG+BMfcGUx2I0BskwSK1Qbe7QR38UzzcmOZ5rYlL1HVYTnMWiVEXMBxypHXlATI9/kDwHNvnl938IsbRUGCXJnHdRHfnMKQyyyE1Tpppp12jjEaccAccVdJmQYW3WK+fJST20KD+ImWR4XtxM2Uj2KU6/3P+ZKT7RvRrk=
X-MS-TrafficTypeDiagnostic: HE1PR0701MB3002:
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 20:RaWE14yPZ3UBAN12c/kf7xNnMm6LrUJ5MIxnxPueqyG3Ov1eRCSOnPJNNS1jLMyR1jmzcL4xQw6vtfAtNfqkfj/Hrzk+En2IXsM+C4U70eY+zwgb+dnFs9/EFuWki8iJp4bWSkI5mMkE6dH2wxlJJKnpCHOyQIKOrbGHs3042Djiajn6knRy6/Wva6NnK+hE1MIGkdGcHIes+feSl/VxSq8xnLyyazmHVFsVvvn4ol3sDNd5ptcP98YhFnft5InN; 4:TwA4bu+HG2G+LKjz37ie5Luizvzd+IA13/ogbS+6dQIWkVzgiXUCWXfNdWOiA4Wc5YqFvS22HNGCwXw1Y5fxt3/4DT9ND11lKc33RbFVXnYXe3TQfnUZYowQGv2/4lICidbDauh+eCcNacc0IS9ZNN5Xmx9ALkvynRZenvRjQJsBRB+d5zD0QuHpwUOQaHQmoBDA3Ky1vKYEh8U1sTTz9TkJ+bJ3D0TaZ0q9bitnrteuG7m2PFqqtg32g7XdqFWp
X-Exchange-Antispam-Report-Test: UriScan:;
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(61426038)(61427038)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR0701MB3002; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR0701MB3002; 
X-Forefront-PRVS: 0433DB2766
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(377454003)(13464003)(199003)(189002)(24454002)(2906002)(6916009)(116806002)(62236002)(84392002)(230700001)(86362001)(68736007)(478600001)(81686999)(6306002)(47776003)(50986999)(61296003)(54906002)(76176999)(1456003)(9686003)(8936002)(8676002)(97736004)(1556002)(81166006)(81156014)(101416001)(33646002)(110136004)(81816999)(44716002)(230783001)(229853002)(16526017)(6116002)(4326008)(53936002)(3846002)(6666003)(66066001)(4720700003)(6496005)(966005)(50466002)(6246003)(105586002)(14496001)(44736005)(305945005)(5660300001)(25786009)(106356001)(7736002)(23756003)(316002)(189998001)(6486002)(50226002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3002; 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; HE1PR0701MB3002; 23:XNk58AvPutdHz/lwCWiALR6GR7A7GlHc2ZeUD?= =?iso-8859-1?Q?a0F4xK2XyIZGp9HAlsa7AhZAk+cwsJaDE2O7MnAQxfpmuVuDnCLcyRuQIp?= =?iso-8859-1?Q?0GfWsGuxJnzmrozy1h1tAXh8w6ZUk7W3v9a+1u/bS5nyJhfQjsE33u/4KS?= =?iso-8859-1?Q?bgS8Pw/wbT8OtmLoy1rOtlJIfVFUzSSgq8UUYRBIO76orPK7+Lgo7G0DzR?= =?iso-8859-1?Q?QvoT1sXGNloEb6Z0XSLO5HJWE5cOzLPpUja7Lw2h7fCvtpq2PIPgPCoesI?= =?iso-8859-1?Q?jVrS5qG7XDmDyEkEj/3oBUlAlfU7MuqS55RoCHQ8NC6/vrwkiLYaoDG6PH?= =?iso-8859-1?Q?sRKP+pMRKY1f1B1ZD4VVGeMr+QeoW8KWD9dZjqnDw1NZq/op3U11EhgZsb?= =?iso-8859-1?Q?x6PdMBweIWjIww4C57ldNUAv5tT/G9mXzsHtkuUWlW+02Jca1M+ud64ISy?= =?iso-8859-1?Q?u1XzikpyzloO2DviBJpfXVXhDVmQh8CdcSZl6R0m6+ATg4njFmob5Q4rVX?= =?iso-8859-1?Q?4YzXHT+aIpZGsQYHaZMwxjFT5bNp2qrgvdUbaacs1HohfNCb37KirKGlLP?= =?iso-8859-1?Q?FHQnQFW754K2Zic9KnMzUor6AkU7rW8kcMjBnT4IN522d/r6wkFyyGSaOw?= =?iso-8859-1?Q?Mi9bbCiTKCtXJIgzSUvoWjXp0ifK3nfW3mnjNQIby3NaBQ31EXG99nphDv?= =?iso-8859-1?Q?ki+4iHQ15M5yEr8p8ahZt1Y9h/t0ZueQ9fqvcuLUdYQYS1mSY+qVoMipUm?= =?iso-8859-1?Q?cHery1TL/sC8uz36jXsh8IfXNnxdwNdRg5YGWmjB4+I0gUkkkleQafp9TK?= =?iso-8859-1?Q?CO+QBYuMkGpo6M0ePS5OIIAwDdyOlaFHwfcYejzilZ0VpX27lMjt7tCBv5?= =?iso-8859-1?Q?wCfL5Du1PCY9KUYYoVrxhPPilRo8ngU1QsPTnaW+hyxXNze78CyYpVxWy0?= =?iso-8859-1?Q?wumlT/hYBPxgT8X/zmG8FE8K5IdJmMOIu8IB27WLWtU3cs2ooGI4KK3EHH?= =?iso-8859-1?Q?yy/REfBOOp+CKsh5B5fvChfdqGVx4Z35qrmt7PLpclctQAXYyD3DnCi/Dh?= =?iso-8859-1?Q?pX0GugTTWs1vBIQ08z7MHunKRAR4c6hKrudlxVQdNHK9n3VSoz71aaGxQ9?= =?iso-8859-1?Q?y5rlRWoeCM5+x67X6ylCaTxMS54VctKRHETL8xC0aSCuIJMce2XqahpL3E?= =?iso-8859-1?Q?ixJy3UHG2nKNv9p0sYyrrnOfogl+tcOXIF8sQ56ixlA2RsNxnT45nA+HQm?= =?iso-8859-1?Q?kzDsSXEsQ9PPdQKi3IHN6xYknxET6xzF3nMZfcYGyGchEunsuT8NSzCkQ4?= =?iso-8859-1?Q?43aaQsCVpNC9+uDEEyxFlZZNFpxiAEzRm8lhyWeCeRcrDakkFNQwPjO+OQ?= =?iso-8859-1?Q?wygcqLGHQvNGsDfWoaaelO9d+OelCN3ART2SsU8iInPmzSkXfPSQ6i/IWb?= =?iso-8859-1?Q?1YLAffgYi0SarFVKNnVHTUBis3VS4/iwYTahfQLdrCgABclUwt05azf0Az?= =?iso-8859-1?Q?LddvCATB0IfS4vhfbbO6mFoawYIiOx8Zp51/Gc5qUyik3tk+1A8yrsO5at?= =?iso-8859-1?Q?2xWRYTFJfI/YSko8f0dFfKDORGmY=3D?=
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 6:StgLUer9eTdThyEUoNFtuR6zMgGvk+BNP+iU+u1YV/csQCTzuQtk1qomfu4dbwJ877TV33W143k1ClWFpmCKMAGnhNJL0DlioSztYNAh5J9DNyIOpO2fHPH2BbQM3xhimecf0GKguwqHCkCaghP0UCM2Sit5mEqjGNgn3PTHa2A026CH9ObDG31a3fC2GsfL+dn4U2kpb9pXY15uxxbl00yhaikUQY5d4DqLgGYxNtM3qKoiemQuStbqRoqJLrVD2OnxFzq8psuh984HbeVo0Axp26m9cq//UxbAIGRphKONEPmrdM06LeEx/Baf1qyyY7rpMrREQy0cQgZSb0ub0g==; 5:NZtLsDTa5iW9DMkKCnF7dMah+/3s0yl2XqsJRif/XKd96Br9SbEthdiLk5UqyahmAdDebhdwIB4iBR48rGDxg+DepgzedYK+Nfst9/AQPQ0oiDLkghi8jDjrQ8YwZ2gR22vKBO/kg4eDPeWqOflqtg==; 24:2dPmSptRlC9W8Al/OlH8zc+RGRnOMkFX11WZBPW+6BwXM4I+0+SJTALyGyAWREtK/oneE0ORgW2dDXuJKPRNSZojmDMlJQwO8s5c6r7qUhI=; 7:Vr7jGrnQvqOWw+7S96anzf5LBsDjCOP+SkvaTrG1GtRcuRcnD9hbEGFlrTroIZwAyv4gMHRGsCm+C/4KYoSiQRfnhVOz5U8srzykTvsAMxm4LVQhdnb/hbHbcnIA0G8flmSt0S0oTvUU99V7ctWjZsDJdQIFlsbEp4MeMufB7iJdolC0oi0fDPWJ+fv4rRz+gPFyApQEY/eY2KG3xHUbbeUknQbiNWZzrx7v3xuUUI8=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Sep 2017 20:34:56.7368 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3002
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 inactive
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Sep 2017 20:35:05 -0000

----- Original Message -----
From: "Juergen Schoenwaelder" 
Sent: Friday, September 15, 2017 6:09 PM


> Two comments:
>
> - Obviously, inactive can be in  and I would not rule out
>   that inactive configuration can be in any other or future
>   configuration datastores.
>
> - Whether protocols support inactive or not does not belong into a
>   definition of what inactive configuration is. The same for backwards
>   compatibility considerations etc.
>
> So if we define inactive configuration, the definition should be
> something like this:
>
> * inactive configuration: Configuration held in a configuration
>   datastore that is marked to be inactive. Inactive configuration is
>   ignored during validation and never applied and actively used by
>   a device.
>
> Yes, we should use 'inactive configuration' everywhere to be
consistent.

Juergen

Yes, your definition is better than mine; let's add it.

Tom Petch

> /js
>
> On Fri, Sep 15, 2017 at 05:20:15PM +0100, t.petch wrote:
> > Inactive appears a dozen times but is not defined, except in the
course
> > of those appearances it effectively is, but is sometimes 'inactive',
> > sometimes 'inactive configuration', sometimes 'inactive data'.
> >
> > I would find it clearer if the term was used consistently and if
there
> > was an explicit definition amongst the other definitions in section
2
> > such as
> >
> > inactve configuration: Configuration that is present in 
which
> > is not in use by the device and which plays no part in validation.
It
> > cannot appear in any other datastore.  The protocols that are
currently
> > standardised do not support inactive configuration but a number of
> > proprietary protocols do. Inactive configuration is only exposed to
> > clients that indicate support for inactive configuration; clients
not
> > indicating support for  inactive configuration receive the contents
of
> >  with the inactive configuration removed.
> >
> > This would put a stake in the ground for as and when the concept is
> > standardised and may reduce the proliferation of the term with
multiple
> > meanings.
> >
> > Tom Petch
> >
> >
> > ----- Original Message -----
> > From: "Lou Berger" 
> > Sent: Friday, September 01, 2017 10:02 PM
> >
> > > This starts a two week working group last call on
> > > draft-ietf-netmod-revised-datastores-04.
> > >
> > > The working group last call ends on September 17.
> > > Please send your comments to the netmod mailing list.
> > >
> > > Positive comments, e.g., "I've reviewed this document and
> > > believe it is ready for publication", are welcome!
> > > This is useful and important, even from authors.
> > >
> > > Thank you,
> > > Netmod Chairs
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         


From nobody Sun Sep 17 13:35:13 2017
Return-Path: 
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 2F24A13336A; Sun, 17 Sep 2017 13:35:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level: 
X-Spam-Status: No, score=-4.7 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=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=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 IZ74nz77Jvk4; Sun, 17 Sep 2017 13:35:02 -0700 (PDT)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20106.outbound.protection.outlook.com [40.107.2.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B005A13334E; Sun, 17 Sep 2017 13:35:00 -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=ElgV+s8c55rfRlB55HaFkXU+JCGzixF2sAMoOHfv0Pc=; b=ORBc4eZxXGv9oAO2A4wcXwqQfLfuJLIf/S0p0ySCeHIkhkSHkvq0jPAOEY0yeK4SHm7hNE96aTSNnteu838rNGcALuTAMM0p5ay6gEF39o3j2rtgr2fu2bWxlTdtsmKzvJfi67YlZXtv/Qb3Okzggp8QhQHMZ1L12giHOxxZTEw=
Received: from pc6 (109.146.128.123) by HE1PR0701MB3002.eurprd07.prod.outlook.com (2603:10a6:3:4d::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Sun, 17 Sep 2017 20:34:57 +0000
Message-ID: <009f01d32ff4$352ddc40$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: , "Martin Bjorklund" 
Cc: "Juergen Schoenwaelder" , , , , 
References: <20170916072403.xp37556z6g7b42gr@elstar.local> <20170917.154115.791964858062115650.mbj@tail-f.com>
Date: Sun, 17 Sep 2017 21:33:13 +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: [109.146.128.123]
X-ClientProxiedBy: VI1PR0602CA0018.eurprd06.prod.outlook.com (2603:10a6:800:bc::28) To HE1PR0701MB3002.eurprd07.prod.outlook.com (2603:10a6:3:4d::8)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 8341f15e-5459-450c-450e-08d4fe0b907d
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:HE1PR0701MB3002; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 3:1Ia+RRm0gOFsb7y0weNhBWrmHuawKixCHRSn7FxCc5juDDAfyaR6hesS+qA5O55TiEPRdHosvcx6bPCOd4IWEgV0wjJDOTbcDQe1l/I6dP7Z71LJeZew+5rw0tx0GOJASL4MJycLFsdtjOUdgPYPgJzL+/Tzop5YYE6pKCL7J71nVYEwKOugkxHF1SVtFygktxMGtr9ZE8pQi3vK/f7fdGav1PdPHrP3M9Vzcl2KlGgwgj78eVxtjJl/1RU5bQ9Z; 25:KQfkfL90RmwU3km8K9fqMzzcohYEmj3qSibxhs4H3kaX1qDrcn7H3869g8JR2DLONmz98ergoYpDSLgLnwDFHNCk8MJ8XzFixmSYiXNZY1sLqcO6QZMCsE4xOSjESWWECsB6qdRyF/1iShFcVSBx1i6v1/qiletsX71LwNjdZ2S46xrkCZ6gqxF8C6pDl38cfKakDQWxZCi+b5yUrNDPhgHAYwBW/qWnjPpnj1OwVn6SulaArUIyRyiN1/3gzwjypehqeOOxqdtiay9PmqUh9OqmjUDeLKezrlpkZySWQYcUhy/SKVS41aJ0EqPUaws5z7w4w9NHv0530TNQsSDMYw==; 31:iBqVlDiBW56EjHviN1Rg8TuuAnfwYJeo0IEmmrwYA5Fvy0ektYlN6ejf7LYlkUTXTnrM19Cf/Uqzszkn69JJTtYCTDHQQI9kIVQ1mD5t42HDeoku0szLs+F6o7GhPkFsJ8wULG84Ri9b5GtHrcxaZjszNMwF6oNnQcXwYWjxY4bYB/CYyGSv2zkhhTAbhgawZr0JcQZtZNarJ8HF37psGiBfmLE03FowIjGXb8B2xxs=
X-MS-TrafficTypeDiagnostic: HE1PR0701MB3002:
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 20:E9Yr9AiWU29tettE4I8NY6wEcv7XtBnFslYVZvwiqO7m/2D1ivT1nLMoWihoHa3wXPA4ZPvyOJTNTz+xAY+i8qKql/gOTD5lSRfzgcfVXGNEmC3b27+fDeaRXBInRMRp+KdXBDdrJRU2KFKYZH39tPXg+TLFMutnIpl13x+15CbTvqB4u9WnMCvPf4uGJechhmoipacVApkFi4qgzrkD48jlen93v/qmj54I7Iy+OmshowoxZwzuDnqwR/W2pkZX; 4:M4JzLicjYl+bMwBUfpc1p5Ru/uJT3aCCYdlvXRaDQ2ZPNc1JxgV8M7YbBrWP9g1QwgLwK9FdQZLXOpXcrb7Wqjmc7Qc//PGnbGnWsKO/iYEKrFdcsvH7cebl+j7usbSp/nENC8sab4dTZ9pjrw0ZcP/FCkAIi/NewM5vOOe/iFN9mCyHSm9wiFtMucoF+utnA7dQ2Nb9POlx32KGM5soqZ9fT9/beiGHGl/t4ORV2+9JP8mfq3P1RcZSUv5sTITxIsjp9MssIDbVCu7L+/rhYg2RV665mY6tgtGTFIqKxbrU6icg0GoqO2OXPpRp0nRJwiP9ZnzYn/Hnkj34PPpWhw==
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(788757137089);
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(61426038)(61427038)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR0701MB3002; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR0701MB3002; 
X-Forefront-PRVS: 0433DB2766
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(377454003)(13464003)(199003)(189002)(24454002)(2906002)(116806002)(62236002)(84392002)(230700001)(86362001)(68736007)(478600001)(81686999)(47776003)(50986999)(61296003)(54906002)(76176999)(1456003)(9686003)(8936002)(8676002)(97736004)(1556002)(81166006)(81156014)(101416001)(33646002)(93886005)(81816999)(44716002)(230783001)(229853002)(16526017)(6116002)(4326008)(53936002)(3846002)(6666003)(66066001)(4720700003)(6496005)(50466002)(6246003)(105586002)(14496001)(44736005)(305945005)(5660300001)(25786009)(106356001)(7736002)(23756003)(316002)(189998001)(6486002)(15650500001)(50226002)(53546010)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3002; 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; HE1PR0701MB3002; 23:LtKV+po4GhBSrcXhV3Dx0nxxvzbXtS3Uq4wfB?= =?iso-8859-1?Q?PATNuRzt5tycEv9wc5eaJJ3txETwgbt54qk9wxv9l9ATfAq24xEwhtuRCV?= =?iso-8859-1?Q?oFGl4s27iq33bq7QrAZPQaaP0DC9o+jVRg6cOVjtiEUYza/zdzPLjaKxrT?= =?iso-8859-1?Q?W0eo9kSnxawPguOOSW36XQUMjkmyvtarGx2lMwbmid0mIfuNoIl9BEcom9?= =?iso-8859-1?Q?cKoINmbYeshaBMRbp2rt6OyWHxBE3w7kidbE+TxCyTHTrNoS0fa9tGWmnW?= =?iso-8859-1?Q?YKwzD3RX6IKRPfx6Qq0vRmk4TpNJZZIuMXtJW8sBzNJaC9umfwr+fnrJod?= =?iso-8859-1?Q?SaD40bS2BVg7sYqL+0thTOunjyaK8enz54A4F/AvLewxEqajIfQAgPPnKZ?= =?iso-8859-1?Q?FAmTX+PbUSW8i92C5gZP3OON6KyxzF/23j0KTRrFGp7aAKztwSUq8R47zX?= =?iso-8859-1?Q?0o3y3jgOYMcNFtBgCfeuBOVaE5B7brIlVHBhA6LrtKSr864wNl6g0UlQ1E?= =?iso-8859-1?Q?2AAqlM2oCB2sffgkrE2qdD9X6DR+xf3FKh+rSokrLUTVKMUUFywBCi4NZ2?= =?iso-8859-1?Q?Sv3yMyhbtsVv5v41VYT1u5XMU0EqQfcXTDx9tczDwumntDvfoaXm3VMoud?= =?iso-8859-1?Q?/QpWLBUzNPaepEWpOTvM/zIQgyF28Zz4wE7KXgrGxkZSmFYe8WeXIqC7mN?= =?iso-8859-1?Q?s9attQ8spePk/5mp/unUuJs95EAJo3ohHKSjNg/V0HJ1emFQf9TJV11X3r?= =?iso-8859-1?Q?GNtAzniOMav2U0O7F5hcrSRo+/mET2Gx+pSakqm/N9xznGC6Q4RpqpTQ+m?= =?iso-8859-1?Q?m4sH43I8KDf75M4EdEdFzaOojRLXLdRj/++eMwXsUyrdWiynAAhgAfdZGV?= =?iso-8859-1?Q?j+TIU9TuccHmhvykiguJRDm0fFoBMV6P1G929oy0qO9lbd9spaETHvF7+G?= =?iso-8859-1?Q?dA5n6LxbyCI15Xy5DCcx1fHYuA3LrGYcjbGcWrMDbUjjdqIkK3AwOu5exU?= =?iso-8859-1?Q?vuHbPe7HoE3seChTsE2IfvWXwBuA3nl0Li/pGVDBy9lat74S8H1PyghsZd?= =?iso-8859-1?Q?0vWDmKfvMl2F9Th1zzUwkd/FBQgROHirFjLYI/6Z53qe5pAyOgWRwZ1FXL?= =?iso-8859-1?Q?VaDSknPbn5mbNVm1oe0Cz3a71MCNp3g64tN27PVOYvYjpqWJxJzZmfwmTF?= =?iso-8859-1?Q?2KREiKxiEj6lcy6P+KC9TCPryWczJP4xQOgyGzxWOiFTxjKidrvdFThAYZ?= =?iso-8859-1?Q?6+9DdvuTwdYKbTvPr7V+SG0UlXxwR9Q2Uya3Aol928QlVs+3fKduHjvH8i?= =?iso-8859-1?Q?LvUbMxfv05LF0/UtE62ylkpsHWxWBRnlwwMv9iSDpl2FfYpYoegPuIbiSd?= =?iso-8859-1?Q?N/+Qx2ZnlZy7q6vF6oVywn6u8QVpmOxUYaKu1Dtb+8MwlewQzene7rECrM?= =?iso-8859-1?Q?2fxBvFpsZ/X8DmQUhzwAWDLEnrFc/KorYiAnQNtvkVWsNxsbTu7afXwLtc?= =?iso-8859-1?Q?J0tQSRXaybRRgvc/vWImkYpTwYlH6oHR4+XPrgBYYyDbck9A7N3+xrURbt?= =?iso-8859-1?Q?7t5PXYQ9gEEl8y6jFnySP8+UgD1U=3D?=
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 6:sed4Y0JIsy7BSg/PRY8P2q8LI57wFzCMHz6ZobFQ2XQrFWYFZIn4dYX7Xkn396tTpFqLe5eN3jUPfcDozWE7V7PzTC+Ng4RX9SNcM793i3RLHbdnlB9cHeJhP6GF9cqe3N5SRyuYyrBW7PafiwACVolk93aTnXEazxpDytC5h8ACu04zC75nMLf+HKpFPGGfT8qmVx3ORQB5dzTDlv59+fZIU/dR7Dcoqlugc4ncA1BhVtP+5rjRx63LOCFc4FmpYobLefL0sO9pkZVrcHfU3PMHHOD9LrOGh5mgBQo1/cZJcLbTguo5jKepZwmij51znnzsBSDZy4a+hH+59B6Vmg==; 5:HteQnCKwzTsgsPOJD0TBwTjwAEY5z+tT4U8s6yXEND4bLTdQD02CQpWLc8l4XU78nM4guNXpL2vnWMuBnH+PK8cjuuM4MLsb2QN2tY94yCqTa0U3XfWnWp1EhrvJqoSrvGXDuprf0KhDNdMMl7pMRQ==; 24:jOw51qLUglXKxR8sJgBPrfql4UforsdVxtS4/NMk4sCSK4/alcEoijYo/NBDOjX1vuifz64tVxw46vfovmZ34EfYqGrw/j4PbM6c0Bq7f/U=; 7:pxwD4qPFzjxxCQNI6FuyhtQtsQx9CKaF5UP6WQRsemnmRstjP0vK+paroUxBx+RWf/zcqIYoj1L9Hri/dpoZpOxzvmD2NanXBcN8M8/xb9OeGbfP3KfBADS8SW3xaJLZvOxi8Sb3Lar9tN9zfIxoo4U+cQlL+vfdAznzimAMCEop3wkcbez6NN+hkjbVfUZ4GA6EnDg681tE1KNKIldOxmNXcDlH2qrRuN3vZU1QZMk=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Sep 2017 20:34:57.9087 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3002
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 updates
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Sep 2017 20:35:07 -0000

----- Original Message -----
From: "Martin Bjorklund" 
Sent: Sunday, September 17, 2017 2:41 PM

> Andy Bierman  wrote:
> > On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder <
> > j.schoenwaelder@jacobs-university.de> wrote:
> >
> > > On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
> > > > Hi,
> > > >
> > > > I strongly agree with Tom that the current draft is an update to
RFC
> > > 7950.
> > > > I also strongly disagree with the decision to omit RFC 2119 in a
> > > standards
> > > > track document. IMO RFC 2119 terms need to be used in normative
text,
> > > > especially when dealing with XPath and YANG compiler behavior.
> > > >
> > >
> > > RFC 8174:
> > >
> > >    o  These words can be used as defined here, but using them is
not
> > >       required.  Specifically, normative text does not require the
use
> > >       of these key words.  They are used for clarity and
consistency
> > >       when that is what's wanted, but a lot of normative text does
not
> > >       use them and is still normative.
> > >
> > >
> > So what?
> > Existing YANG specifications use RFC 2119 terms.
> > This draft uses those terms, just with lower-case.
>
> Actually, section 5.1 XPath Context in the revised datastore draft
> uses the same language as section 6.4.1 XPath Context in RFC 7950.  In
> fact, the text in the draft is copied (and adjusted) from RFC 7950.

Martin

'Adjusted' might be seen as a weasel word:-)

   If the XPath expression is defined in a substatement to a
      "notification" statement, the accessible tree is the notification
      instance, all state data in the server, and the running
      configuration datastore.

becomes

If the XPath expression is defined in a substatement to a
      "notification" statement, the accessible tree is the notification
      instance and all operational state in the server.

Goodbye  (well, running configuration in RFC7950).  Is it a
material difference? - it will take me a while to work that one out.

I focussed on the XPath rules because they seemed the clearest case, but
updating the definitions, and saying this section will replace the
definitions in [RFC6241] and [RFC7950] when these documents are revised
seems .... well, like an Erratum held for Update i.e. another Updates.

Tom Petch


> /martin


From nobody Sun Sep 17 19:58:52 2017
Return-Path: 
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 BB970126B6E; Sun, 17 Sep 2017 19:58:50 -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 XD6ZEogb5NFo; Sun, 17 Sep 2017 19:58:48 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01CC013234B; Sun, 17 Sep 2017 19:58:47 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DVQ61958; Mon, 18 Sep 2017 02:58:45 +0000 (GMT)
Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 18 Sep 2017 03:58:44 +0100
Received: from DGGEML507-MBX.china.huawei.com ([169.254.2.79]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0301.000; Mon, 18 Sep 2017 10:58:40 +0800
From: Jiangyuanlong 
To: Alex Campbell , "netmod@ietf.org" 
CC: "tictoc@ietf.org" 
Thread-Topic: WGLC for draft-ietf-tictoc-1588v2-yang
Thread-Index: AQHTLMS9I02w6VlOokuuR++M6yrZg6K1JzgQgAA51/2ABIXVAA==
Date: Mon, 18 Sep 2017 02:58:40 +0000
Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5B9661@dggeml507-mbx.china.huawei.com>
References: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5A2CBD@dggeml507-mbx.china.huawei.com> <1505453243090.91370@Aviatnet.com>
In-Reply-To: <1505453243090.91370@Aviatnet.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.74.202.215]
Content-Type: text/plain; charset="utf-7"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.59BF3666.0023, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.2.79, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 96097b3aeb14708438b4b2c58c5d4f06
Archived-At: 
Subject: Re: [netmod] WGLC for draft-ietf-tictoc-1588v2-yang
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Sep 2017 02:58:51 -0000

Dear Alex,

Thanks a lot for your prompt review, most of your suggestions will be refle=
cted in the next revision. Please see my further comments inline (prefixed =
with JY).

Cheers,
Yuanlong

-----Original Message-----
From: Alex Campbell +AFs-mailto:Alex.Campbell+AEA-Aviatnet.com+AF0-=20
Sent: Friday, September 15, 2017 1:27 PM
To: Jiangyuanlong+ADs- netmod+AEA-ietf.org
Cc: tictoc+AEA-ietf.org
Subject: Re: WGLC for draft-ietf-tictoc-1588v2-yang

Hi,
I've reviewed the draft and found the following issues.

+ACo- YANG enumeration values are conventionally lowercase, but the delay-m=
echanism-enumeration and port-state-enumeration types in the draft have upp=
ercase values.
+ACo- Similarly, hyphens should be used rather than underscores (pre-master=
 instead of PRE+AF8-MASTER)
+ACo- number-ports doesn't read naturally in English+ADs- I suggest renamin=
g it to number-of-ports.
+ACo- The description of port-ds-list contains a typo - +ACI-memer+ACI- ins=
tead of +ACI-member+ACI-.
JY: All suggestions above are accepted.

+ACo- There's no need to have groupings that are only used once (such as pa=
rent-ds-entry, current-ds-entry, default-ds-entry, transparent-clock-defaul=
t-ds-entry, port-ds-entry, transparent-clock-default-ds-entry, and so on) u=
nless this is for futureproofing or some other reason I'm not aware of.
JY: This grouping structure was used for readability of the main module, ot=
herwise, a single parent container will include tens of pages of YANG codes=
.=20
Turning some sub-containers into groupings will not change the codes in com=
piling for computers, but may reduce the complexity in reading as a layman+=
ADs-)
I know this is a very subjective judgment for myself, so I would like to se=
e more opinions in the WG before restructuring the module.

+ACo- Is it necessary to include -ds in the name of every leaf, container a=
nd grouping?
JY: As explained in Rodney's previous email.

Note I'm not familiar with IEEE 1588, apart from a brief look through it ju=
st now.

Alex


+AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF=
8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8-
From: netmod +ADw-netmod-bounces+AEA-ietf.org+AD4- on behalf of Jiangyuanlo=
ng +ADw-jiangyuanlong+AEA-huawei.com+AD4-
Sent: Friday, 15 September 2017 1:42 p.m.
To: netmod+AEA-ietf.org
Cc: tictoc+AEA-ietf.org
Subject: +AFs-netmod+AF0- FW: WGLC for draft-ietf-tictoc-1588v2-yang

Hi netmoders,

This draft does not tackle the general YANG problem, but provide a generic =
time synchronization module of 1588.
Some of you may have interests in time synchronization, some definitely not=
. But as experts in YANG, could you please have a review of this YANG modul=
e and give an expert opinion?

Thanks,
Yuanlong

-----Original Message-----
From: TICTOC +AFs-mailto:tictoc-bounces+AEA-ietf.org+AF0- On Behalf Of Kare=
n O'Donoghue
Sent: Thursday, September 14, 2017 3:16 AM
To: tictoc+AEA-ietf.org
Cc: ntp+AEA-ietf.org
Subject: +AFs-TICTOC+AF0- WGLC for draft-ietf-tictoc-1588v2-yang

Folks,

This message begins a 2 week working group last call (WGLC) for the followi=
ng document:

YANG Data Model for IEEE 1588v2
https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588v2-yang/

Please review the referenced document and send any comments to the mailing =
list including your assessment of whether this document is mature enough to=
 proceed to the IESG. Please note that these messages of support for progre=
ssion to the mailing list are important and will be used to determine WG co=
nsensus to proceed.

Please send all comments in by Thursday 28 September 2017.

Thank you+ACE-
Karen
+AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF=
8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw-
TICTOC mailing list
TICTOC+AEA-ietf.org
https://www.ietf.org/mailman/listinfo/tictoc

+AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF=
8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw-
netmod mailing list
netmod+AEA-ietf.org
https://www.ietf.org/mailman/listinfo/netmod


From nobody Sun Sep 17 20:16:56 2017
Return-Path: 
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 71AD313234B; Sun, 17 Sep 2017 20:16:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 GB-NUCBQU1De; Sun, 17 Sep 2017 20:16:52 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2998126B71; Sun, 17 Sep 2017 20:16:51 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DOT58829; Mon, 18 Sep 2017 03:16:49 +0000 (GMT)
Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 18 Sep 2017 04:16:48 +0100
Received: from DGGEML507-MBX.china.huawei.com ([169.254.2.79]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0301.000; Mon, 18 Sep 2017 11:16:42 +0800
From: Jiangyuanlong 
To: Benoit Claise , "netmod@ietf.org" , Mehmet 
CC: "tictoc@ietf.org" 
Thread-Topic: [netmod] FW: WGLC for draft-ietf-tictoc-1588v2-yang
Thread-Index: AQHTLMS9I02w6VlOokuuR++M6yrZg6K1JzgQgAA6+gCABJh5IA==
Date: Mon, 18 Sep 2017 03:16:41 +0000
Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5BA686@dggeml507-mbx.china.huawei.com>
References: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5A2CBD@dggeml507-mbx.china.huawei.com> <331b6b30-8089-5411-9a33-88014b7d66c9@cisco.com>
In-Reply-To: <331b6b30-8089-5411-9a33-88014b7d66c9@cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.74.202.215]
Content-Type: multipart/alternative; boundary="_000_3B0A1BED22CAD649A1B3E97BE5DDD68BBB5BA686dggeml507mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.59BF3AA2.0059, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.2.79, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: d8cc9bf0f8c7bf2aaec002eb6d5e1ff4
Archived-At: 
Subject: Re: [netmod] FW: WGLC for draft-ietf-tictoc-1588v2-yang
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Sep 2017 03:16:54 -0000

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

RGVhciBCZW5vaXQsDQoNClRoYW5rIHlvdSBtdWNoIGZvciB0aGUgaW5zdHJ1Y3Rpb24gYW5kIHRo
ZSBleHBsYW5hdGlvbi4NClRoZXJlIGFyZSBlcnJvcnMgc2hvd24gaW4gaHR0cHM6Ly9kYXRhdHJh
Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10aWN0b2MtMTU4OHYyLXlhbmcvP2luY2x1ZGVf
dGV4dD0xLCBidXQgaXQgcGFzc2VzIHZhbGlkYXRpb24gYnkgaHR0cDovL3d3dy55YW5ndmFsaWRh
dG9yLmNvbS9kcmFmdC12YWxpZGF0b3IuIEl0IHNlZW1zIGRpZmZlcmVudCB2ZXJzaW9ucyBvZiBw
eWFuZyB3ZXJlIHVzZWQgYW5kIHRoZSByZXN1bHRzIHByb3ZpZGVkIGJ5IG91ciBvZmZpY2lhbCBz
aXRlIGFyZSBpbmNvbnNpc3RlbnQgbm93Lg0KDQpCZXN0IHJlZ2FyZHMsDQpZdWFubG9uZw0KDQpG
cm9tOiBCZW5vaXQgQ2xhaXNlIFttYWlsdG86YmNsYWlzZUBjaXNjby5jb21dDQpTZW50OiBGcmlk
YXksIFNlcHRlbWJlciAxNSwgMjAxNyA4OjQ4IFBNDQpUbzogSmlhbmd5dWFubG9uZzsgbmV0bW9k
QGlldGYub3JnOyBNZWhtZXQNCkNjOiB0aWN0b2NAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbmV0
bW9kXSBGVzogV0dMQyBmb3IgZHJhZnQtaWV0Zi10aWN0b2MtMTU4OHYyLXlhbmcNCg0KSGkgWXVh
bm9uZywNCg0KVGhlcmUgaXMgcHlhbmcgZXJyb3IuDQpodHRwOi8vd3d3LmNsYWlzZS5iZS9JRVRG
WUFOR1BhZ2VDb21waWxhdGlvbi5odG1sDQppZXRmLXB0cC1kYXRhc2V0QDIwMTctMDQtMjAueWFu
ZzoyOTQ8bWFpbHRvOmlldGYtcHRwLWRhdGFzZXRAMjAxNy0wNC0yMC55YW5nOjI5ND46IGVycm9y
OiB0aGUgdmFsdWUgIjB4RkZGRiIgZG9lcyBub3QgbWF0Y2ggaXRzIGJhc2UgdHlwZSAtIG5vdCBh
biBpbnRlZ2VyDQoNCkhvd2V2ZXIsIHRoaXMgaXMgYSBweWFuZyBwcm9ibGVtLiBTZWUgaHR0cHM6
Ly9naXRodWIuY29tL21iajQ2NjgvcHlhbmcvaXNzdWVzLzMyOQ0KDQpNZWhtZXQsIGNhbiB5b3Ug
cGxlYXNlIGEgWUFORyBkb2N0b3IuIFRoZSBZQU5HIGRvY3RvciByZXZpZXcgaXMgbm9ybWFsbHkg
ZG9uZSBkdXJpbmcgSUVURiBMQywgYnV0IG5vdGhpbmcgcHJldmVudHMgYW4gZWFybHkgcmV2aWV3
Lg0KDQpSZWdhcmRzLCBCZW5vaXQNCg0KSGkgbmV0bW9kZXJzLA0KDQoNCg0KVGhpcyBkcmFmdCBk
b2VzIG5vdCB0YWNrbGUgdGhlIGdlbmVyYWwgWUFORyBwcm9ibGVtLCBidXQgcHJvdmlkZSBhIGdl
bmVyaWMgdGltZSBzeW5jaHJvbml6YXRpb24gbW9kdWxlIG9mIDE1ODguDQoNClNvbWUgb2YgeW91
IG1heSBoYXZlIGludGVyZXN0cyBpbiB0aW1lIHN5bmNocm9uaXphdGlvbiwgc29tZSBkZWZpbml0
ZWx5IG5vdC4gQnV0IGFzIGV4cGVydHMgaW4gWUFORywgY291bGQgeW91IHBsZWFzZSBoYXZlIGEg
cmV2aWV3IG9mIHRoaXMgWUFORyBtb2R1bGUgYW5kIGdpdmUgYW4gZXhwZXJ0IG9waW5pb24/DQoN
Cg0KDQpUaGFua3MsDQoNCll1YW5sb25nDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LQ0KDQpGcm9tOiBUSUNUT0MgW21haWx0bzp0aWN0b2MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo
YWxmIE9mIEthcmVuIE8nRG9ub2dodWUNCg0KU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAxNCwg
MjAxNyAzOjE2IEFNDQoNClRvOiB0aWN0b2NAaWV0Zi5vcmc8bWFpbHRvOnRpY3RvY0BpZXRmLm9y
Zz4NCg0KQ2M6IG50cEBpZXRmLm9yZzxtYWlsdG86bnRwQGlldGYub3JnPg0KDQpTdWJqZWN0OiBb
VElDVE9DXSBXR0xDIGZvciBkcmFmdC1pZXRmLXRpY3RvYy0xNTg4djIteWFuZw0KDQoNCg0KRm9s
a3MsDQoNCg0KDQpUaGlzIG1lc3NhZ2UgYmVnaW5zIGEgMiB3ZWVrIHdvcmtpbmcgZ3JvdXAgbGFz
dCBjYWxsIChXR0xDKSBmb3IgdGhlIGZvbGxvd2luZyBkb2N1bWVudDoNCg0KDQoNCllBTkcgRGF0
YSBNb2RlbCBmb3IgSUVFRSAxNTg4djINCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k
b2MvZHJhZnQtaWV0Zi10aWN0b2MtMTU4OHYyLXlhbmcvDQoNCg0KDQpQbGVhc2UgcmV2aWV3IHRo
ZSByZWZlcmVuY2VkIGRvY3VtZW50IGFuZCBzZW5kIGFueSBjb21tZW50cyB0byB0aGUgbWFpbGlu
ZyBsaXN0IGluY2x1ZGluZyB5b3VyIGFzc2Vzc21lbnQgb2Ygd2hldGhlciB0aGlzIGRvY3VtZW50
IGlzIG1hdHVyZSBlbm91Z2ggdG8gcHJvY2VlZCB0byB0aGUgSUVTRy4gUGxlYXNlIG5vdGUgdGhh
dCB0aGVzZSBtZXNzYWdlcyBvZiBzdXBwb3J0IGZvciBwcm9ncmVzc2lvbiB0byB0aGUgbWFpbGlu
ZyBsaXN0IGFyZSBpbXBvcnRhbnQgYW5kIHdpbGwgYmUgdXNlZCB0byBkZXRlcm1pbmUgV0cgY29u
c2Vuc3VzIHRvIHByb2NlZWQuDQoNCg0KDQpQbGVhc2Ugc2VuZCBhbGwgY29tbWVudHMgaW4gYnkg
VGh1cnNkYXkgMjggU2VwdGVtYmVyIDIwMTcuDQoNCg0KDQpUaGFuayB5b3UhDQoNCkthcmVuDQoN
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClRJQ1RP
QyBtYWlsaW5nIGxpc3QNCg0KVElDVE9DQGlldGYub3JnPG1haWx0bzpUSUNUT0NAaWV0Zi5vcmc+
DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGljdG9jDQoNCg0KDQpf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpuZXRtb2Qg
bWFpbGluZyBsaXN0DQoNCm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0K
DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQouDQoNCg0K
DQo=

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v
c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc
QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp
bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt
YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K
CWZvbnQtZmFtaWx5OuWui+S9kzsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlw
ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj
b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk
DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0
aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls
ZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzsN
Cgljb2xvcjpibGFjazt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0
YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi5om55rOo5qGG
5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv
bnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bh
bi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJ
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8
jyI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkNo
YXINCgl7bXNvLXN0eWxlLW5hbWU6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltc28tc3R5bGUt
cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms65om55rOo5qGG5paH5pysOw0KCWZvbnQtZmFt
aWx5OuWui+S9kzsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5
bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy
aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6
ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7
c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBw
dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+
PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz
cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4
bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg
ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N
Cjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1
cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5E
ZWFyIEJlbm9pdCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmsgeW91
IG11Y2ggZm9yIHRoZSBpbnN0cnVjdGlvbiBhbmQgdGhlIGV4cGxhbmF0aW9uLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlcmUgYXJlIGVycm9ycyBzaG93biBp
bg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10
aWN0b2MtMTU4OHYyLXlhbmcvP2luY2x1ZGVfdGV4dD0xIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIu
aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdGljdG9jLTE1ODh2Mi15YW5nLz9pbmNsdWRlX3RleHQ9
MTwvYT4sIGJ1dCBpdCBwYXNzZXMgdmFsaWRhdGlvbiBieQ0KPGEgaHJlZj0iaHR0cDovL3d3dy55
YW5ndmFsaWRhdG9yLmNvbS9kcmFmdC12YWxpZGF0b3IiPmh0dHA6Ly93d3cueWFuZ3ZhbGlkYXRv
ci5jb20vZHJhZnQtdmFsaWRhdG9yPC9hPi4gSXQgc2VlbXMgZGlmZmVyZW50IHZlcnNpb25zIG9m
IHB5YW5nIHdlcmUgdXNlZCBhbmQgdGhlIHJlc3VsdHMgcHJvdmlkZWQgYnkgb3VyIG9mZmljaWFs
IHNpdGUgYXJlIGluY29uc2lzdGVudCBub3cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPll1YW5sb25nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy
Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj
bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo
b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IEJlbm9p
dCBDbGFpc2UgW21haWx0bzpiY2xhaXNlQGNpc2NvLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBG
cmlkYXksIFNlcHRlbWJlciAxNSwgMjAxNyA4OjQ4IFBNPGJyPg0KPGI+VG86PC9iPiBKaWFuZ3l1
YW5sb25nOyBuZXRtb2RAaWV0Zi5vcmc7IE1laG1ldDxicj4NCjxiPkNjOjwvYj4gdGljdG9jQGll
dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0bW9kXSBGVzogV0dMQyBmb3IgZHJh
ZnQtaWV0Zi10aWN0b2MtMTU4OHYyLXlhbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJFTi1VUyI+SGkgWXVhbm9uZyw8YnI+DQo8YnI+DQpUaGVyZSBpcyBweWFuZyBlcnJvci48
YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmNsYWlzZS5iZS9JRVRGWUFOR1BhZ2VDb21waWxhdGlv
bi5odG1sIj5odHRwOi8vd3d3LmNsYWlzZS5iZS9JRVRGWUFOR1BhZ2VDb21waWxhdGlvbi5odG1s
PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUi
IGJvcmRlcj0iMSIgY2VsbHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJw
YWRkaW5nOjMuMHB0IDMuMHB0IDMuMHB0IDMuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJtYWlsdG86aWV0Zi1wdHAtZGF0YXNldEAyMDE3LTA0
LTIwLnlhbmc6Mjk0Ij5pZXRmLXB0cC1kYXRhc2V0QDIwMTctMDQtMjAueWFuZzoyOTQ8L2E+OiBl
cnJvcjogdGhlIHZhbHVlICZxdW90OzB4RkZGRiZxdW90OyBkb2VzIG5vdCBtYXRjaCBpdHMgYmFz
ZSB0eXBlIC0gbm90IGFuIGludGVnZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90
cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiPkhvd2V2ZXIsIHRoaXMgaXMgYSBweWFuZyBwcm9ibGVtLiBTZWUgPGEgaHJlZj0iaHR0
cHM6Ly9naXRodWIuY29tL21iajQ2NjgvcHlhbmcvaXNzdWVzLzMyOSI+DQpodHRwczovL2dpdGh1
Yi5jb20vbWJqNDY2OC9weWFuZy9pc3N1ZXMvMzI5PC9hPjxicj4NCjxicj4NCk1laG1ldCwgY2Fu
IHlvdSBwbGVhc2UgYSBZQU5HIGRvY3Rvci4gVGhlIFlBTkcgZG9jdG9yIHJldmlldyBpcyBub3Jt
YWxseSBkb25lIGR1cmluZyBJRVRGIExDLCBidXQgbm90aGluZyBwcmV2ZW50cyBhbiBlYXJseSBy
ZXZpZXcuPGJyPg0KPGJyPg0KUmVnYXJkcywgQmVub2l0PG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t
OjUuMHB0Ij4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIG5ldG1vZGVycyw8bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+VGhpcyBkcmFmdCBkb2VzIG5v
dCB0YWNrbGUgdGhlIGdlbmVyYWwgWUFORyBwcm9ibGVtLCBidXQgcHJvdmlkZSBhIGdlbmVyaWMg
dGltZSBzeW5jaHJvbml6YXRpb24gbW9kdWxlIG9mIDE1ODguPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5Tb21lIG9mIHlvdSBtYXkgaGF2ZSBpbnRlcmVz
dHMgaW4gdGltZSBzeW5jaHJvbml6YXRpb24sIHNvbWUgZGVmaW5pdGVseSBub3QuIEJ1dCBhcyBl
eHBlcnRzIGluIFlBTkcsIGNvdWxkIHlvdSBwbGVhc2UgaGF2ZSBhIHJldmlldyBvZiB0aGlzIFlB
TkcgbW9kdWxlIGFuZCBnaXZlIGFuIGV4cGVydCBvcGluaW9uPzxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5ZdWFubG9uZzxvOnA+PC9vOnA+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxv
OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTogVElD
VE9DIFs8YSBocmVmPSJtYWlsdG86dGljdG9jLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzp0aWN0
b2MtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBLYXJlbiBPJ0Rvbm9naHVlPG86
cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5TZW50OiBUaHVy
c2RheSwgU2VwdGVtYmVyIDE0LCAyMDE3IDM6MTYgQU08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N
CjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPlRvOiA8YSBocmVmPSJtYWlsdG86dGljdG9jQGlldGYu
b3JnIj50aWN0b2NAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkVOLVVTIj5DYzogPGEgaHJlZj0ibWFpbHRvOm50cEBpZXRmLm9yZyI+bnRwQGll
dGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1V
UyI+U3ViamVjdDogW1RJQ1RPQ10gV0dMQyBmb3IgZHJhZnQtaWV0Zi10aWN0b2MtMTU4OHYyLXlh
bmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+Rm9sa3Ms
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPlRoaXMgbWVz
c2FnZSBiZWdpbnMgYSAyIHdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwgKFdHTEMpIGZvciB0
aGUgZm9sbG93aW5nIGRvY3VtZW50OiA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJFTi1VUyI+WUFORyBEYXRhIE1vZGVsIGZvciBJRUVFIDE1ODh2MjxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly9k
YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10aWN0b2MtMTU4OHYyLXlhbmcvIj5o
dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRpY3RvYy0xNTg4djIt
eWFuZy88L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVT
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMi
PlBsZWFzZSByZXZpZXcgdGhlIHJlZmVyZW5jZWQgZG9jdW1lbnQgYW5kIHNlbmQgYW55IGNvbW1l
bnRzIHRvIHRoZSBtYWlsaW5nIGxpc3QgaW5jbHVkaW5nIHlvdXIgYXNzZXNzbWVudCBvZiB3aGV0
aGVyIHRoaXMgZG9jdW1lbnQgaXMgbWF0dXJlIGVub3VnaCB0byBwcm9jZWVkIHRvIHRoZSBJRVNH
LiBQbGVhc2Ugbm90ZSB0aGF0IHRoZXNlIG1lc3NhZ2VzIG9mIHN1cHBvcnQgZm9yIHByb2dyZXNz
aW9uIHRvIHRoZSBtYWlsaW5nIGxpc3QgYXJlIGltcG9ydGFudCBhbmQgd2lsbCBiZSB1c2VkIHRv
IGRldGVybWluZSBXRyBjb25zZW5zdXMgdG8gcHJvY2VlZC4gPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPlBsZWFzZSBzZW5kIGFsbCBjb21tZW50cyBpbiBi
eSBUaHVyc2RheSAyOCBTZXB0ZW1iZXIgMjAxNy4mbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rIHlvdSE8bzpwPjwvbzpwPjwvc3Bhbj48
L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPkthcmVuPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJFTi1VUyI+VElDVE9DIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHByZT48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0ibWFpbHRvOlRJQ1RPQ0BpZXRmLm9yZyI+
VElDVE9DQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs
YW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by90aWN0b2MiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGljdG9jPC9h
PjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj5fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+bmV0bW9kIG1haWxpbmcgbGlzdDxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0ibWFp
bHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vbmV0bW9kPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
biBsYW5nPSJFTi1VUyI+LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n
PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_3B0A1BED22CAD649A1B3E97BE5DDD68BBB5BA686dggeml507mbxchi_--


From nobody Mon Sep 18 01:00:16 2017
Return-Path: 
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 66E75133078; Mon, 18 Sep 2017 01:00: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 1ytdFamKU1dP; Mon, 18 Sep 2017 01:00:09 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 16E30132F6C; Mon, 18 Sep 2017 01:00:09 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 157181AE00A0; Mon, 18 Sep 2017 10:00:07 +0200 (CEST)
Date: Mon, 18 Sep 2017 09:58:35 +0200 (CEST)
Message-Id: <20170918.095835.618040149385689102.mbj@tail-f.com>
To: ietfc@btconnect.com
Cc: andy@yumaworks.com, j.schoenwaelder@jacobs-university.de, lberger@labn.net, netmod@ietf.org, netmod-chairs@ietf.org, draft-ietf-netmod-revised-datastores@ietf.org
From: Martin Bjorklund 
In-Reply-To: <009f01d32ff4$352ddc40$4001a8c0@gateway.2wire.net>
References:  <20170917.154115.791964858062115650.mbj@tail-f.com> <009f01d32ff4$352ddc40$4001a8c0@gateway.2wire.net>
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: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 updates
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Sep 2017 08:00:15 -0000

"t.petch"  wrote:
> ----- Original Message -----
> From: "Martin Bjorklund" 
> Sent: Sunday, September 17, 2017 2:41 PM
> 
> > Andy Bierman  wrote:
> > > On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder <
> > > j.schoenwaelder@jacobs-university.de> wrote:
> > >
> > > > On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
> > > > > Hi,
> > > > >
> > > > > I strongly agree with Tom that the current draft is an update to
> RFC
> > > > 7950.
> > > > > I also strongly disagree with the decision to omit RFC 2119 in a
> > > > standards
> > > > > track document. IMO RFC 2119 terms need to be used in normative
> text,
> > > > > especially when dealing with XPath and YANG compiler behavior.
> > > > >
> > > >
> > > > RFC 8174:
> > > >
> > > >    o  These words can be used as defined here, but using them is
> not
> > > >       required.  Specifically, normative text does not require the
> use
> > > >       of these key words.  They are used for clarity and
> consistency
> > > >       when that is what's wanted, but a lot of normative text does
> not
> > > >       use them and is still normative.
> > > >
> > > >
> > > So what?
> > > Existing YANG specifications use RFC 2119 terms.
> > > This draft uses those terms, just with lower-case.
> >
> > Actually, section 5.1 XPath Context in the revised datastore draft
> > uses the same language as section 6.4.1 XPath Context in RFC 7950.  In
> > fact, the text in the draft is copied (and adjusted) from RFC 7950.
> 
> Martin
> 
> 'Adjusted' might be seen as a weasel word:-)
> 
>    If the XPath expression is defined in a substatement to a
>       "notification" statement, the accessible tree is the notification
>       instance, all state data in the server, and the running
>       configuration datastore.
> 
> becomes
> 
> If the XPath expression is defined in a substatement to a
>       "notification" statement, the accessible tree is the notification
>       instance and all operational state in the server.
> 
> Goodbye  (well, running configuration in RFC7950).  Is it a
> material difference? - it will take me a while to work that one out.

The difference is that the xpath expressions no longer sees unused
configuration in running.  But if the config is used, it exists in
 under the same path as before, and it is available.

> I focussed on the XPath rules because they seemed the clearest case, but
> updating the definitions, and saying this section will replace the
> definitions in [RFC6241] and [RFC7950] when these documents are revised
> seems .... well, like an Erratum held for Update i.e. another Updates.

Are you saying that this is an argument for having "Updates: 7950"?


/martin


From nobody Mon Sep 18 02:19:24 2017
Return-Path: 
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 732411320CF for ; Mon, 18 Sep 2017 02:19:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 zq9zcw5dPhbd for ; Mon, 18 Sep 2017 02:19:20 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 52FAE126B6E for ; Mon, 18 Sep 2017 02:19:19 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id 37E5D1820E77; Mon, 18 Sep 2017 11:18:57 +0200 (CEST)
Received: from localhost (unknown [195.113.220.126]) by trail.lhotka.name (Postfix) with ESMTPSA id 435DC1820E71; Mon, 18 Sep 2017 11:18:54 +0200 (CEST)
From: Ladislav Lhotka 
To: Andy Bierman , Robert Wilton 
Cc: "Acee Lindem \(acee\)" , "netmod\@ietf.org" 
In-Reply-To: 
References: <14299503-509D-43BE-A938-0B7B88C3B249@juniper.net> <36ba3d4b-1ae1-0666-12cf-db41e172924b@cisco.com> <75739d75-da96-b340-2403-d0949ac54ed7@labn.net> <19134054-D52E-4A6D-992A-A47F365557AD@juniper.net> <1505471909.18681.7.camel@nic.cz>  <8326bb01-63a6-9746-098b-d693b12a2396@cisco.com>   
Mail-Followup-To: Andy Bierman , Robert Wilton , "Acee Lindem \(acee\)" , "netmod\@ietf.org" 
Date: Mon, 18 Sep 2017 11:19:52 +0200
Message-ID: <87h8w0bbyf.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Sep 2017 09:19:23 -0000

Andy Bierman  writes:

> On Fri, Sep 15, 2017 at 9:02 AM, Robert Wilton  wrote:
>
>>
>>
>> On 15/09/2017 16:23, Andy Bierman wrote:
>>
>> Hi,
>>
>> So are you saying the NMDA transition strategy should be ignored?
>>
>> My personal preference for the routing modules would be to keep the same
>> module name and deprecate the old nodes.
>>
>> However, I doubt that there are many implementations of this 8022 yet, a=
nd
>> if the authors prefer to use a new namespace without the old nodes then =
I'm
>> fine with that also.  Are you opposed to this approach?
>>
>>
>
> A new module name mandates a new namespace, so they go together.
> Abandoning the old module is fine, except leaving that module with status
> "current" is not fine.
> IMO you need to republish the old module as well, with everything status
> obsolete.

I don't agree with this. The "status" tag is justified for subsequent
revisions of the same module so as to aid old clients.

But if the module name and namespace URI are different, there is no such
concern. Modules contained in RFCs 7223, 8022 etc. just define some
schemas that happen to be good for my purposes. So I want to be able to
continue using them, and don't want tools to issue useless warnings or
even refuse to process such modules.

I am fine though with making a new revision of ietf-routing
etc. mentioning in the module description that this module is not
compatible with the NMDA architecture, and providing a pointer to
ietf-routing-2.

Lada

>
>
>
>> E.g. For ietf-interfaces, and ietf-ip, which are older, and hence probab=
ly
>> much more widely implemented then I think that the modules should be
>> updated in place with the existing state tree deprecated.  I.e. I support
>> what Martin has done in his IDs, and don't want this to change.
>>
>> What is the problem with deprecated nodes?
>>
>> Nothing really, but I guess that they are likely to be baggage that is
>> going to be around for a long time even if very few people ever implement
>> the deprecated nodes.
>>
>>
>> Why aren't you following your own transition strategy?
>>
>> Really because I'm not an author, both solutions seem valid, and I
>> actually think just reaching a conclusion quickly is more important than
>> which particular solution is chosen.  I don't see any advantage is pushi=
ng
>> back the adoption call - it seems like it will probably just delay when =
we
>> can do WG LC.
>>
>> I actually think that the bigger question that needs to be resolved is
>> whether we need an optional extension to mark a module as NMDA compatibl=
e,
>> or for the extra NMDA state module, as I think that both you and Tom have
>> been asking for.
>>
>
> I am no fan of YANG conformance.
> The WG does not seem to understand the difference between
>    (A) what a server is supposed to do
>    (B) what a server claims to do
>
> There is no way to express (A) in a YANG module, just (B) in the new
> yang-library.
>
>
> Andy
>
>
>
>>
>> Thanks,
>> Rob
>>
>>
>>
>>
>> Andy
>>
>> On Fri, Sep 15, 2017 at 8:01 AM, Robert Wilton  wrote:
>>
>>>
>>>
>>> On 15/09/2017 15:52, Acee Lindem (acee) wrote:
>>>
>>>> Hi,
>>>>
>>>> With respect to WG adoption, we will do whatever the WG decides for the
>>>> RFC 8022 model. We have a strong preference toward not carrying the
>>>> deprecated nodes forward and new module versions appears to be a good =
way
>>>> to achieve this.
>>>>
>>> Can we not adopt regardless?  We know that we are going to bis 8022, and
>>> having an adopted draft gives it a bit more legitimacy and helps other
>>> folks to migrate.
>>>
>>> Or perhaps we can start the call for adoption and continue to try and
>>> resolve this issue at the same time ;-).  I think that it would be good=
 to
>>> try and get the updated model drafts to WG LC by Singapore.
>>>
>>> I know that it hasn't been asked yet, but I support adoption of any 8022
>>> bis draft that (i) provides the correct NDMA combined tree (ii) removes=
 or
>>> deprecates the old state nodes :-)
>>>
>>> Sorry, if I'm being pushy :-)
>>> Rob
>>>
>>>
>>>
>>>> I agree with Lada that deprecating all the schema nodes is unnecessary.
>>>> However, we=E2=80=99ll do what it takes to reach consensus and satisfy=
 the most
>>>> pedantic among us.
>>>>
>>>> Thanks,
>>>> Acee
>>>>
>>>> On 9/15/17, 6:38 AM, "netmod on behalf of Ladislav Lhotka"
>>>>  wrote:
>>>>
>>>> Kent Watsen p=C3=AD=C5=A1e v =C4=8Ct 14. 09. 2017 v 14:52 +0000:
>>>>>
>>>>>> rfc8022bis-02 signals the intent to ditch the current/soon-to-be-leg=
acy
>>>>>> module, but does it actually say it?  (I can't find it)
>>>>>>
>>>>> The modules contained therein have different names and namespaces, so
>>>>> there is
>>>>> no formal ancestry. I would prefer to keep the modules from RFC 8022 =
as
>>>>> they are
>>>>> - some weirdos may still want to use them.
>>>>>
>>>>> The draft does say that it obsoletes 8022, but I'm unsure if that's
>>>>>> going to
>>>>>> have a meaningful impact in the wild.  I think Juergen said they had
>>>>>> this
>>>>>> issue with MIB2 and only after a couple years of misuse did they
>>>>>> republish the
>>>>>> legacy MIBs with deprecated status.
>>>>>>
>>>>>> I'm okay with this change being made after adoption, so long as ther=
e's
>>>>>> general agreement to do it.  Are the authors okay with it, or are th=
ere
>>>>>> any
>>>>>> better suggestions?
>>>>>>
>>>>>> PS: Sadly, the 'module' statement does not have 'status' as a
>>>>>> substatement [I
>>>>>> just added this omission to the yang-next tracker].  I think the only
>>>>>> way to
>>>>>> "deprecate a module" is to instead deprecate the all the
>>>>>> nodes/rpcs/notifications in the module.  Kind of ugly, but it's for a
>>>>>> deprecated module, so who care, right?  ;)
>>>>>>
>>>>> I think it is unnecessary. If somebody needs adding such a module to =
the
>>>>> data
>>>>> model, he/she should probably have a reason to do so, such as data
>>>>> implemented
>>>>> on the server.
>>>>>
>>>>> Lada
>>>>>
>>>>> Kent
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Hi Rob,
>>>>>>
>>>>>> On 9/14/2017 9:37 AM, Robert Wilton wrote:
>>>>>>
>>>>>>> Hi Kent & Lou,
>>>>>>>
>>>>>>> When do you think that it will be possible to start the adoption
>>>>>>>
>>>>>> process
>>>>>>
>>>>>>> on these drafts?
>>>>>>>
>>>>>>> I think that the first two at least would seem to be ready for
>>>>>>> adoption.  For the 3rd draft, there still seems to be an open
>>>>>>>
>>>>>> question
>>>>>>
>>>>>>> of what to do with the old state tree, but presumably that could be
>>>>>>> solved after the draft has been adopted?
>>>>>>>
>>>>>> I see an update for the third was published yesterday
>>>>>> (https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-02)  that
>>>>>> clarifies the intent is to replace the current modules, and presumab=
ly
>>>>>> obsolete 8022.  And now that this intended direction is clear in the
>>>>>> draft we could poll it.
>>>>>>
>>>>>> I think this still doesn't address if we need to indicate that the
>>>>>> rfc8022 defined modules are deprecated by some other mechanisms than
>>>>>> just replacing the RFC, e.g., by updating the old modules with all
>>>>>> nodes
>>>>>> marked as deprecated.  I think you're right that this could be done
>>>>>> post
>>>>>> adoption.  Of course others are free to disagree.
>>>>>>
>>>>>> I check with Kent and see what he thinks.
>>>>>>
>>>>>> Thanks,
>>>>>> Lou
>>>>>>
>>>>>> Thanks,
>>>>>>> Rob
>>>>>>>
>>>>>>>
>>>>>>> On 30/08/2017 00:46, Kent Watsen wrote:
>>>>>>>
>>>>>>>> Hey folks,
>>>>>>>>
>>>>>>>> As discussed at the last meeting, we are heading to revising
>>>>>>>>
>>>>>>> existing RFCs
>>>>>>
>>>>>>> to align them with NMDA.  The first batch have been published as
>>>>>>>> individual drafts:
>>>>>>>>
>>>>>>>> 1. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00
>>>>>>>> 2. https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00
>>>>>>>> 3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00
>>>>>>>>
>>>>>>>> Please take a look (comments welcome!) and stay tuned for the
>>>>>>>>
>>>>>>> related
>>>>>>
>>>>>>> adoption calls.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Kent (and Lou)
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> netmod mailing list
>>>>>>>> netmod@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>>> .
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> netmod mailing list
>>>>>> netmod@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>
>>>>> --
>>>>> Ladislav Lhotka
>>>>> Head, CZ.NIC Labs
>>>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>>>
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> netmod@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>
>>
>>

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


From nobody Mon Sep 18 02:28:52 2017
Return-Path: 
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 4FD6D1323B8; Mon, 18 Sep 2017 02:28:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 FjCSbcLv4-GY; Mon, 18 Sep 2017 02:28:48 -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 62336126B6E; Mon, 18 Sep 2017 02:28:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15640; q=dns/txt; s=iport; t=1505726927; x=1506936527; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=8Lc5SYe085oFJDvREBOY9B4YxDE+slYOYgL5Gulcl2c=; b=NDi4ouWoamDC9/BQT+WsCWCExHnQb7n8xMfuq1o9gpz+KJKZL0+FJOUb BUjPkYwkLm73fZYOHY4x2Zy5iuncbvnnOP82d48t888s46RtQnJB6tw0M P8OeivdbsvTME3hVbQBDm1h2ZpUPVJZOgAwGyWfmTTVfF0W6EOyE+z7Bp Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DqAQAfkb9Z/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhSwng3WLFJBIK5BnhT+CEgqEK4EQAoR/FgECAQEBAQEBAWsohRk?= =?us-ascii?q?BBSNPBxAJEgIGIwQDAgJGAw4GDQYCAQGKL40nnWaCJyeLAAEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAR2DK4NSgWMriCuCXYJgBaEIlFWCE4lEJIZ9igCDXodXgTkmBit?= =?us-ascii?q?BTDIhCBwVhheBTz82hVQrghQBAQE?=
X-IronPort-AV: E=Sophos;i="5.42,412,1500940800";  d="scan'208,217";a="655723101"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Sep 2017 09:28:45 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v8I9ShBZ006068; Mon, 18 Sep 2017 09:28:44 GMT
To: Andy Bierman 
Cc: Martin Bjorklund , Juergen Schoenwaelder , "t.petch" , Berger Lou , "netmod@ietf.org" , NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org
References:  <20170916072403.xp37556z6g7b42gr@elstar.local>  <20170917.154115.791964858062115650.mbj@tail-f.com> 
From: Robert Wilton 
Message-ID: 
Date: Mon, 18 Sep 2017 10:28:43 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------4157BCD5E2CEB8BC40F38AC3"
Content-Language: en-US
Archived-At: 
Subject: [netmod]  vs  [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Sep 2017 09:28:50 -0000

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

Hi Andy,

At the moment, NMDA does not change the definition of  for a 
standards compliant implementation of YANG/NETCONF/RESTCONF.  It is 
still the same as in 7950, and  must still be a "valid 
configuration data tree" for a standards complaint implementation.

However, the draft acknowledges that proprietary extensions exist that 
can modify the behaviour of  in ways that means that  
is not always a valid configuration data tree.  The draft gives two 
examples of how  could be manipulated (inactive config, and 
templates).

If those extensions are standardized then I think it is likely that 
those RFCs would need to update 7950 to indicate that  isn't 
necessarily a "valid configuration data tree" when those extensions are 
used.  But I don't think that needs to be stated in the NMDA 
architecture at this time.

So, what is ?
  - this is meant to represent the configuration that the system will 
actually attempt to apply after any and all manipulation (e.g. by 
templates, inactive removal, perhaps system scripts, etc) of the 
configuration has been performed.
  - it must always be a valid configuration data tree.
  - If  is updated then  is always updated at the 
same time.  Hence, any successful change to  requires that 
 has also been updated and validated.  E.g. in RESTCONF terms, 
I think that both  and   should get the same 
last-change timestamp whenever  is updated.
  - It provides a known fixed point so that any client can see the full 
validated config, i.e. even for devices that implement proprietary 
manipulations of the configuring in .
  - If the device doesn't support any extra proprietary config 
manipulations, then  is identical to .

I think that we can possibly do a bit more to better define what 
.  My previous suggestion as an improvement was below 
(perhaps you think it needs more clarification)?:

*OLD:*

4.4.  The Intended Configuration Datastore ()

    The intended configuration datastore () is a read-only
    configuration datastore.  It is tightly coupled to .  When
    data is written to , the data that is to be validated is
    also conceptually written to . Validation is performed on
    the contents of .

    For simple implementations,  and  are identical.

     does not persist across reboots; its relationship with
     makes that unnecessary.

    ...

*NEW:*

4.4.  The Intended Configuration Datastore ()

    The intended configuration datastore () is a read-only
    configuration datastore.  It represents the configuration after all
    configuration transformations to  are performed (e.g.
    template expansion, inactive configuration removal), and is the
    configuration that the system attempts to apply.

    It is tightly coupled to .  When data is written to
    , the data that is to be validated is also conceptually
    written to .  Validation is performed on the contents of
    .

    For simple implementations,  and  are identical.

    The contents of  is also related to the 'config true'
    subset of , and hence a client can determine to what
    extent the intended configuration is currently applied by checking
    whether the contents of  also appears in .

     does not persist across reboots; its relationship with
     makes that unnecessary.

    ...

Thanks,
Rob


On 17/09/2017 16:31, Andy Bierman wrote:
> Hi,
>
> My concern is that the definition of  is being changed to
> include undefined and undeclared proprietary extensions.
> This is counter-productive to the IETF's stated goal of interoperability.
>
>
> Andy
>
>
> On Sun, Sep 17, 2017 at 6:41 AM, Martin Bjorklund  > wrote:
>
>     Andy Bierman > wrote:
>     > On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder <
>     > j.schoenwaelder@jacobs-university.de
>     > wrote:
>     >
>     > > On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
>     > > > Hi,
>     > > >
>     > > > I strongly agree with Tom that the current draft is an
>     update to RFC
>     > > 7950.
>     > > > I also strongly disagree with the decision to omit RFC 2119 in a
>     > > standards
>     > > > track document. IMO RFC 2119 terms need to be used in
>     normative text,
>     > > > especially when dealing with XPath and YANG compiler behavior.
>     > > >
>     > >
>     > > RFC 8174:
>     > >
>     > >    o  These words can be used as defined here, but using them
>     is not
>     > >       required.  Specifically, normative text does not require
>     the use
>     > >       of these key words.  They are used for clarity and
>     consistency
>     > >       when that is what's wanted, but a lot of normative text
>     does not
>     > >       use them and is still normative.
>     > >
>     > >
>     > So what?
>     > Existing YANG specifications use RFC 2119 terms.
>     > This draft uses those terms, just with lower-case.
>
>     Actually, section 5.1 XPath Context in the revised datastore draft
>     uses the same language as section 6.4.1 XPath Context in RFC 7950.  In
>     fact, the text in the draft is copied (and adjusted) from RFC 7950.
>
>
>     /martin
>
>


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


  
    
  
  
    
Hi Andy,

    
At the moment, NMDA does not change the definition of
      <running> for a standards compliant implementation of
      YANG/NETCONF/RESTCONF.  It is still the same as in 7950, and
      <running> must still be a "valid configuration data tree"
      for a standards complaint implementation.

    

    
However, the draft acknowledges that proprietary extensions exist
      that can modify the behaviour of <running> in ways that
      means that <running> is not always a valid configuration
      data tree.  The draft gives two examples of how <running>
      could be manipulated (inactive config, and templates).

    

    
If those extensions are standardized then I think it is likely
      that those RFCs would need to update 7950 to indicate that
      <running> isn't necessarily a "valid configuration data
      tree" when those extensions are used.  But I don't think that
      needs to be stated in the NMDA architecture at this time.

    
So, what is <intended>?

       - this is meant to represent the configuration that the system
      will actually attempt to apply after any and all manipulation
      (e.g. by templates, inactive removal, perhaps system scripts, etc)
      of the configuration has been performed.

       - it must always be a valid configuration data tree.

       - If <running> is updated then <intended> is always
      updated at the same time.  Hence, any successful change to
      <running> requires that <intended> has also been
      updated and validated.  E.g. in RESTCONF terms, I think that both
      <running> and  <intended> should get the same
      last-change timestamp whenever <running> is updated.

       - It provides a known fixed point so that any client can see the
      full validated config, i.e. even for devices that implement
      proprietary manipulations of the configuring in <running>.

       - If the device doesn't support any extra proprietary config
      manipulations, then <intended> is identical to
      <running>.

    

    
I think that we can possibly do a bit more to better define what
      <intended is>.  My previous suggestion as an improvement was
      below (perhaps you think it needs more clarification)?:

    
OLD:

    
4.4.  The Intended Configuration Datastore (<intended>)

      

    
   The intended configuration datastore (<intended>) is
        a read-only

         configuration datastore.  It is tightly coupled to
        <running>.  When

         data is written to <running>, the data that is
        to be validated is

         also conceptually written to <intended>. 
        Validation is performed on

         the contents of <intended>.

      

         For simple implementations, <running> and
        <intended> are identical.

      

         <intended> does not persist across reboots; its
        relationship with

         <running> makes that unnecessary.  

      

         ...

    

    
NEW:

    
4.4.  The Intended Configuration Datastore (<intended>)

      

         The intended configuration datastore
        (<intended>) is a read-only

         configuration datastore.  It represents the
        configuration after all

         configuration transformations to <running> are
        performed (e.g.

         template expansion, inactive configuration removal),
        and is the

         configuration that the system attempts to apply.

      

         It is tightly coupled to <running>.  When data
        is written to

         <running>, the data that is to be validated is
        also conceptually

         written to <intended>.  Validation is performed
        on the contents of

         <intended>.

      

         For simple implementations, <running> and
        <intended> are identical.

      

         The contents of <intended> is also related to
        the 'config true'

         subset of <operational>, and hence a client can
        determine to what

         extent the intended configuration is currently applied
        by checking

         whether the contents of <intended> also appears
        in <operational>.

      

         <intended> does not persist across reboots; its
        relationship with

         <running> makes that unnecessary.

       ...
    
Thanks,

      Rob

    

    

    
On 17/09/2017 16:31, Andy Bierman
      wrote:

    

    

      
      
Hi,
        


        

        
My concern is that the definition of <running> is
          being changed to

        
include undefined and undeclared proprietary extensions.

        
This is counter-productive to the IETF's stated goal of
          interoperability.

        


        

        


        

        
Andy

        


        

      

      


        
On Sun, Sep 17, 2017 at 6:41 AM, Martin
          Bjorklund <mbj@tail-f.com>
          wrote:

          
Andy
            Bierman <andy@yumaworks.com> wrote:

            > On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder
            <

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

            >

            > > On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy
            Bierman wrote:

            > > > Hi,

            > > >

            > > > I strongly agree with Tom that the current
            draft is an update to RFC

            > > 7950.

            > > > I also strongly disagree with the decision to
            omit RFC 2119 in a

            > > standards

            > > > track document. IMO RFC 2119 terms need to be
            used in normative text,

            > > > especially when dealing with XPath and YANG
            compiler behavior.

            > > >

            > >

            > > RFC 8174:

            > >

            > >    o  These words can be used as defined here, but
            using them is not

            > >       required.  Specifically, normative text does
            not require the use

            > >       of these key words.  They are used for
            clarity and consistency

            > >       when that is what's wanted, but a lot of
            normative text does not

            > >       use them and is still normative.

            > >

            > >

            > So what?

            > Existing YANG specifications use RFC 2119 terms.

            > This draft uses those terms, just with lower-case.

            

            Actually, section 5.1 XPath Context in the revised datastore
            draft

            uses the same language as section 6.4.1 XPath Context in RFC
            7950.  In

            fact, the text in the draft is copied (and adjusted) from
            RFC 7950.

            

                

                /martin

              

        

        

      

    

    

  


--------------4157BCD5E2CEB8BC40F38AC3--


From nobody Mon Sep 18 03:15:03 2017
Return-Path: 
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 C98391321F5; Mon, 18 Sep 2017 03:15:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 2O5DrUG_sPfs; Mon, 18 Sep 2017 03:15:00 -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 5F724127005; Mon, 18 Sep 2017 03:14:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1953; q=dns/txt; s=iport; t=1505729699; x=1506939299; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=UYPBRm08BjOi8FCw7mpXRFIQCaTLX1E0FBCUUGl4lms=; b=UVMtshkpmBHCFu012czNFBKEqyCPDhOv7xra+W2Bnf6iSQ5WYcY953Gg RugwPoxUv4merBPt78NXRluepjj2oOZ36fQ8/w+0074qzl5OnY6sfmEvQ 4V2CDcwul5Dea+oETj4jDVVPEarbYHSAR3EHNqmZmcjOqx+btbNClH+sa 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CrAQC4m79Z/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhSwng3WLFJBKK5g4CoU7AoUCFAECAQEBAQEBAWsohRgBAQEBAyM?= =?us-ascii?q?PAQVBDAQLEAUBAgICJgICVwYBDAYCAQGKL6phgieLJwEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAR2BDoIdg1KCDoJ9iAuCYAEEoQiUVYtXhyGNXodXgTk2IYENMiEIHBW?= =?us-ascii?q?HZj82hVQrghQBAQE?=
X-IronPort-AV: E=Sophos;i="5.42,412,1500940800"; d="scan'208";a="697270410"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Sep 2017 10:14:57 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8IAEtW4000468; Mon, 18 Sep 2017 10:14:56 GMT
To: "t.petch" , Juergen Schoenwaelder 
Cc: Lou Berger , netmod WG , netmod-chairs@ietf.org, draft-ietf-netmod-revised-datastores@ietf.org
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <000901d32e3e$883fa9c0$4001a8c0@gateway.2wire.net> <20170915170959.q5bfwoqoaqaq4o5b@elstar.local> <009e01d32ff4$345b4a00$4001a8c0@gateway.2wire.net>
From: Robert Wilton 
Message-ID: <2ab1ed32-f499-b6f6-b619-44b46f0c0019@cisco.com>
Date: Mon, 18 Sep 2017 11:14:55 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <009e01d32ff4$345b4a00$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 inactive
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Sep 2017 10:15:02 -0000

On 17/09/2017 21:21, t.petch wrote:
> ----- Original Message -----
> From: "Juergen Schoenwaelder" 
> Sent: Friday, September 15, 2017 6:09 PM
>
>
>> Two comments:
>>
>> - Obviously, inactive can be in  and I would not rule out
>>    that inactive configuration can be in any other or future
>>    configuration datastores.
>>
>> - Whether protocols support inactive or not does not belong into a
>>    definition of what inactive configuration is. The same for backwards
>>    compatibility considerations etc.
>>
>> So if we define inactive configuration, the definition should be
>> something like this:
>>
>> * inactive configuration: Configuration held in a configuration
>>    datastore that is marked to be inactive. Inactive configuration is
>>    ignored during validation and never applied and actively used by
>>    a device.
>>
>> Yes, we should use 'inactive configuration' everywhere to be
> consistent.
>
> Juergen
>
> Yes, your definition is better than mine; let's add it.
I'm not necessarily opposed to this, but I think that we want to be 
careful here.  Inactive configuration and templating are only meant to 
be examples of how  could differ from , and we really 
aren't trying to provide normative definitions of them.  Is putting a 
definition of 'inactive configuration' in this draft going to 
potentially cause problems for a future 'inactive configuration' 
extension that could possibly want to define the term differently?

If we do decide to incorporate a definition, I would suggest at least 
tweaking it slightly to avoid the possible ambiguity of the last phrase:

* inactive configuration: Configuration held in a configuration
   datastore that is marked to be inactive. Inactive configuration is
   ignored during validation, never applied, and not actively used by
   a device.


Thanks,
Rob


From nobody Mon Sep 18 03:26:21 2017
Return-Path: 
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 62FDC13421F; Mon, 18 Sep 2017 03:26:20 -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 OOKTd630aiTD; Mon, 18 Sep 2017 03:26:18 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6D7D13421D; Mon, 18 Sep 2017 03:26:17 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 237AFFC0; Mon, 18 Sep 2017 12:26:16 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id z1JuNQW1xLFi; Mon, 18 Sep 2017 12:26:10 +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 atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 18 Sep 2017 12:26:16 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id F2095200EA; Mon, 18 Sep 2017 12:26:15 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id gLKpchixIkFr; Mon, 18 Sep 2017 12:26:15 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1566D200E8; Mon, 18 Sep 2017 12:26:15 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id EFBB4410AA02; Mon, 18 Sep 2017 12:26:14 +0200 (CEST)
Date: Mon, 18 Sep 2017 12:26:14 +0200
From: Juergen Schoenwaelder 
To: Robert Wilton 
Cc: "t.petch" , Lou Berger , netmod WG , netmod-chairs@ietf.org, draft-ietf-netmod-revised-datastores@ietf.org
Message-ID: <20170918102614.ydoh6xvva3ppzmuf@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Robert Wilton , "t.petch" , Lou Berger , netmod WG , netmod-chairs@ietf.org, draft-ietf-netmod-revised-datastores@ietf.org
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <000901d32e3e$883fa9c0$4001a8c0@gateway.2wire.net> <20170915170959.q5bfwoqoaqaq4o5b@elstar.local> <009e01d32ff4$345b4a00$4001a8c0@gateway.2wire.net> <2ab1ed32-f499-b6f6-b619-44b46f0c0019@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <2ab1ed32-f499-b6f6-b619-44b46f0c0019@cisco.com>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 inactive
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Sep 2017 10:26:20 -0000

On Mon, Sep 18, 2017 at 11:14:55AM +0100, Robert Wilton wrote:
> 
> 
> On 17/09/2017 21:21, t.petch wrote:
> > ----- Original Message -----
> > From: "Juergen Schoenwaelder" 
> > Sent: Friday, September 15, 2017 6:09 PM
> > 
> > 
> > > Two comments:
> > > 
> > > - Obviously, inactive can be in  and I would not rule out
> > >    that inactive configuration can be in any other or future
> > >    configuration datastores.
> > > 
> > > - Whether protocols support inactive or not does not belong into a
> > >    definition of what inactive configuration is. The same for backwards
> > >    compatibility considerations etc.
> > > 
> > > So if we define inactive configuration, the definition should be
> > > something like this:
> > > 
> > > * inactive configuration: Configuration held in a configuration
> > >    datastore that is marked to be inactive. Inactive configuration is
> > >    ignored during validation and never applied and actively used by
> > >    a device.
> > > 
> > > Yes, we should use 'inactive configuration' everywhere to be
> > consistent.
> > 
> > Juergen
> > 
> > Yes, your definition is better than mine; let's add it.
> I'm not necessarily opposed to this, but I think that we want to be careful
> here.  Inactive configuration and templating are only meant to be examples
> of how  could differ from , and we really aren't trying
> to provide normative definitions of them.  Is putting a definition of
> 'inactive configuration' in this draft going to potentially cause problems
> for a future 'inactive configuration' extension that could possibly want to
> define the term differently?

Yes, my preference would be to leave the definition of inactive
configuration to a future draft.

> If we do decide to incorporate a definition, I would suggest at least
> tweaking it slightly to avoid the possible ambiguity of the last phrase:
> 
> * inactive configuration: Configuration held in a configuration
>   datastore that is marked to be inactive. Inactive configuration is
>   ignored during validation, never applied, and not actively used by
>   a device.
>

Yes, this is better (if we have to define this). It all boils down:

a) We publish an architecture which enables future standardization
   work on things we know exist in real implementations.

b) We strictly limit us to what we define right now and this means
   that the architecture does not describe what some real
   implementations do and we have to revise the architecure should
   future work started to standardize such things.

For simple inactive configuration, I do see an opportunity for a
standard solution and hence I think what the revised datastores I-D
proposes makes a lot of sense (but then I am of course biased here).
It provides an architectural framework that enabled a further
evolution without having to change the architectural framework again.

/js

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


From nobody Mon Sep 18 06:34:11 2017
Return-Path: 
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 BB3E213217D for ; Mon, 18 Sep 2017 06:34:09 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCfE4cLGMJtU for ; Mon, 18 Sep 2017 06:34:07 -0700 (PDT)
Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (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 6FCC4126C7A for ; Mon, 18 Sep 2017 06:34:07 -0700 (PDT)
Received: from cmgw2 (unknown [10.0.90.83]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id 3A826140605 for ; Mon, 18 Sep 2017 07:34:06 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id B1a21w01v2SSUrH011a5ZU; Mon, 18 Sep 2017 07:34:06 -0600
X-Authority-Analysis: v=2.2 cv=dZfw5Tfe c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=2JCJgTwv5E4A:10 a=48vgC7mUAAAA:8 a=NEAV23lmAAAA:8 a=ngwYvln4HPmK8yx8zYoA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:References:Cc:To:From:Subject:Sender:Reply-To: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=LdQsuXkIxZq48NliZ4YqIfVE+gNd+9YVCh+QQDfVLDw=; b=FupChYnLbwu+i9oqccAXiLlURE Jiwbi3n6VYgVum15YGULkOD05IYPW3+0VDqnKkBmpsEvH/sb2jUpuNfvTQRoIwlFWr8Q4EQOIh7pj e+VJpvUCOO24WRBufJyfk5L8d;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:54186 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dtwBW-001XuN-9F; Mon, 18 Sep 2017 07:34:02 -0600
From: Lou Berger 
To: netmod WG 
Cc: "netmod-chairs@ietf.org" , draft-ietf-netmod-revised-datastores@ietf.org
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net>
Message-ID: 
Date: Mon, 18 Sep 2017 09:33:58 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dtwBW-001XuN-9F
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:54186
X-Source-Auth: lberger@labn.net
X-Email-Count: 1
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Sep 2017 13:34:10 -0000

All,

    The LC is closed.  There are clearly some issues to discuss and
resolve before this document can be submitted for publications.  Given
the issues raised, as well as the good on-list discussion, I'd like to
ask the authors to formally track all issues raised and their resolutions. 

We have two different issue tracking tools available at the moment: the
WG trac instance [1], or the github document repo [2]. The authors are
free to choose their preferred method, and should let the WG know once
the issues have been entered as well as once an issue is addressed with
through discussion and, as needed, draft text change.

Thank you,

Lou

(as Shepherd)

[1] https://trac.ietf.org/trac/netmod/
[2] https://github.com/netmod-wg/datastore-dt

On 9/1/2017 5:02 PM, Lou Berger wrote:
> All,
>
> This starts a two week working group last call on
> draft-ietf-netmod-revised-datastores-04.
>
> The working group last call ends on September 17.
> Please send your comments to the netmod mailing list.
>
> Positive comments, e.g., "I've reviewed this document and
> believe it is ready for publication", are welcome!
> This is useful and important, even from authors.
>
> Thank you,
> Netmod Chairs
>


From nobody Mon Sep 18 06:46:22 2017
Return-Path: 
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 252901331DC for ; Mon, 18 Sep 2017 06:46:20 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKVmyy38HqrW for ; Mon, 18 Sep 2017 06:46:18 -0700 (PDT)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 8DD61133158 for ; Mon, 18 Sep 2017 06:46:18 -0700 (PDT)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 18A511E31D4 for ; Mon, 18 Sep 2017 07:42:38 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id B1ia1w00c2SSUrH011idBJ; Mon, 18 Sep 2017 07:42:38 -0600
X-Authority-Analysis: v=2.2 cv=K4VSJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=2JCJgTwv5E4A:10 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=XfLPWjWjkKf_1pUmatMA:9 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: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=MClac2UvhPFdpjW+iD0Knhnf9aZvbeLTDn+efScxEdc=; b=kv/d+vuILcl0C5ii5v1Hs4FI4m ShPu9GqKfdTrlyh7iVvtKBWx4eNxnhwwLZOqiroqZyEln0KqwO2tOYZ299+xQUEIJPB094xDkplh8 VD5Jl4XJeciR9iufmVBsKucCM;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:54356 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dtwJm-001ZmK-B1; Mon, 18 Sep 2017 07:42:34 -0600
To: "t.petch" , Kent Watsen , Robert Wilton , netmod@ietf.org
References: <14299503-509D-43BE-A938-0B7B88C3B249@juniper.net> <36ba3d4b-1ae1-0666-12cf-db41e172924b@cisco.com> <75739d75-da96-b340-2403-d0949ac54ed7@labn.net> <19134054-D52E-4A6D-992A-A47F365557AD@juniper.net> <2891bd09-0e0d-415c-2714-15141a293e42@cisco.com>  <011d01d32d77$c8e0a500$4001a8c0@gateway.2wire.net> <9c0d8394-b2a4-180a-2454-8955c1721423@labn.net> <003801d32e3f$ba625460$4001a8c0@gateway.2wire.net>
From: Lou Berger 
Message-ID: <1d23c9e8-446f-aa67-6cbe-fbc52c24f15e@labn.net>
Date: Mon, 18 Sep 2017 09:42:30 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <003801d32e3f$ba625460$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dtwJm-001ZmK-B1
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:54356
X-Source-Auth: lberger@labn.net
X-Email-Count: 7
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] upcoming adoptions - this appendix is normative
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Sep 2017 13:46:20 -0000

Hi Tom.

    A few observations:


On 9/15/2017 12:28 PM, t.petch wrote:
> ----- Original Message -----
> From: "Lou Berger" 
> Sent: Thursday, September 14, 2017 6:06 PM
>
>> On 9/14/2017 12:36 PM, t.petch wrote:
>>> Appendices are Normative if they say that they are Normative.  The
>>> default is that they are not so say that they are and they are.
> This is
>>> well established practice.
>> Hi Tom,
>> My memory (I haven't checked recently) is there is nothing in or
>> defined process that says if an Appendix is normative or not. Other
>> SDOs certainly have formal definitions here. Within the IETF, my view
>> has been that if an appendix includes RFC2119 language, it is
>> normative. Actually, strictly speaking, any text in a Standards Track
>> RFC that doesn't include RFC2119 language is just informative.
> Lou
>
> Try RFC4910.
>
> '   This appendix is normative. '
>
> and not a SHOULD or a MUST in sight.

- This is an Experimental not Proposed Standard RFC. 

- As an organization, we've improved or differentiation of normative and
informative text over the last 10 years

- The RFC editor still does *not* require use of RFC2119 language, see
https://tools.ietf.org/html/rfc7322#section-4.8.2
Lou
> Tom Petch
>
>> Lou
>>
>


From nobody Mon Sep 18 06:48:21 2017
Return-Path: 
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 2B618134231 for ; Mon, 18 Sep 2017 06:48:20 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keXAE6_9BNYA for ; Mon, 18 Sep 2017 06:48:18 -0700 (PDT)
Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (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 C4551132C3F for ; Mon, 18 Sep 2017 06:48:18 -0700 (PDT)
Received: from cmgw2 (unknown [10.0.90.83]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id 77FC61410DA for ; Mon, 18 Sep 2017 07:48:18 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id B1oF1w00u2SSUrH011oJtx; Mon, 18 Sep 2017 07:48:18 -0600
X-Authority-Analysis: v=2.2 cv=dZfw5Tfe c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=2JCJgTwv5E4A:10 a=48vgC7mUAAAA:8 a=-tsAPJKn6S7ax0J5AdsA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:From:Cc:To:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=YC5Qp95XOQVyrlklaQhaTsRKvEnm9RljdtEdz+Wc1GI=; b=P4wfkdXU+GZ62xvv61M6pAjiXq 8N+8F/ZNAvSTWAozfBmSvpgWxLTMTdIoszQHI5EqpshKnXcQD2YSBxhvbuUMugtz/gKv7g1yo48+Q unyS79jmD1bO38Y2fhLPv+Chu;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:54444 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dtwPH-001aw0-AC; Mon, 18 Sep 2017 07:48:15 -0600
To: Martin Bjorklund 
Cc: NetMod WG 
From: Lou Berger 
Message-ID: 
Date: Mon, 18 Sep 2017 09:48:11 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dtwPH-001aw0-AC
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:54444
X-Source-Auth: lberger@labn.net
X-Email-Count: 11
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: [netmod] Regarding IPR on draft-bjorklund-netmod-rfc7277bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Sep 2017 13:48:20 -0000

Authors, Contributors, WG,

As part of the preparation for WG Last Call:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author and listed
contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
NetMod WG Chairs

PS Please include all listed in the headers of this message in your
response.




From nobody Mon Sep 18 06:48:33 2017
Return-Path: 
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 A1449132705 for ; Mon, 18 Sep 2017 06:48:21 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Bw_E1DWNXje for ; Mon, 18 Sep 2017 06:48:20 -0700 (PDT)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 AF40313421A for ; Mon, 18 Sep 2017 06:48:19 -0700 (PDT)
Received: from cmgw2 (unknown [10.0.90.83]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 95A0F1E1104 for ; Mon, 18 Sep 2017 07:48:14 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id B1oB1w01E2SSUrH011oErA; Mon, 18 Sep 2017 07:48:14 -0600
X-Authority-Analysis: v=2.2 cv=dZfw5Tfe c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=2JCJgTwv5E4A:10 a=48vgC7mUAAAA:8 a=-tsAPJKn6S7ax0J5AdsA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:From:Cc:To:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=YC5Qp95XOQVyrlklaQhaTsRKvEnm9RljdtEdz+Wc1GI=; b=YpAIVR2XdkukTVuin/xbT0ELs0 i1QFp4Tk9R2lKebYGRR7z+LcCbVpw9QohybRHkgGBP1dWQ0dCl3ExtZhVFE83AXqCuCiuXb7dLIj0 FM7+2iHT0AHNl1mNzdITUJF/a;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:54442 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dtwPD-001avX-DP; Mon, 18 Sep 2017 07:48:11 -0600
To: Martin Bjorklund 
Cc: NetMod WG 
From: Lou Berger 
Message-ID: <7aba555e-fa12-7680-7f43-2c08a73f410e@labn.net>
Date: Mon, 18 Sep 2017 09:48:08 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dtwPD-001avX-DP
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:54442
X-Source-Auth: lberger@labn.net
X-Email-Count: 9
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: [netmod] Regarding IPR on draft-bjorklund-netmod-rfc7223bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Sep 2017 13:48:22 -0000

Authors, Contributors, WG,

As part of the preparation for WG Last Call:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author and listed
contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
NetMod WG Chairs

PS Please include all listed in the headers of this message in your
response.




From nobody Mon Sep 18 06:48:39 2017
Return-Path: 
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 122A6132705 for ; Mon, 18 Sep 2017 06:48:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level: 
X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IDjDsdjFJLA for ; Mon, 18 Sep 2017 06:48:24 -0700 (PDT)
Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) (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 964FC134231 for ; Mon, 18 Sep 2017 06:48:24 -0700 (PDT)
Received: from cmgw2 (unknown [10.0.90.83]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id 1ACEB1AB241 for ; Mon, 18 Sep 2017 07:48:23 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id B1oL1w00X2SSUrH011oPxk; Mon, 18 Sep 2017 07:48:23 -0600
X-Authority-Analysis: v=2.2 cv=dZfw5Tfe c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=2JCJgTwv5E4A:10 a=48vgC7mUAAAA:8 a=-tsAPJKn6S7ax0J5AdsA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:From:Cc:To:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=YC5Qp95XOQVyrlklaQhaTsRKvEnm9RljdtEdz+Wc1GI=; b=zpfOgXefiw5KjbYw7R7hBrJukj F7cMqZnj8Uqm9VAq85AGk9+d+vkW6542GQpQr/Nhu5jP45wBl8c02J2JYs769X28PFAHTDkDPLqAG jARr9veA51ccuXDtekF8HtokE;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:54446 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dtwPL-001ax9-U6; Mon, 18 Sep 2017 07:48:20 -0600
To: Ladislav Lhotka , Yingzhen Qu , Acee Lindem 
Cc: NetMod WG 
From: Lou Berger 
Message-ID: <7205a700-f00a-13f1-1941-46d578e38a27@labn.net>
Date: Mon, 18 Sep 2017 09:48:16 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dtwPL-001ax9-U6
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:54446
X-Source-Auth: lberger@labn.net
X-Email-Count: 15
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: [netmod] Regarding IPR on draft-acee-netmod-rfc8022bis-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Sep 2017 13:48:26 -0000

Authors, Contributors, WG,

As part of the preparation for WG Last Call:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author and listed
contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
NetMod WG Chairs

PS Please include all listed in the headers of this message in your
response.




From nobody Mon Sep 18 06:50:12 2017
Return-Path: 
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 F3BC1132C3F for ; Mon, 18 Sep 2017 06:50:11 -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 5AuKCp2WE7Rl for ; Mon, 18 Sep 2017 06:50:10 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 435E113202D for ; Mon, 18 Sep 2017 06:50:10 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 339341AE00A0; Mon, 18 Sep 2017 15:50:09 +0200 (CEST)
Date: Mon, 18 Sep 2017 15:48:37 +0200 (CEST)
Message-Id: <20170918.154837.665721148076690640.mbj@tail-f.com>
To: lberger@labn.net
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <7aba555e-fa12-7680-7f43-2c08a73f410e@labn.net>
References: <7aba555e-fa12-7680-7f43-2c08a73f410e@labn.net>
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: [netmod] Regarding IPR on draft-bjorklund-netmod-rfc7223bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Sep 2017 13:50:12 -0000

Lou Berger  wrote:
> Authors, Contributors, WG,
> 
> As part of the preparation for WG Last Call:
> 
> Are you aware of any IPR that applies to drafts identified above?

No, I'm not aware of any IPR that applies to this draft


/martin



> 
> Please state either:
> 
> "No, I'm not aware of any IPR that applies to this draft"
> or
> "Yes, I'm aware of IPR that applies to this draft"
> 
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3669, 5378 and 8179 for more details)?
> 
> If yes to the above, please state either:
> 
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
> 
> If you answer no, please provide any additional details you think
> appropriate.
> 
> If you are listed as a document author or contributor please answer the
> above by responding to this email regardless of whether or not you are
> aware of any relevant IPR. This document will not advance to the next
> stage until a response has been received from each author and listed
> contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
> TO LINES.
> 
> If you are on the WG email list or attend WG meetings but are not listed
> as an author or contributor, we remind you of your obligations under
> the IETF IPR rules which encourages you to notify the IETF if you are
> aware of IPR of others on an IETF contribution, or to refrain from
> participating in any contribution or discussion related to your
> undisclosed IPR. For more information, please see the RFCs listed above
> and
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
> 
> Thank you,
> NetMod WG Chairs
> 
> PS Please include all listed in the headers of this message in your
> response.
> 
> 
> 


From nobody Mon Sep 18 06:50:26 2017
Return-Path: 
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 8521C134231 for ; Mon, 18 Sep 2017 06:50:25 -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 ZYvhqKJwWxLS for ; Mon, 18 Sep 2017 06:50:23 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4470813202D for ; Mon, 18 Sep 2017 06:50:19 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 600361AE0312; Mon, 18 Sep 2017 15:50:18 +0200 (CEST)
Date: Mon, 18 Sep 2017 15:48:47 +0200 (CEST)
Message-Id: <20170918.154847.1778955260935757882.mbj@tail-f.com>
To: lberger@labn.net
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Regarding IPR on draft-bjorklund-netmod-rfc7277bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Sep 2017 13:50:25 -0000

Lou Berger  wrote:
> Authors, Contributors, WG,
> 
> As part of the preparation for WG Last Call:
> 
> Are you aware of any IPR that applies to drafts identified above?

No, I'm not aware of any IPR that applies to this draft


/martin



> 
> Please state either:
> 
> "No, I'm not aware of any IPR that applies to this draft"
> or
> "Yes, I'm aware of IPR that applies to this draft"
> 
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3669, 5378 and 8179 for more details)?
> 
> If yes to the above, please state either:
> 
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
> 
> If you answer no, please provide any additional details you think
> appropriate.
> 
> If you are listed as a document author or contributor please answer the
> above by responding to this email regardless of whether or not you are
> aware of any relevant IPR. This document will not advance to the next
> stage until a response has been received from each author and listed
> contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
> TO LINES.
> 
> If you are on the WG email list or attend WG meetings but are not listed
> as an author or contributor, we remind you of your obligations under
> the IETF IPR rules which encourages you to notify the IETF if you are
> aware of IPR of others on an IETF contribution, or to refrain from
> participating in any contribution or discussion related to your
> undisclosed IPR. For more information, please see the RFCs listed above
> and
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
> 
> Thank you,
> NetMod WG Chairs
> 
> PS Please include all listed in the headers of this message in your
> response.
> 
> 
> 


From nobody Mon Sep 18 06:55:43 2017
Return-Path: 
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 D44DC134265 for ; Mon, 18 Sep 2017 06:55:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 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, 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 10f2CvSv2_Ot for ; Mon, 18 Sep 2017 06:55:41 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD44C1331DC for ; Mon, 18 Sep 2017 06:55:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2538; q=dns/txt; s=iport; t=1505742940; x=1506952540; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SaRlQsjWD3xkQz3SQDv0yQFf42apMH5S32nxh8JhPuI=; b=HtzQ5PT6VgYkNGmuzDCke/4/57KfHWgC9tFx1fqaqXkmlTuhcfkNDA7O XiO0HUdvdBXzfPj0Cbdl7TCEyrGQo78e0+2Mzg5GsKFvTfCxEnIgasHio zjk6+iOvWylkijjbInQhuxGKXrVmaqr66xfWHc2zwEbvHv3DqrdgTyEVx o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbAQAzz79Z/5JdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbicHg26aFpgoggQKI4UYAhqELEIVAQIBAQEBAQEBayiFGQY?= =?us-ascii?q?jEUAFEAIBCA4MAiYCAgIwFRACBAENBYozEKozgieLKQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAR2BDoIdggKDM4MohEUBEgEfgxOCYAEEoQgCh1mMeoITW4UPinuVCAI?= =?us-ascii?q?RGQGBOAE1IoECC3cVSYccdgGFYIEjgQ8BAQE?=
X-IronPort-AV: E=Sophos;i="5.42,413,1500940800"; d="scan'208";a="286429578"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Sep 2017 13:55:40 +0000
Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v8IDtdau015482 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 Sep 2017 13:55:39 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 18 Sep 2017 09:55:38 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1263.000; Mon, 18 Sep 2017 09:55:38 -0400
From: "Acee Lindem (acee)" 
To: Lou Berger , Ladislav Lhotka , "Yingzhen Qu" 
CC: NetMod WG 
Thread-Topic: Regarding IPR on draft-acee-netmod-rfc8022bis-02
Thread-Index: AQHTMITNQDV4AdJmP0KfuG8ktzGDDKK6qocA
Date: Mon, 18 Sep 2017 13:55:38 +0000
Message-ID: 
References: <7205a700-f00a-13f1-1941-46d578e38a27@labn.net>
In-Reply-To: <7205a700-f00a-13f1-1941-46d578e38a27@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.196]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] Regarding IPR on draft-acee-netmod-rfc8022bis-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Sep 2017 13:55:43 -0000

QXMgYSBjby1hdXRob3IsIA0KDQpObywgSSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBw
bGllcyB0byB0aGlzIGRyYWZ0Lg0KDQoNClRoYW5rcywNCkFjZWUgDQoNCk9uIDkvMTgvMTcsIDk6
NDggQU0sICJMb3UgQmVyZ2VyIiA8bGJlcmdlckBsYWJuLm5ldD4gd3JvdGU6DQoNCj5BdXRob3Jz
LCBDb250cmlidXRvcnMsIFdHLA0KPg0KPkFzIHBhcnQgb2YgdGhlIHByZXBhcmF0aW9uIGZvciBX
RyBMYXN0IENhbGw6DQo+DQo+QXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0
byBkcmFmdHMgaWRlbnRpZmllZCBhYm92ZT8NCj4NCj5QbGVhc2Ugc3RhdGUgZWl0aGVyOg0KPg0K
PiJObywgSSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0
Ig0KPm9yDQo+IlllcywgSSdtIGF3YXJlIG9mIElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFm
dCINCj4NCj5JZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ug
d2l0aCBJRVRGIElQUiBydWxlcw0KPihzZWUgUkZDcyAzNjY5LCA1Mzc4IGFuZCA4MTc5IGZvciBt
b3JlIGRldGFpbHMpPw0KPg0KPklmIHllcyB0byB0aGUgYWJvdmUsIHBsZWFzZSBzdGF0ZSBlaXRo
ZXI6DQo+DQo+IlllcywgdGhlIElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3
aXRoIElFVEYgSVBSIHJ1bGVzIg0KPm9yDQo+Ik5vLCB0aGUgSVBSIGhhcyBub3QgYmVlbiBkaXNj
bG9zZWQiDQo+DQo+SWYgeW91IGFuc3dlciBubywgcGxlYXNlIHByb3ZpZGUgYW55IGFkZGl0aW9u
YWwgZGV0YWlscyB5b3UgdGhpbmsNCj5hcHByb3ByaWF0ZS4NCj4NCj5JZiB5b3UgYXJlIGxpc3Rl
ZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgYW5zd2VyIHRoZQ0K
PmFib3ZlIGJ5IHJlc3BvbmRpbmcgdG8gdGhpcyBlbWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIg
b3Igbm90IHlvdSBhcmUNCj5hd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLiBUaGlzIGRvY3VtZW50
IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5leHQNCj5zdGFnZSB1bnRpbCBhIHJlc3BvbnNlIGhh
cyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGxpc3RlZA0KPmNvbnRyaWJ1dG9y
LiBOT1RFOiBUSElTIEFQUExJRVMgVE8gQUxMIE9GIFlPVSBMSVNURUQgSU4gVEhJUyBNRVNTQUdF
J1MNCj5UTyBMSU5FUy4NCj4NCj5JZiB5b3UgYXJlIG9uIHRoZSBXRyBlbWFpbCBsaXN0IG9yIGF0
dGVuZCBXRyBtZWV0aW5ncyBidXQgYXJlIG5vdCBsaXN0ZWQNCj5hcyBhbiBhdXRob3Igb3IgY29u
dHJpYnV0b3IsIHdlIHJlbWluZCB5b3Ugb2YgeW91ciBvYmxpZ2F0aW9ucyB1bmRlcg0KPnRoZSBJ
RVRGIElQUiBydWxlcyB3aGljaCBlbmNvdXJhZ2VzIHlvdSB0byBub3RpZnkgdGhlIElFVEYgaWYg
eW91IGFyZQ0KPmF3YXJlIG9mIElQUiBvZiBvdGhlcnMgb24gYW4gSUVURiBjb250cmlidXRpb24s
IG9yIHRvIHJlZnJhaW4gZnJvbQ0KPnBhcnRpY2lwYXRpbmcgaW4gYW55IGNvbnRyaWJ1dGlvbiBv
ciBkaXNjdXNzaW9uIHJlbGF0ZWQgdG8geW91cg0KPnVuZGlzY2xvc2VkIElQUi4gRm9yIG1vcmUg
aW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIFJGQ3MgbGlzdGVkIGFib3ZlDQo+YW5kDQo+aHR0
cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvZ3JvdXAvaWVzZy90cmFjL3dpa2kvSW50ZWxsZWN0dWFs
UHJvcGVydHkuDQo+DQo+VGhhbmsgeW91LA0KPk5ldE1vZCBXRyBDaGFpcnMNCj4NCj5QUyBQbGVh
c2UgaW5jbHVkZSBhbGwgbGlzdGVkIGluIHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2FnZSBpbiB5
b3VyDQo+cmVzcG9uc2UuDQo+DQo+DQo+DQoNCg==


From nobody Mon Sep 18 07:03:45 2017
Return-Path: 
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 9F383134265; Mon, 18 Sep 2017 07:03:44 -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 i8-lui0sWFHH; Mon, 18 Sep 2017 07:03:43 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3509C133188; Mon, 18 Sep 2017 07:03:43 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 87CD91AE00A0; Mon, 18 Sep 2017 16:03:41 +0200 (CEST)
Date: Mon, 18 Sep 2017 16:02:10 +0200 (CEST)
Message-Id: <20170918.160210.2297632484512263571.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
Cc: rwilton@cisco.com, ietfc@btconnect.com, lberger@labn.net, netmod@ietf.org, netmod-chairs@ietf.org, draft-ietf-netmod-revised-datastores@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20170918102614.ydoh6xvva3ppzmuf@elstar.local>
References: <009e01d32ff4$345b4a00$4001a8c0@gateway.2wire.net> <2ab1ed32-f499-b6f6-b619-44b46f0c0019@cisco.com> <20170918102614.ydoh6xvva3ppzmuf@elstar.local>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 inactive
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Sep 2017 14:03:45 -0000

Juergen Schoenwaelder  wrote:
> On Mon, Sep 18, 2017 at 11:14:55AM +0100, Robert Wilton wrote:
> > =

> > =

> > On 17/09/2017 21:21, t.petch wrote:
> > > ----- Original Message -----
> > > From: "Juergen Schoenwaelder" 
> > > Sent: Friday, September 15, 2017 6:09 PM
> > > =

> > > =

> > > > Two comments:
> > > > =

> > > > - Obviously, inactive can be in  and I would not rul=
e out
> > > >    that inactive configuration can be in any other or future
> > > >    configuration datastores.
> > > > =

> > > > - Whether protocols support inactive or not does not belong int=
o a
> > > >    definition of what inactive configuration is. The same for b=
ackwards
> > > >    compatibility considerations etc.
> > > > =

> > > > So if we define inactive configuration, the definition should b=
e
> > > > something like this:
> > > > =

> > > > * inactive configuration: Configuration held in a configuration=

> > > >    datastore that is marked to be inactive. Inactive configurat=
ion is
> > > >    ignored during validation and never applied and actively use=
d by
> > > >    a device.
> > > > =

> > > > Yes, we should use 'inactive configuration' everywhere to be
> > > consistent.
> > > =

> > > Juergen
> > > =

> > > Yes, your definition is better than mine; let's add it.
> > I'm not necessarily opposed to this, but I think that we want to be=
 careful
> > here.=A0 Inactive configuration and templating are only meant to be=
 examples
> > of how  could differ from , and we really aren't=
 trying
> > to provide normative definitions of them.=A0 Is putting a definitio=
n of
> > 'inactive configuration' in this draft going to potentially cause p=
roblems
> > for a future 'inactive configuration' extension that could possibly=
 want to
> > define the term differently?
> =

> Yes, my preference would be to leave the definition of inactive
> configuration to a future draft.

+1

Since Andy raised a similar issue for templates, maybe we need to make
it more clear that both inactive and templates are really just
examples of things that can influence what goes into  from
.

> > If we do decide to incorporate a definition, I would suggest at lea=
st
> > tweaking it slightly to avoid the possible ambiguity of the last ph=
rase:
> > =

> > * inactive configuration: Configuration held in a configuration
> >   datastore that is marked to be inactive. Inactive configuration i=
s
> >   ignored during validation, never applied, and not actively used b=
y
> >   a device.
> >
> =

> Yes, this is better (if we have to define this). It all boils down:
> =

> a) We publish an architecture which enables future standardization
>    work on things we know exist in real implementations.
> =

> b) We strictly limit us to what we define right now and this means
>    that the architecture does not describe what some real
>    implementations do and we have to revise the architecure should
>    future work started to standardize such things.
> =

> For simple inactive configuration, I do see an opportunity for a
> standard solution and hence I think what the revised datastores I-D
> proposes makes a lot of sense (but then I am of course biased here).
> It provides an architectural framework that enabled a further
> evolution without having to change the architectural framework again.=


I also prefer (a).  If we did (b) without any additional explanation,
it would be quite unclear why we even bother to define .


/martin


From nobody Mon Sep 18 07:17:50 2017
Return-Path: 
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 B01EB1331C1 for ; Mon, 18 Sep 2017 07:17:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level: 
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] 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 7ja_xH3y5MUO for ; Mon, 18 Sep 2017 07:17:47 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 DF4E3134294 for ; Mon, 18 Sep 2017 07:17:44 -0700 (PDT)
Received: from birdie13 (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 7CD5B617DF; Mon, 18 Sep 2017 16:17:41 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1505744261; bh=Aw6wG2wd5cBrrTgiFm+HgjXhoJHQWEh7QfmDnRST/8c=; h=From:To:Date; b=eblSpRNKCP8Yn8BvEZRmRfkJVB9tgF1GCUL6DXFhPEUsSAzZLT7b2ZgnZ3JhXuSin HS9gKs0qJfnzSwwAYGPAUMwDoP937pEYI8hG0QE1F5GyFmnLG5XehCv94ho6enN4GA 7W1XNBXI5GhJgL6JvY3F5wHH9L3IGPVGorlOfLgI=
Message-ID: <1505744300.26551.25.camel@nic.cz>
From: Ladislav Lhotka 
To: Lou Berger , Yingzhen Qu ,  Acee Lindem 
Cc: NetMod WG 
Date: Mon, 18 Sep 2017 16:18:20 +0200
In-Reply-To: <7205a700-f00a-13f1-1941-46d578e38a27@labn.net>
References: <7205a700-f00a-13f1-1941-46d578e38a27@labn.net>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.24.5 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] Regarding IPR on draft-acee-netmod-rfc8022bis-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Sep 2017 14:17:50 -0000

No, I'm not aware of any IPR that applies to this draft.

Lada

Lou Berger píše v Po 18. 09. 2017 v 09:48 -0400:
> Authors, Contributors, WG,
> 
> As part of the preparation for WG Last Call:
> 
> Are you aware of any IPR that applies to drafts identified above?
> 
> Please state either:
> 
> "No, I'm not aware of any IPR that applies to this draft"
> or
> "Yes, I'm aware of IPR that applies to this draft"
> 
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3669, 5378 and 8179 for more details)?
> 
> If yes to the above, please state either:
> 
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
> 
> If you answer no, please provide any additional details you think
> appropriate.
> 
> If you are listed as a document author or contributor please answer the
> above by responding to this email regardless of whether or not you are
> aware of any relevant IPR. This document will not advance to the next
> stage until a response has been received from each author and listed
> contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
> TO LINES.
> 
> If you are on the WG email list or attend WG meetings but are not listed
> as an author or contributor, we remind you of your obligations under
> the IETF IPR rules which encourages you to notify the IETF if you are
> aware of IPR of others on an IETF contribution, or to refrain from
> participating in any contribution or discussion related to your
> undisclosed IPR. For more information, please see the RFCs listed above
> and
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
> 
> Thank you,
> NetMod WG Chairs
> 
> PS Please include all listed in the headers of this message in your
> response.
> 
> 
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Mon Sep 18 07:22:09 2017
Return-Path: 
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 6EE2A134289 for ; Mon, 18 Sep 2017 07:22:07 -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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8wLXIf6529A for ; Mon, 18 Sep 2017 07:22:05 -0700 (PDT)
Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::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 7D0C41331F1 for ; Mon, 18 Sep 2017 07:22:02 -0700 (PDT)
Received: by mail-lf0-x234.google.com with SMTP id a18so694813lfl.13 for ; Mon, 18 Sep 2017 07:22:02 -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=s1tMDhmVQqAaKH6dUDisHKUoShIo1tTvXEBdS134kvc=; b=piWml0GL9UemWYghU4meTuujS50HDogmnMW5LSJZdn5h2QLtWqPnvx64+Iz1XDFVPe zH0WUIzI4XmqoIExFqtVH+j5fh9h8oLDPXhB9dEkcLfCr3M2myeo+aTpL340O3geCt3L cCTl/xpvoXqd/GLU00emfofmITtl82PgA5acjEeridilr2tHMGLmFSagAZT1WQb3OFeE +IAlHcpRmT/fKP1K2Btg5OiAN+plFxSu+ZL1N/pH5dgZGwGAPtgOPnNDYc/v9YlBJ47D A/jgR+WDgKdaKIgIWB795jFEf+3chA0mwfQZaTL44k5BDJyoDISvrCEgqBgR/fcfL5pM kMdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=s1tMDhmVQqAaKH6dUDisHKUoShIo1tTvXEBdS134kvc=; b=K0XZxXrumbcOGKFQscJ6X2nuqtXMWbg3lHgjSfT0mXaI4D4UALgE2/WESyE3eI+Bkk 2zJb4jjFkBY6ine6FBlxTycIm/YYLhsRPOT/NZ02brfxYz0fch9wT7yPIZBrdV9AGRsN vwobCWyqozLpkJsH9oR0LB6Yv8wMJG4mU6jJGGOuEiWNhhHKHm+S4VLNL8/y0DK7WUej umtk3Bh5+bBXunNcoTtb9VV4Mk2sDo25o1++KGF/xqUWKb99bQ37S2EkIna9MUuX1UBj b70p3t0ebzUkM6GV8YioXqaCYwUXgRRWryrbytMb3KgTY7CcYGhhf7pZPYhn4CDM2Trt eAEA==
X-Gm-Message-State: AHPjjUh49LRYKJeRnNti279G+WevGhhPJV73ajpixQslKq3g8Dd+GJIw Wxqa09K4y3P1WPPHCIvJN/P8+K6j7jkqLLp/XLQw8g==
X-Google-Smtp-Source: AOwi7QDA0U28vKBESm2ZYCbRVyn+9EDyM2jXppUPptkotyrtoC/L8LyJvF1Sv/QcoplOYmT1n5C6c/leTjIhMEhQvGk=
X-Received: by 10.46.77.157 with SMTP id c29mr4066596ljd.14.1505744520597; Mon, 18 Sep 2017 07:22:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.18.41 with HTTP; Mon, 18 Sep 2017 07:21:59 -0700 (PDT)
In-Reply-To: 
References:  <20170916072403.xp37556z6g7b42gr@elstar.local>  <20170917.154115.791964858062115650.mbj@tail-f.com>  
From: Andy Bierman 
Date: Mon, 18 Sep 2017 07:21:59 -0700
Message-ID: 
To: Robert Wilton 
Cc: Martin Bjorklund ,  Juergen Schoenwaelder , "t.petch" ,  Berger Lou , "netmod@ietf.org" ,  NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c1aba684607a4055977776b"
Archived-At: 
Subject: Re: [netmod]  vs  [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Sep 2017 14:22:07 -0000

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

On Mon, Sep 18, 2017 at 2:28 AM, Robert Wilton  wrote:

> Hi Andy,
>
> At the moment, NMDA does not change the definition of  for a
> standards compliant implementation of YANG/NETCONF/RESTCONF.  It is still
> the same as in 7950, and  must still be a "valid configuration
> data tree" for a standards complaint implementation.
>
> However, the draft acknowledges that proprietary extensions exist that can
> modify the behaviour of  in ways that means that  is not
> always a valid configuration data tree.  The draft gives two examples of
> how  could be manipulated (inactive config, and templates).
>

I don't see how NMDA can both acknowledge and violate the MUST be valid in
RFC 7950.
That statement is quite clear in RFC 7950.



> If those extensions are standardized then I think it is likely that those
> RFCs would need to update 7950 to indicate that  isn't necessarily
> a "valid configuration data tree" when those extensions are used.  But I
> don't think that needs to be stated in the NMDA architecture at this time.
>

 Right -- because 7950 still holds any any server that does not have a
valid 
is non-compliant to 7950.


Andy


>
So, what is ?
>  - this is meant to represent the configuration that the system will
> actually attempt to apply after any and all manipulation (e.g. by
> templates, inactive removal, perhaps system scripts, etc) of the
> configuration has been performed.
>  - it must always be a valid configuration data tree.
>  - If  is updated then  is always updated at the same
> time.  Hence, any successful change to  requires that 
> has also been updated and validated.  E.g. in RESTCONF terms, I think that
> both  and   should get the same last-change timestamp
> whenever  is updated.
>  - It provides a known fixed point so that any client can see the full
> validated config, i.e. even for devices that implement proprietary
> manipulations of the configuring in .
>  - If the device doesn't support any extra proprietary config
> manipulations, then  is identical to .
>
> I think that we can possibly do a bit more to better define what  is>.  My previous suggestion as an improvement was below (perhaps you think
> it needs more clarification)?:
>
> *OLD:*
>
> 4.4.  The Intended Configuration Datastore ()
>
>    The intended configuration datastore () is a read-only
>    configuration datastore.  It is tightly coupled to .  When
>    data is written to , the data that is to be validated is
>    also conceptually written to .  Validation is performed on
>    the contents of .
>
>    For simple implementations,  and  are identical.
>
>     does not persist across reboots; its relationship with
>     makes that unnecessary.
>
>    ...
>
> *NEW:*
>
> 4.4.  The Intended Configuration Datastore ()
>
>    The intended configuration datastore () is a read-only
>    configuration datastore.  It represents the configuration after all
>    configuration transformations to  are performed (e.g.
>    template expansion, inactive configuration removal), and is the
>    configuration that the system attempts to apply.
>
>    It is tightly coupled to .  When data is written to
>    , the data that is to be validated is also conceptually
>    written to .  Validation is performed on the contents of
>    .
>
>    For simple implementations,  and  are identical.
>
>    The contents of  is also related to the 'config true'
>    subset of , and hence a client can determine to what
>    extent the intended configuration is currently applied by checking
>    whether the contents of  also appears in .
>
>     does not persist across reboots; its relationship with
>     makes that unnecessary.
>    ...
>
> Thanks,
> Rob
>
> On 17/09/2017 16:31, Andy Bierman wrote:
>
> Hi,
>
> My concern is that the definition of  is being changed to
> include undefined and undeclared proprietary extensions.
> This is counter-productive to the IETF's stated goal of interoperability.
>
>
> Andy
>
>
> On Sun, Sep 17, 2017 at 6:41 AM, Martin Bjorklund  wrote:
>
>> Andy Bierman  wrote:
>> > On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder <
>> > j.schoenwaelder@jacobs-university.de> wrote:
>> >
>> > > On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
>> > > > Hi,
>> > > >
>> > > > I strongly agree with Tom that the current draft is an update to RFC
>> > > 7950.
>> > > > I also strongly disagree with the decision to omit RFC 2119 in a
>> > > standards
>> > > > track document. IMO RFC 2119 terms need to be used in normative
>> text,
>> > > > especially when dealing with XPath and YANG compiler behavior.
>> > > >
>> > >
>> > > RFC 8174:
>> > >
>> > >    o  These words can be used as defined here, but using them is not
>> > >       required.  Specifically, normative text does not require the use
>> > >       of these key words.  They are used for clarity and consistency
>> > >       when that is what's wanted, but a lot of normative text does not
>> > >       use them and is still normative.
>> > >
>> > >
>> > So what?
>> > Existing YANG specifications use RFC 2119 terms.
>> > This draft uses those terms, just with lower-case.
>>
>> Actually, section 5.1 XPath Context in the revised datastore draft
>> uses the same language as section 6.4.1 XPath Context in RFC 7950.  In
>> fact, the text in the draft is copied (and adjusted) from RFC 7950.
>>
>>
>> /martin
>>
>
>
>

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




On Mon, Sep 18, 2017 at 2:28 AM, Robert Wilton <rwilton@cisco.com&=
gt; wrote:

 =20
   =20
 =20
  

    
Hi Andy,

    
At the moment, NMDA does not change the definition of
      <running> for a standards compliant implementation of
      YANG/NETCONF/RESTCONF.=C2=A0 It is still the same as in 7950, and
      <running> must still be a "valid configuration data tree&q=
uot;
      for a standards complaint implementation.

    

    
However, the draft acknowledges that proprietary extensions exist
      that can modify the behaviour of <running> in ways that
      means that <running> is not always a valid configuration
      data tree.=C2=A0 The draft gives two examples of how <running>
      could be manipulated (inactive config, and templates).
<=
/blockquote>

I don't see how NMDA can both acknowled=
ge and violate the MUST be valid in RFC 7950.
That statement is q=
uite clear in RFC 7950.

=C2=A0

    

    
If those extensions are standardized then I think it is likely
      that those RFCs would need to update 7950 to indicate that
      <running> isn't necessarily a "valid configuration dat=
a
      tree" when those extensions are used.=C2=A0 But I don't thin=
k that
      needs to be stated in the NMDA architecture at this time.

=C2=A0Right -- because 7950 still holds any =
any server that does not have a valid <running>
is non-=
compliant to 7950. =C2=A0


Andy

=C2=A0

    
So, what is <intended>?

      =C2=A0- this is meant to represent the configuration that the system
      will actually attempt to apply after any and all manipulation
      (e.g. by templates, inactive removal, perhaps system scripts, etc)
      of the configuration has been performed.

      =C2=A0- it must always be a valid configuration data tree.

      =C2=A0- If <running> is updated then <intended> is always
      updated at the same time.=C2=A0 Hence, any successful change to
      <running> requires that <intended> has also been
      updated and validated.=C2=A0 E.g. in RESTCONF terms, I think that bot=
h
      <running> and=C2=A0 <intended> should get the same
      last-change timestamp whenever <running> is updated.

      =C2=A0- It provides a known fixed point so that any client can see th=
e
      full validated config, i.e. even for devices that implement
      proprietary manipulations of the configuring in <running>.

      =C2=A0- If the device doesn't support any extra proprietary confi=
g
      manipulations, then <intended> is identical to
      <running>.

    

    
I think that we can possibly do a bit more to better define what
      <intended is>.=C2=A0 My previous suggestion as an improvement w=
as
      below (perhaps you think it needs more clarification)?:

    
OLD:

    
4.4.=C2=A0 The Intended Configuration Datastore (<intended>=
;)

      

    
=C2=A0=C2=A0 The intended configuration datastore (<intended&=
gt;) is
        a read-only

      =C2=A0=C2=A0 configuration datastore.=C2=A0 It is tightly co=
upled to
        <running>.=C2=A0 When

      =C2=A0=C2=A0 data is written to <running>, the data th=
at is
        to be validated is

      =C2=A0=C2=A0 also conceptually written to <intended>.=
=C2=A0
        Validation is performed on

      =C2=A0=C2=A0 the contents of <intended>.

      

      =C2=A0=C2=A0 For simple implementations, <running> and
        <intended> are identical.

      

      =C2=A0=C2=A0 <intended> does not persist across reboot=
s; its
        relationship with

      =C2=A0=C2=A0 <running> makes that unnecessary.=C2=A0 <=
/tt>

      

      =C2=A0=C2=A0 ...

    

    
NEW:

    
4.4.=C2=A0 The Intended Configuration Datastore (<intended>=
;)

      

      =C2=A0=C2=A0 The intended configuration datastore
        (<intended>) is a read-only

      =C2=A0=C2=A0 configuration datastore.=C2=A0 It represents th=
e
        configuration after all

      =C2=A0=C2=A0 configuration transformations to <running>=
; are
        performed (e.g.

      =C2=A0=C2=A0 template expansion, inactive configuration remo=
val),
        and is the

      =C2=A0=C2=A0 configuration that the system attempts to apply=
.

      

      =C2=A0=C2=A0 It is tightly coupled to <running>.=C2=A0=
 When data
        is written to

      =C2=A0=C2=A0 <running>, the data that is to be validat=
ed is
        also conceptually

      =C2=A0=C2=A0 written to <intended>.=C2=A0 Validation i=
s performed
        on the contents of

      =C2=A0=C2=A0 <intended>.

      

      =C2=A0=C2=A0 For simple implementations, <running> and
        <intended> are identical.

      

      =C2=A0=C2=A0 The contents of <intended> is also relate=
d to
        the 'config true'

      =C2=A0=C2=A0 subset of <operational>, and hence a clie=
nt can
        determine to what

      =C2=A0=C2=A0 extent the intended configuration is currently =
applied
        by checking

      =C2=A0=C2=A0 whether the contents of <intended> also a=
ppears
        in <operational>.

      

      =C2=A0=C2=A0 <intended> does not persist across reboot=
s; its
        relationship with

      =C2=A0=C2=A0 <running> makes that unnecessary.
    =C2=A0=C2=A0 ...
    
Thanks,

      Rob

    

    

    
On 17/09/2017 16:31,=
 Andy Bierman
      wrote:

    

    

     =20
      
Hi,
        


        

        
My concern is that the definition of <running> is
          being changed to

        
include undefined and undeclared proprietary extensions.

        
This is counter-productive to the IETF's stated goal of
          interoperability.

        


        

        


        

        
Andy

        


        

      

      


        
On Sun, Sep 17, 2017 at 6:41 AM, Martin
          Bjorklund <mbj@tail-f.com>
          wrote:

          
Andy
            Bierman <andy@yumaworks.com> wrote:

            > On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder
            <

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

            >

            > > On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy
            Bierman wrote:

            > > > Hi,

            > > >

            > > > I strongly agree with Tom that the current
            draft is an update to RFC

            > > 7950.

            > > > I also strongly disagree with the decision to
            omit RFC 2119 in a

            > > standards

            > > > track document. IMO RFC 2119 terms need to be
            used in normative text,

            > > > especially when dealing with XPath and YANG
            compiler behavior.

            > > >

            > >

            > > RFC 8174:

            > >

            > >=C2=A0 =C2=A0 o=C2=A0 These words can be used as defin=
ed here, but
            using them is not

            > >=C2=A0 =C2=A0 =C2=A0 =C2=A0required.=C2=A0 Specificall=
y, normative text does
            not require the use

            > >=C2=A0 =C2=A0 =C2=A0 =C2=A0of these key words.=C2=A0 T=
hey are used for
            clarity and consistency

            > >=C2=A0 =C2=A0 =C2=A0 =C2=A0when that is what's wan=
ted, but a lot of
            normative text does not

            > >=C2=A0 =C2=A0 =C2=A0 =C2=A0use them and is still norma=
tive.

            > >

            > >

            > So what?

            > Existing YANG specifications use RFC 2119 terms.

            > This draft uses those terms, just with lower-case.

            

            Actually, section 5.1 XPath Context in the revised datastore
            draft

            uses the same language as section 6.4.1 XPath Context in RFC
            7950.=C2=A0 In

            fact, the text in the draft is copied (and adjusted) from
            RFC 7950.

            

                

                /martin

              

        

        

      

    

    

  






--94eb2c1aba684607a4055977776b--


From nobody Mon Sep 18 07:59:05 2017
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E6E13429A; Mon, 18 Sep 2017 07:59:04 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Secretariat 
To: , , 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.62.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150574674487.15655.6319416347982293597.idtracker@ietfa.amsl.com>
Date: Mon, 18 Sep 2017 07:59:04 -0700
Archived-At: 
Subject: [netmod] The NETMOD WG has placed draft-bjorklund-netmod-rfc7223bis in state "Candidate for WG Adoption"
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Sep 2017 14:59:05 -0000

The NETMOD WG has placed draft-bjorklund-netmod-rfc7223bis in state
Candidate for WG Adoption (entered by Lou Berger)

The document is available at
https://datatracker.ietf.org/doc/draft-bjorklund-netmod-rfc7223bis/

Comment:
IPR poll:
https://mailarchive.ietf.org/arch/msg/netmod/8qL7gWmwRtpZdwqP5vmUHEHM22g
Response: 
https://mailarchive.ietf.org/arch/msg/netmod/l-xk3PVHsTBQ8ZIApR8YQ_0LfAc


From nobody Mon Sep 18 08:02:46 2017
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E439134296; Mon, 18 Sep 2017 08:02:45 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Secretariat 
To: , , 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.62.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150574696525.15567.11493542251300060856.idtracker@ietfa.amsl.com>
Date: Mon, 18 Sep 2017 08:02:45 -0700
Archived-At: 
Subject: [netmod] The NETMOD WG has placed draft-bjorklund-netmod-rfc7277bis in state "Candidate for WG Adoption"
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Sep 2017 15:02:45 -0000

The NETMOD WG has placed draft-bjorklund-netmod-rfc7277bis in state
Candidate for WG Adoption (entered by Lou Berger)

The document is available at
https://datatracker.ietf.org/doc/draft-bjorklund-netmod-rfc7277bis/

Comment:
IPR Poll:
https://mailarchive.ietf.org/arch/msg/netmod/lFxzO0pjqxaVrT1x9hxHYL5rMwE IPR
Response:
https://mailarchive.ietf.org/arch/msg/netmod/Lx4u58m2jqbjTwFxoOkA-HLGBjI


From nobody Mon Sep 18 08:34:26 2017
Return-Path: 
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 3F0D41321A2; Mon, 18 Sep 2017 08:34:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 XumZhzQvpxxn; Mon, 18 Sep 2017 08:34:21 -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 709BF134291; Mon, 18 Sep 2017 08:34:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25102; q=dns/txt; s=iport; t=1505748860; x=1506958460; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=g+21SKw1oMc2CtuQ9zs+VYoBLRoubGPPewDmWwJLS3o=; b=mOYcHkOaQpz+r7lJ492vwXllx0/e0d80Xsz+upI6loW/FC7luqj2qNe+ Cm9vHlQj3Gb0d8xOaSYoEnQ5PYobUSrQNsnsB4g4o1sZJh2mvd+2OHfIV A9tjGD5BdlKWAajpi1lVwiYAQgy0UnLPGe0/OTlQvaCQIAIsbeNsN+HwQ E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C1AQD25r9Z/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhSwng3WLFJBLCSKWJoISCoQrgRAChQcXAQIBAQEBAQEBayiFGAE?= =?us-ascii?q?BAQECASNPBxAJAhACBiADBAMCAkYDDgYNBgIBAYonCIwxnWaCJyeLBQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAR2DK4NSgWMrC4JyhGJMgl2CYAWYQIhIlFWCE4lEJIZ?= =?us-ascii?q?9igCDXodXgTkhATVBTDIhCBwVhheBTz82hVQrghQBAQE?=
X-IronPort-AV: E=Sophos;i="5.42,413,1500940800";  d="scan'208,217";a="657553748"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Sep 2017 15:34:18 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v8IFYHNT000481; Mon, 18 Sep 2017 15:34:17 GMT
To: Andy Bierman 
Cc: Martin Bjorklund , Juergen Schoenwaelder , "t.petch" , Berger Lou , "netmod@ietf.org" , NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org
References:  <20170916072403.xp37556z6g7b42gr@elstar.local>  <20170917.154115.791964858062115650.mbj@tail-f.com>   
From: Robert Wilton 
Message-ID: <70a5b659-83a3-5952-b5e7-b8e991c84ef1@cisco.com>
Date: Mon, 18 Sep 2017 16:34:17 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------26DC4F0C8AFF300D3BDE436C"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod]  vs  [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Sep 2017 15:34:24 -0000

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



On 18/09/2017 15:21, Andy Bierman wrote:
>
>
> On Mon, Sep 18, 2017 at 2:28 AM, Robert Wilton  > wrote:
>
>     Hi Andy,
>
>     At the moment, NMDA does not change the definition of 
>     for a standards compliant implementation of
>     YANG/NETCONF/RESTCONF.  It is still the same as in 7950, and
>      must still be a "valid configuration data tree" for a
>     standards complaint implementation.
>
>     However, the draft acknowledges that proprietary extensions exist
>     that can modify the behaviour of  in ways that means that
>      is not always a valid configuration data tree.  The
>     draft gives two examples of how  could be manipulated
>     (inactive config, and templates).
>
>
> I don't see how NMDA can both acknowledge and violate the MUST be 
> valid in RFC 7950.
> That statement is quite clear in RFC 7950.
I think that NMDA acknowledges non standard extensions could exist that 
would violate RFC 7950 if/when those features are used, and provides a 
standard architecture (i.e. the definition of ) to allow 
devices to expose the effects of those bespoke features in a standard way.

Phil had proposed adding the following text on validation:

+The implication of the existence of templating mechanisms is that
+ is now explicitly allowed to be invalid, since the
+templating mechanism may be supplying additional data that satisfies
+constraints that may not be satisfied by  itself.

Do you think that text like this would help?  Or perhaps more 
generically, something like this:

The implication of the existence of mechanisms that can allow
 to differ from  means that  is no
longer guaranteed to always be valid.  However, when any
change is made to ,  must also be updated at
the same time and be successfully validated before the operation
on  can be completed.

Obviously this would then need to update 7950.

>
>     If those extensions are standardized then I think it is likely
>     that those RFCs would need to update 7950 to indicate that
>      isn't necessarily a "valid configuration data tree" when
>     those extensions are used.  But I don't think that needs to be
>     stated in the NMDA architecture at this time.
>
>
>  Right -- because 7950 still holds any any server that does not have a 
> valid 
> is non-compliant to 7950.
I agree.

Thanks,
Rob

>
>
> Andy
>
>     So, what is ?
>      - this is meant to represent the configuration that the system
>     will actually attempt to apply after any and all manipulation
>     (e.g. by templates, inactive removal, perhaps system scripts, etc)
>     of the configuration has been performed.
>      - it must always be a valid configuration data tree.
>      - If  is updated then  is always updated at
>     the same time.  Hence, any successful change to  requires
>     that  has also been updated and validated. E.g. in
>     RESTCONF terms, I think that both  and   should
>     get the same last-change timestamp whenever  is updated.
>      - It provides a known fixed point so that any client can see the
>     full validated config, i.e. even for devices that implement
>     proprietary manipulations of the configuring in .
>      - If the device doesn't support any extra proprietary config
>     manipulations, then  is identical to .
>
>     I think that we can possibly do a bit more to better define what
>     .  My previous suggestion as an improvement was below
>     (perhaps you think it needs more clarification)?:
>
>     *OLD:*
>
>     4.4.  The Intended Configuration Datastore ()
>
>        The intended configuration datastore () is a read-only
>        configuration datastore.  It is tightly coupled to .  When
>        data is written to , the data that is to be validated is
>        also conceptually written to .  Validation is
>     performed on
>        the contents of .
>
>        For simple implementations,  and  are identical.
>
>         does not persist across reboots; its relationship with
>         makes that unnecessary.
>
>        ...
>
>     *NEW:*
>
>     4.4.  The Intended Configuration Datastore ()
>
>        The intended configuration datastore () is a read-only
>        configuration datastore.  It represents the configuration after all
>        configuration transformations to  are performed (e.g.
>        template expansion, inactive configuration removal), and is the
>        configuration that the system attempts to apply.
>
>        It is tightly coupled to . When data is written to
>        , the data that is to be validated is also conceptually
>        written to .  Validation is performed on the contents of
>        .
>
>        For simple implementations,  and  are identical.
>
>        The contents of  is also related to the 'config true'
>        subset of , and hence a client can determine to what
>        extent the intended configuration is currently applied by checking
>        whether the contents of  also appears in .
>
>         does not persist across reboots; its relationship with
>         makes that unnecessary.
>
>        ...
>
>     Thanks,
>     Rob
>
>
>     On 17/09/2017 16:31, Andy Bierman wrote:
>>     Hi,
>>
>>     My concern is that the definition of  is being changed to
>>     include undefined and undeclared proprietary extensions.
>>     This is counter-productive to the IETF's stated goal of
>>     interoperability.
>>
>>
>>     Andy
>>
>>
>>     On Sun, Sep 17, 2017 at 6:41 AM, Martin Bjorklund >     > wrote:
>>
>>         Andy Bierman >
>>         wrote:
>>         > On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder <
>>         > j.schoenwaelder@jacobs-university.de
>>         > wrote:
>>         >
>>         > > On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
>>         > > > Hi,
>>         > > >
>>         > > > I strongly agree with Tom that the current draft is an
>>         update to RFC
>>         > > 7950.
>>         > > > I also strongly disagree with the decision to omit RFC
>>         2119 in a
>>         > > standards
>>         > > > track document. IMO RFC 2119 terms need to be used in
>>         normative text,
>>         > > > especially when dealing with XPath and YANG compiler
>>         behavior.
>>         > > >
>>         > >
>>         > > RFC 8174:
>>         > >
>>         > >    o  These words can be used as defined here, but using
>>         them is not
>>         > >       required.  Specifically, normative text does not
>>         require the use
>>         > >       of these key words.  They are used for clarity and
>>         consistency
>>         > >       when that is what's wanted, but a lot of normative
>>         text does not
>>         > >       use them and is still normative.
>>         > >
>>         > >
>>         > So what?
>>         > Existing YANG specifications use RFC 2119 terms.
>>         > This draft uses those terms, just with lower-case.
>>
>>         Actually, section 5.1 XPath Context in the revised datastore
>>         draft
>>         uses the same language as section 6.4.1 XPath Context in RFC
>>         7950.  In
>>         fact, the text in the draft is copied (and adjusted) from RFC
>>         7950.
>>
>>
>>         /martin
>>
>>
>
>


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


  
    
  
  
    


    

    

    
On 18/09/2017 15:21, Andy Bierman
      wrote:

    

    

      
      


        


          
On Mon, Sep 18, 2017 at 2:28 AM,
            Robert Wilton <rwilton@cisco.com>
            wrote:

            

              

                
Hi Andy,

                
At the moment, NMDA does not change the definition of
                  <running> for a standards compliant
                  implementation of YANG/NETCONF/RESTCONF.  It is still
                  the same as in 7950, and <running> must still be
                  a "valid configuration data tree" for a standards
                  complaint implementation.

                

                
However, the draft acknowledges that proprietary
                  extensions exist that can modify the behaviour of
                  <running> in ways that means that
                  <running> is not always a valid configuration
                  data tree.  The draft gives two examples of how
                  <running> could be manipulated (inactive config,
                  and templates).

                

              

            

            


            

            
I don't see how NMDA can both acknowledge and violate
              the MUST be valid in RFC 7950.

            
That statement is quite clear in RFC 7950.

          

        

      

    

    I think that NMDA acknowledges non standard extensions could exist
    that would violate RFC 7950 if/when those features are used, and
    provides a standard architecture (i.e. the definition of
    <intended>) to allow devices to expose the effects of those
    bespoke features in a standard way.

    

    Phil had proposed adding the following text on validation:

    

    +The implication of the existence of templating mechanisms is
      that

    +<running> is now explicitly allowed to be invalid,
      since the

    +templating mechanism may be supplying additional data that
      satisfies

    +constraints that may not be satisfied by <running>
      itself.

    

    Do you think that text like this would help?  Or perhaps more
    generically, something like this:

    

    The implication of the existence of mechanisms that can allow

      <intended> to differ from <running> means that
      <running> is no

      longer guaranteed to always be valid.  However, when any

      change is made to <running>, <intended> must also be
      updated at

      the same time and be successfully validated before the operation

      on <running> can be completed.

      

      Obviously this would then need to update 7950.

    

    

      

        

          

            


            

            
 

            

              

                
 

                
If those extensions are standardized then I think it
                  is likely that those RFCs would need to update 7950 to
                  indicate that <running> isn't necessarily a
                  "valid configuration data tree" when those extensions
                  are used.  But I don't think that needs to be stated
                  in the NMDA architecture at this time.

              

            

            


            

            
 Right -- because 7950 still holds any any server that
              does not have a valid <running>

            

            
is non-compliant to 7950.  

            

          

        

      

    

    I agree.

    

    Thanks,

    Rob

    

    

      

        

          

            


            

            


            

            
Andy

            


            

            

              

                
 

              

            

            

              

                
So, what is <intended>?

                   - this is meant to represent the configuration that
                  the system will actually attempt to apply after any
                  and all manipulation (e.g. by templates, inactive
                  removal, perhaps system scripts, etc) of the
                  configuration has been performed.

                   - it must always be a valid configuration data tree.

                   - If <running> is updated then <intended>
                  is always updated at the same time.  Hence, any
                  successful change to <running> requires that
                  <intended> has also been updated and validated. 
                  E.g. in RESTCONF terms, I think that both
                  <running> and  <intended> should get the
                  same last-change timestamp whenever <running> is
                  updated.

                   - It provides a known fixed point so that any client
                  can see the full validated config, i.e. even for
                  devices that implement proprietary manipulations of
                  the configuring in <running>.

                   - If the device doesn't support any extra proprietary
                  config manipulations, then <intended> is
                  identical to <running>.

                

                
I think that we can possibly do a bit more to better
                  define what <intended is>.  My previous
                  suggestion as an improvement was below (perhaps you
                  think it needs more clarification)?:

                
OLD:

                
4.4.  The Intended Configuration Datastore
                    (<intended>)

                  

                
   The intended configuration datastore
                    (<intended>) is a read-only

                     configuration datastore.  It is tightly
                    coupled to <running>.  When

                     data is written to <running>, the
                    data that is to be validated is

                     also conceptually written to
                    <intended>.  Validation is performed on

                     the contents of <intended>.

                  

                     For simple implementations,
                    <running> and <intended> are identical.

                  

                     <intended> does not persist across
                    reboots; its relationship with

                     <running> makes that unnecessary.  

                  

                     ...

                

                
NEW:

                
4.4.  The Intended Configuration Datastore
                    (<intended>)

                  

                     The intended configuration datastore
                    (<intended>) is a read-only

                     configuration datastore.  It represents
                    the configuration after all

                     configuration transformations to
                    <running> are performed (e.g.

                     template expansion, inactive configuration
                    removal), and is the

                     configuration that the system attempts to
                    apply.

                  

                     It is tightly coupled to <running>. 
                    When data is written to

                     <running>, the data that is to be
                    validated is also conceptually

                     written to <intended>.  Validation
                    is performed on the contents of

                     <intended>.

                  

                     For simple implementations,
                    <running> and <intended> are identical.

                  

                     The contents of <intended> is also
                    related to the 'config true'

                     subset of <operational>, and hence a
                    client can determine to what

                     extent the intended configuration is
                    currently applied by checking

                     whether the contents of <intended>
                    also appears in <operational>.

                  

                     <intended> does not persist across
                    reboots; its relationship with

                     <running> makes that unnecessary.

                   ...
                
Thanks,

                  Rob

                

                

                
On
                  17/09/2017 16:31, Andy Bierman wrote:

                

                

                  
Hi,
                    


                    

                    
My concern is that the definition of
                      <running> is being changed to

                    
include undefined and undeclared proprietary
                      extensions.

                    
This is counter-productive to the IETF's stated
                      goal of interoperability.

                    


                    

                    


                    

                    
Andy

                    


                    

                  

                  


                    
On Sun, Sep 17, 2017 at
                      6:41 AM, Martin Bjorklund <mbj@tail-f.com>
                      wrote:

                      
Andy Bierman <andy@yumaworks.com>
                        wrote:

                        > On Sat, Sep 16, 2017 at 12:24 AM, Juergen
                        Schoenwaelder <

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

                        >

                        > > On Fri, Sep 15, 2017 at 02:07:58PM
                        -0700, Andy Bierman wrote:

                        > > > Hi,

                        > > >

                        > > > I strongly agree with Tom that
                        the current draft is an update to RFC

                        > > 7950.

                        > > > I also strongly disagree with the
                        decision to omit RFC 2119 in a

                        > > standards

                        > > > track document. IMO RFC 2119
                        terms need to be used in normative text,

                        > > > especially when dealing with
                        XPath and YANG compiler behavior.

                        > > >

                        > >

                        > > RFC 8174:

                        > >

                        > >    o  These words can be used as
                        defined here, but using them is not

                        > >       required.  Specifically,
                        normative text does not require the use

                        > >       of these key words.  They are
                        used for clarity and consistency

                        > >       when that is what's wanted, but
                        a lot of normative text does not

                        > >       use them and is still normative.

                        > >

                        > >

                        > So what?

                        > Existing YANG specifications use RFC 2119
                        terms.

                        > This draft uses those terms, just with
                        lower-case.

                        

                        Actually, section 5.1 XPath Context in the
                        revised datastore draft

                        uses the same language as section 6.4.1 XPath
                        Context in RFC 7950.  In

                        fact, the text in the draft is copied (and
                        adjusted) from RFC 7950.

                        

                            

                            /martin

                          

                    

                    

                  

                

                

              

            

          

          

        

      

    

    

  


--------------26DC4F0C8AFF300D3BDE436C--


From nobody Mon Sep 18 08:48:36 2017
Return-Path: 
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 39AF3133063 for ; Mon, 18 Sep 2017 08:48:35 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGvjrfWKVKVR for ; Mon, 18 Sep 2017 08:48:31 -0700 (PDT)
Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (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 BF0841321A2 for ; Mon, 18 Sep 2017 08:48:31 -0700 (PDT)
Received: from cmgw4 (unknown [10.0.90.85]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id 06EFA140996 for ; Mon, 18 Sep 2017 09:46:11 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id B3m71w00R2SSUrH013mAqJ; Mon, 18 Sep 2017 09:46:11 -0600
X-Authority-Analysis: v=2.2 cv=OZLoNlbY c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=2JCJgTwv5E4A:10 a=AUd_NHdVAAAA:8 a=402DYpBsjlkE6fcHpgkA:9 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:References:Cc:To:Subject:From:Sender:Reply-To: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=wKmJY+fxRZIRLEj0e/Lu+Pb9dtm9aWu0DW5pKw3oPdE=; b=kEW08RezIBCyVmnDHcW10GDR4f 3WSjWXYdXJPBMpVz2gHEDufy0obKbT4W4jwMDt4M5+oR80aWxh/pvUNcvgeCinYkPyPSO1XKkNWwR Rn1kX1GqSPWYKQiShr0OoZqbu;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:56808 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dtyFL-001xR3-NZ; Mon, 18 Sep 2017 09:46:07 -0600
From: Lou Berger 
To: Martin Bjorklund , rwilton@cisco.com
Cc: netmod@ietf.org
References:  <1505470900.18681.0.camel@nic.cz> <5b512435-cebd-3534-eeb3-649154450d81@cisco.com> <20170915.134007.262763963470255554.mbj@tail-f.com>
Message-ID: 
Date: Mon, 18 Sep 2017 11:46:04 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170915.134007.262763963470255554.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dtyFL-001xR3-NZ
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:56808
X-Source-Auth: lberger@labn.net
X-Email-Count: 8
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Sep 2017 15:48:35 -0000

Martin,

Speaking as a contributor:


On 9/15/2017 7:40 AM, Martin Bjorklund wrote:
> Robert Wilton  wrote:
>> On 15/09/2017 11:21, Ladislav Lhotka wrote:
>>> Andy Bierman píše v Čt 14. 09. 2017 v 08:43 -0700:
>>>> Hi,
>>>>
>>>>
>>>> Actually I liked the early pyang output that was concise and easy to
>>>> remember.
>>>> The current format gets very cluttered and there are too many little
>>>> symbols
>>>> to remember them all.
>>> I agree.
> Me too.  The current draft adds three new magic symbols: "mp" "@" and
> "/".
>
> "mp" is for a mount point, and it can be generated directly from the
> YANG modules.
>
> Directly under a "mp", "/" and "@" are used to indicate that a node is mounted
> or available through a parent reference, respectively.
>
> I actually question the usability of "/" and "@".  

I agree that / and @ are something new, and enabled by schema mount. 
There have been repeated comments in the RTG WG that there needs to be
some way for vendors to convey what they have implemented with Schema
mount and this is one way to help convey (a) what is expected of server
implementors and (b) what client implementors should expect.   Hence the
current draft text:

  In describing the intended use of a module containing a mount point,
   it is helpful to show how the mount point would look with mounted
   modules.

The whole point of trees is to facilitate understanding for those who
are less familiar with a model than the authors, and IMO that's the
paramount perspective in this discussion.

> Since a parent
> reference can be very specific, e.g. one specific interface, it isn't
> really accurate to show:
>
>                   +--mp vrf-root
>                      +--rw rt:routing/
>                      |  ...
>                      +--ro if:interfaces@
This is just a conditional and we have precedent on how to handle
conditional representation.   

>
> And the trailing "/" on rt:routing doesn't add any information we
> don't already know.  Since vrf-root is a mount point, it follows that
> its children are mounted.

The issue is a bit more complex when considering some real use cases,
particularity when parent references and augmentations are used.  For
example consider the following *without* the use / or @:

module: ietf-network-instance
  +--rw network-instances
     +--rw network-instance* [name]
        | ...
        +--rw (root-type)
           +--:(vrf-root)
              +--mp vrf-root
                 +--ro rt:routing-state
                 |  +--ro router-id?                 yang:dotted-quad
                 |  +--ro control-plane-protocols
                 |     +--ro control-plane-protocol* [type name]
                 |        +--ro ospf:ospf
                 |           +--ro instance* [af]
                 +--rw rt:routing
                 |  +--rw router-id?                 yang:dotted-quad
                 |  +--rw control-plane-protocols
                 |     +--rw control-plane-protocol* [type name]
                 |     +--rw ospf:ospf
                 |        +--rw instance* [af]
                 |           +--rw areas
                 |              +--rw area* [area-id]
                 |                 +--rw interfaces
                 |                    +--rw interface* [name]
                 |                       +--rw name if:interface-ref
                 |                       +--rw cost?   uint16
                 +--ro if:interfaces
                 |  ...
                 +--ro if:interfaces-state
                 |  ...


It's certainly not too hard to spot the top level mounts, but it is
impossible to distinguish the parent references from the actual mounts. 
Further more, some mounts are hard to spot.  For example, notice ospf. 
Did you notice that it's a mount? Is it a mount or parent reference? 
With the / and @ both cases are transparent:

module: ietf-network-instance
  +--rw network-instances
     +--rw network-instance* [name]
        | ...
        +--rw (root-type)
           +--:(vrf-root)
              +--mp vrf-root
                 +--ro rt:routing-state/
                 |  +--ro router-id?                 yang:dotted-quad
                 |  +--ro control-plane-protocols
                 |     +--ro control-plane-protocol* [type name]
                 |        +--ro ospf:ospf/
                 |           +--ro instance* [af]
                 +--rw rt:routing/
                 |  +--rw router-id?                 yang:dotted-quad
                 |  +--rw control-plane-protocols
                 |     +--rw control-plane-protocol* [type name]
                 |     +--rw ospf:ospf/
                 |        +--rw instance* [af]
                 |           +--rw areas
                 |              +--rw area* [area-id]
                 |                 +--rw interfaces
                 |                    +--rw interface* [name]
                 |                       +--rw name if:interface-ref
                 |                       +--rw cost?   uint16
                 +--ro if:interfaces@
                 |  ...
                 +--ro if:interfaces-state@
                 |  ...

> Also, what is mounted under a mount point is not defined in the
> schema, so a tool cannot generate this from the YANG modules.

I think this is a limitation in the current schema-mount definition that
perhaps will be revisited to support design time mounts, but
nonetheless  still has value to model any reader and implementor.
...

Lou


From nobody Mon Sep 18 09:03:22 2017
Return-Path: 
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 7C3541342C0 for ; Mon, 18 Sep 2017 09:03:21 -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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmgGl73uw10l for ; Mon, 18 Sep 2017 09:03:19 -0700 (PDT)
Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BC881321A2 for ; Mon, 18 Sep 2017 09:03:16 -0700 (PDT)
Received: by mail-lf0-x229.google.com with SMTP id r17so1045164lff.6 for ; Mon, 18 Sep 2017 09:03: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=twb2n01M2fjqnDvRDvM2P4QNQDFdNz7ZXvBAyTdrewY=; b=ZJzhrbnkkMeyitC3wJBzdZVU1hcZQeITUrwkh+WMHV3LklCvs0dlIZ73x1hLznXES5 NAZDFORSbr2E4ZtIz6hLVlY8m2uOGAedm/Fnyey7tj02Ab3gROX7li78fif/HSHjuZSq azVyJnEcyQerpmE7THeoyjv95navj5DPTU2vlusRnjf7R2eVov3vVyJJsMLeF+fiaduT u1MpATXrxxz9QvPLm+ch0Oj6lRRf+3ysT/XkCmx506RxUqIYHCfMjywyDGi+Ioav8Ug2 uMfoEH+rbI/XHBPJEV8pBA3L9dKDpxvO1OVfBsP9B5rt7dtkqa2QKtLtpVNqFKer4hFz vWGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=twb2n01M2fjqnDvRDvM2P4QNQDFdNz7ZXvBAyTdrewY=; b=Og8jGi0ShqFDUECTKmRrCLWk/icIL3sWlJfwYi4dpscF2jKzldcaoChuKVMv3TtyhK +MDc2C0b9Vk/9oPMvzAy2XZOQUJrg5MQyWC80lCfvXFyT4zgD9fBYJ/1HifMFWCuT6/N 6R4x9Cjec27ak4mugroNvV0Xd+aIrE5HEXX5MhexXQz2BBn+JQkmPmGgA0kZtljKUyvj rNhET4raAyH6ErpiOER8edu0NPz3YoKjdF8pnaE/IGOksbsncAE2uzNQPRPsZzuNLMZr CmWkEDA6B0+P56TbkjdEc5NtM25Tr2E6T7Rvn1CyBbufCwlkD7WoAlJefeCpCSvet5MT 5i1Q==
X-Gm-Message-State: AHPjjUgp9KXIWKTw2uSvJVtmDM+t7bTc0gTYODhlbtbfNSXQJmWGkL/o WacFFOjGOZwvGdHL9P0UFdCpl1bisJRdRR3de5/4XA==
X-Google-Smtp-Source: AOwi7QAn0oOqwrpOJSD4W/JQrtVDvo7H5eh9Q0PpnQ60HTEfns69qPMiCdHG7XfyCXoeXr1+loHMyociKddi2McVzd8=
X-Received: by 10.25.223.86 with SMTP id q22mr3641426lfj.45.1505750594251; Mon, 18 Sep 2017 09:03:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.18.41 with HTTP; Mon, 18 Sep 2017 09:03:13 -0700 (PDT)
In-Reply-To: <70a5b659-83a3-5952-b5e7-b8e991c84ef1@cisco.com>
References:  <20170916072403.xp37556z6g7b42gr@elstar.local>  <20170917.154115.791964858062115650.mbj@tail-f.com>    <70a5b659-83a3-5952-b5e7-b8e991c84ef1@cisco.com>
From: Andy Bierman 
Date: Mon, 18 Sep 2017 09:03:13 -0700
Message-ID: 
To: Robert Wilton 
Cc: Martin Bjorklund ,  Juergen Schoenwaelder , "t.petch" ,  Berger Lou , "netmod@ietf.org" ,  NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org
Content-Type: multipart/alternative; boundary="f403045e58a44a9000055978e134"
Archived-At: 
Subject: Re: [netmod]  vs  [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Sep 2017 16:03:21 -0000

--f403045e58a44a9000055978e134
Content-Type: text/plain; charset="UTF-8"

On Mon, Sep 18, 2017 at 8:34 AM, Robert Wilton  wrote:

>
>
> On 18/09/2017 15:21, Andy Bierman wrote:
>
>
>
> On Mon, Sep 18, 2017 at 2:28 AM, Robert Wilton  wrote:
>
>> Hi Andy,
>>
>> At the moment, NMDA does not change the definition of  for a
>> standards compliant implementation of YANG/NETCONF/RESTCONF.  It is still
>> the same as in 7950, and  must still be a "valid configuration
>> data tree" for a standards complaint implementation.
>>
>> However, the draft acknowledges that proprietary extensions exist that
>> can modify the behaviour of  in ways that means that  is
>> not always a valid configuration data tree.  The draft gives two examples
>> of how  could be manipulated (inactive config, and templates).
>>
>
> I don't see how NMDA can both acknowledge and violate the MUST be valid in
> RFC 7950.
> That statement is quite clear in RFC 7950.
>
> I think that NMDA acknowledges non standard extensions could exist that
> would violate RFC 7950 if/when those features are used, and provides a
> standard architecture (i.e. the definition of ) to allow devices
> to expose the effects of those bespoke features in a standard way.
>
> Phil had proposed adding the following text on validation:
>
> +The implication of the existence of templating mechanisms is that
> + is now explicitly allowed to be invalid, since the
> +templating mechanism may be supplying additional data that satisfies
> +constraints that may not be satisfied by  itself.
>
> Do you think that text like this would help?  Or perhaps more generically,
> something like this:
>
>

No.  I do not agree that the MUST in RFC 7950 can be removed.
I do not agree the architecture should update YANG at all.

Andy


> The implication of the existence of mechanisms that can allow
>  to differ from  means that  is no
> longer guaranteed to always be valid.  However, when any
> change is made to ,  must also be updated at
> the same time and be successfully validated before the operation
> on  can be completed.
>
> Obviously this would then need to update 7950.
>
>
>
>
>> If those extensions are standardized then I think it is likely that those
>> RFCs would need to update 7950 to indicate that  isn't necessarily
>> a "valid configuration data tree" when those extensions are used.  But I
>> don't think that needs to be stated in the NMDA architecture at this time.
>>
>
>  Right -- because 7950 still holds any any server that does not have a
> valid 
> is non-compliant to 7950.
>
> I agree.
>
> Thanks,
> Rob
>
>
>
> Andy
>
>
>>
> So, what is ?
>>  - this is meant to represent the configuration that the system will
>> actually attempt to apply after any and all manipulation (e.g. by
>> templates, inactive removal, perhaps system scripts, etc) of the
>> configuration has been performed.
>>  - it must always be a valid configuration data tree.
>>  - If  is updated then  is always updated at the same
>> time.  Hence, any successful change to  requires that 
>> has also been updated and validated.  E.g. in RESTCONF terms, I think that
>> both  and   should get the same last-change timestamp
>> whenever  is updated.
>>  - It provides a known fixed point so that any client can see the full
>> validated config, i.e. even for devices that implement proprietary
>> manipulations of the configuring in .
>>  - If the device doesn't support any extra proprietary config
>> manipulations, then  is identical to .
>>
>> I think that we can possibly do a bit more to better define what
>> .  My previous suggestion as an improvement was below (perhaps
>> you think it needs more clarification)?:
>>
>> *OLD:*
>>
>> 4.4.  The Intended Configuration Datastore ()
>>
>>    The intended configuration datastore () is a read-only
>>    configuration datastore.  It is tightly coupled to .  When
>>    data is written to , the data that is to be validated is
>>    also conceptually written to .  Validation is performed on
>>    the contents of .
>>
>>    For simple implementations,  and  are identical.
>>
>>     does not persist across reboots; its relationship with
>>     makes that unnecessary.
>>
>>    ...
>>
>> *NEW:*
>>
>> 4.4.  The Intended Configuration Datastore ()
>>
>>    The intended configuration datastore () is a read-only
>>    configuration datastore.  It represents the configuration after all
>>    configuration transformations to  are performed (e.g.
>>    template expansion, inactive configuration removal), and is the
>>    configuration that the system attempts to apply.
>>
>>    It is tightly coupled to .  When data is written to
>>    , the data that is to be validated is also conceptually
>>    written to .  Validation is performed on the contents of
>>    .
>>
>>    For simple implementations,  and  are identical.
>>
>>    The contents of  is also related to the 'config true'
>>    subset of , and hence a client can determine to what
>>    extent the intended configuration is currently applied by checking
>>    whether the contents of  also appears in .
>>
>>     does not persist across reboots; its relationship with
>>     makes that unnecessary.
>>    ...
>>
>> Thanks,
>> Rob
>>
>> On 17/09/2017 16:31, Andy Bierman wrote:
>>
>> Hi,
>>
>> My concern is that the definition of  is being changed to
>> include undefined and undeclared proprietary extensions.
>> This is counter-productive to the IETF's stated goal of interoperability.
>>
>>
>> Andy
>>
>>
>> On Sun, Sep 17, 2017 at 6:41 AM, Martin Bjorklund  wrote:
>>
>>> Andy Bierman  wrote:
>>> > On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder <
>>> > j.schoenwaelder@jacobs-university.de> wrote:
>>> >
>>> > > On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
>>> > > > Hi,
>>> > > >
>>> > > > I strongly agree with Tom that the current draft is an update to
>>> RFC
>>> > > 7950.
>>> > > > I also strongly disagree with the decision to omit RFC 2119 in a
>>> > > standards
>>> > > > track document. IMO RFC 2119 terms need to be used in normative
>>> text,
>>> > > > especially when dealing with XPath and YANG compiler behavior.
>>> > > >
>>> > >
>>> > > RFC 8174:
>>> > >
>>> > >    o  These words can be used as defined here, but using them is not
>>> > >       required.  Specifically, normative text does not require the
>>> use
>>> > >       of these key words.  They are used for clarity and consistency
>>> > >       when that is what's wanted, but a lot of normative text does
>>> not
>>> > >       use them and is still normative.
>>> > >
>>> > >
>>> > So what?
>>> > Existing YANG specifications use RFC 2119 terms.
>>> > This draft uses those terms, just with lower-case.
>>>
>>> Actually, section 5.1 XPath Context in the revised datastore draft
>>> uses the same language as section 6.4.1 XPath Context in RFC 7950.  In
>>> fact, the text in the draft is copied (and adjusted) from RFC 7950.
>>>
>>>
>>> /martin
>>>
>>
>>
>>
>
>

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




On Mon, Sep 18, 2017 at 8:34 AM, Robert Wilton <rwilton@cisco.com&=
gt; wrote:

 =20
   =20
 =20
  

    


    

    

    
On 18/09/2017 15:2=
1, Andy Bierman
      wrote:

    

    

     =20
      


        


          
On Mon, Sep 18, 2017 at 2:28 AM,
            Robert Wilton <rwilton@cisco.com>
            wrote:

            

              

                
Hi Andy,

                
At the moment, NMDA does not change the definition of
                  <running> for a standards compliant
                  implementation of YANG/NETCONF/RESTCONF.=C2=A0 It is stil=
l
                  the same as in 7950, and <running> must still be
                  a "valid configuration data tree" for a standar=
ds
                  complaint implementation.

                

                
However, the draft acknowledges that proprietary
                  extensions exist that can modify the behaviour of
                  <running> in ways that means that
                  <running> is not always a valid configuration
                  data tree.=C2=A0 The draft gives two examples of how
                  <running> could be manipulated (inactive config,
                  and templates).

                

              

            

            


            

            
I don't see how NMDA can both acknowledge and violate
              the MUST be valid in RFC 7950.

            
That statement is quite clear in RFC 7950.

          

        

      

    

    I think that NMDA acknowledges non standard extensions could exist
    that would violate RFC 7950 if/when those features are used, and
    provides a standard architecture (i.e. the definition of
    <intended>) to allow devices to expose the effects of those
    bespoke features in a standard way.

    

    Phil had proposed adding the following text on validation:

    

    +The implication of the existence of templating mechanisms is
      that

    +<running> is now explicitly allowed to be invalid,
      since the

    +templating mechanism may be supplying additional data that
      satisfies

    +constraints that may not be satisfied by <running>
      itself.

    

    Do you think that text like this would help?=C2=A0 Or perhaps more
    generically, something like this:

    


No.=C2=A0 I d=
o not agree that the MUST in RFC 7950 can be removed.
I do not ag=
ree the architecture should update YANG at all.

An=
dy
=C2=A0

    The implication of the existence of mechanisms that can allow

      <intended> to differ from <running> means that
      <running> is no

      longer guaranteed to always be valid.=C2=A0 However, when any

      change is made to <running>, <intended> must also be
      updated at

      the same time and be successfully validated before the operation

      on <running> can be completed.

      

      Obviously this would then need to update 7950.

    

    

      

        

          

            


            

            
=C2=A0

            

              

                
 

                
If those extensions are standardized then I think it
                  is likely that those RFCs would need to update 7950 to
                  indicate that <running> isn't necessarily a
                  "valid configuration data tree" when those exte=
nsions
                  are used.=C2=A0 But I don't think that needs to be st=
ated
                  in the NMDA architecture at this time.

              

            

            


            

            
=C2=A0Right -- because 7950 still holds any any server tha=
t
              does not have a valid <running>

            

            
is non-compliant to 7950.=C2=A0 

            

          

        

      

    

    I agree.

    

    Thanks,

    Rob

    

    

      

        

          

            


            

            


            

            
Andy

            


            

            

              

                
=C2=A0

              

            

            

              

                
So, what is <intended>?

                  =C2=A0- this is meant to represent the configuration that
                  the system will actually attempt to apply after any
                  and all manipulation (e.g. by templates, inactive
                  removal, perhaps system scripts, etc) of the
                  configuration has been performed.

                  =C2=A0- it must always be a valid configuration data tree=
.

                  =C2=A0- If <running> is updated then <intended&g=
t;
                  is always updated at the same time.=C2=A0 Hence, any
                  successful change to <running> requires that
                  <intended> has also been updated and validated.=C2=
=A0
                  E.g. in RESTCONF terms, I think that both
                  <running> and=C2=A0 <intended> should get the
                  same last-change timestamp whenever <running> is
                  updated.

                  =C2=A0- It provides a known fixed point so that any clien=
t
                  can see the full validated config, i.e. even for
                  devices that implement proprietary manipulations of
                  the configuring in <running>.

                  =C2=A0- If the device doesn't support any extra propr=
ietary
                  config manipulations, then <intended> is
                  identical to <running>.

                

                
I think that we can possibly do a bit more to better
                  define what <intended is>.=C2=A0 My previous
                  suggestion as an improvement was below (perhaps you
                  think it needs more clarification)?:

                
OLD:

                
4.4.=C2=A0 The Intended Configuration Datastore
                    (<intended>)

                  

                
=C2=A0=C2=A0 The intended configuration datastore
                    (<intended>) is a read-only

                  =C2=A0=C2=A0 configuration datastore.=C2=A0 It i=
s tightly
                    coupled to <running>.=C2=A0 When

                  =C2=A0=C2=A0 data is written to <running>,=
 the
                    data that is to be validated is

                  =C2=A0=C2=A0 also conceptually written to
                    <intended>.=C2=A0 Validation is performed on=


                  =C2=A0=C2=A0 the contents of <intended>.

                  

                  =C2=A0=C2=A0 For simple implementations,
                    <running> and <intended> are identical.

                  

                  =C2=A0=C2=A0 <intended> does not persist a=
cross
                    reboots; its relationship with

                  =C2=A0=C2=A0 <running> makes that unnecess=
ary.=C2=A0 

                  

                  =C2=A0=C2=A0 ...

                

                
NEW:

                
4.4.=C2=A0 The Intended Configuration Datastore
                    (<intended>)

                  

                  =C2=A0=C2=A0 The intended configuration datastor=
e
                    (<intended>) is a read-only

                  =C2=A0=C2=A0 configuration datastore.=C2=A0 It r=
epresents
                    the configuration after all

                  =C2=A0=C2=A0 configuration transformations to
                    <running> are performed (e.g.

                  =C2=A0=C2=A0 template expansion, inactive config=
uration
                    removal), and is the

                  =C2=A0=C2=A0 configuration that the system attem=
pts to
                    apply.

                  

                  =C2=A0=C2=A0 It is tightly coupled to <runnin=
g>.=C2=A0
                    When data is written to

                  =C2=A0=C2=A0 <running>, the data that is t=
o be
                    validated is also conceptually

                  =C2=A0=C2=A0 written to <intended>.=C2=A0 =
Validation
                    is performed on the contents of

                  =C2=A0=C2=A0 <intended>.

                  

                  =C2=A0=C2=A0 For simple implementations,
                    <running> and <intended> are identical.

                  

                  =C2=A0=C2=A0 The contents of <intended> is=
 also
                    related to the 'config true'

                  =C2=A0=C2=A0 subset of <operational>, and =
hence a
                    client can determine to what

                  =C2=A0=C2=A0 extent the intended configuration i=
s
                    currently applied by checking

                  =C2=A0=C2=A0 whether the contents of <intende=
d>
                    also appears in <operational>.

                  

                  =C2=A0=C2=A0 <intended> does not persist a=
cross
                    reboots; its relationship with

                  =C2=A0=C2=A0 <running> makes that unnecess=
ary.

                =C2=A0=C2=A0 ...
                
Thanks,

                  Rob

                

                

                
On
                  17/09/2017 16:31, Andy Bierman wrote:

                

                

                  
Hi,
                    


                    

                    
My concern is that the definition of
                      <running> is being changed to

                    
include undefined and undeclared proprietary
                      extensions.

                    
This is counter-productive to the IETF's state=
d
                      goal of interoperability.

                    


                    

                    


                    

                    
Andy

                    


                    

                  

                  


                    
On Sun, Sep 17, 2017 at
                      6:41 AM, Martin Bjorklund <mbj@tail-f.com>
                      wrote:

                      
Andy Bierman <andy@yumaworks.com&g=
t;
                        wrote:

                        > On Sat, Sep 16, 2017 at 12:24 AM, Juergen
                        Schoenwaelder <

                        > j.schoenwaelder@jacobs-university.de&g=
t;
                        wrote:

                        >

                        > > On Fri, Sep 15, 2017 at 02:07:58PM
                        -0700, Andy Bierman wrote:

                        > > > Hi,

                        > > >

                        > > > I strongly agree with Tom that
                        the current draft is an update to RFC

                        > > 7950.

                        > > > I also strongly disagree with the
                        decision to omit RFC 2119 in a

                        > > standards

                        > > > track document. IMO RFC 2119
                        terms need to be used in normative text,

                        > > > especially when dealing with
                        XPath and YANG compiler behavior.

                        > > >

                        > >

                        > > RFC 8174:

                        > >

                        > >=C2=A0 =C2=A0 o=C2=A0 These words can be u=
sed as
                        defined here, but using them is not

                        > >=C2=A0 =C2=A0 =C2=A0 =C2=A0required.=C2=A0=
 Specifically,
                        normative text does not require the use

                        > >=C2=A0 =C2=A0 =C2=A0 =C2=A0of these key wo=
rds.=C2=A0 They are
                        used for clarity and consistency

                        > >=C2=A0 =C2=A0 =C2=A0 =C2=A0when that is wh=
at's wanted, but
                        a lot of normative text does not

                        > >=C2=A0 =C2=A0 =C2=A0 =C2=A0use them and is=
 still normative.

                        > >

                        > >

                        > So what?

                        > Existing YANG specifications use RFC 2119
                        terms.

                        > This draft uses those terms, just with
                        lower-case.

                        

                        Actually, section 5.1 XPath Context in the
                        revised datastore draft

                        uses the same language as section 6.4.1 XPath
                        Context in RFC 7950.=C2=A0 In

                        fact, the text in the draft is copied (and
                        adjusted) from RFC 7950.

                        

                            

                            /martin

                          

                    

                    

                  

                

                

              

            

          

          

        

      

    

    

  






--f403045e58a44a9000055978e134--


From nobody Mon Sep 18 09:17:55 2017
Return-Path: 
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 F1F3B120720; Mon, 18 Sep 2017 09:17:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 ZmC9sz98qn_j; Mon, 18 Sep 2017 09:17:50 -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 F1EA8132D4E; Mon, 18 Sep 2017 09:17:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35014; q=dns/txt; s=iport; t=1505751469; x=1506961069; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=ixkYwSNU/eRIaSFMyZ0Q02W7r7srh0JmU1dsXUa4VFA=; b=Gn2bgMBVzDOvxc7M1+C0Tf7cFBgLiCPmycYhyRl/WElzBNuTPI3heOSV 1mZR1pT+5kKlO8p22cL/J88uKh+KK4Rm/3JyAHMd6Z+uvuXOBIaYqhj/i IfvsW6g4Jnh4F8O5Ik1NEEmVxlEqxQb6JgAXfGy3VmIVVQREx14DIZupC s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CSAQBl8L9Z/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhSwng3WLFJBLK5YmDoIECoU7AoUIFgECAQEBAQEBAWsohRgBAQE?= =?us-ascii?q?BAgEjTwcQCQIQAgYgAQIEAwICRgMOBg0GAgEBF4oQCIwxnWaCJyeLBQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAR2DK4NSgWMrgn2EYAJMgl2CYAWYQIhIlFWCE4lEJIZ?= =?us-ascii?q?9igCDXodXgTklATFBTDIhCBwVhheBTz82hWArghQBAQE?=
X-IronPort-AV: E=Sophos;i="5.42,413,1500940800";  d="scan'208,217";a="697279810"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Sep 2017 16:17:46 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8IGHkBK008305; Mon, 18 Sep 2017 16:17:46 GMT
To: Andy Bierman 
Cc: Martin Bjorklund , Juergen Schoenwaelder , "t.petch" , Berger Lou , "netmod@ietf.org" , NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org
References:  <20170916072403.xp37556z6g7b42gr@elstar.local>  <20170917.154115.791964858062115650.mbj@tail-f.com>    <70a5b659-83a3-5952-b5e7-b8e991c84ef1@cisco.com> 
From: Robert Wilton 
Message-ID: 
Date: Mon, 18 Sep 2017 17:17:46 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------7CFE5A4BF5E6A26688155C2F"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod]  vs  [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Sep 2017 16:17:52 -0000

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



On 18/09/2017 17:03, Andy Bierman wrote:
>
>
> On Mon, Sep 18, 2017 at 8:34 AM, Robert Wilton  > wrote:
>
>
>
>     On 18/09/2017 15:21, Andy Bierman wrote:
>>
>>
>>     On Mon, Sep 18, 2017 at 2:28 AM, Robert Wilton >     > wrote:
>>
>>         Hi Andy,
>>
>>         At the moment, NMDA does not change the definition of
>>          for a standards compliant implementation of
>>         YANG/NETCONF/RESTCONF.  It is still the same as in 7950, and
>>          must still be a "valid configuration data tree" for
>>         a standards complaint implementation.
>>
>>         However, the draft acknowledges that proprietary extensions
>>         exist that can modify the behaviour of  in ways that
>>         means that  is not always a valid configuration data
>>         tree.  The draft gives two examples of how  could be
>>         manipulated (inactive config, and templates).
>>
>>
>>     I don't see how NMDA can both acknowledge and violate the MUST be
>>     valid in RFC 7950.
>>     That statement is quite clear in RFC 7950.
>     I think that NMDA acknowledges non standard extensions could exist
>     that would violate RFC 7950 if/when those features are used, and
>     provides a standard architecture (i.e. the definition of
>     ) to allow devices to expose the effects of those
>     bespoke features in a standard way.
>
>     Phil had proposed adding the following text on validation:
>
>     +The implication of the existence of templating mechanisms is that
>     + is now explicitly allowed to be invalid, since the
>     +templating mechanism may be supplying additional data that satisfies
>     +constraints that may not be satisfied by  itself.
>
>     Do you think that text like this would help?  Or perhaps more
>     generically, something like this:
>
>
>
> No.  I do not agree that the MUST in RFC 7950 can be removed.
> I do not agree the architecture should update YANG at all.
OK.

So, can the NMDA draft just be silent about whether  is valid 
or not?  I.e. allowing the current statement in 7950 to stand.  That way 
if inactive or templating are standardized, and if the standard solution 
means that running is no longer always valid, then those drafts can 
update 7950 as appropriate.

The NMDA architecture can still specify  and also still 
specify that it is always valid, and explain its relationship to 
 and .

Thanks,
Rob


>
> Andy
>
>     The implication of the existence of mechanisms that can allow
>      to differ from  means that  is no
>     longer guaranteed to always be valid.  However, when any
>     change is made to ,  must also be updated at
>     the same time and be successfully validated before the operation
>     on  can be completed.
>
>     Obviously this would then need to update 7950.
>
>>
>>         If those extensions are standardized then I think it is
>>         likely that those RFCs would need to update 7950 to indicate
>>         that  isn't necessarily a "valid configuration data
>>         tree" when those extensions are used.  But I don't think that
>>         needs to be stated in the NMDA architecture at this time.
>>
>>
>>      Right -- because 7950 still holds any any server that does not
>>     have a valid 
>>     is non-compliant to 7950.
>     I agree.
>
>     Thanks,
>     Rob
>
>>
>>
>>     Andy
>>
>>         So, what is ?
>>          - this is meant to represent the configuration that the
>>         system will actually attempt to apply after any and all
>>         manipulation (e.g. by templates, inactive removal, perhaps
>>         system scripts, etc) of the configuration has been performed.
>>          - it must always be a valid configuration data tree.
>>          - If  is updated then  is always updated
>>         at the same time.  Hence, any successful change to 
>>         requires that  has also been updated and
>>         validated.  E.g. in RESTCONF terms, I think that both
>>          and  should get the same last-change
>>         timestamp whenever  is updated.
>>          - It provides a known fixed point so that any client can see
>>         the full validated config, i.e. even for devices that
>>         implement proprietary manipulations of the configuring in
>>         .
>>          - If the device doesn't support any extra proprietary config
>>         manipulations, then  is identical to .
>>
>>         I think that we can possibly do a bit more to better define
>>         what .  My previous suggestion as an improvement
>>         was below (perhaps you think it needs more clarification)?:
>>
>>         *OLD:*
>>
>>         4.4.  The Intended Configuration Datastore ()
>>
>>            The intended configuration datastore () is a
>>         read-only
>>            configuration datastore.  It is tightly coupled to
>>         . When
>>            data is written to , the data that is to be
>>         validated is
>>            also conceptually written to .  Validation is
>>         performed on
>>            the contents of .
>>
>>            For simple implementations,  and  are
>>         identical.
>>
>>             does not persist across reboots; its
>>         relationship with
>>             makes that unnecessary.
>>
>>            ...
>>
>>         *NEW:*
>>
>>         4.4.  The Intended Configuration Datastore ()
>>
>>            The intended configuration datastore () is a
>>         read-only
>>            configuration datastore.  It represents the configuration
>>         after all
>>            configuration transformations to  are performed (e.g.
>>            template expansion, inactive configuration removal), and
>>         is the
>>            configuration that the system attempts to apply.
>>
>>            It is tightly coupled to .  When data is written to
>>            , the data that is to be validated is also
>>         conceptually
>>            written to . Validation is performed on the
>>         contents of
>>            .
>>
>>            For simple implementations,  and  are
>>         identical.
>>
>>            The contents of  is also related to the 'config
>>         true'
>>            subset of , and hence a client can determine
>>         to what
>>            extent the intended configuration is currently applied by
>>         checking
>>            whether the contents of  also appears in
>>         .
>>
>>             does not persist across reboots; its
>>         relationship with
>>             makes that unnecessary.
>>
>>            ...
>>
>>         Thanks,
>>         Rob
>>
>>
>>         On 17/09/2017 16:31, Andy Bierman wrote:
>>>         Hi,
>>>
>>>         My concern is that the definition of  is being
>>>         changed to
>>>         include undefined and undeclared proprietary extensions.
>>>         This is counter-productive to the IETF's stated goal of
>>>         interoperability.
>>>
>>>
>>>         Andy
>>>
>>>
>>>         On Sun, Sep 17, 2017 at 6:41 AM, Martin Bjorklund
>>>         > wrote:
>>>
>>>             Andy Bierman >>             > wrote:
>>>             > On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder <
>>>             > j.schoenwaelder@jacobs-university.de
>>>             > wrote:
>>>             >
>>>             > > On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy
>>>             Bierman wrote:
>>>             > > > Hi,
>>>             > > >
>>>             > > > I strongly agree with Tom that the current draft
>>>             is an update to RFC
>>>             > > 7950.
>>>             > > > I also strongly disagree with the decision to omit
>>>             RFC 2119 in a
>>>             > > standards
>>>             > > > track document. IMO RFC 2119 terms need to be used
>>>             in normative text,
>>>             > > > especially when dealing with XPath and YANG
>>>             compiler behavior.
>>>             > > >
>>>             > >
>>>             > > RFC 8174:
>>>             > >
>>>             > >    o  These words can be used as defined here, but
>>>             using them is not
>>>             > >       required. Specifically, normative text does
>>>             not require the use
>>>             > >       of these key words. They are used for clarity
>>>             and consistency
>>>             > >       when that is what's wanted, but a lot of
>>>             normative text does not
>>>             > >       use them and is still normative.
>>>             > >
>>>             > >
>>>             > So what?
>>>             > Existing YANG specifications use RFC 2119 terms.
>>>             > This draft uses those terms, just with lower-case.
>>>
>>>             Actually, section 5.1 XPath Context in the revised
>>>             datastore draft
>>>             uses the same language as section 6.4.1 XPath Context in
>>>             RFC 7950.  In
>>>             fact, the text in the draft is copied (and adjusted)
>>>             from RFC 7950.
>>>
>>>
>>>             /martin
>>>
>>>
>>
>>
>
>


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


  
    
  
  
    


    

    

    
On 18/09/2017 17:03, Andy Bierman
      wrote:

    

    

      
      


        


          
On Mon, Sep 18, 2017 at 8:34 AM,
            Robert Wilton <rwilton@cisco.com>
            wrote:

            

              

                


                

                

                
On
                  18/09/2017 15:21, Andy Bierman wrote:

                

                

                  


                    


                      
On Mon, Sep 18, 2017 at
                        2:28 AM, Robert Wilton <rwilton@cisco.com>
                        wrote:

                        

                          

                            
Hi Andy,

                            
At the moment, NMDA does not change the
                              definition of <running> for a
                              standards compliant implementation of
                              YANG/NETCONF/RESTCONF.  It is still the
                              same as in 7950, and <running> must
                              still be a "valid configuration data tree"
                              for a standards complaint implementation.

                            

                            
However, the draft acknowledges that
                              proprietary extensions exist that can
                              modify the behaviour of <running> in
                              ways that means that <running> is
                              not always a valid configuration data
                              tree.  The draft gives two examples of how
                              <running> could be manipulated
                              (inactive config, and templates).

                            

                          

                        

                        


                        

                        
I don't see how NMDA can both acknowledge
                          and violate the MUST be valid in RFC 7950.

                        
That statement is quite clear in RFC 7950.

                      

                    

                  

                

                I think that NMDA acknowledges non standard extensions
                could exist that would violate RFC 7950 if/when those
                features are used, and provides a standard architecture
                (i.e. the definition of <intended>) to allow
                devices to expose the effects of those bespoke features
                in a standard way.

                

                Phil had proposed adding the following text on
                validation:

                

                +The implication of the existence of templating
                  mechanisms is that

                +<running> is now explicitly allowed to
                  be invalid, since the

                +templating mechanism may be supplying
                  additional data that satisfies

                +constraints that may not be satisfied by
                  <running> itself.

                

                Do you think that text like this would help?  Or perhaps
                more generically, something like this:

                

              

            

            


            

            


            

            
No.  I do not agree that the MUST in RFC 7950 can be
              removed.

            
I do not agree the architecture should update YANG at
              all.

          

        

      

    

    OK.

    

    So, can the NMDA draft just be silent about whether <running>
    is valid or not?  I.e. allowing the current statement in 7950 to
    stand.  That way if inactive or templating are standardized, and if
    the standard solution means that running is no longer always valid,
    then those drafts can update 7950 as appropriate.

    

    The NMDA architecture can still specify <intended> and also
    still specify that it is always valid, and explain its relationship
    to <running> and <operational>.

    

    Thanks,

    Rob

    

    

    

      

        

          

            


            

            
Andy

            
 

            

              
 The
                  implication of the existence of mechanisms that can
                  allow

                  <intended> to differ from <running> means
                  that <running> is no

                  longer guaranteed to always be valid.  However, when
                  any

                  change is made to <running>, <intended>
                  must also be updated at

                  the same time and be successfully validated before the
                  operation

                  on <running> can be completed.

                  

                  Obviously this would then need to update 7950.

                

                

                  

                    

                      

                        


                        

                        
 

                        

                          

                            
 

                            
If those extensions are standardized then
                              I think it is likely that those RFCs would
                              need to update 7950 to indicate that
                              <running> isn't necessarily a "valid
                              configuration data tree" when those
                              extensions are used.  But I don't think
                              that needs to be stated in the NMDA
                              architecture at this time.

                          

                        

                        


                        

                        
 Right -- because 7950 still holds any any
                          server that does not have a valid
                          <running>

                        

                        
is non-compliant to 7950.  

                        

                      

                    

                  

                

                I agree.

                

                Thanks,

                Rob

                

                

                  

                    

                      

                        


                        

                        


                        

                        
Andy

                        


                        

                        

                          

                            
 

                          

                        

                        

                          

                            
So, what is <intended>?

                               - this is meant to represent the
                              configuration that the system will
                              actually attempt to apply after any and
                              all manipulation (e.g. by templates,
                              inactive removal, perhaps system scripts,
                              etc) of the configuration has been
                              performed.

                               - it must always be a valid configuration
                              data tree.

                               - If <running> is updated then
                              <intended> is always updated at the
                              same time.  Hence, any successful change
                              to <running> requires that
                              <intended> has also been updated and
                              validated.  E.g. in RESTCONF terms, I
                              think that both <running> and 
                              <intended> should get the same
                              last-change timestamp whenever
                              <running> is updated.

                               - It provides a known fixed point so that
                              any client can see the full validated
                              config, i.e. even for devices that
                              implement proprietary manipulations of the
                              configuring in <running>.

                               - If the device doesn't support any extra
                              proprietary config manipulations, then
                              <intended> is identical to
                              <running>.

                            

                            
I think that we can possibly do a bit
                              more to better define what <intended
                              is>.  My previous suggestion as an
                              improvement was below (perhaps you think
                              it needs more clarification)?:

                            
OLD:

                            
4.4.  The Intended Configuration
                                Datastore (<intended>)

                              

                            
   The intended configuration
                                datastore (<intended>) is a
                                read-only

                                 configuration datastore.  It
                                is tightly coupled to <running>. 
                                When

                                 data is written to
                                <running>, the data that is to be
                                validated is

                                 also conceptually written to
                                <intended>.  Validation is
                                performed on

                                 the contents of
                                <intended>.

                              

                                 For simple implementations,
                                <running> and <intended> are
                                identical.

                              

                                 <intended> does not
                                persist across reboots; its relationship
                                with

                                 <running> makes that
                                unnecessary.  

                              

                                 ...

                            

                            
NEW:

                            
4.4.  The Intended Configuration
                                Datastore (<intended>)

                              

                                 The intended configuration
                                datastore (<intended>) is a
                                read-only

                                 configuration datastore.  It
                                represents the configuration after all

                                 configuration transformations
                                to <running> are performed (e.g.

                                 template expansion, inactive
                                configuration removal), and is the

                                 configuration that the system
                                attempts to apply.

                              

                                 It is tightly coupled to
                                <running>.  When data is written
                                to

                                 <running>, the data that
                                is to be validated is also conceptually

                                 written to <intended>. 
                                Validation is performed on the contents
                                of

                                 <intended>.

                              

                                 For simple implementations,
                                <running> and <intended> are
                                identical.

                              

                                 The contents of
                                <intended> is also related to the
                                'config true'

                                 subset of <operational>,
                                and hence a client can determine to what

                                 extent the intended
                                configuration is currently applied by
                                checking

                                 whether the contents of
                                <intended> also appears in
                                <operational>.

                              

                                 <intended> does not
                                persist across reboots; its relationship
                                with

                                 <running> makes that
                                unnecessary.

                               ...
                            
Thanks,

                              Rob

                            

                            

                            
On
                              17/09/2017 16:31, Andy Bierman wrote:

                            

                            

                              
Hi,
                                


                                

                                
My concern is that the definition
                                  of <running> is being changed to

                                
include undefined and undeclared
                                  proprietary extensions.

                                
This is counter-productive to the
                                  IETF's stated goal of
                                  interoperability.

                                


                                

                                


                                

                                
Andy

                                


                                

                              

                              


                                
On Sun, Sep 17,
                                  2017 at 6:41 AM, Martin Bjorklund <mbj@tail-f.com>
                                  wrote:

                                  
Andy Bierman
                                    <andy@yumaworks.com>
                                    wrote:

                                    > On Sat, Sep 16, 2017 at 12:24
                                    AM, Juergen Schoenwaelder <

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

                                    >

                                    > > On Fri, Sep 15, 2017 at
                                    02:07:58PM -0700, Andy Bierman
                                    wrote:

                                    > > > Hi,

                                    > > >

                                    > > > I strongly agree with
                                    Tom that the current draft is an
                                    update to RFC

                                    > > 7950.

                                    > > > I also strongly
                                    disagree with the decision to omit
                                    RFC 2119 in a

                                    > > standards

                                    > > > track document. IMO
                                    RFC 2119 terms need to be used in
                                    normative text,

                                    > > > especially when
                                    dealing with XPath and YANG compiler
                                    behavior.

                                    > > >

                                    > >

                                    > > RFC 8174:

                                    > >

                                    > >    o  These words can be
                                    used as defined here, but using them
                                    is not

                                    > >       required. 
                                    Specifically, normative text does
                                    not require the use

                                    > >       of these key words. 
                                    They are used for clarity and
                                    consistency

                                    > >       when that is what's
                                    wanted, but a lot of normative text
                                    does not

                                    > >       use them and is
                                    still normative.

                                    > >

                                    > >

                                    > So what?

                                    > Existing YANG specifications
                                    use RFC 2119 terms.

                                    > This draft uses those terms,
                                    just with lower-case.

                                    

                                    Actually, section 5.1 XPath Context
                                    in the revised datastore draft

                                    uses the same language as section
                                    6.4.1 XPath Context in RFC 7950.  In

                                    fact, the text in the draft is
                                    copied (and adjusted) from RFC 7950.

                                    

                                        

                                        /martin

                                      

                                

                                

                              

                            

                            

                          

                        

                      

                      

                    

                  

                

                

              

            

          

          

        

      

    

    

  


--------------7CFE5A4BF5E6A26688155C2F--


From nobody Mon Sep 18 09:21:13 2017
Return-Path: 
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 709921320BD; Mon, 18 Sep 2017 09:21:11 -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 N8ySKhydzD7X; Mon, 18 Sep 2017 09:21:09 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FF1D133063; Mon, 18 Sep 2017 09:21:09 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id D707721; Mon, 18 Sep 2017 18:21:07 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 60IkU4StNXir; Mon, 18 Sep 2017 18:21:02 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 18 Sep 2017 18:21:07 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B2FB6200E9; Mon, 18 Sep 2017 18:21:07 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ojPOh5dIaPaH; Mon, 18 Sep 2017 18:21:07 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2B1A4200E8; Mon, 18 Sep 2017 18:21:07 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 1CF55410B865; Mon, 18 Sep 2017 18:21:07 +0200 (CEST)
Date: Mon, 18 Sep 2017 18:21:07 +0200
From: Juergen Schoenwaelder 
To: Robert Wilton 
Cc: Andy Bierman , Martin Bjorklund , "t.petch" , Berger Lou , "netmod@ietf.org" , NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org
Message-ID: <20170918162107.6qnmrl5hepqcxsrm@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Robert Wilton , Andy Bierman , Martin Bjorklund , "t.petch" , Berger Lou , "netmod@ietf.org" , NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org
References:  <20170916072403.xp37556z6g7b42gr@elstar.local>  <20170917.154115.791964858062115650.mbj@tail-f.com>    <70a5b659-83a3-5952-b5e7-b8e991c84ef1@cisco.com>  
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod]  vs  [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Sep 2017 16:21:11 -0000

On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert Wilton wrote:
> 
> > No.  I do not agree that the MUST in RFC 7950 can be removed.
> > I do not agree the architecture should update YANG at all.
> OK.

I am with Andy here.  has always had the requirement to be
valid and we are not supposed to change that. Mechanisms for inactive
configuration or templating must be designed to be backwards compatible
I think.

/js

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


From nobody Mon Sep 18 09:44:53 2017
Return-Path: 
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 80C20133018 for ; Mon, 18 Sep 2017 09:44:51 -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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CHMxsTbAZJl for ; Mon, 18 Sep 2017 09:44:48 -0700 (PDT)
Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 774D5133071 for ; Mon, 18 Sep 2017 09:44:48 -0700 (PDT)
Received: by mail-lf0-x232.google.com with SMTP id a18so1139604lfl.13 for ; Mon, 18 Sep 2017 09:44:48 -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; bh=GbCexilLVF7WThwVHpzyEBOzLbjypy9tsgR0C6AD31o=; b=ZXSWAklb/jU7GY9EMCqidjl2rtotpm4fyuQmli0kUtveTHZHv1BlEOaSYVF2pea7d6 aaP1HrnAEJmH6bLBcve4eU3wYGzivnRv2Hozrn87KzUlZtCRRpewJb2b1iCS66y0TqSn EtV7XNgm0kba5EBtHDFeIkFqUqroRZkzrPZGlDMVlpBF2wZCDIFY341sFY2rwTYPn3kY CXQTYB1Nwnl1eRrFnpCn+AVfOR4hqSI54XBi8X1I1HPOl6/UOrhmeKxwRJwsHKUZ+N9F eNpqfHkwN+VQlfgsJpp1OzlhsfdwwMRPsg9vDg3zUwwW1TdbkfLfRCGDifdEkStdEjTr CaXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=GbCexilLVF7WThwVHpzyEBOzLbjypy9tsgR0C6AD31o=; b=ndDwTONxIy/HAP+9tamQJDEtFSYtKzSv3Xyj4MKbI0ndfX5SaVnJVn6oP+HClHIhHc ZHHEuXsVTceSxsFEGviHzDRn2B8nXFnKN8tEGlVz9dQNQcwVW/l6RqLlco6SWePi4gpx ghZVMIH3LObWoCiX2xEVYt2dgqHl4RdDpy7EZNO9ZCIoPf0W/cbUP17KGeJuE+yxDaf4 bU+4amzHrTa6IprGUo32cFuf9kLetrvkjTVUG35X7rYlGAy3SeGaK4RWSlPQ5zcnh+H3 05sMQRU+T+UO4z0LdIlU7/Ba2vWKmWd3R14uJkvUOL30vvPE2JMaEgQkioMVWrubEIq4 BXjw==
X-Gm-Message-State: AHPjjUiLVBA88x1whFPC4RT/aVjBTa8qfVHXAw+0epyhXJWZEhLu2yZV qPZXXQi4KAStcDdbVQW3jPtF8cqzMxf5oKZLHgFubQ==
X-Google-Smtp-Source: AOwi7QCNPucJ53bvW9+ncamp9RsspPKfxktGemvw0CqI4FK9Ja7JcZHADbeTILHxxmttsdzTSICjvHJ+iIKRjsuFIhw=
X-Received: by 10.46.83.17 with SMTP id h17mr6123591ljb.158.1505753086693; Mon, 18 Sep 2017 09:44:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.18.41 with HTTP; Mon, 18 Sep 2017 09:44:45 -0700 (PDT)
In-Reply-To: <20170918162107.6qnmrl5hepqcxsrm@elstar.local>
References:  <20170916072403.xp37556z6g7b42gr@elstar.local>  <20170917.154115.791964858062115650.mbj@tail-f.com>    <70a5b659-83a3-5952-b5e7-b8e991c84ef1@cisco.com>   <20170918162107.6qnmrl5hepqcxsrm@elstar.local>
From: Andy Bierman 
Date: Mon, 18 Sep 2017 09:44:45 -0700
Message-ID: 
To: Juergen Schoenwaelder , Robert Wilton ,  Andy Bierman , Martin Bjorklund , "t.petch" ,  Berger Lou , "netmod@ietf.org" ,  NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c1ced70da23900559797545"
Archived-At: 
Subject: Re: [netmod]  vs  [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Sep 2017 16:44:51 -0000

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

On Mon, Sep 18, 2017 at 9:21 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert Wilton wrote:
> >
> > > No.  I do not agree that the MUST in RFC 7950 can be removed.
> > > I do not agree the architecture should update YANG at all.
> > OK.
>
> I am with Andy here.  has always had the requirement to be
> valid and we are not supposed to change that. Mechanisms for inactive
> configuration or templating must be designed to be backwards compatible
> I think.
>
>
I have been trying to think of a way that an enterprise-wide flag day
upgrade is not required,
but no luck so far. As Phil pointed out, if 1 client is using disabled
nodes,
unaware clients clients might end up deleting them if disabled nodes
are just omitted from  responses. (e.g., replace operation).

A client has no requirement to maintain attributes sent with server
responses
(unlike the server for  -> ), so returning the disabled
nodes
to an unaware client is no solution either.

It looks to me that an operator has to make sure all apps that alter
configuration
are aware of the disabled nodes.

IMO a standard attribute should be defined using RFC 7952:

  md:annotation enabled {
    type boolean;
    description "...";
  }

Even if the server supports vendor-specific attributes, it has to report
this attribute as well.
The default is enabled, so only disabled nodes need this attribute.
Standard configuration can wait.  Standard reporting should not wait.

Since clients can ignore YANG extensions, a new version of YANG will be
needed eventually,
but at least this allows 3rd party clients to recognize disabled nodes from
any vendor.



/js
>
>

Andy


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

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




On Mon, Sep 18, 2017 at 9:21 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert Wil=
ton wrote:

>

> > No.=C2=A0 I do not agree that the MUST in RFC 7950 can be removed=
.

> > I do not agree the architecture should update YANG at all.

> OK.



I am with Andy here. <running> has always had the requirement to be
valid and we are not supposed to change that. Mechanisms for inactive

configuration or templating must be designed to be backwards compatible

I think.



I have been trying to think of a way that an enterpr=
ise-wide flag day upgrade is not required,
but no luck so far. As=
 Phil pointed out, if 1 client is using disabled nodes,
unaware c=
lients clients might end up deleting them if disabled nodes
are j=
ust omitted from <get-config> responses. (e.g., replace operation).

A client has no requirement to maintain attributes =
sent with server responses
(unlike the server for <rpc> -&g=
t; <rpc-reply>), so returning the disabled nodes
to an unaw=
are client is no solution either.

It looks to me t=
hat an operator has to make sure all apps that alter configuration
are aware of the disabled nodes.

IMO a standard =
attribute should be defined using RFC 7952:

=C2=A0=
 md:annotation enabled {
=C2=A0 =C2=A0 type boolean;
=
=C2=A0 =C2=A0 description "...";
=C2=A0 }
Even if the server supports vendor-specific attributes, it has =
to report this attribute as well.
The default is enabled, so only=
 disabled nodes need this attribute.
Standard configuration can w=
ait.=C2=A0 Standard reporting should not wait.

Sin=
ce clients can ignore YANG extensions, a new version of YANG will be needed=
 eventually,
but at least this allows 3rd party clients to recogn=
ize disabled nodes from any vendor.




/js




Andy
=C2=A0

--

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28=
759 Bremen | Germany

Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>





--94eb2c1ced70da23900559797545--


From nobody Mon Sep 18 11:06:22 2017
Return-Path: 
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 23FCE13308F; Mon, 18 Sep 2017 11:06: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 8arZhpRMHMG9; Mon, 18 Sep 2017 11:06: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 A84CC1321DE; Mon, 18 Sep 2017 11:06:18 -0700 (PDT)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id B49341AE048A; Mon, 18 Sep 2017 20:06:17 +0200 (CEST)
Date: Mon, 18 Sep 2017 20:07:34 +0200 (CEST)
Message-Id: <20170918.200734.1805388289423863575.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
Cc: rwilton@cisco.com, andy@yumaworks.com, ietfc@btconnect.com, lberger@labn.net, netmod@ietf.org, netmod-chairs@ietf.org, draft-ietf-netmod-revised-datastores@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20170918162107.6qnmrl5hepqcxsrm@elstar.local>
References:   <20170918162107.6qnmrl5hepqcxsrm@elstar.local>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod]  vs 
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Sep 2017 18:06:20 -0000

Juergen Schoenwaelder  wrote:
> On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert Wilton wrote:
> > =

> > > No.=A0 I do not agree that the MUST in RFC 7950 can be removed.
> > > I do not agree the architecture should update YANG at all.
> > OK.
> =

> I am with Andy here.  has always had the requirement to be
> valid and we are not supposed to change that. Mechanisms for inactive=

> configuration or templating must be designed to be backwards compatib=
le
> I think.

Ok.  If we keep the requirement that  in itself must be
valid, it just restricts the usefulness/expressiveness of inactive and
template mechanisms, but it might be ok.

I think that even w/o this requirement, the observable behavior for a
client can be backwards compatible.  For example, suppose we have an
inactive access control rule that refers to a non-existing interface in=

.  If a client that doesn't know anything about inactive asks
for the contents of , our implementation removes the inactive
nodes from the reply to the client.  Only a client that opts-in to
inactive will receive a reply with things that looks invalid if you
don't take the inactive annotation into account.



/martin


From nobody Mon Sep 18 11:25:37 2017
Return-Path: 
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 13405132D49 for ; Mon, 18 Sep 2017 11:25:36 -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 J72zfLp_jqnn for ; Mon, 18 Sep 2017 11:25:33 -0700 (PDT)
Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EADC41342AF for ; Mon, 18 Sep 2017 11:25:28 -0700 (PDT)
Received: by mail-lf0-x22f.google.com with SMTP id k9so1420042lfe.10 for ; Mon, 18 Sep 2017 11:25:28 -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=hOx2R4BGo0YhYo07WNvAp18CVKu8oCrTfZuRTvcc2/I=; b=MMqhT5zHZDKLgJ6Ntbq4Ht/40QnOA86b3LdfHV0APbEZU0G6WVb+wsFN/zMp7DQKr5 GWme8/rtaKxY0pqaZSCqoz5VmOO1UwnR1T/fH2qN7SuyOfM581CHPyD48lWQV4r0mZkF O/o0/PPmtBfMmdRZJGTX+U1wsMUdlQAP5oeVZJpfhuDDZy5FzyV269X2glytpMVhi4+t 993ySaCuNmOHhL4NnQWEDt7/JrlfvQu2f8HSPicT9C2kC4Y8mdoscy6DmkKcryt38Cwa OXFrvDh5GNaZohR3wqvD1J1cRQUwcHqWSniE4QBrL8horA2oT5kcXnni2H5gEcfOB4+P yHzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hOx2R4BGo0YhYo07WNvAp18CVKu8oCrTfZuRTvcc2/I=; b=K9GRMfl5Pdl8Ixdb6t/KUKY5dA2+0bSbMzGMAo8Hsr9NJEZShCDM2wX5+WxN+s4mdg FboO7bkBIzKfuyZA/RQVZ5M86VoMv4/DWorYTsKkBQUT3crCELOFWccnmn9FhpRo9z/9 KWTFGe/FoBQqxKK5cbITnmUmaFH7JcaoD3xdoVqWCHek8wC/beCL40Q1bw9nHq/Nk3ln YW0Y039hSNjdqPIV+XvnXWlGmRV65sA+Tr3T4rdBSocbrCkydPag5aXC1OgDpfepdo5k q/NqfOpvahPXvcoRbBuXPiewRcJKBCvMTnkWNSxRjD7BLlVuB55eLm25Tb29Hb0MG6wX d2WQ==
X-Gm-Message-State: AHPjjUj1J/hR8lOW5jQ264s68IgDXNqcIxmAXJhvvUBNaO7FaeIJ555b WlkpKSq+r2DJdHuyO8UYoFSOsD620y6atNtkrGtZXw==
X-Google-Smtp-Source: AOwi7QCT5RuydNevD1ezpYKk0Bl1BjOrBMZuBjyH+QvOxEmfBx/kPsLrBMElAQAQDGnKe6fTjEaUR4oOmyd0axmlTCA=
X-Received: by 10.25.211.14 with SMTP id k14mr3821303lfg.51.1505759127144; Mon, 18 Sep 2017 11:25:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.18.41 with HTTP; Mon, 18 Sep 2017 11:25:26 -0700 (PDT)
In-Reply-To: <20170918.200734.1805388289423863575.mbj@tail-f.com>
References:   <20170918162107.6qnmrl5hepqcxsrm@elstar.local> <20170918.200734.1805388289423863575.mbj@tail-f.com>
From: Andy Bierman 
Date: Mon, 18 Sep 2017 11:25:26 -0700
Message-ID: 
To: Martin Bjorklund 
Cc: Juergen Schoenwaelder , Robert Wilton ,  "t.petch" , Berger Lou ,  "netmod@ietf.org" , NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org
Content-Type: multipart/alternative; boundary="001a11400d72e424b105597add17"
Archived-At: 
Subject: Re: [netmod]  vs 
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Sep 2017 18:25:36 -0000

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

On Mon, Sep 18, 2017 at 11:07 AM, Martin Bjorklund  wrote:

> Juergen Schoenwaelder  wrote:
> > On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert Wilton wrote:
> > >
> > > > No.  I do not agree that the MUST in RFC 7950 can be removed.
> > > > I do not agree the architecture should update YANG at all.
> > > OK.
> >
> > I am with Andy here.  has always had the requirement to be
> > valid and we are not supposed to change that. Mechanisms for inactive
> > configuration or templating must be designed to be backwards compatible
> > I think.
>
> Ok.  If we keep the requirement that  in itself must be
> valid, it just restricts the usefulness/expressiveness of inactive and
> template mechanisms, but it might be ok.
>
> I think that even w/o this requirement, the observable behavior for a
> client can be backwards compatible.  For example, suppose we have an
> inactive access control rule that refers to a non-existing interface in
> .  If a client that doesn't know anything about inactive asks
> for the contents of , our implementation removes the inactive
> nodes from the reply to the client.  Only a client that opts-in to
> inactive will receive a reply with things that looks invalid if you
> don't take the inactive annotation into account.
>
>
>
There are many ways that validation can fail because inactive nodes are
present,
and considered part of the validation.

e,g, min-elements, max-elements, mandatory, unique.

I think we all agree that validation on the enabled nodes is supposed to
continue to work.

Here is an attempt at a backwards-compatible solution:

1) current  and  responses only include enabled nodes.
2) old-style  operations do not alter inactive nodes
3) NMDA clients use , not  or .  These responses
    include enabled and disabled nodes, so validation does not apply for

4) new style  (i.e.  parameter used) can alter any
type of data node

Note that the YANG MUST rule still applies, because validation is only done
on enabled nodes.
It is only the response message representations that cannot be validated,
not the contents
of  on a server.



> /martin
>

Andy

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




On Mon, Sep 18, 2017 at 11:07 AM, Martin Bjorklund &l=
t;mbj@tail-f.com>=
; wrote:
Juergen Schoenwaelder <=
;j.schoenwaelder@ja=
cobs-university.de> wrote:

> On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert Wilton wrote:

> >

> > > No.=C2=A0 I do not agree that the MUST in RFC 7950 can be re=
moved.

> > > I do not agree the architecture should update YANG at all.
> > OK.

>

> I am with Andy here. <running> has always had the requirement to=
 be

> valid and we are not supposed to change that. Mechanisms for inactive<=
br>
> configuration or templating must be designed to be backwards compatibl=
e

> I think.



Ok.=C2=A0 If we keep the requirement that <running> in itself must be=


valid, it just restricts the usefulness/expressiveness of inactive and

template mechanisms, but it might be ok.



I think that even w/o this requirement, the observable behavior for a

client can be backwards compatible.=C2=A0 For example, suppose we have an
inactive access control rule that refers to a non-existing interface in

<running>.=C2=A0 If a client that doesn't know anything about ina=
ctive asks

for the contents of <running>, our implementation removes the inactiv=
e

nodes from the reply to the client.=C2=A0 Only a client that opts-in to

inactive will receive a reply with things that looks invalid if you

don't take the inactive annotation into account.





There are many ways that=
 validation can fail because inactive nodes are present,
and cons=
idered part of the validation.

e,g, min-elements, =
max-elements, mandatory, unique.

I think we all ag=
ree that validation on the enabled nodes is supposed to continue to work.

Here is an attempt at a backwards-compatible soluti=
on:

1) current <get-config> and <get> =
responses only include enabled nodes.
2) old-style <edit-confi=
g> operations do not alter inactive nodes
3) NMDA clients use =
<get-data>, not <get-config> or <get>.=C2=A0 These respon=
ses
=C2=A0 =C2=A0 include enabled and disabled nodes, so validati=
on does not apply for <running>
4) new style <edit-confi=
g> (i.e. <datastore> parameter used) can alter any type of data no=
de

Note that the YANG MUST rule still applies, bec=
ause validation is only done on enabled nodes.
It is only the res=
ponse message representations that cannot be validated, not the contents
of <running> on a server.


=




/martin



Andy<=
/div>



--001a11400d72e424b105597add17--


From nobody Mon Sep 18 11:36:13 2017
Return-Path: 
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 7D5A31241F3 for ; Mon, 18 Sep 2017 11:35:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.802
X-Spam-Level: 
X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHBFE4rqBzWV for ; Mon, 18 Sep 2017 11:35:53 -0700 (PDT)
Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (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 7EEE3126BF3 for ; Mon, 18 Sep 2017 11:35:53 -0700 (PDT)
Received: from cmgw3 (unknown [10.0.90.84]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id CE0B9144206 for ; Mon, 18 Sep 2017 12:30:01 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with  id B6Vy1w00C2SSUrH016W1Ne; Mon, 18 Sep 2017 12:30:01 -0600
X-Authority-Analysis: v=2.2 cv=K/VSJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=OKIHPbM2HSEA:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=2JCJgTwv5E4A:10 a=2CobPIsa_ywcCmKj4nkA:9 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Cc:To:Subject:From:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=3kYi9lStqrhf7r1yheZQeC0CvRMTzS2EQgZYg6ov7tQ=; b=y+30L5naK9p+yY1+XyDcIgZLLZ 0vkDO8cKeilONx+IzZmN9Sk+6bIVM5UWNczZ1S+KlA9i71OyjH7mJyXvUfo5yOkZkEL9Fp2wvG2Jx eEbPKdYw0X6vxNdGS/GRSRPF8;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:37910 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1du0nt-002ZDe-UO; Mon, 18 Sep 2017 12:29:58 -0600
From: Lou Berger 
To: NetMod WG 
Cc: NetMod WG Chairs 
Message-ID: 
Date: Mon, 18 Sep 2017 14:29:53 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1du0nt-002ZDe-UO
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:37910
X-Source-Auth: lberger@labn.net
X-Email-Count: 2
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7223bis-00 (resend)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Sep 2017 18:35:55 -0000

All,

This is start of a two week poll on making
draft-bjorklund-netmod-rfc7223bis-00 a working group document. Please
send email to the list indicating "yes/support" or "no/do not support".
If indicating no, please state your reservations with the document.  If
yes, please also feel free to provide comments you'd like to see
addressed once the document is a WG document.

The poll ends Oct 2.

Thanks,

Lou (and Kent)


From nobody Mon Sep 18 12:03:30 2017
Return-Path: 
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 CF97D132143; Mon, 18 Sep 2017 12:03:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 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, 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 sajpTKblTIIK; Mon, 18 Sep 2017 12:03:27 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BCAB133055; Mon, 18 Sep 2017 12:03:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1072; q=dns/txt; s=iport; t=1505761407; x=1506971007; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rP4dyocsgg1x/gZOS2nQMhiNE+t6SK5PntcYtnfY/j4=; b=mUnR68a0nFARN064E8efI6eR2R71YnLwfeR6HtV10KFaWOXRI87h03Uu 4NZ97IulbCGHJHbEnJCjcPJxdJjvoHe3RZIsPRAIcBlkTsTpMySbrGf/k bCy/++HtTDO82/w9QPBXGVGKDemmyg9aPvKO5kRbkALZhZovEL3pZzIpY s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CjAAAdGMBZ/4QNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbicHg26KII92mBoOggQKGAuESU8CGoQuPxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUZAgEDAQEhEToLEAIBCA4MAiYCAgIlCxUQAgQBDQWKMxCqCYIniy8BAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEYBYEOgh2CAoZbhEUBEgEfgxOCYAWhCAKUU4IThWq?= =?us-ascii?q?DfoZ9lQgCERkBgTgBHziBAgt3FUmHHHaFbYEjgQ8BAQE?=
X-IronPort-AV: E=Sophos;i="5.42,414,1500940800"; d="scan'208";a="299964070"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Sep 2017 19:03:26 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v8IJ3PxC015166 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 Sep 2017 19:03:26 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 18 Sep 2017 15:03:25 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1263.000; Mon, 18 Sep 2017 15:03:25 -0400
From: "Acee Lindem (acee)" 
To: Lou Berger , NetMod WG 
CC: NetMod WG Chairs 
Thread-Topic: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7223bis-00 (resend)
Thread-Index: AQHTMK0NFNz/5+V6o0ynapRPYEhvx6K7ADWA
Date: Mon, 18 Sep 2017 19:03:25 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.196]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7223bis-00 (resend)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Sep 2017 19:03:29 -0000

SSBoYXZlIHJlYWQgdGhpcyBkb2N1bWVudCBhbmQgc3VwcG9ydCBXRyBhZG9wdGlvbi4NClRoYW5r
cywNCkFjZWUNCg0KT24gOS8xOC8xNywgMjoyOSBQTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgTG91
IEJlcmdlciINCjxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgbGJlcmdlckBs
YWJuLm5ldD4gd3JvdGU6DQoNCj5BbGwsDQo+DQo+VGhpcyBpcyBzdGFydCBvZiBhIHR3byB3ZWVr
IHBvbGwgb24gbWFraW5nDQo+ZHJhZnQtYmpvcmtsdW5kLW5ldG1vZC1yZmM3MjIzYmlzLTAwIGEg
d29ya2luZyBncm91cCBkb2N1bWVudC4gUGxlYXNlDQo+c2VuZCBlbWFpbCB0byB0aGUgbGlzdCBp
bmRpY2F0aW5nICJ5ZXMvc3VwcG9ydCIgb3IgIm5vL2RvIG5vdCBzdXBwb3J0Ii4NCj5JZiBpbmRp
Y2F0aW5nIG5vLCBwbGVhc2Ugc3RhdGUgeW91ciByZXNlcnZhdGlvbnMgd2l0aCB0aGUgZG9jdW1l
bnQuICBJZg0KPnllcywgcGxlYXNlIGFsc28gZmVlbCBmcmVlIHRvIHByb3ZpZGUgY29tbWVudHMg
eW91J2QgbGlrZSB0byBzZWUNCj5hZGRyZXNzZWQgb25jZSB0aGUgZG9jdW1lbnQgaXMgYSBXRyBk
b2N1bWVudC4NCj4NCj5UaGUgcG9sbCBlbmRzIE9jdCAyLg0KPg0KPlRoYW5rcywNCj4NCj5Mb3Ug
KGFuZCBLZW50KQ0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQo+bmV0bW9kIG1haWxpbmcgbGlzdA0KPm5ldG1vZEBpZXRmLm9yZw0KPmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg==


From nobody Mon Sep 18 12:15:59 2017
Return-Path: 
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 5B43D1329B5 for ; Mon, 18 Sep 2017 12:15:57 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fme1YvIErtJB for ; Mon, 18 Sep 2017 12:15:56 -0700 (PDT)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 76140132143 for ; Mon, 18 Sep 2017 12:15:56 -0700 (PDT)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 6D38C1E1FC8 for ; Mon, 18 Sep 2017 13:15:54 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id B7Fq1w0172SSUrH017FtaE; Mon, 18 Sep 2017 13:15:54 -0600
X-Authority-Analysis: v=2.2 cv=K4VSJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=p5GdwvsDEw8A:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=2JCJgTwv5E4A:10 a=2CobPIsa_ywcCmKj4nkA:9 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Cc:To:Subject:From:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=vJsexUbVM0WdjU0OAqT/UYeXF46X24+J1BgPnAs3+4k=; b=QpqWovpEL/VNhbgRr57aH5V5Gs Mb1Of9n5jsYWlAAuG66wYzBLvnYx8GOrURqvEf1+33zdKf6ZPkesjbCieY/7+ZplQgSDFAnri9hmn Fz+NniuHcpmV0Y8nGMATg4NF1;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:38756 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1du1WH-002hoq-QL; Mon, 18 Sep 2017 13:15:50 -0600
From: Lou Berger 
To: NetMod WG 
Cc: NetMod WG Chairs 
Message-ID: <9b125d33-1413-00e5-04c2-408a154745e4@labn.net>
Date: Mon, 18 Sep 2017 15:15:46 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1du1WH-002hoq-QL
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:38756
X-Source-Auth: lberger@labn.net
X-Email-Count: 3
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00 (resend)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Sep 2017 19:15:57 -0000

All,

This is start of a two week poll on making
draft-bjorklund-netmod-rfc7227bis-00 a working group document. Please
send email to the list indicating "yes/support" or "no/do not support".
If indicating no, please state your reservations with the document.  If
yes, please also feel free to provide comments you'd like to see
addressed once the document is a WG document.

The poll ends Oct 2.

Thanks,

Lou (and Kent)


From nobody Mon Sep 18 12:48:13 2017
Return-Path: 
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 12ECC132351 for ; Mon, 18 Sep 2017 12:48:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level: 
X-Spam-Status: No, score=-4.701 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=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L_G6gs_YBAKY for ; Mon, 18 Sep 2017 12:48:08 -0700 (PDT)
Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (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 CF11E132949 for ; Mon, 18 Sep 2017 12:48:08 -0700 (PDT)
Received: from cmgw3 (unknown [10.0.90.84]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id 3953E140905 for ; Mon, 18 Sep 2017 13:48:06 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with  id B7o21w00h2SSUrH017o5dj; Mon, 18 Sep 2017 13:48:06 -0600
X-Authority-Analysis: v=2.2 cv=K/VSJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=2JCJgTwv5E4A:10 a=48vgC7mUAAAA:8 a=I251l077QEUY1vJds0EA:9 a=QEXdDO2ut3YA:10 a=rKrVYePj7rwA:10 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:References:Cc:To:From:Subject:Sender:Reply-To: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=Wru5AZ1hdTmhlUqP2lISDj8IGUsC0GbyO5hizf85MGk=; b=Fxhc3WonVC5xH7mkn7c3CM+R6c v/jf27HNoIZ5WknYKm/yfYfqd70i9xJgI9+DraAr6MlKqtK3v7LIp5aTb5zUwHug1w1rPMXQMYy/f RBWzOCZ7AAM2ZVI7rq5eJuIhk;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:40538 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1du21R-002ntE-At; Mon, 18 Sep 2017 13:48:02 -0600
From: Lou Berger 
To: NetMod WG 
Cc: NetMod WG Chairs 
References: <9b125d33-1413-00e5-04c2-408a154745e4@labn.net>
Message-ID: <2edf2573-c176-5494-cdb3-a6cbb79e46f8@labn.net>
Date: Mon, 18 Sep 2017 15:47:50 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <9b125d33-1413-00e5-04c2-408a154745e4@labn.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1du21R-002ntE-At
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:40538
X-Source-Auth: lberger@labn.net
X-Email-Count: 8
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: [netmod] Correction: WG adoption poll draft-bjorklund-netmod-rfc7277bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Sep 2017 19:48:11 -0000

The draft being polled in this thread is
draft-bjorklund-netmod-rfc7277bis-00

Lou

On 9/18/2017 3:15 PM, Lou Berger wrote:
> All,
>
> This is start of a two week poll on making
> draft-bjorklund-netmod-rfc7227bis-00 a working group document. Please
> send email to the list indicating "yes/support" or "no/do not support".
> If indicating no, please state your reservations with the document.  If
> yes, please also feel free to provide comments you'd like to see
> addressed once the document is a WG document.
>
> The poll ends Oct 2.
>
> Thanks,
>
> Lou (and Kent)
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>


From nobody Mon Sep 18 14:22:09 2017
Return-Path: 
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 3CF0D1330BF for ; Mon, 18 Sep 2017 14:22:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level: 
X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpQdXIob3Jgt for ; Mon, 18 Sep 2017 14:22:07 -0700 (PDT)
Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) (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 7232713306C for ; Mon, 18 Sep 2017 14:22:07 -0700 (PDT)
Received: from cmgw4 (unknown [10.0.90.85]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id 3312C1ADCD9 for ; Mon, 18 Sep 2017 08:33:53 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id B2Zo1w01F2SSUrH012ZsRS; Mon, 18 Sep 2017 08:33:52 -0600
X-Authority-Analysis: v=2.2 cv=OZLoNlbY c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=2JCJgTwv5E4A:10 a=2CobPIsa_ywcCmKj4nkA:9 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Cc:To:Subject:From:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=vJsexUbVM0WdjU0OAqT/UYeXF46X24+J1BgPnAs3+4k=; b=o7KfTGCm/cGlP8Ho2kCVnd0iOb picyz5QtA49kPwLZ/+xmbfHvZhb+VjkXAe2QUzYuAb8rLQ4krSx25AjKRuKBSP3bghNnMFyJe0yz3 NOrC8yP9rbvx1fQDgmBNUISqv;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:55060 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dtx7M-001jDd-H6; Mon, 18 Sep 2017 08:33:48 -0600
From: Lou Berger 
To: NetMod WG 
Cc: NetMod WG Chairs 
Message-ID: <393d3f20-98e3-b4de-e2d7-d627de59ac1f@labn.net>
Date: Mon, 18 Sep 2017 10:33:45 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dtx7M-001jDd-H6
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:55060
X-Source-Auth: lberger@labn.net
X-Email-Count: 5
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Sep 2017 21:22:08 -0000

All,

This is start of a two week poll on making
draft-bjorklund-netmod-rfc7227bis-00 a working group document. Please
send email to the list indicating "yes/support" or "no/do not support".
If indicating no, please state your reservations with the document.  If
yes, please also feel free to provide comments you'd like to see
addressed once the document is a WG document.

The poll ends Oct 2.

Thanks,

Lou (and Kent)


From nobody Tue Sep 19 01:41:02 2017
Return-Path: 
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 7CC4E132198; Tue, 19 Sep 2017 01:41:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 qD3SJsQcckFY; Tue, 19 Sep 2017 01:41:00 -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 B4C22126DFE; Tue, 19 Sep 2017 01:40:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1019; q=dns/txt; s=iport; t=1505810460; x=1507020060; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=8FMUZeqMk46mryvHf4ZcHskk61qtzxwrXZWoemsl0oU=; b=AL2TKp82t8lXtyY/N6RaJ0T1N48ROgT3OW+mib/Qs32w1EmWESpO5TcH PgKW2WLhgTJuQ/yXb/zMp+KqE38qRY2ZvITBawDxqbZ4xXfl2VoRaRWsM 1slapcScA8S66sfLGBBWTAHXErK9F26jKxW7FE3MMc7P+NjsfFv2YGhmt A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpAQAs18BZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD5uJ4N1ixSQTCuWM4IEChgLhElPAoUVFQECAQEBAQEBAWsohRk?= =?us-ascii?q?BAQQBASEVNgsQCw4KAgImAgInMAYBDAYCAQGKLxCpd4IniycBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEYBYEOgh2DUoIOgn2ERQESAYMygmAFmEKISZRWghOFaoNahyK?= =?us-ascii?q?NYIdXgTk1IoECCzIhCBwVSYcdPzaGKYIyAQEB?=
X-IronPort-AV: E=Sophos;i="5.42,417,1500940800"; d="scan'208";a="657575447"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Sep 2017 08:40:57 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8J8evHE023391; Tue, 19 Sep 2017 08:40:57 GMT
To: Lou Berger , NetMod WG 
Cc: NetMod WG Chairs 
References: <9b125d33-1413-00e5-04c2-408a154745e4@labn.net> <2edf2573-c176-5494-cdb3-a6cbb79e46f8@labn.net>
From: Robert Wilton 
Message-ID: <2b653bbc-06ed-f83b-a58a-00476c16fa66@cisco.com>
Date: Tue, 19 Sep 2017 09:40:57 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <2edf2573-c176-5494-cdb3-a6cbb79e46f8@labn.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Correction: WG adoption poll draft-bjorklund-netmod-rfc7277bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Sep 2017 08:41:01 -0000

support.

I have reviewed this document.

Thanks,
Rob


On 18/09/2017 20:47, Lou Berger wrote:
> The draft being polled in this thread is
> draft-bjorklund-netmod-rfc7277bis-00
>
> Lou
>
> On 9/18/2017 3:15 PM, Lou Berger wrote:
>> All,
>>
>> This is start of a two week poll on making
>> draft-bjorklund-netmod-rfc7227bis-00 a working group document. Please
>> send email to the list indicating "yes/support" or "no/do not support".
>> If indicating no, please state your reservations with the document.  If
>> yes, please also feel free to provide comments you'd like to see
>> addressed once the document is a WG document.
>>
>> The poll ends Oct 2.
>>
>> Thanks,
>>
>> Lou (and Kent)
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


From nobody Tue Sep 19 01:41:59 2017
Return-Path: 
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 E11F913307E; Tue, 19 Sep 2017 01:41:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 n15MZ_d5HbVy; Tue, 19 Sep 2017 01:41:56 -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 1B2FA126DFE; Tue, 19 Sep 2017 01:41:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=715; q=dns/txt; s=iport; t=1505810516; x=1507020116; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=vAAvv9lov00zUFy3aKsmytlLOVa6VaknUchH1L+n1C0=; b=U5TLbq9x2JZLe5l0GEh+TQxGGjXAwNqtZzpHCcQzgPAgcOFMxAyxbhCX 8Cj23xSBrZUUqwTxC130LNM05yZlONjIkd66CIrRn/JHFnXBzRdB2ZBF9 GEdXIlOuc54JrfrrFy30fm5uVjqPWhMrM43J8HdFnlpU/P9PKV5g+SA/n M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpAQBW18BZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD5uJ4N1ixSQTCuWM4IEChgLhElPAoUVFQECAQEBAQEBAWsohRk?= =?us-ascii?q?BAQQBASEVNgsQCw4KAgImAgInMAYBDAYCAQGKLxCpd4IniycBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEYBYEOgh2DUoIOC4JyhEUBEgGDMoJgBZhCiEmUVoIThWqDWoc?= =?us-ascii?q?ijWCHV4E5NSKBAgsyIQgcFUmHHT82himCMgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.42,417,1500940800"; d="scan'208";a="655754762"
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; 19 Sep 2017 08:41:54 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8J8frg5000573; Tue, 19 Sep 2017 08:41:54 GMT
To: Lou Berger , NetMod WG 
Cc: NetMod WG Chairs 
References: 
From: Robert Wilton 
Message-ID: 
Date: Tue, 19 Sep 2017 09:41:53 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7223bis-00 (resend)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Sep 2017 08:41:58 -0000

Support.

I have reviewed this document.

Thanks,
Rob


On 18/09/2017 19:29, Lou Berger wrote:
> All,
>
> This is start of a two week poll on making
> draft-bjorklund-netmod-rfc7223bis-00 a working group document. Please
> send email to the list indicating "yes/support" or "no/do not support".
> If indicating no, please state your reservations with the document.  If
> yes, please also feel free to provide comments you'd like to see
> addressed once the document is a WG document.
>
> The poll ends Oct 2.
>
> Thanks,
>
> Lou (and Kent)
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


From nobody Tue Sep 19 02:39:59 2017
Return-Path: 
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 41E51126BF0; Tue, 19 Sep 2017 02:39:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 3yGV7P67Iq4v; Tue, 19 Sep 2017 02:39:55 -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 D46D01241F3; Tue, 19 Sep 2017 02:39:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12896; q=dns/txt; s=iport; t=1505813995; x=1507023595; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=2h5jCAfr+gqCT7MDPi0y4efUyJYbwJGKcPWK39jSRZc=; b=LeUwLnwQnbSWsYaxrxW2ks7ryvY1BB9pWPOyV9RLr2cntw70YiZLbfcX dvrFx4PBq/9E+4cXFBGXIQoj9liboytmhSwUMEV1Pe4y99n08bQfH9DUb c4Y/BeVVlfurd7ax79oMCXVh5AFAd1ksfAT7C9BWKD07qKIW5RMjnmk1V 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAgCK5cBZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhSwng3WLFJBMK3mPbYVNggQKhTsChRcVAQIBAQEBAQEBayiFGAE?= =?us-ascii?q?BAQMBI1YQCxACBhUSAwICRgMOBgEMBgIBAReKEAipWoInJ4sAAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBHYMrg1KBYyuCSDWEMy0CVYJUgmAFoQuUVoITiUSHIooAg2C?= =?us-ascii?q?HV4E5NSKBDTIhCBwVh2Y/NoYcK4IUAQEB?=
X-IronPort-AV: E=Sophos;i="5.42,417,1500940800";  d="scan'208,217";a="655756321"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Sep 2017 09:39:52 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v8J9dq9h021874; Tue, 19 Sep 2017 09:39:52 GMT
To: Andy Bierman , Martin Bjorklund 
Cc: Juergen Schoenwaelder , "t.petch" , Berger Lou , "netmod@ietf.org" , NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org
References:   <20170918162107.6qnmrl5hepqcxsrm@elstar.local> <20170918.200734.1805388289423863575.mbj@tail-f.com> 
From: Robert Wilton 
Message-ID: <99b9a2c6-4bb4-121f-0cba-925cefe09712@cisco.com>
Date: Tue, 19 Sep 2017 10:39:52 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------2910F17FAA5431B974B1AB53"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod]  vs 
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Sep 2017 09:39:57 -0000

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



On 18/09/2017 19:25, Andy Bierman wrote:
>
>
> On Mon, Sep 18, 2017 at 11:07 AM, Martin Bjorklund  > wrote:
>
>     Juergen Schoenwaelder      > wrote:
>     > On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert Wilton wrote:
>     > >
>     > > > No.  I do not agree that the MUST in RFC 7950 can be removed.
>     > > > I do not agree the architecture should update YANG at all.
>     > > OK.
>     >
>     > I am with Andy here.  has always had the requirement to be
>     > valid and we are not supposed to change that. Mechanisms for
>     inactive
>     > configuration or templating must be designed to be backwards
>     compatible
>     > I think.
>
>     Ok.  If we keep the requirement that  in itself must be
>     valid, it just restricts the usefulness/expressiveness of inactive and
>     template mechanisms, but it might be ok.
>
>     I think that even w/o this requirement, the observable behavior for a
>     client can be backwards compatible.  For example, suppose we have an
>     inactive access control rule that refers to a non-existing
>     interface in
>     .  If a client that doesn't know anything about inactive asks
>     for the contents of , our implementation removes the inactive
>     nodes from the reply to the client.  Only a client that opts-in to
>     inactive will receive a reply with things that looks invalid if you
>     don't take the inactive annotation into account.
>
>
>
> There are many ways that validation can fail because inactive nodes 
> are present,
> and considered part of the validation.
>
> e,g, min-elements, max-elements, mandatory, unique.
>
> I think we all agree that validation on the enabled nodes is supposed 
> to continue to work.
>
> Here is an attempt at a backwards-compatible solution:
>
> 1) current  and  responses only include enabled nodes.
> 2) old-style  operations do not alter inactive nodes
> 3) NMDA clients use , not  or .  These 
> responses
>     include enabled and disabled nodes, so validation does not apply 
> for 
> 4) new style  (i.e.  parameter used) can alter 
> any type of data node
//I think that inactive should always be an optional extension.  Not 
everything needs the additional complexity.

Hence rather than tying this function to specific NETCONF operations, I 
would suggest that there should be an extra parameter (like for 
with-defaults) to allow a client to indicate to the server that a get or 
edit request is using the "with-inactive" extension.
1) The server should also have a capability (or perhaps a leaf defined 
in YANG library) to indicate that it supports inactive configuration.
2) If a client doesn't use the extra "with-inactive" parameter during a 
get request then only active nodes are returned.
3) If a client doesn't use the extra "with-inactive" parameter during an 
edit-data request then the request cannot include an extra inactive 
meta-data.  The request is processed in a way that is equivalent to an 
existing NETCONF implementation, but it may unknowingly remove some 
inactive configuration (e.g. via a replace or remove operation on an 
inactive node).  Operations like create, delete, none, replace should 
all treat an inactive target node the same way as in the node doesn't 
exist (e.g. delete on an inactive node would return a "data-missing" 
error), this ensures that the behaviour that an unaware client observes 
is the same as the existing behaviour that it would expect from a 
regular 6241 compliant NETCONF implementation.
4) It a client makes a get request including the "with-inactive" 
parameter then they also get the inactive nodes as well, marked with a 
meta-data annotation.
5) If a client makes an edit request including the "with-inactive" 
parameter, then the inactive meta-data annotation can be used to label 
inactive nodes.  Inactive nodes are regarded as regular data nodes for 
create/delete/replace/none operation error checking.

I think that this approach is similar (perhaps even the same) as Martin 
described.

Thanks,
Rob


>
> Note that the YANG MUST rule still applies, because validation is only 
> done on enabled nodes.
> It is only the response message representations that cannot be 
> validated, not the contents
> of  on a server.
>
>
>
>     /martin
>
>
> Andy
>


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


  
    
  
  
    


    

    

    
On 18/09/2017 19:25, Andy Bierman
      wrote:

    

    

      
      


        


          
On Mon, Sep 18, 2017 at 11:07 AM,
            Martin Bjorklund <mbj@tail-f.com>
            wrote:

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

              > On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert
              Wilton wrote:

              > >

              > > > No.  I do not agree that the MUST in RFC
              7950 can be removed.

              > > > I do not agree the architecture should
              update YANG at all.

              > > OK.

              >

              > I am with Andy here. <running> has always had
              the requirement to be

              > valid and we are not supposed to change that.
              Mechanisms for inactive

              > configuration or templating must be designed to be
              backwards compatible

              > I think.

              

              Ok.  If we keep the requirement that <running> in
              itself must be

              valid, it just restricts the usefulness/expressiveness of
              inactive and

              template mechanisms, but it might be ok.

              

              I think that even w/o this requirement, the observable
              behavior for a

              client can be backwards compatible.  For example, suppose
              we have an

              inactive access control rule that refers to a non-existing
              interface in

              <running>.  If a client that doesn't know anything
              about inactive asks

              for the contents of <running>, our implementation
              removes the inactive

              nodes from the reply to the client.  Only a client that
              opts-in to

              inactive will receive a reply with things that looks
              invalid if you

              don't take the inactive annotation into account.

              

                  

                

            


            

            
There are many ways that validation can fail because
              inactive nodes are present,

            
and considered part of the validation.

            


            

            
e,g, min-elements, max-elements, mandatory, unique.

            


            

            
I think we all agree that validation on the enabled
              nodes is supposed to continue to work.

            


            

            
Here is an attempt at a backwards-compatible solution:

            


            

            
1) current <get-config> and <get> responses
              only include enabled nodes.

            
2) old-style <edit-config> operations do not
              alter inactive nodes

            
3) NMDA clients use <get-data>, not
              <get-config> or <get>.  These responses

            
    include enabled and disabled nodes, so validation
              does not apply for <running>

            
4) new style <edit-config> (i.e.
              <datastore> parameter used) can alter any type of
              data node

          

        

      

    

     I think that inactive should always be an optional
    extension.  Not everything needs the additional complexity.

    

    Hence rather than tying this function to specific NETCONF
    operations, I would suggest that there should be an extra parameter
    (like for with-defaults) to allow a client to indicate to the server
    that a get or edit request is using the "with-inactive" extension.

    1) The server should also have a capability (or perhaps a leaf
    defined in YANG library) to indicate that it supports inactive
    configuration.

    2) If a client doesn't use the extra "with-inactive" parameter
    during a get request then only active nodes are returned.

    3) If a client doesn't use the extra "with-inactive" parameter
    during an edit-data request then the request cannot include an extra
    inactive meta-data.  The request is processed in a way that is
    equivalent to an existing NETCONF implementation, but it may
    unknowingly remove some inactive configuration (e.g. via a replace
    or remove operation on an inactive node).  Operations like create,
    delete, none, replace should all treat an inactive target node the
    same way as in the node doesn't exist (e.g. delete on an inactive
    node would return a "data-missing" error), this ensures that the
    behaviour that an unaware client observes is the same as the
    existing behaviour that it would expect from a regular 6241
    compliant NETCONF implementation.

    4) It a client makes a get request including the "with-inactive"
    parameter then they also get the inactive nodes as well, marked with
    a meta-data annotation.

    5) If a client makes an edit request including the "with-inactive"
    parameter, then the inactive meta-data annotation can be used to
    label inactive nodes.  Inactive nodes are regarded as regular data
    nodes for create/delete/replace/none operation error checking.

    

    I think that this approach is similar (perhaps even the same) as
    Martin described.

    

    Thanks,

    Rob

    

    

    

      

        

          

            


            

            
Note that the YANG MUST rule still applies, because
              validation is only done on enabled nodes.

            
It is only the response message representations that
              cannot be validated, not the contents

            
of <running> on a server.

            


            

            


            

            

                  

                  /martin

                

          

          

        

        
Andy

        


        

      

    

    

  


--------------2910F17FAA5431B974B1AB53--


From nobody Tue Sep 19 02:46:24 2017
Return-Path: 
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 D3AB5132EDA for ; Tue, 19 Sep 2017 02:46:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level: 
X-Spam-Status: No, score=-6.999 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, URIBL_BLOCKED=0.001] 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 NfSkBQvXNX6u for ; Tue, 19 Sep 2017 02:46:20 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 631921270AB for ; Tue, 19 Sep 2017 02:46:20 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:f4a0:4ce4:6515:464f]) by mail.nic.cz (Postfix) with ESMTPSA id AF7B1622A2 for ; Tue, 19 Sep 2017 11:46:18 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1505814378; bh=ptixUmRIS13Zew+dS9TRLQuxN91j2wInPPEG4S25Fkw=; h=From:To:Date; b=N/+sWf+aGTH6h4StLRGhZDV3M3GevVFXtKaAdZLc9AZJzd6oUMOzS976q6cTcyF4l eXNKypUIfQnsLPUfLXL52VSRCzXUmBM+kplT+PvamuyR4oIP4Nc7h7Vd/gNnTg0pvc mrz4fpLHWz3qWx3RYulKFTTp+BZbypjA1l4PVs6I=
Message-ID: <1505814417.5445.14.camel@nic.cz>
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Tue, 19 Sep 2017 11:46:57 +0200
In-Reply-To: <393d3f20-98e3-b4de-e2d7-d627de59ac1f@labn.net>
References: <393d3f20-98e3-b4de-e2d7-d627de59ac1f@labn.net>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.24.5 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Sep 2017 09:46:23 -0000

Hi,

I support the adoption but I propose two conceptual changes:

1. Introduce a new module name and namespace so that it is not necessary to
carry along the deprecated baggage. If readability is the primary concern, this
is IMO the way to go. Instead of "ietf-ip-2", I'd suggest something like "ietf-
ip-nmda".

2. Avoid obsoleting RFC 7277. I believe the old modules may continue to be used
in areas where NMDA is an overkill, such as open source home routers. NMDA
implementors should be aware of the new modules but there is no need to
eradicate the old data models.

#2 applies also to other modules for which the NMDA version is underway.

Lada

PS. The subject is wrong, it shoud be -rfc7277bis-
 
Lou Berger píše v Po 18. 09. 2017 v 10:33 -0400:
> All,
> 
> This is start of a two week poll on making
> draft-bjorklund-netmod-rfc7227bis-00 a working group document. Please
> send email to the list indicating "yes/support" or "no/do not support".
> If indicating no, please state your reservations with the document.  If
> yes, please also feel free to provide comments you'd like to see
> addressed once the document is a WG document.
> 
> The poll ends Oct 2.
> 
> Thanks,
> 
> Lou (and Kent)
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Tue Sep 19 02:57:35 2017
Return-Path: 
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 8C07B126BF0; Tue, 19 Sep 2017 02:57:34 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPZtOnqcpa6y; Tue, 19 Sep 2017 02:57:32 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFED132EDA; Tue, 19 Sep 2017 02:57:32 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id B2C8B1AE02A7; Tue, 19 Sep 2017 11:57:30 +0200 (CEST)
Date: Tue, 19 Sep 2017 11:55:59 +0200 (CEST)
Message-Id: <20170919.115559.1080249872764998055.mbj@tail-f.com>
To: rwilton@cisco.com
Cc: andy@yumaworks.com, j.schoenwaelder@jacobs-university.de, ietfc@btconnect.com, lberger@labn.net, netmod@ietf.org, netmod-chairs@ietf.org, draft-ietf-netmod-revised-datastores@ietf.org
From: Martin Bjorklund 
In-Reply-To: <99b9a2c6-4bb4-121f-0cba-925cefe09712@cisco.com>
References: <20170918.200734.1805388289423863575.mbj@tail-f.com>  <99b9a2c6-4bb4-121f-0cba-925cefe09712@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod]  vs 
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Sep 2017 09:57:35 -0000

Robert Wilton  wrote:
> =

> =

> On 18/09/2017 19:25, Andy Bierman wrote:
> >
> >
> > On Mon, Sep 18, 2017 at 11:07 AM, Martin Bjorklund  > > wrote:
> >
> >     Juergen Schoenwaelder  >     > wrote:
> >     > On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert Wilton wrote=
:
> >     > >
> >     > > > No.=A0 I do not agree that the MUST in RFC 7950 can be re=
moved.
> >     > > > I do not agree the architecture should update YANG at all=
.=

> >     > > OK.
> >     >
> >     > I am with Andy here.  has always had the requirement=
 to be
> >     > valid and we are not supposed to change that. Mechanisms for
> >     inactive
> >     > configuration or templating must be designed to be backwards
> >     compatible
> >     > I think.
> >
> >     Ok.=A0 If we keep the requirement that  in itself must=
 be
> >     valid, it just restricts the usefulness/expressiveness of inact=
ive and
> >     template mechanisms, but it might be ok.
> >
> >     I think that even w/o this requirement, the observable behavior=
 for a
> >     client can be backwards compatible.=A0 For example, suppose we =
have an
> >     inactive access control rule that refers to a non-existing
> >     interface in
> >     .=A0 If a client that doesn't know anything about inac=
tive asks
> >     for the contents of , our implementation removes the i=
nactive
> >     nodes from the reply to the client.=A0 Only a client that opts-=
in to
> >     inactive will receive a reply with things that looks invalid if=
 you
> >     don't take the inactive annotation into account.
> >
> >
> >
> > There are many ways that validation can fail because inactive nodes=

> > are present,
> > and considered part of the validation.
> >
> > e,g, min-elements, max-elements, mandatory, unique.
> >
> > I think we all agree that validation on the enabled nodes is suppos=
ed
> > to continue to work.

Yes.

> > Here is an attempt at a backwards-compatible solution:
> >
> > 1) current  and  responses only include enabled
> > nodes.
> > 2) old-style  operations do not alter inactive nodes
> > 3) NMDA clients use , not  or .=A0 These=

> > responses
> > =A0 =A0 include enabled and disabled nodes, so validation does not =
apply
> > for 
> > 4) new style  (i.e.  parameter used) can al=
ter
> > any type of data node
> //I think that inactive should always be an optional extension.=A0 No=
t
> everything needs the additional complexity.
> =

> Hence rather than tying this function to specific NETCONF operations,=

> I would suggest that there should be an extra parameter (like for
> with-defaults) to allow a client to indicate to the server that a get=

> or edit request is using the "with-inactive" extension.
> 1) The server should also have a capability (or perhaps a leaf define=
d
> in YANG library) to indicate that it supports inactive configuration.=

> 2) If a client doesn't use the extra "with-inactive" parameter during=

> a get request then only active nodes are returned.
> 3) If a client doesn't use the extra "with-inactive" parameter during=

> an edit-data request then the request cannot include an extra inactiv=
e
> meta-data.=A0 The request is processed in a way that is equivalent to=
 an
> existing NETCONF implementation, but it may unknowingly remove some
> inactive configuration (e.g. via a replace or remove operation on an
> inactive node).=A0 Operations like create, delete, none, replace shou=
ld
> all treat an inactive target node the same way as in the node doesn't=

> exist (e.g. delete on an inactive node would return a "data-missing"
> error), this ensures that the behaviour that an unaware client
> observes is the same as the existing behaviour that it would expect
> from a regular 6241 compliant NETCONF implementation.
> 4) It a client makes a get request including the "with-inactive"
> parameter then they also get the inactive nodes as well, marked with =
a
> meta-data annotation.
> 5) If a client makes an edit request including the "with-inactive"
> parameter, then the inactive meta-data annotation can be used to labe=
l
> inactive nodes.=A0 Inactive nodes are regarded as regular data nodes =
for
> create/delete/replace/none operation error checking.
> =

> I think that this approach is similar (perhaps even the same) as
> Martin described.

This is indeed how our implementation works (except I think we don't
do 5; if the client sends an "inactive" attribute it doesn't have to
also send with-inactive).

> > Note that the YANG MUST rule still applies, because validation is o=
nly
> > done on enabled nodes.
> > It is only the response message representations that cannot be
> > validated, not the contents
> > of  on a server.

So the question is how we can make sure that the text in the NMDA
draft covers this yet-to-be-defined feature w/o having to define it
now?  We thought that the current text was sufficient, but do we have
to make any changes to it?


/martin


From nobody Tue Sep 19 03:00:52 2017
Return-Path: 
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 0CFD3126D0C for ; Tue, 19 Sep 2017 03:00:51 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZMdlNOjuPLQ for ; Tue, 19 Sep 2017 03:00:48 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 05C9C132EDA for ; Tue, 19 Sep 2017 03:00:48 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 1FC5F1AE02A7; Tue, 19 Sep 2017 12:00:47 +0200 (CEST)
Date: Tue, 19 Sep 2017 11:59:15 +0200 (CEST)
Message-Id: <20170919.115915.1668734288988659917.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <1505814417.5445.14.camel@nic.cz>
References: <393d3f20-98e3-b4de-e2d7-d627de59ac1f@labn.net> <1505814417.5445.14.camel@nic.cz>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Sep 2017 10:00:51 -0000

Ladislav Lhotka  wrote:
> Hi,
> =

> I support the adoption but I propose two conceptual changes:
> =

> 1. Introduce a new module name and namespace so that it is not
> necessary to carry along the deprecated baggage. If readability is
> the primary concern, this is IMO the way to go. Instead of
> "ietf-ip-2", I'd suggest something like "ietf- ip-nmda".
> =

> 2. Avoid obsoleting RFC 7277. I believe the old modules may continue
> to be used =

> in areas where NMDA is an overkill, such as open source home
> routers.

Why wouldn't NMDA be appropriate in an open source home router?  Note
that the new model really just have a single tree instead of two
trees, so the data that needs to be instrumented is more or less the
same.

In fact, if we claim that the new architecture is not appropriate for
some devices I think we have failed, especially if the conclusion is
that we need to maintain two versions of all modules going forward.


/martin






> NMDA
> implementors should be aware of the new modules but there is no need =
to
> eradicate the old data models.
> =

> #2 applies also to other modules for which the NMDA version is underw=
ay.
> =

> Lada
> =

> PS. The subject is wrong, it shoud be -rfc7277bis-
>  =

> Lou Berger p=ED=A8e v Po 18. 09. 2017 v 10:33 -0400:
> > All,
> > =

> > This is start of a two week poll on making
> > draft-bjorklund-netmod-rfc7227bis-00 a working group document. Plea=
se
> > send email to the list indicating "yes/support" or "no/do not suppo=
rt".
> > If indicating no, please state your reservations with the document.=
  If
> > yes, please also feel free to provide comments you'd like to see
> > addressed once the document is a WG document.
> > =

> > The poll ends Oct 2.
> > =

> > Thanks,
> > =

> > Lou (and Kent)
> > =

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

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

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


From nobody Tue Sep 19 03:44:13 2017
Return-Path: 
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 F0CF3134216; Tue, 19 Sep 2017 03:44:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 PbAdmbyS9El1; Tue, 19 Sep 2017 03:44:10 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B651134210; Tue, 19 Sep 2017 03:44:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1462; q=dns/txt; s=iport; t=1505817850; x=1507027450; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=adjU4UstH1x2uvABTP66txPXddRV8HWhccjvDZJN+sc=; b=HB8rvuZRwzCpkc2jqhwYpSE9kgfoCqwhs0tcgZpF8JTH2qBsE64bhpOl j6C4KdVFUXwYSKaJlskmHwvTiNijqfdOe4IaK/ccArp9jC2AttENotIQc o4e76cY234C4ipYv+kKVQQF/z1/aEQOWe+IZgevMFQZl2iPTOiFnguSWI 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CaAACf9MBZ/4wNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbicHg26KIJFrliUOggQKGAuESU8CGoQ7PxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUZAQEEAQEhEToLEAIBCA4KAgImAgICJQsVEAIEAQ0FijMQqX2CJ4soAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGAWBDoIdggKGW4RFARIBHxeCfIJgBaELApRUghO?= =?us-ascii?q?Faop8lQoCERkBgTgBHziBAgt3FUmHHHaGKYEjgQ8BAQE?=
X-IronPort-AV: E=Sophos;i="5.42,417,1500940800"; d="scan'208";a="79254683"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Sep 2017 10:44:09 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v8JAi9Ph018257 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Sep 2017 10:44:09 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 19 Sep 2017 06:44:08 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1263.000; Tue, 19 Sep 2017 06:44:08 -0400
From: "Acee Lindem (acee)" 
To: Lou Berger , NetMod WG 
CC: NetMod WG Chairs 
Thread-Topic: [netmod] Correction: WG adoption poll draft-bjorklund-netmod-rfc7277bis-00
Thread-Index: AQHTMLcVzhy+4h4Rz0WlOTb/Q9t/VqK8BvQA
Date: Tue, 19 Sep 2017 10:44:08 +0000
Message-ID: 
References: <9b125d33-1413-00e5-04c2-408a154745e4@labn.net> <2edf2573-c176-5494-cdb3-a6cbb79e46f8@labn.net>
In-Reply-To: <2edf2573-c176-5494-cdb3-a6cbb79e46f8@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.196]
Content-Type: text/plain; charset="utf-8"
Content-ID: <950026C0AD67764088471034F2215970@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] Correction: WG adoption poll draft-bjorklund-netmod-rfc7277bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Sep 2017 10:44:12 -0000

SSBzdXBwb3J0IFdHIGFkb3B0aW9uLg0KVGhhbmtzLA0KQWNlZQ0KDQpPbiA5LzE4LzE3LCAzOjQ3
IFBNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBMb3UgQmVyZ2VyIg0KPG5ldG1vZC1ib3VuY2VzQGll
dGYub3JnIG9uIGJlaGFsZiBvZiBsYmVyZ2VyQGxhYm4ubmV0PiB3cm90ZToNCg0KPlRoZSBkcmFm
dCBiZWluZyBwb2xsZWQgaW4gdGhpcyB0aHJlYWQgaXMNCj5kcmFmdC1iam9ya2x1bmQtbmV0bW9k
LXJmYzcyNzdiaXMtMDANCj4NCj5Mb3UNCj4NCj5PbiA5LzE4LzIwMTcgMzoxNSBQTSwgTG91IEJl
cmdlciB3cm90ZToNCj4+IEFsbCwNCj4+DQo+PiBUaGlzIGlzIHN0YXJ0IG9mIGEgdHdvIHdlZWsg
cG9sbCBvbiBtYWtpbmcNCj4+IGRyYWZ0LWJqb3JrbHVuZC1uZXRtb2QtcmZjNzIyN2Jpcy0wMCBh
IHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuIFBsZWFzZQ0KPj4gc2VuZCBlbWFpbCB0byB0aGUgbGlz
dCBpbmRpY2F0aW5nICJ5ZXMvc3VwcG9ydCIgb3IgIm5vL2RvIG5vdCBzdXBwb3J0Ii4NCj4+IElm
IGluZGljYXRpbmcgbm8sIHBsZWFzZSBzdGF0ZSB5b3VyIHJlc2VydmF0aW9ucyB3aXRoIHRoZSBk
b2N1bWVudC4gIElmDQo+PiB5ZXMsIHBsZWFzZSBhbHNvIGZlZWwgZnJlZSB0byBwcm92aWRlIGNv
bW1lbnRzIHlvdSdkIGxpa2UgdG8gc2VlDQo+PiBhZGRyZXNzZWQgb25jZSB0aGUgZG9jdW1lbnQg
aXMgYSBXRyBkb2N1bWVudC4NCj4+DQo+PiBUaGUgcG9sbCBlbmRzIE9jdCAyLg0KPj4NCj4+IFRo
YW5rcywNCj4+DQo+PiBMb3UgKGFuZCBLZW50KQ0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+PiBu
ZXRtb2RAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
bmV0bW9kDQo+Pg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQo+bmV0bW9kIG1haWxpbmcgbGlzdA0KPm5ldG1vZEBpZXRmLm9yZw0KPmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg==


From nobody Tue Sep 19 04:01:38 2017
Return-Path: 
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 623CC132F2E; Tue, 19 Sep 2017 04:01:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.91
X-Spam-Level: 
X-Spam-Status: No, score=-2.91 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 4YKWdhoNQUlo; Tue, 19 Sep 2017 04:01:32 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10106.outbound.protection.outlook.com [40.107.1.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E286D126BF0; Tue, 19 Sep 2017 04:01:31 -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=fOl/AsRHtAyJYb0rzRvIz5qAJjZKo6ZdmSQLPxejgBM=; b=LL+eFasAO+1T4ZKXyCccy31apkW1jZA2uj/8zGxScj0yTYGt3hd8u2C7imzIWVqt4UCIKVEOTG6oKKzP/j/ay/qqeeCq9RET1n9zhL8s4Hc9sxJL2To1qFqFTMt64rl38U7XduVTOwR/pPJaXrrLlVlClH8Sju0FjSdvVM/rLaw=
Received: from pc6 (109.146.128.123) by VI1PR0701MB3006.eurprd07.prod.outlook.com (2603:10a6:800:87::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Tue, 19 Sep 2017 11:01:28 +0000
Message-ID: <071201d33136$6a9326e0$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Martin Bjorklund" 
Cc: , , , , , 
References: <20170917.154115.791964858062115650.mbj@tail-f.com><009f01d32ff4$352ddc40$4001a8c0@gateway.2wire.net> <20170918.095835.618040149385689102.mbj@tail-f.com>
Date: Tue, 19 Sep 2017 11:59:23 +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: [109.146.128.123]
X-ClientProxiedBy: VI1PR0701CA0036.eurprd07.prod.outlook.com (2603:10a6:800:90::22) To VI1PR0701MB3006.eurprd07.prod.outlook.com (2603:10a6:800:87::20)
X-MS-Office365-Filtering-Correlation-Id: ebdd2b3b-f5a8-4886-6438-08d4ff4dc749
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:VI1PR0701MB3006; 
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 3:rWt5cWoeLPxpIw1QOv2fa8pa/8Cpv2UBKtog4xNnaiuW8nupg4MuOul7/WYwQq20U3bQOIPJaBWvDUi2jpgAI32NkOCMiytw/V+vYshd2XVzB5VOM9xpUWCXC8eCt4WI0q+knZC2yDzMv0Jpfm0bQJU1AAa/ZMR1IMRCHwukJhuvbJ/1dtyXOiu6mhe05+fjP+Z2RrHnxlfBJEXng+1I2iN+PLUesl/X4h1wrEDDU+mM3RXhkwch1NUNwO40dX5K; 25:4v+OG4QWiGQNXNYLt8FL7TDNqVkyY/ht23s6i8XJXhaQY+3K+ra7ne65BBnxH7e+PeilYG9w4i6zCJtCkBSHpqe6NjRVrdqXCwP7XNY+PMsbtSLwo04PTayheVHLd91QTfoNBD/yFryLBnYqnIfngvH1XFp8Fwp1roLl7+l80fiKpYWOXWpN2QIq7zwZAGruOcE4rHx0b9J/k3mUhWrQ/oYeP4YkrO3jFsyRazuWd+Bx77ry3GndPEuBM1jQujwHJLZgjQkUmXIbMRA2Xh4kRQDd/2nfecTocZN3haiXdtpkNev2auG5/TXf0ueNVI27wiw3GjoXTirX5dNS601jKg==; 31:R9ev5jII8tomeVXyqqsOA8TJGZfS2khS5RTDHiDor+GJgdP4RZVsDgtLgDbECdvdu5VRhGeWBbu+t7NEc43/uKTOFuO7bSKWfHhFb9aEnLOv68oVz0abB1h4DdbF9kGPLWeM+7H0vNNXZGsSuDb9jXBOVMhgvI8UlBeL7powIqXKLhAq7MdmMZU+u7JIbmLZ8Ab5nrR6h7BOWN+1O3zTd+i1CP+DEh5SJuGGjzAh8P8=
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: VI1PR0701MB3006:
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 20:bhOos2mbJsz4pAKXtC2aW0y4JXYa8jHdjdKPskw3I/LYmQLl5QcjWiWmlq9tF38PmJB928FuHBkFBtKOcBsmlz3sk+tJhegLb+bBvBqC8L8kECqWpAkfB+Bb6k5WBztJjnCnux1Xn24H1T9KiIV1SakUbXTbAXNtNm8BtvJUYiWMdzjtKikQT9YF/vywxrbs3hq7LNYIyuxdJOpSpyiPpq2u47xcjghKBFv2ZgT3VqBQ7hdVu4XbgPmwvczMPiyLCveCLLo5jpV6tCO5BhimQlkiYLdmcTJeqZLTUgp1I5Mp6hDcozzfwieeylAu+C3c81Zb/E/8Yr09fK7lruugMg==; 4:DEu3qhAS9QLfib5iIsV1hQUqpNhspKQ9R7/HsgL0FpKqndRcn3Lc3l9UX7pjvHhlFMZSQB8mdjfNSBnljGW5Bel/me+Kxa7yzvYXNo5/Gb8A+KzGxSvsgHImjBNo8nYE9MJWuMDKoDRYRxwYbltXHWbf4p4K8XC8bvZw31lO6X5IkWOByc4nyR9Bu8fnBQKRoZbiFnSvczft72h1JU+D3WshCHdLpot8BwLvtawPOTd2j5Q6ktlkBGFcI3AGBL22yT0Mai859fkPHz2YMFqdplapmJLc1fSNwAV5RVmQpfosnOUZai2IG5QAEScuqTMn9Fm2F5qZt0HRGy3n5eI+OKnT+z3sWEwCvO9fSRMWst4=
X-Exchange-Antispam-Report-Test: UriScan:(178726229863574)(158342451672863)(788757137089); 
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(61426038)(61427038)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123560025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR0701MB3006; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR0701MB3006; 
X-Forefront-PRVS: 04359FAD81
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(39860400002)(346002)(199003)(189002)(377454003)(13464003)(24454002)(68736007)(9686003)(44716002)(54906002)(1456003)(53936002)(316002)(16526017)(15650500001)(116806002)(230783001)(6496005)(23756003)(4326008)(5660300001)(305945005)(6246003)(1556002)(33646002)(230700001)(4720700003)(7736002)(25786009)(6916009)(6666003)(84392002)(76176999)(6116002)(14496001)(105586002)(81816999)(97736004)(81156014)(8936002)(478600001)(44736005)(101416001)(81686999)(106356001)(50986999)(6486002)(62236002)(47776003)(189998001)(53546010)(93886005)(2906002)(66066001)(61296003)(8676002)(229853002)(50466002)(50226002)(86362001)(81166006)(3846002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB3006; 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; VI1PR0701MB3006; 23:o33TB0Rh5Grqw+KbfY6T4+i2+AQu6EH1t2XjP?= =?iso-8859-1?Q?Mj+nXPlecXDdktdJJLbRART8FQOyMUWhZNvAkpk3Fw5PZEdAnH8iENjTZD?= =?iso-8859-1?Q?86OPj0U59EyE1I9yy9nRgHQmatpI7Bn9E5FzGAeSfbqKV2VGOmc1dHGE4R?= =?iso-8859-1?Q?rxTr//MzjXbVkcPIuOyDhdNgd5QT+pJnfUae+uWO/vPqPUaHIpNbmmi3Vg?= =?iso-8859-1?Q?kX6GO4BnVfLy61AZKRKSVZ6wpCZJ8vYPEY1/FehTUdhLLT9N/FvddSewz3?= =?iso-8859-1?Q?3ryKukq4VrU9SZwolMtfBzEwVKP7vrXYyKqmEcIqn3MWe9GbS+Nyeqxu36?= =?iso-8859-1?Q?lmgse3u6bHpHNaRobC7HdbR5iIJ0vhK/e23UE7CtrjLbWDhWSN6EvAfsxu?= =?iso-8859-1?Q?foyIFKkPgiq8YrlYcZO9WppXK0kMtoZLd1xChSSbizp8/0Boa85/fVjKlR?= =?iso-8859-1?Q?C37GvgPPywT8hmkiq78V7CIVqHKIQhxuxZk4y2Flgk/ZOrGI2ndXr+2p5P?= =?iso-8859-1?Q?h4LSw/sKf+bLVb2/gcJZ3sZ2CAxtKwlz0uV7S69WOLIH3KyNyqwvBWOrsi?= =?iso-8859-1?Q?sgJdpKXeRaLEciYs3PDlEoQOA8pTIjP5PEDivWrjjpBeTt8VgMFvwqIGTY?= =?iso-8859-1?Q?7R0oBWBuKQYQ6UcnhH372OOsuGwVUf45XJWD+Zqj3OtGaplGEEXTtstSpt?= =?iso-8859-1?Q?GVwmREeAyf2c98PVXa6uPMIpeL+o/rDZeNQyDeUPGkzpyGFil7KZ01TioX?= =?iso-8859-1?Q?GPv1NkNG6PxsXnvnpWXXSfGK3K2HaZCWeRK8VmUvU0L/KcwMkPyHAe1o9j?= =?iso-8859-1?Q?OWPOlhSvQQbT5xrXLtHQdNw+aQfiyBfoQIrVDBdcXAlDilcRUNNQuLVPUI?= =?iso-8859-1?Q?y4WssN0KXcFAOH9Ab9H0c8AAfQzzrJbTdGq6EUr/DoyYYIQu85GMT+0Qmu?= =?iso-8859-1?Q?2KpjFD6def3x2x8ynpjBkOYOWmWB2GtJ0oAWZBCN8L5O9yiVZplsUR1pl7?= =?iso-8859-1?Q?2t1CAqdUq1s6yyfzINZ6sdMmFsdwFjaVkVNyv+uisCmH3dl6zV5lK2ufeb?= =?iso-8859-1?Q?Td591OcMxMyzt7qzjqbMyFrpEhkuN7obqh3laXzIcSGTLya9GLVXQ02T+C?= =?iso-8859-1?Q?GkD3C3OMIRJpoOcvhjJizOx2kh/AtM7BnJa3aaw4JIMAOAEamap5orYOYE?= =?iso-8859-1?Q?TK6ZRKMezUYthBeX6uaF/8iQ8hha1FxW3UZcLtzdU3L6yM/WvRHxTZZ9Wz?= =?iso-8859-1?Q?OYFHn263sMiWyUw5FYtfynLmStB0Y3XyXjCMWxHuBixbtPfVtRUUAmv0Va?= =?iso-8859-1?Q?Ifs7G+3rBKRqKq/66IG/hXVaIwn3oMmwh0Tp9dfDiLjudJnm5RHx3+3wPM?= =?iso-8859-1?Q?FOyv6YQTWO+q/ZLnG2CxBAhDNYlSrZj0/LqcVUujVNZDGoeOf/25wX9fbH?= =?iso-8859-1?Q?Qt6DsOGKwdp3fdVT/mRhjK0Myn2nD7X2Y5jVc6ejuCzfdKjbm4+U4BPQ8n?= =?iso-8859-1?Q?sOQ1K4NeHbZ3OpnWp/HjnFBH2SZSmDe0jexXb7jSO9mUpnejiNwyDfMTPS?= =?iso-8859-1?Q?XsOQVOWophj9q9nliRDxHAtJb9oh/QgXvfpFrnpbGG0XJ/7l/?=
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 6:EH1hRlv6aipkR8KPTDx0fWQRtcSZHx1FD1jCaA6s7amF0b05VhwMppI7Tarjz0QKh3NJSxL/T0zufVYWfKziorbGh3yqnVYtdYICcBL3C7q7AylENtqMW+Ytw4Y7S3/PH/m8isIVChCWr5QpZ2t0QbwSKhROa9iqmpkT3PSVx77uCIlhqpEqSk3LBuVWam7mzP6cyAeEcXsM9k15dhKN/GlGLG6n5QmpBWzS8QP33u2OvG5iBMkeKdNK8vkVNGoEnLY40ZI3U8XaefBHb80FaKIlrJn6kiMAp2YiKZDBci+2eYQIsBBdL8D+9DLFRwJBkFZy2YFfo+0PBSPDIj8x5g==; 5:M/3J44LyOgmoGRx2mxPiEAVsdqVkYkq/4GS5rZlB1wzAEmTe9tIkCJjgdUWCUMMoiTI3MzYwmkBM4FTqQ6f2wax4sUJPO+ajySeozqtx2QEBNp5nCabd4NVjfM4sl0WNvyE0K8AdiNMzIgwPjVu8VQ==; 24:cjSpAgIQj/O8XBVTan0gLTQ2hL7vacMHofG981RETtQC5Wc7Y9ZWx/koM8MJLnkZE98N2GOwUVC/F5ekZO6vbbGy9elPgMWtVcI1sGzPW5Q=; 7:QL0FW750lvizhasjfFjFLdisD8mz1TEvGsRya75YD0VOhTP24ikouEHeflJaKAosT7fedWXR0uhBIJe7FmQK9tHrufBeIGU2niHzUNgS7FF4N3ZETbRn5sHyt+z85HTmH8owf9A6hhr9woWAL52BYsKGfUrh4FtFW1Ghkts5QWRzHwAyM/7glKkXFb4zRZ+ABuuZduNU7pxfK2nNC0VEuc1GW9qlQrMiWIHgXOMnp8w=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Sep 2017 11:01:28.0997 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB3006
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 updates
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Sep 2017 11:01:35 -0000

----- Original Message -----
From: "Martin Bjorklund" 
Sent: Monday, September 18, 2017 8:58 AM


> "t.petch"  wrote:
> > ----- Original Message -----
> > From: "Martin Bjorklund" 
> > Sent: Sunday, September 17, 2017 2:41 PM
> >
> > > Andy Bierman  wrote:
> > > > On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder <
> > > > j.schoenwaelder@jacobs-university.de> wrote:
> > > >
> > > > > On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I strongly agree with Tom that the current draft is an
update to
> > RFC
> > > > > 7950.
> > > > > > I also strongly disagree with the decision to omit RFC 2119
in a
> > > > > standards
> > > > > > track document. IMO RFC 2119 terms need to be used in
normative
> > text,
> > > > > > especially when dealing with XPath and YANG compiler
behavior.
> > > > > >
> > > > >
> > > > > RFC 8174:
> > > > >
> > > > >    o  These words can be used as defined here, but using them
is
> > not
> > > > >       required.  Specifically, normative text does not require
the
> > use
> > > > >       of these key words.  They are used for clarity and
> > consistency
> > > > >       when that is what's wanted, but a lot of normative text
does
> > not
> > > > >       use them and is still normative.
> > > > >
> > > > >
> > > > So what?
> > > > Existing YANG specifications use RFC 2119 terms.
> > > > This draft uses those terms, just with lower-case.
> > >
> > > Actually, section 5.1 XPath Context in the revised datastore draft
> > > uses the same language as section 6.4.1 XPath Context in RFC 7950.
In
> > > fact, the text in the draft is copied (and adjusted) from RFC
7950.
> >
> > Martin
> >
> > 'Adjusted' might be seen as a weasel word:-)
> >
> >    If the XPath expression is defined in a substatement to a
> >       "notification" statement, the accessible tree is the
notification
> >       instance, all state data in the server, and the running
> >       configuration datastore.
> >
> > becomes
> >
> > If the XPath expression is defined in a substatement to a
> >       "notification" statement, the accessible tree is the
notification
> >       instance and all operational state in the server.
> >
> > Goodbye  (well, running configuration in RFC7950).  Is it a
> > material difference? - it will take me a while to work that one out.
>
> The difference is that the xpath expressions no longer sees unused
> configuration in running.  But if the config is used, it exists in
>  under the same path as before, and it is available.
>
> > I focussed on the XPath rules because they seemed the clearest case,
but
> > updating the definitions, and saying this section will replace the
> > definitions in [RFC6241] and [RFC7950] when these documents are
revised
> > seems .... well, like an Erratum held for Update i.e. another
Updates.
>
> Are you saying that this is an argument for having "Updates: 7950"?

Yes

Tom Petch

>
> /martin


From nobody Tue Sep 19 04:31:24 2017
Return-Path: 
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 5DF2913207A for ; Tue, 19 Sep 2017 04:31:22 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJax8TSUe7pz for ; Tue, 19 Sep 2017 04:31: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 4ADE5132F76 for ; Tue, 19 Sep 2017 04:31:20 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id E78031AE02A7; Tue, 19 Sep 2017 13:31:18 +0200 (CEST)
Date: Tue, 19 Sep 2017 13:29:47 +0200 (CEST)
Message-Id: <20170919.132947.358857445863848356.mbj@tail-f.com>
To: lberger@labn.net
Cc: rwilton@cisco.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <5b512435-cebd-3534-eeb3-649154450d81@cisco.com> <20170915.134007.262763963470255554.mbj@tail-f.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Sep 2017 11:31:22 -0000

TG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4gd3JvdGU6DQo+IE1hcnRpbiwNCj4gDQo+IFNw
ZWFraW5nIGFzIGEgY29udHJpYnV0b3I6DQo+IA0KPiANCj4gT24gOS8xNS8yMDE3IDc6NDAgQU0s
IE1hcnRpbiBCam9ya2x1bmQgd3JvdGU6DQo+ID4gUm9iZXJ0IFdpbHRvbiA8cndpbHRvbkBjaXNj
by5jb20+IHdyb3RlOg0KPiA+PiBPbiAxNS8wOS8yMDE3IDExOjIxLCBMYWRpc2xhdiBMaG90a2Eg
d3JvdGU6DQo+ID4+PiBBbmR5IEJpZXJtYW4gcMOtxaFlIHYgxIx0IDE0LiAwOS4gMjAxNyB2IDA4
OjQzIC0wNzAwOg0KPiA+Pj4+IEhpLA0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PiBBY3R1YWxseSBJ
IGxpa2VkIHRoZSBlYXJseSBweWFuZyBvdXRwdXQgdGhhdCB3YXMgY29uY2lzZSBhbmQgZWFzeSB0
bw0KPiA+Pj4+IHJlbWVtYmVyLg0KPiA+Pj4+IFRoZSBjdXJyZW50IGZvcm1hdCBnZXRzIHZlcnkg
Y2x1dHRlcmVkIGFuZCB0aGVyZSBhcmUgdG9vIG1hbnkgbGl0dGxlDQo+ID4+Pj4gc3ltYm9scw0K
PiA+Pj4+IHRvIHJlbWVtYmVyIHRoZW0gYWxsLg0KPiA+Pj4gSSBhZ3JlZS4NCj4gPiBNZSB0b28u
ICBUaGUgY3VycmVudCBkcmFmdCBhZGRzIHRocmVlIG5ldyBtYWdpYyBzeW1ib2xzOiAibXAiICJA
IiBhbmQNCj4gPiAiLyIuDQo+ID4NCj4gPiAibXAiIGlzIGZvciBhIG1vdW50IHBvaW50LCBhbmQg
aXQgY2FuIGJlIGdlbmVyYXRlZCBkaXJlY3RseSBmcm9tIHRoZQ0KPiA+IFlBTkcgbW9kdWxlcy4N
Cj4gPg0KPiA+IERpcmVjdGx5IHVuZGVyIGEgIm1wIiwgIi8iIGFuZCAiQCIgYXJlIHVzZWQgdG8g
aW5kaWNhdGUgdGhhdCBhIG5vZGUgaXMgbW91bnRlZA0KPiA+IG9yIGF2YWlsYWJsZSB0aHJvdWdo
IGEgcGFyZW50IHJlZmVyZW5jZSwgcmVzcGVjdGl2ZWx5Lg0KPiA+DQo+ID4gSSBhY3R1YWxseSBx
dWVzdGlvbiB0aGUgdXNhYmlsaXR5IG9mICIvIiBhbmQgIkAiLiAgDQo+IA0KPiBJIGFncmVlIHRo
YXQgLyBhbmQgQCBhcmUgc29tZXRoaW5nIG5ldywgYW5kIGVuYWJsZWQgYnkgc2NoZW1hIG1vdW50
LsKgDQo+IFRoZXJlIGhhdmUgYmVlbiByZXBlYXRlZCBjb21tZW50cyBpbiB0aGUgUlRHIFdHIHRo
YXQgdGhlcmUgbmVlZHMgdG8gYmUNCj4gc29tZSB3YXkgZm9yIHZlbmRvcnMgdG8gY29udmV5IHdo
YXQgdGhleSBoYXZlIGltcGxlbWVudGVkIHdpdGggU2NoZW1hDQo+IG1vdW50DQoNCklmIHRoYXQn
cyB0aGUgcmVxdWlyZW1lbnQsIHVzaW5nIHRoZSB0cmVlIGRpYWdyYW0gaXMgcHJvYmFibHkgbm90
IHRoZQ0KYmVzdCB3YXkuICBUaGUgdHJlZSBkaWFncmFtIGlzIGludGVuZGVkIHRvIHByb3ZpZGUg
YW4gb3ZlcnZpZXcgb2YgYQ0KZ2l2ZW4gKHNldCBvZikgWUFORyBtb2R1bGUocykuDQoNCkEgcGVy
aGFwcyBiZXR0ZXIgd2F5IHRvIGNvbnZleSB0aGUgaW5mb3JtYXRpb24gaXMgdG8gY3JlYXRlIGEg
ZmlsZQ0Kd2l0aCBhbiBpbnN0YW50aWF0ZWQgL3NjaGVtYS1tb3VudHMgdHJlZS4NCg0KPiBhbmQg
dGhpcyBpcyBvbmUgd2F5IHRvIGhlbHAgY29udmV5IChhKSB3aGF0IGlzIGV4cGVjdGVkIG9mIHNl
cnZlcg0KPiBpbXBsZW1lbnRvcnMgYW5kIChiKSB3aGF0IGNsaWVudCBpbXBsZW1lbnRvcnMgc2hv
dWxkIGV4cGVjdC4NCj4NCsKgwqAgSGVuY2UgdGhlDQo+IGN1cnJlbnQgZHJhZnQgdGV4dDoNCj4g
DQo+IMKgIEluIGRlc2NyaWJpbmcgdGhlIGludGVuZGVkIHVzZSBvZiBhIG1vZHVsZSBjb250YWlu
aW5nIGEgbW91bnQgcG9pbnQsDQo+IMKgwqAgaXQgaXMgaGVscGZ1bCB0byBzaG93IGhvdyB0aGUg
bW91bnQgcG9pbnQgd291bGQgbG9vayB3aXRoIG1vdW50ZWQNCj4gwqDCoCBtb2R1bGVzLg0KPiAN
Cj4gVGhlIHdob2xlIHBvaW50IG9mIHRyZWVzIGlzIHRvIGZhY2lsaXRhdGUgdW5kZXJzdGFuZGlu
ZyBmb3IgdGhvc2Ugd2hvDQo+IGFyZSBsZXNzIGZhbWlsaWFyIHdpdGggYSBtb2RlbCB0aGFuIHRo
ZSBhdXRob3JzLCBhbmQgSU1PIHRoYXQncyB0aGUNCj4gcGFyYW1vdW50IHBlcnNwZWN0aXZlIGlu
IHRoaXMgZGlzY3Vzc2lvbi4NCg0KRnVsbHkgYWdyZWUhICBJIHdvdWxkIHNheSB0aGF0IHdlIGhh
dmUgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIGRpYWdyYW1zDQpjYW4gYmUgdW5kZXJzdG9vZCBieSBw
ZW9wbGUgbGVzcyBmYW1pbGlhciB3aXRoIHRoZSB0ZWNobm9sb2d5IHRoYW4gdGhlDQphdXRob3Jz
LiAgTWl4aW5nIHNjaGVtYSBhbmQgaW5zdGFuY2UgZGF0YSBkb2VzIG5vdCBoZWxwIGhlcmUuDQoN
Cj4gPiBTaW5jZSBhIHBhcmVudA0KPiA+IHJlZmVyZW5jZSBjYW4gYmUgdmVyeSBzcGVjaWZpYywg
ZS5nLiBvbmUgc3BlY2lmaWMgaW50ZXJmYWNlLCBpdCBpc24ndA0KPiA+IHJlYWxseSBhY2N1cmF0
ZSB0byBzaG93Og0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAgKy0tbXAgdnJmLXJvb3QNCj4g
PiAgICAgICAgICAgICAgICAgICAgICArLS1ydyBydDpyb3V0aW5nLw0KPiA+ICAgICAgICAgICAg
ICAgICAgICAgIHwgIC4uLg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICstLXJvIGlmOmludGVy
ZmFjZXNADQo+IFRoaXMgaXMganVzdCBhIGNvbmRpdGlvbmFsIGFuZCB3ZSBoYXZlIHByZWNlZGVu
dCBvbiBob3cgdG8gaGFuZGxlDQo+IGNvbmRpdGlvbmFsIHJlcHJlc2VudGF0aW9uLiDCoMKgDQo+
IA0KPiA+DQo+ID4gQW5kIHRoZSB0cmFpbGluZyAiLyIgb24gcnQ6cm91dGluZyBkb2Vzbid0IGFk
ZCBhbnkgaW5mb3JtYXRpb24gd2UNCj4gPiBkb24ndCBhbHJlYWR5IGtub3cuICBTaW5jZSB2cmYt
cm9vdCBpcyBhIG1vdW50IHBvaW50LCBpdCBmb2xsb3dzIHRoYXQNCj4gPiBpdHMgY2hpbGRyZW4g
YXJlIG1vdW50ZWQuDQo+IA0KPiBUaGUgaXNzdWUgaXMgYSBiaXQgbW9yZSBjb21wbGV4IHdoZW4g
Y29uc2lkZXJpbmcgc29tZSByZWFsIHVzZSBjYXNlcywNCj4gcGFydGljdWxhcml0eSB3aGVuIHBh
cmVudCByZWZlcmVuY2VzIGFuZCBhdWdtZW50YXRpb25zIGFyZSB1c2VkLsKgIEZvcg0KPiBleGFt
cGxlIGNvbnNpZGVyIHRoZSBmb2xsb3dpbmcgKndpdGhvdXQqIHRoZSB1c2UgLyBvciBAOg0KPiAN
Cj4gbW9kdWxlOiBpZXRmLW5ldHdvcmstaW5zdGFuY2UNCj4gwqAgKy0tcncgbmV0d29yay1pbnN0
YW5jZXMNCj4gwqDCoMKgwqAgKy0tcncgbmV0d29yay1pbnN0YW5jZSogW25hbWVdDQo+IMKgwqDC
oMKgwqDCoMKgIHwgLi4uDQo+IMKgwqDCoMKgwqDCoMKgICstLXJ3IChyb290LXR5cGUpDQo+IMKg
wqDCoMKgwqDCoMKgwqDCoMKgICstLToodnJmLXJvb3QpDQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgICstLW1wIHZyZi1yb290DQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
ICstLXJvIHJ0OnJvdXRpbmctc3RhdGUNCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqAgfMKgICstLXJvIHJvdXRlci1pZD/CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB5
YW5nOmRvdHRlZC1xdWFkDQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoCAr
LS1ybyBjb250cm9sLXBsYW5lLXByb3RvY29scw0KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoCB8wqDCoMKgwqAgKy0tcm8gY29udHJvbC1wbGFuZS1wcm90b2NvbCogW3R5cGUgbmFt
ZV0NCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgICst
LXJvIG9zcGY6b3NwZg0KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKg
wqDCoMKgwqDCoMKgwqAgKy0tcm8gaW5zdGFuY2UqIFthZl0NCj4gwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqAgKy0tcncgcnQ6cm91dGluZw0KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoCB8wqAgKy0tcncgcm91dGVyLWlkP8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgIHlhbmc6ZG90dGVkLXF1YWQNCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqAgfMKgICstLXJ3IGNvbnRyb2wtcGxhbmUtcHJvdG9jb2xzDQo+IMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoCArLS1ydyBjb250cm9sLXBsYW5lLXByb3RvY29sKiBb
dHlwZSBuYW1lXQ0KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqAg
Ky0tcncgb3NwZjpvc3BmDQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKg
wqDCoMKgwqDCoCArLS1ydyBpbnN0YW5jZSogW2FmXQ0KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqAgKy0tcncgYXJlYXMNCj4gwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICstLXJ3
IGFyZWEqIFthcmVhLWlkXQ0KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgKy0tcncgaW50ZXJmYWNlcw0KPiDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqAgKy0tcncgaW50ZXJmYWNlKiBbbmFtZV0NCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
ICstLXJ3IG5hbWUgaWY6aW50ZXJmYWNlLXJlZg0KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgKy0t
cncgY29zdD/CoMKgIHVpbnQxNg0KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAr
LS1ybyBpZjppbnRlcmZhY2VzDQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzC
oCAuLi4NCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgKy0tcm8gaWY6aW50ZXJm
YWNlcy1zdGF0ZQ0KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqAgLi4uDQo+
IA0KPiANCj4gSXQncyBjZXJ0YWlubHkgbm90IHRvbyBoYXJkIHRvIHNwb3QgdGhlIHRvcCBsZXZl
bCBtb3VudHMsIGJ1dCBpdCBpcw0KPiBpbXBvc3NpYmxlIHRvIGRpc3Rpbmd1aXNoIHRoZSBwYXJl
bnQgcmVmZXJlbmNlcyBmcm9tIHRoZSBhY3R1YWwgbW91bnRzLsKgDQoNCk15IHByb3Bvc2FsIHdv
dWxkIGJlIHRvIG5vdCBldmVuIHNob3cgdGhlIHBhcmVudCByZWZlcmVuY2VzIGluIHRoZQ0KZGlh
Z3JhbS4gIElmIHdlIGRvIHRoYXQsIHRoZSAnLycgaXMgbm90IG5lZWRlZC4NCg0KPiBGdXJ0aGVy
IG1vcmUsIHNvbWUgbW91bnRzIGFyZSBoYXJkIHRvIHNwb3QuwqAgRm9yIGV4YW1wbGUsIG5vdGlj
ZSBvc3BmLsKgDQo+IERpZCB5b3Ugbm90aWNlIHRoYXQgaXQncyBhIG1vdW50Pw0KDQpUaGlzIGlz
IGFjdHVhbGx5IG5vdCBjb3JyZWN0LiAgb3NwZiBpcyAqbm90KiBhIG1vdW50OyBpdCBpcyBhbiBh
dWdtZW50Lg0KDQoNCi9tYXJ0aW4NCg0KDQoNCj4gSXMgaXQgYSBtb3VudCBvciBwYXJlbnQgcmVm
ZXJlbmNlP8KgDQo+IFdpdGggdGhlIC8gYW5kIEAgYm90aCBjYXNlcyBhcmUgdHJhbnNwYXJlbnQ6
DQo+IA0KPiBtb2R1bGU6IGlldGYtbmV0d29yay1pbnN0YW5jZQ0KPiDCoCArLS1ydyBuZXR3b3Jr
LWluc3RhbmNlcw0KPiDCoMKgwqDCoCArLS1ydyBuZXR3b3JrLWluc3RhbmNlKiBbbmFtZV0NCj4g
wqDCoMKgwqDCoMKgwqAgfCAuLi4NCj4gwqDCoMKgwqDCoMKgwqAgKy0tcncgKHJvb3QtdHlwZSkN
Cj4gwqDCoMKgwqDCoMKgwqDCoMKgwqAgKy0tOih2cmYtcm9vdCkNCj4gwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqAgKy0tbXAgdnJmLXJvb3QNCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqAgKy0tcm8gcnQ6cm91dGluZy1zdGF0ZS8NCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqAgfMKgICstLXJvIHJvdXRlci1pZD/CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoCB5YW5nOmRvdHRlZC1xdWFkDQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
IHzCoCArLS1ybyBjb250cm9sLXBsYW5lLXByb3RvY29scw0KPiDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoCB8wqDCoMKgwqAgKy0tcm8gY29udHJvbC1wbGFuZS1wcm90b2NvbCogW3R5
cGUgbmFtZV0NCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDC
oMKgICstLXJvIG9zcGY6b3NwZi8NCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg
fMKgwqDCoMKgwqDCoMKgwqDCoMKgICstLXJvIGluc3RhbmNlKiBbYWZdDQo+IMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgICstLXJ3IHJ0OnJvdXRpbmcvDQo+IMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgIHzCoCArLS1ydyByb3V0ZXItaWQ/wqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqAgeWFuZzpkb3R0ZWQtcXVhZA0KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoCB8wqAgKy0tcncgY29udHJvbC1wbGFuZS1wcm90b2NvbHMNCj4gwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgICstLXJ3IGNvbnRyb2wtcGxhbmUtcHJv
dG9jb2wqIFt0eXBlIG5hbWVdDQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzC
oMKgwqDCoCArLS1ydyBvc3BmOm9zcGYvDQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgIHzCoMKgwqDCoMKgwqDCoCArLS1ydyBpbnN0YW5jZSogW2FmXQ0KPiDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqAgKy0tcncgYXJlYXMNCj4g
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgICstLXJ3IGFyZWEqIFthcmVhLWlkXQ0KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgKy0tcncgaW50ZXJmYWNlcw0K
PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqAgKy0tcncgaW50ZXJmYWNlKiBbbmFtZV0NCj4gwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgICstLXJ3IG5hbWUgaWY6aW50ZXJmYWNlLXJlZg0KPiDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqAgKy0tcncgY29zdD/CoMKgIHVpbnQxNg0KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoCArLS1ybyBpZjppbnRlcmZhY2VzQA0KPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoCB8wqAgLi4uDQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICstLXJv
IGlmOmludGVyZmFjZXMtc3RhdGVADQo+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
IHzCoCAuLi4NCj4gDQo+ID4gQWxzbywgd2hhdCBpcyBtb3VudGVkIHVuZGVyIGEgbW91bnQgcG9p
bnQgaXMgbm90IGRlZmluZWQgaW4gdGhlDQo+ID4gc2NoZW1hLCBzbyBhIHRvb2wgY2Fubm90IGdl
bmVyYXRlIHRoaXMgZnJvbSB0aGUgWUFORyBtb2R1bGVzLg0KPiANCj4gSSB0aGluayB0aGlzIGlz
IGEgbGltaXRhdGlvbiBpbiB0aGUgY3VycmVudCBzY2hlbWEtbW91bnQgZGVmaW5pdGlvbiB0aGF0
DQo+IHBlcmhhcHMgd2lsbCBiZSByZXZpc2l0ZWQgdG8gc3VwcG9ydCBkZXNpZ24gdGltZSBtb3Vu
dHMsIGJ1dA0KPiBub25ldGhlbGVzc8KgIHN0aWxsIGhhcyB2YWx1ZSB0byBtb2RlbCBhbnkgcmVh
ZGVyIGFuZCBpbXBsZW1lbnRvci4NCj4gLi4uDQo+IA0KPiBMb3UNCj4gDQo=


From nobody Tue Sep 19 04:40:38 2017
Return-Path: 
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 2CD20134211 for ; Tue, 19 Sep 2017 04:40:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LG5nXsysiUnK for ; Tue, 19 Sep 2017 04:40:30 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D30D9132D22 for ; Tue, 19 Sep 2017 04:40:28 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id AACF24C3; Tue, 19 Sep 2017 13:40:27 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id SKNyABTQ-bkD; Tue, 19 Sep 2017 13:40:21 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 19 Sep 2017 13:40:27 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 899B4200E8; Tue, 19 Sep 2017 13:40:27 +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 q2eswLVLxFyB; Tue, 19 Sep 2017 13:40:27 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 06F92200EE; Tue, 19 Sep 2017 13:40:27 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 06BDC410CAC5; Tue, 19 Sep 2017 13:40:26 +0200 (CEST)
Date: Tue, 19 Sep 2017 13:40:26 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Cc: netmod@ietf.org
Message-ID: <20170919114026.xna65qtcwenwiicx@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org
References: <393d3f20-98e3-b4de-e2d7-d627de59ac1f@labn.net> <1505814417.5445.14.camel@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <1505814417.5445.14.camel@nic.cz>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Sep 2017 11:40:37 -0000

I believe that starting a new model would cause a real pain since any
model augmentations now need to augment two differnet versions of the
IP model. (Actually any model references may cause extra work.)

I also believe that view that NMDA is for big gear but not for small
gear is not quite right. Differences between operational state and
config state exists in almost all systems I have seen. The /foo and
/foo-state approach came out of long discussions about how to model
interfaces (Lada should recall this) and it was kind of clear even
back then that /foo and /foo-state was just a 'hack', given the
specifications we had to work with. NMDA simplifies models and we
would be failing badly if we now start maintaining multiple versions
of models.

/js

On Tue, Sep 19, 2017 at 11:46:57AM +0200, Ladislav Lhotka wrote:
> Hi,
> 
> I support the adoption but I propose two conceptual changes:
> 
> 1. Introduce a new module name and namespace so that it is not necessary to
> carry along the deprecated baggage. If readability is the primary concern, this
> is IMO the way to go. Instead of "ietf-ip-2", I'd suggest something like "ietf-
> ip-nmda".
> 
> 2. Avoid obsoleting RFC 7277. I believe the old modules may continue to be used
> in areas where NMDA is an overkill, such as open source home routers. NMDA
> implementors should be aware of the new modules but there is no need to
> eradicate the old data models.
> 
> #2 applies also to other modules for which the NMDA version is underway.
> 
> Lada
> 
> PS. The subject is wrong, it shoud be -rfc7277bis-
>  
> Lou Berger píše v Po 18. 09. 2017 v 10:33 -0400:
> > All,
> > 
> > This is start of a two week poll on making
> > draft-bjorklund-netmod-rfc7227bis-00 a working group document. Please
> > send email to the list indicating "yes/support" or "no/do not support".
> > If indicating no, please state your reservations with the document.  If
> > yes, please also feel free to provide comments you'd like to see
> > addressed once the document is a WG document.
> > 
> > The poll ends Oct 2.
> > 
> > Thanks,
> > 
> > Lou (and Kent)
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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


From nobody Tue Sep 19 06:28:37 2017
Return-Path: 
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 474C4134319 for ; Tue, 19 Sep 2017 06:28:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level: 
X-Spam-Status: No, score=-4.7 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=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pt5lniAJB_Lz for ; Tue, 19 Sep 2017 06:28:27 -0700 (PDT)
Received: from outbound-ss-1812.hostmonster.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) (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 61962134312 for ; Tue, 19 Sep 2017 06:28:27 -0700 (PDT)
Received: from cmgw4 (cmgw5 [10.0.90.85]) by gproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id 1DBC9175B39 for ; Tue, 19 Sep 2017 07:28:26 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id BRUN1w01b2SSUrH01RURjX; Tue, 19 Sep 2017 07:28:26 -0600
X-Authority-Analysis: v=2.2 cv=OZLoNlbY c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=2JCJgTwv5E4A:10 a=wU2YTnxGAAAA:8 a=AUd_NHdVAAAA:8 a=p479whFOn2vpGQvl5hgA:9 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: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=eKn9UOZtnbGquQoIquNMGIYPchHl15UKLG77piaE970=; b=04/xOeVQu5bs0OAKAzXJZ8LIsl 6NGFvByF8HPWVmEH8uypMNFjEXexszfmrMAjxwh4OBhTX0a06eFxE53g6NJqYjp9M0KiF/za/GErO 3NgzgM8AAVsYekahwyoqYJ0Jv;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:46730 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1duIZa-001NaZ-2s; Tue, 19 Sep 2017 07:28:22 -0600
To: Martin Bjorklund 
Cc: rwilton@cisco.com, netmod@ietf.org
References: <5b512435-cebd-3534-eeb3-649154450d81@cisco.com> <20170915.134007.262763963470255554.mbj@tail-f.com>  <20170919.132947.358857445863848356.mbj@tail-f.com>
From: Lou Berger 
Message-ID: <990b8722-7a48-46ce-3f5d-96bc5cb66075@labn.net>
Date: Tue, 19 Sep 2017 09:28:20 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170919.132947.358857445863848356.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1duIZa-001NaZ-2s
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:46730
X-Source-Auth: lberger@labn.net
X-Email-Count: 3
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Sep 2017 13:28:34 -0000

On 9/19/2017 7:29 AM, Martin Bjorklund wrote:
> Lou Berger  wrote:
>> Martin,
>>
>> Speaking as a contributor:
>>
>>
>> On 9/15/2017 7:40 AM, Martin Bjorklund wrote:
>>> Robert Wilton  wrote:
>>>> On 15/09/2017 11:21, Ladislav Lhotka wrote:
>>>>> Andy Bierman píše v Čt 14. 09. 2017 v 08:43 -0700:
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>> Actually I liked the early pyang output that was concise and easy to
>>>>>> remember.
>>>>>> The current format gets very cluttered and there are too many little
>>>>>> symbols
>>>>>> to remember them all.
>>>>> I agree.
>>> Me too.  The current draft adds three new magic symbols: "mp" "@" and
>>> "/".
>>>
>>> "mp" is for a mount point, and it can be generated directly from the
>>> YANG modules.
>>>
>>> Directly under a "mp", "/" and "@" are used to indicate that a node is mounted
>>> or available through a parent reference, respectively.
>>>
>>> I actually question the usability of "/" and "@".  
>> I agree that / and @ are something new, and enabled by schema mount. 
>> There have been repeated comments in the RTG WG that there needs to be
>> some way for vendors to convey what they have implemented with Schema
>> mount
> If that's the requirement, using the tree diagram is probably not the
> best way.  The tree diagram is intended to provide an overview of a
> given (set of) YANG module(s).
>
> A perhaps better way to convey the information is to create a file
> with an instantiated /schema-mounts tree.
using what syntax?  JSON and XML really isn't that easy for the (human)
reader to parse.

>
>> and this is one way to help convey (a) what is expected of server
>> implementors and (b) what client implementors should expect.
>>
>    Hence the
>> current draft text:
>>
>>   In describing the intended use of a module containing a mount point,
>>    it is helpful to show how the mount point would look with mounted
>>    modules.
>>
>> The whole point of trees is to facilitate understanding for those who
>> are less familiar with a model than the authors, and IMO that's the
>> paramount perspective in this discussion.
> Fully agree!  I would say that we have to make sure that the diagrams
> can be understood by people less familiar with the technology than the
> authors.  Mixing schema and instance data does not help here.

Can you propose an alternative?  The routing WG participants seem to
find these useful, we can also ask there for broader input if you'd like.

>>> Since a parent
>>> reference can be very specific, e.g. one specific interface, it isn't
>>> really accurate to show:
>>>
>>>                   +--mp vrf-root
>>>                      +--rw rt:routing/
>>>                      |  ...
>>>                      +--ro if:interfaces@
>> This is just a conditional and we have precedent on how to handle
>> conditional representation.   
>>
>>> And the trailing "/" on rt:routing doesn't add any information we
>>> don't already know.  Since vrf-root is a mount point, it follows that
>>> its children are mounted.
>> The issue is a bit more complex when considering some real use cases,
>> particularity when parent references and augmentations are used.  For
>> example consider the following *without* the use / or @:
>>
>> module: ietf-network-instance
>>   +--rw network-instances
>>      +--rw network-instance* [name]
>>         | ...
>>         +--rw (root-type)
>>            +--:(vrf-root)
>>               +--mp vrf-root
>>                  +--ro rt:routing-state
>>                  |  +--ro router-id?                 yang:dotted-quad
>>                  |  +--ro control-plane-protocols
>>                  |     +--ro control-plane-protocol* [type name]
>>                  |        +--ro ospf:ospf
>>                  |           +--ro instance* [af]
>>                  +--rw rt:routing
>>                  |  +--rw router-id?                 yang:dotted-quad
>>                  |  +--rw control-plane-protocols
>>                  |     +--rw control-plane-protocol* [type name]
>>                  |     +--rw ospf:ospf
>>                  |        +--rw instance* [af]
>>                  |           +--rw areas
>>                  |              +--rw area* [area-id]
>>                  |                 +--rw interfaces
>>                  |                    +--rw interface* [name]
>>                  |                       +--rw name if:interface-ref
>>                  |                       +--rw cost?   uint16
>>                  +--ro if:interfaces
>>                  |  ...
>>                  +--ro if:interfaces-state
>>                  |  ...
>>
>>
>> It's certainly not too hard to spot the top level mounts, but it is
>> impossible to distinguish the parent references from the actual mounts. 
> My proposal would be to not even show the parent references in the
> diagram.  If we do that, the '/' is not needed.
>
>> Further more, some mounts are hard to spot.  For example, notice ospf. 
>> Did you notice that it's a mount?
> This is actually not correct.  ospf is *not* a mount; it is an augment.
>
it's a mounted module that augments another mounted module.

Lou
> /martin
>
>
>
>> Is it a mount or parent reference? 
>> With the / and @ both cases are transparent:
>>
>> module: ietf-network-instance
>>   +--rw network-instances
>>      +--rw network-instance* [name]
>>         | ...
>>         +--rw (root-type)
>>            +--:(vrf-root)
>>               +--mp vrf-root
>>                  +--ro rt:routing-state/
>>                  |  +--ro router-id?                 yang:dotted-quad
>>                  |  +--ro control-plane-protocols
>>                  |     +--ro control-plane-protocol* [type name]
>>                  |        +--ro ospf:ospf/
>>                  |           +--ro instance* [af]
>>                  +--rw rt:routing/
>>                  |  +--rw router-id?                 yang:dotted-quad
>>                  |  +--rw control-plane-protocols
>>                  |     +--rw control-plane-protocol* [type name]
>>                  |     +--rw ospf:ospf/
>>                  |        +--rw instance* [af]
>>                  |           +--rw areas
>>                  |              +--rw area* [area-id]
>>                  |                 +--rw interfaces
>>                  |                    +--rw interface* [name]
>>                  |                       +--rw name if:interface-ref
>>                  |                       +--rw cost?   uint16
>>                  +--ro if:interfaces@
>>                  |  ...
>>                  +--ro if:interfaces-state@
>>                  |  ...
>>
>>> Also, what is mounted under a mount point is not defined in the
>>> schema, so a tool cannot generate this from the YANG modules.
>> I think this is a limitation in the current schema-mount definition that
>> perhaps will be revisited to support design time mounts, but
>> nonetheless  still has value to model any reader and implementor.
>> ...
>>
>> Lou
>>


From nobody Tue Sep 19 06:37:25 2017
Return-Path: 
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 8F987134324 for ; Tue, 19 Sep 2017 06:37:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tQke2Nbzo1J for ; Tue, 19 Sep 2017 06:37:22 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id DCAF2134225 for ; Tue, 19 Sep 2017 06:37:18 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id 981561820E76; Tue, 19 Sep 2017 15:36:50 +0200 (CEST)
Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id 6C3571820E71; Tue, 19 Sep 2017 15:36:48 +0200 (CEST)
From: Ladislav Lhotka 
To: Martin Bjorklund 
Cc: netmod@ietf.org
In-Reply-To: <20170919.115915.1668734288988659917.mbj@tail-f.com>
References: <393d3f20-98e3-b4de-e2d7-d627de59ac1f@labn.net> <1505814417.5445.14.camel@nic.cz> <20170919.115915.1668734288988659917.mbj@tail-f.com>
Mail-Followup-To: Martin Bjorklund , netmod@ietf.org
Date: Tue, 19 Sep 2017 15:37:53 +0200
Message-ID: <87shfistam.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Sep 2017 13:37:24 -0000

Martin Bjorklund  writes:

> Ladislav Lhotka  wrote:
>> Hi,
>>=20
>> I support the adoption but I propose two conceptual changes:
>>=20
>> 1. Introduce a new module name and namespace so that it is not
>> necessary to carry along the deprecated baggage. If readability is
>> the primary concern, this is IMO the way to go. Instead of
>> "ietf-ip-2", I'd suggest something like "ietf- ip-nmda".
>>=20
>> 2. Avoid obsoleting RFC 7277. I believe the old modules may continue
>> to be used=20
>> in areas where NMDA is an overkill, such as open source home
>> routers.
>
> Why wouldn't NMDA be appropriate in an open source home router?  Note
> that the new model really just have a single tree instead of two
> trees, so the data that needs to be instrumented is more or less the
> same.

It is quite likely that some parts of the data models will be
implemented only as configuration but not state data. In the "old style"
modules it is easy to add a deviation for the node(s) under -state but
in NMDA style this is not possible because we only have one node.

There are subtle differences in the schemas for configuration and state
data that the NMDA concept doesn't address. If you want another example,
ietf-routing-2 has the "router-id" leaf that is conditional via the
"router-id" feature. If this feature is not supported, router-id cannot
be explicitly configured (it is assigned by the system) but in state data
"router-id" needs IMO be present in any case. But the if-feature
isn't able to differentiate between configuration and state data if
there is only one node for both.

>
> In fact, if we claim that the new architecture is not appropriate for
> some devices I think we have failed, especially if the conclusion is
> that we need to maintain two versions of all modules going forward.

I am not asking for this but, on the other hand, if NMDA versions used a new
module name and namespace (my item #1, which is what ietf-routing-2
does), then I don't see any pressing need for obsoleting the old style
modules.

Lada

>
>
> /martin
>
>
>
>
>
>
>> NMDA
>> implementors should be aware of the new modules but there is no need to
>> eradicate the old data models.
>>=20
>> #2 applies also to other modules for which the NMDA version is underway.
>>=20
>> Lada
>>=20
>> PS. The subject is wrong, it shoud be -rfc7277bis-
>>=20=20
>> Lou Berger p=C3=AD=C5=A1e v Po 18. 09. 2017 v 10:33 -0400:
>> > All,
>> >=20
>> > This is start of a two week poll on making
>> > draft-bjorklund-netmod-rfc7227bis-00 a working group document. Please
>> > send email to the list indicating "yes/support" or "no/do not support".
>> > If indicating no, please state your reservations with the document.  If
>> > yes, please also feel free to provide comments you'd like to see
>> > addressed once the document is a WG document.
>> >=20
>> > The poll ends Oct 2.
>> >=20
>> > Thanks,
>> >=20
>> > Lou (and Kent)
>> >=20
>> > _______________________________________________
>> > netmod mailing list
>> > netmod@ietf.org
>> > https://www.ietf.org/mailman/listinfo/netmod
>> --=20
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod

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


From nobody Tue Sep 19 06:39:21 2017
Return-Path: 
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 2A3C1134320 for ; Tue, 19 Sep 2017 06:39:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 RML7MNmGxiC0 for ; Tue, 19 Sep 2017 06:39:18 -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 3ED8313431E for ; Tue, 19 Sep 2017 06:39:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2347; q=dns/txt; s=iport; t=1505828358; x=1507037958; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=/fTKCyGLiM8M/bIR8nRdAPFzTxtXzmPqyBQ6D1jroI0=; b=LqAYw1Eh6GQW+wE0R81nTGKkVz/oUUMwR6OjKU9FE+cJ67JnTEUBNAMb xpjsUBKbee1TeZZshEHZYU8DArbCZ7keIzqb/ZXTuIEkD1AOaJnm2lkfV 5m2ZCNDfD1Abx43X+hiBfiIVA/bfL3UaHPzBDGiZ7XAw1hnPu2aCJtw2c I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CHAQCfHcFZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhSwng3WLFJBMK5YkghIKhTsChRkWAQIBAQEBAQEBayiFGQEFIw8?= =?us-ascii?q?BBUEQCQIOCgICJgICVwYBDAYCAQGKL40VnWaCJ4skAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEhgQ6CHYNSgg6BcIENiAuCYAEEoQyUVotXhyONYIdXgTkmByqBDTIhCBwVh2Y?= =?us-ascii?q?/NohtAQEB?=
X-IronPort-AV: E=Sophos;i="5.42,418,1500940800"; d="scan'208";a="654739833"
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; 19 Sep 2017 13:39:16 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8JDdGuh017434; Tue, 19 Sep 2017 13:39:16 GMT
To: Lou Berger , Martin Bjorklund 
Cc: netmod@ietf.org
References: <5b512435-cebd-3534-eeb3-649154450d81@cisco.com> <20170915.134007.262763963470255554.mbj@tail-f.com>  <20170919.132947.358857445863848356.mbj@tail-f.com> <990b8722-7a48-46ce-3f5d-96bc5cb66075@labn.net>
From: Robert Wilton 
Message-ID: <3734864d-9b27-7f61-c638-fd7c656c3692@cisco.com>
Date: Tue, 19 Sep 2017 14:39:16 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <990b8722-7a48-46ce-3f5d-96bc5cb66075@labn.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Sep 2017 13:39:20 -0000

On 19/09/2017 14:28, Lou Berger wrote:
>
> On 9/19/2017 7:29 AM, Martin Bjorklund wrote:
>> Lou Berger  wrote:
>>> Martin,
>>>
>>> Speaking as a contributor:
>>>
>>>
>>> On 9/15/2017 7:40 AM, Martin Bjorklund wrote:
>>>> Robert Wilton  wrote:
>>>>> On 15/09/2017 11:21, Ladislav Lhotka wrote:
>>>>>> Andy Bierman píše v Čt 14. 09. 2017 v 08:43 -0700:
>>>>>>> Hi,
>>>>>>>
>>>>>>>
>>>>>>> Actually I liked the early pyang output that was concise and easy to
>>>>>>> remember.
>>>>>>> The current format gets very cluttered and there are too many little
>>>>>>> symbols
>>>>>>> to remember them all.
>>>>>> I agree.
>>>> Me too.  The current draft adds three new magic symbols: "mp" "@" and
>>>> "/".
>>>>
>>>> "mp" is for a mount point, and it can be generated directly from the
>>>> YANG modules.
>>>>
>>>> Directly under a "mp", "/" and "@" are used to indicate that a node is mounted
>>>> or available through a parent reference, respectively.
>>>>
>>>> I actually question the usability of "/" and "@".
>>> I agree that / and @ are something new, and enabled by schema mount.
>>> There have been repeated comments in the RTG WG that there needs to be
>>> some way for vendors to convey what they have implemented with Schema
>>> mount
>> If that's the requirement, using the tree diagram is probably not the
>> best way.  The tree diagram is intended to provide an overview of a
>> given (set of) YANG module(s).
>>
>> A perhaps better way to convey the information is to create a file
>> with an instantiated /schema-mounts tree.
> using what syntax?  JSON and XML really isn't that easy for the (human)
> reader to parse.
Perhaps there needs to be multiple versions of the generated tree output?

1) A normative tree diagram that shows the structure of the model.
2) A subsequent example that demonstrates what it looks like with the 
schema mounted modules.  Within the confines of a text document, the 
tree format still seems like a reasonable way to illustrate this, and I 
would say it is preferable to the verbosity of JSON or XML.

I note that RFC 8022 includes an overview tree model in section 4 with 
some branches pruned, and then the complete representation in an 
appendix, which seems like a pragmatic approach.

Thanks,
Rob


From nobody Tue Sep 19 06:44:14 2017
Return-Path: 
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 75DDA132EC4 for ; Tue, 19 Sep 2017 06:44:13 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bls05HvFFjO for ; Tue, 19 Sep 2017 06:44:11 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 46DB213292E for ; Tue, 19 Sep 2017 06:44:11 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 1399F1AE02A7; Tue, 19 Sep 2017 15:44:10 +0200 (CEST)
Date: Tue, 19 Sep 2017 15:42:38 +0200 (CEST)
Message-Id: <20170919.154238.1738748131929616921.mbj@tail-f.com>
To: lberger@labn.net
Cc: rwilton@cisco.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <990b8722-7a48-46ce-3f5d-96bc5cb66075@labn.net>
References:  <20170919.132947.358857445863848356.mbj@tail-f.com> <990b8722-7a48-46ce-3f5d-96bc5cb66075@labn.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: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Sep 2017 13:44:13 -0000

TG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4gd3JvdGU6DQo+IA0KPiANCj4gT24gOS8xOS8y
MDE3IDc6MjkgQU0sIE1hcnRpbiBCam9ya2x1bmQgd3JvdGU6DQo+ID4gTG91IEJlcmdlciA8bGJl
cmdlckBsYWJuLm5ldD4gd3JvdGU6DQo+ID4+IE1hcnRpbiwNCj4gPj4NCj4gPj4gU3BlYWtpbmcg
YXMgYSBjb250cmlidXRvcjoNCj4gPj4NCj4gPj4NCj4gPj4gT24gOS8xNS8yMDE3IDc6NDAgQU0s
IE1hcnRpbiBCam9ya2x1bmQgd3JvdGU6DQo+ID4+PiBSb2JlcnQgV2lsdG9uIDxyd2lsdG9uQGNp
c2NvLmNvbT4gd3JvdGU6DQo+ID4+Pj4gT24gMTUvMDkvMjAxNyAxMToyMSwgTGFkaXNsYXYgTGhv
dGthIHdyb3RlOg0KPiA+Pj4+PiBBbmR5IEJpZXJtYW4gcMOtxaFlIHYgxIx0IDE0LiAwOS4gMjAx
NyB2IDA4OjQzIC0wNzAwOg0KPiA+Pj4+Pj4gSGksDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+
Pj4+IEFjdHVhbGx5IEkgbGlrZWQgdGhlIGVhcmx5IHB5YW5nIG91dHB1dCB0aGF0IHdhcyBjb25j
aXNlIGFuZCBlYXN5IHRvDQo+ID4+Pj4+PiByZW1lbWJlci4NCj4gPj4+Pj4+IFRoZSBjdXJyZW50
IGZvcm1hdCBnZXRzIHZlcnkgY2x1dHRlcmVkIGFuZCB0aGVyZSBhcmUgdG9vIG1hbnkgbGl0dGxl
DQo+ID4+Pj4+PiBzeW1ib2xzDQo+ID4+Pj4+PiB0byByZW1lbWJlciB0aGVtIGFsbC4NCj4gPj4+
Pj4gSSBhZ3JlZS4NCj4gPj4+IE1lIHRvby4gIFRoZSBjdXJyZW50IGRyYWZ0IGFkZHMgdGhyZWUg
bmV3IG1hZ2ljIHN5bWJvbHM6ICJtcCIgIkAiIGFuZA0KPiA+Pj4gIi8iLg0KPiA+Pj4NCj4gPj4+
ICJtcCIgaXMgZm9yIGEgbW91bnQgcG9pbnQsIGFuZCBpdCBjYW4gYmUgZ2VuZXJhdGVkIGRpcmVj
dGx5IGZyb20gdGhlDQo+ID4+PiBZQU5HIG1vZHVsZXMuDQo+ID4+Pg0KPiA+Pj4gRGlyZWN0bHkg
dW5kZXIgYSAibXAiLCAiLyIgYW5kICJAIiBhcmUgdXNlZCB0byBpbmRpY2F0ZSB0aGF0IGEgbm9k
ZSBpcyBtb3VudGVkDQo+ID4+PiBvciBhdmFpbGFibGUgdGhyb3VnaCBhIHBhcmVudCByZWZlcmVu
Y2UsIHJlc3BlY3RpdmVseS4NCj4gPj4+DQo+ID4+PiBJIGFjdHVhbGx5IHF1ZXN0aW9uIHRoZSB1
c2FiaWxpdHkgb2YgIi8iIGFuZCAiQCIuICANCj4gPj4gSSBhZ3JlZSB0aGF0IC8gYW5kIEAgYXJl
IHNvbWV0aGluZyBuZXcsIGFuZCBlbmFibGVkIGJ5IHNjaGVtYSBtb3VudC7CoA0KPiA+PiBUaGVy
ZSBoYXZlIGJlZW4gcmVwZWF0ZWQgY29tbWVudHMgaW4gdGhlIFJURyBXRyB0aGF0IHRoZXJlIG5l
ZWRzIHRvIGJlDQo+ID4+IHNvbWUgd2F5IGZvciB2ZW5kb3JzIHRvIGNvbnZleSB3aGF0IHRoZXkg
aGF2ZSBpbXBsZW1lbnRlZCB3aXRoIFNjaGVtYQ0KPiA+PiBtb3VudA0KPiA+IElmIHRoYXQncyB0
aGUgcmVxdWlyZW1lbnQsIHVzaW5nIHRoZSB0cmVlIGRpYWdyYW0gaXMgcHJvYmFibHkgbm90IHRo
ZQ0KPiA+IGJlc3Qgd2F5LiAgVGhlIHRyZWUgZGlhZ3JhbSBpcyBpbnRlbmRlZCB0byBwcm92aWRl
IGFuIG92ZXJ2aWV3IG9mIGENCj4gPiBnaXZlbiAoc2V0IG9mKSBZQU5HIG1vZHVsZShzKS4NCj4g
Pg0KPiA+IEEgcGVyaGFwcyBiZXR0ZXIgd2F5IHRvIGNvbnZleSB0aGUgaW5mb3JtYXRpb24gaXMg
dG8gY3JlYXRlIGEgZmlsZQ0KPiA+IHdpdGggYW4gaW5zdGFudGlhdGVkIC9zY2hlbWEtbW91bnRz
IHRyZWUuDQo+IHVzaW5nIHdoYXQgc3ludGF4P8KgIEpTT04gYW5kIFhNTCByZWFsbHkgaXNuJ3Qg
dGhhdCBlYXN5IGZvciB0aGUgKGh1bWFuKQ0KPiByZWFkZXIgdG8gcGFyc2UuDQoNCkVpdGhlciBK
U09OIG9yIFhNTC4NCg0KPiA+PiBhbmQgdGhpcyBpcyBvbmUgd2F5IHRvIGhlbHAgY29udmV5IChh
KSB3aGF0IGlzIGV4cGVjdGVkIG9mIHNlcnZlcg0KPiA+PiBpbXBsZW1lbnRvcnMgYW5kIChiKSB3
aGF0IGNsaWVudCBpbXBsZW1lbnRvcnMgc2hvdWxkIGV4cGVjdC4NCj4gPj4NCj4gPiDCoMKgIEhl
bmNlIHRoZQ0KPiA+PiBjdXJyZW50IGRyYWZ0IHRleHQ6DQo+ID4+DQo+ID4+IMKgIEluIGRlc2Ny
aWJpbmcgdGhlIGludGVuZGVkIHVzZSBvZiBhIG1vZHVsZSBjb250YWluaW5nIGEgbW91bnQgcG9p
bnQsDQo+ID4+IMKgwqAgaXQgaXMgaGVscGZ1bCB0byBzaG93IGhvdyB0aGUgbW91bnQgcG9pbnQg
d291bGQgbG9vayB3aXRoIG1vdW50ZWQNCj4gPj4gwqDCoCBtb2R1bGVzLg0KPiA+Pg0KPiA+PiBU
aGUgd2hvbGUgcG9pbnQgb2YgdHJlZXMgaXMgdG8gZmFjaWxpdGF0ZSB1bmRlcnN0YW5kaW5nIGZv
ciB0aG9zZSB3aG8NCj4gPj4gYXJlIGxlc3MgZmFtaWxpYXIgd2l0aCBhIG1vZGVsIHRoYW4gdGhl
IGF1dGhvcnMsIGFuZCBJTU8gdGhhdCdzIHRoZQ0KPiA+PiBwYXJhbW91bnQgcGVyc3BlY3RpdmUg
aW4gdGhpcyBkaXNjdXNzaW9uLg0KPiA+IEZ1bGx5IGFncmVlISAgSSB3b3VsZCBzYXkgdGhhdCB3
ZSBoYXZlIHRvIG1ha2Ugc3VyZSB0aGF0IHRoZSBkaWFncmFtcw0KPiA+IGNhbiBiZSB1bmRlcnN0
b29kIGJ5IHBlb3BsZSBsZXNzIGZhbWlsaWFyIHdpdGggdGhlIHRlY2hub2xvZ3kgdGhhbiB0aGUN
Cj4gPiBhdXRob3JzLiAgTWl4aW5nIHNjaGVtYSBhbmQgaW5zdGFuY2UgZGF0YSBkb2VzIG5vdCBo
ZWxwIGhlcmUuDQo+IA0KPiBDYW4geW91IHByb3Bvc2UgYW4gYWx0ZXJuYXRpdmU/DQoNCkFzIEkg
aGF2ZSB3cml0dGVuIGJlZm9yZSwgSSB0aGluayB0aGUgIi8iIGlzIG5vdCBuZWVkZWQsIHNvIEkg
d291bGQNCnJlbW92ZSB0aGF0LiAgSSB3b3VsZCBhbHNvIG5vdCBsaXN0IHRoZSBub2RlcyBmcm9t
ICJwYXJlbnQtcmVmZXJlbmNlcyINCmluIHRoZSBzYW1lIHRyZWUgb3VwdXQuICBJdCBpcyBub3Qg
Y2xlYXIgdG8gbWUgdGhhdCB0aGlzIGxldmVsIG9mDQpkZXRhaWwgaXMgbmVlZGVkIGluIHRoZSB0
cmVlLCBhbmQgLSBhcyBub3RlZCBiZWZvcmUgLSBpdCBpc24ndCBldmVuDQpjb3JyZWN0IHRvIGxp
c3QgZS5nLiAiaW50ZXJmYWNlcyIgd2hlbiB0aGUgcGFyZW50LXJlZmVyZW5jZSBpbiBmYWN0DQpz
ZWxlY3RzIGEgc2luZ2xlIGludGVyZmFjZS4NCg0KPiBUaGUgcm91dGluZyBXRyBwYXJ0aWNpcGFu
dHMgc2VlbSB0bw0KPiBmaW5kIHRoZXNlIHVzZWZ1bCwgd2UgY2FuIGFsc28gYXNrIHRoZXJlIGZv
ciBicm9hZGVyIGlucHV0IGlmIHlvdSdkIGxpa2UuDQoNCk9uZSBhcHByb2FjaCBpcyB0byBhZGQg
dGhlIHVuaW9uIG9mIGV2ZXl0aGluZyB0aGF0IHNvbWUgcGVvcGxlIGZpbmQNCnVzZWZ1bC4gIElu
IHRoZSBlbmQgd2UgaGF2ZSB0byBsb29rIGZvciBXRyBjb25zZW5zdXMuICBTZXZlcmFsIHBlb3Bs
ZQ0KaGF2ZSBzYWlkIHRoYXQgdGhleSBwcmVmZXIgYSBsZXNzIGNsdXR0ZXJlZCBmb3JtYXQuDQoN
Cj4gPj4+IFNpbmNlIGEgcGFyZW50DQo+ID4+PiByZWZlcmVuY2UgY2FuIGJlIHZlcnkgc3BlY2lm
aWMsIGUuZy4gb25lIHNwZWNpZmljIGludGVyZmFjZSwgaXQgaXNuJ3QNCj4gPj4+IHJlYWxseSBh
Y2N1cmF0ZSB0byBzaG93Og0KPiA+Pj4NCj4gPj4+ICAgICAgICAgICAgICAgICAgICstLW1wIHZy
Zi1yb290DQo+ID4+PiAgICAgICAgICAgICAgICAgICAgICArLS1ydyBydDpyb3V0aW5nLw0KPiA+
Pj4gICAgICAgICAgICAgICAgICAgICAgfCAgLi4uDQo+ID4+PiAgICAgICAgICAgICAgICAgICAg
ICArLS1ybyBpZjppbnRlcmZhY2VzQA0KPiA+PiBUaGlzIGlzIGp1c3QgYSBjb25kaXRpb25hbCBh
bmQgd2UgaGF2ZSBwcmVjZWRlbnQgb24gaG93IHRvIGhhbmRsZQ0KPiA+PiBjb25kaXRpb25hbCBy
ZXByZXNlbnRhdGlvbi4gwqDCoA0KPiA+Pg0KPiA+Pj4gQW5kIHRoZSB0cmFpbGluZyAiLyIgb24g
cnQ6cm91dGluZyBkb2Vzbid0IGFkZCBhbnkgaW5mb3JtYXRpb24gd2UNCj4gPj4+IGRvbid0IGFs
cmVhZHkga25vdy4gIFNpbmNlIHZyZi1yb290IGlzIGEgbW91bnQgcG9pbnQsIGl0IGZvbGxvd3Mg
dGhhdA0KPiA+Pj4gaXRzIGNoaWxkcmVuIGFyZSBtb3VudGVkLg0KPiA+PiBUaGUgaXNzdWUgaXMg
YSBiaXQgbW9yZSBjb21wbGV4IHdoZW4gY29uc2lkZXJpbmcgc29tZSByZWFsIHVzZSBjYXNlcywN
Cj4gPj4gcGFydGljdWxhcml0eSB3aGVuIHBhcmVudCByZWZlcmVuY2VzIGFuZCBhdWdtZW50YXRp
b25zIGFyZSB1c2VkLsKgIEZvcg0KPiA+PiBleGFtcGxlIGNvbnNpZGVyIHRoZSBmb2xsb3dpbmcg
KndpdGhvdXQqIHRoZSB1c2UgLyBvciBAOg0KPiA+Pg0KPiA+PiBtb2R1bGU6IGlldGYtbmV0d29y
ay1pbnN0YW5jZQ0KPiA+PiDCoCArLS1ydyBuZXR3b3JrLWluc3RhbmNlcw0KPiA+PiDCoMKgwqDC
oCArLS1ydyBuZXR3b3JrLWluc3RhbmNlKiBbbmFtZV0NCj4gPj4gwqDCoMKgwqDCoMKgwqAgfCAu
Li4NCj4gPj4gwqDCoMKgwqDCoMKgwqAgKy0tcncgKHJvb3QtdHlwZSkNCj4gPj4gwqDCoMKgwqDC
oMKgwqDCoMKgwqAgKy0tOih2cmYtcm9vdCkNCj4gPj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqAgKy0tbXAgdnJmLXJvb3QNCj4gPj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg
Ky0tcm8gcnQ6cm91dGluZy1zdGF0ZQ0KPiA+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoCB8wqAgKy0tcm8gcm91dGVyLWlkP8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
IHlhbmc6ZG90dGVkLXF1YWQNCj4gPj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg
fMKgICstLXJvIGNvbnRyb2wtcGxhbmUtcHJvdG9jb2xzDQo+ID4+IMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoCArLS1ybyBjb250cm9sLXBsYW5lLXByb3RvY29sKiBb
dHlwZSBuYW1lXQ0KPiA+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKg
wqDCoMKgwqAgKy0tcm8gb3NwZjpvc3BmDQo+ID4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoCArLS1ybyBpbnN0YW5jZSogW2FmXQ0KPiA+PiDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCArLS1ydyBydDpyb3V0aW5nDQo+ID4+IMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoCArLS1ydyByb3V0ZXItaWQ/wqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgeWFuZzpkb3R0ZWQtcXVhZA0KPiA+PiDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqAgKy0tcncgY29udHJvbC1wbGFuZS1wcm90b2Nv
bHMNCj4gPj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgICstLXJ3
IGNvbnRyb2wtcGxhbmUtcHJvdG9jb2wqIFt0eXBlIG5hbWVdDQo+ID4+IMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoCArLS1ydyBvc3BmOm9zcGYNCj4gPj4gwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgICstLXJ3IGluc3RhbmNl
KiBbYWZdDQo+ID4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKg
wqDCoMKgwqDCoCArLS1ydyBhcmVhcw0KPiA+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgKy0tcncgYXJlYSogW2FyZWEtaWRdDQo+
ID4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoCArLS1ydyBpbnRlcmZhY2VzDQo+ID4+IMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCArLS1y
dyBpbnRlcmZhY2UqIFtuYW1lXQ0KPiA+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgKy0tcncgbmFt
ZSBpZjppbnRlcmZhY2UtcmVmDQo+ID4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
IHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCArLS1ydyBjb3N0
P8KgwqAgdWludDE2DQo+ID4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICstLXJv
IGlmOmludGVyZmFjZXMNCj4gPj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKg
IC4uLg0KPiA+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCArLS1ybyBpZjppbnRl
cmZhY2VzLXN0YXRlDQo+ID4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoCAu
Li4NCj4gPj4NCj4gPj4NCj4gPj4gSXQncyBjZXJ0YWlubHkgbm90IHRvbyBoYXJkIHRvIHNwb3Qg
dGhlIHRvcCBsZXZlbCBtb3VudHMsIGJ1dCBpdCBpcw0KPiA+PiBpbXBvc3NpYmxlIHRvIGRpc3Rp
bmd1aXNoIHRoZSBwYXJlbnQgcmVmZXJlbmNlcyBmcm9tIHRoZSBhY3R1YWwgbW91bnRzLsKgDQo+
ID4gTXkgcHJvcG9zYWwgd291bGQgYmUgdG8gbm90IGV2ZW4gc2hvdyB0aGUgcGFyZW50IHJlZmVy
ZW5jZXMgaW4gdGhlDQo+ID4gZGlhZ3JhbS4gIElmIHdlIGRvIHRoYXQsIHRoZSAnLycgaXMgbm90
IG5lZWRlZC4NCj4gPg0KPiA+PiBGdXJ0aGVyIG1vcmUsIHNvbWUgbW91bnRzIGFyZSBoYXJkIHRv
IHNwb3QuwqAgRm9yIGV4YW1wbGUsIG5vdGljZSBvc3BmLsKgDQo+ID4+IERpZCB5b3Ugbm90aWNl
IHRoYXQgaXQncyBhIG1vdW50Pw0KPiA+IFRoaXMgaXMgYWN0dWFsbHkgbm90IGNvcnJlY3QuICBv
c3BmIGlzICpub3QqIGEgbW91bnQ7IGl0IGlzIGFuIGF1Z21lbnQuDQo+ID4NCj4gaXQncyBhIG1v
dW50ZWQgbW9kdWxlIHRoYXQgYXVnbWVudHMgYW5vdGhlciBtb3VudGVkIG1vZHVsZS4NCg0KQnV0
IHdoeSB3b3VsZCBpdCBoYXZlIGEgIi8iIGp1c3QgYi9jIGl0IGlzIGF1Z21lbnRlZCwgd2hlbiBp
dHMgc2libGluZw0KJ2NvbnRyb2wtcGxhbi1wcm90b2NvbCcgZG9lc24ndCBoYXZlIHRoZSAiLyI/
ICBXaGF0IGFkZGl0aW9uIGluZm8gZG9lcw0KdGhlICIvIiBjb252ZXk/DQoNCg0KL21hcnRpbg0K


From nobody Tue Sep 19 06:49:02 2017
Return-Path: 
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 D4DE3134326 for ; Tue, 19 Sep 2017 06:49:01 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEH8VeOp3yLs for ; Tue, 19 Sep 2017 06:49: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 AC06C134322 for ; Tue, 19 Sep 2017 06:49:00 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id B78C91AE0455; Tue, 19 Sep 2017 15:48:59 +0200 (CEST)
Date: Tue, 19 Sep 2017 15:47:28 +0200 (CEST)
Message-Id: <20170919.154728.285206235172744617.mbj@tail-f.com>
To: rwilton@cisco.com
Cc: lberger@labn.net, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <3734864d-9b27-7f61-c638-fd7c656c3692@cisco.com>
References: <20170919.132947.358857445863848356.mbj@tail-f.com> <990b8722-7a48-46ce-3f5d-96bc5cb66075@labn.net> <3734864d-9b27-7f61-c638-fd7c656c3692@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Sep 2017 13:49:02 -0000

Um9iZXJ0IFdpbHRvbiA8cndpbHRvbkBjaXNjby5jb20+IHdyb3RlOg0KPiANCj4gDQo+IE9uIDE5
LzA5LzIwMTcgMTQ6MjgsIExvdSBCZXJnZXIgd3JvdGU6DQo+ID4NCj4gPiBPbiA5LzE5LzIwMTcg
NzoyOSBBTSwgTWFydGluIEJqb3JrbHVuZCB3cm90ZToNCj4gPj4gTG91IEJlcmdlciA8bGJlcmdl
ckBsYWJuLm5ldD4gd3JvdGU6DQo+ID4+PiBNYXJ0aW4sDQo+ID4+Pg0KPiA+Pj4gU3BlYWtpbmcg
YXMgYSBjb250cmlidXRvcjoNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gT24gOS8xNS8yMDE3IDc6NDAg
QU0sIE1hcnRpbiBCam9ya2x1bmQgd3JvdGU6DQo+ID4+Pj4gUm9iZXJ0IFdpbHRvbiA8cndpbHRv
bkBjaXNjby5jb20+IHdyb3RlOg0KPiA+Pj4+PiBPbiAxNS8wOS8yMDE3IDExOjIxLCBMYWRpc2xh
diBMaG90a2Egd3JvdGU6DQo+ID4+Pj4+PiBBbmR5IEJpZXJtYW4gcMOtxaFlIHYgxIx0IDE0LiAw
OS4gMjAxNyB2IDA4OjQzIC0wNzAwOg0KPiA+Pj4+Pj4+IEhpLA0KPiA+Pj4+Pj4+DQo+ID4+Pj4+
Pj4NCj4gPj4+Pj4+PiBBY3R1YWxseSBJIGxpa2VkIHRoZSBlYXJseSBweWFuZyBvdXRwdXQgdGhh
dCB3YXMgY29uY2lzZSBhbmQgZWFzeSB0bw0KPiA+Pj4+Pj4+IHJlbWVtYmVyLg0KPiA+Pj4+Pj4+
IFRoZSBjdXJyZW50IGZvcm1hdCBnZXRzIHZlcnkgY2x1dHRlcmVkIGFuZCB0aGVyZSBhcmUgdG9v
IG1hbnkgbGl0dGxlDQo+ID4+Pj4+Pj4gc3ltYm9scw0KPiA+Pj4+Pj4+IHRvIHJlbWVtYmVyIHRo
ZW0gYWxsLg0KPiA+Pj4+Pj4gSSBhZ3JlZS4NCj4gPj4+PiBNZSB0b28uICBUaGUgY3VycmVudCBk
cmFmdCBhZGRzIHRocmVlIG5ldyBtYWdpYyBzeW1ib2xzOiAibXAiICJAIiBhbmQNCj4gPj4+PiAi
LyIuDQo+ID4+Pj4NCj4gPj4+PiAibXAiIGlzIGZvciBhIG1vdW50IHBvaW50LCBhbmQgaXQgY2Fu
IGJlIGdlbmVyYXRlZCBkaXJlY3RseSBmcm9tIHRoZQ0KPiA+Pj4+IFlBTkcgbW9kdWxlcy4NCj4g
Pj4+Pg0KPiA+Pj4+IERpcmVjdGx5IHVuZGVyIGEgIm1wIiwgIi8iIGFuZCAiQCIgYXJlIHVzZWQg
dG8gaW5kaWNhdGUgdGhhdCBhIG5vZGUgaXMNCj4gPj4+PiBtb3VudGVkDQo+ID4+Pj4gb3IgYXZh
aWxhYmxlIHRocm91Z2ggYSBwYXJlbnQgcmVmZXJlbmNlLCByZXNwZWN0aXZlbHkuDQo+ID4+Pj4N
Cj4gPj4+PiBJIGFjdHVhbGx5IHF1ZXN0aW9uIHRoZSB1c2FiaWxpdHkgb2YgIi8iIGFuZCAiQCIu
DQo+ID4+PiBJIGFncmVlIHRoYXQgLyBhbmQgQCBhcmUgc29tZXRoaW5nIG5ldywgYW5kIGVuYWJs
ZWQgYnkgc2NoZW1hIG1vdW50Lg0KPiA+Pj4gVGhlcmUgaGF2ZSBiZWVuIHJlcGVhdGVkIGNvbW1l
bnRzIGluIHRoZSBSVEcgV0cgdGhhdCB0aGVyZSBuZWVkcyB0byBiZQ0KPiA+Pj4gc29tZSB3YXkg
Zm9yIHZlbmRvcnMgdG8gY29udmV5IHdoYXQgdGhleSBoYXZlIGltcGxlbWVudGVkIHdpdGggU2No
ZW1hDQo+ID4+PiBtb3VudA0KPiA+PiBJZiB0aGF0J3MgdGhlIHJlcXVpcmVtZW50LCB1c2luZyB0
aGUgdHJlZSBkaWFncmFtIGlzIHByb2JhYmx5IG5vdCB0aGUNCj4gPj4gYmVzdCB3YXkuICBUaGUg
dHJlZSBkaWFncmFtIGlzIGludGVuZGVkIHRvIHByb3ZpZGUgYW4gb3ZlcnZpZXcgb2YgYQ0KPiA+
PiBnaXZlbiAoc2V0IG9mKSBZQU5HIG1vZHVsZShzKS4NCj4gPj4NCj4gPj4gQSBwZXJoYXBzIGJl
dHRlciB3YXkgdG8gY29udmV5IHRoZSBpbmZvcm1hdGlvbiBpcyB0byBjcmVhdGUgYSBmaWxlDQo+
ID4+IHdpdGggYW4gaW5zdGFudGlhdGVkIC9zY2hlbWEtbW91bnRzIHRyZWUuDQo+ID4gdXNpbmcg
d2hhdCBzeW50YXg/wqAgSlNPTiBhbmQgWE1MIHJlYWxseSBpc24ndCB0aGF0IGVhc3kgZm9yIHRo
ZQ0KPiA+IChodW1hbikNCj4gPiByZWFkZXIgdG8gcGFyc2UuDQo+IFBlcmhhcHMgdGhlcmUgbmVl
ZHMgdG8gYmUgbXVsdGlwbGUgdmVyc2lvbnMgb2YgdGhlIGdlbmVyYXRlZCB0cmVlDQo+IG91dHB1
dD8NCj4gDQo+IDEpIEEgbm9ybWF0aXZlIHRyZWUgZGlhZ3JhbSB0aGF0IHNob3dzIHRoZSBzdHJ1
Y3R1cmUgb2YgdGhlIG1vZGVsLg0KPiAyKSBBIHN1YnNlcXVlbnQgZXhhbXBsZSB0aGF0IGRlbW9u
c3RyYXRlcyB3aGF0IGl0IGxvb2tzIGxpa2Ugd2l0aCB0aGUNCj4gc2NoZW1hIG1vdW50ZWQgbW9k
dWxlcy7CoCBXaXRoaW4gdGhlIGNvbmZpbmVzIG9mIGEgdGV4dCBkb2N1bWVudCwgdGhlDQo+IHRy
ZWUgZm9ybWF0IHN0aWxsIHNlZW1zIGxpa2UgYSByZWFzb25hYmxlIHdheSB0byBpbGx1c3RyYXRl
IHRoaXMsIGFuZA0KPiBJIHdvdWxkIHNheSBpdCBpcyBwcmVmZXJhYmxlIHRvIHRoZSB2ZXJib3Np
dHkgb2YgSlNPTiBvciBYTUwuDQo+IA0KPiBJIG5vdGUgdGhhdCBSRkMgODAyMiBpbmNsdWRlcyBh
biBvdmVydmlldyB0cmVlIG1vZGVsIGluIHNlY3Rpb24gNCB3aXRoDQo+IHNvbWUgYnJhbmNoZXMg
cHJ1bmVkLCBhbmQgdGhlbiB0aGUgY29tcGxldGUgcmVwcmVzZW50YXRpb24gaW4gYW4NCj4gYXBw
ZW5kaXgsIHdoaWNoIHNlZW1zIGxpa2UgYSBwcmFnbWF0aWMgYXBwcm9hY2guDQoNClN1cmUsIGJ1
dCB0aGUgcXVlc3Rpb24gaXMgYWJvdXQgd2hhdCBzcGVjaWFsIHN5bWJvbHMgd2UgZGVmaW5lLiAg
RG8gd2UNCm5lZWQgdGhlIGV4dHJhIHN5bWJvbHMgIi8iIGFuZCAiQCIsIGFuZCBkbyB3ZSBhZ3Jl
ZSBvbiB3aGF0IHRoZXkgbWVhbj8NCg0KDQovbWFydGluDQo=


From nobody Tue Sep 19 06:49:18 2017
Return-Path: 
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 AF5F313432D for ; Tue, 19 Sep 2017 06:49:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 goGxjSkTl43L for ; Tue, 19 Sep 2017 06:49:11 -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 36D85134322 for ; Tue, 19 Sep 2017 06:49:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4428; q=dns/txt; s=iport; t=1505828951; x=1507038551; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=Yfu7cYDf+aTG081qif0bBoGFETiAoLEJ0x2uHGXK9dc=; b=IVnZWUK+XorqNlchNcBM62l+kh4r0Pd481wpPu+sXEMNHE8wQ0kbnFzo NiNGGOYAc5To8quiiK/wEj9inyhdx2uu2lkSbmqZP4glGYGnI/AHuTVRe CwrGq3MM20FwZi/oZ4RNLOJdia4rMIaOe+hwDkL+pvqAMVAv/XFEZDhI+ c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CPAQCCHsFZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy2BEW4ng3WLFJBMCSKWJA6CBAoYC4RJTwKFGRYBAgEBAQEBAQF?= =?us-ascii?q?rKIUYAQEBAQIBAQEhBAsBBTYbCQIOBAYCAiYCAiciDgYBDAYCAQGKJwgQjQWdZ?= =?us-ascii?q?oFtOoskAQEBAQEBAQEBAQEBAQEBAQEBARoFgQ6CHYNSgWMrC4JyhEUBEgGDMoJ?= =?us-ascii?q?gBYoFhy6BaI1xlFYCghGFaoNahyONYIdXgTkmBSyBAgsyIQgcFUmHHT82hjuCM?= =?us-ascii?q?gEBAQ?=
X-IronPort-AV: E=Sophos;i="5.42,418,1500940800"; d="scan'208";a="657583538"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Sep 2017 13:49:09 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8JDn9Mn030288; Tue, 19 Sep 2017 13:49:09 GMT
To: Martin Bjorklund , netmod@ietf.org
References: <393d3f20-98e3-b4de-e2d7-d627de59ac1f@labn.net> <1505814417.5445.14.camel@nic.cz> <20170919.115915.1668734288988659917.mbj@tail-f.com> <87shfistam.fsf@nic.cz>
From: Robert Wilton 
Message-ID: <75221540-d587-cd90-60ab-7cf6a8ff5cd4@cisco.com>
Date: Tue, 19 Sep 2017 14:49:09 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <87shfistam.fsf@nic.cz>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Sep 2017 13:49:17 -0000

Hi Lada,


On 19/09/2017 14:37, Ladislav Lhotka wrote:
> Martin Bjorklund  writes:
>
>> Ladislav Lhotka  wrote:
>>> Hi,
>>>
>>> I support the adoption but I propose two conceptual changes:
>>>
>>> 1. Introduce a new module name and namespace so that it is not
>>> necessary to carry along the deprecated baggage. If readability is
>>> the primary concern, this is IMO the way to go. Instead of
>>> "ietf-ip-2", I'd suggest something like "ietf- ip-nmda".
>>>
>>> 2. Avoid obsoleting RFC 7277. I believe the old modules may continue
>>> to be used
>>> in areas where NMDA is an overkill, such as open source home
>>> routers.
>> Why wouldn't NMDA be appropriate in an open source home router?  Note
>> that the new model really just have a single tree instead of two
>> trees, so the data that needs to be instrumented is more or less the
>> same.
> It is quite likely that some parts of the data models will be
> implemented only as configuration but not state data. In the "old style"
> modules it is easy to add a deviation for the node(s) under -state but
> in NMDA style this is not possible because we only have one node.
The new YANG library allows different sets of modules to be available 
for  datastores vs .   The operational 
datastore can also have different features supported and different 
deviations vs the conventional datastores.

So, the device can make the same deviations to remove the state leaves 
from .  Or if they don't want to support the module in 
operational at all then a device could just list it as being supported 
in the conventional datastores and not .

>
> There are subtle differences in the schemas for configuration and state
> data that the NMDA concept doesn't address. If you want another example,
> ietf-routing-2 has the "router-id" leaf that is conditional via the
> "router-id" feature. If this feature is not supported, router-id cannot
> be explicitly configured (it is assigned by the system) but in state data
> "router-id" needs IMO be present in any case. But the if-feature
> isn't able to differentiate between configuration and state data if
> there is only one node for both.
The new YANG library also supports this:

The "router-id" feature would be disabled for the conventional 
datastores, but enabled for .

>
>> In fact, if we claim that the new architecture is not appropriate for
>> some devices I think we have failed, especially if the conclusion is
>> that we need to maintain two versions of all modules going forward.
> I am not asking for this but, on the other hand, if NMDA versions used a new
> module name and namespace (my item #1, which is what ietf-routing-2
> does), then I don't see any pressing need for obsoleting the old style
> modules.
I think that creating a "-2" versions of these models at this time might 
be a mistake.  I actually think that the "deprecate state leaves" -> 
"obsolete state leaves" -> "delete state leaves" path is a better choice.

Thanks,
Rob


>
> Lada
>
>>
>> /martin
>>
>>
>>
>>
>>
>>
>>> NMDA
>>> implementors should be aware of the new modules but there is no need to
>>> eradicate the old data models.
>>>
>>> #2 applies also to other modules for which the NMDA version is underway.
>>>
>>> Lada
>>>
>>> PS. The subject is wrong, it shoud be -rfc7277bis-
>>>   
>>> Lou Berger píše v Po 18. 09. 2017 v 10:33 -0400:
>>>> All,
>>>>
>>>> This is start of a two week poll on making
>>>> draft-bjorklund-netmod-rfc7227bis-00 a working group document. Please
>>>> send email to the list indicating "yes/support" or "no/do not support".
>>>> If indicating no, please state your reservations with the document.  If
>>>> yes, please also feel free to provide comments you'd like to see
>>>> addressed once the document is a WG document.
>>>>
>>>> The poll ends Oct 2.
>>>>
>>>> Thanks,
>>>>
>>>> Lou (and Kent)
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> -- 
>>> Ladislav Lhotka
>>> Head, CZ.NIC Labs
>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod


From nobody Tue Sep 19 06:55:26 2017
Return-Path: 
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 6B1A4134326 for ; Tue, 19 Sep 2017 06:55:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 s7rnwrwmXjmz for ; Tue, 19 Sep 2017 06:55:22 -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 34BDB132D51 for ; Tue, 19 Sep 2017 06:55:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3332; q=dns/txt; s=iport; t=1505829322; x=1507038922; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=mMhqzBZFUpB9Cfbf1GmjYMsdEXeYoKuPL8QfFYhXRbw=; b=dA1y/HTVv8H4zAQHa+1xgfIQSZoNqTCCEc91NcJcEdtDl3mD3o/I6vsO gNG9ngzbJFeV1K+AF0VIweODCevBhNHQv5TsIoqKmuaijUhsEYgnh9xMc K9Bjk7yEipO7g4MvlnxPAmNVlbT1FiLfYPeLNere3zLFNqfR6zJ4HnHTf M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CMAQCCHsFZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhSwng3WLFJBMCSKWJIISCoU7AoUYFwECAQEBAQEBAWsohRkBBSM?= =?us-ascii?q?PAQVBEAkCDgoCAiYCAlcGDQYCAQGKL40VnWaCJ4skAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?SKBDoIdg1KCDguBZYENiAuCYAEEoQyUVotXhyONYIdXgTkhAjSBDTIhCBwVh2Y?= =?us-ascii?q?/NohtAQEB?=
X-IronPort-AV: E=Sophos;i="5.42,418,1500940800"; d="scan'208";a="657583718"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Sep 2017 13:55:20 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v8JDtKl6006333; Tue, 19 Sep 2017 13:55:20 GMT
To: Martin Bjorklund 
Cc: lberger@labn.net, netmod@ietf.org
References: <20170919.132947.358857445863848356.mbj@tail-f.com> <990b8722-7a48-46ce-3f5d-96bc5cb66075@labn.net> <3734864d-9b27-7f61-c638-fd7c656c3692@cisco.com> <20170919.154728.285206235172744617.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: <4f17fbca-6282-6b27-b390-9b85779e96da@cisco.com>
Date: Tue, 19 Sep 2017 14:55:19 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170919.154728.285206235172744617.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Sep 2017 13:55:24 -0000

On 19/09/2017 14:47, Martin Bjorklund wrote:
> Robert Wilton  wrote:
>>
>> On 19/09/2017 14:28, Lou Berger wrote:
>>> On 9/19/2017 7:29 AM, Martin Bjorklund wrote:
>>>> Lou Berger  wrote:
>>>>> Martin,
>>>>>
>>>>> Speaking as a contributor:
>>>>>
>>>>>
>>>>> On 9/15/2017 7:40 AM, Martin Bjorklund wrote:
>>>>>> Robert Wilton  wrote:
>>>>>>> On 15/09/2017 11:21, Ladislav Lhotka wrote:
>>>>>>>> Andy Bierman píše v Čt 14. 09. 2017 v 08:43 -0700:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Actually I liked the early pyang output that was concise and easy to
>>>>>>>>> remember.
>>>>>>>>> The current format gets very cluttered and there are too many little
>>>>>>>>> symbols
>>>>>>>>> to remember them all.
>>>>>>>> I agree.
>>>>>> Me too.  The current draft adds three new magic symbols: "mp" "@" and
>>>>>> "/".
>>>>>>
>>>>>> "mp" is for a mount point, and it can be generated directly from the
>>>>>> YANG modules.
>>>>>>
>>>>>> Directly under a "mp", "/" and "@" are used to indicate that a node is
>>>>>> mounted
>>>>>> or available through a parent reference, respectively.
>>>>>>
>>>>>> I actually question the usability of "/" and "@".
>>>>> I agree that / and @ are something new, and enabled by schema mount.
>>>>> There have been repeated comments in the RTG WG that there needs to be
>>>>> some way for vendors to convey what they have implemented with Schema
>>>>> mount
>>>> If that's the requirement, using the tree diagram is probably not the
>>>> best way.  The tree diagram is intended to provide an overview of a
>>>> given (set of) YANG module(s).
>>>>
>>>> A perhaps better way to convey the information is to create a file
>>>> with an instantiated /schema-mounts tree.
>>> using what syntax?  JSON and XML really isn't that easy for the
>>> (human)
>>> reader to parse.
>> Perhaps there needs to be multiple versions of the generated tree
>> output?
>>
>> 1) A normative tree diagram that shows the structure of the model.
>> 2) A subsequent example that demonstrates what it looks like with the
>> schema mounted modules.  Within the confines of a text document, the
>> tree format still seems like a reasonable way to illustrate this, and
>> I would say it is preferable to the verbosity of JSON or XML.
>>
>> I note that RFC 8022 includes an overview tree model in section 4 with
>> some branches pruned, and then the complete representation in an
>> appendix, which seems like a pragmatic approach.
> Sure, but the question is about what special symbols we define.  Do we
> need the extra symbols "/" and "@", and do we agree on what they mean?
If we agree that tree style output is OK to illustrate the use of schema 
mount, then I think that draft-ietf-netmod-yang-tree-diagrams could 
define them, but indicate that they are only used to illustrate how 
schema mount is used, and would not be seen in a regular YANG tree 
diagram illustrating the structure of a YANG module.  The alternative 
might be that the RFCs that uses them defines what '/' and '@' mean for 
that specific example.

As for what the precise definition of '/' and '@' should be, I'm not 
sure.  I think that you and Lou have a better handle on that ;-)

Thanks,
Rob


>
>
> /martin


From nobody Tue Sep 19 07:06:53 2017
Return-Path: 
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 DBA8B1331F1 for ; Tue, 19 Sep 2017 07:06:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level: 
X-Spam-Status: No, score=-6.999 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, URIBL_BLOCKED=0.001] 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 qyXqvzVvNifD for ; Tue, 19 Sep 2017 07:06:49 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 7D427133080 for ; Tue, 19 Sep 2017 07:06:48 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:f4a0:4ce4:6515:464f]) by mail.nic.cz (Postfix) with ESMTPSA id 93495608E9 for ; Tue, 19 Sep 2017 16:06:46 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1505830006; bh=LhgNNfrA+nQLiGjrKNwiD371fMqgdWuVHPlzWbR5chg=; h=From:To:Date; b=UuWmyZhw67/FQFU8DGD7yiAvqQm1zHuCSX0LFX5SrhyctelBVC9QBz7g6KCnbYd8u tmKU2ipnN+7AnbxByRT049DuIsUdVuwVuZJSSuIi4cEi8ndewOE0nPhw9ilirXTUiF eR/8/wj6YH3agPSUp3m5k/UyPOqTW6Z3EynXbBN0=
Message-ID: <1505830045.5445.47.camel@nic.cz>
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Tue, 19 Sep 2017 16:07:25 +0200
In-Reply-To: <75221540-d587-cd90-60ab-7cf6a8ff5cd4@cisco.com>
References: <393d3f20-98e3-b4de-e2d7-d627de59ac1f@labn.net> <1505814417.5445.14.camel@nic.cz> <20170919.115915.1668734288988659917.mbj@tail-f.com> <87shfistam.fsf@nic.cz> <75221540-d587-cd90-60ab-7cf6a8ff5cd4@cisco.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.24.5 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Sep 2017 14:06:52 -0000

Robert Wilton píše v Út 19. 09. 2017 v 14:49 +0100:
> Hi Lada,
> 
> 
> On 19/09/2017 14:37, Ladislav Lhotka wrote:
> > Martin Bjorklund  writes:
> > 
> > > Ladislav Lhotka  wrote:
> > > > Hi,
> > > > 
> > > > I support the adoption but I propose two conceptual changes:
> > > > 
> > > > 1. Introduce a new module name and namespace so that it is not
> > > > necessary to carry along the deprecated baggage. If readability is
> > > > the primary concern, this is IMO the way to go. Instead of
> > > > "ietf-ip-2", I'd suggest something like "ietf- ip-nmda".
> > > > 
> > > > 2. Avoid obsoleting RFC 7277. I believe the old modules may continue
> > > > to be used
> > > > in areas where NMDA is an overkill, such as open source home
> > > > routers.
> > > 
> > > Why wouldn't NMDA be appropriate in an open source home router?  Note
> > > that the new model really just have a single tree instead of two
> > > trees, so the data that needs to be instrumented is more or less the
> > > same.
> > 
> > It is quite likely that some parts of the data models will be
> > implemented only as configuration but not state data. In the "old style"
> > modules it is easy to add a deviation for the node(s) under -state but
> > in NMDA style this is not possible because we only have one node.
> 
> The new YANG library allows different sets of modules to be available 
> for  datastores vs .   The operational 
> datastore can also have different features supported and different 
> deviations vs the conventional datastores.

OK, I missed the 7895bis draft, sorry. Then there could be differences in
mandatory/optional (e.g. a node is optional in configuration but mandatory in
state data) or the data type of a leaf can differ. How can these be handled?

Lada 

> 
> So, the device can make the same deviations to remove the state leaves 
> from .  Or if they don't want to support the module in 
> operational at all then a device could just list it as being supported 
> in the conventional datastores and not .
> 
> > 
> > There are subtle differences in the schemas for configuration and state
> > data that the NMDA concept doesn't address. If you want another example,
> > ietf-routing-2 has the "router-id" leaf that is conditional via the
> > "router-id" feature. If this feature is not supported, router-id cannot
> > be explicitly configured (it is assigned by the system) but in state data
> > "router-id" needs IMO be present in any case. But the if-feature
> > isn't able to differentiate between configuration and state data if
> > there is only one node for both.
> 
> The new YANG library also supports this:
> 
> The "router-id" feature would be disabled for the conventional 
> datastores, but enabled for .
> 
> > 
> > > In fact, if we claim that the new architecture is not appropriate for
> > > some devices I think we have failed, especially if the conclusion is
> > > that we need to maintain two versions of all modules going forward.
> > 
> > I am not asking for this but, on the other hand, if NMDA versions used a new
> > module name and namespace (my item #1, which is what ietf-routing-2
> > does), then I don't see any pressing need for obsoleting the old style
> > modules.
> 
> I think that creating a "-2" versions of these models at this time might 
> be a mistake.  I actually think that the "deprecate state leaves" -> 
> "obsolete state leaves" -> "delete state leaves" path is a better choice.
> 
> Thanks,
> Rob
> 
> 
> > 
> > Lada
> > 
> > > 
> > > /martin
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > > NMDA
> > > > implementors should be aware of the new modules but there is no need to
> > > > eradicate the old data models.
> > > > 
> > > > #2 applies also to other modules for which the NMDA version is underway.
> > > > 
> > > > Lada
> > > > 
> > > > PS. The subject is wrong, it shoud be -rfc7277bis-
> > > >   
> > > > Lou Berger píše v Po 18. 09. 2017 v 10:33 -0400:
> > > > > All,
> > > > > 
> > > > > This is start of a two week poll on making
> > > > > draft-bjorklund-netmod-rfc7227bis-00 a working group document. Please
> > > > > send email to the list indicating "yes/support" or "no/do not
> > > > > support".
> > > > > If indicating no, please state your reservations with the
> > > > > document.  If
> > > > > yes, please also feel free to provide comments you'd like to see
> > > > > addressed once the document is a WG document.
> > > > > 
> > > > > The poll ends Oct 2.
> > > > > 
> > > > > Thanks,
> > > > > 
> > > > > Lou (and Kent)
> > > > > 
> > > > > _______________________________________________
> > > > > netmod mailing list
> > > > > netmod@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > 
> > > > -- 
> > > > Ladislav Lhotka
> > > > Head, CZ.NIC Labs
> > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > 
> > > > _______________________________________________
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Tue Sep 19 07:21:14 2017
Return-Path: 
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 D50B113219B for ; Tue, 19 Sep 2017 07:21:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoBvdbF-JC0w for ; Tue, 19 Sep 2017 07:21:03 -0700 (PDT)
Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (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 E10AD13318C for ; Tue, 19 Sep 2017 07:21:02 -0700 (PDT)
Received: from cmgw3 (unknown [10.0.90.84]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id 31D011E0A3B for ; Tue, 19 Sep 2017 08:20:57 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with  id BSLt1w00q2SSUrH01SLwYl; Tue, 19 Sep 2017 08:20:57 -0600
X-Authority-Analysis: v=2.2 cv=K/VSJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=2JCJgTwv5E4A:10 a=wU2YTnxGAAAA:8 a=AUd_NHdVAAAA:8 a=fp591vAULOXga0goXgIA:9 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: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=F4fTWPV733Gp4MKjI33ZybzYFiP0k9TOwhrwCUPOsVw=; b=s4haNJBxbC8yX/RwaltWHZxiq7 5T1OAUasfiV0uYEPgA29S1k/2qAre+C5ct5AgbUtAiZbr2aG9FTju3G3Y5XS4LPFxoMV5v/QBDGBb vILvxmyuTBcziiRErojyR6gXj;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:47876 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1duJOP-001XO0-BM; Tue, 19 Sep 2017 08:20:53 -0600
To: Martin Bjorklund 
Cc: rwilton@cisco.com, netmod@ietf.org
References:  <20170919.132947.358857445863848356.mbj@tail-f.com> <990b8722-7a48-46ce-3f5d-96bc5cb66075@labn.net> <20170919.154238.1738748131929616921.mbj@tail-f.com>
From: Lou Berger 
Message-ID: 
Date: Tue, 19 Sep 2017 10:20:51 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170919.154238.1738748131929616921.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1duJOP-001XO0-BM
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:47876
X-Source-Auth: lberger@labn.net
X-Email-Count: 4
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Sep 2017 14:21:11 -0000

On 9/19/2017 9:42 AM, Martin Bjorklund wrote:
> Lou Berger  wrote:
>>
>> On 9/19/2017 7:29 AM, Martin Bjorklund wrote:
>>> Lou Berger  wrote:
>>>> Martin,
>>>>
>>>> Speaking as a contributor:
>>>>
>>>>
>>>> On 9/15/2017 7:40 AM, Martin Bjorklund wrote:
>>>>> Robert Wilton  wrote:
>>>>>> On 15/09/2017 11:21, Ladislav Lhotka wrote:
>>>>>>> Andy Bierman píše v Čt 14. 09. 2017 v 08:43 -0700:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>>
>>>>>>>> Actually I liked the early pyang output that was concise and easy to
>>>>>>>> remember.
>>>>>>>> The current format gets very cluttered and there are too many little
>>>>>>>> symbols
>>>>>>>> to remember them all.
>>>>>>> I agree.
>>>>> Me too.  The current draft adds three new magic symbols: "mp" "@" and
>>>>> "/".
>>>>>
>>>>> "mp" is for a mount point, and it can be generated directly from the
>>>>> YANG modules.
>>>>>
>>>>> Directly under a "mp", "/" and "@" are used to indicate that a node is mounted
>>>>> or available through a parent reference, respectively.
>>>>>
>>>>> I actually question the usability of "/" and "@".  
>>>> I agree that / and @ are something new, and enabled by schema mount. 
>>>> There have been repeated comments in the RTG WG that there needs to be
>>>> some way for vendors to convey what they have implemented with Schema
>>>> mount
>>> If that's the requirement, using the tree diagram is probably not the
>>> best way.  The tree diagram is intended to provide an overview of a
>>> given (set of) YANG module(s).
>>>
>>> A perhaps better way to convey the information is to create a file
>>> with an instantiated /schema-mounts tree.
>> using what syntax?  JSON and XML really isn't that easy for the (human)
>> reader to parse.
> Either JSON or XML.
This is fine for code, less so for humans.  We include both in the NI
draft, the tree provides a quick overview, the JSON provides the details. 

>
>>>> and this is one way to help convey (a) what is expected of server
>>>> implementors and (b) what client implementors should expect.
>>>>
>>>    Hence the
>>>> current draft text:
>>>>
>>>>   In describing the intended use of a module containing a mount point,
>>>>    it is helpful to show how the mount point would look with mounted
>>>>    modules.
>>>>
>>>> The whole point of trees is to facilitate understanding for those who
>>>> are less familiar with a model than the authors, and IMO that's the
>>>> paramount perspective in this discussion.
>>> Fully agree!  I would say that we have to make sure that the diagrams
>>> can be understood by people less familiar with the technology than the
>>> authors.  Mixing schema and instance data does not help here.
>> Can you propose an alternative?
> As I have written before, I think the "/" is not needed, so I would
> remove that.  I would also not list the nodes from "parent-references"
> in the same tree ouput.  It is not clear to me that this level of
> detail is needed in the tree, and - as noted before - it isn't even
> correct to list e.g. "interfaces" when the parent-reference in fact
> selects a single interface.
>
>> The routing WG participants seem to
>> find these useful, we can also ask there for broader input if you'd like.
> One approach is to add the union of eveything that some people find
> useful.  In the end we have to look for WG consensus.  Several people
> have said that they prefer a less cluttered format.
In the context of listing enums...

>
>>>>> Since a parent
>>>>> reference can be very specific, e.g. one specific interface, it isn't
>>>>> really accurate to show:
>>>>>
>>>>>                   +--mp vrf-root
>>>>>                      +--rw rt:routing/
>>>>>                      |  ...
>>>>>                      +--ro if:interfaces@
>>>> This is just a conditional and we have precedent on how to handle
>>>> conditional representation.   
>>>>
>>>>> And the trailing "/" on rt:routing doesn't add any information we
>>>>> don't already know.  Since vrf-root is a mount point, it follows that
>>>>> its children are mounted.
>>>> The issue is a bit more complex when considering some real use cases,
>>>> particularity when parent references and augmentations are used.  For
>>>> example consider the following *without* the use / or @:
>>>>
>>>> module: ietf-network-instance
>>>>   +--rw network-instances
>>>>      +--rw network-instance* [name]
>>>>         | ...
>>>>         +--rw (root-type)
>>>>            +--:(vrf-root)
>>>>               +--mp vrf-root
>>>>                  +--ro rt:routing-state
>>>>                  |  +--ro router-id?                 yang:dotted-quad
>>>>                  |  +--ro control-plane-protocols
>>>>                  |     +--ro control-plane-protocol* [type name]
>>>>                  |        +--ro ospf:ospf
>>>>                  |           +--ro instance* [af]
>>>>                  +--rw rt:routing
>>>>                  |  +--rw router-id?                 yang:dotted-quad
>>>>                  |  +--rw control-plane-protocols
>>>>                  |     +--rw control-plane-protocol* [type name]
>>>>                  |     +--rw ospf:ospf
>>>>                  |        +--rw instance* [af]
>>>>                  |           +--rw areas
>>>>                  |              +--rw area* [area-id]
>>>>                  |                 +--rw interfaces
>>>>                  |                    +--rw interface* [name]
>>>>                  |                       +--rw name if:interface-ref
>>>>                  |                       +--rw cost?   uint16
>>>>                  +--ro if:interfaces
>>>>                  |  ...
>>>>                  +--ro if:interfaces-state
>>>>                  |  ...
>>>>
>>>>
>>>> It's certainly not too hard to spot the top level mounts, but it is
>>>> impossible to distinguish the parent references from the actual mounts. 
>>> My proposal would be to not even show the parent references in the
>>> diagram.  If we do that, the '/' is not needed.
>>>
>>>> Further more, some mounts are hard to spot.  For example, notice ospf. 
>>>> Did you notice that it's a mount?
>>> This is actually not correct.  ospf is *not* a mount; it is an augment.
>>>
>> it's a mounted module that augments another mounted module.
> But why would it have a "/" just b/c it is augmented, when its sibling
> 'control-plan-protocol' doesn't have the "/"?  What addition info does
> the "/" convey?
That it is a (sub)tree that is present due to a mounted module.

Lou

>
>
> /martin


From nobody Tue Sep 19 07:22:32 2017
Return-Path: 
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 1FBAB134226 for ; Tue, 19 Sep 2017 07:22:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level: 
X-Spam-Status: No, score=-1.4 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_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQQYWrTG_Xen for ; Tue, 19 Sep 2017 07:22:23 -0700 (PDT)
Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (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 C4ED61331C2 for ; Tue, 19 Sep 2017 07:22:23 -0700 (PDT)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id 7F6C61E095A for ; Tue, 19 Sep 2017 08:22:23 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id BSNK1w00G2SSUrH01SNNNU; Tue, 19 Sep 2017 08:22:23 -0600
X-Authority-Analysis: v=2.2 cv=K4VSJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=2JCJgTwv5E4A:10 a=AUd_NHdVAAAA:8 a=wU2YTnxGAAAA:8 a=3zw6wJjOMeqJ6GBKg9cA:9 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: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=ViglIRa5NusWjBDDystQMZRlMzQmORv/m5RZQnPfUtI=; b=rcYTw6eqp3hHsoNoR1/ILfC0h6 wQiV3HTtZpU0kP63WGvMDz9WCJuK2TjClSKiPxv1PXLI0MXtC3nqhVSGr3NIa4fM/Dy8wpb+McMv6 Sg5PpxlUM0vWPLUHwSNEqpSm7;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:47886 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1duJPn-001Xd1-D7; Tue, 19 Sep 2017 08:22:19 -0600
To: Robert Wilton , Martin Bjorklund 
Cc: netmod@ietf.org
References: <20170919.132947.358857445863848356.mbj@tail-f.com> <990b8722-7a48-46ce-3f5d-96bc5cb66075@labn.net> <3734864d-9b27-7f61-c638-fd7c656c3692@cisco.com> <20170919.154728.285206235172744617.mbj@tail-f.com> <4f17fbca-6282-6b27-b390-9b85779e96da@cisco.com>
From: Lou Berger 
Message-ID: 
Date: Tue, 19 Sep 2017 10:22:16 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <4f17fbca-6282-6b27-b390-9b85779e96da@cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1duJPn-001Xd1-D7
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:47886
X-Source-Auth: lberger@labn.net
X-Email-Count: 7
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Sep 2017 14:22:28 -0000

On 9/19/2017 9:55 AM, Robert Wilton wrote:
>
> On 19/09/2017 14:47, Martin Bjorklund wrote:
>> Robert Wilton  wrote:
>>> On 19/09/2017 14:28, Lou Berger wrote:
>>>> On 9/19/2017 7:29 AM, Martin Bjorklund wrote:
>>>>> Lou Berger  wrote:
>>>>>> Martin,
>>>>>>
>>>>>> Speaking as a contributor:
>>>>>>
>>>>>>
>>>>>> On 9/15/2017 7:40 AM, Martin Bjorklund wrote:
>>>>>>> Robert Wilton  wrote:
>>>>>>>> On 15/09/2017 11:21, Ladislav Lhotka wrote:
>>>>>>>>> Andy Bierman píše v Čt 14. 09. 2017 v 08:43 -0700:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Actually I liked the early pyang output that was concise and easy to
>>>>>>>>>> remember.
>>>>>>>>>> The current format gets very cluttered and there are too many little
>>>>>>>>>> symbols
>>>>>>>>>> to remember them all.
>>>>>>>>> I agree.
>>>>>>> Me too.  The current draft adds three new magic symbols: "mp" "@" and
>>>>>>> "/".
>>>>>>>
>>>>>>> "mp" is for a mount point, and it can be generated directly from the
>>>>>>> YANG modules.
>>>>>>>
>>>>>>> Directly under a "mp", "/" and "@" are used to indicate that a node is
>>>>>>> mounted
>>>>>>> or available through a parent reference, respectively.
>>>>>>>
>>>>>>> I actually question the usability of "/" and "@".
>>>>>> I agree that / and @ are something new, and enabled by schema mount.
>>>>>> There have been repeated comments in the RTG WG that there needs to be
>>>>>> some way for vendors to convey what they have implemented with Schema
>>>>>> mount
>>>>> If that's the requirement, using the tree diagram is probably not the
>>>>> best way.  The tree diagram is intended to provide an overview of a
>>>>> given (set of) YANG module(s).
>>>>>
>>>>> A perhaps better way to convey the information is to create a file
>>>>> with an instantiated /schema-mounts tree.
>>>> using what syntax?  JSON and XML really isn't that easy for the
>>>> (human)
>>>> reader to parse.
>>> Perhaps there needs to be multiple versions of the generated tree
>>> output?
>>>
>>> 1) A normative tree diagram that shows the structure of the model.
>>> 2) A subsequent example that demonstrates what it looks like with the
>>> schema mounted modules.  Within the confines of a text document, the
>>> tree format still seems like a reasonable way to illustrate this, and
>>> I would say it is preferable to the verbosity of JSON or XML.
>>>
>>> I note that RFC 8022 includes an overview tree model in section 4 with
>>> some branches pruned, and then the complete representation in an
>>> appendix, which seems like a pragmatic approach.
>> Sure, but the question is about what special symbols we define.  Do we
>> need the extra symbols "/" and "@", and do we agree on what they mean?
> If we agree that tree style output is OK to illustrate the use of schema 
> mount, then I think that draft-ietf-netmod-yang-tree-diagrams could 
> define them, but indicate that they are only used to illustrate how 
> schema mount is used, and would not be seen in a regular YANG tree 
> diagram illustrating the structure of a YANG module.  

This seems like a reasonable compromise to me, and not a major change to
the draft.

Martin, what do you think?

Lou

> The alternative 
> might be that the RFCs that uses them defines what '/' and '@' mean for 
> that specific example.
>
> As for what the precise definition of '/' and '@' should be, I'm not 
> sure.  I think that you and Lou have a better handle on that ;-)
>
> Thanks,
> Rob
>
>
>>
>> /martin
>


From nobody Tue Sep 19 07:26:04 2017
Return-Path: 
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 1DF8913422F for ; Tue, 19 Sep 2017 07:26:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 I-ogM6Kq6rB5 for ; Tue, 19 Sep 2017 07:26:01 -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 80E44134226 for ; Tue, 19 Sep 2017 07:26:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5871; q=dns/txt; s=iport; t=1505831160; x=1507040760; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=cU1Q3bNEdRelSxjmcpTzmqj9h6H+9b+SJNvoM78SN3E=; b=GNYISLlRgU36W+oPU1rxTv+WgWP0/FjU8V+bySqEs4HTlx5Tb0xss12I sM903pssy4ZHJsPi9T204OuZWI9kFgnG/yGQYFYI5s2Vct803oS0IITQi qrqM4/Lgvk9FCTGICvRRBEND8OiecfSX0XSSkcXuZm0UbIbVgV8LlE41o s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CJAQAjKMFZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD5uJ4N1ixSQTCuWJA6CBAoYC4RJTwKFGhYBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQEBAQIBAQEhBAsBBTYbCQISBgICJgICJyIOBgEMBgIBAYonCBCNQJ1mgW06i?= =?us-ascii?q?yMBAQEBAQEBAQEBAQEBAQEBAQEBGgWBDoIdg1KBYyuCfYRFARIBgzKCYAWKBYc?= =?us-ascii?q?ugWiNcZRWghOFaoNahyONYIdXgTkmATCBAgsyIQgcFUmHHT82hjuCMgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.42,418,1500940800"; d="scan'208";a="657584596"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Sep 2017 14:25:58 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v8JEPwcL014138; Tue, 19 Sep 2017 14:25:58 GMT
To: Ladislav Lhotka , netmod@ietf.org
References: <393d3f20-98e3-b4de-e2d7-d627de59ac1f@labn.net> <1505814417.5445.14.camel@nic.cz> <20170919.115915.1668734288988659917.mbj@tail-f.com> <87shfistam.fsf@nic.cz> <75221540-d587-cd90-60ab-7cf6a8ff5cd4@cisco.com> <1505830045.5445.47.camel@nic.cz>
From: Robert Wilton 
Message-ID: <4ec007bc-6eb6-38f9-562e-ce9d0b4e1c00@cisco.com>
Date: Tue, 19 Sep 2017 15:25:57 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <1505830045.5445.47.camel@nic.cz>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Sep 2017 14:26:03 -0000

On 19/09/2017 15:07, Ladislav Lhotka wrote:
> Robert Wilton píše v Út 19. 09. 2017 v 14:49 +0100:
>> Hi Lada,
>>
>>
>> On 19/09/2017 14:37, Ladislav Lhotka wrote:
>>> Martin Bjorklund  writes:
>>>
>>>> Ladislav Lhotka  wrote:
>>>>> Hi,
>>>>>
>>>>> I support the adoption but I propose two conceptual changes:
>>>>>
>>>>> 1. Introduce a new module name and namespace so that it is not
>>>>> necessary to carry along the deprecated baggage. If readability is
>>>>> the primary concern, this is IMO the way to go. Instead of
>>>>> "ietf-ip-2", I'd suggest something like "ietf- ip-nmda".
>>>>>
>>>>> 2. Avoid obsoleting RFC 7277. I believe the old modules may continue
>>>>> to be used
>>>>> in areas where NMDA is an overkill, such as open source home
>>>>> routers.
>>>> Why wouldn't NMDA be appropriate in an open source home router?  Note
>>>> that the new model really just have a single tree instead of two
>>>> trees, so the data that needs to be instrumented is more or less the
>>>> same.
>>> It is quite likely that some parts of the data models will be
>>> implemented only as configuration but not state data. In the "old style"
>>> modules it is easy to add a deviation for the node(s) under -state but
>>> in NMDA style this is not possible because we only have one node.
>> The new YANG library allows different sets of modules to be available
>> for  datastores vs .   The operational
>> datastore can also have different features supported and different
>> deviations vs the conventional datastores.
> OK, I missed the 7895bis draft, sorry. Then there could be differences in
> mandatory/optional (e.g. a node is optional in configuration but mandatory in
> state data) or the data type of a leaf can differ. How can these be handled?
If the data type of the leaf can differ, then normally this should be 
modeled as two separate leaves.  Do you have a concrete example of this?

If some data is mandatory in config, but not necessarily mandatory in 
 then normally it can be marked as mandatory true, since 
optional is allowed to violate this constraint if necessary, but 
implementations would generally be expected to conform to the constraint 
if possible.

For the reverse case, we can't express that.  I think that you would 
have to leave out the "mandatory: true" constraint.  Again, can you 
provide a concrete example of this please?  That makes it a bit easier 
to reason about.

Thanks,
Rob


>
> Lada
>
>> So, the device can make the same deviations to remove the state leaves
>> from .  Or if they don't want to support the module in
>> operational at all then a device could just list it as being supported
>> in the conventional datastores and not .
>>
>>> There are subtle differences in the schemas for configuration and state
>>> data that the NMDA concept doesn't address. If you want another example,
>>> ietf-routing-2 has the "router-id" leaf that is conditional via the
>>> "router-id" feature. If this feature is not supported, router-id cannot
>>> be explicitly configured (it is assigned by the system) but in state data
>>> "router-id" needs IMO be present in any case. But the if-feature
>>> isn't able to differentiate between configuration and state data if
>>> there is only one node for both.
>> The new YANG library also supports this:
>>
>> The "router-id" feature would be disabled for the conventional
>> datastores, but enabled for .
>>
>>>> In fact, if we claim that the new architecture is not appropriate for
>>>> some devices I think we have failed, especially if the conclusion is
>>>> that we need to maintain two versions of all modules going forward.
>>> I am not asking for this but, on the other hand, if NMDA versions used a new
>>> module name and namespace (my item #1, which is what ietf-routing-2
>>> does), then I don't see any pressing need for obsoleting the old style
>>> modules.
>> I think that creating a "-2" versions of these models at this time might
>> be a mistake.  I actually think that the "deprecate state leaves" ->
>> "obsolete state leaves" -> "delete state leaves" path is a better choice.
>>
>> Thanks,
>> Rob
>>
>>
>>> Lada
>>>
>>>> /martin
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> NMDA
>>>>> implementors should be aware of the new modules but there is no need to
>>>>> eradicate the old data models.
>>>>>
>>>>> #2 applies also to other modules for which the NMDA version is underway.
>>>>>
>>>>> Lada
>>>>>
>>>>> PS. The subject is wrong, it shoud be -rfc7277bis-
>>>>>    
>>>>> Lou Berger píše v Po 18. 09. 2017 v 10:33 -0400:
>>>>>> All,
>>>>>>
>>>>>> This is start of a two week poll on making
>>>>>> draft-bjorklund-netmod-rfc7227bis-00 a working group document. Please
>>>>>> send email to the list indicating "yes/support" or "no/do not
>>>>>> support".
>>>>>> If indicating no, please state your reservations with the
>>>>>> document.  If
>>>>>> yes, please also feel free to provide comments you'd like to see
>>>>>> addressed once the document is a WG document.
>>>>>>
>>>>>> The poll ends Oct 2.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Lou (and Kent)
>>>>>>
>>>>>> _______________________________________________
>>>>>> netmod mailing list
>>>>>> netmod@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>> -- 
>>>>> Ladislav Lhotka
>>>>> Head, CZ.NIC Labs
>>>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>>>
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> netmod@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod


From nobody Tue Sep 19 08:21:01 2017
Return-Path: 
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 86D2F133020 for ; Tue, 19 Sep 2017 08:20:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqVEMAxxVbon for ; Tue, 19 Sep 2017 08:20:57 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 811351321C9 for ; Tue, 19 Sep 2017 08:20:57 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 573E069A; Tue, 19 Sep 2017 17:20:56 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id KxJQlHFlBiCV; Tue, 19 Sep 2017 17:20:49 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 19 Sep 2017 17:20:56 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 373B3200EC; Tue, 19 Sep 2017 17:20:56 +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 bhlSGgsQPOgM; Tue, 19 Sep 2017 17:20:56 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A34D4200EA; Tue, 19 Sep 2017 17:20:55 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 9FD39410D163; Tue, 19 Sep 2017 17:20:55 +0200 (CEST)
Date: Tue, 19 Sep 2017 17:20:55 +0200
From: Juergen Schoenwaelder 
To: Lou Berger 
Cc: Martin Bjorklund , netmod@ietf.org
Message-ID: <20170919152055.qotlamp3ej3vy4j4@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Lou Berger , Martin Bjorklund , netmod@ietf.org
References: <5b512435-cebd-3534-eeb3-649154450d81@cisco.com> <20170915.134007.262763963470255554.mbj@tail-f.com>  <20170919.132947.358857445863848356.mbj@tail-f.com> <990b8722-7a48-46ce-3f5d-96bc5cb66075@labn.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <990b8722-7a48-46ce-3f5d-96bc5cb66075@labn.net>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Sep 2017 15:20:59 -0000

[...]

I prefer that the (schema) tree format is restricted to show the
schema tree.

If a tree format is also needed for data trees, then this really is a
different tree format. It may use a similar base notation but what it
shows is fundamentally different.

/js

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


From nobody Tue Sep 19 08:22:31 2017
Return-Path: 
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 BC5151321C9; Tue, 19 Sep 2017 08:22:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 AC990XxGu03L; Tue, 19 Sep 2017 08:22:28 -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 6920F133020; Tue, 19 Sep 2017 08:22:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9454; q=dns/txt; s=iport; t=1505834547; x=1507044147; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=yhQy2Xyx9BwMP0x3EvKatG/jVM0JmVhJJTzNHlRBnRw=; b=NuEOqtrhsWWdmTQ+O+b7mkne5zxFYfveGUZaRM3EOB74mlrO7Ti67Gpd OqvX1Nws2zUMIh8kwd9/sJZpOpOvkyYC8edCxrF3gSDKqBFcxpPwcZHQe wJWo8QkvuT4ugQNPJT7QCFb4Pv2CE/4TSPvxTFC2Mh8oNRYfWtlH5NybJ 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CHAQCFNcFZ/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhSwng3WLFJBMK3mVKw6CBAqFOwKFHBYBAgEBAQEBAQFrKIUZAQU?= =?us-ascii?q?jDwEFOgcQCw4CAgYCAhESAwICRgMOBg0GAgEBF4oYqwqCJ4shAQEBAQEBAQECA?= =?us-ascii?q?QEBAQEBASGBDoIdg1KBYyuCSDWEMy0CVYJUgmAFoQyUVoITiUQkhn+KAYNfh1e?= =?us-ascii?q?BOSYOI4ENMiEIHBWHZj82hiwCBR8HghQBAQE?=
X-IronPort-AV: E=Sophos;i="5.42,418,1500940800"; d="scan'208";a="697311567"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Sep 2017 15:22:25 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v8JFMOV4026997; Tue, 19 Sep 2017 15:22:24 GMT
To: Martin Bjorklund 
Cc: andy@yumaworks.com, j.schoenwaelder@jacobs-university.de, ietfc@btconnect.com, lberger@labn.net, netmod@ietf.org, netmod-chairs@ietf.org, draft-ietf-netmod-revised-datastores@ietf.org
References: <20170918.200734.1805388289423863575.mbj@tail-f.com>  <99b9a2c6-4bb4-121f-0cba-925cefe09712@cisco.com> <20170919.115559.1080249872764998055.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: 
Date: Tue, 19 Sep 2017 16:22:24 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170919.115559.1080249872764998055.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod]  vs 
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Sep 2017 15:22:30 -0000

On 19/09/2017 10:55, Martin Bjorklund wrote:
> Robert Wilton  wrote:
>>
>> On 18/09/2017 19:25, Andy Bierman wrote:
>>>
>>> On Mon, Sep 18, 2017 at 11:07 AM, Martin Bjorklund >> > wrote:
>>>
>>>      Juergen Schoenwaelder >>      > wrote:
>>>      > On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert Wilton wrote:
>>>      > >
>>>      > > > No.  I do not agree that the MUST in RFC 7950 can be removed.
>>>      > > > I do not agree the architecture should update YANG at all.
>>>      > > OK.
>>>      >
>>>      > I am with Andy here.  has always had the requirement to be
>>>      > valid and we are not supposed to change that. Mechanisms for
>>>      inactive
>>>      > configuration or templating must be designed to be backwards
>>>      compatible
>>>      > I think.
>>>
>>>      Ok.  If we keep the requirement that  in itself must be
>>>      valid, it just restricts the usefulness/expressiveness of inactive and
>>>      template mechanisms, but it might be ok.
>>>
>>>      I think that even w/o this requirement, the observable behavior for a
>>>      client can be backwards compatible.  For example, suppose we have an
>>>      inactive access control rule that refers to a non-existing
>>>      interface in
>>>      .  If a client that doesn't know anything about inactive asks
>>>      for the contents of , our implementation removes the inactive
>>>      nodes from the reply to the client.  Only a client that opts-in to
>>>      inactive will receive a reply with things that looks invalid if you
>>>      don't take the inactive annotation into account.
>>>
>>>
>>>
>>> There are many ways that validation can fail because inactive nodes
>>> are present,
>>> and considered part of the validation.
>>>
>>> e,g, min-elements, max-elements, mandatory, unique.
>>>
>>> I think we all agree that validation on the enabled nodes is supposed
>>> to continue to work.
> Yes.
>
>>> Here is an attempt at a backwards-compatible solution:
>>>
>>> 1) current  and  responses only include enabled
>>> nodes.
>>> 2) old-style  operations do not alter inactive nodes
>>> 3) NMDA clients use , not  or .  These
>>> responses
>>>      include enabled and disabled nodes, so validation does not apply
>>> for 
>>> 4) new style  (i.e.  parameter used) can alter
>>> any type of data node
>> //I think that inactive should always be an optional extension.  Not
>> everything needs the additional complexity.
>>
>> Hence rather than tying this function to specific NETCONF operations,
>> I would suggest that there should be an extra parameter (like for
>> with-defaults) to allow a client to indicate to the server that a get
>> or edit request is using the "with-inactive" extension.
>> 1) The server should also have a capability (or perhaps a leaf defined
>> in YANG library) to indicate that it supports inactive configuration.
>> 2) If a client doesn't use the extra "with-inactive" parameter during
>> a get request then only active nodes are returned.
>> 3) If a client doesn't use the extra "with-inactive" parameter during
>> an edit-data request then the request cannot include an extra inactive
>> meta-data.  The request is processed in a way that is equivalent to an
>> existing NETCONF implementation, but it may unknowingly remove some
>> inactive configuration (e.g. via a replace or remove operation on an
>> inactive node).  Operations like create, delete, none, replace should
>> all treat an inactive target node the same way as in the node doesn't
>> exist (e.g. delete on an inactive node would return a "data-missing"
>> error), this ensures that the behaviour that an unaware client
>> observes is the same as the existing behaviour that it would expect
>> from a regular 6241 compliant NETCONF implementation.
>> 4) It a client makes a get request including the "with-inactive"
>> parameter then they also get the inactive nodes as well, marked with a
>> meta-data annotation.
>> 5) If a client makes an edit request including the "with-inactive"
>> parameter, then the inactive meta-data annotation can be used to label
>> inactive nodes.  Inactive nodes are regarded as regular data nodes for
>> create/delete/replace/none operation error checking.
>>
>> I think that this approach is similar (perhaps even the same) as
>> Martin described.
> This is indeed how our implementation works (except I think we don't
> do 5; if the client sends an "inactive" attribute it doesn't have to
> also send with-inactive).
>
>>> Note that the YANG MUST rule still applies, because validation is only
>>> done on enabled nodes.
>>> It is only the response message representations that cannot be
>>> validated, not the contents
>>> of  on a server.
> So the question is how we can make sure that the text in the NMDA
> draft covers this yet-to-be-defined feature w/o having to define it
> now?  We thought that the current text was sufficient, but do we have
> to make any changes to it?
1) Do we also need to illustrate a similar proof of concept templating 
implementation to show that templating could work whilst keeping running 
valid?  I would prefer that this is just deferred to whichever draft 
defines templating.

2) I think that we need to reach a decision as to whether the NMDA 
architecture needs to explicitly state that  is always valid, 
or if that can be left to the existing statement in 7950.  My thinking 
is that if the conclusion is that  must always be valid, then 
it would be helpful to explicitly state it the descriptions of both 
 and  in the NMDA architecture.

3) I think that it would be useful to further refine my previous 
proposed text for intended, particularly rewriting the text on 
validation.  This should hopefully also address Balazs' concern about 
default values be included in validation.



4.4.  The Intended Configuration Datastore ()

    The intended configuration datastore () is a read-only
    configuration datastore.  It is tightly coupled to .  When
    data is written to , the data that is to be validated is
    also conceptually written to . Validation is performed on
    the contents of .

    For simple implementations,  and  are identical.

     does not persist across reboots; its relationship with
     makes that unnecessary.

    Currently there are no standard mechanisms defined that affect
     so that it would have different contents than ,
    but this architecture allows for such mechanisms to be defined.

    One example of such a mechanism is support for marking nodes as
    inactive in .  Inactive nodes are not copied to ,
    and are thus not taken into account when validating the
    configuration.

    Another example is support for templates.  Templates are expanded
    when copied into , and the expanded result is validated.




4.1.4.  The Intended Configuration Datastore ()

    The intended configuration datastore () is a read-only
    configuration datastore.  It represents the configuration after all
    configuration transformations to  are performed (e.g.
    template expansion, removal of inactive configuration), and is the
    configuration that the system attempts to apply.

     is tightly coupled to . Whenever data is written
    to , then  is also immediately updated by
    performing all necessary transformations to the contents of 
    and then  is validated.

     may also be updated independently of  (e.g., if
    one of the configuration transformations is changed), but 
    must always be a 'valid configuration data tree' as defined in
    Section 8.1 of [RFC7950].

    For simple implementations,  and  are identical.

    The contents of  is also related to the 'config true'
    subset of , and hence a client can determine to what
    extent the intended configuration is currently in use by checking
    whether the contents of  also appears in .

     does not persist across reboots; its relationship with
     makes that unnecessary.

    Currently there are no standard mechanisms defined that affect
     so that it would have different contents than ,
    but this architecture allows for such mechanisms to be defined.

    One example of such a mechanism is support for marking nodes as
    inactive in .  Inactive nodes are not copied to .
    A second example is support for templates, which can perform
    transformations on the configuration from  to the
    configuration written to .



Thanks,
Rob


>
>
> /martin
> .
>


From nobody Tue Sep 19 08:42:38 2017
Return-Path: 
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 C97D0134294; Tue, 19 Sep 2017 08:42:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 mCnBaBgwq_OT; Tue, 19 Sep 2017 08:42:36 -0700 (PDT)
Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16197133020; Tue, 19 Sep 2017 08:42:36 -0700 (PDT)
Received: by mail-pf0-x244.google.com with SMTP id i23so4969pfi.2; Tue, 19 Sep 2017 08:42:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Az2evFpB7XQy7MIQp81ijOvnLuAJtD/cLLiPDq80hMM=; b=emndimt5o771ssxqO778N9BFAwS1FVWTGRlxn6HqNPmGIOerRSYMbVwV3jPpQ8223L //JHA1U+6VOGVNVKWYgoivqyeEsAt6RcdQiUkIRnnBJ2Og023DQCiLC9DnXgQ/Q0OS/y JAOkesBcHX36C1JqeTp+DIPjDR0YshqNWqdZfNY+sN+lftg2MzBofPzM9fID8X/BhPdf uZnFmDzVUrYBY8xNsqeEHcknK9Zy6Tg+FATSO9vjAVADysTZHjUwH3kFxV4Ze76m9yf8 0cRbeYz2SBrqW7A6d7+Fr7+nzjUi6YeE3pbgCwn3sQUz9v4Om2y11OLlbnkZfPMwF9Jk ibrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Az2evFpB7XQy7MIQp81ijOvnLuAJtD/cLLiPDq80hMM=; b=Ewpm+QR7yuln7RosnuTiQKN/HY+b0o+K2tuvHY5I/0lB8jhqW3cOfavAPfFOAo0dIf ZexocnMGXLvfrCA/CjMzyxxuQbXb83EohOW4x4R+ZrFkZtyzU8FoclmfckRLFG5FmlK6 PspkGpl3rxsXiwNSfojM6wgs3YUFZhiY0dznIPwWuxluPN/14wN3tHy3s1KzpwgH+OwS +Y4A4A/0wfN3mxcl5tz+gMbY9NpKdi8dAuScagds/6cXa3tFdH1xbXYyAMH/Nni0BwWw DOBVn2ArJM7Jz57RH/Dc23ytRb9u5vIw22HzADEYffxGslRvJhOlLD5FgQZN1HahF73f oIXQ==
X-Gm-Message-State: AHPjjUh9CJFVG3MtaW+PrTKl22DOlDf4OQHfrFa3qINR+XiIOHveu9ua U+kGwNInpPHhvsRM5Cj/rqLOw/dn
X-Google-Smtp-Source: AOwi7QCrqPM/n05ZXyMi9lykoxVJpjN5G44MP7t8FLff/YYFq5ZrrQDwvMGVzY19gvTITnGKIcpFUA==
X-Received: by 10.98.95.1 with SMTP id t1mr1661892pfb.217.1505835755695; Tue, 19 Sep 2017 08:42:35 -0700 (PDT)
Received: from ?IPv6:2001:420:28d:1250:7476:800b:61bd:266b? ([2001:420:28d:1250:7476:800b:61bd:266b]) by smtp.gmail.com with ESMTPSA id u77sm4550361pfk.87.2017.09.19.08.42.34 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 19 Sep 2017 08:42:34 -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: 
Date: Tue, 19 Sep 2017 08:43:33 -0700
Cc: NetMod WG , NetMod WG Chairs 
Content-Transfer-Encoding: 7bit
Message-Id: 
References: 
To: Lou Berger 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7223bis-00 (resend)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Sep 2017 15:42:38 -0000

Support the adoption.

> On Sep 18, 2017, at 11:29 AM, Lou Berger  wrote:
> 
> All,
> 
> This is start of a two week poll on making
> draft-bjorklund-netmod-rfc7223bis-00 a working group document. Please
> send email to the list indicating "yes/support" or "no/do not support".
> If indicating no, please state your reservations with the document.  If
> yes, please also feel free to provide comments you'd like to see
> addressed once the document is a WG document.
> 
> The poll ends Oct 2.
> 
> Thanks,
> 
> Lou (and Kent)
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanandani@gmail.com




From nobody Tue Sep 19 08:58:36 2017
Return-Path: 
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 35F07133200 for ; Tue, 19 Sep 2017 08:58:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 RUBuZ-iNQRDY for ; Tue, 19 Sep 2017 08:58:33 -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 E5DB313303B for ; Tue, 19 Sep 2017 08:58:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11543; q=dns/txt; s=iport; t=1505836713; x=1507046313; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=Xqw+uwu5/xLYpVe036Myk0WND1R0Gp86GVuU7lhaa4U=; b=MkOrkDYJLXihdYLUXehaIz1hoR/7jNjAzTxRx8Ecpa64rdFBa5mgyFRY XVch3u+rmobzYjv66dtrQrfC/SQwUhcErNDTyw0vDl81Zj9fLbuXVSGsE FxFvMb10By6MqsL7u0ITK6kY9Z88k4HGTBxI+bzpsia+glXB9qkjCUbeN Y=;
X-IronPort-AV: E=Sophos;i="5.42,418,1500940800";  d="scan'208,217";a="657586968"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Sep 2017 15:58:31 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8JFwUp4028307; Tue, 19 Sep 2017 15:58:30 GMT
To: "Acee Lindem (acee)" , Lou Berger , Ladislav Lhotka , Yingzhen Qu , NetMod WG 
References: <7205a700-f00a-13f1-1941-46d578e38a27@labn.net> 
From: Robert Wilton 
Message-ID: <91a28bbc-0b1d-1907-36b9-501da31cdd42@cisco.com>
Date: Tue, 19 Sep 2017 16:58:30 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------C5D3CD0B2BEA22FA2AD21AB7"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Regarding IPR on draft-acee-netmod-rfc8022bis-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Sep 2017 15:58:35 -0000

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

I support adoption of this draft.

I have reviewed draft-acee-netmod-rfc8022bis-02, and ask that the 
following comments be considered after the document has been adopted:

1. Does the draft still require a normative reference to 6020? Given 
that the modules are all YANG revision 1.1 perhaps this isn't required 
any more?

2. In appendix D:
i) it would be better if the YANG library example was updated to match 
the model in YANG library bis (e.g. use a modules path rather than 
modules-state).
ii) I think that it should state that this is an example of the data 
that may be received by reading from the operational state datastore.
iii) In the example, the "interface-state" tree output should be merged 
in with "interfaces" so illustrate the combined NMDA view.

3. ipv6 prefix list.
When I had first looked at combining the existing RFC YANG modules to 
NMDA, I came up with a slightly different way of modelling IPv6 
prefixes, splitting "no-advertise-prefix-list" separately from the 
"advertised prefixes".

E.g. if your draft the tree output is:

       +--rw prefix-list
          +--rw prefix* [prefix-spec]
             +--rw prefix-spec           inet:ipv6-prefix
             +--rw (control-adv-prefixes)?
                +--:(no-advertise)
                |  +--rw no-advertise?         empty
                +--:(advertise)
                   +--rw valid-lifetime?       uint32
                   +--rw on-link-flag?         boolean
                   +--rw preferred-lifetime?   uint32
                   +--rw autonomous-flag?      boolean

Perhaps you could consider this structure instead (I can send you the 
actual YANG if it helps):

        +--rw no-advertise-prefix-list
        |  +--rw prefix* [prefix-spec]
        |     +--rw prefix-spec     inet:ipv6-prefix
        |     +--rw (control-adv-prefixes)?
        |        +--:(no-advertise)
        |           +--rw no-advertise?   empty
        +--rw prefix-list
           +--rw prefix* [prefix-spec]
              +--rw prefix-spec           inet:ipv6-prefix
              +--ro valid-lifetime?       uint32
              +--ro on-link-flag?         boolean
              +--ro preferred-lifetime?   uint32
              +--ro autonomous-flag?      boolean

Thanks,
Rob


On 18/09/2017 14:55, Acee Lindem (acee) wrote:
> As a co-author,
>
> No, I'm not aware of any IPR that applies to this draft.
>
>
> Thanks,
> Acee
>
> On 9/18/17, 9:48 AM, "Lou Berger"  wrote:
>
>> Authors, Contributors, WG,
>>
>> As part of the preparation for WG Last Call:
>>
>> Are you aware of any IPR that applies to drafts identified above?
>>
>> Please state either:
>>
>> "No, I'm not aware of any IPR that applies to this draft"
>> or
>> "Yes, I'm aware of IPR that applies to this draft"
>>
>> If so, has this IPR been disclosed in compliance with IETF IPR rules
>> (see RFCs 3669, 5378 and 8179 for more details)?
>>
>> If yes to the above, please state either:
>>
>> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
>> or
>> "No, the IPR has not been disclosed"
>>
>> If you answer no, please provide any additional details you think
>> appropriate.
>>
>> If you are listed as a document author or contributor please answer the
>> above by responding to this email regardless of whether or not you are
>> aware of any relevant IPR. This document will not advance to the next
>> stage until a response has been received from each author and listed
>> contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
>> TO LINES.
>>
>> If you are on the WG email list or attend WG meetings but are not listed
>> as an author or contributor, we remind you of your obligations under
>> the IETF IPR rules which encourages you to notify the IETF if you are
>> aware of IPR of others on an IETF contribution, or to refrain from
>> participating in any contribution or discussion related to your
>> undisclosed IPR. For more information, please see the RFCs listed above
>> and
>> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
>>
>> Thank you,
>> NetMod WG Chairs
>>
>> PS Please include all listed in the headers of this message in your
>> response.
>>
>>
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


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


  
    
  
  
    
I support adoption of this draft.

    
I have reviewed draft-acee-netmod-rfc8022bis-02, and ask that the
      following comments be considered after the document has been
      adopted:

    
1. Does the draft still require a normative reference to 6020? 
      Given that the modules are all YANG revision 1.1 perhaps this
      isn't required any more?

    

    
2. In appendix D:

      i) it would be better if the YANG library example was updated to
      match the model in YANG library bis (e.g. use a modules path
      rather than modules-state).

      ii) I think that it should state that this is an example of the
      data that may be received by reading from the operational state
      datastore.

      iii) In the example, the "interface-state" tree output should be
      merged in with "interfaces" so illustrate the combined NMDA view.

    
3. ipv6 prefix list.

      When I had first looked at combining the existing RFC YANG modules
      to NMDA, I came up with a slightly different way of modelling IPv6
      prefixes, splitting "no-advertise-prefix-list" separately from the
      "advertised prefixes".

    

    
E.g. if your draft the tree output is:

    
      +--rw prefix-list
         +--rw prefix* [prefix-spec]
            +--rw prefix-spec           inet:ipv6-prefix
            +--rw (control-adv-prefixes)?
               +--:(no-advertise)
               |  +--rw no-advertise?         empty
               +--:(advertise)
                  +--rw valid-lifetime?       uint32
                  +--rw on-link-flag?         boolean
                  +--rw preferred-lifetime?   uint32
                  +--rw autonomous-flag?      boolean

    
Perhaps you could consider this structure instead (I can send you
      the actual YANG if it helps):

    
       +--rw no-advertise-prefix-list

             |  +--rw prefix* [prefix-spec]

             |     +--rw prefix-spec     inet:ipv6-prefix

             |     +--rw (control-adv-prefixes)?

             |        +--:(no-advertise)

             |           +--rw no-advertise?   empty

             +--rw prefix-list

                +--rw prefix* [prefix-spec]

                   +--rw prefix-spec           inet:ipv6-prefix

                   +--ro valid-lifetime?       uint32

                   +--ro on-link-flag?         boolean

                   +--ro preferred-lifetime?   uint32

                   +--ro autonomous-flag?      boolean

    
Thanks,

      Rob

    


      

    
On 18/09/2017 14:55, Acee Lindem (acee)
      wrote:

    

    

      
As a co-author, 

No, I'm not aware of any IPR that applies to this draft.


Thanks,
Acee 

On 9/18/17, 9:48 AM, "Lou Berger" <lberger@labn.net> wrote:



      

        
Authors, Contributors, WG,

As part of the preparation for WG Last Call:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author and listed
contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
NetMod WG Chairs

PS Please include all listed in the headers of this message in your
response.





      

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



    

    

  


--------------C5D3CD0B2BEA22FA2AD21AB7--


From nobody Tue Sep 19 14:28:56 2017
Return-Path: 
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 067741343A8 for ; Tue, 19 Sep 2017 14:28:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level: 
X-Spam-Status: No, score=-4.7 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=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIlhWU8h6LcX for ; Tue, 19 Sep 2017 14:28:53 -0700 (PDT)
Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) (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 04FA4134390 for ; Tue, 19 Sep 2017 14:28:52 -0700 (PDT)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id 608F31E07A4 for ; Tue, 19 Sep 2017 15:28:52 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id BZUo1w00d2SSUrH01ZUrax; Tue, 19 Sep 2017 15:28:52 -0600
X-Authority-Analysis: v=2.2 cv=K4VSJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=xqWC_Br6kY4A:10 a=2JCJgTwv5E4A:10 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=0FD05c-RAAAA:8 a=wU2YTnxGAAAA:8 a=OUXY8nFuAAAA:8 a=AUd_NHdVAAAA:8 a=J_N6KFswAAAA:8 a=9qxNCY_qAAAA:8 a=mYPrF8hoAAAA:8 a=VNSexNVf58wTsYF8oRcA:9 a=QEXdDO2ut3YA:10 a=5NnwDaS9Sn41lf5ebk8A:9 a=n3BslyFRqc0A:10 a=QGevMSd5eboA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=l1rpMCqCXRGZwUSuRcM3:22 a=Yz9wTY_ffGCQnEDHKrcv:22 a=cAcMbU7R10T-QSRYIcO_:22 a=WeO-vB3rTBbpvfYpX9vN:22 a=A2X48xt2e1hG9NJDz63Y:22 a=SK_ViTGLvA2mnZZ8RFS2:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:To: References:Subject:Sender:Reply-To: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=Yg/F6Zo1xveWNgOLqpWgg2n9KJJHq+DzlqFQ64MOfT8=; b=nFekvd+KUm5np28O6fZlumfVyw pmUau7/d+bm2kAtG6rkh4Hi6hFegDBPfICVyzmfkx1vBpfWggBOZRqGXG1avUtwwGyJNzzmnvI0EE j1NZJcrJUNf3o0wlwe+gSgTgM;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:56390 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1duQ4W-002pZc-4c for netmod@ietf.org; Tue, 19 Sep 2017 15:28:48 -0600
References: <7456A0C8-E227-45E5-8EEF-655F5E989035@ericsson.com>
To: NetMod WG 
From: Lou Berger 
X-Forwarded-Message-Id: <7456A0C8-E227-45E5-8EEF-655F5E989035@ericsson.com>
Message-ID: <38da02b7-1699-beb4-3797-261cdef74b24@labn.net>
Date: Tue, 19 Sep 2017 17:28:46 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <7456A0C8-E227-45E5-8EEF-655F5E989035@ericsson.com>
Content-Type: multipart/mixed; boundary="------------63982BED3A89554ABF6FE3D1"
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1duQ4W-002pZc-4c
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:56390
X-Source-Auth: lberger@labn.net
X-Email-Count: 1
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: [netmod] Fwd: Broadband Forum NMDA Questions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Sep 2017 21:28:55 -0000

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

FYI - I don't see this yet at https://datatracker.ietf.org/liaison/



-------- Forwarded Message --------
Subject: 	Broadband Forum NMDA Questions
Date: 	Tue, 19 Sep 2017 21:25:21 +0000
From: 	David Sinicrope 
To: 	Lou Berger , Kent Watsen ,
Benoit Claise 
CC: 	Michael Fargano, Broadband Forum Technical Committee Chair
, David Sinicrope
, Sven Ooghe, BBF Common YANG Project
Stream Leader, , William Lupton, BBF Common YANG
Project Stream Leader, , Robin Mersh,
Broadband Forum CEO , Gabrielle Bond,
Broadband Forum Secretariat , Statements at
IETF , Liaisons at BBF 



Please find attached a liaison from Broadband Forum to the IETF NETMOD WG.

Please let me know if you have any questions or issues receiving this
liaison.

Please acknowledge successful receipt of the liaison via reply to this
email.

Thank you,

Dave Sinicrope

 


--------------63982BED3A89554ABF6FE3D1
Content-Type: application/pdf;
 name="LIAISE-83 - oLS to IETF NETMOD re NMDA (Network Management Datastore
 Architecture).final.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename*0="LIAISE-83 - oLS to IETF NETMOD re NMDA (Network Management D";
 filename*1="atastore Architecture).final.pdf"

JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVy
IC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHNXGuz3EYR/a5fISdes06wrPcjdrIhviHYxpDA
JQ7E+UC5TBUpDCSBn8T/5Iw05/TsShrJvuFRSXn3SjM9/Tzd05rVd+kX6XdpUbr/my7Phjbt
iy6r6/T7V+nz9K/p/Uc/FOnLH9J8/O+HlxidZ2U9/e2+1GWb9c0wpB3mFWXy8nX6yXXaTOP9
x/Xr9P71NRZJr/+UHm/dTa+/TT+9Hpc+J9aVaZc3WdWmL18ncTJfp8d37oKXIj2+6z7r9Hj7
bnovz6r0eLgzfsOln0xfkuPhxZHXdBOMYDwIvLg7fmsCEqT5Hme97xYpHffJNOmnvHOPkw/6
lo2XQFksueW/Sa+fLMtdDG3WlWXnpb+xEtshB71tJW7You3aLO9BBiZN8izP8yq9fhk17v3b
+bp5+y6r+haMTYRvJiZEzIehLX4UYo6ntnB+v8fxCucL8JZyNDMc7j6/VDUt34xfysSpeHKY
droyOkXEFaoyq/u8MX5m8ZScx1O3rvCiarOiqavdxBBVYrMf+UUQmV8zKuTfMPYYel7I5Kio
kOcrgqQIxu3gJ5PqB+5vaHO6niiuNfHBw5ElaN7HNccaBpzT4PXk+KGmHjTXIOEjimqXyNzp
459dyviJuwAmOMQmncTqIz/pcJKu5sOFJQ+u/PBP3SdQJjrtw5+P7EJT0i1YcLAEYwmDPqNM
XJdqjgo7oVSyiM5NUWdtnbcRb0rPXRMCRqC+rZE6JnSJYQp80kdVcpRQ0qo0/guvQopJsQ8a
4UPS6cgpCxa8HPvY0QBsn+S9HHHh6JZ8hrtARujdnEBzZQpzCwWXuaNGZcws5FyMP5DLksHF
6R5npulweQ4OVvBDeEesyidmd9538sEjP47lr6qCZ+QNQGvLpMmeGqAFBhauBphB35l/jdga
8y9UJI3Lgo7MmL6a1fQ18QVXe3EXJneZGwkfH7B7BKvzPOvLEvAarJS8Ze1T5FXWVOBXxDYq
oK3knZdZz+Qd4QkyV/IQmt+wn87oPS7IZ1Y1HRglRN+g2pKLPXGxhZiTV7/jPAsq5mSNnJVv
wEMLr8XyzcezSJCmANLKNx8CStkU0ET3SGpLztRzUPxJGkW2eJiWTI5cWlROJ67JzzkVM4Cm
veuRBoPXXRKFTNP3rjCPRk/iCvEH64VD12VD1zbtDmKKnJmcplGnc1dIUF6pT7jzdMxWKJd2
+ZKgjQTNVidvcisffukTgxaVRm3WlR8jfsi7t6ZZMYqDZVOORWlEbRfFG4wZQbCmq7IoDu6C
06bp3cYu6hDYmSVAgmejGRClChylHhUd1DlVdFrIjf/LyGZ1XinfT6VBAF2/8nleUlImlRUn
OYni2bwFmXo9Ast+yMoxdHaqfQPHm7rOKmaxOI43YwUxlo8UKJq/hj6rqhKbuvU19rtrkRdZ
XtfDbmJwt187O4Dfz/2ncFB+SDlU+HnstICUg3IosV/EvvDUf+M/uepvY8XuuCXvuyIizlkx
MnYGYqFcDlm7o9qdvGG5AHfgXjTQ8mYsp1Cuz0iJNSGI0PyU+5try+0Z3QclqzvcYkix3MgR
YaPOVrQ14qLovAg32/wXbYsEVSM/jfrYJgZ9CA4O184RsH2SsEFN4ZI/ihI5oMZEdESPE1R4
b020RZTKHmipCBfKQoIj7VjeggvbqH44hYilRglHa2tBfZFMtrLYe+wrOI2hY0WTZI0OX1+2
MV/ejzouJFCFRyNiV5Ks+ybr9iVJORIRRzWLzGwFoqqOJ7GyrShK1Gx9OnGx7c4bOaPuCvRi
gRI320LUTYte1AQ2sW0NgkvltApXKkc6IVqwjpXXvEW97wpKVCm3R0hCJDMChWj0RK0uvg5y
bd3zKcTClbybz2ssI0Xc2xgRVrQq2EmQfCrwbDb3Tlrp5Fk2tnRL0ymm0uOB/FnPQZw+ZXkg
OmulUrBL+91UmKdHjp1ESY4n9qpEn8JdOXhFua9lqmD7dqCcVAkbDPzbNOJEWK+zEPl1XWT9
YuhfAAgidjU1D+hJl32xmxic/XAyJ5q3iiiIxLfO1NQqoonkkjKnci2HcDdjHk7qX86MKTuY
BsWCrSAn1b3nDCLySUt/5eyIXKiRmxb/KFoYY1PZ9/kQ0fRZRbXV3qnLDrXj1q5mqy6rgbzY
526SgdlHN/bNAZY80o20/5QBM78ldJoiJdiQyCqnIFSEHsovuiLaGp4c5zd1hZF5EHMGD89H
foGhZn64KcB1Zn6CjUQVfQmmbEc3VVPTOCYzHKI7Isc7QrXpQhI0WWdjzelNNDFqN/1igC9F
H1cTHwoW3jlBbetAVKOyhy926eRKO5J35IlNXVUZdlLtbmLwS/FrYgpIqGxhvxIEhZPrSX5B
/u+txaf2FkZ9k6w9xwQmVwNaRzvCEnxj/4XdX3Lk/oyffxivp8cvZ5Ekb08XvF1Zl5LFzVbU
ALcGZeg6xxdZJGK2oq6yvsqL3cQgvhxwHt4EWt2hSHJf2UiBQEsHMR7z2rJ0JWJBjm/mtWVZ
Z92Avf+ky21ioddStri5SuT6MkdRu3eJY8RcJXoqfdfspgV2LbbE7wIeRvtCFSqNvou4yEX6
iwmAR+l5W1KCePpyzV5IQL5NEmtynZjP5jH3/Dw/JCoEf4T8kByFPtgenT8e8EV5cIbCIFtQ
JYQXvukWY0hhJphkcaU7F3MSQ1TlM33RWPFHveLOepJwyNhXaN28WWzQxZQJBd9A+KmaFADM
OaNRdYeV3bw1qj29xq7v6Ig0FBzZEdsxtPG8Nay/wBEiSqPMbphT8tb0uVTWWMktulICZq0b
oRyqbBhqYN5+U9BZ5D3hUuE2JzlSOPkVRTHH5RWqUAIIz12K8zWmVprFhpiR6kVIASVjzGaL
P0UPOZ9HP+/QGvN15tTm1aAkwXRvnsQdPIPXBEfJXIy0fbyXM50hA5ppkc9m6rKWpbiVpJo2
s4APscQoK8IV/NK7tCzpadlAVN9KjBYtGk5+gvQt7vfv0IgXklf0JfjDUV+o78mxZJljwCMH
ytjJc6g48nOsNTEbYT5PyTiEnyImzYtrsaQv0vzcKDN6B7mEp2y7Z60gHJ0ZUEv6bvZyK77u
XLuwQjbf57Gxtv6Qp1VTWfcRAOWOT/qP6URN5Q9P/st3MhbCZ6gznMPEgbhNYo0nBgtcf7ss
X4Fzf2d04k+evp66OuEOTaq+tL/svpaN0uMTl9vgohp6SUMRyRQn/7BEwkaTTlmJIxujBcxd
Z+4kjIXPgC00RGyHadMOdlGhJvdTFBo0zZ+mfD0/Tmj7LzF6UY6xL5f8WNv18XhE0JlgApCC
pXp9EW+XVjrh5KADQVjyTOXrGXp0u2qYmtez0z/n+zEkAYGBwvnKIxbZ1g5KJhB0iW2mePkH
UVT2O1ilrCUDhXgZdUXVNBB1XdbSPRFsXTUSCBxrs08YsnyC2GEINmHs1hM8JgzxervEkIUD
2IYhW8TOMGSZp9GYIZ1LDEnsVDiMKfen+qVq+pWsPIvRwgPGZWHroORiXxGNTm/CEMcMRsbQ
QPdXjq8vciW5kFbh0w4NWQngsd8WcZYBQdHjhN1k5e1dRMxZ0KjI+gGd873EYB0aRRIqoCTq
emUh4RdKd01X4p2sG2CQ7ijCDE5oHtli5hsnmoB3+CmyYk9VuNGXvH5QsGUlHYMJOar6b5i1
btQxQPIBzzC27QkTiN+TpRGxDilZq037QnKnWSruo6jknqy3LX7PUe1kLOZoQKVyaNilT/YU
NjFQ2qK1E5MCMufnjmf55dm4s0X6kpPK1voiB6EBWAhYp2QHKjFfqRyVq3vHtlJbJueCtLRL
t/7BqPnvwqUPHFii4S9CAloB7NX/VRoVowvC6J6VYuyM6JZC4EAUo8o0hPo/sKD0d3AgUbM1
eKtSi0d82aMian3E7/pVDWL/OZ7OoPJEyYx/v7oFOfB5+857DyEsvmW3IAA+7z18eOvO7VvZ
7WiMl+43JmXVpxMrS93D81CIxTh27Tjutt7zD5L8FpkGLd7oESmdNdXPbBSYDAYZSfmJtmaZ
550oAHK5lWLZ4kf06CEarIyjvKexCiiurTu2vX/KrhnHTPzhyRQvSALNFl16afTEVVn2GQ4i
wj6jYrdzTMw+Dsrxa6LWPW53p0pujOUjMc/TErG9YB4ydVlgBj87RAztcJoZ2PKoGG0io8sm
8hkZVLdoUQ0xt9JguZOszaVsMD13BmyGecH2c31bLcYmX377Pvd0Rs5WnzH24oVLIAAk6ctg
lPkx2L5JCWwjiFOKrrwYdNNY+kFh64g7PpT1rrsdAfASsS4eFopWiO6btLSWRhMnLjPJ4nNa
P2uhdyyVzDSAOeviupKyLHf8DBeSbqWxycr/peaj9Kcd+6pmCfVqLtgPKixm4gmwxYMAPD9z
qpqy3w323WWOn7XyBMkZkr3FvnuT2F5YDJm6hMUgJcMN1h/0yCbW/kDhMT7qoXF0voNuartj
G+I3ziK3gIf+3psGwuSiS4gXexLb4rBlgSexZ8q+VJLljiT6KBm1Tz+U7S5i/kksdSU9UKva
VAg2BQMB7hFAk+NldmJkqGTVdC1lEaJB8wapspNMFmL9tM/ULa0xGRwFDKavI1SdsyqJueio
fX9wN/Ic3KF75c5dbJtStaP4NVWo5KICpQDtiC68OehOBJZRDl9TDnrHUeW4s8xDjgP+kzzb
CSvmmi4XFEO5600AwAFLsdSCxFFOm+4s7EVjXa3zQ4TvewTxHhk84FUtL++/UHqwZSVHMqaK
cE2WDVQ1k5zuKN60tB+bWOGiFRQvUhTpSU8ibNWOgmvpMJVIaqI6UBSQa/gRYWdSMS33FRkL
10hhmLgjf5FAxe+XmmJAwqEPzRryPLCyI1CBucVQoQW9kxgc8uYwGUkCY3B0vd5vcd4JomDY
U0+HZ659z4TmYIjIgnITWcXgRYNkRA0S0CyYjmtpOi9oLM9Oi5w8UQ6tcOBkURMVX3EtRLWJ
oBXolzabSci6T4pFe9fCjI193Uhge1YPgLHRUjvgEGytnvTGC2hQ9+15x0dsI4x+R1H3yy8u
OO+awIUf+T4alS+tUY3S66XBAlzUJEKnxjJChEgaimfgrurCs3s9DKfLkhdOlucudJXZZ/Bs
BocjSE0rypNJn5/ySeEwkur0IPXKq0dEpA7zvPk9iT/xsJyKrQ6lDHJ8Cawrfo3gp3KSRssb
pFIw3ZKuxb7KYi2hRaWFWUiIXmi80Yp2okorqDCR7cmWljR6ps3wsfM69Dsfxysdtt7B4MtZ
8WTLaGnduzBakMonPwx0b2ToohSNTmcjFoSV7sUEp38zxgS6EjIYCXKEyPkvhonyYlE1cJOQ
hEKSCzehyeVxJ9eVq7se+XWHqs/enLVw+MNZrBjsdRfru5lR88JIxOHZESyc4y3wC+a3ITYT
0PGU46AtW7obr+BQrn127wVyP2oKd+4I/8JI+v4Q0bzutwV+DTo03fmyZ6o4R+gNnMcrpso6
z9dOs59vo9/gJRqB8/OEx+aLDyJC4+xQ3uDlYWT3xmkSZ5tavOzLyb3xA0KkOPtZ37QvVDDM
ftb3n3gLm5oXDDlChmDRsEIQzDHMEUEGadmVlxhMuvwUFes6cW3V+qIiLqw4gjev27LEAYwK
B9NpgTcz5fguP5xHQ0R3Bd6thFYganiEIV5LgSdOfKXf56++f/nq7//45x//kn7/Z5zC9IPc
mbNxIMqkkAZ+GnX/8esivfobns1+8W9G3q88CmVuZHN0cmVhbQplbmRvYmoKNSAwIG9iago0
MjY5CmVuZG9iagoyIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291
cmNlcyA2IDAgUiAvQ29udGVudHMgNCAwIFIgL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KPj4K
ZW5kb2JqCjYgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdl
QyAvSW1hZ2VJIF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUgo+PiAvRm9udCA8PCAvVFQz
IDEwIDAgUiAvVFQ1IDEyIDAgUiAvVFQyIDkgMCBSID4+IC9YT2JqZWN0IDw8IC9JbTEgMTMg
MCBSCj4+ID4+CmVuZG9iagoxMyAwIG9iago8PCAvTGVuZ3RoIDE0IDAgUiAvVHlwZSAvWE9i
amVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDM0NSAvSGVpZ2h0IDcwIC9JbnRlcnBvbGF0
ZQp0cnVlIC9Db2xvclNwYWNlIDcgMCBSIC9JbnRlbnQgL1BlcmNlcHR1YWwgL0JpdHNQZXJD
b21wb25lbnQgOCAvRmlsdGVyIC9EQ1REZWNvZGUKPj4Kc3RyZWFtCv/Y/+AAEEpGSUYAAQEB
AGAAYAAA/9sAQwACAQECAQECAgICAgICAgMFAwMDAwMGBAQDBQcGBwcHBgcHCAkLCQgICggH
BwoNCgoLDAwMDAcJDg8NDA4LDAwM/9sAQwECAgIDAwMGAwMGDAgHCAwMDAwMDAwMDAwMDAwM
DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgARgFZAwEiAAIRAQMR
Af/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAAB
fQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2
Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqi
o6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5
+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAEC
dwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1
Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZ
mqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5
+v/aAAwDAQACEQMRAD8A/T79tz9t3VPDXii78G+Dbr7DLYny9S1KMAyrJjJhiJ+7tz8zdc8D
GCa+QtX1q98QX8l3f3d1fXUpy81xK0sjn3ZiSal8TXV7feJdRn1IudRmupXut/3vNLkvn33Z
qjX8oZ/n2KzTFSrV5PlvpHpFdFbv3fU/Kcwx9XFVXOb06LsFFFFeEcIVgfEz4maR8JPCNxrW
tXAgtYOEQcyXD9o0Hdj+nU8UnxN+JukfCPwjca1rVwIbWH5UReZLh+0aDux/TqeK+Avjt8dt
X+PHi5tQ1FjBZwEpZWSNmO1T+rHu3f6YFfW8LcLVc1q88/dpR3ffyXn3fT7keJnOcwwUOWOs
3sv1f9amt8aP2rvFnxh1K4Vr+50rRmYiLTrWUpGF7eYRgu3qTx6AV5kTk0UV+84PBUMLTVHD
wUYrov61fmz80r4irWm6lWV2fZn/AAQI/wCUnXg3/sHap/6RS1/QZX8+/wDwQDt3n/4Kb+Em
VSVh0zVHc/3R9kkXP5kfnX9BFe3g37j9T+gPCv8A5E8v+vkvyifl1+1H/wAnKeNf+wzN/wCh
V+neh/8AIFs/+uCf+givzD/akO39pLxsfTWJz/49W/8AET9rr4i/GXWfsunX+q6bZKoSDTdH
3hggGAXZBvc+pPHoBX4bw/xRh8mxmOlWi5SnO0UutpTvr815+R25fmdPB1q7mm23ol6s/Sei
vy80D9oH4lfCXW0KeIfEllcId5ttSaSRJB/tRzZyK+3f2RP2tLT9o/QZrW8hi0/xNpiBrq2Q
/u50PAmjzztzwQeVJHXIr9F4e48wWaV/qri6dTon18k+/k0vI+iy/PaGKn7KzjLs+p7NRXwL
+0h+1b8QfA/7QfibTdN8T31tpmn6hshtVSLaqAKduShODz+dRfBr9obx38cf2qPDd1fanqz6
e2poZLGzaRbK1i5wrKvBGMZL9a5ZeI2C+t/UoUpufPydLb2bvd6L0uZPiKh7X2Ki+bmt072u
ff8ARXyT+1l/wUFufC2v3fhnwK1ubmzYw3mrOolWOQcMkKnglTwWORngDjNfNNx8YviR4vkk
1D/hI/Gd6Izl5re4n8uP/v3hRU5v4kZfhK7w1CDqyju1a3nr1t5K3mLF8R0KNR04Jya3tsfq
ZRX54/BD/goB40+Guqwx65eTeKdFLBZorog3US9zHL1JHo2QfbrX3p4N+IOkePPBNp4i028i
m0m8g+0JOx2hFH3t2fulcEEHoQa93h3izA5xCX1duMo7xe6Xfs15/fY7svzWhjE/Z6Nbpm1R
Xwv+0v8A8FDdc8Ua5c6V4Gum0fRLdjH/AGiij7Te46spP+rT0wNx65HSvG9N+LPxKVv7WtfE
HjaRVO43S3FxJF+J5XFfOY/xOy+jXdHD05VUt2rW+Xf10XyPOxHE2HhU5KcXK3VfofqZRX57
6h/wUJ8a6z8KE0ttQez8R2t3G8eq2sSA3VvtYMkikFQ2dpyoGcdj1+gf+Cenxd8RfFbwH4jv
PE2rzapNZX6xxSzKi+UnlBiPlAGM88162U8dZfmOMhg8MpXkr3aSSsm2nre+np5nXhM8w+Ir
KjTTu1f/AIB9D0V8T/tP/wDBRHVdR1y70TwDOlhptsxik1bYHmuiOCYs8Ino2CT1GK8KtPi9
8SZ3bV4PEfjWUKdzXSXNw8QPufuV5eZeJmX4eu6GHhKrbdqyXy7+ui7M5cTxLh6dRwpxcrdV
t8j6n/4Kpf8AJM/C3/YVf/0S1cH+xz/yaP8AGL/r2k/9JWryb4qftSeIfjd8NdL0LxGYb650
m8+0w6gqhJJUMZQo6jgnkHcMd8jvXrP7HP8AyaP8Yv8Ar2k/9JWr4yGbUMz4jljMPfllSlvo
1ak00ePHF08TmTrU9nF/+ks4X/gnz/ydX4e/64Xf/pO9fo5X5T/BH4s3PwQ+INv4ksrWK7vL
O3njgjlJEYeSNkDNjkgZzgdcVr678ffid8Ub6a8fxB4puwGLMmnGWKCH2CxAACp4P40w2UZa
8NKEp1JTbsu1orV/J7JiyjOaWEw3s3Fyk23p6I/UGivzc+Ef7cPj/wCFOsR/adVuvEOmowWe
x1NzI2O4WQ/OjfiR6ivv34RfFfSfjT4BsvEOjylrS7Uh0fiS3kH3o3HZlP8AQ9CK/UuHOMMF
nF4UbxqLVxe9u6tuvx8j6fLc3o4y8YaSXRnTUV8YftWf8FB9SPiC78P+ArlLS0tHMNxq4UPJ
O44YQ5yFUHjfgk9sDk+A2XxZ+JOrXDala+IfG900Z3NcQ3NzIin6j5a8PM/EvAYbEPD0ISq2
3atbzt3/AC7M4cTxJQp1HTpxcrdVt/wT9TaK/PjTf+Cg3jU/CjUtDvL+X+3FaJtP1iKNBMoW
QeZHKpG05XOGxnsfWvUP2L/j34x+I3gf4kXOua9dajcaNpomsnkSMG3fy5juG1R3VeuelduA
8QcuxmJp4ahGTc03stLJtp672XS61Wpvh8/w9apGlBO7V/S19Hr5H1vRX5ueDv28PiV4b1T7
Xda/LrKiCREt7uOMRB2UhXO1QTtJ3YyMkc1zXiD46/EnxWza1d+JPFjQ7s/aIZZYbaM56DZh
APavIqeKuX8ilSozb7aKy73u/wCtzjlxTh+W8INv5H6kUV8L/sp/t8a/oHiyx0LxpfPrGjX8
qwJfT4+02LMcKzN/GmSM55HXPGK+yviZ8SNK+Evgi/8AEGsz+RYWCbmxy8jHhUUd2YkAD3r6
/JOKMDmeEli6T5VD4lLRx669LW6nr4LM6GJpOrB2S3v0N6ivzn+M/wC3p46+KGqSrpuoT+F9
ILEQ2ti+2Zl7b5R8xY+i4HtXK6F8evid8NLuHUI/EHiq1V2DL9vaWW3m9isoKsDXyVfxTy+N
ZxpUpygt5aL5pP8AWx5U+KMOp2jFtd/6/wCAdn/wUa/5Ogv/APrwtf8A0A14VXY/HP4x3fx3
8cr4gv7WG0vZLOG3nWEkxu8YILqDyAeuOcetcdX4xn2Lp4rMa+Jou8ZybXo2fGY6rGriJ1Ib
Ntn1F+3T+x5q+jeNNQ8Z+GrGbUdJ1Vzc39vboXlspj99wo5aNj82R90k54xXy28qxOVZgjA4
Ibgg/Sv2GrJvvAWhapctNc6LpNxM33nls43Y/UkZr9iz3wxo4vEyxOEq+z5ndpq6u97aq3pr
5aaH2GO4ZhWqurSly33Vr/cfkd9oj/56J/30K5/4nfFbRPhF4Rn1nWbtIraL5Y41IMtzJjiN
B3Y/kByeK/WT4u3/AIA+Cfgq51zXNH0KG2hG2ONbCIy3Mh6RouOWP6dTgCvzh+Pvj2H9oLxm
2p6loeiW9nBlLGxSyiMdnGT0+7y543N39gAK/Pc/4Xw2S1IRxNf2knq4RVnbu227X6aM+Yzf
KvqcOWNVOb2VtvN6/wDDn5efHT486t8ePFzajqMghtIcpZWSPmO0T0Hqx7t3+mBXFBwx4IP4
1+n/APwgGgf9ALRP/ACL/wCJrxD9v3wrpejfAyCaz0zTrOY6rAvmQWqRtjZJxlQDivr8j44w
1SrSy/D4fki2or3tF+B+XZjw7VjCeKq1eZrV6b/ifGFLHG00iois7uQqqoyWJ6AD1pYomnlV
EVndyFVVGSxPQAdzX2V+yF+yCvgCO38T+KLdX11wHs7NxldOB6O3rL/6D9en2Ge57h8rw/tq
2rfwx6t/5d309bI8HLctq4yr7Ont1fY9+/4IO/s2XPwj/aO0zXtbi8rXdYsLmNLc/esoPJZt
rf7bHBI7YA65r9jq/Oj/AIJ58/tU6J/163f/AKJav0XqPD/Mq2PwNXFV370qj9EuWNkvJH9J
cF4Snhsu9jS2Un+SPy8/aet3u/2mfGcMeDJNrUyLnpkvgV+hnwF+BWi/AbwJaaVplrCLrylN
7ebR515LgbmZuuM9B0AxX59ftH6Vfat+0145Fhb3FxNb6tPMxiQt5Khs72PRVHqcCvt39l79
sbwZ+0V4bit7LxFoT+KdPhVdV0uO/iknt5B8pcKrHKE9GHHODzXy/AMMOs2xk6sff5nytr+9
LmSe19vO3zMcinRjjKqqWUm3y39Xe34HWfHX4J6P8dfAN7o+p20TzNExs7naPNtJsfK6t1HO
MjoRkGvz1/ZY8W3Xw0/aS8MzK5RjqK6dcqDw6St5Tj6ZIP1UV96/tDftKeH/AIE+Cby6ub+1
m1d4mWxsI5A008pHy5UchQeSx4AHrxXwj+yN4Iuvid+0n4ciCmRba8GqXbgcKkR8wk+mW2j6
sKOO5UJ51go4O3t+ZXtv8UeW/wCPy8rF564PG0VR+O+tvVWv+JX/AGwTt/aY8bH01Bv/AEBa
+0fEcNn+zV+xReT6BBFZz2uixlZUUB5LiZVXzWPUtufdk+mK+Lv2wv8Ak5fxt/2EG/8AQFr7
v+L3gGf4nfsoX+i2i77u70SJrde7yIiSKv4lQPxrl4Voyli82nRX7xKai+t257erSM8qg3Wx
coL3tbfez4c/Y9+Clr8d/jZaaVqRd9Ks4Xv71QxDTIhACZ6/MzKCeuM1+k+h6FZeGtKhsdOt
Lexs7dQkUMEYjjjA7ADivzW/ZD+NUHwE+NlnqupLImmXMb2F/hSWhRyDvx1+V1UkdcZ71+k2
g+JdP8U6PFqGm31rfWM670nglDxsOucjivY8LHg/qNRQt7bmfN3tpb5frc6+FnR9hLl+O+ve
3T5Hyb/wUl/Z60jSfD1t450i0hsbs3S2upJCoRLgODslIHG8MME9wwz0rxz4Y/G3UPDP7J/j
7wzFPIqXV1aLAQf9Uk5YTqPQMsY/76PrXsH/AAUg/aM0fXvD9t4H0W8g1C4F0t1qUsDh47cI
Dsi3DgsWOSO20Z5NeS/C34Gah4n/AGSvH/iZIJGENzavagLzKluzNOw9QBJ/46fSvleIeV8Q
V/7J/wCfc+fl2vyS5tvl/wBveZ5eYWeYT+qfyu9vR3/T5+Zf/YD+A+m/Gf4qXVzrUCXek+HY
FuGtnGUuJWYiNWHdRtZiO+ADxmv0KtrSKztUghijihjXasaKFVR6ADgCvzy/YK+P+nfBD4oX
cGtzC20fxDClvJct922lViY3b/ZO5gT2yD0Br9CbPVrXUNPW7t7m3ntXXes0cgaNl9Qw4xX2
vhi8H/ZVqVvaXfP33087Wtbpe/W57XDLo/Vfc+K7v38vlY+LP+Ck/wABNJ8E3uleLtHtYrEa
vO1pfwwqEjeXaXSUAcAkBg2OuAeua5b4JeOrjwF+xD8SZ7SRornUNTg09HU4KiVFVyP+Abq6
H/go9+0LpPxE1LS/Cmh3cOoQaNM11e3MLB4jMVKLGrDg7QWJI4ywHUGsH4GeAbj4hfsSfEm2
tI2lurDUoNQjRRkv5UaswHvs3V8VmDoviLE/2Zb+HU+Hbm9m72t5/jc8XEcjzGr9W/llt35d
bf1uY/7CXwF0/wCOHxbl/tiIT6PoNuLue3P3bly22NG/2c5JHfbjvX6J2en2+nWUdtbwQwW0
S7EijQKiL6BRwB7V+c/7Dnx7sfgV8XHl1eTydF1y3Fncz4yLZtwaOQ4/hByD6Bie1fopp+uW
WraWl7a3dtc2ci71nilV42X1DA4xX2Phe8H/AGY1St7W75+/l52tt0vc9jhh0fqz5fivr38v
kfGX/BSH9nnSfBX9neMdEtIbAalcm01CCFQkbyFSyShRwCdrBsdeD1zVT9jn/k0f4xf9e0n/
AKStUn/BRr9o7SfiDLp/hDQbuLUINLuDdX9zCwaIyhSqRqw4baGYkjjJA7Go/wBjn/k0f4xf
9e0n/pK1fL1Xg3xVWeCty8k7225vZu9vnv53PMk6P9qz9htyy22vyu/9dzyH9lP4P2/xx+Nu
k6Fesy6cQ91eBThnijGSgPbccLnsCa/TLw54Z07who0GnaVZW2n2NsoSKC3jEaIB7D+dfmN+
zF8X4/gb8Z9H8QXCPJYxFre8VBlvJkXaxA7leGx321+mnhPxlpXjvRIdS0bULTUrG4UMk1vI
HUg+vofY8ivb8KZYP6pVUbe25te/LZWt5Xv89+h28Kuj7KSXx31726fI+c/+CjnwC0nVfhtL
42srSG11nSJYxdyxKF+2QOwT58dWVmUg9cZHpj5+/Zx+NeofDn4QfE/TLad4xeaUk9tg/wCp
maVLdmX0JSUf98Cve/8Agot+0To9p8O5fBOm3sF9q2qSxm9WFw4s4UYPhyOAzMqgL1xk+mfC
v2aPgff/ABJ+D3xP1O3gd/s+lJbWvH+umWRbhlX1O2ID/gYrw+JXF8SP+yfj9nLm5f5uSd9u
trfPzOHMrPMn9U+Lld7d7P8AS3zM79iv4I2Xxy+Nlvp+pp5ukaZbtf3cOceeqlVWM+xZhn2B
Hev0j0vSrXRNPitLK3gtLWBQkcMKBEjA7ADgCvzb/Yx+OVn8CPjPBqOplk0jUrdrG8kVSTAr
FWWTA5IVlGfYmv0g0TxDYeJNKivtPvbW9spl3pPBKJI2HqCOK+l8LHg/7Pmqdva8z5u9unnb
8L3PS4XdH6u+X4769/L5Hyh/wUq+Aek2Hhi18caZaQ2V+t0lpqAiQIt0rg7ZCBxvDADPUhue
grlP+CfX/JOfi3/2CF/9FXFdH/wUj/aI0fXfD9r4I0e8g1C5W6W71KSFw8duEB2RbhwWJOSO
20Z61zn/AAT6/wCSc/Fv/sEL/wCirivCxTwj4w/2S1uWXNbbm9nK/wCl/O/U4arpPOP3PZ3t
35Xf+u54p+zh4FtfiV8b/CuiXyeZY316guEzjzI1Bdl/EKR+NfqPHoVlDo405bO1XTxH5Ith
EvkhMY27MYxjtivzW/Yl/wCTofBn/XzJ/wCiJK/TOvY8J6FP+z61W2rna/kop2/FnXwpCP1e
cra3t+CPyz/ac8C2nw0+O/inRdPQQ2VndlreNekSOqyKo9huwPpXtP8AwUF+JN5q3gP4a6K0
r+Xd6THq90M/62Ro1RCfp+8/OvNf26v+TpfF3/XSH/0njr0b9vDwHcN8Kvhd4njRntk0WDTb
hgOI2MSSR5+vzj8K+GlTnSpZtRwytFSWi/lVR/gl+B4jjKMcXCnsmvu5js/+Cb/7O+kT+Dm8
dapaw32o3NxJDpwmQOtokZ2s4B43lgwz2CjHU19Ua94fsfFGkz2GpWltfWVypSWCeMSI4PYg
8V8of8E4/wBo/SNN8KyeBdZvILC8huHn02SZwkdyjnc0YY8Bw2SB3DcdK+q/EnivTPB2jTaj
qt/aafYwKXeeeUIgAGep6/Sv1vgmWA/sSn7C1re/t8X2ub/g9LdD6zJXQ+pR9na1tfXrf+tj
82f2u/gvbfAn423+j6fuGl3MaXtkrHJijfPyZ77WVgPbFeY16T+1l8aYPjx8atQ1qyV10yFE
s7HeMM8SZ+cjtuYs2OwIrzav57zt4Z5hWeD/AIfM+W21r9PLt5H59jfZfWJ+x+G7sfsJXMfF
34u6J8E/BVzrmuXIhtoRtjjXmW5k7Rovdj+nU4AqT4sfFPSfg14FvfEGtTGKzs1GFUZknc8L
Gg7sx/x6A1+bH7QHx/1r9obxs+q6o5htISUsbFGzFZx+g9XP8Td/oAK/oPjDi+lk9H2dP3q0
louy/mfl2XX7z9AzjN4YOHLHWb2X6v8ArUP2gP2gNa/aG8bPquqMYLSHKWNijZis489B6ueN
zd/oAK4Wiiv5wxWKq4mtKvXk5Sk7ts/OatWdSbqVHdsK8L/4KExPcfAq1jjRpJJNYt1VVGWY
lJAAB3Ne7QwvcTJHGjySSMEREUszsTgAAdST2r2P4ufsVr8Lv2bLDxZ4rt0k8STavbNaWbjK
6WpSX5m9Zj/47065r1+HqVeOI+v0oc0aHvy6Ky6X7vp/wGY18uq4zDVIQ2tq+x8Kfsifsgp8
PYrfxN4nt1k15wHtLRxldOB6M3rL/wCg/Xp9DdaKK4c1zXEZhiHicS7t/cl2Xl/T1ObBYKlh
aSpUlp+fmz23/gnn/wAnU6J/163f/olq/Revzo/4J5/8nU6J/wBet3/6Javs/wDbDvNd0/8A
ZR+JE/hh9Tj8Rw+G799MbTgxvFuRbuYzEE+bzN2NuOc4r9x8LXbJ5v8A6eS/9Jifo3DtX2eX
zqWvZt/ckfjR/wAF0v2vbvxF+0z4m+FXhWZ9H8IaBdiXXEtnKNr+pyKJJHuGHLpFuEaIflUq
xxkjE3/BPL/gmr8bfC9nceNrvwBqFtoev6TE+nv9ogFzMrusit5IfzFBXkZAPI4r4b+JmoeI
9W8f6xc+MX1eXxTPdO+qtqwcXrXBPzmYP82/PXdzX6nf8Env2vfiP+zZ8M/i744/aC1L4lDw
j4Z0bTTosPiKO5VbiVnmRYLNZgFZ3/drhegwTgDNfSY7LKGOw08HUvGMv5bK2t+1j8bybFUM
0zyeIx7kldtNWtBJN+9dOySVtOp3/hH9if4neMtUWIeF7zTg5w9zqTrAiD1OSWP4A19q/sp/
svaV+zh4fuEW6i1PxDfhft94BjAHSJB1VAfXknk9gPwt/a//AOCtHxr/AG3PGs1nba1rHhnw
5eTeTp/hnw9NJHvUnCrI8eJLiQ98/LnooFeZ+Jf2fPj18BdHi8Xap4T+KvhKyTEq6vLa3tqs
XcM0owU+rEV4uQ8I5dlVb6xSUqk1tKVtPRJWXq9T6HD8aYHC1pVMFhp1Yx+23a3mkou3z19D
9hf2lf2QPiN47+OnirV9J8OSXen6heNLbzC6hUSLtUZwXBHI7ivuTwlZS6b4V0y3mXZNBaRR
yLnO1ggBH51+On/BKr/gup4n8NePtJ8AfGrWH8QeG9XlSzsfEl2R9s0qVjhBcP8A8tYSSAXb
50zkllBx6X/wce/Hrxx8GPEXwmXwd4x8TeFk1G21NrkaTqUtoLkq1ttL+Ww3Y3NjPTJ9a9fJ
siwmW1a+MoSk3Vd5J201b0sl38z6fA8T5bSy6tnOG5pWa5ouyabdvu10et/W59R/taf8E/ZP
HGu3fibwS1rb392xlvdNmcRRTueTJG54Rj1IPBPORXzPP+zb8TtDne0Xwf4sQMcMLaCR4pP+
BISpHvmvzg1b9p34+fti+G/D3w3h1zx541TSklaDTbGS5u7q/d5WdpbgqS8pXcEUv8qKoAxy
T7Z/wUs/aB+LX7PfxT8AeFNM8bePPBw0z4b+HY7vSrXVri0W2uRabZQ8asAJNykN3yK+czfg
PLcbWliqblSb35bWbe+jWnydvI+WxXFWAxEJ42FCcYrlV01q5bra2lu+vZH3x8Dv+Cdfi/x3
qcM/iaBvC2iqwaRZGVryYd1RBnYT6t09DX3V4V8D6V4L8H2ugadZQwaTZwfZo7fG5SmOQc9c
5OSepJz1rxn/AIJdeLNV8df8E+/hVq+t6lfavq1/oiS3V5eTtPPcPvf5ndiSx9ya8W/4OBvi
l4m+EX7EOl6p4U8Q614a1N/Fdnbtd6XeSWszRtBckoXQg7SVUkdOBX0mQcMYDJqLeGTcpLWT
1b8uyXkvnc/RKNTC5blTzKEG/cUn3s0nbt1E/aP/AOCdWueHdbudT8C241fR52Mn9nCQLc2W
eqpuIEienO4dMHrXkGnfs2fE+5l+wQeD/F0SOcGNoJIYfxJITH1NY/8Awb9fH3x18X/Dfxxf
xZ4z8UeJX0vTbJ7JtU1Oa6NozJd7jGXY7Sdq5x/dHpX56/DT/gpZ8dfhj4nh1m1+KHjPULm3
gmiii1TVp722RpImj8wxSMUZk3bl3AgMqnBxXyuYeHWWVq3t6UpU1K94q1vldaemqPgswz7L
IUMPjnTnGNbm0TWnK7P/AIY/WvVf+Cc/i/Q/hdFfCKG+8UXV2iLplvcxqlrBtYszOxAd87Rh
eBnv297/AOCfvwY8SfBzwN4hs/E+lnTZ76/WWJGlSTzEEQUn5SR145r8D/GHwk/aD+J/hib4
l67oHxZ13SblTdv4hu7e9niZDz5okPRO+4fKB7V61+x7/wAFsPjD+yb4E1zw82ot42067sWi
0Ya5cPcPodycbZUc5Z4gM5hY7c7cFeQfUynhLLcvxkMZQ5k4q1m007qzb0vd36O3lYnLeNMv
w2LjUxFCdKNtG3e+m7XKnr5Nr5H6iftR/wDBPHUbXXbrXfAccFzYXbmWXSXlWJ7ZjyfJLEKy
E9FJBHQZrwy1/Zu+Jvm/YYvB/i2NZDgxi3kSFvqchMe+cV+bkq/tDft+eItS1+KD4m/E26t3
Jup7SK5ure0PXYqp+6jAHRFAwO1aX7Mf7fnxn/YH+KCf2drfiCGHTbkR6p4W1uSZrS4APzRS
QScxPjOHUKw46jg+VmPh9lmJxDr0nKkpbpWt52TWnpdrsjhrcW4CpXVWeHnTpSfxJr8Fb8FJ
n6r3P/BOjxrp3wq/tI2qXXiSe6iSLSreeMC2gwxd5HYhS2QoCqeMnk9vU/2Z/wBnfxl4D/Zy
+Jeh6toz2mqa7A6WMBnjYzkwMg5DED5iByRXun7NPx90X9qP4EeF/H/h/eul+J7FbuOKQgyW
z8rJC2ONyOrIfdTXc17WA4AyzCVo4jDykmouO6s+ZNNvTfX020sfrGDyXBrlxFCTacdNdGmt
9uzPz6+F3/BPTxt4o1W+tfEOnSeH4fsLvaXbTxSxi5DLsV1RiSpG4HHTr7Vxfif9lP4n/DvU
prVvDOuyKWwZtM3TwTe+Yz3/ANoA+1fpzRXm1fC3LHSjCnOcZK/vXTb8mrJadLWfe5jPhfDO
KUZNNddP8j84vhP+wd8QfiTqsS3ulS+GdNZgZrvURscDvtizvZvrgepr73+Efwo0n4LeAbLw
9o8RW0tFJZ35kuJDy0jnuzH+g6Cumor6Dhzg/A5PedC8pvRylvbsraJf1c9DLsooYO7hrJ9W
fGX7U/8AwTz1OXxHd6/4ChhurW8dpp9JLiOSBzyxhJwpUnnaSCO2RwPBLT9nX4mQXRsYPCPi
2FnOGjS3kjjb6nIXHuTX6kUV4mZ+GmW4rEOvSnKnfdRtb5XWn5eRxYnhrDVajqQbjfotj4Es
f+CcnjC2+FWoard26v4iYxLYaPbzplQXXe8rkhchM4UH8e1elfsb/s6+M/hh4K+I1pruivY3
Gt6aILJDPE/nv5cwx8rHHLL1x1r6xoruwHAGW4PEU8TQck4JrdWd0029N7PpZaLQ3oZBhqNS
NWm3dK3re+r08z4T/ZY/ZG+Inw9+PnhjWNY8OyWem2E7vPMbqF/LBidQcKxJ5I6CvuyiivZ4
d4dw+TUJYfDSk1J83vWveyXRLsdmX5dTwdN06bbTd9T4Y/az/ZL+IXxH+P8A4k1nRfDsl7pt
88RgmF1CgkxCinhmBHII5FfWMPwpsvG/wG07wn4ks98Mmk29rdRbhuhkSJRlWHRlYZBHcV21
FY5dwrg8HiMRiIty9vfmUrNattpKy0163Iw+V0aNSpUV3z7p2t+R+dvxn/YA8c/DfVpjpFhL
4q0csTDPZgG4Vewkiznd7rkfTpXLeGv2Vvif4/v4rNPDGvogIAk1LdBBD75kPGPYE+1fp3RX
y9fwsy2dZzp1Jxi/spr7k2r/AH3PLnwvhnPmjJpdj8/Pid/wTx8beFrvTLbQbBvEO6yWS/uo
544oluC7ZRFdg20Lt5PXk8dBzP8Awwt8Vf8AoVJf/Ay3/wDi6/SmitK/hblM5uUZziuyasvv
i397KnwvhJSunJfNf5Hx3/wVX8RXKy+DtIDMtm4uLx1B4eRdiKT9Azf99V8f1+hv7e/7Pd78
bfhnbXujQm41zw7I88MC/euomAEka+rfKrAd9uO9fnnJG0EzxyI8ckbFXRwVZCOoIPIPtX5z
4j4OvSzmdaqvdmk4vpZJJr5NbfPqfO8R0akcZKctpWt91hKdDC9zMkcSPLLIwRERSzOxOAAB
yST2pbe3ku7mOGGOSaaZgkccalnkY9AAOST6Cvuj9ij9idPhlFbeLPFlukniORd9nZuAy6WC
PvN2MxH/AHz0HOSPC4d4dxOcYn2FBWivil0iv8+y6+l2cOXZdVxdTkht1fb+uwfsU/sTJ8M4
rbxZ4st0l8RyLvs7NwGXSwR95vWYj/vnoOeRpf8ABTb/AJNyt/8AsNW//oEtfQ9eJ/8ABQPw
RdeNv2atTNnG0suj3EWpMijJZIyQ/wCSszf8Br94zPIqGA4er4LBR+w/Vu2rfd/8MtD7vE4G
FDL6lGiuj9WfnPRQDkUV/M5+aHtv/BPP/k6nRP8Ar1u//RLV+i9fAX/BNPwRda98fZNZRGFl
oNjKZZMfLvlGxEz6kbz/AMBr79r+hvC+lKOTOUlpKcmvNWivzTP0LhiLWDbfWT/Q/ma/4KfH
P/BQn4z/APY133/ow19u/wDBxj8W9QT4efA3wNFLImmz6W+u3SBjtnlWOKGIn12hpv8Avuvi
L/gp9/ykJ+M//Y133/ow1+hH/Bwn+zdqHi79mL4T/E7TbeS4g8IWiaXqxRcmCC5jiMUp9FEq
bCfWVa+yinyzt/Wp+LYeFaeEzdUd+aLfopyb/DfyOg/4Nwv2QPDenfBHUvjFqNhbX/inWNRn
0vTJ5kDnTLWHar+Xn7rySFtzDnaqjOCc/pxe2UOpWctvcRRT286GOWKRQ6SKRgqwPBBBwQa/
Gj/ggx/wVC8Jfs8eHtR+EvxG1ODQNIv9QbUtD1i5bbawSyKqy28z9IwxUMrn5clwSMjP6l/E
n9tj4R/CPwVN4h174jeDrTSoo/MEiarDO847CNI2Z5CewQEmuzDyj7NWP1LgjH5cslpKlOMe
Ve/dpWl1b9e/Y/Cf/gtD+yfoX7I/7cOr6P4Yto7Hw34jsYdesrKPhLHzmdJIUHZBJG5UdlYD
tXY/8FQvixf/ABu/Yi/ZH8RapK9xqNx4c1O0uJnOWme2mt7Yux7lvK3E+pryL/go3+1vcf8A
BQX9sjVPFWkaderp9yYNF8PWJTNzJboxWIFRn95JI7NtGcGQLzivoD/gs18Bbj9mL9mP9ljw
Lebf7Q8P+HtRjvQpyouXe2lmAPcCWRwPpXE7Pncdv+CfkWI5Kkc0rYJfuPdtba7qxtb5c1vI
+uf+Daf4a6PpH7H3ifxXFZwjXda8Sz2NzdlB5pgghgMcQbqFDSO2PVjXxV/wcQ/8pHr3/sXN
O/lJX3p/wbd/8o+dQ/7HC/8A/RFrXxF/wcfeD7vQv2+bDVJYnW013wvaPbyY+VzFLNG4B9Rh
c/7wraa/cI+sz+ilwXhuRaJwb+d9fvZ+p/8AwSQ/5RtfB7/sAJ/6G9eD/wDByUf+MBNIHr4w
sv8A0nuqT/ghp+3z4A8WfsbeHPh9rHibR9C8X+B0lspLLUbtLZry3813imiLkBxtcKQMlShy
MEE+C/8ABxX+3H4M+KXhXwp8LPCGvad4ivNP1M6zrU+nzrcW9mUieOGEyKSpkPmuxAOVCrn7
1aznH2PyPoc1zbCPhK8aid6cYpXV+ayVrd11Kf8Awba/8it+0B/2C7H/ANAvK+Bv2Efhvp/x
f/bJ+FnhnVoUuNK1nxLY295Cwys0PmqXQ+zKCD9a++f+DbX/AJFb9oD/ALBdj/6BeV8T/wDB
Lr/lIZ8GP+xps/8A0KuV7Q/rqfnFaEZ4DKISV05TX/lRH9L0VrFDbLAkcaQouxYwoChcYwB0
xjtX80X/AAU++GulfB79vz4raBodrFY6VZ6081tbRLtjtxNGk5RQOigyEAdgAK/phr+b3/gs
j/ykv+L3/YTh/wDSOCujG/Cj7zxYpxeXUZW1U7ffF/5I/eL9gL4UaR8F/wBjD4aaFotpDaWy
eHrK6m8tQDPcTQpLNK3qzO7Ek+tflr/wc0/D3TNA/aV+H/iG0toYNQ8Q6DNDfSIoU3Bt5gI3
b1YLLtyeyqOwr9cf2X/+Tafh3/2LOm/+ksVflV/wdB/8lZ+Ef/YI1D/0dDVYhfufuO/jmjCP
DDilpFU7eWqX5H1V/wAG8mqTah/wTe0uKVyyWWvalBECfuqZA+P++nb86+5K+E/+Ddb/AJRz
W3/Yyaj/ADjr7srWh/DXofS8JtvJsNf+SP5BRRRWp9AFFFFABRRRQAUUUUAFFFFABRRRQAUU
UUAFFFFABXBfEf8AZg8BfFjUGvNd8NWF1et965QNDM/+8yEFvxzRRXPicJQxEPZ4iCnHs0mv
uZnVpQqLlqJNeeo/4b/sz+BfhJei60Hw3p9neAYFywM0y/R3JI/DFd1RRRhsLQw8PZ4eChHs
kkvuQU6UKceWmkl5aBTZYkuImjkVXRwVZWGQwPUEUUV0Gh8jfH7/AIJqw3+p3eseC9TtNLgl
Jlk029VvJiJ6+W6gkD/ZIOOx7V598Nv+CcniXxnqe2/17Q7CyiYea9v5txLjvtVkQZ+poor8
gzfhfK1nMKSpJRlq0m0tfR6fKx8ji8rwv1xRUNH6/wCZ9n/Bf4LaH8CPBcWiaFAyQhvMnnkO
6a6kPV3Pc8dOgHArraKK/WcPh6VCnGjRioxirJLZI+rp04wioQVkj8M/27f+CUvxH+Lf7Yvx
O8Tabq/giHT9d8QXd5bpc3t0kyI7kgOFtmAPrhiPev2kj+HemeMvg3D4W8RWFnq+lX+kpp9/
aTJ5kFzGYgjqQeoPPofpRRWWHS5pHwHCGCoU8ZjOWPxPXrfWXf1Pxf8A+CmH/BDKf9lyC/8A
GfgTxNYXXgiWUldL1ZpVvtPzk+WkioyzIOxba2Ou48n4Q+Gvwov/AIn+N7fQtMewhvbiURK9
wzJECTjkqrHH4UUVyV4KM7I/KuMcrwuEzd0MNDli2tFfr8z9rv8Aglt/wQ+0P9k/XdN+Inj3
U7Hxh44hRZ9Lgto2Gm6KzLkSpvAaWYA8OyqF7LnDVi/8F8f2N/FP7VviD4ZSeHL3w/Zrolvq
Cz/2lcTRFjI1uV2+XE+fuHOcdutFFdlSEY0bI/VcyyjB0OGnh6NNKMlFvfV80dW9/wAT2D/g
iF+z1rn7M37G974c8QXOlXV9J4lu7wPp8skkWx4rdQMuiHdlD2x05rvP+Cjn/BOzwx/wUO+D
8Wi6pOdG8SaMz3Gha1HH5j2MrABkdcjfC+FDLkH5VIIIoorSlFOkkz3cqwGHr5JTwtWN4OFr
P+r/AD3P5+f2qv2Ute/ZK+KV94T8R3mjajeWMxi87T5JHifHf94ikfTFe9/AL/gjz4n+NP7I
+tfEuPxF4ftZmuILTRbBpJlRmMqedJcOIjtxGSFVA2WOSQBglFebGK5n8z8GynLMNVzCtQqR
vGMZtK70aTt1PuP/AIIgfsX+K/2Y9A+McPiC+8PXbeIdPtIrU6fcTSBCi3QO/fEmB846Z718
t/sEf8EvPiF8KP2zPhh4k1HVvBk1jouv2t3OlteXLTMitkhQ1uoJ+pH1oorZpcsP66n2rwFD
6rly5fhlK2r099eZ+6dfiL/wUy/4Jm+P/jX+3P8AEjxTpOq+D4NP1i/jlgju7y5SZQLaFPmC
wMoOVPRjRRW+M+BH1viBhqdfA041Vdc/6M/Y74CaDN4V+BngvS7lonuNN0KxtZWiJKM6W6KS
pIBIyDjIH0r8+v8AgvZ+xb4r/aq+I3w5u/Dl94es4tH029hnGpXE0TMXliI2+XE+RhTnOKKK
uuv3X3HZxVQhVyOVOaurQ/NHvn/BFj4Ba1+zb+xRD4a1640u6v01y9uS9hLJJDtcpgZdEOeO
ePxr61oorSj8C9D2OHqcYZbQhHZRQUUUVoewFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF
AH//2QplbmRzdHJlYW0KZW5kb2JqCjE0IDAgb2JqCjEyMzMwCmVuZG9iagoxNSAwIG9iago8
PCAvTGVuZ3RoIDE2IDAgUiAvTiAzIC9BbHRlcm5hdGUgL0RldmljZVJHQiAvRmlsdGVyIC9G
bGF0ZURlY29kZSA+PgpzdHJlYW0KeAGdlndUU9kWh8+9N73QEiIgJfQaegkg0jtIFQRRiUmA
UAKGhCZ2RAVGFBEpVmRUwAFHhyJjRRQLg4Ji1wnyEFDGwVFEReXdjGsJ7601896a/cdZ39nn
t9fZZ+9917oAUPyCBMJ0WAGANKFYFO7rwVwSE8vE9wIYEAEOWAHA4WZmBEf4RALU/L09mZmo
SMaz9u4ugGS72yy/UCZz1v9/kSI3QyQGAApF1TY8fiYX5QKUU7PFGTL/BMr0lSkyhjEyFqEJ
oqwi48SvbPan5iu7yZiXJuShGlnOGbw0noy7UN6aJeGjjAShXJgl4GejfAdlvVRJmgDl9yjT
0/icTAAwFJlfzOcmoWyJMkUUGe6J8gIACJTEObxyDov5OWieAHimZ+SKBIlJYqYR15hp5ejI
Zvrxs1P5YjErlMNN4Yh4TM/0tAyOMBeAr2+WRQElWW2ZaJHtrRzt7VnW5mj5v9nfHn5T/T3I
evtV8Sbsz55BjJ5Z32zsrC+9FgD2JFqbHbO+lVUAtG0GQOXhrE/vIADyBQC03pzzHoZsXpLE
4gwnC4vs7GxzAZ9rLivoN/ufgm/Kv4Y595nL7vtWO6YXP4EjSRUzZUXlpqemS0TMzAwOl89k
/fcQ/+PAOWnNycMsnJ/AF/GF6FVR6JQJhIlou4U8gViQLmQKhH/V4X8YNicHGX6daxRodV8A
fYU5ULhJB8hvPQBDIwMkbj96An3rWxAxCsi+vGitka9zjzJ6/uf6Hwtcim7hTEEiU+b2DI9k
ciWiLBmj34RswQISkAd0oAo0gS4wAixgDRyAM3AD3iAAhIBIEAOWAy5IAmlABLJBPtgACkEx
2AF2g2pwANSBetAEToI2cAZcBFfADXALDIBHQAqGwUswAd6BaQiC8BAVokGqkBakD5lC1hAb
Wgh5Q0FQOBQDxUOJkBCSQPnQJqgYKoOqoUNQPfQjdBq6CF2D+qAH0CA0Bv0BfYQRmALTYQ3Y
ALaA2bA7HAhHwsvgRHgVnAcXwNvhSrgWPg63whfhG/AALIVfwpMIQMgIA9FGWAgb8URCkFgk
AREha5EipAKpRZqQDqQbuY1IkXHkAwaHoWGYGBbGGeOHWYzhYlZh1mJKMNWYY5hWTBfmNmYQ
M4H5gqVi1bGmWCesP3YJNhGbjS3EVmCPYFuwl7ED2GHsOxwOx8AZ4hxwfrgYXDJuNa4Etw/X
jLuA68MN4SbxeLwq3hTvgg/Bc/BifCG+Cn8cfx7fjx/GvyeQCVoEa4IPIZYgJGwkVBAaCOcI
/YQRwjRRgahPdCKGEHnEXGIpsY7YQbxJHCZOkxRJhiQXUiQpmbSBVElqIl0mPSa9IZPJOmRH
chhZQF5PriSfIF8lD5I/UJQoJhRPShxFQtlOOUq5QHlAeUOlUg2obtRYqpi6nVpPvUR9Sn0v
R5Mzl/OX48mtk6uRa5Xrl3slT5TXl3eXXy6fJ18hf0r+pvy4AlHBQMFTgaOwVqFG4bTCPYVJ
RZqilWKIYppiiWKD4jXFUSW8koGStxJPqUDpsNIlpSEaQtOledK4tE20Otpl2jAdRzek+9OT
6cX0H+i99AllJWVb5SjlHOUa5bPKUgbCMGD4M1IZpYyTjLuMj/M05rnP48/bNq9pXv+8KZX5
Km4qfJUilWaVAZWPqkxVb9UU1Z2qbapP1DBqJmphatlq+9Uuq43Pp893ns+dXzT/5PyH6rC6
iXq4+mr1w+o96pMamhq+GhkaVRqXNMY1GZpumsma5ZrnNMe0aFoLtQRa5VrntV4wlZnuzFRm
JbOLOaGtru2nLdE+pN2rPa1jqLNYZ6NOs84TXZIuWzdBt1y3U3dCT0svWC9fr1HvoT5Rn62f
pL9Hv1t/ysDQINpgi0GbwaihiqG/YZ5ho+FjI6qRq9Eqo1qjO8Y4Y7ZxivE+41smsImdSZJJ
jclNU9jU3lRgus+0zwxr5mgmNKs1u8eisNxZWaxG1qA5wzzIfKN5m/krCz2LWIudFt0WXyzt
LFMt6ywfWSlZBVhttOqw+sPaxJprXWN9x4Zq42Ozzqbd5rWtqS3fdr/tfTuaXbDdFrtOu8/2
DvYi+yb7MQc9h3iHvQ732HR2KLuEfdUR6+jhuM7xjOMHJ3snsdNJp9+dWc4pzg3OowsMF/AX
1C0YctFx4bgccpEuZC6MX3hwodRV25XjWuv6zE3Xjed2xG3E3dg92f24+ysPSw+RR4vHlKeT
5xrPC16Il69XkVevt5L3Yu9q76c+Oj6JPo0+E752vqt9L/hh/QL9dvrd89fw5/rX+08EOASs
CegKpARGBFYHPgsyCRIFdQTDwQHBu4IfL9JfJFzUFgJC/EN2hTwJNQxdFfpzGC4sNKwm7Hm4
VXh+eHcELWJFREPEu0iPyNLIR4uNFksWd0bJR8VF1UdNRXtFl0VLl1gsWbPkRoxajCCmPRYf
GxV7JHZyqffS3UuH4+ziCuPuLjNclrPs2nK15anLz66QX8FZcSoeGx8d3xD/iRPCqeVMrvRf
uXflBNeTu4f7kufGK+eN8V34ZfyRBJeEsoTRRJfEXYljSa5JFUnjAk9BteB1sl/ygeSplJCU
oykzqdGpzWmEtPi000IlYYqwK10zPSe9L8M0ozBDuspp1e5VE6JA0ZFMKHNZZruYjv5M9UiM
JJslg1kLs2qy3mdHZZ/KUcwR5vTkmuRuyx3J88n7fjVmNXd1Z752/ob8wTXuaw6thdauXNu5
Tnddwbrh9b7rj20gbUjZ8MtGy41lG99uit7UUaBRsL5gaLPv5sZCuUJR4b0tzlsObMVsFWzt
3WazrWrblyJe0fViy+KK4k8l3JLr31l9V/ndzPaE7b2l9qX7d+B2CHfc3em681iZYlle2dCu
4F2t5czyovK3u1fsvlZhW3FgD2mPZI+0MqiyvUqvakfVp+qk6oEaj5rmvep7t+2d2sfb17/f
bX/TAY0DxQc+HhQcvH/I91BrrUFtxWHc4azDz+ui6rq/Z39ff0TtSPGRz0eFR6XHwo911TvU
1zeoN5Q2wo2SxrHjccdv/eD1Q3sTq+lQM6O5+AQ4ITnx4sf4H++eDDzZeYp9qukn/Z/2ttBa
ilqh1tzWibakNml7THvf6YDTnR3OHS0/m/989Iz2mZqzymdLz5HOFZybOZ93fvJCxoXxi4kX
hzpXdD66tOTSna6wrt7LgZevXvG5cqnbvfv8VZerZ645XTt9nX297Yb9jdYeu56WX+x+aem1
72296XCz/ZbjrY6+BX3n+l37L972un3ljv+dGwOLBvruLr57/17cPel93v3RB6kPXj/Mejj9
aP1j7OOiJwpPKp6qP6391fjXZqm99Oyg12DPs4hnj4a4Qy//lfmvT8MFz6nPK0a0RupHrUfP
jPmM3Xqx9MXwy4yX0+OFvyn+tveV0auffnf7vWdiycTwa9HrmT9K3qi+OfrW9m3nZOjk03dp
76anit6rvj/2gf2h+2P0x5Hp7E/4T5WfjT93fAn88ngmbWbm3/eE8/sKZW5kc3RyZWFtCmVu
ZG9iagoxNiAwIG9iagoyNjEyCmVuZG9iago3IDAgb2JqClsgL0lDQ0Jhc2VkIDE1IDAgUiBd
CmVuZG9iagoxOCAwIG9iago8PCAvTGVuZ3RoIDE5IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29k
ZSA+PgpzdHJlYW0KeAG1Wdtu3DYQfedXMG225SYNI1IiJdVxNmiaprXhhwALpKmTtoDRPBRw
gdT/D/SQ4gy5u7oFTmED0krkcC5nZg6pT/KN/CSNDf+urXTvZWda3TTy37/kW/mPfPryzsib
O1nFv7sbjK60bYbf4aa1snWt7q24uZU/7KUbRqbL/lY+3e8hXu4/SvVgK/d/y1f7uOipmKbW
tpM3twJiKl1VlZX7m1mB3lfTIrsOMtrOyDYKvp9+faVbW7VfRFZwme20b5KtMy67lspt5RP4
SqrNfgu31FI9iU+cVN/EmyY6FmOMUFf0ise8VzSIH/0S5Bipvg5XzH4YR0Dwaxrab0V8cxFG
YCEELsiX6qs0la7vt/FNOeT3+AT6pklCXdv4CAs8pZuRed/Fd1CH9dzwnY7vYB+rms1i3Zph
kFSX8QYa8A0LItPJQHIBK11vsuTN98FaqN0nR9HoI7cIdbaVH+T+Yhzadd1o1/oi6JN5ImKe
IOgc2ZmgPyeHJe8UnoMNAgErnUmWkw3sySLoAxzOj819EoUhxiSDF+Qblpa9x+rRrDRGqMfB
nQjPizmvNV2vre1cTpUTr4nPqi4mpNuJDJlksOevoldhLGUbeSNbdoo4Nn9AjFAdxYZmH0Fm
VSb5AccF6slzdOV1R5R7G2cDvT8n9JqQ1DDs1/Abucxm/HEEb5b6E4kgKyiUuwcREhDC7toR
sGjshpTkdTjDeUiCuVjKMKnOGGrTcUmIK/zFllAmn8TlPHuOB/+Y/MG430xhWa7EctvppgvN
0jT3a0NoHb7vde1XtY6XbEgo3wj9sxjQ8iZVRqFmwvUozkIx4VKxY19l92WEh9KzrlckhBct
iEAzXItQ5oUYTyMIB7LHET70M8Ioqz+H8NTyjhGewTrjsmOET/UQkbPw7FWIFsoiB2md38+/
HcIjTvv5httIGgMSkf2Il9NNq2md7h1Y4QC3Fahtp5lYQG3XgEB9DrlDF7x8iIABSY8eP093
yGP8To1DjDJJY1tt68rlJSeLPtNSMUNLve91SLcFKVD3XYKVUOzulF5SZbczfGsCCaGSSxxX
qYtUsnkO8S6awkBeDHWgAwXaMgFjESSTYUe5yKtzutpY/tFbmHPxmDMSQ7OXrBSKEDzCSBfN
mkZw7UAgql7G+N0Pv7W3uuuwNyllrdqhLIBYTHHGxnTamLoeVpxE32szQPhZVTv7fBLFjW3W
SCs3apOyQi67Bu1sUikWA+MHroHuwhkBeEzHrHe6qzw2RtNLHJI+LMEpRkDj+sk39IZBOqTR
aHfhkpn72dHehwDOiQOQJrbNVh6W2YGK8+qzuZckUfbwJG5DZAxxMVKHnu829CTzF/C1ZMQZ
MSFWlc3IJYp9UGbm0EF59H0ys8fO3Difony/3Gwqo33XE2SSsP83OZ3XvelRWlYmApr8ZD41
KFO+DrXlCwgLyVn3upvd6gwlA5mTICXUbrMj9BDu6HcGxY7bE4Npk3FFe3wxu8fPLH7FktCL
lzw/yfLdZYQ0+BKTc8YmJQBh/cVWTNcc26JP9B0CsM5zsYlO8QXbWUDbtKuEieUzMW8dKOEy
+RCKN1fsqZPjk4Jm57Cyi1NUUatzVIlu0DVXLsbAGVfZk4WFYuEcmpGFyyIDBlweSFGRKRjV
YWWdCaurdeUDDZxy4WEnUTP81SLh2xqHoqWsiRJzKHWh/0+fGRmDs1g02bjiigqJeExhMhQF
g33Rij1j2I2QGNhneo8DVBz26hr0p3Y17lrnO49ydXcjRo6CHTp4vwawUpmw3cFmbag0Qn2g
FpXhxwyZqtGOMZZxREnOWOOzCQYdlwpG7Y4pNonmV4T1oYgUHIHAKDO9PwTjSJsv8In+WZ6b
W1Qb35peHrgsgqpeOPa+hlLQLm6MSjY1eUZvvddV2+CIfzI8h7BdjYMWOAifAFxfa4dj/h5E
0weUWIEPCB9nPxu4zgzn/Qs7q7nuGZaGcfEofUEMUvEdHfsyICj61DHod4YX0Sx6gw8OKagi
fDo5DKoB0e7qZrVO7OdRWa12jQdA1huYmgCO3OnQ7/oqphXyDIfwBRqPFQ+Uxjkzs9gRQmbK
pfGVRok40hzZkT7piJkPHurP33IJOnFva3Xb11nJ8KVoTlhRzo5lBeQAsSOt9cjQBRl1O5zG
jaFP5G9fQB+FZLfbEKi4Ci3TLqGAvNgduVJlkHKly4+A15lwe6ddYOAuqn/v/uIsAkOnOysD
8uY/uIdTogplbmRzdHJlYW0KZW5kb2JqCjE5IDAgb2JqCjE2NjkKZW5kb2JqCjE3IDAgb2Jq
Cjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyAyMCAwIFIgL0NvbnRl
bnRzIDE4IDAgUiAvTWVkaWFCb3gKWzAgMCA1OTUgODQyXSA+PgplbmRvYmoKMjAgMCBvYmoK
PDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+
PiAvRm9udCA8PCAvRzEgMjEgMCBSCi9UVDIgOSAwIFIgPj4gPj4KZW5kb2JqCjMgMCBvYmoK
PDwgL1R5cGUgL1BhZ2VzIC9NZWRpYUJveCBbMCAwIDU5NSA4NDJdIC9Db3VudCAyIC9LaWRz
IFsgMiAwIFIgMTcgMCBSIF0gPj4KZW5kb2JqCjIyIDAgb2JqCjw8IC9UeXBlIC9DYXRhbG9n
IC9QYWdlcyAzIDAgUiA+PgplbmRvYmoKMjEgMCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5
cGUgL1R5cGUwIC9FbmNvZGluZyAvSWRlbnRpdHktSCAvRGVzY2VuZGFudEZvbnRzIFsyMyAw
IFJdCi9CYXNlRm9udCAvTEtHR0VKK01TLU1pbmNobyAvVG9Vbmljb2RlIDI0IDAgUiA+Pgpl
bmRvYmoKMjQgMCBvYmoKPDwgL0xlbmd0aCAyNSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUg
Pj4Kc3RyZWFtCngBXZDBasQgEIbvPsUcdw+L2ZRCDyKUXQo5bFua9gGMToLQqEzMIW/f0e5u
oQMK/v98+jvy1J274DPId4q2xwyjD45wiStZhAEnH8SxBedtvp6qZmeThGS435aMcxfGCEoJ
APnByJJpg92ziwPui/ZGDsmHCXZfp74q/ZrSN84YMjRCa3A48nUXk17NjCAreugc+z5vB6b+
Oj63hMCJmDj+RrLR4ZKMRTJhQqEaLq1euLTA4P7ZV2gYb90Pj61WTd3bpn2qzM0tePnqPZpd
iThVnUcNXIL4gPeRpZjKo3X9AJXbcdYKZW5kc3RyZWFtCmVuZG9iagoyNSAwIG9iagoyMjkK
ZW5kb2JqCjIzIDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9DSURGb250VHlwZTIg
L0Jhc2VGb250IC9MS0dHRUorTVMtTWluY2hvIC9DSURTeXN0ZW1JbmZvCjw8IC9SZWdpc3Ry
eSAoQWRvYmUpIC9PcmRlcmluZyAoSWRlbnRpdHkpIC9TdXBwbGVtZW50IDAgPj4gL1cgMjYg
MCBSIC9EVyAxMDAwCi9Gb250RGVzY3JpcHRvciAyNyAwIFIgL0NJRFRvR0lETWFwIDI4IDAg
UiA+PgplbmRvYmoKMjYgMCBvYmoKWyA4NTAgODUwIDUwMCBdCmVuZG9iagoyNyAwIG9iago8
PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0ZvbnROYW1lIC9MS0dHRUorTVMtTWluY2hvIC9G
bGFncyA1IC9Gb250QkJveCBbLTk3NyAtMTM3IDk5NiA4NTldCi9JdGFsaWNBbmdsZSAwIC9B
c2NlbnQgODU5IC9EZXNjZW50IC0xNDEgL0NhcEhlaWdodCA2NjggL1N0ZW1WIDAgL1hIZWln
aHQKNDM4IC9BdmdXaWR0aCA1MDAgL01heFdpZHRoIDEwMDAgL0ZvbnRGaWxlMiAyOSAwIFIg
Pj4KZW5kb2JqCjI5IDAgb2JqCjw8IC9MZW5ndGggMzAgMCBSIC9MZW5ndGgxIDQzMiAvRmls
dGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAErKSpNZWBncGBgYjBIz6lMYwADxgwgpZSR
mpgC4TP8AdJmGUABCJ/RBEirZOSWVED5EUCaIyc/GSafAOSz5SZWFEDkGe4AaYW8xNxUCJ+x
B0irQOWAlEOMVnGh0w12BgbZqQLRcsGf+RkRkkisYIaGBCQunHkWuzjIECbGFwy+YIVMDAIM
+si2MoDkWSVnRTa0TIvnt/nKwA2x9cDZHW9AOi72nH/wn+3/XYb/YPdLAsMIAkDK7vwH+omR
ASj/HCgP0QiVBlJMQAElhgawgCCDIEiEQen/P4Z7DLsYmIHhzWAuamwqrmxqrL2Kc8+ejatW
bd4DVsvIIAQ1iw3oWgYfb3d3Vy9t32Bd38y85Ix8BgYAtrtDHQplbmRzdHJlYW0KZW5kb2Jq
CjMwIDAgb2JqCjI4MAplbmRvYmoKMjggMCBvYmoKPDwgL0xlbmd0aCAzMSAwIFIgL0ZpbHRl
ciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBY2AYBaMhMBoCoyEwGgKjITBIQ4ARAAanAAIK
ZW5kc3RyZWFtCmVuZG9iagozMSAwIG9iagoyOAplbmRvYmoKOSAwIG9iago8PCAvVHlwZSAv
Rm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250IC9FSk5FTUgrQ2FsaWJyaSAvRm9u
dERlc2NyaXB0b3IKMzIgMCBSIC9Ub1VuaWNvZGUgMzMgMCBSIC9GaXJzdENoYXIgMzMgL0xh
c3RDaGFyIDk2IC9XaWR0aHMgWyAyMjYgNTQ0IDM0OQo1MjcgNDc5IDUyNSA1MjUgNTI1IDQ1
OSA1MjUgNzk5IDQyMCAyMjkgMzkxIDQ4NyAyNjggNjQ2IDQ4OCA4NTUgNjYyIDYxNSA1MzMK
MzA2IDUyNSA0OTggNDcxIDQ5OCAyMjkgODk0IDI1MiAzMzUgNDk4IDI2OCA1MjAgODkwIDQ1
NSA3MTUgMjM5IDUyNSA1NzkgNDIzCjI1MCAzMDUgNDUzIDQ1OSA2NzMgNTA3IDUwNyA1MDcg
NTA3IDUwNyA0NTIgMzAzIDMwMyA0ODcgNjMxIDU0MyA1MDcgMjUyIDQwMQo0MzMgMzg2IDUx
NyA1MDcgXSA+PgplbmRvYmoKMzMgMCBvYmoKPDwgL0xlbmd0aCAzNCAwIFIgL0ZpbHRlciAv
RmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBXZTNattAFEb3eopZpovgsUdjJyAEISHgRdpStw+g
n5ER1JKQ5YXfvue7TtOSxTF8uvNzj2as1fP+ZT/0i1t9n8fmkBbX9UM7p/N4mZvk6nTsh2y9
cW3fLO/JnjWnaspWTD5cz0s67YdudEWRObf6wZTzMl/d3VM71umLnn2b2zT3w9Hd/Xo+2JPD
ZZp+p1MaFuezsnRt6ljurZq+VqfkVjb1ft9S75frPbP+jfh5nZKjI2asby01Y5vOU9WkuRqO
KSu8L4vX1zJLQ/upFP1tRt29D92sy0J47x/LrNhsiOB9vlEMRPB+ZzEngvfbTtVIBOJacUsE
Yq64IwLR5j4QgZhUfSQCG20VKyKwUVSsicDgVrEhAoMbxZYIVK3nRATmBlU7Ingf1UbgXQjv
Q6WIq2AptRFwFUTtG3AVRO0bcBVE+QZcBdFWxjWYb659A67Ce3oj4ipo8kERV0G0jXClH8Wd
qrgKmpQgPwZVi7gG8829qrgKNjIFXIP57tQVQwyWUjXHVRBrRVwFChZxpXliVBtoGexrVVx5
LVR3VsWVwyJu9SZzXAVVdZXjKlhZlyHHVTBYLyfHVdCzjNjcoKrT51QNltKB8u4NurK5uHJY
zI22Mq4cB5FzzIqIryBKnyEGUbcu4iqINMn/4e/FX4dPfwS2KgQjJcvdMWhJHUZeQzR37jAR
b0FLajjiLXC3uXjzXFXrAe9o7lwtBuMuGGxzcY92t/nfUcVdsK9thHe8nbVuYMRbsLLe+RZv
Qc8M/s9Of3x9oD4+KM1lnvmW2FfMPjP6fPRD+vjQTeOkBYw/Uu5EWQplbmRzdHJlYW0KZW5k
b2JqCjM0IDAgb2JqCjYxMgplbmRvYmoKMzIgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlw
dG9yIC9Gb250TmFtZSAvRUpORU1IK0NhbGlicmkgL0ZsYWdzIDQgL0ZvbnRCQm94IFstNTAz
IC0zMDcgMTI0MCAxMDI2XQovSXRhbGljQW5nbGUgMCAvQXNjZW50IDk1MiAvRGVzY2VudCAt
MjY5IC9DYXBIZWlnaHQgNjQ0IC9TdGVtViAwIC9YSGVpZ2h0CjQ3NiAvQXZnV2lkdGggNTIx
IC9NYXhXaWR0aCAxMzI4IC9Gb250RmlsZTIgMzUgMCBSID4+CmVuZG9iagozNSAwIG9iago8
PCAvTGVuZ3RoIDM2IDAgUiAvTGVuZ3RoMSAxMDI4OCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+
PgpzdHJlYW0KeAGdWgd4HOWZnpl/6pbZnZ3tvWmLelntqq56tYpVLMmyJCPJBXfLHduxjRsh
xphiiggESLGBGFMSnnCUkFxICCSQQEIJdyHcc0+AJORIuTvA9o7um9ldSbbJc/ec/czOzK/d
+b///dr7ff/s2LZzNcZihzCEYdObJrdiyj/iGjjdvXbjdWvS9+gQhgVvvnb15Kr0PXYJzvFr
YSB9j8fgHLx20449mfsRDMPZjVumM38nPoPx45sm92Sej/0r3Hs3T25anf5+RC/fv8NgmOsO
/Qr3wN91ePoPV3wOYIeuuWJIuX31i8flhzTiXkyP/QhjMALORdjxzO9JDIf/GEYTp4zRn65a
qav5L8zGKn989k/7fy5fvH7ylbaLF1InuI/ZONxy8IT0P/gd87XUuximeuDihQsPcB8rT8r8
UTk1kjwg8AsMIx/EAuQodo5sxibJj7Fz6CM4HsXOURpsBUHCeATux7Fz9NswlgtHFzZN+uE8
BecR5btt6ANMx7ixWji70ZvYGBnDZtEUNgrna9BFbJyYwXLQi1i5PI6/hR3D/zj3JvqGcj1L
r8Jm5XGyQvn+LPEK/NaH9RHnMR+Mn0b3YX7qaawc7cai6H7Mj89huUQQa4fjWYLC7kIWDCe2
Yy3EJuwYHHtROXaCCcO6eKwfjnY4zsOxDY61cBTDMQ1HP7qEtcAh6zeNM4ZpMBr7Ctz7sHoY
Q1gIC2JmzIZZsABoJ4r5MTXmxsKYiBVjWviuBuMxCiOxMsyF2TEn/MqHJbASLII1gB5VmBHz
YnmYB8sBvVixQsyBFWAG0HEVVotVY5VYEsvFYlg5ZgL7FrAa0F8cy8dKMR1Wp+hoB7YD+w5O
4X34YfxHuEQMEruJHxOfoFb0NfQOaSLXkT+n8qiV1HM0Rg/T5+n/YlqZW5h/Y9ewj7Lvc0Fu
O3enilB1qI6o3lX71IfUr2lMmlHNj7R6bZd2j/b72s94ni/le/jj/PP8Jd3Del7fpb9F/4Ew
Itwv/Er4F4PO0AZyUBgmbUdvUDwgwoDU3VgPQCb4BOUw8gTDGOmAv5AoD4fiZWWlSaI8Fgr4
eUIZi8UTSVRW6iYQfDM9kiTkexy9cWkU9aZo4kCgbqiMctt1Ri1NEU6roaAmRz+wIqem0MUg
hkYUy0QSjf4lG1v87zKCy2R2GVjW4DKbXAKT+heKv/A3ir/YRG68eBrR1WN1QXS3iiVImn7a
bbXlVvs6hnSinlSLesHMMgZBE2keSx03OeVnOE2m9LNS3RjoKDB3gTxAGUHPIQzLMZtpZVlh
5EM8CvhDoXgCT6/FwgSQj9zJ4vocjydH5MgtqQ/WI5UYcLpydDiLP0lqbWG3N9fOk/vw3+H/
XGt28CRiNBxeLb3MaTmS4h1m8kk1zyLE6tQnU/sA23Ngszig7AabqQCEjTwZ8PlD5UIsXuYD
wEwy1G6ExwqJQECQcRYXLkncU9E7PdMhnbdEoxY8tOP0dKk5ryG3fKwlIqXsFaOdT77Y1B+3
9eS0beh77UL1SFMI3167tj+Za/KEycNhT/7g3u7CwbYKg6q8fzOBF3WVO6XxQHVv6rdVIzUe
qcKZ6AefmJz7C6mh3GAFWI6RT2s9puiTlsWT9Str3mR0g47TeiY1BMUa61fu6zjws1PdA3e+
frBi/Wirg6UQyapZvrR3pnfo5KpE+fQtK7q398V0jIpG39NbDbwxGnYMfvOv9z146bExkzfX
wYt2g9EpcuGicMvxH+7f9/zBhlBRiBbcoDkZu1OAnQG8TUaOuAw5ZhFOp4a+9Zcz0n8oKOU8
9NF9fU/Ftjxy/LEn9j+yrZK456GL3+pP4zH8jY9m1z11tPOSkDz0Q1g5zID2wwz5ysovf76y
dJ+QVVIgfYn2kyotm7pdnopYw2pZioIPicafZMECSA6uewic1arINoPDwKanZQ0Oo8EhsNJ6
Tu8UDXY9I5WwggMWhZ2bu4AGQQKIbekVLp4w61xZY0GDMDkjhfAfMDCBcl3PGr12q9/Igjit
yuiLohNmamf0DpPoELjU7xktQ1HwQZ4Pe8DD5FlXzP0HuYfyyhFJmfUyDccTgmyhsgUoixdk
m5UjQdomSHIPyWoYTcXEkdENj+yqa9n78OqafeXSrwWB5MAZvqo2G1SGqrGpVSV3fvyNofGH
/3xL5+HVLXYVOSG6RDZUGOr5yve37P/B0WaXC7/OHwQhWVbvNEiiPeTyWzXj5/5y+p4Lj0/a
A1G7P40QPgL+a8roSJZESItCmPAR1uizyevnTD6LzWdk7SAbLFfDku9mr7I4fwZPKcs+JRQK
47CydPSaf56QiQUmI83guNmMPmOMfkcg38xIwexMrNFvlWfCX6H1Fp/d7hUZrUEawF8TGKds
ELReRdyQum4e9nk5Uj8k6jgNQ1IgmNZuSc2l7rGLGStcArLZL7PCtKOZFHtAS8CyuNSLluj8
5L+UI84So0PkwMbOZ5d68UFOcGbWS+eBXdVk1yujFsDlkFdIhPHAoqXL4d1NWPAyee3ypYnO
Y40em8UnsoRUhtQml9HkNqoJqQ0Ha7NZYcH5jmu9xUErh++m8ONquydk26RziJoF8NdePM2o
GESC40MMn83KR57JDWrsEcelYXTGnWtTc6LLlNYxxGgBMqgcgSASKkKCigJms+kLRHUjS1lI
DqIZkMgDWpNdm7CHAwGTdK23wUkQBCt6rFaPgc2397vCHpeAV7nipSVWHLxT9NjMXgPbZoR8
oXaVhon3K79U3X5n56W/zyvtkYhfZYl6Uj+NTV8zXtT77V7i+xDpwcE1MqObnvsz+RHlA86Q
9dsF/yCUwLQoXpIfdd7+3unb3jzR3Hn6vdOnfn2y5anwiru3br17ZTQ0ete2mXsmIsSd9116
YuXwmf9+YPbCYyuHvvX3hzc/f6Jn8KZn1277wYnuwVPPydEQIsVLoFEncJa0116uRPBVclFM
RC/V7350z+2c6LPJxpprx0253es2dUWfqh4ez7//qz1rW4Po9sl7N9dIhfPagVUzlrqx64Z7
18f41OeRtmk5g07PNVA3wGrDwG8wKuMz4XQezQSFTB6jlDy2aO3wO5WGNi7fcTRZcud0FoMT
vzrVLkaTuR2b2yNGVjp3JRzbLB6B9tWN1rjzh858+sA9n8uY/O2+vtNHtxbUNPl1YoB4f/Nz
J3oGTj5z7bYXbgKAnpflBIRINSAUx5oXrD6MChFk1gVPl/Ou2eJGmcxrEc1mPBYKh0KZ/Euq
aWPQbfcZ1eRuU0FysHp7FkNIwWJJg33J9p5woHGs0hsriBh38KyUal5qqyu79aHm6UYPeAAL
VqLX4CWx4bpA6jfz2EL0pZC2YmhLU8Pa3iojn1fTUyL9e9CFjnWtszC01OWrXip7btvcn9E0
oN2R0bK/kMyCnKZhhXTm/srsTKPppt0PjjdsGa62qCFGs3zZ0pnOivGmYGn/us3X9pdVr7t1
MG+4u0akSQLRakZd1DxeFV8as5cOrN+8fqAM37DiZmAYXr81xwN8jPFHAu7E0rJET3VJWXJw
prfv4FCBzuYR1YJVNEDSdgZcruLGnHhPTWlZ7cCMLL0OrPRt0IE/I71vAXlf1kfkrILeVnLl
6WxQlU5ncyk6qmRSJY1d/No8fFOs4BTFNLGDeWrnLtDvQ8yU49t8UFMYnRzegNXFFwW1hfBW
CvyPoY6QemfU7clz8qT0V+IC4u1Rry/fqUPSIzQuhLyeoMgQeADHjYgz5ridPiOH8CiBuxAt
BlzugB6nQrwgRwOBR69fKspek9+2ADlELK+++CJZpdaBJQARvPgTsloF1xRvh6oGcyt+bIQq
Afj2vFkuiAz2aCmLxxOizEplcYmOdNA3sdJtakoX9rlzzGrqO7ZSO2EpsX0XqUW/PRjVU2r8
UymQxQv/LfGuLAwJnEC6qXxHdeVMAt+l4iH78Haz7C1jYGd16BXIiPWyt8juDCG1fJFbl5XL
FGue8ydJJTkwaS5oLiuNJ1Cd3umwe/jqW/vatvcVJHc8tG6/uaSnsnayo0TDQrxkHI1Da2KT
Xx4MffNk86pGz/KlDVtqrRoNTWs0o3WtOa1rGrq2dua0xpaWO1wBF6u36Wwue8Al5i87MPii
paAu2jrQ2AzSzoK0b1IzgBrkiCxnCWfp6UImENJcPhuDGcEMgiYJ9GbZ9C3jeR2trWEgYyYI
/DQjeq02yAKRJe3tkakTw5HzpthQvTdZ3xJu3t+UHEnY8A93Pnu0VQhVRTcDrAClhqUqFP+G
j9TvoxUBfc+Rx3e2HF5Va8htLJVmB4ZrpvfJXjAK0nrRy1AFfgGjVgh2wA/e657n08hLUIyt
ZslI0eSdq8sbZmaX5/U1l1s5mjBodeGaZVW7D/rqx2sqh+ryNHJe/bpgE7S2HJehft93dh57
YW+13u638qLVEPb4Ir7vnR8+MpIXzAuwoguwuwakuZfaBPVPmuGnOc9iTUNAnM+lCCLhogie
QPcygtMol1ZtsyumbxqOlE7durL3SD1j9Mj4cWeavtRcB2gBeg2+2vrWsC0L1u7uoe4jT0zt
ePZoW0sToc7m1lQL4DS1v7758GrArakEJBwHCWfBFvOgcgbt0gHfImxAyYtrEsIUjisSMmg2
bEs96W7d2le/qqNIw6hpRCBGHR+aqd9ydltVzcwD0+vvuKbgDLpud+1Y0g+cIOxbsmeo0GQ3
MbzNoBV1GrXNKib3Pr13xz9d39K8/asj4uHThV2rE7IOc+YuEMepPXKEydqbgotJ8QKQcVFS
AddRYjJ4jMJISOI4sDyaMbmjjpyYl3+ZVXOUQfcyCzYH9Ik9qNfL8flgoH1TZ6AxqGERpRMt
PMWpOWtZX9UUI9jFoPfSn6CWghCiZpHJGxTtAjM+ccNQVKvTiFA7IKxcuh3diH4KHYcebGUa
N5kvKTElBPnZZDRbMokuy98T4OJQvMufsqBmC+RCyH7zLi2Xn6FwmIfsmPabG0Xd9QFn6fih
nsS0w2BpiP+paWt/YWzDmZlNs1P5el+Jt6SoNMcTjI1d3xVt8+B6QZCk1ePFbUWW1StK2oss
Ayv7/uCNWrmju5asTjrQjoAnOFzUs2cg32U2FLoDhYSK8NUur05uXVaSU7885ktWlNlsXfm1
14Ryxhu79w4WcKxP+uvYWm9FR2T5Gk+iPTVRVUewtoJoxNTQ5CpOyrqahZj6AESHUsXfspxe
Dl40sxBjs2xRSCcHE3qANaRjgLWwozi5vxluFXabDQ1tt3SM7uvy2bJqIHTdE83BkWWpE9mR
xfFgSUftmhsnwZqPzV3A+6giqFh8l8mTIaui3FiR1QD448kr5xTzq6vy5GN+VnRUrmbkmgsv
rsqNVsIB8XvuTel2fBXMEoS+VZaVZZiCorqFmHjZhH3u+lVt3gIrR+KI4Rg6YPEVufmsYcqz
5+ZVV+fqVu0bzGNVWsGgletVyljQ3oG+fbUgaez3A/bguQp3V6j7F4B+ZWW1n4W85QhYdbR0
9EoQ8EHWYIMqy2/itDrpGXyzVq0QK8RoOfxvkvZq+C+9AdlNyyHwf05j1UvPSDmCXFmAZeBJ
kO6Lq8er0J8HfUGxGfuifgnxCQhado0A71X2ddVARuOmDBtJ5yYT9cu03YmsMb+5sHJ7i4w+
VFuMOb+psHLHvBnSBqfF7NIzXac6KpY3F+sL+pa0BYd3dXjmpSQClVcY5NUjwKfUgAunZncv
67UXNURKmnNFsNSurN/Auv5vfpNZxj/2m3mB7+r+X/zmMqFAmGtkRiJnzfdAmv9TVYXeq9r+
6LYt39ocr9x+bjucE+cdyfW9HeuafY669b3t65u9+O83/9PxJY0HvrsNzp1w3t9xeKoytvJw
d+fhycrYxGGYc1Y6jd6EOS/nFVebr+kf84rbJiLNDfXBrA0DCEaTw8BEu7r7Cqa+IvOKMoVX
tIab9zYllyfs+B92PXekTe+PBaRklk6QfwAFQd9QzV2Xm4yauo4+trPl+lU1YrSpRLpnYKRm
1f6MHRJnQVroYizOSV8Q49Ly0sRZguZY1uIKmmzF5VWBRUIqppXTUFXp0vqCLg2JcDRldgsc
x7HGwq5E6vGsky3o6ki8OaxDrErF8Q6wnr65PxOvgTT/j0qFeK1s4nBP8XBLsVlFypVIXt1Q
RW5zqSNcv3RZX3042r+vP9heFTUxCFxaRXP+eEdRbn3UFKnvXzZQH8b5lo2dIZ3FZgx6RIhP
Dq/DEIjnhGIRjz8vOVRTPtmRrzGY9BqdWS/Y9IzZZhYDxc5wecTrz60ZlLH0zX1CbCIfhb69
7NPpDpdwZSInTIvTvRJX5fRPbGL13mihpXVVveuAziC3AL+UTRofyrzXoPsw0WYJOo0sxVHk
Cpdfz3N0DlSOBJ/O5G9luwlvpXO9pBpfyak4irfKsp2WGRt67jK/zPK1eaImKBwJunXZvAZM
zeAyWVwC3X2n4oCMMU03LEXtxcl9LcDYIL0ZuPnwsXtZT83aG6cIfzZCpP6zd2VTzsgyYmd2
RJbGD9l1H0gDXVLZ6pj5LtJ8T5CwiJZ0wQKV3T6cQIT0Kqm1R9zuiA1qrNdISm66WFwB6KpL
JLpIqESfw+IWGHQ/yak0zKWH5a45yfIqNKwxcAhyHQEfXMqu0RAfcMCPCFYNkpTPXaCOgiQt
siTQoctUfijMLCr9MhxssUyLxKOOkpT0KdJaIm5Prk2DnieIx5DWDuVgGO6kzykSorHF6Tew
6DcE8RLBGQA0aCMRbxP4WwS0AuxW2KFA9zNG3YLUxEmOS21fWIPOyHBqWAKkq5Sd42AJWjBk
yJ4pa/aOYFUytlHAdgmsqAis0KwUYVC/ooWtiUV14XxBiKMmVgx73AGTmnznbVJt8sMOhYBz
uFX6lMXFsNcVMKrIV39JqgSPw5VjIDjp83xe1FCQHBl8tfRVOCFKI/L49/CzvKglEa1ipCfw
XjghUm3USROy1iEy7gfJgrB1htJVYUKUu6ah2HxxLSok0mxkiLI9dEmp3SsQ9H5Oj6QXWH3Q
7fYbOQrH0We04Pc6gwItPaUXKI2RxytJgwqNmaw8BTsl2lQh8ZaopsD2DTBvrvQevh17H/bV
lFzLMGklJ8SsXvHtNG8RbqS0ok0ULCqcPKa2Bu22oEV9yhMrLLC9xqggkgLYuHjI4dXTtN4r
Z5d26Xf4SXQHZBfAOhs9s8+UA/4XzHSSs0U83ggozRrxeiI2jtZahC9TWoPNoMx8RGMJ2qww
M/J68x1qtSPf6y+QzwWpbkWWn7MqBhoCag4XFsvy7NynGVm+oH84n3wyfo1fJcWVUl09e8SX
FsfnKwAXshcArnfBnJsBV7WM6yIGurkoWVMoH5vaigpb4IDv4tKHSEV9X2ZNlgz8GfrGPERq
jS6TzWcgaWKc1IpuExSBJPVXLXQ4GK2opfdpdRygb9TCc1rw7xKFRC3sfcr+qmzfZPa9iEKD
IE0Y4B/+dej3UPjnYbcnFHLTgh1+d0w6i/+dOgE7tBhOQ2/RYJnftytEss4y24/4JyvHV66g
cN5lM9hFDYr3Vzg9lf1lOOyzmC1OPUFNvSwtf+ttafRnGkFNETRLrXn9nd/OzPzrb95YC5uJ
YPjwCgCO7YX5PoT5gK8rEU5es7wzGDeUx4hwKE3jLGYD/qGzoi+ONLBpZXdpcWpsYmKCJPRO
iwn2XIi1OwnbzG/feX0NlH4EpRY0r+Bn334LP/syp4ftL5omX5V6ZUs8gdYQ91A7Ad1sJ1fu
jKGMupl520yPmE3EEdhoMBiAKVtURp/FCu0oXLrhsrHiEDqepRL4L7JXsMuUrhzY9JheD1Uj
Nqel91CF2FbsCHZUWa+S+6DmgyJRLiCUNo8lkXZyBtFy1oNxpRV0WdMiXZgHlWKSltMipbQO
yEztmMDpPUIoObq7O9oaz2Ggz9Liy2ssC1pVvLdiYFuXtzpeahdIZ8hg4yliub64KdpY6jer
ira9cMuup29a1ZJrZsoO/PrBjl3DcWAAFIFDB6Zy8nDPs1LqG+1qT8Xyg4/+7uQ3P7m3K/Vc
aGkZsIeAmSuvs5ZW1IUuXkJ4883Hd4+WicHKnEhlUC/4imvac/O27JpZntB5i30jPA+bE4wU
Gx6Ito6v3Vg6fN/uttjyHUduPLg1vOXp452CKDA6i8AbdBqV0ciPfPODm2M3zN5/9w2rq3pv
+cUP6pujDf1DfZ7OpUKgMoz6Adl+yNrPKH3yBNaWtqT5ujtttunWgbLji9Llg9wEssTj8qZv
tuqOo2dqZs5sWPW1zVWRJZtbasbqfSXTs2umTo3nyz2gti1Lwu+4KgbKN25xVA7XrN6Y629Z
21y3stZz7OihI3jX4JHRwtz+Pd21a4aW+D0tfWPx5t0jZUV9m+vKJgY7vIHOZSuJlbnNxbap
ZeGmmkpP7EDq64VLGmp9nmRjR/7k+g1yrISVvKTsb+Rdvg55AdBbA4uZ3w8m0UtFmx6/fu/Z
NXnFGx8/tA/Oj/OOvJru4mXra83uhtXtFctqIYQSX7njv5+YHH740wdOf6qcz03es2tZwrb0
puc23vqzQ1XBpoltx8AXz0Nr437KAm9WpGuthbaxwNB0unORyMmUUrBjDozjfhq2RVNjjEZN
07ADi/MX5GYKdLg5PJfUGKwGYD30H1meo5plssjo7bAJK3DonTtUpNZtEax6Df0CIkkwMDV9
8RSnxKBtIMe9gAE0GJSaLyuHzHOuaIwqxi/3XRhG6W3fS3E6LlXOm3QMUuk0F4fXVRqc5Utj
SlsUki8Jm+fW6uUbqidOjhea245veZUog0Yx1Sk31Rm922x0WyxaXDV2256pvLzuKr8/4mcN
bhOQWd4UDFjLx/a2JPedemzbW5wB0iSOrQV93Qayyu8/Ke0feY8gLmOT2TJIb6kp2W5+ZKGx
uyC/yY3Qbckdj2xomBmp0rE04rVc+cCW5sZVzf68geu694GYDK3muZnGdR1he6yvvGqyq1Ql
EwoIrmLVsi31o19eUeBNjlY3bVlagG9bfmpNwuTy8DwkjaDTm+P1J5eVJkbq/aAEk2jTMf76
5YlIR9wTiAQoncMse5wISywc3NlWu66vUk0w5Us3yFGzGJjSr6DjnytbhpxNFvXf5nWTbTKA
XZihge9DvzIabstuWqb+qNFrIQmoGPwNSnTnu30lbv1tgkl6kJBW4Gfxrb6Q9Jds1YPrab3b
KrptFi0yQBiFF1a03KWfBIg/pKoA8WmQ5jHY58i8mZCmosrLJIv3ztFjiOJoqZDSWYJ2fwjY
Ef7H1O2iSKl4jvgbb1LT5IsGl8PGX3xNA1mThvxJdkaCIpgBlJHY3Fw2phC0/PYIzNuCjaO7
yBC8myRncVqmY0ovL4HHlc4f7FqDCu8iVTr1pY9VGmjx0EiwCMBENan9xCHI0ujrNo8WBLmZ
CgVh211L4DeprUUuPwgj/Vh6hVGbAjDPamwCPU36FtY373o4LseyeNxskffHnyZpFX3pE7We
IwmGVxPHUgdhDgJ2wNTIqNISScFhVCNph5yjgVWbNBRei5fTanPABRmUoKXtFFAg+R8O73ng
yhUNb2BhLZ09Ld3teU2TG9dNbVv3Pz0qW4IKZW5kc3RyZWFtCmVuZG9iagozNiAwIG9iago3
MTQ1CmVuZG9iagoxMiAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUg
L0Jhc2VGb250IC9YR0VWSE8rQXJpYWxNVCAvRm9udERlc2NyaXB0b3IKMzcgMCBSIC9Ub1Vu
aWNvZGUgMzggMCBSIC9GaXJzdENoYXIgMzMgL0xhc3RDaGFyIDMzIC9XaWR0aHMgWyAyNzgg
XSA+PgplbmRvYmoKMzggMCBvYmoKPDwgL0xlbmd0aCAzOSAwIFIgL0ZpbHRlciAvRmxhdGVE
ZWNvZGUgPj4Kc3RyZWFtCngBXZDBbsMgEETvfMUek0ME9hkhVaki+dA2qpMPwLC2kGpAa3zw
3xeIk0o97IGZeTAsP3fvnXcJ+JWC6THB6LwlXMJKBmHAyXnWtGCdSfupambWkfEM99uScO78
GEBKBsC/M7Ik2uDwZsOAx6J9kUVyfoLD/dxXpV9j/MEZfQLBlAKLY77uQ8dPPSPwip46m32X
tlOm/hK3LSLkRploHpVMsLhEbZC0n5BJIZS8XBRDb/9ZOzCMe7JtlCwjRCtq/ukUtHzxVcms
RLlN3UMtWgo4j69VxRDLg3V+AW40cBIKZW5kc3RyZWFtCmVuZG9iagozOSAwIG9iagoyMjMK
ZW5kb2JqCjM3IDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvRm9udE5hbWUgL1hH
RVZITytBcmlhbE1UIC9GbGFncyA0IC9Gb250QkJveCBbLTY2NSAtMzI1IDIwMDAgMTAzOV0K
L0l0YWxpY0FuZ2xlIDAgL0FzY2VudCA5MDUgL0Rlc2NlbnQgLTIxMiAvQ2FwSGVpZ2h0IDcy
OCAvU3RlbVYgMCAvTGVhZGluZwozMyAvWEhlaWdodCA1MzAgL0F2Z1dpZHRoIDQ0MSAvTWF4
V2lkdGggMjAwMCAvRm9udEZpbGUyIDQwIDAgUiA+PgplbmRvYmoKNDAgMCBvYmoKPDwgL0xl
bmd0aCA0MSAwIFIgL0xlbmd0aDEgNDY0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVh
bQp4ASspKk1l4GBoYGBmYEjOTSxgAAPGBCAllZ5TmQbltwBprYzUxBQIn+EPkDbLAApA5U2A
tEpGbkkFlB8BpDly8pNh8jVAPltuYgXUfIY7QL5CXmJuKlT9BhCfYYa5I8Os/Y4Mf1odGe6Y
ODJYHHdk8NjjyKBxyZHhAxCDaBA+b+QEpku6IeIgPTA5ZDYj0FQmpq0MNgynGNgZmBgEGPQZ
QGIgwArkg9hsZ84+jGGvj+e3+cohzQGWWvRYXQvEOBtwVezX+r/pAgwcgUAuJ1wvUB+73T8/
BmcBhl/rf1UJMMBlwPqBBBMbUIjJEsxlhMryMLAx8ABFFIF8mCtEGURBqkFcViAExgI7UIGg
oqAqkGBkYGH4o8B84I8DK8NvBgWWA0BVQMDIIATVz8bAx8AQ4e4a5uGv7ViUmZjjGwIA4rFP
vwplbmRzdHJlYW0KZW5kb2JqCjQxIDAgb2JqCjMyMwplbmRvYmoKMTAgMCBvYmoKPDwgL1R5
cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvR0ZKT1daK1N5bWJvbE1U
IC9Gb250RGVzY3JpcHRvcgo0MiAwIFIgL0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nIC9G
aXJzdENoYXIgMTY1IC9MYXN0Q2hhciAxNjUgL1dpZHRocyBbCjQ2MCBdID4+CmVuZG9iago0
MiAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0ZvbnROYW1lIC9HRkpPV1orU3lt
Ym9sTVQgL0ZsYWdzIDMyIC9Gb250QkJveCBbMCAtMjIwIDExMTMgMTAwNV0KL0l0YWxpY0Fu
Z2xlIDAgL0FzY2VudCAxMDA1IC9EZXNjZW50IC0yMjAgL0NhcEhlaWdodCA2NzcgL1N0ZW1W
IDAgL1hIZWlnaHQKNjkzIC9BdmdXaWR0aCA2MDAgL01heFdpZHRoIDEwNDIgL0ZvbnRGaWxl
MiA0MyAwIFIgPj4KZW5kb2JqCjQzIDAgb2JqCjw8IC9MZW5ndGggNDQgMCBSIC9MZW5ndGgx
IDQyNjAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBhRcNVFRV+rv3vjfv8ScD
IgKj8aYnEA6ImvkDBAPMoDmJIKgzaDXDgKCJsIokq7WcPJaNSbPl0bbatLI/PVtvMNqhLaXa
fs5Z2zx14uymtWquedosT1u2bjJvv/tmJGk7u+/Ovff7u/f7vW/u61q/sQUSoRcY2P3tvk4w
nuRNOGX5u7uUKC4cBRCFVZ2t7VE87hjie1vX9qyK4smP4dzf1uJrjuJwGefZbUiI4mQWzlPa
2rv4vvgkcz3y2g5/jJ+8C3FTu29TTD+cQFxZ52tvwRkfcy8OUzo7NnRxDPFaHKZ3rm+JyRM3
ANsA131QAY8cqTBmDhOUotAKIl+DkBmKYClCX4l7DQrnIy/SI6m3JZd+J0+WDfJTC14t4cD7
kb826nqkTP5cTkA0wdiPM3CdnBApw3FZ5ODlafLnoxzO5Q8NNaRWpNE8bLk0FzpIOorcZoyL
jbHcGIv4SIv6i7Kzw3Ra/z4+FfRPzsdpij3hVFb2jLzU7NI8jk+0l6zNzz55IDP7FPaDeTOz
t5fOzN6KvQh7N+JcLu9AfnZHXkd7xz0d9wpzID0dbUlNke1h8tnLS9Pi0uLmBMPkiH2eFHxN
Ch6Sgq1SsFkKLpeC1VJwthScJgVtUjBHCk6R0uRU2SyPkxPleFmWTbIgUxnktLB+0m7jEUgz
mflkEvgoGLCZchgHHIESmcJC0MYzF3XVVxKXNuQHV5OiXaxXwyS+rlET1UqipbrA1VCZoc21
ucKSvkSbY3NpUu0Kd4iQPg9SNbo9TKDBHSY6J22zaKlV7kEgRN+20xKbPR5I7y7PKE8tS5lX
7fiZwWsQvQ7bj0/GjyBCrtqeVyGbbAQJx65DUvZDEqfWIzVoUIOcGjSoGZO13a56t3Zgskeb
yQF9soccqhiwb3a2qE6v6mzB7tV2dLdlaL1NihKyD3CGorFcb5O/jc++Fm1AbXFodtWhhCqM
dT9hb+bsCtURgs3OBndos73F0V9hr3CqPodnEGpIU2hq3xh1911RNwhTSdN/KwyTJr7lVK6x
xlj6E419nF3DNfZxjX1cY429xtDoXM0TWOsOyVDpqVoZnQ/RhHjMhddi9VSmmzvLjMSUWDPu
srwiAHkOEmweLVGt1JKw85wVVhRWcBYWDGeNQ3JyjJVxV4nV8gp5LsYyIzlFrQTbxjFJQmQD
fyDDudrBO1oyqA/R3v7U7Jk2jw3EW2CGeDNkY5/EdoEFQD8V62ciHv28eDuokTX6ibxkLNGX
Yh0nfHyQA7dCPhbsG3ABDpOpUAtD+jHwg5veAYVIfwB+D0PwKTigGUs8i2wBRX8M7odc2Ar7
YJ6QpQ/AzXBOToZ0mALFpANMMAHfPY+TE3ATuHCPEpgP98F6HOuQ/j2ZixwC8XALat8Fj8Jh
+DP8DTJxx2kwTCTyvf4HqIJ6tGEzDMKnYqW4A8bDr+FZeB5eh7+TaWQ/+YJ9pQ/oR/V/4Kp8
mAGzYQU0YXsQnkC5Z+FPVGVP6Vn6Zv05/V2YhNYfRM9fh7dQ10WikGXET59hPZF/6+v0gxiH
RLQZrcdWgd7UQBc8jZLD8AOJw3Y3VWg59UdS9In8pIACNrRvKbTDXbAddqIXj8BeeBHOkXLS
Rt4jX9Ek2kuPiLVSjVQTd2TkI32+fhF1JIIVrV0Ot8MmXPkgPAS7ceUTqOuP2C7ACJlNSkgZ
uYksIQ+Qe8jT5F/URo/TH9g4lswKmId52RZ2ml2SxZHFkT2RY3qtvgljia8jjGcORs0BDbAS
OmED3AFboBet68MWxOgdxKZhPI9gexM+gc+wnYVz8CWhREQf48lUbNOxlRA7WUiWkttIK9lA
9pCXSZgcJm+RL8i3dBadTefRxXQJbaWdtIsGqUZD9Ag9Q/+JVhYzJ9vAfsUOsjfYu+wD9jFW
/ULBJ6wWNgq7BE34SLggfCtERBBVbNNEn7hv5MmIK7JCz9VL9CZ9px7Edg5jfA16kwt56E8t
ZtUPq7ByOrH9AlsPxm4berQbHsfY8ei9DGF4Fav0Dczv23AMPkb/PoHT8D1cwuBw/yYQKykk
MzC+N5L52BoxT91kC+klfeQRjHOIDGAbIifQywh6uIx66K20m26hO+ke+igdpEN0GDOhMxNm
IoPNZy62nK1gt7Iutps9zH7DHmd7WZgNsbcFKhQLtcJ6YasQFJ4UXhTeET4UTojTxRIxgE0T
B8TXxLOmVJPFNMtUbwpLJrkH/2kjcAjegRAMGOfyqoFsJ2YSgt+Rz5nAeulR6qYJdJjcLbxP
8jADpQTEPlgH36CFk8kHdA5ZzvykEeN3N1lFVsBv2ST2JFsIR8V1pJ7VkmaoF/bAZfFN8IkB
2s+oGGAj5BI9CG3QR28feV73kHFQT/bTZ7Bi7oRSyBeyYJjOEwZJDs2nR6QXSBjKJBObx4rl
ZMT2s8/Q3Ho5mXwBPnYaz88pPFtL6DP4TjhLTkiL0boR9iLK3AllZH8kBZ4XPdRLJtH95OaR
rSN/YY/qe0kmPQ0wkjJSQauw4pbqB+hh+Br2RC4JJ+EwPQ5L8a3hN07ON3j27sA3zTK4TJPw
PNXje6TTbm8oL7uxtKR43tw5N8y6fuaM6UXTCgtsU/Ovy8vNmaJea1Wyr5k8yZKVmTExfULa
+NQUc/K4pMSE+DhZMokCowQKnGq1V9FyvZqQqy5YUMhx1YcE31UEr6YgqXqsjKbwdT5kjZG0
o+Sqn0jao5L2UUliVkqhtLBAcaqK9p5DVcKksc6N8E6H6lG08wa8yICFXANJQsRqxRWKM6PN
oWjEqzi16u62gNPrKCwgoYT4KrWqJb6wAELxCQgmIKRNVDtDZGIZMQA60VkcoiAnoY9alupw
apkqLsVtWI7T16zV1rmdDovV6iks0EiVX23SgP9p2QwRqDLUaKYqTTLUKKs1dAd2KKGCocD9
YTM0eW2JzWqzb6VbYz7cw6ml2FCvQ5v4yzMZP6K4Of493ns118ICzozVChcOBO5VtH117qvW
Wqx8B48H98C1NKfaG6hG1fdjqlz1Cmqj2zxujWxDlfgfn2N4FfUveg3J8a5RtDi1Um0LrPFi
brICGizpsfZnZdkH9ZOQ5VQCDW7VqpVbVI/PMSmUBoElPYcy7UrmWE5hQcicEg1saFxyDEhM
uhpowaBHeQZkiHPItWQ0soTbqN6k2bGk/Apa4lbRp7l8aJkLAf9cTAA+HoKrtGbMyGotrsob
MBdzOrpINDHHrCqB7wArQD3/5ViKL0Yx5Zi/A87kdTJaaxrxXYE1m02bOpWXiFSFOUUbywz8
hsKC7jCtUDvNCk54i4NajK3PU1yE4bdaeYJ3hO3QhIjWW+eO4go0WfrBXoTXHOrlnKErnAlL
Oaf3Cmd0uVfFSn6J35thgibnjv6SzenjnW3FGkn/H+yWKN9Vr7rqGt2KM+CNVa2rYQwW5fOA
YtyQF4O08VVuZqFI4xC1MIOLRbmycVQEEXeiJuTgz2QUdXNYkrEqDQpRqjWzd0F09MRbrbEz
8/8WhfULfJUx/bgs5oZWbIsZGjVbKxmDjzEvMcBcDfjOoa6GxkAgfgwPD3hlSCXb60J2sr2+
0T2InyrK9gZ3PyW0ylvpCU1BnntQAbAbVDpK5TIKx8BFsGD7qWywLIN2gF5DVjAIBu7HrxSD
FhVCGgF/mEZpZkPO4/EUgvAetLIXYA0ACvB08zuXCTvg//cVCsBM8CCFf7uC0IqfqAzvAiX2
a0ySH9/QouBnEG8S/YzRrDhJ8BPIlPPnZthqzN+WLhoprTFfLF1kHimF8tKRUt5nTL8+xZqS
Y02xtgpwWWFDl+0i/ACKMMStAPiQHkebEsA6CIy8ZB8XJ0FWkikzMelrK9/WVnPGfBbKF52f
MZ2kmdRrc2+YNfv6men0+PCeh4eHH94zTCui87BhMw5467biPfnnHvw8JNTUtHHt2pbYxzyB
1FgkTIA38/nVCxcvb7TV97Q3daxd1IB7/Af1DkgeCmVuZHN0cmVhbQplbmRvYmoKNDQgMCBv
YmoKMjk2MwplbmRvYmoKNDUgMCBvYmoKKG9MUyB0byBJRVRGIE5FVE1PRCByZSBOTURBIFwo
TmV0d29yayBNYW5hZ2VtZW50IERhdGFzdG9yZSBBcmNoaXRlY3R1cmVcKSkKZW5kb2JqCjQ2
IDAgb2JqCihNYWMgT1MgWCAxMC4xMi42IFF1YXJ0eiBQREZDb250ZXh0KQplbmRvYmoKNDcg
MCBvYmoKKERhdmlkIFNpbmljcm9wZSkKZW5kb2JqCjQ4IDAgb2JqCigpCmVuZG9iago0OSAw
IG9iagooV29yZCkKZW5kb2JqCjUwIDAgb2JqCihEOjIwMTcwOTE5MjExNzU0WjAwJzAwJykK
ZW5kb2JqCjUxIDAgb2JqCigpCmVuZG9iago1MiAwIG9iagpbIF0KZW5kb2JqCjEgMCBvYmoK
PDwgL1RpdGxlIDQ1IDAgUiAvQXV0aG9yIDQ3IDAgUiAvU3ViamVjdCA0OCAwIFIgL1Byb2R1
Y2VyIDQ2IDAgUiAvQ3JlYXRvcgo0OSAwIFIgL0NyZWF0aW9uRGF0ZSA1MCAwIFIgL01vZERh
dGUgNTAgMCBSIC9LZXl3b3JkcyA1MSAwIFIgL0FBUEw6S2V5d29yZHMKNTIgMCBSID4+CmVu
ZG9iagp4cmVmCjAgNTMKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDM3MTQ0IDAwMDAwIG4g
CjAwMDAwMDQzODUgMDAwMDAgbiAKMDAwMDAyMTk3MCAwMDAwMCBuIAowMDAwMDAwMDIyIDAw
MDAwIG4gCjAwMDAwMDQzNjUgMDAwMDAgbiAKMDAwMDAwNDQ4OSAwMDAwMCBuIAowMDAwMDE5
OTUyIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAyMzU4MCAwMDAwMCBuIAow
MDAwMDMzMzU3IDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAzMjE5NSAwMDAw
MCBuIAowMDAwMDA0NjYxIDAwMDAwIG4gCjAwMDAwMTcxOTQgMDAwMDAgbiAKMDAwMDAxNzIx
NiAwMDAwMCBuIAowMDAwMDE5OTMxIDAwMDAwIG4gCjAwMDAwMjE3NTQgMDAwMDAgbiAKMDAw
MDAxOTk4OCAwMDAwMCBuIAowMDAwMDIxNzMzIDAwMDAwIG4gCjAwMDAwMjE4NjEgMDAwMDAg
biAKMDAwMDAyMjExMCAwMDAwMCBuIAowMDAwMDIyMDYwIDAwMDAwIG4gCjAwMDAwMjI1Nzkg
MDAwMDAgbiAKMDAwMDAyMjI1NCAwMDAwMCBuIAowMDAwMDIyNTU5IDAwMDAwIG4gCjAwMDAw
MjI4MDAgMDAwMDAgbiAKMDAwMDAyMjgzMiAwMDAwMCBuIAowMDAwMDIzNDU3IDAwMDAwIG4g
CjAwMDAwMjMwNjggMDAwMDAgbiAKMDAwMDAyMzQzNyAwMDAwMCBuIAowMDAwMDIzNTYxIDAw
MDAwIG4gCjAwMDAwMjQ3MDIgMDAwMDAgbiAKMDAwMDAyMzk5NCAwMDAwMCBuIAowMDAwMDI0
NjgyIDAwMDAwIG4gCjAwMDAwMjQ5MzggMDAwMDAgbiAKMDAwMDAzMjE3NCAwMDAwMCBuIAow
MDAwMDMyNjc3IDAwMDAwIG4gCjAwMDAwMzIzNTggMDAwMDAgbiAKMDAwMDAzMjY1NyAwMDAw
MCBuIAowMDAwMDMyOTI1IDAwMDAwIG4gCjAwMDAwMzMzMzcgMDAwMDAgbiAKMDAwMDAzMzUz
MyAwMDAwMCBuIAowMDAwMDMzNzY5IDAwMDAwIG4gCjAwMDAwMzY4MjIgMDAwMDAgbiAKMDAw
MDAzNjg0MyAwMDAwMCBuIAowMDAwMDM2OTM0IDAwMDAwIG4gCjAwMDAwMzY5ODcgMDAwMDAg
biAKMDAwMDAzNzAyMSAwMDAwMCBuIAowMDAwMDM3MDQwIDAwMDAwIG4gCjAwMDAwMzcwNjMg
MDAwMDAgbiAKMDAwMDAzNzEwNSAwMDAwMCBuIAowMDAwMDM3MTI0IDAwMDAwIG4gCnRyYWls
ZXIKPDwgL1NpemUgNTMgL1Jvb3QgMjIgMCBSIC9JbmZvIDEgMCBSIC9JRCBbIDw3NmEzMDJi
NWMyODRhYjc0YWVjZWY4MWQ3NTEwOWE0ND4KPDc2YTMwMmI1YzI4NGFiNzRhZWNlZjgxZDc1
MTA5YTQ0PiBdID4+CnN0YXJ0eHJlZgozNzMxOQolJUVPRgo=
--------------63982BED3A89554ABF6FE3D1--


From nobody Tue Sep 19 23:33:13 2017
Return-Path: 
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 DD0F1132F2C for ; Tue, 19 Sep 2017 23:33:11 -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 H2K9M876I0Ui for ; Tue, 19 Sep 2017 23:33:10 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D65B71326ED for ; Tue, 19 Sep 2017 23:33:09 -0700 (PDT)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 0DEA01AE0383; Wed, 20 Sep 2017 08:33:08 +0200 (CEST)
Date: Wed, 20 Sep 2017 08:34:39 +0200 (CEST)
Message-Id: <20170920.083439.2133568542308133041.mbj@tail-f.com>
To: lberger@labn.net
Cc: rwilton@cisco.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <990b8722-7a48-46ce-3f5d-96bc5cb66075@labn.net> <20170919.154238.1738748131929616921.mbj@tail-f.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Sep 2017 06:33:12 -0000

TG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4gd3JvdGU6DQo+IA0KPiANCj4gT24gOS8xOS8y
MDE3IDk6NDIgQU0sIE1hcnRpbiBCam9ya2x1bmQgd3JvdGU6DQo+ID4gTG91IEJlcmdlciA8bGJl
cmdlckBsYWJuLm5ldD4gd3JvdGU6DQo+ID4+DQo+ID4+IE9uIDkvMTkvMjAxNyA3OjI5IEFNLCBN
YXJ0aW4gQmpvcmtsdW5kIHdyb3RlOg0KPiA+Pj4gTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5l
dD4gd3JvdGU6DQo+ID4+Pj4gTWFydGluLA0KPiA+Pj4+DQo+ID4+Pj4gU3BlYWtpbmcgYXMgYSBj
b250cmlidXRvcjoNCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gT24gOS8xNS8yMDE3IDc6NDAgQU0s
IE1hcnRpbiBCam9ya2x1bmQgd3JvdGU6DQo+ID4+Pj4+IFJvYmVydCBXaWx0b24gPHJ3aWx0b25A
Y2lzY28uY29tPiB3cm90ZToNCj4gPj4+Pj4+IE9uIDE1LzA5LzIwMTcgMTE6MjEsIExhZGlzbGF2
IExob3RrYSB3cm90ZToNCj4gPj4+Pj4+PiBBbmR5IEJpZXJtYW4gcMOtxaFlIHYgxIx0IDE0LiAw
OS4gMjAxNyB2IDA4OjQzIC0wNzAwOg0KPiA+Pj4+Pj4+PiBIaSwNCj4gPj4+Pj4+Pj4NCj4gPj4+
Pj4+Pj4NCj4gPj4+Pj4+Pj4gQWN0dWFsbHkgSSBsaWtlZCB0aGUgZWFybHkgcHlhbmcgb3V0cHV0
IHRoYXQgd2FzIGNvbmNpc2UgYW5kIGVhc3kgdG8NCj4gPj4+Pj4+Pj4gcmVtZW1iZXIuDQo+ID4+
Pj4+Pj4+IFRoZSBjdXJyZW50IGZvcm1hdCBnZXRzIHZlcnkgY2x1dHRlcmVkIGFuZCB0aGVyZSBh
cmUgdG9vIG1hbnkgbGl0dGxlDQo+ID4+Pj4+Pj4+IHN5bWJvbHMNCj4gPj4+Pj4+Pj4gdG8gcmVt
ZW1iZXIgdGhlbSBhbGwuDQo+ID4+Pj4+Pj4gSSBhZ3JlZS4NCj4gPj4+Pj4gTWUgdG9vLiAgVGhl
IGN1cnJlbnQgZHJhZnQgYWRkcyB0aHJlZSBuZXcgbWFnaWMgc3ltYm9sczogIm1wIiAiQCIgYW5k
DQo+ID4+Pj4+ICIvIi4NCj4gPj4+Pj4NCj4gPj4+Pj4gIm1wIiBpcyBmb3IgYSBtb3VudCBwb2lu
dCwgYW5kIGl0IGNhbiBiZSBnZW5lcmF0ZWQgZGlyZWN0bHkgZnJvbSB0aGUNCj4gPj4+Pj4gWUFO
RyBtb2R1bGVzLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBEaXJlY3RseSB1bmRlciBhICJtcCIsICIvIiBh
bmQgIkAiIGFyZSB1c2VkIHRvIGluZGljYXRlIHRoYXQgYSBub2RlIGlzIG1vdW50ZWQNCj4gPj4+
Pj4gb3IgYXZhaWxhYmxlIHRocm91Z2ggYSBwYXJlbnQgcmVmZXJlbmNlLCByZXNwZWN0aXZlbHku
DQo+ID4+Pj4+DQo+ID4+Pj4+IEkgYWN0dWFsbHkgcXVlc3Rpb24gdGhlIHVzYWJpbGl0eSBvZiAi
LyIgYW5kICJAIi4gIA0KPiA+Pj4+IEkgYWdyZWUgdGhhdCAvIGFuZCBAIGFyZSBzb21ldGhpbmcg
bmV3LCBhbmQgZW5hYmxlZCBieSBzY2hlbWEgbW91bnQuwqANCj4gPj4+PiBUaGVyZSBoYXZlIGJl
ZW4gcmVwZWF0ZWQgY29tbWVudHMgaW4gdGhlIFJURyBXRyB0aGF0IHRoZXJlIG5lZWRzIHRvIGJl
DQo+ID4+Pj4gc29tZSB3YXkgZm9yIHZlbmRvcnMgdG8gY29udmV5IHdoYXQgdGhleSBoYXZlIGlt
cGxlbWVudGVkIHdpdGggU2NoZW1hDQo+ID4+Pj4gbW91bnQNCj4gPj4+IElmIHRoYXQncyB0aGUg
cmVxdWlyZW1lbnQsIHVzaW5nIHRoZSB0cmVlIGRpYWdyYW0gaXMgcHJvYmFibHkgbm90IHRoZQ0K
PiA+Pj4gYmVzdCB3YXkuICBUaGUgdHJlZSBkaWFncmFtIGlzIGludGVuZGVkIHRvIHByb3ZpZGUg
YW4gb3ZlcnZpZXcgb2YgYQ0KPiA+Pj4gZ2l2ZW4gKHNldCBvZikgWUFORyBtb2R1bGUocykuDQo+
ID4+Pg0KPiA+Pj4gQSBwZXJoYXBzIGJldHRlciB3YXkgdG8gY29udmV5IHRoZSBpbmZvcm1hdGlv
biBpcyB0byBjcmVhdGUgYSBmaWxlDQo+ID4+PiB3aXRoIGFuIGluc3RhbnRpYXRlZCAvc2NoZW1h
LW1vdW50cyB0cmVlLg0KPiA+PiB1c2luZyB3aGF0IHN5bnRheD/CoCBKU09OIGFuZCBYTUwgcmVh
bGx5IGlzbid0IHRoYXQgZWFzeSBmb3IgdGhlIChodW1hbikNCj4gPj4gcmVhZGVyIHRvIHBhcnNl
Lg0KPiA+IEVpdGhlciBKU09OIG9yIFhNTC4NCj4gVGhpcyBpcyBmaW5lIGZvciBjb2RlLCBsZXNz
IHNvIGZvciBodW1hbnMuwqAgV2UgaW5jbHVkZSBib3RoIGluIHRoZSBOSQ0KPiBkcmFmdCwgdGhl
IHRyZWUgcHJvdmlkZXMgYSBxdWljayBvdmVydmlldywgdGhlIEpTT04gcHJvdmlkZXMgdGhlIGRl
dGFpbHMuwqANCj4gDQo+ID4NCj4gPj4+PiBhbmQgdGhpcyBpcyBvbmUgd2F5IHRvIGhlbHAgY29u
dmV5IChhKSB3aGF0IGlzIGV4cGVjdGVkIG9mIHNlcnZlcg0KPiA+Pj4+IGltcGxlbWVudG9ycyBh
bmQgKGIpIHdoYXQgY2xpZW50IGltcGxlbWVudG9ycyBzaG91bGQgZXhwZWN0Lg0KPiA+Pj4+DQo+
ID4+PiDCoMKgIEhlbmNlIHRoZQ0KPiA+Pj4+IGN1cnJlbnQgZHJhZnQgdGV4dDoNCj4gPj4+Pg0K
PiA+Pj4+IMKgIEluIGRlc2NyaWJpbmcgdGhlIGludGVuZGVkIHVzZSBvZiBhIG1vZHVsZSBjb250
YWluaW5nIGEgbW91bnQgcG9pbnQsDQo+ID4+Pj4gwqDCoCBpdCBpcyBoZWxwZnVsIHRvIHNob3cg
aG93IHRoZSBtb3VudCBwb2ludCB3b3VsZCBsb29rIHdpdGggbW91bnRlZA0KPiA+Pj4+IMKgwqAg
bW9kdWxlcy4NCj4gPj4+Pg0KPiA+Pj4+IFRoZSB3aG9sZSBwb2ludCBvZiB0cmVlcyBpcyB0byBm
YWNpbGl0YXRlIHVuZGVyc3RhbmRpbmcgZm9yIHRob3NlIHdobw0KPiA+Pj4+IGFyZSBsZXNzIGZh
bWlsaWFyIHdpdGggYSBtb2RlbCB0aGFuIHRoZSBhdXRob3JzLCBhbmQgSU1PIHRoYXQncyB0aGUN
Cj4gPj4+PiBwYXJhbW91bnQgcGVyc3BlY3RpdmUgaW4gdGhpcyBkaXNjdXNzaW9uLg0KPiA+Pj4g
RnVsbHkgYWdyZWUhICBJIHdvdWxkIHNheSB0aGF0IHdlIGhhdmUgdG8gbWFrZSBzdXJlIHRoYXQg
dGhlIGRpYWdyYW1zDQo+ID4+PiBjYW4gYmUgdW5kZXJzdG9vZCBieSBwZW9wbGUgbGVzcyBmYW1p
bGlhciB3aXRoIHRoZSB0ZWNobm9sb2d5IHRoYW4gdGhlDQo+ID4+PiBhdXRob3JzLiAgTWl4aW5n
IHNjaGVtYSBhbmQgaW5zdGFuY2UgZGF0YSBkb2VzIG5vdCBoZWxwIGhlcmUuDQo+ID4+IENhbiB5
b3UgcHJvcG9zZSBhbiBhbHRlcm5hdGl2ZT8NCj4gPiBBcyBJIGhhdmUgd3JpdHRlbiBiZWZvcmUs
IEkgdGhpbmsgdGhlICIvIiBpcyBub3QgbmVlZGVkLCBzbyBJIHdvdWxkDQo+ID4gcmVtb3ZlIHRo
YXQuICBJIHdvdWxkIGFsc28gbm90IGxpc3QgdGhlIG5vZGVzIGZyb20gInBhcmVudC1yZWZlcmVu
Y2VzIg0KPiA+IGluIHRoZSBzYW1lIHRyZWUgb3VwdXQuICBJdCBpcyBub3QgY2xlYXIgdG8gbWUg
dGhhdCB0aGlzIGxldmVsIG9mDQo+ID4gZGV0YWlsIGlzIG5lZWRlZCBpbiB0aGUgdHJlZSwgYW5k
IC0gYXMgbm90ZWQgYmVmb3JlIC0gaXQgaXNuJ3QgZXZlbg0KPiA+IGNvcnJlY3QgdG8gbGlzdCBl
LmcuICJpbnRlcmZhY2VzIiB3aGVuIHRoZSBwYXJlbnQtcmVmZXJlbmNlIGluIGZhY3QNCj4gPiBz
ZWxlY3RzIGEgc2luZ2xlIGludGVyZmFjZS4NCj4gPg0KPiA+PiBUaGUgcm91dGluZyBXRyBwYXJ0
aWNpcGFudHMgc2VlbSB0bw0KPiA+PiBmaW5kIHRoZXNlIHVzZWZ1bCwgd2UgY2FuIGFsc28gYXNr
IHRoZXJlIGZvciBicm9hZGVyIGlucHV0IGlmIHlvdSdkIGxpa2UuDQo+ID4gT25lIGFwcHJvYWNo
IGlzIHRvIGFkZCB0aGUgdW5pb24gb2YgZXZleXRoaW5nIHRoYXQgc29tZSBwZW9wbGUgZmluZA0K
PiA+IHVzZWZ1bC4gIEluIHRoZSBlbmQgd2UgaGF2ZSB0byBsb29rIGZvciBXRyBjb25zZW5zdXMu
ICBTZXZlcmFsIHBlb3BsZQ0KPiA+IGhhdmUgc2FpZCB0aGF0IHRoZXkgcHJlZmVyIGEgbGVzcyBj
bHV0dGVyZWQgZm9ybWF0Lg0KPiBJbiB0aGUgY29udGV4dCBvZiBsaXN0aW5nIGVudW1zLi4uDQo+
IA0KPiA+DQo+ID4+Pj4+IFNpbmNlIGEgcGFyZW50DQo+ID4+Pj4+IHJlZmVyZW5jZSBjYW4gYmUg
dmVyeSBzcGVjaWZpYywgZS5nLiBvbmUgc3BlY2lmaWMgaW50ZXJmYWNlLCBpdCBpc24ndA0KPiA+
Pj4+PiByZWFsbHkgYWNjdXJhdGUgdG8gc2hvdzoNCj4gPj4+Pj4NCj4gPj4+Pj4gICAgICAgICAg
ICAgICAgICAgKy0tbXAgdnJmLXJvb3QNCj4gPj4+Pj4gICAgICAgICAgICAgICAgICAgICAgKy0t
cncgcnQ6cm91dGluZy8NCj4gPj4+Pj4gICAgICAgICAgICAgICAgICAgICAgfCAgLi4uDQo+ID4+
Pj4+ICAgICAgICAgICAgICAgICAgICAgICstLXJvIGlmOmludGVyZmFjZXNADQo+ID4+Pj4gVGhp
cyBpcyBqdXN0IGEgY29uZGl0aW9uYWwgYW5kIHdlIGhhdmUgcHJlY2VkZW50IG9uIGhvdyB0byBo
YW5kbGUNCj4gPj4+PiBjb25kaXRpb25hbCByZXByZXNlbnRhdGlvbi4gwqDCoA0KPiA+Pj4+DQo+
ID4+Pj4+IEFuZCB0aGUgdHJhaWxpbmcgIi8iIG9uIHJ0OnJvdXRpbmcgZG9lc24ndCBhZGQgYW55
IGluZm9ybWF0aW9uIHdlDQo+ID4+Pj4+IGRvbid0IGFscmVhZHkga25vdy4gIFNpbmNlIHZyZi1y
b290IGlzIGEgbW91bnQgcG9pbnQsIGl0IGZvbGxvd3MgdGhhdA0KPiA+Pj4+PiBpdHMgY2hpbGRy
ZW4gYXJlIG1vdW50ZWQuDQo+ID4+Pj4gVGhlIGlzc3VlIGlzIGEgYml0IG1vcmUgY29tcGxleCB3
aGVuIGNvbnNpZGVyaW5nIHNvbWUgcmVhbCB1c2UgY2FzZXMsDQo+ID4+Pj4gcGFydGljdWxhcml0
eSB3aGVuIHBhcmVudCByZWZlcmVuY2VzIGFuZCBhdWdtZW50YXRpb25zIGFyZSB1c2VkLsKgIEZv
cg0KPiA+Pj4+IGV4YW1wbGUgY29uc2lkZXIgdGhlIGZvbGxvd2luZyAqd2l0aG91dCogdGhlIHVz
ZSAvIG9yIEA6DQo+ID4+Pj4NCj4gPj4+PiBtb2R1bGU6IGlldGYtbmV0d29yay1pbnN0YW5jZQ0K
PiA+Pj4+IMKgICstLXJ3IG5ldHdvcmstaW5zdGFuY2VzDQo+ID4+Pj4gwqDCoMKgwqAgKy0tcncg
bmV0d29yay1pbnN0YW5jZSogW25hbWVdDQo+ID4+Pj4gwqDCoMKgwqDCoMKgwqAgfCAuLi4NCj4g
Pj4+PiDCoMKgwqDCoMKgwqDCoCArLS1ydyAocm9vdC10eXBlKQ0KPiA+Pj4+IMKgwqDCoMKgwqDC
oMKgwqDCoMKgICstLToodnJmLXJvb3QpDQo+ID4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqAgKy0tbXAgdnJmLXJvb3QNCj4gPj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oCArLS1ybyBydDpyb3V0aW5nLXN0YXRlDQo+ID4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqAgfMKgICstLXJvIHJvdXRlci1pZD/CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoCB5YW5nOmRvdHRlZC1xdWFkDQo+ID4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqAgfMKgICstLXJvIGNvbnRyb2wtcGxhbmUtcHJvdG9jb2xzDQo+ID4+Pj4gwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgICstLXJvIGNvbnRyb2wtcGxhbmUtcHJv
dG9jb2wqIFt0eXBlIG5hbWVdDQo+ID4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqAgfMKgwqDCoMKgwqDCoMKgICstLXJvIG9zcGY6b3NwZg0KPiA+Pj4+IMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoCArLS1ybyBpbnN0YW5jZSog
W2FmXQ0KPiA+Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICstLXJ3IHJ0OnJv
dXRpbmcNCj4gPj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqAgKy0tcncg
cm91dGVyLWlkP8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHlhbmc6ZG90dGVkLXF1
YWQNCj4gPj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqAgKy0tcncgY29u
dHJvbC1wbGFuZS1wcm90b2NvbHMNCj4gPj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoCB8wqDCoMKgwqAgKy0tcncgY29udHJvbC1wbGFuZS1wcm90b2NvbCogW3R5cGUgbmFtZV0N
Cj4gPj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqAgKy0tcncg
b3NwZjpvc3BmDQo+ID4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDC
oMKgwqDCoMKgICstLXJ3IGluc3RhbmNlKiBbYWZdDQo+ID4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgICstLXJ3IGFyZWFzDQo+ID4+Pj4g
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgICstLXJ3IGFyZWEqIFthcmVhLWlkXQ0KPiA+Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCArLS1ydyBpbnRlcmZh
Y2VzDQo+ID4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICstLXJ3IGludGVyZmFjZSogW25hbWVdDQo+ID4+
Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgICstLXJ3IG5hbWUgaWY6aW50ZXJmYWNlLXJlZg0KPiA+
Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCArLS1ydyBjb3N0P8KgwqAgdWludDE2DQo+ID4+Pj4g
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgKy0tcm8gaWY6aW50ZXJmYWNlcw0KPiA+
Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoCAuLi4NCj4gPj4+PiDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCArLS1ybyBpZjppbnRlcmZhY2VzLXN0YXRlDQo+
ID4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgIC4uLg0KPiA+Pj4+DQo+
ID4+Pj4NCj4gPj4+PiBJdCdzIGNlcnRhaW5seSBub3QgdG9vIGhhcmQgdG8gc3BvdCB0aGUgdG9w
IGxldmVsIG1vdW50cywgYnV0IGl0IGlzDQo+ID4+Pj4gaW1wb3NzaWJsZSB0byBkaXN0aW5ndWlz
aCB0aGUgcGFyZW50IHJlZmVyZW5jZXMgZnJvbSB0aGUgYWN0dWFsIG1vdW50cy7CoA0KPiA+Pj4g
TXkgcHJvcG9zYWwgd291bGQgYmUgdG8gbm90IGV2ZW4gc2hvdyB0aGUgcGFyZW50IHJlZmVyZW5j
ZXMgaW4gdGhlDQo+ID4+PiBkaWFncmFtLiAgSWYgd2UgZG8gdGhhdCwgdGhlICcvJyBpcyBub3Qg
bmVlZGVkLg0KPiA+Pj4NCj4gPj4+PiBGdXJ0aGVyIG1vcmUsIHNvbWUgbW91bnRzIGFyZSBoYXJk
IHRvIHNwb3QuwqAgRm9yIGV4YW1wbGUsIG5vdGljZSBvc3BmLsKgDQo+ID4+Pj4gRGlkIHlvdSBu
b3RpY2UgdGhhdCBpdCdzIGEgbW91bnQ/DQo+ID4+PiBUaGlzIGlzIGFjdHVhbGx5IG5vdCBjb3Jy
ZWN0LiAgb3NwZiBpcyAqbm90KiBhIG1vdW50OyBpdCBpcyBhbiBhdWdtZW50Lg0KPiA+Pj4NCj4g
Pj4gaXQncyBhIG1vdW50ZWQgbW9kdWxlIHRoYXQgYXVnbWVudHMgYW5vdGhlciBtb3VudGVkIG1v
ZHVsZS4NCj4gPiBCdXQgd2h5IHdvdWxkIGl0IGhhdmUgYSAiLyIganVzdCBiL2MgaXQgaXMgYXVn
bWVudGVkLCB3aGVuIGl0cyBzaWJsaW5nDQo+ID4gJ2NvbnRyb2wtcGxhbi1wcm90b2NvbCcgZG9l
c24ndCBoYXZlIHRoZSAiLyI/ICBXaGF0IGFkZGl0aW9uIGluZm8gZG9lcw0KPiA+IHRoZSAiLyIg
Y29udmV5Pw0KPiBUaGF0IGl0IGlzIGEgKHN1Yil0cmVlIHRoYXQgaXMgcHJlc2VudCBkdWUgdG8g
YSBtb3VudGVkIG1vZHVsZS4NCg0KU28gaXMgJ2NvbnRyb2wtcGxhbmUtcHJvdG9jb2wnLCBzbyB0
aGVuIGl0IHNob3VsZCBhbHNvIGhhdmUgJy8nLA0KcmlnaHQ/DQoNCg0KL21hcnRpbg0K


From nobody Tue Sep 19 23:38:49 2017
Return-Path: 
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 CD1F3132F2C for ; Tue, 19 Sep 2017 23:38:47 -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 XtdLvrq5Up4A for ; Tue, 19 Sep 2017 23:38:46 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B188A1326ED for ; Tue, 19 Sep 2017 23:38:46 -0700 (PDT)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id CF2BA1AE0383; Wed, 20 Sep 2017 08:38:45 +0200 (CEST)
Date: Wed, 20 Sep 2017 08:40:16 +0200 (CEST)
Message-Id: <20170920.084016.1173553333008898354.mbj@tail-f.com>
To: lberger@labn.net
Cc: rwilton@cisco.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <20170919.154728.285206235172744617.mbj@tail-f.com> <4f17fbca-6282-6b27-b390-9b85779e96da@cisco.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Sep 2017 06:38:48 -0000

TG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4gd3JvdGU6DQo+IA0KPiANCj4gT24gOS8xOS8y
MDE3IDk6NTUgQU0sIFJvYmVydCBXaWx0b24gd3JvdGU6DQo+ID4NCj4gPiBPbiAxOS8wOS8yMDE3
IDE0OjQ3LCBNYXJ0aW4gQmpvcmtsdW5kIHdyb3RlOg0KPiA+PiBSb2JlcnQgV2lsdG9uIDxyd2ls
dG9uQGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4+PiBPbiAxOS8wOS8yMDE3IDE0OjI4LCBMb3UgQmVy
Z2VyIHdyb3RlOg0KPiA+Pj4+IE9uIDkvMTkvMjAxNyA3OjI5IEFNLCBNYXJ0aW4gQmpvcmtsdW5k
IHdyb3RlOg0KPiA+Pj4+PiBMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0PiB3cm90ZToNCj4g
Pj4+Pj4+IE1hcnRpbiwNCj4gPj4+Pj4+DQo+ID4+Pj4+PiBTcGVha2luZyBhcyBhIGNvbnRyaWJ1
dG9yOg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBPbiA5LzE1LzIwMTcgNzo0MCBBTSwg
TWFydGluIEJqb3JrbHVuZCB3cm90ZToNCj4gPj4+Pj4+PiBSb2JlcnQgV2lsdG9uIDxyd2lsdG9u
QGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4+Pj4+Pj4+IE9uIDE1LzA5LzIwMTcgMTE6MjEsIExhZGlz
bGF2IExob3RrYSB3cm90ZToNCj4gPj4+Pj4+Pj4+IEFuZHkgQmllcm1hbiBww63FoWUgdiDEjHQg
MTQuIDA5LiAyMDE3IHYgMDg6NDMgLTA3MDA6DQo+ID4+Pj4+Pj4+Pj4gSGksDQo+ID4+Pj4+Pj4+
Pj4NCj4gPj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+IEFjdHVhbGx5IEkgbGlrZWQgdGhlIGVhcmx5
IHB5YW5nIG91dHB1dCB0aGF0IHdhcyBjb25jaXNlIGFuZCBlYXN5IHRvDQo+ID4+Pj4+Pj4+Pj4g
cmVtZW1iZXIuDQo+ID4+Pj4+Pj4+Pj4gVGhlIGN1cnJlbnQgZm9ybWF0IGdldHMgdmVyeSBjbHV0
dGVyZWQgYW5kIHRoZXJlIGFyZSB0b28gbWFueSBsaXR0bGUNCj4gPj4+Pj4+Pj4+PiBzeW1ib2xz
DQo+ID4+Pj4+Pj4+Pj4gdG8gcmVtZW1iZXIgdGhlbSBhbGwuDQo+ID4+Pj4+Pj4+PiBJIGFncmVl
Lg0KPiA+Pj4+Pj4+IE1lIHRvby4gIFRoZSBjdXJyZW50IGRyYWZ0IGFkZHMgdGhyZWUgbmV3IG1h
Z2ljIHN5bWJvbHM6ICJtcCIgIkAiIGFuZA0KPiA+Pj4+Pj4+ICIvIi4NCj4gPj4+Pj4+Pg0KPiA+
Pj4+Pj4+ICJtcCIgaXMgZm9yIGEgbW91bnQgcG9pbnQsIGFuZCBpdCBjYW4gYmUgZ2VuZXJhdGVk
IGRpcmVjdGx5IGZyb20gdGhlDQo+ID4+Pj4+Pj4gWUFORyBtb2R1bGVzLg0KPiA+Pj4+Pj4+DQo+
ID4+Pj4+Pj4gRGlyZWN0bHkgdW5kZXIgYSAibXAiLCAiLyIgYW5kICJAIiBhcmUgdXNlZCB0byBp
bmRpY2F0ZSB0aGF0IGEgbm9kZSBpcw0KPiA+Pj4+Pj4+IG1vdW50ZWQNCj4gPj4+Pj4+PiBvciBh
dmFpbGFibGUgdGhyb3VnaCBhIHBhcmVudCByZWZlcmVuY2UsIHJlc3BlY3RpdmVseS4NCj4gPj4+
Pj4+Pg0KPiA+Pj4+Pj4+IEkgYWN0dWFsbHkgcXVlc3Rpb24gdGhlIHVzYWJpbGl0eSBvZiAiLyIg
YW5kICJAIi4NCj4gPj4+Pj4+IEkgYWdyZWUgdGhhdCAvIGFuZCBAIGFyZSBzb21ldGhpbmcgbmV3
LCBhbmQgZW5hYmxlZCBieSBzY2hlbWEgbW91bnQuDQo+ID4+Pj4+PiBUaGVyZSBoYXZlIGJlZW4g
cmVwZWF0ZWQgY29tbWVudHMgaW4gdGhlIFJURyBXRyB0aGF0IHRoZXJlIG5lZWRzIHRvIGJlDQo+
ID4+Pj4+PiBzb21lIHdheSBmb3IgdmVuZG9ycyB0byBjb252ZXkgd2hhdCB0aGV5IGhhdmUgaW1w
bGVtZW50ZWQgd2l0aCBTY2hlbWENCj4gPj4+Pj4+IG1vdW50DQo+ID4+Pj4+IElmIHRoYXQncyB0
aGUgcmVxdWlyZW1lbnQsIHVzaW5nIHRoZSB0cmVlIGRpYWdyYW0gaXMgcHJvYmFibHkgbm90IHRo
ZQ0KPiA+Pj4+PiBiZXN0IHdheS4gIFRoZSB0cmVlIGRpYWdyYW0gaXMgaW50ZW5kZWQgdG8gcHJv
dmlkZSBhbiBvdmVydmlldyBvZiBhDQo+ID4+Pj4+IGdpdmVuIChzZXQgb2YpIFlBTkcgbW9kdWxl
KHMpLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBBIHBlcmhhcHMgYmV0dGVyIHdheSB0byBjb252ZXkgdGhl
IGluZm9ybWF0aW9uIGlzIHRvIGNyZWF0ZSBhIGZpbGUNCj4gPj4+Pj4gd2l0aCBhbiBpbnN0YW50
aWF0ZWQgL3NjaGVtYS1tb3VudHMgdHJlZS4NCj4gPj4+PiB1c2luZyB3aGF0IHN5bnRheD/CoCBK
U09OIGFuZCBYTUwgcmVhbGx5IGlzbid0IHRoYXQgZWFzeSBmb3IgdGhlDQo+ID4+Pj4gKGh1bWFu
KQ0KPiA+Pj4+IHJlYWRlciB0byBwYXJzZS4NCj4gPj4+IFBlcmhhcHMgdGhlcmUgbmVlZHMgdG8g
YmUgbXVsdGlwbGUgdmVyc2lvbnMgb2YgdGhlIGdlbmVyYXRlZCB0cmVlDQo+ID4+PiBvdXRwdXQ/
DQo+ID4+Pg0KPiA+Pj4gMSkgQSBub3JtYXRpdmUgdHJlZSBkaWFncmFtIHRoYXQgc2hvd3MgdGhl
IHN0cnVjdHVyZSBvZiB0aGUgbW9kZWwuDQo+ID4+PiAyKSBBIHN1YnNlcXVlbnQgZXhhbXBsZSB0
aGF0IGRlbW9uc3RyYXRlcyB3aGF0IGl0IGxvb2tzIGxpa2Ugd2l0aCB0aGUNCj4gPj4+IHNjaGVt
YSBtb3VudGVkIG1vZHVsZXMuwqAgV2l0aGluIHRoZSBjb25maW5lcyBvZiBhIHRleHQgZG9jdW1l
bnQsIHRoZQ0KPiA+Pj4gdHJlZSBmb3JtYXQgc3RpbGwgc2VlbXMgbGlrZSBhIHJlYXNvbmFibGUg
d2F5IHRvIGlsbHVzdHJhdGUgdGhpcywgYW5kDQo+ID4+PiBJIHdvdWxkIHNheSBpdCBpcyBwcmVm
ZXJhYmxlIHRvIHRoZSB2ZXJib3NpdHkgb2YgSlNPTiBvciBYTUwuDQo+ID4+Pg0KPiA+Pj4gSSBu
b3RlIHRoYXQgUkZDIDgwMjIgaW5jbHVkZXMgYW4gb3ZlcnZpZXcgdHJlZSBtb2RlbCBpbiBzZWN0
aW9uIDQgd2l0aA0KPiA+Pj4gc29tZSBicmFuY2hlcyBwcnVuZWQsIGFuZCB0aGVuIHRoZSBjb21w
bGV0ZSByZXByZXNlbnRhdGlvbiBpbiBhbg0KPiA+Pj4gYXBwZW5kaXgsIHdoaWNoIHNlZW1zIGxp
a2UgYSBwcmFnbWF0aWMgYXBwcm9hY2guDQo+ID4+IFN1cmUsIGJ1dCB0aGUgcXVlc3Rpb24gaXMg
YWJvdXQgd2hhdCBzcGVjaWFsIHN5bWJvbHMgd2UgZGVmaW5lLiAgRG8gd2UNCj4gPj4gbmVlZCB0
aGUgZXh0cmEgc3ltYm9scyAiLyIgYW5kICJAIiwgYW5kIGRvIHdlIGFncmVlIG9uIHdoYXQgdGhl
eSBtZWFuPw0KPiA+IElmIHdlIGFncmVlIHRoYXQgdHJlZSBzdHlsZSBvdXRwdXQgaXMgT0sgdG8g
aWxsdXN0cmF0ZSB0aGUgdXNlIG9mIHNjaGVtYSANCj4gPiBtb3VudCwgdGhlbiBJIHRoaW5rIHRo
YXQgZHJhZnQtaWV0Zi1uZXRtb2QteWFuZy10cmVlLWRpYWdyYW1zIGNvdWxkIA0KPiA+IGRlZmlu
ZSB0aGVtLCBidXQgaW5kaWNhdGUgdGhhdCB0aGV5IGFyZSBvbmx5IHVzZWQgdG8gaWxsdXN0cmF0
ZSBob3cgDQo+ID4gc2NoZW1hIG1vdW50IGlzIHVzZWQsIGFuZCB3b3VsZCBub3QgYmUgc2VlbiBp
biBhIHJlZ3VsYXIgWUFORyB0cmVlIA0KPiA+IGRpYWdyYW0gaWxsdXN0cmF0aW5nIHRoZSBzdHJ1
Y3R1cmUgb2YgYSBZQU5HIG1vZHVsZS7CoCANCj4gDQo+IFRoaXMgc2VlbXMgbGlrZSBhIHJlYXNv
bmFibGUgY29tcHJvbWlzZSB0byBtZSwgYW5kIG5vdCBhIG1ham9yIGNoYW5nZSB0bw0KPiB0aGUg
ZHJhZnQuDQo+IA0KPiBNYXJ0aW4sIHdoYXQgZG8geW91IHRoaW5rPw0KDQpUaGlzIGlzIG5vdCBh
IGNvbXByb21pc2UuICBFaXRoZXIgdGhlIHRyZWUgZG9jdW1lbnQgZGVmaW5lcyB0aGUNCnN5bWJv
bHMgb3IgaXQgZG9lc24ndC4gIFRoZSBkcmFmdCBhbHJlYWR5IHNheXM6DQoNCiAgTW9kdWxlIHRy
ZWVzIG1heSBiZSBpbmNsdWRlZCBpbiBhIGRvY3VtZW50IGFzIGEgd2hvbGUsIGJ5IG9uZSBvcg0K
ICBtb3JlIHNlY3Rpb25zLCBvciBldmVuIHN1YnNldHMgb2Ygbm9kZXMuDQoNCmFuZA0KDQogIEF0
IHRpbWVzIHdoZW4gdGhlIGNvbXBvc2l0aW9uIG9mIHRoZSBub2RlcyB3aXRoaW4gYSBtb2R1bGUg
c2NoZW1hDQogIGFyZSBub3QgaW1wb3J0YW50IGluIHRoZSBjb250ZXh0IG9mIHRoZSBwcmVzZW50
ZWQgdHJlZSwgcGVlciBub2Rlcw0KICBhbmQgdGhlaXIgY2hpbGRyZW4gY2FuIGJlIGNvbGxhcHNl
ZCB1c2luZyB0aGUgbm90YXRpb24gJy4uLicgaW4NCiAgcGxhY2Ugb2YgdGhlIHRleHQgbGluZXMg
dXNlZCB0byByZXByZXNlbnQgdGhlIHN1bW1hcml6ZWQgbm9kZXMuDQoNCnNvIHRoZSB1c2FnZSBp
biA4MDIyIGlzIGFscmVhZHkgY292ZXJlZC4NCg0KDQo+ID4gVGhlIGFsdGVybmF0aXZlIA0KPiA+
IG1pZ2h0IGJlIHRoYXQgdGhlIFJGQ3MgdGhhdCB1c2VzIHRoZW0gZGVmaW5lcyB3aGF0ICcvJyBh
bmQgJ0AnIG1lYW4gZm9yIA0KPiA+IHRoYXQgc3BlY2lmaWMgZXhhbXBsZS4NCj4gPg0KPiA+IEFz
IGZvciB3aGF0IHRoZSBwcmVjaXNlIGRlZmluaXRpb24gb2YgJy8nIGFuZCAnQCcgc2hvdWxkIGJl
LCBJJ20gbm90IA0KPiA+IHN1cmUuwqAgSSB0aGluayB0aGF0IHlvdSBhbmQgTG91IGhhdmUgYSBi
ZXR0ZXIgaGFuZGxlIG9uIHRoYXQgOy0pDQoNClNpbmNlIExvdSBhbmQgSSBoYXZlIGRpZmZlcmVu
dCBvcGluaW9ucyBvbiB0aGlzLCBpdCB3b3VsZCBiZSB2ZXJ5DQp1c2VmdWwgdG8gaGVhciB3aGF0
IG90aGVycyB0aGluay4NCg0KDQovbWFydGluDQo=


From nobody Tue Sep 19 23:59:44 2017
Return-Path: 
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 592DF133070 for ; Tue, 19 Sep 2017 23:59:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level: 
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] 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 PqO7YzLq_RDO for ; Tue, 19 Sep 2017 23:59:41 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 6BB2D133073 for ; Tue, 19 Sep 2017 23:59:41 -0700 (PDT)
Received: from birdie5 (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id BE6216178F for ; Wed, 20 Sep 2017 08:59:39 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1505890779; bh=bdIaMhbOnEXVdTEB522bGgkixh8v95bAN+fmDzrUhqo=; h=From:To:Date; b=q9dyvJLQ5J3Wx5hQoMUyrSDoqaT9qrg+/uJIYfCVn4Z9JgtFiRCqpCks2Tav5cSOC QMyVoLcc5prf8HloB+p+X0Rb8ufumUGfp6jMVgxdMiEKyIboPRPvi/s5CBzx7PNRz6 R6g/GbYXe7KhB3kAmg18e75KvZGtGg9w6YQMdZ/Q=
Message-ID: <1505890819.5891.7.camel@nic.cz>
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Wed, 20 Sep 2017 09:00:19 +0200
In-Reply-To: <20170919152055.qotlamp3ej3vy4j4@elstar.local>
References: <5b512435-cebd-3534-eeb3-649154450d81@cisco.com> <20170915.134007.262763963470255554.mbj@tail-f.com>  <20170919.132947.358857445863848356.mbj@tail-f.com> <990b8722-7a48-46ce-3f5d-96bc5cb66075@labn.net> <20170919152055.qotlamp3ej3vy4j4@elstar.local>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.24.5 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Sep 2017 06:59:43 -0000

Juergen Schoenwaelder píše v Út 19. 09. 2017 v 17:20 +0200:
> [...]
> 
> I prefer that the (schema) tree format is restricted to show the
> schema tree.
> 
> If a tree format is also needed for data trees, then this really is a
> different tree format. It may use a similar base notation but what it
> shows is fundamentally different.

+1

Lada

> 
> /js
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Wed Sep 20 02:52:46 2017
Return-Path: 
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 CA95D1342E6; Wed, 20 Sep 2017 02:52:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 1EieuxsJb6ES; Wed, 20 Sep 2017 02:52:42 -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 98AA81330AD; Wed, 20 Sep 2017 02:52:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17216; q=dns/txt; s=iport; t=1505901162; x=1507110762; h=subject:from:to:references:message-id:date:mime-version: in-reply-to; bh=0vvs72+fB7EuSReWMu8dS2W2hMgYkHcIGuApLtCF5fw=; b=S6ZiQWgzFfF/b9HZ+tBR+vrdTCcgX40uCagcD07pMF5SHv9PnD7M0+be 9rG11lggZzeO0TT1hSojvF77AYahMyEvz2B4DK6jw4FTB4SMlD9uRLVpu sxuAk8E51+oNIPxlIJ7n/MFtLbZr+mOL7ThsrcNOPWu0JCMFU0wQmSY8q I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B8AQAxOcJZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhSyEHIsUkEkrkGiHUAqFOwKFJhUBAgEBAQEBAQFrKIUZAQUjSwQ?= =?us-ascii?q?XCQIYKgICVwYBDAgBAYovij+dZoInJ4pzAQEBAQEBBAEBAQEBAQEBIIMrg1OCD?= =?us-ascii?q?4J9iA6CYAWhD5RXghOFaoNaJIcAjWGHV4E5NSKBDTIhCBwVSYUZHIFoP4cOK4I?= =?us-ascii?q?VAQEB?=
X-IronPort-AV: E=Sophos;i="5.42,420,1500940800";  d="scan'208,217";a="655783792"
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; 20 Sep 2017 09:52:39 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8K9qbOd018089; Wed, 20 Sep 2017 09:52:39 GMT
From: Robert Wilton 
To: netmod WG , "netmod-chairs@ietf.org" , draft-ietf-netmod-revised-datastores@ietf.org
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <10476e00-0169-4258-449f-22cc7ca978a8@cisco.com>
Message-ID: <8d1d9733-10fc-9c47-1fca-30ab9024fcf5@cisco.com>
Date: Wed, 20 Sep 2017 10:52:37 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <10476e00-0169-4258-449f-22cc7ca978a8@cisco.com>
Content-Type: multipart/alternative; boundary="------------6FDE4B1C5295A37481C6E58E"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Sep 2017 09:52:45 -0000

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

There have been no objections to proposed changes (1), (3) and (4) so we 
will apply those to the draft.

(2) is still awaiting further comment from the latest updated text that 
I sent yesterday.

Thanks,
Rob


On 11/09/2017 16:22, Robert Wilton wrote:
>
> As one of the authors, I would like to see a few minor editorial 
> updates, described below.  Otherwise I believe that the document is 
> ready for publication.
>
> Proposed changes:
>
> 1. I think that the document could further emphasis that the schema 
> for all the conventional datastores must be the same.
>
> *Old:*
>
> 4.5.  Conventional Configuration Datastores
>
>    The conventional configuration datastores are a set of configuration
>    datastores that share a common schema, allowing data to be copied
>    between them.  The term is meant as a generic umbrella description of
>    these datastores.  The set of datastores include:
>
> *New:*
>
> 4.5.  Conventional Configuration Datastores
>
>    The conventional configuration datastores are a set of configuration
>    datastores that all share exactly the same schema, allowing data to 
> be copied
>    between them.  The term is meant as a generic umbrella description of
>    these datastores.  The set of datastores include:
>
>
> 2. I think that the description of the intended datastore could be 
> expanded to give a bit more clarity.
>
> *OLD:*
>
> 4.4.  The Intended Configuration Datastore ()
>
>    The intended configuration datastore () is a read-only
>    configuration datastore.  It is tightly coupled to .  When
>    data is written to , the data that is to be validated is
>    also conceptually written to . Validation is performed on
>    the contents of .
>
>    For simple implementations,  and  are identical.
>
>     does not persist across reboots; its relationship with
>     makes that unnecessary.
>
>    ...
>
> *NEW:*
>
> 4.4.  The Intended Configuration Datastore ()
>
>    The intended configuration datastore () is a read-only
>    configuration datastore.  It represents the configuration after all
>    configuration transformations to  are performed (e.g.
>    template expansion, inactive configuration removal), and is the
>    configuration that the system attempts to apply.
>
>    It is tightly coupled to .  When data is written to
>    , the data that is to be validated is also conceptually
>    written to .  Validation is performed on the contents of
>    .
>
>    For simple implementations,  and  are identical.
>
>    The contents of  is also related to the 'config true'
>    subset of , and hence a client can determine to what
>    extent the intended configuration is currently applied by checking
>    whether the contents of  also appears in .
>
>     does not persist across reboots; its relationship with
>     makes that unnecessary.
>
>    ...
>
>
> 3. I think that it may aid readability if the section on conventional 
> configuration datastores was moved above the description of the 
> individual conventional configuration datastores, which could then be 
> intended one level.  Best illustrated via the change to the table of 
> contents.
>
> *E.g. current TOC: *
>
>    4.  Architectural Model of Datastores . . . . . . . . . . . . . .   8
>      4.1.  The Startup Configuration Datastore () . . . . .   9
>      4.2.  The Candidate Configuration Datastore () . . .  10
>      4.3.  The Running Configuration Datastore () . . . . .  10
>      4.4.  The Intended Configuration Datastore () . . . .  10
>      4.5.  Conventional Configuration Datastores . . . . . . . . . .  11
>      4.6.  Dynamic Configuration Datastores  . . . . . . . . . . . .  11
>      4.7.  The Operational State Datastore () . . . . .  11
>        4.7.1.  Remnant Configuration . . . . . . . . . . . . . . . .  12
>        4.7.2.  Missing Resources . . . . . . . . . . . . . . . . . .  13
>        4.7.3.  System-controlled Resources . . . . . . . . . . . . .  13
>        4.7.4.  Origin Metadata Annotation  . . . . . . . . . . . . .  13
>
> *Proposed TOC: *
>
>    4.  Architectural Model of Datastores . . . . . . . . . . . . . .   8
>      4.1.  Conventional Configuration Datastores . . . . . . . . . .   9
>        4.1.1.  The Startup Configuration Datastore () . . .  10
>        4.1.2.  The Candidate Configuration Datastore () .  10
>        4.1.3.  The Running Configuration Datastore () . . .  10
>        4.1.4.  The Intended Configuration Datastore () . .  11
>      4.2.  Dynamic Configuration Datastores  . . . . . . . . . . . .  12
>      4.3.  The Operational State Datastore () . . . . .  12
>        4.3.1.  Remnant Configuration . . . . . . . . . . . . . . . .  13
>        4.3.2.  Missing Resources . . . . . . . . . . . . . . . . . .  13
>        4.3.3.  System-controlled Resources . . . . . . . . . . . . .  14
>        4.3.4.  Origin Metadata Annotation  . . . . . . . . . . . . .  14
>
> 4. Finally, I noticed one reference that could be improved, by 
> changing it from "(described below)" to a proper section reference:
>
> 647,648c644,645
> <    circumstances, e.g., an abnormal value is 'in use', or due to remnant
> <    configuration (described below).  Note, that deviations are still
> ---
> >    circumstances, e.g., an abnormal value is "in use", or due to remnant
> >    configuration (see Section 4.7.1).  Note, that deviations are still
>
> Thanks,
> Rob
>
>
>
> On 01/09/2017 22:02, Lou Berger wrote:
>> All,
>>
>> This starts a two week working group last call on
>> draft-ietf-netmod-revised-datastores-04.
>>
>> The working group last call ends on September 17.
>> Please send your comments to the netmod mailing list.
>>
>> Positive comments, e.g., "I've reviewed this document and
>> believe it is ready for publication", are welcome!
>> This is useful and important, even from authors.
>>
>> Thank you,
>> Netmod Chairs
>>
>>


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


  
    
  
  
    
There have been no objections to proposed changes (1), (3) and
      (4) so we will apply those to the draft.

    
(2) is still awaiting further comment from the latest updated
      text that I sent yesterday.

    

    Thanks,

    Rob

    

    

    
On 11/09/2017 16:22, Robert Wilton
      wrote:

    

    

      
      
As one of the authors, I would like to see a few minor
        editorial updates, described below.  Otherwise I believe that
        the document is ready for publication.

      
Proposed changes:

      
1. I think that the document could further emphasis that the
        schema for all the conventional datastores must be the same.

      
Old:

      

      
4.5.  Conventional Configuration Datastores

         

           The conventional configuration datastores are a set
          of configuration

           datastores that share a common schema, allowing data
          to be copied

           between them.  The term is meant as a generic
          umbrella description of

           these datastores.  The set of datastores include:

        

        New:

        

        4.5.  Conventional Configuration Datastores

      
    The conventional configuration datastores are
          a set of configuration

             datastores that all share exactly the same schema, allowing
          data to be copied

             between them.  The term is meant as a generic umbrella
          description of

             these datastores.  The set of datastores include:

        

      


      

      
2. I think that the description of the intended datastore could
        be expanded to give a bit more clarity.

      
OLD:

      
4.4.  The Intended Configuration Datastore
          (<intended>)

        

      
   The intended configuration datastore (<intended>)
          is a read-only

           configuration datastore.  It is tightly coupled to
          <running>.  When

           data is written to <running>, the data that is
          to be validated is

           also conceptually written to <intended>. 
          Validation is performed on

           the contents of <intended>.

        

           For simple implementations, <running> and
          <intended> are identical.

        

           <intended> does not persist across reboots;
          its relationship with

           <running> makes that unnecessary.  

        

           ...

      

      
NEW:

      
4.4.  The Intended Configuration Datastore
          (<intended>)

        

           The intended configuration datastore
          (<intended>) is a read-only

           configuration datastore.  It represents the
          configuration after all

           configuration transformations to <running> are
          performed (e.g.

           template expansion, inactive configuration removal),
          and is the

           configuration that the system attempts to apply.

        

           It is tightly coupled to <running>.  When data
          is written to

           <running>, the data that is to be validated is
          also conceptually

           written to <intended>.  Validation is
          performed on the contents of

           <intended>.

        

           For simple implementations, <running> and
          <intended> are identical.

        

           The contents of <intended> is also related to
          the 'config true'

           subset of <operational>, and hence a client
          can determine to what

           extent the intended configuration is currently
          applied by checking

           whether the contents of <intended> also
          appears in <operational>.

        

           <intended> does not persist across reboots;
          its relationship with

           <running> makes that unnecessary.

      
   ...

      

      

      3. I think that it may aid readability if the section on
      conventional configuration datastores was moved above the
      description of the individual conventional configuration
      datastores, which could then be intended one level.  Best
      illustrated via the change to the table of contents.

      

      E.g. current TOC: 

      

         4.  Architectural Model of Datastores . . . . . . . . . . .
        . . .   8 

           4.1.  The Startup Configuration Datastore
        (<startup>) . . . . .   9 

           4.2.  The Candidate Configuration Datastore
        (<candidate>) . . .  10 

           4.3.  The Running Configuration Datastore
        (<running>) . . . . .  10 

           4.4.  The Intended Configuration Datastore
        (<intended>) . . . .  10 

           4.5.  Conventional Configuration Datastores . . . .
        . . . . . .  11 

           4.6.  Dynamic Configuration Datastores  . . . . . .
        . . . . . .  11 

           4.7.  The Operational State Datastore
        (<operational>) . . . . .  11 

             4.7.1.  Remnant Configuration . . . . . . . . . .
        . . . . . .  12 

             4.7.2.  Missing Resources . . . . . . . . . . . .
        . . . . . .  13 

             4.7.3.  System-controlled Resources . . . . . . .
        . . . . . .  13 

             4.7.4.  Origin Metadata Annotation  . . . . . . .
        . . . . . .  13 

      

      Proposed TOC: 

      

         4.  Architectural Model of Datastores . . . . . . . . . . .
        . . .   8 

           4.1.  Conventional Configuration Datastores . . . .
        . . . . . .   9 

             4.1.1.  The Startup Configuration Datastore
        (<startup>) . . .  10 

             4.1.2.  The Candidate Configuration Datastore
        (<candidate>) .  10 

             4.1.3.  The Running Configuration Datastore
        (<running>) . . .  10 

             4.1.4.  The Intended Configuration Datastore
        (<intended>) . .  11 

           4.2.  Dynamic Configuration Datastores  . . . . . .
        . . . . . .  12 

           4.3.  The Operational State Datastore
        (<operational>) . . . . .  12 

             4.3.1.  Remnant Configuration . . . . . . . . . .
        . . . . . .  13 

             4.3.2.  Missing Resources . . . . . . . . . . . .
        . . . . . .  13 

             4.3.3.  System-controlled Resources . . . . . . .
        . . . . . .  14 

             4.3.4.  Origin Metadata Annotation  . . . . . . .
        . . . . . .  14 

      

      4. Finally, I noticed one reference that could be improved, by
      changing it from "(described below)" to a proper section
      reference:

      

      647,648c644,645

      <    circumstances, e.g., an abnormal value is 'in use', or due
      to remnant

      <    configuration (described below).  Note, that deviations
      are still

      ---

      >    circumstances, e.g., an abnormal value is "in use", or due
      to remnant

      >    configuration (see Section 4.7.1).  Note, that deviations
      are still

      

      Thanks,

      Rob

      

      

      

      
On 01/09/2017 22:02, Lou Berger
        wrote:

      

      

        
All,

This starts a two week working group last call on
draft-ietf-netmod-revised-datastores-04.

The working group last call ends on September 17.
Please send your comments to the netmod mailing list.

Positive comments, e.g., "I've reviewed this document and
believe it is ready for publication", are welcome!
This is useful and important, even from authors.

Thank you,
Netmod Chairs




      

    

    

  


--------------6FDE4B1C5295A37481C6E58E--


From nobody Wed Sep 20 03:20:56 2017
Return-Path: 
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 7AC8D132D41 for ; Wed, 20 Sep 2017 03:20: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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_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 H3FfrYSkzkQw for ; Wed, 20 Sep 2017 03:20:52 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0126.outbound.protection.outlook.com [104.47.1.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A69EB1241F3 for ; Wed, 20 Sep 2017 03:20:51 -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=vMRcqCdADYKuB5kcJn/JKjUiWMHNwjnj2Pg2KQDnFh4=; b=NZ8Y0VsCBJXfme2C8wyM0pVnXByqpGzsh4YbP0cUbpf2tnnHu2fJC1bEIML1uYYCbZXi45j2C6D/5saHNseb7LSLGTif5SKaPmP+zZ/FuxRNGoRDtSrfPO/aUvSbn2G5Kq6pY2qd/pe/jod5ep+O/exIbCPL/0uAnN5oq+DLTy4=
Received: from pc6 (109.146.128.123) by HE1PR0701MB3002.eurprd07.prod.outlook.com (2603:10a6:3:4d::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Wed, 20 Sep 2017 10:20:48 +0000
Message-ID: <031701d331f9$e64cffe0$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: , "Martin Bjorklund" 
Cc: 
References:  <20170919.132947.358857445863848356.mbj@tail-f.com> <990b8722-7a48-46ce-3f5d-96bc5cb66075@labn.net> <20170919.154238.1738748131929616921.mbj@tail-f.com>
Date: Wed, 20 Sep 2017 11:09:07 +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: [109.146.128.123]
X-ClientProxiedBy: AM5P194CA0007.EURP194.PROD.OUTLOOK.COM (2603:10a6:203:8f::17) To HE1PR0701MB3002.eurprd07.prod.outlook.com (2603:10a6:3:4d::8)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: a32fcfba-ab84-4dbe-0083-08d5001143ae
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:HE1PR0701MB3002; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 3:Yt37XD5r1fCEh2DtpsM5w3ECulVj74A1j8nb6o+8ZKsv2bhskKoryfRzDicHfmMojSSU+O5jVQHdF1wKpUcFcxtxOpgB7jLSGKD4qwQWoaZ8MnIiBaeVoVVBAHRaYedP6P7+XAtRPl/JySDzy7pOXICZisiGbf9Gz0eQiVmM2dVNeYcHwmvvtQ2KzbpKu7KhpjqLThUL+fRD52UvPBj71Pem+HzzMp2IOP8bI8Kmy51BudoUKJChTya6NDHnaNTx; 25:rbZGkZrVTRyiST05sNy5G/bXxNKmzlmhiVSchMqC7l9q7ZITg72gYjj9s4pzypVOt9YjYwMZaaWZZvWraf8YFfIYFFZmhSZHRVcM4x5BQ00L4kt/0SlM9qzlLiOBKYz3AEdteL6VpoKit72XzBLGSaSE9LYqV621Qc0S4Tniy7iUX4YPWFJoPymUrBF3XsE2i83APAN3IPgSMtrlf4epJ6Joc/+UlzfEAb5RVyp+YtMFaBjZqpKLmwrIA3vERSL7hWE4XuWb3S47g4rxwkCeq40zYZjbVKE3YFGbptDJyEFb0CZMYBrwZIrVLII1BOyH4/8pn0FtRISaW4SwAkFZcA==; 31:4pKEB+cY1lpUyibZHAAK20qKy8o+SFoNasGZgsZYTLw1A6EbyWmdLgO1MuXorMnsIwJv3scF2cedgp0H6BboGyyIsHaTHErzRZmT25LTXtgj9rPW7e9dz0QDoeKRweviBgGkfvOtM0MsYgQrHuu0IbffYF31pMDj+Xl/Fn03LzrqblTYT7jtjAvjOQzKN16/XicBdbaEmiG4ccua21JxAqt8sXqST8i2TxmOTzYPiDE=
X-MS-TrafficTypeDiagnostic: HE1PR0701MB3002:
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 20:Oquyl4ZsLKwK99XD9AMZ8oLzwHtDTac9z/hrdnx/+M6FCdCQ6o7ZrhtA3Xcq291iYPIz+D1hXBCYLWo0QjeaRjPF2CdYCh0bpp6OHN/ziFYQ/2Sp0aiN1EPwYhQ9TBKjF7LgfbNwoPRWFmjfz6qHJYidurEtna343dHzSHd0zIjmh2jKsJb7mhKxCzkFJw68OlAu3sT/HnX0y21Pmn3cCnJchHW/zon/kovREU/WOPU73Sek4muejyBFlZQFxFt9ycxSb+MDJFx+OJTiYooL5YRRZ1FBT3KXxykOhOcwLfjkP1w9orbHNHyZ56FosEIOs+OEgDOCuvgPLnRzvWPodQ==; 4:3hjIytgcRiRwwVbKCoDXxYQ83EvN2BCcZv0cRV6gN5HUC7Zbt1Mc+K7fACMJg0v/7kr3bCpEtQs3rqP6NZ3LDBdPp38A4EzypeNKHFDgN9eGL+RHFxSG/XTCB+0bjViGjg5o7fq6+90uXd5JBqsmyCFWIWK3318b2/gWXZiLp56iOi5MA/bZ4sl/1QhTLWxkx+oSbF3AuvV+MdwybTGzevgn7bbKEglnOLdKiVVwFCrQc3kqdNkh9IeNdvwmaLi6XHWZAAh+Tq+twGBKNSMIhZJIeARQWNM8bf02UuTQl3ZW5SiRe0FHQsoRzbyHroURg+5L8kovfCDoSFeHtXibeQ==
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(95692535739014);
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR0701MB3002; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR0701MB3002; 
X-Forefront-PRVS: 04362AC73B
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(346002)(376002)(51444003)(24454002)(199003)(13464003)(189002)(377454003)(97736004)(53936002)(53546010)(6116002)(3846002)(1456003)(316002)(110136005)(16526017)(2906002)(68736007)(25786009)(6666003)(4720700003)(62236002)(47776003)(9686003)(23676002)(189998001)(66066001)(116806002)(2870700001)(101416001)(44716002)(33646002)(84392002)(1556002)(61296003)(6496005)(8936002)(81166006)(8676002)(81156014)(6246003)(229853002)(4326008)(81686999)(305945005)(50466002)(50986999)(5660300001)(105586002)(478600001)(81816999)(93886005)(86362001)(50226002)(106356001)(14496001)(7736002)(76176999)(44736005)(6486002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3002; 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?MTtIRTFQUjA3MDFNQjMwMDI7MjM6RzMzVWRCVHFVajhscEJCRlJITVZKa2Qz?= =?utf-8?B?R0p2KzkwTEM5RTRDK3ZzM0s0RkNRNUNNMy9sVFRueTBxYnRoakxwUEJ3ZW5l?= =?utf-8?B?L2RUTzhwM1BiZzE1aEoyaVNTSmxnbitBSmNYZDZTK1ViVmkyOC9kS3Q0bkdx?= =?utf-8?B?b2o4bHlrVFpIVDlPQzJZWGRYMVFJUkhhVmpmWWlYa1pmSnAyNkNBU0hCRFdQ?= =?utf-8?B?d1dPSUJaZGl1dFAzRFc0ZTI5UUZYYnBPczZlWkdkOFBKVUY1THdXdExUd3p5?= =?utf-8?B?RDk5amt1VlBtcFliUjlVdElVeUxibFFmR05vbUNPSms1eis1UFk2QnRDWkdo?= =?utf-8?B?YUxXUXI2NW05SVc2Rk9jKzY4cmhwWWlHQVZHMWFaWldqd0dvLzkxL1hGQmZX?= =?utf-8?B?SUx0U01DRnVFMHJGN3gwZnRZeFpJYWJVSi80WjhLdEJMNW9KaEJmMXdSWjVS?= =?utf-8?B?RTRFR3dRdmVYRSsyclpNQk81b3YzOThoRi81eVA0VXFIM05iMnJwT09hb2c2?= =?utf-8?B?SHhLSllQRXQySStEcG1zUzZXVmVoTmxKbEhqNFJDTUFnY0pJblJpTER6S0lT?= =?utf-8?B?a0Z6SVpEcmpJbkh5UHFLWDk3NjcrR084Y1QxSEU3VXhXZ2taczM3SmQyR2hx?= =?utf-8?B?NllEa2h0SUt0V2tYQ2dodGdiTGUvV0R3WUhjNXljOTBTR3MzN2VuWjlFcGV0?= =?utf-8?B?ckQ3SmdsY21VUy95TlZoN0RBelpsK1BJUkU4NldBbXJjcHRES2ZqS1FKdStE?= =?utf-8?B?LzJEeFZpd1lUeGlHeTlxTkZmNlkrWGFvdjN3T0lZRDVndFREZ2tndG5lcURt?= =?utf-8?B?Y2VnL2hNeFpNV0h0c2dkVGpadjVJdmdYMjRyNVJmcUhVQVYvTnh1Z25jZG9q?= =?utf-8?B?cFdPMmY0RDFDNVV6NVZvVkxLczBoRC84RFVJekxkLzdJUWNMSTBRZS9qS2x5?= =?utf-8?B?bG9qdGN2YXF3TDczWER5WmFySUNyZDBZbUs1TjZSRGtwSHlGcTNNakNsajhL?= =?utf-8?B?Tzh2UUszS2xCaFdUWVN5VlR3WEJZRXY4ZTB6SGp2TDI0VDNoMzJBUk5rMitn?= =?utf-8?B?L1czSUJWQktEVUlIVExvWENqMDlFZlhzZnNOdjJ0M21oQ2lCempGbEJ0ZGRj?= =?utf-8?B?ZXpJNGUwMzVTMitRV0hzQ3JHSitTRy9nNkNseUsxd3FDVGVtWjlsL2hPcVRX?= =?utf-8?B?NjFKU1J3R1dHK2lIUTJDcmRYdWY2NmVDK1JYNjliNXI4eXBnWVBoYWdCNENL?= =?utf-8?B?bk8zOFExQWVwMzZpQk1lWE1OR0Fjbm1vNnMydFJHNm9EYUFjUTFsQXhKQXo1?= =?utf-8?B?UE5mOTRMK0RnNFo0MkgxQjBGa3JVMmplajl2bWd5U0F0WE1DRmJHRVQ1TXVN?= =?utf-8?B?MnBhamMyK3lobmFxaG9YUTdJcTljdno5alg0U3RqUVpOZTRyemtqUFZId2Vt?= =?utf-8?B?WGNoTStOaVJSbHNiS2NETzlXb21rVHdUQUNtYS9hUFJkQ3pEZm1HYmk0SWN2?= =?utf-8?B?K0plOUlQMVIza1g3enhKSTh3QW5EYmRtby8rb3BNVWxObGUrUjZ0UXpzLzFw?= =?utf-8?B?dm84RUp5RkRCSGdkbUh4S1RCMTZFTzI3STlTWW9PUlUxUlZsa0Fzc1BHbXdw?= =?utf-8?B?MnpqamlTVndRczQwS2RXOVVuS28zZjk3V2tHbUt3VHk0OW04UHBuKzJyK3ln?= =?utf-8?B?a2tNZytCK2hZaFpud1JuNFJOM2MvUkJYN2hUOWFzbmdaK1VpSlRNYngxQkhQ?= =?utf-8?B?KzV4NllaVTNyQUpCcGwzVnErcXdSZjIxUTBGczA0c09UNGhkSnEyaGRVVSta?= =?utf-8?B?ajJFQlNKczRLQU0wL1d6TTdlWU83ZDdIQXhtM21qN1M3N1pBV1YvTzg4R2o5?= =?utf-8?B?Z3RBaFRQOUtWemZXaVc2eWRUQVR6MktSS1FCKy9qK25pSnhwRnZYSFZWUW1H?= =?utf-8?B?NGVzUG5SRVVNTkpWZkt4QWxPUlAyL0NnLzNNTGRrQ3dzTEJjUmo0b0FHdmJP?= =?utf-8?B?eU55c0tpZmQxK2t4WEZXVENieUEya3MvSnU2RDRBPT0=?=
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 6:aCgPVKo2F9Y6EPLXslQn6z+fLLU76vSlxOVRM8GuOqfEdx7fpeyFnfhscD1BdmVuHmKWd1iV9eTEFEIf0+0ce33PhXPCobDS8b96L6G1vn8IHAPpKEGixSocs++wrXQHJn3xxrOpjK/WhcoeCLUcrumX7sIdqR7vo6uBDmiT824jO5K+2XIOByxkSycfY6xzZiIbGsVx3VFw1LeqXnycMUbzamzvJgSKQW7/piEV1A9Spj8VhHoP6d2nPNuLQRQYmHeC2CByIZrsW9PexokQJiWmRJrUXv4QcRXhojnjtquUubuq7Sl6BpSwiMgotYUOwGaWkNPXNxD91AvawTxkqA==; 5:A73EGccDWv4JHss+li/qqm7vf7V/oEZQj1BD1p03mufOmNu+264XIb3nNCcEkE05dTK/C1+/1osJ/dyiI7D/tUUC/QhwG3nN+FsCGirf8gNjKGgrpxk5eUi2s4cGsrny+NQ05xLTBnjuvqcltuKnfA==; 24:IEZqSCZtNKCMCTEXrREVr32jchc/TuB8sKdjj3AbyGmUi7RV8KDZ1q2jB2CnbPwvuKJCz7nPYcdRgMqG/rwEvTk0NdfYI8l1JBofzl6oe+c=; 7:KlKjabVzJbDSY023/0mnlVTA+BqqftDn1slDSPtqj2wzdcPEslq/0wKtc+CKbcrtpy+65D+wXpA1cQXxFvntaoKB4Tuw8cdbVgkdOROjsFTh/I27sG/bQ0z6VHtcYLvQLn4ogw533QZjkwWQigDEoNQoc8eYbhyHvDDwHfl1H41rIRuqIJ7TpjIUzgz1cWF0ucJvrGoWu22k2dxYur71rJ1MwmsdkUgvt4At/u5DNa8=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Sep 2017 10:20:48.8495 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3002
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Sep 2017 10:20:54 -0000

----- Original Message -----
From: "Martin Bjorklund" 
Sent: Tuesday, September 19, 2017 2:42 PM

> Lou Berger  wrote:
> >
> > On 9/19/2017 7:29 AM, Martin Bjorklund wrote:
> > > Lou Berger  wrote:
> > >> Martin,
> > >>
> > >> Speaking as a contributor:
 > >>
> > >> On 9/15/2017 7:40 AM, Martin Bjorklund wrote:
> > >>> Robert Wilton  wrote:
> > >>>> On 15/09/2017 11:21, Ladislav Lhotka wrote:
> > >>>>> Andy Bierman píše v Čt 14. 09. 2017 v 08:43 -0700:
> > >>>>>>
> > >>>>>> Actually I liked the early pyang output that was concise and
easy to
> > >>>>>> remember.
> > >>>>>> The current format gets very cluttered and there are too many
little
> > >>>>>> symbols
> > >>>>>> to remember them all.
> > >>>>> I agree.
> > >>> Me too.  The current draft adds three new magic symbols: "mp"
"@" and
> > >>> "/".
> > >>>
> > >>> "mp" is for a mount point, and it can be generated directly from
the
> > >>> YANG modules.
> > >>>
> > >>> Directly under a "mp", "/" and "@" are used to indicate that a
node is mounted
> > >>> or available through a parent reference, respectively.
> > >>>
> > >>> I actually question the usability of "/" and "@".
> > >> I agree that / and @ are something new, and enabled by schema
mount.
> > >> There have been repeated comments in the RTG WG that there needs
to be
> > >> some way for vendors to convey what they have implemented with
Schema
> > >> mount
> > > If that's the requirement, using the tree diagram is probably not
the
> > > best way.  The tree diagram is intended to provide an overview of
a
> > > given (set of) YANG module(s).
> > >
> > > A perhaps better way to convey the information is to create a file
> > > with an instantiated /schema-mounts tree.
> > using what syntax? JSON and XML really isn't that easy for the
(human)
> > reader to parse.
>
> Either JSON or XML.
>
> > >> and this is one way to help convey (a) what is expected of server
> > >> implementors and (b) what client implementors should expect.
> > >>
> > > Hence the
> > >> current draft text:
> > >>
> > >> In describing the intended use of a module containing a mount
point,
> > >> it is helpful to show how the mount point would look with mounted
> > >> modules.
> > >>
> > >> The whole point of trees is to facilitate understanding for those
who
> > >> are less familiar with a model than the authors, and IMO that's
the
> > >> paramount perspective in this discussion.
> > > Fully agree!  I would say that we have to make sure that the
diagrams
> > > can be understood by people less familiar with the technology than
the
> > > authors.  Mixing schema and instance data does not help here.
> >
> > Can you propose an alternative?
>
> As I have written before, I think the "/" is not needed, so I would
> remove that.  I would also not list the nodes from "parent-references"
> in the same tree ouput.  It is not clear to me that this level of
> detail is needed in the tree, and - as noted before - it isn't even
> correct to list e.g. "interfaces" when the parent-reference in fact
> selects a single interface.
>
> > The routing WG participants seem to
> > find these useful, we can also ask there for broader input if you'd
like.
>
> One approach is to add the union of eveything that some people find
> useful.  In the end we have to look for WG consensus.  Several people
> have said that they prefer a less cluttered format.

A union is what might be termed the OSI approach to design, an approach
that led to ... well, ISIS and that's about it.

draft-ietf-isis-yang-isis-cfg-18 has some 10 pages of tree structure
which are of little help to me in understanding the module.

With draft-ietf-teas-yang-te-topo-12, the tree structure
runs to over 35 pages and then I think that the tree structure has
failed.

Adding more symbols will not help.

Less is More.

Tom Petch

> > >>> Since a parent
> > >>> reference can be very specific, e.g. one specific interface, it
isn't
> > >>> really accurate to show:



From nobody Wed Sep 20 03:21:02 2017
Return-Path: 
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 092A01241F3 for ; Wed, 20 Sep 2017 03:20:55 -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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_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 wQ4Fl5c-2KbK for ; Wed, 20 Sep 2017 03:20:52 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0126.outbound.protection.outlook.com [104.47.1.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85C8F13213D for ; Wed, 20 Sep 2017 03:20:52 -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=6TnlB/CUZxYxhlMj6n3Uot1CvwjceHC3v5LTzWjji74=; b=bzroWWnD6x86O/wfvAQYOCuxSO2YvC0Y+0a2Ksf4rhr4xy2g8FwZI0ecqSzIsnG2q+2DqnE3tkUDKyO8O/MS1Yvcc599UnqJ49lUsMoKZi3OgugoQEUr3mC18ZUGqCGM0JO59dRbA54HzQ7dGYCxJspmED/eW1qf5EsQvZlckn0=
Received: from pc6 (109.146.128.123) by HE1PR0701MB3002.eurprd07.prod.outlook.com (2603:10a6:3:4d::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Wed, 20 Sep 2017 10:20:49 +0000
Message-ID: <031801d331f9$e6b95640$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Ladislav Lhotka" , "Martin Bjorklund" 
Cc: 
References: <393d3f20-98e3-b4de-e2d7-d627de59ac1f@labn.net> <1505814417.5445.14.camel@nic.cz> <20170919.115915.1668734288988659917.mbj@tail-f.com> <87shfistam.fsf@nic.cz>
Date: Wed, 20 Sep 2017 11:18: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: [109.146.128.123]
X-ClientProxiedBy: AM5P194CA0007.EURP194.PROD.OUTLOOK.COM (2603:10a6:203:8f::17) To HE1PR0701MB3002.eurprd07.prod.outlook.com (2603:10a6:3:4d::8)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: d221cb29-d473-49e8-d3fe-08d500114422
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:HE1PR0701MB3002; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 3:fMjKVj0bCqhv+yCmdyTDORyxXJShd8pzPmTClrcQ6Kdu3LhIr/SHqXMBkBwj+BDNVriFXXZ1puJ0IFKqKMHjZut8aQCTmNGercDqtKElYat04k0mo0evnKaAgRctNaRKD9olAn5+2e9h3uv2whAGsSxOPvewCZ7nAC0m8BZ8R4QgU47AnpJz0SDujjTEx4GoPYSnrm8myRTO185WZ+Wz3rdPXq+0h7EURqSyaNLTRf8pJTaAFd1kvO0Us+la85Ka; 25:KWLSjtF30aQ6InWSDbbk6yYw9xi9/E3MXx5oRNnNuUTv9Lq4oyDxPSnGboi9ofvFP3dt7SqnkBQAqyX8akza56KOsyrlQucO87LFAlsinylO+LMkhPo6EX3Hlv2w5bnaNkGOCIM81qmLYDt2sCmuP4XMFNeRgLOZrAKtYv0VhynsFtCJloUTdDtuK9VbhcTNnweN3IqvI4A7B6p0fayrbK2oDKwiGUdFBh/9exdhotdNSVjenukExBDThcvlsUciZs9o3TxajaYjynuRUaklECE8egyffZo6TwEsoyxFkCd8FRBTEYQheJZrwu9GdgfhBBKpG/jOZ1Pw22MNVYW9JA==; 31:AjbA9NcES30iqzL8+Xmvms97M5g06p8ULUGK7UbKjbONgptP/OVSQMuHcIdc7aH1q1JMtvwmVlKcpkpqWrniPtTK8vkfN7ESBApveoQu5kQuIBYcLbPqcs5qu0G12LOsNeiyCcEmsOn5ErpGP88aIV+m4fWhA7AGJLgYs9atchV3RCIQ52zhO9LtqKvSO9NHUroPf/MNK4bF7293GgMAIVa3obx9iNdSVHVSjgeJOFQ=
X-MS-TrafficTypeDiagnostic: HE1PR0701MB3002:
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 20:GbRKoB6SfznkDZ57qJhZm3H3OBun5bhs+/iL/SI6tZ+g4waxtT6WcMw2KJLrvvDc94FASarl6/lDjA0qjW1NihHTW2Dp/el6IwGETSsGXbpMBQxtw7RLQLfgFP0Y5ttqrosFiiCHCPefSkuEw8goT+ZPPzfCBhHwqjZ80LXzxprJByhUIQJvg5eWEuGPU0tX5f/t3NCoRizlJ/YDCyhcf0VnWQZl0ekfDetHj9T7veidDKBThgirkoF8j1IcTiJz27MdQ/H08fZXMUq3OK+nrLEU2RmcZERufhUiGN1HLuZ9fzGGjNisjmX3F7/QOKpGNhkNle1F1dCjaeF0BR2WXA==; 4:sE1uwwd2TFqGutNp8roVpRDnORUbv2TLcOptxgcXZIGz6lZ9pkzST28vYLemgBAWCZm4ctCFN3s/OToqegWkjlBCat6gPVW/a7Mwc7Ugr3nsP9CoHgfHqGdnMuii/nAi3VzU7Py8fYjvuKPr0bPeySaF2algDJPFpveELn4WBKNsY7rnckJAN3dRL9j+T2y6xLw6nN+dMVqahuFHLAVeAjGxlB2O6WlGZK6VkuG16DFhV82E9WFq5xESDXV8nH3e
X-Exchange-Antispam-Report-Test: UriScan:;
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR0701MB3002; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR0701MB3002; 
X-Forefront-PRVS: 04362AC73B
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(346002)(376002)(51444003)(24454002)(199003)(13464003)(189002)(377454003)(97736004)(114624004)(966005)(53936002)(6116002)(3846002)(1456003)(316002)(561944003)(110136005)(16526017)(2906002)(68736007)(25786009)(6666003)(4720700003)(62236002)(230783001)(47776003)(9686003)(23676002)(189998001)(66066001)(6306002)(116806002)(2870700001)(101416001)(44716002)(33646002)(84392002)(1556002)(61296003)(6496005)(8936002)(81166006)(8676002)(81156014)(6246003)(229853002)(4326008)(81686999)(305945005)(50466002)(50986999)(5660300001)(105586002)(478600001)(81816999)(93886005)(86362001)(50226002)(106356001)(14496001)(7736002)(76176999)(44736005)(6486002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3002; 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?MTtIRTFQUjA3MDFNQjMwMDI7MjM6Tk5LRm9rOFQ2Ri9UOUlMNTg1OTY0ZTk4?= =?utf-8?B?RW4vNzRwcCtpdyt5YU9DYWR1NjFQMWprT3BSU3ZSV0s0aTM1SjNjOW1LY0l5?= =?utf-8?B?V0ZIMHJMYXo2N1BKU2ZmY1paWFlkd3RpczVGd01XRk5VQmNqckVaaEdUN2Zh?= =?utf-8?B?NVNKWC9ud0JxQURCNzRmYTlFZEIxZGZvQ0lTYTVhWFp2bGhJRC9DQ3lKc2ty?= =?utf-8?B?NnJWSDBDcXUxa3lCQlFvRklnSUx4ME5iMlBHaDFNSmtkSmxuU25yZ0tuMm4w?= =?utf-8?B?cFdoQnJ5L09Pd0FxSFU5WnRpaWhrVG5XQm9xY1FDOFpVMjdrQktmUVJraWZh?= =?utf-8?B?Y3ZTYTMrTzhYNVAyekV0RDQ2T1gvTEtyN0wxUCsvUUs2THNRcjl2SUhRTkE3?= =?utf-8?B?eThKODN0ZjZ2RXhDOVo5ckZNYWV4dmpvWThkSFpVd2FkTkt3L1phdVI1ZFR2?= =?utf-8?B?QkZmY0ZvdEpGZ1UzOE1DWWFjaEp5VENiam01NW5LOFByaGhqSGJJWVU2SDZi?= =?utf-8?B?VFZyQVM4eFNKU3BTM3c1cmJ0cXlWV1Z0Uk05M0VHMEhQYTY4Y2Nnem5NV2Vq?= =?utf-8?B?T0pzQXQ4dmdxQnhMSFNuRUpTS0ZQWm5tci9jN2tPRXV3RmVDa01yTlJZWEwx?= =?utf-8?B?dXZVU0t2RnhHNkRmR3UwNkx1cElkWHZvdkZET1JrVDZycUxrSVY2ZlBkMCtn?= =?utf-8?B?TjhsS2tJam8vZDVZbE1YbnJDblQxYW5oT2VtdU5Hak9OVEJYU1JxdlJzUGhn?= =?utf-8?B?NThPS0FSNEJxTDAxam53MHQ4MlBkTWlkU0FOcXFVU092bHEvb3R4VzU2RXZz?= =?utf-8?B?d3JQNGZmV1JZZzkrODZWTCtwQldydklqZG5uTElJL3VjWlhOTEwycTN4K2J5?= =?utf-8?B?MlIwbWZNNEk0VFRBblM1RFEvVlh3QW5QOHY3dlptMGVjV0hmaWs3N0xubXN3?= =?utf-8?B?RXQvbmNNeWdTb2N2Q0VZVzdTTlJrbEpIRmZsTE5mVjJlYmVPRFo3TUtvK2Nn?= =?utf-8?B?MElUSlFZWEViWlBOcExaNS9uT2lpZml1TkFpMkNBKzUxbDNYaGoyOXhXTWRE?= =?utf-8?B?NHJGcnVtdmZUNVJiVFRueVk3bTlDYXlpNWNMcUJINng4LzRUVWxYWE1YTHBM?= =?utf-8?B?U3paWCtPdDRtOGo4ZHBtbUw3UE5VbG0yT3ZENGZWakx0cEg0clNSNnZMOXB2?= =?utf-8?B?VUdIcmsrc0dSd2ZOeVdiTDVmelh0dVJ2K0FoQjlGU2Y0bmJqZldBY1QvWHp3?= =?utf-8?B?QUdnKzZYcXpRQlRsWTN2QW1DazIrSXBBRFpqandWL1g4YWhybGhIQTYweG1I?= =?utf-8?B?dERUclZsYVdtOFp5SWpFdmVBY2hCMjNuOUtzcFpvRE5ORTNRZnZCeEZkdUpw?= =?utf-8?B?UjRXZ2FnWXpUdkkrZmliQzZaTVJ1Tk91N1ZhdFZvbTVGRHVnVE5JUDBSU0Jr?= =?utf-8?B?a2F6SWpSWEloY3ZLZE85VGkzcUY0SG8xRXB0ZjJURFJXMFlybnNOcm5UejFj?= =?utf-8?B?SGJ6dlg3OVlBUG1leFoyUWNFYjR1aTBiM3NYbnB6SVBkd0xJc2FrMXA0V3oy?= =?utf-8?B?S2hQRzJ1dTRVSWFaTWRvOXljVU0wUURKRUJKMVZsU1JVYjUzUzBSOEtiQVVW?= =?utf-8?B?ekUvTVR1RWJkQzBVOXJpY2NBbUxLQ3c4M0l3Qi8vTjZFem0vQnczSllJaThO?= =?utf-8?B?QU5POGFwdDAvZGduTkpGdUJQa2hJWWdZYitwcTdoWDQrZUZ1ZFlyUG1DMm9o?= =?utf-8?B?Sk9YdG1JYkJxb09Jc05TSUVFWlRTaTVqc1BDN1FjdEpXeFEvazhIeEtQNEdJ?= =?utf-8?B?OU4rK1pOZC9zblEvaFV0MGtXU0ZRZmg1b2NndzV0ZW12SWFwWFFpNGhsZkwx?= =?utf-8?B?QjAyWE5JQ0N4VDQ1T2pXUVZ1TXEwNXc4WHFiTmdJenhQMTZJQ2hVVEFWNW9a?= =?utf-8?B?cTVPam1yeUxZYzNaVGU3VnBhYWhITzdpRnhld29neXRzaUV6bnR3dzZJQ1FH?= =?utf-8?B?dHVLWnpLckFzRUk3NEtsRzBRQ3IwVGRzV1ppektaelVwbzNXT25FMUNhRXpt?= =?utf-8?B?Q2lsdEd5NzNQQlZQOXl1RDNnb2JaQXRQV1RiTEc3T2dPUzkwRHc2b2ZGRk44?= =?utf-8?Q?xP/X61ieu44miLxX6aGtP8pYA=3D?=
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 6:7CpOZIrzmDgsy92x5uDg9idLNDoqc4ceUCJsomFlsCfdYw6nlcK4QX2dtSiMI/C8Qg2oPhBpLpy+sN+UliEAtpRFOEEKuHDKy1uRm0AcGya7HdCkMfksTY3LAgtUZ4lSEcKfW2zeyB4Z1hX6xjryNEZTKg3ucbYI0kB8UispGJ0ddvABvNEVl8qdqOuE355gwBWXMdgQbae2BWVNUJVo2uUcyFNjzsES1mcVy8jSoNccjiXNBUdAOak/RSyK+FKFVUrZKzia8JW/mKwJnMYE+8G0ADAtWoC3GY5ayqM8DixJkhLWimU+dlRBFrEhsYIe4FX9zNtGSa6iIgTPJ+Zg2w==; 5:sdO6WyNHolMjkMapvAh6kWgj4vSVoBMpgSxnKKo9fh7ERBxCz1Sk41YiSqjQ+TBeEJfcFcJrjNLC7/qmXt4MnQUiJPCX0mvpzqJsRLF4ifGxdd9TwiysdVZK20b3fdgfLYAIawcVKD6PfFkfIjOIRA==; 24:eOdxkQgqgPuxYR1EBr7ZUIPIfnt1MrBvtZfAJJGAXsFgwxTIaZlQGH8HDWVBgAtkNNc1mUU10yTHEQeSKfUOyBjDafqKBSjegTDCgvWutm0=; 7:GDjtth3mWho8w0bRUmVnefHleoJeZ9X1WnfUyUnXwahK545xBI1gugAwMDJ3rpgS7LXKWlPI6ucj4EPgWifjdoe16g/JT3+quolgCbqoS4Z0IO/sWE4VC+smdwODY8Y2QNTpHoHOwHV2DaRzV80Zspr72SfHGdrRa0ukBb/lNTY7CzIjwpvu5QO1mfA/SNNf2Iz++oThIl+QY+hbzS9UpC7KsgWQXXp5ERuzbTbd1Ts=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Sep 2017 10:20:49.5995 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3002
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Sep 2017 10:20:55 -0000

----- Original Message -----
From: "Ladislav Lhotka" 
Sent: Tuesday, September 19, 2017 2:37 PM

> Martin Bjorklund  writes:
>
> > Ladislav Lhotka  wrote:
> >> Hi,
> >>
> >> I support the adoption but I propose two conceptual changes:
> >>
> >> 1. Introduce a new module name and namespace so that it is not
> >> necessary to carry along the deprecated baggage. If readability is
> >> the primary concern, this is IMO the way to go. Instead of
> >> "ietf-ip-2", I'd suggest something like "ietf- ip-nmda".
> >>
> >> 2. Avoid obsoleting RFC 7277. I believe the old modules may
continue
> >> to be used
> >> in areas where NMDA is an overkill, such as open source home
> >> routers.
> >
> > Why wouldn't NMDA be appropriate in an open source home router?
Note
> > that the new model really just have a single tree instead of two
> > trees, so the data that needs to be instrumented is more or less the
> > same.
>
> It is quite likely that some parts of the data models will be
> implemented only as configuration but not state data. In the "old
style"
> modules it is easy to add a deviation for the node(s) under -state but
> in NMDA style this is not possible because we only have one node.
>
> There are subtle differences in the schemas for configuration and
state
> data that the NMDA concept doesn't address. If you want another
example,
> ietf-routing-2 has the "router-id" leaf that is conditional via the
> "router-id" feature. If this feature is not supported, router-id
cannot
> be explicitly configured (it is assigned by the system) but in state
data
> "router-id" needs IMO be present in any case. But the if-feature
> isn't able to differentiate between configuration and state data if
> there is only one node for both.

So add a second node!  I think that the idea that NMDA eliminates all
duplication of config and state is a myth; there will still be
duplication where the life cycle of the data diverges, ie it is not
really duplication! I think too that the twin trees approach, while
clumsy, was easy to create; the NMDA approach is more subtle, more
complex, easier to get wrong.

I recall that in the initial stages of discussion of this issue there
was a proposal for an object to have potentially eight different
characteristics so what NMDA gives us at present is limited and will not
solve all the issues of needing more than one node.

Tom Petch








>
> >
> > In fact, if we claim that the new architecture is not appropriate
for
> > some devices I think we have failed, especially if the conclusion is
> > that we need to maintain two versions of all modules going forward.
>
> I am not asking for this but, on the other hand, if NMDA versions used
a new
> module name and namespace (my item #1, which is what ietf-routing-2
> does), then I don't see any pressing need for obsoleting the old style
> modules.
>
> Lada
>
> >
> >
> > /martin
> >
> >
> >
> >
> >
> >
> >> NMDA
> >> implementors should be aware of the new modules but there is no
need to
> >> eradicate the old data models.
> >>
> >> #2 applies also to other modules for which the NMDA version is
underway.
> >>
> >> Lada
> >>
> >> PS. The subject is wrong, it shoud be -rfc7277bis-
> >>
> >> Lou Berger píše v Po 18. 09. 2017 v 10:33 -0400:
> >> > All,
> >> >
> >> > This is start of a two week poll on making
> >> > draft-bjorklund-netmod-rfc7227bis-00 a working group document.
Please
> >> > send email to the list indicating "yes/support" or "no/do not
support".
> >> > If indicating no, please state your reservations with the
document.  If
> >> > yes, please also feel free to provide comments you'd like to see
> >> > addressed once the document is a WG document.
> >> >
> >> > The poll ends Oct 2.
> >> >
> >> > Thanks,
> >> >
> >> > Lou (and Kent)
> >> >
> >> > _______________________________________________
> >> > netmod mailing list
> >> > netmod@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/netmod
> >> --
> >> Ladislav Lhotka
> >> Head, CZ.NIC Labs
> >> PGP Key ID: 0xB8F92B08A9F76C67
> >>
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>


From nobody Wed Sep 20 04:05:01 2017
Return-Path: 
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 83F99134230 for ; Wed, 20 Sep 2017 04:04:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 xL_Bzgsx_thw for ; Wed, 20 Sep 2017 04:04:57 -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 E6BEA133087 for ; Wed, 20 Sep 2017 04:04:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7714; q=dns/txt; s=iport; t=1505905497; x=1507115097; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=7W7b8rw1XK/Fz483VTy42vGTMkGTNim6oIJsJJOcAc4=; b=Ffb784VMpmAA4fNtT29M/DxLzOvA9H7ZjKAM7XGjVE+TD0glj3PDbUQ+ XyQDsVokxIPXjZkHLKkgsha/s5zVKEEcxJvZspzV+nNF9lPEivzAKN0cZ cqy1ncn6ziKAjvcoqVxUba4FdlcCXM/doQ1xzxh/qeRIFXQeH+MKKIrVA 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B3AQBySsJZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy2BEW4ng3WLFJBJK5YmDoIEChgLhElPAoUkFwECAQEBAQEBAWs?= =?us-ascii?q?ohRgBAQEBAgEBASEPAQU2BgUFBwQJAhIDAQICAiYCAiciDgYBDAYCAQEVihIIE?= =?us-ascii?q?IoWnWaCJ4saAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBDoIdg1OBZCuBcIENhEg?= =?us-ascii?q?BCwcBgzKCYAWKCIcugWiNcZRXghOFaoNahySNYYdXgTkhAjSBAgsyIQgcFUmHH?= =?us-ascii?q?T82hlYPF4IcAQEB?=
X-IronPort-AV: E=Sophos;i="5.42,421,1500940800"; d="scan'208";a="654762562"
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; 20 Sep 2017 11:04:54 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8KB4sX4001766; Wed, 20 Sep 2017 11:04:54 GMT
To: "t.petch" , Ladislav Lhotka , Martin Bjorklund 
Cc: netmod@ietf.org
References: <393d3f20-98e3-b4de-e2d7-d627de59ac1f@labn.net> <1505814417.5445.14.camel@nic.cz> <20170919.115915.1668734288988659917.mbj@tail-f.com> <87shfistam.fsf@nic.cz> <031801d331f9$e6b95640$4001a8c0@gateway.2wire.net>
From: Robert Wilton 
Message-ID: <6def5662-2b4f-b7f3-f709-4d133a91b033@cisco.com>
Date: Wed, 20 Sep 2017 12:04:54 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <031801d331f9$e6b95640$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Sep 2017 11:04:59 -0000

On 20/09/2017 11:18, t.petch wrote:
> ----- Original Message -----
> From: "Ladislav Lhotka" 
> Sent: Tuesday, September 19, 2017 2:37 PM
>
>> Martin Bjorklund  writes:
>>
>>> Ladislav Lhotka  wrote:
>>>> Hi,
>>>>
>>>> I support the adoption but I propose two conceptual changes:
>>>>
>>>> 1. Introduce a new module name and namespace so that it is not
>>>> necessary to carry along the deprecated baggage. If readability is
>>>> the primary concern, this is IMO the way to go. Instead of
>>>> "ietf-ip-2", I'd suggest something like "ietf- ip-nmda".
>>>>
>>>> 2. Avoid obsoleting RFC 7277. I believe the old modules may
> continue
>>>> to be used
>>>> in areas where NMDA is an overkill, such as open source home
>>>> routers.
>>> Why wouldn't NMDA be appropriate in an open source home router?
> Note
>>> that the new model really just have a single tree instead of two
>>> trees, so the data that needs to be instrumented is more or less the
>>> same.
>> It is quite likely that some parts of the data models will be
>> implemented only as configuration but not state data. In the "old
> style"
>> modules it is easy to add a deviation for the node(s) under -state but
>> in NMDA style this is not possible because we only have one node.
>>
>> There are subtle differences in the schemas for configuration and
> state
>> data that the NMDA concept doesn't address. If you want another
> example,
>> ietf-routing-2 has the "router-id" leaf that is conditional via the
>> "router-id" feature. If this feature is not supported, router-id
> cannot
>> be explicitly configured (it is assigned by the system) but in state
> data
>> "router-id" needs IMO be present in any case. But the if-feature
>> isn't able to differentiate between configuration and state data if
>> there is only one node for both.
> So add a second node!  I think that the idea that NMDA eliminates all
> duplication of config and state is a myth; there will still be
> duplication where the life cycle of the data diverges, ie it is not
> really duplication! I think too that the twin trees approach, while
> clumsy, was easy to create;
Easy to create, but just as easy to get wrong.  Alas, with the twin 
trees approach, the config and state trees can (and do) diverge. 
Different WGs within IETF were already starting to model the state 
information with different tree structures.  Some WG models includes the 
applied config value, others didn't.  We seemed to be loosing 
consistency between the model.  My opinion is that the end outcome of 
this would effectively require all clients to write custom code to 
correlate equivalent information between the config and its related 
state, which doesn't seem great.

>   the NMDA approach is more subtle, more
> complex, easier to get wrong.
Yes, I agree the NMDA approach is a bit more subtle. And there are 
definitely some concepts that probably should be modeled slightly 
differently:

A case in point might be "interface MTU" that can be automatically 
assigned (the default behaviour) or statically configured.

(1) A pre-NMDA split config/state model might have:
- a config true interfaces/mtu leaf that is either "auto" or a specific 
value,
- a config false interfaces-state/mtu leaf holding the actual 
operational value,
- [potentially also a config false interfaces-state/cfgd-mtu leaf 
indicating the applied config value.]

(2) One way of modelling this in NMDA would be to split whether mtu was 
auto vs manually configured separately from the mtu value.  So this 
could be modeled as:
- one config true leaf that represents with MTU is automatic or manually 
configured.
--one config true leaf that represents the manually configured and 
operational MTU value.  Allow with an appropriate constraint so that 
both leaves are not configured.

(3) Alternatively, in both pre NMDA or post NMDA, the model could assume 
"automatic" as the implicit default MTU behaviour.  In this case you 
only need to have a single leaf in the NMDA model (or 2 leaves in the 
split model).
  - one config true leaf that represents the operational MTU of the 
interface, which may be configured if a specific value is to be enforced.

For MTU, it is the third approach that I prefer.

Another similar example is Ethernet auto-negotiation, where (2) looks 
like the best approach post NMDA with an explicit leaf to control 
whether the auto-negotiation protocol is enabled (rather than attempting 
to merge it with the speed, duplex, and flow-control leaves).  But in 
the end, (2) also has the added benefit that it actually more closely 
marries up to how the auto-negotiation protocol is defined, and what 
functionality is actually allowed.

I think that building up a set of these examples (probably on an FAQ), 
of how particular abstract concepts can be effectively modeled may make 
it a bit easier when folks are trying to figure out the best way of 
modeling something in the post NMDA world.

>
> I recall that in the initial stages of discussion of this issue there
> was a proposal for an object to have potentially eight different
> characteristics so what NMDA gives us at present is limited and will not
> solve all the issues of needing more than one node.
I think that I missed those early discussions.  Perhaps that was a good 
thing :-)

Thanks,
Rob

>
> Tom Petch
>
>
>
>
>
>
>
>
>>> In fact, if we claim that the new architecture is not appropriate
> for
>>> some devices I think we have failed, especially if the conclusion is
>>> that we need to maintain two versions of all modules going forward.
>> I am not asking for this but, on the other hand, if NMDA versions used
> a new
>> module name and namespace (my item #1, which is what ietf-routing-2
>> does), then I don't see any pressing need for obsoleting the old style
>> modules.
>>
>> Lada
>>
>>>
>>> /martin
>>>
>>>
>>>
>>>
>>>
>>>
>>>> NMDA
>>>> implementors should be aware of the new modules but there is no
> need to
>>>> eradicate the old data models.
>>>>
>>>> #2 applies also to other modules for which the NMDA version is
> underway.
>>>> Lada
>>>>
>>>> PS. The subject is wrong, it shoud be -rfc7277bis-
>>>>
>>>> Lou Berger píše v Po 18. 09. 2017 v 10:33 -0400:
>>>>> All,
>>>>>
>>>>> This is start of a two week poll on making
>>>>> draft-bjorklund-netmod-rfc7227bis-00 a working group document.
> Please
>>>>> send email to the list indicating "yes/support" or "no/do not
> support".
>>>>> If indicating no, please state your reservations with the
> document.  If
>>>>> yes, please also feel free to provide comments you'd like to see
>>>>> addressed once the document is a WG document.
>>>>>
>>>>> The poll ends Oct 2.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Lou (and Kent)
>>>>>
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> netmod@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>> --
>>>> Ladislav Lhotka
>>>> Head, CZ.NIC Labs
>>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>> --
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Sep 20 04:29:12 2017
Return-Path: 
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 2112C133049 for ; Wed, 20 Sep 2017 04:29:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.801
X-Spam-Level: 
X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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=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 cxtwwF9RHZqY for ; Wed, 20 Sep 2017 04:29:08 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00097.outbound.protection.outlook.com [40.107.0.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A38113234B for ; Wed, 20 Sep 2017 04:29:08 -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=iieFsfezYk1/wzirD+ZuE9Mt90RTu8V7N4aFsF1E9TY=; b=Pn/rOdM6/XIaT7Iw2m/R/61+Yxc8qWtKk3qKzCM+QOJcc8HJBjgvHBXIltDiuN6PgeDjYKdkAr48LT4hX1eZoJGFOKXoIgzafxxlGCZhZbgEcfAcLck8fLI8aSIc5LF8DUlXx8SLoXUevVK3KKWOfZujF9vR4fLoKQGygWBxLYk=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (109.146.128.123) by DB6PR0701MB2997.eurprd07.prod.outlook.com (2603:10a6:4:73::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Wed, 20 Sep 2017 11:29:05 +0000
Message-ID: <03e701d33203$7022dce0$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: , "Martin Bjorklund" 
Cc: 
References: <20170830.094028.1809893324608957744.mbj@tail-f.com> <15e32791e40.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>  <20170913.132031.1474514593050589478.mbj@tail-f.com>
Date: Wed, 20 Sep 2017 12:27:21 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-15"
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: [109.146.128.123]
X-ClientProxiedBy: AM5P194CA0023.EURP194.PROD.OUTLOOK.COM (2603:10a6:203:8f::33) To DB6PR0701MB2997.eurprd07.prod.outlook.com (2603:10a6:4:73::7)
X-MS-Office365-Filtering-Correlation-Id: 4993f966-3d9a-422d-c47e-08d5001acd9a
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB6PR0701MB2997; 
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2997; 3:n68OG8rM/I8wMFJEJbk8qQH6FqcDyWTmLg72LuOFaaloyLzW9bnjSGHZ6yjQcAbZcv0sCkmG7CVh57Budi+jE9W+ggF8k/WrMSVk8z6X/DO5soKwqh1sQ2+WkCOOkMUQsSapznmIxMl3L3jycztAngRiWe/+QuIzzDV901mWpr7M9NmbLHzrhru4hVyJNLPpMSG92/8P0AVlJMfdiYjGVSUHfrqay3SinOUzz6YJ3NrLeYkLZ2XYnxN+HWXyd2NN; 25:NkUATT5ejKT56sE7TGeJ8OoGdHdKOtk3/HtvRt7BdqU3M/pIusdnZ7OiTTfZ19DmLgEE7Ty4kfbPWyRCcc0adbgVX/J6y83ViNAP91sSqH7Phwb73Kce9+4FNtyY7zL3woI2RJBzGqimJzIGuglXJCo3aE3mg3S8JTDcUF3igFcmJKoA5amtJg7v/yMZ395r7QfD5S+ocx0R2R2Ts4d3K61fSC+LpD16QNLB9YI7cYyIuGg0gHtc5lxWHxosVI3rRpjtKxYQXL+70ir+PjAReFs1EcvXW3rrkSWmauGJTUB9vzZAUAw+UeipNavMuI3R/E4GRsWsT7iStSRBKEzr3A==; 31:DrBY5SUqBIOKt/VocuVJ2GeBsQIKxc0ANQk5N46ZIgzkNw/ZloKcWQNSSTLOsfytgtqCELxdY7aI27YazyZEH1hIxlZ5yvJKClj+1T63y7PAkiNUjFuxtnmzNwdpjpQtahBXfZs12FdwzOtQqd2n5wkoZS2we03vwcNLH2GaGKnsiVmjJE1lJCDNCSEkWKEFzTtdzDuBZ4CYthD77ZzohIVMzTnxQ0fpqx3RyUH9g5g=
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DB6PR0701MB2997:
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2997; 20:CM9Cl+veccqHXv+mM59p78lHWLTeTReP10y161NWpfieug+rrR3MGawCweRlERJYiml7dM2y1tanUJ5zQGSzy4k5AHLaYTmkoOUBeORd0KuJcuLWY8FMRcFp/EaabGVupm0FEnhoXIZrtM2hJh1CZg7Xa1iTztL4keXsNYvd3SFsjRBzMPKynifVQJ8h+O8GyNjT205jvyrTDo37fcGV8v1j/aioLLTVQ2u9Z/W3OnoUJaybyZXkrTopd54P2ENdQ53nj+U5RzhvOU7TWV8dvHxz1l26y4EqKCITCiEWdr9dMRB+g4KgKqJtOb9DI7QieHiV2vvEfU19vHbsbTrSSA==; 4:W8WaY1wEOgS+Zk9V7HiEy6KFv6SCbZqFNW2ak5/lbwF2iO4M2rItOJxOXhGwwzVigVA7FvXg3bxa/iyhgo4UVnoPcA9FMVm42nkFxPQVe0Um+RudlFZrzTz+VYVXGTCI601KAUJyxDF+sp/BW/6YhaHV4DaMZwWjLitdowZ+U1JsjfTc6Y33K36esxWkB/ioj/oTv9caJEZqmcxRsKoiJT/LSpYZyw1+iWxxLy9yQmDyJF1MtCi7QGn8QuW/AJA/ruIotxRjx/TPE02B/O3u39bABE2WQyE+Gnyx82r09ss=
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863);
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(61426038)(61427038)(6041248)(20161123560025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB6PR0701MB2997; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB6PR0701MB2997; 
X-Forefront-PRVS: 04362AC73B
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(189002)(199003)(69234005)(13464003)(377454003)(24454002)(5383002)(110136005)(316002)(97736004)(14496001)(2906002)(68736007)(16526017)(84392002)(8676002)(478600001)(44736005)(305945005)(229853002)(47776003)(6306002)(6666003)(1556002)(4720700003)(9686003)(66066001)(6486002)(116806002)(7736002)(50986999)(81156014)(8936002)(33646002)(6496005)(106356001)(105586002)(23756003)(53546010)(81166006)(76176999)(3846002)(50226002)(6116002)(4326008)(53936002)(81816999)(81686999)(189998001)(62236002)(44716002)(1456003)(93886005)(6246003)(966005)(561944003)(5660300001)(86362001)(101416001)(61296003)(25786009)(2870700001)(50466002)(74416001)(7726001)(17413003); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2997; 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: =?iso-8859-15?Q?1; DB6PR0701MB2997; 23:AxiWl3HNzGLuTe6i+ioCxxsilMMUv7X6xoRY?= =?iso-8859-15?Q?OC5Begd01Noq9K1kPDsAvJfzCscy/nuD8EJMbxYJ9lXMQ1nlk5m1Cdja3?= =?iso-8859-15?Q?dg+Q6LiEQ5Fc+LEmuY8m0Pq2Vvxrqidwm672egQfg6dkz9nOc4YajAAxx?= =?iso-8859-15?Q?ohawN49gN1PKFu6wzfr6dW9kDR5JBuB/zxCSmjTUgElHzCkrHDeYr2J+n?= =?iso-8859-15?Q?YZ7xozluEI4Idn250l2hkRQcm+Z7oOnIJfJ31ZAyHz7iMaJtudMptiY4s?= =?iso-8859-15?Q?o5c3pIvnf3ZdLwizz7WN03k1QAwda0LJ349XN5rDlG8wObQz1uJxD+06m?= =?iso-8859-15?Q?H98VPLxxDWPw/VJ5Y8aCo+IpN5ZXHL4SEn4fya9gMdgxQ4xDOYMd8SX01?= =?iso-8859-15?Q?vq0wpiPBtxmWRZCjDRCPcBeeifCabCCPIgkI8CL+ZK6AyqA35J61qT14Q?= =?iso-8859-15?Q?dqLp4XYZSgm/vjkXfSCmLFVJgqCYSlL9X8kQDbNzfufX3b/Oda90M1aLJ?= =?iso-8859-15?Q?LYxBN6NAEWfLuAouISN6IXm4q84ZLafqqNCFgOkSjl02470BC/yfsCEje?= =?iso-8859-15?Q?0DE1ENZyFNBS0B5jqrBoHGU8e1s0UckJs+8P9MfM6BAbyzbeOkeG8bB7j?= =?iso-8859-15?Q?4eYGM1iAcgcO5vCG3R1BF6vZ7pLpkaE+WAQIxqMwDqcwuvCztobKf1aLp?= =?iso-8859-15?Q?PYONKG2akMDQdkYCfbStqXJRJk+6yhjToEJ393/8qh0r1jUJXd4pF0kW1?= =?iso-8859-15?Q?YgDQsxhblfJyBpz3CnaQGiB695TekT4jo0n2gr3TmE9JD+m9+MwP24TPF?= =?iso-8859-15?Q?rSjhW8GO8JF9wkZw/4BCxC66I+YiH+C6DUDWPSvtz43ZAzWktaDeBj4+3?= =?iso-8859-15?Q?UNy3cq7oUNxUcUlegvjhynZMGCfqDH68tX36gPbB69fQ7o7053NeOOe4z?= =?iso-8859-15?Q?zcF2lrjJxoDBYbTSmjZHWmFpoePwVrxA08WoVZpGle1h984P/MEIXohks?= =?iso-8859-15?Q?Gx/FJcfFyb7SA2BHpMekMayhFPf6e8AFB5p6akdtYFRcjJUNRvwMXzRCd?= =?iso-8859-15?Q?17n7RG7rcs/mlYjARiD5l175ykSQvDkSeHDDgm8SNerngTC6hyEpkqxGz?= =?iso-8859-15?Q?RYXmZBm0IT1JW7whhU65YH3fOS10OpUPygKpIMhn6ATBG+H+rKRoqiMW9?= =?iso-8859-15?Q?Tv2fQrAgma0jikmDOgDbl7fEeaWrzM9qfrzXvczSiXHOyQ8vwn0+ccxbL?= =?iso-8859-15?Q?wzjus7NOw+JPALm/KS53Dg5uO5YUz3uXNdmzVBnX8Vtitsw73jwWprsCD?= =?iso-8859-15?Q?bRxfv6mPWE4dNJgtAisD/cS4qZjZBkBV9QtJ83Ee6v9aAXygTknuXSlcd?= =?iso-8859-15?Q?lYjPRsXPSFFfcHM2DJdG+Y6efM6SljJudPig5+Y5cs2zbVEyZaFKBmVW4?= =?iso-8859-15?Q?xoor1cplEkReaBDp3IKVIG3BHi8VN0H7HNmuxh4hM2BB6t/mNlm8NU5RO?= =?iso-8859-15?Q?vm2VkgSBnjOV/CtpbgGKouF9Ad/uS74bTqUg2MzUMPw3n4SMp4+GTDLcU?= =?iso-8859-15?Q?+7Q6w51N7saJ9raUkFoO3QvNC0MXtis7jZDbDmEo6B+JFsRrYStDjCPKl?= =?iso-8859-15?Q?5qotZveKRqJP62Xv2I5NXWZx45xjQu0kKma9ih6AcomnL0uikKviP5+RB?= =?iso-8859-15?Q?JnzsVYEwO+gJ+go+7DgsSwiAN?=
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2997; 6:FrNM1sITrOtz4uLYMnZjgoMm2C0fJKjOnFVqqIMud84FGbwUVEn+zZycAMKTViE6gXBPerdkkJloplfv7J9D17dSRO3s8ZzbuPqfUqDun6K4MtKdH8kSiQxLO9ieC23uSN5vHkaGWkeH6sSMjDl/KJfRNVsyNg1t6X8utzN2niiXTWgUGayAo+7Zxd9gpYgqYjPRutvRnfG48PIsvz6Ikjb1HuPq63+aT4GAG6J2UJw+S+zXjrtWVtoqWoakkgsCJI7cdmOR2oRkTJWP5iTA1y/prwcRSIrTUwShbD/Dd5ZWoscbgiy4QJ2pUj+7HlyFjCoxI+zPSs2/QbtqcoR2yg==; 5:mVpHG7v+iGQ61qm4aBmjBzHLY0y4elmdayVOU3NSFUb5fxESNYD8bPBAsVQFxhwlppcCIjoYKfmCpomk663RrqudXCcX5fozSUv89p9JocSiz67bkj2qAYwO7u2PzH6U/n+4wDwprxce9V8Nsg4Rsw==; 24:ysa0wssMHVgeRCknotHNXRs9M13JE40RAayiC33sBbJr8mgjJG98gdoGAs8cdfFlqS6KWjp6+2PV8wCbK6Y5gOlE7lmAGIWQ/jT5j3GhFTk=; 7:TzAmcrXdk34fqRUsYSzeg0bHB8BzGO3NxQrMjSpi6IWcue1OSz2BSyvdx2b38dWGW09mK3R8InFNuHzEw40Lg/dk+MoGASQBo2jXH07M2uFeuIey29gwXGQ3bIi9+FA/EnRomFsEtGgEVa589rk0WuIgoRTTJU8oEWUQBJPQMvxWJqlThAto2oRmjOsMpD8QjyZAkVEd0uS/Fs6B0lwlOrj5/ng32t6VlVKhlFaP7/M=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Sep 2017 11:29:05.7665 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2997
Archived-At: 
Subject: Re: [netmod] schema mount open issue #1 terminology
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Sep 2017 11:29:11 -0000

Martin

Since you are doing an update, you might consider updating the
definitions to point to the  NMDA I-D
rather than RFC6241 although configuration data is not defined in
RFC7950 or NMDA.

Tom Petch


----- Original Message -----
From: "Martin Bjorklund" 
To: 
Cc: 
Sent: Wednesday, September 13, 2017 12:20 PM
Subject: Re: [netmod] schema mount open issue #1


Hi,

Lou Berger  wrote:
> Hi,
>
> The LNI/NI authors/RTG Area DT met yesterday and discussed the
proposed
> change as well as the other topics that came up in the subsequent
> discussion. The high order bit is that the proposed and current
> definitions are adequate for our needs. Read further if you care about
> details, including confirming our understanding:
>
> 1) WRT xpath context change proposed by martin
>
> Our understanding is that absolute paths continue to be allowed

Yes, this is correct.

> , for
> example the following remains valid:
>
> "use-schema": [
> {
> "name": "ni-schema",
> "parent-reference": [
> "/*[namespace-uri() = 'urn:ietf:...:ietf-interfaces']"
> ]
> }
> ]
>
> Assuming yes, then we have no objection to the change (as it allows
the
> server implementor to choose how/if they support vrf name filtering.
> Obviously, using the new syntax exposes the restriction to the client
> which is probably desirable.)
>
> 2. parent-reference location is adequate for our needs.
> This said, we think parent-references are more appropriately contained
> within the schema list and having them there will yield less complex
> operational data.
>
> 3. current mount point extension usage definition (must be in a list
or
> container).
> Our use case is covered by always having a single mount point
contained
> in a container. We don't see the need for mount point extensions
within
> lists or for there to ever be siblings of mount point extensions.
>
> We don't see a need to discuss items 2 and 3 further at this time.
> Assuming our understanding is correct, we will update the NI and LNE
> draft as soon as schema mount is updated as proposed.

Ok, since we haven't seen any objections to the proposal, I will
update the schema mount draft accordingly.


/martin


>
> Lou
> (as contributor and NI/LNE draft co-author)
>
>
> On 8/30/2017 5:29 AM, Lou Berger wrote:
> > FYI I've asked folks in the routing area, i.e., the ietf users of
schema
> > mount, if they have an opinion on the node discussion. I will also
do so on
> > the point I raised on parent reference location. (Which is
independent from
> > your format change.) Clearly, if I'm the only one to be raising
objections,
> > I'll be the one in the rough on these points.
> >
> > Thanks,
> >
> > Lou
> > - as contributor
> >
> >
> > On August 30, 2017 3:42:26 AM Martin Bjorklund 
wrote:
> >
> >> Ladislav Lhotka  wrote:
> >>> Lou Berger  writes:
> >>>
> >>>> Lada,
> >>>>
> >>>>
> >>>> On 8/28/2017 10:16 AM, Ladislav Lhotka wrote:
> >>>>> Lou Berger pí¨e v Po 28. 08. 2017 v 09:40 -0400:
> >> [...]
> >>
> >>>>>> PS is your view aligned with martin or our example?
> >>>>> If you mean shifting the XPath context node to the mount point
instance,
> >>> then
> >>>>> yes.
> >> So, going back to the original issue; does anyone have any
objection
> >> to changing the XPath context for parent-reference as describied in
my
> >> original post?
> >>
> >>
> >> /martin
> >>
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Sep 20 04:35:18 2017
Return-Path: 
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 01E0412EC30 for ; Wed, 20 Sep 2017 04:35:16 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWnjbYGLO3Kh for ; Wed, 20 Sep 2017 04:35:09 -0700 (PDT)
Received: from outbound-ss-1812.hostmonster.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) (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 23A6D1321A0 for ; Wed, 20 Sep 2017 04:35:09 -0700 (PDT)
Received: from CMOut01 (cmgw2 [10.0.90.82]) by gproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id 426F3175E5F for ; Wed, 20 Sep 2017 05:35:08 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id Bnb41w00j2SSUrH01nb7ft; Wed, 20 Sep 2017 05:35:08 -0600
X-Authority-Analysis: v=2.2 cv=K4VSJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=2JCJgTwv5E4A:10 a=u07AKapRAAAA:8 a=wU2YTnxGAAAA:8 a=AUd_NHdVAAAA:8 a=L0rEDTKoYN_WA3rYJbkA:9 a=QEXdDO2ut3YA:10 a=SkebfZ6J2Mmvk2rLHZle:22 a=Yz9wTY_ffGCQnEDHKrcv:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:References:Cc:To:Subject:From:Sender:Reply-To: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=5ERSXn6c3gh7q9R+L55dpEn5Ty2u+IIoMjlSaDnGI34=; b=eeHrQkSeYi52KMxcCRd8Htwa23 pjKo8/qlEjO3m2OhTIK9P0Yi6ESY+REyddAqaceLVMBTToZdjP0a2qyYfDtx6F9uT+o4eP8US/4Qy 1SXGGutyGJEwbrJPupVIAD8L/;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:39662 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dudHU-000kxr-67; Wed, 20 Sep 2017 05:35:04 -0600
From: Lou Berger 
To: Martin Bjorklund 
Cc: rwilton@cisco.com, netmod@ietf.org
References: <990b8722-7a48-46ce-3f5d-96bc5cb66075@labn.net> <20170919.154238.1738748131929616921.mbj@tail-f.com>  <20170920.083439.2133568542308133041.mbj@tail-f.com>
Message-ID: <2816f2ca-8e86-aeb6-a8f3-bfad703f6362@labn.net>
Date: Wed, 20 Sep 2017 07:35:01 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170920.083439.2133568542308133041.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dudHU-000kxr-67
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:39662
X-Source-Auth: lberger@labn.net
X-Email-Count: 3
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Sep 2017 11:35:16 -0000

On September 20, 2017 2:33:47 AM Martin Bjorklund  wrote:

> Lou Berger  wrote:
>>
>>
>> On 9/19/2017 9:42 AM, Martin Bjorklund wrote:
>> > Lou Berger  wrote:
>> >>
>> >> On 9/19/2017 7:29 AM, Martin Bjorklund wrote:
>> >>> Lou Berger  wrote:
>> >>>> Martin,
>> >>>>
>> >>>> Speaking as a contributor:
>> >>>>
>> >>>>
>> >>>> On 9/15/2017 7:40 AM, Martin Bjorklund wrote:
>> >>>>> Robert Wilton  wrote:
>> >>>>>> On 15/09/2017 11:21, Ladislav Lhotka wrote:
>> >>>>>>> Andy Bierman píše v Čt 14. 09. 2017 v 08:43 -0700:
>> >>>>>>>> Hi,
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> Actually I liked the early pyang output that was concise and easy to
>> >>>>>>>> remember.
>> >>>>>>>> The current format gets very cluttered and there are too many little
>> >>>>>>>> symbols
>> >>>>>>>> to remember them all.
>> >>>>>>> I agree.
>> >>>>> Me too.  The current draft adds three new magic symbols: "mp" "@" and
>> >>>>> "/".
>> >>>>>
>> >>>>> "mp" is for a mount point, and it can be generated directly from the
>> >>>>> YANG modules.
>> >>>>>
>> >>>>> Directly under a "mp", "/" and "@" are used to indicate that a node 
>> is mounted
>> >>>>> or available through a parent reference, respectively.
>> >>>>>
>> >>>>> I actually question the usability of "/" and "@".
>> >>>> I agree that / and @ are something new, and enabled by schema mount. 
>> >>>> There have been repeated comments in the RTG WG that there needs to be
>> >>>> some way for vendors to convey what they have implemented with Schema
>> >>>> mount
>> >>> If that's the requirement, using the tree diagram is probably not the
>> >>> best way.  The tree diagram is intended to provide an overview of a
>> >>> given (set of) YANG module(s).
>> >>>
>> >>> A perhaps better way to convey the information is to create a file
>> >>> with an instantiated /schema-mounts tree.
>> >> using what syntax?  JSON and XML really isn't that easy for the (human)
>> >> reader to parse.
>> > Either JSON or XML.
>> This is fine for code, less so for humans.  We include both in the NI
>> draft, the tree provides a quick overview, the JSON provides the details. 
>>
>> >
>> >>>> and this is one way to help convey (a) what is expected of server
>> >>>> implementors and (b) what client implementors should expect.
>> >>>>
>> >>>    Hence the
>> >>>> current draft text:
>> >>>>
>> >>>>   In describing the intended use of a module containing a mount point,
>> >>>>    it is helpful to show how the mount point would look with mounted
>> >>>>    modules.
>> >>>>
>> >>>> The whole point of trees is to facilitate understanding for those who
>> >>>> are less familiar with a model than the authors, and IMO that's the
>> >>>> paramount perspective in this discussion.
>> >>> Fully agree!  I would say that we have to make sure that the diagrams
>> >>> can be understood by people less familiar with the technology than the
>> >>> authors.  Mixing schema and instance data does not help here.
>> >> Can you propose an alternative?
>> > As I have written before, I think the "/" is not needed, so I would
>> > remove that.  I would also not list the nodes from "parent-references"
>> > in the same tree ouput.  It is not clear to me that this level of
>> > detail is needed in the tree, and - as noted before - it isn't even
>> > correct to list e.g. "interfaces" when the parent-reference in fact
>> > selects a single interface.
>> >
>> >> The routing WG participants seem to
>> >> find these useful, we can also ask there for broader input if you'd like.
>> > One approach is to add the union of eveything that some people find
>> > useful.  In the end we have to look for WG consensus.  Several people
>> > have said that they prefer a less cluttered format.
>> In the context of listing enums...
>>
>> >
>> >>>>> Since a parent
>> >>>>> reference can be very specific, e.g. one specific interface, it isn't
>> >>>>> really accurate to show:
>> >>>>>
>> >>>>>                   +--mp vrf-root
>> >>>>>                      +--rw rt:routing/
>> >>>>>                      |  ...
>> >>>>>                      +--ro if:interfaces@
>> >>>> This is just a conditional and we have precedent on how to handle
>> >>>> conditional representation.   
>> >>>>
>> >>>>> And the trailing "/" on rt:routing doesn't add any information we
>> >>>>> don't already know.  Since vrf-root is a mount point, it follows that
>> >>>>> its children are mounted.
>> >>>> The issue is a bit more complex when considering some real use cases,
>> >>>> particularity when parent references and augmentations are used.  For
>> >>>> example consider the following *without* the use / or @:
>> >>>>
>> >>>> module: ietf-network-instance
>> >>>>   +--rw network-instances
>> >>>>      +--rw network-instance* [name]
>> >>>>         | ...
>> >>>>         +--rw (root-type)
>> >>>>            +--:(vrf-root)
>> >>>>               +--mp vrf-root
>> >>>>                  +--ro rt:routing-state
>> >>>>                  |  +--ro router-id?                 yang:dotted-quad
>> >>>>                  |  +--ro control-plane-protocols
>> >>>>                  |     +--ro control-plane-protocol* [type name]
>> >>>>                  |        +--ro ospf:ospf
>> >>>>                  |           +--ro instance* [af]
>> >>>>                  +--rw rt:routing
>> >>>>                  |  +--rw router-id?                 yang:dotted-quad
>> >>>>                  |  +--rw control-plane-protocols
>> >>>>                  |     +--rw control-plane-protocol* [type name]
>> >>>>                  |     +--rw ospf:ospf
>> >>>>                  |        +--rw instance* [af]
>> >>>>                  |           +--rw areas
>> >>>>                  |              +--rw area* [area-id]
>> >>>>                  |                 +--rw interfaces
>> >>>>                  |                    +--rw interface* [name]
>> >>>>                  |                       +--rw name if:interface-ref
>> >>>>                  |                       +--rw cost?   uint16
>> >>>>                  +--ro if:interfaces
>> >>>>                  |  ...
>> >>>>                  +--ro if:interfaces-state
>> >>>>                  |  ...
>> >>>>
>> >>>>
>> >>>> It's certainly not too hard to spot the top level mounts, but it is
>> >>>> impossible to distinguish the parent references from the actual mounts. 
>> >>> My proposal would be to not even show the parent references in the
>> >>> diagram.  If we do that, the '/' is not needed.
>> >>>
>> >>>> Further more, some mounts are hard to spot.  For example, notice ospf. 
>> >>>> Did you notice that it's a mount?
>> >>> This is actually not correct.  ospf is *not* a mount; it is an augment.
>> >>>
>> >> it's a mounted module that augments another mounted module.
>> > But why would it have a "/" just b/c it is augmented, when its sibling
>> > 'control-plan-protocol' doesn't have the "/"?  What addition info does
>> > the "/" convey?
>> That it is a (sub)tree that is present due to a mounted module.
>
> So is 'control-plane-protocol', so then it should also have '/',
> right?

Why, it's defined in ietf-routing (under rt:routing-state and rt:routing)?

Lou

>
>
> /martin


From nobody Wed Sep 20 04:46:51 2017
Return-Path: 
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 95E421330B1 for ; Wed, 20 Sep 2017 04:46:50 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9s9TduhPBFgQ for ; Wed, 20 Sep 2017 04:46:49 -0700 (PDT)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 64EB713309C for ; Wed, 20 Sep 2017 04:46:49 -0700 (PDT)
Received: from cmgw4 (unknown [10.0.90.85]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 12C3B1E0C92 for ; Wed, 20 Sep 2017 05:46:48 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id Bnmk1w01M2SSUrH01nmnp5; Wed, 20 Sep 2017 05:46:48 -0600
X-Authority-Analysis: v=2.2 cv=OZLoNlbY c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=2JCJgTwv5E4A:10 a=lI54y5JCEApwcvzhCeQA:9 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: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=0XVbEFIILj/olGVXXYyM+I/VXUSaqiQi3P0bBo7bxSM=; b=vtcoroc8lfpA+0bVPfvLm4dMbt g/ALY81c0hInFIrvkC8fL7+zNlJAqNYBNeez1qCoRYYEmoNDCVNqhpOakC3KIfeihpBu9lLxKwvoi G4pbtxHJWqLPBtrNR3bGEAlrE;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:39886 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dudSm-000mhi-Q3; Wed, 20 Sep 2017 05:46:44 -0600
To: Martin Bjorklund 
Cc: rwilton@cisco.com, netmod@ietf.org
References: <20170919.154728.285206235172744617.mbj@tail-f.com> <4f17fbca-6282-6b27-b390-9b85779e96da@cisco.com>  <20170920.084016.1173553333008898354.mbj@tail-f.com>
From: Lou Berger 
Message-ID: <092315ab-a60e-8af4-bcae-b52b26634782@labn.net>
Date: Wed, 20 Sep 2017 07:46:42 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170920.084016.1173553333008898354.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dudSm-000mhi-Q3
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:39886
X-Source-Auth: lberger@labn.net
X-Email-Count: 7
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Sep 2017 11:46:51 -0000

On 9/20/2017 2:40 AM, Martin Bjorklund wrote:
>>> As for what the precise definition of '/' and '@' should be, I'm not 
>>> sure.  I think that you and Lou have a better handle on that ;-)
> Since Lou and I have different opinions on this, it would be very
> useful to hear what others think.

I completely agree that hearing from the WG makes sense (I can also take
this to the users in the RTG WG and see if there is any input from that
WG). 

Obviously, if there's no consensus for these symbols at this time,
they're dropped!

Thanks ,
Lou
(as contributor)


From nobody Wed Sep 20 05:08:22 2017
Return-Path: 
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 76B001342E1 for ; Wed, 20 Sep 2017 05:08: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 ler4ypSvhrke for ; Wed, 20 Sep 2017 05:08:18 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40123.outbound.protection.outlook.com [40.107.4.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0E92133208 for ; Wed, 20 Sep 2017 05:08:17 -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=Glm/ovvDUNZwqluxBFhvT+0HiyGeUM7sLhYE0FNqQEs=; b=eZxOIAMtgoZ3CsfMX7nkEnZf3fkRSQM+YM/MhYuGkBbMXrF2wVgXja7gQ0kh33hoWTBm6VEwY/VlAzO4gswmiA2brVhxxmXVemtMcDlVgEcMmur8WjWOvUZ08D6mSV6SqwQPwKSHxtfNe2IYStatnfT1PBclejbrkRW5YfCOrQM=
Received: from pc6 (109.146.128.123) by AM5PR0701MB2996.eurprd07.prod.outlook.com (2603:10a6:203:48::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Wed, 20 Sep 2017 12:08:15 +0000
Message-ID: <045f01d33208$e8adae60$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Ladislav Lhotka" , "Martin Bjorklund" , "Robert Wilton" 
Cc: 
References: <393d3f20-98e3-b4de-e2d7-d627de59ac1f@labn.net> <1505814417.5445.14.camel@nic.cz> <20170919.115915.1668734288988659917.mbj@tail-f.com> <87shfistam.fsf@nic.cz> <031801d331f9$e6b95640$4001a8c0@gateway.2wire.net> <6def5662-2b4f-b7f3-f709-4d133a91b033@cisco.com>
Date: Wed, 20 Sep 2017 13:06:30 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
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: [109.146.128.123]
X-ClientProxiedBy: AM5P194CA0017.EURP194.PROD.OUTLOOK.COM (2603:10a6:203:8f::27) To AM5PR0701MB2996.eurprd07.prod.outlook.com (2603:10a6:203:48::18)
X-MS-Office365-Filtering-Correlation-Id: d847999e-9542-40cb-71a9-08d50020462e
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM5PR0701MB2996; 
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2996; 3:PLufzYX47qSTH+zsXGzXrZm0ppG8+2WZYoN6jvhv16NtATXM8MWgBXG43+sRBVddOxRzqldA7RyCWmWxIoZeqvyuYobN2rsIuAruISwYNye0oaRQ/gga4z1v0JwyWTNys7kB7Xa0bMBwHOfVkI/FG2jb9uRBJ3LGz8k2YDtDLi3bbyWgx6R12kp0grUvQpUG+3dMoDYxau7s0jHueQE0RNfjUVnot2/MiKBlsy4jd/fqh5ionFYNuR4rOPpeVDwH; 25:WZ7UBqBrzOOMu9bAKKvFdgRnejuG9rycAcaX4uBM6OtC/m+gxusg6pVnUJN5t09/WzzKOqMAuuBxcQxKUekZQVcP+5ew4C/FaitaaPp/q/NYDpSJtXIS7d2HsVx5ANzFsowBGxIzEBEygdvoGagzzVUpHJUcpobuSVW8EO/T+yapR/y5MH6eOMy7y84dweB3XbVhwmlIrb6Av4TASHTHbhQkZG9hvNU5KYG/DU0lATYmRp09QZXS98AZiGoUZUWPVUvMvUTUXsXJniV1WjesViQwHFI5XBzGUJArMaFj4bnI7SK0K4rDmkgIN1C0K2HUIeU8FIrNSbzAWffFOzceiw==; 31:jtu+eMHv70/wl879rFTqABFk3neN5lIf+bP3dECiC6NIV1eivlYcoCY/HfMSlUowIzzChjGnPAz6dYclF7c5B+pQ2Hd3YYuFrHPA91UIoLVlX8o04VNmF4lNQRoldd3klPzZnr34Fx44mydPQJoQTJ2Th/4i8trGelw8JppBCBy78TxyxXm7NKdBy2L7t0bC0tD3B3XKz/hxuJ+jx0D8AO/AiIuhtKJWhXZyW9YOv3U=
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AM5PR0701MB2996:
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2996; 20:RNqelyc1EWlCIYCKaPm1cvh65+0ZUYZtU/qjN/SKzqJbEcVJXgDbViY3flU9DdmCpmKd+2/7pbIsQ7mwJbBnQMhEtPXCVS106teqKiqopypiM9LfOoNHkHVzE/iqb5FIjXrpeaFKRpJc+LhjTPj95cbHxXEPuwAdOcOjm6TgL94Muf9i7Pew3jdnitz70K3kinmvpS6cx1kWgbR3rxo0D5eUJT8Bp+3vLNu0xMS2TqKlpNOJ2oECUGLMVxWv1ocDrlLxLdZeZ9D05IauooZCzwJDNwwyGSszZaTI/6cGwGibFyRXA+kXr28AZ2tu31useyRYUEfBJfndi7tLoLcNqg==; 4:ugKEdETE7PkFpusQut4gTwjl6rdfzMX8OUqMATKsnJ8TjeFtdcRSl+/stIP6C18bM1bPwm1gwQyuCdjHv3ekdSoySoS+lw5itYgNTxXXbJeAYF1am8NNhmL1RS671y3atN9U5OOpPLRN4DKZvZCC3Y76Uyk+X0zo54HOb+3hUkvnall80AftmgIAiSQCGEbEjNtM1zlSusEO4YSWREypUmCq/0ZHYg1IXhwVrAtfqFZXYVYPR7nyhibnYR70EXtAlpjApC38Zl3aJwvXEbXE2I4CKcHbmQ+ZT9JoIRgPDyU=
X-Exchange-Antispam-Report-Test: UriScan:(95692535739014);
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2996; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2996; 
X-Forefront-PRVS: 04362AC73B
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(189002)(24454002)(377454003)(13464003)(199003)(51444003)(53546010)(105586002)(2906002)(305945005)(106356001)(8676002)(1556002)(84392002)(86362001)(50226002)(81156014)(81166006)(16526017)(8936002)(316002)(478600001)(61296003)(14496001)(93886005)(116806002)(97736004)(110136005)(230783001)(7736002)(1456003)(33646002)(4326008)(81686999)(81816999)(76176999)(50986999)(50466002)(6666003)(561944003)(4720700003)(229853002)(101416001)(68736007)(9686003)(53936002)(6486002)(44736005)(6116002)(6246003)(3846002)(66066001)(230700001)(44716002)(25786009)(62236002)(5660300001)(189998001)(6496005)(23676002)(47776003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2996; 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?MTtBTTVQUjA3MDFNQjI5OTY7MjM6MlBRdFM2U1dSZ0c3SkhTeXp1N09FaHEx?= =?utf-8?B?UndQOEhvM1FHYmRHUFhzMVFZZWh6aEY2cVpTN0dHMUJJQVpna0pUbTB0L1Rp?= =?utf-8?B?RVgraVhFdkx5ZXBpZjVMb0pySGpWZmpnMXJOaWg0Yll2SVRZanh2ZStCNGlj?= =?utf-8?B?NFl4UHBqUnN4Z3JPcThPQzhIZkVaalNYTWNVZ1NuL3lXdmcvMFlZTnFtTlNM?= =?utf-8?B?VW4ydytnOWNEWm5GZUJuTElSYjJkYm1naHp5a21YcTg2R0FTM3doSjV4bnFP?= =?utf-8?B?Yjk1ZUJ5SWRGS0NpRU9OMlZMQUcybkY1bThaSzk4UWdsS1hHbDlWNHJPM3VS?= =?utf-8?B?TUN3TTRVTjd4dmlDTE9iQUFUdjl3RktvWnU4dVBuWnpMY21pMFVzWmZwUjls?= =?utf-8?B?WlU5WW03QVNpbGI2eTVpamNiK2E2OUwzT3FZeDhBQ2hrVW1BTXBIL25nNUE1?= =?utf-8?B?SlU1U3YvWjZuVTZsUmxCZnFTNzFWUFlndTM3OG1zKzROYWJiMVpsMC9zNlpa?= =?utf-8?B?U3VMNkxjaEd1ODJ1d2MwbHhPY0ZJUlpmeXppZ2tLK1R6MmkvbFh6QlpnLzVt?= =?utf-8?B?bjM5Y1U5a2l5QjQwVk9ZYUVUNUtiNjdoWWdyakVmL3U2aGthZHFvelpNc3Y0?= =?utf-8?B?b0g1bllwUzQ4NUtWRTBSK1ozOHVUQjZLVDdRNXRmY3BPUlkvZjR4M0hDRytC?= =?utf-8?B?a1drOUJMVWdHdlY5WkQvVUVnRzVDRVJQeDRKWlRQUTNDYUpzZnZ1QTVyMmxE?= =?utf-8?B?SDJUZEZuSjQxWm4zekQwVjZFeTBadnN5TUFBRE9MQmRtN0hOSTROdnVOS1lT?= =?utf-8?B?Yk0rU1RWVXh1dnJxSEtEWDUzOStKYXcwNllZbEVmWUFZcWpNaUFqU0pYRjZL?= =?utf-8?B?aVBzQldyNE50b2pWU2kzdUhUZVlzb1ZacVdGZHBMSW9ZOGY2U0hscmZmQ2da?= =?utf-8?B?RTF4RVhSTUc5Wks0cGo4Q1ZwdzBHWHh3ZXpsMnk4ekJGVTF3TDE1TG1hUkJ2?= =?utf-8?B?eEdKK1c3Z0FHcVVTMDQvRkpwbEEybGJqQUhwbjBueEM2dUQ3L0k2MTZndWhq?= =?utf-8?B?a1F1K0NTeGZPYk1ZN1NZK041cEtJZlgwdE1pa3kvQnZKS2dQdU42bUJadEZa?= =?utf-8?B?SnJ4YVhVNjluY0hubUtOYTU1dHR0VURUN1JiSnF2aFh6RFhTU0RIWnp5MEtC?= =?utf-8?B?ZXpHbFlSTWpkMG9RYytnbVI1L2ZhZ2tneEQxdHJpa1dXbyt6M2hFelYwZEla?= =?utf-8?B?M2pEbjFwT3lPbXprc0MxZHQ4cmpQbWVDMHpEZDZrNE1va1dpUWdKV0haN1cz?= =?utf-8?B?dkcxQmtNNU1CVWJpaStkaW94TmxGUWZyYUo4REtRSm5tTnV4VXBYek9BWkZS?= =?utf-8?B?VDdzK0pJY1NFcmVTYTlzRlcyTVJOWDRESEs5UUV6NWFZMlRtc1ZKRHdKampx?= =?utf-8?B?QnNLMENrNjBIdmhISkdsa3Nnb1VpVDJ2N0lHSXZFZW4zMmJEVER3NmdlNTkr?= =?utf-8?B?TGh3WTFXdnZoemVCRk5BQXREVkZUcFFVOXhTWGZUUTZCQVlraWZBM0JxZVl1?= =?utf-8?B?anlOTGxPblV5bUM1c2tGRFRYQ0V5VTEvNUNLdis4THNQdC94NFR1bDdCVmJG?= =?utf-8?B?aldKUXRjY1ZXTHpJcmxZb3p3SlE3TnBKd3ptMUlCVVlKMzFBMVZ2Zk5jTVdE?= =?utf-8?B?TkZucktNTlhzTWs4SzlKczRJSFRQNVREaXR4eDlJQUEvZUJpb3p0THo3eGJo?= =?utf-8?B?Wmxwa3Qzc2o2M0VIOFc3T1E4eDRxWXVjWTFpTXFURC9xNUl3aElLSFV3UGFz?= =?utf-8?B?R09nV2RHeTgwSUtUNEwvbHZrcXluenVyWm5ldm5YMmljdnV6c0toQzRRekkv?= =?utf-8?B?aUwveXFvcW5oTjZNcEJtU2pIR0xveHc5UjJvaGRhL0NtUXJNQk5NVDlpcTAv?= =?utf-8?B?UDltSFhwR1l2NEEzaUxUZnpNMno0eFZjb1kzSUowSGt3ZGZ2MXdSUVdpaVI1?= =?utf-8?B?dk5zYjdFZ2ppRE9vNSt1cWFhbGt3KzBUYzZXeHh2SytXeng4VFVrMGZXVW5z?= =?utf-8?Q?M+Gi6z5xs8OFkYzmr3DDah7x7c0?=
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2996; 6:ftHFL+g0KTz798bKPNd7RpAiG6r415rIpa+V+VZHkGGL50YYsgGy9J1Mp56FjSI6oHx6R05MV5DDcoqR8kavANZhoQ1bgNNl0XYXEZaUOtkc2t5mEvAM3diXSkw2qNO3IL6dotc/bKDoxlFp7t6kDjBUeSUEe3Qpg6/mp+fWwYhM8s8FkXtRAjwVngpoXamjafYJk3sC2e3sztuKFLt0Bp5EYin05tavxT/A3+zKqQxwKIlTSQZIz3else0eYjJ3SKiGtgljQ3bIX9cU3xlirhetWUuVpGbq6eEo8JheCa7V1G2bxjiMCPeF7ELft0b6xtcGXAeRReITnlwX3p5Oxg==; 5:Y5Hrp+bGTfIB4Pc8HRTT0dYQoWxw79GYJ5qQ7ePQyGmT2WtnlK89ZlNh92tjPbtakFvkfaTfBMYCHXjlqP5f+GHkI4y+AeMXSEnfcUEQBtSUtZCVZcZ1tyfI8/wb14LNdtIvSIkxFOP4lGJ9ritHQw==; 24:XO3T3KacOxEbzzC0nnZ8tAzpFmBh8U+u0wTO/b/8yF0NH5Ynzwb1jjLtVEDd/mN1lMq5mTxNTYggLbUoK/IMmAQRTAZcZyn9zIp7XWOvAqo=; 7:2zXsq+3IusjzcXsEGn4vn/ejDsaGqxtHgDfKw1afjSOIs8cmxAIoKpEVB6ambKI1eVbtA4Hv3PBIMYG+f+9uvtEwW7eBAGUSuflpN4RK8H3gqp1cyGXaqAS+evIWEI6nwi4jaPD9KCUWzDL05BrptV0m4FHIwA3JVXD3GA1qGyI3dZjdRWyhJqlMbANl2TuY5mfOU2zF9NJHygvIxJy5HHvfALeD7dalnIZ2xFZfTSQ=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Sep 2017 12:08:15.5758 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2996
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Sep 2017 12:08:20 -0000

----- Original Message -----
From: "Robert Wilton" 
Sent: Wednesday, September 20, 2017 12:04 PM

> On 20/09/2017 11:18, t.petch wrote:
> > ----- Original Message -----
> > From: "Ladislav Lhotka" 
> > Sent: Tuesday, September 19, 2017 2:37 PM
> >
> >> Martin Bjorklund  writes:
> >>
> >>> Ladislav Lhotka  wrote:
> >>>>
> >>>> I support the adoption but I propose two conceptual changes:
> >>>>
> >>>> 1. Introduce a new module name and namespace so that it is not
> >>>> necessary to carry along the deprecated baggage. If readability
is
> >>>> the primary concern, this is IMO the way to go. Instead of
> >>>> "ietf-ip-2", I'd suggest something like "ietf- ip-nmda".
> >>>>
> >>>> 2. Avoid obsoleting RFC 7277. I believe the old modules may
> > continue
> >>>> to be used
> >>>> in areas where NMDA is an overkill, such as open source home
> >>>> routers.
> >>> Why wouldn't NMDA be appropriate in an open source home router?
> > Note
> >>> that the new model really just have a single tree instead of two
> >>> trees, so the data that needs to be instrumented is more or less
the
> >>> same.
> >> It is quite likely that some parts of the data models will be
> >> implemented only as configuration but not state data. In the "old
> > style"
> >> modules it is easy to add a deviation for the node(s) under -state
but
> >> in NMDA style this is not possible because we only have one node.
> >>
> >> There are subtle differences in the schemas for configuration and
> > state
> >> data that the NMDA concept doesn't address. If you want another
> > example,
> >> ietf-routing-2 has the "router-id" leaf that is conditional via the
> >> "router-id" feature. If this feature is not supported, router-id
> > cannot
> >> be explicitly configured (it is assigned by the system) but in
state
> > data
> >> "router-id" needs IMO be present in any case. But the if-feature
> >> isn't able to differentiate between configuration and state data if
> >> there is only one node for both.
> > So add a second node!  I think that the idea that NMDA eliminates
all
> > duplication of config and state is a myth; there will still be
> > duplication where the life cycle of the data diverges, ie it is not
> > really duplication! I think too that the twin trees approach, while
> > clumsy, was easy to create;
> Easy to create, but just as easy to get wrong. Alas, with the twin
> trees approach, the config and state trees can (and do) diverge.
> Different WGs within IETF were already starting to model the state
> information with different tree structures. Some WG models includes
the
> applied config value, others didn't. We seemed to be loosing
> consistency between the model. My opinion is that the end outcome of
> this would effectively require all clients to write custom code to
> correlate equivalent information between the config and its related
> state, which doesn't seem great.
>
> >   the NMDA approach is more subtle, more
> > complex, easier to get wrong.
> Yes, I agree the NMDA approach is a bit more subtle. And there are
> definitely some concepts that probably should be modeled slightly
> differently:
>
> A case in point might be "interface MTU" that can be automatically
> assigned (the default behaviour) or statically configured.
>
> (1) A pre-NMDA split config/state model might have:
> - a config true interfaces/mtu leaf that is either "auto" or a
specific
> value,
> - a config false interfaces-state/mtu leaf holding the actual
> operational value,
> - [potentially also a config false interfaces-state/cfgd-mtu leaf
> indicating the applied config value.]
>
> (2) One way of modelling this in NMDA would be to split whether mtu
was
> auto vs manually configured separately from the mtu value. So this
> could be modeled as:
> - one config true leaf that represents with MTU is automatic or
manually
> configured.
> --one config true leaf that represents the manually configured and
> operational MTU value. Allow with an appropriate constraint so that
> both leaves are not configured.
>
> (3) Alternatively, in both pre NMDA or post NMDA, the model could
assume
> "automatic" as the implicit default MTU behaviour. In this case you
> only need to have a single leaf in the NMDA model (or 2 leaves in the
> split model).
>   - one config true leaf that represents the operational MTU of the
> interface, which may be configured if a specific value is to be
enforced.
>
> For MTU, it is the third approach that I prefer.
>
> Another similar example is Ethernet auto-negotiation, where (2) looks
> like the best approach post NMDA with an explicit leaf to control
> whether the auto-negotiation protocol is enabled (rather than
attempting
> to merge it with the speed, duplex, and flow-control leaves). But in
> the end, (2) also has the added benefit that it actually more closely
> marries up to how the auto-negotiation protocol is defined, and what
> functionality is actually allowed.
>
> I think that building up a set of these examples (probably on an FAQ),
> of how particular abstract concepts can be effectively modeled may
make
> it a bit easier when folks are trying to figure out the best way of
> modeling something in the post NMDA world.

Yes, although I would make it an RFC,  guidelines on how to use NMDA.

The examples you give above are spot on, and we have had many such over
the past few years.

Tom Petch

> > I recall that in the initial stages of discussion of this issue
there
> > was a proposal for an object to have potentially eight different
> > characteristics so what NMDA gives us at present is limited and will
not
> > solve all the issues of needing more than one node.
> I think that I missed those early discussions. Perhaps that was a good
> thing :-)
>
> Thanks,
> Rob
>
> >
> > Tom Petch
> >
> >>> In fact, if we claim that the new architecture is not appropriate
> > for
> >>> some devices I think we have failed, especially if the conclusion
is
> >>> that we need to maintain two versions of all modules going
forward.
> >> I am not asking for this but, on the other hand, if NMDA versions
used
> > a new
> >> module name and namespace (my item #1, which is what ietf-routing-2
> >> does), then I don't see any pressing need for obsoleting the old
style
> >> modules.
> >>
> >> Lada
> >>
> >>> /martin




From nobody Wed Sep 20 06:28:05 2017
Return-Path: 
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 9884F1332D5 for ; Wed, 20 Sep 2017 06:28:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 4HPIeh3HSXGw for ; Wed, 20 Sep 2017 06:28:02 -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 B113213214D for ; Wed, 20 Sep 2017 06:28:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=853; q=dns/txt; s=iport; t=1505914081; x=1507123681; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=tR+4+0TZVnWsrI8jMSa8ddOY79bBZROQ0f22J4y0s3c=; b=RQH1wVSh28twt6m51pkVnZTDjqcksqNzexe8u5/ieQ0Lqy/njD+4hMMi Ngk5ZGi9oIvw7D1pblsfsqLiEkLbIch7iRCyw4LMEhiu6unB36o6NxcyU DiGPOFunAbZ2Dt7j1wbRWWAZwCE/ePkXHbn8/9ppRHdizzAE6+0znNGjv g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgCda8JZ/xbLJq1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBhD5uhByLFJBKmGMKH4pFFAECAQEBAQEBAWsdC4VCDwEFM0MCJgJDHA0?= =?us-ascii?q?IAQEQih8QqA2CJ4scAQEBBwEBAQEBAQEcBYEOgh2DU4FkK4sLgmAFoQ+HXYx6g?= =?us-ascii?q?hOJRIckigGDYIdXgTk2IUFMMiEIHBWHZj+JTgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.42,421,1500940800"; d="scan'208";a="654765534"
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; 20 Sep 2017 13:27:59 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8KDRxnh025007 for ; Wed, 20 Sep 2017 13:27:59 GMT
To: "netmod@ietf.org" 
From: Robert Wilton 
Message-ID: <7a2c2ef4-f572-44a1-f1cd-74febdaa15ca@cisco.com>
Date: Wed, 20 Sep 2017 14:27:59 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: [netmod] NMDA FAQ
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Sep 2017 13:28:04 -0000

Hi,

The NMDA authors have put together a NMDA related FAQ that is available at:

https://github.com/netmod-wg/FAQ/wiki

The hope is that this can be a community maintained and updated FAQ 
relating to NMDA in particular and YANG in general, with the desire that 
it represents the best current practice knowledge from all of the people 
who contribute their knowledge and expertise to the NETMOD WG alias.

At the moment, it is using github wiki pages, but we are considering 
changing it to use a regular Github repository.  The hope is that we can 
make it relatively easy to update whilst maintaining sensible change 
control.  If the current approach gets a positive reception then we will 
try and incorporate the relevant questions from the existing YANG FAQ to 
this location as well.

[Nice] feedback is welcome ;-)

Rob


From nobody Wed Sep 20 08:48:46 2017
Return-Path: 
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 A6ED21330B3; Wed, 20 Sep 2017 08:48:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 l_Bj0ifYLpWJ; Wed, 20 Sep 2017 08:48:43 -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 4B27F1321A0; Wed, 20 Sep 2017 08:48:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1611; q=dns/txt; s=iport; t=1505922522; x=1507132122; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=+ZOhaRzWivUI3uC6LDoagELyvyTFPb3B1nZpTRfesJs=; b=CtCaeARRdG6QuyTU0QQtqlpTuE46q1oqyb4HugLEprvdD7pONt2pMtcC 4ssB2Y4mFFJ52Qejz1T56ygPDsFf+NXpFwGZJmgTxbu4L1GSFIalQfzNS 6KYsyoBKe60SQn8WKy7uEpagXVPeFUVAatuMMA9f3r64YdEqX+9D6b2hz k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CnAwCojMJZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD5uhByLFI5RAYF5CSJxl0gKI4UYAoUoFAECAQEBAQEBAWsohRk?= =?us-ascii?q?BBSMPAQU2CxALDgoCAiYCAlcGAQwIAQGKLxCoAIInix0BAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBARkFgQ6CHYNTgg8LgnKCQYVNgmAFoROHXYx6ghOFaoNahySNY4dXgTk?= =?us-ascii?q?2IYENMiEIHBVJhx0/iVgBAQE?=
X-IronPort-AV: E=Sophos;i="5.42,421,1500940800"; d="scan'208";a="657612094"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Sep 2017 15:48:40 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8KFmemG022792; Wed, 20 Sep 2017 15:48:40 GMT
To: Lou Berger , netmod WG 
Cc: "netmod-chairs@ietf.org" , draft-ietf-netmod-revised-datastores@ietf.org
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> 
From: Robert Wilton 
Message-ID: <39f7d9aa-3554-3498-1075-b8e7e2688f0b@cisco.com>
Date: Wed, 20 Sep 2017 16:48:39 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Sep 2017 15:48:45 -0000

Hi Lou,

We are using github to track the issues: 
https://github.com/netmod-wg/datastore-dt/issues

We think that all issues have been entered.  The authors have discussed 
them today and will send proposed resolutions to the alias.

Thanks,
Rob


On 18/09/2017 14:33, Lou Berger wrote:
> All,
>
>      The LC is closed.  There are clearly some issues to discuss and
> resolve before this document can be submitted for publications.  Given
> the issues raised, as well as the good on-list discussion, I'd like to
> ask the authors to formally track all issues raised and their resolutions.
>
> We have two different issue tracking tools available at the moment: the
> WG trac instance [1], or the github document repo [2]. The authors are
> free to choose their preferred method, and should let the WG know once
> the issues have been entered as well as once an issue is addressed with
> through discussion and, as needed, draft text change.
>
> Thank you,
>
> Lou
>
> (as Shepherd)
>
> [1] https://trac.ietf.org/trac/netmod/
> [2] https://github.com/netmod-wg/datastore-dt
>
> On 9/1/2017 5:02 PM, Lou Berger wrote:
>> All,
>>
>> This starts a two week working group last call on
>> draft-ietf-netmod-revised-datastores-04.
>>
>> The working group last call ends on September 17.
>> Please send your comments to the netmod mailing list.
>>
>> Positive comments, e.g., "I've reviewed this document and
>> believe it is ready for publication", are welcome!
>> This is useful and important, even from authors.
>>
>> Thank you,
>> Netmod Chairs
>>
> .
>


From nobody Wed Sep 20 08:58:00 2017
Return-Path: 
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 1DA7E13422F for ; Wed, 20 Sep 2017 08:57:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 zce24jwuy-lI for ; Wed, 20 Sep 2017 08:57:57 -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 3011413422D for ; Wed, 20 Sep 2017 08:57:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1369; q=dns/txt; s=iport; t=1505923077; x=1507132677; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=fl2dvEjwIvbVJKSYI9sqEizSMucbGo93a0nW4Q59B0M=; b=Sd7hwORVZyUSWJHEehvXQtVA1lp9N1CyXS1OkL+vfSz4V4qurxd4ByTi dQFnwx5V3NmnWqsATpaBXjWktD4HKGNsHlVgSwcp/3QIfFhwoZ7xUMtCQ vMnEVbLM00RfZoWVDHtXnkbRjGPlWqe1BByQtjQcbpXaWX8OCZLD+l8pj M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B8AQD2jsJZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD5uhByLFJBLK5Y1ggQKI4UYAoUnFQECAQEBAQEBAWsohRkBBSM?= =?us-ascii?q?PAQVBEAsYAgIRFQICVwYBDAgBAYovEKgFgieLHQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBGQWBDoIdg1OBZCuCfYQ2gQSCVIJgBaETh12MeoIThWqDWockjWOHV4E5NSK?= =?us-ascii?q?BDTIhCBwVh2Y/hxgrghUBAQE?=
X-IronPort-AV: E=Sophos;i="5.42,421,1500940800"; d="scan'208";a="657612273"
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; 20 Sep 2017 15:57:55 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8KFvs5Q013706; Wed, 20 Sep 2017 15:57:55 GMT
To: Balazs Lengyel , netmod@ietf.org
References: <9ec6b2e4-36a7-87e6-59fa-828855235835@ericsson.com> <20170914.163239.143365521945928900.mbj@tail-f.com> <0605fab0-f879-e02d-4858-52a247571cb8@ericsson.com>
From: Robert Wilton 
Message-ID: <38bf1069-c21e-c160-c5e9-9d70dd9d990f@cisco.com>
Date: Wed, 20 Sep 2017 16:57:54 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <0605fab0-f879-e02d-4858-52a247571cb8@ericsson.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Comments on NMDA-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Sep 2017 15:57:59 -0000

Hi Balazs,


On 14/09/2017 16:44, Balazs Lengyel wrote:
> See below !
>
>
> On 2017-09-14 16:32, Martin Bjorklund wrote:
>
>>> CH 4.4.)  "Validation is performed on the contents of ."
>>> This to me means that default data is not considered at validation
>> Note that RFC 7950, section 6.4.1, says:
>>
>>     In the accessible tree, all leafs and leaf-lists with default values
>>     in use exist (see Sections 7.6.1 and 7.7.2).
>>
>> So defaults are taken into account when intended is validated.
> BALAZS: Yes the two seem to contradict each other. This can be 
> understood in your way, however the current text is not clear enough. 
> I would add:
> Validation is performed on the contents of  (EXTENDED WITH 
> DEFAULT CONFIGURATION).

I've slightly reworked the text on intended.  It was sent to the alias 
yesterday on the thread  vs . The new text on 
intended states " must always be a 'valid configuration data 
tree' as defined in Section 8.1 of [RFC7950]. "

This implicitly means that it must consider default values, just like 
validation in any other configuration datastore is required to do.

Please can you check the proposed text on intended to see if it 
sufficient to resolve this issue. 
https://github.com/netmod-wg/datastore-dt/issues/9

Thanks,
Rob


From nobody Wed Sep 20 10:52:47 2017
Return-Path: 
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 B652B13421B for ; Wed, 20 Sep 2017 10:52:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level: 
X-Spam-Status: No, score=-4.701 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=-2.8, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Exo_xgcZpWD2 for ; Wed, 20 Sep 2017 10:52:45 -0700 (PDT)
Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) (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 5E468132924 for ; Wed, 20 Sep 2017 10:52:45 -0700 (PDT)
Received: from cmgw3 (unknown [10.0.90.84]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id 027B3216257 for ; Wed, 20 Sep 2017 11:51:54 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with  id Btrq1w00D2SSUrH01trtQJ; Wed, 20 Sep 2017 11:51:53 -0600
X-Authority-Analysis: v=2.2 cv=K/VSJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=2JCJgTwv5E4A:10 a=AUd_NHdVAAAA:8 a=NEAV23lmAAAA:8 a=48vgC7mUAAAA:8 a=EuFEwqUUAO6VqI4UoUsA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From:Sender:Reply-To: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=WqB1eJUopHPeSa0XFSUDt9HgTD+NcJpmTY5Wr79GQA0=; b=PkSkhQ0/WQkVBUCBu2LBObEkTG RuWW2uSSwpb8RBG8bglZ9B2n4jCulEH2mTCt7AEbm2qDcOyaVy7hSaf9tsNevXUbK1AY8H7Hidg8v qKABU4IWv+vn4/DwpDExt4+cK;
Received: from [172.58.184.63] (port=40833 helo=[IPV6:2607:fb90:6455:d15:0:47:1e6b:1e01]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dujA5-001uan-Tk; Wed, 20 Sep 2017 11:51:50 -0600
From: Lou Berger 
To: Robert Wilton , netmod WG 
CC: , 
Date: Wed, 20 Sep 2017 13:51:47 -0400
Message-ID: <15ea06ac750.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <39f7d9aa-3554-3498-1075-b8e7e2688f0b@cisco.com>
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net>  <39f7d9aa-3554-3498-1075-b8e7e2688f0b@cisco.com>
User-Agent: AquaMail/1.11.0-568 (build: 101100004)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 172.58.184.63
X-Exim-ID: 1dujA5-001uan-Tk
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: ([IPV6:2607:fb90:6455:d15:0:47:1e6b:1e01]) [172.58.184.63]:40833
X-Source-Auth: lberger@labn.net
X-Email-Count: 12
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Sep 2017 17:52:47 -0000

Sounds great. Thank you for the update.

Lou


On September 20, 2017 11:49:18 AM Robert Wilton  wrote:

> Hi Lou,
>
> We are using github to track the issues:
> https://github.com/netmod-wg/datastore-dt/issues
>
> We think that all issues have been entered.  The authors have discussed
> them today and will send proposed resolutions to the alias.
>
> Thanks,
> Rob
>
>
> On 18/09/2017 14:33, Lou Berger wrote:
>> All,
>>
>>      The LC is closed.  There are clearly some issues to discuss and
>> resolve before this document can be submitted for publications.  Given
>> the issues raised, as well as the good on-list discussion, I'd like to
>> ask the authors to formally track all issues raised and their resolutions.
>>
>> We have two different issue tracking tools available at the moment: the
>> WG trac instance [1], or the github document repo [2]. The authors are
>> free to choose their preferred method, and should let the WG know once
>> the issues have been entered as well as once an issue is addressed with
>> through discussion and, as needed, draft text change.
>>
>> Thank you,
>>
>> Lou
>>
>> (as Shepherd)
>>
>> [1] https://trac.ietf.org/trac/netmod/
>> [2] https://github.com/netmod-wg/datastore-dt
>>
>> On 9/1/2017 5:02 PM, Lou Berger wrote:
>>> All,
>>>
>>> This starts a two week working group last call on
>>> draft-ietf-netmod-revised-datastores-04.
>>>
>>> The working group last call ends on September 17.
>>> Please send your comments to the netmod mailing list.
>>>
>>> Positive comments, e.g., "I've reviewed this document and
>>> believe it is ready for publication", are welcome!
>>> This is useful and important, even from authors.
>>>
>>> Thank you,
>>> Netmod Chairs
>>>
>> .
>>
>
>



From nobody Wed Sep 20 16:54:30 2017
Return-Path: 
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 3B30E1321BB; Wed, 20 Sep 2017 16:54:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 QbcX7g9xic98; Wed, 20 Sep 2017 16:54:26 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAD7113209C; Wed, 20 Sep 2017 16:54:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16459; q=dns/txt; s=iport; t=1505951666; x=1507161266; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=kwtaT50gpILQ5XRCE+w6LVbZ5W8NeKKg2oS3i1e3KDo=; b=LDgJ2M4FxAeaQll2/01pARsh5YNRUxyFps7D7d+F0AqWdtws66AVT8tT jrJsEOJEVhyLa/BS7Zk1EEg0Uw2OE0UyeV923Wl9rlQEW04ipSWOopnH8 QZHFtvukGKEj0J7dMjXpqLe11rq2x9bEZonKLSzDmktLWUM+PCw3Nj6kr A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AMAgBa/sJZ/5BdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9rZG4ng3WaF4FJK5BphT4OggQKGAEMhEdPAoRlQRYBAgEBAQE?= =?us-ascii?q?BAQFrKIUYAQEBAQMBASEKPgMLDAQLEQQBASgDAgInHwkIBgEMBgIBAYovEKctg?= =?us-ascii?q?icnilcBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgyuCAoFRgWQrgn2DKYEaboJdgmA?= =?us-ascii?q?FkkaGAYhMh12MeoITW4UPg1qFWoFKigODYIdXgTkmDSSBDTIhCBwVSYc8IDYBh?= =?us-ascii?q?mErghUBAQE?=
X-IronPort-AV: E=Sophos;i="5.42,422,1500940800";  d="scan'208,217";a="295839089"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Sep 2017 23:54:25 +0000
Received: from [10.155.68.132] (dhcp-10-155-68-132.cisco.com [10.155.68.132]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v8KNsPp4019583; Wed, 20 Sep 2017 23:54:25 GMT
To: Jiangyuanlong , "netmod@ietf.org" , Mehmet 
Cc: "tictoc@ietf.org" , Henrik Levkowetz 
References: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5A2CBD@dggeml507-mbx.china.huawei.com> <331b6b30-8089-5411-9a33-88014b7d66c9@cisco.com> <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5BA686@dggeml507-mbx.china.huawei.com>
From: Benoit Claise 
Message-ID: 
Date: Wed, 20 Sep 2017 16:54:25 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5BA686@dggeml507-mbx.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------B6A96880AD86E0731D0471DF"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] FW: WGLC for draft-ietf-tictoc-1588v2-yang
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Sep 2017 23:54:29 -0000

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

Dear Yuanlong,

The pyang bug has been fixed (thanks Martin).
I updated my toolchain with the latest pyang version (and the latest 
yanglint 0.13.49, btw).
So no more errors at http://www.claise.be/IETFYANGPageCompilation.html 
for your draft.

For the IETF tracker, I guess we have to wait until the next pyang 
version (1.7.4) for Henrik to update pyang.

yangcatalog.org still needs to be updated with the latest validators.

Regards, Benoit
>
> Dear Benoit,
>
> Thank you much for the instruction and the explanation.
>
> There are errors shown in 
> https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588v2-yang/?include_text=1, 
> but it passes validation by 
> http://www.yangvalidator.com/draft-validator. It seems different 
> versions of pyang were used and the results provided by our official 
> site are inconsistent now.
>
> Best regards,
>
> Yuanlong
>
> *From:*Benoit Claise [mailto:bclaise@cisco.com]
> *Sent:* Friday, September 15, 2017 8:48 PM
> *To:* Jiangyuanlong; netmod@ietf.org; Mehmet
> *Cc:* tictoc@ietf.org
> *Subject:* Re: [netmod] FW: WGLC for draft-ietf-tictoc-1588v2-yang
>
> Hi Yuanong,
>
> There is pyang error.
> http://www.claise.be/IETFYANGPageCompilation.html
>
> ietf-ptp-dataset@2017-04-20.yang:294 
> : error: the value 
> "0xFFFF" does not match its base type - not an integer
>
> However, this is a pyang problem. See 
> https://github.com/mbj4668/pyang/issues/329 
> 
>
> Mehmet, can you please a YANG doctor. The YANG doctor review is 
> normally done during IETF LC, but nothing prevents an early review.
>
> Regards, Benoit
>
>     Hi netmoders,
>
>     This draft does not tackle the general YANG problem, but provide a
>     generic time synchronization module of 1588.
>
>     Some of you may have interests in time synchronization, some
>     definitely not. But as experts in YANG, could you please have a
>     review of this YANG module and give an expert opinion?
>
>     Thanks,
>
>     Yuanlong
>
>     -----Original Message-----
>
>     From: TICTOC [mailto:tictoc-bounces@ietf.org] On Behalf Of Karen
>     O'Donoghue
>
>     Sent: Thursday, September 14, 2017 3:16 AM
>
>     To: tictoc@ietf.org 
>
>     Cc: ntp@ietf.org 
>
>     Subject: [TICTOC] WGLC for draft-ietf-tictoc-1588v2-yang
>
>     Folks,
>
>     This message begins a 2 week working group last call (WGLC) for
>     the following document:
>
>     YANG Data Model for IEEE 1588v2
>
>     https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588v2-yang/
>
>     Please review the referenced document and send any comments to the
>     mailing list including your assessment of whether this document is
>     mature enough to proceed to the IESG. Please note that these
>     messages of support for progression to the mailing list are
>     important and will be used to determine WG consensus to proceed.
>
>     Please send all comments in by Thursday 28 September 2017.
>
>     Thank you!
>
>     Karen
>
>     _______________________________________________
>
>     TICTOC mailing list
>
>     TICTOC@ietf.org 
>
>     https://www.ietf.org/mailman/listinfo/tictoc
>
>     _______________________________________________
>
>     netmod mailing list
>
>     netmod@ietf.org 
>
>     https://www.ietf.org/mailman/listinfo/netmod
>
>     .
>


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


  
    
  
  
    
Dear Yuanlong,

      

      The pyang bug has been fixed (thanks Martin).

      I updated my toolchain with the latest pyang version (and the
      latest yanglint 0.13.49, btw).

      So no more errors at
      http://www.claise.be/IETFYANGPageCompilation.html for your draft.

      

      For the IETF tracker, I guess we have to wait until the next pyang
      version (1.7.4) for Henrik to update pyang.

      

      yangcatalog.org still needs to be updated with the latest
      validators.

      

      Regards, Benoit

    

    

      
      
      
      

        
Dear Benoit,

        
 

        
Thank you much for the instruction and the
            explanation.

        
There are errors shown in
            
https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588v2-yang/?include_text=1,
            but it passes validation by
            http://www.yangvalidator.com/draft-validator.
            It seems different versions of pyang were used and the
            results provided by our official site are inconsistent now.

        
 

        
Best regards,

        
Yuanlong

        
 

        

          

            
From: Benoit Claise [mailto:bclaise@cisco.com]
                

                Sent: Friday, September 15, 2017 8:48 PM

                To: Jiangyuanlong; netmod@ietf.org; Mehmet

                Cc: tictoc@ietf.org

                Subject: Re: [netmod] FW: WGLC for
                draft-ietf-tictoc-1588v2-yang

          

        

        
 

        

          
Hi Yuanong,

              

              There is pyang error.

              http://www.claise.be/IETFYANGPageCompilation.html

          

            
              

                
                  
ietf-ptp-dataset@2017-04-20.yang:294:
                      error: the value "0xFFFF" does not match its base
                      type - not an integer

                		
              

            
          

          
However, this is a
              pyang problem. See 
                https://github.com/mbj4668/pyang/issues/329

              

              Mehmet, can you please a YANG doctor. The YANG doctor
              review is normally done during IETF LC, but nothing
              prevents an early review.

              

              Regards, Benoit

        

        

          
Hi netmoders,

          
 

          
This draft does not tackle the general YANG problem, but provide a generic time synchronization module of 1588.

          
Some of you may have interests in time synchronization, some definitely not. But as experts in YANG, could you please have a review of this YANG module and give an expert opinion?

          
 

          
Thanks,

          
Yuanlong

          
 

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

          
From: TICTOC [mailto:tictoc-bounces@ietf.org] On Behalf Of Karen O'Donoghue

          
Sent: Thursday, September 14, 2017 3:16 AM

          
To: tictoc@ietf.org

          
Cc: ntp@ietf.org

          
Subject: [TICTOC] WGLC for draft-ietf-tictoc-1588v2-yang

          
 

          
Folks,

          
 

          
This message begins a 2 week working group last call (WGLC) for the following document: 

          
 

          
YANG Data Model for IEEE 1588v2

          
https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588v2-yang/

          
 

          
Please review the referenced document and send any comments to the mailing list including your assessment of whether this document is mature enough to proceed to the IESG. Please note that these messages of support for progression to the mailing list are important and will be used to determine WG consensus to proceed. 

          
 

          
Please send all comments in by Thursday 28 September 2017.  

          
 

          
Thank you!

          
Karen

          
_______________________________________________

          
TICTOC mailing list

          
TICTOC@ietf.org

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

          
 

          
_______________________________________________

          
netmod mailing list

          
netmod@ietf.org

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

          
.

          
 

        

        
 

      

    

    

  


--------------B6A96880AD86E0731D0471DF--


From nobody Wed Sep 20 18:00:13 2017
Return-Path: 
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 BE73E132944; Wed, 20 Sep 2017 18:00:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level: 
X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 1BnpZiPzd6c1; Wed, 20 Sep 2017 18:00:10 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA606132CE7; Wed, 20 Sep 2017 18:00:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6723; q=dns/txt; s=iport; t=1505955609; x=1507165209; h=to:cc:from:subject:message-id:date:mime-version; bh=1LLmztzNuhsvr3whFV/099LoM7UtRWMn0aQJKPwWuC8=; b=iZU8zXqokclcYTTD8Qh0u1x0wNdYguLmKmFow4CiD+UhSUs1AEXKbMCL bEeUEZKIQtc143l75+JTBcDiHlK7GDPxzDZ8Ni07/mcrajM+p2WhHhOzd unhPsLedWxAeLhIgkM/53GHmjTcyEhnxv9a4u5gJ7eoolDYaEs3bkhV1w U=;
X-IronPort-AV: E=Sophos;i="5.42,422,1500940800"; d="scan'208,217";a="5939108"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Sep 2017 01:00:09 +0000
Received: from [10.155.68.132] (dhcp-10-155-68-132.cisco.com [10.155.68.132]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v8L108QE017591; Thu, 21 Sep 2017 01:00:08 GMT
To: NETMOD Working Group 
Cc: draft-claise-semver@ietf.org, "Miroslav Kovac -X (mirkovac - PANTHEON TECHNOLOGIES at Cisco)" 
From: Benoit Claise 
Message-ID: 
Date: Wed, 20 Sep 2017 18:00:08 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------CCAADBD5FDCCED4D2E9A3950"
Content-Language: en-US
Archived-At: 
Subject: [netmod] semver.org comparison of two YANG modules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Sep 2017 01:00:12 -0000

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

Dear all,

In light of draft-claise-semver-01 
, and thinking 
about adding an extra metadata piece of information to a YANG module 
(for example here 
), 
I'm wondering if any of you investigated how to map semver tags into 
backwards (in)compatible YANG module revisions?

    The fields in such a structured version have the following semantics
    (cf.  semver.org):

    o  MAJOR is incremented when the new version of the specification is
       incompatible with previous versions.

    o  MINOR is incremented when new functionality is added in a manner
       that is backward-compatible with previous versions.

    o  PATCH is incremented when bug fixes are made in a backward-
       compatible manner.


I played with "pyang --check-update-from". As an example, ietf-interfaces

    $ pyang ietf-interfaces@2017-08-14.yang
    ietf-interfaces@2017-08-14.yang:1: warning: unexpected latest
    revision "2017-08-17" in ietf-interfaces@2017-08-14.yang, should be
    2017-08-14


Let's not pay attention to this warning above.
If I compare with the RFC version, I get the same output. cx

    $ pyang --path=/home/bclaise/yang/modules
    --check-update-from=/home/bclaise/ietf/YANG-rfc/ietf-interfaces@2014-05-08.yang
    ietf-interfaces@2017-08-14.yang
    ietf-interfaces@2017-08-14.yang:1: warning: unexpected latest
    revision "2017-08-17" in ietf-interfaces@2017-08-14.yang, should be
    2017-08-14
    So the tag should be MINOR or PATCH. Not sure if there is a way to
    automate MINOR versus PATCH?


Now, if I manually modify a leaf in ietf-interfaces@2014-05-08.yang, 
then I get:

    $ pyang --path=/home/bclaise/yang/modules
    --check-update-from=/home/bclaise/ietf/YANG-rfc/ietf-interfaces@2014-05-08.yang
    ietf-interfaces@2017-08-14.yang
    ietf-interfaces@2017-08-14.yang:1: warning: unexpected latest
    revision "2017-08-17" in ietf-interfaces@2017-08-14.yang, should be
    2017-08-14
    ietf-interfaces@2017-08-14.yang:224: error: the base type has
    illegally changed from string to boolean

So I should increment the MAJOR tag.

Is my logic right? Is "pyang --check-update-from" reliable for my use case?

And yeah, I know YANG modules are always supposed to be backwards 
compatible...

Regards, Benoit

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


  

    
  
  
    Dear all,

    

    In light of draft-claise-semver-01,
    and thinking about adding an extra metadata piece of information to
    a YANG module (for example here),
    I'm wondering if any of you investigated how to map semver tags into
    backwards (in)compatible YANG module revisions?

    
   The fields in such a structured version have the following semantics
   (cf.  semver.org):

   o  MAJOR is incremented when the new version of the specification is
      incompatible with previous versions.

   o  MINOR is incremented when new functionality is added in a manner
      that is backward-compatible with previous versions.

   o  PATCH is incremented when bug fixes are made in a backward-
      compatible manner.


    

    I played with "pyang --check-update-from". As an example,
    ietf-interfaces

    

    
$ pyang ietf-interfaces@2017-08-14.yang 

      ietf-interfaces@2017-08-14.yang:1: warning: unexpected latest
      revision "2017-08-17" in ietf-interfaces@2017-08-14.yang, should
      be 2017-08-14

    

    

    Let's not pay attention to this warning above.

    If I compare with the RFC version, I get the same output. cx

    
$ pyang --path=/home/bclaise/yang/modules
--check-update-from=/home/bclaise/ietf/YANG-rfc/ietf-interfaces@2014-05-08.yang
      ietf-interfaces@2017-08-14.yang 

      ietf-interfaces@2017-08-14.yang:1: warning: unexpected latest
      revision "2017-08-17" in ietf-interfaces@2017-08-14.yang, should
      be 2017-08-14

      So the tag should be MINOR or PATCH. Not sure if there is a way to
      automate MINOR versus PATCH?

    

    

    Now, if I manually modify a leaf in ietf-interfaces@2014-05-08.yang,
    then I get:

    
$ pyang --path=/home/bclaise/yang/modules
--check-update-from=/home/bclaise/ietf/YANG-rfc/ietf-interfaces@2014-05-08.yang
      ietf-interfaces@2017-08-14.yang 

      ietf-interfaces@2017-08-14.yang:1: warning: unexpected latest
      revision "2017-08-17" in ietf-interfaces@2017-08-14.yang, should
      be 2017-08-14

      ietf-interfaces@2017-08-14.yang:224: error: the base type has
      illegally changed from string to boolean

    

    So I should increment the MAJOR tag.

    

    Is my logic right? Is "pyang --check-update-from" reliable for my
    use case?

    

    And yeah, I know YANG modules are always supposed to be backwards
    compatible...

    

    Regards, Benoit

  


--------------CCAADBD5FDCCED4D2E9A3950--


From nobody Thu Sep 21 02:38:47 2017
Return-Path: 
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 703EE134677 for ; Thu, 21 Sep 2017 02:38:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 CozLmMpz-0F9 for ; Thu, 21 Sep 2017 02:38:43 -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 4D06C134661 for ; Thu, 21 Sep 2017 02:38:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6078; q=dns/txt; s=iport; t=1505986690; x=1507196290; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=E0cuIz+hXfHjI+unDSoxaAJwlqKDQHD2Jr6wms9pwzw=; b=PmcnPs0ngD4praHOzAIevKJb6RDObohy2eNA/2VjodiuflUV97MPA2J6 U76QD9yGclSlev3uGCWbGF7MapICGTHwCrt4OWGQ59P7W3c9fFFOBQhdl ww2PbdwNYyHhk5IINqZ8jZvtN/ADKgG7uhw36t9p4EztmjsH1i9unn0oB 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQA9h8NZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy2BEW4ng3aLFJBMK5g7CieFFAKFMRUBAgEBAQEBAQFrKIUYAQE?= =?us-ascii?q?BAQIBIw8BBVEJAhgCAiYCAlcTBgIBAReKEAgQiTudZoInin4BAQEBAQUBAQEBA?= =?us-ascii?q?QEdBYEOgh2DU4FkK4J9iA6CYAWKI4cUgWiNdIddjHqCE4Vqg1qHJI1jh1eBOTU?= =?us-ascii?q?igQ0yIQgcFYdmPzYBhmErghUBAQE?=
X-IronPort-AV: E=Sophos;i="5.42,424,1500940800"; d="scan'208";a="655807910"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Sep 2017 09:38:08 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8L9c7BR028675 for ; Thu, 21 Sep 2017 09:38:08 GMT
To: netmod@ietf.org
References: <393d3f20-98e3-b4de-e2d7-d627de59ac1f@labn.net> <1505814417.5445.14.camel@nic.cz> <20170919.115915.1668734288988659917.mbj@tail-f.com> <87shfistam.fsf@nic.cz> <75221540-d587-cd90-60ab-7cf6a8ff5cd4@cisco.com> <1505830045.5445.47.camel@nic.cz> <4ec007bc-6eb6-38f9-562e-ce9d0b4e1c00@cisco.com> <87mv5p783v.fsf@nic.cz>
From: Robert Wilton 
Message-ID: <9e3e2d36-f99e-aa9c-844a-d61b3ca20213@cisco.com>
Date: Thu, 21 Sep 2017 10:38:07 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <87mv5p783v.fsf@nic.cz>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Sep 2017 09:38:45 -0000

On 20/09/2017 15:33, Ladislav Lhotka wrote:
> Robert Wilton  writes:
>
>> On 19/09/2017 15:07, Ladislav Lhotka wrote:
>>> Robert Wilton píše v Út 19. 09. 2017 v 14:49 +0100:
>>>> Hi Lada,
>>>>
>>>>
>>>> On 19/09/2017 14:37, Ladislav Lhotka wrote:
>>>>> Martin Bjorklund  writes:
>>>>>
>>>>>> Ladislav Lhotka  wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I support the adoption but I propose two conceptual changes:
>>>>>>>
>>>>>>> 1. Introduce a new module name and namespace so that it is not
>>>>>>> necessary to carry along the deprecated baggage. If readability is
>>>>>>> the primary concern, this is IMO the way to go. Instead of
>>>>>>> "ietf-ip-2", I'd suggest something like "ietf- ip-nmda".
>>>>>>>
>>>>>>> 2. Avoid obsoleting RFC 7277. I believe the old modules may continue
>>>>>>> to be used
>>>>>>> in areas where NMDA is an overkill, such as open source home
>>>>>>> routers.
>>>>>> Why wouldn't NMDA be appropriate in an open source home router?  Note
>>>>>> that the new model really just have a single tree instead of two
>>>>>> trees, so the data that needs to be instrumented is more or less the
>>>>>> same.
>>>>> It is quite likely that some parts of the data models will be
>>>>> implemented only as configuration but not state data. In the "old style"
>>>>> modules it is easy to add a deviation for the node(s) under -state but
>>>>> in NMDA style this is not possible because we only have one node.
>>>> The new YANG library allows different sets of modules to be available
>>>> for  datastores vs .   The operational
>>>> datastore can also have different features supported and different
>>>> deviations vs the conventional datastores.
>>> OK, I missed the 7895bis draft, sorry. Then there could be differences in
>>> mandatory/optional (e.g. a node is optional in configuration but mandatory in
>>> state data) or the data type of a leaf can differ. How can these be handled?
>> If the data type of the leaf can differ, then normally this should be
>> modeled as two separate leaves.  Do you have a concrete example of
>> this?
> So, for example, duplex and duplex-state? And  will
> have both as siblings?
Here I presume you are thinking that the configurable value for duplex 
is "full/half/auto", but the operational value is "full/half"?

The solution here is really to model auto-negotiation on/off as a 
separate leaf (which also more closely reflects the actual behaviour of 
the auto-negotiation protocol).  Then for duplex both the space for both 
the configured and operational leaves are the same, i.e. both taking 
"full/half", and hence only a single leaf is required to model both the 
optional configured value and the operational value.

A concrete example of the Ethernet interface YANG structured this way is @
https://github.com/8023YangDesignTeam/EthernetYang/blob/nmda/standard/ieee/802.3/draft/ieee802-ethernet-interface.yang



>
>> If some data is mandatory in config, but not necessarily mandatory in
>>  then normally it can be marked as mandatory true, since
>> optional is allowed to violate this constraint if necessary, but
>> implementations would generally be expected to conform to the constraint
>> if possible.
>>
>> For the reverse case, we can't express that.  I think that you would
>> have to leave out the "mandatory: true" constraint.  Again, can you
>> provide a concrete example of this please?  That makes it a bit easier
>> to reason about.
> This should be quite typical: a config leaf is optional and if it is not
> configured, the system sets it to some value (as in the case of
> router-id). But in state data it is mandatory so that the client can see
> what the system chose.
Yes, I agree that this scenario is very likely, but I think that the 
solution here is just to not mark the leaf as mandatory.

It is interesting to consider what "mandatory" exactly means in the 
 datastore.  Given that the mandatory constraint may be 
violated in , then my interpretation is that it means that 
a correct implementation SHOULD always return a mandatory node (if it is 
in scope).  But a client has no way to force a device return this data 
(except perhaps shouting at the vendor :-), and so it seems that a 
robust client would need to be able to cope with the fact that the 
device is not behaving nicely and isn't returning the data regardless of 
any mandatory keyword specified in the schema.

To further expand on this, a device is required to ensure that 
configuration datastores are valid, and hence all mandatory constraints 
are enforced, or a config change would be rejected, but I don't think 
that many devices are going to validate operational. They will just 
return the current state of the system back to the client, and let the 
client deal with any unexpected inconsistencies.

Also, what about all the regular config false nodes in the schema that 
are not marked as mandatory?  Is a device always required to return 
those leaves (if they are in scope)?  If a device is never going to 
return those leaves then it should use a deviation to remove them, but 
is that actually required?

Is seems that possibly the most useful use of mandatory in the context 
of operational is for something like an IP address/prefix length 
pairing, i.e. to indicate that the data really doesn't make any sense 
unless both address and prefix are provided.

When the next version of YANG is specified, perhaps we should consider 
allowing an extra options to mandatory to that it only applies to the 
state datastores?  if so, we could add this to the YANG.Next issue tracker?

So, in conclusion, I think that the NMDA modelling advice for mandatory 
on config true nodes might be to only use it when the node is mandatory 
in configuration datastores.

If the WG isn't opposed, then I would suggested adding this to the NMDA FAQ.

Thanks,
Rob


From nobody Thu Sep 21 04:38:55 2017
Return-Path: 
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 AE924134ACB for ; Thu, 21 Sep 2017 04:38:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3II4kY_6FUtk for ; Thu, 21 Sep 2017 04:38:51 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6435C134AD0 for ; Thu, 21 Sep 2017 04:38:50 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id B9A641820E76; Wed, 20 Sep 2017 16:32:14 +0200 (CEST)
Received: from localhost (unknown [195.113.220.126]) by trail.lhotka.name (Postfix) with ESMTPSA id D9DA81820E71; Wed, 20 Sep 2017 16:32:12 +0200 (CEST)
From: Ladislav Lhotka 
To: Robert Wilton , netmod@ietf.org
In-Reply-To: <4ec007bc-6eb6-38f9-562e-ce9d0b4e1c00@cisco.com>
References: <393d3f20-98e3-b4de-e2d7-d627de59ac1f@labn.net> <1505814417.5445.14.camel@nic.cz> <20170919.115915.1668734288988659917.mbj@tail-f.com> <87shfistam.fsf@nic.cz> <75221540-d587-cd90-60ab-7cf6a8ff5cd4@cisco.com> <1505830045.5445.47.camel@nic.cz> <4ec007bc-6eb6-38f9-562e-ce9d0b4e1c00@cisco.com>
Mail-Followup-To: Robert Wilton , netmod@ietf.org
Date: Wed, 20 Sep 2017 16:33:24 +0200
Message-ID: <87mv5p783v.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Sep 2017 11:38:55 -0000

Robert Wilton  writes:

> On 19/09/2017 15:07, Ladislav Lhotka wrote:
>> Robert Wilton p=C3=AD=C5=A1e v =C3=9At 19. 09. 2017 v 14:49 +0100:
>>> Hi Lada,
>>>
>>>
>>> On 19/09/2017 14:37, Ladislav Lhotka wrote:
>>>> Martin Bjorklund  writes:
>>>>
>>>>> Ladislav Lhotka  wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I support the adoption but I propose two conceptual changes:
>>>>>>
>>>>>> 1. Introduce a new module name and namespace so that it is not
>>>>>> necessary to carry along the deprecated baggage. If readability is
>>>>>> the primary concern, this is IMO the way to go. Instead of
>>>>>> "ietf-ip-2", I'd suggest something like "ietf- ip-nmda".
>>>>>>
>>>>>> 2. Avoid obsoleting RFC 7277. I believe the old modules may continue
>>>>>> to be used
>>>>>> in areas where NMDA is an overkill, such as open source home
>>>>>> routers.
>>>>> Why wouldn't NMDA be appropriate in an open source home router?  Note
>>>>> that the new model really just have a single tree instead of two
>>>>> trees, so the data that needs to be instrumented is more or less the
>>>>> same.
>>>> It is quite likely that some parts of the data models will be
>>>> implemented only as configuration but not state data. In the "old styl=
e"
>>>> modules it is easy to add a deviation for the node(s) under -state but
>>>> in NMDA style this is not possible because we only have one node.
>>> The new YANG library allows different sets of modules to be available
>>> for  datastores vs .   The operational
>>> datastore can also have different features supported and different
>>> deviations vs the conventional datastores.
>> OK, I missed the 7895bis draft, sorry. Then there could be differences in
>> mandatory/optional (e.g. a node is optional in configuration but mandato=
ry in
>> state data) or the data type of a leaf can differ. How can these be hand=
led?
> If the data type of the leaf can differ, then normally this should be=20
> modeled as two separate leaves.=C2=A0 Do you have a concrete example of
> this?

So, for example, duplex and duplex-state? And  will
have both as siblings?

>
> If some data is mandatory in config, but not necessarily mandatory in=20
>  then normally it can be marked as mandatory true, since=20
> optional is allowed to violate this constraint if necessary, but=20
> implementations would generally be expected to conform to the constraint=
=20
> if possible.
>
> For the reverse case, we can't express that.=C2=A0 I think that you would=
=20
> have to leave out the "mandatory: true" constraint.=C2=A0 Again, can you=
=20
> provide a concrete example of this please?=C2=A0 That makes it a bit easi=
er=20
> to reason about.

This should be quite typical: a config leaf is optional and if it is not
configured, the system sets it to some value (as in the case of
router-id). But in state data it is mandatory so that the client can see
what the system chose.

Lada

>
> Thanks,
> Rob
>
>
>>
>> Lada
>>
>>> So, the device can make the same deviations to remove the state leaves
>>> from .  Or if they don't want to support the module in
>>> operational at all then a device could just list it as being supported
>>> in the conventional datastores and not .
>>>
>>>> There are subtle differences in the schemas for configuration and state
>>>> data that the NMDA concept doesn't address. If you want another exampl=
e,
>>>> ietf-routing-2 has the "router-id" leaf that is conditional via the
>>>> "router-id" feature. If this feature is not supported, router-id cannot
>>>> be explicitly configured (it is assigned by the system) but in state d=
ata
>>>> "router-id" needs IMO be present in any case. But the if-feature
>>>> isn't able to differentiate between configuration and state data if
>>>> there is only one node for both.
>>> The new YANG library also supports this:
>>>
>>> The "router-id" feature would be disabled for the conventional
>>> datastores, but enabled for .
>>>
>>>>> In fact, if we claim that the new architecture is not appropriate for
>>>>> some devices I think we have failed, especially if the conclusion is
>>>>> that we need to maintain two versions of all modules going forward.
>>>> I am not asking for this but, on the other hand, if NMDA versions used=
 a new
>>>> module name and namespace (my item #1, which is what ietf-routing-2
>>>> does), then I don't see any pressing need for obsoleting the old style
>>>> modules.
>>> I think that creating a "-2" versions of these models at this time might
>>> be a mistake.  I actually think that the "deprecate state leaves" ->
>>> "obsolete state leaves" -> "delete state leaves" path is a better choic=
e.
>>>
>>> Thanks,
>>> Rob
>>>
>>>
>>>> Lada
>>>>
>>>>> /martin
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> NMDA
>>>>>> implementors should be aware of the new modules but there is no need=
 to
>>>>>> eradicate the old data models.
>>>>>>
>>>>>> #2 applies also to other modules for which the NMDA version is under=
way.
>>>>>>
>>>>>> Lada
>>>>>>
>>>>>> PS. The subject is wrong, it shoud be -rfc7277bis-
>>>>>>=20=20=20=20
>>>>>> Lou Berger p=C3=AD=C5=A1e v Po 18. 09. 2017 v 10:33 -0400:
>>>>>>> All,
>>>>>>>
>>>>>>> This is start of a two week poll on making
>>>>>>> draft-bjorklund-netmod-rfc7227bis-00 a working group document. Plea=
se
>>>>>>> send email to the list indicating "yes/support" or "no/do not
>>>>>>> support".
>>>>>>> If indicating no, please state your reservations with the
>>>>>>> document.  If
>>>>>>> yes, please also feel free to provide comments you'd like to see
>>>>>>> addressed once the document is a WG document.
>>>>>>>
>>>>>>> The poll ends Oct 2.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Lou (and Kent)
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> netmod mailing list
>>>>>>> netmod@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>> --=20
>>>>>> Ladislav Lhotka
>>>>>> Head, CZ.NIC Labs
>>>>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>>>>
>>>>>> _______________________________________________
>>>>>> netmod mailing list
>>>>>> netmod@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>

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


From nobody Thu Sep 21 04:50:16 2017
Return-Path: 
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 F1A97126C0F; Thu, 21 Sep 2017 04:50:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0OPik80m-lR; Thu, 21 Sep 2017 04:50:03 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0323E1323B8; Thu, 21 Sep 2017 04:50:01 -0700 (PDT)
Received: from [193.10.0.186] (port=62159 helo=tannat.pilsnet.sunet.se) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1duzzS-0006mw-4S; Thu, 21 Sep 2017 04:49:59 -0700
To: Benoit Claise , Jiangyuanlong , "netmod@ietf.org" , Mehmet 
References: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5A2CBD@dggeml507-mbx.china.huawei.com> <331b6b30-8089-5411-9a33-88014b7d66c9@cisco.com> <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5BA686@dggeml507-mbx.china.huawei.com> 
Cc: "tictoc@ietf.org" 
From: Henrik Levkowetz 
Message-ID: <59C3A771.8000400@levkowetz.com>
Date: Thu, 21 Sep 2017 13:50:09 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 193.10.0.186
X-SA-Exim-Rcpt-To: tictoc@ietf.org, mersue@gmail.com, netmod@ietf.org, jiangyuanlong@huawei.com, bclaise@cisco.com
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: 
Subject: Re: [netmod] FW: WGLC for draft-ietf-tictoc-1588v2-yang
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Sep 2017 11:50:07 -0000

Hi Benoit,

The version of pyang used by the datatracker will be updated when the next
release installation is done, which I expect to be later today (6.62.1).


Best regards,

	Henrik

On 2017-09-21 01:54, Benoit Claise wrote:
> Dear Yuanlong,
> 
> The pyang bug has been fixed (thanks Martin).
> I updated my toolchain with the latest pyang version (and the latest 
> yanglint 0.13.49, btw).
> So no more errors at http://www.claise.be/IETFYANGPageCompilation.html 
> for your draft.
> 
> For the IETF tracker, I guess we have to wait until the next pyang 
> version (1.7.4) for Henrik to update pyang.
> 
> yangcatalog.org still needs to be updated with the latest validators.
> 
> Regards, Benoit
>>
>> Dear Benoit,
>>
>> Thank you much for the instruction and the explanation.
>>
>> There are errors shown in 
>> https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588v2-yang/?include_text=1, 
>> but it passes validation by 
>> http://www.yangvalidator.com/draft-validator. It seems different 
>> versions of pyang were used and the results provided by our official 
>> site are inconsistent now.
>>
>> Best regards,
>>
>> Yuanlong
>>
>> *From:*Benoit Claise [mailto:bclaise@cisco.com]
>> *Sent:* Friday, September 15, 2017 8:48 PM
>> *To:* Jiangyuanlong; netmod@ietf.org; Mehmet
>> *Cc:* tictoc@ietf.org
>> *Subject:* Re: [netmod] FW: WGLC for draft-ietf-tictoc-1588v2-yang
>>
>> Hi Yuanong,
>>
>> There is pyang error.
>> http://www.claise.be/IETFYANGPageCompilation.html
>>
>> ietf-ptp-dataset@2017-04-20.yang:294 
>> : error: the value 
>> "0xFFFF" does not match its base type - not an integer
>>
>> However, this is a pyang problem. See 
>> https://github.com/mbj4668/pyang/issues/329 
>> 
>>
>> Mehmet, can you please a YANG doctor. The YANG doctor review is 
>> normally done during IETF LC, but nothing prevents an early review.
>>
>> Regards, Benoit
>>
>>     Hi netmoders,
>>
>>     This draft does not tackle the general YANG problem, but provide a
>>     generic time synchronization module of 1588.
>>
>>     Some of you may have interests in time synchronization, some
>>     definitely not. But as experts in YANG, could you please have a
>>     review of this YANG module and give an expert opinion?
>>
>>     Thanks,
>>
>>     Yuanlong
>>
>>     -----Original Message-----
>>
>>     From: TICTOC [mailto:tictoc-bounces@ietf.org] On Behalf Of Karen
>>     O'Donoghue
>>
>>     Sent: Thursday, September 14, 2017 3:16 AM
>>
>>     To: tictoc@ietf.org 
>>
>>     Cc: ntp@ietf.org 
>>
>>     Subject: [TICTOC] WGLC for draft-ietf-tictoc-1588v2-yang
>>
>>     Folks,
>>
>>     This message begins a 2 week working group last call (WGLC) for
>>     the following document:
>>
>>     YANG Data Model for IEEE 1588v2
>>
>>     https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588v2-yang/
>>
>>     Please review the referenced document and send any comments to the
>>     mailing list including your assessment of whether this document is
>>     mature enough to proceed to the IESG. Please note that these
>>     messages of support for progression to the mailing list are
>>     important and will be used to determine WG consensus to proceed.
>>
>>     Please send all comments in by Thursday 28 September 2017.
>>
>>     Thank you!
>>
>>     Karen
>>
>>     _______________________________________________
>>
>>     TICTOC mailing list
>>
>>     TICTOC@ietf.org 
>>
>>     https://www.ietf.org/mailman/listinfo/tictoc
>>
>>     _______________________________________________
>>
>>     netmod mailing list
>>
>>     netmod@ietf.org 
>>
>>     https://www.ietf.org/mailman/listinfo/netmod
>>
>>     .
>>
> 
> 


From nobody Thu Sep 21 08:10:18 2017
Return-Path: 
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 E5AF3132811 for ; Thu, 21 Sep 2017 08:10:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level: 
X-Spam-Status: No, score=-6.999 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, URIBL_BLOCKED=0.001] 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 V1E291fqHs8k for ; Thu, 21 Sep 2017 08:10:15 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 E54D9126B6D for ; Thu, 21 Sep 2017 08:10:14 -0700 (PDT)
Received: from birdie5 (unknown [IPv6:2001:1488:fffe:6:f4a0:4ce4:6515:464f]) by mail.nic.cz (Postfix) with ESMTPSA id 81FE5624B7 for ; Thu, 21 Sep 2017 17:10:12 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1506006612; bh=bQ6zoyQouubbB6gTKSOEI0ddW6ta21QVMS5NhDUOBgM=; h=From:To:Date; b=cxBQjxOiNnnyRYRUK2AhOi3oYbZWPPtwLW68V/CoGohcBS/9rhpsAC8RGos0B3IB+ rW2gSFZcfAR5QpCNbcXpuxtWK53X30RP6pfK2xG5JGDJpKC+NkaC+0U/XM5p5Djm56 74C2GvZDRUD9TNNXus1eTrse8dofxIudRAK563UI=
Message-ID: <1506006652.6428.57.camel@nic.cz>
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Thu, 21 Sep 2017 17:10:52 +0200
In-Reply-To: <9e3e2d36-f99e-aa9c-844a-d61b3ca20213@cisco.com>
References: <393d3f20-98e3-b4de-e2d7-d627de59ac1f@labn.net> <1505814417.5445.14.camel@nic.cz> <20170919.115915.1668734288988659917.mbj@tail-f.com> <87shfistam.fsf@nic.cz> <75221540-d587-cd90-60ab-7cf6a8ff5cd4@cisco.com> <1505830045.5445.47.camel@nic.cz> <4ec007bc-6eb6-38f9-562e-ce9d0b4e1c00@cisco.com> <87mv5p783v.fsf@nic.cz> <9e3e2d36-f99e-aa9c-844a-d61b3ca20213@cisco.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.24.5 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Sep 2017 15:10:18 -0000

Robert Wilton píše v Čt 21. 09. 2017 v 10:38 +0100:
> 
> On 20/09/2017 15:33, Ladislav Lhotka wrote:
> > Robert Wilton  writes:
> > 
> > > On 19/09/2017 15:07, Ladislav Lhotka wrote:
> > > > Robert Wilton píše v Út 19. 09. 2017 v 14:49 +0100:
> > > > > Hi Lada,
> > > > > 
> > > > > 
> > > > > On 19/09/2017 14:37, Ladislav Lhotka wrote:
> > > > > > Martin Bjorklund  writes:
> > > > > > 
> > > > > > > Ladislav Lhotka  wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > I support the adoption but I propose two conceptual changes:
> > > > > > > > 
> > > > > > > > 1. Introduce a new module name and namespace so that it is not
> > > > > > > > necessary to carry along the deprecated baggage. If readability
> > > > > > > > is
> > > > > > > > the primary concern, this is IMO the way to go. Instead of
> > > > > > > > "ietf-ip-2", I'd suggest something like "ietf- ip-nmda".
> > > > > > > > 
> > > > > > > > 2. Avoid obsoleting RFC 7277. I believe the old modules may
> > > > > > > > continue
> > > > > > > > to be used
> > > > > > > > in areas where NMDA is an overkill, such as open source home
> > > > > > > > routers.
> > > > > > > 
> > > > > > > Why wouldn't NMDA be appropriate in an open source home
> > > > > > > router?  Note
> > > > > > > that the new model really just have a single tree instead of two
> > > > > > > trees, so the data that needs to be instrumented is more or less
> > > > > > > the
> > > > > > > same.
> > > > > > 
> > > > > > It is quite likely that some parts of the data models will be
> > > > > > implemented only as configuration but not state data. In the "old
> > > > > > style"
> > > > > > modules it is easy to add a deviation for the node(s) under -state
> > > > > > but
> > > > > > in NMDA style this is not possible because we only have one node.
> > > > > 
> > > > > The new YANG library allows different sets of modules to be available
> > > > > for  datastores vs .   The operational
> > > > > datastore can also have different features supported and different
> > > > > deviations vs the conventional datastores.
> > > > 
> > > > OK, I missed the 7895bis draft, sorry. Then there could be differences
> > > > in
> > > > mandatory/optional (e.g. a node is optional in configuration but
> > > > mandatory in
> > > > state data) or the data type of a leaf can differ. How can these be
> > > > handled?
> > > 
> > > If the data type of the leaf can differ, then normally this should be
> > > modeled as two separate leaves.  Do you have a concrete example of
> > > this?
> > 
> > So, for example, duplex and duplex-state? And  will
> > have both as siblings?
> 
> Here I presume you are thinking that the configurable value for duplex 
> is "full/half/auto", but the operational value is "full/half"?
> 
> The solution here is really to model auto-negotiation on/off as a 
> separate leaf (which also more closely reflects the actual behaviour of 
> the auto-negotiation protocol).  Then for duplex both the space for both 
> the configured and operational leaves are the same, i.e. both taking 
> "full/half", and hence only a single leaf is required to model both the 
> optional configured value and the operational value.

Yes, this sounds reasonable. Here also the config value should then be optional
while the state value mandatory.

> 
> A concrete example of the Ethernet interface YANG structured this way is @
> https://github.com/8023YangDesignTeam/EthernetYang/blob/nmda/standard/ieee/802
> .3/draft/ieee802-ethernet-interface.yang
> 
> 
> 
> > 
> > > If some data is mandatory in config, but not necessarily mandatory in
> > >  then normally it can be marked as mandatory true, since
> > > optional is allowed to violate this constraint if necessary, but
> > > implementations would generally be expected to conform to the constraint
> > > if possible.
> > > 
> > > For the reverse case, we can't express that.  I think that you would
> > > have to leave out the "mandatory: true" constraint.  Again, can you
> > > provide a concrete example of this please?  That makes it a bit easier
> > > to reason about.
> > 
> > This should be quite typical: a config leaf is optional and if it is not
> > configured, the system sets it to some value (as in the case of
> > router-id). But in state data it is mandatory so that the client can see
> > what the system chose.
> 
> Yes, I agree that this scenario is very likely, but I think that the 
> solution here is just to not mark the leaf as mandatory.

But this makes the schema weaker, and implementors may think it needn't be
implemented.

> 
> It is interesting to consider what "mandatory" exactly means in the 
>  datastore.  Given that the mandatory constraint may be

Yes, the semantics in the context of NM protocols is different from that of
configuration datastores. But in the context of document (data tree) validation
it is the same: the instance has to be present for a data tree to be valid. 

> violated in , then my interpretation is that it means that 
> a correct implementation SHOULD always return a mandatory node (if it is 
> in scope).  But a client has no way to force a device return this data 
> (except perhaps shouting at the vendor :-), and so it seems that a 
> robust client would need to be able to cope with the fact that the 
> device is not behaving nicely and isn't returning the data regardless of 
> any mandatory keyword specified in the schema.

I don't really share this view, it is IMO not much different from the situation
when a vendor fails to implement a config node. Either way, the implementation
doesn't conform to the data model.

One of the benefits of a data model is that an application can offload
validation to an external tool, such as a generic YANG library, and then can
rely on data being valid so that the application's code needn't be cluttered
with all kinds of sanity checks.

I can imagine a tool collecting data from a number of devices that fails if a
mandatory state data are absent.  

> 
> To further expand on this, a device is required to ensure that 
> configuration datastores are valid, and hence all mandatory constraints 
> are enforced, or a config change would be rejected, but I don't think 
> that many devices are going to validate operational. They will just
> return the current state of the system back to the client, and let the 
> client deal with any unexpected inconsistencies.

I could likewise expect the server to be prepared to deal with unexpected
inconsistencies in config data. The data model is a contract, so it should be
binding for both parties.

> 
> Also, what about all the regular config false nodes in the schema that 
> are not marked as mandatory?  Is a device always required to return 
> those leaves (if they are in scope)?  If a device is never going to 

In terms of YANG, no.

> return those leaves then it should use a deviation to remove them, but 
> is that actually required?
> 
> Is seems that possibly the most useful use of mandatory in the context 
> of operational is for something like an IP address/prefix length 
> pairing, i.e. to indicate that the data really doesn't make any sense 
> unless both address and prefix are provided.
> 
> When the next version of YANG is specified, perhaps we should consider 
> allowing an extra options to mandatory to that it only applies to the 
> state datastores?  if so, we could add this to the YANG.Next issue tracker?

I believe the fundamental problem is that YANG was designed basically as a
document-oriented schema language, and NMDA tries to make the same schema work
for multiple different data trees. I am concerned this means a lot of complexity
 and CLRs that will render the next version unusable.

Lada

> 
> So, in conclusion, I think that the NMDA modelling advice for mandatory 
> on config true nodes might be to only use it when the node is mandatory 
> in configuration datastores.
> 
> If the WG isn't opposed, then I would suggested adding this to the NMDA FAQ.
> 
> Thanks,
> Rob
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Thu Sep 21 08:59:18 2017
Return-Path: 
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 62EB7132D53 for ; Thu, 21 Sep 2017 08:59:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 X2sNm0l_fnyK for ; Thu, 21 Sep 2017 08:59:13 -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 F0BF4124F57 for ; Thu, 21 Sep 2017 08:59:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11902; q=dns/txt; s=iport; t=1506009553; x=1507219153; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=wruQJZuWsoGOqjoLqWBfSpmVRRrtpxuAbD9LMpvmNIQ=; b=ARmtdSao5/mxLrCzlmw5GaPU7eyirAB2fl4cJ7Z9+n4+wpBYJwpdI+TN fecayEm/P3H8HZ5uUnoACw24OwfQegsMNau3QSMAF8AEjln/t33EY1pSN cNNcz7mva/96bLrCy97P0sEfOQiIu+Tw39MmAFTgt/ZX9Vi/xhxiReglo 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CSAAC+4MNZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD5uJ4N2iiB0kFArliqCEgoYDYRHTwKEUxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQEBAQIBAQEhDwEFDycbCQISBgICJgICJyIOBgEMBgIBAReKEAgQiWOdZoIng?= =?us-ascii?q?z+HRAEBAQEBAQEBAgEBAQEBAQEBAQEBGAWBDoIdg1OBZCuCfYRlgymCYAWKFwy?= =?us-ascii?q?HFIFojXSHXYx7ghOFa4NaJIcCjWaHWIE5HziBDTIhCBwVSYcdPzaGfyuCFQEBA?= =?us-ascii?q?Q?=
X-IronPort-AV: E=Sophos;i="5.42,425,1500940800"; d="scan'208";a="697361687"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Sep 2017 15:59:10 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8LFx9US006002; Thu, 21 Sep 2017 15:59:09 GMT
To: Ladislav Lhotka , netmod@ietf.org
References: <393d3f20-98e3-b4de-e2d7-d627de59ac1f@labn.net> <1505814417.5445.14.camel@nic.cz> <20170919.115915.1668734288988659917.mbj@tail-f.com> <87shfistam.fsf@nic.cz> <75221540-d587-cd90-60ab-7cf6a8ff5cd4@cisco.com> <1505830045.5445.47.camel@nic.cz> <4ec007bc-6eb6-38f9-562e-ce9d0b4e1c00@cisco.com> <87mv5p783v.fsf@nic.cz> <9e3e2d36-f99e-aa9c-844a-d61b3ca20213@cisco.com> <1506006652.6428.57.camel@nic.cz>
From: Robert Wilton 
Message-ID: 
Date: Thu, 21 Sep 2017 16:59:09 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <1506006652.6428.57.camel@nic.cz>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Sep 2017 15:59:17 -0000

On 21/09/2017 16:10, Ladislav Lhotka wrote:
> Robert Wilton píše v Čt 21. 09. 2017 v 10:38 +0100:
>> On 20/09/2017 15:33, Ladislav Lhotka wrote:
>>> Robert Wilton  writes:
>>>
>>>> On 19/09/2017 15:07, Ladislav Lhotka wrote:
>>>>> Robert Wilton píše v Út 19. 09. 2017 v 14:49 +0100:
>>>>>> Hi Lada,
>>>>>>
>>>>>>
>>>>>> On 19/09/2017 14:37, Ladislav Lhotka wrote:
>>>>>>> Martin Bjorklund  writes:
>>>>>>>
>>>>>>>> Ladislav Lhotka  wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I support the adoption but I propose two conceptual changes:
>>>>>>>>>
>>>>>>>>> 1. Introduce a new module name and namespace so that it is not
>>>>>>>>> necessary to carry along the deprecated baggage. If readability
>>>>>>>>> is
>>>>>>>>> the primary concern, this is IMO the way to go. Instead of
>>>>>>>>> "ietf-ip-2", I'd suggest something like "ietf- ip-nmda".
>>>>>>>>>
>>>>>>>>> 2. Avoid obsoleting RFC 7277. I believe the old modules may
>>>>>>>>> continue
>>>>>>>>> to be used
>>>>>>>>> in areas where NMDA is an overkill, such as open source home
>>>>>>>>> routers.
>>>>>>>> Why wouldn't NMDA be appropriate in an open source home
>>>>>>>> router?  Note
>>>>>>>> that the new model really just have a single tree instead of two
>>>>>>>> trees, so the data that needs to be instrumented is more or less
>>>>>>>> the
>>>>>>>> same.
>>>>>>> It is quite likely that some parts of the data models will be
>>>>>>> implemented only as configuration but not state data. In the "old
>>>>>>> style"
>>>>>>> modules it is easy to add a deviation for the node(s) under -state
>>>>>>> but
>>>>>>> in NMDA style this is not possible because we only have one node.
>>>>>> The new YANG library allows different sets of modules to be available
>>>>>> for  datastores vs .   The operational
>>>>>> datastore can also have different features supported and different
>>>>>> deviations vs the conventional datastores.
>>>>> OK, I missed the 7895bis draft, sorry. Then there could be differences
>>>>> in
>>>>> mandatory/optional (e.g. a node is optional in configuration but
>>>>> mandatory in
>>>>> state data) or the data type of a leaf can differ. How can these be
>>>>> handled?
>>>> If the data type of the leaf can differ, then normally this should be
>>>> modeled as two separate leaves.  Do you have a concrete example of
>>>> this?
>>> So, for example, duplex and duplex-state? And  will
>>> have both as siblings?
>> Here I presume you are thinking that the configurable value for duplex
>> is "full/half/auto", but the operational value is "full/half"?
>>
>> The solution here is really to model auto-negotiation on/off as a
>> separate leaf (which also more closely reflects the actual behaviour of
>> the auto-negotiation protocol).  Then for duplex both the space for both
>> the configured and operational leaves are the same, i.e. both taking
>> "full/half", and hence only a single leaf is required to model both the
>> optional configured value and the operational value.
> Yes, this sounds reasonable. Here also the config value should then be optional
> while the state value mandatory.
I think that this would mean that lots of "config false" leaves should 
be marked mandatory.  But looking at the YANG models going through IETF 
standardization that doesn't seem to be the case.

Perhaps a very simple device doesn't have the capability to report 
duplexity because it is always full duplex, hence mandatory seems less 
useful.  Or a device might be able to report duplexicty but not at that 
instant in time (e.g. perhaps the optics module is missing)?  It seems 
more natural for operational to say that if you don't know something 
then don't return it.

So, I wouldn't support marking this field as being mandatory in 
 regardless of model structure.

>> A concrete example of the Ethernet interface YANG structured this way is @
>> https://github.com/8023YangDesignTeam/EthernetYang/blob/nmda/standard/ieee/802
>> .3/draft/ieee802-ethernet-interface.yang
>>
>>
>>
>>>> If some data is mandatory in config, but not necessarily mandatory in
>>>>  then normally it can be marked as mandatory true, since
>>>> optional is allowed to violate this constraint if necessary, but
>>>> implementations would generally be expected to conform to the constraint
>>>> if possible.
>>>>
>>>> For the reverse case, we can't express that.  I think that you would
>>>> have to leave out the "mandatory: true" constraint.  Again, can you
>>>> provide a concrete example of this please?  That makes it a bit easier
>>>> to reason about.
>>> This should be quite typical: a config leaf is optional and if it is not
>>> configured, the system sets it to some value (as in the case of
>>> router-id). But in state data it is mandatory so that the client can see
>>> what the system chose.
>> Yes, I agree that this scenario is very likely, but I think that the
>> solution here is just to not mark the leaf as mandatory.
> But this makes the schema weaker, and implementors may think it needn't be
> implemented.
I think that implementations SHOULD implement everything in the schema 
and use deviations if they don't.

>
>> It is interesting to consider what "mandatory" exactly means in the
>>  datastore.  Given that the mandatory constraint may be
> Yes, the semantics in the context of NM protocols is different from that of
> configuration datastores. But in the context of document (data tree) validation
> it is the same: the instance has to be present for a data tree to be valid.
Yes, the NMDA architecture states that the  tree may not be 
valid.  There are several reasons why  might not be valid, 
a few that I can think of are:
(1) The system is constant changing, and the device isn't able to 
provide a consistent snapshot across the entire device (e.g. on a 
distribute platform the FIBs on the LC may lag behind the RIB on the RP).
(2) The system might be in the middle of a config change at the time 
that  is read meaning that either the device would have to 
prevent  from being read until the config change had 
completed, or alternatively accept that it may provide an inconsistent view.
(3) There may be bugs or errors in the implementation.  They may have 
been a failure to program the hardware that means the state between 
different parts of the system is not consistent.

>
>> violated in , then my interpretation is that it means that
>> a correct implementation SHOULD always return a mandatory node (if it is
>> in scope).  But a client has no way to force a device return this data
>> (except perhaps shouting at the vendor :-), and so it seems that a
>> robust client would need to be able to cope with the fact that the
>> device is not behaving nicely and isn't returning the data regardless of
>> any mandatory keyword specified in the schema.
> I don't really share this view, it is IMO not much different from the situation
> when a vendor fails to implement a config node. Either way, the implementation
> doesn't conform to the data model.
The difference is that a device can reject an invalid config.  A client 
cannot reject an inconsistent state tree.  Perhaps it could choose to 
ignore it, but I'm not sure that helps.  I think that the client 
probably just has to cope with what is there.

>
> One of the benefits of a data model is that an application can offload
> validation to an external tool, such as a generic YANG library, and then can
> rely on data being valid so that the application's code needn't be cluttered
> with all kinds of sanity checks.
Yes, if there is data missing then I think that such a tool might need 
to prune the operational tree provided to the application code, or 
perhaps annotate the tree with additional metadata flags the 
inconsistencies.

>
> I can imagine a tool collecting data from a number of devices that fails if a
> mandatory state data are absent.
I think that the tool needs a plan B.  E.g. perhaps if the interface is 
admin-down then it doesn't matter whether or not the duplex setting has 
been provided by the device.

>    
>
>> To further expand on this, a device is required to ensure that
>> configuration datastores are valid, and hence all mandatory constraints
>> are enforced, or a config change would be rejected, but I don't think
>> that many devices are going to validate operational. They will just
>> return the current state of the system back to the client, and let the
>> client deal with any unexpected inconsistencies.
> I could likewise expect the server to be prepared to deal with unexpected
> inconsistencies in config data. The data model is a contract, so it should be
> binding for both parties.
But the server is allowed to just reject the change with an error. It 
isn't possible to reject the response to a  request.

>
>> Also, what about all the regular config false nodes in the schema that
>> are not marked as mandatory?  Is a device always required to return
>> those leaves (if they are in scope)?  If a device is never going to
> In terms of YANG, no.
So, should a device deviate config false leaves that it will never return?

>
>> return those leaves then it should use a deviation to remove them, but
>> is that actually required?
>>
>> Is seems that possibly the most useful use of mandatory in the context
>> of operational is for something like an IP address/prefix length
>> pairing, i.e. to indicate that the data really doesn't make any sense
>> unless both address and prefix are provided.
>>
>> When the next version of YANG is specified, perhaps we should consider
>> allowing an extra options to mandatory to that it only applies to the
>> state datastores?  if so, we could add this to the YANG.Next issue tracker?
> I believe the fundamental problem is that YANG was designed basically as a
> document-oriented schema language, and NMDA tries to make the same schema work
> for multiple different data trees. I am concerned this means a lot of complexity
>   and CLRs that will render the next version unusable.
OK.

But I'm not convinced that this is really much of an issue in practice.  
I've looked at converting quite a few YANG models either from an OC like 
structure, or IETF split structure to a combined NMDA tree (* list 
below).  In most cases, the models between config and state have been 
very closely aligned such that the config and state nodes are trivially 
identical.  In the cases that they differ (e.g. boolean vs empty), or a 
slight structure change, they have been pretty straight forward to 
resolve.  When the operational structure really differs from the 
configured structure then this can be represented using addition config 
false nodes (when doing the conversion on the models below, I don't 
recall having to add any extra config false leaves).

* By a few YANG modules I mean IETF draft/standard YANG modules for: 
interfaces, ip, routing, vrrp, rip, bgp, network, network-topology, te, 
te-topology, mpls, mpls-ldp, mpls-static, rsvp, rsvp-te, te-device, 
sr-topology, te-mpls, te-path-computation, te-service, transport services.

Thanks,
Rob


>
> Lada
>
>> So, in conclusion, I think that the NMDA modelling advice for mandatory
>> on config true nodes might be to only use it when the node is mandatory
>> in configuration datastores.
>>
>> If the WG isn't opposed, then I would suggested adding this to the NMDA FAQ.
>>
>> Thanks,
>> Rob
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod


From nobody Thu Sep 21 10:29:35 2017
Return-Path: 
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 A3A94127517 for ; Thu, 21 Sep 2017 10:29:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rq9Ug0a4DsfA for ; Thu, 21 Sep 2017 10:29:32 -0700 (PDT)
Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.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 64384126E64 for ; Thu, 21 Sep 2017 10:29:32 -0700 (PDT)
X-AuditID: c618062d-b93ff70000004f0a-58-59c40f3a3aa3
Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 1C.11.20234.A3F04C95; Thu, 21 Sep 2017 21:12:59 +0200 (CEST)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0352.000; Thu, 21 Sep 2017 13:29:30 -0400
From: David Sinicrope 
To: "netmod@ietf.org" 
Thread-Topic: Broadband Forum NMDA Questions
Thread-Index: AQHTMv8uhuM0z33d0UW4R/qSzhNqyw==
Date: Thu, 21 Sep 2017 17:29:30 +0000
Message-ID: <3B4C29A3-961C-405B-86DB-5050A90301A8@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.26.0.170902
x-originating-ip: [147.117.188.11]
Content-Type: multipart/alternative; boundary="_000_3B4C29A3961C405B86DB5050A90301A8ericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyuXRPuK41/5FIg+YTjBbzLzayOjB6LFny kymAMYrLJiU1J7MstUjfLoErY/tSmYLVahVrDjSzNTBOU+1i5OSQEDCR2HCmm6mLkYtDSOAo o0T7758sEM5yRonjL/awgVSxAVWt27iHBcQWEVCXmLlzPVhcGMg+tG02UJwDKK4j8fKZCkSJ nsSEjzeYQWwWAVWJBTPPMILYvAL2El/nnGAHsRkFxCS+n1rDBGIzC4hL3HoynwniIAGJJXvO M0PYohIvH/9jBRkvCjSz/X8tRFhJ4uPv+ewQrckSq04sYYEYLyhxcuYTlgmMQrOQTJ2FpGwW krJZQFOZBTQl1u/ShyhRlJjS/ZAdwtaQaJ0zF8q2lng8/ScLspoFjByrGDlKiwtyctONDDYx AmPhmASb7g7G+9M9DzEKcDAq8fCmcR2JFGJNLCuuzD3EKMHBrCTCe+zt4Ugh3pTEyqrUovz4 otKc1OJDjNIcLErivBPOX4gQEkhPLEnNTk0tSC2CyTJxcEo1MMqfPB+dlGu+17OffYW6psmM dQkzWxk8Y7TPWVzSa1z/QXA/Y/Pjh//Ytp/9f5R1jn2//8FpDyyDl+tmi4Wty2gJfH3WLFDy WMsT+9U3A85mREqoHnNbc6zvwdUO151JbwIulTPZTDnB6tybujqC6VE+z0sxg9z137bcXdOT 8fz7aYkViesPblNiKc5INNRiLipOBACLzqccgQIAAA==
Archived-At: 
Subject: [netmod] Broadband Forum NMDA Questions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Sep 2017 17:29:34 -0000

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

aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzE1NDQvDQoNCkhpIEFsbCwNClRo
ZSBkYXRhdHJhY2tlciBlbnRyeSBmb3IgdGhlIHN1YmplY3QgbGlhaXNvbiByZXF1ZXN0cyBhIHJl
c3BvbnNlIGJ5IE5vdiAyNyB3aGljaCBpcyB0aGUgd2VlayBiZWZvcmUgdGhlIDRRMjAxNyBCQkYg
bWVldGluZy4NCg0KSG93ZXZlciwgdGhlIEJCRiBncm91cCByZXF1ZXN0aW5nIHRoZSByZXNwb25z
ZSBoYXMgYSBjb25mZXJlbmNlIGNhbGwgTm92IDIxIChNb25kYXkgYWZ0ZXIgU2luZ2Fwb3JlKS4N
CklmIHRoZXJlIGlzIGFueSB3YXkgdG8gZ2V0IGEgcmVzcG9uc2UgZm9yIHRoYXQgY2FsbCwgSeKA
mW0gc3VyZSB0aGV5IHdvdWxkIGdyZWF0bHkgYXBwcmVjaWF0ZSBpdC4NCg0KRGF2ZSBTaW5pY3Jv
cGUNCkJCRi9JRVRGIExpYWlzb24gTWFuYWdlcg0KDQo=

--_000_3B4C29A3961C405B86DB5050A90301A8ericssoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: <99BE93E491D1894ABF2E030094785BAD@ericsson.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z
by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1
bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl
cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29t
cG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0
ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1z
dHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9
DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh
bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4
LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk
U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxi
b2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5
NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFj
a2VyLmlldGYub3JnL2xpYWlzb24vMTU0NC8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv
bGlhaXNvbi8xNTQ0LzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQiPkhpIEFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhlIGRhdGF0cmFja2VyIGVudHJ5IGZvciB0
aGUgc3ViamVjdCBsaWFpc29uIHJlcXVlc3RzIGEgcmVzcG9uc2UgYnkgTm92IDI3IHdoaWNoIGlz
IHRoZSB3ZWVrIGJlZm9yZSB0aGUgNFEyMDE3IEJCRiBtZWV0aW5nLjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SG93ZXZlciwgdGhlIEJCRiBncm91cCByZXF1ZXN0
aW5nIHRoZSByZXNwb25zZSBoYXMgYSBjb25mZXJlbmNlIGNhbGwgTm92IDIxIChNb25kYXkgYWZ0
ZXIgU2luZ2Fwb3JlKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SWYgdGhlcmUgaXMgYW55IHdheSB0byBn
ZXQgYSByZXNwb25zZSBmb3IgdGhhdCBjYWxsLCBJ4oCZbSBzdXJlIHRoZXkgd291bGQgZ3JlYXRs
eSBhcHByZWNpYXRlIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dCI+RGF2ZSBTaW5pY3JvcGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QkJGL0lFVEYgTGlhaXNvbiBNYW5h
Z2VyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_3B4C29A3961C405B86DB5050A90301A8ericssoncom_--


From nobody Thu Sep 21 10:59:44 2017
Return-Path: 
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 5DA64132355 for ; Thu, 21 Sep 2017 10:59:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOvrh3Nlv12x for ; Thu, 21 Sep 2017 10:59:39 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FCCB13219F for ; Thu, 21 Sep 2017 10:59:39 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 099546AA; Thu, 21 Sep 2017 19:59:37 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id x4oZ-ERwTHfE; Thu, 21 Sep 2017 19:59:35 +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 atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 21 Sep 2017 19:59:36 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id DDC2C200F4; Thu, 21 Sep 2017 19:59:36 +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 Wu0AWdx2CLBk; Thu, 21 Sep 2017 19:59:36 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8FE0B200F1; Thu, 21 Sep 2017 19:59:36 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 892124110716; Thu, 21 Sep 2017 19:59:35 +0200 (CEST)
Date: Thu, 21 Sep 2017 19:59:35 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Cc: netmod@ietf.org
Message-ID: <20170921175935.t7gvwswbwijbcxxt@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org
References: <393d3f20-98e3-b4de-e2d7-d627de59ac1f@labn.net> <1505814417.5445.14.camel@nic.cz> <20170919.115915.1668734288988659917.mbj@tail-f.com> <87shfistam.fsf@nic.cz> <75221540-d587-cd90-60ab-7cf6a8ff5cd4@cisco.com> <1505830045.5445.47.camel@nic.cz> <4ec007bc-6eb6-38f9-562e-ce9d0b4e1c00@cisco.com> <87mv5p783v.fsf@nic.cz> <9e3e2d36-f99e-aa9c-844a-d61b3ca20213@cisco.com> <1506006652.6428.57.camel@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1506006652.6428.57.camel@nic.cz>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Sep 2017 17:59:41 -0000

On Thu, Sep 21, 2017 at 05:10:52PM +0200, Ladislav Lhotka wrote:
> 
> I can imagine a tool collecting data from a number of devices that fails if a
> mandatory state data are absent.  
>

This is not a very robust tool. There are other reasons why a leaf may
be absert, e.g., an access control rule. In general, there is no
requirement that state data is reported as consistent snapshots, so
robust tools will have to be somewhat tolerant anyway.

> I could likewise expect the server to be prepared to deal with unexpected
> inconsistencies in config data. The data model is a contract, so it should be
> binding for both parties.

The server is prepared; it fails the commit if configuration data is
unexpectedly inconsistent.

/js

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


From nobody Fri Sep 22 02:03:22 2017
Return-Path: 
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 37F1113320C; Fri, 22 Sep 2017 02:03:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 Ef3s2Fe9m-9n; Fri, 22 Sep 2017 02:03:16 -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 EEA031329B5; Fri, 22 Sep 2017 02:03:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11723; q=dns/txt; s=iport; t=1506070996; x=1507280596; h=subject:from:to:cc:references:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=m0fY1RkjIgbC5xpiSseRuJGMESvg0WA5Z0xZWRZ4Trg=; b=mA21nhoQxjBRBPp9WbGwYwm6jVIvITc1E3ZgsHRvUEKkW0OCZutF+qqb S5+m2SIbC7yYaxeG+c0kqKe2yMaxb/aeipiBr6IqRW25AkXNe/R4Kvew+ +OaBexPsZHX4mOrU/Ps9d8fnDfPBoUFDOHguwvin8o7UEJ2iMi9ySjM1b A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B6AQCK0cRZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhSwng3aLFJBQK3mVMA6CBAqFOwKEYBYBAgEBAQEBAQFrKIUZAQU?= =?us-ascii?q?jDwEFOgcQCQIOAgIGAgIREgMCAkYDDgYBDAYCAQEXihiJKp1mgieLAgEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEfgQ6CHYNTgWQrC4I9NYQ2LQICU4JUgmAFoROUWIITiUU?= =?us-ascii?q?khwKKBYNhh1iBOSYFLEFMMiEIHBWHZj82iRYBAQUfB4IVAQEB?=
X-IronPort-AV: E=Sophos;i="5.42,427,1500940800"; d="scan'208";a="657676664"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Sep 2017 09:03:10 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8M939QG025155; Fri, 22 Sep 2017 09:03:09 GMT
From: Robert Wilton 
To: Martin Bjorklund , andy@yumaworks.com, netmod@ietf.org
Cc: j.schoenwaelder@jacobs-university.de, ietfc@btconnect.com, lberger@labn.net, draft-ietf-netmod-revised-datastores@ietf.org
References: <20170918.200734.1805388289423863575.mbj@tail-f.com>  <99b9a2c6-4bb4-121f-0cba-925cefe09712@cisco.com> <20170919.115559.1080249872764998055.mbj@tail-f.com> 
Message-ID: <5481ac35-c789-0796-36f6-8a02a5ebef8c@cisco.com>
Date: Fri, 22 Sep 2017 10:03:09 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod]  vs 
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Sep 2017 09:03:19 -0000

Hi,

Regarding whether  is always valid, the proposed modification 
to the draft is to add the following text to section 4.3 that describes 
:

OLD:

4.3.  The Running Configuration Datastore ()

    The running configuration datastore () holds the complete
    current configuration on the device.  It may include inactive
    configuration or template-mechanism-oriented configuration that
    require further expansion.

    If a device does not have a distinct  and non-volatile is
    available, the device will typically use that non-volatile storage to
    allow  to persist across reboots.

NEW:

4.3.  The Running Configuration Datastore ()

    The running configuration datastore () holds the complete
    current configuration on the device.  This could, for example, include
    inactiveconfiguration or template-mechanism-oriented configuration
    thatrequires further expansion.However,  must always be a
    'valid configuration data tree' as defined in Section 8.1 of [RFC7950].

    If a device does not have a distinct  and non-volatile is
    available, the device will typically use that non-volatile storage to
    allow  to persist across reboots.

END


Then the intention is that if inactive or a templating solution is 
standardized then those drafts would update the validation rules in RFC 
7950 such that  is still valid.  E.g. an inactive config draft 
would probably indicate that validation excludes all configuration nodes 
that are marked as inactive.

Does anyone have any comments?

Do we also need to state that  must always be a 'valid 
configuration data tree'?

Thanks,
Rob


On 19/09/2017 16:22, Robert Wilton wrote:
>
>
> On 19/09/2017 10:55, Martin Bjorklund wrote:
>> Robert Wilton  wrote:
>>>
>>> On 18/09/2017 19:25, Andy Bierman wrote:
>>>>
>>>> On Mon, Sep 18, 2017 at 11:07 AM, Martin Bjorklund >>> > wrote:
>>>>
>>>>      Juergen Schoenwaelder >>>      > wrote:
>>>>      > On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert Wilton wrote:
>>>>      > >
>>>>      > > > No.  I do not agree that the MUST in RFC 7950 can be 
>>>> removed.
>>>>      > > > I do not agree the architecture should update YANG at all.
>>>>      > > OK.
>>>>      >
>>>>      > I am with Andy here.  has always had the 
>>>> requirement to be
>>>>      > valid and we are not supposed to change that. Mechanisms for
>>>>      inactive
>>>>      > configuration or templating must be designed to be backwards
>>>>      compatible
>>>>      > I think.
>>>>
>>>>      Ok.  If we keep the requirement that  in itself must be
>>>>      valid, it just restricts the usefulness/expressiveness of 
>>>> inactive and
>>>>      template mechanisms, but it might be ok.
>>>>
>>>>      I think that even w/o this requirement, the observable 
>>>> behavior for a
>>>>      client can be backwards compatible.  For example, suppose we 
>>>> have an
>>>>      inactive access control rule that refers to a non-existing
>>>>      interface in
>>>>      .  If a client that doesn't know anything about 
>>>> inactive asks
>>>>      for the contents of , our implementation removes the 
>>>> inactive
>>>>      nodes from the reply to the client.  Only a client that 
>>>> opts-in to
>>>>      inactive will receive a reply with things that looks invalid 
>>>> if you
>>>>      don't take the inactive annotation into account.
>>>>
>>>>
>>>>
>>>> There are many ways that validation can fail because inactive nodes
>>>> are present,
>>>> and considered part of the validation.
>>>>
>>>> e,g, min-elements, max-elements, mandatory, unique.
>>>>
>>>> I think we all agree that validation on the enabled nodes is supposed
>>>> to continue to work.
>> Yes.
>>
>>>> Here is an attempt at a backwards-compatible solution:
>>>>
>>>> 1) current  and  responses only include enabled
>>>> nodes.
>>>> 2) old-style  operations do not alter inactive nodes
>>>> 3) NMDA clients use , not  or .  These
>>>> responses
>>>>      include enabled and disabled nodes, so validation does not apply
>>>> for 
>>>> 4) new style  (i.e.  parameter used) can alter
>>>> any type of data node
>>> //I think that inactive should always be an optional extension.  Not
>>> everything needs the additional complexity.
>>>
>>> Hence rather than tying this function to specific NETCONF operations,
>>> I would suggest that there should be an extra parameter (like for
>>> with-defaults) to allow a client to indicate to the server that a get
>>> or edit request is using the "with-inactive" extension.
>>> 1) The server should also have a capability (or perhaps a leaf defined
>>> in YANG library) to indicate that it supports inactive configuration.
>>> 2) If a client doesn't use the extra "with-inactive" parameter during
>>> a get request then only active nodes are returned.
>>> 3) If a client doesn't use the extra "with-inactive" parameter during
>>> an edit-data request then the request cannot include an extra inactive
>>> meta-data.  The request is processed in a way that is equivalent to an
>>> existing NETCONF implementation, but it may unknowingly remove some
>>> inactive configuration (e.g. via a replace or remove operation on an
>>> inactive node).  Operations like create, delete, none, replace should
>>> all treat an inactive target node the same way as in the node doesn't
>>> exist (e.g. delete on an inactive node would return a "data-missing"
>>> error), this ensures that the behaviour that an unaware client
>>> observes is the same as the existing behaviour that it would expect
>>> from a regular 6241 compliant NETCONF implementation.
>>> 4) It a client makes a get request including the "with-inactive"
>>> parameter then they also get the inactive nodes as well, marked with a
>>> meta-data annotation.
>>> 5) If a client makes an edit request including the "with-inactive"
>>> parameter, then the inactive meta-data annotation can be used to label
>>> inactive nodes.  Inactive nodes are regarded as regular data nodes for
>>> create/delete/replace/none operation error checking.
>>>
>>> I think that this approach is similar (perhaps even the same) as
>>> Martin described.
>> This is indeed how our implementation works (except I think we don't
>> do 5; if the client sends an "inactive" attribute it doesn't have to
>> also send with-inactive).
>>
>>>> Note that the YANG MUST rule still applies, because validation is only
>>>> done on enabled nodes.
>>>> It is only the response message representations that cannot be
>>>> validated, not the contents
>>>> of  on a server.
>> So the question is how we can make sure that the text in the NMDA
>> draft covers this yet-to-be-defined feature w/o having to define it
>> now?  We thought that the current text was sufficient, but do we have
>> to make any changes to it?
> 1) Do we also need to illustrate a similar proof of concept templating 
> implementation to show that templating could work whilst keeping 
> running valid?  I would prefer that this is just deferred to whichever 
> draft defines templating.
>
> 2) I think that we need to reach a decision as to whether the NMDA 
> architecture needs to explicitly state that  is always valid, 
> or if that can be left to the existing statement in 7950.  My thinking 
> is that if the conclusion is that  must always be valid, then 
> it would be helpful to explicitly state it the descriptions of both 
>  and  in the NMDA architecture.
>
> 3) I think that it would be useful to further refine my previous 
> proposed text for intended, particularly rewriting the text on 
> validation.  This should hopefully also address Balazs' concern about 
> default values be included in validation.
>
> 
>
> 4.4.  The Intended Configuration Datastore ()
>
>    The intended configuration datastore () is a read-only
>    configuration datastore.  It is tightly coupled to .  When
>    data is written to , the data that is to be validated is
>    also conceptually written to . Validation is performed on
>    the contents of .
>
>    For simple implementations,  and  are identical.
>
>     does not persist across reboots; its relationship with
>     makes that unnecessary.
>
>    Currently there are no standard mechanisms defined that affect
>     so that it would have different contents than ,
>    but this architecture allows for such mechanisms to be defined.
>
>    One example of such a mechanism is support for marking nodes as
>    inactive in .  Inactive nodes are not copied to ,
>    and are thus not taken into account when validating the
>    configuration.
>
>    Another example is support for templates.  Templates are expanded
>    when copied into , and the expanded result is validated.
>
> 
> 
>
> 4.1.4.  The Intended Configuration Datastore ()
>
>    The intended configuration datastore () is a read-only
>    configuration datastore.  It represents the configuration after all
>    configuration transformations to  are performed (e.g.
>    template expansion, removal of inactive configuration), and is the
>    configuration that the system attempts to apply.
>
>     is tightly coupled to . Whenever data is written
>    to , then  is also immediately updated by
>    performing all necessary transformations to the contents of 
>    and then  is validated.
>
>     may also be updated independently of  (e.g., if
>    one of the configuration transformations is changed), but 
>    must always be a 'valid configuration data tree' as defined in
>    Section 8.1 of [RFC7950].
>
>    For simple implementations,  and  are identical.
>
>    The contents of  is also related to the 'config true'
>    subset of , and hence a client can determine to what
>    extent the intended configuration is currently in use by checking
>    whether the contents of  also appears in .
>
>     does not persist across reboots; its relationship with
>     makes that unnecessary.
>
>    Currently there are no standard mechanisms defined that affect
>     so that it would have different contents than ,
>    but this architecture allows for such mechanisms to be defined.
>
>    One example of such a mechanism is support for marking nodes as
>    inactive in .  Inactive nodes are not copied to .
>    A second example is support for templates, which can perform
>    transformations on the configuration from  to the
>    configuration written to .
>
> 
>
> Thanks,
> Rob
>
>
>>
>>
>> /martin
>> .
>>
>
> .
>


From nobody Fri Sep 22 05:01:18 2017
Return-Path: 
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 A643C1342D1 for ; Fri, 22 Sep 2017 05:01:14 -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 5z2tgxwRU8p1 for ; Fri, 22 Sep 2017 05:01:11 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id B5847133344 for ; Fri, 22 Sep 2017 05:01:10 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id 95B3E1820E77; Fri, 22 Sep 2017 14:00:24 +0200 (CEST)
Received: from localhost (unknown [195.113.220.126]) by trail.lhotka.name (Postfix) with ESMTPSA id C29B81820E71; Fri, 22 Sep 2017 14:00:20 +0200 (CEST)
From: Ladislav Lhotka 
To: Robert Wilton , netmod@ietf.org
In-Reply-To: 
References: <393d3f20-98e3-b4de-e2d7-d627de59ac1f@labn.net> <1505814417.5445.14.camel@nic.cz> <20170919.115915.1668734288988659917.mbj@tail-f.com> <87shfistam.fsf@nic.cz> <75221540-d587-cd90-60ab-7cf6a8ff5cd4@cisco.com> <1505830045.5445.47.camel@nic.cz> <4ec007bc-6eb6-38f9-562e-ce9d0b4e1c00@cisco.com> <87mv5p783v.fsf@nic.cz> <9e3e2d36-f99e-aa9c-844a-d61b3ca20213@cisco.com> <1506006652.6428.57.camel@nic.cz> 
Mail-Followup-To: Robert Wilton , netmod@ietf.org
Date: Fri, 22 Sep 2017 14:01:46 +0200
Message-ID: <87efqzdjrp.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Sep 2017 12:01:15 -0000

Robert Wilton  writes:

> On 21/09/2017 16:10, Ladislav Lhotka wrote:
>> Robert Wilton p=C3=AD=C5=A1e v =C4=8Ct 21. 09. 2017 v 10:38 +0100:
>>> On 20/09/2017 15:33, Ladislav Lhotka wrote:
>>>> Robert Wilton  writes:
>>>>
>>>>> On 19/09/2017 15:07, Ladislav Lhotka wrote:
>>>>>> Robert Wilton p=C3=AD=C5=A1e v =C3=9At 19. 09. 2017 v 14:49 +0100:
>>>>>>> Hi Lada,
>>>>>>>
>>>>>>>
>>>>>>> On 19/09/2017 14:37, Ladislav Lhotka wrote:
>>>>>>>> Martin Bjorklund  writes:
>>>>>>>>
>>>>>>>>> Ladislav Lhotka  wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I support the adoption but I propose two conceptual changes:
>>>>>>>>>>
>>>>>>>>>> 1. Introduce a new module name and namespace so that it is not
>>>>>>>>>> necessary to carry along the deprecated baggage. If readability
>>>>>>>>>> is
>>>>>>>>>> the primary concern, this is IMO the way to go. Instead of
>>>>>>>>>> "ietf-ip-2", I'd suggest something like "ietf- ip-nmda".
>>>>>>>>>>
>>>>>>>>>> 2. Avoid obsoleting RFC 7277. I believe the old modules may
>>>>>>>>>> continue
>>>>>>>>>> to be used
>>>>>>>>>> in areas where NMDA is an overkill, such as open source home
>>>>>>>>>> routers.
>>>>>>>>> Why wouldn't NMDA be appropriate in an open source home
>>>>>>>>> router?  Note
>>>>>>>>> that the new model really just have a single tree instead of two
>>>>>>>>> trees, so the data that needs to be instrumented is more or less
>>>>>>>>> the
>>>>>>>>> same.
>>>>>>>> It is quite likely that some parts of the data models will be
>>>>>>>> implemented only as configuration but not state data. In the "old
>>>>>>>> style"
>>>>>>>> modules it is easy to add a deviation for the node(s) under -state
>>>>>>>> but
>>>>>>>> in NMDA style this is not possible because we only have one node.
>>>>>>> The new YANG library allows different sets of modules to be availab=
le
>>>>>>> for  datastores vs .   The operational
>>>>>>> datastore can also have different features supported and different
>>>>>>> deviations vs the conventional datastores.
>>>>>> OK, I missed the 7895bis draft, sorry. Then there could be differenc=
es
>>>>>> in
>>>>>> mandatory/optional (e.g. a node is optional in configuration but
>>>>>> mandatory in
>>>>>> state data) or the data type of a leaf can differ. How can these be
>>>>>> handled?
>>>>> If the data type of the leaf can differ, then normally this should be
>>>>> modeled as two separate leaves.  Do you have a concrete example of
>>>>> this?
>>>> So, for example, duplex and duplex-state? And  will
>>>> have both as siblings?
>>> Here I presume you are thinking that the configurable value for duplex
>>> is "full/half/auto", but the operational value is "full/half"?
>>>
>>> The solution here is really to model auto-negotiation on/off as a
>>> separate leaf (which also more closely reflects the actual behaviour of
>>> the auto-negotiation protocol).  Then for duplex both the space for both
>>> the configured and operational leaves are the same, i.e. both taking
>>> "full/half", and hence only a single leaf is required to model both the
>>> optional configured value and the operational value.
>> Yes, this sounds reasonable. Here also the config value should then be o=
ptional
>> while the state value mandatory.

> I think that this would mean that lots of "config false" leaves should=20
> be marked mandatory.=C2=A0 But looking at the YANG models going through I=
ETF=20
> standardization that doesn't seem to be the case.

Many of them have defaults that effectively mean that the leaves have to
be implemented. Otherwise the guarantees provided by the data model are
really weaker - there is no way to tell whether a given server will send
a parameter or not.

>
> Perhaps a very simple device doesn't have the capability to report=20
> duplexity because it is always full duplex, hence mandatory seems less

Then we have features and/or deviations to account for this.

> useful.=C2=A0 Or a device might be able to report duplexicty but not at t=
hat=20
> instant in time (e.g. perhaps the optics module is missing)?=C2=A0 It see=
ms=20
> more natural for operational to say that if you don't know something=20
> then don't return it.

Of course, transient effects need to be considered, and perhaps
statistics are also a bit special. But, for example, if an NM
application isn't able to learn actual router-id, it may be stuck.

>
> So, I wouldn't support marking this field as being mandatory in=20
>  regardless of model structure.
>
>>> A concrete example of the Ethernet interface YANG structured this way i=
s @
>>> https://github.com/8023YangDesignTeam/EthernetYang/blob/nmda/standard/i=
eee/802
>>> .3/draft/ieee802-ethernet-interface.yang
>>>
>>>
>>>
>>>>> If some data is mandatory in config, but not necessarily mandatory in
>>>>>  then normally it can be marked as mandatory true, since
>>>>> optional is allowed to violate this constraint if necessary, but
>>>>> implementations would generally be expected to conform to the constra=
int
>>>>> if possible.
>>>>>
>>>>> For the reverse case, we can't express that.  I think that you would
>>>>> have to leave out the "mandatory: true" constraint.  Again, can you
>>>>> provide a concrete example of this please?  That makes it a bit easier
>>>>> to reason about.
>>>> This should be quite typical: a config leaf is optional and if it is n=
ot
>>>> configured, the system sets it to some value (as in the case of
>>>> router-id). But in state data it is mandatory so that the client can s=
ee
>>>> what the system chose.
>>> Yes, I agree that this scenario is very likely, but I think that the
>>> solution here is just to not mark the leaf as mandatory.
>> But this makes the schema weaker, and implementors may think it needn't =
be
>> implemented.
> I think that implementations SHOULD implement everything in the schema=20
> and use deviations if they don't.

This is not what YANG says - the state data tree is valid without a paramet=
er
that is optional.

>
>>
>>> It is interesting to consider what "mandatory" exactly means in the
>>>  datastore.  Given that the mandatory constraint may be
>> Yes, the semantics in the context of NM protocols is different from that=
 of
>> configuration datastores. But in the context of document (data tree) val=
idation
>> it is the same: the instance has to be present for a data tree to be val=
id.
> Yes, the NMDA architecture states that the  tree may not be=
=20
> valid.=C2=A0 There are several reasons why  might not be val=
id,=20
> a few that I can think of are:
> (1) The system is constant changing, and the device isn't able to=20
> provide a consistent snapshot across the entire device (e.g. on a=20
> distribute platform the FIBs on the LC may lag behind the RIB on the RP).
> (2) The system might be in the middle of a config change at the time=20
> that  is read meaning that either the device would have to=20
> prevent  from being read until the config change had=20
> completed, or alternatively accept that it may provide an inconsistent vi=
ew.
> (3) There may be bugs or errors in the implementation.=C2=A0 They may hav=
e=20
> been a failure to program the hardware that means the state between=20
> different parts of the system is not consistent.
>
>>
>>> violated in , then my interpretation is that it means that
>>> a correct implementation SHOULD always return a mandatory node (if it is
>>> in scope).  But a client has no way to force a device return this data
>>> (except perhaps shouting at the vendor :-), and so it seems that a
>>> robust client would need to be able to cope with the fact that the
>>> device is not behaving nicely and isn't returning the data regardless of
>>> any mandatory keyword specified in the schema.
>> I don't really share this view, it is IMO not much different from the si=
tuation
>> when a vendor fails to implement a config node. Either way, the implemen=
tation
>> doesn't conform to the data model.
> The difference is that a device can reject an invalid config.=C2=A0 A cli=
ent=20
> cannot reject an inconsistent state tree.=C2=A0 Perhaps it could choose t=
o=20
> ignore it, but I'm not sure that helps.=C2=A0 I think that the client=20
> probably just has to cope with what is there.
>
>>
>> One of the benefits of a data model is that an application can offload
>> validation to an external tool, such as a generic YANG library, and then=
 can
>> rely on data being valid so that the application's code needn't be clutt=
ered
>> with all kinds of sanity checks.
> Yes, if there is data missing then I think that such a tool might need=20
> to prune the operational tree provided to the application code, or=20
> perhaps annotate the tree with additional metadata flags the=20
> inconsistencies.
>
>>
>> I can imagine a tool collecting data from a number of devices that fails=
 if a
>> mandatory state data are absent.
> I think that the tool needs a plan B.=C2=A0 E.g. perhaps if the interface=
 is=20
> admin-down then it doesn't matter whether or not the duplex setting has=20
> been provided by the device.

Of course, but this is business as usual. The problem I am talking about
is an interface that is up and running but the server fails to provide
important data.

>
>>=20=20=20=20
>>
>>> To further expand on this, a device is required to ensure that
>>> configuration datastores are valid, and hence all mandatory constraints
>>> are enforced, or a config change would be rejected, but I don't think
>>> that many devices are going to validate operational. They will just
>>> return the current state of the system back to the client, and let the
>>> client deal with any unexpected inconsistencies.
>> I could likewise expect the server to be prepared to deal with unexpected
>> inconsistencies in config data. The data model is a contract, so it shou=
ld be
>> binding for both parties.
> But the server is allowed to just reject the change with an error. It=20
> isn't possible to reject the response to a  request.

Either way, the NM application may fail, which defeats the purpose of
standardizing data models.

Lada

>
>>
>>> Also, what about all the regular config false nodes in the schema that
>>> are not marked as mandatory?  Is a device always required to return
>>> those leaves (if they are in scope)?  If a device is never going to
>> In terms of YANG, no.
> So, should a device deviate config false leaves that it will never return?
>
>>
>>> return those leaves then it should use a deviation to remove them, but
>>> is that actually required?
>>>
>>> Is seems that possibly the most useful use of mandatory in the context
>>> of operational is for something like an IP address/prefix length
>>> pairing, i.e. to indicate that the data really doesn't make any sense
>>> unless both address and prefix are provided.
>>>
>>> When the next version of YANG is specified, perhaps we should consider
>>> allowing an extra options to mandatory to that it only applies to the
>>> state datastores?  if so, we could add this to the YANG.Next issue trac=
ker?
>> I believe the fundamental problem is that YANG was designed basically as=
 a
>> document-oriented schema language, and NMDA tries to make the same schem=
a work
>> for multiple different data trees. I am concerned this means a lot of co=
mplexity
>>   and CLRs that will render the next version unusable.
> OK.
>
> But I'm not convinced that this is really much of an issue in practice.=
=C2=A0=20
> I've looked at converting quite a few YANG models either from an OC like=
=20
> structure, or IETF split structure to a combined NMDA tree (* list=20
> below).=C2=A0 In most cases, the models between config and state have been
> very closely aligned such that the config and state nodes are trivially=20
> identical.=C2=A0 In the cases that they differ (e.g. boolean vs empty), o=
r a=20
> slight structure change, they have been pretty straight forward to=20
> resolve.=C2=A0 When the operational structure really differs from the=20
> configured structure then this can be represented using addition config=20
> false nodes (when doing the conversion on the models below, I don't=20
> recall having to add any extra config false leaves).
>
> * By a few YANG modules I mean IETF draft/standard YANG modules for:=20
> interfaces, ip, routing, vrrp, rip, bgp, network, network-topology, te,=20
> te-topology, mpls, mpls-ldp, mpls-static, rsvp, rsvp-te, te-device,=20
> sr-topology, te-mpls, te-path-computation, te-service, transport services.
>
> Thanks,
> Rob
>
>
>>
>> Lada
>>
>>> So, in conclusion, I think that the NMDA modelling advice for mandatory
>>> on config true nodes might be to only use it when the node is mandatory
>>> in configuration datastores.
>>>
>>> If the WG isn't opposed, then I would suggested adding this to the NMDA=
 FAQ.
>>>
>>> Thanks,
>>> Rob
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>

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


From nobody Fri Sep 22 09:30:00 2017
Return-Path: 
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 8613C134533 for ; Fri, 22 Sep 2017 09:29:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.911
X-Spam-Level: 
X-Spam-Status: No, score=-2.911 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_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 J7lTbJg3h840 for ; Fri, 22 Sep 2017 09:29:51 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0138.outbound.protection.outlook.com [104.47.0.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F305B13452A for ; Fri, 22 Sep 2017 09:29:50 -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=d6wapbzQL9rxOYo/pqj7LQ26Gibs9zxpDWTX+LTGPwQ=; b=Sro4rQfVS7T27NsNuhpkIgt2GD37jaF8LNOn/364JdOEvth2zmO3/vfqFQjIGQbu0JV+x0gMe43JSAb+C4p8RVMwvnb9UH4B3juHcueg4yraOMxJpFUirqucM53krdCvKlbNOOSNXFl8Msrz5YQh9V4KmkG1KYK67g4L14aT2HI=
Received: from pc6 (109.146.128.123) by AM5PR0701MB2996.eurprd07.prod.outlook.com (2603:10a6:203:48::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Fri, 22 Sep 2017 16:29:48 +0000
Message-ID: <00bf01d333bf$c4fd96c0$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: 
References: <3B4C29A3-961C-405B-86DB-5050A90301A8@ericsson.com>
Date: Fri, 22 Sep 2017 17:27:56 +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: [109.146.128.123]
X-ClientProxiedBy: AM3PR07CA0128.eurprd07.prod.outlook.com (2603:10a6:207:8::14) To AM5PR0701MB2996.eurprd07.prod.outlook.com (2603:10a6:203:48::18)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: fcd606f0-49d6-485b-4e35-08d501d72472
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM5PR0701MB2996; 
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2996; 3:9M5oYgWBjK6KSBjCBjAPHwhL7iAdJ96gaUyVrdO3t5GXXcsvgBJIp9uxjX+m/5xhZHqRm1AGpsu8X1qmLeQ19OlTPp2wijLqgM+mC3rVhlfO8Ol76oVfMjpJOrWYYfvMmUJEpMd6nmM/qNi56sBJRylEzPzu1qtfqbSi+v9Z9J9YsNzUaGdT7G9F5QG4739ViziCnm2ztdkyyXqSERBQ1ZoZ1kEFboCPeHwCcXMxIdFfX+BhXOr70B+Qb5DOoot+; 25:EH+jBXth6f65QVPpx/kcIXJ1lUkHMQU7o1I2/bV5yRvrI0OQFLUmd8m4rxsw8LTKJQaCfDFRcnr4C0M207LYWU+ko9K1D856Br1YgCsZEgsjhXj0gfQfa/XVLmmx4u19D/vRwPZvOm5/j2KKZQ5YDuJQEF0j+Cg3JFbMFXSIntIzJgVUcI6Ff9+c7LUbCh5cgdQFUStDuipKow6SMMjAG6EwWnSQMWMViz3VbqvIEdlCUcUIPvzLHh5fNAKYjzcD4+f219IasZMifGrZVFlYyE4BgNEnP45r2WwvcbAip5GKLr1R+i2r1NlqMzK7OyC67dURsEI5uC+BLdGacA+Mig==; 31:YINQRDGbplKP/SlVe4Gw1iri9gKJ8+JlXzpHXRcF7+X31IXP3yGH/PQkIchdqirRr471vELP72Nt22YWBxvo2Ku8gMMJrwI42fLh7FDlF3v2b+fRMfeWIMelsbNLUVUJvAWJ/J52I+Bl+uXZUDbaPPxkxVbImfa0rAXIYw0swW/HQvHziB9I7nucMwP4Q+CEnFkmcpK+WRsIhb7gC9ZZ6+u/zrYk8rYAvfX6fmkMy4w=
X-MS-TrafficTypeDiagnostic: AM5PR0701MB2996:
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2996; 20:Y7eUvwYtQvKKMfYPaRbcmc+538z5AhxMTWdXh26U4SLKZaM2n0uJNEFTvRQrxyA/EM24wbmdZkGwGFkU30fFtWUijZwu8DpFTzf9sHUMtonecM0F3Ksj6+k4l/F/+G2s+Zj+F7n6zkwjbgDBhLf1y0yizJgYAqiyVbpO7DuNTDh3ZmURFrCGoQQzBucYArHuJY19M0ZcjcOJyBvY9TKFLGF2aYTRwP7teMq895boUt/BZ2DY/+S4CQ1iRPxZ2Pu7S4tBpcGgR/yPXd/NB+r1BH1IgU7tW6suuuq2X8VC9vcPddAa9H5RqTPfxl76HmDOmNNlWvKtpjFWA9VwjOb94A==; 4:OsexQTuKhQ7JjFpwdZPYXx6zwvH9gxc7ufI5o7pF/KlwU96Fkda/2Fz17gXxyrr0eYuJkLrMgLoUS/PbvjpLuMVjJn0s5RiwHJTcF1G9dMUhb1C/YTKAv08Gh9AHBsl1k3xUs++hVUBBfyNMnf1apoMdVDs++6qD2/TGFLNGWfEdNC9mFo4X/atjrbFLEYIB0whD4TvIeEQOLfZYtajuedkj6uUbgJFC3o7Yt5RPJeMlLam80nbpm7qTKk4P0zeS09eCzfsYethE3/3ihM0Pl9gqbllHCWqhcASQJInZAHe2YIKeGffguLkRjCvSDLOAwqVjApB1Au19pCNyd9YYCw==
X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(82608151540597);
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(61426038)(61427038)(6041248)(20161123558100)(20161123555025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2996; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2996; 
X-Forefront-PRVS: 0438F90F17
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(189002)(199003)(7736002)(9686003)(305945005)(1456003)(86362001)(116806002)(81686999)(76176999)(8936002)(81156014)(14496001)(81166006)(189998001)(33646002)(2351001)(101416001)(8676002)(50986999)(105586002)(106356001)(84392002)(61296003)(81816999)(3846002)(6486002)(6666003)(229853002)(53936002)(2906002)(16526017)(316002)(1556002)(6496005)(6246003)(5890100001)(2870700001)(4720700003)(44736005)(62236002)(47776003)(6116002)(68736007)(66066001)(50226002)(5660300001)(23676002)(478600001)(44716002)(25786009)(50466002)(97736004)(6916009)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2996; 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?MTtBTTVQUjA3MDFNQjI5OTY7MjM6cnpMM2Y1b2V2STZyek0yUE1nelRCeTBu?= =?utf-8?B?ei9CRm40Mms0RlRlYjVWR3pKRE9vUWVodXNlTzBwNTlMOTFnR1JwcnZJaFg5?= =?utf-8?B?Uzd0RkhycHNDdmVIK2g4Q2tWaHNXZktpNjZINldRTmpabDVScnRTenAwN1px?= =?utf-8?B?V3NKNGFEckFuczE2VE5QTENmMzhBTFhiRlIyQ2hVR0hwZFdxKyszUUFIYjc2?= =?utf-8?B?TGlBeUNRbVlFMEg1TjViQjRzc0YxYmUyUFQxdGwySjhpRmUzQVUxWHJXWnRO?= =?utf-8?B?UGU0VmdhcHJhUm56MGQxZ3k4TDREOW83Q2QveVA4Wmxlb3hjdktWSnRzeUpI?= =?utf-8?B?bG8yTXM5RGtINGZ4VTNlVkZGYkNWZU1seFBsMlo5cWQxNmNxaVlOVU50MThz?= =?utf-8?B?KzNzdDlObzNUcmZEdkNtRVArZ0ZqWVcvcmxyUlA3cHZ5dW4xQkhiZHhBbTJk?= =?utf-8?B?VDZhNjJvc21EV1lyYk1FZ3hGNTBXN2VCSVd3azBJblJvd091ZUh6eXRUSmFP?= =?utf-8?B?eHArK3I1clp0MEtiR3NYYkUvajVFTEJsSDBpa1BHNUVZM0t5citrSDE4elQ1?= =?utf-8?B?YVRBc2pQR1JxeWtTU1IvY0ZldzRBTlh1VTI0eFR0cDhJdW5zY1pZTFk4MXNQ?= =?utf-8?B?REN2SFlvLzRrbEV6Nks5VC9BR3F4TVBWRUJHZEErOUtMTlg4dkJSd1E1d052?= =?utf-8?B?L0kvTis0VG1OeTQ4aXJlb2dLdDZsd1dIWTF0RVJwOC9vT29pZEdHMUhFc3lq?= =?utf-8?B?dDg0M01YU2hKbmJ4RDBha045d2pzSHhnRUtUaGxkOWhSZFNDVzV5TGdUSVZD?= =?utf-8?B?cjUydVJPZDBkN1VZby9SNWpPUk82QjU0RlB4MXFMMVh5UDZPd0RBdTgwNHJK?= =?utf-8?B?VmdtQVBvS285VHlqeHNlalMxTnhERHREYmZ2R1RRTUgvWGt1dHVyY0NJbmJD?= =?utf-8?B?bXNobnh5OEhxS0tvVUVsS3VsaXpyV2Yzc1JCM0ppeE9WK0pqdk1md25MN0tH?= =?utf-8?B?MURGcVllV2xkNmlUdmRLeEQ4WHhjSzRqNUQ4d0x6eXJjdk1qVEpIbUd3NzFO?= =?utf-8?B?cGlUekhLUDVad3BVYjhwbk1ldStDYUJ1NjJKVWdHeUtVdkdxZVEwdWpEaDA2?= =?utf-8?B?RlNOWW8vSzhPeHBhWXNWNURwODQ1UDZIbjdsbXRxQWRrbmlHV0V2azc5R0JS?= =?utf-8?B?ZmVIR0ZHWGVLWWx2ZW9ERVZkY3d4WW9EVGFuaEd4KzNROE1hYWtoMmtocW1p?= =?utf-8?B?UEg1Um12ZUIzVC9FZ293QVQ0MnVKVFlpa1NDNlZCZ3dyNlI4N1F5SS9HSWIy?= =?utf-8?B?VWZzanN3RktqS3dQcFl1Q1V6NlFiQlBxWGxTV1JudFBEbFNYOS9rUWtqcHdN?= =?utf-8?B?eER5T0pPOGc5bVI2SUhubDdKVHRuZWRHSVN3aFBjTHArOUtNUUNib3c2ODRw?= =?utf-8?B?YkZVOU1pWFlBVyt5eURxbk5vWndhMnFCbDZIMS9CWE1GcUtOaGpwaW5BY1B6?= =?utf-8?B?dllnbWlzMVpUMGFzS1Y2MGFzZ0hydHl2UkxYRHhQK2hweURtQi9sL0lOcDcv?= =?utf-8?B?TFRqZzEyTUtlbmNqQnFkcVM4bXVjWGhGdE5IOHlRM2g0b3gxcFpmaHluZXkr?= =?utf-8?B?Y2J4WU92OGd3b3loby9lTzdtSGs0VURiSU8yNm1ZRE81UGdaNnFhWHFvRVdX?= =?utf-8?B?MG9yYjJBdEhZME5IWEFDcm5IMC9xay9leTZZZU8vK2dEV0pkWUwzRXdCTklV?= =?utf-8?B?WEtqNUd2dTk0L2poamFVbklxMlFxT2lRYzZ4QWdxMEMzRy9pK3YwRjl5VzZ6?= =?utf-8?B?N2JCMUEyMEtyeEl1TlJGTkFTcHovOUcwbnhocHppb1R3YlBNYnMzTWpUYW1B?= =?utf-8?Q?c7kgOrtTtmE14=3D?=
X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2996; 6:H8ky7HuC2aqqLF37qcBflNO3DDgm/ZHAhb9Le+pUM0ZV2qAtOhY+/jZZ7rZQ3+KZIAGhvglM0XttTHVCALMUKZ5HtaBIFM59BIdTUT4oFHr2vKYlrSBFP3zACjOaRJhDapwbVebo7YlfDpaKVE3OYK6ANRX2f02Qhx/A3/KFF1MiSAhBWT5wgWHz9wjzwZaqTYeH1bzmVdEDRIbu3MA2rzevj7EcZyy/3tTUyvk3xQvqVb+UyAaIifvXW5ruVrdhhesWa/f6fIsHJlztLBuRtnCCtH94XY+7UELefLrsYnTEfzpMZ7mY+RFr1BHR1qscVmlR8qnZtqPKBOwo0CCXdA==; 5:SHOl6E1uUSxPdOtIJba/Y6HVEolYdQHEvY/EmsYXXFs2kyT+yMr/BTTgKeh4RlmsZwe+/9wMDiWqIgZjFxZa5HTLNEtQps/5ltNVTHJfcfOgCdOT6TjBL+G2J2h5YvzosIl4ydyOc1pk8ZV/geAP9Q==; 24:bB+uKDpPby+ItTgfxR5rjXnlnQYGpqbIOMCh2Y0AF9WLn9Dc9hzhycZjipOrGLroC5AQ3KFAu0vAbEVYT0NnC7TaSaOtZFRs4B2NlMsuAjQ=; 7:utGrTZWp9D5N8vIE679MrRCVh1eafLcaVAgReC6Mnqv16K5KIeEtUy3dSKjmpByiNHeHFXsZs60FjWU9J7nvoAak9yyk034ZGQGuUPFOUL7kAB/0B4NtTGgLwx5V4g9GDKf0MUd8j7O1Ep+ALVavbqXrKah/vG+1heWFiCUS/To9eFmJFUEj7kehe5okMRRKHOAksltuKBDLd352e79iwaVuSY1U1lIvJiTu2+dEVTg=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2017 16:29:48.1985 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2996
Archived-At: 
Subject: Re: [netmod] Broadband Forum NMDA Questions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Sep 2017 16:30:00 -0000

For those who wonder, the text of the liaison  (slightly mangled by code
page issues) is as follows (I know what advice I would give but am
probably in a minority there on this list:-))

Broadband Forum NMDA Questions

Body

Dear all,

The Broadband Forum has been considering the impact of NMDA (Network
Management Datastore Architecture) on its YANG work.

Many of our standard and draft YANG modules are dependent on the
ietf-interfaces (RFC 7223) and ietf-hardware (draft-ietf-netmod-entity)
YANG
modules, both of which will be impacted by NMDA. Therefore we need to
decide
whether (and, if so, how) we should update our published and draft YANG
modules. We see three possible approaches:
- Ignore NMDA, relying on the fact that updated IETF YANG modules will
retain backwards compatibility.
- Embrace NMDA, updating all our YANG modules to use single trees (no
separate state trees).
- Support NMDA, while retaining backwards compatibility in the same way
as IETF YANG modules will do so.

Our decision will be affected by:
- Our level of confidence that NMDA will be the "last big change" to the
way in
which IETF YANG modules are written.
- The timescales on which NMDA-compliant versions of the ietf-interfaces
and ietfhardware YANG modules will be published as RFCs (we note that
NMDA-compliant versions of these modules are now available).

We would much appreciate your feedback on our analysis of the possible
approaches and on our concerns as expressed above.

Sincerely
Michael Fargano
Broadband Forum Technical Committee Chair

CC:
David Sinicrope, BBF / IETF Liaison Officer/Manager,
 Sven Ooghe, BBF Common YANG Project
Stream
Leader,  William Lupton, BBF Common YANG Project
Stream
Leader,  Robin Mersh, Broadband Forum CEO
 Gabrielle Bond, Broadband Forum Secretariat
 Statements at IETF 
Liaisons at BBF 


  StatementHistoryStatePosted
      Posted Date2017-09-20
      From GroupBROADBAND-FORUM
      From ContactMichael Fargano
      To Groupsnetmod, OPS
      To ContactsWarren Kumari
      Benoit Claise
      Jürgen Schönwälder
      Tom Nadeau
      CcDavid Sinicrope
      Kent Watsen
      Warren Kumari
      The IETF Chair
      Lou Berger
      Benoit Claise
      Network Modeling Discussion List
      Response Contactmichael.fargano@centurylink.com
      david.sinicrope@ericsson.com
      PurposeFor comment
      Deadline2017-11-27 Action Needed
      Attachments41;.final


From nobody Fri Sep 22 09:35:58 2017
Return-Path: 
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 48B75132E24; Fri, 22 Sep 2017 09:35:56 -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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_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 ycDvLIAHHvp5; Fri, 22 Sep 2017 09:35:54 -0700 (PDT)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50091.outbound.protection.outlook.com [40.107.5.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66D84132930; Fri, 22 Sep 2017 09:35:53 -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=nNxLU79I6+Bb1QiGsYLOss2/G5kWFKYQSJ/lCY65H08=; b=Ov8MiYteeGiUg/5q1AlqSdOg/w42XFSVaMUwtr72rKQOkAobxy2d9rd3vs13Snt4jpfoB53Y/RIohd7a8SFLE1g79954/WXFPj7s+lKxZKDwI56Kz1VX+LTnKlyYC+FdshBlohW2vy0Ph/RXDfZLs68NuhbM0Oy60oBEnEAnxSk=
Received: from pc6 (109.146.128.123) by VI1PR0701MB3007.eurprd07.prod.outlook.com (2603:10a6:800:87::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Fri, 22 Sep 2017 16:35:50 +0000
Message-ID: <00c501d333c0$9d210280$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Robert Wilton" , 
Cc: 
References: <20170918.200734.1805388289423863575.mbj@tail-f.com>  <99b9a2c6-4bb4-121f-0cba-925cefe09712@cisco.com> <20170919.115559.1080249872764998055.mbj@tail-f.com>  <5481ac35-c789-0796-36f6-8a02a5ebef8c@cisco.com>
Date: Fri, 22 Sep 2017 17:34:03 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
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: [109.146.128.123]
X-ClientProxiedBy: AM3PR07CA0136.eurprd07.prod.outlook.com (2603:10a6:207:8::22) To VI1PR0701MB3007.eurprd07.prod.outlook.com (2603:10a6:800:87::21)
X-MS-Office365-Filtering-Correlation-Id: afe5c96f-742b-4312-3f27-08d501d7fc9d
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:VI1PR0701MB3007; 
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 3:BKppYhihYNzcANIlQyJcQEeKOjOIfPRK2fBAl340pabTFbc3qqHFTODByYNsXNp8hogh9lpwVqm1tPuNv3iIe7V7tYLxizgf8aDysSCeiBMlBPK4hPqcFAQ3xUxsBow58nLsShL8dDEh7pG5UQkd8ixACh9jOR9ceXRUe/kAiidCtaml60kodSOYp42jAAucvu1WdlzgZizYKlgfUmsVIEW87vc5RqcogazammfM+uyMu2KCE0NmOWZfgLqBe7+l; 25:a3ALC2UWMFgmB/bLxl0cunVYOc36CR2vKtXVp1vYj2mf7kZQru6vSD0Vy06GXjOqBIVLGjy/F6gmMQvU6Ltw40xctOv50gcUj3/3W1exPiA06Smce0c8dnmbrt1XMP3pnHImRSPughDeF1gtGtpnuCpWlILMKiF9RLS9ZVhCvq+TZBGGhFf/kozWEUsEnjxP9YcT1aZ4ybpNlLr6+vVnaIqIm4bGtMM40QQQcmud1AXOi8TSGSurbsm/2MDdNhcHOFtkw/zaBjCKoz6D44NPJLKO4jtq8xH8wFEcRtb8r90MrkB/N9dUFTGKfie1R06Lk36uSyo+wuKCGo8h+uSMYA==; 31:MjgyADpZqBHml4amYMaiR7b6XfdmSHFXxni1PMgCVXlJoqCyHjIuhfzBPl8xl1U3BAiJf4IeWpOOrCo7A0uw+42M/tZ3a8H6F0k5Z3u+4fF9qBLkRIqM4tULmvo/L8JEsPFsmugjfnxAS8twDPOylrF4EMoxC3XWa7KGazvRh6Uso8TO3hMfNecnYyNYfhcaOipPRdqjEv6/Wtuki9HXUlFDGCKF6Qptlm4OIjegKVM=
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: VI1PR0701MB3007:
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 20:6G6oLpaogsjf3UxKiw/ZFkaQ7lWz/PXWXWQLZmX7/T4QTRY+5n3Rg8rl27oY0V8NFJ0kp8uSLTB+qUxpD/zLtiPhLU6vCT9uru268jvnaZx+UGWAIY58IHWjSQvL/DsHDBIn1K7RkqmMUKsokIOGzifq4kMz4J9oQnF96dIywwbsIKfkYECpSRwGMUKw3uxc8G8WLjEV8kRGohX+/csaqT8E8TKRPMwMKV23drHCeVZc4JKE1wjHxhgoFDt/ZNLh/dvlIZcpCoOw6txP0A+nsZUkuMXIE1cPlvz7nnTjVf8PC9ASWfn2D5eatlq5toRdTkjA+1ufFAa423tXUXsyDQ==; 4:STFYUWQALoF127rrGsBGKEuQlhuw0kJOxy/0uKOoReB0uR/boctX+ocSkbnMLCsGUPt5+RnH8nWvZij3/U+R2TokaVF/Bgux4i+bthZiF80H1tIJp/Bba6kgqtoLitfZn9+fNFrhQQbMkXvvdOozLurkvgsRYueR1An1GargVksGyf3ir9R7UgBH+IbVtuzxHUPv7A/Hh9TBp52sQKudjZrqHmeiUYdAG3SVzTBGtZ/XFl505Won/UY4Fb2puAPKiVYRnfXYI23PbtBdMLGbvpmbgdjTVzQjwlrF0F9DsjCE78EVlgPGOYaVz2bzm3TPahyVNiipoV2I2aR9qWD9akxMrqdgVwMXnsWQxscOnyo=
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(788757137089)(95692535739014); 
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(61426038)(61427038)(6041248)(20161123555025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR0701MB3007; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR0701MB3007; 
X-Forefront-PRVS: 0438F90F17
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(39860400002)(376002)(189002)(199003)(54094003)(51444003)(13464003)(24454002)(377454003)(6246003)(81686999)(25786009)(4326008)(76176999)(86362001)(23676002)(6496005)(81816999)(14496001)(229853002)(116806002)(6486002)(44736005)(478600001)(97736004)(61296003)(3846002)(230700001)(50466002)(8676002)(1456003)(33646002)(106356001)(105586002)(9686003)(53936002)(47776003)(93886005)(8936002)(316002)(6666003)(305945005)(2906002)(44716002)(50226002)(101416001)(62236002)(6116002)(50986999)(189998001)(81156014)(1556002)(16526017)(81166006)(68736007)(7736002)(84392002)(66066001)(110136005)(4720700003)(53546010)(5660300001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB3007; 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?MTtWSTFQUjA3MDFNQjMwMDc7MjM6M1pFYWF2b1RuZlZxUGRUUTIza1ZKK2pB?= =?utf-8?B?bkxNamsycUtURzF3SkVXRWwxOG9rWkphNGJCWDNHV1pRaUtYMDd0RDdpcHYx?= =?utf-8?B?TVVnKytUSzlwMmxGb2pCTXRCWFhRYjBMREtLMlduWWloKzQ2V3hlYnI2MWI3?= =?utf-8?B?eUNDelNBRWxiOVV2TndGQkp6MUhQdElQTGpteVlXOXdCb2ZOOHBReFcyMWsw?= =?utf-8?B?azhtNkZ2YTRVcDBPeEtVU0xvVlEvb1NoMm1nWUhYWG81ckNRV09Cc1hSeFBH?= =?utf-8?B?YklVVU5hdktGd3ZjNklCbEx3R1J6T05IdnNaRDlHUWorUUg1UGtKelFzdGw2?= =?utf-8?B?elFDZ29MMGZlSTJtalRKVldlcWhWUitDZkVzemd2NWZNMCtLK0lBb0tudU5C?= =?utf-8?B?b0xQdjQzYnRGUGZIRnlrcXl1c0NpSFR1ZUw4ME5wMjdMd01LNDcyRXJxVERh?= =?utf-8?B?TitqVjBNTjJtc3E3Umc3MzdLd2Z1S3VhRm00ZHNwOHhPaU9OeWZOQzBnM3pl?= =?utf-8?B?MjBZcXdjbllaby9NcjV1SFA4RVV0K0FLeVorRzFzTTQwVm4rU0R1R1ltbU5Z?= =?utf-8?B?YW5jNjBWVFFUaGcyUWhjSmFjanJkcHdDUEIwMTF2ZUlsaWdwcWtaM1M1YmRC?= =?utf-8?B?ekZJUitELzNFTkZFWWNJVXRkRm1jelg0SWpMZzhpei9ORlh6SWFvd1V5Mmhi?= =?utf-8?B?VnZnU1ViZk8rTk9OT1Y0V09WWlBiaHdzKzNMV0dOYWx1ZXhLb3FlUVY5ZXoy?= =?utf-8?B?dEVka0dZWlhFanZCdUFxSjdjSUVLTU9ndHBqUzJWanZmcWJBMzZKZHdYZmtS?= =?utf-8?B?OTljU3djVU5Ia2VmYnlkUjd1SjhLRGd2L05TR3A3VDlETU55Sms1WmMrU1lQ?= =?utf-8?B?RWxxUmVocVJaeFZHN3g0d2JmUlFpREQrMGJZQlNydlU1NGpURW1UWlNNNk03?= =?utf-8?B?RUh5ZFMzenNZTG5PaVRicHZ3VmdnM0E0OEpQbjNVanJDUTJGTm1OZExzbk93?= =?utf-8?B?UURvQ3lUd1lNT29NQlovK044UFphSjduQ3EvRDk1S2ZpWHAvU0Rqa0ROVE84?= =?utf-8?B?VUtBbTRwQ2tDVjFyV2ZZcmh2R29DNGhOc0lZSjdjd0gxcE5oSHFMdFlFTXo4?= =?utf-8?B?cVJ3MUVGNWdrOVZRWUZ1MFhnSlpBT0pPaVo5TkM1STZ4SGdaVnEzcE5kVXVk?= =?utf-8?B?aVZtQUlLellLUEx5dzFLa1FNb0MzK0U0eUdLcnk1N24wQXpFVnhDNUI0N1Fn?= =?utf-8?B?NXdVTGtYMkltZjJmSkdpMDJFYXV0OUJ0T2tJWDNST0pGWFJUcHYzYW1BK1VX?= =?utf-8?B?eTFpbHNDNW9qUjRKVllUb2VXS096K3R3TlZMYWRaWGNTcUZMN0RUMktyckEz?= =?utf-8?B?RlIrVjczMEZrSXhPVEtLRDJHamRVeUJ3b3RQYUhxTis3aW04WU1FMmJiMHNL?= =?utf-8?B?TmJQSUVIbE5pMjNCdWw3Q2FYcmpDRkgrTlR0YklmN3doSUkvb3JDQkpSMElZ?= =?utf-8?B?RXR6YnBEdDYyZXlRUDlWdVlVdjRRYjN0bVNjUG1oRDJ5VXRORUZUVHFJTHFn?= =?utf-8?B?VnZtVXNKdURwTjkvR1pGZEhRTTlGZmt3bmdmZ0NFQ1VGT1JpVmZxdk85bjNY?= =?utf-8?B?WDFILzFkOWplUy9lcVYzcVRwWGppUjczdDFzdUVXdDdEbTR3OEVQbUM0TEU2?= =?utf-8?B?V3g0dnNRZE5JYWtBOEZHamVyQW0zMVJRRDM3b0VpejBiQzhLZ21vSGNHQjVz?= =?utf-8?B?ZE1ZWWttcmdQYllxNUF5dWhmZE1OZGx5SWpGVk1BY05wNE1TZVhjSUFvbnFI?= =?utf-8?B?WHB5T1pOb2tpdFJ3Z2l6azVOM0RCOXQ2cDJvNW1tU0lUMlR0TnowRFd0b015?= =?utf-8?B?ZSt1ZzBGOGNOckI3MzBxaUpPNVpFV2JDOHRmSm94OElyOWdRdWJqSTFvc3Fj?= =?utf-8?B?ZDRVVndudWJJTXBTUEdWS0JsOVk0UGlsbmp6Wm9NUjZWQmtReS9QYytYeWlz?= =?utf-8?B?ZzVCZXFPNmVDQ2ZPOUNBbm5UVFZXUTRieUo5Njl5N295aWdRUisxUzkrNDhH?= =?utf-8?Q?G1hplU=3D?=
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3007; 6:oAWMigHuF4JFO3d22MSVAUFvUF7M7uCO9Xf0ScrEVb/LP51WCg6tJFadzij/ErpQl93KvoF7py//DLWzT71UV0hrjF+DVzktUdIpwHax3m6stJIb65DzDFru/r4zBbv9Wh5Skz5ALbfcbanKI/QXDvbPK6a0IwvIt5XIkyBxpQzBP/ti1/CPJTaQl/to2aHW5A+JnNyHZTEHEgyFLz5d0+kEXRHNRjya2mZ14RtH9z7rX54FrTChkitu9t5NBbPAXptBcdOsyGwn5iyPyeXDQTh116Gp3w6FXQpm4/QNfmcLK/kleqAusZ4YaNuAoBdfp30WzkW9NGxGy3osyk/+VA==; 5:qOfWYwpMOnpJI2vAPjKbLKPXCd1ANFN3EQyfI7hIEqOgAXzcMtzFTj4phMfmLTXbV7fBrZvh6NTnvZJj9McaLZlwM3AJZSypAyJJvR51BbG4sw5icd7G0qmY1JgrJhbOJetEjrJ1nC4rYvjfQU6WCQ==; 24:woNSfvvf9v00j/CB3Qm5GXqRi7eorRFjTnNo7myowy5C9If0o5gL+5/HeVmU4tjItBuZgRP5G/W0iO9ot96aWmZXUChYm4U7m2R2Kcwgeew=; 7:dm1QOPYNlY2ZTCj9TLKTIALfxWgzjZVbmQ3Tirlh5GFn6/ctIBOmvc0f7/EcPuMGQwf4ypb7NQ55/eV2tr2uAkOriguJmIbWt4Xts+TKNRrpud8cojL1Xd1FkJbOz16BcpIgJV9iPKJ+cKUxGDBiTvlcia0vxDPYUAaWImRn0z6aKKd+RgV8UUcRsliIRN8bVjy3KsZ4hdsu6rxZwDwuG4S2KHT7VyBjgCxJYN5ZDtw=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2017 16:35:50.6178 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB3007
Archived-At: 
Subject: Re: [netmod]  vs 
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Sep 2017 16:35:56 -0000

Robert

I wonder if this says the opposite of what is intended

-  holds the complete  current configuration on the device.

- This could include inactiveconfiguration

 -  must always be a  'valid configuration data tree' as
defined in Section 8.1 of [RFC7950].

Ergo, inactiveconfiguration must form part of a valid configuration
tree.

I thought the idea was that inactiveconfiguration was logically removed
before validation but this seems to state the opposite..

Tom Petch

----- Original Message -----
From: "Robert Wilton" 
Sent: Friday, September 22, 2017 10:03 AM

> Hi,
>
> Regarding whether  is always valid, the proposed modification
> to the draft is to add the following text to section 4.3 that
describes
> :
>
> OLD:
>
> 4.3. The Running Configuration Datastore ()
>
>   The running configuration datastore () holds the complete
>   current configuration on the device. It may include inactive
>   configuration or template-mechanism-oriented configuration that
>   require further expansion.
>
>   If a device does not have a distinct  and non-volatile is
>   available, the device will typically use that non-volatile storage
to
>   allow  to persist across reboots.
>
> NEW:
>
> 4.3. The Running Configuration Datastore ()
>
>   The running configuration datastore () holds the complete
>   current configuration on the device. This could, for example,
include
>   inactiveconfiguration or template-mechanism-oriented configuration
>   thatrequires further expansion.However,  must always be a
>   'valid configuration data tree' as defined in Section 8.1 of
[RFC7950].
>
>   If a device does not have a distinct  and non-volatile is
>   available, the device will typically use that non-volatile storage
to
>   allow  to persist across reboots.
>
> END
>
>
> Then the intention is that if inactive or a templating solution is
> standardized then those drafts would update the validation rules in
RFC
> 7950 such that  is still valid. E.g. an inactive config draft
> would probably indicate that validation excludes all configuration
nodes
> that are marked as inactive.
>
> Does anyone have any comments?
>
> Do we also need to state that  must always be a 'valid
> configuration data tree'?
>
> Thanks,
> Rob
>
>
> On 19/09/2017 16:22, Robert Wilton wrote:
> >
> >
> > On 19/09/2017 10:55, Martin Bjorklund wrote:
> >> Robert Wilton  wrote:
> >>>
> >>> On 18/09/2017 19:25, Andy Bierman wrote:
> >>>>
> >>>> On Mon, Sep 18, 2017 at 11:07 AM, Martin Bjorklund
 >>>> > wrote:
> >>>>
> >>>> Juergen Schoenwaelder  >>>> > wrote:
> >>>> > On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert Wilton wrote:
> >>>> > >
> >>>> > > > No. I do not agree that the MUST in RFC 7950 can be
> >>>> removed.
> >>>> > > > I do not agree the architecture should update YANG at all.
> >>>> > > OK.
> >>>> >
> >>>> > I am with Andy here.  has always had the
> >>>> requirement to be
> >>>> > valid and we are not supposed to change that. Mechanisms for
> >>>> inactive
> >>>> > configuration or templating must be designed to be backwards
> >>>> compatible
> >>>> > I think.
> >>>>
> >>>> Ok. If we keep the requirement that  in itself must be
> >>>> valid, it just restricts the usefulness/expressiveness of
> >>>> inactive and
> >>>> template mechanisms, but it might be ok.
> >>>>
> >>>> I think that even w/o this requirement, the observable
> >>>> behavior for a
> >>>> client can be backwards compatible. For example, suppose we
> >>>> have an
> >>>> inactive access control rule that refers to a non-existing
> >>>> interface in
> >>>> . If a client that doesn't know anything about
> >>>> inactive asks
> >>>> for the contents of , our implementation removes the
> >>>> inactive
> >>>> nodes from the reply to the client. Only a client that
> >>>> opts-in to
> >>>> inactive will receive a reply with things that looks invalid
> >>>> if you
> >>>> don't take the inactive annotation into account.
> >>>>
> >>>>
> >>>>
> >>>> There are many ways that validation can fail because inactive
nodes
> >>>> are present,
> >>>> and considered part of the validation.
> >>>>
> >>>> e,g, min-elements, max-elements, mandatory, unique.
> >>>>
> >>>> I think we all agree that validation on the enabled nodes is
supposed
> >>>> to continue to work.
> >> Yes.
> >>
> >>>> Here is an attempt at a backwards-compatible solution:
> >>>>
> >>>> 1) current  and  responses only include enabled
> >>>> nodes.
> >>>> 2) old-style  operations do not alter inactive nodes
> >>>> 3) NMDA clients use , not  or . These
> >>>> responses
> >>>> include enabled and disabled nodes, so validation does not apply
> >>>> for 
> >>>> 4) new style  (i.e.  parameter used) can
alter
> >>>> any type of data node
> >>> //I think that inactive should always be an optional extension.
Not
> >>> everything needs the additional complexity.
> >>>
> >>> Hence rather than tying this function to specific NETCONF
operations,
> >>> I would suggest that there should be an extra parameter (like for
> >>> with-defaults) to allow a client to indicate to the server that a
get
> >>> or edit request is using the "with-inactive" extension.
> >>> 1) The server should also have a capability (or perhaps a leaf
defined
> >>> in YANG library) to indicate that it supports inactive
configuration.
> >>> 2) If a client doesn't use the extra "with-inactive" parameter
during
> >>> a get request then only active nodes are returned.
> >>> 3) If a client doesn't use the extra "with-inactive" parameter
during
> >>> an edit-data request then the request cannot include an extra
inactive
> >>> meta-data. The request is processed in a way that is equivalent to
an
> >>> existing NETCONF implementation, but it may unknowingly remove
some
> >>> inactive configuration (e.g. via a replace or remove operation on
an
> >>> inactive node). Operations like create, delete, none, replace
should
> >>> all treat an inactive target node the same way as in the node
doesn't
> >>> exist (e.g. delete on an inactive node would return a
"data-missing"
> >>> error), this ensures that the behaviour that an unaware client
> >>> observes is the same as the existing behaviour that it would
expect
> >>> from a regular 6241 compliant NETCONF implementation.
> >>> 4) It a client makes a get request including the "with-inactive"
> >>> parameter then they also get the inactive nodes as well, marked
with a
> >>> meta-data annotation.
> >>> 5) If a client makes an edit request including the "with-inactive"
> >>> parameter, then the inactive meta-data annotation can be used to
label
> >>> inactive nodes. Inactive nodes are regarded as regular data nodes
for
> >>> create/delete/replace/none operation error checking.
> >>>
> >>> I think that this approach is similar (perhaps even the same) as
> >>> Martin described.
> >> This is indeed how our implementation works (except I think we
don't
> >> do 5; if the client sends an "inactive" attribute it doesn't have
to
> >> also send with-inactive).
> >>
> >>>> Note that the YANG MUST rule still applies, because validation is
only
> >>>> done on enabled nodes.
> >>>> It is only the response message representations that cannot be
> >>>> validated, not the contents
> >>>> of  on a server.
> >> So the question is how we can make sure that the text in the NMDA
> >> draft covers this yet-to-be-defined feature w/o having to define it
> >> now? We thought that the current text was sufficient, but do we
have
> >> to make any changes to it?
> > 1) Do we also need to illustrate a similar proof of concept
templating
> > implementation to show that templating could work whilst keeping
> > running valid? I would prefer that this is just deferred to
whichever
> > draft defines templating.
> >
> > 2) I think that we need to reach a decision as to whether the NMDA
> > architecture needs to explicitly state that  is always
valid,
> > or if that can be left to the existing statement in 7950. My
thinking
> > is that if the conclusion is that  must always be valid,
then
> > it would be helpful to explicitly state it the descriptions of both
> >  and  in the NMDA architecture.
> >
> > 3) I think that it would be useful to further refine my previous
> > proposed text for intended, particularly rewriting the text on
> > validation. This should hopefully also address Balazs' concern about
> > default values be included in validation.
> >
> > 
> >
> > 4.4. The Intended Configuration Datastore ()
> >
> > The intended configuration datastore () is a read-only
> > configuration datastore. It is tightly coupled to . When
> > data is written to , the data that is to be validated is
> > also conceptually written to . Validation is performed on
> > the contents of .
> >
> > For simple implementations,  and  are identical.
> >
> >  does not persist across reboots; its relationship with
> >  makes that unnecessary.
> >
> > Currently there are no standard mechanisms defined that affect
> >  so that it would have different contents than ,
> > but this architecture allows for such mechanisms to be defined.
> >
> > One example of such a mechanism is support for marking nodes as
> > inactive in . Inactive nodes are not copied to ,
> > and are thus not taken into account when validating the
> > configuration.
> >
> > Another example is support for templates. Templates are expanded
> > when copied into , and the expanded result is validated.
> >
> > 
> > 
> >
> > 4.1.4. The Intended Configuration Datastore ()
> >
> > The intended configuration datastore () is a read-only
> > configuration datastore. It represents the configuration after all
> > configuration transformations to  are performed (e.g.
> > template expansion, removal of inactive configuration), and is the
> > configuration that the system attempts to apply.
> >
> >  is tightly coupled to . Whenever data is written
> > to , then  is also immediately updated by
> > performing all necessary transformations to the contents of

> > and then  is validated.
> >
> >  may also be updated independently of  (e.g., if
> > one of the configuration transformations is changed), but 
> > must always be a 'valid configuration data tree' as defined in
> > Section 8.1 of [RFC7950].
> >
> > For simple implementations,  and  are identical.
> >
> > The contents of  is also related to the 'config true'
> > subset of , and hence a client can determine to what
> > extent the intended configuration is currently in use by checking
> > whether the contents of  also appears in .
> >
> >  does not persist across reboots; its relationship with
> >  makes that unnecessary.
> >
> > Currently there are no standard mechanisms defined that affect
> >  so that it would have different contents than ,
> > but this architecture allows for such mechanisms to be defined.
> >
> > One example of such a mechanism is support for marking nodes as
> > inactive in . Inactive nodes are not copied to .
> > A second example is support for templates, which can perform
> > transformations on the configuration from  to the
> > configuration written to .
> >
> > 
> >
> > Thanks,
> > Rob
> >
> >
> >>
> >>
> >> /martin
> >> .
> >>
> >
> > .
> >
>


From nobody Fri Sep 22 10:13:00 2017
Return-Path: 
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 AF4FD134560; Fri, 22 Sep 2017 10:12:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 hV_D627GtZUV; Fri, 22 Sep 2017 10:12:55 -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 6EB86134557; Fri, 22 Sep 2017 10:12:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12931; q=dns/txt; s=iport; t=1506100373; x=1507309973; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=HWXEULqXZAbeTbpLZV3RU6YT+n27asSbkWsN30fJJB8=; b=aPLVA8QQhoOnQQL+MiZ7gHb25rbB1LBzNvpZdR/FOW+3ME1SDAmxywMF P3rJ4WEwGFWOy640H3EA5he+7hrKI2Zy2rL9Ifs5xNbM3tpd9n6Vqe0Xd fN/ZLElZHpp+Wa6YceQTJJN2hSygivhC8X0+Wp5B4kVhirnObxcSO7o3N g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B9AQCNQ8VZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhSwng3aLFJBPK3mVPYIECoU7AoRmFQECAQEBAQEBAWsohRgBAQE?= =?us-ascii?q?BAgEjDwEFOgcMBAsQAgMBAgICERIDAgJGAw4GAQwGAgEBF4oQCKcAgieLFAEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAR2BDoIdg1OBZCuCSDWENi0CAlOCVIJgBaEXlFy?= =?us-ascii?q?CE4lIJIcFigmDY4dYgTk1IoEOMiEIHRWHZz82h2kBAQUfB4IVAQEB?=
X-IronPort-AV: E=Sophos;i="5.42,427,1500940800"; d="scan'208";a="657699418"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Sep 2017 17:12:51 +0000
Received: from [10.61.237.101] ([10.61.237.101]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v8MHCol9001336; Fri, 22 Sep 2017 17:12:50 GMT
To: "t.petch" , netmod@ietf.org
Cc: draft-ietf-netmod-revised-datastores@ietf.org
References: <20170918.200734.1805388289423863575.mbj@tail-f.com>  <99b9a2c6-4bb4-121f-0cba-925cefe09712@cisco.com> <20170919.115559.1080249872764998055.mbj@tail-f.com>  <5481ac35-c789-0796-36f6-8a02a5ebef8c@cisco.com> <00c501d333c0$9d210280$4001a8c0@gateway.2wire.net>
From: Robert Wilton 
Message-ID: 
Date: Fri, 22 Sep 2017 18:12:50 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <00c501d333c0$9d210280$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod]  vs 
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Sep 2017 17:12:59 -0000

Hi Tom,


On 22/09/2017 17:34, t.petch wrote:
> Robert
>
> I wonder if this says the opposite of what is intended
>
> -  holds the complete  current configuration on the device.
I agree.

>
> - This could include inactiveconfiguration
I agree.

>
>   -  must always be a  'valid configuration data tree' as
> defined in Section 8.1 of [RFC7950].
I agree.

>
> Ergo, inactiveconfiguration must form part of a valid configuration
> tree.

Ergo, inactive configuration can form part of a valid configuration
tree.

>
> I thought the idea was that inactiveconfiguration was logically removed
> before validation but this seems to state the opposite..
I don't think that this is necessarily true.  One choice is inactive 
configuration is removed before validation, but this isn't quite what 
I'm proposing.  I'm proposing that the act of validation itself is 
refined (via an tbd inactive configuration draft) such that it ignores 
configuration nodes marked as inactive.

Thanks,
Rob

>
> Tom Petch
>
> ----- Original Message -----
> From: "Robert Wilton" 
> Sent: Friday, September 22, 2017 10:03 AM
>
>> Hi,
>>
>> Regarding whether  is always valid, the proposed modification
>> to the draft is to add the following text to section 4.3 that
> describes
>> :
>>
>> OLD:
>>
>> 4.3. The Running Configuration Datastore ()
>>
>>    The running configuration datastore () holds the complete
>>    current configuration on the device. It may include inactive
>>    configuration or template-mechanism-oriented configuration that
>>    require further expansion.
>>
>>    If a device does not have a distinct  and non-volatile is
>>    available, the device will typically use that non-volatile storage
> to
>>    allow  to persist across reboots.
>>
>> NEW:
>>
>> 4.3. The Running Configuration Datastore ()
>>
>>    The running configuration datastore () holds the complete
>>    current configuration on the device. This could, for example,
> include
>>    inactiveconfiguration or template-mechanism-oriented configuration
>>    thatrequires further expansion.However,  must always be a
>>    'valid configuration data tree' as defined in Section 8.1 of
> [RFC7950].
>>    If a device does not have a distinct  and non-volatile is
>>    available, the device will typically use that non-volatile storage
> to
>>    allow  to persist across reboots.
>>
>> END
>>
>>
>> Then the intention is that if inactive or a templating solution is
>> standardized then those drafts would update the validation rules in
> RFC
>> 7950 such that  is still valid. E.g. an inactive config draft
>> would probably indicate that validation excludes all configuration
> nodes
>> that are marked as inactive.
>>
>> Does anyone have any comments?
>>
>> Do we also need to state that  must always be a 'valid
>> configuration data tree'?
>>
>> Thanks,
>> Rob
>>
>>
>> On 19/09/2017 16:22, Robert Wilton wrote:
>>>
>>> On 19/09/2017 10:55, Martin Bjorklund wrote:
>>>> Robert Wilton  wrote:
>>>>> On 18/09/2017 19:25, Andy Bierman wrote:
>>>>>> On Mon, Sep 18, 2017 at 11:07 AM, Martin Bjorklund
> >>>>> > wrote:
>>>>>>
>>>>>> Juergen Schoenwaelder >>>>> > wrote:
>>>>>>> On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert Wilton wrote:
>>>>>>>>> No. I do not agree that the MUST in RFC 7950 can be
>>>>>> removed.
>>>>>>>>> I do not agree the architecture should update YANG at all.
>>>>>>>> OK.
>>>>>>> I am with Andy here.  has always had the
>>>>>> requirement to be
>>>>>>> valid and we are not supposed to change that. Mechanisms for
>>>>>> inactive
>>>>>>> configuration or templating must be designed to be backwards
>>>>>> compatible
>>>>>>> I think.
>>>>>> Ok. If we keep the requirement that  in itself must be
>>>>>> valid, it just restricts the usefulness/expressiveness of
>>>>>> inactive and
>>>>>> template mechanisms, but it might be ok.
>>>>>>
>>>>>> I think that even w/o this requirement, the observable
>>>>>> behavior for a
>>>>>> client can be backwards compatible. For example, suppose we
>>>>>> have an
>>>>>> inactive access control rule that refers to a non-existing
>>>>>> interface in
>>>>>> . If a client that doesn't know anything about
>>>>>> inactive asks
>>>>>> for the contents of , our implementation removes the
>>>>>> inactive
>>>>>> nodes from the reply to the client. Only a client that
>>>>>> opts-in to
>>>>>> inactive will receive a reply with things that looks invalid
>>>>>> if you
>>>>>> don't take the inactive annotation into account.
>>>>>>
>>>>>>
>>>>>>
>>>>>> There are many ways that validation can fail because inactive
> nodes
>>>>>> are present,
>>>>>> and considered part of the validation.
>>>>>>
>>>>>> e,g, min-elements, max-elements, mandatory, unique.
>>>>>>
>>>>>> I think we all agree that validation on the enabled nodes is
> supposed
>>>>>> to continue to work.
>>>> Yes.
>>>>
>>>>>> Here is an attempt at a backwards-compatible solution:
>>>>>>
>>>>>> 1) current  and  responses only include enabled
>>>>>> nodes.
>>>>>> 2) old-style  operations do not alter inactive nodes
>>>>>> 3) NMDA clients use , not  or . These
>>>>>> responses
>>>>>> include enabled and disabled nodes, so validation does not apply
>>>>>> for 
>>>>>> 4) new style  (i.e.  parameter used) can
> alter
>>>>>> any type of data node
>>>>> //I think that inactive should always be an optional extension.
> Not
>>>>> everything needs the additional complexity.
>>>>>
>>>>> Hence rather than tying this function to specific NETCONF
> operations,
>>>>> I would suggest that there should be an extra parameter (like for
>>>>> with-defaults) to allow a client to indicate to the server that a
> get
>>>>> or edit request is using the "with-inactive" extension.
>>>>> 1) The server should also have a capability (or perhaps a leaf
> defined
>>>>> in YANG library) to indicate that it supports inactive
> configuration.
>>>>> 2) If a client doesn't use the extra "with-inactive" parameter
> during
>>>>> a get request then only active nodes are returned.
>>>>> 3) If a client doesn't use the extra "with-inactive" parameter
> during
>>>>> an edit-data request then the request cannot include an extra
> inactive
>>>>> meta-data. The request is processed in a way that is equivalent to
> an
>>>>> existing NETCONF implementation, but it may unknowingly remove
> some
>>>>> inactive configuration (e.g. via a replace or remove operation on
> an
>>>>> inactive node). Operations like create, delete, none, replace
> should
>>>>> all treat an inactive target node the same way as in the node
> doesn't
>>>>> exist (e.g. delete on an inactive node would return a
> "data-missing"
>>>>> error), this ensures that the behaviour that an unaware client
>>>>> observes is the same as the existing behaviour that it would
> expect
>>>>> from a regular 6241 compliant NETCONF implementation.
>>>>> 4) It a client makes a get request including the "with-inactive"
>>>>> parameter then they also get the inactive nodes as well, marked
> with a
>>>>> meta-data annotation.
>>>>> 5) If a client makes an edit request including the "with-inactive"
>>>>> parameter, then the inactive meta-data annotation can be used to
> label
>>>>> inactive nodes. Inactive nodes are regarded as regular data nodes
> for
>>>>> create/delete/replace/none operation error checking.
>>>>>
>>>>> I think that this approach is similar (perhaps even the same) as
>>>>> Martin described.
>>>> This is indeed how our implementation works (except I think we
> don't
>>>> do 5; if the client sends an "inactive" attribute it doesn't have
> to
>>>> also send with-inactive).
>>>>
>>>>>> Note that the YANG MUST rule still applies, because validation is
> only
>>>>>> done on enabled nodes.
>>>>>> It is only the response message representations that cannot be
>>>>>> validated, not the contents
>>>>>> of  on a server.
>>>> So the question is how we can make sure that the text in the NMDA
>>>> draft covers this yet-to-be-defined feature w/o having to define it
>>>> now? We thought that the current text was sufficient, but do we
> have
>>>> to make any changes to it?
>>> 1) Do we also need to illustrate a similar proof of concept
> templating
>>> implementation to show that templating could work whilst keeping
>>> running valid? I would prefer that this is just deferred to
> whichever
>>> draft defines templating.
>>>
>>> 2) I think that we need to reach a decision as to whether the NMDA
>>> architecture needs to explicitly state that  is always
> valid,
>>> or if that can be left to the existing statement in 7950. My
> thinking
>>> is that if the conclusion is that  must always be valid,
> then
>>> it would be helpful to explicitly state it the descriptions of both
>>>  and  in the NMDA architecture.
>>>
>>> 3) I think that it would be useful to further refine my previous
>>> proposed text for intended, particularly rewriting the text on
>>> validation. This should hopefully also address Balazs' concern about
>>> default values be included in validation.
>>>
>>> 
>>>
>>> 4.4. The Intended Configuration Datastore ()
>>>
>>> The intended configuration datastore () is a read-only
>>> configuration datastore. It is tightly coupled to . When
>>> data is written to , the data that is to be validated is
>>> also conceptually written to . Validation is performed on
>>> the contents of .
>>>
>>> For simple implementations,  and  are identical.
>>>
>>>  does not persist across reboots; its relationship with
>>>  makes that unnecessary.
>>>
>>> Currently there are no standard mechanisms defined that affect
>>>  so that it would have different contents than ,
>>> but this architecture allows for such mechanisms to be defined.
>>>
>>> One example of such a mechanism is support for marking nodes as
>>> inactive in . Inactive nodes are not copied to ,
>>> and are thus not taken into account when validating the
>>> configuration.
>>>
>>> Another example is support for templates. Templates are expanded
>>> when copied into , and the expanded result is validated.
>>>
>>> 
>>> 
>>>
>>> 4.1.4. The Intended Configuration Datastore ()
>>>
>>> The intended configuration datastore () is a read-only
>>> configuration datastore. It represents the configuration after all
>>> configuration transformations to  are performed (e.g.
>>> template expansion, removal of inactive configuration), and is the
>>> configuration that the system attempts to apply.
>>>
>>>  is tightly coupled to . Whenever data is written
>>> to , then  is also immediately updated by
>>> performing all necessary transformations to the contents of
> 
>>> and then  is validated.
>>>
>>>  may also be updated independently of  (e.g., if
>>> one of the configuration transformations is changed), but 
>>> must always be a 'valid configuration data tree' as defined in
>>> Section 8.1 of [RFC7950].
>>>
>>> For simple implementations,  and  are identical.
>>>
>>> The contents of  is also related to the 'config true'
>>> subset of , and hence a client can determine to what
>>> extent the intended configuration is currently in use by checking
>>> whether the contents of  also appears in .
>>>
>>>  does not persist across reboots; its relationship with
>>>  makes that unnecessary.
>>>
>>> Currently there are no standard mechanisms defined that affect
>>>  so that it would have different contents than ,
>>> but this architecture allows for such mechanisms to be defined.
>>>
>>> One example of such a mechanism is support for marking nodes as
>>> inactive in . Inactive nodes are not copied to .
>>> A second example is support for templates, which can perform
>>> transformations on the configuration from  to the
>>> configuration written to .
>>>
>>> 
>>>
>>> Thanks,
>>> Rob
>>>
>>>
>>>>
>>>> /martin
>>>> .
>>>>
>>> .
>>>
> .
>


From nobody Mon Sep 25 02:59:21 2017
Return-Path: 
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 E865713334E for ; Mon, 25 Sep 2017 02:59:19 -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 28EKd4_FPDSD for ; Mon, 25 Sep 2017 02:59: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 3E9E9133344 for ; Mon, 25 Sep 2017 02:59:18 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 7E86A1AE02A7; Mon, 25 Sep 2017 11:59:16 +0200 (CEST)
Date: Mon, 25 Sep 2017 11:57:45 +0200 (CEST)
Message-Id: <20170925.115745.769022803919274339.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <1506006652.6428.57.camel@nic.cz>
References: <87mv5p783v.fsf@nic.cz> <9e3e2d36-f99e-aa9c-844a-d61b3ca20213@cisco.com> <1506006652.6428.57.camel@nic.cz>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Sep 2017 09:59:20 -0000

TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gUm9iZXJ0IFdpbHRvbiBw
w63FoWUgdiDEjHQgMjEuIDA5LiAyMDE3IHYgMTA6MzggKzAxMDA6DQoNClsuLi5dDQoNCj4gPiBZ
ZXMsIEkgYWdyZWUgdGhhdCB0aGlzIHNjZW5hcmlvIGlzIHZlcnkgbGlrZWx5LCBidXQgSSB0aGlu
ayB0aGF0IHRoZSANCj4gPiBzb2x1dGlvbiBoZXJlIGlzIGp1c3QgdG8gbm90IG1hcmsgdGhlIGxl
YWYgYXMgbWFuZGF0b3J5Lg0KPiANCj4gQnV0IHRoaXMgbWFrZXMgdGhlIHNjaGVtYSB3ZWFrZXIs
IGFuZCBpbXBsZW1lbnRvcnMgbWF5IHRoaW5rIGl0IG5lZWRuJ3QgYmUNCj4gaW1wbGVtZW50ZWQu
DQoNCldoZXRoZXIgdGhlICJtYW5kYXRvcnkiIHN0YXRlbWVudCBpcyBwcmVzZW50IG9yIG5vdCBv
biBhIG5vZGUgaGFzDQpub3RoaW5nIHRvIGRvIHdpdGggd2hhdCBhIGRldmljZSBtdXN0IGltcGxl
bWVudC4gICJtYW5kYXRvcnkiIGRvZXMgbm90DQphZmZlY3QgY29uZm9ybWFuY2UuDQoNCkFzIGxv
bmcgYXMgd2UgZG9uJ3QgaGF2ZSBhIG1vcmUgZWxhYm9yYXRlIGNvbmZvcm1hbmNlIG1lY2hhbmlz
bSwgYWxsDQpub2RlcyBpbiBhIG1vZHVsZSAobW9kdWxvIGlmLWZlYXR1cmUpIG11c3QgYmUgaW1w
bGVtZW50ZWQgaW4gb3JkZXIgdG8NCmNsYWltIGNvbmZvcm1hbmNlIHRvIHRoZSBtb2R1bGUuICBU
aGlzIHNhaWQsIHRoZXJlIGNhbiBiZSBjYXNlcyB3aGVyZQ0KImltcGxlbWVudCIgaW4gcmVhbGl0
eSB0cmFuc2xhdGVzIHRvICJuZXZlciByZXR1cm4iLCBiL2MgdGhlDQpjb25kaXRpb25zIHRoYXQg
d291bGQgbWFrZSB0aGUgZGV2aWNlIGluc3RhbnRpYXRlIHRoZSBub2RlIGFyZSBuZXZlcg0KZnVs
ZmlsbGVkLg0KDQoNCg0KL21hcnRpbg0KDQoNCg0KPiANCj4gPiANCj4gPiBJdCBpcyBpbnRlcmVz
dGluZyB0byBjb25zaWRlciB3aGF0ICJtYW5kYXRvcnkiIGV4YWN0bHkgbWVhbnMgaW4gdGhlIA0K
PiA+IDxvcGVyYXRpb25hbD4gZGF0YXN0b3JlLiAgR2l2ZW4gdGhhdCB0aGUgbWFuZGF0b3J5IGNv
bnN0cmFpbnQgbWF5IGJlDQo+IA0KPiBZZXMsIHRoZSBzZW1hbnRpY3MgaW4gdGhlIGNvbnRleHQg
b2YgTk0gcHJvdG9jb2xzIGlzIGRpZmZlcmVudCBmcm9tIHRoYXQgb2YNCj4gY29uZmlndXJhdGlv
biBkYXRhc3RvcmVzLiBCdXQgaW4gdGhlIGNvbnRleHQgb2YgZG9jdW1lbnQgKGRhdGEgdHJlZSkg
dmFsaWRhdGlvbg0KPiBpdCBpcyB0aGUgc2FtZTogdGhlIGluc3RhbmNlIGhhcyB0byBiZSBwcmVz
ZW50IGZvciBhIGRhdGEgdHJlZSB0byBiZSB2YWxpZC4gDQo+IA0KPiA+IHZpb2xhdGVkIGluIDxv
cGVyYXRpb25hbD4sIHRoZW4gbXkgaW50ZXJwcmV0YXRpb24gaXMgdGhhdCBpdCBtZWFucyB0aGF0
IA0KPiA+IGEgY29ycmVjdCBpbXBsZW1lbnRhdGlvbiBTSE9VTEQgYWx3YXlzIHJldHVybiBhIG1h
bmRhdG9yeSBub2RlIChpZiBpdCBpcyANCj4gPiBpbiBzY29wZSkuICBCdXQgYSBjbGllbnQgaGFz
IG5vIHdheSB0byBmb3JjZSBhIGRldmljZSByZXR1cm4gdGhpcyBkYXRhIA0KPiA+IChleGNlcHQg
cGVyaGFwcyBzaG91dGluZyBhdCB0aGUgdmVuZG9yIDotKSwgYW5kIHNvIGl0IHNlZW1zIHRoYXQg
YSANCj4gPiByb2J1c3QgY2xpZW50IHdvdWxkIG5lZWQgdG8gYmUgYWJsZSB0byBjb3BlIHdpdGgg
dGhlIGZhY3QgdGhhdCB0aGUgDQo+ID4gZGV2aWNlIGlzIG5vdCBiZWhhdmluZyBuaWNlbHkgYW5k
IGlzbid0IHJldHVybmluZyB0aGUgZGF0YSByZWdhcmRsZXNzIG9mIA0KPiA+IGFueSBtYW5kYXRv
cnkga2V5d29yZCBzcGVjaWZpZWQgaW4gdGhlIHNjaGVtYS4NCj4gDQo+IEkgZG9uJ3QgcmVhbGx5
IHNoYXJlIHRoaXMgdmlldywgaXQgaXMgSU1PIG5vdCBtdWNoIGRpZmZlcmVudCBmcm9tIHRoZSBz
aXR1YXRpb24NCj4gd2hlbiBhIHZlbmRvciBmYWlscyB0byBpbXBsZW1lbnQgYSBjb25maWcgbm9k
ZS4gRWl0aGVyIHdheSwgdGhlIGltcGxlbWVudGF0aW9uDQo+IGRvZXNuJ3QgY29uZm9ybSB0byB0
aGUgZGF0YSBtb2RlbC4NCj4gDQo+IE9uZSBvZiB0aGUgYmVuZWZpdHMgb2YgYSBkYXRhIG1vZGVs
IGlzIHRoYXQgYW4gYXBwbGljYXRpb24gY2FuIG9mZmxvYWQNCj4gdmFsaWRhdGlvbiB0byBhbiBl
eHRlcm5hbCB0b29sLCBzdWNoIGFzIGEgZ2VuZXJpYyBZQU5HIGxpYnJhcnksIGFuZCB0aGVuIGNh
bg0KPiByZWx5IG9uIGRhdGEgYmVpbmcgdmFsaWQgc28gdGhhdCB0aGUgYXBwbGljYXRpb24ncyBj
b2RlIG5lZWRuJ3QgYmUgY2x1dHRlcmVkDQo+IHdpdGggYWxsIGtpbmRzIG9mIHNhbml0eSBjaGVj
a3MuDQo+IA0KPiBJIGNhbiBpbWFnaW5lIGEgdG9vbCBjb2xsZWN0aW5nIGRhdGEgZnJvbSBhIG51
bWJlciBvZiBkZXZpY2VzIHRoYXQgZmFpbHMgaWYgYQ0KPiBtYW5kYXRvcnkgc3RhdGUgZGF0YSBh
cmUgYWJzZW50LiAgDQo+IA0KPiA+IA0KPiA+IFRvIGZ1cnRoZXIgZXhwYW5kIG9uIHRoaXMsIGEg
ZGV2aWNlIGlzIHJlcXVpcmVkIHRvIGVuc3VyZSB0aGF0IA0KPiA+IGNvbmZpZ3VyYXRpb24gZGF0
YXN0b3JlcyBhcmUgdmFsaWQsIGFuZCBoZW5jZSBhbGwgbWFuZGF0b3J5IGNvbnN0cmFpbnRzIA0K
PiA+IGFyZSBlbmZvcmNlZCwgb3IgYSBjb25maWcgY2hhbmdlIHdvdWxkIGJlIHJlamVjdGVkLCBi
dXQgSSBkb24ndCB0aGluayANCj4gPiB0aGF0IG1hbnkgZGV2aWNlcyBhcmUgZ29pbmcgdG8gdmFs
aWRhdGUgb3BlcmF0aW9uYWwuIFRoZXkgd2lsbCBqdXN0DQo+ID4gcmV0dXJuIHRoZSBjdXJyZW50
IHN0YXRlIG9mIHRoZSBzeXN0ZW0gYmFjayB0byB0aGUgY2xpZW50LCBhbmQgbGV0IHRoZSANCj4g
PiBjbGllbnQgZGVhbCB3aXRoIGFueSB1bmV4cGVjdGVkIGluY29uc2lzdGVuY2llcy4NCj4gDQo+
IEkgY291bGQgbGlrZXdpc2UgZXhwZWN0IHRoZSBzZXJ2ZXIgdG8gYmUgcHJlcGFyZWQgdG8gZGVh
bCB3aXRoIHVuZXhwZWN0ZWQNCj4gaW5jb25zaXN0ZW5jaWVzIGluIGNvbmZpZyBkYXRhLiBUaGUg
ZGF0YSBtb2RlbCBpcyBhIGNvbnRyYWN0LCBzbyBpdCBzaG91bGQgYmUNCj4gYmluZGluZyBmb3Ig
Ym90aCBwYXJ0aWVzLg0KPiANCj4gPiANCj4gPiBBbHNvLCB3aGF0IGFib3V0IGFsbCB0aGUgcmVn
dWxhciBjb25maWcgZmFsc2Ugbm9kZXMgaW4gdGhlIHNjaGVtYSB0aGF0IA0KPiA+IGFyZSBub3Qg
bWFya2VkIGFzIG1hbmRhdG9yeT8gIElzIGEgZGV2aWNlIGFsd2F5cyByZXF1aXJlZCB0byByZXR1
cm4gDQo+ID4gdGhvc2UgbGVhdmVzIChpZiB0aGV5IGFyZSBpbiBzY29wZSk/ICBJZiBhIGRldmlj
ZSBpcyBuZXZlciBnb2luZyB0byANCj4gDQo+IEluIHRlcm1zIG9mIFlBTkcsIG5vLg0KPiANCj4g
PiByZXR1cm4gdGhvc2UgbGVhdmVzIHRoZW4gaXQgc2hvdWxkIHVzZSBhIGRldmlhdGlvbiB0byBy
ZW1vdmUgdGhlbSwgYnV0IA0KPiA+IGlzIHRoYXQgYWN0dWFsbHkgcmVxdWlyZWQ/DQo+ID4gDQo+
ID4gSXMgc2VlbXMgdGhhdCBwb3NzaWJseSB0aGUgbW9zdCB1c2VmdWwgdXNlIG9mIG1hbmRhdG9y
eSBpbiB0aGUgY29udGV4dCANCj4gPiBvZiBvcGVyYXRpb25hbCBpcyBmb3Igc29tZXRoaW5nIGxp
a2UgYW4gSVAgYWRkcmVzcy9wcmVmaXggbGVuZ3RoIA0KPiA+IHBhaXJpbmcsIGkuZS4gdG8gaW5k
aWNhdGUgdGhhdCB0aGUgZGF0YSByZWFsbHkgZG9lc24ndCBtYWtlIGFueSBzZW5zZSANCj4gPiB1
bmxlc3MgYm90aCBhZGRyZXNzIGFuZCBwcmVmaXggYXJlIHByb3ZpZGVkLg0KPiA+IA0KPiA+IFdo
ZW4gdGhlIG5leHQgdmVyc2lvbiBvZiBZQU5HIGlzIHNwZWNpZmllZCwgcGVyaGFwcyB3ZSBzaG91
bGQgY29uc2lkZXIgDQo+ID4gYWxsb3dpbmcgYW4gZXh0cmEgb3B0aW9ucyB0byBtYW5kYXRvcnkg
dG8gdGhhdCBpdCBvbmx5IGFwcGxpZXMgdG8gdGhlIA0KPiA+IHN0YXRlIGRhdGFzdG9yZXM/ICBp
ZiBzbywgd2UgY291bGQgYWRkIHRoaXMgdG8gdGhlIFlBTkcuTmV4dCBpc3N1ZSB0cmFja2VyPw0K
PiANCj4gSSBiZWxpZXZlIHRoZSBmdW5kYW1lbnRhbCBwcm9ibGVtIGlzIHRoYXQgWUFORyB3YXMg
ZGVzaWduZWQgYmFzaWNhbGx5IGFzIGENCj4gZG9jdW1lbnQtb3JpZW50ZWQgc2NoZW1hIGxhbmd1
YWdlLCBhbmQgTk1EQSB0cmllcyB0byBtYWtlIHRoZSBzYW1lIHNjaGVtYSB3b3JrDQo+IGZvciBt
dWx0aXBsZSBkaWZmZXJlbnQgZGF0YSB0cmVlcy4gSSBhbSBjb25jZXJuZWQgdGhpcyBtZWFucyBh
IGxvdCBvZiBjb21wbGV4aXR5DQo+ICBhbmQgQ0xScyB0aGF0IHdpbGwgcmVuZGVyIHRoZSBuZXh0
IHZlcnNpb24gdW51c2FibGUuDQo+IA0KPiBMYWRhDQo+IA0KPiA+IA0KPiA+IFNvLCBpbiBjb25j
bHVzaW9uLCBJIHRoaW5rIHRoYXQgdGhlIE5NREEgbW9kZWxsaW5nIGFkdmljZSBmb3IgbWFuZGF0
b3J5IA0KPiA+IG9uIGNvbmZpZyB0cnVlIG5vZGVzIG1pZ2h0IGJlIHRvIG9ubHkgdXNlIGl0IHdo
ZW4gdGhlIG5vZGUgaXMgbWFuZGF0b3J5IA0KPiA+IGluIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3Jl
cy4NCj4gPiANCj4gPiBJZiB0aGUgV0cgaXNuJ3Qgb3Bwb3NlZCwgdGhlbiBJIHdvdWxkIHN1Z2dl
c3RlZCBhZGRpbmcgdGhpcyB0byB0aGUgTk1EQSBGQVEuDQo+ID4gDQo+ID4gVGhhbmtzLA0KPiA+
IFJvYg0KPiA+IA0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQo+ID4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+
IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+IC0tIA0KPiBM
YWRpc2xhdiBMaG90a2ENCj4gSGVhZCwgQ1ouTklDIExhYnMNCj4gUEdQIEtleSBJRDogMHhCOEY5
MkIwOEE5Rjc2QzY3DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9yZw0KPiBo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K


From nobody Mon Sep 25 04:09:11 2017
Return-Path: 
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 857E3134218 for ; Mon, 25 Sep 2017 04:09:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level: 
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] 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 ZYc10bealKw2 for ; Mon, 25 Sep 2017 04:09:07 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 8E3A0132944 for ; Mon, 25 Sep 2017 04:09:07 -0700 (PDT)
Received: from birdie2 (unknown [IPv6:2001:1488:fffe:6:bc92:1aff:fee1:6813]) by mail.nic.cz (Postfix) with ESMTPSA id CA43062469; Mon, 25 Sep 2017 13:09:05 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1506337745; bh=vEKIQVHeqOMHZARAEl6JCxLxEUludD7fBJtvCtzFDiE=; h=From:To:Date; b=aTC6nawCIQMNQql4F0V2UDOTaNK8+aX2rVqbOkOfhpWgu/2c3znFrLNJeMNuLQKiZ 6DXDfExEO3g/sGFznEUv5+YnyW6V3vzbYDMaNv9UH0pV/VNzSntQQDc4TzscNDCbI0 KjEKawEhEcuTvgg15TDOXpoFyVw8m9GWr8lCG9SI=
Message-ID: <1506337788.14136.12.camel@nic.cz>
From: Ladislav Lhotka 
To: Martin Bjorklund 
Cc: netmod@ietf.org
Date: Mon, 25 Sep 2017 13:09:48 +0200
In-Reply-To: <20170925.115745.769022803919274339.mbj@tail-f.com>
References: <87mv5p783v.fsf@nic.cz> <9e3e2d36-f99e-aa9c-844a-d61b3ca20213@cisco.com> <1506006652.6428.57.camel@nic.cz> <20170925.115745.769022803919274339.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.24.5 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Sep 2017 11:09:10 -0000

Martin Bjorklund píše v Po 25. 09. 2017 v 11:57 +0200:
> Ladislav Lhotka  wrote:
> > Robert Wilton píše v Čt 21. 09. 2017 v 10:38 +0100:
> 
> 
> [...]
> 
> > > Yes, I agree that this scenario is very likely, but I think that the 
> 
> > > solution here is just to not mark the leaf as mandatory.
> 
> > 
> 
> > But this makes the schema weaker, and implementors may think it needn't be
> 
> > implemented.
> 
> 
> Whether the "mandatory" statement is present or not on a node has
> nothing to do with what a device must implement.  "mandatory" does not
> affect conformance.
> 
> As long as we don't have a more elaborate conformance mechanism, all
> nodes in a module (modulo if-feature) must be implemented in order to
> claim conformance to the module.  This said, there can be cases where

Section 5.6 in RFC 7950 describes conformance but I think it neither states nor
implies what you are saying. Specifically (in 5.6.5):

   A server implements a module if it implements the module's data
   nodes, RPCs, actions, notifications, and deviations.

But what does "implements the module's data nodes" exactly mean? My
interpretation is that if a node is optional, then it may or may not be
implemented.

> "implement" in reality translates to "never return", b/c the
> conditions that would make the device instantiate the node are never
> fulfilled.

Right, if a node is optional (with no default) then it may not exist in the data
tree (hence is never returned), and the client isn't able to tell whether it is
internally implemented or not.

Lada

> 
> 
> 
> /martin
> 
> 
> 
> > 
> 
> > > 
> 
> > > It is interesting to consider what "mandatory" exactly means in the 
> 
> > >  datastore.  Given that the mandatory constraint may be
> 
> > 
> 
> > Yes, the semantics in the context of NM protocols is different from that of
> 
> > configuration datastores. But in the context of document (data tree)
> validation
> 
> > it is the same: the instance has to be present for a data tree to be valid. 
> 
> > 
> 
> > > violated in , then my interpretation is that it means that 
> 
> > > a correct implementation SHOULD always return a mandatory node (if it is 
> 
> > > in scope).  But a client has no way to force a device return this data 
> 
> > > (except perhaps shouting at the vendor :-), and so it seems that a 
> 
> > > robust client would need to be able to cope with the fact that the 
> 
> > > device is not behaving nicely and isn't returning the data regardless of 
> 
> > > any mandatory keyword specified in the schema.
> 
> > 
> 
> > I don't really share this view, it is IMO not much different from the
> situation
> 
> > when a vendor fails to implement a config node. Either way, the
> implementation
> 
> > doesn't conform to the data model.
> 
> > 
> 
> > One of the benefits of a data model is that an application can offload
> 
> > validation to an external tool, such as a generic YANG library, and then can
> 
> > rely on data being valid so that the application's code needn't be cluttered
> 
> > with all kinds of sanity checks.
> 
> > 
> 
> > I can imagine a tool collecting data from a number of devices that fails if
> a
> 
> > mandatory state data are absent.  
> 
> > 
> 
> > > 
> 
> > > To further expand on this, a device is required to ensure that 
> 
> > > configuration datastores are valid, and hence all mandatory constraints 
> 
> > > are enforced, or a config change would be rejected, but I don't think 
> 
> > > that many devices are going to validate operational. They will just
> 
> > > return the current state of the system back to the client, and let the 
> 
> > > client deal with any unexpected inconsistencies.
> 
> > 
> 
> > I could likewise expect the server to be prepared to deal with unexpected
> 
> > inconsistencies in config data. The data model is a contract, so it should
> be
> 
> > binding for both parties.
> 
> > 
> 
> > > 
> 
> > > Also, what about all the regular config false nodes in the schema that 
> 
> > > are not marked as mandatory?  Is a device always required to return 
> 
> > > those leaves (if they are in scope)?  If a device is never going to 
> 
> > 
> 
> > In terms of YANG, no.
> 
> > 
> 
> > > return those leaves then it should use a deviation to remove them, but 
> 
> > > is that actually required?
> 
> > > 
> 
> > > Is seems that possibly the most useful use of mandatory in the context 
> 
> > > of operational is for something like an IP address/prefix length 
> 
> > > pairing, i.e. to indicate that the data really doesn't make any sense 
> 
> > > unless both address and prefix are provided.
> 
> > > 
> 
> > > When the next version of YANG is specified, perhaps we should consider 
> 
> > > allowing an extra options to mandatory to that it only applies to the 
> 
> > > state datastores?  if so, we could add this to the YANG.Next issue
> tracker?
> 
> > 
> 
> > I believe the fundamental problem is that YANG was designed basically as a
> 
> > document-oriented schema language, and NMDA tries to make the same schema
> work
> 
> > for multiple different data trees. I am concerned this means a lot of
> complexity
> 
> >  and CLRs that will render the next version unusable.
> 
> > 
> 
> > Lada
> 
> > 
> 
> > > 
> 
> > > So, in conclusion, I think that the NMDA modelling advice for mandatory 
> 
> > > on config true nodes might be to only use it when the node is mandatory 
> 
> > > in configuration datastores.
> 
> > > 
> 
> > > If the WG isn't opposed, then I would suggested adding this to the NMDA
> FAQ.
> 
> > > 
> 
> > > Thanks,
> 
> > > Rob
> 
> > > 
> 
> > > _______________________________________________
> 
> > > netmod mailing list
> 
> > > netmod@ietf.org
> 
> > > https://www.ietf.org/mailman/listinfo/netmod
> 
> > -- 
> 
> > Ladislav Lhotka
> 
> > Head, CZ.NIC Labs
> 
> > PGP Key ID: 0xB8F92B08A9F76C67
> 
> > 
> 
> > _______________________________________________
> 
> > netmod mailing list
> 
> > netmod@ietf.org
> 
> > https://www.ietf.org/mailman/listinfo/netmod
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Mon Sep 25 04:21:34 2017
Return-Path: 
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 385B8134234 for ; Mon, 25 Sep 2017 04:21:33 -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 x_YLmavxIz7W for ; Mon, 25 Sep 2017 04:21:32 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CED6E134218 for ; Mon, 25 Sep 2017 04:21:31 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 7BD171AE02A7; Mon, 25 Sep 2017 13:21:30 +0200 (CEST)
Date: Mon, 25 Sep 2017 13:19:59 +0200 (CEST)
Message-Id: <20170925.131959.1916170593014790430.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <1506337788.14136.12.camel@nic.cz>
References: <1506006652.6428.57.camel@nic.cz> <20170925.115745.769022803919274339.mbj@tail-f.com> <1506337788.14136.12.camel@nic.cz>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7227bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Sep 2017 11:21:33 -0000

TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gTWFydGluIEJqb3JrbHVu
ZCBww63FoWUgdiBQbyAyNS4gMDkuIDIwMTcgdiAxMTo1NyArMDIwMDoNCj4gPiBMYWRpc2xhdiBM
aG90a2EgPGxob3RrYUBuaWMuY3o+IHdyb3RlOg0KPiA+ID4gUm9iZXJ0IFdpbHRvbiBww63FoWUg
diDEjHQgMjEuIDA5LiAyMDE3IHYgMTA6MzggKzAxMDA6DQo+ID4gDQo+ID4gDQo+ID4gWy4uLl0N
Cj4gPiANCj4gPiA+ID4gWWVzLCBJIGFncmVlIHRoYXQgdGhpcyBzY2VuYXJpbyBpcyB2ZXJ5IGxp
a2VseSwgYnV0IEkgdGhpbmsgdGhhdCB0aGUgDQo+ID4gDQo+ID4gPiA+IHNvbHV0aW9uIGhlcmUg
aXMganVzdCB0byBub3QgbWFyayB0aGUgbGVhZiBhcyBtYW5kYXRvcnkuDQo+ID4gDQo+ID4gPiAN
Cj4gPiANCj4gPiA+IEJ1dCB0aGlzIG1ha2VzIHRoZSBzY2hlbWEgd2Vha2VyLCBhbmQgaW1wbGVt
ZW50b3JzIG1heSB0aGluayBpdCBuZWVkbid0IGJlDQo+ID4gDQo+ID4gPiBpbXBsZW1lbnRlZC4N
Cj4gPiANCj4gPiANCj4gPiBXaGV0aGVyIHRoZSAibWFuZGF0b3J5IiBzdGF0ZW1lbnQgaXMgcHJl
c2VudCBvciBub3Qgb24gYSBub2RlIGhhcw0KPiA+IG5vdGhpbmcgdG8gZG8gd2l0aCB3aGF0IGEg
ZGV2aWNlIG11c3QgaW1wbGVtZW50LiAgIm1hbmRhdG9yeSIgZG9lcyBub3QNCj4gPiBhZmZlY3Qg
Y29uZm9ybWFuY2UuDQo+ID4gDQo+ID4gQXMgbG9uZyBhcyB3ZSBkb24ndCBoYXZlIGEgbW9yZSBl
bGFib3JhdGUgY29uZm9ybWFuY2UgbWVjaGFuaXNtLCBhbGwNCj4gPiBub2RlcyBpbiBhIG1vZHVs
ZSAobW9kdWxvIGlmLWZlYXR1cmUpIG11c3QgYmUgaW1wbGVtZW50ZWQgaW4gb3JkZXIgdG8NCj4g
PiBjbGFpbSBjb25mb3JtYW5jZSB0byB0aGUgbW9kdWxlLiAgVGhpcyBzYWlkLCB0aGVyZSBjYW4g
YmUgY2FzZXMgd2hlcmUNCj4gDQo+IFNlY3Rpb24gNS42IGluIFJGQyA3OTUwIGRlc2NyaWJlcyBj
b25mb3JtYW5jZSBidXQgSSB0aGluayBpdCBuZWl0aGVyIHN0YXRlcyBub3INCj4gaW1wbGllcyB3
aGF0IHlvdSBhcmUgc2F5aW5nLiBTcGVjaWZpY2FsbHkgKGluIDUuNi41KToNCj4gDQo+ICAgIEEg
c2VydmVyIGltcGxlbWVudHMgYSBtb2R1bGUgaWYgaXQgaW1wbGVtZW50cyB0aGUgbW9kdWxlJ3Mg
ZGF0YQ0KPiAgICBub2RlcywgUlBDcywgYWN0aW9ucywgbm90aWZpY2F0aW9ucywgYW5kIGRldmlh
dGlvbnMuDQo+IA0KPiBCdXQgd2hhdCBkb2VzICJpbXBsZW1lbnRzIHRoZSBtb2R1bGUncyBkYXRh
IG5vZGVzIiBleGFjdGx5IG1lYW4/DQoNCkl0IG1lYW5zIHRoYXQgdGhlIGRldmljZSBtdXN0IGlt
cGxlbWVudCB3aGF0ZXZlciB0aGUgZGVmaW50aW9uIG9mIHRoYXQNCm5vZGUgc2F5cywgZWl0aGVy
IHdpdGggZm9ybWFsIHN0YXRlbWVudHMgb3IgaW4gdGhlIGRlc2NyaXB0aW9uDQpzdGF0ZW1lbnQu
DQoNCj4gTXkNCj4gaW50ZXJwcmV0YXRpb24gaXMgdGhhdCBpZiBhIG5vZGUgaXMgb3B0aW9uYWws
IHRoZW4gaXQgbWF5IG9yIG1heSBub3QgYmUNCj4gaW1wbGVtZW50ZWQuDQoNCldoaWNoIHRleHQg
c3VwcG9ydHMgdGhpcyBpbnRlcnByZXRhdGlvbj8gIDc5NTAgZG9lc24ndCB1c2UgdGhlIHRlcm0N
CiJvcHRpb25hbCBub2RlIiwgc28gSSBkb24ndCBrbm93IHdoYXQgdGhhdCBpcy4gIFRoZSB0ZXh0
IGFib3V0IHRoZQ0KIm1hbmRhdG9yeSIgc3RhdGVtZW50IGluIDcuNi41IHNheXM6DQoNCiAgIFRo
ZSAibWFuZGF0b3J5IiBzdGF0ZW1lbnQgWy4uLl0gcHV0cyBhIGNvbnN0cmFpbnQgb24gdmFsaWQg
ZGF0YS4NCg0KSXQgZG9lcyBub3Qgc2F5ICIuLi4gbWVhbnMgdGhhdCBhIHNlcnZlciBNVVNUIGlt
cGxlbWVudCB0aGlzIG5vZGUiLg0KDQoNCj4gPiAiaW1wbGVtZW50IiBpbiByZWFsaXR5IHRyYW5z
bGF0ZXMgdG8gIm5ldmVyIHJldHVybiIsIGIvYyB0aGUNCj4gPiBjb25kaXRpb25zIHRoYXQgd291
bGQgbWFrZSB0aGUgZGV2aWNlIGluc3RhbnRpYXRlIHRoZSBub2RlIGFyZSBuZXZlcg0KPiA+IGZ1
bGZpbGxlZC4NCj4gDQo+IFJpZ2h0LCBpZiBhIG5vZGUgaXMgb3B0aW9uYWwgKHdpdGggbm8gZGVm
YXVsdCkgdGhlbiBpdCBtYXkgbm90IGV4aXN0IGluIHRoZSBkYXRhDQo+IHRyZWUgKGhlbmNlIGlz
IG5ldmVyIHJldHVybmVkKSwgYW5kIHRoZSBjbGllbnQgaXNuJ3QgYWJsZSB0byB0ZWxsIHdoZXRo
ZXIgaXQgaXMNCj4gaW50ZXJuYWxseSBpbXBsZW1lbnRlZCBvciBub3QuDQoNCkNvcnJlY3QuDQoN
Cg0KL21hcnRpbg0K


From nobody Mon Sep 25 09:30:17 2017
Return-Path: 
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 B0FBA1344D4 for ; Mon, 25 Sep 2017 09:30:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 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, 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 deevAnmpVrHd for ; Mon, 25 Sep 2017 09:30:07 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD33C1344D5 for ; Mon, 25 Sep 2017 09:30:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4434; q=dns/txt; s=iport; t=1506357005; x=1507566605; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=uzLPC+Cfe4nf1VLKx+q4V/zCpho7F3aI75CsJlnwvgA=; b=TDvRLva+8irDGq5wUEFByDcdGnSODQ7RiDVSHU6LumXZu8pBCotohIDr 48M29bcrzUyqjM1MQqEPeEWu3BslTZGnufFQRZPFhqg81Fsic/I1TJDSr 6Y3xAfzjX/oroH75VUzOHFz950tXfAdyQfydQ4yqLTQfDcF7usry3N0WZ M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbAQCdLslZ/5RdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbicHg2+aG4F2mDwKGAuESU8CGoQdVwECAQEBAQECayiFGQE?= =?us-ascii?q?BAQMBASEEDTobAgEGAhgCAiYCAgIlCxUQAgQBEoozEIoMnWaBbTqLGAEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAR2BDoIdggKGYIUDgxOCYAWMMoUJj2QCh1uMf4JukBi?= =?us-ascii?q?VGQIRGQGBOAFXgQ54FUmHHXaHCIEQAQEB?=
X-IronPort-AV: E=Sophos;i="5.42,437,1500940800";  d="scan'208";a="8379378"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Sep 2017 16:30:05 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v8PGU31w024603 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 25 Sep 2017 16:30:04 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 25 Sep 2017 12:30:03 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Mon, 25 Sep 2017 12:30:03 -0400
From: "Acee Lindem (acee)" 
To: Ladislav Lhotka , "netmod@ietf.org" , Martin Bjorklund 
Thread-Topic: [netmod] Proposal to enhance the YANG tree output
Thread-Index: AQHTLW7ooMSJJm/gdkGnL0U2wTeGA6K0yJQAgAE4cwD///jZAIAP4k6A
Date: Mon, 25 Sep 2017 16:30:03 +0000
Message-ID: 
References: <9d84d068-29ba-8e89-394f-b7f6a5272adc@cisco.com>  <1505470900.18681.0.camel@nic.cz> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.196]
Content-Type: text/plain; charset="utf-8"
Content-ID: <8F1491827B9B4E459076913C5236E6E5@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Sep 2017 16:30:13 -0000

TWFydGluLCBMYWRhLCBldCBhbCwNCg0KV2hpbGUgSSBkb27igJl0IHRoaW5rIHdlIG5lZWQgYWRk
aXRpb25hbCBhbm5vdGF0aW9ucyB0aGF0IEpvZSBoYWQgcHJvdG90eXBlZA0KKGF0IGxlYXN0IG5v
dCBhcyB0aGUgZGVmYXVsdCksIEkgc3Ryb25nbHkgYmVsaWV2ZSB3ZSBuZWVkIHRvIGtlZXAgdGhl
IOKAmEDigJgNCmFuZCDigJgv4oCYIGluIHRoZSB0cmVlIG91dHB1dCBmb3Igc2NoZW1hIG1vdW50
LiBXaGlsZSB0aGUgZm9ybWVyIGVuaGFuY2VtZW50DQpwcm92aWRlZCBkZXRhaWxzLCB0aGUgc2No
ZW1hIG1vdW50IHRyZWUgZGVzaWduYXRpb25zIGFyZSBldmVyeSBiaXQgYXMNCmltcG9ydGFudCBh
cyBrbm93aW5nLCBmb3IgZXhhbXBsZSwgd2hldGhlciBvciBub3QgYSBzY2hlbWEgbGVhZiBpcyBh
DQpwcmVzZW5jZSBub2RlLiANCg0KVGhhbmtzLA0KQWNlZSANCg0KDQpPbiA5LzE1LzE3LCA5OjU2
IEFNLCAiQWNlZSBMaW5kZW0gKGFjZWUpIiA8YWNlZUBjaXNjby5jb20+IHdyb3RlOg0KDQo+KzEg
LSBBbHNvIGl0IGlzIGhhcmQgZW5vdWdoIHRvIGZvcm1hdCB0aGUgdHJlZSBvdXRwdXQgdG8gZml0
IGluIGEgZHJhZnQNCj53L28gZnVydGhlciBhbm5vdGF0aW9ucyAoZXZlbiB3aXRoIOKAlC10cmVl
LWxpbmUtbGVuZ3RoKS4NCj5UaGFua3MsDQo+QWNlZQ0KPg0KPg0KPk9uIDkvMTUvMTcsIDY6MjEg
QU0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIExhZGlzbGF2IExob3RrYSINCj48bmV0bW9kLWJvdW5j
ZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGxob3RrYUBuaWMuY3o+IHdyb3RlOg0KPg0KPj5BbmR5
IEJpZXJtYW4gcMOtxaFlIHYgxIx0IDE0LiAwOS4gMjAxNyB2IDA4OjQzIC0wNzAwOg0KPj4+IEhp
LA0KPj4+IA0KPj4+IA0KPj4+IEFjdHVhbGx5IEkgbGlrZWQgdGhlIGVhcmx5IHB5YW5nIG91dHB1
dCB0aGF0IHdhcyBjb25jaXNlIGFuZCBlYXN5IHRvDQo+Pj5yZW1lbWJlci4NCj4+PiBUaGUgY3Vy
cmVudCBmb3JtYXQgZ2V0cyB2ZXJ5IGNsdXR0ZXJlZCBhbmQgdGhlcmUgYXJlIHRvbyBtYW55IGxp
dHRsZQ0KPj4+c3ltYm9scw0KPj4+IHRvIHJlbWVtYmVyIHRoZW0gYWxsLg0KPj4NCj4+SSBhZ3Jl
ZS4NCj4+DQo+PkxhZGENCj4+DQo+Pj4gDQo+Pj4gDQo+Pj4gQW5keQ0KPj4+IA0KPj4+IA0KPj4+
IE9uIFRodSwgU2VwIDE0LCAyMDE3IGF0IDg6MzMgQU0sIEpvZSBDbGFya2UgPGpjbGFya2VAY2lz
Y28uY29tPiB3cm90ZToNCj4+PiA+IEkndmUgYmVlbiBoYWNraW5nIG9uIHB5YW5nLCBhbmQgSSBj
aGFuZ2VkIHRyZWUucHkgdG8gYWRkIHRoZSBlbnVtDQo+Pj52YWx1ZXMNCj4+PiA+IGZvciBlbnVt
ZXJhdGlvbiB0eXBlcyBhbmQgaWRlbnRpeXJlZiBiYXNlcyBmb3IgaWRlbnRpdHlyZWYgdHlwZXMu
DQo+Pj5IZXJlDQo+Pj4gPiBpcyBhbiBleGFtcGxlOg0KPj4+ID4gDQo+Pj4gPiBtb2R1bGU6IHlh
bmctY2F0YWxvZw0KPj4+ID4gICAgICstLXJ3IGNhdGFsb2cNCj4+PiA+ICAgICAgICArLS1ydyBt
b2R1bGVzDQo+Pj4gPiAgICAgICAgfCAgKy0tcncgbW9kdWxlKiBbbmFtZSByZXZpc2lvbiBvcmdh
bml6YXRpb25dDQo+Pj4gPiAgICAgICAgfCAgICAgKy0tcncgbmFtZSAgICAgICAgICAgICAgICAg
ICAgIHlhbmc6eWFuZy1pZGVudGlmaWVyDQo+Pj4gPiAgICAgICAgfCAgICAgKy0tcncgcmV2aXNp
b24gICAgICAgICAgICAgICAgIHVuaW9uDQo+Pj4gPiAgICAgICAgfCAgICAgKy0tcncgb3JnYW5p
emF0aW9uICAgICAgICAgICAgIHN0cmluZw0KPj4+ID4gICAgICAgIHwgICAgICstLXJ3IGlldGYN
Cj4+PiA+ICAgICAgICB8ICAgICB8ICArLS1ydyBpZXRmLXdnPyAgIHN0cmluZw0KPj4+ID4gICAg
ICAgIHwgICAgICstLXJ3IG5hbWVzcGFjZSAgICAgICAgICAgICAgICBpbmV0OnVyaQ0KPj4+ID4g
ICAgICAgIHwgICAgICstLXJ3IHNjaGVtYT8gICAgICAgICAgICAgICAgICBpbmV0OnVyaQ0KPj4+
ID4gICAgICAgIHwgICAgICstLXJ3IGdlbmVyYXRlZC1mcm9tPyAgICAgICAgICBlbnVtZXJhdGlv
biBbbWliLCBjb2RlLA0KPj4+ID4gbm90LWFwcGxpY2FibGUsIG5hdGl2ZV0NCj4+PiA+ICAgICAg
ICB8ICAgICArLS1ydyBtYXR1cml0eS1sZXZlbD8gICAgICAgICAgZW51bWVyYXRpb24gW3JhdGlm
aWVkLA0KPj4+ID4gYWRvcHRlZCwgaW5pdGlhbCwgbm90LWFwcGxpY2FibGVdDQo+Pj4gPiAuLi4N
Cj4+PiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS1ydyBwcm90b2NvbHMNCj4+
PiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICArLS1ydyBwcm90b2NvbCogW25h
bWVdDQo+Pj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgKy0tcncgbmFt
ZQ0KPj4+ID4gaWRlbnRpdHlyZWYgLT4gcHJvdG9jb2wNCj4+PiA+IC4uLg0KPj4+ID4gDQo+Pj4g
PiBNeSBxdWVzdGlvbnMgYXJlOg0KPj4+ID4gDQo+Pj4gPiAxLiBJcyB0aGlzIHVzZWZ1bD8NCj4+
PiA+IA0KPj4+ID4gMi4gSWYgc28sIGNhbiB0aGlzIGJlIGFkZGVkIHRvIHB5YW5nIChoYXBweSB0
byBzdWJtaXQgYSBQUikgYW5kDQo+Pj4gPiBkcmFmdC1pZXRmLW5ldG1vZC15YW5nLXRyZWUtZGlh
Z3JhbXM/DQo+Pj4gPiANCj4+PiA+IDMuIFdoYXQgY2hhbmdlcyB0byB0aGUgb3V0cHV0IGZvcm1h
dCB3b3VsZCB5b3UgcmVjb21tZW5kPw0KPj4+ID4gDQo+Pj4gPiBUaGFua3MuDQo+Pj4gPiANCj4+
PiA+IEpvZQ0KPj4+ID4gDQo+Pj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KPj4+ID4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4+ID4gbmV0bW9kQGll
dGYub3JnDQo+Pj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1v
ZA0KPj4+IA0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQo+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4+IG5ldG1vZEBpZXRmLm9yZw0KPj4+IGh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+Pi0tIA0KPj5MYWRp
c2xhdiBMaG90a2ENCj4+SGVhZCwgQ1ouTklDIExhYnMNCj4+UEdQIEtleSBJRDogMHhCOEY5MkIw
OEE5Rjc2QzY3DQo+Pg0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KPj5uZXRtb2QgbWFpbGluZyBsaXN0DQo+Pm5ldG1vZEBpZXRmLm9yZw0KPj5odHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPg0KDQo=


From nobody Mon Sep 25 09:54:06 2017
Return-Path: 
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 081F31344E7 for ; Mon, 25 Sep 2017 09:54:05 -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 lVPGZC3fbZ1R for ; Mon, 25 Sep 2017 09:54:03 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A514A1344CA for ; Mon, 25 Sep 2017 09:54:02 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML713-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPG99195; Mon, 25 Sep 2017 16:54:00 +0000 (GMT)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 25 Sep 2017 17:53:59 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.175]) by SJCEML702-CHM.china.huawei.com ([169.254.4.207]) with mapi id 14.03.0301.000;  Mon, 25 Sep 2017 09:53:54 -0700
From: Yingzhen Qu 
To: "Acee Lindem (acee)" , Lou Berger , Ladislav Lhotka 
CC: NetMod WG 
Thread-Topic: Regarding IPR on draft-acee-netmod-rfc8022bis-02
Thread-Index: AQHTMITQ6AtnCHKMEkeL0SOK/jhJHKK7H+wAgAq8p6A=
Date: Mon, 25 Sep 2017 16:53:53 +0000
Message-ID: <594D005A3CB0724DB547CF3E9A9E810BF15A5A@sjceml521-mbx.china.huawei.com>
References: <7205a700-f00a-13f1-1941-46d578e38a27@labn.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.213.49.36]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59C934A8.01BA, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.1.175, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: c4d7d35b10a71b9d7881fce2e22acc9f
Archived-At: 
Subject: Re: [netmod] Regarding IPR on draft-acee-netmod-rfc8022bis-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Sep 2017 16:54:05 -0000

Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdC4N
Cg0KDQpUaGFua3MsDQpZaW5nemhlbg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv
bTogQWNlZSBMaW5kZW0gKGFjZWUpIFttYWlsdG86YWNlZUBjaXNjby5jb21dIA0KU2VudDogTW9u
ZGF5LCBTZXB0ZW1iZXIgMTgsIDIwMTcgNjo1NiBBTQ0KVG86IExvdSBCZXJnZXIgPGxiZXJnZXJA
bGFibi5uZXQ+OyBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBuaWMuY3o+OyBZaW5nemhlbiBRdSA8
eWluZ3poZW4ucXVAaHVhd2VpLmNvbT4NCkNjOiBOZXRNb2QgV0cgPG5ldG1vZEBpZXRmLm9yZz4N
ClN1YmplY3Q6IFJlOiBSZWdhcmRpbmcgSVBSIG9uIGRyYWZ0LWFjZWUtbmV0bW9kLXJmYzgwMjJi
aXMtMDINCg0KQXMgYSBjby1hdXRob3IsIA0KDQpObywgSSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBS
IHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Lg0KDQoNClRoYW5rcywNCkFjZWUgDQoNCk9uIDkv
MTgvMTcsIDk6NDggQU0sICJMb3UgQmVyZ2VyIiA8bGJlcmdlckBsYWJuLm5ldD4gd3JvdGU6DQoN
Cj5BdXRob3JzLCBDb250cmlidXRvcnMsIFdHLA0KPg0KPkFzIHBhcnQgb2YgdGhlIHByZXBhcmF0
aW9uIGZvciBXRyBMYXN0IENhbGw6DQo+DQo+QXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQg
YXBwbGllcyB0byBkcmFmdHMgaWRlbnRpZmllZCBhYm92ZT8NCj4NCj5QbGVhc2Ugc3RhdGUgZWl0
aGVyOg0KPg0KPiJObywgSSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0
aGlzIGRyYWZ0Ig0KPm9yDQo+IlllcywgSSdtIGF3YXJlIG9mIElQUiB0aGF0IGFwcGxpZXMgdG8g
dGhpcyBkcmFmdCINCj4NCj5JZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNv
bXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyANCj4oc2VlIFJGQ3MgMzY2OSwgNTM3OCBhbmQg
ODE3OSBmb3IgbW9yZSBkZXRhaWxzKT8NCj4NCj5JZiB5ZXMgdG8gdGhlIGFib3ZlLCBwbGVhc2Ug
c3RhdGUgZWl0aGVyOg0KPg0KPiJZZXMsIHRoZSBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNv
bXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyINCj5vcg0KPiJObywgdGhlIElQUiBoYXMgbm90
IGJlZW4gZGlzY2xvc2VkIg0KPg0KPklmIHlvdSBhbnN3ZXIgbm8sIHBsZWFzZSBwcm92aWRlIGFu
eSBhZGRpdGlvbmFsIGRldGFpbHMgeW91IHRoaW5rIA0KPmFwcHJvcHJpYXRlLg0KPg0KPklmIHlv
dSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSBh
bnN3ZXIgdGhlIA0KPmFib3ZlIGJ5IHJlc3BvbmRpbmcgdG8gdGhpcyBlbWFpbCByZWdhcmRsZXNz
IG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgDQo+YXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4g
VGhpcyBkb2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IA0KPnN0YWdlIHVudGls
IGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgbGlzdGVk
IA0KPmNvbnRyaWJ1dG9yLiBOT1RFOiBUSElTIEFQUExJRVMgVE8gQUxMIE9GIFlPVSBMSVNURUQg
SU4gVEhJUyBNRVNTQUdFJ1MgDQo+VE8gTElORVMuDQo+DQo+SWYgeW91IGFyZSBvbiB0aGUgV0cg
ZW1haWwgbGlzdCBvciBhdHRlbmQgV0cgbWVldGluZ3MgYnV0IGFyZSBub3QgDQo+bGlzdGVkIGFz
IGFuIGF1dGhvciBvciBjb250cmlidXRvciwgd2UgcmVtaW5kIHlvdSBvZiB5b3VyIG9ibGlnYXRp
b25zIA0KPnVuZGVyIHRoZSBJRVRGIElQUiBydWxlcyB3aGljaCBlbmNvdXJhZ2VzIHlvdSB0byBu
b3RpZnkgdGhlIElFVEYgaWYgeW91IA0KPmFyZSBhd2FyZSBvZiBJUFIgb2Ygb3RoZXJzIG9uIGFu
IElFVEYgY29udHJpYnV0aW9uLCBvciB0byByZWZyYWluIGZyb20gDQo+cGFydGljaXBhdGluZyBp
biBhbnkgY29udHJpYnV0aW9uIG9yIGRpc2N1c3Npb24gcmVsYXRlZCB0byB5b3VyIA0KPnVuZGlz
Y2xvc2VkIElQUi4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIFJGQ3MgbGlz
dGVkIGFib3ZlIA0KPmFuZCANCj5odHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9ncm91cC9pZXNn
L3RyYWMvd2lraS9JbnRlbGxlY3R1YWxQcm9wZXJ0eS4NCj4NCj5UaGFuayB5b3UsDQo+TmV0TW9k
IFdHIENoYWlycw0KPg0KPlBTIFBsZWFzZSBpbmNsdWRlIGFsbCBsaXN0ZWQgaW4gdGhlIGhlYWRl
cnMgb2YgdGhpcyBtZXNzYWdlIGluIHlvdXIgDQo+cmVzcG9uc2UuDQo+DQo+DQo+DQoNCg==


From nobody Mon Sep 25 10:36:53 2017
Return-Path: 
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 C05E0134515 for ; Mon, 25 Sep 2017 10:36:51 -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=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 xTdUPjpfvfNX for ; Mon, 25 Sep 2017 10:36:42 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3BC1320CF for ; Mon, 25 Sep 2017 10:36:42 -0700 (PDT)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 7D8461AE02A7; Mon, 25 Sep 2017 19:36:41 +0200 (CEST)
Date: Mon, 25 Sep 2017 19:39:03 +0200 (CEST)
Message-Id: <20170925.193903.1777711656523405872.mbj@tail-f.com>
To: acee@cisco.com
Cc: lhotka@nic.cz, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <1505470900.18681.0.camel@nic.cz>  
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Sep 2017 17:36:52 -0000

IkFjZWUgTGluZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29tPiB3cm90ZToNCj4gTWFydGluLCBM
YWRhLCBldCBhbCwNCj4gDQo+IFdoaWxlIEkgZG9u4oCZdCB0aGluayB3ZSBuZWVkIGFkZGl0aW9u
YWwgYW5ub3RhdGlvbnMgdGhhdCBKb2UgaGFkIHByb3RvdHlwZWQNCj4gKGF0IGxlYXN0IG5vdCBh
cyB0aGUgZGVmYXVsdCksIEkgc3Ryb25nbHkgYmVsaWV2ZSB3ZSBuZWVkIHRvIGtlZXAgdGhlIOKA
mEDigJgNCj4gYW5kIOKAmC/igJggaW4gdGhlIHRyZWUgb3V0cHV0IGZvciBzY2hlbWEgbW91bnQu
DQoNCkNhbiB5b3UgZXhwbGFpbiB3aGF0IGluZm9ybWF0aW9uICIvIiBnaXZlcyB0aGUgcmVhZGVy
PyAgQ29tcGFyZSB0aGVzZQ0KdHdvIHRyZWVzOg0KDQogICstLW1wIHZyZi1yb290DQogICAgICst
LXJ3IHJ0OnJvdXRpbmcvDQogICAgICAgICstLXJ3IHJ0OnJvdXRlci1pZA0KDQphbmQNCg0KICAr
LS1tcCB2cmYtcm9vdA0KICAgICArLS1ydyBydDpyb3V0aW5nDQogICAgICAgICstLXJ3IHJ0OnJv
dXRlci1pZA0KDQpXaGF0IGRpZCB0aGUgIi8iIGluIHRoZSBmaXJzdCB0cmVlIHRlbGwgbWUgdGhh
dCBJIGRvbid0IHNlZSBpbiB0aGUNCnNlY29uZCB0cmVlPw0KDQoNCg0KVGhlbiBjb25zaWRlcjoN
Cg0KICArLS1ybyBpZjppbnRlcmZhY2VzQA0KDQphbmQNCg0KICArLS1ybyBpZjppbnRlcmZhY2Vz
DQogICAgICstLSBpZjppbnRlcmZhY2VADQoNCmFuZA0KDQogICstLXJvIGlmOmludGVyZmFjZXNA
DQogICAgICstLSBpZjppbnRlcmZhY2VADQogICAgIA0KDQpXaGljaCBvbmVzIGFyZSBsZWdhbCwg
YW5kIHdoYXQgZG8gdGhleSBtZWFuPw0KDQoNCg0KL21hcnRpbg0KDQpXaGlsZSB0aGUgZm9ybWVy
IGVuaGFuY2VtZW50DQo+IHByb3ZpZGVkIGRldGFpbHMsIHRoZSBzY2hlbWEgbW91bnQgdHJlZSBk
ZXNpZ25hdGlvbnMgYXJlIGV2ZXJ5IGJpdCBhcw0KPiBpbXBvcnRhbnQgYXMga25vd2luZywgZm9y
IGV4YW1wbGUsIHdoZXRoZXIgb3Igbm90IGEgc2NoZW1hIGxlYWYgaXMgYQ0KPiBwcmVzZW5jZSBu
b2RlLiANCj4gDQo+IFRoYW5rcywNCj4gQWNlZSANCj4gDQo+IA0KPiBPbiA5LzE1LzE3LCA5OjU2
IEFNLCAiQWNlZSBMaW5kZW0gKGFjZWUpIiA8YWNlZUBjaXNjby5jb20+IHdyb3RlOg0KPiANCj4g
PisxIC0gQWxzbyBpdCBpcyBoYXJkIGVub3VnaCB0byBmb3JtYXQgdGhlIHRyZWUgb3V0cHV0IHRv
IGZpdCBpbiBhIGRyYWZ0DQo+ID53L28gZnVydGhlciBhbm5vdGF0aW9ucyAoZXZlbiB3aXRoIOKA
lC10cmVlLWxpbmUtbGVuZ3RoKS4NCj4gPlRoYW5rcywNCj4gPkFjZWUNCj4gPg0KPiA+DQo+ID5P
biA5LzE1LzE3LCA2OjIxIEFNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBMYWRpc2xhdiBMaG90a2Ei
DQo+ID48bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGxob3RrYUBuaWMuY3o+
IHdyb3RlOg0KPiA+DQo+ID4+QW5keSBCaWVybWFuIHDDrcWhZSB2IMSMdCAxNC4gMDkuIDIwMTcg
diAwODo0MyAtMDcwMDoNCj4gPj4+IEhpLA0KPiA+Pj4gDQo+ID4+PiANCj4gPj4+IEFjdHVhbGx5
IEkgbGlrZWQgdGhlIGVhcmx5IHB5YW5nIG91dHB1dCB0aGF0IHdhcyBjb25jaXNlIGFuZCBlYXN5
IHRvDQo+ID4+PnJlbWVtYmVyLg0KPiA+Pj4gVGhlIGN1cnJlbnQgZm9ybWF0IGdldHMgdmVyeSBj
bHV0dGVyZWQgYW5kIHRoZXJlIGFyZSB0b28gbWFueSBsaXR0bGUNCj4gPj4+c3ltYm9scw0KPiA+
Pj4gdG8gcmVtZW1iZXIgdGhlbSBhbGwuDQo+ID4+DQo+ID4+SSBhZ3JlZS4NCj4gPj4NCj4gPj5M
YWRhDQo+ID4+DQo+ID4+PiANCj4gPj4+IA0KPiA+Pj4gQW5keQ0KPiA+Pj4gDQo+ID4+PiANCj4g
Pj4+IE9uIFRodSwgU2VwIDE0LCAyMDE3IGF0IDg6MzMgQU0sIEpvZSBDbGFya2UgPGpjbGFya2VA
Y2lzY28uY29tPiB3cm90ZToNCj4gPj4+ID4gSSd2ZSBiZWVuIGhhY2tpbmcgb24gcHlhbmcsIGFu
ZCBJIGNoYW5nZWQgdHJlZS5weSB0byBhZGQgdGhlIGVudW0NCj4gPj4+dmFsdWVzDQo+ID4+PiA+
IGZvciBlbnVtZXJhdGlvbiB0eXBlcyBhbmQgaWRlbnRpeXJlZiBiYXNlcyBmb3IgaWRlbnRpdHly
ZWYgdHlwZXMuDQo+ID4+PkhlcmUNCj4gPj4+ID4gaXMgYW4gZXhhbXBsZToNCj4gPj4+ID4gDQo+
ID4+PiA+IG1vZHVsZTogeWFuZy1jYXRhbG9nDQo+ID4+PiA+ICAgICArLS1ydyBjYXRhbG9nDQo+
ID4+PiA+ICAgICAgICArLS1ydyBtb2R1bGVzDQo+ID4+PiA+ICAgICAgICB8ICArLS1ydyBtb2R1
bGUqIFtuYW1lIHJldmlzaW9uIG9yZ2FuaXphdGlvbl0NCj4gPj4+ID4gICAgICAgIHwgICAgICst
LXJ3IG5hbWUgICAgICAgICAgICAgICAgICAgICB5YW5nOnlhbmctaWRlbnRpZmllcg0KPiA+Pj4g
PiAgICAgICAgfCAgICAgKy0tcncgcmV2aXNpb24gICAgICAgICAgICAgICAgIHVuaW9uDQo+ID4+
PiA+ICAgICAgICB8ICAgICArLS1ydyBvcmdhbml6YXRpb24gICAgICAgICAgICAgc3RyaW5nDQo+
ID4+PiA+ICAgICAgICB8ICAgICArLS1ydyBpZXRmDQo+ID4+PiA+ICAgICAgICB8ICAgICB8ICAr
LS1ydyBpZXRmLXdnPyAgIHN0cmluZw0KPiA+Pj4gPiAgICAgICAgfCAgICAgKy0tcncgbmFtZXNw
YWNlICAgICAgICAgICAgICAgIGluZXQ6dXJpDQo+ID4+PiA+ICAgICAgICB8ICAgICArLS1ydyBz
Y2hlbWE/ICAgICAgICAgICAgICAgICAgaW5ldDp1cmkNCj4gPj4+ID4gICAgICAgIHwgICAgICst
LXJ3IGdlbmVyYXRlZC1mcm9tPyAgICAgICAgICBlbnVtZXJhdGlvbiBbbWliLCBjb2RlLA0KPiA+
Pj4gPiBub3QtYXBwbGljYWJsZSwgbmF0aXZlXQ0KPiA+Pj4gPiAgICAgICAgfCAgICAgKy0tcncg
bWF0dXJpdHktbGV2ZWw/ICAgICAgICAgIGVudW1lcmF0aW9uIFtyYXRpZmllZCwNCj4gPj4+ID4g
YWRvcHRlZCwgaW5pdGlhbCwgbm90LWFwcGxpY2FibGVdDQo+ID4+PiA+IC4uLg0KPiA+Pj4gPiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tcncgcHJvdG9jb2xzDQo+ID4+PiA+ICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICArLS1ydyBwcm90b2NvbCogW25hbWVdDQo+
ID4+PiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICArLS1ydyBuYW1lDQo+
ID4+PiA+IGlkZW50aXR5cmVmIC0+IHByb3RvY29sDQo+ID4+PiA+IC4uLg0KPiA+Pj4gPiANCj4g
Pj4+ID4gTXkgcXVlc3Rpb25zIGFyZToNCj4gPj4+ID4gDQo+ID4+PiA+IDEuIElzIHRoaXMgdXNl
ZnVsPw0KPiA+Pj4gPiANCj4gPj4+ID4gMi4gSWYgc28sIGNhbiB0aGlzIGJlIGFkZGVkIHRvIHB5
YW5nIChoYXBweSB0byBzdWJtaXQgYSBQUikgYW5kDQo+ID4+PiA+IGRyYWZ0LWlldGYtbmV0bW9k
LXlhbmctdHJlZS1kaWFncmFtcz8NCj4gPj4+ID4gDQo+ID4+PiA+IDMuIFdoYXQgY2hhbmdlcyB0
byB0aGUgb3V0cHV0IGZvcm1hdCB3b3VsZCB5b3UgcmVjb21tZW5kPw0KPiA+Pj4gPiANCj4gPj4+
ID4gVGhhbmtzLg0KPiA+Pj4gPiANCj4gPj4+ID4gSm9lDQo+ID4+PiA+IA0KPiA+Pj4gPiBfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4gPiBuZXRt
b2QgbWFpbGluZyBsaXN0DQo+ID4+PiA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+Pj4gPiBodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiA+Pj4gDQo+ID4+PiBfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4gbmV0bW9k
IG1haWxpbmcgbGlzdA0KPiA+Pj4gbmV0bW9kQGlldGYub3JnDQo+ID4+PiBodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiA+Pi0tIA0KPiA+PkxhZGlzbGF2IExo
b3RrYQ0KPiA+PkhlYWQsIENaLk5JQyBMYWJzDQo+ID4+UEdQIEtleSBJRDogMHhCOEY5MkIwOEE5
Rjc2QzY3DQo+ID4+DQo+ID4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCj4gPj5uZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4+bmV0bW9kQGlldGYub3JnDQo+
ID4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gPg0KPiAN
Cg==


From nobody Mon Sep 25 19:57:07 2017
Return-Path: 
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 65A4113219E for ; Mon, 25 Sep 2017 19:57:02 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 8p4K3RvbvW6z for ; Mon, 25 Sep 2017 19:56:57 -0700 (PDT)
Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 68168132D44 for ; Mon, 25 Sep 2017 19:56:57 -0700 (PDT)
Received: by mail-oi0-x22c.google.com with SMTP id p126so9960601oih.9 for ; Mon, 25 Sep 2017 19:56:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=qVY77SGLfqx9B3NGVo/GaGWV5wOtaUtmY6YAB+XY5MU=; b=gkLqNjxIJ/fRFttn+4hmwDYk841Yebo8nxnLodCV/U5Lia8n2GSAXqtJgDQqnLhHvW uID1oSOhtH+OcXu5iu7Y/YuJZ8Vr+XV2SSFMDzQEJ2tpyVcPZB1+yt8C85VqQ/pQ1evQ rJjnmEdF5+qYpnPdT2JKfpFUCXtXZhdKjikZjsMX/x7O2nNlOXBZkJi5eyGYBHZgdLDp QdHrX1NswWgSnLHtRy90XhiGh7MfroVL1oeiDA8PDbNl+S+80/ojBMvt0AYRzdymDgwm quUoKf6osXZpM/oB/6iz2VcZoRsAubOKBfAQxjWUbZ5Dd8ENv4kBjq9F1inBPYA2rU0A y+Yg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=qVY77SGLfqx9B3NGVo/GaGWV5wOtaUtmY6YAB+XY5MU=; b=WJdypzZ4XfzyVLybgJRl0KqqJoZZK+KmOUGVSBwzuQc9+IFxzwPkbszvazcfCWbOZu /y6DXbS64Y/sauA2frTkmNatbUZQOeNBhE714AURA4jN4UsaMqR2TXgRVF4dXHFOGHNS 6OIqDf8pdbIyn7SUYuaQ5jn/uwESzRZOz4yN18aHHk9yRM+mYB2hn5aBwbWLYBpWh2Cw B+nZm6klNPCr8O/2HgTwdrADt1fMJC2Tk83KEozVX7/KSlTTVWBHRu6oCRuoRwpovkiL HEj2kd0LLNuW4N8N3LIzIXPYPpxiOBLVXmgjHQu+RpShr/KL2TdgCsYeThqrb1xBxMDm 5z6w==
X-Gm-Message-State: AHPjjUhffajyw7GWzeZ+auZoFhuzDaQ7A8obpaih05gvYxeuL9lUhEMj Btlm4jUX7W4iJcvKrVSB/Hc=
X-Google-Smtp-Source: AOwi7QCC/aNLMVEP0ij6W38uQC5Q24JnMTnkAS/OWHc9DBV7DilaAyOH01Yhnoq2csC37eMy4C50eg==
X-Received: by 10.202.107.9 with SMTP id g9mr7948015oic.144.1506394616791; Mon, 25 Sep 2017 19:56:56 -0700 (PDT)
Received: from xliuus (ip72-209-195-86.dc.dc.cox.net. [72.209.195.86]) by smtp.gmail.com with ESMTPSA id n13sm703867ote.29.2017.09.25.19.56.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Sep 2017 19:56:56 -0700 (PDT)
From: "Xufeng Liu" 
To: "'Martin Bjorklund'" , 
Cc: 
References: <1505470900.18681.0.camel@nic.cz>   <20170925.193903.1777711656523405872.mbj@tail-f.com>
In-Reply-To: <20170925.193903.1777711656523405872.mbj@tail-f.com>
Date: Mon, 25 Sep 2017 22:56:54 -0400
Message-ID: <005601d33673$1d27c180$57774480$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKwBGEFaMxUg+s4xnRBAtCiCR/z3QMcvPuxAYzk5ZACS8EYQ6DVMLPw
Content-Language: en-us
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Sep 2017 02:57:02 -0000

To a user of the schema-mount, it is important to be able to visualize =
all key elements of the mounting mechanism: mount-point, mounted schema =
module, and parent-reference. The details can be worked out, but if any =
of these elements were not useful in the presentation, it would be =
questionable whether it had well-specified in the schema mount draft.

> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Martin
> Bjorklund
> Sent: Monday, September 25, 2017 1:39 PM
> To: acee@cisco.com
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Proposal to enhance the YANG tree output
>=20
> "Acee Lindem (acee)"  wrote:
> > Martin, Lada, et al,
> >
> > While I don=E2=80=99t think we need additional annotations that Joe =
had
> > prototyped (at least not as the default), I strongly believe we need
> > to keep the =E2=80=98@=E2=80=98 and =E2=80=98/=E2=80=98 in the tree =
output for schema mount.
>=20
> Can you explain what information "/" gives the reader?  Compare these =
two
> trees:
>=20
>   +--mp vrf-root
>      +--rw rt:routing/
>         +--rw rt:router-id
>=20
> and
>=20
>   +--mp vrf-root
>      +--rw rt:routing
>         +--rw rt:router-id
>=20
> What did the "/" in the first tree tell me that I don't see in the =
second tree?

[Xufeng] Because the schema mount draft allows an augmenting module not =
to be listed in the mounted schema list. The following two examples show =
two different configurations:

  +--mp root
     +--rw rt:routing/
     |  +--rw router-id?                 yang:dotted-quad
     |  +--rw control-plane-protocols
     |     +--rw control-plane-protocol* [type name]
     |        +--rw ospf:ospf/

where ospf augments rt, and has been listed in the mounting schema list.

  +--mp root
     +--rw rt:routing/
     |  +--rw router-id?                 yang:dotted-quad
     |  +--rw control-plane-protocols
     |     +--rw control-plane-protocol* [type name]
     |        +--rw ospf:ospf

where ospf augments rt, and has not been listed in the mounting schema =
list.


>=20
>=20
>=20
> Then consider:
>=20
>   +--ro if:interfaces@
>=20
> and
>=20
>   +--ro if:interfaces
>      +-- if:interface@
>=20
> and
>=20
>   +--ro if:interfaces@
>      +-- if:interface@
>=20
>=20
> Which ones are legal, and what do they mean?
>=20
[Xufeng] The display shows the result of the XPath, right? Whether they =
are legal or not should be determined by the schema-mount draft, not by =
the displaying notation.

>=20
>=20
> /martin
>=20
> While the former enhancement
> > provided details, the schema mount tree designations are every bit =
as
> > important as knowing, for example, whether or not a schema leaf is a
> > presence node.
> >
> > Thanks,
> > Acee
> >
> >
> > On 9/15/17, 9:56 AM, "Acee Lindem (acee)"  wrote:
> >
> > >+1 - Also it is hard enough to format the tree output to fit in a
> > >+draft
> > >w/o further annotations (even with =E2=80=94-tree-line-length).
> > >Thanks,
> > >Acee
> > >
> > >
> > >On 9/15/17, 6:21 AM, "netmod on behalf of Ladislav Lhotka"
> > > wrote:
> > >
> > >>Andy Bierman p=C3=AD=C5=A1e v =C4=8Ct 14. 09. 2017 v 08:43 -0700:
> > >>> Hi,
> > >>>
> > >>>
> > >>> Actually I liked the early pyang output that was concise and =
easy
> > >>>to remember.
> > >>> The current format gets very cluttered and there are too many
> > >>>little symbols  to remember them all.
> > >>
> > >>I agree.
> > >>
> > >>Lada
> > >>
> > >>>
> > >>>
> > >>> Andy
> > >>>
> > >>>
> > >>> On Thu, Sep 14, 2017 at 8:33 AM, Joe Clarke  =
wrote:
> > >>> > I've been hacking on pyang, and I changed tree.py to add the
> > >>> > enum
> > >>>values
> > >>> > for enumeration types and identiyref bases for identityref =
types.
> > >>>Here
> > >>> > is an example:
> > >>> >
> > >>> > module: yang-catalog
> > >>> >     +--rw catalog
> > >>> >        +--rw modules
> > >>> >        |  +--rw module* [name revision organization]
> > >>> >        |     +--rw name                     =
yang:yang-identifier
> > >>> >        |     +--rw revision                 union
> > >>> >        |     +--rw organization             string
> > >>> >        |     +--rw ietf
> > >>> >        |     |  +--rw ietf-wg?   string
> > >>> >        |     +--rw namespace                inet:uri
> > >>> >        |     +--rw schema?                  inet:uri
> > >>> >        |     +--rw generated-from?          enumeration [mib, =
code,
> > >>> > not-applicable, native]
> > >>> >        |     +--rw maturity-level?          enumeration =
[ratified,
> > >>> > adopted, initial, not-applicable] ...
> > >>> >                                +--rw protocols
> > >>> >                                |  +--rw protocol* [name]
> > >>> >                                |     +--rw name
> > >>> > identityref -> protocol
> > >>> > ...
> > >>> >
> > >>> > My questions are:
> > >>> >
> > >>> > 1. Is this useful?
> > >>> >
> > >>> > 2. If so, can this be added to pyang (happy to submit a PR) =
and
> > >>> > draft-ietf-netmod-yang-tree-diagrams?
> > >>> >
> > >>> > 3. What changes to the output format would you recommend?
> > >>> >
> > >>> > Thanks.
> > >>> >
> > >>> > Joe
> > >>> >
> > >>> > _______________________________________________
> > >>> > netmod mailing list
> > >>> > netmod@ietf.org
> > >>> > https://www.ietf.org/mailman/listinfo/netmod
> > >>>
> > >>> _______________________________________________
> > >>> netmod mailing list
> > >>> netmod@ietf.org
> > >>> https://www.ietf.org/mailman/listinfo/netmod
> > >>--
> > >>Ladislav Lhotka
> > >>Head, CZ.NIC Labs
> > >>PGP Key ID: 0xB8F92B08A9F76C67
> > >>
> > >>_______________________________________________
> > >>netmod mailing list
> > >>netmod@ietf.org
> > >>https://www.ietf.org/mailman/listinfo/netmod
> > >
> >
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Mon Sep 25 23:34:19 2017
Return-Path: 
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 22CCD1321D8 for ; Mon, 25 Sep 2017 23:34:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZP0jHbQUTfzh for ; Mon, 25 Sep 2017 23:34: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 1AA54124239 for ; Mon, 25 Sep 2017 23:34:16 -0700 (PDT)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 4E6F51AE018C; Tue, 26 Sep 2017 08:34:15 +0200 (CEST)
Date: Tue, 26 Sep 2017 08:36:42 +0200 (CEST)
Message-Id: <20170926.083642.680914684763815093.mbj@tail-f.com>
To: xufeng.liu.ietf@gmail.com
Cc: acee@cisco.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <005601d33673$1d27c180$57774480$@gmail.com>
References:  <20170925.193903.1777711656523405872.mbj@tail-f.com> <005601d33673$1d27c180$57774480$@gmail.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Sep 2017 06:34:18 -0000

Ilh1ZmVuZyBMaXUiIDx4dWZlbmcubGl1LmlldGZAZ21haWwuY29tPiB3cm90ZToNCj4gVG8gYSB1
c2VyIG9mIHRoZSBzY2hlbWEtbW91bnQsIGl0IGlzIGltcG9ydGFudCB0byBiZSBhYmxlIHRvIHZp
c3VhbGl6ZQ0KPiBhbGwga2V5IGVsZW1lbnRzIG9mIHRoZSBtb3VudGluZyBtZWNoYW5pc206IG1v
dW50LXBvaW50LCBtb3VudGVkDQo+IHNjaGVtYSBtb2R1bGUsIGFuZCBwYXJlbnQtcmVmZXJlbmNl
LiBUaGUgZGV0YWlscyBjYW4gYmUgd29ya2VkIG91dCwNCj4gYnV0IGlmIGFueSBvZiB0aGVzZSBl
bGVtZW50cyB3ZXJlIG5vdCB1c2VmdWwgaW4gdGhlIHByZXNlbnRhdGlvbiwgaXQNCj4gd291bGQg
YmUgcXVlc3Rpb25hYmxlIHdoZXRoZXIgaXQgaGFkIHdlbGwtc3BlY2lmaWVkIGluIHRoZSBzY2hl
bWENCj4gbW91bnQgZHJhZnQuDQoNCldlIGFncmVlZCB0aGF0IHdlIHByb2JhYmx5IGRvbid0IHdh
bnQgdG8gbGlzdCBhbGwgZW51bXMgaW4gdGhlIHRyZWUuDQpEb2VzIHRoYXQgaW1wbHkgdGhhdCBl
bnVtZXJhdGlvbnMgYXJlIG5vdCB3ZWxsLXNwZWNpZmllZCBpbiBZQU5HPw0KDQo+ID4gLS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91
bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcnRpbg0KPiA+IEJqb3JrbHVuZA0KPiA+IFNl
bnQ6IE1vbmRheSwgU2VwdGVtYmVyIDI1LCAyMDE3IDE6MzkgUE0NCj4gPiBUbzogYWNlZUBjaXNj
by5jb20NCj4gPiBDYzogbmV0bW9kQGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFtuZXRtb2Rd
IFByb3Bvc2FsIHRvIGVuaGFuY2UgdGhlIFlBTkcgdHJlZSBvdXRwdXQNCj4gPiANCj4gPiAiQWNl
ZSBMaW5kZW0gKGFjZWUpIiA8YWNlZUBjaXNjby5jb20+IHdyb3RlOg0KPiA+ID4gTWFydGluLCBM
YWRhLCBldCBhbCwNCj4gPiA+DQo+ID4gPiBXaGlsZSBJIGRvbuKAmXQgdGhpbmsgd2UgbmVlZCBh
ZGRpdGlvbmFsIGFubm90YXRpb25zIHRoYXQgSm9lIGhhZA0KPiA+ID4gcHJvdG90eXBlZCAoYXQg
bGVhc3Qgbm90IGFzIHRoZSBkZWZhdWx0KSwgSSBzdHJvbmdseSBiZWxpZXZlIHdlIG5lZWQNCj4g
PiA+IHRvIGtlZXAgdGhlIOKAmEDigJggYW5kIOKAmC/igJggaW4gdGhlIHRyZWUgb3V0cHV0IGZv
ciBzY2hlbWEgbW91bnQuDQo+ID4gDQo+ID4gQ2FuIHlvdSBleHBsYWluIHdoYXQgaW5mb3JtYXRp
b24gIi8iIGdpdmVzIHRoZSByZWFkZXI/ICBDb21wYXJlIHRoZXNlDQo+ID4gdHdvDQo+ID4gdHJl
ZXM6DQo+ID4gDQo+ID4gICArLS1tcCB2cmYtcm9vdA0KPiA+ICAgICAgKy0tcncgcnQ6cm91dGlu
Zy8NCj4gPiAgICAgICAgICstLXJ3IHJ0OnJvdXRlci1pZA0KPiA+IA0KPiA+IGFuZA0KPiA+IA0K
PiA+ICAgKy0tbXAgdnJmLXJvb3QNCj4gPiAgICAgICstLXJ3IHJ0OnJvdXRpbmcNCj4gPiAgICAg
ICAgICstLXJ3IHJ0OnJvdXRlci1pZA0KPiA+IA0KPiA+IFdoYXQgZGlkIHRoZSAiLyIgaW4gdGhl
IGZpcnN0IHRyZWUgdGVsbCBtZSB0aGF0IEkgZG9uJ3Qgc2VlIGluIHRoZQ0KPiA+IHNlY29uZCB0
cmVlPw0KPiANCj4gW1h1ZmVuZ10gQmVjYXVzZSB0aGUgc2NoZW1hIG1vdW50IGRyYWZ0IGFsbG93
cyBhbiBhdWdtZW50aW5nIG1vZHVsZQ0KPiBub3QgdG8gYmUgbGlzdGVkIGluIHRoZSBtb3VudGVk
IHNjaGVtYSBsaXN0LiBUaGUgZm9sbG93aW5nIHR3bw0KPiBleGFtcGxlcyBzaG93IHR3byBkaWZm
ZXJlbnQgY29uZmlndXJhdGlvbnM6DQo+IA0KPiAgICstLW1wIHJvb3QNCj4gICAgICArLS1ydyBy
dDpyb3V0aW5nLw0KPiAgICAgIHwgICstLXJ3IHJvdXRlci1pZD8gICAgICAgICAgICAgICAgIHlh
bmc6ZG90dGVkLXF1YWQNCj4gICAgICB8ICArLS1ydyBjb250cm9sLXBsYW5lLXByb3RvY29scw0K
PiAgICAgIHwgICAgICstLXJ3IGNvbnRyb2wtcGxhbmUtcHJvdG9jb2wqIFt0eXBlIG5hbWVdDQo+
ICAgICAgfCAgICAgICAgKy0tcncgb3NwZjpvc3BmLw0KPiANCj4gd2hlcmUgb3NwZiBhdWdtZW50
cyBydCwgYW5kIGhhcyBiZWVuIGxpc3RlZCBpbiB0aGUgbW91bnRpbmcgc2NoZW1hDQo+IGxpc3Qu
DQo+IA0KPiAgICstLW1wIHJvb3QNCj4gICAgICArLS1ydyBydDpyb3V0aW5nLw0KPiAgICAgIHwg
ICstLXJ3IHJvdXRlci1pZD8gICAgICAgICAgICAgICAgIHlhbmc6ZG90dGVkLXF1YWQNCj4gICAg
ICB8ICArLS1ydyBjb250cm9sLXBsYW5lLXByb3RvY29scw0KPiAgICAgIHwgICAgICstLXJ3IGNv
bnRyb2wtcGxhbmUtcHJvdG9jb2wqIFt0eXBlIG5hbWVdDQo+ICAgICAgfCAgICAgICAgKy0tcncg
b3NwZjpvc3BmDQo+IA0KPiB3aGVyZSBvc3BmIGF1Z21lbnRzIHJ0LCBhbmQgaGFzIG5vdCBiZWVu
IGxpc3RlZCBpbiB0aGUgbW91bnRpbmcgc2NoZW1hDQo+IGxpc3QuDQoNCklmIHRoZSBvc3BmIG1v
ZHVsZSBpcyBOT1QgbGlzdGVkIGluIHRoZSB5YW5nIGxpYnJhcnkgZGF0YSBmb3IgdGhlDQptb3Vu
dCBwb2ludCwgdGhlbiBpdCB3aWxsIG5vdCBiZSBwcmVzZW50IGluIHRoZSB0cmVlLiAgU28gaW4g
dGhpcyBjYXNlDQp0aGUgdHJlZSB3aWxsIGJlOg0KDQogICArLS1tcCByb290DQogICAgICArLS1y
dyBydDpyb3V0aW5nDQogICAgICB8ICArLS1ydyByb3V0ZXItaWQ/ICAgICAgICAgICAgICAgICB5
YW5nOmRvdHRlZC1xdWFkDQogICAgICB8ICArLS1ydyBjb250cm9sLXBsYW5lLXByb3RvY29scw0K
ICAgICAgfCAgICAgKy0tcncgY29udHJvbC1wbGFuZS1wcm90b2NvbCogW3R5cGUgbmFtZV0NCiAg
ICAgICAgICAgICAvLyBubyBvc3BmIGhlcmUNCg0KW1RoaW5rIGFib3V0IGl0IHRoZSBvdGhlciB3
YXkgYXJvdW5kOyBpZiB3ZSB3ZXJlIHRvIHNob3cgYWxsIG5vZGVzDQpmcm9tIGFsbCBtb2R1bGVz
IHRoYXQgYXJlIE5PVCBtb3VudGVkLCBvdXIgdHJlZSB3b3VsZCBiZSBpbmlmaW5pdGVseQ0KYmln
Li4uXQ0KDQpJZiB0aGUgb3NwZiBtb2R1bGUgKmlzKiBsaXN0ZWQgaW4gdGhlIHlhbmcgbGlicmFy
eSBkYXRhIGZvciB0aGUNCm1vdW50IHBvaW50LCB0aGVuIHRoZSB0cmVlIGNhbiBiZToNCg0KICAg
Ky0tbXAgcm9vdA0KICAgICAgKy0tcncgcnQ6cm91dGluZw0KICAgICAgfCAgKy0tcncgcm91dGVy
LWlkPyAgICAgICAgICAgICAgICAgeWFuZzpkb3R0ZWQtcXVhZA0KICAgICAgfCAgKy0tcncgY29u
dHJvbC1wbGFuZS1wcm90b2NvbHMNCiAgICAgIHwgICAgICstLXJ3IGNvbnRyb2wtcGxhbmUtcHJv
dG9jb2wqIFt0eXBlIG5hbWVdDQogICAgICB8ICAgICAgICArLS1ydyBvc3BmOm9zcGYNCg0KTm8g
bmVlZCBmb3IgYSAnLycuDQoNCg0KPiA+IFRoZW4gY29uc2lkZXI6DQo+ID4gDQo+ID4gICArLS1y
byBpZjppbnRlcmZhY2VzQA0KPiA+IA0KPiA+IGFuZA0KPiA+IA0KPiA+ICAgKy0tcm8gaWY6aW50
ZXJmYWNlcw0KPiA+ICAgICAgKy0tIGlmOmludGVyZmFjZUANCj4gPiANCj4gPiBhbmQNCj4gPiAN
Cj4gPiAgICstLXJvIGlmOmludGVyZmFjZXNADQo+ID4gICAgICArLS0gaWY6aW50ZXJmYWNlQA0K
PiA+IA0KPiA+IA0KPiA+IFdoaWNoIG9uZXMgYXJlIGxlZ2FsLCBhbmQgd2hhdCBkbyB0aGV5IG1l
YW4/DQo+ID4gDQo+IFtYdWZlbmddIFRoZSBkaXNwbGF5IHNob3dzIHRoZSByZXN1bHQgb2YgdGhl
IFhQYXRoLCByaWdodD8NCg0KSSBkb24ndCBrbm93IHdoYXQgaXQgc2hvd3M7IEknbSBub3QgcHJv
cG9zaW5nIHRoaXMgbm90YXRpb24uICBBbHNvDQpub3RlIHRoYXQgdGhlIHJlc3VsdCBvZiB0aGUg
WFBhdGggaXMgYSBub2RlIHNldCBvZiAqaW5zdGFuY2UgZGF0YSosDQpidXQgdGhlIHRyZWUgc2hv
d3MgdGhlICpzY2hlbWEqLCBhbmQgbWl4aW5nIHRoZSB0d28gaXMgY29uZnVzaW5nLg0KDQpIb3Bl
ZnVsbHkgYnkgbG9va2luZyBhdCB0aGUgdHJlZXMgYWJvdmUsIHRoZSByZWFkZXIgd2lsbCB1bmRl
cnN0YW5kDQp3aGF0J3MgYmVoaW5kIHRoaXMgbm90YXRpb24uICBTbyBJIGFzayBhZ2Fpbiwgd2hh
dCBkbyB0aGUgbm90YXRpb25zDQphYm92ZSBtZWFuPw0KDQo+IFdoZXRoZXINCj4gdGhleSBhcmUg
bGVnYWwgb3Igbm90IHNob3VsZCBiZSBkZXRlcm1pbmVkIGJ5IHRoZSBzY2hlbWEtbW91bnQgZHJh
ZnQsDQo+IG5vdCBieSB0aGUgZGlzcGxheWluZyBub3RhdGlvbi4NCg0KVGhlIHNjaGVtYSBtb3Vu
dCBkcmFmdCBkb2VzIG5vdCBzcGVjaWZ5IHRoZSBydWxlcyBmb3IgdGhlICdAJyBpbiB0aGUNCnRy
ZWUgb3V0cHV0Lg0KDQotLQ0KDQpNeSBwb2ludHMgYXJlIHRoYXQ6DQoNCiAgKDEpICAiLyIgaXMg
cmVkdW5kYW50IGFuZCBub3QgbmVlZGVkLiAgVGhlIHNhbWUgaW5mb3JtYXRpb24gY2FuIGJlDQog
ICAgICAgY29udmV5ZWQgdy9vICIvIi4NCg0KICAoMikgICJAIiBpcyB1bmRlciBzcGVjaWZpZWQs
IGFuZCBpdCBtaXhlcyBzY2hlbWEgYW5kIGluc3RhbmNlIGRhdGEuDQoNCg0KDQovbWFydGluDQoN
Cg0KDQoNCg0KDQo+IA0KPiA+IA0KPiA+IA0KPiA+IC9tYXJ0aW4NCj4gPiANCj4gPiBXaGlsZSB0
aGUgZm9ybWVyIGVuaGFuY2VtZW50DQo+ID4gPiBwcm92aWRlZCBkZXRhaWxzLCB0aGUgc2NoZW1h
IG1vdW50IHRyZWUgZGVzaWduYXRpb25zIGFyZSBldmVyeSBiaXQgYXMNCj4gPiA+IGltcG9ydGFu
dCBhcyBrbm93aW5nLCBmb3IgZXhhbXBsZSwgd2hldGhlciBvciBub3QgYSBzY2hlbWEgbGVhZiBp
cyBhDQo+ID4gPiBwcmVzZW5jZSBub2RlLg0KPiA+ID4NCj4gPiA+IFRoYW5rcywNCj4gPiA+IEFj
ZWUNCj4gPiA+DQo+ID4gPg0KPiA+ID4gT24gOS8xNS8xNywgOTo1NiBBTSwgIkFjZWUgTGluZGVt
IChhY2VlKSIgPGFjZWVAY2lzY28uY29tPiB3cm90ZToNCj4gPiA+DQo+ID4gPiA+KzEgLSBBbHNv
IGl0IGlzIGhhcmQgZW5vdWdoIHRvIGZvcm1hdCB0aGUgdHJlZSBvdXRwdXQgdG8gZml0IGluIGEN
Cj4gPiA+ID4rZHJhZnQNCj4gPiA+ID53L28gZnVydGhlciBhbm5vdGF0aW9ucyAoZXZlbiB3aXRo
IOKAlC10cmVlLWxpbmUtbGVuZ3RoKS4NCj4gPiA+ID5UaGFua3MsDQo+ID4gPiA+QWNlZQ0KPiA+
ID4gPg0KPiA+ID4gPg0KPiA+ID4gPk9uIDkvMTUvMTcsIDY6MjEgQU0sICJuZXRtb2Qgb24gYmVo
YWxmIG9mIExhZGlzbGF2IExob3RrYSINCj4gPiA+ID48bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcg
b24gYmVoYWxmIG9mIGxob3RrYUBuaWMuY3o+IHdyb3RlOg0KPiA+ID4gPg0KPiA+ID4gPj5BbmR5
IEJpZXJtYW4gcMOtxaFlIHYgxIx0IDE0LiAwOS4gMjAxNyB2IDA4OjQzIC0wNzAwOg0KPiA+ID4g
Pj4+IEhpLA0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4NCj4gPiA+ID4+PiBBY3R1YWxseSBJIGxpa2Vk
IHRoZSBlYXJseSBweWFuZyBvdXRwdXQgdGhhdCB3YXMgY29uY2lzZSBhbmQgZWFzeQ0KPiA+ID4g
Pj4+dG8gcmVtZW1iZXIuDQo+ID4gPiA+Pj4gVGhlIGN1cnJlbnQgZm9ybWF0IGdldHMgdmVyeSBj
bHV0dGVyZWQgYW5kIHRoZXJlIGFyZSB0b28gbWFueQ0KPiA+ID4gPj4+bGl0dGxlIHN5bWJvbHMg
IHRvIHJlbWVtYmVyIHRoZW0gYWxsLg0KPiA+ID4gPj4NCj4gPiA+ID4+SSBhZ3JlZS4NCj4gPiA+
ID4+DQo+ID4gPiA+PkxhZGENCj4gPiA+ID4+DQo+ID4gPiA+Pj4NCj4gPiA+ID4+Pg0KPiA+ID4g
Pj4+IEFuZHkNCj4gPiA+ID4+Pg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gT24gVGh1LCBTZXAgMTQs
IDIwMTcgYXQgODozMyBBTSwgSm9lIENsYXJrZSA8amNsYXJrZUBjaXNjby5jb20+IHdyb3RlOg0K
PiA+ID4gPj4+ID4gSSd2ZSBiZWVuIGhhY2tpbmcgb24gcHlhbmcsIGFuZCBJIGNoYW5nZWQgdHJl
ZS5weSB0byBhZGQgdGhlDQo+ID4gPiA+Pj4gPiBlbnVtDQo+ID4gPiA+Pj52YWx1ZXMNCj4gPiA+
ID4+PiA+IGZvciBlbnVtZXJhdGlvbiB0eXBlcyBhbmQgaWRlbnRpeXJlZiBiYXNlcyBmb3IgaWRl
bnRpdHlyZWYgdHlwZXMuDQo+ID4gPiA+Pj5IZXJlDQo+ID4gPiA+Pj4gPiBpcyBhbiBleGFtcGxl
Og0KPiA+ID4gPj4+ID4NCj4gPiA+ID4+PiA+IG1vZHVsZTogeWFuZy1jYXRhbG9nDQo+ID4gPiA+
Pj4gPiAgICAgKy0tcncgY2F0YWxvZw0KPiA+ID4gPj4+ID4gICAgICAgICstLXJ3IG1vZHVsZXMN
Cj4gPiA+ID4+PiA+ICAgICAgICB8ICArLS1ydyBtb2R1bGUqIFtuYW1lIHJldmlzaW9uIG9yZ2Fu
aXphdGlvbl0NCj4gPiA+ID4+PiA+ICAgICAgICB8ICAgICArLS1ydyBuYW1lICAgICAgICAgICAg
ICAgICAgICAgeWFuZzp5YW5nLWlkZW50aWZpZXINCj4gPiA+ID4+PiA+ICAgICAgICB8ICAgICAr
LS1ydyByZXZpc2lvbiAgICAgICAgICAgICAgICAgdW5pb24NCj4gPiA+ID4+PiA+ICAgICAgICB8
ICAgICArLS1ydyBvcmdhbml6YXRpb24gICAgICAgICAgICAgc3RyaW5nDQo+ID4gPiA+Pj4gPiAg
ICAgICAgfCAgICAgKy0tcncgaWV0Zg0KPiA+ID4gPj4+ID4gICAgICAgIHwgICAgIHwgICstLXJ3
IGlldGYtd2c/ICAgc3RyaW5nDQo+ID4gPiA+Pj4gPiAgICAgICAgfCAgICAgKy0tcncgbmFtZXNw
YWNlICAgICAgICAgICAgICAgIGluZXQ6dXJpDQo+ID4gPiA+Pj4gPiAgICAgICAgfCAgICAgKy0t
cncgc2NoZW1hPyAgICAgICAgICAgICAgICAgIGluZXQ6dXJpDQo+ID4gPiA+Pj4gPiAgICAgICAg
fCAgICAgKy0tcncgZ2VuZXJhdGVkLWZyb20/ICAgICAgICAgIGVudW1lcmF0aW9uIFttaWIsIGNv
ZGUsDQo+ID4gPiA+Pj4gPiBub3QtYXBwbGljYWJsZSwgbmF0aXZlXQ0KPiA+ID4gPj4+ID4gICAg
ICAgIHwgICAgICstLXJ3IG1hdHVyaXR5LWxldmVsPyAgICAgICAgICBlbnVtZXJhdGlvbiBbcmF0
aWZpZWQsDQo+ID4gPiA+Pj4gPiBhZG9wdGVkLCBpbml0aWFsLCBub3QtYXBwbGljYWJsZV0gLi4u
DQo+ID4gPiA+Pj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tcncgcHJvdG9j
b2xzDQo+ID4gPiA+Pj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgKy0tcncg
cHJvdG9jb2wqIFtuYW1lXQ0KPiA+ID4gPj4+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHwgICAgICstLXJ3IG5hbWUNCj4gPiA+ID4+PiA+IGlkZW50aXR5cmVmIC0+IHByb3RvY29s
DQo+ID4gPiA+Pj4gPiAuLi4NCj4gPiA+ID4+PiA+DQo+ID4gPiA+Pj4gPiBNeSBxdWVzdGlvbnMg
YXJlOg0KPiA+ID4gPj4+ID4NCj4gPiA+ID4+PiA+IDEuIElzIHRoaXMgdXNlZnVsPw0KPiA+ID4g
Pj4+ID4NCj4gPiA+ID4+PiA+IDIuIElmIHNvLCBjYW4gdGhpcyBiZSBhZGRlZCB0byBweWFuZyAo
aGFwcHkgdG8gc3VibWl0IGEgUFIpIGFuZA0KPiA+ID4gPj4+ID4gZHJhZnQtaWV0Zi1uZXRtb2Qt
eWFuZy10cmVlLWRpYWdyYW1zPw0KPiA+ID4gPj4+ID4NCj4gPiA+ID4+PiA+IDMuIFdoYXQgY2hh
bmdlcyB0byB0aGUgb3V0cHV0IGZvcm1hdCB3b3VsZCB5b3UgcmVjb21tZW5kPw0KPiA+ID4gPj4+
ID4NCj4gPiA+ID4+PiA+IFRoYW5rcy4NCj4gPiA+ID4+PiA+DQo+ID4gPiA+Pj4gPiBKb2UNCj4g
PiA+ID4+PiA+DQo+ID4gPiA+Pj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KPiA+ID4gPj4+ID4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+ID4gPj4+
ID4gbmV0bW9kQGlldGYub3JnDQo+ID4gPiA+Pj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL25ldG1vZA0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4+PiBuZXRtb2QgbWFpbGlu
ZyBsaXN0DQo+ID4gPiA+Pj4gbmV0bW9kQGlldGYub3JnDQo+ID4gPiA+Pj4gaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gPiA+ID4+LS0NCj4gPiA+ID4+TGFk
aXNsYXYgTGhvdGthDQo+ID4gPiA+PkhlYWQsIENaLk5JQyBMYWJzDQo+ID4gPiA+PlBHUCBLZXkg
SUQ6IDB4QjhGOTJCMDhBOUY3NkM2Nw0KPiA+ID4gPj4NCj4gPiA+ID4+X19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4+bmV0bW9kIG1haWxpbmcg
bGlzdA0KPiA+ID4gPj5uZXRtb2RAaWV0Zi5vcmcNCj4gPiA+ID4+aHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gPiA+ID4NCj4gPiA+DQo+ID4gX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBuZXRtb2QgbWFpbGlu
ZyBsaXN0DQo+ID4gbmV0bW9kQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9uZXRtb2QNCj4gDQo=


From nobody Tue Sep 26 10:28:39 2017
Return-Path: 
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 523621342AD for ; Tue, 26 Sep 2017 10:28:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hn_-f9tWnz4i for ; Tue, 26 Sep 2017 10:28:36 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 742C613428A for ; Tue, 26 Sep 2017 10:28:35 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPI82681; Tue, 26 Sep 2017 17:28:33 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 26 Sep 2017 18:28:32 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.175]) by SJCEML701-CHM.china.huawei.com ([169.254.3.215]) with mapi id 14.03.0301.000;  Tue, 26 Sep 2017 10:28:25 -0700
From: Yingzhen Qu 
To: "Acee Lindem (acee)" , Ladislav Lhotka , "netmod@ietf.org" , Martin Bjorklund 
Thread-Topic: [netmod] Proposal to enhance the YANG tree output
Thread-Index: AQHTLW7wdmy8RMDQEUSny+0Ug5iEtaK0+t4AgAE4cwCAADv9AIAP4kCAgAEpEjA=
Date: Tue, 26 Sep 2017 17:28:24 +0000
Message-ID: <594D005A3CB0724DB547CF3E9A9E810BF15DC4@sjceml521-mbx.china.huawei.com>
References: <9d84d068-29ba-8e89-394f-b7f6a5272adc@cisco.com>  <1505470900.18681.0.camel@nic.cz>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.212.245.200]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.59CA8E41.0126, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.1.175, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 042b507eb9bb95e723f00ed33727c1a5
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Sep 2017 17:28:38 -0000

SGkgYWxsLA0KDQpJIHBlcnNvbmFsbHkgbGlrZSB0byBrZWVwIHRoZSDigJhA4oCZIGFuZCB0aGUg
Jy8nIGluIHRoZSB0cmVlIG91dHB1dC4gQXMgd2Uga25vdyB0aGF0IGEgdHJlZSBtYXkgbm90IGNh
dGNoIGFsbCB3aGF0IGEgbW9kdWxlIGlzIHRyeWluZyB0byBkbywgYnV0IGl0IGNhbiBoZWxwIHVz
ZXJzIHRvIHF1aWNrbHkgZ2V0IGFuIGlkZWEgb2YgdGhlIG1vZHVsZSdzIG92ZXJhbGwgYXJjaGl0
ZWN0dXJlIGV0Yy4gVGhlICdAJyBhbmQgdGhlICcvJyBpcyB2ZXJ5IGhlbHBmdWwgaW4gb3JkZXIg
dG8gdW5kZXJzdGFuZCBhbGwgdGhlIG1vdW50aW5nIHBvaW50cy4NCg0KVGhhbmtzLA0KWWluZ3po
ZW4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG5ldG1vZCBbbWFpbHRvOm5l
dG1vZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWNlZSBMaW5kZW0gKGFjZWUpDQpT
ZW50OiBNb25kYXksIFNlcHRlbWJlciAyNSwgMjAxNyA5OjMwIEFNDQpUbzogTGFkaXNsYXYgTGhv
dGthIDxsaG90a2FAbmljLmN6PjsgbmV0bW9kQGlldGYub3JnOyBNYXJ0aW4gQmpvcmtsdW5kIDxt
YmpAdGFpbC1mLmNvbT4NClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBQcm9wb3NhbCB0byBlbmhhbmNl
IHRoZSBZQU5HIHRyZWUgb3V0cHV0DQoNCk1hcnRpbiwgTGFkYSwgZXQgYWwsDQoNCldoaWxlIEkg
ZG9u4oCZdCB0aGluayB3ZSBuZWVkIGFkZGl0aW9uYWwgYW5ub3RhdGlvbnMgdGhhdCBKb2UgaGFk
IHByb3RvdHlwZWQgKGF0IGxlYXN0IG5vdCBhcyB0aGUgZGVmYXVsdCksIEkgc3Ryb25nbHkgYmVs
aWV2ZSB3ZSBuZWVkIHRvIGtlZXAgdGhlIOKAmEDigJggYW5kIOKAmC/igJggaW4gdGhlIHRyZWUg
b3V0cHV0IGZvciBzY2hlbWEgbW91bnQuIFdoaWxlIHRoZSBmb3JtZXIgZW5oYW5jZW1lbnQgcHJv
dmlkZWQgZGV0YWlscywgdGhlIHNjaGVtYSBtb3VudCB0cmVlIGRlc2lnbmF0aW9ucyBhcmUgZXZl
cnkgYml0IGFzIGltcG9ydGFudCBhcyBrbm93aW5nLCBmb3IgZXhhbXBsZSwgd2hldGhlciBvciBu
b3QgYSBzY2hlbWEgbGVhZiBpcyBhIHByZXNlbmNlIG5vZGUuIA0KDQpUaGFua3MsDQpBY2VlIA0K
DQoNCk9uIDkvMTUvMTcsIDk6NTYgQU0sICJBY2VlIExpbmRlbSAoYWNlZSkiIDxhY2VlQGNpc2Nv
LmNvbT4gd3JvdGU6DQoNCj4rMSAtIEFsc28gaXQgaXMgaGFyZCBlbm91Z2ggdG8gZm9ybWF0IHRo
ZSB0cmVlIG91dHB1dCB0byBmaXQgaW4gYSBkcmFmdA0KPncvbyBmdXJ0aGVyIGFubm90YXRpb25z
IChldmVuIHdpdGgg4oCULXRyZWUtbGluZS1sZW5ndGgpLg0KPlRoYW5rcywNCj5BY2VlDQo+DQo+
DQo+T24gOS8xNS8xNywgNjoyMSBBTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgTGFkaXNsYXYgTGhv
dGthIg0KPjxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgbGhvdGthQG5pYy5j
ej4gd3JvdGU6DQo+DQo+PkFuZHkgQmllcm1hbiBww63FoWUgdiDEjHQgMTQuIDA5LiAyMDE3IHYg
MDg6NDMgLTA3MDA6DQo+Pj4gSGksDQo+Pj4gDQo+Pj4gDQo+Pj4gQWN0dWFsbHkgSSBsaWtlZCB0
aGUgZWFybHkgcHlhbmcgb3V0cHV0IHRoYXQgd2FzIGNvbmNpc2UgYW5kIGVhc3kgdG8gDQo+Pj5y
ZW1lbWJlci4NCj4+PiBUaGUgY3VycmVudCBmb3JtYXQgZ2V0cyB2ZXJ5IGNsdXR0ZXJlZCBhbmQg
dGhlcmUgYXJlIHRvbyBtYW55IGxpdHRsZSANCj4+PnN5bWJvbHMgIHRvIHJlbWVtYmVyIHRoZW0g
YWxsLg0KPj4NCj4+SSBhZ3JlZS4NCj4+DQo+PkxhZGENCj4+DQo+Pj4gDQo+Pj4gDQo+Pj4gQW5k
eQ0KPj4+IA0KPj4+IA0KPj4+IE9uIFRodSwgU2VwIDE0LCAyMDE3IGF0IDg6MzMgQU0sIEpvZSBD
bGFya2UgPGpjbGFya2VAY2lzY28uY29tPiB3cm90ZToNCj4+PiA+IEkndmUgYmVlbiBoYWNraW5n
IG9uIHB5YW5nLCBhbmQgSSBjaGFuZ2VkIHRyZWUucHkgdG8gYWRkIHRoZSBlbnVtDQo+Pj52YWx1
ZXMNCj4+PiA+IGZvciBlbnVtZXJhdGlvbiB0eXBlcyBhbmQgaWRlbnRpeXJlZiBiYXNlcyBmb3Ig
aWRlbnRpdHlyZWYgdHlwZXMuDQo+Pj5IZXJlDQo+Pj4gPiBpcyBhbiBleGFtcGxlOg0KPj4+ID4g
DQo+Pj4gPiBtb2R1bGU6IHlhbmctY2F0YWxvZw0KPj4+ID4gICAgICstLXJ3IGNhdGFsb2cNCj4+
PiA+ICAgICAgICArLS1ydyBtb2R1bGVzDQo+Pj4gPiAgICAgICAgfCAgKy0tcncgbW9kdWxlKiBb
bmFtZSByZXZpc2lvbiBvcmdhbml6YXRpb25dDQo+Pj4gPiAgICAgICAgfCAgICAgKy0tcncgbmFt
ZSAgICAgICAgICAgICAgICAgICAgIHlhbmc6eWFuZy1pZGVudGlmaWVyDQo+Pj4gPiAgICAgICAg
fCAgICAgKy0tcncgcmV2aXNpb24gICAgICAgICAgICAgICAgIHVuaW9uDQo+Pj4gPiAgICAgICAg
fCAgICAgKy0tcncgb3JnYW5pemF0aW9uICAgICAgICAgICAgIHN0cmluZw0KPj4+ID4gICAgICAg
IHwgICAgICstLXJ3IGlldGYNCj4+PiA+ICAgICAgICB8ICAgICB8ICArLS1ydyBpZXRmLXdnPyAg
IHN0cmluZw0KPj4+ID4gICAgICAgIHwgICAgICstLXJ3IG5hbWVzcGFjZSAgICAgICAgICAgICAg
ICBpbmV0OnVyaQ0KPj4+ID4gICAgICAgIHwgICAgICstLXJ3IHNjaGVtYT8gICAgICAgICAgICAg
ICAgICBpbmV0OnVyaQ0KPj4+ID4gICAgICAgIHwgICAgICstLXJ3IGdlbmVyYXRlZC1mcm9tPyAg
ICAgICAgICBlbnVtZXJhdGlvbiBbbWliLCBjb2RlLA0KPj4+ID4gbm90LWFwcGxpY2FibGUsIG5h
dGl2ZV0NCj4+PiA+ICAgICAgICB8ICAgICArLS1ydyBtYXR1cml0eS1sZXZlbD8gICAgICAgICAg
ZW51bWVyYXRpb24gW3JhdGlmaWVkLA0KPj4+ID4gYWRvcHRlZCwgaW5pdGlhbCwgbm90LWFwcGxp
Y2FibGVdDQo+Pj4gPiAuLi4NCj4+PiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAr
LS1ydyBwcm90b2NvbHMNCj4+PiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAr
LS1ydyBwcm90b2NvbCogW25hbWVdDQo+Pj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgfCAgICAgKy0tcncgbmFtZQ0KPj4+ID4gaWRlbnRpdHlyZWYgLT4gcHJvdG9jb2wNCj4+PiA+
IC4uLg0KPj4+ID4gDQo+Pj4gPiBNeSBxdWVzdGlvbnMgYXJlOg0KPj4+ID4gDQo+Pj4gPiAxLiBJ
cyB0aGlzIHVzZWZ1bD8NCj4+PiA+IA0KPj4+ID4gMi4gSWYgc28sIGNhbiB0aGlzIGJlIGFkZGVk
IHRvIHB5YW5nIChoYXBweSB0byBzdWJtaXQgYSBQUikgYW5kIA0KPj4+ID4gZHJhZnQtaWV0Zi1u
ZXRtb2QteWFuZy10cmVlLWRpYWdyYW1zPw0KPj4+ID4gDQo+Pj4gPiAzLiBXaGF0IGNoYW5nZXMg
dG8gdGhlIG91dHB1dCBmb3JtYXQgd291bGQgeW91IHJlY29tbWVuZD8NCj4+PiA+IA0KPj4+ID4g
VGhhbmtzLg0KPj4+ID4gDQo+Pj4gPiBKb2UNCj4+PiA+IA0KPj4+ID4gX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiA+IG5ldG1vZCBtYWlsaW5nIGxp
c3QNCj4+PiA+IG5ldG1vZEBpZXRmLm9yZw0KPj4+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9uZXRtb2QNCj4+PiANCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KPj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4+PiBuZXRt
b2RAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l
dG1vZA0KPj4tLQ0KPj5MYWRpc2xhdiBMaG90a2ENCj4+SGVhZCwgQ1ouTklDIExhYnMNCj4+UEdQ
IEtleSBJRDogMHhCOEY5MkIwOEE5Rjc2QzY3DQo+Pg0KPj5fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj5uZXRtb2QgbWFpbGluZyBsaXN0DQo+Pm5ldG1v
ZEBpZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1v
ZA0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
bmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K


From nobody Wed Sep 27 03:24:58 2017
Return-Path: 
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 359CC13498B; Wed, 27 Sep 2017 03:24:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 rfSF7n0q-YnB; Wed, 27 Sep 2017 03:24:53 -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 1A9161345AE; Wed, 27 Sep 2017 03:24:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7569; q=dns/txt; s=iport; t=1506507893; x=1507717493; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Z+HnMdcTy6P0p+jYTGYp8n1Don7FHqppl7kFx6iRlFQ=; b=Q1QaesLio+y4yCOOFVm82bPnE3hELpSqe1ILopl/6Mru8SAKeYsiBly+ CYfkqkCsEDFEZLC9G3yx+d9uTDYjnEoWy111FL7z1/HhO97kdgN1GZGtc n+dAT6rtEpJ5BkRG9iclthcpUXXNdwiETm5h3cENA036xeah9s1KQaaqT o=;
X-IronPort-AV: E=Sophos;i="5.42,444,1500940800"; d="scan'208";a="657859887"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Sep 2017 10:24:51 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8RAOoNu012777; Wed, 27 Sep 2017 10:24:50 GMT
To: Kent Watsen , "t.petch" , "netmod@ietf.org" , "Clyde Wildes (cwildes)" 
Cc: "draft-ietf-netmod-syslog-model@ietf.org" 
References: <49B4BE2F-6912-49BE-9E4A-830146309AB2@juniper.net> <019b01d32c76$fa7dfc40$4001a8c0@gateway.2wire.net> <8CF097E4-CEB7-4C4E-AC7D-F7F896CD1BB7@juniper.net> <00ae01d32d74$49e24c20$4001a8c0@gateway.2wire.net> <5CE9EE07-D75D-4E5C-BC70-1F969732A526@juniper.net>
From: Benoit Claise 
Message-ID: <8e873d52-a6bd-87ee-9ff5-62c85eb5b6dc@cisco.com>
Date: Wed, 27 Sep 2017 12:24:50 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <5CE9EE07-D75D-4E5C-BC70-1F969732A526@juniper.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] syslog-model-17 shepherd writeup issues -references
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Sep 2017 10:24:56 -0000

Clyde,

Do you know your next step to progress this document?

Regards, Benoit
> I meant to say something about the .1 vs .2 difference.  My comment
> assumes that it's supposed to be .1, but we of course should use
> whatever is correct.
>
> I also don't know much about that standards body.
>
> K.
>
>
>
> ----- Original Message -----
> From: "Kent Watsen" 
> Sent: Wednesday, September 13, 2017 6:08 PM
>
>> Hi Tom,
>>
>> Thanks.  The fix I'm looking for is for the 'pattern-match' leaf
>> to have a 'reference' statement to Std-1003.1-2008, and for S4.1
>> to also list Std-1003.1-2008 as a draft-level reference.
> and I am unfamiliar with that standards body so am looking for a little
> more.
>
> Is STD-nnnn always Posix or do we need to say Posix 1003 or Posix
> Std-1003 or is Std-1003 completely unrelated to Posix 1003?
>
> Is there a difference between Std-1003.1-2008 and Posix 1003.2 ie is the
> .1 or .2 significant?  You want Std-1003.1; the description contains
> Posix 1003.2; the normative Reference is to Std-1003.1-2008.
>
> You pointed out that the Normative Reference is not used; well if we can
> sort out what the standard is and get the right label in Normative
> References then we can - must - include this in Section 4.1 which will
> resolve that comment of yours.
>
> The discussions last July had Clyde saying he wants Posix 1003.2 so if
> Std-1003 and Posix 1003 are the same but .1 and.2 are different, then
> you are asking for a semantic change against Clyde's wishes.
>
> I hope my confusion is sufficiently clear, at least to Clyde!
>
> Tom Petch
>
>> I was going to point out the typo "the the" as well, but figured
>> that the RFC Editor would get it.
>>
>> K. // shepherd
>>
>>
>> --
>>
>> Kent
>>
>> You flag Std-1003.1-2008 as listed as a normative reference but not
> used
>> anywhere in the document.  In the Descriptions, but not in the s.4.1
>> references, I see
>>
>> This leaf describes a Posix 1003.2 regular expression ...
>>
>> twice, which may, or may not, relate to this issue.
>>
>> Back in July, clyde said
>> "I will insert a normative reference to POSIX 1003.2 in the next
>> revision of the draft."
>>
>> In a similar vein, RFC6991 appears in a reference statement but
> nowhere
>> else.
>>
>> As you point out, RFC6021 is referenced but is obsoleted by RFC6991 so
>> should not be.
>>
>> And in a slightly different vein,
>>
>>     registry [RFC7895]/>.  Following the format in [RFC7950]/>, the the
>>
>> looks odd for plain text and for the repetition of 'the'..
>>
>> Tom Petch
>>
>> ----- Original Message -----
>> From: "Kent Watsen" 
>> To: 
>> Cc: 
>> Sent: Tuesday, September 12, 2017 10:50 PM
>> Subject: [netmod] syslog-model-17 shepherd writeup issues
>>
>>
>>> Clyde, all,
>>>
>>> In reviewing the draft for Shepherd writeup, I found the following
>> issues that I think need to be addressed before the document can be
> sent
>> to Benoit for AD review:
>>>
>>> 1. Idnits found the following:
>>>
>>>    Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment
>> (--).
>>>      ** There are 2 instances of too long lines in the document, the
>> longest one
>>>           being 3 characters in excess of 72.
>>>
>>>      ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC
> 6991)
>>>      ** Downref: Normative reference to an Historic RFC: RFC 6587
>>>
>>>      == Missing Reference: 'RFC5425' is mentioned on line 359, but
> not
>> defined
>>>           '[RFC5425], [RFC5426], [RFC6587], and [RFC5848]....'
>>>
>>>       == Unused Reference: 'RFC7895' is defined on line 1406, but no
>> explicit
>>>            reference was found in the text
>>>            '[RFC7895]  Bierman, A., Bjorklund, M., and K. Watsen,
> "YANG
>> Module L...'
>>>       == Unused Reference: 'RFC6242' is defined on line 1435, but no
>> explicit
>>>            reference was found in the text
>>>            '[RFC6242]  Wasserman, M., "Using the NETCONF Protocol
> over
>> Secure Sh...'
>>>
>>> 2. `rfcstrip` extracted "ietf-syslog.yang",  which is missing
>> "@yyyy-mm-dd" in its name
>>> 3.  neither `pyang` nor `yanglint` found any errors with
>> ietf-syslog.yang.    pyang says
>>>        for vendor-syslog-types-example: statement "identity" must
> have
>> a "description"
>>>        substatement.
>>>
>>> 4. testing the examples in the draft against yanglint:
>>>        - for both examples: Missing element's "namespace". (/config)
>>>        - just removing the "" element envelop resolves this
>> error.
>>> 5. the 2nd example uses IP address "2001:db8:a0b:12f0::1", but this
>> SHOULD be a
>>>       domain name (e.g., foo.example.com)
>>>
>>> 6. in the YANG module, anywhere you have an RFC listed in a
>> 'description' statement,
>>>       there should be a 'reference' statement for that RFC.
>>>
>>> 7. in the tree diagram, the leafrefs no longer indicate what they
>> point at, they now all
>>>       just say "leafref".  Did you do this on purpose, or are you
> using
>> a different tree
>>>       output generator from -15?
>>>
>>> 8. RFC6536 is listed as a normative reference, but it probably
> should
>> be informative.
>>> 9. Std-1003.1-2008 is listed as a normative reference, but it is not
>> used anywhere in the document.
>>> 10. RFC6242 is listed as an informative reference, but it is not
> used
>> anywhere in the document.
>>> 11. the document fails to declare its normative references to
>> ietf-keystore and ietf-tls-client-server.
>>>          Note: you manually entered the "[RFC yyyy], and [RFC xxxx]"
>> references…
>>> 12.  The IANA considerations section seems asymmetric.  Either put
>> both registry insertions into
>>>          subsections, or keep them both at the top-level…
>>>
>>> 13. reviewing the final document against my original YD review, I
> have
>> the following responses.  Let's be sure to close out these items as
>> well.  Ref:
> https://mailarchive.ietf.org/arch/msg/netmod/10lo41Ud4A3ZN11
>> s-0gOfCe8NSE
>>> 1. ok
>>> 2. better
>>> 3. should be: s/the message/these messages/  [RFC Editor might've
>> caught this]
>>> 4. better
>>> 5. still feel the same way, but no biggee
>>> 6. better, but from 8174, you should add the part "when, and only
>> when, they appear in all capitals, as shown here."
>>> 7. fixed
>>> 8. fixed
>>> 9. you did what I asked, but the result still isn't satisfying...
>>> 10. some improvements made in this area, but my ask wasn't among
> them
>>> 11. better
>>> 12. better, but I think the 4th line should be indented too, right?
>>> 13. better, but I wish you called S1.3 "Tree Diagram Notation"
>>> 14. fixed
>>> 15. fixed
>>> 16. fixed
>>> 17. fine
>>> 18. still a weird line brake here.  try putting the quoted string on
>> the next line.
>>> 19. fixed
>>> 20. fixed
>>> 21. not fixed (re: yang-security-guidelines)
>>> 22. fine
>>>
>>>
>>> PS: please also be sure to follow-up with Benoit on his AD review.
>>>
>>> Thanks,
>>> Kent  // shepherd & yang doctor
>>>
>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>
>>
>>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Sep 27 03:52:03 2017
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 577F713430E; Wed, 27 Sep 2017 03:52:01 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.62.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150650952130.25003.1792240611663747386@ietfa.amsl.com>
Date: Wed, 27 Sep 2017 03:52:01 -0700
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-schema-mount-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Sep 2017 10:52:01 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

        Title           : YANG Schema Mount
        Authors         : Martin Bjorklund
                          Ladislav Lhotka
	Filename        : draft-ietf-netmod-schema-mount-07.txt
	Pages           : 27
	Date            : 2017-09-27

Abstract:
   This document defines a mechanism to combine YANG modules into the
   schema defined in other YANG modules.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-07
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-schema-mount-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-schema-mount-07


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Sep 27 03:57:32 2017
Return-Path: 
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 4D9B2134318 for ; Wed, 27 Sep 2017 03:57:31 -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 TjCgpTki_UQs for ; Wed, 27 Sep 2017 03:57: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 A671B13430E for ; Wed, 27 Sep 2017 03:57:29 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 9E0BB1AE0397 for ; Wed, 27 Sep 2017 12:57:28 +0200 (CEST)
Date: Wed, 27 Sep 2017 12:55:58 +0200 (CEST)
Message-Id: <20170927.125558.606437323539289377.mbj@tail-f.com>
To: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <150650952130.25003.1792240611663747386@ietfa.amsl.com>
References: <150650952130.25003.1792240611663747386@ietfa.amsl.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: [netmod] I-D Action: draft-ietf-netmod-schema-mount-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Sep 2017 10:57:31 -0000

Hi,

This version fixes the XPath context for parent-reference.


However, there is one more thing to discuss, which is the term "mount
point".  

The current text says:

   - mount point: container or list node whose definition contains
     the "mount-point" extension statement. The argument of the
     "mount-point" statement defines the name of the mount point.


So if we have:
    
  container top {
    container root {
      yangmnt:mount-point ni;
    }
  }
    
There is one mount point, the node /top/root, with the name "ni".

Pretty confusing...   Does anyone have any comments around this?



/martin





internet-drafts@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Network Modeling WG of the IETF.
> 
>         Title           : YANG Schema Mount
>         Authors         : Martin Bjorklund
>                           Ladislav Lhotka
> 	Filename        : draft-ietf-netmod-schema-mount-07.txt
> 	Pages           : 27
> 	Date            : 2017-09-27
> 
> Abstract:
>    This document defines a mechanism to combine YANG modules into the
>    schema defined in other YANG modules.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-07
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-schema-mount-07
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-schema-mount-07
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Wed Sep 27 06:31:10 2017
Return-Path: 
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 C1EC613301E for ; Wed, 27 Sep 2017 06:31:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lhqwJIrK3z7 for ; Wed, 27 Sep 2017 06:31:07 -0700 (PDT)
Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::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 D4AB513308D for ; Wed, 27 Sep 2017 06:31:06 -0700 (PDT)
Received: by mail-wr0-x235.google.com with SMTP id 108so16520317wra.5 for ; Wed, 27 Sep 2017 06:31:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=HXwzyjzttF9Gr6SOoeJCiZ7KMEwjHlK6l0dTxx466XQ=; b=V0qffVK5XW6hUu7oyEr3fFQaYMN7ktNKESjxZfT6nwLwDlzh9VZeHm6GrFsxC4ugiv Lgor4cIauXK4GhTRW7IqlOOGD8sD89btY5xnEJYZDtssKpsIN0yh0/v2FOydJWW+TdG8 7d5tLkumelLLSsdjQpfd3pBqiH0Zi1BR529J6Hz69gr+08DecJ1s/6fae2BIjhteSkC4 rI9daCHh98CaqmVWro0lDg0A9/545lRDdWd8mnXbol3f+ht5E0GSkh0JC8/QuG3xlc+m C7fwuWR0YL3hVw1VvMMwG+lxQ3VZz+9k4MuDLGGigOSnqhb9cKzXkFnpb/0OR8jrBtgB csPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=HXwzyjzttF9Gr6SOoeJCiZ7KMEwjHlK6l0dTxx466XQ=; b=TIehqC6vlP7LXW3PyygN6DeAj0vSCbpAqVu74KyGJER8eU2FbFMZUy9GozDojEgHu+ 3coOgA+54vKZHpnOpcv1OKTvVlJeZlIaoTd7ggHjTkI6yjDcjV3SvJmjNrfuiizFxEAo 4uTd/2H6YzN+ZtVby1pZftNRzIUysIl0v/RtNwgRylhKuwrSZbg0XE56a6x1MFwLpmim CK2hZNiD9II5rqF4Vh3xgMRF3SvZQ5CBCBw4aQ2YnxL3xzlP5tgNYDOy1US7UWXPljxC vcR+VwJLfyRiU1+ZdqcjK7r0UxeDpZ0frgWY/QOVR2LaELG6G/ZTczYIKQQqkyVPq1o5 fY3w==
X-Gm-Message-State: AMCzsaXwueaU1KMmrdp8uhDOHIzNstBXL7t9ZYecC0s0P2sgooYrONoP mp9fYyjlTLugp7FKx2HrL0E=
X-Google-Smtp-Source: AOwi7QDkgfP8wT3E033qw3uKl39rRSvx5L3DDEnhKyf6fInj0RBC14PW01yPZ2Mr4keAYoGlYoRTYw==
X-Received: by 10.25.78.81 with SMTP id c78mr559064lfb.133.1506519065228; Wed, 27 Sep 2017 06:31:05 -0700 (PDT)
Received: from xliuus (wsip-98-191-72-170.dc.dc.cox.net. [98.191.72.170]) by smtp.gmail.com with ESMTPSA id g12sm1678477lfd.64.2017.09.27.06.31.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Sep 2017 06:31:04 -0700 (PDT)
From: "Xufeng Liu" 
To: "'Martin Bjorklund'" 
Cc: , 
References: 	<20170925.193903.1777711656523405872.mbj@tail-f.com>	<005601d33673$1d27c180$57774480$@gmail.com> <20170926.083642.680914684763815093.mbj@tail-f.com>
In-Reply-To: <20170926.083642.680914684763815093.mbj@tail-f.com>
Date: Wed, 27 Sep 2017 09:31:01 -0400
Message-ID: <011001d33794$ddfb0760$99f11620$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGM5OWQIGcbPwETqqFBVCOq/XS5FwJLwRhDAXmsw7wCS2U42aMk1GkQ
Content-Language: en-us
Archived-At: 
Subject: Re: [netmod] Proposal to enhance the YANG tree output
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Sep 2017 13:31:10 -0000

> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com]
> Sent: Tuesday, September 26, 2017 2:37 AM
> To: xufeng.liu.ietf@gmail.com
> Cc: acee@cisco.com; netmod@ietf.org
> Subject: Re: [netmod] Proposal to enhance the YANG tree output
>=20
> "Xufeng Liu"  wrote:
> > To a user of the schema-mount, it is important to be able to =
visualize
> > all key elements of the mounting mechanism: mount-point, mounted
> > schema module, and parent-reference. The details can be worked out,
> > but if any of these elements were not useful in the presentation, it
> > would be questionable whether it had well-specified in the schema
> > mount draft.
>=20
> We agreed that we probably don't want to list all enums in the tree.
> Does that imply that enumerations are not well-specified in YANG?
>=20
> > > -----Original Message-----
> > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Martin
> > > Bjorklund
> > > Sent: Monday, September 25, 2017 1:39 PM
> > > To: acee@cisco.com
> > > Cc: netmod@ietf.org
> > > Subject: Re: [netmod] Proposal to enhance the YANG tree output
> > >
> > > "Acee Lindem (acee)"  wrote:
> > > > Martin, Lada, et al,
> > > >
> > > > While I don=E2=80=99t think we need additional annotations that =
Joe had
> > > > prototyped (at least not as the default), I strongly believe we
> > > > need to keep the =E2=80=98@=E2=80=98 and =E2=80=98/=E2=80=98 in =
the tree output for schema mount.
> > >
> > > Can you explain what information "/" gives the reader?  Compare
> > > these two
> > > trees:
> > >
> > >   +--mp vrf-root
> > >      +--rw rt:routing/
> > >         +--rw rt:router-id
> > >
> > > and
> > >
> > >   +--mp vrf-root
> > >      +--rw rt:routing
> > >         +--rw rt:router-id
> > >
> > > What did the "/" in the first tree tell me that I don't see in the
> > > second tree?
> >
> > [Xufeng] Because the schema mount draft allows an augmenting module
> > not to be listed in the mounted schema list. The following two
> > examples show two different configurations:
> >
> >   +--mp root
> >      +--rw rt:routing/
> >      |  +--rw router-id?                 yang:dotted-quad
> >      |  +--rw control-plane-protocols
> >      |     +--rw control-plane-protocol* [type name]
> >      |        +--rw ospf:ospf/
> >
> > where ospf augments rt, and has been listed in the mounting schema
> > list.
> >
> >   +--mp root
> >      +--rw rt:routing/
> >      |  +--rw router-id?                 yang:dotted-quad
> >      |  +--rw control-plane-protocols
> >      |     +--rw control-plane-protocol* [type name]
> >      |        +--rw ospf:ospf
> >
> > where ospf augments rt, and has not been listed in the mounting =
schema
> > list.
>=20
> If the ospf module is NOT listed in the yang library data for the =
mount point,

[Xufeng] I think that draft-ietf-netmod-schema-mount has the distinction =
between yang library data and schema-mounts/schema list. Do you mean the =
latter?

> then it will not be present in the tree.  So in this case the tree =
will be:
>=20
>    +--mp root
>       +--rw rt:routing
>       |  +--rw router-id?                 yang:dotted-quad
>       |  +--rw control-plane-protocols
>       |     +--rw control-plane-protocol* [type name]
>              // no ospf here
>=20
> [Think about it the other way around; if we were to show all nodes =
from all
> modules that are NOT mounted, our tree would be inifinitely big...]
>=20
> If the ospf module *is* listed in the yang library data for the mount =
point, then
> the tree can be:
>=20
>    +--mp root
>       +--rw rt:routing
>       |  +--rw router-id?                 yang:dotted-quad
>       |  +--rw control-plane-protocols
>       |     +--rw control-plane-protocol* [type name]
>       |        +--rw ospf:ospf
>=20
> No need for a '/'.
>=20
[Xufeng] What if the user does want to see all nodes in the system, =
whether they are mounted or un-mounted, is it possible?

Also, there is another case: I think that draft-ietf-netmod-schema-mount =
does not prohibit the mount-point container from containing other =
sub-containers. How can we tell these sub-containers are not from =
mounted modules?

   +--mp root
      +--rw rt:routing
      |  +--rw router-id?                 yang:dotted-quad
      |  +--rw control-plane-protocols
      |     +--rw control-plane-protocol* [type name]
      |        +--rw ospf:ospf
      +--rw other:other-container  // augmented by module "other"
      |  +--rw other-leaf?                 int32

>=20
> > > Then consider:
> > >
> > >   +--ro if:interfaces@
> > >
> > > and
> > >
> > >   +--ro if:interfaces
> > >      +-- if:interface@
> > >
> > > and
> > >
> > >   +--ro if:interfaces@
> > >      +-- if:interface@
> > >
> > >
> > > Which ones are legal, and what do they mean?
> > >
> > [Xufeng] The display shows the result of the XPath, right?
>=20
> I don't know what it shows; I'm not proposing this notation.  Also =
note that the
> result of the XPath is a node set of *instance data*, but the tree =
shows the
> *schema*, and mixing the two is confusing.
>=20
> Hopefully by looking at the trees above, the reader will understand =
what's
> behind this notation.  So I ask again, what do the notations above =
mean?
>=20
> > Whether
> > they are legal or not should be determined by the schema-mount =
draft,
> > not by the displaying notation.
>=20
> The schema mount draft does not specify the rules for the '@' in the =
tree output.
>=20
> --
>=20
> My points are that:
>=20
>   (1)  "/" is redundant and not needed.  The same information can be
>        conveyed w/o "/".
>=20
>   (2)  "@" is under specified, and it mixes schema and instance data.
[Xufeng] I agree that we should have "@" fully specified, but I'd hope =
that it won't get dropped so that there won't be a convenient way to =
tell whether a node is a parent-reference or not.

Thanks,
- Xufeng

>=20
>=20
>=20
> /martin
>=20
>=20
>=20
>=20
>=20
>=20
> >
> > >
> > >
> > > /martin
> > >
> > > While the former enhancement
> > > > provided details, the schema mount tree designations are every =
bit
> > > > as important as knowing, for example, whether or not a schema =
leaf
> > > > is a presence node.
> > > >
> > > > Thanks,
> > > > Acee
> > > >
> > > >
> > > > On 9/15/17, 9:56 AM, "Acee Lindem (acee)"  =
wrote:
> > > >
> > > > >+1 - Also it is hard enough to format the tree output to fit in =
a
> > > > >+draft
> > > > >w/o further annotations (even with =E2=80=94-tree-line-length).
> > > > >Thanks,
> > > > >Acee
> > > > >
> > > > >
> > > > >On 9/15/17, 6:21 AM, "netmod on behalf of Ladislav Lhotka"
> > > > > wrote:
> > > > >
> > > > >>Andy Bierman p=C3=AD=C5=A1e v =C4=8Ct 14. 09. 2017 v 08:43 =
-0700:
> > > > >>> Hi,
> > > > >>>
> > > > >>>
> > > > >>> Actually I liked the early pyang output that was concise and
> > > > >>>easy to remember.
> > > > >>> The current format gets very cluttered and there are too =
many
> > > > >>>little symbols  to remember them all.
> > > > >>
> > > > >>I agree.
> > > > >>
> > > > >>Lada
> > > > >>
> > > > >>>
> > > > >>>
> > > > >>> Andy
> > > > >>>
> > > > >>>
> > > > >>> On Thu, Sep 14, 2017 at 8:33 AM, Joe Clarke =

> wrote:
> > > > >>> > I've been hacking on pyang, and I changed tree.py to add =
the
> > > > >>> > enum
> > > > >>>values
> > > > >>> > for enumeration types and identiyref bases for identityref =
types.
> > > > >>>Here
> > > > >>> > is an example:
> > > > >>> >
> > > > >>> > module: yang-catalog
> > > > >>> >     +--rw catalog
> > > > >>> >        +--rw modules
> > > > >>> >        |  +--rw module* [name revision organization]
> > > > >>> >        |     +--rw name                     =
yang:yang-identifier
> > > > >>> >        |     +--rw revision                 union
> > > > >>> >        |     +--rw organization             string
> > > > >>> >        |     +--rw ietf
> > > > >>> >        |     |  +--rw ietf-wg?   string
> > > > >>> >        |     +--rw namespace                inet:uri
> > > > >>> >        |     +--rw schema?                  inet:uri
> > > > >>> >        |     +--rw generated-from?          enumeration =
[mib, code,
> > > > >>> > not-applicable, native]
> > > > >>> >        |     +--rw maturity-level?          enumeration =
[ratified,
> > > > >>> > adopted, initial, not-applicable] ...
> > > > >>> >                                +--rw protocols
> > > > >>> >                                |  +--rw protocol* [name]
> > > > >>> >                                |     +--rw name
> > > > >>> > identityref -> protocol
> > > > >>> > ...
> > > > >>> >
> > > > >>> > My questions are:
> > > > >>> >
> > > > >>> > 1. Is this useful?
> > > > >>> >
> > > > >>> > 2. If so, can this be added to pyang (happy to submit a =
PR)
> > > > >>> > and draft-ietf-netmod-yang-tree-diagrams?
> > > > >>> >
> > > > >>> > 3. What changes to the output format would you recommend?
> > > > >>> >
> > > > >>> > Thanks.
> > > > >>> >
> > > > >>> > Joe
> > > > >>> >
> > > > >>> > _______________________________________________
> > > > >>> > netmod mailing list
> > > > >>> > netmod@ietf.org
> > > > >>> > https://www.ietf.org/mailman/listinfo/netmod
> > > > >>>
> > > > >>> _______________________________________________
> > > > >>> netmod mailing list
> > > > >>> netmod@ietf.org
> > > > >>> https://www.ietf.org/mailman/listinfo/netmod
> > > > >>--
> > > > >>Ladislav Lhotka
> > > > >>Head, CZ.NIC Labs
> > > > >>PGP Key ID: 0xB8F92B08A9F76C67
> > > > >>
> > > > >>_______________________________________________
> > > > >>netmod mailing list
> > > > >>netmod@ietf.org
> > > > >>https://www.ietf.org/mailman/listinfo/netmod
> > > > >
> > > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >


From nobody Wed Sep 27 06:44:01 2017
Return-Path: 
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 7F8F613214D for ; Wed, 27 Sep 2017 06:43:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1zDsWmmFecL for ; Wed, 27 Sep 2017 06:43:57 -0700 (PDT)
Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::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 81D8D134B5E for ; Wed, 27 Sep 2017 06:43:44 -0700 (PDT)
Received: by mail-wr0-x231.google.com with SMTP id v109so16564547wrc.1 for ; Wed, 27 Sep 2017 06:43:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=jFOjjctfBO5FZoFaO5+6U9utejh6FWqkAEScFiKr6kQ=; b=LlZHxqy8Rff8vybxZD5t5/6RXi+FtBXBqbO7gzSWlIpiaA3uO2ATTCh8xrOv+ZfV85 Fo/lX2MQ0QxzKuv+Aw6PvM8Xifx+yUMaiJT1CLpGWrMHhRGC2VLbXEKdYOeKmxdsFPl0 q5LDJrbirt5vxNJewG93ySTCUf1Pq2haAVzWRgTfBsjWiqEzM9dshrlZ9dQUdhLTjUwz v4xsOrMk6aB5tMfHsqAdn/VQ/VcpjW8pdDPvT0paDv7W2/8BfQgQE1su+SPtjsehxFLj Q4yP4IFMhijA/fqzjQJktpQiaObAvFo6FuAC1ap/w4zxFtaSQ9u8nKO92cGep8uv5cIP /Dhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=jFOjjctfBO5FZoFaO5+6U9utejh6FWqkAEScFiKr6kQ=; b=KXZ6yLbWCDhFtRHzf65W2Svv3G/PbId1Q5MCHB2gLLeX24qRKenNec31nfBWDSnS9g HvX7qPXgRmtrI9lTcln4OtUSsRG4Hd/8EFrC9SA5AvzRl7mVA7Z3OppbuvLbrFHhtToD Vduw3b3d3LjfRolDFH93nEnvR7yPUmgMQv1h133/NyawtYDgl5UWGnZABb/4tVJM7AVI mmYj74wwrOHdshZ1IRPeGqXf7Lsksa0SV49IVgj3WT7dybM9HCoTnl7jICXL3uoV0+tR Ej3cl1Du3J+yoOsvF/lD4Vkv5jOQFam8r9LydTWfcFC1il1tGfqdEmOhP5glPFlJS6pH Gb8w==
X-Gm-Message-State: AHPjjUjxStEQEgq8cO81JT4V9aYwFlE/BWBpCJ6nElmTwW8wmFHoZt6S hqxPteBDrgL8uFHwUKbhXY4=
X-Google-Smtp-Source: AOwi7QDmL4mKr3XlBe5XFgLLzbVrUA/54RaqtiIfT6+P2qCDwh22r9zuyC+nByM9CfRmb/mo7KnYAA==
X-Received: by 10.46.4.154 with SMTP id a26mr737847ljf.6.1506519823055; Wed, 27 Sep 2017 06:43:43 -0700 (PDT)
Received: from xliuus (wsip-98-191-72-170.dc.dc.cox.net. [98.191.72.170]) by smtp.gmail.com with ESMTPSA id q190sm1713155lfe.51.2017.09.27.06.43.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Sep 2017 06:43:42 -0700 (PDT)
From: "Xufeng Liu" 
To: "'Martin Bjorklund'" , 
References: <150650952130.25003.1792240611663747386@ietfa.amsl.com> <20170927.125558.606437323539289377.mbj@tail-f.com>
In-Reply-To: <20170927.125558.606437323539289377.mbj@tail-f.com>
Date: Wed, 27 Sep 2017 09:43:40 -0400
Message-ID: <011301d33796$a1d3f100$e57bd300$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQMIT43kc5jtpSAat0yG5Djln5sx+AGe1P1yoFGMMrA=
Content-Language: en-us
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-schema-mount-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Sep 2017 13:43:59 -0000

Alternatively we can use "/top/root" as the name of the mount-point, then
there won't be case for 
  'A module MAY contain multiple "mount-point" statements having the same
argument.'
The "mount-point" extension statement won't take an argument, which will be
cleaner, and make the extension statement look more like a property
specifier than a node declaration.

Thanks,
- Xufeng

> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Martin
> Bjorklund
> Sent: Wednesday, September 27, 2017 6:56 AM
> To: netmod@ietf.org
> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-schema-mount-07.txt
> 
> Hi,
> 
> This version fixes the XPath context for parent-reference.
> 
> 
> However, there is one more thing to discuss, which is the term "mount
point".
> 
> The current text says:
> 
>    - mount point: container or list node whose definition contains
>      the "mount-point" extension statement. The argument of the
>      "mount-point" statement defines the name of the mount point.
> 
> 
> So if we have:
> 
>   container top {
>     container root {
>       yangmnt:mount-point ni;
>     }
>   }
> 
> There is one mount point, the node /top/root, with the name "ni".
> 
> Pretty confusing...   Does anyone have any comments around this?
> 
> 
> 
> /martin
> 
> 
> 
> 
> 
> internet-drafts@ietf.org wrote:
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> > This draft is a work item of the Network Modeling WG of the IETF.
> >
> >         Title           : YANG Schema Mount
> >         Authors         : Martin Bjorklund
> >                           Ladislav Lhotka
> > 	Filename        : draft-ietf-netmod-schema-mount-07.txt
> > 	Pages           : 27
> > 	Date            : 2017-09-27
> >
> > Abstract:
> >    This document defines a mechanism to combine YANG modules into the
> >    schema defined in other YANG modules.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-07
> > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-schema-mount-0
> > 7
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-schema-mount-07
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at
tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Sep 27 07:05:52 2017
Return-Path: 
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 E52C4132D8A for ; Wed, 27 Sep 2017 07:05:51 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 xymXnqsfbZrk for ; Wed, 27 Sep 2017 07:05:50 -0700 (PDT)
Received: from us-smtp-delivery-128.mimecast.com (us-smtp-delivery-128.mimecast.com [63.128.21.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C37C13239C for ; Wed, 27 Sep 2017 07:05:50 -0700 (PDT)
Received: from ex-hc2.corp.adtran.com (ex-hc3.adtran.com [76.164.174.83]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-86-3L8H47suNkCPUq_X-mgotw-1; Wed, 27 Sep 2017 10:05:48 -0400
Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc2.corp.adtran.com ([fe80::a019:449b:3f62:28e5%10]) with mapi id 14.03.0361.001; Wed, 27 Sep 2017 09:05:47 -0500
From: JOEY BOYD 
To: "'netmod@ietf.org'" 
Thread-Topic: Backward Compatibility Question
Thread-Index: AdM3mbcvie9AP8VEQcaGGyl32renDQ==
Date: Wed, 27 Sep 2017 14:05:46 +0000
Message-ID: <26CE489EF4611643B3EFE43D06E02654015E751148@ex-mb1.corp.adtran.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.22.112.103]
MIME-Version: 1.0
X-MC-Unique: 3L8H47suNkCPUq_X-mgotw-1
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: [netmod] Backward Compatibility Question
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Sep 2017 14:05:52 -0000

Hi all,

Suppose I had a published YANG model with the following leaf.


  leaf thing1 {
    type uint8;
    description
      "Thing 1.";
  }

Later, I realize that I wish I had modeled this in a choice as I now have a=
 mutually exclusive option to 'thing1' which I want to add to the model.

  leaf thing2 {
    type empty;
    description
      "Thing 2.";
  }

This is a very simplified example but should be sufficient to demonstrate t=
he problem.=20

If I look at the XML representation of 'thing1', it looks like this.

123

If I were to move 'thing1' into a choice with a single case, it would look =
like this.

choice things {
  case thing1 {
    leaf thing1 {
      type uint8;
      description
        "Thing 1.";
    }
  }
}

Looking to the XML representation, it looks the same as before.

123

To me, this means that taking a single node or set of nodes and moving them=
 under a case within a new choice statement is a backward compatible change=
. This assumes, of course, any mandatory or default behavior is preserved. =
I now can add 'thing2' to the existing model as an option to 'thing1'.

choice things {
  case thing1 {
    leaf thing1 {
      type uint8;
      description
        "Thing 1.";
    }
  }
  case thing2 {
    leaf thing2 {
      type empty;
      description
        "Thing 2.";
    }
  }
}

Do you agree with this analysis or am I missing something?

Best regards,
Joey


From nobody Wed Sep 27 09:12:45 2017
Return-Path: 
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 A7A79134DE1; Wed, 27 Sep 2017 09:12:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 7KQCEO-kMBrX; Wed, 27 Sep 2017 09:12:42 -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 02981134DE0; Wed, 27 Sep 2017 09:12:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4219; q=dns/txt; s=iport; t=1506528762; x=1507738362; h=subject:from:to:cc:references:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=G8JoTALB2EYCI3bqtclb2pnkdtGszJXSQ18j989UOzk=; b=XYH51SqHBraWFMt+ahl0gFM6a2ntdoShosa3oSPFcW/MtXjFPX5Lx4Lb 8D9VC1AhfRAaicdeF60AtX2rhAhA5gCj0y1jNSSJQtqyqQspmrT+vXL5E o3cM08IQQFs8cPFSgzUKxlAcLJdxrSx9M82Z8c9NsvGHAnxRl9gn11aGv Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DoAQCLzMtZ/xbLJq1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBhEBuhB+LE5BgljmCBAojhRgChR4VAQIBAQEBAQEBayiFGQEEASMPAQU?= =?us-ascii?q?6BxALEggCERUCAkkOEwgBAYolCBCoLIIniwQBAQEBAQUBAQEBAQEBHAWBDoIdg?= =?us-ascii?q?1OBaiuCfYQ/gQSCVIJgBaEjh16NAYITiUgkhweKDYNjh1mBOTUigQ4yIQgdFR+?= =?us-ascii?q?HSD+IJCyCFQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.42,445,1500940800"; d="scan'208";a="657867575"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Sep 2017 16:12:37 +0000
Received: from [10.63.23.161] (dhcp-ensft1-uk-vla370-10-63-23-161.cisco.com [10.63.23.161]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8RGCbMh027985; Wed, 27 Sep 2017 16:12:37 GMT
From: Robert Wilton 
To: netmod@ietf.org
Cc: netmod-chairs@ietf.org, draft-ietf-netmod-revised-datastores@ietf.org
References: <20170918.200734.1805388289423863575.mbj@tail-f.com>  <99b9a2c6-4bb4-121f-0cba-925cefe09712@cisco.com> <20170919.115559.1080249872764998055.mbj@tail-f.com> 
Message-ID: <1a50f499-d953-8d8d-995a-067c6da6aea8@cisco.com>
Date: Wed, 27 Sep 2017 17:12:37 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod]  vs 
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Sep 2017 16:12:45 -0000

We want to close on some of the NMDA document comments.  I'll send a 
separate summary for all the issues later, possible tomorrow.

In the absence of seeing any comments to the contrary, and with the 
change supported by the other authors, I will apply the proposed update 
to the  description below.

This should resolve two issues:
https://github.com/netmod-wg/datastore-dt/issues/9
  - Title: "Make it clear that validation of intended includes default 
values"

https://github.com/netmod-wg/datastore-dt/issues/3
- Title: "Enhance description of intended datastore"

Thanks,
Rob


>
> 3) I think that it would be useful to further refine my previous 
> proposed text for intended, particularly rewriting the text on 
> validation.  This should hopefully also address Balazs' concern about 
> default values be included in validation.
>
> 
>
> 4.4.  The Intended Configuration Datastore ()
>
>    The intended configuration datastore () is a read-only
>    configuration datastore.  It is tightly coupled to .  When
>    data is written to , the data that is to be validated is
>    also conceptually written to . Validation is performed on
>    the contents of .
>
>    For simple implementations,  and  are identical.
>
>     does not persist across reboots; its relationship with
>     makes that unnecessary.
>
>    Currently there are no standard mechanisms defined that affect
>     so that it would have different contents than ,
>    but this architecture allows for such mechanisms to be defined.
>
>    One example of such a mechanism is support for marking nodes as
>    inactive in .  Inactive nodes are not copied to ,
>    and are thus not taken into account when validating the
>    configuration.
>
>    Another example is support for templates.  Templates are expanded
>    when copied into , and the expanded result is validated.
>
> 
> 
>
> 4.1.4.  The Intended Configuration Datastore ()
>
>    The intended configuration datastore () is a read-only
>    configuration datastore.  It represents the configuration after all
>    configuration transformations to  are performed (e.g.
>    template expansion, removal of inactive configuration), and is the
>    configuration that the system attempts to apply.
>
>     is tightly coupled to . Whenever data is written
>    to , then  is also immediately updated by
>    performing all necessary transformations to the contents of 
>    and then  is validated.
>
>     may also be updated independently of  (e.g., if
>    one of the configuration transformations is changed), but 
>    must always be a 'valid configuration data tree' as defined in
>    Section 8.1 of [RFC7950].
>
>    For simple implementations,  and  are identical.
>
>    The contents of  is also related to the 'config true'
>    subset of , and hence a client can determine to what
>    extent the intended configuration is currently in use by checking
>    whether the contents of  also appears in .
>
>     does not persist across reboots; its relationship with
>     makes that unnecessary.
>
>    Currently there are no standard mechanisms defined that affect
>     so that it would have different contents than ,
>    but this architecture allows for such mechanisms to be defined.
>
>    One example of such a mechanism is support for marking nodes as
>    inactive in .  Inactive nodes are not copied to .
>    A second example is support for templates, which can perform
>    transformations on the configuration from  to the
>    configuration written to .
>
> 
>
> Thanks,
> Rob
>
>
>>
>>
>> /martin
>> .
>>
>
> .
>


From nobody Wed Sep 27 09:28:24 2017
Return-Path: 
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 CBD0E134E2A; Wed, 27 Sep 2017 09:28:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 0smGE3xEfAQT; Wed, 27 Sep 2017 09:28:20 -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 477FF134E28; Wed, 27 Sep 2017 09:28:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6986; q=dns/txt; s=iport; t=1506529699; x=1507739299; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=bBhv2nES5lYdpyYTmqGqZ4MebLQ9GtcxZmPoAa094lo=; b=TUr4umjRPC3VqQJyICSMbbPoqVztqzOxL6zursRksdAz7dRStBJaHBYF XpoTaxtb6gZuZdHVfZIsGbPGHGoYWUkzNgid2QKZmRbNbE19KQVp2jGBC FUXUqE6S8PmCT+h7JUPjmujG+nDtMIo3xhtk3cVXWcOdjaFX2TcIUZidy w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAQBF0MtZ/xbLJq1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYRAbieDeIsTkGCQbYdQCiODOoFeAoUfFAECAQEBAQEBAWsohRk?= =?us-ascii?q?BBSNkAgkSAgYnAwICGysDDgYBDAYCAQGKLRCKV51mgicnil4BAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEdBYMmg1OBaiuEOoNoJoJMgmAFmE+IVIdejQGCE4lIhyuKDYN?= =?us-ascii?q?jh1mBOTYhgQ4yIQgdFR+FCzkMEBmBTz82ii8BAQE?=
X-IronPort-AV: E=Sophos;i="5.42,445,1500940800";  d="scan'208,217";a="657867804"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Sep 2017 16:28:15 +0000
Received: from [10.63.23.161] (dhcp-ensft1-uk-vla370-10-63-23-161.cisco.com [10.63.23.161]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v8RGSE0I020031; Wed, 27 Sep 2017 16:28:15 GMT
To: netmod WG , NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <022001d32e14$8d5d4540$4001a8c0@gateway.2wire.net> <20170915123443.kvagu7dut7oaqoo2@elstar.local>  <20170916072403.xp37556z6g7b42gr@elstar.local> 
From: Robert Wilton 
Message-ID: <07b5a5df-794e-2ba8-6cad-abfcfadfc4cc@cisco.com>
Date: Wed, 27 Sep 2017 17:28:14 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------B29F64369E06B6D5412D01D7"
Content-Language: en-US
Archived-At: 
Subject: [netmod] RFC 2119 language [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Sep 2017 16:28:23 -0000

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

The authors discussed this, and we will close this issue 
(https://github.com/netmod-wg/datastore-dt/issues/14 - title: Does the 
NMDA architecture need to use RFC 2119 language?) by adding RFC 2119 
text to the document, which will probably be best illustrated with an 
updated draft revision.

For the record, the majority of the authors had the view that RFC 2119 
language does not particularly aid readability in this architecture 
document.

Thanks,
Rob


On 16/09/2017 10:56, Andy Bierman wrote:
>
>
> On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder 
>  > wrote:
>
>     On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
>     > Hi,
>     >
>     > I strongly agree with Tom that the current draft is an update to
>     RFC 7950.
>     > I also strongly disagree with the decision to omit RFC 2119 in a
>     standards
>     > track document. IMO RFC 2119 terms need to be used in normative
>     text,
>     > especially when dealing with XPath and YANG compiler behavior.
>     >
>
>     RFC 8174:
>
>        o  These words can be used as defined here, but using them is not
>           required.  Specifically, normative text does not require the use
>           of these key words.  They are used for clarity and consistency
>           when that is what's wanted, but a lot of normative text does not
>           use them and is still normative.
>
>
> So what?
> Existing YANG specifications use RFC 2119 terms.
> This draft uses those terms, just with lower-case.
> Either way, the new YANG rules seem half-baked and not ready
> for standardization.
>
>     /js
>
>
> Andy
>
>     --
>     Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>     Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>     Fax:   +49 421 200 3103              >
>
>


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


  
    
  
  
    
The authors discussed this, and we will close this issue
      (https://github.com/netmod-wg/datastore-dt/issues/14 - title: Does
      the NMDA architecture need to use RFC 2119 language?) by adding
      RFC 2119 text to the document, which will probably be best
      illustrated with an updated draft revision.

    
For the record, the majority of the authors had the view that RFC
      2119 language does not particularly aid readability in this
      architecture document.

    

    
Thanks,

      Rob

    

    

    
On 16/09/2017 10:56, Andy Bierman
      wrote:

    

    

      
      


        


          
On Sat, Sep 16, 2017 at 12:24 AM,
            Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
            wrote:

            
On Fri,
              Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:

              > Hi,

              >

              > I strongly agree with Tom that the current draft is
              an update to RFC 7950.

              > I also strongly disagree with the decision to omit
              RFC 2119 in a standards

              > track document. IMO RFC 2119 terms need to be used in
              normative text,

              > especially when dealing with XPath and YANG compiler
              behavior.

              >

              

              RFC 8174:

              

                 o  These words can be used as defined here, but using
              them is not

                    required.  Specifically, normative text does not
              require the use

                    of these key words.  They are used for clarity and
              consistency

                    when that is what's wanted, but a lot of normative
              text does not

                    use them and is still normative.

              

                

            


            

            
So what?

            
Existing YANG specifications use RFC 2119 terms.

            
This draft uses those terms, just with lower-case.

            
Either way, the new YANG rules seem half-baked and not
              ready

            
for standardization.

            


            

            
 

            

                  /js

                  

                

            


            

            
Andy

            
 

            

                  --

                  Juergen Schoenwaelder           Jacobs University
                  Bremen gGmbH

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

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

                

          

          

        

      

    

    

  


--------------B29F64369E06B6D5412D01D7--


From nobody Wed Sep 27 10:20:32 2017
Return-Path: 
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 B262F134E91 for ; Wed, 27 Sep 2017 10:20:26 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1rexLGHC4Fr for ; Wed, 27 Sep 2017 10:20:21 -0700 (PDT)
Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) (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 154D6134E8E for ; Wed, 27 Sep 2017 10:20:21 -0700 (PDT)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id BEF3C1E0850 for ; Wed, 27 Sep 2017 11:20:20 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id EhLG1w00g2SSUrH01hLKlQ; Wed, 27 Sep 2017 11:20:20 -0600
X-Authority-Analysis: v=2.2 cv=K4VSJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=2JCJgTwv5E4A:10 a=NEAV23lmAAAA:8 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=ZdAbnrQtolJFRyD-KY0A:9 a=QEXdDO2ut3YA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=9ZYBcOd_X9kS2t7VFny2:22 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: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=VRfuZNlqLhtq05ZA3xwmG8iRPNwg+laTW9H0BWghM/8=; b=RLe/ia3Tj1XtqF0ZHfwBDD8EY8 pDu7oIlIRHOPFuoNopVydmKl19j+xkj14rtjmMTpHwveLmYyctL3YYE5uzRAKvynbVkVhXSeJopSk UPY2nKEAjw+Ft8dYzskIu8jRF;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:35250 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dxG0O-003txJ-Ac; Wed, 27 Sep 2017 11:20:16 -0600
To: Robert Wilton , netmod WG , NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <022001d32e14$8d5d4540$4001a8c0@gateway.2wire.net> <20170915123443.kvagu7dut7oaqoo2@elstar.local>  <20170916072403.xp37556z6g7b42gr@elstar.local>  <07b5a5df-794e-2ba8-6cad-abfcfadfc4cc@cisco.com>
From: Lou Berger 
Message-ID: <4d345c3b-a28b-a0e0-27cb-306ff4618d0e@labn.net>
Date: Wed, 27 Sep 2017 13:20:13 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <07b5a5df-794e-2ba8-6cad-abfcfadfc4cc@cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dxG0O-003txJ-Ac
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:35250
X-Source-Auth: lberger@labn.net
X-Email-Count: 2
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] RFC 2119 language [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Sep 2017 17:20:26 -0000

I think this goes to if this, or any, draft is a proposed standard or
not. In other words, if it specifies any behavior that for which
interoperability between independent implementations is the objective. 
My general view is that in a Proposed Standard RFC, if it impacts
interoperability, the text should be normative and an RFC should use
2119 language to identify such normative text.  I accept that this is
not strictly required by IETF process, but it has become the norm for PS
track RFCs produced today  -- and I see no reason to not follow IETF norm.

In the context of this draft , as I read it, at least section 5.1 and
some portions of 4.

Lou

On 9/27/2017 12:28 PM, Robert Wilton wrote:
>
> The authors discussed this, and we will close this issue
> (https://github.com/netmod-wg/datastore-dt/issues/14 - title: Does the
> NMDA architecture need to use RFC 2119 language?) by adding RFC 2119
> text to the document, which will probably be best illustrated with an
> updated draft revision.
>
> For the record, the majority of the authors had the view that RFC 2119
> language does not particularly aid readability in this architecture
> document.
>
> Thanks,
> Rob
>
>
> On 16/09/2017 10:56, Andy Bierman wrote:
>>
>>
>> On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder
>> > > wrote:
>>
>>     On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
>>     > Hi,
>>     >
>>     > I strongly agree with Tom that the current draft is an update
>>     to RFC 7950.
>>     > I also strongly disagree with the decision to omit RFC 2119 in
>>     a standards
>>     > track document. IMO RFC 2119 terms need to be used in normative
>>     text,
>>     > especially when dealing with XPath and YANG compiler behavior.
>>     >
>>
>>     RFC 8174:
>>
>>        o  These words can be used as defined here, but using them is not
>>           required.  Specifically, normative text does not require
>>     the use
>>           of these key words.  They are used for clarity and consistency
>>           when that is what's wanted, but a lot of normative text
>>     does not
>>           use them and is still normative.
>>
>>
>> So what?
>> Existing YANG specifications use RFC 2119 terms.
>> This draft uses those terms, just with lower-case.
>> Either way, the new YANG rules seem half-baked and not ready
>> for standardization.
>>
>>  
>>
>>     /js
>>
>>
>> Andy
>>  
>>
>>     --
>>     Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>     Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen |
>>     Germany
>>     Fax:   +49 421 200 3103         >     >
>>
>>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Sep 27 10:26:26 2017
Return-Path: 
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 17E5D134E90; Wed, 27 Sep 2017 10:26:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 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, 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 m7iolv0cR0Ob; Wed, 27 Sep 2017 10:26:23 -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 B46EF1342EC; Wed, 27 Sep 2017 10:26:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12050; q=dns/txt; s=iport; t=1506533182; x=1507742782; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=P8XyzfjqutDqCpg2/Vw1926r9dwv3dRln8waqdzRbgk=; b=P1xY12HwpN0+SXVMf/lbMFruAzyCfRYulb+TMHSK5srNbp5qFZzr1JdR q/ZeRWyurd66dtRoDnzaPm2FhISIW64wE53/J69BpBlYj3SFz7qARIH/w cJSiBBvd7V9njDCJ7BUz2PSCU15LFT5ZlMEkrUssq7OOZkHWUWLHsSbvu w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BrAgB+3stZ/5tdJa1UCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNcZG4nB4NxmUwxgVQimD0KGAuESU8CGoRCVwECAQEBAQECayi?= =?us-ascii?q?FGAEBAQEDAQEhEToLDAQCAQgRBAEBAwImAgICJQsVCAgCBAENBYoxEKgogieLB?= =?us-ascii?q?AEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQ6CHYICgVGBaisLgnKCRYIVFC2CfC+?= =?us-ascii?q?CMQWRO49oAodcjQGCE4VuiwWVHAIRGQGBOAFXgQ54FUkSAYUHHIFndokfgRABA?= =?us-ascii?q?QE?=
X-IronPort-AV: E=Sophos;i="5.42,445,1500940800";  d="scan'208";a="9508763"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Sep 2017 17:26:21 +0000
Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8RHQL9U009046 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 27 Sep 2017 17:26:21 GMT
Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 27 Sep 2017 12:26:20 -0500
Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1320.000; Wed, 27 Sep 2017 12:26:20 -0500
From: "Clyde Wildes (cwildes)" 
To: "Benoit Claise (bclaise)" , Kent Watsen , "t.petch" , "netmod@ietf.org" 
CC: "draft-ietf-netmod-syslog-model@ietf.org" 
Thread-Topic: [netmod] syslog-model-17 shepherd writeup issues -references
Thread-Index: AQHTLHc0MtKErjQWME+Yl1a8S7HtcKKzYLeAgAEvaqSAAFV3AIAUCv4AgAAAaIA=
Date: Wed, 27 Sep 2017 17:26:20 +0000
Message-ID: <8015AC50-45CE-4813-B77B-8D1D3D3BC349@cisco.com>
References: <49B4BE2F-6912-49BE-9E4A-830146309AB2@juniper.net> <019b01d32c76$fa7dfc40$4001a8c0@gateway.2wire.net> <8CF097E4-CEB7-4C4E-AC7D-F7F896CD1BB7@juniper.net> <00ae01d32d74$49e24c20$4001a8c0@gateway.2wire.net> <5CE9EE07-D75D-4E5C-BC70-1F969732A526@juniper.net> <8e873d52-a6bd-87ee-9ff5-62c85eb5b6dc@cisco.com>
In-Reply-To: <8e873d52-a6bd-87ee-9ff5-62c85eb5b6dc@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.154.131.1]
Content-Type: text/plain; charset="utf-8"
Content-ID: <17BFC603EA031446B9EC11B886657E20@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] syslog-model-17 shepherd writeup issues -references
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Sep 2017 17:26:25 -0000

QmVub2l0LA0KDQpUaGVyZSB3ZXJlIGFwcHJveGltYXRlbHkgMjQgY2hhbmdlcyByZXF1ZXN0ZWQg
ZnJvbSB5b3UsIEtlbnQsIFJvYmVydCBXaWx0b24sIGFuZCBUb20gUGV0Y2guIEkgaGF2ZSBtYWRl
IGFwcHJveGltYXRlbHkgaGFsZiBvZiB0aGVtIGFuZCB3aWxsIHRyeSB0byBmaW5pc2ggYW5vdGhl
ciByZXZpc2lvbiBvZiB0aGUgZHJhZnQgYnkgRnJpZGF5Lg0KDQpUaGFua3MsDQoNCkNseWRlDQoN
Ck9uIDkvMjcvMTcsIDM6MjQgQU0sICJCZW5vaXQgQ2xhaXNlIChiY2xhaXNlKSIgPGJjbGFpc2VA
Y2lzY28uY29tPiB3cm90ZToNCg0KICAgIENseWRlLA0KICAgIA0KICAgIERvIHlvdSBrbm93IHlv
dXIgbmV4dCBzdGVwIHRvIHByb2dyZXNzIHRoaXMgZG9jdW1lbnQ/DQogICAgDQogICAgUmVnYXJk
cywgQmVub2l0DQogICAgPiBJIG1lYW50IHRvIHNheSBzb21ldGhpbmcgYWJvdXQgdGhlIC4xIHZz
IC4yIGRpZmZlcmVuY2UuICBNeSBjb21tZW50DQogICAgPiBhc3N1bWVzIHRoYXQgaXQncyBzdXBw
b3NlZCB0byBiZSAuMSwgYnV0IHdlIG9mIGNvdXJzZSBzaG91bGQgdXNlDQogICAgPiB3aGF0ZXZl
ciBpcyBjb3JyZWN0Lg0KICAgID4NCiAgICA+IEkgYWxzbyBkb24ndCBrbm93IG11Y2ggYWJvdXQg
dGhhdCBzdGFuZGFyZHMgYm9keS4NCiAgICA+DQogICAgPiBLLg0KICAgID4NCiAgICA+DQogICAg
Pg0KICAgID4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KICAgID4gRnJvbTogIktlbnQg
V2F0c2VuIiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4NCiAgICA+IFNlbnQ6IFdlZG5lc2RheSwgU2Vw
dGVtYmVyIDEzLCAyMDE3IDY6MDggUE0NCiAgICA+DQogICAgPj4gSGkgVG9tLA0KICAgID4+DQog
ICAgPj4gVGhhbmtzLiAgVGhlIGZpeCBJJ20gbG9va2luZyBmb3IgaXMgZm9yIHRoZSAncGF0dGVy
bi1tYXRjaCcgbGVhZg0KICAgID4+IHRvIGhhdmUgYSAncmVmZXJlbmNlJyBzdGF0ZW1lbnQgdG8g
U3RkLTEwMDMuMS0yMDA4LCBhbmQgZm9yIFM0LjENCiAgICA+PiB0byBhbHNvIGxpc3QgU3RkLTEw
MDMuMS0yMDA4IGFzIGEgZHJhZnQtbGV2ZWwgcmVmZXJlbmNlLg0KICAgID4gYW5kIEkgYW0gdW5m
YW1pbGlhciB3aXRoIHRoYXQgc3RhbmRhcmRzIGJvZHkgc28gYW0gbG9va2luZyBmb3IgYSBsaXR0
bGUNCiAgICA+IG1vcmUuDQogICAgPg0KICAgID4gSXMgU1RELW5ubm4gYWx3YXlzIFBvc2l4IG9y
IGRvIHdlIG5lZWQgdG8gc2F5IFBvc2l4IDEwMDMgb3IgUG9zaXgNCiAgICA+IFN0ZC0xMDAzIG9y
IGlzIFN0ZC0xMDAzIGNvbXBsZXRlbHkgdW5yZWxhdGVkIHRvIFBvc2l4IDEwMDM/DQogICAgPg0K
ICAgID4gSXMgdGhlcmUgYSBkaWZmZXJlbmNlIGJldHdlZW4gU3RkLTEwMDMuMS0yMDA4IGFuZCBQ
b3NpeCAxMDAzLjIgaWUgaXMgdGhlDQogICAgPiAuMSBvciAuMiBzaWduaWZpY2FudD8gIFlvdSB3
YW50IFN0ZC0xMDAzLjE7IHRoZSBkZXNjcmlwdGlvbiBjb250YWlucw0KICAgID4gUG9zaXggMTAw
My4yOyB0aGUgbm9ybWF0aXZlIFJlZmVyZW5jZSBpcyB0byBTdGQtMTAwMy4xLTIwMDguDQogICAg
Pg0KICAgID4gWW91IHBvaW50ZWQgb3V0IHRoYXQgdGhlIE5vcm1hdGl2ZSBSZWZlcmVuY2UgaXMg
bm90IHVzZWQ7IHdlbGwgaWYgd2UgY2FuDQogICAgPiBzb3J0IG91dCB3aGF0IHRoZSBzdGFuZGFy
ZCBpcyBhbmQgZ2V0IHRoZSByaWdodCBsYWJlbCBpbiBOb3JtYXRpdmUNCiAgICA+IFJlZmVyZW5j
ZXMgdGhlbiB3ZSBjYW4gLSBtdXN0IC0gaW5jbHVkZSB0aGlzIGluIFNlY3Rpb24gNC4xIHdoaWNo
IHdpbGwNCiAgICA+IHJlc29sdmUgdGhhdCBjb21tZW50IG9mIHlvdXJzLg0KICAgID4NCiAgICA+
IFRoZSBkaXNjdXNzaW9ucyBsYXN0IEp1bHkgaGFkIENseWRlIHNheWluZyBoZSB3YW50cyBQb3Np
eCAxMDAzLjIgc28gaWYNCiAgICA+IFN0ZC0xMDAzIGFuZCBQb3NpeCAxMDAzIGFyZSB0aGUgc2Ft
ZSBidXQgLjEgYW5kLjIgYXJlIGRpZmZlcmVudCwgdGhlbg0KICAgID4geW91IGFyZSBhc2tpbmcg
Zm9yIGEgc2VtYW50aWMgY2hhbmdlIGFnYWluc3QgQ2x5ZGUncyB3aXNoZXMuDQogICAgPg0KICAg
ID4gSSBob3BlIG15IGNvbmZ1c2lvbiBpcyBzdWZmaWNpZW50bHkgY2xlYXIsIGF0IGxlYXN0IHRv
IENseWRlIQ0KICAgID4NCiAgICA+IFRvbSBQZXRjaA0KICAgID4NCiAgICA+PiBJIHdhcyBnb2lu
ZyB0byBwb2ludCBvdXQgdGhlIHR5cG8gInRoZSB0aGUiIGFzIHdlbGwsIGJ1dCBmaWd1cmVkDQog
ICAgPj4gdGhhdCB0aGUgUkZDIEVkaXRvciB3b3VsZCBnZXQgaXQuDQogICAgPj4NCiAgICA+PiBL
LiAvLyBzaGVwaGVyZA0KICAgID4+DQogICAgPj4NCiAgICA+PiAtLQ0KICAgID4+DQogICAgPj4g
S2VudA0KICAgID4+DQogICAgPj4gWW91IGZsYWcgU3RkLTEwMDMuMS0yMDA4IGFzIGxpc3RlZCBh
cyBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgYnV0IG5vdA0KICAgID4gdXNlZA0KICAgID4+IGFueXdo
ZXJlIGluIHRoZSBkb2N1bWVudC4gIEluIHRoZSBEZXNjcmlwdGlvbnMsIGJ1dCBub3QgaW4gdGhl
IHMuNC4xDQogICAgPj4gcmVmZXJlbmNlcywgSSBzZWUNCiAgICA+Pg0KICAgID4+IFRoaXMgbGVh
ZiBkZXNjcmliZXMgYSBQb3NpeCAxMDAzLjIgcmVndWxhciBleHByZXNzaW9uIC4uLg0KICAgID4+
DQogICAgPj4gdHdpY2UsIHdoaWNoIG1heSwgb3IgbWF5IG5vdCwgcmVsYXRlIHRvIHRoaXMgaXNz
dWUuDQogICAgPj4NCiAgICA+PiBCYWNrIGluIEp1bHksIGNseWRlIHNhaWQNCiAgICA+PiAiSSB3
aWxsIGluc2VydCBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gUE9TSVggMTAwMy4yIGluIHRoZSBu
ZXh0DQogICAgPj4gcmV2aXNpb24gb2YgdGhlIGRyYWZ0LiINCiAgICA+Pg0KICAgID4+IEluIGEg
c2ltaWxhciB2ZWluLCBSRkM2OTkxIGFwcGVhcnMgaW4gYSByZWZlcmVuY2Ugc3RhdGVtZW50IGJ1
dA0KICAgID4gbm93aGVyZQ0KICAgID4+IGVsc2UuDQogICAgPj4NCiAgICA+PiBBcyB5b3UgcG9p
bnQgb3V0LCBSRkM2MDIxIGlzIHJlZmVyZW5jZWQgYnV0IGlzIG9ic29sZXRlZCBieSBSRkM2OTkx
IHNvDQogICAgPj4gc2hvdWxkIG5vdCBiZS4NCiAgICA+Pg0KICAgID4+IEFuZCBpbiBhIHNsaWdo
dGx5IGRpZmZlcmVudCB2ZWluLA0KICAgID4+DQogICAgPj4gICAgIHJlZ2lzdHJ5IFtSRkM3ODk1
XS8+LiAgRm9sbG93aW5nIHRoZSBmb3JtYXQgaW4gW1JGQzc5NTBdLz4sIHRoZSB0aGUNCiAgICA+
Pg0KICAgID4+IGxvb2tzIG9kZCBmb3IgcGxhaW4gdGV4dCBhbmQgZm9yIHRoZSByZXBldGl0aW9u
IG9mICd0aGUnLi4NCiAgICA+Pg0KICAgID4+IFRvbSBQZXRjaA0KICAgID4+DQogICAgPj4gLS0t
LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KICAgID4+IEZyb206ICJLZW50IFdhdHNlbiIgPGt3
YXRzZW5AanVuaXBlci5uZXQ+DQogICAgPj4gVG86IDxuZXRtb2RAaWV0Zi5vcmc+DQogICAgPj4g
Q2M6IDxkcmFmdC1pZXRmLW5ldG1vZC1zeXNsb2ctbW9kZWxAaWV0Zi5vcmc+DQogICAgPj4gU2Vu
dDogVHVlc2RheSwgU2VwdGVtYmVyIDEyLCAyMDE3IDEwOjUwIFBNDQogICAgPj4gU3ViamVjdDog
W25ldG1vZF0gc3lzbG9nLW1vZGVsLTE3IHNoZXBoZXJkIHdyaXRldXAgaXNzdWVzDQogICAgPj4N
CiAgICA+Pg0KICAgID4+PiBDbHlkZSwgYWxsLA0KICAgID4+Pg0KICAgID4+PiBJbiByZXZpZXdp
bmcgdGhlIGRyYWZ0IGZvciBTaGVwaGVyZCB3cml0ZXVwLCBJIGZvdW5kIHRoZSBmb2xsb3dpbmcN
CiAgICA+PiBpc3N1ZXMgdGhhdCBJIHRoaW5rIG5lZWQgdG8gYmUgYWRkcmVzc2VkIGJlZm9yZSB0
aGUgZG9jdW1lbnQgY2FuIGJlDQogICAgPiBzZW50DQogICAgPj4gdG8gQmVub2l0IGZvciBBRCBy
ZXZpZXc6DQogICAgPj4+DQogICAgPj4+IDEuIElkbml0cyBmb3VuZCB0aGUgZm9sbG93aW5nOg0K
ICAgID4+Pg0KICAgID4+PiAgICBTdW1tYXJ5OiAzIGVycm9ycyAoKiopLCAwIGZsYXdzICh+fiks
IDMgd2FybmluZ3MgKD09KSwgMSBjb21tZW50DQogICAgPj4gKC0tKS4NCiAgICA+Pj4gICAgICAq
KiBUaGVyZSBhcmUgMiBpbnN0YW5jZXMgb2YgdG9vIGxvbmcgbGluZXMgaW4gdGhlIGRvY3VtZW50
LCB0aGUNCiAgICA+PiBsb25nZXN0IG9uZQ0KICAgID4+PiAgICAgICAgICAgYmVpbmcgMyBjaGFy
YWN0ZXJzIGluIGV4Y2VzcyBvZiA3Mi4NCiAgICA+Pj4NCiAgICA+Pj4gICAgICAqKiBPYnNvbGV0
ZSBub3JtYXRpdmUgcmVmZXJlbmNlOiBSRkMgNjAyMSAoT2Jzb2xldGVkIGJ5IFJGQw0KICAgID4g
Njk5MSkNCiAgICA+Pj4gICAgICAqKiBEb3ducmVmOiBOb3JtYXRpdmUgcmVmZXJlbmNlIHRvIGFu
IEhpc3RvcmljIFJGQzogUkZDIDY1ODcNCiAgICA+Pj4NCiAgICA+Pj4gICAgICA9PSBNaXNzaW5n
IFJlZmVyZW5jZTogJ1JGQzU0MjUnIGlzIG1lbnRpb25lZCBvbiBsaW5lIDM1OSwgYnV0DQogICAg
PiBub3QNCiAgICA+PiBkZWZpbmVkDQogICAgPj4+ICAgICAgICAgICAnW1JGQzU0MjVdLCBbUkZD
NTQyNl0sIFtSRkM2NTg3XSwgYW5kIFtSRkM1ODQ4XS4uLi4nDQogICAgPj4+DQogICAgPj4+ICAg
ICAgID09IFVudXNlZCBSZWZlcmVuY2U6ICdSRkM3ODk1JyBpcyBkZWZpbmVkIG9uIGxpbmUgMTQw
NiwgYnV0IG5vDQogICAgPj4gZXhwbGljaXQNCiAgICA+Pj4gICAgICAgICAgICByZWZlcmVuY2Ug
d2FzIGZvdW5kIGluIHRoZSB0ZXh0DQogICAgPj4+ICAgICAgICAgICAgJ1tSRkM3ODk1XSAgQmll
cm1hbiwgQS4sIEJqb3JrbHVuZCwgTS4sIGFuZCBLLiBXYXRzZW4sDQogICAgPiAiWUFORw0KICAg
ID4+IE1vZHVsZSBMLi4uJw0KICAgID4+PiAgICAgICA9PSBVbnVzZWQgUmVmZXJlbmNlOiAnUkZD
NjI0MicgaXMgZGVmaW5lZCBvbiBsaW5lIDE0MzUsIGJ1dCBubw0KICAgID4+IGV4cGxpY2l0DQog
ICAgPj4+ICAgICAgICAgICAgcmVmZXJlbmNlIHdhcyBmb3VuZCBpbiB0aGUgdGV4dA0KICAgID4+
PiAgICAgICAgICAgICdbUkZDNjI0Ml0gIFdhc3Nlcm1hbiwgTS4sICJVc2luZyB0aGUgTkVUQ09O
RiBQcm90b2NvbA0KICAgID4gb3Zlcg0KICAgID4+IFNlY3VyZSBTaC4uLicNCiAgICA+Pj4NCiAg
ICA+Pj4gMi4gYHJmY3N0cmlwYCBleHRyYWN0ZWQgImlldGYtc3lzbG9nLnlhbmciLCAgd2hpY2gg
aXMgbWlzc2luZw0KICAgID4+ICJAeXl5eS1tbS1kZCIgaW4gaXRzIG5hbWUNCiAgICA+Pj4gMy4g
IG5laXRoZXIgYHB5YW5nYCBub3IgYHlhbmdsaW50YCBmb3VuZCBhbnkgZXJyb3JzIHdpdGgNCiAg
ICA+PiBpZXRmLXN5c2xvZy55YW5nLiAgICBweWFuZyBzYXlzDQogICAgPj4+ICAgICAgICBmb3Ig
dmVuZG9yLXN5c2xvZy10eXBlcy1leGFtcGxlOiBzdGF0ZW1lbnQgImlkZW50aXR5IiBtdXN0DQog
ICAgPiBoYXZlDQogICAgPj4gYSAiZGVzY3JpcHRpb24iDQogICAgPj4+ICAgICAgICBzdWJzdGF0
ZW1lbnQuDQogICAgPj4+DQogICAgPj4+IDQuIHRlc3RpbmcgdGhlIGV4YW1wbGVzIGluIHRoZSBk
cmFmdCBhZ2FpbnN0IHlhbmdsaW50Og0KICAgID4+PiAgICAgICAgLSBmb3IgYm90aCBleGFtcGxl
czogTWlzc2luZyBlbGVtZW50J3MgIm5hbWVzcGFjZSIuICgvY29uZmlnKQ0KICAgID4+PiAgICAg
ICAgLSBqdXN0IHJlbW92aW5nIHRoZSAiPGNvbmZpZz4iIGVsZW1lbnQgZW52ZWxvcCByZXNvbHZl
cyB0aGlzDQogICAgPj4gZXJyb3IuDQogICAgPj4+IDUuIHRoZSAybmQgZXhhbXBsZSB1c2VzIElQ
IGFkZHJlc3MgIjIwMDE6ZGI4OmEwYjoxMmYwOjoxIiwgYnV0IHRoaXMNCiAgICA+PiBTSE9VTEQg
YmUgYQ0KICAgID4+PiAgICAgICBkb21haW4gbmFtZSAoZS5nLiwgZm9vLmV4YW1wbGUuY29tKQ0K
ICAgID4+Pg0KICAgID4+PiA2LiBpbiB0aGUgWUFORyBtb2R1bGUsIGFueXdoZXJlIHlvdSBoYXZl
IGFuIFJGQyBsaXN0ZWQgaW4gYQ0KICAgID4+ICdkZXNjcmlwdGlvbicgc3RhdGVtZW50LA0KICAg
ID4+PiAgICAgICB0aGVyZSBzaG91bGQgYmUgYSAncmVmZXJlbmNlJyBzdGF0ZW1lbnQgZm9yIHRo
YXQgUkZDLg0KICAgID4+Pg0KICAgID4+PiA3LiBpbiB0aGUgdHJlZSBkaWFncmFtLCB0aGUgbGVh
ZnJlZnMgbm8gbG9uZ2VyIGluZGljYXRlIHdoYXQgdGhleQ0KICAgID4+IHBvaW50IGF0LCB0aGV5
IG5vdyBhbGwNCiAgICA+Pj4gICAgICAganVzdCBzYXkgImxlYWZyZWYiLiAgRGlkIHlvdSBkbyB0
aGlzIG9uIHB1cnBvc2UsIG9yIGFyZSB5b3UNCiAgICA+IHVzaW5nDQogICAgPj4gYSBkaWZmZXJl
bnQgdHJlZQ0KICAgID4+PiAgICAgICBvdXRwdXQgZ2VuZXJhdG9yIGZyb20gLTE1Pw0KICAgID4+
Pg0KICAgID4+PiA4LiBSRkM2NTM2IGlzIGxpc3RlZCBhcyBhIG5vcm1hdGl2ZSByZWZlcmVuY2Us
IGJ1dCBpdCBwcm9iYWJseQ0KICAgID4gc2hvdWxkDQogICAgPj4gYmUgaW5mb3JtYXRpdmUuDQog
ICAgPj4+IDkuIFN0ZC0xMDAzLjEtMjAwOCBpcyBsaXN0ZWQgYXMgYSBub3JtYXRpdmUgcmVmZXJl
bmNlLCBidXQgaXQgaXMgbm90DQogICAgPj4gdXNlZCBhbnl3aGVyZSBpbiB0aGUgZG9jdW1lbnQu
DQogICAgPj4+IDEwLiBSRkM2MjQyIGlzIGxpc3RlZCBhcyBhbiBpbmZvcm1hdGl2ZSByZWZlcmVu
Y2UsIGJ1dCBpdCBpcyBub3QNCiAgICA+IHVzZWQNCiAgICA+PiBhbnl3aGVyZSBpbiB0aGUgZG9j
dW1lbnQuDQogICAgPj4+IDExLiB0aGUgZG9jdW1lbnQgZmFpbHMgdG8gZGVjbGFyZSBpdHMgbm9y
bWF0aXZlIHJlZmVyZW5jZXMgdG8NCiAgICA+PiBpZXRmLWtleXN0b3JlIGFuZCBpZXRmLXRscy1j
bGllbnQtc2VydmVyLg0KICAgID4+PiAgICAgICAgICBOb3RlOiB5b3UgbWFudWFsbHkgZW50ZXJl
ZCB0aGUgIltSRkMgeXl5eV0sIGFuZCBbUkZDIHh4eHhdIg0KICAgID4+IHJlZmVyZW5jZXPigKYN
CiAgICA+Pj4gMTIuICBUaGUgSUFOQSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIHNlZW1zIGFzeW1t
ZXRyaWMuICBFaXRoZXIgcHV0DQogICAgPj4gYm90aCByZWdpc3RyeSBpbnNlcnRpb25zIGludG8N
CiAgICA+Pj4gICAgICAgICAgc3Vic2VjdGlvbnMsIG9yIGtlZXAgdGhlbSBib3RoIGF0IHRoZSB0
b3AtbGV2ZWzigKYNCiAgICA+Pj4NCiAgICA+Pj4gMTMuIHJldmlld2luZyB0aGUgZmluYWwgZG9j
dW1lbnQgYWdhaW5zdCBteSBvcmlnaW5hbCBZRCByZXZpZXcsIEkNCiAgICA+IGhhdmUNCiAgICA+
PiB0aGUgZm9sbG93aW5nIHJlc3BvbnNlcy4gIExldCdzIGJlIHN1cmUgdG8gY2xvc2Ugb3V0IHRo
ZXNlIGl0ZW1zIGFzDQogICAgPj4gd2VsbC4gIFJlZjoNCiAgICA+IGh0dHBzOi8vbWFpbGFyY2hp
dmUuaWV0Zi5vcmcvYXJjaC9tc2cvbmV0bW9kLzEwbG80MVVkNEEzWk4xMQ0KICAgID4+IHMtMGdP
ZkNlOE5TRQ0KICAgID4+PiAxLiBvaw0KICAgID4+PiAyLiBiZXR0ZXINCiAgICA+Pj4gMy4gc2hv
dWxkIGJlOiBzL3RoZSBtZXNzYWdlL3RoZXNlIG1lc3NhZ2VzLyAgW1JGQyBFZGl0b3IgbWlnaHQn
dmUNCiAgICA+PiBjYXVnaHQgdGhpc10NCiAgICA+Pj4gNC4gYmV0dGVyDQogICAgPj4+IDUuIHN0
aWxsIGZlZWwgdGhlIHNhbWUgd2F5LCBidXQgbm8gYmlnZ2VlDQogICAgPj4+IDYuIGJldHRlciwg
YnV0IGZyb20gODE3NCwgeW91IHNob3VsZCBhZGQgdGhlIHBhcnQgIndoZW4sIGFuZCBvbmx5DQog
ICAgPj4gd2hlbiwgdGhleSBhcHBlYXIgaW4gYWxsIGNhcGl0YWxzLCBhcyBzaG93biBoZXJlLiIN
CiAgICA+Pj4gNy4gZml4ZWQNCiAgICA+Pj4gOC4gZml4ZWQNCiAgICA+Pj4gOS4geW91IGRpZCB3
aGF0IEkgYXNrZWQsIGJ1dCB0aGUgcmVzdWx0IHN0aWxsIGlzbid0IHNhdGlzZnlpbmcuLi4NCiAg
ICA+Pj4gMTAuIHNvbWUgaW1wcm92ZW1lbnRzIG1hZGUgaW4gdGhpcyBhcmVhLCBidXQgbXkgYXNr
IHdhc24ndCBhbW9uZw0KICAgID4gdGhlbQ0KICAgID4+PiAxMS4gYmV0dGVyDQogICAgPj4+IDEy
LiBiZXR0ZXIsIGJ1dCBJIHRoaW5rIHRoZSA0dGggbGluZSBzaG91bGQgYmUgaW5kZW50ZWQgdG9v
LCByaWdodD8NCiAgICA+Pj4gMTMuIGJldHRlciwgYnV0IEkgd2lzaCB5b3UgY2FsbGVkIFMxLjMg
IlRyZWUgRGlhZ3JhbSBOb3RhdGlvbiINCiAgICA+Pj4gMTQuIGZpeGVkDQogICAgPj4+IDE1LiBm
aXhlZA0KICAgID4+PiAxNi4gZml4ZWQNCiAgICA+Pj4gMTcuIGZpbmUNCiAgICA+Pj4gMTguIHN0
aWxsIGEgd2VpcmQgbGluZSBicmFrZSBoZXJlLiAgdHJ5IHB1dHRpbmcgdGhlIHF1b3RlZCBzdHJp
bmcgb24NCiAgICA+PiB0aGUgbmV4dCBsaW5lLg0KICAgID4+PiAxOS4gZml4ZWQNCiAgICA+Pj4g
MjAuIGZpeGVkDQogICAgPj4+IDIxLiBub3QgZml4ZWQgKHJlOiB5YW5nLXNlY3VyaXR5LWd1aWRl
bGluZXMpDQogICAgPj4+IDIyLiBmaW5lDQogICAgPj4+DQogICAgPj4+DQogICAgPj4+IFBTOiBw
bGVhc2UgYWxzbyBiZSBzdXJlIHRvIGZvbGxvdy11cCB3aXRoIEJlbm9pdCBvbiBoaXMgQUQgcmV2
aWV3Lg0KICAgID4+Pg0KICAgID4+PiBUaGFua3MsDQogICAgPj4+IEtlbnQgIC8vIHNoZXBoZXJk
ICYgeWFuZyBkb2N0b3INCiAgICA+Pj4NCiAgICA+Pj4NCiAgICA+Pj4NCiAgICA+Pj4gX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+Pj4gbmV0bW9k
IG1haWxpbmcgbGlzdA0KICAgID4+PiBuZXRtb2RAaWV0Zi5vcmcNCiAgICA+Pj4gaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCiAgICA+Pj4NCiAgICA+Pg0KICAg
ID4+DQogICAgPj4NCiAgICA+DQogICAgPg0KICAgID4gX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCiAgICA+
IG5ldG1vZEBpZXRmLm9yZw0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9uZXRtb2QNCiAgICANCiAgICANCg0K


From nobody Wed Sep 27 10:41:44 2017
Return-Path: 
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 D55A6134EB9; Wed, 27 Sep 2017 10:41:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6KH593IM6BFp; Wed, 27 Sep 2017 10:41:40 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B8CCE134EBB; Wed, 27 Sep 2017 10:41:40 -0700 (PDT)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id AEE8C1AE0397; Wed, 27 Sep 2017 19:41:39 +0200 (CEST)
Date: Wed, 27 Sep 2017 19:41:39 +0200 (CEST)
Message-Id: <20170927.194139.78699449443066932.mbj@tail-f.com>
To: lberger@labn.net
Cc: rwilton@cisco.com, netmod@ietf.org, netmod-chairs@ietf.org, draft-ietf-netmod-revised-datastores@ietf.org
From: Martin Bjorklund 
In-Reply-To: <4d345c3b-a28b-a0e0-27cb-306ff4618d0e@labn.net>
References:  <07b5a5df-794e-2ba8-6cad-abfcfadfc4cc@cisco.com> <4d345c3b-a28b-a0e0-27cb-306ff4618d0e@labn.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] RFC 2119 language
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Sep 2017 17:41:43 -0000

Lou Berger  wrote:
> I think this goes to if this, or any, draft is a proposed standard or=

> not. In other words, if it specifies any behavior that for which
> interoperability between independent implementations is the objective=
.=A0
> My general view is that in a Proposed Standard RFC, if it impacts
> interoperability, the text should be normative and an RFC should use
> 2119 language to identify such normative text.=A0 I accept that this =
is
> not strictly required by IETF process, but it has become the norm for=
 PS
> track RFCs produced today=A0 -- and I see no reason to not follow IET=
F norm.

As Rob wrote, we will add 2119 language to the draft, since that's
seems to be WG consensus.


/martin


> =

> In the context of this draft , as I read it, at least section 5.1 and=

> some portions of 4.
> =

> Lou
> =

> On 9/27/2017 12:28 PM, Robert Wilton wrote:
> >
> > The authors discussed this, and we will close this issue
> > (https://github.com/netmod-wg/datastore-dt/issues/14 - title: Does =
the
> > NMDA architecture need to use RFC 2119 language?) by adding RFC 211=
9
> > text to the document, which will probably be best illustrated with =
an
> > updated draft revision.
> >
> > For the record, the majority of the authors had the view that RFC 2=
119
> > language does not particularly aid readability in this architecture=

> > document.
> >
> > Thanks,
> > Rob
> >
> >
> > On 16/09/2017 10:56, Andy Bierman wrote:
> >>
> >>
> >> On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder
> >>  >> > wrote:
> >>
> >>     On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
> >>     > Hi,
> >>     >
> >>     > I strongly agree with Tom that the current draft is an updat=
e
> >>     to RFC 7950.
> >>     > I also strongly disagree with the decision to omit RFC 2119 =
in
> >>     a standards
> >>     > track document. IMO RFC 2119 terms need to be used in normat=
ive
> >>     text,
> >>     > especially when dealing with XPath and YANG compiler behavio=
r.
> >>     >
> >>
> >>     RFC 8174:
> >>
> >>     =A0 =A0o=A0 These words can be used as defined here, but using=
 them is not
> >>     =A0 =A0 =A0 required.=A0 Specifically, normative text does not=
 require
> >>     the use
> >>     =A0 =A0 =A0 of these key words.=A0 They are used for clarity a=
nd consistency
> >>     =A0 =A0 =A0 when that is what's wanted, but a lot of normative=
 text
> >>     does not
> >>     =A0 =A0 =A0 use them and is still normative.
> >>
> >>
> >> So what?
> >> Existing YANG specifications use RFC 2119 terms.
> >> This draft uses those terms, just with lower-case.
> >> Either way, the new YANG rules seem half-baked and not ready
> >> for standardization.
> >>
> >> =A0
> >>
> >>     /js
> >>
> >>
> >> Andy
> >> =A0
> >>
> >>     --
> >>     Juergen Schoenwaelder=A0 =A0 =A0 =A0 =A0 =A0Jacobs University =
Bremen gGmbH
> >>     Phone: +49 421 200 3587=A0 =A0 =A0 =A0 =A0Campus Ring 1 | 2875=
9 Bremen |
> >>     Germany
> >>     Fax:=A0 =A0+49 421 200 3103=A0 =A0 =A0 =A0 =A0 >>     >
> >>
> >>
> >
> >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> =

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


From nobody Wed Sep 27 11:24:46 2017
Return-Path: 
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 455BD1342E8 for ; Wed, 27 Sep 2017 11:24:44 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Va4ahUx6NitC for ; Wed, 27 Sep 2017 11:24:42 -0700 (PDT)
Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) (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 833F313334E for ; Wed, 27 Sep 2017 11:24:42 -0700 (PDT)
Received: from cmgw4 (unknown [10.0.90.85]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id 425831AB261 for ; Wed, 27 Sep 2017 12:24:41 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id EiQd1w00V2SSUrH01iQg4W; Wed, 27 Sep 2017 12:24:41 -0600
X-Authority-Analysis: v=2.2 cv=OZLoNlbY c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=2JCJgTwv5E4A:10 a=48vgC7mUAAAA:8 a=lKxbPOWRVp9zlBxft1cA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: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=l1rWJSDz2M6H/qXbZoJPWRSa+kFvW5T+uns7ANQnh6I=; b=JPDWea1j06491MT+WL9KNtJ6bV rapu67fCSaoL36guEVnmjQZMEM7G+PRajrf8X7sOpnrWxacPqD3wScll2wLS9einDWc93QaNKg51A TzlqcIzCB8j1DGGz4uKsvGRbd;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:35694 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dxH0f-00473w-3n; Wed, 27 Sep 2017 12:24:37 -0600
To: Martin Bjorklund , netmod@ietf.org
References: <150650952130.25003.1792240611663747386@ietfa.amsl.com> <20170927.125558.606437323539289377.mbj@tail-f.com>
From: Lou Berger 
Message-ID: 
Date: Wed, 27 Sep 2017 14:24:34 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170927.125558.606437323539289377.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dxH0f-00473w-3n
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:35694
X-Source-Auth: lberger@labn.net
X-Email-Count: 4
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-schema-mount-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Sep 2017 18:24:44 -0000

Hi Martin,

See below

On 9/27/2017 6:55 AM, Martin Bjorklund wrote:
> Hi,
>
> This version fixes the XPath context for parent-reference.
>
>
> However, there is one more thing to discuss, which is the term "mount
> point".  
>
> The current text says:
>
>    - mount point: container or list node whose definition contains
>      the "mount-point" extension statement. The argument of the
>      "mount-point" statement defines the name of the mount point.
>
>
> So if we have:
>     
>   container top {
>     container root {
>       yangmnt:mount-point ni;
>     }
>   }
>     
> There is one mount point, the node /top/root, with the name "ni".
in the NI draft [1] we solve this by keeping the names the same:

        container vrf-root {
          description
            "Container for mount point.";
          yangmnt:mount-point "vrf-root" {
            description
              "Root for L3VPN type models. This will typically
               not be an inline type mount point.";
          }
        }

[1] https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model-04
> Pretty confusing...   Does anyone have any comments around this?
>
When the NE authors discussed this, we (a) discussed it's not a
significant impediment or issue worth discussing, and (b) one author
noted that the flexibility may even be useful down the road.

Thanks,
Lou
(As contributor)
 
>
> /martin
>
>
>
>
>
> internet-drafts@ietf.org wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Network Modeling WG of the IETF.
>>
>>         Title           : YANG Schema Mount
>>         Authors         : Martin Bjorklund
>>                           Ladislav Lhotka
>> 	Filename        : draft-ietf-netmod-schema-mount-07.txt
>> 	Pages           : 27
>> 	Date            : 2017-09-27
>>
>> Abstract:
>>    This document defines a mechanism to combine YANG modules into the
>>    schema defined in other YANG modules.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-07
>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-schema-mount-07
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-schema-mount-07
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>


From nobody Wed Sep 27 12:59:35 2017
Return-Path: 
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 C7825134F13 for ; Wed, 27 Sep 2017 12:59:33 -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 R7bcuRH_bLf3 for ; Wed, 27 Sep 2017 12:59:32 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E6F7D135002 for ; Wed, 27 Sep 2017 12:59:25 -0700 (PDT)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id CA3091AE0397; Wed, 27 Sep 2017 21:59:24 +0200 (CEST)
Date: Wed, 27 Sep 2017 21:59:24 +0200 (CEST)
Message-Id: <20170927.215924.550019105119501379.mbj@tail-f.com>
To: lberger@labn.net
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <150650952130.25003.1792240611663747386@ietfa.amsl.com> <20170927.125558.606437323539289377.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=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-schema-mount-07.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Sep 2017 19:59:34 -0000

Lou Berger  wrote:
> Hi Martin,
> =

> See below
> =

> On 9/27/2017 6:55 AM, Martin Bjorklund wrote:
> > Hi,
> >
> > This version fixes the XPath context for parent-reference.
> >
> >
> > However, there is one more thing to discuss, which is the term "mou=
nt
> > point".  =

> >
> > The current text says:
> >
> >    - mount point: container or list node whose definition contains
> >      the "mount-point" extension statement. The argument of the
> >      "mount-point" statement defines the name of the mount point.
> >
> >
> > So if we have:
> >     =

> >   container top {
> >     container root {
> >       yangmnt:mount-point ni;
> >     }
> >   }
> >     =

> > There is one mount point, the node /top/root, with the name "ni".
> in the NI draft [1] we solve this by keeping the names the same:
> =

> =A0=A0=A0=A0=A0=A0=A0 container vrf-root {
> =A0=A0=A0=A0=A0=A0=A0=A0=A0 description
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "Container for mount point.";
> =A0=A0=A0=A0=A0=A0=A0=A0=A0 yangmnt:mount-point "vrf-root" {
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 description
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "Root for L3VPN type models. =
This will typically
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 not be an inline type moun=
t point.";
> =A0=A0=A0=A0=A0=A0=A0=A0=A0 }
> =A0=A0=A0=A0=A0=A0=A0 }
> =

> [1] https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model-04
> > Pretty confusing...   Does anyone have any comments around this?
> >
> When the NE authors discussed this, we (a) discussed it's not a
> significant impediment or issue worth discussing, and (b) one author
> noted that the flexibility may even be useful down the road.

Yes, I don't want to change any functionality, but perhaps change the
terminology to make it less confusion.

Maybe change the extension to:

  extension mount-point {
    argument id; // instead of 'name'
    ...
  }

So the container "vrf-root" would be a mount point, with id "ni".



/martin




> =

> Thanks,
> Lou
> (As contributor)
> =A0
> >
> > /martin
> >
> >
> >
> >
> >
> > internet-drafts@ietf.org wrote:
> >> A New Internet-Draft is available from the on-line Internet-Drafts=
 directories.
> >> This draft is a work item of the Network Modeling WG of the IETF.
> >>
> >>         Title           : YANG Schema Mount
> >>         Authors         : Martin Bjorklund
> >>                           Ladislav Lhotka
> >> 	Filename        : draft-ietf-netmod-schema-mount-07.txt
> >> 	Pages           : 27
> >> 	Date            : 2017-09-27
> >>
> >> Abstract:
> >>    This document defines a mechanism to combine YANG modules into =
the
> >>    schema defined in other YANG modules.
> >>
> >>
> >> The IETF datatracker status page for this draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/
> >>
> >> There are also htmlized versions available at:
> >> https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-07
> >> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-schema-mou=
nt-07
> >>
> >> A diff from the previous version is available at:
> >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-schema-mount=
-07
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of =
submission
> >> until the htmlized version and diff are available at tools.ietf.or=
g.
> >>
> >> Internet-Drafts are also available by anonymous FTP at:
> >> ftp://ftp.ietf.org/internet-drafts/
> >>
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >>
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> =


From nobody Wed Sep 27 13:42:07 2017
Return-Path: 
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 E896F135081; Wed, 27 Sep 2017 13:42:04 -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 DRoN3nR5Ttq4; Wed, 27 Sep 2017 13:42:02 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 230F4135052; Wed, 27 Sep 2017 13:42:00 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id B3005F17; Wed, 27 Sep 2017 22:41:58 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id e3AKntpAbO83; Wed, 27 Sep 2017 22:41:56 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 27 Sep 2017 22:41:58 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6EF0D200F6; Wed, 27 Sep 2017 22:41:58 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SFr3Lk6dkBcs; Wed, 27 Sep 2017 22:41:57 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AD4C1200F4; Wed, 27 Sep 2017 22:41:57 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 53A494118C0C; Wed, 27 Sep 2017 22:41:56 +0200 (CEST)
Date: Wed, 27 Sep 2017 22:41:56 +0200
From: Juergen Schoenwaelder 
To: Lou Berger 
Cc: Robert Wilton , netmod WG , NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org
Message-ID: <20170927204156.zcm4rpzkcz66avhi@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Lou Berger , Robert Wilton , netmod WG , NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <022001d32e14$8d5d4540$4001a8c0@gateway.2wire.net> <20170915123443.kvagu7dut7oaqoo2@elstar.local>  <20170916072403.xp37556z6g7b42gr@elstar.local>  <07b5a5df-794e-2ba8-6cad-abfcfadfc4cc@cisco.com> <4d345c3b-a28b-a0e0-27cb-306ff4618d0e@labn.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <4d345c3b-a28b-a0e0-27cb-306ff4618d0e@labn.net>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] RFC 2119 language [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Sep 2017 20:42:05 -0000

Lou,

text is normative without RFC 2119 language. There clearly is no such
'norm' unless people try to make it a new norm and I am strictly
opposed to that. If the reason to add RFC 2119 language is to comply
to a new norm being created, I have to object. If you want such a norm
to be created, write an I-D and run it through the process.

/js

PS: Sorry co-authors I promised to be silent but somehow I can't let
    this reasoning go without seriously questioning it.

On Wed, Sep 27, 2017 at 01:20:13PM -0400, Lou Berger wrote:
> I think this goes to if this, or any, draft is a proposed standard or
> not. In other words, if it specifies any behavior that for which
> interoperability between independent implementations is the objective. 
> My general view is that in a Proposed Standard RFC, if it impacts
> interoperability, the text should be normative and an RFC should use
> 2119 language to identify such normative text.  I accept that this is
> not strictly required by IETF process, but it has become the norm for PS
> track RFCs produced today  -- and I see no reason to not follow IETF norm.
> 
> In the context of this draft , as I read it, at least section 5.1 and
> some portions of 4.
> 
> Lou
> 
> On 9/27/2017 12:28 PM, Robert Wilton wrote:
> >
> > The authors discussed this, and we will close this issue
> > (https://github.com/netmod-wg/datastore-dt/issues/14 - title: Does the
> > NMDA architecture need to use RFC 2119 language?) by adding RFC 2119
> > text to the document, which will probably be best illustrated with an
> > updated draft revision.
> >
> > For the record, the majority of the authors had the view that RFC 2119
> > language does not particularly aid readability in this architecture
> > document.
> >
> > Thanks,
> > Rob
> >
> >
> > On 16/09/2017 10:56, Andy Bierman wrote:
> >>
> >>
> >> On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder
> >>  >> > wrote:
> >>
> >>     On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
> >>     > Hi,
> >>     >
> >>     > I strongly agree with Tom that the current draft is an update
> >>     to RFC 7950.
> >>     > I also strongly disagree with the decision to omit RFC 2119 in
> >>     a standards
> >>     > track document. IMO RFC 2119 terms need to be used in normative
> >>     text,
> >>     > especially when dealing with XPath and YANG compiler behavior.
> >>     >
> >>
> >>     RFC 8174:
> >>
> >>        o  These words can be used as defined here, but using them is not
> >>           required.  Specifically, normative text does not require
> >>     the use
> >>           of these key words.  They are used for clarity and consistency
> >>           when that is what's wanted, but a lot of normative text
> >>     does not
> >>           use them and is still normative.
> >>
> >>
> >> So what?
> >> Existing YANG specifications use RFC 2119 terms.
> >> This draft uses those terms, just with lower-case.
> >> Either way, the new YANG rules seem half-baked and not ready
> >> for standardization.
> >>
> >>  
> >>
> >>     /js
> >>
> >>
> >> Andy
> >>  
> >>
> >>     --
> >>     Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >>     Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen |
> >>     Germany
> >>     Fax:   +49 421 200 3103          >>     >
> >>
> >>
> >
> >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 

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


From nobody Wed Sep 27 13:56:20 2017
Return-Path: 
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 25D9A1350C6 for ; Wed, 27 Sep 2017 13:56:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQ6wuTZd1CBL for ; Wed, 27 Sep 2017 13:56:17 -0700 (PDT)
Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::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 004411350C8 for ; Wed, 27 Sep 2017 13:56:12 -0700 (PDT)
Received: by mail-wr0-x230.google.com with SMTP id z39so18630525wrb.8 for ; Wed, 27 Sep 2017 13:56:12 -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; bh=OWZR5qjtjFNTIo45xrab3n/DBv9CETBGZH2At/Q4Wz8=; b=YmV7o79IkZMQIPvyeQjfMs3fD0a59JChImKSx3RkHi//SnejOOuG8ckztx2GIM22Ax eStWeRMmDXkKPRGW2nc89hLc4BJJs9xX+5E0q0gKF2rIA7TAoQmVpWDLcz5K6dj125Xe E+pz3cqbUkK9ljVR5vKTlJWXNxdZcQrH0UXJ8oDGmeeX4SJ1gQqdA66hac6cb8t7n3iN 1SxE0l8i5vLeOI50ng8+0bttuMkxPb8VEN79KMKhXutZdRWH7Zba/nxCL3mLMhiJAPrK iJz/+l98VgHHaz+ohWzjij3AL9qHQRAYV2/lYTroXV2jYCiVTOmP+SXJCBcGHNrDaj9h Bl7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=OWZR5qjtjFNTIo45xrab3n/DBv9CETBGZH2At/Q4Wz8=; b=R0For9qF5aGTksqQX7/xNLmAKkQ+kyXgW1ASSAjIn92wzWS5am8CeRNXZfCf9TycMA lbwx7wScOd74ZzM78CKqy9ZzDJVtodkjwonxNYJvP91Cea1GdgDpNDJybq+B1tNndamU 3ErDMX0+lP10xp1Y7uyBUeraRoHqSNDv021TfxwAT8sffhUwh5mbUUMzqlUAME9wUvN/ CQxzHpRDwMNYZN1NeLLqhtu2UJMIXxsvtwfJd3YF8IBgr/sNhv1l67pJruPt2d6Q30b2 EdwM0uJT+2UcQgZYBV92EJ/ZpWRV2c4HPl4xCvCoaTEvemHAOBeW+VieDxP+/evsSG3m XgoQ==
X-Gm-Message-State: AHPjjUh1uqXAIhamp/Qe8SnWVm8d9k4OrrVMQpb+bE7WvvOy88M/pPcs 39YgmdRWP2bXqpZgR+d+tSTuXXfpmG27fFBcLXqQOg==
X-Google-Smtp-Source: AOwi7QD4TrLSgaf+Be8S8YaC2OYDVIQHZulzm6QTgDN+NVfDFoyKkG5Og+MEMiMyt2YQthvKoJYMSMczM0oPNqqP+zk=
X-Received: by 10.46.77.157 with SMTP id c29mr1139021ljd.14.1506545771433; Wed, 27 Sep 2017 13:56:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.18.41 with HTTP; Wed, 27 Sep 2017 13:56:10 -0700 (PDT)
In-Reply-To: <20170927204156.zcm4rpzkcz66avhi@elstar.local>
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <022001d32e14$8d5d4540$4001a8c0@gateway.2wire.net> <20170915123443.kvagu7dut7oaqoo2@elstar.local>  <20170916072403.xp37556z6g7b42gr@elstar.local>  <07b5a5df-794e-2ba8-6cad-abfcfadfc4cc@cisco.com> <4d345c3b-a28b-a0e0-27cb-306ff4618d0e@labn.net> <20170927204156.zcm4rpzkcz66avhi@elstar.local>
From: Andy Bierman 
Date: Wed, 27 Sep 2017 13:56:10 -0700
Message-ID: 
To: Juergen Schoenwaelder , Lou Berger ,  Robert Wilton , netmod WG ,  NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c1aba688b61ce055a320550"
Archived-At: 
Subject: Re: [netmod] RFC 2119 language [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Sep 2017 20:56:19 -0000

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

Hi,



On Wed, Sep 27, 2017 at 1:41 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> Lou,
>
> text is normative without RFC 2119 language. There clearly is no such
> 'norm' unless people try to make it a new norm and I am strictly
> opposed to that. If the reason to add RFC 2119 language is to comply
> to a new norm being created, I have to object. If you want such a norm
> to be created, write an I-D and run it through the process.
>
>

It is quite common for Standards Track documents to use RFC 2119 terms.
The only new norm being set here is that the RD draft mixes architecture and
normative YANG/protocol behavior together.

If this was an Informational RFC that just discussed architecture,
then I would agree the RFC 2119 terms are not needed.



> /js
>
>
Andy



> PS: Sorry co-authors I promised to be silent but somehow I can't let
>     this reasoning go without seriously questioning it.
>
> On Wed, Sep 27, 2017 at 01:20:13PM -0400, Lou Berger wrote:
> > I think this goes to if this, or any, draft is a proposed standard or
> > not. In other words, if it specifies any behavior that for which
> > interoperability between independent implementations is the objective.
> > My general view is that in a Proposed Standard RFC, if it impacts
> > interoperability, the text should be normative and an RFC should use
> > 2119 language to identify such normative text.  I accept that this is
> > not strictly required by IETF process, but it has become the norm for PS
> > track RFCs produced today  -- and I see no reason to not follow IETF
> norm.
> >
> > In the context of this draft , as I read it, at least section 5.1 and
> > some portions of 4.
> >
> > Lou
> >
> > On 9/27/2017 12:28 PM, Robert Wilton wrote:
> > >
> > > The authors discussed this, and we will close this issue
> > > (https://github.com/netmod-wg/datastore-dt/issues/14 - title: Does the
> > > NMDA architecture need to use RFC 2119 language?) by adding RFC 2119
> > > text to the document, which will probably be best illustrated with an
> > > updated draft revision.
> > >
> > > For the record, the majority of the authors had the view that RFC 2119
> > > language does not particularly aid readability in this architecture
> > > document.
> > >
> > > Thanks,
> > > Rob
> > >
> > >
> > > On 16/09/2017 10:56, Andy Bierman wrote:
> > >>
> > >>
> > >> On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder
> > >>  > >> > wrote:
> > >>
> > >>     On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
> > >>     > Hi,
> > >>     >
> > >>     > I strongly agree with Tom that the current draft is an update
> > >>     to RFC 7950.
> > >>     > I also strongly disagree with the decision to omit RFC 2119 in
> > >>     a standards
> > >>     > track document. IMO RFC 2119 terms need to be used in normative
> > >>     text,
> > >>     > especially when dealing with XPath and YANG compiler behavior.
> > >>     >
> > >>
> > >>     RFC 8174:
> > >>
> > >>        o  These words can be used as defined here, but using them is
> not
> > >>           required.  Specifically, normative text does not require
> > >>     the use
> > >>           of these key words.  They are used for clarity and
> consistency
> > >>           when that is what's wanted, but a lot of normative text
> > >>     does not
> > >>           use them and is still normative.
> > >>
> > >>
> > >> So what?
> > >> Existing YANG specifications use RFC 2119 terms.
> > >> This draft uses those terms, just with lower-case.
> > >> Either way, the new YANG rules seem half-baked and not ready
> > >> for standardization.
> > >>
> > >>
> > >>
> > >>     /js
> > >>
> > >>
> > >> Andy
> > >>
> > >>
> > >>     --
> > >>     Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > >>     Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen |
> > >>     Germany
> > >>     Fax:   +49 421 200 3103          > >>     >
> > >>
> > >>
> > >
> > >
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
>
> --
> 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
>

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


Hi,



=

On Wed, Sep 27, 2017 at 1:41 PM, Juergen Schoenw=
aelder <j.schoenwaelder@jacobs-university.de> wrote:
Lou,



text is normative without RFC 2119 language. There clearly is no such

'norm' unless people try to make it a new norm and I am strictly
opposed to that. If the reason to add RFC 2119 language is to comply

to a new norm being created, I have to object. If you want such a norm

to be created, write an I-D and run it through the process.




It is quite common for =
Standards Track documents to use RFC 2119 terms.
The only new nor=
m being set here is that the RD draft mixes architecture and
norm=
ative YANG/protocol behavior together.

If this was=
 an Informational RFC that just discussed architecture,
then I wo=
uld agree the RFC 2119 terms are not needed.

=C2=
=A0

/js



Andy

=C2=A0

PS: Sorry co-authors I promised to be silent but somehow I can't let
=C2=A0 =C2=A0 this reasoning go without seriously questioning it.



On Wed, Sep 27, 2017 at 01:20:13PM -0400, Lou Berger wrote:

> I think this goes to if this, or any, draft is a proposed standard or<=
br>
> not. In other words, if it specifies any behavior that for which

> interoperability between independent implementations is the objective.=
=C2=A0

> My general view is that in a Proposed Standard RFC, if it impacts

> interoperability, the text should be normative and an RFC should use
> 2119 language to identify such normative text.=C2=A0 I accept that thi=
s is

> not strictly required by IETF process, but it has become the norm for =
PS

> track RFCs produced today=C2=A0 -- and I see no reason to not follow I=
ETF norm.

>

> In the context of this draft , as I read it, at least section 5.1 and<=
br>
> some portions of 4.

>

> Lou

>

> On 9/27/2017 12:28 PM, Robert Wilton wrote:

> >

> > The authors discussed this, and we will close this issue

> > (https://github.com/netmod-wg/data=
store-dt/issues/14 - title: Does the

> > NMDA architecture need to use RFC 2119 language?) by adding RFC 2=
119

> > text to the document, which will probably be best illustrated wit=
h an

> > updated draft revision.

> >

> > For the record, the majority of the authors had the view that RFC=
 2119

> > language does not particularly aid readability in this architectu=
re

> > document.

> >

> > Thanks,

> > Rob

> >

> >

> > On 16/09/2017 10:56, Andy Bierman wrote:

> >>

> >>

> >> On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder

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

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

> >>

> >>=C2=A0 =C2=A0 =C2=A0On Fri, Sep 15, 2017 at 02:07:58PM -0700, =
Andy Bierman wrote:

> >>=C2=A0 =C2=A0 =C2=A0> Hi,

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

> >>=C2=A0 =C2=A0 =C2=A0> I strongly agree with Tom that the cu=
rrent draft is an update

> >>=C2=A0 =C2=A0 =C2=A0to RFC 7950.

> >>=C2=A0 =C2=A0 =C2=A0> I also strongly disagree with the dec=
ision to omit RFC 2119 in

> >>=C2=A0 =C2=A0 =C2=A0a standards

> >>=C2=A0 =C2=A0 =C2=A0> track document. IMO RFC 2119 terms ne=
ed to be used in normative

> >>=C2=A0 =C2=A0 =C2=A0text,

> >>=C2=A0 =C2=A0 =C2=A0> especially when dealing with XPath an=
d YANG compiler behavior.

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

> >>

> >>=C2=A0 =C2=A0 =C2=A0RFC 8174:

> >>

> >>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0o=C2=A0 These words can be us=
ed as defined here, but using them is not

> >>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 required.=C2=A0 Speci=
fically, normative text does not require

> >>=C2=A0 =C2=A0 =C2=A0the use

> >>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 of these key words.=
=C2=A0 They are used for clarity and consistency

> >>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 when that is what'=
;s wanted, but a lot of normative text

> >>=C2=A0 =C2=A0 =C2=A0does not

> >>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 use them and is still=
 normative.

> >>

> >>

> >> So what?

> >> Existing YANG specifications use RFC 2119 terms.

> >> This draft uses those terms, just with lower-case.

> >> Either way, the new YANG rules seem half-baked and not ready<=
br>
> >> for standardization.

> >>

> >> =C2=A0

> >>

> >>=C2=A0 =C2=A0 =C2=A0/js

> >>

> >>

> >> Andy

> >> =C2=A0

> >>

> >>=C2=A0 =C2=A0 =C2=A0--

> >>=C2=A0 =C2=A0 =C2=A0Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0Jacobs University Bremen gGmbH

> >>=C2=A0 =C2=A0 =C2=A0Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Bremen |

> >>=C2=A0 =C2=A0 =C2=A0Germany

> >>=C2=A0 =C2=A0 =C2=A0Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/=


> >>=C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>>

> >>

> >>

> >

> >

> >

> > _______________________________________________

> > netmod mailing list

> > netmod@ietf.org

> > https://www.ietf.org/mailman/listinfo/net=
mod

>



--

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28=
759 Bremen | Germany

Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>



_______________________________________________

netmod mailing list

netmod@ietf.org

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




--94eb2c1aba688b61ce055a320550--


From nobody Wed Sep 27 14:03:33 2017
Return-Path: 
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 2A2811350CC; Wed, 27 Sep 2017 14:03:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 j04YTqKyZi5b; Wed, 27 Sep 2017 14:03:29 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7745A1350D0; Wed, 27 Sep 2017 14:03:29 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 41723E90; Wed, 27 Sep 2017 23:03:28 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id SJtrPkj5evfX; Wed, 27 Sep 2017 23:03:26 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 27 Sep 2017 23:03:28 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 00BD3200FA; Wed, 27 Sep 2017 23:03:28 +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 wu98qhaCkjTO; Wed, 27 Sep 2017 23:03:27 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9C028200F6; Wed, 27 Sep 2017 23:03:27 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 906E14118DBE; Wed, 27 Sep 2017 23:03:27 +0200 (CEST)
Date: Wed, 27 Sep 2017 23:03:27 +0200
From: Juergen Schoenwaelder 
To: Andy Bierman 
Cc: Lou Berger , Robert Wilton , netmod WG , NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org
Message-ID: <20170927210327.k4mxf5re4w5ngf5p@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Andy Bierman , Lou Berger , Robert Wilton , netmod WG , NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <022001d32e14$8d5d4540$4001a8c0@gateway.2wire.net> <20170915123443.kvagu7dut7oaqoo2@elstar.local>  <20170916072403.xp37556z6g7b42gr@elstar.local>  <07b5a5df-794e-2ba8-6cad-abfcfadfc4cc@cisco.com> <4d345c3b-a28b-a0e0-27cb-306ff4618d0e@labn.net> <20170927204156.zcm4rpzkcz66avhi@elstar.local> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] RFC 2119 language [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Sep 2017 21:03:31 -0000

On Wed, Sep 27, 2017 at 01:56:10PM -0700, Andy Bierman wrote:
> Hi,
> 
> 
> 
> On Wed, Sep 27, 2017 at 1:41 PM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> 
> > Lou,
> >
> > text is normative without RFC 2119 language. There clearly is no such
> > 'norm' unless people try to make it a new norm and I am strictly
> > opposed to that. If the reason to add RFC 2119 language is to comply
> > to a new norm being created, I have to object. If you want such a norm
> > to be created, write an I-D and run it through the process.
> 
> It is quite common for Standards Track documents to use RFC 2119 terms.
> The only new norm being set here is that the RD draft mixes architecture and
> normative YANG/protocol behavior together.

The idea that normative text requires RFC 2119 words is wrong.
 
> If this was an Informational RFC that just discussed architecture,
> then I would agree the RFC 2119 terms are not needed.

If the only reason to add RFC 2119 language is to comply to an
unwritten norm, then I am questioning adding RFC 2119 language. There
needs to be a bit more logic and reasoning for each decision whether a
must or MUST or a should or a SHOULD is appropriate.

/js

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


From nobody Wed Sep 27 14:05:05 2017
Return-Path: 
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 60D361350CC for ; Wed, 27 Sep 2017 14:05: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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjydYdBXz1tZ for ; Wed, 27 Sep 2017 14:04:59 -0700 (PDT)
Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::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 692011350CE for ; Wed, 27 Sep 2017 14:04:59 -0700 (PDT)
Received: by mail-wr0-x232.google.com with SMTP id b21so1019660wrg.7 for ; Wed, 27 Sep 2017 14:04: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; bh=YTFlBZ+Vp0dekCbY+A9tZzLqGzBUpx7yX1jEJWNyiFc=; b=dkP5jXxezZigEw4dnyqqyNDRgRZ1mCocJtMq/oCWiviesOapLkwJ/KXvCq/chnY5I1 8kAMlAYf4/xjMHU5Gy8St3E/IrpLFfYIrTgUHpXfgwM/dWGvcMTOfBYJ5hNLdRlwU8aY 5FJIUM8KqCHLePxO9Tr/ea+/fbFOyZJCY5Z6Hiq3iuWWVNaGUvyt8t4XckJVdmwpGGOS de4gfIV6EYBWxZ36vW6FNpc30l3BcoV9LrqgL6Vbz063/GCQwuTplZ4+sysCKDT7OOD0 tcOPAIhn/DiwCzfIIkJhKZT3jzo+sozU/1W0pzYSnDEK/ysWyusYb+/04GoJET1TBS5/ UR3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=YTFlBZ+Vp0dekCbY+A9tZzLqGzBUpx7yX1jEJWNyiFc=; b=rO0SJEMllQ6ix5I5P9LoDydv1tt9TonbiQOrgQM0roqz+Ai1TQ4RNE9ny/nZSKdLdZ CeXTITyDX+nXii0gCzgb8n7jf1WeVwFx12zOlI4p00H2/ckcnFt+uWHtyyBE6/XDyRLW y1bIK9H7Z2ojocZpZTAOf33Ld1C18UfUQnbXQjHHtVpy+l08NukS4R0dOrqbY6/0hq4V bHthV0MdWrlGkB47hLwCvUPrej5YSA1Tz3Hg8Ri4a3MMCC7GgbFyNh4nsf04Ki7cLC2F bk/uS1YGAl1FRNz61yGPMVkzY22Vytoy9q/H+plJse0b1vmJP3VvxbavyHAX8RAMofW0 jaSw==
X-Gm-Message-State: AMCzsaXLWKiNHrWyYp7aFQK8xXANuOByBYuH5POqzuxuLtHQusMAucCz lrl1jwvJA+3GL2fOAdPnxkEX2jw0FehM7fZMnW4njw==
X-Google-Smtp-Source: AOwi7QAWfW2t8jxo3gmise+8T8pj3dRjOpFPEANodjnhuONlcxasjuHKFlF+MgapC0XF1ws+VZGcI249B+JLUIeeU8Q=
X-Received: by 10.25.235.220 with SMTP id f89mr920296lfk.194.1506546297877; Wed, 27 Sep 2017 14:04:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.18.41 with HTTP; Wed, 27 Sep 2017 14:04:57 -0700 (PDT)
In-Reply-To: <20170927204156.zcm4rpzkcz66avhi@elstar.local>
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <022001d32e14$8d5d4540$4001a8c0@gateway.2wire.net> <20170915123443.kvagu7dut7oaqoo2@elstar.local>  <20170916072403.xp37556z6g7b42gr@elstar.local>  <07b5a5df-794e-2ba8-6cad-abfcfadfc4cc@cisco.com> <4d345c3b-a28b-a0e0-27cb-306ff4618d0e@labn.net> <20170927204156.zcm4rpzkcz66avhi@elstar.local>
From: Andy Bierman 
Date: Wed, 27 Sep 2017 14:04:57 -0700
Message-ID: 
To: Juergen Schoenwaelder , Lou Berger ,  Robert Wilton , netmod WG ,  NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org
Content-Type: multipart/alternative; boundary="001a113c1796ec4d30055a322467"
Archived-At: 
Subject: Re: [netmod] RFC 2119 language [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Sep 2017 21:05:03 -0000

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

Hi,

I do not want to generate more process so I will drop the issue,
but the fact that this draft updates RFC 7950 instead of RFC 6244
indicates the problems with it are way beyond using capital letters for a
few words.


Andy


On Wed, Sep 27, 2017 at 1:41 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> Lou,
>
> text is normative without RFC 2119 language. There clearly is no such
> 'norm' unless people try to make it a new norm and I am strictly
> opposed to that. If the reason to add RFC 2119 language is to comply
> to a new norm being created, I have to object. If you want such a norm
> to be created, write an I-D and run it through the process.
>
> /js
>
> PS: Sorry co-authors I promised to be silent but somehow I can't let
>     this reasoning go without seriously questioning it.
>
> On Wed, Sep 27, 2017 at 01:20:13PM -0400, Lou Berger wrote:
> > I think this goes to if this, or any, draft is a proposed standard or
> > not. In other words, if it specifies any behavior that for which
> > interoperability between independent implementations is the objective.
> > My general view is that in a Proposed Standard RFC, if it impacts
> > interoperability, the text should be normative and an RFC should use
> > 2119 language to identify such normative text.  I accept that this is
> > not strictly required by IETF process, but it has become the norm for PS
> > track RFCs produced today  -- and I see no reason to not follow IETF
> norm.
> >
> > In the context of this draft , as I read it, at least section 5.1 and
> > some portions of 4.
> >
> > Lou
> >
> > On 9/27/2017 12:28 PM, Robert Wilton wrote:
> > >
> > > The authors discussed this, and we will close this issue
> > > (https://github.com/netmod-wg/datastore-dt/issues/14 - title: Does the
> > > NMDA architecture need to use RFC 2119 language?) by adding RFC 2119
> > > text to the document, which will probably be best illustrated with an
> > > updated draft revision.
> > >
> > > For the record, the majority of the authors had the view that RFC 2119
> > > language does not particularly aid readability in this architecture
> > > document.
> > >
> > > Thanks,
> > > Rob
> > >
> > >
> > > On 16/09/2017 10:56, Andy Bierman wrote:
> > >>
> > >>
> > >> On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder
> > >>  > >> > wrote:
> > >>
> > >>     On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
> > >>     > Hi,
> > >>     >
> > >>     > I strongly agree with Tom that the current draft is an update
> > >>     to RFC 7950.
> > >>     > I also strongly disagree with the decision to omit RFC 2119 in
> > >>     a standards
> > >>     > track document. IMO RFC 2119 terms need to be used in normative
> > >>     text,
> > >>     > especially when dealing with XPath and YANG compiler behavior.
> > >>     >
> > >>
> > >>     RFC 8174:
> > >>
> > >>        o  These words can be used as defined here, but using them is
> not
> > >>           required.  Specifically, normative text does not require
> > >>     the use
> > >>           of these key words.  They are used for clarity and
> consistency
> > >>           when that is what's wanted, but a lot of normative text
> > >>     does not
> > >>           use them and is still normative.
> > >>
> > >>
> > >> So what?
> > >> Existing YANG specifications use RFC 2119 terms.
> > >> This draft uses those terms, just with lower-case.
> > >> Either way, the new YANG rules seem half-baked and not ready
> > >> for standardization.
> > >>
> > >>
> > >>
> > >>     /js
> > >>
> > >>
> > >> Andy
> > >>
> > >>
> > >>     --
> > >>     Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > >>     Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen |
> > >>     Germany
> > >>     Fax:   +49 421 200 3103          > >>     >
> > >>
> > >>
> > >
> > >
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
>
> --
> 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
>

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


Hi,

I do not want to generate more proc=
ess so I will drop the issue,
but the fact that this draft update=
s RFC 7950 instead of RFC 6244
indicates the problems with it are=
 way beyond using capital letters for a few words.


Andy

<=
br>
On Wed, Sep 27, 2017 at 1:41 PM, Juergen Scho=
enwaelder <j.schoenwaelder@jacobs-university.de>=
 wrote:
Lou,



text is normative without RFC 2119 language. There clearly is no such

'norm' unless people try to make it a new norm and I am strictly
opposed to that. If the reason to add RFC 2119 language is to comply

to a new norm being created, I have to object. If you want such a norm

to be created, write an I-D and run it through the process.



/js



PS: Sorry co-authors I promised to be silent but somehow I can't let
=C2=A0 =C2=A0 this reasoning go without seriously questioning it.



On Wed, Sep 27, 2017 at 01:20:13PM -0400, Lou Berger wrote:

> I think this goes to if this, or any, draft is a proposed standard or<=
br>
> not. In other words, if it specifies any behavior that for which

> interoperability between independent implementations is the objective.=
=C2=A0

> My general view is that in a Proposed Standard RFC, if it impacts

> interoperability, the text should be normative and an RFC should use
> 2119 language to identify such normative text.=C2=A0 I accept that thi=
s is

> not strictly required by IETF process, but it has become the norm for =
PS

> track RFCs produced today=C2=A0 -- and I see no reason to not follow I=
ETF norm.

>

> In the context of this draft , as I read it, at least section 5.1 and<=
br>
> some portions of 4.

>

> Lou

>

> On 9/27/2017 12:28 PM, Robert Wilton wrote:

> >

> > The authors discussed this, and we will close this issue

> > (https://github.com/netmod-wg/data=
store-dt/issues/14 - title: Does the

> > NMDA architecture need to use RFC 2119 language?) by adding RFC 2=
119

> > text to the document, which will probably be best illustrated wit=
h an

> > updated draft revision.

> >

> > For the record, the majority of the authors had the view that RFC=
 2119

> > language does not particularly aid readability in this architectu=
re

> > document.

> >

> > Thanks,

> > Rob

> >

> >

> > On 16/09/2017 10:56, Andy Bierman wrote:

> >>

> >>

> >> On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder

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

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

> >>

> >>=C2=A0 =C2=A0 =C2=A0On Fri, Sep 15, 2017 at 02:07:58PM -0700, =
Andy Bierman wrote:

> >>=C2=A0 =C2=A0 =C2=A0> Hi,

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

> >>=C2=A0 =C2=A0 =C2=A0> I strongly agree with Tom that the cu=
rrent draft is an update

> >>=C2=A0 =C2=A0 =C2=A0to RFC 7950.

> >>=C2=A0 =C2=A0 =C2=A0> I also strongly disagree with the dec=
ision to omit RFC 2119 in

> >>=C2=A0 =C2=A0 =C2=A0a standards

> >>=C2=A0 =C2=A0 =C2=A0> track document. IMO RFC 2119 terms ne=
ed to be used in normative

> >>=C2=A0 =C2=A0 =C2=A0text,

> >>=C2=A0 =C2=A0 =C2=A0> especially when dealing with XPath an=
d YANG compiler behavior.

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

> >>

> >>=C2=A0 =C2=A0 =C2=A0RFC 8174:

> >>

> >>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0o=C2=A0 These words can be us=
ed as defined here, but using them is not

> >>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 required.=C2=A0 Speci=
fically, normative text does not require

> >>=C2=A0 =C2=A0 =C2=A0the use

> >>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 of these key words.=
=C2=A0 They are used for clarity and consistency

> >>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 when that is what'=
;s wanted, but a lot of normative text

> >>=C2=A0 =C2=A0 =C2=A0does not

> >>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 use them and is still=
 normative.

> >>

> >>

> >> So what?

> >> Existing YANG specifications use RFC 2119 terms.

> >> This draft uses those terms, just with lower-case.

> >> Either way, the new YANG rules seem half-baked and not ready<=
br>
> >> for standardization.

> >>

> >> =C2=A0

> >>

> >>=C2=A0 =C2=A0 =C2=A0/js

> >>

> >>

> >> Andy

> >> =C2=A0

> >>

> >>=C2=A0 =C2=A0 =C2=A0--

> >>=C2=A0 =C2=A0 =C2=A0Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0Jacobs University Bremen gGmbH

> >>=C2=A0 =C2=A0 =C2=A0Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Bremen |

> >>=C2=A0 =C2=A0 =C2=A0Germany

> >>=C2=A0 =C2=A0 =C2=A0Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/=


> >>=C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>>

> >>

> >>

> >

> >

> >

> > _______________________________________________

> > netmod mailing list

> > netmod@ietf.org

> > https://www.ietf.org/mailman/listinfo/net=
mod

>



--

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28=
759 Bremen | Germany

Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>



_______________________________________________

netmod mailing list

netmod@ietf.org

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




--001a113c1796ec4d30055a322467--


From nobody Wed Sep 27 14:50:44 2017
Return-Path: 
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 E55CF134478 for ; Wed, 27 Sep 2017 14:50:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level: 
X-Spam-Status: No, score=-4.701 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=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUYT4KJX4HeJ for ; Wed, 27 Sep 2017 14:50:38 -0700 (PDT)
Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (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 13300134471 for ; Wed, 27 Sep 2017 14:50:38 -0700 (PDT)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id 6B0541E091A for ; Wed, 27 Sep 2017 15:50:37 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id ElqZ1w00J2SSUrH01lqcH1; Wed, 27 Sep 2017 15:50:37 -0600
X-Authority-Analysis: v=2.2 cv=K4VSJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=2JCJgTwv5E4A:10 a=NEAV23lmAAAA:8 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=CZY7irZrpuLruoW8yB8A:9 a=QEXdDO2ut3YA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=9ZYBcOd_X9kS2t7VFny2:22 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: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=DPynj/Fhu1jS7HkLjNZBldveIKp77s4QB3unXxx5dlE=; b=xRm+Om71YkH0LNLHZcslFEb/b3 DhCgAO5xjKmx/QmUWnTsgP/JhBHwNakVmQ3bydBSL3yH4DBYvXPTc0c7hKy9741wCDiMPNSiLDs/9 FW5PN2t6h+YVWOiNJRKjkxWiC;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:37584 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dxKDx-000NGj-49; Wed, 27 Sep 2017 15:50:33 -0600
To: Robert Wilton , netmod WG , NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <022001d32e14$8d5d4540$4001a8c0@gateway.2wire.net> <20170915123443.kvagu7dut7oaqoo2@elstar.local>  <20170916072403.xp37556z6g7b42gr@elstar.local>  <07b5a5df-794e-2ba8-6cad-abfcfadfc4cc@cisco.com> <4d345c3b-a28b-a0e0-27cb-306ff4618d0e@labn.net> <20170927204156.zcm4rpzkcz66avhi@elstar.local>
From: Lou Berger 
Message-ID: <5768f361-7e60-8110-162a-a73f5857e3a5@labn.net>
Date: Wed, 27 Sep 2017 17:50:30 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170927204156.zcm4rpzkcz66avhi@elstar.local>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dxKDx-000NGj-49
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:37584
X-Source-Auth: lberger@labn.net
X-Email-Count: 4
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] RFC 2119 language [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Sep 2017 21:50:42 -0000

Juergen,

I guess our experiences at the IETF differ.  Certainly RFCs I authored
prior to 2219 (being published) were loose in their use of
capitalization and, frankly, sometimes open to interpretation as to what
was normative and what was informative.  But soon very soon after, most
of us switched over to citing RFC2119 and using its language to
distinguish between the two -- and I think this truly helped readers and
implementers know what they had to do to conform with and what they
didn't to ensure interoperable implementations. I'm really not sure  how
20 years later, the use of RFC2119 to identify normative language can be
considered anything but the norm, let alone a proposed 'new norm'.

FWIW of the 3198 RFCs with a 'standards'  category published after
RFC2119, 1995 reference RFC2119.  In the last 5 years the numbers are
961 and 892 respectively.

Lou


On 9/27/2017 4:41 PM, Juergen Schoenwaelder wrote:
> Lou,
>
> text is normative without RFC 2119 language. There clearly is no such
> 'norm' unless people try to make it a new norm and I am strictly
> opposed to that. If the reason to add RFC 2119 language is to comply
> to a new norm being created, I have to object. If you want such a norm
> to be created, write an I-D and run it through the process.
>
> /js
>
> PS: Sorry co-authors I promised to be silent but somehow I can't let
>     this reasoning go without seriously questioning it.
>
> On Wed, Sep 27, 2017 at 01:20:13PM -0400, Lou Berger wrote:
>> I think this goes to if this, or any, draft is a proposed standard or
>> not. In other words, if it specifies any behavior that for which
>> interoperability between independent implementations is the objective. 
>> My general view is that in a Proposed Standard RFC, if it impacts
>> interoperability, the text should be normative and an RFC should use
>> 2119 language to identify such normative text.  I accept that this is
>> not strictly required by IETF process, but it has become the norm for PS
>> track RFCs produced today  -- and I see no reason to not follow IETF norm.
>>
>> In the context of this draft , as I read it, at least section 5.1 and
>> some portions of 4.
>>
>> Lou
>>
>> On 9/27/2017 12:28 PM, Robert Wilton wrote:
>>> The authors discussed this, and we will close this issue
>>> (https://github.com/netmod-wg/datastore-dt/issues/14 - title: Does the
>>> NMDA architecture need to use RFC 2119 language?) by adding RFC 2119
>>> text to the document, which will probably be best illustrated with an
>>> updated draft revision.
>>>
>>> For the record, the majority of the authors had the view that RFC 2119
>>> language does not particularly aid readability in this architecture
>>> document.
>>>
>>> Thanks,
>>> Rob
>>>
>>>
>>> On 16/09/2017 10:56, Andy Bierman wrote:
>>>>
>>>> On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder
>>>> >>> > wrote:
>>>>
>>>>     On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
>>>>     > Hi,
>>>>     >
>>>>     > I strongly agree with Tom that the current draft is an update
>>>>     to RFC 7950.
>>>>     > I also strongly disagree with the decision to omit RFC 2119 in
>>>>     a standards
>>>>     > track document. IMO RFC 2119 terms need to be used in normative
>>>>     text,
>>>>     > especially when dealing with XPath and YANG compiler behavior.
>>>>     >
>>>>
>>>>     RFC 8174:
>>>>
>>>>        o  These words can be used as defined here, but using them is not
>>>>           required.  Specifically, normative text does not require
>>>>     the use
>>>>           of these key words.  They are used for clarity and consistency
>>>>           when that is what's wanted, but a lot of normative text
>>>>     does not
>>>>           use them and is still normative.
>>>>
>>>>
>>>> So what?
>>>> Existing YANG specifications use RFC 2119 terms.
>>>> This draft uses those terms, just with lower-case.
>>>> Either way, the new YANG rules seem half-baked and not ready
>>>> for standardization.
>>>>
>>>>  
>>>>
>>>>     /js
>>>>
>>>>
>>>> Andy
>>>>  
>>>>
>>>>     --
>>>>     Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>>>     Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen |
>>>>     Germany
>>>>     Fax:   +49 421 200 3103         >>>     >
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Sep 27 15:03:30 2017
Return-Path: 
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 8DCE6134F4D; Wed, 27 Sep 2017 15:03:29 -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 q1rptSmJgx-e; Wed, 27 Sep 2017 15:03:27 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EBFB13446A; Wed, 27 Sep 2017 15:03:27 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 03A10F17; Thu, 28 Sep 2017 00:03:26 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id Pd3oYnaQgDiT; Thu, 28 Sep 2017 00:03:24 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 28 Sep 2017 00:03:25 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A9C8E200F6; Thu, 28 Sep 2017 00:03:25 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id OuJNhsx5Y6Kr; Thu, 28 Sep 2017 00:03:24 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D4A2D200F4; Thu, 28 Sep 2017 00:03:24 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id A32BE41191C1; Thu, 28 Sep 2017 00:03:24 +0200 (CEST)
Date: Thu, 28 Sep 2017 00:03:24 +0200
From: Juergen Schoenwaelder 
To: Lou Berger 
Cc: Robert Wilton , netmod WG , NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org
Message-ID: <20170927220324.7r2qj5aqlyb76fsp@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Lou Berger , Robert Wilton , netmod WG , NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <022001d32e14$8d5d4540$4001a8c0@gateway.2wire.net> <20170915123443.kvagu7dut7oaqoo2@elstar.local>  <20170916072403.xp37556z6g7b42gr@elstar.local>  <07b5a5df-794e-2ba8-6cad-abfcfadfc4cc@cisco.com> <4d345c3b-a28b-a0e0-27cb-306ff4618d0e@labn.net> <20170927204156.zcm4rpzkcz66avhi@elstar.local> <5768f361-7e60-8110-162a-a73f5857e3a5@labn.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <5768f361-7e60-8110-162a-a73f5857e3a5@labn.net>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] RFC 2119 language [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Sep 2017 22:03:30 -0000

Lou,

I do not have statistics, just some RFC text:

- RFC 8174 section 2 first bullet in the === NEW === text says "These
  words can be used as defined here, but using them is not required.
  Specifically, normative text does not require the use of these key
  words.  They are used for clarity and consistency when that is
  what's wanted, but a lot of normative text does not use them and is
  still normative."

- I can also point to RFC 2119 section 6 which says "they MUST only be
  used where it is actually required for interoperation or to limit
  behavior which has potential for causing harm (e.g., limiting
  retransmisssions)".

/js

On Wed, Sep 27, 2017 at 05:50:30PM -0400, Lou Berger wrote:
> Juergen,
> 
> I guess our experiences at the IETF differ.  Certainly RFCs I authored
> prior to 2219 (being published) were loose in their use of
> capitalization and, frankly, sometimes open to interpretation as to what
> was normative and what was informative.  But soon very soon after, most
> of us switched over to citing RFC2119 and using its language to
> distinguish between the two -- and I think this truly helped readers and
> implementers know what they had to do to conform with and what they
> didn't to ensure interoperable implementations. I'm really not sure  how
> 20 years later, the use of RFC2119 to identify normative language can be
> considered anything but the norm, let alone a proposed 'new norm'.
> 
> FWIW of the 3198 RFCs with a 'standards'  category published after
> RFC2119, 1995 reference RFC2119.  In the last 5 years the numbers are
> 961 and 892 respectively.
> 
> Lou
> 
> 
> On 9/27/2017 4:41 PM, Juergen Schoenwaelder wrote:
> > Lou,
> >
> > text is normative without RFC 2119 language. There clearly is no such
> > 'norm' unless people try to make it a new norm and I am strictly
> > opposed to that. If the reason to add RFC 2119 language is to comply
> > to a new norm being created, I have to object. If you want such a norm
> > to be created, write an I-D and run it through the process.
> >
> > /js
> >
> > PS: Sorry co-authors I promised to be silent but somehow I can't let
> >     this reasoning go without seriously questioning it.
> >
> > On Wed, Sep 27, 2017 at 01:20:13PM -0400, Lou Berger wrote:
> >> I think this goes to if this, or any, draft is a proposed standard or
> >> not. In other words, if it specifies any behavior that for which
> >> interoperability between independent implementations is the objective. 
> >> My general view is that in a Proposed Standard RFC, if it impacts
> >> interoperability, the text should be normative and an RFC should use
> >> 2119 language to identify such normative text.  I accept that this is
> >> not strictly required by IETF process, but it has become the norm for PS
> >> track RFCs produced today  -- and I see no reason to not follow IETF norm.
> >>
> >> In the context of this draft , as I read it, at least section 5.1 and
> >> some portions of 4.
> >>
> >> Lou
> >>
> >> On 9/27/2017 12:28 PM, Robert Wilton wrote:
> >>> The authors discussed this, and we will close this issue
> >>> (https://github.com/netmod-wg/datastore-dt/issues/14 - title: Does the
> >>> NMDA architecture need to use RFC 2119 language?) by adding RFC 2119
> >>> text to the document, which will probably be best illustrated with an
> >>> updated draft revision.
> >>>
> >>> For the record, the majority of the authors had the view that RFC 2119
> >>> language does not particularly aid readability in this architecture
> >>> document.
> >>>
> >>> Thanks,
> >>> Rob
> >>>
> >>>
> >>> On 16/09/2017 10:56, Andy Bierman wrote:
> >>>>
> >>>> On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder
> >>>>  >>>> > wrote:
> >>>>
> >>>>     On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
> >>>>     > Hi,
> >>>>     >
> >>>>     > I strongly agree with Tom that the current draft is an update
> >>>>     to RFC 7950.
> >>>>     > I also strongly disagree with the decision to omit RFC 2119 in
> >>>>     a standards
> >>>>     > track document. IMO RFC 2119 terms need to be used in normative
> >>>>     text,
> >>>>     > especially when dealing with XPath and YANG compiler behavior.
> >>>>     >
> >>>>
> >>>>     RFC 8174:
> >>>>
> >>>>        o  These words can be used as defined here, but using them is not
> >>>>           required.  Specifically, normative text does not require
> >>>>     the use
> >>>>           of these key words.  They are used for clarity and consistency
> >>>>           when that is what's wanted, but a lot of normative text
> >>>>     does not
> >>>>           use them and is still normative.
> >>>>
> >>>>
> >>>> So what?
> >>>> Existing YANG specifications use RFC 2119 terms.
> >>>> This draft uses those terms, just with lower-case.
> >>>> Either way, the new YANG rules seem half-baked and not ready
> >>>> for standardization.
> >>>>
> >>>>  
> >>>>
> >>>>     /js
> >>>>
> >>>>
> >>>> Andy
> >>>>  
> >>>>
> >>>>     --
> >>>>     Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >>>>     Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen |
> >>>>     Germany
> >>>>     Fax:   +49 421 200 3103          >>>>     >
> >>>>
> >>>>
> >>>
> >>>
> >>> _______________________________________________
> >>> netmod mailing list
> >>> netmod@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/netmod
> 

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


From nobody Wed Sep 27 15:08:19 2017
Return-Path: 
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 09BB3135148 for ; Wed, 27 Sep 2017 15:08:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level: 
X-Spam-Status: No, score=-4.701 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=-2.8, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slxbsD_N_HhQ for ; Wed, 27 Sep 2017 15:08:16 -0700 (PDT)
Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (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 50B76135145 for ; Wed, 27 Sep 2017 15:08:16 -0700 (PDT)
Received: from cmgw3 (unknown [10.0.90.84]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id F36B1140537 for ; Wed, 27 Sep 2017 16:08:13 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with  id Em8A1w00E2SSUrH01m8DwW; Wed, 27 Sep 2017 16:08:13 -0600
X-Authority-Analysis: v=2.2 cv=K/VSJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=2JCJgTwv5E4A:10 a=NEAV23lmAAAA:8 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=fEaDuy-KPGFyYXx-NrIA:9 a=QEXdDO2ut3YA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=9ZYBcOd_X9kS2t7VFny2:22 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: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=V9bpgCwbz/BxepyslhfZ1ZxMR0b8sOqsMtNKVCeCJiQ=; b=ChXjBHprPHsHyIrOYrmUk0rTp3 qJLM6m5w4pBLMbWe1MNUIttB/WmzYy1fg3wZtDVJ/vV2Y8ERqDrNLszQITpOMwqeXueJMxsK4xO4e tFyv/mLUz2RbrkMfHQAOmMSQF;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:37722 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dxKV0-000QOM-3J; Wed, 27 Sep 2017 16:08:10 -0600
To: Robert Wilton , netmod WG , NetMod WG Chairs , draft-ietf-netmod-revised-datastores@ietf.org
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <022001d32e14$8d5d4540$4001a8c0@gateway.2wire.net> <20170915123443.kvagu7dut7oaqoo2@elstar.local>  <20170916072403.xp37556z6g7b42gr@elstar.local>  <07b5a5df-794e-2ba8-6cad-abfcfadfc4cc@cisco.com> <4d345c3b-a28b-a0e0-27cb-306ff4618d0e@labn.net> <20170927204156.zcm4rpzkcz66avhi@elstar.local> <5768f361-7e60-8110-162a-a73f5857e3a5@labn.net> <20170927220324.7r2qj5aqlyb76fsp@elstar.local>
From: Lou Berger 
Message-ID: <255f3bdc-b44c-ee9f-2470-d173f5bffdc1@labn.net>
Date: Wed, 27 Sep 2017 18:08:07 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170927220324.7r2qj5aqlyb76fsp@elstar.local>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dxKV0-000QOM-3J
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:37722
X-Source-Auth: lberger@labn.net
X-Email-Count: 2
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] RFC 2119 language [was Re: WG Last Call: draft-ietf-netmod-revised-datastores-04 updates]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Sep 2017 22:08:18 -0000

Juergen,

Thanks for the "interesting" discussion.  I really do appreciate the authors adding the 2119 language even though they are unconvinced of it's value.  

Lou

On 9/27/2017 6:03 PM, Juergen Schoenwaelder wrote:
> Lou,
>
> I do not have statistics, just some RFC text:
>
> - RFC 8174 section 2 first bullet in the === NEW === text says "These
>   words can be used as defined here, but using them is not required.
>   Specifically, normative text does not require the use of these key
>   words.  They are used for clarity and consistency when that is
>   what's wanted, but a lot of normative text does not use them and is
>   still normative."
>
> - I can also point to RFC 2119 section 6 which says "they MUST only be
>   used where it is actually required for interoperation or to limit
>   behavior which has potential for causing harm (e.g., limiting
>   retransmisssions)".
>
> /js
>
> On Wed, Sep 27, 2017 at 05:50:30PM -0400, Lou Berger wrote:
>> Juergen,
>>
>> I guess our experiences at the IETF differ.  Certainly RFCs I authored
>> prior to 2219 (being published) were loose in their use of
>> capitalization and, frankly, sometimes open to interpretation as to what
>> was normative and what was informative.  But soon very soon after, most
>> of us switched over to citing RFC2119 and using its language to
>> distinguish between the two -- and I think this truly helped readers and
>> implementers know what they had to do to conform with and what they
>> didn't to ensure interoperable implementations. I'm really not sure  how
>> 20 years later, the use of RFC2119 to identify normative language can be
>> considered anything but the norm, let alone a proposed 'new norm'.
>>
>> FWIW of the 3198 RFCs with a 'standards'  category published after
>> RFC2119, 1995 reference RFC2119.  In the last 5 years the numbers are
>> 961 and 892 respectively.
>>
>> Lou
>>
>>
>> On 9/27/2017 4:41 PM, Juergen Schoenwaelder wrote:
>>> Lou,
>>>
>>> text is normative without RFC 2119 language. There clearly is no such
>>> 'norm' unless people try to make it a new norm and I am strictly
>>> opposed to that. If the reason to add RFC 2119 language is to comply
>>> to a new norm being created, I have to object. If you want such a norm
>>> to be created, write an I-D and run it through the process.
>>>
>>> /js
>>>
>>> PS: Sorry co-authors I promised to be silent but somehow I can't let
>>>     this reasoning go without seriously questioning it.
>>>
>>> On Wed, Sep 27, 2017 at 01:20:13PM -0400, Lou Berger wrote:
>>>> I think this goes to if this, or any, draft is a proposed standard or
>>>> not. In other words, if it specifies any behavior that for which
>>>> interoperability between independent implementations is the objective. 
>>>> My general view is that in a Proposed Standard RFC, if it impacts
>>>> interoperability, the text should be normative and an RFC should use
>>>> 2119 language to identify such normative text.  I accept that this is
>>>> not strictly required by IETF process, but it has become the norm for PS
>>>> track RFCs produced today  -- and I see no reason to not follow IETF norm.
>>>>
>>>> In the context of this draft , as I read it, at least section 5.1 and
>>>> some portions of 4.
>>>>
>>>> Lou
>>>>
>>>> On 9/27/2017 12:28 PM, Robert Wilton wrote:
>>>>> The authors discussed this, and we will close this issue
>>>>> (https://github.com/netmod-wg/datastore-dt/issues/14 - title: Does the
>>>>> NMDA architecture need to use RFC 2119 language?) by adding RFC 2119
>>>>> text to the document, which will probably be best illustrated with an
>>>>> updated draft revision.
>>>>>
>>>>> For the record, the majority of the authors had the view that RFC 2119
>>>>> language does not particularly aid readability in this architecture
>>>>> document.
>>>>>
>>>>> Thanks,
>>>>> Rob
>>>>>
>>>>>
>>>>> On 16/09/2017 10:56, Andy Bierman wrote:
>>>>>> On Sat, Sep 16, 2017 at 12:24 AM, Juergen Schoenwaelder
>>>>>> >>>>> > wrote:
>>>>>>
>>>>>>     On Fri, Sep 15, 2017 at 02:07:58PM -0700, Andy Bierman wrote:
>>>>>>     > Hi,
>>>>>>     >
>>>>>>     > I strongly agree with Tom that the current draft is an update
>>>>>>     to RFC 7950.
>>>>>>     > I also strongly disagree with the decision to omit RFC 2119 in
>>>>>>     a standards
>>>>>>     > track document. IMO RFC 2119 terms need to be used in normative
>>>>>>     text,
>>>>>>     > especially when dealing with XPath and YANG compiler behavior.
>>>>>>     >
>>>>>>
>>>>>>     RFC 8174:
>>>>>>
>>>>>>        o  These words can be used as defined here, but using them is not
>>>>>>           required.  Specifically, normative text does not require
>>>>>>     the use
>>>>>>           of these key words.  They are used for clarity and consistency
>>>>>>           when that is what's wanted, but a lot of normative text
>>>>>>     does not
>>>>>>           use them and is still normative.
>>>>>>
>>>>>>
>>>>>> So what?
>>>>>> Existing YANG specifications use RFC 2119 terms.
>>>>>> This draft uses those terms, just with lower-case.
>>>>>> Either way, the new YANG rules seem half-baked and not ready
>>>>>> for standardization.
>>>>>>
>>>>>>  
>>>>>>
>>>>>>     /js
>>>>>>
>>>>>>
>>>>>> Andy
>>>>>>  
>>>>>>
>>>>>>     --
>>>>>>     Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>>>>>     Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen |
>>>>>>     Germany
>>>>>>     Fax:   +49 421 200 3103         >>>>>     >
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> netmod@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netmod


From nobody Thu Sep 28 02:37:28 2017
Return-Path: 
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 1D7EC1345C3; Thu, 28 Sep 2017 02:37:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 UigrDI7aAiBy; Thu, 28 Sep 2017 02:37:23 -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 8E605132351; Thu, 28 Sep 2017 02:37:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17045; q=dns/txt; s=iport; t=1506591442; x=1507801042; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=d/4FfvqDNv8kgRUtu2foncBoeiBQWkajUEC9MeNvJdg=; b=Y+jcNq6IKH8kajqVyeYkviksKQYVoOBR6pGQ9XO0jL5P8XooLwqLh2YB L8w6PbYvY4oYTPMZS7mk5FNpgGcL/B+ZnT2fAw1kxcUzdyGRLzoSv4WbN rQP8w8Fk5yZdjzPMf16wmfyLrsvHPpKhwb0PZDBb6/+sxyUPQ2gYQyEF6 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAABdwsxZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhS4ng3iKH3SQYHmVMg6CBAqFOwKFJRgBAgEBAQEBAQFrKIUYAQE?= =?us-ascii?q?BAQMjDwEFOhMECQIQAgMBAgICERIDAgJGAw4GAQwGAgEBF4oWiU+dZoIniwEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEdgQ6CHYNTgWorgkg1hD8tAgJTglSCYAWhJZR?= =?us-ascii?q?fghOJSCSHB4oPg2SHWYE5HzhCTDIhCB0Vh2c/NoYNAQEFIAeCFQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.42,449,1500940800"; d="scan'208";a="657883119"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Sep 2017 09:37:20 +0000
Received: from [10.63.23.161] (dhcp-ensft1-uk-vla370-10-63-23-161.cisco.com [10.63.23.161]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v8S9bJAn017511; Thu, 28 Sep 2017 09:37:20 GMT
To: netmod@ietf.org, draft-ietf-netmod-revised-datastores@ietf.org, "j.schoenwaelder@jacobs-university.de" 
References: <20170918.200734.1805388289423863575.mbj@tail-f.com>  <99b9a2c6-4bb4-121f-0cba-925cefe09712@cisco.com> <20170919.115559.1080249872764998055.mbj@tail-f.com>  <5481ac35-c789-0796-36f6-8a02a5ebef8c@cisco.com> <00c501d333c0$9d210280$4001a8c0@gateway.2wire.net> 
From: Robert Wilton 
Message-ID: <3274ba62-d60d-976b-9a22-879089abbbf2@cisco.com>
Date: Thu, 28 Sep 2017 10:37:19 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod]  vs 
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Sep 2017 09:37:26 -0000

Hi,

After comment from the other authors, an updated proposed description 
for  is as follows:

OLD:

4.3.  The Running Configuration Datastore ()

    The running configuration datastore () holds the complete
    current configuration on the device.  It may include inactive
    configuration or template-mechanism-oriented configuration that
    require further expansion.

    If a device does not have a distinct  and non-volatile is
    available, the device will typically use that non-volatile storage to
    allow  to persist across reboots.

NEW:

4.1.3.  The Running Configuration Datastore ()

    The running configuration datastore () is aconfiguration
    datastore that holds the complete current configuration
    on the device.  It may include configuration that requires further
    transformation before it can be applied, e.g., inactive
    configuration, or template-mechanism-oriented configuration that
    needs further expansion.  However,  MUST always be a 'valid
    configuration data tree' as defined in Section 8.1 of [RFC7950].

     MUST be supported if the device can be configured via
    conventional configuration datastores.

    If a device does not have a distinct  and non-volatile is
    available, the device will typically use that non-volatile storage to
    allow  to persist across reboots.


Given that the definition of  and  are being updated, 
I think that the definitions should similarly be updated.  Hence I propose:



OLD:
    o  running configuration datastore: A configuration datastore holding
       the current configuration of the device.  It may include inactive
       configuration or template-mechanism-oriented configuration that
       require further expansion.  This datastore is commonly referred to
       as "".

NEW (based on the new description of running above):
    o  running configuration datastore: A configuration datastore holding
       the current configuration of the device. It may include
       configuration that requires furthertransformations before it can
       be applied. This datastore is commonly referred to
       as "".



OLD:

   o  intended configuration: Configuration that is intended to be used
       by the device.  For example, intended configuration excludes any
       inactive configuration and it would include configuration produced
       through the expansion of templates.


NEW (based on the proposed updated description of intended):

   o  intended configuration: Configuration that is intended to be used
      by the device. It represents the configuration after all
      configuration transformations to  have been performed and
      is the configuration that the system attempts to apply.



It may also be helpful if we define "configuration transformation", or 
would that be better captured in the introduction text?

A possible definition could be along the lines of:

  configuration transformation: The addition, modification or removal of
  configuration between the  and  datastores.
  Examples of configuration transformations include the removal of
  inactive configuration and the configuration produced through the
  expansion of templates.

If I don't hear anything back, I'll take that as a tacit approval of 
these proposed changes.

Thanks,
Rob


On 22/09/2017 18:12, Robert Wilton wrote:
> Hi Tom,
>
>
> On 22/09/2017 17:34, t.petch wrote:
>> Robert
>>
>> I wonder if this says the opposite of what is intended
>>
>> -  holds the complete  current configuration on the device.
> I agree.
>
>>
>> - This could include inactiveconfiguration
> I agree.
>
>>
>>   -  must always be a  'valid configuration data tree' as
>> defined in Section 8.1 of [RFC7950].
> I agree.
>
>>
>> Ergo, inactiveconfiguration must form part of a valid configuration
>> tree.
>
> Ergo, inactive configuration can form part of a valid configuration
> tree.
>
>>
>> I thought the idea was that inactiveconfiguration was logically removed
>> before validation but this seems to state the opposite..
> I don't think that this is necessarily true.  One choice is inactive 
> configuration is removed before validation, but this isn't quite what 
> I'm proposing.  I'm proposing that the act of validation itself is 
> refined (via an tbd inactive configuration draft) such that it ignores 
> configuration nodes marked as inactive.
>
> Thanks,
> Rob
>
>>
>> Tom Petch
>>
>> ----- Original Message -----
>> From: "Robert Wilton" 
>> Sent: Friday, September 22, 2017 10:03 AM
>>
>>> Hi,
>>>
>>> Regarding whether  is always valid, the proposed modification
>>> to the draft is to add the following text to section 4.3 that
>> describes
>>> :
>>>
>>> OLD:
>>>
>>> 4.3. The Running Configuration Datastore ()
>>>
>>>    The running configuration datastore () holds the complete
>>>    current configuration on the device. It may include inactive
>>>    configuration or template-mechanism-oriented configuration that
>>>    require further expansion.
>>>
>>>    If a device does not have a distinct  and non-volatile is
>>>    available, the device will typically use that non-volatile storage
>> to
>>>    allow  to persist across reboots.
>>>
>>> NEW:
>>>
>>> 4.3. The Running Configuration Datastore ()
>>>
>>>    The running configuration datastore () holds the complete
>>>    current configuration on the device. This could, for example,
>> include
>>>    inactiveconfiguration or template-mechanism-oriented configuration
>>>    thatrequires further expansion.However,  must always be a
>>>    'valid configuration data tree' as defined in Section 8.1 of
>> [RFC7950].
>>>    If a device does not have a distinct  and non-volatile is
>>>    available, the device will typically use that non-volatile storage
>> to
>>>    allow  to persist across reboots.
>>>
>>> END
>>>
>>>
>>> Then the intention is that if inactive or a templating solution is
>>> standardized then those drafts would update the validation rules in
>> RFC
>>> 7950 such that  is still valid. E.g. an inactive config draft
>>> would probably indicate that validation excludes all configuration
>> nodes
>>> that are marked as inactive.
>>>
>>> Does anyone have any comments?
>>>
>>> Do we also need to state that  must always be a 'valid
>>> configuration data tree'?
>>>
>>> Thanks,
>>> Rob
>>>
>>>
>>> On 19/09/2017 16:22, Robert Wilton wrote:
>>>>
>>>> On 19/09/2017 10:55, Martin Bjorklund wrote:
>>>>> Robert Wilton  wrote:
>>>>>> On 18/09/2017 19:25, Andy Bierman wrote:
>>>>>>> On Mon, Sep 18, 2017 at 11:07 AM, Martin Bjorklund
>> >>>>>> > wrote:
>>>>>>>
>>>>>>> Juergen Schoenwaelder >>>>>> > wrote:
>>>>>>>> On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert Wilton wrote:
>>>>>>>>>> No. I do not agree that the MUST in RFC 7950 can be
>>>>>>> removed.
>>>>>>>>>> I do not agree the architecture should update YANG at all.
>>>>>>>>> OK.
>>>>>>>> I am with Andy here.  has always had the
>>>>>>> requirement to be
>>>>>>>> valid and we are not supposed to change that. Mechanisms for
>>>>>>> inactive
>>>>>>>> configuration or templating must be designed to be backwards
>>>>>>> compatible
>>>>>>>> I think.
>>>>>>> Ok. If we keep the requirement that  in itself must be
>>>>>>> valid, it just restricts the usefulness/expressiveness of
>>>>>>> inactive and
>>>>>>> template mechanisms, but it might be ok.
>>>>>>>
>>>>>>> I think that even w/o this requirement, the observable
>>>>>>> behavior for a
>>>>>>> client can be backwards compatible. For example, suppose we
>>>>>>> have an
>>>>>>> inactive access control rule that refers to a non-existing
>>>>>>> interface in
>>>>>>> . If a client that doesn't know anything about
>>>>>>> inactive asks
>>>>>>> for the contents of , our implementation removes the
>>>>>>> inactive
>>>>>>> nodes from the reply to the client. Only a client that
>>>>>>> opts-in to
>>>>>>> inactive will receive a reply with things that looks invalid
>>>>>>> if you
>>>>>>> don't take the inactive annotation into account.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> There are many ways that validation can fail because inactive
>> nodes
>>>>>>> are present,
>>>>>>> and considered part of the validation.
>>>>>>>
>>>>>>> e,g, min-elements, max-elements, mandatory, unique.
>>>>>>>
>>>>>>> I think we all agree that validation on the enabled nodes is
>> supposed
>>>>>>> to continue to work.
>>>>> Yes.
>>>>>
>>>>>>> Here is an attempt at a backwards-compatible solution:
>>>>>>>
>>>>>>> 1) current  and  responses only include enabled
>>>>>>> nodes.
>>>>>>> 2) old-style  operations do not alter inactive nodes
>>>>>>> 3) NMDA clients use , not  or . These
>>>>>>> responses
>>>>>>> include enabled and disabled nodes, so validation does not apply
>>>>>>> for 
>>>>>>> 4) new style  (i.e.  parameter used) can
>> alter
>>>>>>> any type of data node
>>>>>> //I think that inactive should always be an optional extension.
>> Not
>>>>>> everything needs the additional complexity.
>>>>>>
>>>>>> Hence rather than tying this function to specific NETCONF
>> operations,
>>>>>> I would suggest that there should be an extra parameter (like for
>>>>>> with-defaults) to allow a client to indicate to the server that a
>> get
>>>>>> or edit request is using the "with-inactive" extension.
>>>>>> 1) The server should also have a capability (or perhaps a leaf
>> defined
>>>>>> in YANG library) to indicate that it supports inactive
>> configuration.
>>>>>> 2) If a client doesn't use the extra "with-inactive" parameter
>> during
>>>>>> a get request then only active nodes are returned.
>>>>>> 3) If a client doesn't use the extra "with-inactive" parameter
>> during
>>>>>> an edit-data request then the request cannot include an extra
>> inactive
>>>>>> meta-data. The request is processed in a way that is equivalent to
>> an
>>>>>> existing NETCONF implementation, but it may unknowingly remove
>> some
>>>>>> inactive configuration (e.g. via a replace or remove operation on
>> an
>>>>>> inactive node). Operations like create, delete, none, replace
>> should
>>>>>> all treat an inactive target node the same way as in the node
>> doesn't
>>>>>> exist (e.g. delete on an inactive node would return a
>> "data-missing"
>>>>>> error), this ensures that the behaviour that an unaware client
>>>>>> observes is the same as the existing behaviour that it would
>> expect
>>>>>> from a regular 6241 compliant NETCONF implementation.
>>>>>> 4) It a client makes a get request including the "with-inactive"
>>>>>> parameter then they also get the inactive nodes as well, marked
>> with a
>>>>>> meta-data annotation.
>>>>>> 5) If a client makes an edit request including the "with-inactive"
>>>>>> parameter, then the inactive meta-data annotation can be used to
>> label
>>>>>> inactive nodes. Inactive nodes are regarded as regular data nodes
>> for
>>>>>> create/delete/replace/none operation error checking.
>>>>>>
>>>>>> I think that this approach is similar (perhaps even the same) as
>>>>>> Martin described.
>>>>> This is indeed how our implementation works (except I think we
>> don't
>>>>> do 5; if the client sends an "inactive" attribute it doesn't have
>> to
>>>>> also send with-inactive).
>>>>>
>>>>>>> Note that the YANG MUST rule still applies, because validation is
>> only
>>>>>>> done on enabled nodes.
>>>>>>> It is only the response message representations that cannot be
>>>>>>> validated, not the contents
>>>>>>> of  on a server.
>>>>> So the question is how we can make sure that the text in the NMDA
>>>>> draft covers this yet-to-be-defined feature w/o having to define it
>>>>> now? We thought that the current text was sufficient, but do we
>> have
>>>>> to make any changes to it?
>>>> 1) Do we also need to illustrate a similar proof of concept
>> templating
>>>> implementation to show that templating could work whilst keeping
>>>> running valid? I would prefer that this is just deferred to
>> whichever
>>>> draft defines templating.
>>>>
>>>> 2) I think that we need to reach a decision as to whether the NMDA
>>>> architecture needs to explicitly state that  is always
>> valid,
>>>> or if that can be left to the existing statement in 7950. My
>> thinking
>>>> is that if the conclusion is that  must always be valid,
>> then
>>>> it would be helpful to explicitly state it the descriptions of both
>>>>  and  in the NMDA architecture.
>>>>
>>>> 3) I think that it would be useful to further refine my previous
>>>> proposed text for intended, particularly rewriting the text on
>>>> validation. This should hopefully also address Balazs' concern about
>>>> default values be included in validation.
>>>>
>>>> 
>>>>
>>>> 4.4. The Intended Configuration Datastore ()
>>>>
>>>> The intended configuration datastore () is a read-only
>>>> configuration datastore. It is tightly coupled to . When
>>>> data is written to , the data that is to be validated is
>>>> also conceptually written to . Validation is performed on
>>>> the contents of .
>>>>
>>>> For simple implementations,  and  are identical.
>>>>
>>>>  does not persist across reboots; its relationship with
>>>>  makes that unnecessary.
>>>>
>>>> Currently there are no standard mechanisms defined that affect
>>>>  so that it would have different contents than ,
>>>> but this architecture allows for such mechanisms to be defined.
>>>>
>>>> One example of such a mechanism is support for marking nodes as
>>>> inactive in . Inactive nodes are not copied to ,
>>>> and are thus not taken into account when validating the
>>>> configuration.
>>>>
>>>> Another example is support for templates. Templates are expanded
>>>> when copied into , and the expanded result is validated.
>>>>
>>>> 
>>>> 
>>>>
>>>> 4.1.4. The Intended Configuration Datastore ()
>>>>
>>>> The intended configuration datastore () is a read-only
>>>> configuration datastore. It represents the configuration after all
>>>> configuration transformations to  are performed (e.g.
>>>> template expansion, removal of inactive configuration), and is the
>>>> configuration that the system attempts to apply.
>>>>
>>>>  is tightly coupled to . Whenever data is written
>>>> to , then  is also immediately updated by
>>>> performing all necessary transformations to the contents of
>> 
>>>> and then  is validated.
>>>>
>>>>  may also be updated independently of  (e.g., if
>>>> one of the configuration transformations is changed), but 
>>>> must always be a 'valid configuration data tree' as defined in
>>>> Section 8.1 of [RFC7950].
>>>>
>>>> For simple implementations,  and  are identical.
>>>>
>>>> The contents of  is also related to the 'config true'
>>>> subset of , and hence a client can determine to what
>>>> extent the intended configuration is currently in use by checking
>>>> whether the contents of  also appears in .
>>>>
>>>>  does not persist across reboots; its relationship with
>>>>  makes that unnecessary.
>>>>
>>>> Currently there are no standard mechanisms defined that affect
>>>>  so that it would have different contents than ,
>>>> but this architecture allows for such mechanisms to be defined.
>>>>
>>>> One example of such a mechanism is support for marking nodes as
>>>> inactive in . Inactive nodes are not copied to .
>>>> A second example is support for templates, which can perform
>>>> transformations on the configuration from  to the
>>>> configuration written to .
>>>>
>>>> 
>>>>
>>>> Thanks,
>>>> Rob
>>>>
>>>>
>>>>>
>>>>> /martin
>>>>> .
>>>>>
>>>> .
>>>>
>> .
>>
>


From nobody Thu Sep 28 03:26:40 2017
Return-Path: 
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 01314134668 for ; Thu, 28 Sep 2017 03:26:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 VABra4POAJFm for ; Thu, 28 Sep 2017 03:26:36 -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 267E41321DF for ; Thu, 28 Sep 2017 03:26:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10365; q=dns/txt; s=iport; t=1506594396; x=1507803996; h=subject:from:to:references:message-id:date:mime-version: in-reply-to; bh=QRkC6BOWzi6bk6f2TssWofvntbLhgWlGMZXav/OSllg=; b=g5jC2894sFUqA3m1X9093Db/aDUmH0g40SJxN6ua0kjgkqCImNo9CoCh smY1P27RoiGZmnAxmGRAFTsqtOOkTi9AN6v+0WMtCd+X0TPQy8spwgKjn jlXof+9dp9a9vZnuebO6F+TK748jDKYHvlCAvWtdYyXo2F+AqUh/PrbWx I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CsAAA4zcxZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhEBuJ44XdJA+IpBthT4OggQKGAEMhEdPAoUmGAECAQEBAQEBAWs?= =?us-ascii?q?ohRkBAQEDAQFsGwsSBi4nIg4GAQwGAgEBii0QqT8niloBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEYBYMrg1OBaisLgnKEUQESAQmGCQWYT4hWh16NAYtbhyuNc4dZgTk?= =?us-ascii?q?fOEJBCzIhCB0VSYVPgU8/NoYPDRgHghUBAQE?=
X-IronPort-AV: E=Sophos;i="5.42,449,1500940800";  d="scan'208,217";a="656063647"
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; 28 Sep 2017 10:26:33 +0000
Received: from [10.63.23.161] (dhcp-ensft1-uk-vla370-10-63-23-161.cisco.com [10.63.23.161]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8SAQXWn019600; Thu, 28 Sep 2017 10:26:33 GMT
From: Robert Wilton 
To: Balazs Lengyel , Martin Bjorklund , netmod@ietf.org
References: <9ec6b2e4-36a7-87e6-59fa-828855235835@ericsson.com> <20170914.163239.143365521945928900.mbj@tail-f.com> <4ce3efcd-6e88-9390-1241-21fb89985a9a@ericsson.com> <4dc2014b-0355-ac0b-f9a0-06a2d73033c4@cisco.com>
Message-ID: 
Date: Thu, 28 Sep 2017 11:26:33 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <4dc2014b-0355-ac0b-f9a0-06a2d73033c4@cisco.com>
Content-Type: multipart/alternative; boundary="------------CCB37260CFEBBD5130108C8C"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Adding system configuration to running [was: Re: Comments on NMDA-04]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Sep 2017 10:26:39 -0000

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

Hi,

This is regarding the question as to whether it should be allowed for a 
system to manipulate :

This issue isn't really specific to the NMDA architecture, and there is 
no consensus on whether this should be allowed.

Hence, the proposal is that the NMDA architecture draft be completely 
silent on this, neither endorsing this behaviour, not restricting it.  
Hence no changes to the NMDA architecture draft are required for this issue.

However, I have added an FAQ entry to clarify that this being is not 
prevented, but pointing out some of the potential downsides to a device 
doing this.  The FAQ entry is 
https://github.com/netmod-wg/FAQ/wiki/FAQ-related-to-NMDA-implementations#Q9

Unless I hear otherwise, I propose closing this issue 
(https://github.com/netmod-wg/datastore-dt/issues/8). Comments/review of 
the FAQ text is also welcome.


Thanks,
Rob



On 14/09/2017 18:08, Robert Wilton wrote:
>
>
>
> On 14/09/2017 16:35, Balazs Lengyel wrote:
>>
>> See below!
>>
>> On 2017-09-14 16:32, Martin Bjorklund wrote:
>>> Hi Balazs,
>>>
>>> Thanks for your review.  Comments inline.
>>>
>>> Balazs Lengyel  wrote:
>>>> Hello,
>>>>
>>>> Reading the draft-ietf-netmod-revised-datastores-04 some comments:
>>>>
>>>> General) The system often adds data to the  or 
>>>> datastore already not just to : e.g.
>>>>
>>>> UC1: I have a server configured in running. I need to bind it to an
>>>> ip-address. The ip-address might be the local loopback address,
>>>> however if that is only added to , validation will
>>>> fail indicating that the server is bound to a non-existent
>>>> address. How to handle this?
>>>>
>>>> UC2: I have a set of capabilities set by the system
>>>> e.g. supported-reporting-intervals. I need to configure a job that
>>>> MUST use one of these intervals. If the supported-reporting-intervals
>>>> are only added to  I can not validate the
>>>> selected-interval in my configured job.
>>>>
>>>> My proposal is to allow the system to add data to running as
>>>> well. Actually I think that is a more relevant case then adding
>>>> configuration just to .
>>> I think the consensus is that in general it is a bad idea if servers
>>> (spontaneously) add data to .  However, there is nothing in
>>> the new or old architectures that prohibits this.
>> BALAZS: I strongly disagree.  I know others are also adding stuff to 
>> running as well.
>> IMHO the above use cases are real and used and actually important for 
>> us.
>> I would like to see them included in some way.
> I basically agree with Martin here.
>
> The architecture is cleaner if  is only written by the 
> client.  This avoid requiring clients tracking unexpected changes to 
> running, and opens up the possibility of validating configuration off 
> the box.  Ideally extra stuff should be added into  and then 
> become visible in .
>
> I understand that some systems add data to , and this is 
> fine.  But I think that it is better for an architecture document to 
> be silent on this point.
>
> Thanks,
> Rob
>
>
>>
>> regards Balazs
>> -- 
>> Balazs Lengyel                       Ericsson Hungary Ltd.
>> Senior Specialist
>> Mobile: +36-70-330-7909              email:Balazs.Lengyel@ericsson.com  
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


--------------CCB37260CFEBBD5130108C8C
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi,

    
This is regarding the question as to whether it should be allowed
      for a system to manipulate <running>:

    

    
This issue isn't really specific to the NMDA architecture, and
      there is no consensus on whether this should be allowed.

    
Hence, the proposal is that the NMDA architecture draft be
      completely silent on this, neither endorsing this behaviour, not
      restricting it.  Hence no changes to the NMDA architecture draft
      are required for this issue.

    

    
However, I have added an FAQ entry to clarify that this being is
      not prevented, but pointing out some of the potential downsides to
      a device doing this.  The FAQ entry is
https://github.com/netmod-wg/FAQ/wiki/FAQ-related-to-NMDA-implementations#Q9

    
Unless I hear otherwise, I propose closing this issue
      (https://github.com/netmod-wg/datastore-dt/issues/8). 
      Comments/review of the FAQ text is also welcome.

    

    

    Thanks,

    Rob

    

    

    

    
On 14/09/2017 18:08, Robert Wilton
      wrote:

    

    

      
      


      

      

      
On 14/09/2017 16:35, Balazs Lengyel
        wrote:

      

      

        
See below!

        

        
On 2017-09-14 16:32, Martin
          Bjorklund wrote:

        

        

          
Hi Balazs,

Thanks for your review.  Comments inline.

Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:


          

            
Hello,

Reading the draft-ietf-netmod-revised-datastores-04 some comments:

General) The system often adds data to the <running> or <intended>
datastore already not just to <operational>: e.g.

UC1: I have a server configured in running. I need to bind it to an
ip-address. The ip-address might be the local loopback address,
however if that is only added to <operational>, validation will
fail indicating that the server is bound to a non-existent
address. How to handle this?

UC2: I have a set of capabilities set by the system
e.g. supported-reporting-intervals. I need to configure a job that
MUST use one of these intervals. If the supported-reporting-intervals
are only added to <operational> I can not validate the
selected-interval in my configured job.

My proposal is to allow the system to add data to running as
well. Actually I think that is a more relevant case then adding
configuration just to <operation>.


          

          
I think the consensus is that in general it is a bad idea if servers
(spontaneously) add data to <running>.  However, there is nothing in
the new or old architectures that prohibits this.

        

        BALAZS: I strongly disagree.  I know others are also adding
        stuff to running as well. 

        IMHO the above use cases are real and used and actually
        important for us. 

        I would like to see them included in some way.

      

      I basically agree with Martin here.

      

      The architecture is cleaner if <running> is only written by
      the client.  This avoid requiring clients tracking unexpected
      changes to running, and opens up the possibility of validating
      configuration off the box.  Ideally extra stuff should be added
      into <intended> and then become visible in
      <operational>.

      

      I understand that some systems add data to <running>, and
      this is fine.  But I think that it is better for an architecture
      document to be silent on this point.  

      

      Thanks,

      Rob

      

      

      
 

        regards Balazs

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


        

        

        

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


      

      

      

      

      

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


    

    

  


--------------CCB37260CFEBBD5130108C8C--


From nobody Thu Sep 28 04:05:13 2017
Return-Path: 
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 52E5B1346B0 for ; Thu, 28 Sep 2017 04:05:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 q1CHcdHcAUcI for ; Thu, 28 Sep 2017 04:05:10 -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 73ACF1345D8 for ; Thu, 28 Sep 2017 04:05:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4204; q=dns/txt; s=iport; t=1506596709; x=1507806309; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=QgYQjjfSfC3eK75STQrspDRFcozX5cwL291w1g6Dc/o=; b=T2CrDBFC5XF7Z323qA2jNhrGy66Tm/81iEa8lcoE86VxxKqXeUs9TAQy 7ggOIb+POsBdiYhX39kpPgJz8bGftqcstZpl3lnrQP99+SibfFM0whtnN nwyXaO6Uf7c0hOet9tf59cBDQptHO8AqB8qmOPlIQFxElw2dJOB3SG59/ c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BwAQCZ1sxZ/xbLJq1TChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYRAbiePC5BgliuCEgoYC4RJTwKFKBcBAgEBAQEBAQFrKIUYAQE?= =?us-ascii?q?BAQMBATABBTYXBAsOBwECLicwBgEMBgIBAYhZgVQQqSyLAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARgFgyuDU4FqK4J9hFkEEYYJBYw0lHSHXoMUiW6CE4Vug1qHK41?= =?us-ascii?q?0h1mBOSABNoEOMiEIHRVJhx4/NoZCgkMBAQE?=
X-IronPort-AV: E=Sophos;i="5.42,449,1500940800"; d="scan'208";a="697610245"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Sep 2017 11:05:07 +0000
Received: from [10.63.23.161] (dhcp-ensft1-uk-vla370-10-63-23-161.cisco.com [10.63.23.161]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8SB57cc015954; Thu, 28 Sep 2017 11:05:07 GMT
To: Martin Bjorklund , lhotka@nic.cz, netmod@ietf.org, "t.petch" 
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <022e01d32e17$dfd54d60$4001a8c0@gateway.2wire.net> <1505476654.18681.29.camel@nic.cz> <20170915.142130.250716263736500205.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: <3bc878a3-f055-ba4a-fc05-e0e464b6bb18@cisco.com>
Date: Thu, 28 Sep 2017 12:05:06 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170915.142130.250716263736500205.mbj@tail-f.com>
Content-Type: text/plain; charset=iso-8859-15; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04 guessing
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Sep 2017 11:05:12 -0000

The authors have discussed this issue 
(https://github.com/netmod-wg/datastore-dt/issues/15), and their 
proposal is to close this with no change to the NMDA draft with the 
following justifications:

1) This assumption is that longer term all models would become NMDA 
compliant and over time it would likely require that all modules would 
need to have this extension added, creating a CLR.

2) Defining the extension would take time, and further delay the IETF 
standardization of YANG models, but it is important that IETF actually 
gets standard YANG models published as quickly as possible so that they 
can be implemented by the industry.

3) NMDA devices can implement "non NMDA style" modules (but with 
duplication of state), and non NMDA devices can implement "NMDA style" 
modules (but with reduced functionality).

4) YANG Catalog can identify what type of style a particular module is, 
by using some heuristically analysis of the structure of the model.

Thanks,
Rob


On 15/09/2017 13:21, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
>> t.petch pí¨e v Pá 15. 09. 2017 v 12:29 +0100:
>>> Looking at a YANG module in future, how can I tell whether or not it is
>>> written to work with revised datastores?
>> Ideally, this ought to be a wrong question. A YANG module (or rather a YANG data
>> model) should specify constraints for a data tree, no matter where the tree
>> happens to reside.
> I agree, and an old module can be implemented in an NMDA-compatible
> server (with some redundant info), and a new modules can be implemented in a
> non-NMDA-compatible server (with limited functionality).
>
> But the truth is that modules are and will be designed to fit into
> some environment (or "meta model").  For example, with NMDA, there
> will be a single tree.  If we had an annotation for "comments" on
> nodes, you wouldn't see any leafs called "description".  If we didn't
> have the ability to create things in the protocol, our models would
> have objects of type "RowStatus".  Etc.
>
>
> /martin
>
>
>> Coupling a data modelling language with rather specific aspects of an NM
>> application is a bad design.
>>
>> Lada
>>
>>> If the module is written assuming revised datastores and the environment
>>> does not support this in some regard, then we have a management
>>> malfunction, which could be disastrous.
>>>
>>> I think that there should be some mechanistic way, something that can be
>>> automated, for a system to check whether or not a module is assuming
>>> revised datastores or not.  This is a bit like the change from YANG 1.0
>>> to YANG 1.1; there needs to be a way of telling what environment the
>>> module is written for, and so we have the
>>>
>>> yang-version 1.1;
>>>
>>> statement.
>>>
>>> Revised datastores needs something similar in the module.
>>>
>>> Tom Petch
>>>
>>>
>>> ----- Original Message -----
>>> From: "Lou Berger" 
>>> Sent: Friday, September 01, 2017 10:02 PM
>>>
>>>
>>>> All,
>>>>
>>>> This starts a two week working group last call on
>>>> draft-ietf-netmod-revised-datastores-04.
>>>>
>>>> The working group last call ends on September 17.
>>>> Please send your comments to the netmod mailing list.
>>>>
>>>> Positive comments, e.g., "I've reviewed this document and
>>>> believe it is ready for publication", are welcome!
>>>> This is useful and important, even from authors.
>>>>
>>>> Thank you,
>>>> Netmod Chairs
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> -- 
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


From nobody Thu Sep 28 04:10:48 2017
Return-Path: 
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 B14D21346BC for ; Thu, 28 Sep 2017 04:10:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 IHaocujDyrdG for ; Thu, 28 Sep 2017 04:10:46 -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 C72631346B8 for ; Thu, 28 Sep 2017 04:10:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1122; q=dns/txt; s=iport; t=1506597045; x=1507806645; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=m86SolgX+D4JkiWJoXk1sTMNgxwOTFM5cGf5qxQnMDg=; b=O3GKpA7rLmxnPueuBZ8vBaQmuZU1CqwbFsMGx4mJZHDqI/Cep+aDvl5X 9NZKwgeT+5bkLjoX7BWclsduTZOa3aINHbhrh/qBx2xBM7k+dHUlkcvq/ vFwxUivTn6g8TKnGd0VpuwmIogBjePHvx9W/X6srQD9IT8iZMRyCmXIIU Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BxAQAA2MxZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhEBuJ4N4ixOQYJYrghIKI4UYAoUpFgECAQEBAQEBAWsohRkBBSM?= =?us-ascii?q?PAQVRCw4KAgImAgJXBgEMBgIBAYotEKcEgieLAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RsFgQ6CHYNTgWorgn2IF4JgBaEoh16NAotbhyuNdIdZgTkmBC1CTDIhCB0Vh2c?= =?us-ascii?q?/NokFAQEB?=
X-IronPort-AV: E=Sophos;i="5.42,449,1500940800"; d="scan'208";a="655041036"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Sep 2017 11:10:43 +0000
Received: from [10.63.23.161] (dhcp-ensft1-uk-vla370-10-63-23-161.cisco.com [10.63.23.161]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v8SBAhhv013295; Thu, 28 Sep 2017 11:10:43 GMT
To: Martin Bjorklund , balazs.lengyel@ericsson.com, netmod@ietf.org
References: <9ec6b2e4-36a7-87e6-59fa-828855235835@ericsson.com> <20170914.163239.143365521945928900.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: 
Date: Thu, 28 Sep 2017 12:10:43 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170914.163239.143365521945928900.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Comments on NMDA-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Sep 2017 11:10:47 -0000

Hi,

This is regarding issue 
(https://github.com/netmod-wg/datastore-dt/issues/11): actions and rpcs 
should be allowed to include other datastores in their XPath evaluation

There has been no further discussion of this issue after Martin's reply, 
and this seems to be out of scope for the NMDA draft.  Hence the authors 
proposal is to close this issue with no change to the draft.

Thanks,
Rob


On 14/09/2017 15:32, Martin Bjorklund wrote:
> Hi Balazs,
>
> Thanks for your review.  Comments inline.
>
> Balazs Lengyel  wrote:
>
>> Ch 5.1) IMHO actions and rpcs should be allowed to include other
>> datastores in their XPath evaluation. My suggestion is that they need
>> to specify it somehow. (Yang extension?)
> This is something that the WG has discussed in the past as well, but
> so far no concrete proposal has been made.  I think such extensions
> can be done in a separate document in the future, or maybe if we do a
> new version of YANG.
>
> But note that for rpc and action, this section only talks about
> XPath in input/output parameters.
>


From nobody Thu Sep 28 06:11:40 2017
Return-Path: 
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 49B5513472D; Thu, 28 Sep 2017 06:11:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level: 
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uw_HAOasEzRt; Thu, 28 Sep 2017 06:11:22 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF338133023; Thu, 28 Sep 2017 06:11:20 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DWL41176; Thu, 28 Sep 2017 13:11:17 +0000 (GMT)
Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 28 Sep 2017 14:11:15 +0100
Received: from DGGEML507-MBX.china.huawei.com ([169.254.2.79]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0301.000; Thu, 28 Sep 2017 21:11:05 +0800
From: Jiangyuanlong 
To: Sean Condon , "netmod@ietf.org" 
CC: "tictoc@ietf.org" , Rodney Cummings 
Thread-Topic: draft-ietf-tictoc-1588v2-yang-05 - Concern over port identifier
Thread-Index: AdM20lxp4a4LJ64bREK66XJnd3gJawAF4nRwABKMRUAAEqGn9wA1hiAA
Date: Thu, 28 Sep 2017 13:11:04 +0000
Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5CB62E@dggeml507-mbx.china.huawei.com>
References: <640F4C69F839A64C8949EF04FAAEE44679F253DE@avsrvexchmbx1.microsemi.net> , <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5C9C01@dggeml507-mbx.china.huawei.com> <640F4C69F839A64C8949EF04FAAEE44679F25561@avsrvexchmbx1.microsemi.net>
In-Reply-To: <640F4C69F839A64C8949EF04FAAEE44679F25561@avsrvexchmbx1.microsemi.net>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.74.202.215]
Content-Type: multipart/alternative; boundary="_000_3B0A1BED22CAD649A1B3E97BE5DDD68BBB5CB62Edggeml507mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.59CCF4F7.0032, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.2.79, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 58b7b61f005eaa07963247ff9f32f3b7
Archived-At: 
Subject: Re: [netmod] draft-ietf-tictoc-1588v2-yang-05 - Concern over port identifier
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Sep 2017 13:11:33 -0000

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

U2VhbiwNCg0KTXkgcGVyc29uYWwgb3BpbmlvbiBpcyB0aGF0IGl0IGNhbiB3b3JrLCBidXQgSSB3
b3VsZCBsaWtlIHRvIGFzayBmb3IgbW9yZSBvcGluaW9ucyBmcm9tIG91ciBuZXRtb2QgZXhwZXJ0
czspDQoNCkhpIG5ldG1vZCBleHBlcnRzLA0KQ29uc2lkZXJpbmcgdGhlIGZvbGxvd2luZyBzYW1w
bGUgbW9kdWxlLCBteS1saXN0IGlzIGEgbGlzdCwgYW5kIGl0IG5lZWRzIHRvIHVzZSBhIGxlYWYg
bWVtYmVyICJwb3J0LW51bWJlciIgaW4gbXktcG9ydC1jb250YWluZXIgYXMgYSBrZXkuDQpXZSBu
b3cgaGF2ZSAzIG9wdGlvbnM6DQoxLg0KICBsaXN0IG15LWxpc3Qgew0KICAgIGtleSAicG9ydC1u
dW1iZXIiOw0KICAgIGxlYWYgcG9ydC1udW1iZXIgew0KICAgICAgIHR5cGUgdWludDE2Ow0KICAg
IH0NCg0KICAgIGNvbnRhaW5lciBteS1wb3J0LWNvbnRhaW5lciB7DQogICAgICAgIGxlYWYgcG9y
dC1udW1iZXIgew0KICAgICAgICAgIHR5cGUgdWludDE2Ow0KICAgICAgICB9DQogICAgICAgICBs
ZWFmIG90aGVyLWxlYWYgew0KICAgICAgICAgICAuLi4NCiAgICAgICAgIH0NCiAgICB9DQogIH0N
CkJ1dCB0aGlzIGRvZXMgbm90IHdvcmsgZm9yIHRoZXJlIGlzIGNvbXBpbGluZyBlcnJvci4NCg0K
Mi4NCiAgbGlzdCBteS1saXN0IHsNCiAgICBrZXkgInBvcnQtbnVtYmVyIjsNCiAgICBsZWFmIHBv
cnQtbnVtYmVyIHsNCiAgICAgICB0eXBlIHVpbnQxNjsNCiAgICB9DQogICAgY29udGFpbmVyIG15
LXBvcnQtY29udGFpbmVyIHsNCiAgICAgICAgbGVhZiBwb3J0LW51bWJlciB7DQogICAgICAgICAg
ICB0eXBlIGxlYWZyZWZ7DQogICAgICAgICAgICAgIHBhdGggIi4uLy4uL3BvcnQtbnVtYmVyIjsN
CiAgICAgICAgICAgIH0NCiAgICAgICAgfQ0KICAgICAgICAgbGVhZiBvdGhlci1sZWFmIHsNCiAg
ICAgICAgICAgLi4uDQogICAgICAgICB9DQogICAgfQ0KICB9DQpPcHRpb24gMiBjYW4gcGFyc2Us
IHRob3VnaCBsZWFmcmVmIGluIGEgc3ViLW1vZHVsZSBzZWVtcyBub3QgdmVyeSBuYXR1cmFsLg0K
DQozLg0KICBsaXN0IG15LWxpc3Qgew0KICAgIGtleSAicG9ydC1udW1iZXIiOw0KICAgIGxlYWYg
cG9ydC1udW1iZXIgew0KICAgICAgIHR5cGUgbGVhZnJlZnsNCiAgICAgICAgICBwYXRoICIuLi9t
eS1wb3J0LWNvbnRhaW5lci9wb3J0LW51bWJlciI7DQogICAgICAgfQ0KICAgIH0NCiAgICBjb250
YWluZXIgbXktcG9ydC1jb250YWluZXIgew0KICAgICAgICBsZWFmIHBvcnQtbnVtYmVyIHsNCiAg
ICAgICAgICB0eXBlIHVpbnQxNjsNCiAgICAgICAgfQ0KICAgICAgICAgbGVhZiBvdGhlci1sZWFm
IHsNCiAgICAgICAgICAgLi4uDQogICAgICAgICB9DQogICAgfQ0KICB9DQoNCk9wdGlvbiAzIGNh
biBhbHNvIHBhcnNlLCB0aG91Z2ggbGVhZnJlZiBzZWVtcyBub3QgYSB2ZXJ5IG5hdHVyYWwga2V5
LiBXaGF0IGlzIHlvdXIgZmF2b3JpdGUgb3B0aW9uPyBPciBkbyB5b3UgaGF2ZSBhbnkgYmV0dGVy
IHNjaGVtZXM/DQpZb3VyIG9waW5pb25zIGFyZSB2ZXJ5IGltcG9ydGFudCBmb3Igb3VyIHJldmlz
aW9uIG9mIHRoaXMgZHJhZnQuDQoNClRoYW5rcywNCll1YW5sb25nDQoNCg0KRnJvbTogU2VhbiBD
b25kb24gW21haWx0bzpzZWFuLmNvbmRvbkBtaWNyb3NlbWkuY29tXQ0KU2VudDogV2VkbmVzZGF5
LCBTZXB0ZW1iZXIgMjcsIDIwMTcgNzoxMSBQTQ0KVG86IEppYW5neXVhbmxvbmcNCkNjOiB0aWN0
b2NAaWV0Zi5vcmc7IFJvZG5leSBDdW1taW5ncw0KU3ViamVjdDogUkU6IGRyYWZ0LWlldGYtdGlj
dG9jLTE1ODh2Mi15YW5nLTA1IC0gQ29uY2VybiBvdmVyIHBvcnQgaWRlbnRpZmllcg0KDQpUaGFu
a3MgZ3V5cyBmb3IgeW91ciByZXNwb25zZXMuDQoNCkkgYWNjZXB0IHlvdXIgcG9pbnRzIHRvIGtl
ZXAgdGhlIHN0cnVjdHVyZSBhcyBhbGlnbmVkIHRvIHRoZSBJRUVFIDE1ODggc3RhbmRhcmQgYXMg
cG9zc2libGUuDQoNCk9uZSBhbHRlcm5hdGUgc3VnZ2VzdGlvbiB0aGF0IEkgd291bGQgbWFrZSwg
aXMgdGhhdCB0aGUgcG9ydC1udW1iZXIgY3VycmVudGx5IGRlZmluZWQgYXMgbGVhZnJlZiBzaG91
bGQgYmUgbWFkZSB0aGUgcmVhbCBhdHRyaWJ1dGUgKGkuZS4gdWludDE2KSBhbmQgdGhhdCB0aGUg
cG9ydC1udW1iZXIgaW5zaWRlIHBvcnQtaWRlbnRpdHkgY29udGFpbmVyIHNob3VsZCBiZSBtYWRl
IGluIHRvIHRoZSBsZWFmIHJlZiAoYW5kIHNldCB0byBtYW5kYXRvcnkgdHJ1ZSkuDQoNClRoZSBy
ZWFzb24gSSBzYXkgdGhpcyBpcyB0aGF0DQoNCiAgMS4gIFhNTCBtb2RlbHMgYXJlIHVzdWFsbHkg
bmF2aWdhdGVkIGFuZCBjb25zdHJ1Y3RlZCByb290LXRvLWxlYWYsIGFuZCB0aGUgd2F5IGl0J3Mg
cG9ydHJheWVkIGF0IHRoZSBtb21lbnQgaXMgdGhhdCBwb3J0LW51bWJlciBsZWFmcmVmIHBvaW50
cyB0byBzb21ldGhpbmcgdGhhdCBtYXkgbm90IGV4aXN0IGF0IHRoZSB0aW1lIGl0IGlzIGJlaW5n
IGRlZmluZWQuIFRoaXMgbWFrZXMgaXQgZGlmZmljdWx0IHRvIGltcGxlbWVudC4NCiAgMi4gIEFs
c28gcG9ydC1pZGVudGl0eS9wb3J0LW51bWJlciBpcyBub3QgIm1hbmRhdG9yeSB0cnVlIiBtZWFu
aW5nIHRoYXQgaXQgY291bGQgYmUgbGVmdCBvdXQgYWx0b2dldGhlci4gSXQncyBub3QgdmFsaWQg
Zm9yIGl0IHRvIGhhdmUgYSBkZWZhdWx0IHZhbHVlIGVpdGhlciBzaW5jZSBldmVyeSBpdGVtIGlu
IHRoZSBsaXN0IHdpbGwgbmVlZCBhIGRpZmZlcmVudCBpZGVudGlmaWVyLg0KDQpXaXRoIHRoaXMg
c3VnZ2VzdGlvbiB0aGUgc3RydWN0dXJlIHlvdSByZXF1aXJlIHdpdGggcG9ydC1pZGVudGl0eSBz
dGlsbCBleGlzdHMsIGJ1dCBub3cgdGhlIGltcGxlbWVudGF0aW9uIGlzIG1vcmUgc3RyYWlnaHRm
b3J3YXJkLCBhbmQgdGhlIGNoYW5nZSB3aWxsIGJlIHRyYW5zcGFyZW50IHRvIGFuIGVuZCB1c2Vy
Lg0KDQoNCkJlc3QgcmVnYXJkcywgU2Vhbg0KPT09PT09PT09PT09PT09PT09PT09PT0NClNlYW4g
Q29uZG9uDQpTeXN0ZW0gJiBTb2Z0d2FyZSBBcmNoaXRlY3QNCkZyZXF1ZW5jeSAmIFRpbWluZyBE
aXZpc2lvbg0KTWljcm9zZW1pIEluYy4NCnNlYW4uY29uZG9uQG1pY3Jvc2VtaS5jb208bWFpbHRv
OnNlYW4uY29uZG9uQG1pY3Jvc2VtaS5jb20+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQpGcm9tOiBKaWFuZ3l1YW5sb25nIFtqaWFuZ3l1YW5sb25nQGh1YXdlaS5jb21dDQpT
ZW50OiAyNyBTZXB0ZW1iZXIgMjAxNyAwODowNQ0KVG86IFNlYW4gQ29uZG9uDQpDYzogdGljdG9j
QGlldGYub3JnPG1haWx0bzp0aWN0b2NAaWV0Zi5vcmc+OyBSb2RuZXkgQ3VtbWluZ3MNClN1Ympl
Y3Q6IFJFOiBkcmFmdC1pZXRmLXRpY3RvYy0xNTg4djIteWFuZy0wNSAtIENvbmNlcm4gb3ZlciBw
b3J0IGlkZW50aWZpZXINCkVYVEVSTkFMIEVNQUlMDQoNCkRlYXIgU2VhbiwNCg0KDQoNClRoYW5r
IHlvdSBhIGxvdCBmb3IgZGl2aW5nIGludG8gdGhlIHRlY2huaWNhbCBkZXRhaWxzIG9mIHRoaXMg
bW9kdWxlLiBKdXN0IGFzIFJvZG5leSBzYWlkLCBpdCBpcyBhIGNoYWxsZW5nZSBvZiAxNTg4IGlu
Zm8gbW9kZWwgdG8gWUFORywgYW5kIHdlIHVzZSB0aGUgbGVhZnJlZiBvZiBZQU5HIHRvIHdvcmsg
YXJvdW5kIGl0Lg0KDQpJIHdvdWxkIGxpa2UgdG8gcHJvdmlkZSBhIGxpdHRsZSBtb3JlIGJhY2tn
cm91bmRzIG9uIHRoZSB0cmFkZW9mZjoNCg0KDQoNCjEuIEl0IHNheXMgaW4gU2VjLiA3LjUuMi4x
IGluIElFRUUgMTU4OC0yMDA4OiBwb3J0SWRlbnRpdHkgaXMgYSBtZW1iZXIgb2YgdGhlIHBvcnRE
UyBkYXRhIHNldC4gQSBwb3J0SWRlbnRpdHkgY29uc2lzdHMgb2YgdHdvIGF0dHJpYnV0ZXMsIGFz
DQoNCmZvbGxvd3M6DQoNCuKOryBwb3J0SWRlbnRpdHkuY2xvY2tJZGVudGl0eQ0KDQrijq8gcG9y
dElkZW50aXR5LnBvcnROdW1iZXINCg0KRnVydGhlcm1vcmUsIHRoZSAicG9ydERTLnBvcnRJZGVu
dGl0eSIgYXR0cmlidXRlIGlzIG1lbnRpb25lZCBxdWl0ZSBhIGZldyB0aW1lcyBpbiAxNTg4LTIw
MDgsIGVzcGVjaWFsbHkgaW4gVGFibGUgMTcgYW5kIHVuZGVyIFRhYmxlIDYxLCB3aXRoIGEgaGlu
dCB0aGF0IGFzc2lnbm1lbnQgYW5kIGNvbXBhcmlzb24gY2FuIGJlIGRvbmUgb24gdGhpcyBtZW1i
ZXIgZGlyZWN0bHksIHRodXMgaXQgc2VlbXMgdG8gbWUgcG9ydElkZW50aXR5IGlzIGFuIGltcG9y
dGFudCBhbmQgd2VsbCB1bmRlcnN0b29kIGNvbnN0cnVjdCBpbiB0aGUgMTU4OCBzcGVjaWZpY2F0
aW9uLg0KDQoNCg0KMi4gSWYgd2UgY2hhbmdlIHBvcnREUy5wb3J0SWRlbnRpdHkgZnJvbSBhIGNv
bnRhaW5lciB0byBhIGdyb3VwaW5nLCB0aGVuIHRoZXJlIGlzIG5vIHBvcnRJZGVudGl0eSBmb3Ig
cG9ydERTIGFuZCB0cmFuc3BhcmVudGNsb2NrUG9ydERTIGluIHRoZSByZXN1bHRpbmcgdHJlZSBk
aWFncmFtOg0KDQoNCg0KbW9kdWxlOiBpZXRmLXB0cC1kYXRhc2V0DQoNCiAgICArLS1ydyBpbnN0
YW5jZS1saXN0KiBbaW5zdGFuY2UtbnVtYmVyXQ0KDQogICAgfCAgKy0tcncgaW5zdGFuY2UtbnVt
YmVyICAgICAgIHVpbnQxNg0KDQogICAgfCAgKy0tcncgZGVmYXVsdC1kcw0KDQogICAgfCAgfCAg
Ky0tcncgdHdvLXN0ZXAtZmxhZz8gICAgYm9vbGVhbg0KDQogICAgfCAgfCAgKy0tcncgY2xvY2st
aWRlbnRpdHk/ICAgY2xvY2staWRlbnRpdHktdHlwZQ0KDQogICAgfCAgfCAgKy0tcncgbnVtYmVy
LXBvcnRzPyAgICAgdWludDE2DQoNCiAgICB8ICB8ICArLS1ydyBjbG9jay1xdWFsaXR5DQoNCiAg
ICB8ICB8ICB8ICArLS1ydyBjbG9jay1jbGFzcz8gICAgICAgICAgICAgICAgICB1aW50OA0KDQog
ICAgfCAgfCAgfCAgKy0tcncgY2xvY2stYWNjdXJhY3k/ICAgICAgICAgICAgICAgdWludDgNCg0K
ICAgIHwgIHwgIHwgICstLXJ3IG9mZnNldC1zY2FsZWQtbG9nLXZhcmlhbmNlPyAgIHVpbnQxNg0K
DQogICAgfCAgfCAgKy0tcncgcHJpb3JpdHkxPyAgICAgICAgdWludDgNCg0KICAgIHwgIHwgICst
LXJ3IHByaW9yaXR5Mj8gICAgICAgIHVpbnQ4DQoNCiAgICB8ICB8ICArLS1ydyBkb21haW4tbnVt
YmVyPyAgICB1aW50OA0KDQogICAgfCAgfCAgKy0tcncgc2xhdmUtb25seT8gICAgICAgYm9vbGVh
bg0KDQogICAgfCAgKy0tcncgY3VycmVudC1kcw0KDQogICAgfCAgfCAgKy0tcncgc3RlcHMtcmVt
b3ZlZD8gICAgICAgIHVpbnQxNg0KDQogICAgfCAgfCAgKy0tcncgb2Zmc2V0LWZyb20tbWFzdGVy
PyAgIHRpbWUtaW50ZXJ2YWwtdHlwZQ0KDQogICAgfCAgfCAgKy0tcncgbWVhbi1wYXRoLWRlbGF5
PyAgICAgIHRpbWUtaW50ZXJ2YWwtdHlwZQ0KDQogICAgfCAgKy0tcncgcGFyZW50LWRzDQoNCiAg
ICB8ICB8ICArLS1ydyBwYXJlbnQtcG9ydC1pZGVudGl0eQ0KDQogICAgfCAgfCAgfCAgKy0tcncg
Y2xvY2staWRlbnRpdHk/ICAgY2xvY2staWRlbnRpdHktdHlwZQ0KDQogICAgfCAgfCAgfCAgKy0t
cncgcG9ydC1udW1iZXI/ICAgICAgdWludDE2DQoNCiAgICB8ICB8ICArLS1ydyBwYXJlbnQtc3Rh
dHM/ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYm9vbGVhbg0KDQogICAgfCAgfCAg
Ky0tcncgb2JzZXJ2ZWQtcGFyZW50LW9mZnNldC1zY2FsZWQtbG9nLXZhcmlhbmNlPyAgIHVpbnQx
Ng0KDQogICAgfCAgfCAgKy0tcncgb2JzZXJ2ZWQtcGFyZW50LWNsb2NrLXBoYXNlLWNoYW5nZS1y
YXRlPyAgICAgIGludDMyDQoNCiAgICB8ICB8ICArLS1ydyBncmFuZG1hc3Rlci1pZGVudGl0eT8g
ICAgICAgICAgICAgICAgICAgICAgICAgYmluYXJ5DQoNCiAgICB8ICB8ICArLS1ydyBncmFuZG1h
c3Rlci1jbG9jay1xdWFsaXR5DQoNCiAgICB8ICB8ICB8ICArLS1ydyBjbG9jay1jbGFzcz8gICAg
ICAgICAgICAgICAgICB1aW50OA0KDQogICAgfCAgfCAgfCAgKy0tcncgY2xvY2stYWNjdXJhY3k/
ICAgICAgICAgICAgICAgdWludDgNCg0KICAgIHwgIHwgIHwgICstLXJ3IG9mZnNldC1zY2FsZWQt
bG9nLXZhcmlhbmNlPyAgIHVpbnQxNg0KDQogICAgfCAgfCAgKy0tcncgZ3JhbmRtYXN0ZXItcHJp
b3JpdHkxPyAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQ4DQoNCiAgICB8ICB8ICArLS1ydyBn
cmFuZG1hc3Rlci1wcmlvcml0eTI/ICAgICAgICAgICAgICAgICAgICAgICAgdWludDgNCg0KICAg
IHwgICstLXJ3IHRpbWUtcHJvcGVydGllcy1kcw0KDQogICAgfCAgfCAgKy0tcncgY3VycmVudC11
dGMtb2Zmc2V0LXZhbGlkPyAgIGJvb2xlYW4NCg0KICAgIHwgIHwgICstLXJ3IGN1cnJlbnQtdXRj
LW9mZnNldD8gICAgICAgICBpbnQxNg0KDQogICAgfCAgfCAgKy0tcncgbGVhcDU5PyAgICAgICAg
ICAgICAgICAgICAgIGJvb2xlYW4NCg0KICAgIHwgIHwgICstLXJ3IGxlYXA2MT8gICAgICAgICAg
ICAgICAgICAgICBib29sZWFuDQoNCiAgICB8ICB8ICArLS1ydyB0aW1lLXRyYWNlYWJsZT8gICAg
ICAgICAgICAgYm9vbGVhbg0KDQogICAgfCAgfCAgKy0tcncgZnJlcXVlbmN5LXRyYWNlYWJsZT8g
ICAgICAgIGJvb2xlYW4NCg0KICAgIHwgIHwgICstLXJ3IHB0cC10aW1lc2NhbGU/ICAgICAgICAg
ICAgICBib29sZWFuDQoNCiAgICB8ICB8ICArLS1ydyB0aW1lLXNvdXJjZT8gICAgICAgICAgICAg
ICAgdWludDgNCg0KICAgIHwgICstLXJ3IHBvcnQtZHMtbGlzdCogW3BvcnQtbnVtYmVyXQ0KDQog
ICAgfCAgICAgKy0tcncgY2xvY2staWRlbnRpdHk/ICAgICAgICAgICAgICAgIGNsb2NrLWlkZW50
aXR5LXR5cGUNCg0KICAgIHwgICAgICstLXJ3IHBvcnQtbnVtYmVyICAgICAgICAgICAgICAgICAg
ICB1aW50MTYNCg0KICAgIHwgICAgICstLXJ3IHBvcnQtc3RhdGU/ICAgICAgICAgICAgICAgICAg
ICBwb3J0LXN0YXRlLWVudW1lcmF0aW9uDQoNCiAgICB8ICAgICArLS1ydyB1bmRlcmx5aW5nLWlu
dGVyZmFjZT8gICAgICAgICAgaWY6aW50ZXJmYWNlLXJlZg0KDQogICAgfCAgICAgKy0tcncgbG9n
LW1pbi1kZWxheS1yZXEtaW50ZXJ2YWw/ICAgIGludDgNCg0KICAgIHwgICAgICstLXJ3IHBlZXIt
bWVhbi1wYXRoLWRlbGF5PyAgICAgICAgICB0aW1lLWludGVydmFsLXR5cGUNCg0KICAgIHwgICAg
ICstLXJ3IGxvZy1hbm5vdW5jZS1pbnRlcnZhbD8gICAgICAgICBpbnQ4DQoNCiAgICB8ICAgICAr
LS1ydyBhbm5vdW5jZS1yZWNlaXB0LXRpbWVvdXQ/ICAgICAgdWludDgNCg0KICAgIHwgICAgICst
LXJ3IGxvZy1zeW5jLWludGVydmFsPyAgICAgICAgICAgICBpbnQ4DQoNCiAgICB8ICAgICArLS1y
dyBkZWxheS1tZWNoYW5pc20/ICAgICAgICAgICAgICAgZGVsYXktbWVjaGFuaXNtLWVudW1lcmF0
aW9uDQoNCiAgICB8ICAgICArLS1ydyBsb2ctbWluLXBkZWxheS1yZXEtaW50ZXJ2YWw/ICAgaW50
OA0KDQogICAgfCAgICAgKy0tcncgdmVyc2lvbi1udW1iZXI/ICAgICAgICAgICAgICAgIHVpbnQ4
DQoNCiAgICArLS1ydyB0cmFuc3BhcmVudC1jbG9jay1kZWZhdWx0LWRzDQoNCiAgICB8ICArLS1y
dyBjbG9jay1pZGVudGl0eT8gICAgY2xvY2staWRlbnRpdHktdHlwZQ0KDQogICAgfCAgKy0tcncg
bnVtYmVyLXBvcnRzPyAgICAgIHVpbnQxNg0KDQogICAgfCAgKy0tcncgZGVsYXktbWVjaGFuaXNt
PyAgIGRlbGF5LW1lY2hhbmlzbS1lbnVtZXJhdGlvbg0KDQogICAgfCAgKy0tcncgcHJpbWFyeS1k
b21haW4/ICAgIHVpbnQ4DQoNCiAgICArLS1ydyB0cmFuc3BhcmVudC1jbG9jay1wb3J0LWRzLWxp
c3QqIFtwb3J0LW51bWJlcl0NCg0KICAgICAgICstLXJ3IGNsb2NrLWlkZW50aXR5PyAgICAgICAg
ICAgICAgICBjbG9jay1pZGVudGl0eS10eXBlDQoNCiAgICAgICArLS1ydyBwb3J0LW51bWJlciAg
ICAgICAgICAgICAgICAgICAgdWludDE2DQoNCiAgICAgICArLS1ydyBsb2ctbWluLXBkZWxheS1y
ZXEtaW50ZXJ2YWw/ICAgaW50OA0KDQogICAgICAgKy0tcncgZmF1bHR5LWZsYWc/ICAgICAgICAg
ICAgICAgICAgIGJvb2xlYW4NCg0KICAgICAgICstLXJ3IHBlZXItbWVhbi1wYXRoLWRlbGF5PyAg
ICAgICAgICB0aW1lLWludGVydmFsLXR5cGUNCg0KDQoNCkluIGNvbnRyYXN0IHRvIHRoZSBvcmln
aW5hbCAxNTg4IFlBTkcgdHJlZSBkaWFncmFtOg0KDQogICBtb2R1bGU6IGlldGYtcHRwLWRhdGFz
ZXQNCg0KICAgICAgICstLXJ3IGluc3RhbmNlLWxpc3QqIFtpbnN0YW5jZS1udW1iZXJdDQoNCiAg
ICAgICB8ICArLS1ydyBpbnN0YW5jZS1udW1iZXIgICAgICB1aW50MTYNCg0KICAgICAgIHwgICst
LXJ3IGRlZmF1bHQtZHMNCg0KICAgICAgIHwgIHwgICstLXJ3IHR3by1zdGVwLWZsYWc/ICAgIGJv
b2xlYW4NCg0KICAgICAgIHwgIHwgICstLXJ3IGNsb2NrLWlkZW50aXR5PyAgIGNsb2NrLWlkZW50
aXR5LXR5cGUNCg0KICAgICAgIHwgIHwgICstLXJ3IG51bWJlci1wb3J0cz8gICAgIHVpbnQxNg0K
DQogICAgICAgfCAgfCAgKy0tcncgY2xvY2stcXVhbGl0eQ0KDQogICAgICAgfCAgfCAgfCAgKy0t
cncgY2xvY2stY2xhc3M/ICAgICAgICAgICAgICAgICAgdWludDgNCg0KICAgICAgIHwgIHwgIHwg
ICstLXJ3IGNsb2NrLWFjY3VyYWN5PyAgICAgICAgICAgICAgIHVpbnQ4DQoNCiAgICAgICB8ICB8
ICB8ICArLS1ydyBvZmZzZXQtc2NhbGVkLWxvZy12YXJpYW5jZT8gICB1aW50MTYNCg0KICAgICAg
IHwgIHwgICstLXJ3IHByaW9yaXR5MT8gICAgICAgIHVpbnQ4DQoNCiAgICAgICB8ICB8ICArLS1y
dyBwcmlvcml0eTI/ICAgICAgICB1aW50OA0KDQogICAgICAgfCAgfCAgKy0tcncgZG9tYWluLW51
bWJlcj8gICAgdWludDgNCg0KICAgICAgIHwgIHwgICstLXJ3IHNsYXZlLW9ubHk/ICAgICAgIGJv
b2xlYW4NCg0KICAgICAgIHwgICstLXJ3IGN1cnJlbnQtZHMNCg0KICAgICAgIHwgIHwgICstLXJ3
IHN0ZXBzLXJlbW92ZWQ/ICAgICAgIHVpbnQxNg0KDQogICAgICAgfCAgfCAgKy0tcncgb2Zmc2V0
LWZyb20tbWFzdGVyPyAgdGltZS1pbnRlcnZhbC10eXBlDQoNCiAgICAgICB8ICB8ICArLS1ydyBt
ZWFuLXBhdGgtZGVsYXk/ICAgICB0aW1lLWludGVydmFsLXR5cGUNCg0KICAgICAgIHwgICstLXJ3
IHBhcmVudC1kcw0KDQogICAgICAgfCAgfCAgKy0tcncgcGFyZW50LXBvcnQtaWRlbnRpdHkNCg0K
ICAgICAgIHwgIHwgIHwgICstLXJ3IGNsb2NrLWlkZW50aXR5PyAgIGNsb2NrLWlkZW50aXR5LXR5
cGUNCg0KICAgICAgIHwgIHwgIHwgICstLXJ3IHBvcnQtbnVtYmVyPyAgICAgIHVpbnQxNg0KDQog
ICAgICAgfCAgfCAgKy0tcncgcGFyZW50LXN0YXRzPyAgICAgICAgYm9vbGVhbg0KDQogICAgICAg
fCAgfCAgKy0tcncgb2JzZXJ2ZWQtcGFyZW50LW9mZnNldC1zY2FsZWQtbG9nLXZhcmlhbmNlPyB1
aW50MTYNCg0KICAgICAgIHwgIHwgICstLXJ3IG9ic2VydmVkLXBhcmVudC1jbG9jay1waGFzZS1j
aGFuZ2UtcmF0ZT8gICAgaW50MzINCg0KICAgICAgIHwgIHwgICstLXJ3IGdyYW5kbWFzdGVyLWlk
ZW50aXR5PyAgICAgICAgICAgICAgICAgICAgICAgYmluYXJ5DQoNCiAgICAgICB8ICB8ICArLS1y
dyBncmFuZG1hc3Rlci1jbG9jay1xdWFsaXR5DQoNCiAgICAgICB8ICB8ICB8ICArLS1ydyBjbG9j
ay1jbGFzcz8gICAgICAgICAgICAgICAgICB1aW50OA0KDQogICAgICAgfCAgfCAgfCAgKy0tcncg
Y2xvY2stYWNjdXJhY3k/ICAgICAgICAgICAgICAgdWludDgNCg0KICAgICAgIHwgIHwgIHwgICst
LXJ3IG9mZnNldC1zY2FsZWQtbG9nLXZhcmlhbmNlPyAgIHVpbnQxNg0KDQogICAgICAgfCAgfCAg
Ky0tcncgZ3JhbmRtYXN0ZXItcHJpb3JpdHkxPyAgICAgICAgICAgdWludDgNCg0KICAgICAgIHwg
IHwgICstLXJ3IGdyYW5kbWFzdGVyLXByaW9yaXR5Mj8gICAgICAgICAgIHVpbnQ4DQoNCiAgICAg
ICB8ICArLS1ydyB0aW1lLXByb3BlcnRpZXMtZHMNCg0KICAgICAgIHwgIHwgICstLXJ3IGN1cnJl
bnQtdXRjLW9mZnNldC12YWxpZD8gICBib29sZWFuDQoNCiAgICAgICB8ICB8ICArLS1ydyBjdXJy
ZW50LXV0Yy1vZmZzZXQ/ICAgICAgICAgaW50MTYNCg0KICAgICAgIHwgIHwgICstLXJ3IGxlYXA1
OT8gICAgICAgICAgICAgICAgICAgICBib29sZWFuDQoNCiAgICAgICB8ICB8ICArLS1ydyBsZWFw
NjE/ICAgICAgICAgICAgICAgICAgICAgYm9vbGVhbg0KDQogICAgICAgfCAgfCAgKy0tcncgdGlt
ZS10cmFjZWFibGU/ICAgICAgICAgICAgIGJvb2xlYW4NCg0KICAgICAgIHwgIHwgICstLXJ3IGZy
ZXF1ZW5jeS10cmFjZWFibGU/ICAgICAgICBib29sZWFuDQoNCiAgICAgICB8ICB8ICArLS1ydyBw
dHAtdGltZXNjYWxlPyAgICAgICAgICAgICAgYm9vbGVhbg0KDQogICAgICAgfCAgfCAgKy0tcncg
dGltZS1zb3VyY2U/ICAgICAgICAgICAgICAgIHVpbnQ4DQoNCiAgICAgICB8ICArLS1ydyBwb3J0
LWRzLWxpc3QqIFtwb3J0LW51bWJlcl0NCg0KICAgICAgIHwgICAgICstLXJ3IHBvcnQtbnVtYmVy
ICAgICAgICAtPiAuLi9wb3J0LWlkZW50aXR5L3BvcnQtbnVtYmVyDQoNCiAgICAgICB8ICAgICAr
LS1ydyBwb3J0LWlkZW50aXR5DQoNCiAgICAgICB8ICAgICB8ICArLS1ydyBjbG9jay1pZGVudGl0
eT8gICBjbG9jay1pZGVudGl0eS10eXBlDQoNCiAgICAgICB8ICAgICB8ICArLS1ydyBwb3J0LW51
bWJlcj8gICAgICB1aW50MTYNCg0KICAgICAgIHwgICAgICstLXJ3IHBvcnQtc3RhdGU/ICAgICAg
ICAgIHBvcnQtc3RhdGUtZW51bWVyYXRpb24NCg0KICAgICAgIHwgICAgICstLXJ3IHVuZGVybHlp
bmctaW50ZXJmYWNlPyBpZjppbnRlcmZhY2UtcmVmDQoNCiAgICAgICB8ICAgICArLS1ydyBsb2ct
bWluLWRlbGF5LXJlcS1pbnRlcnZhbD8gICAgaW50OA0KDQogICAgICAgfCAgICAgKy0tcncgcGVl
ci1tZWFuLXBhdGgtZGVsYXk/ICAgICAgICAgIHRpbWUtaW50ZXJ2YWwtdHlwZQ0KDQogICAgICAg
fCAgICAgKy0tcncgbG9nLWFubm91bmNlLWludGVydmFsPyAgICAgICAgIGludDgNCg0KICAgICAg
IHwgICAgICstLXJ3IGFubm91bmNlLXJlY2VpcHQtdGltZW91dD8gICAgICB1aW50OA0KDQogICAg
ICAgfCAgICAgKy0tcncgbG9nLXN5bmMtaW50ZXJ2YWw/ICAgICAgICAgICAgIGludDgNCg0KICAg
ICAgIHwgICAgICstLXJ3IGRlbGF5LW1lY2hhbmlzbT8gICAgIGRlbGF5LW1lY2hhbmlzbS1lbnVt
ZXJhdGlvbg0KDQogICAgICAgfCAgICAgKy0tcncgbG9nLW1pbi1wZGVsYXktcmVxLWludGVydmFs
PyAgIGludDgNCg0KICAgICAgIHwgICAgICstLXJ3IHZlcnNpb24tbnVtYmVyPyAgICAgICAgICAg
ICAgICB1aW50OA0KDQogICAgICAgKy0tcncgdHJhbnNwYXJlbnQtY2xvY2stZGVmYXVsdC1kcw0K
DQogICAgICAgfCAgKy0tcncgY2xvY2staWRlbnRpdHk/ICAgIGNsb2NrLWlkZW50aXR5LXR5cGUN
Cg0KICAgICAgIHwgICstLXJ3IG51bWJlci1wb3J0cz8gICAgICB1aW50MTYNCg0KICAgICAgIHwg
ICstLXJ3IGRlbGF5LW1lY2hhbmlzbT8gICBkZWxheS1tZWNoYW5pc20tZW51bWVyYXRpb24NCg0K
ICAgICAgIHwgICstLXJ3IHByaW1hcnktZG9tYWluPyAgICB1aW50OA0KDQogICAgICAgKy0tcncg
dHJhbnNwYXJlbnQtY2xvY2stcG9ydC1kcy1saXN0KiBbcG9ydC1udW1iZXJdDQoNCiAgICAgICAg
ICArLS1ydyBwb3J0LW51bWJlciAgICAgICAgICAgLT4gLi4vcG9ydC1pZGVudGl0eS9wb3J0LW51
bWJlcg0KDQogICAgICAgICAgKy0tcncgcG9ydC1pZGVudGl0eQ0KDQogICAgICAgICAgfCAgKy0t
cncgY2xvY2staWRlbnRpdHk/ICAgY2xvY2staWRlbnRpdHktdHlwZQ0KDQogICAgICAgICAgfCAg
Ky0tcncgcG9ydC1udW1iZXI/ICAgICAgdWludDE2DQoNCiAgICAgICAgICArLS1ydyBsb2ctbWlu
LXBkZWxheS1yZXEtaW50ZXJ2YWw/ICAgaW50OA0KDQogICAgICAgICAgKy0tcncgZmF1bHR5LWZs
YWc/ICAgICAgICAgICAgICAgICAgIGJvb2xlYW4NCg0KICAgICAgICAgICstLXJ3IHBlZXItbWVh
bi1wYXRoLWRlbGF5PyAgICAgICAgIHRpbWUtaW50ZXJ2YWwtdHlwZQ0KDQoNCg0KSSBhZ3JlZSwg
YXNzaWdubWVudCBhbmQgY29tcGFyaXNvbiBjYW4gc3RpbGwgYmUgZG9uZSBvbiBjbG9jay1pZGVu
dGl0eSBhbmQgcG9ydC1udW1iZXIgZGlyZWN0bHkgKHdpdGhvdXQgYSBwb3J0SWRlbnRpdHkgY29u
c3RydWN0KSAuIEJ1dCBwZW9wbGUgd2hvIGFyZSBmYW1pbGlhciB3aXRoIDE1ODgtMjAwOCBtYXkg
cXVlc3Rpb24gd2hlcmUgcG9ydElkZW50aXR5IGlzIGdvbmUuDQoNCg0KDQozLiBJIHRoaW5rIGxl
YWZyZWYgaXMgYSB2ZXJ5IGdlbmVyYWwgc2VtYW50aWNzIHRoaW5nIGluIFlBTkcgbGFuZ3VhZ2Us
IGlmIGFueSB0b29scyBoYXZlIHByb2JsZW0gd2l0aCB0aGlzIGZlYXR1cmUsIG1heWJlIHdlIG5l
ZWQgdG8gY29udGFjdCB3aXRoIHRoZSB0b29s4oCZcyBkZXZlbG9wZXIgdG8gc3VwcG9ydCBpdC4N
Cg0KDQoNCkZpbmFsbHksIG1vcmUgaW5wdXRzIGZyb20gdGhlIFdHIGFyZSB3ZWxjb21lLg0KDQoN
Cg0KVGhhbmtzIGFnYWluLA0KDQpZdWFubG9uZw0KDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVz
c2FnZS0tLS0tDQpGcm9tOiBUSUNUT0MgW21haWx0bzp0aWN0b2MtYm91bmNlc0BpZXRmLm9yZ10g
T24gQmVoYWxmIE9mIFJvZG5leSBDdW1taW5ncw0KU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIg
MjcsIDIwMTcgMToyNCBBTQ0KVG86IHRpY3RvY0BpZXRmLm9yZzxtYWlsdG86dGljdG9jQGlldGYu
b3JnPg0KU3ViamVjdDogUmU6IFtUSUNUT0NdIGRyYWZ0LWlldGYtdGljdG9jLTE1ODh2Mi15YW5n
LTA1IC0gQ29uY2VybiBvdmVyIHBvcnQgaWRlbnRpZmllcg0KDQoNCg0KVGhhbmtzIFNlYW4sDQoN
Cg0KDQpSZWdhcmRpbmcgeW91ciBvdGhlciBjb21tZW50IG9uIFRMRC4uLiBJIGFncmVlLg0KDQoN
Cg0KUmVnYXJkaW5nIHRoZSBjb21tZW50IGJlbG93IG9uIHBvcnQtaWRlbnRpdHksIEkgYWdyZWUg
dGhhdCB3ZSBuZWVkIHRvIGRvIGl0IGZvciBwcmFjdGljYWwgcmVhc29ucy4NCg0KDQoNCkluIDE1
ODgtMjAwOCwgdGhlcmUgaXMgYSBkaXN0aW5jdCBkYXRhc2V0IG1lbWJlciBmb3IgcG9ydERTLnBv
cnRJZGVudGl0eSwgd2hpY2ggNS4zLjUgc3BlY2lmaWVzIGFzIHVzaW5nIHR5cGUgUG9ydElkZW50
aXR5Og0KDQogIHN0cnVjdCBQb3J0SWRlbnRpdHkgew0KDQogICAgQ2xvY2tJZGVudGl0eSBjbG9j
a0lkZW50aXR5Ow0KDQogICAgVUludGVnZXIgcG9ydE51bWJlcjsNCg0KICB9DQoNCg0KDQpJZiB3
ZSBpbnRlcnByZXQgdGhlIDE1ODgtMjAwOCBkYXRhc2V0cyBhcyBhbiBpbmZvcm1hdGlvbiBtb2Rl
bCwgYW5kIGFwcGx5IHRoYXQgYXMgZGlyZWN0bHkgYXMgcG9zc2libGUgdG8gYSBZQU5HIGRhdGEg
bW9kZWwsIHBvcnREUy5wb3J0SWRlbnRpdHkgaXMgYSBjb250YWluZXIsIHdoaWNoIGlzIHdoYXQg
d2UgaGF2ZSBzbyBmYXIuIFRoYXQgaW50cm9kdWNlcyBhIGNoYWxsZW5nZSwgYmVjYXVzZSB3ZSB3
YW50IHRvIHVzZSBwb3J0RFMucG9ydElkZW50aXR5LnBvcnROdW1iZXIgYXMgdGhlIGtleSB0byB0
aGUgbGlzdCBvZiBwb3J0RFMncy4gV2Ugc29sdmVkIHRoYXQgY2hhbGxlbmdlIHdpdGggYSBsZWFm
cmVmLCBidXQgSSdkIGFncmVlIHRoYXQgaXMgdWdseS4NCg0KDQoNCllvdXIgcHJvcG9zYWwgY2hh
bmdlcyBwb3J0RFMucG9ydElkZW50aXR5IGZyb20gYSBjb250YWluZXIgdG8gYSBncm91cGluZywg
c28gdGhhdCBpdCBwb3J0RFMucG9ydElkZW50aXR5LnBvcnROdW1iZXIgY2FuIGJlIHVzZWQgYXMg
dGhlIGtleSB3aXRob3V0IGEgbGVhZnJlZi4NCg0KDQoNClRoZSBkb3duc2lkZSBpcyB0aGF0IGlm
L3doZW4gYSBZQU5HIG1hbmFnZW1lbnQgY2xpZW50IHRyaWVzIHRvICJnZXQiIHBvcnREUy5wb3J0
SWRlbnRpdHksIGl0IGRvZXNuJ3Qgd29yay4uLiB0aGVyZSBpcyBubyBwb3J0SWRlbnRpdHkgdG8g
Z2V0Lg0KDQoNCg0KUGVyc29uYWxseSwgSSB0aGluayB0aGF0IGRvd25zaWRlIGlzIHdvcnRoIGl0
LiBPbmUgY2FuIGFyZ3VlIHRoYXQgeW91ciBwcm9wb3NhbCBzdGlsbCBjb25mb3JtcyB0byB0aGUg
MTU4OC0yMDA4IGluZm9ybWF0aW9uIG1vZGVsIGZvciBtYW5hZ2VtZW50LCBpbiB0aGF0IHBvcnRE
Uy5wb3J0SWRlbnRpdHkgc3RpbGwgImV4aXN0cyIgaW4gYSBtYW5uZXIgdGhhdCBtYWtlcyBzZW5z
ZSBmb3IgWUFORy4NCg0KDQoNClJvZG5leQ0KDQoNCg0KDQoNCg0KDQpGcm9tOiBUSUNUT0MgW21h
aWx0bzp0aWN0b2MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNlYW4gQ29uZG9uDQoN
ClNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAyNiwgMjAxNyAxMDozOCBBTQ0KDQpUbzogdGljdG9j
QGlldGYub3JnPG1haWx0bzp0aWN0b2NAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFtUSUNUT0NdIGRy
YWZ0LWlldGYtdGljdG9jLTE1ODh2Mi15YW5nLTA1IC0gQ29uY2VybiBvdmVyIHBvcnQgaWRlbnRp
Zmllcg0KDQoNCg0KV2l0aCByZWZlcmVuY2UgdG8gIllBTkcgRGF0YSBNb2RlbCBmb3IgSUVFRSAx
NTg4djIiIGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z
QV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGlldGYtMkR0aWN0b2MtMkQxNTg4djItMkR5
YW5nLTJEMDUmZD1Ed01GQXcmYz1JXzBZd29LeTd6NUxNVFZkeU82WUNpRTJ1ekkxampaWnVJUGVs
Y1NqaXhBJnI9V0E3MXNmMm83RHc3Q2JZaEZ0MjREUGp0M2xKdXVwc3dXWWRuYm9LYlo4ayZtPWpL
SGN6Vk5MTi1LdVYySFJaa2JFWlkxU3psQ0RfQXp0a2FXU2NjcnFCSTgmcz1tc2g3QTdfT2dIWjFs
NjVEbjZfTGhpRElYa1hwRmVpTEdtS2JLeHNxWFd3JmU9DQoNCg0KDQpJIGhhdmUgYSBjb25jZXJu
IGFib3V0IHRoZSBzdHJ1Y3R1cmUgb2YgdGhlIFlBTkcsIGFuZCBob3cgdGhlIGxpc3RzIHBvcnQt
ZHMtbGlzdCBhbmQgdHJhbnNwYXJlbnQtY2xvY2stcG9ydC1kcy1saXN0IGFyZSBpbmRleGVkIHdp
dGggYSBsZWFmIHdoaWNoIGlzIGEgbGVhZnJlZi4NCg0KDQoNClRoZSBzdHJ1Y3R1cmUgc2VlbXMg
dW5uZWNlc3NhcmlseSBjb21wbGV4IC0gcG9ydC1udW1iZXIgaXMgcmVwcmVzZW50ZWQgYXMgYSBs
ZWFmIGRpcmVjdGx5IGJlbmVhdGggdGhlIGxpc3QgKHRvIGJlIHVzZWQgYXMga2V5KSBhbmQgYWdh
aW4gdW5kZXIgdGhlIHBvcnQtaWRlbnRpdHkgY29udGFpbmVyLiBJdCBpcyBzdHJ1Y3R1cmVkIGlu
IGEgd2F5IHRoYXQgSSBiZWxpZXZlIHdvdWxkIG1ha2UgaXQgZGlmZmljdWx0IHRvIHdvcmsgd2l0
aCBzb21lIFlBTkcgdG9vbHMgaW4gdGhlIG1hcmtldC4NCg0KDQoNClRoZSBwdXJwb3NlIG9mIHBv
cnQtaWRlbnRpdHkgY29udGFpbmVyIGlzIG5vdCBjbGVhciBmcm9tIHRoZSBkb2N1bWVudCAtIGl0
IHdvdWxkIGFjaGlldmUgdGhlIHNhbWUgcHVycG9zZSBpZiBpdCB3YXMgbGVmdCBvdXQgb2YgcG9y
dC1kcy1lbnRyeSBhbmQgdHJhbnNwYXJlbnQtY2xvY2stcG9ydC1kcy1lbnRyeSBhbmQgaW5zdGVh
ZCB0aGUgZ3JvdXBpbmcgcG9ydC1pZGVudGl0eS1ncm91cGluZyBpbmNsdWRlZCBkaXJlY3RseS4N
Cg0KDQoNClNlZSB0aGUgYXR0YWNoZWQgZmlsZXMgYXMgb3JpZ2luYWwsIGEgbW9kaWZpZWQgdmVy
c2lvbiBhbmQgYXMgYSBwYXRjaCBmaWxlLg0KDQoNCg0KU2VhbiBDb25kb24NCg0KPT09PT09PT09
PT09PT09PT09PT09PT0NCg0KU2VhbiBDb25kb24NCg0KU3lzdGVtICYgU29mdHdhcmUgQXJjaGl0
ZWN0DQoNCkZyZXF1ZW5jeSAmIFRpbWluZyBEaXZpc2lvbg0KDQpNaWNyb3NlbWkgSW5jLg0KDQpt
YWlsdG86c2Vhbi5jb25kb25AbWljcm9zZW1pLmNvbQ0KDQoNCg0KX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVElDVE9DIG1haWxpbmcgbGlzdA0KDQpU
SUNUT0NAaWV0Zi5vcmc8bWFpbHRvOlRJQ1RPQ0BpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90aWN0b2MNCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp
ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7
YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0
I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh
W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbWJyaWE7DQoJ
cGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5
OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0K
QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAg
MyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N
c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w
MDAxcHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCXRleHQtanVzdGlmeTppbnRlci1pZGVvZ3Jh
cGg7DQoJZm9udC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy
aWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5
Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs
IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv
bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0
LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiLnuq/mlofmnKwgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCglt
YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1h
cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ
Zm9udC1mYW1pbHk65a6L5L2TO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1z
b0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiLmibnm
s6jmoYbmlofmnKwgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7
DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCXRleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGg7DQoJ
Zm9udC1zaXplOjkuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K
c3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLnuq/mlofmnKwgQ2hhciI7DQoJbXNvLXN0eWxl
LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOue6r+aWh+acrDsNCglmb250LWZhbWlseTrl
rovkvZM7fQ0Kc3Bhbi5DaGFyMA0KCXttc28tc3R5bGUtbmFtZToi5om55rOo5qGG5paH5pysIENo
YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazrmibnms6jmoYbm
lofmnKw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLmNoYXIx
DQoJe21zby1zdHlsZS1uYW1lOmNoYXI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl
cmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs
eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7
fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z
aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7
DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x
DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGww
DQoJe21zby1saXN0LWlkOjE0MzU2MzI3ODg7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNTY3
NzAwNjY4O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206
MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1
bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt
LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp
ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl
bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0i
cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlNlYW4sPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk15
IHBlcnNvbmFsIG9waW5pb24gaXMgdGhhdCBpdCBjYW4gd29yaywgYnV0IEkgd291bGQgbGlrZSB0
byBhc2sgZm9yIG1vcmUgb3BpbmlvbnMgZnJvbSBvdXIgbmV0bW9kIGV4cGVydHM7KTxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5I
aSBuZXRtb2QgZXhwZXJ0cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkNvbnNpZGVyaW5n
IHRoZSBmb2xsb3dpbmcgc2FtcGxlIG1vZHVsZSwgbXktbGlzdCBpcyBhIGxpc3QsIGFuZCBpdCBu
ZWVkcyB0byB1c2UgYSBsZWFmIG1lbWJlciAmcXVvdDtwb3J0LW51bWJlciZxdW90OyBpbiBteS1w
b3J0LWNvbnRhaW5lciBhcyBhIGtleS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPldlIG5v
dyBoYXZlIDMgb3B0aW9uczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjEuIDxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7bGlzdCBteS1saXN0IHs8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyBrZXkgJnF1b3Q7cG9ydC1udW1i
ZXImcXVvdDs7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsg
bGVhZiBwb3J0LW51bWJlciB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHlwZSB1aW50MTY7PG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv
cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3
RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsg
Y29udGFpbmVyIG15LXBvcnQtY29udGFpbmVyIHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsZWFmIHBvcnQtbnVt
YmVyIHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0eXBlIHVpbnQxNjs8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyB9PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbGVhZiBvdGhlci1sZWFmIHs8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv
bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyAmbmJzcDsgLi4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6
IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi
PiZuYnNwOyB9PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5CdXQgdGhpcyBkb2VzIG5vdCB3
b3JrIGZvciB0aGVyZSBpcyBjb21waWxpbmcgZXJyb3IuPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0
OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4yLjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7IGxpc3QgbXktbGlzdCB7PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsga2V5ICZxdW90O3BvcnQtbnVt
YmVyJnF1b3Q7OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
IGxlYWYgcG9ydC1udW1iZXIgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGUgdWludDE2OzxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s
b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5
N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyBjb250YWluZXIgbXktcG9ydC1jb250YWluZXIgezxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IGxlYWYgcG9ydC1udW1iZXIgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IHR5cGUgbGVhZnJlZns8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyBwYXRoICZxdW90Oy4uLy4uL3BvcnQtbnVtYmVyJnF1b3Q7OzxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMx
RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgbGVhZiBvdGhlci1sZWFmIHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5
N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJz
cDsgLi4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyB9
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5PcHRpb24gMiBjYW4gcGFyc2UsIHRob3VnaCBs
ZWFmcmVmIGluIGEgc3ViLW1vZHVsZSBzZWVtcyBub3QgdmVyeSBuYXR1cmFsLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4zLjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7IGxpc3QgbXktbGlzdCB7PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsga2V5ICZxdW90O3BvcnQtbnVt
YmVyJnF1b3Q7OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
IGxlYWYgcG9ydC1udW1iZXIgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGUgbGVhZnJlZns8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv
bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyBwYXRoICZxdW90Oy4uL215LXBvcnQtY29udGFpbmVyL3BvcnQtbnVtYmVyJnF1
b3Q7OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZu
YnNwOyB9PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsgY29u
dGFpbmVyIG15LXBvcnQtY29udGFpbmVyIHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsZWFmIHBvcnQtbnVtYmVy
IHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0eXBlIHVpbnQxNjs8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv
bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgbGVhZiBvdGhlci1sZWFmIHs8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y
OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyAmbmJzcDsgLi4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFG
NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZu
YnNwOyB9PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv
bG9yOiMxRjQ5N0QiPk9wdGlvbiAzIGNhbiBhbHNvIHBhcnNlLCB0aG91Z2ggbGVhZnJlZiBzZWVt
cyBub3QgYSB2ZXJ5IG5hdHVyYWwga2V5LiBXaGF0IGlzIHlvdXIgZmF2b3JpdGUgb3B0aW9uPyBP
ciBkbyB5b3UgaGF2ZSBhbnkgYmV0dGVyIHNjaGVtZXM/PG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0
OTdEIj5Zb3VyIG9waW5pb25zIGFyZSB2ZXJ5IGltcG9ydGFudCBmb3Igb3VyIHJldmlzaW9uIG9m
IHRoaXMgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImNvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPll1
YW5sb25nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv
bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0
eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz
LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5
bGU9InRleHQtYWxpZ246bGVmdCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij4gU2VhbiBDb25kb24gW21haWx0bzpzZWFuLmNvbmRvbkBtaWNyb3NlbWkuY29tXQ0K
PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgU2VwdGVtYmVyIDI3LCAyMDE3IDc6MTEgUE08
YnI+DQo8Yj5Ubzo8L2I+IEppYW5neXVhbmxvbmc8YnI+DQo8Yj5DYzo8L2I+IHRpY3RvY0BpZXRm
Lm9yZzsgUm9kbmV5IEN1bW1pbmdzPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBkcmFmdC1pZXRm
LXRpY3RvYy0xNTg4djIteWFuZy0wNSAtIENvbmNlcm4gb3ZlciBwb3J0IGlkZW50aWZpZXI8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
YWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIGxhbmc9IkVOLVVTIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
YWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhhbmtzIGd1eXMgZm9yIHlvdXIgcmVz
cG9uc2VzLjxicj4NCjxicj4NCkkgYWNjZXB0IHlvdXIgcG9pbnRzIHRvIGtlZXAgdGhlIHN0cnVj
dHVyZSBhcyBhbGlnbmVkIHRvIHRoZSBJRUVFIDE1ODggc3RhbmRhcmQgYXMgcG9zc2libGUuDQo8
YnI+DQo8YnI+DQpPbmUgYWx0ZXJuYXRlIHN1Z2dlc3Rpb24gdGhhdCBJIHdvdWxkIG1ha2UsIGlz
IHRoYXQgdGhlIHBvcnQtbnVtYmVyIGN1cnJlbnRseSBkZWZpbmVkIGFzIGxlYWZyZWYgc2hvdWxk
IGJlIG1hZGUgdGhlIHJlYWwgYXR0cmlidXRlIChpLmUuIHVpbnQxNikgYW5kIHRoYXQgdGhlIHBv
cnQtbnVtYmVyIGluc2lkZSBwb3J0LWlkZW50aXR5IGNvbnRhaW5lciBzaG91bGQgYmUgbWFkZSBp
biB0byB0aGUgbGVhZiByZWYgKGFuZCBzZXQgdG8gbWFuZGF0b3J5DQogdHJ1ZSkuPGJyPg0KPGJy
Pg0KVGhlIHJlYXNvbiBJIHNheSB0aGlzIGlzIHRoYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xv
cjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
bzt0ZXh0LWFsaWduOmxlZnQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5YTUwgbW9kZWxzIGFyZSB1c3VhbGx5IG5hdmln
YXRlZCBhbmQgY29uc3RydWN0ZWQgcm9vdC10by1sZWFmLCBhbmQgdGhlIHdheSBpdCdzIHBvcnRy
YXllZCBhdCB0aGUgbW9tZW50IGlzIHRoYXQgcG9ydC1udW1iZXIgbGVhZnJlZiBwb2ludHMgdG8g
c29tZXRoaW5nIHRoYXQgbWF5IG5vdCBleGlzdCBhdCB0aGUgdGltZQ0KIGl0IGlzIGJlaW5nIGRl
ZmluZWQuIFRoaXMgbWFrZXMgaXQgZGlmZmljdWx0IHRvIGltcGxlbWVudC48bzpwPjwvbzpwPjwv
c3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1hbGlnbjps
ZWZ0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90OyI+QWxzbyBwb3J0LWlkZW50aXR5L3BvcnQtbnVtYmVyIGlzIG5vdCAmcXVv
dDttYW5kYXRvcnkgdHJ1ZSZxdW90OyBtZWFuaW5nIHRoYXQgaXQgY291bGQgYmUgbGVmdCBvdXQg
YWx0b2dldGhlci4gSXQncyBub3QgdmFsaWQgZm9yIGl0IHRvIGhhdmUgYSBkZWZhdWx0IHZhbHVl
IGVpdGhlciBzaW5jZSBldmVyeSBpdGVtIGluIHRoZSBsaXN0DQogd2lsbCBuZWVkIGEgZGlmZmVy
ZW50IGlkZW50aWZpZXIuPG86cD48L286cD48L3NwYW4+PC9saT48L29sPg0KPHA+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t
YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5XaXRoIHRoaXMgc3Vn
Z2VzdGlvbiB0aGUgc3RydWN0dXJlIHlvdSByZXF1aXJlIHdpdGggcG9ydC1pZGVudGl0eSBzdGls
bCBleGlzdHMsIGJ1dCBub3cgdGhlIGltcGxlbWVudGF0aW9uIGlzIG1vcmUgc3RyYWlnaHRmb3J3
YXJkLCBhbmQgdGhlIGNoYW5nZSB3aWxsIGJlIHRyYW5zcGFyZW50DQogdG8gYW4gZW5kIHVzZXIu
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5CZXN0IHJl
Z2FyZHMsIFNlYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo
b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPj09PT09PT09PT09
PT09PT09PT09PT09PGJyPg0KU2VhbiBDb25kb248YnI+DQpTeXN0ZW0gJmFtcDsgU29mdHdhcmUg
QXJjaGl0ZWN0PGJyPg0KRnJlcXVlbmN5ICZhbXA7IFRpbWluZyBEaXZpc2lvbjxicj4NCk1pY3Jv
c2VtaSBJbmMuPGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNlYW4uY29uZG9uQG1pY3Jvc2VtaS5jb20i
PnNlYW4uY29uZG9uQG1pY3Jvc2VtaS5jb208L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0ibWFy
Z2luLWJvdHRvbToxMi4wcHQ7dGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0
ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx
dW90Oztjb2xvcjpibGFjayI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50
ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBpZD0iZGl2UnBGMTE4MTE5Ij4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7dGV4dC1h
bGlnbjpsZWZ0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6YmxhY2siPg0KIEppYW5neXVhbmxvbmcgW2ppYW5neXVhbmxvbmdAaHVh
d2VpLmNvbV08YnI+DQo8Yj5TZW50OjwvYj4gMjcgU2VwdGVtYmVyIDIwMTcgMDg6MDU8YnI+DQo8
Yj5Ubzo8L2I+IFNlYW4gQ29uZG9uPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86dGlj
dG9jQGlldGYub3JnIj50aWN0b2NAaWV0Zi5vcmc8L2E+OyBSb2RuZXkgQ3VtbWluZ3M8YnI+DQo8
Yj5TdWJqZWN0OjwvYj4gUkU6IGRyYWZ0LWlldGYtdGljdG9jLTE1ODh2Mi15YW5nLTA1IC0gQ29u
Y2VybiBvdmVyIHBvcnQgaWRlbnRpZmllcjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7
LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9Im1h
cmdpbi1ib3R0b206MTIuMHB0O3RleHQtYWxpZ246bGVmdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbWJyaWEmcXVvdDssJnF1
b3Q7c2VyaWYmcXVvdDs7Y29sb3I6cmVkIj5FWFRFUk5BTCBFTUFJTDwvc3Bhbj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg
TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPkRlYXIgU2Vhbiw8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGFu
ayB5b3UgYSBsb3QgZm9yIGRpdmluZyBpbnRvIHRoZSB0ZWNobmljYWwgZGV0YWlscyBvZiB0aGlz
IG1vZHVsZS4gSnVzdCBhcyBSb2RuZXkgc2FpZCwgaXQgaXMgYSBjaGFsbGVuZ2Ugb2YgMTU4OCBp
bmZvIG1vZGVsIHRvIFlBTkcsIGFuZCB3ZSB1c2UgdGhlIGxlYWZyZWYgb2YgWUFORyB0byB3b3Jr
IGFyb3VuZCBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5JIHdvdWxkIGxpa2UgdG8g
cHJvdmlkZSBhIGxpdHRsZSBtb3JlIGJhY2tncm91bmRzIG9uIHRoZSB0cmFkZW9mZjo8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNr
Ij4xLiBJdCBzYXlzIGluIFNlYy4gNy41LjIuMSBpbiBJRUVFIDE1ODgtMjAwODogcG9ydElkZW50
aXR5IGlzIGEgbWVtYmVyIG9mIHRoZSBwb3J0RFMgZGF0YSBzZXQuIEEgcG9ydElkZW50aXR5IGNv
bnNpc3RzIG9mIHR3byBhdHRyaWJ1dGVzLCBhczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2si
PmZvbGxvd3M6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYW1icmlhIE1hdGgm
cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPuKOrzwvc3Bhbj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4gcG9ydElkZW50aXR5LmNsb2NrSWRlbnRpdHk8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbWJyaWEgTWF0aCZxdW90OywmcXVv
dDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+4o6vPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iY29sb3I6YmxhY2siPiBwb3J0SWRlbnRpdHkucG9ydE51bWJlcjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iY29sb3I6YmxhY2siPkZ1cnRoZXJtb3JlLCB0aGUgJnF1b3Q7cG9ydERTLnBvcnRJZGVudGl0
eSZxdW90OyBhdHRyaWJ1dGUgaXMgbWVudGlvbmVkIHF1aXRlIGEgZmV3IHRpbWVzIGluIDE1ODgt
MjAwOCwgZXNwZWNpYWxseSBpbiBUYWJsZSAxNyBhbmQgdW5kZXIgVGFibGUgNjEsIHdpdGggYSBo
aW50IHRoYXQgYXNzaWdubWVudCBhbmQgY29tcGFyaXNvbiBjYW4gYmUgZG9uZSBvbg0KIHRoaXMg
bWVtYmVyIGRpcmVjdGx5LCB0aHVzIGl0IHNlZW1zIHRvIG1lIHBvcnRJZGVudGl0eSBpcyBhbiBp
bXBvcnRhbnQgYW5kIHdlbGwgdW5kZXJzdG9vZCBjb25zdHJ1Y3QgaW4gdGhlIDE1ODggc3BlY2lm
aWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImNvbG9yOmJsYWNrIj4yLiBJZiB3ZSBjaGFuZ2UgcG9ydERTLnBvcnRJZGVudGl0eSBmcm9t
IGEgY29udGFpbmVyIHRvIGEgZ3JvdXBpbmcsIHRoZW4gdGhlcmUgaXMgbm8gcG9ydElkZW50aXR5
IGZvciBwb3J0RFMgYW5kIHRyYW5zcGFyZW50Y2xvY2tQb3J0RFMgaW4gdGhlIHJlc3VsdGluZyB0
cmVlIGRpYWdyYW06PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJjb2xvcjpibGFjayI+bW9kdWxlOiBpZXRmLXB0cC1kYXRhc2V0PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBpbnN0YW5jZS1s
aXN0KiBbaW5zdGFuY2UtbnVtYmVyXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw
OyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBpbnN0YW5jZS1udW1iZXImbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdWludDE2PG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi
bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGRlZmF1bHQtZHM8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5i
c3A7ICYjNDM7LS1ydyB0d28tc3RlcC1mbGFnPyZuYnNwOyZuYnNwOyZuYnNwOyBib29sZWFuPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZu
YnNwOyAmIzQzOy0tcncgY2xvY2staWRlbnRpdHk/Jm5ic3A7Jm5ic3A7IGNsb2NrLWlkZW50aXR5
LXR5cGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZu
YnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBudW1iZXItcG9ydHM/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IHVpbnQxNjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNw
OyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGNsb2NrLXF1YWxpdHk8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsg
JiM0MzstLXJ3IGNsb2NrLWNsYXNzPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyB1aW50ODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNw
OyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgY2xvY2stYWNjdXJhY3k/
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVpbnQ4PG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi
bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1y
dyBvZmZzZXQtc2NhbGVkLWxvZy12YXJpYW5jZT8mbmJzcDsmbmJzcDsgdWludDE2PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAm
IzQzOy0tcncgcHJpb3JpdHkxPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyB1aW50ODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNw
OyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IHByaW9yaXR5Mj8mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdWludDg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNr
Ij4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBkb21haW4tbnVt
YmVyPyZuYnNwOyZuYnNwOyZuYnNwOyB1aW50ODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2si
PiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IHNsYXZlLW9ubHk/
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJvb2xlYW48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgY3Vy
cmVudC1kczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyB8
Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IHN0ZXBzLXJlbW92ZWQ/Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVpbnQxNjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Ymxh
Y2siPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IG9mZnNldC1m
cm9tLW1hc3Rlcj8mbmJzcDsmbmJzcDsgdGltZS1pbnRlcnZhbC10eXBlPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0t
cncgbWVhbi1wYXRoLWRlbGF5PyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aW1lLWlu
dGVydmFsLXR5cGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJz
cDsgfCZuYnNwOyAmIzQzOy0tcncgcGFyZW50LWRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFj
ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCAmbmJzcDsmIzQzOy0tcncgcGFyZW50LXBv
cnQtaWRlbnRpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJz
cDsgfCZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGNsb2NrLWlkZW50aXR5PyZuYnNw
OyZuYnNwOyBjbG9jay1pZGVudGl0eS10eXBlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBwb3J0
LW51bWJlcj8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdWludDE2PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQz
Oy0tcncgcGFyZW50LXN0YXRzPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBib29sZWFuPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAm
IzQzOy0tcncgb2JzZXJ2ZWQtcGFyZW50LW9mZnNldC1zY2FsZWQtbG9nLXZhcmlhbmNlPyZuYnNw
OyZuYnNwOyB1aW50MTY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U
ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsm
bmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBvYnNlcnZlZC1wYXJlbnQtY2xvY2stcGhh
c2UtY2hhbmdlLXJhdGU/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGludDMyPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNw
OyAmIzQzOy0tcncgZ3JhbmRtYXN0ZXItaWRlbnRpdHk/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IGJpbmFyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZu
YnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGdyYW5kbWFzdGVyLWNsb2NrLXF1YWxpdHk8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8
Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGNsb2NrLWNsYXNzPyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1aW50ODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Ymxh
Y2siPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncg
Y2xvY2stYWNjdXJhY3k/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVpbnQ4PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyB8
Jm5ic3A7ICYjNDM7LS1ydyBvZmZzZXQtc2NhbGVkLWxvZy12YXJpYW5jZT8mbmJzcDsmbmJzcDsg
dWludDE2PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm
bmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgZ3JhbmRtYXN0ZXItcHJpb3JpdHkxPyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyB1aW50ODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZu
YnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGdyYW5kbWFzdGVyLXByaW9yaXR5
Mj8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdWludDg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs
YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgdGltZS1wcm9wZXJ0aWVz
LWRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz
cDsgfCZuYnNwOyAmIzQzOy0tcncgY3VycmVudC11dGMtb2Zmc2V0LXZhbGlkPyZuYnNwOyZuYnNw
OyBib29sZWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgY3VycmVudC11dGMtb2Zmc2V0PyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbnQxNjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0Mzst
LXJ3IGxlYXA1OT8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgYm9vbGVhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZu
YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGxlYXA2MT8mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Ym9vbGVhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyB8
Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IHRpbWUtdHJhY2VhYmxlPyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBi
b29sZWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm
bmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgZnJlcXVlbmN5LXRyYWNlYWJsZT8mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYm9vbGVhbjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s
b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IHB0
cC10aW1lc2NhbGU/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJvb2xlYW48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1y
dyB0aW1lLXNvdXJjZT8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdWludDg8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyAmIzQz
Oy0tcncgcG9ydC1kcy1saXN0KiBbcG9ydC1udW1iZXJdPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi
bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0Mzst
LXJ3IGNsb2NrLWlkZW50aXR5PyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjbG9j
ay1pZGVudGl0eS10eXBlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHBvcnQtbnVtYmVyJm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVp
bnQxNjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBwb3J0LXN0YXRlPyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwb3J0LXN0YXRlLWVu
dW1lcmF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHVuZGVybHlpbmctaW50ZXJmYWNl
PyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBp
ZjppbnRlcmZhY2UtcmVmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IGxvZy1taW4tZGVsYXkt
cmVxLWludGVydmFsPyZuYnNwOyZuYnNwOyZuYnNwOyBpbnQ4PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv
cjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0
MzstLXJ3IHBlZXItbWVhbi1wYXRoLWRlbGF5PyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aW1lLWludGVydmFsLXR5cGU8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyAmIzQzOy0tcncgbG9nLWFubm91bmNlLWludGVydmFsPyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbnQ4PG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi
bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0Mzst
LXJ3IGFubm91bmNlLXJlY2VpcHQtdGltZW91dD8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgdWludDg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsg
fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgbG9nLXN5bmMtaW50ZXJ2YWw/Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IGludDg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz
cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgZGVsYXktbWVjaGFu
aXNtPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZWxheS1tZWNoYW5pc20tZW51bWVyYXRp
b248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgbG9nLW1pbi1wZGVsYXktcmVxLWludGVydmFs
PyZuYnNwOyZuYnNwOyBpbnQ4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs
YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHZlcnNpb24tbnVt
YmVyPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1aW50ODxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgdHJhbnNwYXJlbnQt
Y2xvY2stZGVmYXVsdC1kczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNw
OyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBjbG9jay1pZGVudGl0eT8mbmJzcDsmbmJzcDsmbmJz
cDsgY2xvY2staWRlbnRpdHktdHlwZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw
OyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBudW1iZXItcG9ydHM/Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVpbnQxNjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZu
YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBkZWxheS1tZWNoYW5pc20/Jm5ic3A7
Jm5ic3A7IGRlbGF5LW1lY2hhbmlzbS1lbnVtZXJhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6
YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBwcmltYXJ5LWRvbWFp
bj8mbmJzcDsmbmJzcDsmbmJzcDsgdWludDg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4m
bmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHRyYW5zcGFyZW50LWNsb2NrLXBvcnQtZHMtbGlz
dCogW3BvcnQtbnVtYmVyXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgY2xvY2staWRlbnRpdHk/Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNsb2NrLWlkZW50aXR5LXR5cGU8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
JiM0MzstLXJ3IHBvcnQtbnVtYmVyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVpbnQxNjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2si
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgbG9nLW1pbi1w
ZGVsYXktcmVxLWludGVydmFsPyZuYnNwOyZuYnNwOyBpbnQ4PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv
cjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBm
YXVsdHktZmxhZz8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgYm9vbGVhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgcGVlci1tZWFuLXBhdGgtZGVsYXk/Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRpbWUt
aW50ZXJ2YWwtdHlwZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iY29sb3I6YmxhY2siPkluIGNvbnRyYXN0IHRvIHRoZSBvcmlnaW5hbCAxNTg4IFlB
TkcgdHJlZSBkaWFncmFtOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNw
OyBtb2R1bGU6IGlldGYtcHRwLWRhdGFzZXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IGluc3RhbmNlLWxp
c3QqIFtpbnN0YW5jZS1udW1iZXJdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGluc3RhbmNl
LW51bWJlciZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1aW50MTY8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu
YnNwOyAmIzQzOy0tcncgZGVmYXVsdC1kczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0Mzst
LXJ3IHR3by1zdGVwLWZsYWc/Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJvb2xlYW48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu
YnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBjbG9jay1pZGVudGl0eT8mbmJzcDsmbmJzcDsgY2xvY2st
aWRlbnRpdHktdHlwZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IG51bWJlci1w
b3J0cz8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdWludDE2PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv
cjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZu
YnNwOyAmIzQzOy0tcncgY2xvY2stcXVhbGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2si
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgfCZu
YnNwOyAmIzQzOy0tcncgY2xvY2stY2xhc3M/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IHVpbnQ4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYj
NDM7LS1ydyBjbG9jay1hY2N1cmFjeT8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdWludDg8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IG9mZnNldC1zY2FsZWQt
bG9nLXZhcmlhbmNlPyZuYnNwOyZuYnNwOyB1aW50MTY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs
YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7
ICYjNDM7LS1ydyBwcmlvcml0eTE/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IHVpbnQ4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgcHJpb3JpdHky
PyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1aW50ODxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGRvbWFpbi1udW1iZXI/Jm5ic3A7Jm5ic3A7Jm5i
c3A7IHVpbnQ4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgc2xhdmUtb25seT8m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYm9vbGVhbjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i
c3A7ICYjNDM7LS1ydyBjdXJyZW50LWRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0t
cncgc3RlcHMtcmVtb3ZlZD8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdWlu
dDE2PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgb2Zmc2V0LWZyb20tbWFzdGVy
PyZuYnNwOyB0aW1lLWludGVydmFsLXR5cGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7
LS1ydyBtZWFuLXBhdGgtZGVsYXk/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRpbWUtaW50ZXJ2
YWwtdHlwZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBwYXJlbnQtZHM8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu
YnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBwYXJlbnQtcG9ydC1pZGVudGl0eTxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i
c3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgY2xvY2staWRlbnRpdHk/Jm5ic3A7Jm5ic3A7
IGNsb2NrLWlkZW50aXR5LXR5cGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0
MzstLXJ3IHBvcnQtbnVtYmVyPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1aW50MTY8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBwYXJlbnQtc3RhdHM/Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJvb2xlYW48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw
OyB8Jm5ic3A7ICYjNDM7LS1ydyBvYnNlcnZlZC1wYXJlbnQtb2Zmc2V0LXNjYWxlZC1sb2ctdmFy
aWFuY2U/IHVpbnQxNjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZu
YnNwOyAmbmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IG9ic2VydmVk
LXBhcmVudC1jbG9jay1waGFzZS1jaGFuZ2UtcmF0ZT8mbmJzcDsmbmJzcDsmbmJzcDsgaW50MzI8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBncmFuZG1hc3Rlci1pZGVudGl0eT8m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgYmluYXJ5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0t
cncgZ3JhbmRtYXN0ZXItY2xvY2stcXVhbGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2si
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgfCZu
YnNwOyAmIzQzOy0tcncgY2xvY2stY2xhc3M/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IHVpbnQ4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYj
NDM7LS1ydyBjbG9jay1hY2N1cmFjeT8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdWludDg8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IG9mZnNldC1zY2FsZWQt
bG9nLXZhcmlhbmNlPyZuYnNwOyZuYnNwOyB1aW50MTY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs
YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7
ICYjNDM7LS1ydyBncmFuZG1hc3Rlci1wcmlvcml0eTE/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVpbnQ4PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz
cDsgfCZuYnNwOyAmIzQzOy0tcncgZ3JhbmRtYXN0ZXItcHJpb3JpdHkyPyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1aW50ODxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyB0aW1lLXByb3BlcnRpZXMtZHM8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw
OyB8Jm5ic3A7ICYjNDM7LS1ydyBjdXJyZW50LXV0Yy1vZmZzZXQtdmFsaWQ/Jm5ic3A7Jm5ic3A7
IGJvb2xlYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBjdXJyZW50LXV0Yy1v
ZmZzZXQ/Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2lu
dDE2PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgbGVhcDU5PyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBib29s
ZWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgbGVhcDYxPyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBib29s
ZWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgdGltZS10cmFjZWFibGU/Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IGJvb2xlYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBm
cmVxdWVuY3ktdHJhY2VhYmxlPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyBib29sZWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgcHRwLXRpbWVz
Y2FsZT8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYm9vbGVhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6
YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJz
cDsgJiM0MzstLXJ3IHRpbWUtc291cmNlPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyB1aW50ODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBwb3J0LWRzLWxpc3QqIFtwb3J0LW51
bWJlcl08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgcG9ydC1u
dW1iZXImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSZndDsgLi4v
cG9ydC1pZGVudGl0eS9wb3J0LW51bWJlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7ICYjNDM7LS1ydw0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93Ij5wb3J0LWlkZW50
aXR5PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0
MzstLXJ3IGNsb2NrLWlkZW50aXR5PyZuYnNwOyZuYnNwOyBjbG9jay1pZGVudGl0eS10eXBlPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgcG9ydC1u
dW1iZXI/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVpbnQxNjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBwb3J0LXN0YXRlPyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwb3J0LXN0YXRlLWVudW1l
cmF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHVuZGVy
bHlpbmctaW50ZXJmYWNlPyBpZjppbnRlcmZhY2UtcmVmPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi
bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgJiM0MzstLXJ3IGxvZy1taW4tZGVsYXktcmVxLWludGVydmFsPyZuYnNwOyZu
YnNwOyZuYnNwOyBpbnQ4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0Mzst
LXJ3IHBlZXItbWVhbi1wYXRoLWRlbGF5PyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aW1lLWludGVydmFsLXR5cGU8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgbG9nLWFubm91bmNlLWludGVydmFsPyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbnQ4PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IGFubm91bmNlLXJlY2VpcHQtdGlt
ZW91dD8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdWludDg8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgbG9nLXN5bmMtaW50ZXJ2YWw/Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IGludDg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncg
ZGVsYXktbWVjaGFuaXNtPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZWxheS1tZWNoYW5pc20t
ZW51bWVyYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncg
bG9nLW1pbi1wZGVsYXktcmVxLWludGVydmFsPyZuYnNwOyZuYnNwOyBpbnQ4PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHZlcnNpb24tbnVtYmVyPyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1aW50ODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Ymxh
Y2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgdHJhbnNw
YXJlbnQtY2xvY2stZGVmYXVsdC1kczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBjbG9jay1p
ZGVudGl0eT8mbmJzcDsmbmJzcDsmbmJzcDsgY2xvY2staWRlbnRpdHktdHlwZTxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8
Jm5ic3A7ICYjNDM7LS1ydyBudW1iZXItcG9ydHM/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IHVpbnQxNjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBkZWxheS1tZWNoYW5pc20/Jm5i
c3A7Jm5ic3A7IGRlbGF5LW1lY2hhbmlzbS1lbnVtZXJhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s
b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYj
NDM7LS1ydyBwcmltYXJ5LWRvbWFpbj8mbmJzcDsmbmJzcDsmbmJzcDsgdWludDg8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
JiM0MzstLXJ3IHRyYW5zcGFyZW50LWNsb2NrLXBvcnQtZHMtbGlzdCogW3BvcnQtbnVtYmVyXTxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgcG9ydC1udW1iZXImbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSZndDsg
Li4vcG9ydC1pZGVudGl0eS9wb3J0LW51bWJlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2si
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm
IzQzOy0tcncgPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93Ij4NCnBvcnQtaWRlbnRpdHk8
L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGNsb2Nr
LWlkZW50aXR5PyZuYnNwOyZuYnNwOyBjbG9jay1pZGVudGl0eS10eXBlPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IHBvcnQtbnVtYmVyPyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyB1aW50MTY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0Mzst
LXJ3IGxvZy1taW4tcGRlbGF5LXJlcS1pbnRlcnZhbD8mbmJzcDsmbmJzcDsgaW50ODxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgZmF1bHR5LWZsYWc/Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJvb2xlYW48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHBlZXItbWVhbi1wYXRoLWRlbGF5PyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aW1lLWludGVydmFsLXR5cGU8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y
OmJsYWNrIj5JIGFncmVlLCBhc3NpZ25tZW50IGFuZCBjb21wYXJpc29uIGNhbiBzdGlsbCBiZSBk
b25lIG9uIGNsb2NrLWlkZW50aXR5IGFuZCBwb3J0LW51bWJlciBkaXJlY3RseSAod2l0aG91dCBh
IHBvcnRJZGVudGl0eSBjb25zdHJ1Y3QpIC4gQnV0IHBlb3BsZSB3aG8gYXJlIGZhbWlsaWFyIHdp
dGggMTU4OC0yMDA4IG1heSBxdWVzdGlvbiB3aGVyZQ0KIHBvcnRJZGVudGl0eSBpcyBnb25lLjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6
YmxhY2siPjMuIEkgdGhpbmsgbGVhZnJlZiBpcyBhIHZlcnkgZ2VuZXJhbCBzZW1hbnRpY3MgdGhp
bmcgaW4gWUFORyBsYW5ndWFnZSwgaWYgYW55IHRvb2xzIGhhdmUgcHJvYmxlbSB3aXRoIHRoaXMg
ZmVhdHVyZSwgbWF5YmUgd2UgbmVlZCB0byBjb250YWN0IHdpdGggdGhlIHRvb2w8L3NwYW4+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
Oztjb2xvcjpibGFjayI+4oCZPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6
YmxhY2siPnMNCiBkZXZlbG9wZXIgdG8gc3VwcG9ydCBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y
OmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U
ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5GaW5hbGx5LCBtb3Jl
IGlucHV0cyBmcm9tIHRoZSBXRyBhcmUgd2VsY29tZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs
YWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGFua3MgYWdhaW4sPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+WXVhbmxvbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y
OmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U
ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZy
b206IFRJQ1RPQyBbPGEgaHJlZj0ibWFpbHRvOnRpY3RvYy1ib3VuY2VzQGlldGYub3JnIj5tYWls
dG86dGljdG9jLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgUm9kbmV5IEN1bW1p
bmdzPGJyPg0KU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMjcsIDIwMTcgMToyNCBBTTxicj4N
ClRvOiA8YSBocmVmPSJtYWlsdG86dGljdG9jQGlldGYub3JnIj50aWN0b2NAaWV0Zi5vcmc8L2E+
PGJyPg0KU3ViamVjdDogUmU6IFtUSUNUT0NdIGRyYWZ0LWlldGYtdGljdG9jLTE1ODh2Mi15YW5n
LTA1IC0gQ29uY2VybiBvdmVyIHBvcnQgaWRlbnRpZmllcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6
YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPlRoYW5rcyBTZWFuLDxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6
YmxhY2siPlJlZ2FyZGluZyB5b3VyIG90aGVyIGNvbW1lbnQgb24gVExELi4uIEkgYWdyZWUuPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi
bGFjayI+UmVnYXJkaW5nIHRoZSBjb21tZW50IGJlbG93IG9uIHBvcnQtaWRlbnRpdHksIEkgYWdy
ZWUgdGhhdCB3ZSBuZWVkIHRvIGRvIGl0IGZvciBwcmFjdGljYWwgcmVhc29ucy48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5J
biAxNTg4LTIwMDgsIHRoZXJlIGlzIGEgZGlzdGluY3QgZGF0YXNldCBtZW1iZXIgZm9yIHBvcnRE
Uy5wb3J0SWRlbnRpdHksIHdoaWNoIDUuMy41IHNwZWNpZmllcyBhcyB1c2luZyB0eXBlIFBvcnRJ
ZGVudGl0eTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgc3RydWN0IFBvcnRJ
ZGVudGl0eSB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
IENsb2NrSWRlbnRpdHkgY2xvY2tJZGVudGl0eTs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNr
Ij4mbmJzcDsmbmJzcDsmbmJzcDsgVUludGVnZXIgcG9ydE51bWJlcjs8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImNvbG9yOmJsYWNrIj4mbmJzcDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw
OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPklmIHdlIGludGVycHJldCB0aGUgMTU4OC0y
MDA4IGRhdGFzZXRzIGFzIGFuIGluZm9ybWF0aW9uIG1vZGVsLCBhbmQgYXBwbHkgdGhhdCBhcyBk
aXJlY3RseSBhcyBwb3NzaWJsZSB0byBhIFlBTkcgZGF0YSBtb2RlbCwgcG9ydERTLnBvcnRJZGVu
dGl0eSBpcyBhIGNvbnRhaW5lciwgd2hpY2ggaXMgd2hhdCB3ZSBoYXZlIHNvIGZhci4gVGhhdA0K
IGludHJvZHVjZXMgYSBjaGFsbGVuZ2UsIGJlY2F1c2Ugd2Ugd2FudCB0byB1c2UgcG9ydERTLnBv
cnRJZGVudGl0eS5wb3J0TnVtYmVyIGFzIHRoZSBrZXkgdG8gdGhlIGxpc3Qgb2YgcG9ydERTJ3Mu
IFdlIHNvbHZlZCB0aGF0IGNoYWxsZW5nZSB3aXRoIGEgbGVhZnJlZiwgYnV0IEknZCBhZ3JlZSB0
aGF0IGlzIHVnbHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJjb2xvcjpibGFjayI+WW91ciBwcm9wb3NhbCBjaGFuZ2VzIHBvcnREUy5wb3J0SWRl
bnRpdHkgZnJvbSBhIGNvbnRhaW5lciB0byBhIGdyb3VwaW5nLCBzbyB0aGF0IGl0IHBvcnREUy5w
b3J0SWRlbnRpdHkucG9ydE51bWJlciBjYW4gYmUgdXNlZCBhcyB0aGUga2V5IHdpdGhvdXQgYSBs
ZWFmcmVmLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iY29sb3I6YmxhY2siPlRoZSBkb3duc2lkZSBpcyB0aGF0IGlmL3doZW4gYSBZQU5HIG1hbmFn
ZW1lbnQgY2xpZW50IHRyaWVzIHRvICZxdW90O2dldCZxdW90OyBwb3J0RFMucG9ydElkZW50aXR5
LCBpdCBkb2Vzbid0IHdvcmsuLi4gdGhlcmUgaXMgbm8gcG9ydElkZW50aXR5IHRvIGdldC48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs
YWNrIj5QZXJzb25hbGx5LCBJIHRoaW5rIHRoYXQgZG93bnNpZGUgaXMgd29ydGggaXQuIE9uZSBj
YW4gYXJndWUgdGhhdCB5b3VyIHByb3Bvc2FsIHN0aWxsIGNvbmZvcm1zIHRvIHRoZSAxNTg4LTIw
MDggaW5mb3JtYXRpb24gbW9kZWwgZm9yIG1hbmFnZW1lbnQsIGluIHRoYXQgcG9ydERTLnBvcnRJ
ZGVudGl0eSBzdGlsbCAmcXVvdDtleGlzdHMmcXVvdDsgaW4gYQ0KIG1hbm5lciB0aGF0IG1ha2Vz
IHNlbnNlIGZvciBZQU5HLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPlJvZG5leTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Ymxh
Y2siPiZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi
bGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+RnJvbTogVElDVE9DIFs8
YSBocmVmPSJtYWlsdG86dGljdG9jLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48
c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+bWFpbHRv
OnRpY3RvYy1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT5dIE9uIEJlaGFsZiBPZiBTZWFuIENv
bmRvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPlNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJl
ciAyNiwgMjAxNyAxMDozOCBBTTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPlRvOiA8YSBo
cmVmPSJtYWlsdG86dGljdG9jQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQo8c3BhbiBzdHls
ZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+dGljdG9jQGlldGYub3Jn
PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5TdWJqZWN0OiBbVElDVE9D
XSBkcmFmdC1pZXRmLXRpY3RvYy0xNTg4djIteWFuZy0wNSAtIENvbmNlcm4gb3ZlciBwb3J0IGlk
ZW50aWZpZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImNvbG9yOmJsYWNrIj5XaXRoIHJlZmVyZW5jZSB0byAmcXVvdDtZQU5HIERhdGEgTW9kZWwg
Zm9yIElFRUUgMTU4OHYyJnF1b3Q7DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zw
b2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfZHJhZnQtMkRp
ZXRmLTJEdGljdG9jLTJEMTU4OHYyLTJEeWFuZy0yRDA1JmFtcDtkPUR3TUZBdyZhbXA7Yz1JXzBZ
d29LeTd6NUxNVFZkeU82WUNpRTJ1ekkxampaWnVJUGVsY1NqaXhBJmFtcDtyPVdBNzFzZjJvN0R3
N0NiWWhGdDI0RFBqdDNsSnV1cHN3V1lkbmJvS2JaOGsmYW1wO209aktIY3pWTkxOLUt1VjJIUlpr
YkVaWTFTemxDRF9BenRrYVdTY2NycUJJOCZhbXA7cz1tc2g3QTdfT2dIWjFsNjVEbjZfTGhpRElY
a1hwRmVpTEdtS2JLeHNxWFd3JmFtcDtlIiB0YXJnZXQ9Il9ibGFuayI+DQo8c3BhbiBzdHlsZT0i
Y29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly91cmxkZWZlbnNl
LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX2Ry
YWZ0LTJEaWV0Zi0yRHRpY3RvYy0yRDE1ODh2Mi0yRHlhbmctMkQwNSZhbXA7ZD1Ed01GQXcmYW1w
O2M9SV8wWXdvS3k3ejVMTVRWZHlPNllDaUUydXpJMWpqWlp1SVBlbGNTaml4QSZhbXA7cj1XQTcx
c2YybzdEdzdDYlloRnQyNERQanQzbEp1dXBzd1dZZG5ib0tiWjhrJmFtcDttPWpLSGN6Vk5MTi1L
dVYySFJaa2JFWlkxU3psQ0RfQXp0a2FXU2NjcnFCSTgmYW1wO3M9bXNoN0E3X09nSFoxbDY1RG42
X0xoaURJWGtYcEZlaUxHbUtiS3hzcVhXdyZhbXA7ZTwvc3Bhbj48L2E+PQ0KPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+SSBo
YXZlIGEgY29uY2VybiBhYm91dCB0aGUgc3RydWN0dXJlIG9mIHRoZSBZQU5HLCBhbmQgaG93IHRo
ZSBsaXN0cyBwb3J0LWRzLWxpc3QgYW5kIHRyYW5zcGFyZW50LWNsb2NrLXBvcnQtZHMtbGlzdCBh
cmUgaW5kZXhlZCB3aXRoIGEgbGVhZiB3aGljaCBpcyBhIGxlYWZyZWYuPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIHN0
cnVjdHVyZSBzZWVtcyB1bm5lY2Vzc2FyaWx5IGNvbXBsZXggLSBwb3J0LW51bWJlciBpcyByZXBy
ZXNlbnRlZCBhcyBhIGxlYWYgZGlyZWN0bHkgYmVuZWF0aCB0aGUgbGlzdCAodG8gYmUgdXNlZCBh
cyBrZXkpIGFuZCBhZ2FpbiB1bmRlciB0aGUgcG9ydC1pZGVudGl0eSBjb250YWluZXIuIEl0IGlz
IHN0cnVjdHVyZWQgaW4gYQ0KIHdheSB0aGF0IEkgYmVsaWV2ZSB3b3VsZCBtYWtlIGl0IGRpZmZp
Y3VsdCB0byB3b3JrIHdpdGggc29tZSBZQU5HIHRvb2xzIGluIHRoZSBtYXJrZXQuPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+
VGhlIHB1cnBvc2Ugb2YgcG9ydC1pZGVudGl0eSBjb250YWluZXIgaXMgbm90IGNsZWFyIGZyb20g
dGhlIGRvY3VtZW50IC0gaXQgd291bGQgYWNoaWV2ZSB0aGUgc2FtZSBwdXJwb3NlIGlmIGl0IHdh
cyBsZWZ0IG91dCBvZiBwb3J0LWRzLWVudHJ5IGFuZCB0cmFuc3BhcmVudC1jbG9jay1wb3J0LWRz
LWVudHJ5IGFuZCBpbnN0ZWFkIHRoZQ0KIGdyb3VwaW5nIHBvcnQtaWRlbnRpdHktZ3JvdXBpbmcg
aW5jbHVkZWQgZGlyZWN0bHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs
YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+U2VlIHRoZSBhdHRhY2hlZCBmaWxlcyBhcyBvcmln
aW5hbCwgYSBtb2RpZmllZCB2ZXJzaW9uIGFuZCBhcyBhIHBhdGNoIGZpbGUuPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+U2Vh
biBDb25kb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj49PT09PT09PT09PT09PT09PT09
PT09PTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPlNlYW4gQ29uZG9uPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJjb2xvcjpibGFjayI+U3lzdGVtICZhbXA7IFNvZnR3YXJlIEFyY2hpdGVjdDxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iY29sb3I6YmxhY2siPkZyZXF1ZW5jeSAmYW1wOyBUaW1pbmcgRGl2aXNpb248bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5NaWNyb3NlbWkgSW5jLjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Y29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpzZWFuLmNvbmRvbkBtaWNyb3NlbWkuY29tIiB0
YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0
aW9uOm5vbmUiPm1haWx0bzpzZWFuLmNvbmRvbkBtaWNyb3NlbWkuY29tPC9zcGFuPjwvYT48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs
YWNrIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPlRJQ1RPQyBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJtYWlsdG86VElDVE9DQGlldGYub3JnIiB0YXJnZXQ9
Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5v
bmUiPlRJQ1RPQ0BpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFj
ayI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90aWN0b2Mi
IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29y
YXRpb246bm9uZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90aWN0b2M8
L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_3B0A1BED22CAD649A1B3E97BE5DDD68BBB5CB62Edggeml507mbxchi_--


From nobody Thu Sep 28 06:19:29 2017
Return-Path: 
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 0F913133044; Thu, 28 Sep 2017 06:19:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.689
X-Spam-Level: 
X-Spam-Status: No, score=-4.689 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=-2.8, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mscc365.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 0-J3cAPecj7S; Thu, 28 Sep 2017 06:19:23 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0064.outbound.protection.outlook.com [104.47.32.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C134A132193; Thu, 28 Sep 2017 06:19:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mscc365.onmicrosoft.com; s=selector1-microsemi-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NQ8iWM117jr4Juh5JmGpd2XNwbcDRVz7uxzufHnb6Jw=; b=BabUZ8pvNPcSPBDi7Z/AhQlfqN9CFe9KqjsMRXL1nfs8s3mypEVBvLrpmPwNbff9ICfThtUxI3GI4zXQ3fE07o+ElMDbbSsWdzV1Ha+yw6auz6Ho9kXCveHYL2HDg2ZKdbvap0OwC2+6v4gF9zaHH11gg7fVjyTa8LyvtNYLy+w=
Received: from BLUPR0201CA0040.namprd02.prod.outlook.com (10.163.116.50) by BY2PR0201MB1496.namprd02.prod.outlook.com (10.163.153.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Thu, 28 Sep 2017 13:19:20 +0000
Received: from BL2FFO11FD030.protection.gbl (2a01:111:f400:7c09::121) by BLUPR0201CA0040.outlook.office365.com (2a01:111:e400:52e7::50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.56.11 via Frontend Transport; Thu, 28 Sep 2017 13:19:19 +0000
Authentication-Results: spf=pass (sender IP is 208.19.100.20) smtp.mailfrom=microsemi.com; huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=bestguesspass action=none header.from=microsemi.com;
Received-SPF: Pass (protection.outlook.com: domain of microsemi.com designates 208.19.100.20 as permitted sender) receiver=protection.outlook.com;  client-ip=208.19.100.20; helo=avsrvexchhts2.microsemi.net;
Received: from avsrvexchhts2.microsemi.net (208.19.100.20) by BL2FFO11FD030.mail.protection.outlook.com (10.173.161.40) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.20.56.11 via Frontend Transport; Thu, 28 Sep 2017 13:19:19 +0000
Received: from AVSRVEXCHMBX1.microsemi.net ([fe80::950f:17ba:a56d:40e6]) by avsrvexchhts2.microsemi.net ([::1]) with mapi id 14.03.0361.001; Thu, 28 Sep 2017 06:19:18 -0700
From: Sean Condon 
To: Jiangyuanlong , "netmod@ietf.org" 
CC: "tictoc@ietf.org" , Rodney Cummings 
Thread-Topic: draft-ietf-tictoc-1588v2-yang-05 - Concern over port identifier
Thread-Index: AdM20lxp4a4LJ64bREK66XJnd3gJawAF4nRwABKMRUAAEqGn9wA1hiAAAAHl76Y=
Date: Thu, 28 Sep 2017 13:19:17 +0000
Message-ID: <640F4C69F839A64C8949EF04FAAEE44679F2583E@avsrvexchmbx1.microsemi.net>
References: <640F4C69F839A64C8949EF04FAAEE44679F253DE@avsrvexchmbx1.microsemi.net> , <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5C9C01@dggeml507-mbx.china.huawei.com> <640F4C69F839A64C8949EF04FAAEE44679F25561@avsrvexchmbx1.microsemi.net>, <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5CB62E@dggeml507-mbx.china.huawei.com>
In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5CB62E@dggeml507-mbx.china.huawei.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.100.34.31]
Content-Type: multipart/alternative; boundary="_000_640F4C69F839A64C8949EF04FAAEE44679F2583Eavsrvexchmbx1mi_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:208.19.100.20; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(376002)(39860400002)(346002)(2980300002)(438002)(189002)(43784003)(51444003)(13464003)(199003)(377454003)(81166006)(53936002)(512874002)(53946003)(6306002)(7736002)(54896002)(6246003)(229853002)(93886005)(561944003)(9686003)(236005)(189998001)(104016004)(33656002)(49446005)(2501003)(4326008)(5890100001)(16200700003)(966005)(86362001)(69596002)(68736007)(6116002)(102836003)(53546010)(5660300001)(606006)(55846006)(2950100002)(316002)(16586007)(3846002)(97736004)(53416004)(7696004)(54906003)(5250100002)(110136005)(8676002)(81156014)(478600001)(345774005)(8936002)(76176999)(2900100001)(106466001)(84326002)(356003)(2906002)(2920100001)(50986999)(54356999)(230783001)(559001)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR0201MB1496; H:avsrvexchhts2.microsemi.net;  FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD030; 1:Ya2/Dd58/eX7w/v8S0mNSKB0sGdo6XlFvdnWsXK1Lya4UQymW1yrGErdMEXJKu3tjm7HL0UsS9J0QC/GoqylhaGMPgrqyex2+GgKAeYfvrDCbPTC2xlbxglRTjKb/dmO
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 49c55f96-2705-4b07-a895-08d5067386d1
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(8251501002)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:BY2PR0201MB1496; 
X-Microsoft-Exchange-Diagnostics: 1; BY2PR0201MB1496; 3:qGvi2SfXj8TS+5LrjX9qc8SnA0IEUI+kcvIOaeAGV/iYyRbU6YutpFcyBOY1cLcuXW/9Onvv6U7lBSMIZc7TT3j3gpLXZVjq5wnw8BsQaYIBBOQCqQilIgtl+DnkC1GfSWt64R/U7Royw+6N+BYPPeq+Lln18AF8r2gGqTPVZy2Qm/tsUpUXyM1FDT/PkD87+faAMStk2WD34212Rg5s91b+IVGHyaJ6pmu0P1PEj3Nt7N9hlITdzuYNXwcCFJdLlsLfs2CVgABtqw/lLYXI+pJN40mSO8d2kD2mJbw+8j7toAzUr7sgeA75XCkwmpCEBgkv4cCXDosndFRIA9Cz5Qe27oxIy1+LfPqCTGAPA3w=; 25:NfLRynIJVBtx3wFxO4Tpp/6qrX0041RcE2hHIshmJadvZ2j9sco9D+ZD2e/1jkc5ncU78rhf+h3QzZHJU4G3njnDZysmUeTYQkxGVunsrvJCNWyAasyvAx6YFBEJcm5yxYdIxoVM+cNatHzJBnW2tvwDq1KZucr6ZG+El8z3e25oxX0pEaOI4dUuXnjqphYcAXlCMrPlFLnNRc86yNhgjRJA1xd+roLwz8k9eHoOV87WSpOGefFVLWvPjFTp8YgZPS61W/WoxB/hY6k9PNyLa0g4KGbPfFZlBJ0BV5XcIa8Eg0yNfYh18RAWJH6KVIhOAA2T3L2ZYk5uJZDdsK4fqA==
X-MS-TrafficTypeDiagnostic: BY2PR0201MB1496:
X-Microsoft-Exchange-Diagnostics: 1; BY2PR0201MB1496; 31:BlySTzDJ/NjEjC9ivRj6P9OK1m7zyVjfdcTo4RMeauB0/5KzD0D3Xmd3tGNQ5F9//X23TG/VdTyO4op+0Ftp11Ayy7Rjf7o0Vn8hoHLgByXi8nPF8b+eRCDnJNGZc9SjpbW/nWGc+uRyymfihYQJvj57W//HmcR8XXsvmhULeYJm/bldvt3k6c9qKTxaHBvr/A6Ofq4tPihnVmk0+vi8tB3/7WHyBW2rYHtOQN8pXX8=; 20:iTZRxcYhVosX0Lt6LU6hIPPRvq+One7sutD4irKPh035VmA379dfN0LyeAdDMe4ZaugstuU/J87okzeXURr/AnQ0Xi6ac03OPEI2CAI7kRIT88EypWCz+Lnm6htCzPQp7rsu3LWfKhLf+zTVKlljnik4YCY1WklrzgTp66TaYMMbLcEp5nDK35vuKEkFEhyocG6Ulk0NTRk3srRmrLEfymcghpD7rfWegdldLMHv98wL9ZtDAWzpjz+eXc0o3TJjS5w9XvVZXdehzBDmmtY8R6FbwzGIFquesMVmqtNy5n/3u6Y/Zx9H4k2VGpUVv1/yGYFnUGwcGtua4YSr0NOtvANC4SGf6zi8E5uzR2eJneSPfdvyBqw5fL7Eyaraw2OfRRcLpgMZ/+WSDCJOz4lAlEoBKvm4fXxDGiBXz6SoXhloTqn8WdF8QvFBplqEh/9PQifoSwvTdQQ7kme46/oZvzsbJaTrOPS2ofVI3Ygczr2sjufesvAAFp+bn2umkRWX
X-Exchange-Antispam-Report-Test: UriScan:(10436049006162)(50582790962513)(72170198267865)(17755550239193); 
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93004095)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123555025)(20161123558100)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BY2PR0201MB1496; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BY2PR0201MB1496; 
X-Microsoft-Exchange-Diagnostics: 1; BY2PR0201MB1496; 4:A1NgPTFpIxcemaNoQ42lr8TAurO8RVbFAM+aEqnHYgPihQsyP8v5t2hUeYPXEw9/gy/BTqWxTQTORq6UacrXbOysaXtTSTmMxfm1FN4dTs7hWGIps+lXhI0RspbiOIoUAIpTOUe9ot91KKBagrz/eo3tmB+CiafofF9Ycp+pSmKm56X4/DfqI+lWoX4LyZuLu4LDX8MjI9RdKBH5s/5v1Wgf61F3fcl7djkNJgpMMQKvLCoEj6vUD+UiLQ+Q2x5QTJMVI/K4DVx8cZdjQMM0U7U+Ml9/g+I3mopYOfsrI4vJtfHLYVumGhglPIXdG6VaH4h18WqR2eRGFF+IwqbUqI9mQ0yQMpCiYZuAo9pJAk+Ze1mKrbwpsIhgishHP99EDHdYYcJf2aUn9B0xjeiJjw==
X-Forefront-PRVS: 0444EB1997
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR0201MB1496; 23:bA0mbW1jAMkkwtpftJ8wQzQ5pX8hxPh+r29WQ73?= =?us-ascii?Q?iqR6FVXLQeP7NgtiJw3t1O8SjGnC5SGuWHJjlQTpQKYEVOuyHQKtbB/xl5DQ?= =?us-ascii?Q?lh4b9YHVTJuq4xOaGh8g/i1XgLJf/WRj613tciMhwrvMHrMkMfqhJo6P9RVz?= =?us-ascii?Q?d/L6VIlfwUTPNxTPklBlJAtSqKnUfimr7wzR87oTOFHzfWY6ruYb7puzmcGH?= =?us-ascii?Q?Z+NwxajEXFUMQ7CH6CIMjuD8Li5dk9WsJ4foDo8BpN4aRcQzlNFN+F8z1xSg?= =?us-ascii?Q?opYzjS4mzygxOqFrGt6jMm5oj3numphJVUXk2iGqUyfoNZL06K0wswyzqtNr?= =?us-ascii?Q?FyMXJjAY4Aa9hvBH/X0ILL172zjm5BiHNAZas7DaIj0KkM831ykIZ+PHCwJJ?= =?us-ascii?Q?cTH+DZDhbs3vVxEGsC2GNnqSQWnshdDSTNvaAACuwjpkQGfjlZ0tGK9Y1CK/?= =?us-ascii?Q?CVHag2jHLTovWaJpsu+4M1cUgl7loWS0Ki23BZee9b6vTIceAMIkWeu4gndL?= =?us-ascii?Q?/nhzbORoPM7j8CqgC/RyZ9cqelktyVEb7EpKMHA0Csr7MHcSxO13fKgvEQYt?= =?us-ascii?Q?bhJdboWD1uWWdWaEfGNC0n3j+Xs/OnWgantE2E2uhBSaYCLqLwJu+sJsRdxk?= =?us-ascii?Q?b5vb8NzlvHijRf6LlTE6RZ7qNsZtnxU1cJsT4otQikDMRNVBK3YbwQkaVgZ6?= =?us-ascii?Q?yDkgDgAVorC8abKa69wjSyn6Lj5BHv5cGx788N5hRWcnuujeiBNELXm/dBIE?= =?us-ascii?Q?qzvUis7gOgTuwhKe8Q9AufJk+a8JY9BMY5useEBu1teBVWEO2A9NUm+hWWFN?= =?us-ascii?Q?/98SDeaHkL6l0d0UjhbifpA9uMUh6ZsZyvm3nMsvbSHZezBucxkYyuRi84Be?= =?us-ascii?Q?J0S8xxjVioq4EZU0IRKV0NMfruKOJVS0zHRlbXlUo1GbLV3SgMHBTmM6jG7C?= =?us-ascii?Q?UyQRjkwwNg96kgpgOnRuTKVmGlRX7kP+uQYv8SOP8sUKSLf3n577dSPlB4F5?= =?us-ascii?Q?nkNBGf4zLwDHg2FhiKr+2puwnU+hxgzPGHAcB4mylI4vo332AtemrEfdI4x9?= =?us-ascii?Q?zLrRh5y69oe7kgTo91WukXBRUlhk2YmkeJbEwJ0ojYZM1Ek2azNtY9lUqPTc?= =?us-ascii?Q?BUFwcL7YjCkUeJMHaf8SV56Pn6y5oI8Q6bmFdlfCim53VombVuHCjq73eTfL?= =?us-ascii?Q?pr89fG/y08Q2Jza1yUY3uWUMbRFuIoV++4RO43VVgVU5cWUD2Vq8GkYDiiL/?= =?us-ascii?Q?4jHzvS9j6tJxIF0tu7Z8Iy3EmlYnazKrSEUPe4NHU7NEpEGHi+vSlqwsgGUy?= =?us-ascii?Q?ETE8QzswsT4vro73PPDeAdPSWrEUFH1DzwG85jyFlU+D5zQVd7Ow5bwuP+A5?= =?us-ascii?Q?3crAZv9eat2m/hutJTBVPSqKON3kdV/ABJlNhi7aEA0PZLgUwzadj+uNxlnX?= =?us-ascii?Q?ublltrNbfsks39IcNdFvwvw8HBpdD7A0y3rAIDdcgPmyM9jA78eWG0pSetzs?= =?us-ascii?Q?DianGkSuhhaJUEgdJjgcTHFTSy1Sup5ax+l0KNaZW0Ekd0MhE08vViuIMEVz?= =?us-ascii?Q?/1YB8lh+WDO4BbAa7j00qKh70eNr+Dl+PACpuLLQ=3D?=
X-Microsoft-Exchange-Diagnostics: 1; BY2PR0201MB1496; 6:VS4DjbM2T1Qhfin0jkl2gFpePwLraLtuKz8KqTkvQ0qZRJGVJLmmYtPv6GPP8CIfF/2fNvDh0YWrlcMvNEvP1M7vUy9VPDm8YdfayWyJ5ojrjKdv4xkto82rGcnOS3kub2+6THaKeiPlDLJDwjgshDMa+k73XfPNSDzD31hFpYppk9qB4OY8Ck/C2tPhLFt0iSNya+/Zh6a7iWaTu2bNpDm0q6/pO7eRKoJTk1qGCKFxbdWUD+5WmWO+r2bIsJiexw+PPNNGdLLDHpiAGv+HlDbk43NkVQelt/cBxmNFuqiMlFlidXeV5cRhystYglqaO4hf+kyr+uLy8l75ee/qCg==; 5:jjwzAyyhEqNwYfn50MPVsxrSp5BbevXe6l6DTbFat0dBE9n6tKugKHH8F/G3Wr6rhxwFHfE7a3xHogTkTD1L2qwRtTaiMLckF27dm2r6j5i6PaoWWuSt6IWHMz1V4HQiIqZyfH285s3bp/ka7pnvcg==; 24:/dp1aKKm2uMs2ww3k8bPVBRvSddpJSoH8Wok2GsetXLGXfCxc1/V5h0ZEr+D+gAKPgRB7V3lCWROy6rC9YMicd/MSV+p9CqwDh+RE/JpZdg=; 7:nScn6wPEhhnzLr46uwdqDmKGAsHYquvBw00sYArAkHS0LaDyS5NmApvd/nR9oEus+cQ352uKEhXQGZMcUKqI8plOU/pUN8EDzcsz52WyBOWHYP/lSzhUETQWoAmlGPAY6kB0U3kynkQhriLGH24Kx3EL6FJp/uWkjiPWyw9d6eo19oECJSnMwALPgJUSvENQhjJC2BcoOIOfMR2h96j6biGMpxGI2ef5uPQv47Z5gIg=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: microsemi.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Sep 2017 13:19:19.1318 (UTC)
X-MS-Exchange-CrossTenant-Id: f267a5c8-86d8-4cc9-af71-1fd2c67c8fad
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f267a5c8-86d8-4cc9-af71-1fd2c67c8fad; Ip=[208.19.100.20];  Helo=[avsrvexchhts2.microsemi.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1496
Archived-At: 
Subject: Re: [netmod] draft-ietf-tictoc-1588v2-yang-05 - Concern over port identifier
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Sep 2017 13:19:28 -0000

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

VGhhbmsgeW91IGZvciB5b3VyIGluIGRlcHRoIGNvbnNpZGVyYXRpb24gb2YgdGhpcyBpc3N1ZS4g
U2Vhbg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IEppYW5neXVhbmxv
bmcgW2ppYW5neXVhbmxvbmdAaHVhd2VpLmNvbV0NClNlbnQ6IDI4IFNlcHRlbWJlciAyMDE3IDE0
OjExDQpUbzogU2VhbiBDb25kb247IG5ldG1vZEBpZXRmLm9yZw0KQ2M6IHRpY3RvY0BpZXRmLm9y
ZzsgUm9kbmV5IEN1bW1pbmdzDQpTdWJqZWN0OiBSRTogZHJhZnQtaWV0Zi10aWN0b2MtMTU4OHYy
LXlhbmctMDUgLSBDb25jZXJuIG92ZXIgcG9ydCBpZGVudGlmaWVyDQoNCkVYVEVSTkFMIEVNQUlM
DQoNClNlYW4sDQoNCk15IHBlcnNvbmFsIG9waW5pb24gaXMgdGhhdCBpdCBjYW4gd29yaywgYnV0
IEkgd291bGQgbGlrZSB0byBhc2sgZm9yIG1vcmUgb3BpbmlvbnMgZnJvbSBvdXIgbmV0bW9kIGV4
cGVydHM7KQ0KDQpIaSBuZXRtb2QgZXhwZXJ0cywNCkNvbnNpZGVyaW5nIHRoZSBmb2xsb3dpbmcg
c2FtcGxlIG1vZHVsZSwgbXktbGlzdCBpcyBhIGxpc3QsIGFuZCBpdCBuZWVkcyB0byB1c2UgYSBs
ZWFmIG1lbWJlciAicG9ydC1udW1iZXIiIGluIG15LXBvcnQtY29udGFpbmVyIGFzIGEga2V5Lg0K
V2Ugbm93IGhhdmUgMyBvcHRpb25zOg0KMS4NCiAgbGlzdCBteS1saXN0IHsNCiAgICBrZXkgInBv
cnQtbnVtYmVyIjsNCiAgICBsZWFmIHBvcnQtbnVtYmVyIHsNCiAgICAgICB0eXBlIHVpbnQxNjsN
CiAgICB9DQoNCiAgICBjb250YWluZXIgbXktcG9ydC1jb250YWluZXIgew0KICAgICAgICBsZWFm
IHBvcnQtbnVtYmVyIHsNCiAgICAgICAgICB0eXBlIHVpbnQxNjsNCiAgICAgICAgfQ0KICAgICAg
ICAgbGVhZiBvdGhlci1sZWFmIHsNCiAgICAgICAgICAgLi4uDQogICAgICAgICB9DQogICAgfQ0K
ICB9DQpCdXQgdGhpcyBkb2VzIG5vdCB3b3JrIGZvciB0aGVyZSBpcyBjb21waWxpbmcgZXJyb3Iu
DQoNCjIuDQogIGxpc3QgbXktbGlzdCB7DQogICAga2V5ICJwb3J0LW51bWJlciI7DQogICAgbGVh
ZiBwb3J0LW51bWJlciB7DQogICAgICAgdHlwZSB1aW50MTY7DQogICAgfQ0KICAgIGNvbnRhaW5l
ciBteS1wb3J0LWNvbnRhaW5lciB7DQogICAgICAgIGxlYWYgcG9ydC1udW1iZXIgew0KICAgICAg
ICAgICAgdHlwZSBsZWFmcmVmew0KICAgICAgICAgICAgICBwYXRoICIuLi8uLi9wb3J0LW51bWJl
ciI7DQogICAgICAgICAgICB9DQogICAgICAgIH0NCiAgICAgICAgIGxlYWYgb3RoZXItbGVhZiB7
DQogICAgICAgICAgIC4uLg0KICAgICAgICAgfQ0KICAgIH0NCiAgfQ0KT3B0aW9uIDIgY2FuIHBh
cnNlLCB0aG91Z2ggbGVhZnJlZiBpbiBhIHN1Yi1tb2R1bGUgc2VlbXMgbm90IHZlcnkgbmF0dXJh
bC4NCg0KMy4NCiAgbGlzdCBteS1saXN0IHsNCiAgICBrZXkgInBvcnQtbnVtYmVyIjsNCiAgICBs
ZWFmIHBvcnQtbnVtYmVyIHsNCiAgICAgICB0eXBlIGxlYWZyZWZ7DQogICAgICAgICAgcGF0aCAi
Li4vbXktcG9ydC1jb250YWluZXIvcG9ydC1udW1iZXIiOw0KICAgICAgIH0NCiAgICB9DQogICAg
Y29udGFpbmVyIG15LXBvcnQtY29udGFpbmVyIHsNCiAgICAgICAgbGVhZiBwb3J0LW51bWJlciB7
DQogICAgICAgICAgdHlwZSB1aW50MTY7DQogICAgICAgIH0NCiAgICAgICAgIGxlYWYgb3RoZXIt
bGVhZiB7DQogICAgICAgICAgIC4uLg0KICAgICAgICAgfQ0KICAgIH0NCiAgfQ0KDQpPcHRpb24g
MyBjYW4gYWxzbyBwYXJzZSwgdGhvdWdoIGxlYWZyZWYgc2VlbXMgbm90IGEgdmVyeSBuYXR1cmFs
IGtleS4gV2hhdCBpcyB5b3VyIGZhdm9yaXRlIG9wdGlvbj8gT3IgZG8geW91IGhhdmUgYW55IGJl
dHRlciBzY2hlbWVzPw0KWW91ciBvcGluaW9ucyBhcmUgdmVyeSBpbXBvcnRhbnQgZm9yIG91ciBy
ZXZpc2lvbiBvZiB0aGlzIGRyYWZ0Lg0KDQpUaGFua3MsDQpZdWFubG9uZw0KDQoNCkZyb206IFNl
YW4gQ29uZG9uIFttYWlsdG86c2Vhbi5jb25kb25AbWljcm9zZW1pLmNvbV0NClNlbnQ6IFdlZG5l
c2RheSwgU2VwdGVtYmVyIDI3LCAyMDE3IDc6MTEgUE0NClRvOiBKaWFuZ3l1YW5sb25nDQpDYzog
dGljdG9jQGlldGYub3JnOyBSb2RuZXkgQ3VtbWluZ3MNClN1YmplY3Q6IFJFOiBkcmFmdC1pZXRm
LXRpY3RvYy0xNTg4djIteWFuZy0wNSAtIENvbmNlcm4gb3ZlciBwb3J0IGlkZW50aWZpZXINCg0K
VGhhbmtzIGd1eXMgZm9yIHlvdXIgcmVzcG9uc2VzLg0KDQpJIGFjY2VwdCB5b3VyIHBvaW50cyB0
byBrZWVwIHRoZSBzdHJ1Y3R1cmUgYXMgYWxpZ25lZCB0byB0aGUgSUVFRSAxNTg4IHN0YW5kYXJk
IGFzIHBvc3NpYmxlLg0KDQpPbmUgYWx0ZXJuYXRlIHN1Z2dlc3Rpb24gdGhhdCBJIHdvdWxkIG1h
a2UsIGlzIHRoYXQgdGhlIHBvcnQtbnVtYmVyIGN1cnJlbnRseSBkZWZpbmVkIGFzIGxlYWZyZWYg
c2hvdWxkIGJlIG1hZGUgdGhlIHJlYWwgYXR0cmlidXRlIChpLmUuIHVpbnQxNikgYW5kIHRoYXQg
dGhlIHBvcnQtbnVtYmVyIGluc2lkZSBwb3J0LWlkZW50aXR5IGNvbnRhaW5lciBzaG91bGQgYmUg
bWFkZSBpbiB0byB0aGUgbGVhZiByZWYgKGFuZCBzZXQgdG8gbWFuZGF0b3J5IHRydWUpLg0KDQpU
aGUgcmVhc29uIEkgc2F5IHRoaXMgaXMgdGhhdA0KDQogIDEuICBYTUwgbW9kZWxzIGFyZSB1c3Vh
bGx5IG5hdmlnYXRlZCBhbmQgY29uc3RydWN0ZWQgcm9vdC10by1sZWFmLCBhbmQgdGhlIHdheSBp
dCdzIHBvcnRyYXllZCBhdCB0aGUgbW9tZW50IGlzIHRoYXQgcG9ydC1udW1iZXIgbGVhZnJlZiBw
b2ludHMgdG8gc29tZXRoaW5nIHRoYXQgbWF5IG5vdCBleGlzdCBhdCB0aGUgdGltZSBpdCBpcyBi
ZWluZyBkZWZpbmVkLiBUaGlzIG1ha2VzIGl0IGRpZmZpY3VsdCB0byBpbXBsZW1lbnQuDQogIDIu
ICBBbHNvIHBvcnQtaWRlbnRpdHkvcG9ydC1udW1iZXIgaXMgbm90ICJtYW5kYXRvcnkgdHJ1ZSIg
bWVhbmluZyB0aGF0IGl0IGNvdWxkIGJlIGxlZnQgb3V0IGFsdG9nZXRoZXIuIEl0J3Mgbm90IHZh
bGlkIGZvciBpdCB0byBoYXZlIGEgZGVmYXVsdCB2YWx1ZSBlaXRoZXIgc2luY2UgZXZlcnkgaXRl
bSBpbiB0aGUgbGlzdCB3aWxsIG5lZWQgYSBkaWZmZXJlbnQgaWRlbnRpZmllci4NCg0KV2l0aCB0
aGlzIHN1Z2dlc3Rpb24gdGhlIHN0cnVjdHVyZSB5b3UgcmVxdWlyZSB3aXRoIHBvcnQtaWRlbnRp
dHkgc3RpbGwgZXhpc3RzLCBidXQgbm93IHRoZSBpbXBsZW1lbnRhdGlvbiBpcyBtb3JlIHN0cmFp
Z2h0Zm9yd2FyZCwgYW5kIHRoZSBjaGFuZ2Ugd2lsbCBiZSB0cmFuc3BhcmVudCB0byBhbiBlbmQg
dXNlci4NCg0KDQpCZXN0IHJlZ2FyZHMsIFNlYW4NCj09PT09PT09PT09PT09PT09PT09PT09DQpT
ZWFuIENvbmRvbg0KU3lzdGVtICYgU29mdHdhcmUgQXJjaGl0ZWN0DQpGcmVxdWVuY3kgJiBUaW1p
bmcgRGl2aXNpb24NCk1pY3Jvc2VtaSBJbmMuDQpzZWFuLmNvbmRvbkBtaWNyb3NlbWkuY29tPG1h
aWx0bzpzZWFuLmNvbmRvbkBtaWNyb3NlbWkuY29tPg0KDQpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KRnJvbTogSmlhbmd5dWFubG9uZyBbamlhbmd5dWFubG9uZ0BodWF3ZWkuY29t
XQ0KU2VudDogMjcgU2VwdGVtYmVyIDIwMTcgMDg6MDUNClRvOiBTZWFuIENvbmRvbg0KQ2M6IHRp
Y3RvY0BpZXRmLm9yZzxtYWlsdG86dGljdG9jQGlldGYub3JnPjsgUm9kbmV5IEN1bW1pbmdzDQpT
dWJqZWN0OiBSRTogZHJhZnQtaWV0Zi10aWN0b2MtMTU4OHYyLXlhbmctMDUgLSBDb25jZXJuIG92
ZXIgcG9ydCBpZGVudGlmaWVyDQpFWFRFUk5BTCBFTUFJTA0KDQpEZWFyIFNlYW4sDQoNCg0KDQpU
aGFuayB5b3UgYSBsb3QgZm9yIGRpdmluZyBpbnRvIHRoZSB0ZWNobmljYWwgZGV0YWlscyBvZiB0
aGlzIG1vZHVsZS4gSnVzdCBhcyBSb2RuZXkgc2FpZCwgaXQgaXMgYSBjaGFsbGVuZ2Ugb2YgMTU4
OCBpbmZvIG1vZGVsIHRvIFlBTkcsIGFuZCB3ZSB1c2UgdGhlIGxlYWZyZWYgb2YgWUFORyB0byB3
b3JrIGFyb3VuZCBpdC4NCg0KSSB3b3VsZCBsaWtlIHRvIHByb3ZpZGUgYSBsaXR0bGUgbW9yZSBi
YWNrZ3JvdW5kcyBvbiB0aGUgdHJhZGVvZmY6DQoNCg0KDQoxLiBJdCBzYXlzIGluIFNlYy4gNy41
LjIuMSBpbiBJRUVFIDE1ODgtMjAwODogcG9ydElkZW50aXR5IGlzIGEgbWVtYmVyIG9mIHRoZSBw
b3J0RFMgZGF0YSBzZXQuIEEgcG9ydElkZW50aXR5IGNvbnNpc3RzIG9mIHR3byBhdHRyaWJ1dGVz
LCBhcw0KDQpmb2xsb3dzOg0KDQrijq8gcG9ydElkZW50aXR5LmNsb2NrSWRlbnRpdHkNCg0K4o6v
IHBvcnRJZGVudGl0eS5wb3J0TnVtYmVyDQoNCkZ1cnRoZXJtb3JlLCB0aGUgInBvcnREUy5wb3J0
SWRlbnRpdHkiIGF0dHJpYnV0ZSBpcyBtZW50aW9uZWQgcXVpdGUgYSBmZXcgdGltZXMgaW4gMTU4
OC0yMDA4LCBlc3BlY2lhbGx5IGluIFRhYmxlIDE3IGFuZCB1bmRlciBUYWJsZSA2MSwgd2l0aCBh
IGhpbnQgdGhhdCBhc3NpZ25tZW50IGFuZCBjb21wYXJpc29uIGNhbiBiZSBkb25lIG9uIHRoaXMg
bWVtYmVyIGRpcmVjdGx5LCB0aHVzIGl0IHNlZW1zIHRvIG1lIHBvcnRJZGVudGl0eSBpcyBhbiBp
bXBvcnRhbnQgYW5kIHdlbGwgdW5kZXJzdG9vZCBjb25zdHJ1Y3QgaW4gdGhlIDE1ODggc3BlY2lm
aWNhdGlvbi4NCg0KDQoNCjIuIElmIHdlIGNoYW5nZSBwb3J0RFMucG9ydElkZW50aXR5IGZyb20g
YSBjb250YWluZXIgdG8gYSBncm91cGluZywgdGhlbiB0aGVyZSBpcyBubyBwb3J0SWRlbnRpdHkg
Zm9yIHBvcnREUyBhbmQgdHJhbnNwYXJlbnRjbG9ja1BvcnREUyBpbiB0aGUgcmVzdWx0aW5nIHRy
ZWUgZGlhZ3JhbToNCg0KDQoNCm1vZHVsZTogaWV0Zi1wdHAtZGF0YXNldA0KDQogICAgKy0tcncg
aW5zdGFuY2UtbGlzdCogW2luc3RhbmNlLW51bWJlcl0NCg0KICAgIHwgICstLXJ3IGluc3RhbmNl
LW51bWJlciAgICAgICB1aW50MTYNCg0KICAgIHwgICstLXJ3IGRlZmF1bHQtZHMNCg0KICAgIHwg
IHwgICstLXJ3IHR3by1zdGVwLWZsYWc/ICAgIGJvb2xlYW4NCg0KICAgIHwgIHwgICstLXJ3IGNs
b2NrLWlkZW50aXR5PyAgIGNsb2NrLWlkZW50aXR5LXR5cGUNCg0KICAgIHwgIHwgICstLXJ3IG51
bWJlci1wb3J0cz8gICAgIHVpbnQxNg0KDQogICAgfCAgfCAgKy0tcncgY2xvY2stcXVhbGl0eQ0K
DQogICAgfCAgfCAgfCAgKy0tcncgY2xvY2stY2xhc3M/ICAgICAgICAgICAgICAgICAgdWludDgN
Cg0KICAgIHwgIHwgIHwgICstLXJ3IGNsb2NrLWFjY3VyYWN5PyAgICAgICAgICAgICAgIHVpbnQ4
DQoNCiAgICB8ICB8ICB8ICArLS1ydyBvZmZzZXQtc2NhbGVkLWxvZy12YXJpYW5jZT8gICB1aW50
MTYNCg0KICAgIHwgIHwgICstLXJ3IHByaW9yaXR5MT8gICAgICAgIHVpbnQ4DQoNCiAgICB8ICB8
ICArLS1ydyBwcmlvcml0eTI/ICAgICAgICB1aW50OA0KDQogICAgfCAgfCAgKy0tcncgZG9tYWlu
LW51bWJlcj8gICAgdWludDgNCg0KICAgIHwgIHwgICstLXJ3IHNsYXZlLW9ubHk/ICAgICAgIGJv
b2xlYW4NCg0KICAgIHwgICstLXJ3IGN1cnJlbnQtZHMNCg0KICAgIHwgIHwgICstLXJ3IHN0ZXBz
LXJlbW92ZWQ/ICAgICAgICB1aW50MTYNCg0KICAgIHwgIHwgICstLXJ3IG9mZnNldC1mcm9tLW1h
c3Rlcj8gICB0aW1lLWludGVydmFsLXR5cGUNCg0KICAgIHwgIHwgICstLXJ3IG1lYW4tcGF0aC1k
ZWxheT8gICAgICB0aW1lLWludGVydmFsLXR5cGUNCg0KICAgIHwgICstLXJ3IHBhcmVudC1kcw0K
DQogICAgfCAgfCAgKy0tcncgcGFyZW50LXBvcnQtaWRlbnRpdHkNCg0KICAgIHwgIHwgIHwgICst
LXJ3IGNsb2NrLWlkZW50aXR5PyAgIGNsb2NrLWlkZW50aXR5LXR5cGUNCg0KICAgIHwgIHwgIHwg
ICstLXJ3IHBvcnQtbnVtYmVyPyAgICAgIHVpbnQxNg0KDQogICAgfCAgfCAgKy0tcncgcGFyZW50
LXN0YXRzPyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJvb2xlYW4NCg0KICAgIHwg
IHwgICstLXJ3IG9ic2VydmVkLXBhcmVudC1vZmZzZXQtc2NhbGVkLWxvZy12YXJpYW5jZT8gICB1
aW50MTYNCg0KICAgIHwgIHwgICstLXJ3IG9ic2VydmVkLXBhcmVudC1jbG9jay1waGFzZS1jaGFu
Z2UtcmF0ZT8gICAgICBpbnQzMg0KDQogICAgfCAgfCAgKy0tcncgZ3JhbmRtYXN0ZXItaWRlbnRp
dHk/ICAgICAgICAgICAgICAgICAgICAgICAgIGJpbmFyeQ0KDQogICAgfCAgfCAgKy0tcncgZ3Jh
bmRtYXN0ZXItY2xvY2stcXVhbGl0eQ0KDQogICAgfCAgfCAgfCAgKy0tcncgY2xvY2stY2xhc3M/
ICAgICAgICAgICAgICAgICAgdWludDgNCg0KICAgIHwgIHwgIHwgICstLXJ3IGNsb2NrLWFjY3Vy
YWN5PyAgICAgICAgICAgICAgIHVpbnQ4DQoNCiAgICB8ICB8ICB8ICArLS1ydyBvZmZzZXQtc2Nh
bGVkLWxvZy12YXJpYW5jZT8gICB1aW50MTYNCg0KICAgIHwgIHwgICstLXJ3IGdyYW5kbWFzdGVy
LXByaW9yaXR5MT8gICAgICAgICAgICAgICAgICAgICAgICB1aW50OA0KDQogICAgfCAgfCAgKy0t
cncgZ3JhbmRtYXN0ZXItcHJpb3JpdHkyPyAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQ4DQoN
CiAgICB8ICArLS1ydyB0aW1lLXByb3BlcnRpZXMtZHMNCg0KICAgIHwgIHwgICstLXJ3IGN1cnJl
bnQtdXRjLW9mZnNldC12YWxpZD8gICBib29sZWFuDQoNCiAgICB8ICB8ICArLS1ydyBjdXJyZW50
LXV0Yy1vZmZzZXQ/ICAgICAgICAgaW50MTYNCg0KICAgIHwgIHwgICstLXJ3IGxlYXA1OT8gICAg
ICAgICAgICAgICAgICAgICBib29sZWFuDQoNCiAgICB8ICB8ICArLS1ydyBsZWFwNjE/ICAgICAg
ICAgICAgICAgICAgICAgYm9vbGVhbg0KDQogICAgfCAgfCAgKy0tcncgdGltZS10cmFjZWFibGU/
ICAgICAgICAgICAgIGJvb2xlYW4NCg0KICAgIHwgIHwgICstLXJ3IGZyZXF1ZW5jeS10cmFjZWFi
bGU/ICAgICAgICBib29sZWFuDQoNCiAgICB8ICB8ICArLS1ydyBwdHAtdGltZXNjYWxlPyAgICAg
ICAgICAgICAgYm9vbGVhbg0KDQogICAgfCAgfCAgKy0tcncgdGltZS1zb3VyY2U/ICAgICAgICAg
ICAgICAgIHVpbnQ4DQoNCiAgICB8ICArLS1ydyBwb3J0LWRzLWxpc3QqIFtwb3J0LW51bWJlcl0N
Cg0KICAgIHwgICAgICstLXJ3IGNsb2NrLWlkZW50aXR5PyAgICAgICAgICAgICAgICBjbG9jay1p
ZGVudGl0eS10eXBlDQoNCiAgICB8ICAgICArLS1ydyBwb3J0LW51bWJlciAgICAgICAgICAgICAg
ICAgICAgdWludDE2DQoNCiAgICB8ICAgICArLS1ydyBwb3J0LXN0YXRlPyAgICAgICAgICAgICAg
ICAgICAgcG9ydC1zdGF0ZS1lbnVtZXJhdGlvbg0KDQogICAgfCAgICAgKy0tcncgdW5kZXJseWlu
Zy1pbnRlcmZhY2U/ICAgICAgICAgIGlmOmludGVyZmFjZS1yZWYNCg0KICAgIHwgICAgICstLXJ3
IGxvZy1taW4tZGVsYXktcmVxLWludGVydmFsPyAgICBpbnQ4DQoNCiAgICB8ICAgICArLS1ydyBw
ZWVyLW1lYW4tcGF0aC1kZWxheT8gICAgICAgICAgdGltZS1pbnRlcnZhbC10eXBlDQoNCiAgICB8
ICAgICArLS1ydyBsb2ctYW5ub3VuY2UtaW50ZXJ2YWw/ICAgICAgICAgaW50OA0KDQogICAgfCAg
ICAgKy0tcncgYW5ub3VuY2UtcmVjZWlwdC10aW1lb3V0PyAgICAgIHVpbnQ4DQoNCiAgICB8ICAg
ICArLS1ydyBsb2ctc3luYy1pbnRlcnZhbD8gICAgICAgICAgICAgaW50OA0KDQogICAgfCAgICAg
Ky0tcncgZGVsYXktbWVjaGFuaXNtPyAgICAgICAgICAgICAgIGRlbGF5LW1lY2hhbmlzbS1lbnVt
ZXJhdGlvbg0KDQogICAgfCAgICAgKy0tcncgbG9nLW1pbi1wZGVsYXktcmVxLWludGVydmFsPyAg
IGludDgNCg0KICAgIHwgICAgICstLXJ3IHZlcnNpb24tbnVtYmVyPyAgICAgICAgICAgICAgICB1
aW50OA0KDQogICAgKy0tcncgdHJhbnNwYXJlbnQtY2xvY2stZGVmYXVsdC1kcw0KDQogICAgfCAg
Ky0tcncgY2xvY2staWRlbnRpdHk/ICAgIGNsb2NrLWlkZW50aXR5LXR5cGUNCg0KICAgIHwgICst
LXJ3IG51bWJlci1wb3J0cz8gICAgICB1aW50MTYNCg0KICAgIHwgICstLXJ3IGRlbGF5LW1lY2hh
bmlzbT8gICBkZWxheS1tZWNoYW5pc20tZW51bWVyYXRpb24NCg0KICAgIHwgICstLXJ3IHByaW1h
cnktZG9tYWluPyAgICB1aW50OA0KDQogICAgKy0tcncgdHJhbnNwYXJlbnQtY2xvY2stcG9ydC1k
cy1saXN0KiBbcG9ydC1udW1iZXJdDQoNCiAgICAgICArLS1ydyBjbG9jay1pZGVudGl0eT8gICAg
ICAgICAgICAgICAgY2xvY2staWRlbnRpdHktdHlwZQ0KDQogICAgICAgKy0tcncgcG9ydC1udW1i
ZXIgICAgICAgICAgICAgICAgICAgIHVpbnQxNg0KDQogICAgICAgKy0tcncgbG9nLW1pbi1wZGVs
YXktcmVxLWludGVydmFsPyAgIGludDgNCg0KICAgICAgICstLXJ3IGZhdWx0eS1mbGFnPyAgICAg
ICAgICAgICAgICAgICBib29sZWFuDQoNCiAgICAgICArLS1ydyBwZWVyLW1lYW4tcGF0aC1kZWxh
eT8gICAgICAgICAgdGltZS1pbnRlcnZhbC10eXBlDQoNCg0KDQpJbiBjb250cmFzdCB0byB0aGUg
b3JpZ2luYWwgMTU4OCBZQU5HIHRyZWUgZGlhZ3JhbToNCg0KICAgbW9kdWxlOiBpZXRmLXB0cC1k
YXRhc2V0DQoNCiAgICAgICArLS1ydyBpbnN0YW5jZS1saXN0KiBbaW5zdGFuY2UtbnVtYmVyXQ0K
DQogICAgICAgfCAgKy0tcncgaW5zdGFuY2UtbnVtYmVyICAgICAgdWludDE2DQoNCiAgICAgICB8
ICArLS1ydyBkZWZhdWx0LWRzDQoNCiAgICAgICB8ICB8ICArLS1ydyB0d28tc3RlcC1mbGFnPyAg
ICBib29sZWFuDQoNCiAgICAgICB8ICB8ICArLS1ydyBjbG9jay1pZGVudGl0eT8gICBjbG9jay1p
ZGVudGl0eS10eXBlDQoNCiAgICAgICB8ICB8ICArLS1ydyBudW1iZXItcG9ydHM/ICAgICB1aW50
MTYNCg0KICAgICAgIHwgIHwgICstLXJ3IGNsb2NrLXF1YWxpdHkNCg0KICAgICAgIHwgIHwgIHwg
ICstLXJ3IGNsb2NrLWNsYXNzPyAgICAgICAgICAgICAgICAgIHVpbnQ4DQoNCiAgICAgICB8ICB8
ICB8ICArLS1ydyBjbG9jay1hY2N1cmFjeT8gICAgICAgICAgICAgICB1aW50OA0KDQogICAgICAg
fCAgfCAgfCAgKy0tcncgb2Zmc2V0LXNjYWxlZC1sb2ctdmFyaWFuY2U/ICAgdWludDE2DQoNCiAg
ICAgICB8ICB8ICArLS1ydyBwcmlvcml0eTE/ICAgICAgICB1aW50OA0KDQogICAgICAgfCAgfCAg
Ky0tcncgcHJpb3JpdHkyPyAgICAgICAgdWludDgNCg0KICAgICAgIHwgIHwgICstLXJ3IGRvbWFp
bi1udW1iZXI/ICAgIHVpbnQ4DQoNCiAgICAgICB8ICB8ICArLS1ydyBzbGF2ZS1vbmx5PyAgICAg
ICBib29sZWFuDQoNCiAgICAgICB8ICArLS1ydyBjdXJyZW50LWRzDQoNCiAgICAgICB8ICB8ICAr
LS1ydyBzdGVwcy1yZW1vdmVkPyAgICAgICB1aW50MTYNCg0KICAgICAgIHwgIHwgICstLXJ3IG9m
ZnNldC1mcm9tLW1hc3Rlcj8gIHRpbWUtaW50ZXJ2YWwtdHlwZQ0KDQogICAgICAgfCAgfCAgKy0t
cncgbWVhbi1wYXRoLWRlbGF5PyAgICAgdGltZS1pbnRlcnZhbC10eXBlDQoNCiAgICAgICB8ICAr
LS1ydyBwYXJlbnQtZHMNCg0KICAgICAgIHwgIHwgICstLXJ3IHBhcmVudC1wb3J0LWlkZW50aXR5
DQoNCiAgICAgICB8ICB8ICB8ICArLS1ydyBjbG9jay1pZGVudGl0eT8gICBjbG9jay1pZGVudGl0
eS10eXBlDQoNCiAgICAgICB8ICB8ICB8ICArLS1ydyBwb3J0LW51bWJlcj8gICAgICB1aW50MTYN
Cg0KICAgICAgIHwgIHwgICstLXJ3IHBhcmVudC1zdGF0cz8gICAgICAgIGJvb2xlYW4NCg0KICAg
ICAgIHwgIHwgICstLXJ3IG9ic2VydmVkLXBhcmVudC1vZmZzZXQtc2NhbGVkLWxvZy12YXJpYW5j
ZT8gdWludDE2DQoNCiAgICAgICB8ICB8ICArLS1ydyBvYnNlcnZlZC1wYXJlbnQtY2xvY2stcGhh
c2UtY2hhbmdlLXJhdGU/ICAgIGludDMyDQoNCiAgICAgICB8ICB8ICArLS1ydyBncmFuZG1hc3Rl
ci1pZGVudGl0eT8gICAgICAgICAgICAgICAgICAgICAgIGJpbmFyeQ0KDQogICAgICAgfCAgfCAg
Ky0tcncgZ3JhbmRtYXN0ZXItY2xvY2stcXVhbGl0eQ0KDQogICAgICAgfCAgfCAgfCAgKy0tcncg
Y2xvY2stY2xhc3M/ICAgICAgICAgICAgICAgICAgdWludDgNCg0KICAgICAgIHwgIHwgIHwgICst
LXJ3IGNsb2NrLWFjY3VyYWN5PyAgICAgICAgICAgICAgIHVpbnQ4DQoNCiAgICAgICB8ICB8ICB8
ICArLS1ydyBvZmZzZXQtc2NhbGVkLWxvZy12YXJpYW5jZT8gICB1aW50MTYNCg0KICAgICAgIHwg
IHwgICstLXJ3IGdyYW5kbWFzdGVyLXByaW9yaXR5MT8gICAgICAgICAgIHVpbnQ4DQoNCiAgICAg
ICB8ICB8ICArLS1ydyBncmFuZG1hc3Rlci1wcmlvcml0eTI/ICAgICAgICAgICB1aW50OA0KDQog
ICAgICAgfCAgKy0tcncgdGltZS1wcm9wZXJ0aWVzLWRzDQoNCiAgICAgICB8ICB8ICArLS1ydyBj
dXJyZW50LXV0Yy1vZmZzZXQtdmFsaWQ/ICAgYm9vbGVhbg0KDQogICAgICAgfCAgfCAgKy0tcncg
Y3VycmVudC11dGMtb2Zmc2V0PyAgICAgICAgIGludDE2DQoNCiAgICAgICB8ICB8ICArLS1ydyBs
ZWFwNTk/ICAgICAgICAgICAgICAgICAgICAgYm9vbGVhbg0KDQogICAgICAgfCAgfCAgKy0tcncg
bGVhcDYxPyAgICAgICAgICAgICAgICAgICAgIGJvb2xlYW4NCg0KICAgICAgIHwgIHwgICstLXJ3
IHRpbWUtdHJhY2VhYmxlPyAgICAgICAgICAgICBib29sZWFuDQoNCiAgICAgICB8ICB8ICArLS1y
dyBmcmVxdWVuY3ktdHJhY2VhYmxlPyAgICAgICAgYm9vbGVhbg0KDQogICAgICAgfCAgfCAgKy0t
cncgcHRwLXRpbWVzY2FsZT8gICAgICAgICAgICAgIGJvb2xlYW4NCg0KICAgICAgIHwgIHwgICst
LXJ3IHRpbWUtc291cmNlPyAgICAgICAgICAgICAgICB1aW50OA0KDQogICAgICAgfCAgKy0tcncg
cG9ydC1kcy1saXN0KiBbcG9ydC1udW1iZXJdDQoNCiAgICAgICB8ICAgICArLS1ydyBwb3J0LW51
bWJlciAgICAgICAgLT4gLi4vcG9ydC1pZGVudGl0eS9wb3J0LW51bWJlcg0KDQogICAgICAgfCAg
ICAgKy0tcncgcG9ydC1pZGVudGl0eQ0KDQogICAgICAgfCAgICAgfCAgKy0tcncgY2xvY2staWRl
bnRpdHk/ICAgY2xvY2staWRlbnRpdHktdHlwZQ0KDQogICAgICAgfCAgICAgfCAgKy0tcncgcG9y
dC1udW1iZXI/ICAgICAgdWludDE2DQoNCiAgICAgICB8ICAgICArLS1ydyBwb3J0LXN0YXRlPyAg
ICAgICAgICBwb3J0LXN0YXRlLWVudW1lcmF0aW9uDQoNCiAgICAgICB8ICAgICArLS1ydyB1bmRl
cmx5aW5nLWludGVyZmFjZT8gaWY6aW50ZXJmYWNlLXJlZg0KDQogICAgICAgfCAgICAgKy0tcncg
bG9nLW1pbi1kZWxheS1yZXEtaW50ZXJ2YWw/ICAgIGludDgNCg0KICAgICAgIHwgICAgICstLXJ3
IHBlZXItbWVhbi1wYXRoLWRlbGF5PyAgICAgICAgICB0aW1lLWludGVydmFsLXR5cGUNCg0KICAg
ICAgIHwgICAgICstLXJ3IGxvZy1hbm5vdW5jZS1pbnRlcnZhbD8gICAgICAgICBpbnQ4DQoNCiAg
ICAgICB8ICAgICArLS1ydyBhbm5vdW5jZS1yZWNlaXB0LXRpbWVvdXQ/ICAgICAgdWludDgNCg0K
ICAgICAgIHwgICAgICstLXJ3IGxvZy1zeW5jLWludGVydmFsPyAgICAgICAgICAgICBpbnQ4DQoN
CiAgICAgICB8ICAgICArLS1ydyBkZWxheS1tZWNoYW5pc20/ICAgICBkZWxheS1tZWNoYW5pc20t
ZW51bWVyYXRpb24NCg0KICAgICAgIHwgICAgICstLXJ3IGxvZy1taW4tcGRlbGF5LXJlcS1pbnRl
cnZhbD8gICBpbnQ4DQoNCiAgICAgICB8ICAgICArLS1ydyB2ZXJzaW9uLW51bWJlcj8gICAgICAg
ICAgICAgICAgdWludDgNCg0KICAgICAgICstLXJ3IHRyYW5zcGFyZW50LWNsb2NrLWRlZmF1bHQt
ZHMNCg0KICAgICAgIHwgICstLXJ3IGNsb2NrLWlkZW50aXR5PyAgICBjbG9jay1pZGVudGl0eS10
eXBlDQoNCiAgICAgICB8ICArLS1ydyBudW1iZXItcG9ydHM/ICAgICAgdWludDE2DQoNCiAgICAg
ICB8ICArLS1ydyBkZWxheS1tZWNoYW5pc20/ICAgZGVsYXktbWVjaGFuaXNtLWVudW1lcmF0aW9u
DQoNCiAgICAgICB8ICArLS1ydyBwcmltYXJ5LWRvbWFpbj8gICAgdWludDgNCg0KICAgICAgICst
LXJ3IHRyYW5zcGFyZW50LWNsb2NrLXBvcnQtZHMtbGlzdCogW3BvcnQtbnVtYmVyXQ0KDQogICAg
ICAgICAgKy0tcncgcG9ydC1udW1iZXIgICAgICAgICAgIC0+IC4uL3BvcnQtaWRlbnRpdHkvcG9y
dC1udW1iZXINCg0KICAgICAgICAgICstLXJ3IHBvcnQtaWRlbnRpdHkNCg0KICAgICAgICAgIHwg
ICstLXJ3IGNsb2NrLWlkZW50aXR5PyAgIGNsb2NrLWlkZW50aXR5LXR5cGUNCg0KICAgICAgICAg
IHwgICstLXJ3IHBvcnQtbnVtYmVyPyAgICAgIHVpbnQxNg0KDQogICAgICAgICAgKy0tcncgbG9n
LW1pbi1wZGVsYXktcmVxLWludGVydmFsPyAgIGludDgNCg0KICAgICAgICAgICstLXJ3IGZhdWx0
eS1mbGFnPyAgICAgICAgICAgICAgICAgICBib29sZWFuDQoNCiAgICAgICAgICArLS1ydyBwZWVy
LW1lYW4tcGF0aC1kZWxheT8gICAgICAgICB0aW1lLWludGVydmFsLXR5cGUNCg0KDQoNCkkgYWdy
ZWUsIGFzc2lnbm1lbnQgYW5kIGNvbXBhcmlzb24gY2FuIHN0aWxsIGJlIGRvbmUgb24gY2xvY2st
aWRlbnRpdHkgYW5kIHBvcnQtbnVtYmVyIGRpcmVjdGx5ICh3aXRob3V0IGEgcG9ydElkZW50aXR5
IGNvbnN0cnVjdCkgLiBCdXQgcGVvcGxlIHdobyBhcmUgZmFtaWxpYXIgd2l0aCAxNTg4LTIwMDgg
bWF5IHF1ZXN0aW9uIHdoZXJlIHBvcnRJZGVudGl0eSBpcyBnb25lLg0KDQoNCg0KMy4gSSB0aGlu
ayBsZWFmcmVmIGlzIGEgdmVyeSBnZW5lcmFsIHNlbWFudGljcyB0aGluZyBpbiBZQU5HIGxhbmd1
YWdlLCBpZiBhbnkgdG9vbHMgaGF2ZSBwcm9ibGVtIHdpdGggdGhpcyBmZWF0dXJlLCBtYXliZSB3
ZSBuZWVkIHRvIGNvbnRhY3Qgd2l0aCB0aGUgdG9vbOKAmXMgZGV2ZWxvcGVyIHRvIHN1cHBvcnQg
aXQuDQoNCg0KDQpGaW5hbGx5LCBtb3JlIGlucHV0cyBmcm9tIHRoZSBXRyBhcmUgd2VsY29tZS4N
Cg0KDQoNClRoYW5rcyBhZ2FpbiwNCg0KWXVhbmxvbmcNCg0KDQoNCg0KDQotLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLQ0KRnJvbTogVElDVE9DIFttYWlsdG86dGljdG9jLWJvdW5jZXNAaWV0Zi5v
cmddIE9uIEJlaGFsZiBPZiBSb2RuZXkgQ3VtbWluZ3MNClNlbnQ6IFdlZG5lc2RheSwgU2VwdGVt
YmVyIDI3LCAyMDE3IDE6MjQgQU0NClRvOiB0aWN0b2NAaWV0Zi5vcmc8bWFpbHRvOnRpY3RvY0Bp
ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbVElDVE9DXSBkcmFmdC1pZXRmLXRpY3RvYy0xNTg4djIt
eWFuZy0wNSAtIENvbmNlcm4gb3ZlciBwb3J0IGlkZW50aWZpZXINCg0KDQoNClRoYW5rcyBTZWFu
LA0KDQoNCg0KUmVnYXJkaW5nIHlvdXIgb3RoZXIgY29tbWVudCBvbiBUTEQuLi4gSSBhZ3JlZS4N
Cg0KDQoNClJlZ2FyZGluZyB0aGUgY29tbWVudCBiZWxvdyBvbiBwb3J0LWlkZW50aXR5LCBJIGFn
cmVlIHRoYXQgd2UgbmVlZCB0byBkbyBpdCBmb3IgcHJhY3RpY2FsIHJlYXNvbnMuDQoNCg0KDQpJ
biAxNTg4LTIwMDgsIHRoZXJlIGlzIGEgZGlzdGluY3QgZGF0YXNldCBtZW1iZXIgZm9yIHBvcnRE
Uy5wb3J0SWRlbnRpdHksIHdoaWNoIDUuMy41IHNwZWNpZmllcyBhcyB1c2luZyB0eXBlIFBvcnRJ
ZGVudGl0eToNCg0KICBzdHJ1Y3QgUG9ydElkZW50aXR5IHsNCg0KICAgIENsb2NrSWRlbnRpdHkg
Y2xvY2tJZGVudGl0eTsNCg0KICAgIFVJbnRlZ2VyIHBvcnROdW1iZXI7DQoNCiAgfQ0KDQoNCg0K
SWYgd2UgaW50ZXJwcmV0IHRoZSAxNTg4LTIwMDggZGF0YXNldHMgYXMgYW4gaW5mb3JtYXRpb24g
bW9kZWwsIGFuZCBhcHBseSB0aGF0IGFzIGRpcmVjdGx5IGFzIHBvc3NpYmxlIHRvIGEgWUFORyBk
YXRhIG1vZGVsLCBwb3J0RFMucG9ydElkZW50aXR5IGlzIGEgY29udGFpbmVyLCB3aGljaCBpcyB3
aGF0IHdlIGhhdmUgc28gZmFyLiBUaGF0IGludHJvZHVjZXMgYSBjaGFsbGVuZ2UsIGJlY2F1c2Ug
d2Ugd2FudCB0byB1c2UgcG9ydERTLnBvcnRJZGVudGl0eS5wb3J0TnVtYmVyIGFzIHRoZSBrZXkg
dG8gdGhlIGxpc3Qgb2YgcG9ydERTJ3MuIFdlIHNvbHZlZCB0aGF0IGNoYWxsZW5nZSB3aXRoIGEg
bGVhZnJlZiwgYnV0IEknZCBhZ3JlZSB0aGF0IGlzIHVnbHkuDQoNCg0KDQpZb3VyIHByb3Bvc2Fs
IGNoYW5nZXMgcG9ydERTLnBvcnRJZGVudGl0eSBmcm9tIGEgY29udGFpbmVyIHRvIGEgZ3JvdXBp
bmcsIHNvIHRoYXQgaXQgcG9ydERTLnBvcnRJZGVudGl0eS5wb3J0TnVtYmVyIGNhbiBiZSB1c2Vk
IGFzIHRoZSBrZXkgd2l0aG91dCBhIGxlYWZyZWYuDQoNCg0KDQpUaGUgZG93bnNpZGUgaXMgdGhh
dCBpZi93aGVuIGEgWUFORyBtYW5hZ2VtZW50IGNsaWVudCB0cmllcyB0byAiZ2V0IiBwb3J0RFMu
cG9ydElkZW50aXR5LCBpdCBkb2Vzbid0IHdvcmsuLi4gdGhlcmUgaXMgbm8gcG9ydElkZW50aXR5
IHRvIGdldC4NCg0KDQoNClBlcnNvbmFsbHksIEkgdGhpbmsgdGhhdCBkb3duc2lkZSBpcyB3b3J0
aCBpdC4gT25lIGNhbiBhcmd1ZSB0aGF0IHlvdXIgcHJvcG9zYWwgc3RpbGwgY29uZm9ybXMgdG8g
dGhlIDE1ODgtMjAwOCBpbmZvcm1hdGlvbiBtb2RlbCBmb3IgbWFuYWdlbWVudCwgaW4gdGhhdCBw
b3J0RFMucG9ydElkZW50aXR5IHN0aWxsICJleGlzdHMiIGluIGEgbWFubmVyIHRoYXQgbWFrZXMg
c2Vuc2UgZm9yIFlBTkcuDQoNCg0KDQpSb2RuZXkNCg0KDQoNCg0KDQoNCg0KRnJvbTogVElDVE9D
IFttYWlsdG86dGljdG9jLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTZWFuIENvbmRv
bg0KDQpTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMjYsIDIwMTcgMTA6MzggQU0NCg0KVG86IHRp
Y3RvY0BpZXRmLm9yZzxtYWlsdG86dGljdG9jQGlldGYub3JnPg0KDQpTdWJqZWN0OiBbVElDVE9D
XSBkcmFmdC1pZXRmLXRpY3RvYy0xNTg4djIteWFuZy0wNSAtIENvbmNlcm4gb3ZlciBwb3J0IGlk
ZW50aWZpZXINCg0KDQoNCldpdGggcmVmZXJlbmNlIHRvICJZQU5HIERhdGEgTW9kZWwgZm9yIElF
RUUgMTU4OHYyIiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0
cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfZHJhZnQtMkRpZXRmLTJEdGljdG9jLTJEMTU4OHYy
LTJEeWFuZy0yRDA1JmQ9RHdNRkF3JmM9SV8wWXdvS3k3ejVMTVRWZHlPNllDaUUydXpJMWpqWlp1
SVBlbGNTaml4QSZyPVdBNzFzZjJvN0R3N0NiWWhGdDI0RFBqdDNsSnV1cHN3V1lkbmJvS2JaOGsm
bT1qS0hjelZOTE4tS3VWMkhSWmtiRVpZMVN6bENEX0F6dGthV1NjY3JxQkk4JnM9bXNoN0E3X09n
SFoxbDY1RG42X0xoaURJWGtYcEZlaUxHbUtiS3hzcVhXdyZlPQ0KDQoNCg0KSSBoYXZlIGEgY29u
Y2VybiBhYm91dCB0aGUgc3RydWN0dXJlIG9mIHRoZSBZQU5HLCBhbmQgaG93IHRoZSBsaXN0cyBw
b3J0LWRzLWxpc3QgYW5kIHRyYW5zcGFyZW50LWNsb2NrLXBvcnQtZHMtbGlzdCBhcmUgaW5kZXhl
ZCB3aXRoIGEgbGVhZiB3aGljaCBpcyBhIGxlYWZyZWYuDQoNCg0KDQpUaGUgc3RydWN0dXJlIHNl
ZW1zIHVubmVjZXNzYXJpbHkgY29tcGxleCAtIHBvcnQtbnVtYmVyIGlzIHJlcHJlc2VudGVkIGFz
IGEgbGVhZiBkaXJlY3RseSBiZW5lYXRoIHRoZSBsaXN0ICh0byBiZSB1c2VkIGFzIGtleSkgYW5k
IGFnYWluIHVuZGVyIHRoZSBwb3J0LWlkZW50aXR5IGNvbnRhaW5lci4gSXQgaXMgc3RydWN0dXJl
ZCBpbiBhIHdheSB0aGF0IEkgYmVsaWV2ZSB3b3VsZCBtYWtlIGl0IGRpZmZpY3VsdCB0byB3b3Jr
IHdpdGggc29tZSBZQU5HIHRvb2xzIGluIHRoZSBtYXJrZXQuDQoNCg0KDQpUaGUgcHVycG9zZSBv
ZiBwb3J0LWlkZW50aXR5IGNvbnRhaW5lciBpcyBub3QgY2xlYXIgZnJvbSB0aGUgZG9jdW1lbnQg
LSBpdCB3b3VsZCBhY2hpZXZlIHRoZSBzYW1lIHB1cnBvc2UgaWYgaXQgd2FzIGxlZnQgb3V0IG9m
IHBvcnQtZHMtZW50cnkgYW5kIHRyYW5zcGFyZW50LWNsb2NrLXBvcnQtZHMtZW50cnkgYW5kIGlu
c3RlYWQgdGhlIGdyb3VwaW5nIHBvcnQtaWRlbnRpdHktZ3JvdXBpbmcgaW5jbHVkZWQgZGlyZWN0
bHkuDQoNCg0KDQpTZWUgdGhlIGF0dGFjaGVkIGZpbGVzIGFzIG9yaWdpbmFsLCBhIG1vZGlmaWVk
IHZlcnNpb24gYW5kIGFzIGEgcGF0Y2ggZmlsZS4NCg0KDQoNClNlYW4gQ29uZG9uDQoNCj09PT09
PT09PT09PT09PT09PT09PT09DQoNClNlYW4gQ29uZG9uDQoNClN5c3RlbSAmIFNvZnR3YXJlIEFy
Y2hpdGVjdA0KDQpGcmVxdWVuY3kgJiBUaW1pbmcgRGl2aXNpb24NCg0KTWljcm9zZW1pIEluYy4N
Cg0KbWFpbHRvOnNlYW4uY29uZG9uQG1pY3Jvc2VtaS5jb20NCg0KDQoNCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClRJQ1RPQyBtYWlsaW5nIGxpc3QN
Cg0KVElDVE9DQGlldGYub3JnPG1haWx0bzpUSUNUT0NAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGljdG9jDQo=

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

PGh0bWwgZGlyPSJsdHIiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUi
IGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8c3R5bGU+CjwhLS0KQGZvbnQt
ZmFjZQoJe2ZvbnQtZmFtaWx5OuWui+S9k30KQGZvbnQtZmFjZQoJe2ZvbnQtZmFtaWx5OiJDYW1i
cmlhIE1hdGgifQpAZm9udC1mYWNlCgl7Zm9udC1mYW1pbHk6Q2FtYnJpYX0KQGZvbnQtZmFjZQoJ
e2ZvbnQtZmFtaWx5OkNhbGlicml9CkBmb250LWZhY2UKCXtmb250LWZhbWlseTpUYWhvbWF9CnAu
TXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwKCXttYXJnaW46MGNtOwoJbWFy
Z2luLWJvdHRvbTouMDAwMXB0OwoJdGV4dC1hbGlnbjpqdXN0aWZ5OwoJdGV4dC1qdXN0aWZ5Omlu
dGVyLWlkZW9ncmFwaDsKCWZvbnQtc2l6ZToxMC41cHQ7Cglmb250LWZhbWlseToiQ2FsaWJyaSIs
InNhbnMtc2VyaWYifQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rCgl7Y29sb3I6Ymx1ZTsKCXRl
eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmV9CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs
b3dlZAoJe2NvbG9yOnB1cnBsZTsKCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmV9CnAuTXNvUGxh
aW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQKCXttYXJnaW46MGNtOwoJ
bWFyZ2luLWJvdHRvbTouMDAwMXB0OwoJZm9udC1zaXplOjEwLjVwdDsKCWZvbnQtZmFtaWx5OiJD
YWxpYnJpIiwic2Fucy1zZXJpZiJ9CnAKCXttYXJnaW46MGNtOwoJbWFyZ2luLWJvdHRvbTouMDAw
MXB0OwoJZm9udC1zaXplOjEyLjBwdDsKCWZvbnQtZmFtaWx5OuWui+S9k30KcC5Nc29BY2V0YXRl
LCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQoJe21hcmdpbjowY207CgltYXJnaW4tYm90
dG9tOi4wMDAxcHQ7Cgl0ZXh0LWFsaWduOmp1c3RpZnk7Cgl0ZXh0LWp1c3RpZnk6aW50ZXItaWRl
b2dyYXBoOwoJZm9udC1zaXplOjkuMHB0OwoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl
cmlmIn0Kc3Bhbi5DaGFyCgl7Zm9udC1mYW1pbHk65a6L5L2TfQpzcGFuLkNoYXIwCgl7Zm9udC1m
YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIn0Kc3Bhbi5jaGFyMQoJe2ZvbnQtZmFtaWx5OiJD
YWxpYnJpIiwic2Fucy1zZXJpZiJ9CnNwYW4uRW1haWxTdHlsZTIzCgl7Zm9udC1mYW1pbHk6IkNh
bGlicmkiLCJzYW5zLXNlcmlmIjsKCWNvbG9yOiMxRjQ5N0R9Ci5Nc29DaHBEZWZhdWx0Cgl7Zm9u
dC1zaXplOjEwLjBwdH0KQHBhZ2UgV29yZFNlY3Rpb24xCgl7bWFyZ2luOjcyLjBwdCA5MC4wcHQg
NzIuMHB0IDkwLjBwdH0Kb2wKCXttYXJnaW4tYm90dG9tOjBjbX0KdWwKCXttYXJnaW4tYm90dG9t
OjBjbX0KLS0+Cjwvc3R5bGU+PHN0eWxlIHR5cGU9InRleHQvY3NzIiBpZD0ib3dhUGFyYVN0eWxl
Ij5QIHttYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowO308L3N0eWxlPg0KPC9oZWFkPg0KPGJv
ZHkgZnBzdHlsZT0iMSIgb2NzaT0iMCIgdmxpbms9InB1cnBsZSIgbGluaz0iYmx1ZSIgbGFuZz0i
WkgtQ04iPg0KPGRpdiBzdHlsZT0iZGlyZWN0aW9uOiBsdHI7Zm9udC1mYW1pbHk6IFRhaG9tYTtj
b2xvcjogIzAwMDAwMDtmb250LXNpemU6IDEwcHQ7Ij5UaGFuayB5b3UgZm9yIHlvdXIgaW4gZGVw
dGggY29uc2lkZXJhdGlvbiBvZiB0aGlzIGlzc3VlLiBTZWFuPGJyPg0KPGRpdiBzdHlsZT0iZm9u
dC1mYW1pbHk6IFRpbWVzIE5ldyBSb21hbjsgY29sb3I6ICMwMDAwMDA7IGZvbnQtc2l6ZTogMTZw
eCI+DQo8aHIgdGFiaW5kZXg9Ii0xIj4NCjxkaXYgaWQ9ImRpdlJwRjYzOTQwNCIgc3R5bGU9ImRp
cmVjdGlvbjogbHRyOyI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMwMDAwMDAiIGZhY2U9IlRhaG9t
YSI+PGI+RnJvbTo8L2I+IEppYW5neXVhbmxvbmcgW2ppYW5neXVhbmxvbmdAaHVhd2VpLmNvbV08
YnI+DQo8Yj5TZW50OjwvYj4gMjggU2VwdGVtYmVyIDIwMTcgMTQ6MTE8YnI+DQo8Yj5Ubzo8L2I+
IFNlYW4gQ29uZG9uOyBuZXRtb2RAaWV0Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IHRpY3RvY0BpZXRm
Lm9yZzsgUm9kbmV5IEN1bW1pbmdzPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBkcmFmdC1pZXRm
LXRpY3RvYy0xNTg4djIteWFuZy0wNSAtIENvbmNlcm4gb3ZlciBwb3J0IGlkZW50aWZpZXI8YnI+
DQo8L2ZvbnQ+PGJyPg0KPC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjE0cHQ7IGZvbnQtZmFtaWx5OidDYW1icmlhJywndGltZXMgbmV3IHJvbWFuJywnZ2Fy
YW1vbmQnLHNlcmlmOyBjb2xvcjojZmYwMDAwIj5FWFRFUk5BTCBFTUFJTDwvc3Bhbj48YnI+DQo8
YnI+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIiBsYW5nPSJFTi1VUyI+U2Vhbiw8L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiIGxh
bmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImNvbG9yOiMxRjQ5N0QiIGxhbmc9IkVOLVVTIj5NeSBwZXJzb25hbCBvcGluaW9uIGlz
IHRoYXQgaXQgY2FuIHdvcmssIGJ1dCBJIHdvdWxkIGxpa2UgdG8gYXNrIGZvciBtb3JlIG9waW5p
b25zIGZyb20gb3VyIG5ldG1vZCBleHBlcnRzOyk8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi
IGxhbmc9IkVOLVVTIj5IaSBuZXRtb2QgZXhwZXJ0cyw8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiIGxhbmc9IkVOLVVTIj5Db25zaWRl
cmluZyB0aGUgZm9sbG93aW5nIHNhbXBsZSBtb2R1bGUsIG15LWxpc3QgaXMgYSBsaXN0LCBhbmQg
aXQgbmVlZHMgdG8gdXNlIGEgbGVhZiBtZW1iZXIgJnF1b3Q7cG9ydC1udW1iZXImcXVvdDsgaW4g
bXktcG9ydC1jb250YWluZXIgYXMgYSBrZXkuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIiBsYW5nPSJFTi1VUyI+V2Ugbm93IGhhdmUg
MyBvcHRpb25zOjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Y29sb3I6IzFGNDk3RCIgbGFuZz0iRU4tVVMiPjEuIDwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCIgbGFuZz0iRU4tVVMiPiZuYnNwOyZu
YnNwO2xpc3QgbXktbGlzdCB7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJjb2xvcjojMUY0OTdEIiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGtl
eSAmcXVvdDtwb3J0LW51bWJlciZxdW90Ozs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsm
bmJzcDsgbGVhZiBwb3J0LW51bWJlciB7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGUgdWludDE2Ozwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCIgbGFuZz0iRU4tVVMiPiZuYnNw
OyZuYnNwOyZuYnNwOyB9PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJjb2xvcjojMUY0OTdEIiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIiBsYW5nPSJFTi1VUyI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbnRhaW5lciBteS1wb3J0LWNvbnRhaW5lciB7PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIiBsYW5n
PSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxlYWYg
cG9ydC1udW1iZXIgezwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iY29sb3I6IzFGNDk3RCIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0eXBlIHVpbnQxNjs8L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiIGxhbmc9IkVOLVVT
Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCIgbGFuZz0i
RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBs
ZWFmIG90aGVyLWxlYWYgezwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iY29sb3I6IzFGNDk3RCIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsgLi4uPC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIiBsYW5nPSJFTi1VUyI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiIGxhbmc9
IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCIgbGFuZz0iRU4tVVMiPiZuYnNwOyB9PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE
IiBsYW5nPSJFTi1VUyI+QnV0IHRoaXMgZG9lcyBub3Qgd29yayBmb3IgdGhlcmUgaXMgY29tcGls
aW5nIGVycm9yLjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Y29sb3I6IzFGNDk3RCIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiIGxhbmc9
IkVOLVVTIj4yLjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Y29sb3I6IzFGNDk3RCIgbGFuZz0iRU4tVVMiPiZuYnNwOyBsaXN0IG15LWxpc3Qgezwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCIgbGFu
Zz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyBrZXkgJnF1b3Q7cG9ydC1udW1iZXImcXVvdDs7
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0
OTdEIiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxlYWYgcG9ydC1udW1iZXIgezwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3
RCIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0eXBl
IHVpbnQxNjs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv
bG9yOiMxRjQ5N0QiIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCIgbGFuZz0i
RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyBjb250YWluZXIgbXktcG9ydC1jb250YWluZXIgezwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3
RCIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyBsZWFmIHBvcnQtbnVtYmVyIHs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHlwZSBsZWFm
cmVmezwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6
IzFGNDk3RCIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwYXRoICZxdW90Oy4u
Ly4uL3BvcnQtbnVtYmVyJnF1b3Q7Ozwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIiBs
YW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5
N0QiIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgbGVhZiBvdGhlci1sZWFmIHs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7IC4uLjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCIgbGFuZz0i
RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0
OTdEIiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiIGxhbmc9IkVOLVVTIj4m
bmJzcDsgfTwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s
b3I6IzFGNDk3RCIgbGFuZz0iRU4tVVMiPk9wdGlvbiAyIGNhbiBwYXJzZSwgdGhvdWdoIGxlYWZy
ZWYgaW4gYSBzdWItbW9kdWxlIHNlZW1zIG5vdCB2ZXJ5IG5hdHVyYWwuPC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIiBsYW5nPSJFTi1V
UyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj
b2xvcjojMUY0OTdEIiBsYW5nPSJFTi1VUyI+My48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiIGxhbmc9IkVOLVVTIj4mbmJzcDsgbGlz
dCBteS1saXN0IHs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImNvbG9yOiMxRjQ5N0QiIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsga2V5ICZxdW90
O3BvcnQtbnVtYmVyJnF1b3Q7Ozwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iY29sb3I6IzFGNDk3RCIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyBs
ZWFmIHBvcnQtbnVtYmVyIHs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImNvbG9yOiMxRjQ5N0QiIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgdHlwZSBsZWFmcmVmezwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwYXRoICZxdW90Oy4u
L215LXBvcnQtY29udGFpbmVyL3BvcnQtbnVtYmVyJnF1b3Q7Ozwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCIgbGFuZz0iRU4tVVMiPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIiBsYW5nPSJFTi1VUyI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7IH08L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImNvbG9yOiMxRjQ5N0QiIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsgY29u
dGFpbmVyIG15LXBvcnQtY29udGFpbmVyIHs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbGVhZiBwb3J0LW51bWJlciB7PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIiBsYW5n
PSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IHR5cGUgdWludDE2Ozwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iY29sb3I6IzFGNDk3RCIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxlYWYgb3RoZXItbGVhZiB7PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIiBs
YW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7ICZuYnNwOyAuLi48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImNvbG9yOiMxRjQ5N0QiIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZu
YnNwOyB9PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv
cjojMUY0OTdEIiBsYW5nPSJFTi1VUyI+Jm5ic3A7IH08L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiIGxhbmc9IkVOLVVTIj4mbmJzcDs8
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5
N0QiIGxhbmc9IkVOLVVTIj5PcHRpb24gMyBjYW4gYWxzbyBwYXJzZSwgdGhvdWdoIGxlYWZyZWYg
c2VlbXMgbm90IGEgdmVyeSBuYXR1cmFsIGtleS4gV2hhdCBpcyB5b3VyIGZhdm9yaXRlIG9wdGlv
bj8gT3IgZG8geW91IGhhdmUgYW55IGJldHRlciBzY2hlbWVzPzwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCIgbGFuZz0iRU4tVVMiPllv
dXIgb3BpbmlvbnMgYXJlIHZlcnkgaW1wb3J0YW50IGZvciBvdXIgcmV2aXNpb24gb2YgdGhpcyBk
cmFmdC48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y
OiMxRjQ5N0QiIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiIGxhbmc9IkVOLVVTIj5UaGFua3MsPC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE
IiBsYW5nPSJFTi1VUyI+WXVhbmxvbmc8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiIGxhbmc9
IkVOLVVTIj4mbmJzcDs8L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l
OyBib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7IHBhZGRpbmc6My4wcHQgMGNtIDBjbSAw
Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCIgYWxpZ249
ImxlZnQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVv
dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyIgbGFuZz0iRU4tVVMiPkZyb206
PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1
b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiIGxhbmc9IkVOLVVTIj4gU2Vh
biBDb25kb24gW21haWx0bzpzZWFuLmNvbmRvbkBtaWNyb3NlbWkuY29tXQ0KPGJyPg0KPGI+U2Vu
dDo8L2I+IFdlZG5lc2RheSwgU2VwdGVtYmVyIDI3LCAyMDE3IDc6MTEgUE08YnI+DQo8Yj5Ubzo8
L2I+IEppYW5neXVhbmxvbmc8YnI+DQo8Yj5DYzo8L2I+IHRpY3RvY0BpZXRmLm9yZzsgUm9kbmV5
IEN1bW1pbmdzPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBkcmFmdC1pZXRmLXRpY3RvYy0xNTg4
djIteWFuZy0wNSAtIENvbmNlcm4gb3ZlciBwb3J0IGlkZW50aWZpZXI8L3NwYW4+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQi
IGFsaWduPSJsZWZ0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0IiBhbGlnbj0ibGVm
dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1RhaG9t
YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMi
PlRoYW5rcyBndXlzIGZvciB5b3VyIHJlc3BvbnNlcy48YnI+DQo8YnI+DQpJIGFjY2VwdCB5b3Vy
IHBvaW50cyB0byBrZWVwIHRoZSBzdHJ1Y3R1cmUgYXMgYWxpZ25lZCB0byB0aGUgSUVFRSAxNTg4
IHN0YW5kYXJkIGFzIHBvc3NpYmxlLg0KPGJyPg0KPGJyPg0KT25lIGFsdGVybmF0ZSBzdWdnZXN0
aW9uIHRoYXQgSSB3b3VsZCBtYWtlLCBpcyB0aGF0IHRoZSBwb3J0LW51bWJlciBjdXJyZW50bHkg
ZGVmaW5lZCBhcyBsZWFmcmVmIHNob3VsZCBiZSBtYWRlIHRoZSByZWFsIGF0dHJpYnV0ZSAoaS5l
LiB1aW50MTYpIGFuZCB0aGF0IHRoZSBwb3J0LW51bWJlciBpbnNpZGUgcG9ydC1pZGVudGl0eSBj
b250YWluZXIgc2hvdWxkIGJlIG1hZGUgaW4gdG8gdGhlIGxlYWYgcmVmIChhbmQgc2V0IHRvIG1h
bmRhdG9yeQ0KIHRydWUpLjxicj4NCjxicj4NClRoZSByZWFzb24gSSBzYXkgdGhpcyBpcyB0aGF0
PC9zcGFuPjwvcD4NCjxvbCBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9ImNvbG9yOmJsYWNrOyB0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90OyIgbGFuZz0iRU4tVVMiPlhNTCBtb2RlbHMgYXJlIHVzdWFsbHkgbmF2aWdhdGVk
IGFuZCBjb25zdHJ1Y3RlZCByb290LXRvLWxlYWYsIGFuZCB0aGUgd2F5IGl0J3MgcG9ydHJheWVk
IGF0IHRoZSBtb21lbnQgaXMgdGhhdCBwb3J0LW51bWJlcg0KIGxlYWZyZWYgcG9pbnRzIHRvIHNv
bWV0aGluZyB0aGF0IG1heSBub3QgZXhpc3QgYXQgdGhlIHRpbWUgaXQgaXMgYmVpbmcgZGVmaW5l
ZC4gVGhpcyBtYWtlcyBpdCBkaWZmaWN1bHQgdG8gaW1wbGVtZW50Ljwvc3Bhbj48L2xpPjxsaSBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7IHRleHQtYWxpZ246bGVmdCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7IiBsYW5nPSJFTi1VUyI+QWxzbyBwb3J0LWlkZW50aXR5
L3BvcnQtbnVtYmVyIGlzIG5vdCAmcXVvdDttYW5kYXRvcnkgdHJ1ZSZxdW90OyBtZWFuaW5nIHRo
YXQgaXQgY291bGQgYmUgbGVmdCBvdXQgYWx0b2dldGhlci4gSXQncyBub3QgdmFsaWQgZm9yDQog
aXQgdG8gaGF2ZSBhIGRlZmF1bHQgdmFsdWUgZWl0aGVyIHNpbmNlIGV2ZXJ5IGl0ZW0gaW4gdGhl
IGxpc3Qgd2lsbCBuZWVkIGEgZGlmZmVyZW50IGlkZW50aWZpZXIuPC9zcGFuPjwvbGk+PC9vbD4N
CjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtUYWhv
bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6YmxhY2siIGxhbmc9IkVOLVVT
Ij5XaXRoIHRoaXMgc3VnZ2VzdGlvbiB0aGUgc3RydWN0dXJlIHlvdSByZXF1aXJlIHdpdGggcG9y
dC1pZGVudGl0eSBzdGlsbCBleGlzdHMsIGJ1dCBub3cgdGhlIGltcGxlbWVudGF0aW9uIGlzIG1v
cmUgc3RyYWlnaHRmb3J3YXJkLCBhbmQgdGhlIGNoYW5nZSB3aWxsIGJlIHRyYW5zcGFyZW50DQog
dG8gYW4gZW5kIHVzZXIuPC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0OyBmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
OzsgY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCIgYWxpZ249ImxlZnQiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj5CZXN0IHJlZ2Fy
ZHMsIFNlYW48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0idGV4dC1hbGlnbjpsZWZ0IiBhbGlnbj0ibGVmdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7OyBjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPj09PT09PT09PT09PT09PT09PT09PT09
PGJyPg0KU2VhbiBDb25kb248YnI+DQpTeXN0ZW0gJmFtcDsgU29mdHdhcmUgQXJjaGl0ZWN0PGJy
Pg0KRnJlcXVlbmN5ICZhbXA7IFRpbWluZyBEaXZpc2lvbjxicj4NCk1pY3Jvc2VtaSBJbmMuPGJy
Pg0KPGEgaHJlZj0ibWFpbHRvOnNlYW4uY29uZG9uQG1pY3Jvc2VtaS5jb20iIHRhcmdldD0iX2Js
YW5rIj5zZWFuLmNvbmRvbkBtaWNyb3NlbWkuY29tPC9hPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0OyB0
ZXh0LWFsaWduOmxlZnQiIGFsaWduPSJsZWZ0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDsgZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
IGNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciIgYWxpZ249ImNlbnRl
ciI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1RpbWVz
IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OzsgY29sb3I6YmxhY2siIGxhbmc9IkVO
LVVTIj4NCjxociB3aWR0aD0iMTAwJSIgc2l6ZT0iMiIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+
PC9kaXY+DQo8ZGl2IGlkPSJkaXZScEYxMTgxMTkiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0OyB0ZXh0LWFsaWduOmxlZnQiIGFsaWduPSJsZWZ0Ij48
Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VGFob21h
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+
RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWls
eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6YmxhY2si
IGxhbmc9IkVOLVVTIj4NCiBKaWFuZ3l1YW5sb25nIFtqaWFuZ3l1YW5sb25nQGh1YXdlaS5jb21d
PGJyPg0KPGI+U2VudDo8L2I+IDI3IFNlcHRlbWJlciAyMDE3IDA4OjA1PGJyPg0KPGI+VG86PC9i
PiBTZWFuIENvbmRvbjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnRpY3RvY0BpZXRm
Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRpY3RvY0BpZXRmLm9yZzwvYT47IFJvZG5leSBDdW1taW5n
czxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogZHJhZnQtaWV0Zi10aWN0b2MtMTU4OHYyLXlhbmct
MDUgLSBDb25jZXJuIG92ZXIgcG9ydCBpZGVudGlmaWVyPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTIuMHB0OyBmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1
b3Q7c2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy
LjBwdDsgdGV4dC1hbGlnbjpsZWZ0IiBhbGlnbj0ibGVmdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxNC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbWJyaWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVv
dDs7IGNvbG9yOnJlZCIgbGFuZz0iRU4tVVMiPkVYVEVSTkFMIEVNQUlMPC9zcGFuPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTIuMHB0OyBmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m
cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+PC9zcGFu
PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9
ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+RGVhciBTZWFuLDwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4m
bmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNv
bG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+VGhhbmsgeW91IGEgbG90IGZvciBkaXZpbmcgaW50byB0
aGUgdGVjaG5pY2FsIGRldGFpbHMgb2YgdGhpcyBtb2R1bGUuIEp1c3QgYXMgUm9kbmV5IHNhaWQs
IGl0IGlzIGEgY2hhbGxlbmdlIG9mIDE1ODggaW5mbyBtb2RlbCB0byBZQU5HLCBhbmQgd2UgdXNl
IHRoZSBsZWFmcmVmIG9mIFlBTkcgdG8gd29yayBhcm91bmQgaXQuPC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMi
Pkkgd291bGQgbGlrZSB0byBwcm92aWRlIGEgbGl0dGxlIG1vcmUgYmFja2dyb3VuZHMgb24gdGhl
IHRyYWRlb2ZmOjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls
ZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+MS4g
SXQgc2F5cyBpbiBTZWMuIDcuNS4yLjEgaW4gSUVFRSAxNTg4LTIwMDg6IHBvcnRJZGVudGl0eSBp
cyBhIG1lbWJlciBvZiB0aGUgcG9ydERTIGRhdGEgc2V0LiBBIHBvcnRJZGVudGl0eSBjb25zaXN0
cyBvZiB0d28gYXR0cmlidXRlcywgYXM8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+Zm9sbG93czo8L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx
dW90O0NhbWJyaWEgTWF0aCZxdW90OywmcXVvdDtzZXJpZiZxdW90OzsgY29sb3I6YmxhY2siIGxh
bmc9IkVOLVVTIj7ijq88L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1V
UyI+IHBvcnRJZGVudGl0eS5jbG9ja0lkZW50aXR5PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYW1icmlhIE1hdGgmcXVv
dDssJnF1b3Q7c2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+4o6vPC9zcGFu
PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPiBwb3J0SWRlbnRpdHkucG9y
dE51bWJlcjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0i
Y29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj5GdXJ0aGVybW9yZSwgdGhlICZxdW90O3BvcnREUy5w
b3J0SWRlbnRpdHkmcXVvdDsgYXR0cmlidXRlIGlzIG1lbnRpb25lZCBxdWl0ZSBhIGZldyB0aW1l
cyBpbiAxNTg4LTIwMDgsIGVzcGVjaWFsbHkgaW4gVGFibGUgMTcgYW5kIHVuZGVyIFRhYmxlIDYx
LCB3aXRoIGEgaGludCB0aGF0IGFzc2lnbm1lbnQgYW5kIGNvbXBhcmlzb24gY2FuIGJlIGRvbmUg
b24NCiB0aGlzIG1lbWJlciBkaXJlY3RseSwgdGh1cyBpdCBzZWVtcyB0byBtZSBwb3J0SWRlbnRp
dHkgaXMgYW4gaW1wb3J0YW50IGFuZCB3ZWxsIHVuZGVyc3Rvb2QgY29uc3RydWN0IGluIHRoZSAx
NTg4IHNwZWNpZmljYXRpb24uPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz
cGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVO
LVVTIj4yLiBJZiB3ZSBjaGFuZ2UgcG9ydERTLnBvcnRJZGVudGl0eSBmcm9tIGEgY29udGFpbmVy
IHRvIGEgZ3JvdXBpbmcsIHRoZW4gdGhlcmUgaXMgbm8gcG9ydElkZW50aXR5IGZvciBwb3J0RFMg
YW5kIHRyYW5zcGFyZW50Y2xvY2tQb3J0RFMgaW4gdGhlIHJlc3VsdGluZyB0cmVlIGRpYWdyYW06
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpi
bGFjayIgbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U
ZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj5tb2R1bGU6IGlldGYt
cHRwLWRhdGFzZXQ8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5
bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1y
dyBpbnN0YW5jZS1saXN0KiBbaW5zdGFuY2UtbnVtYmVyXTwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJz
cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgaW5zdGFuY2UtbnVtYmVyJm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVpbnQxNjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJz
cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgZGVmYXVsdC1kczwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVO
LVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyB0d28tc3Rl
cC1mbGFnPyZuYnNwOyZuYnNwOyZuYnNwOyBib29sZWFuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPiZuYnNw
OyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGNsb2NrLWlkZW50aXR5PyZu
YnNwOyZuYnNwOyBjbG9jay1pZGVudGl0eS10eXBlPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPiZuYnNwOyZu
YnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IG51bWJlci1wb3J0cz8mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgdWludDE2PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZu
YnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGNsb2NrLXF1YWxpdHk8L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJF
Ti1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1y
dyBjbG9jay1jbGFzcz8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgdWludDg8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9
ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZu
YnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBjbG9jay1hY2N1cmFjeT8mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgdWludDg8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g
c3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz
cDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBvZmZzZXQtc2NhbGVkLWxvZy12YXJpYW5jZT8m
bmJzcDsmbmJzcDsgdWludDE2PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz
cGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyB8
Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IHByaW9yaXR5MT8mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgdWludDg8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgcHJpb3JpdHkyPyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1aW50ODwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJz
cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBkb21haW4tbnVtYmVyPyZu
YnNwOyZuYnNwOyZuYnNwOyB1aW50ODwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJz
cDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBzbGF2ZS1vbmx5PyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyBib29sZWFuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNw
OyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBjdXJyZW50LWRzPC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPiZu
YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IHN0ZXBzLXJlbW92ZWQ/
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVpbnQxNjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxh
bmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBv
ZmZzZXQtZnJvbS1tYXN0ZXI/Jm5ic3A7Jm5ic3A7IHRpbWUtaW50ZXJ2YWwtdHlwZTwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxh
bmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBt
ZWFuLXBhdGgtZGVsYXk/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRpbWUtaW50ZXJ2
YWwtdHlwZTwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0i
Y29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyAmIzQz
Oy0tcncgcGFyZW50LWRzPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu
IHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i
c3A7IHwgJm5ic3A7JiM0MzstLXJ3IHBhcmVudC1wb3J0LWlkZW50aXR5PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4t
VVMiPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncg
Y2xvY2staWRlbnRpdHk/Jm5ic3A7Jm5ic3A7IGNsb2NrLWlkZW50aXR5LXR5cGU8L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5n
PSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7
LS1ydyBwb3J0LW51bWJlcj8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdWludDE2PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj
ayIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0Mzst
LXJ3IHBhcmVudC1zdGF0cz8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYm9vbGVhbjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9
IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBvYnNl
cnZlZC1wYXJlbnQtb2Zmc2V0LXNjYWxlZC1sb2ctdmFyaWFuY2U/Jm5ic3A7Jm5ic3A7IHVpbnQx
Njwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6
YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYj
NDM7LS1ydyBvYnNlcnZlZC1wYXJlbnQtY2xvY2stcGhhc2UtY2hhbmdlLXJhdGU/Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGludDMyPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNw
OyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGdyYW5kbWFzdGVyLWlkZW50aXR5PyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBiaW5hcnk8L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgZ3JhbmRtYXN0ZXItY2xv
Y2stcXVhbGl0eTwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls
ZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8
Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGNsb2NrLWNsYXNzPyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1aW50ODwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJzcDsm
bmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGNsb2NrLWFjY3Vy
YWN5PyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1aW50ODwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4m
bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IG9mZnNl
dC1zY2FsZWQtbG9nLXZhcmlhbmNlPyZuYnNwOyZuYnNwOyB1aW50MTY8L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1V
UyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgZ3JhbmRtYXN0
ZXItcHJpb3JpdHkxPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1aW50ODwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVO
LVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBncmFuZG1h
c3Rlci1wcmlvcml0eTI/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVpbnQ4PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0i
RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyB0aW1lLXByb3BlcnRp
ZXMtZHM8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNv
bG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNw
OyAmIzQzOy0tcncgY3VycmVudC11dGMtb2Zmc2V0LXZhbGlkPyZuYnNwOyZuYnNwOyBib29sZWFu
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpi
bGFjayIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0
MzstLXJ3IGN1cnJlbnQtdXRjLW9mZnNldD8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgaW50MTY8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgbGVhcDU5PyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBib29sZWFuPC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIg
bGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3
IGxlYXA2MT8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Ym9vbGVhbjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJz
cDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyB0aW1lLXRyYWNlYWJsZT8mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgYm9vbGVhbjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls
ZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8
Jm5ic3A7ICYjNDM7LS1ydyBmcmVxdWVuY3ktdHJhY2VhYmxlPyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBib29sZWFuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPiZuYnNwOyZu
YnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IHB0cC10aW1lc2NhbGU/Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IGJvb2xlYW48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgdGltZS1zb3VyY2U/Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVpbnQ4PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZu
YnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBwb3J0LWRzLWxpc3QqIFtwb3J0LW51bWJlcl08L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBs
YW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
JiM0MzstLXJ3IGNsb2NrLWlkZW50aXR5PyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyBjbG9jay1pZGVudGl0eS10eXBlPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNw
OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBwb3J0LW51bWJlciZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1aW50MTY8
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs
YWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgJiM0MzstLXJ3IHBvcnQtc3RhdGU/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBvcnQtc3RhdGUtZW51bWVyYXRpb248L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBs
YW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
JiM0MzstLXJ3IHVuZGVybHlpbmctaW50ZXJmYWNlPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpZjppbnRlcmZhY2UtcmVmPC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0i
RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7
LS1ydyBsb2ctbWluLWRlbGF5LXJlcS1pbnRlcnZhbD8mbmJzcDsmbmJzcDsmbmJzcDsgaW50ODwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6Ymxh
Y2siIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyAmIzQzOy0tcncgcGVlci1tZWFuLXBhdGgtZGVsYXk/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRpbWUtaW50ZXJ2YWwtdHlwZTwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si
IGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyAmIzQzOy0tcncgbG9nLWFubm91bmNlLWludGVydmFsPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbnQ4PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPiZuYnNwOyZu
YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBhbm5vdW5jZS1y
ZWNlaXB0LXRpbWVvdXQ/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVpbnQ4PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIg
bGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
ICYjNDM7LS1ydyBsb2ctc3luYy1pbnRlcnZhbD8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW50ODwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxh
bmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm
IzQzOy0tcncgZGVsYXktbWVjaGFuaXNtPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZWxh
eS1tZWNoYW5pc20tZW51bWVyYXRpb248L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IGxvZy1taW4tcGRlbGF5LXJl
cS1pbnRlcnZhbD8mbmJzcDsmbmJzcDsgaW50ODwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJz
cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgdmVyc2lvbi1udW1i
ZXI/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVpbnQ4PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4t
VVMiPiZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgdHJhbnNwYXJlbnQtY2xvY2stZGVmYXVs
dC1kczwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29s
b3I6YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyAmIzQzOy0t
cncgY2xvY2staWRlbnRpdHk/Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNsb2NrLWlkZW50aXR5LXR5cGU8
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs
YWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IG51
bWJlci1wb3J0cz8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdWludDE2PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFu
Zz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBkZWxheS1tZWNo
YW5pc20/Jm5ic3A7Jm5ic3A7IGRlbGF5LW1lY2hhbmlzbS1lbnVtZXJhdGlvbjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9
IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgcHJpbWFyeS1kb21h
aW4/Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVpbnQ4PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNw
OyZuYnNwOyAmIzQzOy0tcncgdHJhbnNwYXJlbnQtY2xvY2stcG9ydC1kcy1saXN0KiBbcG9ydC1u
dW1iZXJdPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJj
b2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyAmIzQzOy0tcncgY2xvY2staWRlbnRpdHk/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IGNsb2NrLWlkZW50aXR5LXR5cGU8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBwb3J0LW51bWJlciZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1aW50MTY8L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr
IiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7
LS1ydyBsb2ctbWluLXBkZWxheS1yZXEtaW50ZXJ2YWw/Jm5ic3A7Jm5ic3A7IGludDg8L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBs
YW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1y
dyBmYXVsdHktZmxhZz8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgYm9vbGVhbjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh
biBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHBlZXItbWVhbi1wYXRoLWRlbGF5PyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aW1lLWludGVydmFs
LXR5cGU8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNv
bG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPkluIGNvbnRy
YXN0IHRvIHRoZSBvcmlnaW5hbCAxNTg4IFlBTkcgdHJlZSBkaWFncmFtOjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVO
LVVTIj4mbmJzcDsmbmJzcDsgbW9kdWxlOiBpZXRmLXB0cC1kYXRhc2V0PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4t
VVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgaW5zdGFu
Y2UtbGlzdCogW2luc3RhbmNlLW51bWJlcl08L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGluc3RhbmNlLW51bWJl
ciZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1aW50MTY8L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGRl
ZmF1bHQtZHM8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9
ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgdHdvLXN0ZXAtZmxhZz8mbmJzcDsmbmJz
cDsmbmJzcDsgYm9vbGVhbjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh
biBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBjbG9jay1pZGVudGl0eT8m
bmJzcDsmbmJzcDsgY2xvY2staWRlbnRpdHktdHlwZTwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBu
dW1iZXItcG9ydHM/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVpbnQxNjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVO
LVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7
ICYjNDM7LS1ydyBjbG9jay1xdWFsaXR5PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncg
Y2xvY2stY2xhc3M/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IHVpbnQ4PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJj
b2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyB8Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgY2xvY2stYWNjdXJhY3k/Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVpbnQ4PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQz
Oy0tcncgb2Zmc2V0LXNjYWxlZC1sb2ctdmFyaWFuY2U/Jm5ic3A7Jm5ic3A7IHVpbnQxNjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si
IGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw
OyB8Jm5ic3A7ICYjNDM7LS1ydyBwcmlvcml0eTE/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IHVpbnQ4PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IHByaW9yaXR5Mj8m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdWludDg8L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5n
PSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZu
YnNwOyAmIzQzOy0tcncgZG9tYWluLW51bWJlcj8mbmJzcDsmbmJzcDsmbmJzcDsgdWludDg8L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr
IiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz
cDsgfCZuYnNwOyAmIzQzOy0tcncgc2xhdmUtb25seT8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgYm9vbGVhbjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48
c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgY3VycmVudC1kczwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9
IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5i
c3A7ICYjNDM7LS1ydyBzdGVwcy1yZW1vdmVkPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyB1aW50MTY8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g
c3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgb2Zmc2V0LWZyb20tbWFzdGVy
PyZuYnNwOyB0aW1lLWludGVydmFsLXR5cGU8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgbWVhbi1w
YXRoLWRlbGF5PyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aW1lLWludGVydmFsLXR5cGU8L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr
IiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz
cDsgJiM0MzstLXJ3IHBhcmVudC1kczwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBwYXJlbnQtcG9y
dC1pZGVudGl0eTwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls
ZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGNsb2NrLWlkZW50aXR5
PyZuYnNwOyZuYnNwOyBjbG9jay1pZGVudGl0eS10eXBlPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAm
IzQzOy0tcncgcG9ydC1udW1iZXI/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVpbnQx
Njwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6
YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
fCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBwYXJlbnQtc3RhdHM/Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJvb2xlYW48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncg
b2JzZXJ2ZWQtcGFyZW50LW9mZnNldC1zY2FsZWQtbG9nLXZhcmlhbmNlPyB1aW50MTY8L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBs
YW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwO3wmbmJzcDsg
fCZuYnNwOyAmIzQzOy0tcncgb2JzZXJ2ZWQtcGFyZW50LWNsb2NrLXBoYXNlLWNoYW5nZS1yYXRl
PyZuYnNwOyZuYnNwOyZuYnNwOyBpbnQzMjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U
ZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBncmFuZG1h
c3Rlci1pZGVudGl0eT8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYmluYXJ5PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMi
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0
MzstLXJ3IGdyYW5kbWFzdGVyLWNsb2NrLXF1YWxpdHk8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYj
NDM7LS1ydyBjbG9jay1jbGFzcz8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgdWludDg8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g
c3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBjbG9jay1hY2N1
cmFjeT8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdWludDg8L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyB8Jm5i
c3A7ICYjNDM7LS1ydyBvZmZzZXQtc2NhbGVkLWxvZy12YXJpYW5jZT8mbmJzcDsmbmJzcDsgdWlu
dDE2PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xv
cjpibGFjayIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGdyYW5kbWFzdGVyLXByaW9yaXR5MT8mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdWlu
dDg8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9y
OmJsYWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgZ3JhbmRtYXN0ZXItcHJpb3JpdHkyPyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1aW50
ODwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6
YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
fCZuYnNwOyAmIzQzOy0tcncgdGltZS1wcm9wZXJ0aWVzLWRzPC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0Mzst
LXJ3IGN1cnJlbnQtdXRjLW9mZnNldC12YWxpZD8mbmJzcDsmbmJzcDsgYm9vbGVhbjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxh
bmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8
Jm5ic3A7ICYjNDM7LS1ydyBjdXJyZW50LXV0Yy1vZmZzZXQ/Jm5ic3A7Jm5ic3A7ICZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2ludDE2PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3
IGxlYXA1OT8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgYm9vbGVhbjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBsZWFwNjE/Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IGJvb2xlYW48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5
bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgdGltZS10cmFjZWFibGU/Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IGJvb2xlYW48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw
YW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgZnJlcXVlbmN5LXRyYWNl
YWJsZT8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYm9vbGVhbjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6Ymxh
Y2siIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu
YnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBwdHAtdGltZXNjYWxlPyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyBib29sZWFuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl
PSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IHRpbWUtc291cmNlPyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1aW50ODwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgcG9ydC1kcy1saXN0
KiBbcG9ydC1udW1iZXJdPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu
IHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBwb3J0LW51
bWJlciZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtJmd0OyAuLi9w
b3J0LWlkZW50aXR5L3BvcnQtbnVtYmVyPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1y
dw0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93Ij5wb3J0LWlkZW50aXR5PC9zcGFuPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6Ymxh
Y2siIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBjbG9jay1pZGVudGl0eT8m
bmJzcDsmbmJzcDsgY2xvY2staWRlbnRpdHktdHlwZTwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8
Jm5ic3A7ICYjNDM7LS1ydyBwb3J0LW51bWJlcj8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgdWludDE2PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl
PSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBwb3J0LXN0YXRlPyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwb3J0
LXN0YXRlLWVudW1lcmF0aW9uPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz
cGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyB1bmRl
cmx5aW5nLWludGVyZmFjZT8gaWY6aW50ZXJmYWNlLXJlZjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyAmIzQzOy0tcncgbG9nLW1pbi1kZWxheS1yZXEtaW50ZXJ2YWw/Jm5ic3A7Jm5ic3A7Jm5ic3A7
IGludDg8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNv
bG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHBlZXItbWVhbi1wYXRoLWRl
bGF5PyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyB0aW1lLWludGVydmFsLXR5cGU8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IGxv
Zy1hbm5vdW5jZS1pbnRlcnZhbD8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgaW50ODwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh
biBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgYW5ub3Vu
Y2UtcmVjZWlwdC10aW1lb3V0PyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1aW50ODwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6Ymxh
Y2siIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgbG9nLXN5bmMtaW50ZXJ2YWw/Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IGludDg8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g
c3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IGRlbGF5LW1l
Y2hhbmlzbT8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVsYXktbWVjaGFuaXNtLWVudW1lcmF0
aW9uPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xv
cjpibGFjayIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBsb2ctbWluLXBkZWxheS1yZXEt
aW50ZXJ2YWw/Jm5ic3A7Jm5ic3A7IGludDg8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0Mzst
LXJ3IHZlcnNpb24tbnVtYmVyPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1aW50
ODwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6
YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
JiM0MzstLXJ3IHRyYW5zcGFyZW50LWNsb2NrLWRlZmF1bHQtZHM8L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGNs
b2NrLWlkZW50aXR5PyZuYnNwOyZuYnNwOyZuYnNwOyBjbG9jay1pZGVudGl0eS10eXBlPC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIg
bGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7
ICYjNDM7LS1ydyBudW1iZXItcG9ydHM/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVp
bnQxNjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29s
b3I6YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgfCZuYnNwOyAmIzQzOy0tcncgZGVsYXktbWVjaGFuaXNtPyZuYnNwOyZuYnNwOyBkZWxheS1t
ZWNoYW5pc20tZW51bWVyYXRpb248L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IHByaW1hcnktZG9tYWluPyZuYnNw
OyZuYnNwOyZuYnNwOyB1aW50ODwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48
c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHRyYW5zcGFyZW50LWNsb2NrLXBvcnQtZHMtbGlz
dCogW3BvcnQtbnVtYmVyXTwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh
biBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHBvcnQtbnVtYmVyJm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IC0mZ3Q7IC4uL3BvcnQtaWRlbnRpdHkvcG9ydC1udW1iZXI8L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7
LS1ydyA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxsb3ciPg0KcG9ydC1pZGVudGl0eTwvc3Bh
bj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9y
OmJsYWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGNsb2NrLWlkZW50aXR5PyZuYnNw
OyZuYnNwOyBjbG9jay1pZGVudGl0eS10eXBlPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7
LS1ydyBwb3J0LW51bWJlcj8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdWludDE2PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj
ayIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgbG9nLW1pbi1wZGVsYXktcmVxLWludGVydmFsPyZuYnNw
OyZuYnNwOyBpbnQ4PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0
eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgZmF1bHR5LWZsYWc/Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJvb2xlYW48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr
IiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBwZWVyLW1lYW4tcGF0aC1kZWxheT8mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGltZS1pbnRlcnZhbC10eXBlPC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj
ayIgbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj5JIGFncmVlLCBhc3NpZ25t
ZW50IGFuZCBjb21wYXJpc29uIGNhbiBzdGlsbCBiZSBkb25lIG9uIGNsb2NrLWlkZW50aXR5IGFu
ZCBwb3J0LW51bWJlciBkaXJlY3RseSAod2l0aG91dCBhIHBvcnRJZGVudGl0eSBjb25zdHJ1Y3Qp
IC4gQnV0IHBlb3BsZSB3aG8gYXJlIGZhbWlsaWFyIHdpdGggMTU4OC0yMDA4IG1heSBxdWVzdGlv
biB3aGVyZQ0KIHBvcnRJZGVudGl0eSBpcyBnb25lLjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJzcDs8
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs
YWNrIiBsYW5nPSJFTi1VUyI+My4gSSB0aGluayBsZWFmcmVmIGlzIGEgdmVyeSBnZW5lcmFsIHNl
bWFudGljcyB0aGluZyBpbiBZQU5HIGxhbmd1YWdlLCBpZiBhbnkgdG9vbHMgaGF2ZSBwcm9ibGVt
IHdpdGggdGhpcyBmZWF0dXJlLCBtYXliZSB3ZSBuZWVkIHRvIGNvbnRhY3Qgd2l0aCB0aGUgdG9v
bDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7
IGNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+4oCZPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi
bGFjayIgbGFuZz0iRU4tVVMiPnMNCiBkZXZlbG9wZXIgdG8gc3VwcG9ydCBpdC48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5n
PSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu
IHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPkZpbmFsbHksIG1vcmUgaW5wdXRzIGZy
b20gdGhlIFdHIGFyZSB3ZWxjb21lLjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5n
PSJFTi1VUyI+VGhhbmtzIGFnYWluLDwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj5ZdWFubG9uZzwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxh
bmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw
YW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4t
VVMiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogVElDVE9DIFs8YSBocmVm
PSJtYWlsdG86dGljdG9jLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86
dGljdG9jLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgUm9kbmV5IEN1bW1pbmdz
PGJyPg0KU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMjcsIDIwMTcgMToyNCBBTTxicj4NClRv
OiA8YSBocmVmPSJtYWlsdG86dGljdG9jQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dGljdG9j
QGlldGYub3JnPC9hPjxicj4NClN1YmplY3Q6IFJlOiBbVElDVE9DXSBkcmFmdC1pZXRmLXRpY3Rv
Yy0xNTg4djIteWFuZy0wNSAtIENvbmNlcm4gb3ZlciBwb3J0IGlkZW50aWZpZXI8L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5n
PSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu
IHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPlRoYW5rcyBTZWFuLDwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9
IkVOLVVTIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g
c3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+UmVnYXJkaW5nIHlvdXIgb3RoZXIgY29t
bWVudCBvbiBUTEQuLi4gSSBhZ3JlZS48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFu
Zz0iRU4tVVMiPlJlZ2FyZGluZyB0aGUgY29tbWVudCBiZWxvdyBvbiBwb3J0LWlkZW50aXR5LCBJ
IGFncmVlIHRoYXQgd2UgbmVlZCB0byBkbyBpdCBmb3IgcHJhY3RpY2FsIHJlYXNvbnMuPC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIg
bGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48
c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj5JbiAxNTg4LTIwMDgsIHRoZXJl
IGlzIGEgZGlzdGluY3QgZGF0YXNldCBtZW1iZXIgZm9yIHBvcnREUy5wb3J0SWRlbnRpdHksIHdo
aWNoIDUuMy41IHNwZWNpZmllcyBhcyB1c2luZyB0eXBlIFBvcnRJZGVudGl0eTo8L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5n
PSJFTi1VUyI+Jm5ic3A7IHN0cnVjdCBQb3J0SWRlbnRpdHkgezwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4m
bmJzcDsmbmJzcDsmbmJzcDsgQ2xvY2tJZGVudGl0eSBjbG9ja0lkZW50aXR5Ozwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9
IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsgVUludGVnZXIgcG9ydE51bWJlcjs8L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5n
PSJFTi1VUyI+Jm5ic3A7IH08L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw
YW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4t
VVMiPklmIHdlIGludGVycHJldCB0aGUgMTU4OC0yMDA4IGRhdGFzZXRzIGFzIGFuIGluZm9ybWF0
aW9uIG1vZGVsLCBhbmQgYXBwbHkgdGhhdCBhcyBkaXJlY3RseSBhcyBwb3NzaWJsZSB0byBhIFlB
TkcgZGF0YSBtb2RlbCwgcG9ydERTLnBvcnRJZGVudGl0eSBpcyBhIGNvbnRhaW5lciwgd2hpY2gg
aXMgd2hhdCB3ZSBoYXZlIHNvIGZhci4gVGhhdA0KIGludHJvZHVjZXMgYSBjaGFsbGVuZ2UsIGJl
Y2F1c2Ugd2Ugd2FudCB0byB1c2UgcG9ydERTLnBvcnRJZGVudGl0eS5wb3J0TnVtYmVyIGFzIHRo
ZSBrZXkgdG8gdGhlIGxpc3Qgb2YgcG9ydERTJ3MuIFdlIHNvbHZlZCB0aGF0IGNoYWxsZW5nZSB3
aXRoIGEgbGVhZnJlZiwgYnV0IEknZCBhZ3JlZSB0aGF0IGlzIHVnbHkuPC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4t
VVMiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls
ZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj5Zb3VyIHByb3Bvc2FsIGNoYW5nZXMgcG9ydERT
LnBvcnRJZGVudGl0eSBmcm9tIGEgY29udGFpbmVyIHRvIGEgZ3JvdXBpbmcsIHNvIHRoYXQgaXQg
cG9ydERTLnBvcnRJZGVudGl0eS5wb3J0TnVtYmVyIGNhbiBiZSB1c2VkIGFzIHRoZSBrZXkgd2l0
aG91dCBhIGxlYWZyZWYuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu
IHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVT
Ij5UaGUgZG93bnNpZGUgaXMgdGhhdCBpZi93aGVuIGEgWUFORyBtYW5hZ2VtZW50IGNsaWVudCB0
cmllcyB0byAmcXVvdDtnZXQmcXVvdDsgcG9ydERTLnBvcnRJZGVudGl0eSwgaXQgZG9lc24ndCB3
b3JrLi4uIHRoZXJlIGlzIG5vIHBvcnRJZGVudGl0eSB0byBnZXQuPC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMi
PiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0i
Y29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj5QZXJzb25hbGx5LCBJIHRoaW5rIHRoYXQgZG93bnNp
ZGUgaXMgd29ydGggaXQuIE9uZSBjYW4gYXJndWUgdGhhdCB5b3VyIHByb3Bvc2FsIHN0aWxsIGNv
bmZvcm1zIHRvIHRoZSAxNTg4LTIwMDggaW5mb3JtYXRpb24gbW9kZWwgZm9yIG1hbmFnZW1lbnQs
IGluIHRoYXQgcG9ydERTLnBvcnRJZGVudGl0eSBzdGlsbCAmcXVvdDtleGlzdHMmcXVvdDsgaW4g
YQ0KIG1hbm5lciB0aGF0IG1ha2VzIHNlbnNlIGZvciBZQU5HLjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4m
bmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNv
bG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+Um9kbmV5PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPiZuYnNwOyA8
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs
YWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IDwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHls
ZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+RnJv
bTogVElDVE9DIFs8YSBocmVmPSJtYWlsdG86dGljdG9jLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdl
dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDsgdGV4dC1kZWNvcmF0aW9u
Om5vbmUiPm1haWx0bzp0aWN0b2MtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+XSBPbiBCZWhh
bGYgT2YgU2VhbiBDb25kb248L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw
YW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+U2VudDogVHVlc2RheSwgU2VwdGVt
YmVyIDI2LCAyMDE3IDEwOjM4IEFNPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPlRvOiA8YSBocmVmPSJtYWls
dG86dGljdG9jQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQo8c3BhbiBzdHlsZT0iY29sb3I6
d2luZG93dGV4dDsgdGV4dC1kZWNvcmF0aW9uOm5vbmUiPnRpY3RvY0BpZXRmLm9yZzwvc3Bhbj48
L2E+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xv
cjpibGFjayIgbGFuZz0iRU4tVVMiPlN1YmplY3Q6IFtUSUNUT0NdIGRyYWZ0LWlldGYtdGljdG9j
LTE1ODh2Mi15YW5nLTA1IC0gQ29uY2VybiBvdmVyIHBvcnQgaWRlbnRpZmllcjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9
IkVOLVVTIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g
c3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+V2l0aCByZWZlcmVuY2UgdG8gJnF1b3Q7
WUFORyBEYXRhIE1vZGVsIGZvciBJRUVFIDE1ODh2MiZxdW90Ow0KPGEgaHJlZj0iaHR0cHM6Ly91
cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9y
Z19odG1sX2RyYWZ0LTJEaWV0Zi0yRHRpY3RvYy0yRDE1ODh2Mi0yRHlhbmctMkQwNSZhbXA7ZD1E
d01GQXcmYW1wO2M9SV8wWXdvS3k3ejVMTVRWZHlPNllDaUUydXpJMWpqWlp1SVBlbGNTaml4QSZh
bXA7cj1XQTcxc2YybzdEdzdDYlloRnQyNERQanQzbEp1dXBzd1dZZG5ib0tiWjhrJmFtcDttPWpL
SGN6Vk5MTi1LdVYySFJaa2JFWlkxU3psQ0RfQXp0a2FXU2NjcnFCSTgmYW1wO3M9bXNoN0E3X09n
SFoxbDY1RG42X0xoaURJWGtYcEZlaUxHbUtiS3hzcVhXdyZhbXA7ZSIgdGFyZ2V0PSJfYmxhbmsi
Pg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7IHRleHQtZGVjb3JhdGlvbjpub25lIj5o
dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xz
LmlldGYub3JnX2h0bWxfZHJhZnQtMkRpZXRmLTJEdGljdG9jLTJEMTU4OHYyLTJEeWFuZy0yRDA1
JmFtcDtkPUR3TUZBdyZhbXA7Yz1JXzBZd29LeTd6NUxNVFZkeU82WUNpRTJ1ekkxampaWnVJUGVs
Y1NqaXhBJmFtcDtyPVdBNzFzZjJvN0R3N0NiWWhGdDI0RFBqdDNsSnV1cHN3V1lkbmJvS2JaOGsm
YW1wO209aktIY3pWTkxOLUt1VjJIUlprYkVaWTFTemxDRF9BenRrYVdTY2NycUJJOCZhbXA7cz1t
c2g3QTdfT2dIWjFsNjVEbjZfTGhpRElYa1hwRmVpTEdtS2JLeHNxWFd3JmFtcDtlPC9zcGFuPjwv
YT49DQo8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNv
bG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPkkgaGF2ZSBh
IGNvbmNlcm4gYWJvdXQgdGhlIHN0cnVjdHVyZSBvZiB0aGUgWUFORywgYW5kIGhvdyB0aGUgbGlz
dHMgcG9ydC1kcy1saXN0IGFuZCB0cmFuc3BhcmVudC1jbG9jay1wb3J0LWRzLWxpc3QgYXJlIGlu
ZGV4ZWQgd2l0aCBhIGxlYWYgd2hpY2ggaXMgYSBsZWFmcmVmLjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4m
bmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNv
bG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+VGhlIHN0cnVjdHVyZSBzZWVtcyB1bm5lY2Vzc2FyaWx5
IGNvbXBsZXggLSBwb3J0LW51bWJlciBpcyByZXByZXNlbnRlZCBhcyBhIGxlYWYgZGlyZWN0bHkg
YmVuZWF0aCB0aGUgbGlzdCAodG8gYmUgdXNlZCBhcyBrZXkpIGFuZCBhZ2FpbiB1bmRlciB0aGUg
cG9ydC1pZGVudGl0eSBjb250YWluZXIuIEl0IGlzIHN0cnVjdHVyZWQgaW4gYQ0KIHdheSB0aGF0
IEkgYmVsaWV2ZSB3b3VsZCBtYWtlIGl0IGRpZmZpY3VsdCB0byB3b3JrIHdpdGggc29tZSBZQU5H
IHRvb2xzIGluIHRoZSBtYXJrZXQuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9
IkVOLVVTIj5UaGUgcHVycG9zZSBvZiBwb3J0LWlkZW50aXR5IGNvbnRhaW5lciBpcyBub3QgY2xl
YXIgZnJvbSB0aGUgZG9jdW1lbnQgLSBpdCB3b3VsZCBhY2hpZXZlIHRoZSBzYW1lIHB1cnBvc2Ug
aWYgaXQgd2FzIGxlZnQgb3V0IG9mIHBvcnQtZHMtZW50cnkgYW5kIHRyYW5zcGFyZW50LWNsb2Nr
LXBvcnQtZHMtZW50cnkgYW5kIGluc3RlYWQgdGhlDQogZ3JvdXBpbmcgcG9ydC1pZGVudGl0eS1n
cm91cGluZyBpbmNsdWRlZCBkaXJlY3RseS48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIg
bGFuZz0iRU4tVVMiPlNlZSB0aGUgYXR0YWNoZWQgZmlsZXMgYXMgb3JpZ2luYWwsIGEgbW9kaWZp
ZWQgdmVyc2lvbiBhbmQgYXMgYSBwYXRjaCBmaWxlLjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj4mbmJzcDs8
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs
YWNrIiBsYW5nPSJFTi1VUyI+U2VhbiBDb25kb248L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs
YWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+PT09PT09PT09
PT09PT09PT09PT09PT08L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g
c3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJFTi1VUyI+U2VhbiBDb25kb248L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIiBsYW5nPSJF
Ti1VUyI+U3lzdGVtICZhbXA7IFNvZnR3YXJlIEFyY2hpdGVjdDwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj5G
cmVxdWVuY3kgJmFtcDsgVGltaW5nIERpdmlzaW9uPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPk1pY3Jvc2Vt
aSBJbmMuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJj
b2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPjxhIGhyZWY9Im1haWx0bzpzZWFuLmNvbmRvbkBtaWNy
b3NlbWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7
IHRleHQtZGVjb3JhdGlvbjpub25lIj5tYWlsdG86c2Vhbi5jb25kb25AbWljcm9zZW1pLmNvbTwv
c3Bhbj48L2E+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl
PSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVOLVVTIj5fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siIGxhbmc9IkVO
LVVTIj5USUNUT0MgbWFpbGluZyBsaXN0PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayIgbGFuZz0iRU4tVVMiPjxhIGhyZWY9Im1haWx0
bzpUSUNUT0NAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6d2lu
ZG93dGV4dDsgdGV4dC1kZWNvcmF0aW9uOm5vbmUiPlRJQ1RPQ0BpZXRmLm9yZzwvc3Bhbj48L2E+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpi
bGFjayIgbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vdGljdG9jIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRv
d3RleHQ7IHRleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL3RpY3RvYzwvc3Bhbj48L2E+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_640F4C69F839A64C8949EF04FAAEE44679F2583Eavsrvexchmbx1mi_--


From nobody Thu Sep 28 06:25:35 2017
Return-Path: 
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 CF4AE1344EA; Thu, 28 Sep 2017 06:25:27 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4wXtQLLuMiu; Thu, 28 Sep 2017 06:25: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 DA02C134749; Thu, 28 Sep 2017 06:24:44 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 50CFC1AE02A7; Thu, 28 Sep 2017 15:24:42 +0200 (CEST)
Date: Thu, 28 Sep 2017 15:23:12 +0200 (CEST)
Message-Id: <20170928.152312.261607006753399632.mbj@tail-f.com>
To: jiangyuanlong@huawei.com
Cc: sean.condon@microsemi.com, netmod@ietf.org, tictoc@ietf.org
From: Martin Bjorklund 
In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5CB62E@dggeml507-mbx.china.huawei.com>
References: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5C9C01@dggeml507-mbx.china.huawei.com> <640F4C69F839A64C8949EF04FAAEE44679F25561@avsrvexchmbx1.microsemi.net> <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5CB62E@dggeml507-mbx.china.huawei.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [netmod] draft-ietf-tictoc-1588v2-yang-05 - Concern over port identifier
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Sep 2017 13:25:28 -0000

Smlhbmd5dWFubG9uZyA8amlhbmd5dWFubG9uZ0BodWF3ZWkuY29tPiB3cm90ZToNCj4gU2VhbiwN
Cj4gDQo+IE15IHBlcnNvbmFsIG9waW5pb24gaXMgdGhhdCBpdCBjYW4gd29yaywgYnV0IEkgd291
bGQgbGlrZSB0byBhc2sgZm9yDQo+IG1vcmUgb3BpbmlvbnMgZnJvbSBvdXIgbmV0bW9kIGV4cGVy
dHM7KQ0KPiANCj4gSGkgbmV0bW9kIGV4cGVydHMsDQo+IENvbnNpZGVyaW5nIHRoZSBmb2xsb3dp
bmcgc2FtcGxlIG1vZHVsZSwgbXktbGlzdCBpcyBhIGxpc3QsIGFuZCBpdA0KPiBuZWVkcyB0byB1
c2UgYSBsZWFmIG1lbWJlciAicG9ydC1udW1iZXIiIGluIG15LXBvcnQtY29udGFpbmVyIGFzIGEN
Cj4ga2V5Lg0KPiBXZSBub3cgaGF2ZSAzIG9wdGlvbnM6DQo+IDEuDQo+ICAgbGlzdCBteS1saXN0
IHsNCj4gICAgIGtleSAicG9ydC1udW1iZXIiOw0KPiAgICAgbGVhZiBwb3J0LW51bWJlciB7DQo+
ICAgICAgICB0eXBlIHVpbnQxNjsNCj4gICAgIH0NCj4gDQo+ICAgICBjb250YWluZXIgbXktcG9y
dC1jb250YWluZXIgew0KPiAgICAgICAgIGxlYWYgcG9ydC1udW1iZXIgew0KPiAgICAgICAgICAg
dHlwZSB1aW50MTY7DQo+ICAgICAgICAgfQ0KPiAgICAgICAgICBsZWFmIG90aGVyLWxlYWYgew0K
PiAgICAgICAgICAgIC4uLg0KPiAgICAgICAgICB9DQo+ICAgICB9DQo+ICAgfQ0KPiBCdXQgdGhp
cyBkb2VzIG5vdCB3b3JrIGZvciB0aGVyZSBpcyBjb21waWxpbmcgZXJyb3IuDQoNCldoeSB3b3Vs
ZG4ndCB0aGlzIHdvcms/DQoNCkkgc3VzcGVjdCB5b3UgbWVhbnQ6DQoNCiAgIGxpc3QgbXktbGlz
dCB7DQogICAgIGtleSAicG9ydC1udW1iZXIiOw0KIA0KICAgICBjb250YWluZXIgbXktcG9ydC1j
b250YWluZXIgew0KICAgICAgICAgbGVhZiBwb3J0LW51bWJlciB7DQogICAgICAgICAgdHlwZSB1
aW50MTY7DQogICAgICAgICB9DQogICAgICAgICAgbGVhZiBvdGhlci1sZWFmIHsNCiAgICAgICAg
ICAgIC4uLg0KICAgICAgICAgIH0NCiAgICAgfQ0KICAgfQ0KDQoNCj4gMi4NCj4gICBsaXN0IG15
LWxpc3Qgew0KPiAgICAga2V5ICJwb3J0LW51bWJlciI7DQo+ICAgICBsZWFmIHBvcnQtbnVtYmVy
IHsNCj4gICAgICAgIHR5cGUgdWludDE2Ow0KPiAgICAgfQ0KPiAgICAgY29udGFpbmVyIG15LXBv
cnQtY29udGFpbmVyIHsNCj4gICAgICAgICBsZWFmIHBvcnQtbnVtYmVyIHsNCj4gICAgICAgICAg
ICAgdHlwZSBsZWFmcmVmew0KPiAgICAgICAgICAgICAgIHBhdGggIi4uLy4uL3BvcnQtbnVtYmVy
IjsNCj4gICAgICAgICAgICAgfQ0KPiAgICAgICAgIH0NCj4gICAgICAgICAgbGVhZiBvdGhlci1s
ZWFmIHsNCj4gICAgICAgICAgICAuLi4NCj4gICAgICAgICAgfQ0KPiAgICAgfQ0KPiAgIH0NCj4g
T3B0aW9uIDIgY2FuIHBhcnNlLCB0aG91Z2ggbGVhZnJlZiBpbiBhIHN1Yi1tb2R1bGUgc2VlbXMg
bm90IHZlcnkNCj4gbmF0dXJhbC4NCj4gDQo+IDMuDQo+ICAgbGlzdCBteS1saXN0IHsNCj4gICAg
IGtleSAicG9ydC1udW1iZXIiOw0KPiAgICAgbGVhZiBwb3J0LW51bWJlciB7DQo+ICAgICAgICB0
eXBlIGxlYWZyZWZ7DQo+ICAgICAgICAgICBwYXRoICIuLi9teS1wb3J0LWNvbnRhaW5lci9wb3J0
LW51bWJlciI7DQo+ICAgICAgICB9DQo+ICAgICB9DQo+ICAgICBjb250YWluZXIgbXktcG9ydC1j
b250YWluZXIgew0KPiAgICAgICAgIGxlYWYgcG9ydC1udW1iZXIgew0KPiAgICAgICAgICAgdHlw
ZSB1aW50MTY7DQo+ICAgICAgICAgfQ0KPiAgICAgICAgICBsZWFmIG90aGVyLWxlYWYgew0KPiAg
ICAgICAgICAgIC4uLg0KPiAgICAgICAgICB9DQo+ICAgICB9DQo+ICAgfQ0KPiANCj4gT3B0aW9u
IDMgY2FuIGFsc28gcGFyc2UsIHRob3VnaCBsZWFmcmVmIHNlZW1zIG5vdCBhIHZlcnkgbmF0dXJh
bA0KPiBrZXkuIFdoYXQgaXMgeW91ciBmYXZvcml0ZSBvcHRpb24/IE9yIGRvIHlvdSBoYXZlIGFu
eSBiZXR0ZXIgc2NoZW1lcz8NCg0KDQpIYXZpbmcgYSBsZWFmcmVmIGxpa2UgaW4gb3B0aW9uIDIg
b3IgMyBpcyBqdXN0IHJlZHVuZGFudCBhbmQgYSBoYXNzbGUNCmZvciB0aGUgY2xpZW50LiAgSW4g
b3JkZXIgdG8gY3JlYXRlIGEgYSBsaXN0IGVudHJ5LCB0aGUgY2xpZW50IHdvdWxkDQpoYXZlIHRv
IGZpcnN0IHByb3ZpZGUgdGhlIHBvcnQtbnVtYmVyIHZhbHVlIG9uY2UgZm9yIHRoZSBrZXksIGFu
ZCB0aGVuDQphZ2FpbiB0aGUgZXhhY3Qgc2FtZSB2YWx1ZSBpbiB0aGUgY29udGFpbmVyOg0KDQog
IDxteS1saXN0Pg0KICAgIDxwb3J0LW51bWJlcj4yNTwvcG9ydC1udW1iZXI+DQogICAgPG15LXBv
cnQtY29udGFpbmVyPg0KICAgICAgPHBvcnQtbnVtYmVyPjI1PC9wb3J0LW51bWJlcj4NCiAgICAg
IDxvdGhlci1sZWFmPi4uLjwvb3RoZXItbGVhZj4NCiAgICA8L215LXBvcnQtY29udGFpbmVyPg0K
ICA8L215LWxpc3Q+DQoNCk5vdGUgdGhhdCBib3RoICJwb3J0LW51bWJlciIgTVVTVCBiZSBnaXZl
biB0aGUgZXhhY3Qgc2FtZSB2YWx1ZSBieSB0aGUNCmNsaWVudC4NCg0KSW4gWUFORywga2V5IGxl
YWZzIGNhbm5vdCBiZSBuZXN0ZWQgdW5kZXIgY29udGFpbmVycy4gIEkgd291bGQgc2ltcGx5DQpo
YXZlIHRoZSBrZXkgb24gdGhlIHRvcCBvZiB0aGUgbGlzdCwgYW5kIG5vdCBpbiB0aGUgY29udGFp
bmVyLg0KDQooSXQgc2VlbXMgdGhpcyBpcyB3aGF0IG90aGVycyBoYXZlIHByb3Bvc2VkIGFzIHdl
bGwgaW4gdGhpcyB0aHJlYWQuKQ0KDQoNCg0KL21hcnRpbg0KDQoNCg0KDQoNCj4gWW91ciBvcGlu
aW9ucyBhcmUgdmVyeSBpbXBvcnRhbnQgZm9yIG91ciByZXZpc2lvbiBvZiB0aGlzIGRyYWZ0Lg0K
PiANCj4gVGhhbmtzLA0KPiBZdWFubG9uZw0KPiANCj4gDQo+IEZyb206IFNlYW4gQ29uZG9uIFtt
YWlsdG86c2Vhbi5jb25kb25AbWljcm9zZW1pLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBTZXB0
ZW1iZXIgMjcsIDIwMTcgNzoxMSBQTQ0KPiBUbzogSmlhbmd5dWFubG9uZw0KPiBDYzogdGljdG9j
QGlldGYub3JnOyBSb2RuZXkgQ3VtbWluZ3MNCj4gU3ViamVjdDogUkU6IGRyYWZ0LWlldGYtdGlj
dG9jLTE1ODh2Mi15YW5nLTA1IC0gQ29uY2VybiBvdmVyIHBvcnQNCj4gaWRlbnRpZmllcg0KPiAN
Cj4gVGhhbmtzIGd1eXMgZm9yIHlvdXIgcmVzcG9uc2VzLg0KPiANCj4gSSBhY2NlcHQgeW91ciBw
b2ludHMgdG8ga2VlcCB0aGUgc3RydWN0dXJlIGFzIGFsaWduZWQgdG8gdGhlIElFRUUgMTU4OA0K
PiBzdGFuZGFyZCBhcyBwb3NzaWJsZS4NCj4gDQo+IE9uZSBhbHRlcm5hdGUgc3VnZ2VzdGlvbiB0
aGF0IEkgd291bGQgbWFrZSwgaXMgdGhhdCB0aGUgcG9ydC1udW1iZXINCj4gY3VycmVudGx5IGRl
ZmluZWQgYXMgbGVhZnJlZiBzaG91bGQgYmUgbWFkZSB0aGUgcmVhbCBhdHRyaWJ1dGUNCj4gKGku
ZS4gdWludDE2KSBhbmQgdGhhdCB0aGUgcG9ydC1udW1iZXIgaW5zaWRlIHBvcnQtaWRlbnRpdHkg
Y29udGFpbmVyDQo+IHNob3VsZCBiZSBtYWRlIGluIHRvIHRoZSBsZWFmIHJlZiAoYW5kIHNldCB0
byBtYW5kYXRvcnkgdHJ1ZSkuDQo+IA0KPiBUaGUgcmVhc29uIEkgc2F5IHRoaXMgaXMgdGhhdA0K
PiANCj4gICAxLiAgWE1MIG1vZGVscyBhcmUgdXN1YWxseSBuYXZpZ2F0ZWQgYW5kIGNvbnN0cnVj
dGVkIHJvb3QtdG8tbGVhZiwgYW5kDQo+ICAgdGhlIHdheSBpdCdzIHBvcnRyYXllZCBhdCB0aGUg
bW9tZW50IGlzIHRoYXQgcG9ydC1udW1iZXIgbGVhZnJlZg0KPiAgIHBvaW50cyB0byBzb21ldGhp
bmcgdGhhdCBtYXkgbm90IGV4aXN0IGF0IHRoZSB0aW1lIGl0IGlzIGJlaW5nDQo+ICAgZGVmaW5l
ZC4gVGhpcyBtYWtlcyBpdCBkaWZmaWN1bHQgdG8gaW1wbGVtZW50Lg0KPiAgIDIuICBBbHNvIHBv
cnQtaWRlbnRpdHkvcG9ydC1udW1iZXIgaXMgbm90ICJtYW5kYXRvcnkgdHJ1ZSIgbWVhbmluZw0K
PiAgIHRoYXQgaXQgY291bGQgYmUgbGVmdCBvdXQgYWx0b2dldGhlci4gSXQncyBub3QgdmFsaWQg
Zm9yIGl0IHRvIGhhdmUgYQ0KPiAgIGRlZmF1bHQgdmFsdWUgZWl0aGVyIHNpbmNlIGV2ZXJ5IGl0
ZW0gaW4gdGhlIGxpc3Qgd2lsbCBuZWVkIGENCj4gICBkaWZmZXJlbnQgaWRlbnRpZmllci4NCj4g
DQo+IFdpdGggdGhpcyBzdWdnZXN0aW9uIHRoZSBzdHJ1Y3R1cmUgeW91IHJlcXVpcmUgd2l0aCBw
b3J0LWlkZW50aXR5DQo+IHN0aWxsIGV4aXN0cywgYnV0IG5vdyB0aGUgaW1wbGVtZW50YXRpb24g
aXMgbW9yZSBzdHJhaWdodGZvcndhcmQsIGFuZA0KPiB0aGUgY2hhbmdlIHdpbGwgYmUgdHJhbnNw
YXJlbnQgdG8gYW4gZW5kIHVzZXIuDQo+IA0KPiANCj4gQmVzdCByZWdhcmRzLCBTZWFuDQo+ID09
PT09PT09PT09PT09PT09PT09PT09DQo+IFNlYW4gQ29uZG9uDQo+IFN5c3RlbSAmIFNvZnR3YXJl
IEFyY2hpdGVjdA0KPiBGcmVxdWVuY3kgJiBUaW1pbmcgRGl2aXNpb24NCj4gTWljcm9zZW1pIElu
Yy4NCj4gc2Vhbi5jb25kb25AbWljcm9zZW1pLmNvbTxtYWlsdG86c2Vhbi5jb25kb25AbWljcm9z
ZW1pLmNvbT4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEZyb206
IEppYW5neXVhbmxvbmcgW2ppYW5neXVhbmxvbmdAaHVhd2VpLmNvbV0NCj4gU2VudDogMjcgU2Vw
dGVtYmVyIDIwMTcgMDg6MDUNCj4gVG86IFNlYW4gQ29uZG9uDQo+IENjOiB0aWN0b2NAaWV0Zi5v
cmc8bWFpbHRvOnRpY3RvY0BpZXRmLm9yZz47IFJvZG5leSBDdW1taW5ncw0KPiBTdWJqZWN0OiBS
RTogZHJhZnQtaWV0Zi10aWN0b2MtMTU4OHYyLXlhbmctMDUgLSBDb25jZXJuIG92ZXIgcG9ydA0K
PiBpZGVudGlmaWVyDQo+IEVYVEVSTkFMIEVNQUlMDQo+IA0KPiBEZWFyIFNlYW4sDQo+IA0KPiAN
Cj4gDQo+IFRoYW5rIHlvdSBhIGxvdCBmb3IgZGl2aW5nIGludG8gdGhlIHRlY2huaWNhbCBkZXRh
aWxzIG9mIHRoaXMNCj4gbW9kdWxlLiBKdXN0IGFzIFJvZG5leSBzYWlkLCBpdCBpcyBhIGNoYWxs
ZW5nZSBvZiAxNTg4IGluZm8gbW9kZWwgdG8NCj4gWUFORywgYW5kIHdlIHVzZSB0aGUgbGVhZnJl
ZiBvZiBZQU5HIHRvIHdvcmsgYXJvdW5kIGl0Lg0KPiANCj4gSSB3b3VsZCBsaWtlIHRvIHByb3Zp
ZGUgYSBsaXR0bGUgbW9yZSBiYWNrZ3JvdW5kcyBvbiB0aGUgdHJhZGVvZmY6DQo+IA0KPiANCj4g
DQo+IDEuIEl0IHNheXMgaW4gU2VjLiA3LjUuMi4xIGluIElFRUUgMTU4OC0yMDA4OiBwb3J0SWRl
bnRpdHkgaXMgYSBtZW1iZXINCj4gb2YgdGhlIHBvcnREUyBkYXRhIHNldC4gQSBwb3J0SWRlbnRp
dHkgY29uc2lzdHMgb2YgdHdvIGF0dHJpYnV0ZXMsIGFzDQo+IA0KPiBmb2xsb3dzOg0KPiANCj4g
4o6vIHBvcnRJZGVudGl0eS5jbG9ja0lkZW50aXR5DQo+IA0KPiDijq8gcG9ydElkZW50aXR5LnBv
cnROdW1iZXINCj4gDQo+IEZ1cnRoZXJtb3JlLCB0aGUgInBvcnREUy5wb3J0SWRlbnRpdHkiIGF0
dHJpYnV0ZSBpcyBtZW50aW9uZWQgcXVpdGUgYQ0KPiBmZXcgdGltZXMgaW4gMTU4OC0yMDA4LCBl
c3BlY2lhbGx5IGluIFRhYmxlIDE3IGFuZCB1bmRlciBUYWJsZSA2MSwNCj4gd2l0aCBhIGhpbnQg
dGhhdCBhc3NpZ25tZW50IGFuZCBjb21wYXJpc29uIGNhbiBiZSBkb25lIG9uIHRoaXMgbWVtYmVy
DQo+IGRpcmVjdGx5LCB0aHVzIGl0IHNlZW1zIHRvIG1lIHBvcnRJZGVudGl0eSBpcyBhbiBpbXBv
cnRhbnQgYW5kIHdlbGwNCj4gdW5kZXJzdG9vZCBjb25zdHJ1Y3QgaW4gdGhlIDE1ODggc3BlY2lm
aWNhdGlvbi4NCj4gDQo+IA0KPiANCj4gMi4gSWYgd2UgY2hhbmdlIHBvcnREUy5wb3J0SWRlbnRp
dHkgZnJvbSBhIGNvbnRhaW5lciB0byBhIGdyb3VwaW5nLA0KPiB0aGVuIHRoZXJlIGlzIG5vIHBv
cnRJZGVudGl0eSBmb3IgcG9ydERTIGFuZCB0cmFuc3BhcmVudGNsb2NrUG9ydERTIGluDQo+IHRo
ZSByZXN1bHRpbmcgdHJlZSBkaWFncmFtOg0KPiANCj4gDQo+IA0KPiBtb2R1bGU6IGlldGYtcHRw
LWRhdGFzZXQNCj4gDQo+ICAgICArLS1ydyBpbnN0YW5jZS1saXN0KiBbaW5zdGFuY2UtbnVtYmVy
XQ0KPiANCj4gICAgIHwgICstLXJ3IGluc3RhbmNlLW51bWJlciAgICAgICB1aW50MTYNCj4gDQo+
ICAgICB8ICArLS1ydyBkZWZhdWx0LWRzDQo+IA0KPiAgICAgfCAgfCAgKy0tcncgdHdvLXN0ZXAt
ZmxhZz8gICAgYm9vbGVhbg0KPiANCj4gICAgIHwgIHwgICstLXJ3IGNsb2NrLWlkZW50aXR5PyAg
IGNsb2NrLWlkZW50aXR5LXR5cGUNCj4gDQo+ICAgICB8ICB8ICArLS1ydyBudW1iZXItcG9ydHM/
ICAgICB1aW50MTYNCj4gDQo+ICAgICB8ICB8ICArLS1ydyBjbG9jay1xdWFsaXR5DQo+IA0KPiAg
ICAgfCAgfCAgfCAgKy0tcncgY2xvY2stY2xhc3M/ICAgICAgICAgICAgICAgICAgdWludDgNCj4g
DQo+ICAgICB8ICB8ICB8ICArLS1ydyBjbG9jay1hY2N1cmFjeT8gICAgICAgICAgICAgICB1aW50
OA0KPiANCj4gICAgIHwgIHwgIHwgICstLXJ3IG9mZnNldC1zY2FsZWQtbG9nLXZhcmlhbmNlPyAg
IHVpbnQxNg0KPiANCj4gICAgIHwgIHwgICstLXJ3IHByaW9yaXR5MT8gICAgICAgIHVpbnQ4DQo+
IA0KPiAgICAgfCAgfCAgKy0tcncgcHJpb3JpdHkyPyAgICAgICAgdWludDgNCj4gDQo+ICAgICB8
ICB8ICArLS1ydyBkb21haW4tbnVtYmVyPyAgICB1aW50OA0KPiANCj4gICAgIHwgIHwgICstLXJ3
IHNsYXZlLW9ubHk/ICAgICAgIGJvb2xlYW4NCj4gDQo+ICAgICB8ICArLS1ydyBjdXJyZW50LWRz
DQo+IA0KPiAgICAgfCAgfCAgKy0tcncgc3RlcHMtcmVtb3ZlZD8gICAgICAgIHVpbnQxNg0KPiAN
Cj4gICAgIHwgIHwgICstLXJ3IG9mZnNldC1mcm9tLW1hc3Rlcj8gICB0aW1lLWludGVydmFsLXR5
cGUNCj4gDQo+ICAgICB8ICB8ICArLS1ydyBtZWFuLXBhdGgtZGVsYXk/ICAgICAgdGltZS1pbnRl
cnZhbC10eXBlDQo+IA0KPiAgICAgfCAgKy0tcncgcGFyZW50LWRzDQo+IA0KPiAgICAgfCAgfCAg
Ky0tcncgcGFyZW50LXBvcnQtaWRlbnRpdHkNCj4gDQo+ICAgICB8ICB8ICB8ICArLS1ydyBjbG9j
ay1pZGVudGl0eT8gICBjbG9jay1pZGVudGl0eS10eXBlDQo+IA0KPiAgICAgfCAgfCAgfCAgKy0t
cncgcG9ydC1udW1iZXI/ICAgICAgdWludDE2DQo+IA0KPiAgICAgfCAgfCAgKy0tcncgcGFyZW50
LXN0YXRzPyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJvb2xlYW4NCj4gDQo+ICAg
ICB8ICB8ICArLS1ydyBvYnNlcnZlZC1wYXJlbnQtb2Zmc2V0LXNjYWxlZC1sb2ctdmFyaWFuY2U/
ICAgdWludDE2DQo+IA0KPiAgICAgfCAgfCAgKy0tcncgb2JzZXJ2ZWQtcGFyZW50LWNsb2NrLXBo
YXNlLWNoYW5nZS1yYXRlPyAgICAgIGludDMyDQo+IA0KPiAgICAgfCAgfCAgKy0tcncgZ3JhbmRt
YXN0ZXItaWRlbnRpdHk/ICAgICAgICAgICAgICAgICAgICAgICAgIGJpbmFyeQ0KPiANCj4gICAg
IHwgIHwgICstLXJ3IGdyYW5kbWFzdGVyLWNsb2NrLXF1YWxpdHkNCj4gDQo+ICAgICB8ICB8ICB8
ICArLS1ydyBjbG9jay1jbGFzcz8gICAgICAgICAgICAgICAgICB1aW50OA0KPiANCj4gICAgIHwg
IHwgIHwgICstLXJ3IGNsb2NrLWFjY3VyYWN5PyAgICAgICAgICAgICAgIHVpbnQ4DQo+IA0KPiAg
ICAgfCAgfCAgfCAgKy0tcncgb2Zmc2V0LXNjYWxlZC1sb2ctdmFyaWFuY2U/ICAgdWludDE2DQo+
IA0KPiAgICAgfCAgfCAgKy0tcncgZ3JhbmRtYXN0ZXItcHJpb3JpdHkxPyAgICAgICAgICAgICAg
ICAgICAgICAgIHVpbnQ4DQo+IA0KPiAgICAgfCAgfCAgKy0tcncgZ3JhbmRtYXN0ZXItcHJpb3Jp
dHkyPyAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQ4DQo+IA0KPiAgICAgfCAgKy0tcncgdGlt
ZS1wcm9wZXJ0aWVzLWRzDQo+IA0KPiAgICAgfCAgfCAgKy0tcncgY3VycmVudC11dGMtb2Zmc2V0
LXZhbGlkPyAgIGJvb2xlYW4NCj4gDQo+ICAgICB8ICB8ICArLS1ydyBjdXJyZW50LXV0Yy1vZmZz
ZXQ/ICAgICAgICAgaW50MTYNCj4gDQo+ICAgICB8ICB8ICArLS1ydyBsZWFwNTk/ICAgICAgICAg
ICAgICAgICAgICAgYm9vbGVhbg0KPiANCj4gICAgIHwgIHwgICstLXJ3IGxlYXA2MT8gICAgICAg
ICAgICAgICAgICAgICBib29sZWFuDQo+IA0KPiAgICAgfCAgfCAgKy0tcncgdGltZS10cmFjZWFi
bGU/ICAgICAgICAgICAgIGJvb2xlYW4NCj4gDQo+ICAgICB8ICB8ICArLS1ydyBmcmVxdWVuY3kt
dHJhY2VhYmxlPyAgICAgICAgYm9vbGVhbg0KPiANCj4gICAgIHwgIHwgICstLXJ3IHB0cC10aW1l
c2NhbGU/ICAgICAgICAgICAgICBib29sZWFuDQo+IA0KPiAgICAgfCAgfCAgKy0tcncgdGltZS1z
b3VyY2U/ICAgICAgICAgICAgICAgIHVpbnQ4DQo+IA0KPiAgICAgfCAgKy0tcncgcG9ydC1kcy1s
aXN0KiBbcG9ydC1udW1iZXJdDQo+IA0KPiAgICAgfCAgICAgKy0tcncgY2xvY2staWRlbnRpdHk/
ICAgICAgICAgICAgICAgIGNsb2NrLWlkZW50aXR5LXR5cGUNCj4gDQo+ICAgICB8ICAgICArLS1y
dyBwb3J0LW51bWJlciAgICAgICAgICAgICAgICAgICAgdWludDE2DQo+IA0KPiAgICAgfCAgICAg
Ky0tcncgcG9ydC1zdGF0ZT8gICAgICAgICAgICAgICAgICAgIHBvcnQtc3RhdGUtZW51bWVyYXRp
b24NCj4gDQo+ICAgICB8ICAgICArLS1ydyB1bmRlcmx5aW5nLWludGVyZmFjZT8gICAgICAgICAg
aWY6aW50ZXJmYWNlLXJlZg0KPiANCj4gICAgIHwgICAgICstLXJ3IGxvZy1taW4tZGVsYXktcmVx
LWludGVydmFsPyAgICBpbnQ4DQo+IA0KPiAgICAgfCAgICAgKy0tcncgcGVlci1tZWFuLXBhdGgt
ZGVsYXk/ICAgICAgICAgIHRpbWUtaW50ZXJ2YWwtdHlwZQ0KPiANCj4gICAgIHwgICAgICstLXJ3
IGxvZy1hbm5vdW5jZS1pbnRlcnZhbD8gICAgICAgICBpbnQ4DQo+IA0KPiAgICAgfCAgICAgKy0t
cncgYW5ub3VuY2UtcmVjZWlwdC10aW1lb3V0PyAgICAgIHVpbnQ4DQo+IA0KPiAgICAgfCAgICAg
Ky0tcncgbG9nLXN5bmMtaW50ZXJ2YWw/ICAgICAgICAgICAgIGludDgNCj4gDQo+ICAgICB8ICAg
ICArLS1ydyBkZWxheS1tZWNoYW5pc20/ICAgICAgICAgICAgICAgZGVsYXktbWVjaGFuaXNtLWVu
dW1lcmF0aW9uDQo+IA0KPiAgICAgfCAgICAgKy0tcncgbG9nLW1pbi1wZGVsYXktcmVxLWludGVy
dmFsPyAgIGludDgNCj4gDQo+ICAgICB8ICAgICArLS1ydyB2ZXJzaW9uLW51bWJlcj8gICAgICAg
ICAgICAgICAgdWludDgNCj4gDQo+ICAgICArLS1ydyB0cmFuc3BhcmVudC1jbG9jay1kZWZhdWx0
LWRzDQo+IA0KPiAgICAgfCAgKy0tcncgY2xvY2staWRlbnRpdHk/ICAgIGNsb2NrLWlkZW50aXR5
LXR5cGUNCj4gDQo+ICAgICB8ICArLS1ydyBudW1iZXItcG9ydHM/ICAgICAgdWludDE2DQo+IA0K
PiAgICAgfCAgKy0tcncgZGVsYXktbWVjaGFuaXNtPyAgIGRlbGF5LW1lY2hhbmlzbS1lbnVtZXJh
dGlvbg0KPiANCj4gICAgIHwgICstLXJ3IHByaW1hcnktZG9tYWluPyAgICB1aW50OA0KPiANCj4g
ICAgICstLXJ3IHRyYW5zcGFyZW50LWNsb2NrLXBvcnQtZHMtbGlzdCogW3BvcnQtbnVtYmVyXQ0K
PiANCj4gICAgICAgICstLXJ3IGNsb2NrLWlkZW50aXR5PyAgICAgICAgICAgICAgICBjbG9jay1p
ZGVudGl0eS10eXBlDQo+IA0KPiAgICAgICAgKy0tcncgcG9ydC1udW1iZXIgICAgICAgICAgICAg
ICAgICAgIHVpbnQxNg0KPiANCj4gICAgICAgICstLXJ3IGxvZy1taW4tcGRlbGF5LXJlcS1pbnRl
cnZhbD8gICBpbnQ4DQo+IA0KPiAgICAgICAgKy0tcncgZmF1bHR5LWZsYWc/ICAgICAgICAgICAg
ICAgICAgIGJvb2xlYW4NCj4gDQo+ICAgICAgICArLS1ydyBwZWVyLW1lYW4tcGF0aC1kZWxheT8g
ICAgICAgICAgdGltZS1pbnRlcnZhbC10eXBlDQo+IA0KPiANCj4gDQo+IEluIGNvbnRyYXN0IHRv
IHRoZSBvcmlnaW5hbCAxNTg4IFlBTkcgdHJlZSBkaWFncmFtOg0KPiANCj4gICAgbW9kdWxlOiBp
ZXRmLXB0cC1kYXRhc2V0DQo+IA0KPiAgICAgICAgKy0tcncgaW5zdGFuY2UtbGlzdCogW2luc3Rh
bmNlLW51bWJlcl0NCj4gDQo+ICAgICAgICB8ICArLS1ydyBpbnN0YW5jZS1udW1iZXIgICAgICB1
aW50MTYNCj4gDQo+ICAgICAgICB8ICArLS1ydyBkZWZhdWx0LWRzDQo+IA0KPiAgICAgICAgfCAg
fCAgKy0tcncgdHdvLXN0ZXAtZmxhZz8gICAgYm9vbGVhbg0KPiANCj4gICAgICAgIHwgIHwgICst
LXJ3IGNsb2NrLWlkZW50aXR5PyAgIGNsb2NrLWlkZW50aXR5LXR5cGUNCj4gDQo+ICAgICAgICB8
ICB8ICArLS1ydyBudW1iZXItcG9ydHM/ICAgICB1aW50MTYNCj4gDQo+ICAgICAgICB8ICB8ICAr
LS1ydyBjbG9jay1xdWFsaXR5DQo+IA0KPiAgICAgICAgfCAgfCAgfCAgKy0tcncgY2xvY2stY2xh
c3M/ICAgICAgICAgICAgICAgICAgdWludDgNCj4gDQo+ICAgICAgICB8ICB8ICB8ICArLS1ydyBj
bG9jay1hY2N1cmFjeT8gICAgICAgICAgICAgICB1aW50OA0KPiANCj4gICAgICAgIHwgIHwgIHwg
ICstLXJ3IG9mZnNldC1zY2FsZWQtbG9nLXZhcmlhbmNlPyAgIHVpbnQxNg0KPiANCj4gICAgICAg
IHwgIHwgICstLXJ3IHByaW9yaXR5MT8gICAgICAgIHVpbnQ4DQo+IA0KPiAgICAgICAgfCAgfCAg
Ky0tcncgcHJpb3JpdHkyPyAgICAgICAgdWludDgNCj4gDQo+ICAgICAgICB8ICB8ICArLS1ydyBk
b21haW4tbnVtYmVyPyAgICB1aW50OA0KPiANCj4gICAgICAgIHwgIHwgICstLXJ3IHNsYXZlLW9u
bHk/ICAgICAgIGJvb2xlYW4NCj4gDQo+ICAgICAgICB8ICArLS1ydyBjdXJyZW50LWRzDQo+IA0K
PiAgICAgICAgfCAgfCAgKy0tcncgc3RlcHMtcmVtb3ZlZD8gICAgICAgdWludDE2DQo+IA0KPiAg
ICAgICAgfCAgfCAgKy0tcncgb2Zmc2V0LWZyb20tbWFzdGVyPyAgdGltZS1pbnRlcnZhbC10eXBl
DQo+IA0KPiAgICAgICAgfCAgfCAgKy0tcncgbWVhbi1wYXRoLWRlbGF5PyAgICAgdGltZS1pbnRl
cnZhbC10eXBlDQo+IA0KPiAgICAgICAgfCAgKy0tcncgcGFyZW50LWRzDQo+IA0KPiAgICAgICAg
fCAgfCAgKy0tcncgcGFyZW50LXBvcnQtaWRlbnRpdHkNCj4gDQo+ICAgICAgICB8ICB8ICB8ICAr
LS1ydyBjbG9jay1pZGVudGl0eT8gICBjbG9jay1pZGVudGl0eS10eXBlDQo+IA0KPiAgICAgICAg
fCAgfCAgfCAgKy0tcncgcG9ydC1udW1iZXI/ICAgICAgdWludDE2DQo+IA0KPiAgICAgICAgfCAg
fCAgKy0tcncgcGFyZW50LXN0YXRzPyAgICAgICAgYm9vbGVhbg0KPiANCj4gICAgICAgIHwgIHwg
ICstLXJ3IG9ic2VydmVkLXBhcmVudC1vZmZzZXQtc2NhbGVkLWxvZy12YXJpYW5jZT8gdWludDE2
DQo+IA0KPiAgICAgICAgfCAgfCAgKy0tcncgb2JzZXJ2ZWQtcGFyZW50LWNsb2NrLXBoYXNlLWNo
YW5nZS1yYXRlPyAgICBpbnQzMg0KPiANCj4gICAgICAgIHwgIHwgICstLXJ3IGdyYW5kbWFzdGVy
LWlkZW50aXR5PyAgICAgICAgICAgICAgICAgICAgICAgYmluYXJ5DQo+IA0KPiAgICAgICAgfCAg
fCAgKy0tcncgZ3JhbmRtYXN0ZXItY2xvY2stcXVhbGl0eQ0KPiANCj4gICAgICAgIHwgIHwgIHwg
ICstLXJ3IGNsb2NrLWNsYXNzPyAgICAgICAgICAgICAgICAgIHVpbnQ4DQo+IA0KPiAgICAgICAg
fCAgfCAgfCAgKy0tcncgY2xvY2stYWNjdXJhY3k/ICAgICAgICAgICAgICAgdWludDgNCj4gDQo+
ICAgICAgICB8ICB8ICB8ICArLS1ydyBvZmZzZXQtc2NhbGVkLWxvZy12YXJpYW5jZT8gICB1aW50
MTYNCj4gDQo+ICAgICAgICB8ICB8ICArLS1ydyBncmFuZG1hc3Rlci1wcmlvcml0eTE/ICAgICAg
ICAgICB1aW50OA0KPiANCj4gICAgICAgIHwgIHwgICstLXJ3IGdyYW5kbWFzdGVyLXByaW9yaXR5
Mj8gICAgICAgICAgIHVpbnQ4DQo+IA0KPiAgICAgICAgfCAgKy0tcncgdGltZS1wcm9wZXJ0aWVz
LWRzDQo+IA0KPiAgICAgICAgfCAgfCAgKy0tcncgY3VycmVudC11dGMtb2Zmc2V0LXZhbGlkPyAg
IGJvb2xlYW4NCj4gDQo+ICAgICAgICB8ICB8ICArLS1ydyBjdXJyZW50LXV0Yy1vZmZzZXQ/ICAg
ICAgICAgaW50MTYNCj4gDQo+ICAgICAgICB8ICB8ICArLS1ydyBsZWFwNTk/ICAgICAgICAgICAg
ICAgICAgICAgYm9vbGVhbg0KPiANCj4gICAgICAgIHwgIHwgICstLXJ3IGxlYXA2MT8gICAgICAg
ICAgICAgICAgICAgICBib29sZWFuDQo+IA0KPiAgICAgICAgfCAgfCAgKy0tcncgdGltZS10cmFj
ZWFibGU/ICAgICAgICAgICAgIGJvb2xlYW4NCj4gDQo+ICAgICAgICB8ICB8ICArLS1ydyBmcmVx
dWVuY3ktdHJhY2VhYmxlPyAgICAgICAgYm9vbGVhbg0KPiANCj4gICAgICAgIHwgIHwgICstLXJ3
IHB0cC10aW1lc2NhbGU/ICAgICAgICAgICAgICBib29sZWFuDQo+IA0KPiAgICAgICAgfCAgfCAg
Ky0tcncgdGltZS1zb3VyY2U/ICAgICAgICAgICAgICAgIHVpbnQ4DQo+IA0KPiAgICAgICAgfCAg
Ky0tcncgcG9ydC1kcy1saXN0KiBbcG9ydC1udW1iZXJdDQo+IA0KPiAgICAgICAgfCAgICAgKy0t
cncgcG9ydC1udW1iZXIgICAgICAgIC0+IC4uL3BvcnQtaWRlbnRpdHkvcG9ydC1udW1iZXINCj4g
DQo+ICAgICAgICB8ICAgICArLS1ydyBwb3J0LWlkZW50aXR5DQo+IA0KPiAgICAgICAgfCAgICAg
fCAgKy0tcncgY2xvY2staWRlbnRpdHk/ICAgY2xvY2staWRlbnRpdHktdHlwZQ0KPiANCj4gICAg
ICAgIHwgICAgIHwgICstLXJ3IHBvcnQtbnVtYmVyPyAgICAgIHVpbnQxNg0KPiANCj4gICAgICAg
IHwgICAgICstLXJ3IHBvcnQtc3RhdGU/ICAgICAgICAgIHBvcnQtc3RhdGUtZW51bWVyYXRpb24N
Cj4gDQo+ICAgICAgICB8ICAgICArLS1ydyB1bmRlcmx5aW5nLWludGVyZmFjZT8gaWY6aW50ZXJm
YWNlLXJlZg0KPiANCj4gICAgICAgIHwgICAgICstLXJ3IGxvZy1taW4tZGVsYXktcmVxLWludGVy
dmFsPyAgICBpbnQ4DQo+IA0KPiAgICAgICAgfCAgICAgKy0tcncgcGVlci1tZWFuLXBhdGgtZGVs
YXk/ICAgICAgICAgIHRpbWUtaW50ZXJ2YWwtdHlwZQ0KPiANCj4gICAgICAgIHwgICAgICstLXJ3
IGxvZy1hbm5vdW5jZS1pbnRlcnZhbD8gICAgICAgICBpbnQ4DQo+IA0KPiAgICAgICAgfCAgICAg
Ky0tcncgYW5ub3VuY2UtcmVjZWlwdC10aW1lb3V0PyAgICAgIHVpbnQ4DQo+IA0KPiAgICAgICAg
fCAgICAgKy0tcncgbG9nLXN5bmMtaW50ZXJ2YWw/ICAgICAgICAgICAgIGludDgNCj4gDQo+ICAg
ICAgICB8ICAgICArLS1ydyBkZWxheS1tZWNoYW5pc20/ICAgICBkZWxheS1tZWNoYW5pc20tZW51
bWVyYXRpb24NCj4gDQo+ICAgICAgICB8ICAgICArLS1ydyBsb2ctbWluLXBkZWxheS1yZXEtaW50
ZXJ2YWw/ICAgaW50OA0KPiANCj4gICAgICAgIHwgICAgICstLXJ3IHZlcnNpb24tbnVtYmVyPyAg
ICAgICAgICAgICAgICB1aW50OA0KPiANCj4gICAgICAgICstLXJ3IHRyYW5zcGFyZW50LWNsb2Nr
LWRlZmF1bHQtZHMNCj4gDQo+ICAgICAgICB8ICArLS1ydyBjbG9jay1pZGVudGl0eT8gICAgY2xv
Y2staWRlbnRpdHktdHlwZQ0KPiANCj4gICAgICAgIHwgICstLXJ3IG51bWJlci1wb3J0cz8gICAg
ICB1aW50MTYNCj4gDQo+ICAgICAgICB8ICArLS1ydyBkZWxheS1tZWNoYW5pc20/ICAgZGVsYXkt
bWVjaGFuaXNtLWVudW1lcmF0aW9uDQo+IA0KPiAgICAgICAgfCAgKy0tcncgcHJpbWFyeS1kb21h
aW4/ICAgIHVpbnQ4DQo+IA0KPiAgICAgICAgKy0tcncgdHJhbnNwYXJlbnQtY2xvY2stcG9ydC1k
cy1saXN0KiBbcG9ydC1udW1iZXJdDQo+IA0KPiAgICAgICAgICAgKy0tcncgcG9ydC1udW1iZXIg
ICAgICAgICAgIC0+IC4uL3BvcnQtaWRlbnRpdHkvcG9ydC1udW1iZXINCj4gDQo+ICAgICAgICAg
ICArLS1ydyBwb3J0LWlkZW50aXR5DQo+IA0KPiAgICAgICAgICAgfCAgKy0tcncgY2xvY2staWRl
bnRpdHk/ICAgY2xvY2staWRlbnRpdHktdHlwZQ0KPiANCj4gICAgICAgICAgIHwgICstLXJ3IHBv
cnQtbnVtYmVyPyAgICAgIHVpbnQxNg0KPiANCj4gICAgICAgICAgICstLXJ3IGxvZy1taW4tcGRl
bGF5LXJlcS1pbnRlcnZhbD8gICBpbnQ4DQo+IA0KPiAgICAgICAgICAgKy0tcncgZmF1bHR5LWZs
YWc/ICAgICAgICAgICAgICAgICAgIGJvb2xlYW4NCj4gDQo+ICAgICAgICAgICArLS1ydyBwZWVy
LW1lYW4tcGF0aC1kZWxheT8gICAgICAgICB0aW1lLWludGVydmFsLXR5cGUNCj4gDQo+IA0KPiAN
Cj4gSSBhZ3JlZSwgYXNzaWdubWVudCBhbmQgY29tcGFyaXNvbiBjYW4gc3RpbGwgYmUgZG9uZSBv
biBjbG9jay1pZGVudGl0eQ0KPiBhbmQgcG9ydC1udW1iZXIgZGlyZWN0bHkgKHdpdGhvdXQgYSBw
b3J0SWRlbnRpdHkgY29uc3RydWN0KSAuIEJ1dA0KPiBwZW9wbGUgd2hvIGFyZSBmYW1pbGlhciB3
aXRoIDE1ODgtMjAwOCBtYXkgcXVlc3Rpb24gd2hlcmUgcG9ydElkZW50aXR5DQo+IGlzIGdvbmUu
DQo+IA0KPiANCj4gDQo+IDMuIEkgdGhpbmsgbGVhZnJlZiBpcyBhIHZlcnkgZ2VuZXJhbCBzZW1h
bnRpY3MgdGhpbmcgaW4gWUFORyBsYW5ndWFnZSwNCj4gaWYgYW55IHRvb2xzIGhhdmUgcHJvYmxl
bSB3aXRoIHRoaXMgZmVhdHVyZSwgbWF5YmUgd2UgbmVlZCB0byBjb250YWN0DQo+IHdpdGggdGhl
IHRvb2zigJlzIGRldmVsb3BlciB0byBzdXBwb3J0IGl0Lg0KPiANCj4gDQo+IA0KPiBGaW5hbGx5
LCBtb3JlIGlucHV0cyBmcm9tIHRoZSBXRyBhcmUgd2VsY29tZS4NCj4gDQo+IA0KPiANCj4gVGhh
bmtzIGFnYWluLA0KPiANCj4gWXVhbmxvbmcNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAtLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBUSUNUT0MgW21haWx0bzp0aWN0b2MtYm91bmNl
c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvZG5leQ0KPiBDdW1taW5ncw0KPiBTZW50OiBXZWRu
ZXNkYXksIFNlcHRlbWJlciAyNywgMjAxNyAxOjI0IEFNDQo+IFRvOiB0aWN0b2NAaWV0Zi5vcmc8
bWFpbHRvOnRpY3RvY0BpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFtUSUNUT0NdIGRyYWZ0LWll
dGYtdGljdG9jLTE1ODh2Mi15YW5nLTA1IC0gQ29uY2VybiBvdmVyDQo+IHBvcnQgaWRlbnRpZmll
cg0KPiANCj4gDQo+IA0KPiBUaGFua3MgU2VhbiwNCj4gDQo+IA0KPiANCj4gUmVnYXJkaW5nIHlv
dXIgb3RoZXIgY29tbWVudCBvbiBUTEQuLi4gSSBhZ3JlZS4NCj4gDQo+IA0KPiANCj4gUmVnYXJk
aW5nIHRoZSBjb21tZW50IGJlbG93IG9uIHBvcnQtaWRlbnRpdHksIEkgYWdyZWUgdGhhdCB3ZSBu
ZWVkIHRvDQo+IGRvIGl0IGZvciBwcmFjdGljYWwgcmVhc29ucy4NCj4gDQo+IA0KPiANCj4gSW4g
MTU4OC0yMDA4LCB0aGVyZSBpcyBhIGRpc3RpbmN0IGRhdGFzZXQgbWVtYmVyIGZvcg0KPiBwb3J0
RFMucG9ydElkZW50aXR5LCB3aGljaCA1LjMuNSBzcGVjaWZpZXMgYXMgdXNpbmcgdHlwZSBQb3J0
SWRlbnRpdHk6DQo+IA0KPiAgIHN0cnVjdCBQb3J0SWRlbnRpdHkgew0KPiANCj4gICAgIENsb2Nr
SWRlbnRpdHkgY2xvY2tJZGVudGl0eTsNCj4gDQo+ICAgICBVSW50ZWdlciBwb3J0TnVtYmVyOw0K
PiANCj4gICB9DQo+IA0KPiANCj4gDQo+IElmIHdlIGludGVycHJldCB0aGUgMTU4OC0yMDA4IGRh
dGFzZXRzIGFzIGFuIGluZm9ybWF0aW9uIG1vZGVsLCBhbmQNCj4gYXBwbHkgdGhhdCBhcyBkaXJl
Y3RseSBhcyBwb3NzaWJsZSB0byBhIFlBTkcgZGF0YSBtb2RlbCwNCj4gcG9ydERTLnBvcnRJZGVu
dGl0eSBpcyBhIGNvbnRhaW5lciwgd2hpY2ggaXMgd2hhdCB3ZSBoYXZlIHNvIGZhci4gVGhhdA0K
PiBpbnRyb2R1Y2VzIGEgY2hhbGxlbmdlLCBiZWNhdXNlIHdlIHdhbnQgdG8gdXNlDQo+IHBvcnRE
Uy5wb3J0SWRlbnRpdHkucG9ydE51bWJlciBhcyB0aGUga2V5IHRvIHRoZSBsaXN0IG9mIHBvcnRE
UydzLiBXZQ0KPiBzb2x2ZWQgdGhhdCBjaGFsbGVuZ2Ugd2l0aCBhIGxlYWZyZWYsIGJ1dCBJJ2Qg
YWdyZWUgdGhhdCBpcyB1Z2x5Lg0KPiANCj4gDQo+IA0KPiBZb3VyIHByb3Bvc2FsIGNoYW5nZXMg
cG9ydERTLnBvcnRJZGVudGl0eSBmcm9tIGEgY29udGFpbmVyIHRvIGENCj4gZ3JvdXBpbmcsIHNv
IHRoYXQgaXQgcG9ydERTLnBvcnRJZGVudGl0eS5wb3J0TnVtYmVyIGNhbiBiZSB1c2VkIGFzIHRo
ZQ0KPiBrZXkgd2l0aG91dCBhIGxlYWZyZWYuDQo+IA0KPiANCj4gDQo+IFRoZSBkb3duc2lkZSBp
cyB0aGF0IGlmL3doZW4gYSBZQU5HIG1hbmFnZW1lbnQgY2xpZW50IHRyaWVzIHRvICJnZXQiDQo+
IHBvcnREUy5wb3J0SWRlbnRpdHksIGl0IGRvZXNuJ3Qgd29yay4uLiB0aGVyZSBpcyBubyBwb3J0
SWRlbnRpdHkgdG8NCj4gZ2V0Lg0KPiANCj4gDQo+IA0KPiBQZXJzb25hbGx5LCBJIHRoaW5rIHRo
YXQgZG93bnNpZGUgaXMgd29ydGggaXQuIE9uZSBjYW4gYXJndWUgdGhhdCB5b3VyDQo+IHByb3Bv
c2FsIHN0aWxsIGNvbmZvcm1zIHRvIHRoZSAxNTg4LTIwMDggaW5mb3JtYXRpb24gbW9kZWwgZm9y
DQo+IG1hbmFnZW1lbnQsIGluIHRoYXQgcG9ydERTLnBvcnRJZGVudGl0eSBzdGlsbCAiZXhpc3Rz
IiBpbiBhIG1hbm5lcg0KPiB0aGF0IG1ha2VzIHNlbnNlIGZvciBZQU5HLg0KPiANCj4gDQo+IA0K
PiBSb2RuZXkNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IEZyb206IFRJQ1RPQyBbbWFp
bHRvOnRpY3RvYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU2VhbiBDb25kb24NCj4g
DQo+IFNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAyNiwgMjAxNyAxMDozOCBBTQ0KPiANCj4gVG86
IHRpY3RvY0BpZXRmLm9yZzxtYWlsdG86dGljdG9jQGlldGYub3JnPg0KPiANCj4gU3ViamVjdDog
W1RJQ1RPQ10gZHJhZnQtaWV0Zi10aWN0b2MtMTU4OHYyLXlhbmctMDUgLSBDb25jZXJuIG92ZXIg
cG9ydA0KPiBpZGVudGlmaWVyDQo+IA0KPiANCj4gDQo+IFdpdGggcmVmZXJlbmNlIHRvICJZQU5H
IERhdGEgTW9kZWwgZm9yIElFRUUgMTU4OHYyIg0KPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zw
b2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfZHJhZnQtMkRp
ZXRmLTJEdGljdG9jLTJEMTU4OHYyLTJEeWFuZy0yRDA1JmQ9RHdNRkF3JmM9SV8wWXdvS3k3ejVM
TVRWZHlPNllDaUUydXpJMWpqWlp1SVBlbGNTaml4QSZyPVdBNzFzZjJvN0R3N0NiWWhGdDI0RFBq
dDNsSnV1cHN3V1lkbmJvS2JaOGsmbT1qS0hjelZOTE4tS3VWMkhSWmtiRVpZMVN6bENEX0F6dGth
V1NjY3JxQkk4JnM9bXNoN0E3X09nSFoxbDY1RG42X0xoaURJWGtYcEZlaUxHbUtiS3hzcVhXdyZl
PQ0KPiANCj4gDQo+IA0KPiBJIGhhdmUgYSBjb25jZXJuIGFib3V0IHRoZSBzdHJ1Y3R1cmUgb2Yg
dGhlIFlBTkcsIGFuZCBob3cgdGhlIGxpc3RzDQo+IHBvcnQtZHMtbGlzdCBhbmQgdHJhbnNwYXJl
bnQtY2xvY2stcG9ydC1kcy1saXN0IGFyZSBpbmRleGVkIHdpdGggYQ0KPiBsZWFmIHdoaWNoIGlz
IGEgbGVhZnJlZi4NCj4gDQo+IA0KPiANCj4gVGhlIHN0cnVjdHVyZSBzZWVtcyB1bm5lY2Vzc2Fy
aWx5IGNvbXBsZXggLSBwb3J0LW51bWJlciBpcyByZXByZXNlbnRlZA0KPiBhcyBhIGxlYWYgZGly
ZWN0bHkgYmVuZWF0aCB0aGUgbGlzdCAodG8gYmUgdXNlZCBhcyBrZXkpIGFuZCBhZ2Fpbg0KPiB1
bmRlciB0aGUgcG9ydC1pZGVudGl0eSBjb250YWluZXIuIEl0IGlzIHN0cnVjdHVyZWQgaW4gYSB3
YXkgdGhhdCBJDQo+IGJlbGlldmUgd291bGQgbWFrZSBpdCBkaWZmaWN1bHQgdG8gd29yayB3aXRo
IHNvbWUgWUFORyB0b29scyBpbiB0aGUNCj4gbWFya2V0Lg0KPiANCj4gDQo+IA0KPiBUaGUgcHVy
cG9zZSBvZiBwb3J0LWlkZW50aXR5IGNvbnRhaW5lciBpcyBub3QgY2xlYXIgZnJvbSB0aGUgZG9j
dW1lbnQNCj4gLSBpdCB3b3VsZCBhY2hpZXZlIHRoZSBzYW1lIHB1cnBvc2UgaWYgaXQgd2FzIGxl
ZnQgb3V0IG9mDQo+IHBvcnQtZHMtZW50cnkgYW5kIHRyYW5zcGFyZW50LWNsb2NrLXBvcnQtZHMt
ZW50cnkgYW5kIGluc3RlYWQgdGhlDQo+IGdyb3VwaW5nIHBvcnQtaWRlbnRpdHktZ3JvdXBpbmcg
aW5jbHVkZWQgZGlyZWN0bHkuDQo+IA0KPiANCj4gDQo+IFNlZSB0aGUgYXR0YWNoZWQgZmlsZXMg
YXMgb3JpZ2luYWwsIGEgbW9kaWZpZWQgdmVyc2lvbiBhbmQgYXMgYSBwYXRjaA0KPiBmaWxlLg0K
PiANCj4gDQo+IA0KPiBTZWFuIENvbmRvbg0KPiANCj4gPT09PT09PT09PT09PT09PT09PT09PT0N
Cj4gDQo+IFNlYW4gQ29uZG9uDQo+IA0KPiBTeXN0ZW0gJiBTb2Z0d2FyZSBBcmNoaXRlY3QNCj4g
DQo+IEZyZXF1ZW5jeSAmIFRpbWluZyBEaXZpc2lvbg0KPiANCj4gTWljcm9zZW1pIEluYy4NCj4g
DQo+IG1haWx0bzpzZWFuLmNvbmRvbkBtaWNyb3NlbWkuY29tDQo+IA0KPiANCj4gDQo+IF9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IA0KPiBUSUNUT0Mg
bWFpbGluZyBsaXN0DQo+IA0KPiBUSUNUT0NAaWV0Zi5vcmc8bWFpbHRvOlRJQ1RPQ0BpZXRmLm9y
Zz4NCj4gDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGljdG9jDQo=


From nobody Thu Sep 28 09:04:20 2017
Return-Path: 
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 4293813420D; Thu, 28 Sep 2017 09:04:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level: 
X-Spam-Status: No, score=-4.7 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=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=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 FGqNBO5A3s6h; Thu, 28 Sep 2017 09:04:15 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0109.outbound.protection.outlook.com [104.47.2.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DC5D13339D; Thu, 28 Sep 2017 09:04:15 -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=y7uoMXxZxN+ZOShLCOzQr/EK8m3DXUKNmm2oaFFtzwo=; b=MPBcVgLHaHVMVDNhtonMpAt2vvHj/r++RjhzzGexRi/gdIpb5qX6699hdYxZeoPlAsD7zt0UFmVCZh8zbt+NixWdnJe2FgnLMCry+4HQiHZiBzj5i5nMpxdBV7E4RF/jKyvkxmoSjRt1BnaktK4Xz61iVbHUiYZK/6Jm54rmML0=
Received: from pc6 (109.146.128.123) by VI1PR0701MB3006.eurprd07.prod.outlook.com (2603:10a6:800:87::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Thu, 28 Sep 2017 16:04:11 +0000
Message-ID: <02d101d33873$2a3fdfe0$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: , , , "Robert Wilton" 
References: <20170918.200734.1805388289423863575.mbj@tail-f.com>  <99b9a2c6-4bb4-121f-0cba-925cefe09712@cisco.com> <20170919.115559.1080249872764998055.mbj@tail-f.com>  <5481ac35-c789-0796-36f6-8a02a5ebef8c@cisco.com> <00c501d333c0$9d210280$4001a8c0@gateway.2wire.net>  <3274ba62-d60d-976b-9a22-879089abbbf2@cisco.com>
Date: Thu, 28 Sep 2017 16:39:13 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
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: [109.146.128.123]
X-ClientProxiedBy: VI1PR0701CA0029.eurprd07.prod.outlook.com (2603:10a6:800:90::15) To VI1PR0701MB3006.eurprd07.prod.outlook.com (2603:10a6:800:87::20)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 541cf5a4-fc71-4c36-9099-08d5068a8f6d
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:VI1PR0701MB3006; 
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 3:nBqUWK0U3z/6/OVBjOEvjKjGZk8yYa96Xve5PyQ+cEM73EwCLW/ADmPNc94HUKCOTAMFR82NF2kTlbcCkypNk2mwhkgtmZmli5bg2GLG8MnFb/TUUdZqHq707QpoQA0bObDHPfzAUBvZNtHsY+w9oNB32vkcitCUwjhbxPrjArmV/cPAb60Hq875CQkZoB1TMdl9b0ZUg1/25vb4nOrrWVruAw7361BWTDJ8Fs14eNAanwzANEiu7DmQvvhpB/K1; 25:VT/pWYEh2YrCTMjH9Hgtz08cLAVKKfifcNMLMUHsDQRQ/pRj/QwSkYUrEI6R78b4uYUidFMvwzpE5SBJF0Z51xgnHL5aKGWsH3SlL9h6qC9wwBzHe5OFQ5FQ54xOZuMQwcl2I+XVoMiKc8EY62+kILJM04irCZQc1dnqMZk7S1iwNAx5cHXC8Qw8o6AYXRsab8ABAsxDbeCn7Al//0KW+yrLGEYE349y6i3ETfKPwkx5vKYS3nQIQbNvtK2vfJZJ2UizKYUo0/ooeLL2inF8jWj2WJ8VIU23SM5ORmTacXp69bHG4yFvi4HHcPqtRPwDcQsbnYkIuT/MXOT8s1UwJg==; 31:KNlld4bG2529DTpQ8J2crFIWbIO6fYn7OCBU3vz1k/BgHXK1dE1KV+jNaimTccfq9mMZduX9L8mNJ6F/IkBtR23NdIy8Bn5z1LzwYzYFMh40Qc0KdA8WOC1amryJLrf78vsnD+lFuQKJEs/9enxL2UHzLmZ/zK5a7QWm/h4nOUnzzIs+mipOwuBdqVj/LT+SP5kkfDdwwWaRJ1R3nf8CMbebZSmiNL15PmKgO0oMjDo=
X-MS-TrafficTypeDiagnostic: VI1PR0701MB3006:
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(788757137089)(95692535739014); 
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(61426038)(61427038)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR0701MB3006; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR0701MB3006; 
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 4:aA0gyPKtbT4lB3ChhQCwjOd1L16myqRkSyi2oDOFB1+ZQOqLFJLoYpyMBfLbmKwTECyJtCbOL5boG7geH2pSZS2OXCcmsZna6o4pvM1B2E8cExXxVJ8dtFkhv88NvQQdFI/OaCJNnvB3Z/BPFTU9sU0RDj7kqyLLoC/eW/I1kY38PbnMOocKQzYaRuSTZdJ1pOMonuE4pCdL1PO8bdhGDbYalqIAnaw+sFRLcp0UuyUAnN5EWUGcjg5loBI/FG7oyG8DAJoDJu8rqdgIjlpZZ5V7SOK7Mbt3aqib+iDLTAuuleJGuYxt9Vf5rityK+bKIE42MA0xlW+Eg8uDVl2EDjmhJertWDNkFQNsMsiL9Fk=
X-Forefront-PRVS: 0444EB1997
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39860400002)(54094003)(13464003)(51444003)(199003)(24454002)(377454003)(189002)(6496005)(2201001)(6486002)(25786009)(230700001)(6246003)(76176999)(229853002)(81686999)(81816999)(50986999)(101416001)(84392002)(68736007)(33646002)(86362001)(478600001)(966005)(44736005)(14496001)(9686003)(106356001)(6306002)(3846002)(16526017)(97736004)(66066001)(316002)(81156014)(50466002)(8676002)(8936002)(44716002)(53546010)(62236002)(50226002)(110136005)(116806002)(105586002)(81166006)(5660300001)(2906002)(61296003)(47776003)(305945005)(93886005)(1556002)(53936002)(4720700003)(7736002)(1456003)(23676002)(6116002)(189998001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB3006; 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?MTtWSTFQUjA3MDFNQjMwMDY7MjM6eFRLVlQ3ZFpiTjFBL3RoWFBBaUJ0aHVO?= =?utf-8?B?WUFQNjhDWk5FclE0WFJ0RzZCbmw5OTNoRGVQc1Y4d0F3S3lVOFlySjhqUWFJ?= =?utf-8?B?Q3VDS0d5S242REhUN3QycGJPckgxaEpQdXlZOXNEWFJ1dmMrdnlzcUs0Ynlj?= =?utf-8?B?aGVrbkJaV29zUVo4SXdSbjFBUExCSWZIdlpqWkh3WkQ4UWdpV2FyenB3M2Zl?= =?utf-8?B?alZwOUZvYmIwdkhOK0kvMWQrTzQ2TU9WVk1xRHZxOFExc2pnMTdPQTZKblRq?= =?utf-8?B?QWFZbWJUS1FJUGdvQXpKWmJMWDFFUGNrQlRBS3ZzOEpZVlVvSUwvQlRyb1Fx?= =?utf-8?B?bzBJZFJaemU5V0k3WkYwbldVRWJoVEpjbzdMeFc5ZHZvbmM4S2crLzlNQzgz?= =?utf-8?B?elZVWEtiTGxPT0RKUE1ZdGlsaXlINFNDV1dQeEFZWngxd3dWNVRnVzIvaEpZ?= =?utf-8?B?U0ExOWJUY1BFSTlJcTNXNnM3MTdSa3l2Y1d0YjRWaGg0VWJST2hEVHV2WEFZ?= =?utf-8?B?ejlJSkVLcGJHekFjWC9TWndrakh3TkcyaVRBUjZyWnFXRGsxbkxQeEd6em53?= =?utf-8?B?UzBsZHhhb21yK3ZoaHo0QUVGMHFSa042WjA3OHNlQ2doV01JSEZCczdEek41?= =?utf-8?B?eXVTK0NDY2VyeEhsRnQ0WjJhUld0M2x5ZlVuSkd0dm5iK2tPL0dyZFNjeUVQ?= =?utf-8?B?ejVuYys3SVdpeS9ia1ZZY0UrcFBqV1RnK21VdmY2SGRibW9DNjZWS3k1ZVhs?= =?utf-8?B?WGlYY3ZiM2RHRUtYb2xJREJyUDh1Y3hTMk5nTG9GbDFIaTJWaVY2Nm5jL3dv?= =?utf-8?B?a3NTQWduaUhUTHJwTXN2Q3AwcExHUE84aVNWVWtxVm1EbWtudUx4MTkxbjR3?= =?utf-8?B?NUtiM1pQeFhRTjZrY0NIZDA1NCtwQkRwbnREZXJzd3B6Z2F0VFdHZ09za1RT?= =?utf-8?B?dGZaK3luQk5QbVFwUFJIM081c05MTFl4LzJDS2VvQTZ5SGNnaWl2RUc0alM5?= =?utf-8?B?SmI2SUZtd21aWmVSc3dGUzRRcldvM2dJQnZPUXUwUXQvVjd0dGl0ZUpURGxQ?= =?utf-8?B?ankvTU5PQU1JenlFZzE4YndEQm5zaXkxZ0IzQjV5RFgvYWZndEhVeXVPV082?= =?utf-8?B?NnF6YjJzL2YyWndEcys2WGlNSnBhUjJkV29xaEdkam1HNm5tQURTcDhUVW9q?= =?utf-8?B?cUY4STQ4V1NONHJkTWYyaDIzVndLVGpYbWhkSTQ1OXhLSDNVbEpVZHVVKzZm?= =?utf-8?B?S0lmQmo2Nk9qalFEeDY0ZlFmR2Z4cUc1SFpwWHBXYXFoR2Izc3RPNlNodzJN?= =?utf-8?B?VjE4aG82SUp3Q2dIMWlVMzB5RldkZGh1Ynpyc0M2dE1OOTlnQXowT2Y1Vlpa?= =?utf-8?B?bU9xNTVYdGtnNGd0L21IdjRXcHhQOG1mdmkyZEx3YkM1N2JaQWlQRG90SmZh?= =?utf-8?B?UGYzd2kvNFhGUmZBVW4zbytKOFF2WkkyemFtVVNOQTZ3aG1RdDMvcnpVK1VZ?= =?utf-8?B?WDgzaHhjUkQ4aGpwWTZwSUJTOXNvTEw4WlJ2WmM4V2g2YnEydmRaU01wcHc3?= =?utf-8?B?RlBMSjlLekZsMkJGTXJIQVZyU3hYOEdKT3p4Y1F1QlVFdnkySTFEaWxPNGZo?= =?utf-8?B?aDhleTdWNUlvdlVpRkM3WmQ1bGZTc3VhcXlQZ0hJUjd6NjhSRGFaNE1nQjZR?= =?utf-8?B?UzFuZU5jL2hYbFcwelpWV2ZTQVZodWEyVEFxbjNTT0c4Uzl4anBLVWIraHpT?= =?utf-8?B?NE5LVEpycHB5WmdOMzFxLzhicnRYYzUzL3JnNzRvZm9GY0tFT1RobkNsTUEz?= =?utf-8?B?aUhQN0dkTUhEUnBGcUgzRmtaS0xIVTBOdG4zMFNYdVVTcjhXVTNuTVo2MG5j?= =?utf-8?B?dGtEemNHMnlSYWpGeXNzQmR1VXA4NmhrVTVSVE5DMS9RVHU0aHJ0QkMyRDA1?= =?utf-8?B?dDkweGIvZDFheHJOdlRvRFUrTWRhTldWRVF1WmgwSlhFcGRNcWNkTDZ5Ujlk?= =?utf-8?B?VlZZcGVBZUYrOTRGbnRwWmU5aE5qMkRYc1U2SUZxV3YvRjcxK0w1c2pBeVlL?= =?utf-8?Q?fwlz7DZRbVB0Lczo5Qi1P2SbDw5?=
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 6:vqHhSIBNld26PaZHsmJHXckBoxiU0iWLwXEZY7G2xGEZe7n2AQaf/aggGH1xBpayOtLarDr9RM1OYZ2oIPwmz2x+9XP+gK8j4NcPtpQ8Naqo1Xwkvp3eud6Qc/4e9aIItmOBatjHEpeXW2dNeB1hUi6kkx+N2Pe8RaNZTklD3fF6IMohi8nA5/BEcLOcYDe9XZezmmoM2UoMeaEjDx+25VGNIGaqpiV5dGC7VVWhp9v3m7x6Rccy/0bKbxd3W5D/8Vf30A2oEF//7x+it7xPqRm/D99kRqfUz2PECQsVWWd5ROMscRQduLcY4TBRWVc1B7YYfWN8K9FoTgDcifoVQg==; 5:MuWsc6oW0S/lqc77l8cC3cDVHK1TRJTbVWOBvm8V2lexRygwk+m8rfNfjl7UdBkEtbqOY6ZKRrvec5jG3mUwi61NKIJnKKgCHGEBtjI3/FeO6KZ1kPd8i75CaiLEkXdHmB7GlXcIZ9f/dYCmb1SekA==; 24:Lhmjrijdp7UzllT/Nbx6dKPFhjvCZUrsRCnTuvyNjYsYnZS832SVyCi4uxZF1Mb1vhVvGoN6JQxJO1MZSZVAF1EiZAJFlLJSJSBBsnVLmB8=; 7:nSgrRr0ENk3qD28sQuXWrtWcJaQ7+pCvJDsC0rNjs9GAv2yCFtlxGN8F6B6t5U/Dn48LElPXYIEwSoLbtQKI0QiEzdscyhlpsVy1oNAzrNWyqT3xs32R40O1gVQMaeIjiKKn4rOrZxJV92nYncjYEvglGzlmZlet4LBHjLJsRpl5gWyfckOORZgnZUxa6Ok8pV8YilUYG9re7osr1OkUXXoXRK8ci+5wVZhoVUzmg6w=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Sep 2017 16:04:11.9681 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB3006
Archived-At: 
Subject: Re: [netmod]  vs 
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Sep 2017 16:04:19 -0000

Robert

I would like you to tweak the definition of running configuration
datastore slightly.

You say

" The running configuration datastore () is a configuration
  datastore that holds the complete current configuration
  on the device"

which I see as black and white, the terminology is .

But then you say

"This datastore is commonly referred to
  as "".

which I see as introducing wiggle room with the use of 'commonly' so I
would like you to excise 'commonly' leaving

NEW
This datastore is referred to as "".

Black and white.

Tom Petch

----- Original Message -----
From: "Robert Wilton" 
Sent: Thursday, September 28, 2017 10:37 AM
>
> After comment from the other authors, an updated proposed description
> for  is as follows:
>
> OLD:
>
> 4.3. The Running Configuration Datastore ()
>
>   The running configuration datastore () holds the complete
>   current configuration on the device. It may include inactive
>   configuration or template-mechanism-oriented configuration that
>   require further expansion.
>
>   If a device does not have a distinct  and non-volatile is
>   available, the device will typically use that non-volatile storage
to
>   allow  to persist across reboots.
>
> NEW:
>
> 4.1.3. The Running Configuration Datastore ()
>
>   The running configuration datastore () is aconfiguration
>   datastore that holds the complete current configuration
>   on the device. It may include configuration that requires further
>   transformation before it can be applied, e.g., inactive
>   configuration, or template-mechanism-oriented configuration that
>   needs further expansion. However,  MUST always be a 'valid
>   configuration data tree' as defined in Section 8.1 of [RFC7950].
>
>    MUST be supported if the device can be configured via
>   conventional configuration datastores.
>
>   If a device does not have a distinct  and non-volatile is
>   available, the device will typically use that non-volatile storage
to
>   allow  to persist across reboots.
>
>
> Given that the definition of  and  are being
updated,
> I think that the definitions should similarly be updated. Hence I
propose:
>
>
>
> OLD:
>   o running configuration datastore: A configuration datastore holding
>   the current configuration of the device. It may include inactive
>   configuration or template-mechanism-oriented configuration that
>   require further expansion. This datastore is commonly referred to
>   as "".
>
> NEW (based on the new description of running above):
>   o running configuration datastore: A configuration datastore holding
>   the current configuration of the device. It may include
>   configuration that requires furthertransformations before it can
>   be applied. This datastore is commonly referred to
>   as "".
>
>
>
> OLD:
>
>   o intended configuration: Configuration that is intended to be used
>   by the device. For example, intended configuration excludes any
>   inactive configuration and it would include configuration produced
>   through the expansion of templates.
>
>
> NEW (based on the proposed updated description of intended):
>
>   o intended configuration: Configuration that is intended to be used
>   by the device. It represents the configuration after all
>   configuration transformations to  have been performed and
>   is the configuration that the system attempts to apply.
>
>
>
> It may also be helpful if we define "configuration transformation", or
> would that be better captured in the introduction text?
>
> A possible definition could be along the lines of:
>
>   configuration transformation: The addition, modification or removal
of
>   configuration between the  and  datastores.
>   Examples of configuration transformations include the removal of
>   inactive configuration and the configuration produced through the
>   expansion of templates.
>
> If I don't hear anything back, I'll take that as a tacit approval of
> these proposed changes.
>
> Thanks,
> Rob
>
>
> On 22/09/2017 18:12, Robert Wilton wrote:
> > Hi Tom,
> >
> >
> > On 22/09/2017 17:34, t.petch wrote:
> >> Robert
> >>
> >> I wonder if this says the opposite of what is intended
> >>
> >> -  holds the complete current configuration on the device.
> > I agree.
> >
> >>
> >> - This could include inactiveconfiguration
> > I agree.
> >
> >>
> >> -  must always be a 'valid configuration data tree' as
> >> defined in Section 8.1 of [RFC7950].
> > I agree.
> >
> >>
> >> Ergo, inactiveconfiguration must form part of a valid configuration
> >> tree.
> >
> > Ergo, inactive configuration can form part of a valid configuration
> > tree.
> >
> >>
> >> I thought the idea was that inactiveconfiguration was logically
removed
> >> before validation but this seems to state the opposite..
> > I don't think that this is necessarily true. One choice is inactive
> > configuration is removed before validation, but this isn't quite
what
> > I'm proposing. I'm proposing that the act of validation itself is
> > refined (via an tbd inactive configuration draft) such that it
ignores
> > configuration nodes marked as inactive.
> >
> > Thanks,
> > Rob
> >
> >>
> >> Tom Petch
> >>
> >> ----- Original Message -----
> >> From: "Robert Wilton" 
> >> Sent: Friday, September 22, 2017 10:03 AM
> >>
> >>> Hi,
> >>>
> >>> Regarding whether  is always valid, the proposed
modification
> >>> to the draft is to add the following text to section 4.3 that
> >> describes
> >>> :
> >>>
> >>> OLD:
> >>>
> >>> 4.3. The Running Configuration Datastore ()
> >>>
> >>> The running configuration datastore () holds the complete
> >>> current configuration on the device. It may include inactive
> >>> configuration or template-mechanism-oriented configuration that
> >>> require further expansion.
> >>>
> >>> If a device does not have a distinct  and non-volatile is
> >>> available, the device will typically use that non-volatile storage
> >> to
> >>> allow  to persist across reboots.
> >>>
> >>> NEW:
> >>>
> >>> 4.3. The Running Configuration Datastore ()
> >>>
> >>> The running configuration datastore () holds the complete
> >>> current configuration on the device. This could, for example,
> >> include
> >>> inactiveconfiguration or template-mechanism-oriented configuration
> >>> thatrequires further expansion.However,  must always be a
> >>> 'valid configuration data tree' as defined in Section 8.1 of
> >> [RFC7950].
> >>> If a device does not have a distinct  and non-volatile is
> >>> available, the device will typically use that non-volatile storage
> >> to
> >>> allow  to persist across reboots.
> >>>
> >>> END
> >>>
> >>>
> >>> Then the intention is that if inactive or a templating solution is
> >>> standardized then those drafts would update the validation rules
in
> >> RFC
> >>> 7950 such that  is still valid. E.g. an inactive config
draft
> >>> would probably indicate that validation excludes all configuration
> >> nodes
> >>> that are marked as inactive.
> >>>
> >>> Does anyone have any comments?
> >>>
> >>> Do we also need to state that  must always be a 'valid
> >>> configuration data tree'?
> >>>
> >>> Thanks,
> >>> Rob
> >>>
> >>>
> >>> On 19/09/2017 16:22, Robert Wilton wrote:
> >>>>
> >>>> On 19/09/2017 10:55, Martin Bjorklund wrote:
> >>>>> Robert Wilton  wrote:
> >>>>>> On 18/09/2017 19:25, Andy Bierman wrote:
> >>>>>>> On Mon, Sep 18, 2017 at 11:07 AM, Martin Bjorklund
> >>  >>>>>>> > wrote:
> >>>>>>>
> >>>>>>> Juergen Schoenwaelder  >>>>>>> > wrote:
> >>>>>>>> On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert Wilton
wrote:
> >>>>>>>>>> No. I do not agree that the MUST in RFC 7950 can be
> >>>>>>> removed.
> >>>>>>>>>> I do not agree the architecture should update YANG at all.
> >>>>>>>>> OK.
> >>>>>>>> I am with Andy here.  has always had the
> >>>>>>> requirement to be
> >>>>>>>> valid and we are not supposed to change that. Mechanisms for
> >>>>>>> inactive
> >>>>>>>> configuration or templating must be designed to be backwards
> >>>>>>> compatible
> >>>>>>>> I think.
> >>>>>>> Ok. If we keep the requirement that  in itself must
be
> >>>>>>> valid, it just restricts the usefulness/expressiveness of
> >>>>>>> inactive and
> >>>>>>> template mechanisms, but it might be ok.
> >>>>>>>
> >>>>>>> I think that even w/o this requirement, the observable
> >>>>>>> behavior for a
> >>>>>>> client can be backwards compatible. For example, suppose we
> >>>>>>> have an
> >>>>>>> inactive access control rule that refers to a non-existing
> >>>>>>> interface in
> >>>>>>> . If a client that doesn't know anything about
> >>>>>>> inactive asks
> >>>>>>> for the contents of , our implementation removes the
> >>>>>>> inactive
> >>>>>>> nodes from the reply to the client. Only a client that
> >>>>>>> opts-in to
> >>>>>>> inactive will receive a reply with things that looks invalid
> >>>>>>> if you
> >>>>>>> don't take the inactive annotation into account.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> There are many ways that validation can fail because inactive
> >> nodes
> >>>>>>> are present,
> >>>>>>> and considered part of the validation.
> >>>>>>>
> >>>>>>> e,g, min-elements, max-elements, mandatory, unique.
> >>>>>>>
> >>>>>>> I think we all agree that validation on the enabled nodes is
> >> supposed
> >>>>>>> to continue to work.
> >>>>> Yes.
> >>>>>
> >>>>>>> Here is an attempt at a backwards-compatible solution:
> >>>>>>>
> >>>>>>> 1) current  and  responses only include
enabled
> >>>>>>> nodes.
> >>>>>>> 2) old-style  operations do not alter inactive
nodes
> >>>>>>> 3) NMDA clients use , not  or .
These
> >>>>>>> responses
> >>>>>>> include enabled and disabled nodes, so validation does not
apply
> >>>>>>> for 
> >>>>>>> 4) new style  (i.e.  parameter used)
can
> >> alter
> >>>>>>> any type of data node
> >>>>>> //I think that inactive should always be an optional extension.
> >> Not
> >>>>>> everything needs the additional complexity.
> >>>>>>
> >>>>>> Hence rather than tying this function to specific NETCONF
> >> operations,
> >>>>>> I would suggest that there should be an extra parameter (like
for
> >>>>>> with-defaults) to allow a client to indicate to the server that
a
> >> get
> >>>>>> or edit request is using the "with-inactive" extension.
> >>>>>> 1) The server should also have a capability (or perhaps a leaf
> >> defined
> >>>>>> in YANG library) to indicate that it supports inactive
> >> configuration.
> >>>>>> 2) If a client doesn't use the extra "with-inactive" parameter
> >> during
> >>>>>> a get request then only active nodes are returned.
> >>>>>> 3) If a client doesn't use the extra "with-inactive" parameter
> >> during
> >>>>>> an edit-data request then the request cannot include an extra
> >> inactive
> >>>>>> meta-data. The request is processed in a way that is equivalent
to
> >> an
> >>>>>> existing NETCONF implementation, but it may unknowingly remove
> >> some
> >>>>>> inactive configuration (e.g. via a replace or remove operation
on
> >> an
> >>>>>> inactive node). Operations like create, delete, none, replace
> >> should
> >>>>>> all treat an inactive target node the same way as in the node
> >> doesn't
> >>>>>> exist (e.g. delete on an inactive node would return a
> >> "data-missing"
> >>>>>> error), this ensures that the behaviour that an unaware client
> >>>>>> observes is the same as the existing behaviour that it would
> >> expect
> >>>>>> from a regular 6241 compliant NETCONF implementation.
> >>>>>> 4) It a client makes a get request including the
"with-inactive"
> >>>>>> parameter then they also get the inactive nodes as well, marked
> >> with a
> >>>>>> meta-data annotation.
> >>>>>> 5) If a client makes an edit request including the
"with-inactive"
> >>>>>> parameter, then the inactive meta-data annotation can be used
to
> >> label
> >>>>>> inactive nodes. Inactive nodes are regarded as regular data
nodes
> >> for
> >>>>>> create/delete/replace/none operation error checking.
> >>>>>>
> >>>>>> I think that this approach is similar (perhaps even the same)
as
> >>>>>> Martin described.
> >>>>> This is indeed how our implementation works (except I think we
> >> don't
> >>>>> do 5; if the client sends an "inactive" attribute it doesn't
have
> >> to
> >>>>> also send with-inactive).
> >>>>>
> >>>>>>> Note that the YANG MUST rule still applies, because validation
is
> >> only
> >>>>>>> done on enabled nodes.
> >>>>>>> It is only the response message representations that cannot be
> >>>>>>> validated, not the contents
> >>>>>>> of  on a server.
> >>>>> So the question is how we can make sure that the text in the
NMDA
> >>>>> draft covers this yet-to-be-defined feature w/o having to define
it
> >>>>> now? We thought that the current text was sufficient, but do we
> >> have
> >>>>> to make any changes to it?
> >>>> 1) Do we also need to illustrate a similar proof of concept
> >> templating
> >>>> implementation to show that templating could work whilst keeping
> >>>> running valid? I would prefer that this is just deferred to
> >> whichever
> >>>> draft defines templating.
> >>>>
> >>>> 2) I think that we need to reach a decision as to whether the
NMDA
> >>>> architecture needs to explicitly state that  is always
> >> valid,
> >>>> or if that can be left to the existing statement in 7950. My
> >> thinking
> >>>> is that if the conclusion is that  must always be valid,
> >> then
> >>>> it would be helpful to explicitly state it the descriptions of
both
> >>>>  and  in the NMDA architecture.
> >>>>
> >>>> 3) I think that it would be useful to further refine my previous
> >>>> proposed text for intended, particularly rewriting the text on
> >>>> validation. This should hopefully also address Balazs' concern
about
> >>>> default values be included in validation.
> >>>>
> >>>> 
> >>>>
> >>>> 4.4. The Intended Configuration Datastore ()
> >>>>
> >>>> The intended configuration datastore () is a read-only
> >>>> configuration datastore. It is tightly coupled to . When
> >>>> data is written to , the data that is to be validated is
> >>>> also conceptually written to . Validation is performed
on
> >>>> the contents of .
> >>>>
> >>>> For simple implementations,  and  are
identical.
> >>>>
> >>>>  does not persist across reboots; its relationship with
> >>>>  makes that unnecessary.
> >>>>
> >>>> Currently there are no standard mechanisms defined that affect
> >>>>  so that it would have different contents than
,
> >>>> but this architecture allows for such mechanisms to be defined.
> >>>>
> >>>> One example of such a mechanism is support for marking nodes as
> >>>> inactive in . Inactive nodes are not copied to
,
> >>>> and are thus not taken into account when validating the
> >>>> configuration.
> >>>>
> >>>> Another example is support for templates. Templates are expanded
> >>>> when copied into , and the expanded result is
validated.
> >>>>
> >>>> 
> >>>> 
> >>>>
> >>>> 4.1.4. The Intended Configuration Datastore ()
> >>>>
> >>>> The intended configuration datastore () is a read-only
> >>>> configuration datastore. It represents the configuration after
all
> >>>> configuration transformations to  are performed (e.g.
> >>>> template expansion, removal of inactive configuration), and is
the
> >>>> configuration that the system attempts to apply.
> >>>>
> >>>>  is tightly coupled to . Whenever data is
written
> >>>> to , then  is also immediately updated by
> >>>> performing all necessary transformations to the contents of
> >> 
> >>>> and then  is validated.
> >>>>
> >>>>  may also be updated independently of  (e.g.,
if
> >>>> one of the configuration transformations is changed), but

> >>>> must always be a 'valid configuration data tree' as defined in
> >>>> Section 8.1 of [RFC7950].
> >>>>
> >>>> For simple implementations,  and  are
identical.
> >>>>
> >>>> The contents of  is also related to the 'config true'
> >>>> subset of , and hence a client can determine to what
> >>>> extent the intended configuration is currently in use by checking
> >>>> whether the contents of  also appears in .
> >>>>
> >>>>  does not persist across reboots; its relationship with
> >>>>  makes that unnecessary.
> >>>>
> >>>> Currently there are no standard mechanisms defined that affect
> >>>>  so that it would have different contents than
,
> >>>> but this architecture allows for such mechanisms to be defined.
> >>>>
> >>>> One example of such a mechanism is support for marking nodes as
> >>>> inactive in . Inactive nodes are not copied to
.
> >>>> A second example is support for templates, which can perform
> >>>> transformations on the configuration from  to the
> >>>> configuration written to .
> >>>>
> >>>> 
> >>>>
> >>>> Thanks,
> >>>> Rob
> >>>>
> >>>>
> >>>>>
> >>>>> /martin
> >>>>> .
> >>>>>
> >>>> .
> >>>>
> >> .
> >>
> >
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>


From nobody Thu Sep 28 09:12:12 2017
Return-Path: 
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 4E5FB13421F; Thu, 28 Sep 2017 09:12:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 VuQRnK6JHKUo; Thu, 28 Sep 2017 09:12:03 -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 C20EE126B71; Thu, 28 Sep 2017 09:12:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18841; q=dns/txt; s=iport; t=1506615123; x=1507824723; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=ROI+ubImoZrN/bcu41/UOCDhW0E2+iIpRbJ4l2yFThI=; b=ZzOtIWf5cjuGaC2I5x2/BBhB9PMeTlgUhConT/K4B30WjkQ+fl4pGigI HAyDuEErLHfZiKOMt+m2e9gphf6LqxETscxY4C/oNhfwqEB9kX72ETJMm rF0IV0RsUmUp4/rrCLq2CAX57pVxvic3TulcRKWRh8G7EnTENcfMedVav Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DFAAB5Hs1Z/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhEBuJ4N4ih90kD4ieZUyDoIEChgLhElPAoRkGAECAQEBAQEBAWs?= =?us-ascii?q?ohRgBAQEBAgEBASEPAQU2BBMECxACAwECAgIREgMCAicfAw4GAQwGAgEBF4oOC?= =?us-ascii?q?BCmaIInixEBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEOgh2DU4FqKwuCPTWEPy0?= =?us-ascii?q?CAlOCVIJgBaEolGCCE4lIJIcHihCDZIdZgTkfOIEOMiEIHRVJhx4/NoZDASUHg?= =?us-ascii?q?hUBAQE?=
X-IronPort-AV: E=Sophos;i="5.42,450,1500940800"; d="scan'208";a="656071930"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Sep 2017 16:12:00 +0000
Received: from [10.63.23.161] (dhcp-ensft1-uk-vla370-10-63-23-161.cisco.com [10.63.23.161]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8SGBxHY011255; Thu, 28 Sep 2017 16:12:00 GMT
To: "t.petch" , netmod@ietf.org, draft-ietf-netmod-revised-datastores@ietf.org, j.schoenwaelder@jacobs-university.de
References: <20170918.200734.1805388289423863575.mbj@tail-f.com>  <99b9a2c6-4bb4-121f-0cba-925cefe09712@cisco.com> <20170919.115559.1080249872764998055.mbj@tail-f.com>  <5481ac35-c789-0796-36f6-8a02a5ebef8c@cisco.com> <00c501d333c0$9d210280$4001a8c0@gateway.2wire.net>  <3274ba62-d60d-976b-9a22-879089abbbf2@cisco.com> <02d101d33873$2a3fdfe0$4001a8c0@gateway.2wire.net>
From: Robert Wilton 
Message-ID: 
Date: Thu, 28 Sep 2017 17:11:59 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <02d101d33873$2a3fdfe0$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod]  vs 
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Sep 2017 16:12:10 -0000

On 28/09/2017 16:39, t.petch wrote:
> Robert
>
> I would like you to tweak the definition of running configuration
> datastore slightly.
>
> You say
>
> " The running configuration datastore () is a configuration
>    datastore that holds the complete current configuration
>    on the device"
>
> which I see as black and white, the terminology is .
>
> But then you say
>
> "This datastore is commonly referred to
>    as "".
>
> which I see as introducing wiggle room with the use of 'commonly' so I
> would like you to excise 'commonly' leaving
>
> NEW
> This datastore is referred to as "".
Yes. fine with me.  We should also make the equivalent update for the 
other datastore definitions as well.

Thanks,
Rob

>
> Black and white.
>
> Tom Petch
>
> ----- Original Message -----
> From: "Robert Wilton" 
> Sent: Thursday, September 28, 2017 10:37 AM
>> After comment from the other authors, an updated proposed description
>> for  is as follows:
>>
>> OLD:
>>
>> 4.3. The Running Configuration Datastore ()
>>
>>    The running configuration datastore () holds the complete
>>    current configuration on the device. It may include inactive
>>    configuration or template-mechanism-oriented configuration that
>>    require further expansion.
>>
>>    If a device does not have a distinct  and non-volatile is
>>    available, the device will typically use that non-volatile storage
> to
>>    allow  to persist across reboots.
>>
>> NEW:
>>
>> 4.1.3. The Running Configuration Datastore ()
>>
>>    The running configuration datastore () is aconfiguration
>>    datastore that holds the complete current configuration
>>    on the device. It may include configuration that requires further
>>    transformation before it can be applied, e.g., inactive
>>    configuration, or template-mechanism-oriented configuration that
>>    needs further expansion. However,  MUST always be a 'valid
>>    configuration data tree' as defined in Section 8.1 of [RFC7950].
>>
>>     MUST be supported if the device can be configured via
>>    conventional configuration datastores.
>>
>>    If a device does not have a distinct  and non-volatile is
>>    available, the device will typically use that non-volatile storage
> to
>>    allow  to persist across reboots.
>>
>>
>> Given that the definition of  and  are being
> updated,
>> I think that the definitions should similarly be updated. Hence I
> propose:
>>
>>
>> OLD:
>>    o running configuration datastore: A configuration datastore holding
>>    the current configuration of the device. It may include inactive
>>    configuration or template-mechanism-oriented configuration that
>>    require further expansion. This datastore is commonly referred to
>>    as "".
>>
>> NEW (based on the new description of running above):
>>    o running configuration datastore: A configuration datastore holding
>>    the current configuration of the device. It may include
>>    configuration that requires furthertransformations before it can
>>    be applied. This datastore is commonly referred to
>>    as "".
>>
>>
>>
>> OLD:
>>
>>    o intended configuration: Configuration that is intended to be used
>>    by the device. For example, intended configuration excludes any
>>    inactive configuration and it would include configuration produced
>>    through the expansion of templates.
>>
>>
>> NEW (based on the proposed updated description of intended):
>>
>>    o intended configuration: Configuration that is intended to be used
>>    by the device. It represents the configuration after all
>>    configuration transformations to  have been performed and
>>    is the configuration that the system attempts to apply.
>>
>>
>>
>> It may also be helpful if we define "configuration transformation", or
>> would that be better captured in the introduction text?
>>
>> A possible definition could be along the lines of:
>>
>>    configuration transformation: The addition, modification or removal
> of
>>    configuration between the  and  datastores.
>>    Examples of configuration transformations include the removal of
>>    inactive configuration and the configuration produced through the
>>    expansion of templates.
>>
>> If I don't hear anything back, I'll take that as a tacit approval of
>> these proposed changes.
>>
>> Thanks,
>> Rob
>>
>>
>> On 22/09/2017 18:12, Robert Wilton wrote:
>>> Hi Tom,
>>>
>>>
>>> On 22/09/2017 17:34, t.petch wrote:
>>>> Robert
>>>>
>>>> I wonder if this says the opposite of what is intended
>>>>
>>>> -  holds the complete current configuration on the device.
>>> I agree.
>>>
>>>> - This could include inactiveconfiguration
>>> I agree.
>>>
>>>> -  must always be a 'valid configuration data tree' as
>>>> defined in Section 8.1 of [RFC7950].
>>> I agree.
>>>
>>>> Ergo, inactiveconfiguration must form part of a valid configuration
>>>> tree.
>>> Ergo, inactive configuration can form part of a valid configuration
>>> tree.
>>>
>>>> I thought the idea was that inactiveconfiguration was logically
> removed
>>>> before validation but this seems to state the opposite..
>>> I don't think that this is necessarily true. One choice is inactive
>>> configuration is removed before validation, but this isn't quite
> what
>>> I'm proposing. I'm proposing that the act of validation itself is
>>> refined (via an tbd inactive configuration draft) such that it
> ignores
>>> configuration nodes marked as inactive.
>>>
>>> Thanks,
>>> Rob
>>>
>>>> Tom Petch
>>>>
>>>> ----- Original Message -----
>>>> From: "Robert Wilton" 
>>>> Sent: Friday, September 22, 2017 10:03 AM
>>>>
>>>>> Hi,
>>>>>
>>>>> Regarding whether  is always valid, the proposed
> modification
>>>>> to the draft is to add the following text to section 4.3 that
>>>> describes
>>>>> :
>>>>>
>>>>> OLD:
>>>>>
>>>>> 4.3. The Running Configuration Datastore ()
>>>>>
>>>>> The running configuration datastore () holds the complete
>>>>> current configuration on the device. It may include inactive
>>>>> configuration or template-mechanism-oriented configuration that
>>>>> require further expansion.
>>>>>
>>>>> If a device does not have a distinct  and non-volatile is
>>>>> available, the device will typically use that non-volatile storage
>>>> to
>>>>> allow  to persist across reboots.
>>>>>
>>>>> NEW:
>>>>>
>>>>> 4.3. The Running Configuration Datastore ()
>>>>>
>>>>> The running configuration datastore () holds the complete
>>>>> current configuration on the device. This could, for example,
>>>> include
>>>>> inactiveconfiguration or template-mechanism-oriented configuration
>>>>> thatrequires further expansion.However,  must always be a
>>>>> 'valid configuration data tree' as defined in Section 8.1 of
>>>> [RFC7950].
>>>>> If a device does not have a distinct  and non-volatile is
>>>>> available, the device will typically use that non-volatile storage
>>>> to
>>>>> allow  to persist across reboots.
>>>>>
>>>>> END
>>>>>
>>>>>
>>>>> Then the intention is that if inactive or a templating solution is
>>>>> standardized then those drafts would update the validation rules
> in
>>>> RFC
>>>>> 7950 such that  is still valid. E.g. an inactive config
> draft
>>>>> would probably indicate that validation excludes all configuration
>>>> nodes
>>>>> that are marked as inactive.
>>>>>
>>>>> Does anyone have any comments?
>>>>>
>>>>> Do we also need to state that  must always be a 'valid
>>>>> configuration data tree'?
>>>>>
>>>>> Thanks,
>>>>> Rob
>>>>>
>>>>>
>>>>> On 19/09/2017 16:22, Robert Wilton wrote:
>>>>>> On 19/09/2017 10:55, Martin Bjorklund wrote:
>>>>>>> Robert Wilton  wrote:
>>>>>>>> On 18/09/2017 19:25, Andy Bierman wrote:
>>>>>>>>> On Mon, Sep 18, 2017 at 11:07 AM, Martin Bjorklund
>>>> >>>>>>>> > wrote:
>>>>>>>>>
>>>>>>>>> Juergen Schoenwaelder >>>>>>>> > wrote:
>>>>>>>>>> On Mon, Sep 18, 2017 at 05:17:46PM +0100, Robert Wilton
> wrote:
>>>>>>>>>>>> No. I do not agree that the MUST in RFC 7950 can be
>>>>>>>>> removed.
>>>>>>>>>>>> I do not agree the architecture should update YANG at all.
>>>>>>>>>>> OK.
>>>>>>>>>> I am with Andy here.  has always had the
>>>>>>>>> requirement to be
>>>>>>>>>> valid and we are not supposed to change that. Mechanisms for
>>>>>>>>> inactive
>>>>>>>>>> configuration or templating must be designed to be backwards
>>>>>>>>> compatible
>>>>>>>>>> I think.
>>>>>>>>> Ok. If we keep the requirement that  in itself must
> be
>>>>>>>>> valid, it just restricts the usefulness/expressiveness of
>>>>>>>>> inactive and
>>>>>>>>> template mechanisms, but it might be ok.
>>>>>>>>>
>>>>>>>>> I think that even w/o this requirement, the observable
>>>>>>>>> behavior for a
>>>>>>>>> client can be backwards compatible. For example, suppose we
>>>>>>>>> have an
>>>>>>>>> inactive access control rule that refers to a non-existing
>>>>>>>>> interface in
>>>>>>>>> . If a client that doesn't know anything about
>>>>>>>>> inactive asks
>>>>>>>>> for the contents of , our implementation removes the
>>>>>>>>> inactive
>>>>>>>>> nodes from the reply to the client. Only a client that
>>>>>>>>> opts-in to
>>>>>>>>> inactive will receive a reply with things that looks invalid
>>>>>>>>> if you
>>>>>>>>> don't take the inactive annotation into account.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> There are many ways that validation can fail because inactive
>>>> nodes
>>>>>>>>> are present,
>>>>>>>>> and considered part of the validation.
>>>>>>>>>
>>>>>>>>> e,g, min-elements, max-elements, mandatory, unique.
>>>>>>>>>
>>>>>>>>> I think we all agree that validation on the enabled nodes is
>>>> supposed
>>>>>>>>> to continue to work.
>>>>>>> Yes.
>>>>>>>
>>>>>>>>> Here is an attempt at a backwards-compatible solution:
>>>>>>>>>
>>>>>>>>> 1) current  and  responses only include
> enabled
>>>>>>>>> nodes.
>>>>>>>>> 2) old-style  operations do not alter inactive
> nodes
>>>>>>>>> 3) NMDA clients use , not  or .
> These
>>>>>>>>> responses
>>>>>>>>> include enabled and disabled nodes, so validation does not
> apply
>>>>>>>>> for 
>>>>>>>>> 4) new style  (i.e.  parameter used)
> can
>>>> alter
>>>>>>>>> any type of data node
>>>>>>>> //I think that inactive should always be an optional extension.
>>>> Not
>>>>>>>> everything needs the additional complexity.
>>>>>>>>
>>>>>>>> Hence rather than tying this function to specific NETCONF
>>>> operations,
>>>>>>>> I would suggest that there should be an extra parameter (like
> for
>>>>>>>> with-defaults) to allow a client to indicate to the server that
> a
>>>> get
>>>>>>>> or edit request is using the "with-inactive" extension.
>>>>>>>> 1) The server should also have a capability (or perhaps a leaf
>>>> defined
>>>>>>>> in YANG library) to indicate that it supports inactive
>>>> configuration.
>>>>>>>> 2) If a client doesn't use the extra "with-inactive" parameter
>>>> during
>>>>>>>> a get request then only active nodes are returned.
>>>>>>>> 3) If a client doesn't use the extra "with-inactive" parameter
>>>> during
>>>>>>>> an edit-data request then the request cannot include an extra
>>>> inactive
>>>>>>>> meta-data. The request is processed in a way that is equivalent
> to
>>>> an
>>>>>>>> existing NETCONF implementation, but it may unknowingly remove
>>>> some
>>>>>>>> inactive configuration (e.g. via a replace or remove operation
> on
>>>> an
>>>>>>>> inactive node). Operations like create, delete, none, replace
>>>> should
>>>>>>>> all treat an inactive target node the same way as in the node
>>>> doesn't
>>>>>>>> exist (e.g. delete on an inactive node would return a
>>>> "data-missing"
>>>>>>>> error), this ensures that the behaviour that an unaware client
>>>>>>>> observes is the same as the existing behaviour that it would
>>>> expect
>>>>>>>> from a regular 6241 compliant NETCONF implementation.
>>>>>>>> 4) It a client makes a get request including the
> "with-inactive"
>>>>>>>> parameter then they also get the inactive nodes as well, marked
>>>> with a
>>>>>>>> meta-data annotation.
>>>>>>>> 5) If a client makes an edit request including the
> "with-inactive"
>>>>>>>> parameter, then the inactive meta-data annotation can be used
> to
>>>> label
>>>>>>>> inactive nodes. Inactive nodes are regarded as regular data
> nodes
>>>> for
>>>>>>>> create/delete/replace/none operation error checking.
>>>>>>>>
>>>>>>>> I think that this approach is similar (perhaps even the same)
> as
>>>>>>>> Martin described.
>>>>>>> This is indeed how our implementation works (except I think we
>>>> don't
>>>>>>> do 5; if the client sends an "inactive" attribute it doesn't
> have
>>>> to
>>>>>>> also send with-inactive).
>>>>>>>
>>>>>>>>> Note that the YANG MUST rule still applies, because validation
> is
>>>> only
>>>>>>>>> done on enabled nodes.
>>>>>>>>> It is only the response message representations that cannot be
>>>>>>>>> validated, not the contents
>>>>>>>>> of  on a server.
>>>>>>> So the question is how we can make sure that the text in the
> NMDA
>>>>>>> draft covers this yet-to-be-defined feature w/o having to define
> it
>>>>>>> now? We thought that the current text was sufficient, but do we
>>>> have
>>>>>>> to make any changes to it?
>>>>>> 1) Do we also need to illustrate a similar proof of concept
>>>> templating
>>>>>> implementation to show that templating could work whilst keeping
>>>>>> running valid? I would prefer that this is just deferred to
>>>> whichever
>>>>>> draft defines templating.
>>>>>>
>>>>>> 2) I think that we need to reach a decision as to whether the
> NMDA
>>>>>> architecture needs to explicitly state that  is always
>>>> valid,
>>>>>> or if that can be left to the existing statement in 7950. My
>>>> thinking
>>>>>> is that if the conclusion is that  must always be valid,
>>>> then
>>>>>> it would be helpful to explicitly state it the descriptions of
> both
>>>>>>  and  in the NMDA architecture.
>>>>>>
>>>>>> 3) I think that it would be useful to further refine my previous
>>>>>> proposed text for intended, particularly rewriting the text on
>>>>>> validation. This should hopefully also address Balazs' concern
> about
>>>>>> default values be included in validation.
>>>>>>
>>>>>> 
>>>>>>
>>>>>> 4.4. The Intended Configuration Datastore ()
>>>>>>
>>>>>> The intended configuration datastore () is a read-only
>>>>>> configuration datastore. It is tightly coupled to . When
>>>>>> data is written to , the data that is to be validated is
>>>>>> also conceptually written to . Validation is performed
> on
>>>>>> the contents of .
>>>>>>
>>>>>> For simple implementations,  and  are
> identical.
>>>>>>  does not persist across reboots; its relationship with
>>>>>>  makes that unnecessary.
>>>>>>
>>>>>> Currently there are no standard mechanisms defined that affect
>>>>>>  so that it would have different contents than
> ,
>>>>>> but this architecture allows for such mechanisms to be defined.
>>>>>>
>>>>>> One example of such a mechanism is support for marking nodes as
>>>>>> inactive in . Inactive nodes are not copied to
> ,
>>>>>> and are thus not taken into account when validating the
>>>>>> configuration.
>>>>>>
>>>>>> Another example is support for templates. Templates are expanded
>>>>>> when copied into , and the expanded result is
> validated.
>>>>>> 
>>>>>> 
>>>>>>
>>>>>> 4.1.4. The Intended Configuration Datastore ()
>>>>>>
>>>>>> The intended configuration datastore () is a read-only
>>>>>> configuration datastore. It represents the configuration after
> all
>>>>>> configuration transformations to  are performed (e.g.
>>>>>> template expansion, removal of inactive configuration), and is
> the
>>>>>> configuration that the system attempts to apply.
>>>>>>
>>>>>>  is tightly coupled to . Whenever data is
> written
>>>>>> to , then  is also immediately updated by
>>>>>> performing all necessary transformations to the contents of
>>>> 
>>>>>> and then  is validated.
>>>>>>
>>>>>>  may also be updated independently of  (e.g.,
> if
>>>>>> one of the configuration transformations is changed), but
> 
>>>>>> must always be a 'valid configuration data tree' as defined in
>>>>>> Section 8.1 of [RFC7950].
>>>>>>
>>>>>> For simple implementations,  and  are
> identical.
>>>>>> The contents of  is also related to the 'config true'
>>>>>> subset of , and hence a client can determine to what
>>>>>> extent the intended configuration is currently in use by checking
>>>>>> whether the contents of  also appears in .
>>>>>>
>>>>>>  does not persist across reboots; its relationship with
>>>>>>  makes that unnecessary.
>>>>>>
>>>>>> Currently there are no standard mechanisms defined that affect
>>>>>>  so that it would have different contents than
> ,
>>>>>> but this architecture allows for such mechanisms to be defined.
>>>>>>
>>>>>> One example of such a mechanism is support for marking nodes as
>>>>>> inactive in . Inactive nodes are not copied to
> .
>>>>>> A second example is support for templates, which can perform
>>>>>> transformations on the configuration from  to the
>>>>>> configuration written to .
>>>>>>
>>>>>> 
>>>>>>
>>>>>> Thanks,
>>>>>> Rob
>>>>>>
>>>>>>
>>>>>>> /martin
>>>>>>> .
>>>>>>>
>>>>>> .
>>>>>>
>>>> .
>>>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
> .
>


From nobody Thu Sep 28 09:28:50 2017
Return-Path: 
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 2231B132D44 for ; Thu, 28 Sep 2017 09:28:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 IhVGn7Nl6L1E for ; Thu, 28 Sep 2017 09:28:48 -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 B0264134234 for ; Thu, 28 Sep 2017 09:28:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5092; q=dns/txt; s=iport; t=1506616119; x=1507825719; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=fuUPQLmLmhSQoh1OXlqruKPPmMReN4Lm69BUF6V6NYk=; b=U32hOWVpvhNQXCmjg8PycPKmOcIs1FIZqEHVaKAFGvZ+kVqcHODrbE4r MPbP6l9RGQ/jf+29vtazGDYi9qotL9oSxd+s7C5zU3ugNpRnY/y0OT7S+ L6yyjhTuQK4VvWwjnjrNNWaHVVjpryUq+Ec0LR9zzmX6QKFtkC9AoWQI+ A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQDIIc1Z/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhEBuhB+LE5BgljmCBAojhRgChGcVAQIBAQEBAQEBayiFGQEFIw8?= =?us-ascii?q?BBUEQCxgCAhEVAgJXBgEMCAEBii0Qpw2CJ4sRAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEZBYEOgh2DU4FqK4J9hD+BBIJUgmAFoSiHXo0Ci1uHK410h1mBOTUiQkwyIQg?= =?us-ascii?q?dFUmHHj+GeSyCFQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.42,450,1500940800"; d="scan'208";a="697617866"
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; 28 Sep 2017 16:28:37 +0000
Received: from [10.63.23.161] (dhcp-ensft1-uk-vla370-10-63-23-161.cisco.com [10.63.23.161]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v8SGSbiS011436; Thu, 28 Sep 2017 16:28:37 GMT
To: Balazs Lengyel , Martin Bjorklund 
Cc: netmod@ietf.org
References: <9ec6b2e4-36a7-87e6-59fa-828855235835@ericsson.com> <20170914.163239.143365521945928900.mbj@tail-f.com> <0605fab0-f879-e02d-4858-52a247571cb8@ericsson.com>
From: Robert Wilton 
Message-ID: 
Date: Thu, 28 Sep 2017 17:28:37 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <0605fab0-f879-e02d-4858-52a247571cb8@ericsson.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Comments on NMDA-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Sep 2017 16:28:50 -0000

Hi,

Regarding the issue "Is it allowed to violate uniqueness of key 
values?", https://github.com/netmod-wg/datastore-dt/issues/10

We have discussed this further, and would like to extend the text in the 
draft to explicitly allow key uniqueness to be violated!

We have thought of several cases where it is possible that duplicate 
entries could appear, and we don't want to force any overhead on the 
device to guarantee that this does not occur, nor do we want to force 
synchronization between configuration processing and what is reported in 
.  Of course, in normal circumstances this constraint, like 
the others, should not be violated.  This is already stated in the draft.

Examples of where uniqueness of list keys could be violated include:
1) If a device is internally paging the results back for a long list, 
then it is possible that a entry could have been reported near the 
beginning of the list, then moved, and then reported again at the end of 
the list.
2) If the list being stored somewhere in the system has become corrupted 
and contains duplicate entries.  It is better to return truth.
3) On a distributed system where the list is being constructed from 
multiple nodes (e.g. linecards or peer devices) then if a list entry is 
moved from one node to another then it is again possible that an entry 
could be reported in both places (or neither) for a short interval 
before the system becomes consistent again.

Proposed text:

OLD:

     SHOULD conform to any constraints specified in the data
    model, but given the principal aim of returning "in use" values, it
    is possible that constraints MAY be violated under some
    circumstances, e.g., an abnormal value is "in use", or due to remnant
    configuration (see Section 4.3.1).  Note, that deviations are still
    used when it is known in advance that a device does not fully conform
    to the  schema.

    Only semantic constraints MAY be violated, these are the YANG "when",
    "must", "mandatory", "unique", "min-elements", and "max-elements"
    statements.

NEW:

     SHOULD conform to any constraints specified in the data
    model, but given the principal aim of returning "in use" values, it
    is possible that constraints MAY be violated under some
    circumstances, e.g., an abnormal value is "in use", the structure of
    a list is being modified, or due to remnant configuration (see
    Section 4.3.1).  Note, that deviations are still used when it is
    known in advance that a device does not fully conform to the
     schema.

    Only semantic constraints MAY be violated, these are the YANG "when",
    "must", "mandatory", "unique", "min-elements", and "max-elements"
    statements; and the uniqueness of key values.

Again, if there are no objections, I will apply this change.

Thanks,
Rob


On 14/09/2017 16:44, Balazs Lengyel wrote:
> See below !
>
>
> On 2017-09-14 16:32, Martin Bjorklund wrote:
>
>>> CH 4.4.)  "Validation is performed on the contents of ."
>>> This to me means that default data is not considered at validation
>> Note that RFC 7950, section 6.4.1, says:
>>
>>     In the accessible tree, all leafs and leaf-lists with default values
>>     in use exist (see Sections 7.6.1 and 7.7.2).
>>
>> So defaults are taken into account when intended is validated.
> BALAZS: Yes the two seem to contradict each other. This can be 
> understood in your way, however the current text is not clear enough. 
> I would add:
> Validation is performed on the contents of  (EXTENDED WITH 
> DEFAULT CONFIGURATION).
>>> which would be a backwards incompatible change. Also if validation
>>> does not consider system configured data that would allow cases like
>>> multiple interfaces named lo0. One from  one from system
>>> configuration. IMHO while it is OK to violate uniqueness because of
>>> remnant data, the above violation of uniqueness seems a bad idea.
>> If your system adds data to , or to , it will be
>> validated.
>>
>>> Ch. 4.7) Is it allowed to violate uniqueness of key values? IMHO it
>>> should not be.
>> Agreed.  Note that the draft explicitly lists the constraints that can
>> be violated, and uniqueness of keys is not listed.
> BALAZS: If that is the intent I would propose to explicitly state it. 
> For me it was non-trivial.
> Can a a choice statement be violated? Having to existing branches at 
> the same time? It seems a semantic constraint to me. IMHO yes.
> Can an if-feature be violated? If  support has just changed and we 
> have some remnant config, I can very well imagine it violated.
>
> Also here could you change
> If a node in   does not meet the syntactic constraints 
> then it cannot   be returned
> to
> If a node in   does not meet the syntactic constraints 
> then it MUST NOT be returned
>> /martin
>


From nobody Thu Sep 28 09:59:24 2017
Return-Path: 
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 31C2C1342CD for ; Thu, 28 Sep 2017 09:59:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 EU9CQkzyrn4o for ; Thu, 28 Sep 2017 09:59:19 -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 50A2B134762 for ; Thu, 28 Sep 2017 09:59:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2463; q=dns/txt; s=iport; t=1506617959; x=1507827559; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=M25HBhA3UmXwk/8xWpjeGjMrESB+FY5qKXWvwIE5mGo=; b=VB60JGz9QSlPGMSPwk7ccRPRFBIrPlejRmVwSSI2uT9qkewQ6Uh2z0Jp Ueybt8mL/8CyNHNhltmSZptAU22DUDgZjmRI1HnH0fY/0paDnDDtQkquC iYXwSHF0yysx0iFfuukEjI1f45LgxPjNDFuCI5fU/aWduX6VYRZlom1PG k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BkAgBCKc1Z/xbLJq1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgy+BEW6EH4sTkD6YXwojigEVAQIBAQEBAQEBax0LhUIPAQVuCAImAks?= =?us-ascii?q?UDQgBAYotEKcTgieLEgEBCAIBIAWBDoIdg1OBaisLgWWJJIJgBaEoh16NAoITi?= =?us-ascii?q?UiHK4oQg2SHWYE5NSJCTDIhCB0Vh2c/hnksghUBAQE?=
X-IronPort-AV: E=Sophos;i="5.42,450,1500940800"; d="scan'208";a="655049051"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Sep 2017 16:59:17 +0000
Received: from [10.63.23.161] (dhcp-ensft1-uk-vla370-10-63-23-161.cisco.com [10.63.23.161]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v8SGxGLc017366 for ; Thu, 28 Sep 2017 16:59:17 GMT
To: "netmod@ietf.org" 
From: Robert Wilton 
Message-ID: <56ec3b6d-86d8-e8ff-8077-fea5550c4409@cisco.com>
Date: Thu, 28 Sep 2017 17:59:16 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: [netmod] Summary of issues for WG LC for draft-ietf-netmod-revised-datastores-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Sep 2017 16:59:22 -0000

Hi,

Here is the status, and proposed resolution, of all the issues tracked 
on github for the WG LC of the revised datastores draft:

https://github.com/netmod-wg/datastore-dt/issues

Proposed text has been sent to the WG alias for all the open issues 
except the move to the RFC 2119 language and the updated introduction.  
I think that these 2 changes would be best be reviewed once all of WG 
feedback has been incorporated into the draft and a new version posted 
for the WG to verify that all concerns have been addressed.


#1 Define "inactive configuration"
Resolution: Proposal is that this issue is also covered by #5.

#2 Emphasize that the schema for all conventional datastores must be the 
same
Resolution: Proposed text accepted, draft updated, issue closed.

#3 Enhance description of intended datastore
Resolution: Proposed text sent to WG, draft will be updated.

#4 Make convention datastores a subsection of conventional
Resolution: Change accepted, draft updated, issue closed.

#5 Provide a better introduction to justify the architecture
Resolution: Change accepted, draft will be updated.

#6 Describe validation
Resolution: Proposed text defining  sent to WG, draft will be 
updated.

#7 Other cosmetic improvements proposed by Phil
Resolution: Change accepted, draft updated, issue closed.

#8 Allow the system to add configuration to 
Resolution: No change to the draft, issue will be closed.

#9 Make it clear that validation of intended includes default values
Resolution: Covered by propose text for issue #3, issue will be closed.

#10 Is it allowed to violate uniqueness of key values?
Resolution: Proposed text sent to WG, draft will be updated.

#11 actions and rpcs should be allowed to include other datastores in 
their XPath evaluation.
Resolution: Out of scope, issue will be closed.

#12 Appendix minor comments
Resolution: Change accepted, draft updated, issue closed.

#13 Does the NMDA architecture need to update 7950?
Resolution: Yes, document updated, issue closed.

#14 Does the NMDA architecture need to use RFC 2119 language?
Resolution: Yes, document will be updated.

#15 How can a client determine that a module is NMDA compatible?
Resolution: No change required, issue will be closed.

#16 Remove "commonly" from datastore definition sentences.
Resolution: New.  Currently plan to accept the proposed change.

Thanks,
Rob


From nobody Fri Sep 29 02:22:29 2017
Return-Path: 
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 2FB79132941; Fri, 29 Sep 2017 02:22:22 -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 j-e1DNjG33ON; Fri, 29 Sep 2017 02:22:18 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABEB1132403; Fri, 29 Sep 2017 02:22:15 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DWM85036; Fri, 29 Sep 2017 09:22:12 +0000 (GMT)
Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 29 Sep 2017 10:22:10 +0100
Received: from DGGEML507-MBX.china.huawei.com ([169.254.2.79]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0301.000; Fri, 29 Sep 2017 17:22:03 +0800
From: Jiangyuanlong 
To: Martin Bjorklund 
CC: "sean.condon@microsemi.com" , "netmod@ietf.org" , "tictoc@ietf.org" 
Thread-Topic: [netmod] draft-ietf-tictoc-1588v2-yang-05 - Concern over port identifier
Thread-Index: AdM20lxp4a4LJ64bREK66XJnd3gJawAF4nRwABKMRUAAEqGn9wA1hiAA//+KVAD//jENcA==
Date: Fri, 29 Sep 2017 09:22:02 +0000
Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5CC14E@dggeml507-mbx.china.huawei.com>
References: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5C9C01@dggeml507-mbx.china.huawei.com> <640F4C69F839A64C8949EF04FAAEE44679F25561@avsrvexchmbx1.microsemi.net> <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5CB62E@dggeml507-mbx.china.huawei.com> <20170928.152312.261607006753399632.mbj@tail-f.com>
In-Reply-To: <20170928.152312.261607006753399632.mbj@tail-f.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.74.202.215]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59CE10C5.00AD, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.2.79, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: d823f5a7908b24376032dabf2c58d99d
Archived-At: 
Subject: Re: [netmod] draft-ietf-tictoc-1588v2-yang-05 - Concern over port identifier
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Sep 2017 09:22:22 -0000

TWFydGluLA0KDQpUaGFuayBhIGxvdCBmb3IgeW91ciBpbnN0YW50bHkgcmVwbHkuIFBsZWFzZSBz
ZWUgbXkgZnVydGhlciBjb21tZW50cyBpbmxpbmUuDQoNCkNoZWVycywNCll1YW5sb25nDQoNCi0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNYXJ0aW4gQmpvcmtsdW5kIFttYWlsdG86
bWJqQHRhaWwtZi5jb21dIA0KU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAyOCwgMjAxNyA5OjIz
IFBNDQpUbzogSmlhbmd5dWFubG9uZw0KQ2M6IHNlYW4uY29uZG9uQG1pY3Jvc2VtaS5jb207IG5l
dG1vZEBpZXRmLm9yZzsgdGljdG9jQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW25ldG1vZF0gZHJh
ZnQtaWV0Zi10aWN0b2MtMTU4OHYyLXlhbmctMDUgLSBDb25jZXJuIG92ZXIgcG9ydCBpZGVudGlm
aWVyDQoNCkppYW5neXVhbmxvbmcgPGppYW5neXVhbmxvbmdAaHVhd2VpLmNvbT4gd3JvdGU6DQo+
IFNlYW4sDQo+IA0KPiBNeSBwZXJzb25hbCBvcGluaW9uIGlzIHRoYXQgaXQgY2FuIHdvcmssIGJ1
dCBJIHdvdWxkIGxpa2UgdG8gYXNrIGZvciANCj4gbW9yZSBvcGluaW9ucyBmcm9tIG91ciBuZXRt
b2QgZXhwZXJ0czspDQo+IA0KPiBIaSBuZXRtb2QgZXhwZXJ0cywNCj4gQ29uc2lkZXJpbmcgdGhl
IGZvbGxvd2luZyBzYW1wbGUgbW9kdWxlLCBteS1saXN0IGlzIGEgbGlzdCwgYW5kIGl0IA0KPiBu
ZWVkcyB0byB1c2UgYSBsZWFmIG1lbWJlciAicG9ydC1udW1iZXIiIGluIG15LXBvcnQtY29udGFp
bmVyIGFzIGEgDQo+IGtleS4NCj4gV2Ugbm93IGhhdmUgMyBvcHRpb25zOg0KPiAxLg0KPiAgIGxp
c3QgbXktbGlzdCB7DQo+ICAgICBrZXkgInBvcnQtbnVtYmVyIjsNCj4gICAgIGxlYWYgcG9ydC1u
dW1iZXIgew0KPiAgICAgICAgdHlwZSB1aW50MTY7DQo+ICAgICB9DQo+IA0KPiAgICAgY29udGFp
bmVyIG15LXBvcnQtY29udGFpbmVyIHsNCj4gICAgICAgICBsZWFmIHBvcnQtbnVtYmVyIHsNCj4g
ICAgICAgICAgIHR5cGUgdWludDE2Ow0KPiAgICAgICAgIH0NCj4gICAgICAgICAgbGVhZiBvdGhl
ci1sZWFmIHsNCj4gICAgICAgICAgICAuLi4NCj4gICAgICAgICAgfQ0KPiAgICAgfQ0KPiAgIH0N
Cj4gQnV0IHRoaXMgZG9lcyBub3Qgd29yayBmb3IgdGhlcmUgaXMgY29tcGlsaW5nIGVycm9yLg0K
DQpXaHkgd291bGRuJ3QgdGhpcyB3b3JrPw0KW0pZXSBUaGUgb3JpZ2luYWwgaW50ZW50aW9uIG9m
IHRoZSAxNTg4IGluZm8gbW9kZWwgaXMgdG8gdXNlIG15LXBvcnQtY29udGFpbmVyLnBvcnQtbnVt
YmVyIGFzIHRoZSBrZXkuIFRoZSBjb2RlIGFjdHVhbGx5IHBhcnNlcywgYnV0IHdlIG5lZWQgdG8g
c3luY2hyb25pemUgbXktbGlzdC5wb3J0LW51bWJlciBhbmQgbXktbGlzdC5teS1wb3J0LWNvbnRh
aW5lci5wb3J0LW51bWJlciBhbGwgdGhlIHdoaWxlLg0KDQpJIHN1c3BlY3QgeW91IG1lYW50Og0K
DQogICBsaXN0IG15LWxpc3Qgew0KICAgICBrZXkgInBvcnQtbnVtYmVyIjsNCiANCiAgICAgY29u
dGFpbmVyIG15LXBvcnQtY29udGFpbmVyIHsNCiAgICAgICAgIGxlYWYgcG9ydC1udW1iZXIgew0K
ICAgICAgICAgIHR5cGUgdWludDE2Ow0KICAgICAgICAgfQ0KICAgICAgICAgIGxlYWYgb3RoZXIt
bGVhZiB7DQogICAgICAgICAgICAuLi4NCiAgICAgICAgICB9DQogICAgIH0NCiAgIH0NCg0KDQo+
IDIuDQo+ICAgbGlzdCBteS1saXN0IHsNCj4gICAgIGtleSAicG9ydC1udW1iZXIiOw0KPiAgICAg
bGVhZiBwb3J0LW51bWJlciB7DQo+ICAgICAgICB0eXBlIHVpbnQxNjsNCj4gICAgIH0NCj4gICAg
IGNvbnRhaW5lciBteS1wb3J0LWNvbnRhaW5lciB7DQo+ICAgICAgICAgbGVhZiBwb3J0LW51bWJl
ciB7DQo+ICAgICAgICAgICAgIHR5cGUgbGVhZnJlZnsNCj4gICAgICAgICAgICAgICBwYXRoICIu
Li8uLi9wb3J0LW51bWJlciI7DQo+ICAgICAgICAgICAgIH0NCj4gICAgICAgICB9DQo+ICAgICAg
ICAgIGxlYWYgb3RoZXItbGVhZiB7DQo+ICAgICAgICAgICAgLi4uDQo+ICAgICAgICAgIH0NCj4g
ICAgIH0NCj4gICB9DQo+IE9wdGlvbiAyIGNhbiBwYXJzZSwgdGhvdWdoIGxlYWZyZWYgaW4gYSBz
dWItbW9kdWxlIHNlZW1zIG5vdCB2ZXJ5IA0KPiBuYXR1cmFsLg0KPiANCj4gMy4NCj4gICBsaXN0
IG15LWxpc3Qgew0KPiAgICAga2V5ICJwb3J0LW51bWJlciI7DQo+ICAgICBsZWFmIHBvcnQtbnVt
YmVyIHsNCj4gICAgICAgIHR5cGUgbGVhZnJlZnsNCj4gICAgICAgICAgIHBhdGggIi4uL215LXBv
cnQtY29udGFpbmVyL3BvcnQtbnVtYmVyIjsNCj4gICAgICAgIH0NCj4gICAgIH0NCj4gICAgIGNv
bnRhaW5lciBteS1wb3J0LWNvbnRhaW5lciB7DQo+ICAgICAgICAgbGVhZiBwb3J0LW51bWJlciB7
DQo+ICAgICAgICAgICB0eXBlIHVpbnQxNjsNCj4gICAgICAgICB9DQo+ICAgICAgICAgIGxlYWYg
b3RoZXItbGVhZiB7DQo+ICAgICAgICAgICAgLi4uDQo+ICAgICAgICAgIH0NCj4gICAgIH0NCj4g
ICB9DQo+IA0KPiBPcHRpb24gMyBjYW4gYWxzbyBwYXJzZSwgdGhvdWdoIGxlYWZyZWYgc2VlbXMg
bm90IGEgdmVyeSBuYXR1cmFsIGtleS4gDQo+IFdoYXQgaXMgeW91ciBmYXZvcml0ZSBvcHRpb24/
IE9yIGRvIHlvdSBoYXZlIGFueSBiZXR0ZXIgc2NoZW1lcz8NCg0KDQpIYXZpbmcgYSBsZWFmcmVm
IGxpa2UgaW4gb3B0aW9uIDIgb3IgMyBpcyBqdXN0IHJlZHVuZGFudCBhbmQgYSBoYXNzbGUgZm9y
IHRoZSBjbGllbnQuICBJbiBvcmRlciB0byBjcmVhdGUgYSBhIGxpc3QgZW50cnksIHRoZSBjbGll
bnQgd291bGQgaGF2ZSB0byBmaXJzdCBwcm92aWRlIHRoZSBwb3J0LW51bWJlciB2YWx1ZSBvbmNl
IGZvciB0aGUga2V5LCBhbmQgdGhlbiBhZ2FpbiB0aGUgZXhhY3Qgc2FtZSB2YWx1ZSBpbiB0aGUg
Y29udGFpbmVyOg0KDQogIDxteS1saXN0Pg0KICAgIDxwb3J0LW51bWJlcj4yNTwvcG9ydC1udW1i
ZXI+DQogICAgPG15LXBvcnQtY29udGFpbmVyPg0KICAgICAgPHBvcnQtbnVtYmVyPjI1PC9wb3J0
LW51bWJlcj4NCiAgICAgIDxvdGhlci1sZWFmPi4uLjwvb3RoZXItbGVhZj4NCiAgICA8L215LXBv
cnQtY29udGFpbmVyPg0KICA8L215LWxpc3Q+DQoNCk5vdGUgdGhhdCBib3RoICJwb3J0LW51bWJl
ciIgTVVTVCBiZSBnaXZlbiB0aGUgZXhhY3Qgc2FtZSB2YWx1ZSBieSB0aGUgY2xpZW50Lg0KDQpJ
biBZQU5HLCBrZXkgbGVhZnMgY2Fubm90IGJlIG5lc3RlZCB1bmRlciBjb250YWluZXJzLiAgSSB3
b3VsZCBzaW1wbHkgaGF2ZSB0aGUga2V5IG9uIHRoZSB0b3Agb2YgdGhlIGxpc3QsIGFuZCBub3Qg
aW4gdGhlIGNvbnRhaW5lci4NCg0KKEl0IHNlZW1zIHRoaXMgaXMgd2hhdCBvdGhlcnMgaGF2ZSBw
cm9wb3NlZCBhcyB3ZWxsIGluIHRoaXMgdGhyZWFkLikNCg0KW0pZXSBZZXMsIEkgYWdyZWUgdGhh
dCB0aGlzIG1vZGVsIGlzIG5vdCB2ZXJ5IGVsZWdhbnQsIGJ1dCB0aGUgaW5mbyBtb2RlbCB3YXMg
cHVibGlzaGVkIGluIElFRUUgMTU4OCBhbHJlYWR5LCBwZW9wbGUgaGF2ZSBiZWVuIHVzZWQgdG8g
dGhpcyBpbmZvIG1vZGVsIGZvciBhIGxvbmcgdGltZSBhbmQgd2Ugd291bGQgbGlrZSB0byBzdGlj
ayB0byBpdCBhcyBmYXIgYXMgd2UgY2FuLiANCkFzIGFuIGFsdGVybmF0aXZlLCBvcHRpb24gMiBj
YW4gYmUgZW5oYW5jZWQ6DQogICBsaXN0IG15LWxpc3QgeyANCiAgICAga2V5ICJwb3J0LW51bWJl
ciI7IA0KICAgICBsZWFmIHBvcnQtbnVtYmVyIHsgDQogICAgICAgIHR5cGUgdWludDE2OyANCiAg
ICAgfSANCiAgICAgY29udGFpbmVyIG15LXBvcnQtY29udGFpbmVyIHsgDQogICAgICAgICBsZWFm
IHBvcnQtbnVtYmVyIHsgDQogICAgICAgICAgICAgdHlwZSBsZWFmcmVmeyANCiAgICAgICAgICAg
ICAgIHBhdGggIi4uLy4uL3BvcnQtbnVtYmVyIjsgDQogICAgICAgICAgICAgfQ0KICAgICAgICAg
ICAgIGNvbmZpZyBmYWxzZTsNCiAgICAgICAgIH0gDQogICAgICAgICBsZWFmIG90aGVyLWxlYWYg
eyANCiAgICAgICAgICAgLi4uIA0KICAgICAgIH0gDQogICAgIH0gDQogICB9DQoNCkluIHRoaXMg
d2F5LCB0aGUgImNvbmZpZyBmYWxzZSIgbWFrZXMgdGhlIGxlYWZyZWYgcmVhZC1vbmx5LCBzbyB0
aGF0IGNvbmZpZ3VyYXRpb24gZG9lc24ndCBuZWVkIHRvIHdyaXRlIHR3aWNlLiBIb3cgZG8geW91
IHRoaW5rIGFib3V0IHRoaXMgc2NoZW1lPw0KVGhhbmtzIGFnYWluLA0KWXVhbmxvbmcNCg0KDQov
bWFydGluDQoNCg0KDQoNCg0KPiBZb3VyIG9waW5pb25zIGFyZSB2ZXJ5IGltcG9ydGFudCBmb3Ig
b3VyIHJldmlzaW9uIG9mIHRoaXMgZHJhZnQuDQo+IA0KPiBUaGFua3MsDQo+IFl1YW5sb25nDQo+
IA0KPiANCj4gRnJvbTogU2VhbiBDb25kb24gW21haWx0bzpzZWFuLmNvbmRvbkBtaWNyb3NlbWku
Y29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAyNywgMjAxNyA3OjExIFBNDQo+IFRv
OiBKaWFuZ3l1YW5sb25nDQo+IENjOiB0aWN0b2NAaWV0Zi5vcmc7IFJvZG5leSBDdW1taW5ncw0K
PiBTdWJqZWN0OiBSRTogZHJhZnQtaWV0Zi10aWN0b2MtMTU4OHYyLXlhbmctMDUgLSBDb25jZXJu
IG92ZXIgcG9ydCANCj4gaWRlbnRpZmllcg0KPiANCj4gVGhhbmtzIGd1eXMgZm9yIHlvdXIgcmVz
cG9uc2VzLg0KPiANCj4gSSBhY2NlcHQgeW91ciBwb2ludHMgdG8ga2VlcCB0aGUgc3RydWN0dXJl
IGFzIGFsaWduZWQgdG8gdGhlIElFRUUgMTU4OCANCj4gc3RhbmRhcmQgYXMgcG9zc2libGUuDQo+
IA0KPiBPbmUgYWx0ZXJuYXRlIHN1Z2dlc3Rpb24gdGhhdCBJIHdvdWxkIG1ha2UsIGlzIHRoYXQg
dGhlIHBvcnQtbnVtYmVyIA0KPiBjdXJyZW50bHkgZGVmaW5lZCBhcyBsZWFmcmVmIHNob3VsZCBi
ZSBtYWRlIHRoZSByZWFsIGF0dHJpYnV0ZSAoaS5lLiANCj4gdWludDE2KSBhbmQgdGhhdCB0aGUg
cG9ydC1udW1iZXIgaW5zaWRlIHBvcnQtaWRlbnRpdHkgY29udGFpbmVyIHNob3VsZCANCj4gYmUg
bWFkZSBpbiB0byB0aGUgbGVhZiByZWYgKGFuZCBzZXQgdG8gbWFuZGF0b3J5IHRydWUpLg0KPiAN
Cj4gVGhlIHJlYXNvbiBJIHNheSB0aGlzIGlzIHRoYXQNCj4gDQo+ICAgMS4gIFhNTCBtb2RlbHMg
YXJlIHVzdWFsbHkgbmF2aWdhdGVkIGFuZCBjb25zdHJ1Y3RlZCByb290LXRvLWxlYWYsIGFuZA0K
PiAgIHRoZSB3YXkgaXQncyBwb3J0cmF5ZWQgYXQgdGhlIG1vbWVudCBpcyB0aGF0IHBvcnQtbnVt
YmVyIGxlYWZyZWYNCj4gICBwb2ludHMgdG8gc29tZXRoaW5nIHRoYXQgbWF5IG5vdCBleGlzdCBh
dCB0aGUgdGltZSBpdCBpcyBiZWluZw0KPiAgIGRlZmluZWQuIFRoaXMgbWFrZXMgaXQgZGlmZmlj
dWx0IHRvIGltcGxlbWVudC4NCj4gICAyLiAgQWxzbyBwb3J0LWlkZW50aXR5L3BvcnQtbnVtYmVy
IGlzIG5vdCAibWFuZGF0b3J5IHRydWUiIG1lYW5pbmcNCj4gICB0aGF0IGl0IGNvdWxkIGJlIGxl
ZnQgb3V0IGFsdG9nZXRoZXIuIEl0J3Mgbm90IHZhbGlkIGZvciBpdCB0byBoYXZlIGENCj4gICBk
ZWZhdWx0IHZhbHVlIGVpdGhlciBzaW5jZSBldmVyeSBpdGVtIGluIHRoZSBsaXN0IHdpbGwgbmVl
ZCBhDQo+ICAgZGlmZmVyZW50IGlkZW50aWZpZXIuDQo+IA0KPiBXaXRoIHRoaXMgc3VnZ2VzdGlv
biB0aGUgc3RydWN0dXJlIHlvdSByZXF1aXJlIHdpdGggcG9ydC1pZGVudGl0eSANCj4gc3RpbGwg
ZXhpc3RzLCBidXQgbm93IHRoZSBpbXBsZW1lbnRhdGlvbiBpcyBtb3JlIHN0cmFpZ2h0Zm9yd2Fy
ZCwgYW5kIA0KPiB0aGUgY2hhbmdlIHdpbGwgYmUgdHJhbnNwYXJlbnQgdG8gYW4gZW5kIHVzZXIu
DQo+IA0KPiANCj4gQmVzdCByZWdhcmRzLCBTZWFuDQo+ID09PT09PT09PT09PT09PT09PT09PT09
DQo+IFNlYW4gQ29uZG9uDQo+IFN5c3RlbSAmIFNvZnR3YXJlIEFyY2hpdGVjdA0KPiBGcmVxdWVu
Y3kgJiBUaW1pbmcgRGl2aXNpb24NCj4gTWljcm9zZW1pIEluYy4NCj4gc2Vhbi5jb25kb25AbWlj
cm9zZW1pLmNvbTxtYWlsdG86c2Vhbi5jb25kb25AbWljcm9zZW1pLmNvbT4NCj4gDQo+IF9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEZyb206IEppYW5neXVhbmxvbmcgW2ppYW5n
eXVhbmxvbmdAaHVhd2VpLmNvbV0NCj4gU2VudDogMjcgU2VwdGVtYmVyIDIwMTcgMDg6MDUNCj4g
VG86IFNlYW4gQ29uZG9uDQo+IENjOiB0aWN0b2NAaWV0Zi5vcmc8bWFpbHRvOnRpY3RvY0BpZXRm
Lm9yZz47IFJvZG5leSBDdW1taW5ncw0KPiBTdWJqZWN0OiBSRTogZHJhZnQtaWV0Zi10aWN0b2Mt
MTU4OHYyLXlhbmctMDUgLSBDb25jZXJuIG92ZXIgcG9ydCANCj4gaWRlbnRpZmllciBFWFRFUk5B
TCBFTUFJTA0KPiANCj4gRGVhciBTZWFuLA0KPiANCj4gDQo+IA0KPiBUaGFuayB5b3UgYSBsb3Qg
Zm9yIGRpdmluZyBpbnRvIHRoZSB0ZWNobmljYWwgZGV0YWlscyBvZiB0aGlzIG1vZHVsZS4gDQo+
IEp1c3QgYXMgUm9kbmV5IHNhaWQsIGl0IGlzIGEgY2hhbGxlbmdlIG9mIDE1ODggaW5mbyBtb2Rl
bCB0byBZQU5HLCBhbmQgDQo+IHdlIHVzZSB0aGUgbGVhZnJlZiBvZiBZQU5HIHRvIHdvcmsgYXJv
dW5kIGl0Lg0KPiANCj4gSSB3b3VsZCBsaWtlIHRvIHByb3ZpZGUgYSBsaXR0bGUgbW9yZSBiYWNr
Z3JvdW5kcyBvbiB0aGUgdHJhZGVvZmY6DQo+IA0KPiANCj4gDQo+IDEuIEl0IHNheXMgaW4gU2Vj
LiA3LjUuMi4xIGluIElFRUUgMTU4OC0yMDA4OiBwb3J0SWRlbnRpdHkgaXMgYSBtZW1iZXIgDQo+
IG9mIHRoZSBwb3J0RFMgZGF0YSBzZXQuIEEgcG9ydElkZW50aXR5IGNvbnNpc3RzIG9mIHR3byBh
dHRyaWJ1dGVzLCBhcw0KPiANCj4gZm9sbG93czoNCj4gDQo+IOKOryBwb3J0SWRlbnRpdHkuY2xv
Y2tJZGVudGl0eQ0KPiANCj4g4o6vIHBvcnRJZGVudGl0eS5wb3J0TnVtYmVyDQo+IA0KPiBGdXJ0
aGVybW9yZSwgdGhlICJwb3J0RFMucG9ydElkZW50aXR5IiBhdHRyaWJ1dGUgaXMgbWVudGlvbmVk
IHF1aXRlIGEgDQo+IGZldyB0aW1lcyBpbiAxNTg4LTIwMDgsIGVzcGVjaWFsbHkgaW4gVGFibGUg
MTcgYW5kIHVuZGVyIFRhYmxlIDYxLCANCj4gd2l0aCBhIGhpbnQgdGhhdCBhc3NpZ25tZW50IGFu
ZCBjb21wYXJpc29uIGNhbiBiZSBkb25lIG9uIHRoaXMgbWVtYmVyIA0KPiBkaXJlY3RseSwgdGh1
cyBpdCBzZWVtcyB0byBtZSBwb3J0SWRlbnRpdHkgaXMgYW4gaW1wb3J0YW50IGFuZCB3ZWxsIA0K
PiB1bmRlcnN0b29kIGNvbnN0cnVjdCBpbiB0aGUgMTU4OCBzcGVjaWZpY2F0aW9uLg0KPiANCj4g
DQo+IA0KPiAyLiBJZiB3ZSBjaGFuZ2UgcG9ydERTLnBvcnRJZGVudGl0eSBmcm9tIGEgY29udGFp
bmVyIHRvIGEgZ3JvdXBpbmcsIA0KPiB0aGVuIHRoZXJlIGlzIG5vIHBvcnRJZGVudGl0eSBmb3Ig
cG9ydERTIGFuZCB0cmFuc3BhcmVudGNsb2NrUG9ydERTIGluIA0KPiB0aGUgcmVzdWx0aW5nIHRy
ZWUgZGlhZ3JhbToNCj4gDQo+IA0KPiANCj4gbW9kdWxlOiBpZXRmLXB0cC1kYXRhc2V0DQo+IA0K
PiAgICAgKy0tcncgaW5zdGFuY2UtbGlzdCogW2luc3RhbmNlLW51bWJlcl0NCj4gDQo+ICAgICB8
ICArLS1ydyBpbnN0YW5jZS1udW1iZXIgICAgICAgdWludDE2DQo+IA0KPiAgICAgfCAgKy0tcncg
ZGVmYXVsdC1kcw0KPiANCj4gICAgIHwgIHwgICstLXJ3IHR3by1zdGVwLWZsYWc/ICAgIGJvb2xl
YW4NCj4gDQo+ICAgICB8ICB8ICArLS1ydyBjbG9jay1pZGVudGl0eT8gICBjbG9jay1pZGVudGl0
eS10eXBlDQo+IA0KPiAgICAgfCAgfCAgKy0tcncgbnVtYmVyLXBvcnRzPyAgICAgdWludDE2DQo+
IA0KPiAgICAgfCAgfCAgKy0tcncgY2xvY2stcXVhbGl0eQ0KPiANCj4gICAgIHwgIHwgIHwgICst
LXJ3IGNsb2NrLWNsYXNzPyAgICAgICAgICAgICAgICAgIHVpbnQ4DQo+IA0KPiAgICAgfCAgfCAg
fCAgKy0tcncgY2xvY2stYWNjdXJhY3k/ICAgICAgICAgICAgICAgdWludDgNCj4gDQo+ICAgICB8
ICB8ICB8ICArLS1ydyBvZmZzZXQtc2NhbGVkLWxvZy12YXJpYW5jZT8gICB1aW50MTYNCj4gDQo+
ICAgICB8ICB8ICArLS1ydyBwcmlvcml0eTE/ICAgICAgICB1aW50OA0KPiANCj4gICAgIHwgIHwg
ICstLXJ3IHByaW9yaXR5Mj8gICAgICAgIHVpbnQ4DQo+IA0KPiAgICAgfCAgfCAgKy0tcncgZG9t
YWluLW51bWJlcj8gICAgdWludDgNCj4gDQo+ICAgICB8ICB8ICArLS1ydyBzbGF2ZS1vbmx5PyAg
ICAgICBib29sZWFuDQo+IA0KPiAgICAgfCAgKy0tcncgY3VycmVudC1kcw0KPiANCj4gICAgIHwg
IHwgICstLXJ3IHN0ZXBzLXJlbW92ZWQ/ICAgICAgICB1aW50MTYNCj4gDQo+ICAgICB8ICB8ICAr
LS1ydyBvZmZzZXQtZnJvbS1tYXN0ZXI/ICAgdGltZS1pbnRlcnZhbC10eXBlDQo+IA0KPiAgICAg
fCAgfCAgKy0tcncgbWVhbi1wYXRoLWRlbGF5PyAgICAgIHRpbWUtaW50ZXJ2YWwtdHlwZQ0KPiAN
Cj4gICAgIHwgICstLXJ3IHBhcmVudC1kcw0KPiANCj4gICAgIHwgIHwgICstLXJ3IHBhcmVudC1w
b3J0LWlkZW50aXR5DQo+IA0KPiAgICAgfCAgfCAgfCAgKy0tcncgY2xvY2staWRlbnRpdHk/ICAg
Y2xvY2staWRlbnRpdHktdHlwZQ0KPiANCj4gICAgIHwgIHwgIHwgICstLXJ3IHBvcnQtbnVtYmVy
PyAgICAgIHVpbnQxNg0KPiANCj4gICAgIHwgIHwgICstLXJ3IHBhcmVudC1zdGF0cz8gICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBib29sZWFuDQo+IA0KPiAgICAgfCAgfCAgKy0tcncg
b2JzZXJ2ZWQtcGFyZW50LW9mZnNldC1zY2FsZWQtbG9nLXZhcmlhbmNlPyAgIHVpbnQxNg0KPiAN
Cj4gICAgIHwgIHwgICstLXJ3IG9ic2VydmVkLXBhcmVudC1jbG9jay1waGFzZS1jaGFuZ2UtcmF0
ZT8gICAgICBpbnQzMg0KPiANCj4gICAgIHwgIHwgICstLXJ3IGdyYW5kbWFzdGVyLWlkZW50aXR5
PyAgICAgICAgICAgICAgICAgICAgICAgICBiaW5hcnkNCj4gDQo+ICAgICB8ICB8ICArLS1ydyBn
cmFuZG1hc3Rlci1jbG9jay1xdWFsaXR5DQo+IA0KPiAgICAgfCAgfCAgfCAgKy0tcncgY2xvY2st
Y2xhc3M/ICAgICAgICAgICAgICAgICAgdWludDgNCj4gDQo+ICAgICB8ICB8ICB8ICArLS1ydyBj
bG9jay1hY2N1cmFjeT8gICAgICAgICAgICAgICB1aW50OA0KPiANCj4gICAgIHwgIHwgIHwgICst
LXJ3IG9mZnNldC1zY2FsZWQtbG9nLXZhcmlhbmNlPyAgIHVpbnQxNg0KPiANCj4gICAgIHwgIHwg
ICstLXJ3IGdyYW5kbWFzdGVyLXByaW9yaXR5MT8gICAgICAgICAgICAgICAgICAgICAgICB1aW50
OA0KPiANCj4gICAgIHwgIHwgICstLXJ3IGdyYW5kbWFzdGVyLXByaW9yaXR5Mj8gICAgICAgICAg
ICAgICAgICAgICAgICB1aW50OA0KPiANCj4gICAgIHwgICstLXJ3IHRpbWUtcHJvcGVydGllcy1k
cw0KPiANCj4gICAgIHwgIHwgICstLXJ3IGN1cnJlbnQtdXRjLW9mZnNldC12YWxpZD8gICBib29s
ZWFuDQo+IA0KPiAgICAgfCAgfCAgKy0tcncgY3VycmVudC11dGMtb2Zmc2V0PyAgICAgICAgIGlu
dDE2DQo+IA0KPiAgICAgfCAgfCAgKy0tcncgbGVhcDU5PyAgICAgICAgICAgICAgICAgICAgIGJv
b2xlYW4NCj4gDQo+ICAgICB8ICB8ICArLS1ydyBsZWFwNjE/ICAgICAgICAgICAgICAgICAgICAg
Ym9vbGVhbg0KPiANCj4gICAgIHwgIHwgICstLXJ3IHRpbWUtdHJhY2VhYmxlPyAgICAgICAgICAg
ICBib29sZWFuDQo+IA0KPiAgICAgfCAgfCAgKy0tcncgZnJlcXVlbmN5LXRyYWNlYWJsZT8gICAg
ICAgIGJvb2xlYW4NCj4gDQo+ICAgICB8ICB8ICArLS1ydyBwdHAtdGltZXNjYWxlPyAgICAgICAg
ICAgICAgYm9vbGVhbg0KPiANCj4gICAgIHwgIHwgICstLXJ3IHRpbWUtc291cmNlPyAgICAgICAg
ICAgICAgICB1aW50OA0KPiANCj4gICAgIHwgICstLXJ3IHBvcnQtZHMtbGlzdCogW3BvcnQtbnVt
YmVyXQ0KPiANCj4gICAgIHwgICAgICstLXJ3IGNsb2NrLWlkZW50aXR5PyAgICAgICAgICAgICAg
ICBjbG9jay1pZGVudGl0eS10eXBlDQo+IA0KPiAgICAgfCAgICAgKy0tcncgcG9ydC1udW1iZXIg
ICAgICAgICAgICAgICAgICAgIHVpbnQxNg0KPiANCj4gICAgIHwgICAgICstLXJ3IHBvcnQtc3Rh
dGU/ICAgICAgICAgICAgICAgICAgICBwb3J0LXN0YXRlLWVudW1lcmF0aW9uDQo+IA0KPiAgICAg
fCAgICAgKy0tcncgdW5kZXJseWluZy1pbnRlcmZhY2U/ICAgICAgICAgIGlmOmludGVyZmFjZS1y
ZWYNCj4gDQo+ICAgICB8ICAgICArLS1ydyBsb2ctbWluLWRlbGF5LXJlcS1pbnRlcnZhbD8gICAg
aW50OA0KPiANCj4gICAgIHwgICAgICstLXJ3IHBlZXItbWVhbi1wYXRoLWRlbGF5PyAgICAgICAg
ICB0aW1lLWludGVydmFsLXR5cGUNCj4gDQo+ICAgICB8ICAgICArLS1ydyBsb2ctYW5ub3VuY2Ut
aW50ZXJ2YWw/ICAgICAgICAgaW50OA0KPiANCj4gICAgIHwgICAgICstLXJ3IGFubm91bmNlLXJl
Y2VpcHQtdGltZW91dD8gICAgICB1aW50OA0KPiANCj4gICAgIHwgICAgICstLXJ3IGxvZy1zeW5j
LWludGVydmFsPyAgICAgICAgICAgICBpbnQ4DQo+IA0KPiAgICAgfCAgICAgKy0tcncgZGVsYXkt
bWVjaGFuaXNtPyAgICAgICAgICAgICAgIGRlbGF5LW1lY2hhbmlzbS1lbnVtZXJhdGlvbg0KPiAN
Cj4gICAgIHwgICAgICstLXJ3IGxvZy1taW4tcGRlbGF5LXJlcS1pbnRlcnZhbD8gICBpbnQ4DQo+
IA0KPiAgICAgfCAgICAgKy0tcncgdmVyc2lvbi1udW1iZXI/ICAgICAgICAgICAgICAgIHVpbnQ4
DQo+IA0KPiAgICAgKy0tcncgdHJhbnNwYXJlbnQtY2xvY2stZGVmYXVsdC1kcw0KPiANCj4gICAg
IHwgICstLXJ3IGNsb2NrLWlkZW50aXR5PyAgICBjbG9jay1pZGVudGl0eS10eXBlDQo+IA0KPiAg
ICAgfCAgKy0tcncgbnVtYmVyLXBvcnRzPyAgICAgIHVpbnQxNg0KPiANCj4gICAgIHwgICstLXJ3
IGRlbGF5LW1lY2hhbmlzbT8gICBkZWxheS1tZWNoYW5pc20tZW51bWVyYXRpb24NCj4gDQo+ICAg
ICB8ICArLS1ydyBwcmltYXJ5LWRvbWFpbj8gICAgdWludDgNCj4gDQo+ICAgICArLS1ydyB0cmFu
c3BhcmVudC1jbG9jay1wb3J0LWRzLWxpc3QqIFtwb3J0LW51bWJlcl0NCj4gDQo+ICAgICAgICAr
LS1ydyBjbG9jay1pZGVudGl0eT8gICAgICAgICAgICAgICAgY2xvY2staWRlbnRpdHktdHlwZQ0K
PiANCj4gICAgICAgICstLXJ3IHBvcnQtbnVtYmVyICAgICAgICAgICAgICAgICAgICB1aW50MTYN
Cj4gDQo+ICAgICAgICArLS1ydyBsb2ctbWluLXBkZWxheS1yZXEtaW50ZXJ2YWw/ICAgaW50OA0K
PiANCj4gICAgICAgICstLXJ3IGZhdWx0eS1mbGFnPyAgICAgICAgICAgICAgICAgICBib29sZWFu
DQo+IA0KPiAgICAgICAgKy0tcncgcGVlci1tZWFuLXBhdGgtZGVsYXk/ICAgICAgICAgIHRpbWUt
aW50ZXJ2YWwtdHlwZQ0KPiANCj4gDQo+IA0KPiBJbiBjb250cmFzdCB0byB0aGUgb3JpZ2luYWwg
MTU4OCBZQU5HIHRyZWUgZGlhZ3JhbToNCj4gDQo+ICAgIG1vZHVsZTogaWV0Zi1wdHAtZGF0YXNl
dA0KPiANCj4gICAgICAgICstLXJ3IGluc3RhbmNlLWxpc3QqIFtpbnN0YW5jZS1udW1iZXJdDQo+
IA0KPiAgICAgICAgfCAgKy0tcncgaW5zdGFuY2UtbnVtYmVyICAgICAgdWludDE2DQo+IA0KPiAg
ICAgICAgfCAgKy0tcncgZGVmYXVsdC1kcw0KPiANCj4gICAgICAgIHwgIHwgICstLXJ3IHR3by1z
dGVwLWZsYWc/ICAgIGJvb2xlYW4NCj4gDQo+ICAgICAgICB8ICB8ICArLS1ydyBjbG9jay1pZGVu
dGl0eT8gICBjbG9jay1pZGVudGl0eS10eXBlDQo+IA0KPiAgICAgICAgfCAgfCAgKy0tcncgbnVt
YmVyLXBvcnRzPyAgICAgdWludDE2DQo+IA0KPiAgICAgICAgfCAgfCAgKy0tcncgY2xvY2stcXVh
bGl0eQ0KPiANCj4gICAgICAgIHwgIHwgIHwgICstLXJ3IGNsb2NrLWNsYXNzPyAgICAgICAgICAg
ICAgICAgIHVpbnQ4DQo+IA0KPiAgICAgICAgfCAgfCAgfCAgKy0tcncgY2xvY2stYWNjdXJhY3k/
ICAgICAgICAgICAgICAgdWludDgNCj4gDQo+ICAgICAgICB8ICB8ICB8ICArLS1ydyBvZmZzZXQt
c2NhbGVkLWxvZy12YXJpYW5jZT8gICB1aW50MTYNCj4gDQo+ICAgICAgICB8ICB8ICArLS1ydyBw
cmlvcml0eTE/ICAgICAgICB1aW50OA0KPiANCj4gICAgICAgIHwgIHwgICstLXJ3IHByaW9yaXR5
Mj8gICAgICAgIHVpbnQ4DQo+IA0KPiAgICAgICAgfCAgfCAgKy0tcncgZG9tYWluLW51bWJlcj8g
ICAgdWludDgNCj4gDQo+ICAgICAgICB8ICB8ICArLS1ydyBzbGF2ZS1vbmx5PyAgICAgICBib29s
ZWFuDQo+IA0KPiAgICAgICAgfCAgKy0tcncgY3VycmVudC1kcw0KPiANCj4gICAgICAgIHwgIHwg
ICstLXJ3IHN0ZXBzLXJlbW92ZWQ/ICAgICAgIHVpbnQxNg0KPiANCj4gICAgICAgIHwgIHwgICst
LXJ3IG9mZnNldC1mcm9tLW1hc3Rlcj8gIHRpbWUtaW50ZXJ2YWwtdHlwZQ0KPiANCj4gICAgICAg
IHwgIHwgICstLXJ3IG1lYW4tcGF0aC1kZWxheT8gICAgIHRpbWUtaW50ZXJ2YWwtdHlwZQ0KPiAN
Cj4gICAgICAgIHwgICstLXJ3IHBhcmVudC1kcw0KPiANCj4gICAgICAgIHwgIHwgICstLXJ3IHBh
cmVudC1wb3J0LWlkZW50aXR5DQo+IA0KPiAgICAgICAgfCAgfCAgfCAgKy0tcncgY2xvY2staWRl
bnRpdHk/ICAgY2xvY2staWRlbnRpdHktdHlwZQ0KPiANCj4gICAgICAgIHwgIHwgIHwgICstLXJ3
IHBvcnQtbnVtYmVyPyAgICAgIHVpbnQxNg0KPiANCj4gICAgICAgIHwgIHwgICstLXJ3IHBhcmVu
dC1zdGF0cz8gICAgICAgIGJvb2xlYW4NCj4gDQo+ICAgICAgICB8ICB8ICArLS1ydyBvYnNlcnZl
ZC1wYXJlbnQtb2Zmc2V0LXNjYWxlZC1sb2ctdmFyaWFuY2U/IHVpbnQxNg0KPiANCj4gICAgICAg
IHwgIHwgICstLXJ3IG9ic2VydmVkLXBhcmVudC1jbG9jay1waGFzZS1jaGFuZ2UtcmF0ZT8gICAg
aW50MzINCj4gDQo+ICAgICAgICB8ICB8ICArLS1ydyBncmFuZG1hc3Rlci1pZGVudGl0eT8gICAg
ICAgICAgICAgICAgICAgICAgIGJpbmFyeQ0KPiANCj4gICAgICAgIHwgIHwgICstLXJ3IGdyYW5k
bWFzdGVyLWNsb2NrLXF1YWxpdHkNCj4gDQo+ICAgICAgICB8ICB8ICB8ICArLS1ydyBjbG9jay1j
bGFzcz8gICAgICAgICAgICAgICAgICB1aW50OA0KPiANCj4gICAgICAgIHwgIHwgIHwgICstLXJ3
IGNsb2NrLWFjY3VyYWN5PyAgICAgICAgICAgICAgIHVpbnQ4DQo+IA0KPiAgICAgICAgfCAgfCAg
fCAgKy0tcncgb2Zmc2V0LXNjYWxlZC1sb2ctdmFyaWFuY2U/ICAgdWludDE2DQo+IA0KPiAgICAg
ICAgfCAgfCAgKy0tcncgZ3JhbmRtYXN0ZXItcHJpb3JpdHkxPyAgICAgICAgICAgdWludDgNCj4g
DQo+ICAgICAgICB8ICB8ICArLS1ydyBncmFuZG1hc3Rlci1wcmlvcml0eTI/ICAgICAgICAgICB1
aW50OA0KPiANCj4gICAgICAgIHwgICstLXJ3IHRpbWUtcHJvcGVydGllcy1kcw0KPiANCj4gICAg
ICAgIHwgIHwgICstLXJ3IGN1cnJlbnQtdXRjLW9mZnNldC12YWxpZD8gICBib29sZWFuDQo+IA0K
PiAgICAgICAgfCAgfCAgKy0tcncgY3VycmVudC11dGMtb2Zmc2V0PyAgICAgICAgIGludDE2DQo+
IA0KPiAgICAgICAgfCAgfCAgKy0tcncgbGVhcDU5PyAgICAgICAgICAgICAgICAgICAgIGJvb2xl
YW4NCj4gDQo+ICAgICAgICB8ICB8ICArLS1ydyBsZWFwNjE/ICAgICAgICAgICAgICAgICAgICAg
Ym9vbGVhbg0KPiANCj4gICAgICAgIHwgIHwgICstLXJ3IHRpbWUtdHJhY2VhYmxlPyAgICAgICAg
ICAgICBib29sZWFuDQo+IA0KPiAgICAgICAgfCAgfCAgKy0tcncgZnJlcXVlbmN5LXRyYWNlYWJs
ZT8gICAgICAgIGJvb2xlYW4NCj4gDQo+ICAgICAgICB8ICB8ICArLS1ydyBwdHAtdGltZXNjYWxl
PyAgICAgICAgICAgICAgYm9vbGVhbg0KPiANCj4gICAgICAgIHwgIHwgICstLXJ3IHRpbWUtc291
cmNlPyAgICAgICAgICAgICAgICB1aW50OA0KPiANCj4gICAgICAgIHwgICstLXJ3IHBvcnQtZHMt
bGlzdCogW3BvcnQtbnVtYmVyXQ0KPiANCj4gICAgICAgIHwgICAgICstLXJ3IHBvcnQtbnVtYmVy
ICAgICAgICAtPiAuLi9wb3J0LWlkZW50aXR5L3BvcnQtbnVtYmVyDQo+IA0KPiAgICAgICAgfCAg
ICAgKy0tcncgcG9ydC1pZGVudGl0eQ0KPiANCj4gICAgICAgIHwgICAgIHwgICstLXJ3IGNsb2Nr
LWlkZW50aXR5PyAgIGNsb2NrLWlkZW50aXR5LXR5cGUNCj4gDQo+ICAgICAgICB8ICAgICB8ICAr
LS1ydyBwb3J0LW51bWJlcj8gICAgICB1aW50MTYNCj4gDQo+ICAgICAgICB8ICAgICArLS1ydyBw
b3J0LXN0YXRlPyAgICAgICAgICBwb3J0LXN0YXRlLWVudW1lcmF0aW9uDQo+IA0KPiAgICAgICAg
fCAgICAgKy0tcncgdW5kZXJseWluZy1pbnRlcmZhY2U/IGlmOmludGVyZmFjZS1yZWYNCj4gDQo+
ICAgICAgICB8ICAgICArLS1ydyBsb2ctbWluLWRlbGF5LXJlcS1pbnRlcnZhbD8gICAgaW50OA0K
PiANCj4gICAgICAgIHwgICAgICstLXJ3IHBlZXItbWVhbi1wYXRoLWRlbGF5PyAgICAgICAgICB0
aW1lLWludGVydmFsLXR5cGUNCj4gDQo+ICAgICAgICB8ICAgICArLS1ydyBsb2ctYW5ub3VuY2Ut
aW50ZXJ2YWw/ICAgICAgICAgaW50OA0KPiANCj4gICAgICAgIHwgICAgICstLXJ3IGFubm91bmNl
LXJlY2VpcHQtdGltZW91dD8gICAgICB1aW50OA0KPiANCj4gICAgICAgIHwgICAgICstLXJ3IGxv
Zy1zeW5jLWludGVydmFsPyAgICAgICAgICAgICBpbnQ4DQo+IA0KPiAgICAgICAgfCAgICAgKy0t
cncgZGVsYXktbWVjaGFuaXNtPyAgICAgZGVsYXktbWVjaGFuaXNtLWVudW1lcmF0aW9uDQo+IA0K
PiAgICAgICAgfCAgICAgKy0tcncgbG9nLW1pbi1wZGVsYXktcmVxLWludGVydmFsPyAgIGludDgN
Cj4gDQo+ICAgICAgICB8ICAgICArLS1ydyB2ZXJzaW9uLW51bWJlcj8gICAgICAgICAgICAgICAg
dWludDgNCj4gDQo+ICAgICAgICArLS1ydyB0cmFuc3BhcmVudC1jbG9jay1kZWZhdWx0LWRzDQo+
IA0KPiAgICAgICAgfCAgKy0tcncgY2xvY2staWRlbnRpdHk/ICAgIGNsb2NrLWlkZW50aXR5LXR5
cGUNCj4gDQo+ICAgICAgICB8ICArLS1ydyBudW1iZXItcG9ydHM/ICAgICAgdWludDE2DQo+IA0K
PiAgICAgICAgfCAgKy0tcncgZGVsYXktbWVjaGFuaXNtPyAgIGRlbGF5LW1lY2hhbmlzbS1lbnVt
ZXJhdGlvbg0KPiANCj4gICAgICAgIHwgICstLXJ3IHByaW1hcnktZG9tYWluPyAgICB1aW50OA0K
PiANCj4gICAgICAgICstLXJ3IHRyYW5zcGFyZW50LWNsb2NrLXBvcnQtZHMtbGlzdCogW3BvcnQt
bnVtYmVyXQ0KPiANCj4gICAgICAgICAgICstLXJ3IHBvcnQtbnVtYmVyICAgICAgICAgICAtPiAu
Li9wb3J0LWlkZW50aXR5L3BvcnQtbnVtYmVyDQo+IA0KPiAgICAgICAgICAgKy0tcncgcG9ydC1p
ZGVudGl0eQ0KPiANCj4gICAgICAgICAgIHwgICstLXJ3IGNsb2NrLWlkZW50aXR5PyAgIGNsb2Nr
LWlkZW50aXR5LXR5cGUNCj4gDQo+ICAgICAgICAgICB8ICArLS1ydyBwb3J0LW51bWJlcj8gICAg
ICB1aW50MTYNCj4gDQo+ICAgICAgICAgICArLS1ydyBsb2ctbWluLXBkZWxheS1yZXEtaW50ZXJ2
YWw/ICAgaW50OA0KPiANCj4gICAgICAgICAgICstLXJ3IGZhdWx0eS1mbGFnPyAgICAgICAgICAg
ICAgICAgICBib29sZWFuDQo+IA0KPiAgICAgICAgICAgKy0tcncgcGVlci1tZWFuLXBhdGgtZGVs
YXk/ICAgICAgICAgdGltZS1pbnRlcnZhbC10eXBlDQo+IA0KPiANCj4gDQo+IEkgYWdyZWUsIGFz
c2lnbm1lbnQgYW5kIGNvbXBhcmlzb24gY2FuIHN0aWxsIGJlIGRvbmUgb24gY2xvY2staWRlbnRp
dHkgDQo+IGFuZCBwb3J0LW51bWJlciBkaXJlY3RseSAod2l0aG91dCBhIHBvcnRJZGVudGl0eSBj
b25zdHJ1Y3QpIC4gQnV0IA0KPiBwZW9wbGUgd2hvIGFyZSBmYW1pbGlhciB3aXRoIDE1ODgtMjAw
OCBtYXkgcXVlc3Rpb24gd2hlcmUgcG9ydElkZW50aXR5IA0KPiBpcyBnb25lLg0KPiANCj4gDQo+
IA0KPiAzLiBJIHRoaW5rIGxlYWZyZWYgaXMgYSB2ZXJ5IGdlbmVyYWwgc2VtYW50aWNzIHRoaW5n
IGluIFlBTkcgbGFuZ3VhZ2UsIA0KPiBpZiBhbnkgdG9vbHMgaGF2ZSBwcm9ibGVtIHdpdGggdGhp
cyBmZWF0dXJlLCBtYXliZSB3ZSBuZWVkIHRvIGNvbnRhY3QgDQo+IHdpdGggdGhlIHRvb2zigJlz
IGRldmVsb3BlciB0byBzdXBwb3J0IGl0Lg0KPiANCj4gDQo+IA0KPiBGaW5hbGx5LCBtb3JlIGlu
cHV0cyBmcm9tIHRoZSBXRyBhcmUgd2VsY29tZS4NCj4gDQo+IA0KPiANCj4gVGhhbmtzIGFnYWlu
LA0KPiANCj4gWXVhbmxvbmcNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLQ0KPiBGcm9tOiBUSUNUT0MgW21haWx0bzp0aWN0b2MtYm91bmNlc0BpZXRmLm9y
Z10gT24gQmVoYWxmIE9mIFJvZG5leSANCj4gQ3VtbWluZ3MNCj4gU2VudDogV2VkbmVzZGF5LCBT
ZXB0ZW1iZXIgMjcsIDIwMTcgMToyNCBBTQ0KPiBUbzogdGljdG9jQGlldGYub3JnPG1haWx0bzp0
aWN0b2NAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbVElDVE9DXSBkcmFmdC1pZXRmLXRpY3Rv
Yy0xNTg4djIteWFuZy0wNSAtIENvbmNlcm4gb3ZlciANCj4gcG9ydCBpZGVudGlmaWVyDQo+IA0K
PiANCj4gDQo+IFRoYW5rcyBTZWFuLA0KPiANCj4gDQo+IA0KPiBSZWdhcmRpbmcgeW91ciBvdGhl
ciBjb21tZW50IG9uIFRMRC4uLiBJIGFncmVlLg0KPiANCj4gDQo+IA0KPiBSZWdhcmRpbmcgdGhl
IGNvbW1lbnQgYmVsb3cgb24gcG9ydC1pZGVudGl0eSwgSSBhZ3JlZSB0aGF0IHdlIG5lZWQgdG8g
DQo+IGRvIGl0IGZvciBwcmFjdGljYWwgcmVhc29ucy4NCj4gDQo+IA0KPiANCj4gSW4gMTU4OC0y
MDA4LCB0aGVyZSBpcyBhIGRpc3RpbmN0IGRhdGFzZXQgbWVtYmVyIGZvciANCj4gcG9ydERTLnBv
cnRJZGVudGl0eSwgd2hpY2ggNS4zLjUgc3BlY2lmaWVzIGFzIHVzaW5nIHR5cGUgUG9ydElkZW50
aXR5Og0KPiANCj4gICBzdHJ1Y3QgUG9ydElkZW50aXR5IHsNCj4gDQo+ICAgICBDbG9ja0lkZW50
aXR5IGNsb2NrSWRlbnRpdHk7DQo+IA0KPiAgICAgVUludGVnZXIgcG9ydE51bWJlcjsNCj4gDQo+
ICAgfQ0KPiANCj4gDQo+IA0KPiBJZiB3ZSBpbnRlcnByZXQgdGhlIDE1ODgtMjAwOCBkYXRhc2V0
cyBhcyBhbiBpbmZvcm1hdGlvbiBtb2RlbCwgYW5kIA0KPiBhcHBseSB0aGF0IGFzIGRpcmVjdGx5
IGFzIHBvc3NpYmxlIHRvIGEgWUFORyBkYXRhIG1vZGVsLCANCj4gcG9ydERTLnBvcnRJZGVudGl0
eSBpcyBhIGNvbnRhaW5lciwgd2hpY2ggaXMgd2hhdCB3ZSBoYXZlIHNvIGZhci4gVGhhdCANCj4g
aW50cm9kdWNlcyBhIGNoYWxsZW5nZSwgYmVjYXVzZSB3ZSB3YW50IHRvIHVzZSANCj4gcG9ydERT
LnBvcnRJZGVudGl0eS5wb3J0TnVtYmVyIGFzIHRoZSBrZXkgdG8gdGhlIGxpc3Qgb2YgcG9ydERT
J3MuIFdlIA0KPiBzb2x2ZWQgdGhhdCBjaGFsbGVuZ2Ugd2l0aCBhIGxlYWZyZWYsIGJ1dCBJJ2Qg
YWdyZWUgdGhhdCBpcyB1Z2x5Lg0KPiANCj4gDQo+IA0KPiBZb3VyIHByb3Bvc2FsIGNoYW5nZXMg
cG9ydERTLnBvcnRJZGVudGl0eSBmcm9tIGEgY29udGFpbmVyIHRvIGEgDQo+IGdyb3VwaW5nLCBz
byB0aGF0IGl0IHBvcnREUy5wb3J0SWRlbnRpdHkucG9ydE51bWJlciBjYW4gYmUgdXNlZCBhcyB0
aGUgDQo+IGtleSB3aXRob3V0IGEgbGVhZnJlZi4NCj4gDQo+IA0KPiANCj4gVGhlIGRvd25zaWRl
IGlzIHRoYXQgaWYvd2hlbiBhIFlBTkcgbWFuYWdlbWVudCBjbGllbnQgdHJpZXMgdG8gImdldCIN
Cj4gcG9ydERTLnBvcnRJZGVudGl0eSwgaXQgZG9lc24ndCB3b3JrLi4uIHRoZXJlIGlzIG5vIHBv
cnRJZGVudGl0eSB0byANCj4gZ2V0Lg0KPiANCj4gDQo+IA0KPiBQZXJzb25hbGx5LCBJIHRoaW5r
IHRoYXQgZG93bnNpZGUgaXMgd29ydGggaXQuIE9uZSBjYW4gYXJndWUgdGhhdCB5b3VyIA0KPiBw
cm9wb3NhbCBzdGlsbCBjb25mb3JtcyB0byB0aGUgMTU4OC0yMDA4IGluZm9ybWF0aW9uIG1vZGVs
IGZvciANCj4gbWFuYWdlbWVudCwgaW4gdGhhdCBwb3J0RFMucG9ydElkZW50aXR5IHN0aWxsICJl
eGlzdHMiIGluIGEgbWFubmVyIA0KPiB0aGF0IG1ha2VzIHNlbnNlIGZvciBZQU5HLg0KPiANCj4g
DQo+IA0KPiBSb2RuZXkNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IEZyb206IFRJQ1RP
QyBbbWFpbHRvOnRpY3RvYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU2VhbiBDb25k
b24NCj4gDQo+IFNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAyNiwgMjAxNyAxMDozOCBBTQ0KPiAN
Cj4gVG86IHRpY3RvY0BpZXRmLm9yZzxtYWlsdG86dGljdG9jQGlldGYub3JnPg0KPiANCj4gU3Vi
amVjdDogW1RJQ1RPQ10gZHJhZnQtaWV0Zi10aWN0b2MtMTU4OHYyLXlhbmctMDUgLSBDb25jZXJu
IG92ZXIgcG9ydCANCj4gaWRlbnRpZmllcg0KPiANCj4gDQo+IA0KPiBXaXRoIHJlZmVyZW5jZSB0
byAiWUFORyBEYXRhIE1vZGVsIGZvciBJRUVFIDE1ODh2MiINCj4gaHR0cHM6Ly91cmxkZWZlbnNl
LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odA0KPiBt
bF9kcmFmdC0yRGlldGYtMkR0aWN0b2MtMkQxNTg4djItMkR5YW5nLTJEMDUmZD1Ed01GQXcmYz1J
XzBZd29LeTd6NUxNDQo+IFRWZHlPNllDaUUydXpJMWpqWlp1SVBlbGNTaml4QSZyPVdBNzFzZjJv
N0R3N0NiWWhGdDI0RFBqdDNsSnV1cHN3V1lkbmINCj4gb0tiWjhrJm09aktIY3pWTkxOLUt1VjJI
UlprYkVaWTFTemxDRF9BenRrYVdTY2NycUJJOCZzPW1zaDdBN19PZ0haMWw2NQ0KPiBEbjZfTGhp
RElYa1hwRmVpTEdtS2JLeHNxWFd3JmU9DQo+IA0KPiANCj4gDQo+IEkgaGF2ZSBhIGNvbmNlcm4g
YWJvdXQgdGhlIHN0cnVjdHVyZSBvZiB0aGUgWUFORywgYW5kIGhvdyB0aGUgbGlzdHMgDQo+IHBv
cnQtZHMtbGlzdCBhbmQgdHJhbnNwYXJlbnQtY2xvY2stcG9ydC1kcy1saXN0IGFyZSBpbmRleGVk
IHdpdGggYSANCj4gbGVhZiB3aGljaCBpcyBhIGxlYWZyZWYuDQo+IA0KPiANCj4gDQo+IFRoZSBz
dHJ1Y3R1cmUgc2VlbXMgdW5uZWNlc3NhcmlseSBjb21wbGV4IC0gcG9ydC1udW1iZXIgaXMgcmVw
cmVzZW50ZWQgDQo+IGFzIGEgbGVhZiBkaXJlY3RseSBiZW5lYXRoIHRoZSBsaXN0ICh0byBiZSB1
c2VkIGFzIGtleSkgYW5kIGFnYWluIA0KPiB1bmRlciB0aGUgcG9ydC1pZGVudGl0eSBjb250YWlu
ZXIuIEl0IGlzIHN0cnVjdHVyZWQgaW4gYSB3YXkgdGhhdCBJIA0KPiBiZWxpZXZlIHdvdWxkIG1h
a2UgaXQgZGlmZmljdWx0IHRvIHdvcmsgd2l0aCBzb21lIFlBTkcgdG9vbHMgaW4gdGhlIA0KPiBt
YXJrZXQuDQo+IA0KPiANCj4gDQo+IFRoZSBwdXJwb3NlIG9mIHBvcnQtaWRlbnRpdHkgY29udGFp
bmVyIGlzIG5vdCBjbGVhciBmcm9tIHRoZSBkb2N1bWVudA0KPiAtIGl0IHdvdWxkIGFjaGlldmUg
dGhlIHNhbWUgcHVycG9zZSBpZiBpdCB3YXMgbGVmdCBvdXQgb2YgDQo+IHBvcnQtZHMtZW50cnkg
YW5kIHRyYW5zcGFyZW50LWNsb2NrLXBvcnQtZHMtZW50cnkgYW5kIGluc3RlYWQgdGhlIA0KPiBn
cm91cGluZyBwb3J0LWlkZW50aXR5LWdyb3VwaW5nIGluY2x1ZGVkIGRpcmVjdGx5Lg0KPiANCj4g
DQo+IA0KPiBTZWUgdGhlIGF0dGFjaGVkIGZpbGVzIGFzIG9yaWdpbmFsLCBhIG1vZGlmaWVkIHZl
cnNpb24gYW5kIGFzIGEgcGF0Y2ggDQo+IGZpbGUuDQo+IA0KPiANCj4gDQo+IFNlYW4gQ29uZG9u
DQo+IA0KPiA9PT09PT09PT09PT09PT09PT09PT09PQ0KPiANCj4gU2VhbiBDb25kb24NCj4gDQo+
IFN5c3RlbSAmIFNvZnR3YXJlIEFyY2hpdGVjdA0KPiANCj4gRnJlcXVlbmN5ICYgVGltaW5nIERp
dmlzaW9uDQo+IA0KPiBNaWNyb3NlbWkgSW5jLg0KPiANCj4gbWFpbHRvOnNlYW4uY29uZG9uQG1p
Y3Jvc2VtaS5jb20NCj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCj4gDQo+IFRJQ1RPQyBtYWlsaW5nIGxpc3QNCj4gDQo+IFRJQ1RP
Q0BpZXRmLm9yZzxtYWlsdG86VElDVE9DQGlldGYub3JnPg0KPiANCj4gaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90aWN0b2MNCg==


From nobody Fri Sep 29 02:35:25 2017
Return-Path: 
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 CF0CC132D14; Fri, 29 Sep 2017 02:35:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 ls5jod_kWvU0; Fri, 29 Sep 2017 02:35:13 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F074713219B; Fri, 29 Sep 2017 02:35:10 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DWM87494; Fri, 29 Sep 2017 09:35:08 +0000 (GMT)
Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 29 Sep 2017 10:35:03 +0100
Received: from DGGEML507-MBX.china.huawei.com ([169.254.2.79]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0301.000; Fri, 29 Sep 2017 17:34:55 +0800
From: Jiangyuanlong 
To: Sean Condon , "netmod@ietf.org" 
CC: "tictoc@ietf.org" , Rodney Cummings 
Thread-Topic: draft-ietf-tictoc-1588v2-yang-05 - Concern over port identifier
Thread-Index: AdM20lxp4a4LJ64bREK66XJnd3gJawAF4nRwABKMRUAAEqGn9wA1hiAAAAHl76YAKlc90A==
Date: Fri, 29 Sep 2017 09:34:55 +0000
Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5CC17D@dggeml507-mbx.china.huawei.com>
References: <640F4C69F839A64C8949EF04FAAEE44679F253DE@avsrvexchmbx1.microsemi.net> , <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5C9C01@dggeml507-mbx.china.huawei.com> <640F4C69F839A64C8949EF04FAAEE44679F25561@avsrvexchmbx1.microsemi.net>, <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5CB62E@dggeml507-mbx.china.huawei.com> <640F4C69F839A64C8949EF04FAAEE44679F2583E@avsrvexchmbx1.microsemi.net>
In-Reply-To: <640F4C69F839A64C8949EF04FAAEE44679F2583E@avsrvexchmbx1.microsemi.net>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.74.202.215]
Content-Type: multipart/alternative; boundary="_000_3B0A1BED22CAD649A1B3E97BE5DDD68BBB5CC17Ddggeml507mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.59CE13CD.003F, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.2.79, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 58b7b61f005eaa07963247ff9f32f3b7
Archived-At: 
Subject: Re: [netmod] draft-ietf-tictoc-1588v2-yang-05 - Concern over port identifier
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Sep 2017 09:35:17 -0000

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

RGVhciBTZWFuLCB5b3UgcmFpc2VkIGEgdmVyeSBnb29kIHRvcGljIGFuZCBhbHNvIGluc3RydWN0
aXZlIHN1Z2dlc3Rpb25zLg0KDQpDaGVlcnMsDQpZdWFubG9uZw0KDQpGcm9tOiBTZWFuIENvbmRv
biBbbWFpbHRvOnNlYW4uY29uZG9uQG1pY3Jvc2VtaS5jb21dDQpTZW50OiBUaHVyc2RheSwgU2Vw
dGVtYmVyIDI4LCAyMDE3IDk6MTkgUE0NClRvOiBKaWFuZ3l1YW5sb25nOyBuZXRtb2RAaWV0Zi5v
cmcNCkNjOiB0aWN0b2NAaWV0Zi5vcmc7IFJvZG5leSBDdW1taW5ncw0KU3ViamVjdDogUkU6IGRy
YWZ0LWlldGYtdGljdG9jLTE1ODh2Mi15YW5nLTA1IC0gQ29uY2VybiBvdmVyIHBvcnQgaWRlbnRp
Zmllcg0KDQpUaGFuayB5b3UgZm9yIHlvdXIgaW4gZGVwdGggY29uc2lkZXJhdGlvbiBvZiB0aGlz
IGlzc3VlLiBTZWFuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogSmlh
bmd5dWFubG9uZyBbamlhbmd5dWFubG9uZ0BodWF3ZWkuY29tXQ0KU2VudDogMjggU2VwdGVtYmVy
IDIwMTcgMTQ6MTENClRvOiBTZWFuIENvbmRvbjsgbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRt
b2RAaWV0Zi5vcmc+DQpDYzogdGljdG9jQGlldGYub3JnPG1haWx0bzp0aWN0b2NAaWV0Zi5vcmc+
OyBSb2RuZXkgQ3VtbWluZ3MNClN1YmplY3Q6IFJFOiBkcmFmdC1pZXRmLXRpY3RvYy0xNTg4djIt
eWFuZy0wNSAtIENvbmNlcm4gb3ZlciBwb3J0IGlkZW50aWZpZXINCkVYVEVSTkFMIEVNQUlMDQpT
ZWFuLA0KDQpNeSBwZXJzb25hbCBvcGluaW9uIGlzIHRoYXQgaXQgY2FuIHdvcmssIGJ1dCBJIHdv
dWxkIGxpa2UgdG8gYXNrIGZvciBtb3JlIG9waW5pb25zIGZyb20gb3VyIG5ldG1vZCBleHBlcnRz
OykNCg0KSGkgbmV0bW9kIGV4cGVydHMsDQpDb25zaWRlcmluZyB0aGUgZm9sbG93aW5nIHNhbXBs
ZSBtb2R1bGUsIG15LWxpc3QgaXMgYSBsaXN0LCBhbmQgaXQgbmVlZHMgdG8gdXNlIGEgbGVhZiBt
ZW1iZXIgInBvcnQtbnVtYmVyIiBpbiBteS1wb3J0LWNvbnRhaW5lciBhcyBhIGtleS4NCldlIG5v
dyBoYXZlIDMgb3B0aW9uczoNCjEuDQogIGxpc3QgbXktbGlzdCB7DQogICAga2V5ICJwb3J0LW51
bWJlciI7DQogICAgbGVhZiBwb3J0LW51bWJlciB7DQogICAgICAgdHlwZSB1aW50MTY7DQogICAg
fQ0KDQogICAgY29udGFpbmVyIG15LXBvcnQtY29udGFpbmVyIHsNCiAgICAgICAgbGVhZiBwb3J0
LW51bWJlciB7DQogICAgICAgICAgdHlwZSB1aW50MTY7DQogICAgICAgIH0NCiAgICAgICAgIGxl
YWYgb3RoZXItbGVhZiB7DQogICAgICAgICAgIC4uLg0KICAgICAgICAgfQ0KICAgIH0NCiAgfQ0K
QnV0IHRoaXMgZG9lcyBub3Qgd29yayBmb3IgdGhlcmUgaXMgY29tcGlsaW5nIGVycm9yLg0KDQoy
Lg0KICBsaXN0IG15LWxpc3Qgew0KICAgIGtleSAicG9ydC1udW1iZXIiOw0KICAgIGxlYWYgcG9y
dC1udW1iZXIgew0KICAgICAgIHR5cGUgdWludDE2Ow0KICAgIH0NCiAgICBjb250YWluZXIgbXkt
cG9ydC1jb250YWluZXIgew0KICAgICAgICBsZWFmIHBvcnQtbnVtYmVyIHsNCiAgICAgICAgICAg
IHR5cGUgbGVhZnJlZnsNCiAgICAgICAgICAgICAgcGF0aCAiLi4vLi4vcG9ydC1udW1iZXIiOw0K
ICAgICAgICAgICAgfQ0KICAgICAgICB9DQogICAgICAgICBsZWFmIG90aGVyLWxlYWYgew0KICAg
ICAgICAgICAuLi4NCiAgICAgICAgIH0NCiAgICB9DQogIH0NCk9wdGlvbiAyIGNhbiBwYXJzZSwg
dGhvdWdoIGxlYWZyZWYgaW4gYSBzdWItbW9kdWxlIHNlZW1zIG5vdCB2ZXJ5IG5hdHVyYWwuDQoN
CjMuDQogIGxpc3QgbXktbGlzdCB7DQogICAga2V5ICJwb3J0LW51bWJlciI7DQogICAgbGVhZiBw
b3J0LW51bWJlciB7DQogICAgICAgdHlwZSBsZWFmcmVmew0KICAgICAgICAgIHBhdGggIi4uL215
LXBvcnQtY29udGFpbmVyL3BvcnQtbnVtYmVyIjsNCiAgICAgICB9DQogICAgfQ0KICAgIGNvbnRh
aW5lciBteS1wb3J0LWNvbnRhaW5lciB7DQogICAgICAgIGxlYWYgcG9ydC1udW1iZXIgew0KICAg
ICAgICAgIHR5cGUgdWludDE2Ow0KICAgICAgICB9DQogICAgICAgICBsZWFmIG90aGVyLWxlYWYg
ew0KICAgICAgICAgICAuLi4NCiAgICAgICAgIH0NCiAgICB9DQogIH0NCg0KT3B0aW9uIDMgY2Fu
IGFsc28gcGFyc2UsIHRob3VnaCBsZWFmcmVmIHNlZW1zIG5vdCBhIHZlcnkgbmF0dXJhbCBrZXku
IFdoYXQgaXMgeW91ciBmYXZvcml0ZSBvcHRpb24/IE9yIGRvIHlvdSBoYXZlIGFueSBiZXR0ZXIg
c2NoZW1lcz8NCllvdXIgb3BpbmlvbnMgYXJlIHZlcnkgaW1wb3J0YW50IGZvciBvdXIgcmV2aXNp
b24gb2YgdGhpcyBkcmFmdC4NCg0KVGhhbmtzLA0KWXVhbmxvbmcNCg0KDQpGcm9tOiBTZWFuIENv
bmRvbiBbbWFpbHRvOnNlYW4uY29uZG9uQG1pY3Jvc2VtaS5jb21dDQpTZW50OiBXZWRuZXNkYXks
IFNlcHRlbWJlciAyNywgMjAxNyA3OjExIFBNDQpUbzogSmlhbmd5dWFubG9uZw0KQ2M6IHRpY3Rv
Y0BpZXRmLm9yZzxtYWlsdG86dGljdG9jQGlldGYub3JnPjsgUm9kbmV5IEN1bW1pbmdzDQpTdWJq
ZWN0OiBSRTogZHJhZnQtaWV0Zi10aWN0b2MtMTU4OHYyLXlhbmctMDUgLSBDb25jZXJuIG92ZXIg
cG9ydCBpZGVudGlmaWVyDQoNClRoYW5rcyBndXlzIGZvciB5b3VyIHJlc3BvbnNlcy4NCg0KSSBh
Y2NlcHQgeW91ciBwb2ludHMgdG8ga2VlcCB0aGUgc3RydWN0dXJlIGFzIGFsaWduZWQgdG8gdGhl
IElFRUUgMTU4OCBzdGFuZGFyZCBhcyBwb3NzaWJsZS4NCg0KT25lIGFsdGVybmF0ZSBzdWdnZXN0
aW9uIHRoYXQgSSB3b3VsZCBtYWtlLCBpcyB0aGF0IHRoZSBwb3J0LW51bWJlciBjdXJyZW50bHkg
ZGVmaW5lZCBhcyBsZWFmcmVmIHNob3VsZCBiZSBtYWRlIHRoZSByZWFsIGF0dHJpYnV0ZSAoaS5l
LiB1aW50MTYpIGFuZCB0aGF0IHRoZSBwb3J0LW51bWJlciBpbnNpZGUgcG9ydC1pZGVudGl0eSBj
b250YWluZXIgc2hvdWxkIGJlIG1hZGUgaW4gdG8gdGhlIGxlYWYgcmVmIChhbmQgc2V0IHRvIG1h
bmRhdG9yeSB0cnVlKS4NCg0KVGhlIHJlYXNvbiBJIHNheSB0aGlzIGlzIHRoYXQNCg0KICAxLiAg
WE1MIG1vZGVscyBhcmUgdXN1YWxseSBuYXZpZ2F0ZWQgYW5kIGNvbnN0cnVjdGVkIHJvb3QtdG8t
bGVhZiwgYW5kIHRoZSB3YXkgaXQncyBwb3J0cmF5ZWQgYXQgdGhlIG1vbWVudCBpcyB0aGF0IHBv
cnQtbnVtYmVyIGxlYWZyZWYgcG9pbnRzIHRvIHNvbWV0aGluZyB0aGF0IG1heSBub3QgZXhpc3Qg
YXQgdGhlIHRpbWUgaXQgaXMgYmVpbmcgZGVmaW5lZC4gVGhpcyBtYWtlcyBpdCBkaWZmaWN1bHQg
dG8gaW1wbGVtZW50Lg0KICAyLiAgQWxzbyBwb3J0LWlkZW50aXR5L3BvcnQtbnVtYmVyIGlzIG5v
dCAibWFuZGF0b3J5IHRydWUiIG1lYW5pbmcgdGhhdCBpdCBjb3VsZCBiZSBsZWZ0IG91dCBhbHRv
Z2V0aGVyLiBJdCdzIG5vdCB2YWxpZCBmb3IgaXQgdG8gaGF2ZSBhIGRlZmF1bHQgdmFsdWUgZWl0
aGVyIHNpbmNlIGV2ZXJ5IGl0ZW0gaW4gdGhlIGxpc3Qgd2lsbCBuZWVkIGEgZGlmZmVyZW50IGlk
ZW50aWZpZXIuDQoNCldpdGggdGhpcyBzdWdnZXN0aW9uIHRoZSBzdHJ1Y3R1cmUgeW91IHJlcXVp
cmUgd2l0aCBwb3J0LWlkZW50aXR5IHN0aWxsIGV4aXN0cywgYnV0IG5vdyB0aGUgaW1wbGVtZW50
YXRpb24gaXMgbW9yZSBzdHJhaWdodGZvcndhcmQsIGFuZCB0aGUgY2hhbmdlIHdpbGwgYmUgdHJh
bnNwYXJlbnQgdG8gYW4gZW5kIHVzZXIuDQoNCg0KQmVzdCByZWdhcmRzLCBTZWFuDQo9PT09PT09
PT09PT09PT09PT09PT09PQ0KU2VhbiBDb25kb24NClN5c3RlbSAmIFNvZnR3YXJlIEFyY2hpdGVj
dA0KRnJlcXVlbmN5ICYgVGltaW5nIERpdmlzaW9uDQpNaWNyb3NlbWkgSW5jLg0Kc2Vhbi5jb25k
b25AbWljcm9zZW1pLmNvbTxtYWlsdG86c2Vhbi5jb25kb25AbWljcm9zZW1pLmNvbT4NCg0KX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IEppYW5neXVhbmxvbmcgW2ppYW5n
eXVhbmxvbmdAaHVhd2VpLmNvbV0NClNlbnQ6IDI3IFNlcHRlbWJlciAyMDE3IDA4OjA1DQpUbzog
U2VhbiBDb25kb24NCkNjOiB0aWN0b2NAaWV0Zi5vcmc8bWFpbHRvOnRpY3RvY0BpZXRmLm9yZz47
IFJvZG5leSBDdW1taW5ncw0KU3ViamVjdDogUkU6IGRyYWZ0LWlldGYtdGljdG9jLTE1ODh2Mi15
YW5nLTA1IC0gQ29uY2VybiBvdmVyIHBvcnQgaWRlbnRpZmllcg0KRVhURVJOQUwgRU1BSUwNCg0K
RGVhciBTZWFuLA0KDQoNCg0KVGhhbmsgeW91IGEgbG90IGZvciBkaXZpbmcgaW50byB0aGUgdGVj
aG5pY2FsIGRldGFpbHMgb2YgdGhpcyBtb2R1bGUuIEp1c3QgYXMgUm9kbmV5IHNhaWQsIGl0IGlz
IGEgY2hhbGxlbmdlIG9mIDE1ODggaW5mbyBtb2RlbCB0byBZQU5HLCBhbmQgd2UgdXNlIHRoZSBs
ZWFmcmVmIG9mIFlBTkcgdG8gd29yayBhcm91bmQgaXQuDQoNCkkgd291bGQgbGlrZSB0byBwcm92
aWRlIGEgbGl0dGxlIG1vcmUgYmFja2dyb3VuZHMgb24gdGhlIHRyYWRlb2ZmOg0KDQoNCg0KMS4g
SXQgc2F5cyBpbiBTZWMuIDcuNS4yLjEgaW4gSUVFRSAxNTg4LTIwMDg6IHBvcnRJZGVudGl0eSBp
cyBhIG1lbWJlciBvZiB0aGUgcG9ydERTIGRhdGEgc2V0LiBBIHBvcnRJZGVudGl0eSBjb25zaXN0
cyBvZiB0d28gYXR0cmlidXRlcywgYXMNCg0KZm9sbG93czoNCg0K4o6vIHBvcnRJZGVudGl0eS5j
bG9ja0lkZW50aXR5DQoNCuKOryBwb3J0SWRlbnRpdHkucG9ydE51bWJlcg0KDQpGdXJ0aGVybW9y
ZSwgdGhlICJwb3J0RFMucG9ydElkZW50aXR5IiBhdHRyaWJ1dGUgaXMgbWVudGlvbmVkIHF1aXRl
IGEgZmV3IHRpbWVzIGluIDE1ODgtMjAwOCwgZXNwZWNpYWxseSBpbiBUYWJsZSAxNyBhbmQgdW5k
ZXIgVGFibGUgNjEsIHdpdGggYSBoaW50IHRoYXQgYXNzaWdubWVudCBhbmQgY29tcGFyaXNvbiBj
YW4gYmUgZG9uZSBvbiB0aGlzIG1lbWJlciBkaXJlY3RseSwgdGh1cyBpdCBzZWVtcyB0byBtZSBw
b3J0SWRlbnRpdHkgaXMgYW4gaW1wb3J0YW50IGFuZCB3ZWxsIHVuZGVyc3Rvb2QgY29uc3RydWN0
IGluIHRoZSAxNTg4IHNwZWNpZmljYXRpb24uDQoNCg0KDQoyLiBJZiB3ZSBjaGFuZ2UgcG9ydERT
LnBvcnRJZGVudGl0eSBmcm9tIGEgY29udGFpbmVyIHRvIGEgZ3JvdXBpbmcsIHRoZW4gdGhlcmUg
aXMgbm8gcG9ydElkZW50aXR5IGZvciBwb3J0RFMgYW5kIHRyYW5zcGFyZW50Y2xvY2tQb3J0RFMg
aW4gdGhlIHJlc3VsdGluZyB0cmVlIGRpYWdyYW06DQoNCg0KDQptb2R1bGU6IGlldGYtcHRwLWRh
dGFzZXQNCg0KICAgICstLXJ3IGluc3RhbmNlLWxpc3QqIFtpbnN0YW5jZS1udW1iZXJdDQoNCiAg
ICB8ICArLS1ydyBpbnN0YW5jZS1udW1iZXIgICAgICAgdWludDE2DQoNCiAgICB8ICArLS1ydyBk
ZWZhdWx0LWRzDQoNCiAgICB8ICB8ICArLS1ydyB0d28tc3RlcC1mbGFnPyAgICBib29sZWFuDQoN
CiAgICB8ICB8ICArLS1ydyBjbG9jay1pZGVudGl0eT8gICBjbG9jay1pZGVudGl0eS10eXBlDQoN
CiAgICB8ICB8ICArLS1ydyBudW1iZXItcG9ydHM/ICAgICB1aW50MTYNCg0KICAgIHwgIHwgICst
LXJ3IGNsb2NrLXF1YWxpdHkNCg0KICAgIHwgIHwgIHwgICstLXJ3IGNsb2NrLWNsYXNzPyAgICAg
ICAgICAgICAgICAgIHVpbnQ4DQoNCiAgICB8ICB8ICB8ICArLS1ydyBjbG9jay1hY2N1cmFjeT8g
ICAgICAgICAgICAgICB1aW50OA0KDQogICAgfCAgfCAgfCAgKy0tcncgb2Zmc2V0LXNjYWxlZC1s
b2ctdmFyaWFuY2U/ICAgdWludDE2DQoNCiAgICB8ICB8ICArLS1ydyBwcmlvcml0eTE/ICAgICAg
ICB1aW50OA0KDQogICAgfCAgfCAgKy0tcncgcHJpb3JpdHkyPyAgICAgICAgdWludDgNCg0KICAg
IHwgIHwgICstLXJ3IGRvbWFpbi1udW1iZXI/ICAgIHVpbnQ4DQoNCiAgICB8ICB8ICArLS1ydyBz
bGF2ZS1vbmx5PyAgICAgICBib29sZWFuDQoNCiAgICB8ICArLS1ydyBjdXJyZW50LWRzDQoNCiAg
ICB8ICB8ICArLS1ydyBzdGVwcy1yZW1vdmVkPyAgICAgICAgdWludDE2DQoNCiAgICB8ICB8ICAr
LS1ydyBvZmZzZXQtZnJvbS1tYXN0ZXI/ICAgdGltZS1pbnRlcnZhbC10eXBlDQoNCiAgICB8ICB8
ICArLS1ydyBtZWFuLXBhdGgtZGVsYXk/ICAgICAgdGltZS1pbnRlcnZhbC10eXBlDQoNCiAgICB8
ICArLS1ydyBwYXJlbnQtZHMNCg0KICAgIHwgIHwgICstLXJ3IHBhcmVudC1wb3J0LWlkZW50aXR5
DQoNCiAgICB8ICB8ICB8ICArLS1ydyBjbG9jay1pZGVudGl0eT8gICBjbG9jay1pZGVudGl0eS10
eXBlDQoNCiAgICB8ICB8ICB8ICArLS1ydyBwb3J0LW51bWJlcj8gICAgICB1aW50MTYNCg0KICAg
IHwgIHwgICstLXJ3IHBhcmVudC1zdGF0cz8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBib29sZWFuDQoNCiAgICB8ICB8ICArLS1ydyBvYnNlcnZlZC1wYXJlbnQtb2Zmc2V0LXNjYWxl
ZC1sb2ctdmFyaWFuY2U/ICAgdWludDE2DQoNCiAgICB8ICB8ICArLS1ydyBvYnNlcnZlZC1wYXJl
bnQtY2xvY2stcGhhc2UtY2hhbmdlLXJhdGU/ICAgICAgaW50MzINCg0KICAgIHwgIHwgICstLXJ3
IGdyYW5kbWFzdGVyLWlkZW50aXR5PyAgICAgICAgICAgICAgICAgICAgICAgICBiaW5hcnkNCg0K
ICAgIHwgIHwgICstLXJ3IGdyYW5kbWFzdGVyLWNsb2NrLXF1YWxpdHkNCg0KICAgIHwgIHwgIHwg
ICstLXJ3IGNsb2NrLWNsYXNzPyAgICAgICAgICAgICAgICAgIHVpbnQ4DQoNCiAgICB8ICB8ICB8
ICArLS1ydyBjbG9jay1hY2N1cmFjeT8gICAgICAgICAgICAgICB1aW50OA0KDQogICAgfCAgfCAg
fCAgKy0tcncgb2Zmc2V0LXNjYWxlZC1sb2ctdmFyaWFuY2U/ICAgdWludDE2DQoNCiAgICB8ICB8
ICArLS1ydyBncmFuZG1hc3Rlci1wcmlvcml0eTE/ICAgICAgICAgICAgICAgICAgICAgICAgdWlu
dDgNCg0KICAgIHwgIHwgICstLXJ3IGdyYW5kbWFzdGVyLXByaW9yaXR5Mj8gICAgICAgICAgICAg
ICAgICAgICAgICB1aW50OA0KDQogICAgfCAgKy0tcncgdGltZS1wcm9wZXJ0aWVzLWRzDQoNCiAg
ICB8ICB8ICArLS1ydyBjdXJyZW50LXV0Yy1vZmZzZXQtdmFsaWQ/ICAgYm9vbGVhbg0KDQogICAg
fCAgfCAgKy0tcncgY3VycmVudC11dGMtb2Zmc2V0PyAgICAgICAgIGludDE2DQoNCiAgICB8ICB8
ICArLS1ydyBsZWFwNTk/ICAgICAgICAgICAgICAgICAgICAgYm9vbGVhbg0KDQogICAgfCAgfCAg
Ky0tcncgbGVhcDYxPyAgICAgICAgICAgICAgICAgICAgIGJvb2xlYW4NCg0KICAgIHwgIHwgICst
LXJ3IHRpbWUtdHJhY2VhYmxlPyAgICAgICAgICAgICBib29sZWFuDQoNCiAgICB8ICB8ICArLS1y
dyBmcmVxdWVuY3ktdHJhY2VhYmxlPyAgICAgICAgYm9vbGVhbg0KDQogICAgfCAgfCAgKy0tcncg
cHRwLXRpbWVzY2FsZT8gICAgICAgICAgICAgIGJvb2xlYW4NCg0KICAgIHwgIHwgICstLXJ3IHRp
bWUtc291cmNlPyAgICAgICAgICAgICAgICB1aW50OA0KDQogICAgfCAgKy0tcncgcG9ydC1kcy1s
aXN0KiBbcG9ydC1udW1iZXJdDQoNCiAgICB8ICAgICArLS1ydyBjbG9jay1pZGVudGl0eT8gICAg
ICAgICAgICAgICAgY2xvY2staWRlbnRpdHktdHlwZQ0KDQogICAgfCAgICAgKy0tcncgcG9ydC1u
dW1iZXIgICAgICAgICAgICAgICAgICAgIHVpbnQxNg0KDQogICAgfCAgICAgKy0tcncgcG9ydC1z
dGF0ZT8gICAgICAgICAgICAgICAgICAgIHBvcnQtc3RhdGUtZW51bWVyYXRpb24NCg0KICAgIHwg
ICAgICstLXJ3IHVuZGVybHlpbmctaW50ZXJmYWNlPyAgICAgICAgICBpZjppbnRlcmZhY2UtcmVm
DQoNCiAgICB8ICAgICArLS1ydyBsb2ctbWluLWRlbGF5LXJlcS1pbnRlcnZhbD8gICAgaW50OA0K
DQogICAgfCAgICAgKy0tcncgcGVlci1tZWFuLXBhdGgtZGVsYXk/ICAgICAgICAgIHRpbWUtaW50
ZXJ2YWwtdHlwZQ0KDQogICAgfCAgICAgKy0tcncgbG9nLWFubm91bmNlLWludGVydmFsPyAgICAg
ICAgIGludDgNCg0KICAgIHwgICAgICstLXJ3IGFubm91bmNlLXJlY2VpcHQtdGltZW91dD8gICAg
ICB1aW50OA0KDQogICAgfCAgICAgKy0tcncgbG9nLXN5bmMtaW50ZXJ2YWw/ICAgICAgICAgICAg
IGludDgNCg0KICAgIHwgICAgICstLXJ3IGRlbGF5LW1lY2hhbmlzbT8gICAgICAgICAgICAgICBk
ZWxheS1tZWNoYW5pc20tZW51bWVyYXRpb24NCg0KICAgIHwgICAgICstLXJ3IGxvZy1taW4tcGRl
bGF5LXJlcS1pbnRlcnZhbD8gICBpbnQ4DQoNCiAgICB8ICAgICArLS1ydyB2ZXJzaW9uLW51bWJl
cj8gICAgICAgICAgICAgICAgdWludDgNCg0KICAgICstLXJ3IHRyYW5zcGFyZW50LWNsb2NrLWRl
ZmF1bHQtZHMNCg0KICAgIHwgICstLXJ3IGNsb2NrLWlkZW50aXR5PyAgICBjbG9jay1pZGVudGl0
eS10eXBlDQoNCiAgICB8ICArLS1ydyBudW1iZXItcG9ydHM/ICAgICAgdWludDE2DQoNCiAgICB8
ICArLS1ydyBkZWxheS1tZWNoYW5pc20/ICAgZGVsYXktbWVjaGFuaXNtLWVudW1lcmF0aW9uDQoN
CiAgICB8ICArLS1ydyBwcmltYXJ5LWRvbWFpbj8gICAgdWludDgNCg0KICAgICstLXJ3IHRyYW5z
cGFyZW50LWNsb2NrLXBvcnQtZHMtbGlzdCogW3BvcnQtbnVtYmVyXQ0KDQogICAgICAgKy0tcncg
Y2xvY2staWRlbnRpdHk/ICAgICAgICAgICAgICAgIGNsb2NrLWlkZW50aXR5LXR5cGUNCg0KICAg
ICAgICstLXJ3IHBvcnQtbnVtYmVyICAgICAgICAgICAgICAgICAgICB1aW50MTYNCg0KICAgICAg
ICstLXJ3IGxvZy1taW4tcGRlbGF5LXJlcS1pbnRlcnZhbD8gICBpbnQ4DQoNCiAgICAgICArLS1y
dyBmYXVsdHktZmxhZz8gICAgICAgICAgICAgICAgICAgYm9vbGVhbg0KDQogICAgICAgKy0tcncg
cGVlci1tZWFuLXBhdGgtZGVsYXk/ICAgICAgICAgIHRpbWUtaW50ZXJ2YWwtdHlwZQ0KDQoNCg0K
SW4gY29udHJhc3QgdG8gdGhlIG9yaWdpbmFsIDE1ODggWUFORyB0cmVlIGRpYWdyYW06DQoNCiAg
IG1vZHVsZTogaWV0Zi1wdHAtZGF0YXNldA0KDQogICAgICAgKy0tcncgaW5zdGFuY2UtbGlzdCog
W2luc3RhbmNlLW51bWJlcl0NCg0KICAgICAgIHwgICstLXJ3IGluc3RhbmNlLW51bWJlciAgICAg
IHVpbnQxNg0KDQogICAgICAgfCAgKy0tcncgZGVmYXVsdC1kcw0KDQogICAgICAgfCAgfCAgKy0t
cncgdHdvLXN0ZXAtZmxhZz8gICAgYm9vbGVhbg0KDQogICAgICAgfCAgfCAgKy0tcncgY2xvY2st
aWRlbnRpdHk/ICAgY2xvY2staWRlbnRpdHktdHlwZQ0KDQogICAgICAgfCAgfCAgKy0tcncgbnVt
YmVyLXBvcnRzPyAgICAgdWludDE2DQoNCiAgICAgICB8ICB8ICArLS1ydyBjbG9jay1xdWFsaXR5
DQoNCiAgICAgICB8ICB8ICB8ICArLS1ydyBjbG9jay1jbGFzcz8gICAgICAgICAgICAgICAgICB1
aW50OA0KDQogICAgICAgfCAgfCAgfCAgKy0tcncgY2xvY2stYWNjdXJhY3k/ICAgICAgICAgICAg
ICAgdWludDgNCg0KICAgICAgIHwgIHwgIHwgICstLXJ3IG9mZnNldC1zY2FsZWQtbG9nLXZhcmlh
bmNlPyAgIHVpbnQxNg0KDQogICAgICAgfCAgfCAgKy0tcncgcHJpb3JpdHkxPyAgICAgICAgdWlu
dDgNCg0KICAgICAgIHwgIHwgICstLXJ3IHByaW9yaXR5Mj8gICAgICAgIHVpbnQ4DQoNCiAgICAg
ICB8ICB8ICArLS1ydyBkb21haW4tbnVtYmVyPyAgICB1aW50OA0KDQogICAgICAgfCAgfCAgKy0t
cncgc2xhdmUtb25seT8gICAgICAgYm9vbGVhbg0KDQogICAgICAgfCAgKy0tcncgY3VycmVudC1k
cw0KDQogICAgICAgfCAgfCAgKy0tcncgc3RlcHMtcmVtb3ZlZD8gICAgICAgdWludDE2DQoNCiAg
ICAgICB8ICB8ICArLS1ydyBvZmZzZXQtZnJvbS1tYXN0ZXI/ICB0aW1lLWludGVydmFsLXR5cGUN
Cg0KICAgICAgIHwgIHwgICstLXJ3IG1lYW4tcGF0aC1kZWxheT8gICAgIHRpbWUtaW50ZXJ2YWwt
dHlwZQ0KDQogICAgICAgfCAgKy0tcncgcGFyZW50LWRzDQoNCiAgICAgICB8ICB8ICArLS1ydyBw
YXJlbnQtcG9ydC1pZGVudGl0eQ0KDQogICAgICAgfCAgfCAgfCAgKy0tcncgY2xvY2staWRlbnRp
dHk/ICAgY2xvY2staWRlbnRpdHktdHlwZQ0KDQogICAgICAgfCAgfCAgfCAgKy0tcncgcG9ydC1u
dW1iZXI/ICAgICAgdWludDE2DQoNCiAgICAgICB8ICB8ICArLS1ydyBwYXJlbnQtc3RhdHM/ICAg
ICAgICBib29sZWFuDQoNCiAgICAgICB8ICB8ICArLS1ydyBvYnNlcnZlZC1wYXJlbnQtb2Zmc2V0
LXNjYWxlZC1sb2ctdmFyaWFuY2U/IHVpbnQxNg0KDQogICAgICAgfCAgfCAgKy0tcncgb2JzZXJ2
ZWQtcGFyZW50LWNsb2NrLXBoYXNlLWNoYW5nZS1yYXRlPyAgICBpbnQzMg0KDQogICAgICAgfCAg
fCAgKy0tcncgZ3JhbmRtYXN0ZXItaWRlbnRpdHk/ICAgICAgICAgICAgICAgICAgICAgICBiaW5h
cnkNCg0KICAgICAgIHwgIHwgICstLXJ3IGdyYW5kbWFzdGVyLWNsb2NrLXF1YWxpdHkNCg0KICAg
ICAgIHwgIHwgIHwgICstLXJ3IGNsb2NrLWNsYXNzPyAgICAgICAgICAgICAgICAgIHVpbnQ4DQoN
CiAgICAgICB8ICB8ICB8ICArLS1ydyBjbG9jay1hY2N1cmFjeT8gICAgICAgICAgICAgICB1aW50
OA0KDQogICAgICAgfCAgfCAgfCAgKy0tcncgb2Zmc2V0LXNjYWxlZC1sb2ctdmFyaWFuY2U/ICAg
dWludDE2DQoNCiAgICAgICB8ICB8ICArLS1ydyBncmFuZG1hc3Rlci1wcmlvcml0eTE/ICAgICAg
ICAgICB1aW50OA0KDQogICAgICAgfCAgfCAgKy0tcncgZ3JhbmRtYXN0ZXItcHJpb3JpdHkyPyAg
ICAgICAgICAgdWludDgNCg0KICAgICAgIHwgICstLXJ3IHRpbWUtcHJvcGVydGllcy1kcw0KDQog
ICAgICAgfCAgfCAgKy0tcncgY3VycmVudC11dGMtb2Zmc2V0LXZhbGlkPyAgIGJvb2xlYW4NCg0K
ICAgICAgIHwgIHwgICstLXJ3IGN1cnJlbnQtdXRjLW9mZnNldD8gICAgICAgICBpbnQxNg0KDQog
ICAgICAgfCAgfCAgKy0tcncgbGVhcDU5PyAgICAgICAgICAgICAgICAgICAgIGJvb2xlYW4NCg0K
ICAgICAgIHwgIHwgICstLXJ3IGxlYXA2MT8gICAgICAgICAgICAgICAgICAgICBib29sZWFuDQoN
CiAgICAgICB8ICB8ICArLS1ydyB0aW1lLXRyYWNlYWJsZT8gICAgICAgICAgICAgYm9vbGVhbg0K
DQogICAgICAgfCAgfCAgKy0tcncgZnJlcXVlbmN5LXRyYWNlYWJsZT8gICAgICAgIGJvb2xlYW4N
Cg0KICAgICAgIHwgIHwgICstLXJ3IHB0cC10aW1lc2NhbGU/ICAgICAgICAgICAgICBib29sZWFu
DQoNCiAgICAgICB8ICB8ICArLS1ydyB0aW1lLXNvdXJjZT8gICAgICAgICAgICAgICAgdWludDgN
Cg0KICAgICAgIHwgICstLXJ3IHBvcnQtZHMtbGlzdCogW3BvcnQtbnVtYmVyXQ0KDQogICAgICAg
fCAgICAgKy0tcncgcG9ydC1udW1iZXIgICAgICAgIC0+IC4uL3BvcnQtaWRlbnRpdHkvcG9ydC1u
dW1iZXINCg0KICAgICAgIHwgICAgICstLXJ3IHBvcnQtaWRlbnRpdHkNCg0KICAgICAgIHwgICAg
IHwgICstLXJ3IGNsb2NrLWlkZW50aXR5PyAgIGNsb2NrLWlkZW50aXR5LXR5cGUNCg0KICAgICAg
IHwgICAgIHwgICstLXJ3IHBvcnQtbnVtYmVyPyAgICAgIHVpbnQxNg0KDQogICAgICAgfCAgICAg
Ky0tcncgcG9ydC1zdGF0ZT8gICAgICAgICAgcG9ydC1zdGF0ZS1lbnVtZXJhdGlvbg0KDQogICAg
ICAgfCAgICAgKy0tcncgdW5kZXJseWluZy1pbnRlcmZhY2U/IGlmOmludGVyZmFjZS1yZWYNCg0K
ICAgICAgIHwgICAgICstLXJ3IGxvZy1taW4tZGVsYXktcmVxLWludGVydmFsPyAgICBpbnQ4DQoN
CiAgICAgICB8ICAgICArLS1ydyBwZWVyLW1lYW4tcGF0aC1kZWxheT8gICAgICAgICAgdGltZS1p
bnRlcnZhbC10eXBlDQoNCiAgICAgICB8ICAgICArLS1ydyBsb2ctYW5ub3VuY2UtaW50ZXJ2YWw/
ICAgICAgICAgaW50OA0KDQogICAgICAgfCAgICAgKy0tcncgYW5ub3VuY2UtcmVjZWlwdC10aW1l
b3V0PyAgICAgIHVpbnQ4DQoNCiAgICAgICB8ICAgICArLS1ydyBsb2ctc3luYy1pbnRlcnZhbD8g
ICAgICAgICAgICAgaW50OA0KDQogICAgICAgfCAgICAgKy0tcncgZGVsYXktbWVjaGFuaXNtPyAg
ICAgZGVsYXktbWVjaGFuaXNtLWVudW1lcmF0aW9uDQoNCiAgICAgICB8ICAgICArLS1ydyBsb2ct
bWluLXBkZWxheS1yZXEtaW50ZXJ2YWw/ICAgaW50OA0KDQogICAgICAgfCAgICAgKy0tcncgdmVy
c2lvbi1udW1iZXI/ICAgICAgICAgICAgICAgIHVpbnQ4DQoNCiAgICAgICArLS1ydyB0cmFuc3Bh
cmVudC1jbG9jay1kZWZhdWx0LWRzDQoNCiAgICAgICB8ICArLS1ydyBjbG9jay1pZGVudGl0eT8g
ICAgY2xvY2staWRlbnRpdHktdHlwZQ0KDQogICAgICAgfCAgKy0tcncgbnVtYmVyLXBvcnRzPyAg
ICAgIHVpbnQxNg0KDQogICAgICAgfCAgKy0tcncgZGVsYXktbWVjaGFuaXNtPyAgIGRlbGF5LW1l
Y2hhbmlzbS1lbnVtZXJhdGlvbg0KDQogICAgICAgfCAgKy0tcncgcHJpbWFyeS1kb21haW4/ICAg
IHVpbnQ4DQoNCiAgICAgICArLS1ydyB0cmFuc3BhcmVudC1jbG9jay1wb3J0LWRzLWxpc3QqIFtw
b3J0LW51bWJlcl0NCg0KICAgICAgICAgICstLXJ3IHBvcnQtbnVtYmVyICAgICAgICAgICAtPiAu
Li9wb3J0LWlkZW50aXR5L3BvcnQtbnVtYmVyDQoNCiAgICAgICAgICArLS1ydyBwb3J0LWlkZW50
aXR5DQoNCiAgICAgICAgICB8ICArLS1ydyBjbG9jay1pZGVudGl0eT8gICBjbG9jay1pZGVudGl0
eS10eXBlDQoNCiAgICAgICAgICB8ICArLS1ydyBwb3J0LW51bWJlcj8gICAgICB1aW50MTYNCg0K
ICAgICAgICAgICstLXJ3IGxvZy1taW4tcGRlbGF5LXJlcS1pbnRlcnZhbD8gICBpbnQ4DQoNCiAg
ICAgICAgICArLS1ydyBmYXVsdHktZmxhZz8gICAgICAgICAgICAgICAgICAgYm9vbGVhbg0KDQog
ICAgICAgICAgKy0tcncgcGVlci1tZWFuLXBhdGgtZGVsYXk/ICAgICAgICAgdGltZS1pbnRlcnZh
bC10eXBlDQoNCg0KDQpJIGFncmVlLCBhc3NpZ25tZW50IGFuZCBjb21wYXJpc29uIGNhbiBzdGls
bCBiZSBkb25lIG9uIGNsb2NrLWlkZW50aXR5IGFuZCBwb3J0LW51bWJlciBkaXJlY3RseSAod2l0
aG91dCBhIHBvcnRJZGVudGl0eSBjb25zdHJ1Y3QpIC4gQnV0IHBlb3BsZSB3aG8gYXJlIGZhbWls
aWFyIHdpdGggMTU4OC0yMDA4IG1heSBxdWVzdGlvbiB3aGVyZSBwb3J0SWRlbnRpdHkgaXMgZ29u
ZS4NCg0KDQoNCjMuIEkgdGhpbmsgbGVhZnJlZiBpcyBhIHZlcnkgZ2VuZXJhbCBzZW1hbnRpY3Mg
dGhpbmcgaW4gWUFORyBsYW5ndWFnZSwgaWYgYW55IHRvb2xzIGhhdmUgcHJvYmxlbSB3aXRoIHRo
aXMgZmVhdHVyZSwgbWF5YmUgd2UgbmVlZCB0byBjb250YWN0IHdpdGggdGhlIHRvb2zigJlzIGRl
dmVsb3BlciB0byBzdXBwb3J0IGl0Lg0KDQoNCg0KRmluYWxseSwgbW9yZSBpbnB1dHMgZnJvbSB0
aGUgV0cgYXJlIHdlbGNvbWUuDQoNCg0KDQpUaGFua3MgYWdhaW4sDQoNCll1YW5sb25nDQoNCg0K
DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFRJQ1RPQyBbbWFpbHRvOnRp
Y3RvYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9kbmV5IEN1bW1pbmdzDQpTZW50
OiBXZWRuZXNkYXksIFNlcHRlbWJlciAyNywgMjAxNyAxOjI0IEFNDQpUbzogdGljdG9jQGlldGYu
b3JnPG1haWx0bzp0aWN0b2NAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1RJQ1RPQ10gZHJhZnQt
aWV0Zi10aWN0b2MtMTU4OHYyLXlhbmctMDUgLSBDb25jZXJuIG92ZXIgcG9ydCBpZGVudGlmaWVy
DQoNCg0KDQpUaGFua3MgU2VhbiwNCg0KDQoNClJlZ2FyZGluZyB5b3VyIG90aGVyIGNvbW1lbnQg
b24gVExELi4uIEkgYWdyZWUuDQoNCg0KDQpSZWdhcmRpbmcgdGhlIGNvbW1lbnQgYmVsb3cgb24g
cG9ydC1pZGVudGl0eSwgSSBhZ3JlZSB0aGF0IHdlIG5lZWQgdG8gZG8gaXQgZm9yIHByYWN0aWNh
bCByZWFzb25zLg0KDQoNCg0KSW4gMTU4OC0yMDA4LCB0aGVyZSBpcyBhIGRpc3RpbmN0IGRhdGFz
ZXQgbWVtYmVyIGZvciBwb3J0RFMucG9ydElkZW50aXR5LCB3aGljaCA1LjMuNSBzcGVjaWZpZXMg
YXMgdXNpbmcgdHlwZSBQb3J0SWRlbnRpdHk6DQoNCiAgc3RydWN0IFBvcnRJZGVudGl0eSB7DQoN
CiAgICBDbG9ja0lkZW50aXR5IGNsb2NrSWRlbnRpdHk7DQoNCiAgICBVSW50ZWdlciBwb3J0TnVt
YmVyOw0KDQogIH0NCg0KDQoNCklmIHdlIGludGVycHJldCB0aGUgMTU4OC0yMDA4IGRhdGFzZXRz
IGFzIGFuIGluZm9ybWF0aW9uIG1vZGVsLCBhbmQgYXBwbHkgdGhhdCBhcyBkaXJlY3RseSBhcyBw
b3NzaWJsZSB0byBhIFlBTkcgZGF0YSBtb2RlbCwgcG9ydERTLnBvcnRJZGVudGl0eSBpcyBhIGNv
bnRhaW5lciwgd2hpY2ggaXMgd2hhdCB3ZSBoYXZlIHNvIGZhci4gVGhhdCBpbnRyb2R1Y2VzIGEg
Y2hhbGxlbmdlLCBiZWNhdXNlIHdlIHdhbnQgdG8gdXNlIHBvcnREUy5wb3J0SWRlbnRpdHkucG9y
dE51bWJlciBhcyB0aGUga2V5IHRvIHRoZSBsaXN0IG9mIHBvcnREUydzLiBXZSBzb2x2ZWQgdGhh
dCBjaGFsbGVuZ2Ugd2l0aCBhIGxlYWZyZWYsIGJ1dCBJJ2QgYWdyZWUgdGhhdCBpcyB1Z2x5Lg0K
DQoNCg0KWW91ciBwcm9wb3NhbCBjaGFuZ2VzIHBvcnREUy5wb3J0SWRlbnRpdHkgZnJvbSBhIGNv
bnRhaW5lciB0byBhIGdyb3VwaW5nLCBzbyB0aGF0IGl0IHBvcnREUy5wb3J0SWRlbnRpdHkucG9y
dE51bWJlciBjYW4gYmUgdXNlZCBhcyB0aGUga2V5IHdpdGhvdXQgYSBsZWFmcmVmLg0KDQoNCg0K
VGhlIGRvd25zaWRlIGlzIHRoYXQgaWYvd2hlbiBhIFlBTkcgbWFuYWdlbWVudCBjbGllbnQgdHJp
ZXMgdG8gImdldCIgcG9ydERTLnBvcnRJZGVudGl0eSwgaXQgZG9lc24ndCB3b3JrLi4uIHRoZXJl
IGlzIG5vIHBvcnRJZGVudGl0eSB0byBnZXQuDQoNCg0KDQpQZXJzb25hbGx5LCBJIHRoaW5rIHRo
YXQgZG93bnNpZGUgaXMgd29ydGggaXQuIE9uZSBjYW4gYXJndWUgdGhhdCB5b3VyIHByb3Bvc2Fs
IHN0aWxsIGNvbmZvcm1zIHRvIHRoZSAxNTg4LTIwMDggaW5mb3JtYXRpb24gbW9kZWwgZm9yIG1h
bmFnZW1lbnQsIGluIHRoYXQgcG9ydERTLnBvcnRJZGVudGl0eSBzdGlsbCAiZXhpc3RzIiBpbiBh
IG1hbm5lciB0aGF0IG1ha2VzIHNlbnNlIGZvciBZQU5HLg0KDQoNCg0KUm9kbmV5DQoNCg0KDQoN
Cg0KDQoNCkZyb206IFRJQ1RPQyBbbWFpbHRvOnRpY3RvYy1ib3VuY2VzQGlldGYub3JnXSBPbiBC
ZWhhbGYgT2YgU2VhbiBDb25kb24NCg0KU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDI2LCAyMDE3
IDEwOjM4IEFNDQoNClRvOiB0aWN0b2NAaWV0Zi5vcmc8bWFpbHRvOnRpY3RvY0BpZXRmLm9yZz4N
Cg0KU3ViamVjdDogW1RJQ1RPQ10gZHJhZnQtaWV0Zi10aWN0b2MtMTU4OHYyLXlhbmctMDUgLSBD
b25jZXJuIG92ZXIgcG9ydCBpZGVudGlmaWVyDQoNCg0KDQpXaXRoIHJlZmVyZW5jZSB0byAiWUFO
RyBEYXRhIE1vZGVsIGZvciBJRUVFIDE1ODh2MiIgaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p
bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX2RyYWZ0LTJEaWV0
Zi0yRHRpY3RvYy0yRDE1ODh2Mi0yRHlhbmctMkQwNSZkPUR3TUZBdyZjPUlfMFl3b0t5N3o1TE1U
VmR5TzZZQ2lFMnV6STFqalpadUlQZWxjU2ppeEEmcj1XQTcxc2YybzdEdzdDYlloRnQyNERQanQz
bEp1dXBzd1dZZG5ib0tiWjhrJm09aktIY3pWTkxOLUt1VjJIUlprYkVaWTFTemxDRF9BenRrYVdT
Y2NycUJJOCZzPW1zaDdBN19PZ0haMWw2NURuNl9MaGlESVhrWHBGZWlMR21LYkt4c3FYV3cmZT0N
Cg0KDQoNCkkgaGF2ZSBhIGNvbmNlcm4gYWJvdXQgdGhlIHN0cnVjdHVyZSBvZiB0aGUgWUFORywg
YW5kIGhvdyB0aGUgbGlzdHMgcG9ydC1kcy1saXN0IGFuZCB0cmFuc3BhcmVudC1jbG9jay1wb3J0
LWRzLWxpc3QgYXJlIGluZGV4ZWQgd2l0aCBhIGxlYWYgd2hpY2ggaXMgYSBsZWFmcmVmLg0KDQoN
Cg0KVGhlIHN0cnVjdHVyZSBzZWVtcyB1bm5lY2Vzc2FyaWx5IGNvbXBsZXggLSBwb3J0LW51bWJl
ciBpcyByZXByZXNlbnRlZCBhcyBhIGxlYWYgZGlyZWN0bHkgYmVuZWF0aCB0aGUgbGlzdCAodG8g
YmUgdXNlZCBhcyBrZXkpIGFuZCBhZ2FpbiB1bmRlciB0aGUgcG9ydC1pZGVudGl0eSBjb250YWlu
ZXIuIEl0IGlzIHN0cnVjdHVyZWQgaW4gYSB3YXkgdGhhdCBJIGJlbGlldmUgd291bGQgbWFrZSBp
dCBkaWZmaWN1bHQgdG8gd29yayB3aXRoIHNvbWUgWUFORyB0b29scyBpbiB0aGUgbWFya2V0Lg0K
DQoNCg0KVGhlIHB1cnBvc2Ugb2YgcG9ydC1pZGVudGl0eSBjb250YWluZXIgaXMgbm90IGNsZWFy
IGZyb20gdGhlIGRvY3VtZW50IC0gaXQgd291bGQgYWNoaWV2ZSB0aGUgc2FtZSBwdXJwb3NlIGlm
IGl0IHdhcyBsZWZ0IG91dCBvZiBwb3J0LWRzLWVudHJ5IGFuZCB0cmFuc3BhcmVudC1jbG9jay1w
b3J0LWRzLWVudHJ5IGFuZCBpbnN0ZWFkIHRoZSBncm91cGluZyBwb3J0LWlkZW50aXR5LWdyb3Vw
aW5nIGluY2x1ZGVkIGRpcmVjdGx5Lg0KDQoNCg0KU2VlIHRoZSBhdHRhY2hlZCBmaWxlcyBhcyBv
cmlnaW5hbCwgYSBtb2RpZmllZCB2ZXJzaW9uIGFuZCBhcyBhIHBhdGNoIGZpbGUuDQoNCg0KDQpT
ZWFuIENvbmRvbg0KDQo9PT09PT09PT09PT09PT09PT09PT09PQ0KDQpTZWFuIENvbmRvbg0KDQpT
eXN0ZW0gJiBTb2Z0d2FyZSBBcmNoaXRlY3QNCg0KRnJlcXVlbmN5ICYgVGltaW5nIERpdmlzaW9u
DQoNCk1pY3Jvc2VtaSBJbmMuDQoNCm1haWx0bzpzZWFuLmNvbmRvbkBtaWNyb3NlbWkuY29tDQoN
Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpU
SUNUT0MgbWFpbGluZyBsaXN0DQoNClRJQ1RPQ0BpZXRmLm9yZzxtYWlsdG86VElDVE9DQGlldGYu
b3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RpY3RvYw0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp
ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7
YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0
I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh
W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbWJyaWE7DQoJ
cGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5
OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0K
QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAg
MyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N
c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w
MDAxcHQ7DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCXRleHQtanVzdGlmeTppbnRlci1pZGVvZ3Jh
cGg7DQoJZm9udC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy
aWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5
Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs
IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv
bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0
LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiLnuq/mlofmnKwgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCglt
YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1h
cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ
Zm9udC1mYW1pbHk65a6L5L2TO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1z
b0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiLmibnm
s6jmoYbmlofmnKwgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7
DQoJdGV4dC1hbGlnbjpqdXN0aWZ5Ow0KCXRleHQtanVzdGlmeTppbnRlci1pZGVvZ3JhcGg7DQoJ
Zm9udC1zaXplOjkuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K
c3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLnuq/mlofmnKwgQ2hhciI7DQoJbXNvLXN0eWxl
LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOue6r+aWh+acrDsNCglmb250LWZhbWlseTrl
rovkvZM7fQ0Kc3Bhbi5DaGFyMA0KCXttc28tc3R5bGUtbmFtZToi5om55rOo5qGG5paH5pysIENo
YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazrmibnms6jmoYbm
lofmnKw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpwLm1zb2NocGRl
ZmF1bHQsIGxpLm1zb2NocGRlZmF1bHQsIGRpdi5tc29jaHBkZWZhdWx0DQoJe21zby1zdHlsZS1u
YW1lOm1zb2NocGRlZmF1bHQ7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7
DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5jaGFyMQ0K
CXttc28tc3R5bGUtbmFtZTpjaGFyOw0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLmNoYXIw
MA0KCXttc28tc3R5bGUtbmFtZTpjaGFyMDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt
c2VyaWYiO30NCnNwYW4uY2hhcjEwDQoJe21zby1zdHlsZS1uYW1lOmNoYXIxOw0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5lbWFpbHN0eWxlMjMNCgl7bXNvLXN0
eWxlLW5hbWU6ZW1haWxzdHlsZTIzOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp
ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNw0KCXttc28tc3R5bGUtdHlw
ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K
CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0
LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2
MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpk
aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv
bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjM5MDQyNjQxMjsNCgltc28tbGlzdC10ZW1w
bGF0ZS1pZHM6LTE3NzM5OTc5NjQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7
bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N
CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48
IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0
PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5
b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9
ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+
RGVhciBTZWFuLCB5b3UgcmFpc2VkIGEgdmVyeSBnb29kIHRvcGljIGFuZCBhbHNvIGluc3RydWN0
aXZlIHN1Z2dlc3Rpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdE
Ij5ZdWFubG9uZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s
aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48Yj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo
b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo
b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBTZWFuIENvbmRvbiBbbWFpbHRvOnNl
YW4uY29uZG9uQG1pY3Jvc2VtaS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIFNl
cHRlbWJlciAyOCwgMjAxNyA5OjE5IFBNPGJyPg0KPGI+VG86PC9iPiBKaWFuZ3l1YW5sb25nOyBu
ZXRtb2RAaWV0Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IHRpY3RvY0BpZXRmLm9yZzsgUm9kbmV5IEN1
bW1pbmdzPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBkcmFmdC1pZXRmLXRpY3RvYy0xNTg4djIt
eWFuZy0wNSAtIENvbmNlcm4gb3ZlciBwb3J0IGlkZW50aWZpZXI8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0
eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0
eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjpibGFjayI+VGhhbmsgeW91IGZvciB5b3VyIGluIGRlcHRoIGNvbnNpZGVyYXRp
b24gb2YgdGhpcyBpc3N1ZS4gU2VhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2
IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRl
ciI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFj
ayI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwv
ZGl2Pg0KPGRpdiBpZD0iZGl2UnBGNjM5NDA0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu
PSJsZWZ0IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7dGV4dC1hbGlnbjpsZWZ0Ij48Yj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206
PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
YmxhY2siPg0KIEppYW5neXVhbmxvbmcgW2ppYW5neXVhbmxvbmdAaHVhd2VpLmNvbV08YnI+DQo8
Yj5TZW50OjwvYj4gMjggU2VwdGVtYmVyIDIwMTcgMTQ6MTE8YnI+DQo8Yj5Ubzo8L2I+IFNlYW4g
Q29uZG9uOyA8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8
L2E+PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86dGljdG9jQGlldGYub3JnIj50aWN0
b2NAaWV0Zi5vcmc8L2E+OyBSb2RuZXkgQ3VtbWluZ3M8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6
IGRyYWZ0LWlldGYtdGljdG9jLTE1ODh2Mi15YW5nLTA1IC0gQ29uY2VybiBvdmVyIHBvcnQgaWRl
bnRpZmllcjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7
O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0
O3RleHQtYWxpZ246bGVmdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTQu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbWJyaWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29s
b3I6cmVkIj5FWFRFUk5BTCBFTUFJTDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx
dW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Y29sb3I6IzFGNDk3RCI+U2Vhbiw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv
cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0
OTdEIj5NeSBwZXJzb25hbCBvcGluaW9uIGlzIHRoYXQgaXQgY2FuIHdvcmssIGJ1dCBJIHdvdWxk
IGxpa2UgdG8gYXNrIGZvciBtb3JlIG9waW5pb25zIGZyb20gb3VyIG5ldG1vZCBleHBlcnRzOyk8
L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj
b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5IaSBuZXRtb2QgZXhwZXJ0
cyw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJjb2xvcjojMUY0OTdEIj5Db25zaWRlcmluZyB0aGUgZm9sbG93aW5nIHNhbXBsZSBtb2R1
bGUsIG15LWxpc3QgaXMgYSBsaXN0LCBhbmQgaXQgbmVlZHMgdG8gdXNlIGEgbGVhZiBtZW1iZXIg
JnF1b3Q7cG9ydC1udW1iZXImcXVvdDsgaW4gbXktcG9ydC1jb250YWluZXIgYXMgYSBrZXkuPC9z
cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Y29sb3I6IzFGNDk3RCI+V2Ugbm93IGhhdmUgMyBvcHRpb25zOjwvc3Bhbj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjEu
IDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwO2xpc3QgbXktbGlzdCB7PC9zcGFuPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFG
NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGtleSAmcXVvdDtwb3J0LW51bWJlciZxdW90Ozs8L3Nw
YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj
b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsgbGVhZiBwb3J0LW51bWJlciB7PC9zcGFu
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s
b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGUgdWlu
dDE2Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyB9PC9zcGFuPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3
RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbnRhaW5lciBt
eS1wb3J0LWNvbnRhaW5lciB7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6
YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxlYWYgcG9ydC1udW1iZXIgezwvc3Bhbj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0
eXBlIHVpbnQxNjs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs
YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsZWFmIG90aGVyLWxlYWYgezwvc3Bhbj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5
N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJz
cDsgLi4uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IH08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi
bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsgfTwv
c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyB9PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QnV0IHRoaXMgZG9lcyBu
b3Qgd29yayBmb3IgdGhlcmUgaXMgY29tcGlsaW5nIGVycm9yLjwvc3Bhbj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZu
YnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi
bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4yLjwvc3Bhbj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZu
YnNwOyBsaXN0IG15LWxpc3Qgezwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y
OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyBr
ZXkgJnF1b3Q7cG9ydC1udW1iZXImcXVvdDs7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7IGxlYWYgcG9ydC1udW1iZXIgezwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0eXBlIHVpbnQxNjs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJz
cDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs
YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyBjb250
YWluZXIgbXktcG9ydC1jb250YWluZXIgezwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsZWFmIHBvcnQtbnVtYmVyIHs8L3NwYW4+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjoj
MUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgdHlwZSBsZWFmcmVmezwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyBwYXRoICZxdW90Oy4uLy4uL3BvcnQtbnVtYmVyJnF1b3Q7Ozwvc3Bhbj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y
OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyB9PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s
b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbGVhZiBvdGhlci1sZWFmIHs8L3Nw
YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj
b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgJm5ic3A7IC4uLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs
YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7IH08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsgfTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk9wdGlv
biAyIGNhbiBwYXJzZSwgdGhvdWdoIGxlYWZyZWYgaW4gYSBzdWItbW9kdWxlIHNlZW1zIG5vdCB2
ZXJ5IG5hdHVyYWwuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2si
PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+My48
L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJjb2xvcjojMUY0OTdEIj4mbmJzcDsgbGlzdCBteS1saXN0IHs8L3NwYW4+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4m
bmJzcDsmbmJzcDsmbmJzcDsga2V5ICZxdW90O3BvcnQtbnVtYmVyJnF1b3Q7Ozwvc3Bhbj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMx
RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyBsZWFmIHBvcnQtbnVtYmVyIHs8L3NwYW4+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0
OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHlwZSBsZWFmcmVmezwv
c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyBwYXRoICZxdW90Oy4uL215LXBvcnQtY29udGFpbmVyL3BvcnQtbnVtYmVy
JnF1b3Q7Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyB9PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08L3NwYW4+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0
OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsgY29udGFpbmVyIG15LXBvcnQtY29udGFpbmVyIHs8L3Nw
YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj
b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
bGVhZiBwb3J0LW51bWJlciB7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6
YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGUgdWludDE2Ozwvc3Bhbj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMx
RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PC9zcGFu
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s
b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IGxlYWYgb3RoZXItbGVhZiB7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s
b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyAuLi48L3NwYW4+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdE
Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bh
bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv
bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyB9PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7
IH08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5PcHRpb24gMyBjYW4g
YWxzbyBwYXJzZSwgdGhvdWdoIGxlYWZyZWYgc2VlbXMgbm90IGEgdmVyeSBuYXR1cmFsIGtleS4g
V2hhdCBpcyB5b3VyIGZhdm9yaXRlIG9wdGlvbj8gT3IgZG8geW91IGhhdmUgYW55IGJldHRlciBz
Y2hlbWVzPzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPllvdXIgb3BpbmlvbnMgYXJlIHZlcnkgaW1wb3J0YW50
IGZvciBvdXIgcmV2aXNpb24gb2YgdGhpcyBkcmFmdC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8
L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJjb2xvcjojMUY0OTdEIj5UaGFua3MsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+WXVhbmxvbmc8L3NwYW4+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv
cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi
bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp
dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw
dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu
PSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPg0KIFNlYW4gQ29uZG9u
IFs8YSBocmVmPSJtYWlsdG86c2Vhbi5jb25kb25AbWljcm9zZW1pLmNvbSI+bWFpbHRvOnNlYW4u
Y29uZG9uQG1pY3Jvc2VtaS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwg
U2VwdGVtYmVyIDI3LCAyMDE3IDc6MTEgUE08YnI+DQo8Yj5Ubzo8L2I+IEppYW5neXVhbmxvbmc8
YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzp0aWN0b2NAaWV0Zi5vcmciPnRpY3RvY0Bp
ZXRmLm9yZzwvYT47IFJvZG5leSBDdW1taW5nczxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogZHJh
ZnQtaWV0Zi10aWN0b2MtMTU4OHYyLXlhbmctMDUgLSBDb25jZXJuIG92ZXIgcG9ydCBpZGVudGlm
aWVyPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGln
bj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRoYW5rcyBn
dXlzIGZvciB5b3VyIHJlc3BvbnNlcy48YnI+DQo8YnI+DQpJIGFjY2VwdCB5b3VyIHBvaW50cyB0
byBrZWVwIHRoZSBzdHJ1Y3R1cmUgYXMgYWxpZ25lZCB0byB0aGUgSUVFRSAxNTg4IHN0YW5kYXJk
IGFzIHBvc3NpYmxlLg0KPGJyPg0KPGJyPg0KT25lIGFsdGVybmF0ZSBzdWdnZXN0aW9uIHRoYXQg
SSB3b3VsZCBtYWtlLCBpcyB0aGF0IHRoZSBwb3J0LW51bWJlciBjdXJyZW50bHkgZGVmaW5lZCBh
cyBsZWFmcmVmIHNob3VsZCBiZSBtYWRlIHRoZSByZWFsIGF0dHJpYnV0ZSAoaS5lLiB1aW50MTYp
IGFuZCB0aGF0IHRoZSBwb3J0LW51bWJlciBpbnNpZGUgcG9ydC1pZGVudGl0eSBjb250YWluZXIg
c2hvdWxkIGJlIG1hZGUgaW4gdG8gdGhlIGxlYWYgcmVmIChhbmQgc2V0IHRvIG1hbmRhdG9yeQ0K
IHRydWUpLjxicj4NCjxicj4NClRoZSByZWFzb24gSSBzYXkgdGhpcyBpcyB0aGF0PC9zcGFuPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowY20iIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7dGV4dC1hbGlnbjpsZWZ0O21zby1s
aXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90OyI+WE1MIG1vZGVscyBhcmUgdXN1YWxseSBuYXZpZ2F0ZWQgYW5kIGNvbnN0cnVjdGVkIHJv
b3QtdG8tbGVhZiwgYW5kIHRoZSB3YXkgaXQncyBwb3J0cmF5ZWQgYXQgdGhlIG1vbWVudCBpcyB0
aGF0IHBvcnQtbnVtYmVyIGxlYWZyZWYgcG9pbnRzIHRvIHNvbWV0aGluZyB0aGF0IG1heSBub3Qg
ZXhpc3QgYXQgdGhlIHRpbWUNCiBpdCBpcyBiZWluZyBkZWZpbmVkLiBUaGlzIG1ha2VzIGl0IGRp
ZmZpY3VsdCB0byBpbXBsZW1lbnQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw
Pjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7dGV4
dC1hbGlnbjpsZWZ0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QWxzbyBwb3J0LWlkZW50aXR5L3BvcnQtbnVtYmVyIGlz
IG5vdCAmcXVvdDttYW5kYXRvcnkgdHJ1ZSZxdW90OyBtZWFuaW5nIHRoYXQgaXQgY291bGQgYmUg
bGVmdCBvdXQgYWx0b2dldGhlci4gSXQncyBub3QgdmFsaWQgZm9yIGl0IHRvIGhhdmUgYSBkZWZh
dWx0IHZhbHVlIGVpdGhlciBzaW5jZSBldmVyeSBpdGVtIGluIHRoZSBsaXN0DQogd2lsbCBuZWVk
IGEgZGlmZmVyZW50IGlkZW50aWZpZXIuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv
bzpwPjwvc3Bhbj48L2xpPjwvb2w+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6YmxhY2siPldpdGggdGhpcyBzdWdnZXN0aW9uIHRoZSBzdHJ1Y3R1cmUg
eW91IHJlcXVpcmUgd2l0aCBwb3J0LWlkZW50aXR5IHN0aWxsIGV4aXN0cywgYnV0IG5vdyB0aGUg
aW1wbGVtZW50YXRpb24gaXMgbW9yZSBzdHJhaWdodGZvcndhcmQsIGFuZCB0aGUgY2hhbmdlIHdp
bGwgYmUgdHJhbnNwYXJlbnQNCiB0byBhbiBlbmQgdXNlci48L3NwYW4+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh
aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3Nw
YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFs
aWduOmxlZnQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi
bGFjayI+QmVzdCByZWdhcmRzLCBTZWFuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU
YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PT09PT09PT09
PT09PT09PT09PT09PT08YnI+DQpTZWFuIENvbmRvbjxicj4NClN5c3RlbSAmYW1wOyBTb2Z0d2Fy
ZSBBcmNoaXRlY3Q8YnI+DQpGcmVxdWVuY3kgJmFtcDsgVGltaW5nIERpdmlzaW9uPGJyPg0KTWlj
cm9zZW1pIEluYy48YnI+DQo8YSBocmVmPSJtYWlsdG86c2Vhbi5jb25kb25AbWljcm9zZW1pLmNv
bSIgdGFyZ2V0PSJfYmxhbmsiPnNlYW4uY29uZG9uQG1pY3Jvc2VtaS5jb208L2E+PC9zcGFuPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5
bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O3RleHQtYWxpZ246bGVmdCI+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K
PGRpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQt
YWxpZ246Y2VudGVyIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7
O2NvbG9yOmJsYWNrIj4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+
DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IGlkPSJkaXZScEYxMTgxMTkiPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDt0ZXh0LWFsaWdu
OmxlZnQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi
bGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjpibGFjayI+DQogSmlhbmd5dWFubG9uZyBbamlhbmd5dWFubG9uZ0BodWF3ZWku
Y29tXTxicj4NCjxiPlNlbnQ6PC9iPiAyNyBTZXB0ZW1iZXIgMjAxNyAwODowNTxicj4NCjxiPlRv
OjwvYj4gU2VhbiBDb25kb248YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzp0aWN0b2NA
aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50aWN0b2NAaWV0Zi5vcmc8L2E+OyBSb2RuZXkgQ3Vt
bWluZ3M8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IGRyYWZ0LWlldGYtdGljdG9jLTE1ODh2Mi15
YW5nLTA1IC0gQ29uY2VybiBvdmVyIHBvcnQgaWRlbnRpZmllcjwvc3Bhbj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9Im1hcmdpbi1i
b3R0b206MTIuMHB0O3RleHQtYWxpZ246bGVmdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTQuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbWJyaWEmcXVvdDssJnF1b3Q7c2Vy
aWYmcXVvdDs7Y29sb3I6cmVkIj5FWFRFUk5BTCBFTUFJTDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s
b3I6YmxhY2siPkRlYXIgU2Vhbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGFuayB5b3UgYSBsb3QgZm9yIGRpdmluZyBp
bnRvIHRoZSB0ZWNobmljYWwgZGV0YWlscyBvZiB0aGlzIG1vZHVsZS4gSnVzdCBhcyBSb2RuZXkg
c2FpZCwgaXQgaXMgYSBjaGFsbGVuZ2Ugb2YgMTU4OCBpbmZvIG1vZGVsIHRvIFlBTkcsIGFuZCB3
ZSB1c2UgdGhlIGxlYWZyZWYgb2YgWUFORyB0byB3b3JrIGFyb3VuZCBpdC48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImNvbG9yOmJsYWNrIj5JIHdvdWxkIGxpa2UgdG8gcHJvdmlkZSBhIGxpdHRsZSBtb3JlIGJh
Y2tncm91bmRzIG9uIHRoZSB0cmFkZW9mZjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4m
bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4xLiBJdCBzYXlzIGluIFNlYy4gNy41
LjIuMSBpbiBJRUVFIDE1ODgtMjAwODogcG9ydElkZW50aXR5IGlzIGEgbWVtYmVyIG9mIHRoZSBw
b3J0RFMgZGF0YSBzZXQuIEEgcG9ydElkZW50aXR5IGNvbnNpc3RzIG9mIHR3byBhdHRyaWJ1dGVz
LCBhczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPmZvbGxvd3M6PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LWZhbWlseTomcXVvdDtDYW1icmlhIE1hdGgmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7
Y29sb3I6YmxhY2siPuKOrzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs
YWNrIj4gcG9ydElkZW50aXR5LmNsb2NrSWRlbnRpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt
aWx5OiZxdW90O0NhbWJyaWEgTWF0aCZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFj
ayI+4o6vPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiBwb3J0
SWRlbnRpdHkucG9ydE51bWJlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPkZ1cnRoZXJt
b3JlLCB0aGUgJnF1b3Q7cG9ydERTLnBvcnRJZGVudGl0eSZxdW90OyBhdHRyaWJ1dGUgaXMgbWVu
dGlvbmVkIHF1aXRlIGEgZmV3IHRpbWVzIGluIDE1ODgtMjAwOCwgZXNwZWNpYWxseSBpbiBUYWJs
ZSAxNyBhbmQgdW5kZXIgVGFibGUgNjEsIHdpdGggYSBoaW50IHRoYXQgYXNzaWdubWVudCBhbmQg
Y29tcGFyaXNvbiBjYW4gYmUgZG9uZSBvbg0KIHRoaXMgbWVtYmVyIGRpcmVjdGx5LCB0aHVzIGl0
IHNlZW1zIHRvIG1lIHBvcnRJZGVudGl0eSBpcyBhbiBpbXBvcnRhbnQgYW5kIHdlbGwgdW5kZXJz
dG9vZCBjb25zdHJ1Y3QgaW4gdGhlIDE1ODggc3BlY2lmaWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4yLiBJZiB3
ZSBjaGFuZ2UgcG9ydERTLnBvcnRJZGVudGl0eSBmcm9tIGEgY29udGFpbmVyIHRvIGEgZ3JvdXBp
bmcsIHRoZW4gdGhlcmUgaXMgbm8gcG9ydElkZW50aXR5IGZvciBwb3J0RFMgYW5kIHRyYW5zcGFy
ZW50Y2xvY2tQb3J0RFMgaW4gdGhlIHJlc3VsdGluZyB0cmVlIGRpYWdyYW06PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+bW9k
dWxlOiBpZXRmLXB0cC1kYXRhc2V0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBpbnN0YW5jZS1saXN0KiBbaW5zdGFuY2UtbnVtYmVyXTxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYj
NDM7LS1ydyBpbnN0YW5jZS1udW1iZXImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgdWludDE2PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
IHwmbmJzcDsgJiM0MzstLXJ3IGRlZmF1bHQtZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNr
Ij4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyB0d28tc3RlcC1m
bGFnPyZuYnNwOyZuYnNwOyZuYnNwOyBib29sZWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFj
ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgY2xvY2staWRl
bnRpdHk/Jm5ic3A7Jm5ic3A7IGNsb2NrLWlkZW50aXR5LXR5cGU8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv
bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBu
dW1iZXItcG9ydHM/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVpbnQxNjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0Mzst
LXJ3IGNsb2NrLXF1YWxpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz
cDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGNsb2NrLWNsYXNzPyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1aW50ODxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsg
fCZuYnNwOyAmIzQzOy0tcncgY2xvY2stYWNjdXJhY3k/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IHVpbnQ4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
IHwmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBvZmZzZXQtc2NhbGVkLWxvZy12YXJp
YW5jZT8mbmJzcDsmbmJzcDsgdWludDE2PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgcHJpb3JpdHkxPyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1aW50ODxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0Mzst
LXJ3IHByaW9yaXR5Mj8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
dWludDg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZu
YnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBkb21haW4tbnVtYmVyPyZuYnNwOyZuYnNwOyZuYnNwOyB1
aW50ODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i
c3A7IHwmbmJzcDsgJiM0MzstLXJ3IHNsYXZlLW9ubHk/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IGJvb2xlYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm
bmJzcDsmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgY3VycmVudC1kczxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3
IHN0ZXBzLXJlbW92ZWQ/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IHVpbnQxNjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyB8
Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IG9mZnNldC1mcm9tLW1hc3Rlcj8mbmJzcDsmbmJzcDsg
dGltZS1pbnRlcnZhbC10eXBlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs
YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgbWVhbi1wYXRoLWRlbGF5PyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aW1lLWludGVydmFsLXR5cGU8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgcGFy
ZW50LWRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm
bmJzcDsgfCAmbmJzcDsmIzQzOy0tcncgcGFyZW50LXBvcnQtaWRlbnRpdHk8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7IHwmbmJz
cDsgJiM0MzstLXJ3IGNsb2NrLWlkZW50aXR5PyZuYnNwOyZuYnNwOyBjbG9jay1pZGVudGl0eS10
eXBlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz
cDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBwb3J0LW51bWJlcj8mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgdWludDE2PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgcGFyZW50LXN0YXRzPyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyBib29sZWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgb2JzZXJ2ZWQtcGFyZW50
LW9mZnNldC1zY2FsZWQtbG9nLXZhcmlhbmNlPyZuYnNwOyZuYnNwOyB1aW50MTY8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYj
NDM7LS1ydyBvYnNlcnZlZC1wYXJlbnQtY2xvY2stcGhhc2UtY2hhbmdlLXJhdGU/Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGludDMyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgZ3JhbmRtYXN0ZXIt
aWRlbnRpdHk/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJpbmFyeTxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0
MzstLXJ3IGdyYW5kbWFzdGVyLWNsb2NrLXF1YWxpdHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs
YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3
IGNsb2NrLWNsYXNzPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyB1aW50ODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyB8
Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgY2xvY2stYWNjdXJhY3k/Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVpbnQ4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBvZmZzZXQt
c2NhbGVkLWxvZy12YXJpYW5jZT8mbmJzcDsmbmJzcDsgdWludDE2PG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj
b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncg
Z3JhbmRtYXN0ZXItcHJpb3JpdHkxPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1aW50ODxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJz
cDsgJiM0MzstLXJ3IGdyYW5kbWFzdGVyLXByaW9yaXR5Mj8mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgdWludDg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsg
fCZuYnNwOyAmIzQzOy0tcncgdGltZS1wcm9wZXJ0aWVzLWRzPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv
cjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgY3Vy
cmVudC11dGMtb2Zmc2V0LXZhbGlkPyZuYnNwOyZuYnNwOyBib29sZWFuPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0t
cncgY3VycmVudC11dGMtb2Zmc2V0PyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyBpbnQxNjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZu
YnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGxlYXA1OT8mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYm9vbGVh
bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7
IHwmbmJzcDsgJiM0MzstLXJ3IGxlYXA2MT8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Ym9vbGVhbjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3
IHRpbWUtdHJhY2VhYmxlPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBib29sZWFuPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj
b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncg
ZnJlcXVlbmN5LXRyYWNlYWJsZT8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgYm9vbGVhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZu
YnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IHB0cC10aW1lc2NhbGU/Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IGJvb2xlYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz
cDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyB0aW1lLXNvdXJjZT8mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdWludDg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNr
Ij4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgcG9ydC1kcy1saXN0KiBbcG9y
dC1udW1iZXJdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IGNsb2NrLWlkZW50aXR5PyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjbG9jay1pZGVudGl0eS10eXBlPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgJiM0MzstLXJ3IHBvcnQtbnVtYmVyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVpbnQxNjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s
b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYj
NDM7LS1ydyBwb3J0LXN0YXRlPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyBwb3J0LXN0YXRlLWVudW1lcmF0aW9uPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgJiM0MzstLXJ3IHVuZGVybHlpbmctaW50ZXJmYWNlPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpZjppbnRlcmZhY2UtcmVmPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgJiM0MzstLXJ3IGxvZy1taW4tZGVsYXktcmVxLWludGVydmFsPyZuYnNwOyZuYnNw
OyZuYnNwOyBpbnQ4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHBlZXItbWVhbi1wYXRoLWRl
bGF5PyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyB0aW1lLWludGVydmFsLXR5cGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm
bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgbG9nLWFubm91
bmNlLWludGVydmFsPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyBpbnQ4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IGFubm91bmNlLXJlY2VpcHQtdGlt
ZW91dD8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdWludDg8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyAmIzQzOy0tcncgbG9nLXN5bmMtaW50ZXJ2YWw/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGludDg8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyAmIzQzOy0tcncgZGVsYXktbWVjaGFuaXNtPyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyBkZWxheS1tZWNoYW5pc20tZW51bWVyYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y
OmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQz
Oy0tcncgbG9nLW1pbi1wZGVsYXktcmVxLWludGVydmFsPyZuYnNwOyZuYnNwOyBpbnQ4PG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgJiM0MzstLXJ3IHZlcnNpb24tbnVtYmVyPyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyB1aW50ODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZu
YnNwOyZuYnNwOyAmIzQzOy0tcncgdHJhbnNwYXJlbnQtY2xvY2stZGVmYXVsdC1kczxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1y
dyBjbG9jay1pZGVudGl0eT8mbmJzcDsmbmJzcDsmbmJzcDsgY2xvY2staWRlbnRpdHktdHlwZTxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYj
NDM7LS1ydyBudW1iZXItcG9ydHM/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVpbnQx
NjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7
ICYjNDM7LS1ydyBkZWxheS1tZWNoYW5pc20/Jm5ic3A7Jm5ic3A7IGRlbGF5LW1lY2hhbmlzbS1l
bnVtZXJhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNw
OyB8Jm5ic3A7ICYjNDM7LS1ydyBwcmltYXJ5LWRvbWFpbj8mbmJzcDsmbmJzcDsmbmJzcDsgdWlu
dDg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsgJiM0Mzst
LXJ3IHRyYW5zcGFyZW50LWNsb2NrLXBvcnQtZHMtbGlzdCogW3BvcnQtbnVtYmVyXTxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyAmIzQzOy0tcncgY2xvY2staWRlbnRpdHk/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IGNsb2NrLWlkZW50aXR5LXR5cGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHBvcnQtbnVtYmVyJm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVp
bnQxNjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgbG9nLW1pbi1wZGVsYXktcmVxLWludGVydmFsPyZuYnNw
OyZuYnNwOyBpbnQ4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBmYXVsdHktZmxhZz8mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYm9vbGVhbjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm
IzQzOy0tcncgcGVlci1tZWFuLXBhdGgtZGVsYXk/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRpbWUtaW50ZXJ2YWwtdHlwZTxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPklu
IGNvbnRyYXN0IHRvIHRoZSBvcmlnaW5hbCAxNTg4IFlBTkcgdHJlZSBkaWFncmFtOjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBtb2R1bGU6IGlldGYtcHRwLWRhdGFz
ZXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgJiM0MzstLXJ3IGluc3RhbmNlLWxpc3QqIFtpbnN0YW5jZS1udW1iZXJdPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGluc3RhbmNlLW51bWJlciZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyB1aW50MTY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgZGVmYXVsdC1k
czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IHR3by1zdGVwLWZsYWc/Jm5ic3A7
Jm5ic3A7Jm5ic3A7IGJvb2xlYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBj
bG9jay1pZGVudGl0eT8mbmJzcDsmbmJzcDsgY2xvY2staWRlbnRpdHktdHlwZTxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8
Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IG51bWJlci1wb3J0cz8mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgdWludDE2PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgY2xvY2stcXVh
bGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgY2xvY2stY2xh
c3M/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVpbnQ4PG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBjbG9jay1hY2N1cmFjeT8m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdWludDg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs
YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7
IHwmbmJzcDsgJiM0MzstLXJ3IG9mZnNldC1zY2FsZWQtbG9nLXZhcmlhbmNlPyZuYnNwOyZuYnNw
OyB1aW50MTY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBwcmlvcml0eTE/Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVpbnQ4PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm
bmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgcHJpb3JpdHkyPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyB1aW50ODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0Mzst
LXJ3IGRvbWFpbi1udW1iZXI/Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVpbnQ4PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz
cDsgfCZuYnNwOyAmIzQzOy0tcncgc2xhdmUtb25seT8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgYm9vbGVhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBjdXJyZW50LWRz
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgc3RlcHMtcmVtb3ZlZD8mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdWludDE2PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv
cjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZu
YnNwOyAmIzQzOy0tcncgb2Zmc2V0LWZyb20tbWFzdGVyPyZuYnNwOyB0aW1lLWludGVydmFsLXR5
cGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBtZWFuLXBhdGgtZGVsYXk/Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRpbWUtaW50ZXJ2YWwtdHlwZTxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7
ICYjNDM7LS1ydyBwYXJlbnQtZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBw
YXJlbnQtcG9ydC1pZGVudGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQz
Oy0tcncgY2xvY2staWRlbnRpdHk/Jm5ic3A7Jm5ic3A7IGNsb2NrLWlkZW50aXR5LXR5cGU8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgfCZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IHBvcnQtbnVtYmVyPyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1aW50MTY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs
YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7
ICYjNDM7LS1ydyBwYXJlbnQtc3RhdHM/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IGJvb2xlYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBvYnNl
cnZlZC1wYXJlbnQtb2Zmc2V0LXNjYWxlZC1sb2ctdmFyaWFuY2U/IHVpbnQxNjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDt8
Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IG9ic2VydmVkLXBhcmVudC1jbG9jay1waGFzZS1jaGFu
Z2UtcmF0ZT8mbmJzcDsmbmJzcDsmbmJzcDsgaW50MzI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs
YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7
ICYjNDM7LS1ydyBncmFuZG1hc3Rlci1pZGVudGl0eT8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYmluYXJ5
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgZ3JhbmRtYXN0ZXItY2xvY2stcXVh
bGl0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgY2xvY2stY2xh
c3M/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVpbnQ4PG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBjbG9jay1hY2N1cmFjeT8m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdWludDg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs
YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7
IHwmbmJzcDsgJiM0MzstLXJ3IG9mZnNldC1zY2FsZWQtbG9nLXZhcmlhbmNlPyZuYnNwOyZuYnNw
OyB1aW50MTY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBncmFuZG1hc3Rlci1w
cmlvcml0eTE/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IHVpbnQ4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs
YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgZ3Jh
bmRtYXN0ZXItcHJpb3JpdHkyPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1aW50ODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2si
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyB0
aW1lLXByb3BlcnRpZXMtZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBjdXJy
ZW50LXV0Yy1vZmZzZXQtdmFsaWQ/Jm5ic3A7Jm5ic3A7IGJvb2xlYW48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw
OyB8Jm5ic3A7ICYjNDM7LS1ydyBjdXJyZW50LXV0Yy1vZmZzZXQ/Jm5ic3A7Jm5ic3A7ICZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2ludDE2PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv
cjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZu
YnNwOyAmIzQzOy0tcncgbGVhcDU5PyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBib29sZWFuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv
cjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZu
YnNwOyAmIzQzOy0tcncgbGVhcDYxPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBib29sZWFuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv
cjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgfCZu
YnNwOyAmIzQzOy0tcncgdGltZS10cmFjZWFibGU/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJvb2xlYW48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgfCZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBmcmVxdWVuY3ktdHJhY2VhYmxlPyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBib29sZWFuPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm
bmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgcHRwLXRpbWVzY2FsZT8mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgYm9vbGVhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IHRpbWUtc291cmNl
PyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1aW50ODxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7
ICYjNDM7LS1ydyBwb3J0LWRzLWxpc3QqIFtwb3J0LW51bWJlcl08bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv
bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgcG9ydC1udW1iZXImbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSZndDsgLi4vcG9ydC1pZGVudGl0eS9wb3J0LW51bWJl
cjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydw0KPHNwYW4gc3R5
bGU9ImJhY2tncm91bmQ6eWVsbG93Ij5wb3J0LWlkZW50aXR5PC9zcGFuPjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGNsb2NrLWlkZW50aXR5PyZu
YnNwOyZuYnNwOyBjbG9jay1pZGVudGl0eS10eXBlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFj
ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgfCZuYnNwOyAmIzQzOy0tcncgcG9ydC1udW1iZXI/Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IHVpbnQxNjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYj
NDM7LS1ydyBwb3J0LXN0YXRlPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyBwb3J0LXN0YXRlLWVudW1lcmF0aW9uPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj
b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHVuZGVybHlpbmctaW50ZXJmYWNlPyBpZjppbnRl
cmZhY2UtcmVmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IGxv
Zy1taW4tZGVsYXktcmVxLWludGVydmFsPyZuYnNwOyZuYnNwOyZuYnNwOyBpbnQ4PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHBlZXItbWVhbi1wYXRoLWRlbGF5
PyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0
aW1lLWludGVydmFsLXR5cGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQz
Oy0tcncgbG9nLWFubm91bmNlLWludGVydmFsPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyBpbnQ4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgJiM0MzstLXJ3IGFubm91bmNlLXJlY2VpcHQtdGltZW91dD8mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgdWludDg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQz
Oy0tcncgbG9nLXN5bmMtaW50ZXJ2YWw/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGludDg8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgZGVsYXktbWVjaGFuaXNtPyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyBkZWxheS1tZWNoYW5pc20tZW51bWVyYXRpb248bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgbG9nLW1pbi1wZGVsYXktcmVxLWludGVy
dmFsPyZuYnNwOyZuYnNwOyBpbnQ4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
JiM0MzstLXJ3IHZlcnNpb24tbnVtYmVyPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyB1aW50ODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgdHJhbnNwYXJlbnQtY2xvY2stZGVmYXVsdC1kczxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBjbG9jay1pZGVudGl0eT8mbmJzcDsmbmJzcDsmbmJz
cDsgY2xvY2staWRlbnRpdHktdHlwZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBudW1iZXIt
cG9ydHM/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVpbnQxNjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i
c3A7ICYjNDM7LS1ydyBkZWxheS1tZWNoYW5pc20/Jm5ic3A7Jm5ic3A7IGRlbGF5LW1lY2hhbmlz
bS1lbnVtZXJhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl
eHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICYjNDM7LS1ydyBwcmltYXJ5LWRvbWFpbj8m
bmJzcDsmbmJzcDsmbmJzcDsgdWludDg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHRyYW5zcGFyZW50LWNs
b2NrLXBvcnQtZHMtbGlzdCogW3BvcnQtbnVtYmVyXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Ymxh
Y2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyAmIzQzOy0tcncgcG9ydC1udW1iZXImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSZndDsgLi4vcG9ydC1pZGVudGl0eS9wb3J0LW51
bWJlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgPHNwYW4gc3R5bGU9ImJh
Y2tncm91bmQ6eWVsbG93Ij4NCnBvcnQtaWRlbnRpdHk8L3NwYW4+PG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj
b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGNsb2NrLWlkZW50aXR5PyZuYnNwOyZuYnNwOyBj
bG9jay1pZGVudGl0eS10eXBlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs
YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0
MzstLXJ3IHBvcnQtbnVtYmVyPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1aW50MTY8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IGxvZy1taW4tcGRlbGF5LXJlcS1p
bnRlcnZhbD8mbmJzcDsmbmJzcDsgaW50ODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQz
Oy0tcncgZmF1bHR5LWZsYWc/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IGJvb2xlYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3
IHBlZXItbWVhbi1wYXRoLWRlbGF5PyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyB0aW1lLWludGVydmFsLXR5cGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs
YWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5JIGFncmVlLCBhc3NpZ25t
ZW50IGFuZCBjb21wYXJpc29uIGNhbiBzdGlsbCBiZSBkb25lIG9uIGNsb2NrLWlkZW50aXR5IGFu
ZCBwb3J0LW51bWJlciBkaXJlY3RseSAod2l0aG91dCBhIHBvcnRJZGVudGl0eSBjb25zdHJ1Y3Qp
IC4gQnV0IHBlb3BsZSB3aG8gYXJlIGZhbWlsaWFyIHdpdGggMTU4OC0yMDA4IG1heSBxdWVzdGlv
biB3aGVyZQ0KIHBvcnRJZGVudGl0eSBpcyBnb25lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Ymxh
Y2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjMuIEkgdGhpbmsgbGVhZnJl
ZiBpcyBhIHZlcnkgZ2VuZXJhbCBzZW1hbnRpY3MgdGhpbmcgaW4gWUFORyBsYW5ndWFnZSwgaWYg
YW55IHRvb2xzIGhhdmUgcHJvYmxlbSB3aXRoIHRoaXMgZmVhdHVyZSwgbWF5YmUgd2UgbmVlZCB0
byBjb250YWN0IHdpdGggdGhlIHRvb2w8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+4oCZPC9zcGFu
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPnMNCiBkZXZlbG9wZXIgdG8g
c3VwcG9ydCBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImNvbG9yOmJsYWNrIj5GaW5hbGx5LCBtb3JlIGlucHV0cyBmcm9tIHRoZSBXRyBhcmUg
d2VsY29tZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImNvbG9yOmJsYWNrIj5UaGFua3MgYWdhaW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFj
ayI+WXVhbmxvbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4t
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IFRJQ1RPQyBbPGEgaHJlZj0ibWFp
bHRvOnRpY3RvYy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnRpY3Rv
Yy1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIFJvZG5leSBDdW1taW5nczxicj4N
ClNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDI3LCAyMDE3IDE6MjQgQU08YnI+DQpUbzogPGEg
aHJlZj0ibWFpbHRvOnRpY3RvY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRpY3RvY0BpZXRm
Lm9yZzwvYT48YnI+DQpTdWJqZWN0OiBSZTogW1RJQ1RPQ10gZHJhZnQtaWV0Zi10aWN0b2MtMTU4
OHYyLXlhbmctMDUgLSBDb25jZXJuIG92ZXIgcG9ydCBpZGVudGlmaWVyPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+VGhhbmtz
IFNlYW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJjb2xvcjpibGFjayI+UmVnYXJkaW5nIHlvdXIgb3RoZXIgY29tbWVudCBvbiBUTEQuLi4gSSBh
Z3JlZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImNvbG9yOmJsYWNrIj5SZWdhcmRpbmcgdGhlIGNvbW1lbnQgYmVsb3cgb24gcG9ydC1pZGVudGl0
eSwgSSBhZ3JlZSB0aGF0IHdlIG5lZWQgdG8gZG8gaXQgZm9yIHByYWN0aWNhbCByZWFzb25zLjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6
YmxhY2siPkluIDE1ODgtMjAwOCwgdGhlcmUgaXMgYSBkaXN0aW5jdCBkYXRhc2V0IG1lbWJlciBm
b3IgcG9ydERTLnBvcnRJZGVudGl0eSwgd2hpY2ggNS4zLjUgc3BlY2lmaWVzIGFzIHVzaW5nIHR5
cGUgUG9ydElkZW50aXR5OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyBzdHJ1
Y3QgUG9ydElkZW50aXR5IHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz
cDsmbmJzcDsgQ2xvY2tJZGVudGl0eSBjbG9ja0lkZW50aXR5OzxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s
b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyBVSW50ZWdlciBwb3J0TnVtYmVyOzxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyB9PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFj
ayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+SWYgd2UgaW50ZXJwcmV0IHRo
ZSAxNTg4LTIwMDggZGF0YXNldHMgYXMgYW4gaW5mb3JtYXRpb24gbW9kZWwsIGFuZCBhcHBseSB0
aGF0IGFzIGRpcmVjdGx5IGFzIHBvc3NpYmxlIHRvIGEgWUFORyBkYXRhIG1vZGVsLCBwb3J0RFMu
cG9ydElkZW50aXR5IGlzIGEgY29udGFpbmVyLCB3aGljaCBpcyB3aGF0IHdlIGhhdmUgc28gZmFy
LiBUaGF0DQogaW50cm9kdWNlcyBhIGNoYWxsZW5nZSwgYmVjYXVzZSB3ZSB3YW50IHRvIHVzZSBw
b3J0RFMucG9ydElkZW50aXR5LnBvcnROdW1iZXIgYXMgdGhlIGtleSB0byB0aGUgbGlzdCBvZiBw
b3J0RFMncy4gV2Ugc29sdmVkIHRoYXQgY2hhbGxlbmdlIHdpdGggYSBsZWFmcmVmLCBidXQgSSdk
IGFncmVlIHRoYXQgaXMgdWdseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5Zb3VyIHByb3Bvc2FsIGNoYW5nZXMgcG9ydERT
LnBvcnRJZGVudGl0eSBmcm9tIGEgY29udGFpbmVyIHRvIGEgZ3JvdXBpbmcsIHNvIHRoYXQgaXQg
cG9ydERTLnBvcnRJZGVudGl0eS5wb3J0TnVtYmVyIGNhbiBiZSB1c2VkIGFzIHRoZSBrZXkgd2l0
aG91dCBhIGxlYWZyZWYuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIGRvd25zaWRlIGlzIHRoYXQgaWYvd2hlbiBhIFlB
TkcgbWFuYWdlbWVudCBjbGllbnQgdHJpZXMgdG8gJnF1b3Q7Z2V0JnF1b3Q7IHBvcnREUy5wb3J0
SWRlbnRpdHksIGl0IGRvZXNuJ3Qgd29yay4uLiB0aGVyZSBpcyBubyBwb3J0SWRlbnRpdHkgdG8g
Z2V0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Y29sb3I6YmxhY2siPlBlcnNvbmFsbHksIEkgdGhpbmsgdGhhdCBkb3duc2lkZSBpcyB3b3J0aCBp
dC4gT25lIGNhbiBhcmd1ZSB0aGF0IHlvdXIgcHJvcG9zYWwgc3RpbGwgY29uZm9ybXMgdG8gdGhl
IDE1ODgtMjAwOCBpbmZvcm1hdGlvbiBtb2RlbCBmb3IgbWFuYWdlbWVudCwgaW4gdGhhdCBwb3J0
RFMucG9ydElkZW50aXR5IHN0aWxsICZxdW90O2V4aXN0cyZxdW90OyBpbiBhDQogbWFubmVyIHRo
YXQgbWFrZXMgc2Vuc2UgZm9yIFlBTkcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i
c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Um9kbmV5PG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj
b2xvcjpibGFjayI+Jm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOiBU
SUNUT0MgWzxhIGhyZWY9Im1haWx0bzp0aWN0b2MtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJf
YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25l
Ij5tYWlsdG86dGljdG9jLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPl0gT24gQmVoYWxmIE9m
IFNlYW4gQ29uZG9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+U2VudDogVHVlc2RheSwg
U2VwdGVtYmVyIDI2LCAyMDE3IDEwOjM4IEFNPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+
VG86IDxhIGhyZWY9Im1haWx0bzp0aWN0b2NAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCjxz
cGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj50aWN0b2NA
aWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q
bGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPlN1YmplY3Q6
IFtUSUNUT0NdIGRyYWZ0LWlldGYtdGljdG9jLTE1ODh2Mi15YW5nLTA1IC0gQ29uY2VybiBvdmVy
IHBvcnQgaWRlbnRpZmllcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPldpdGggcmVmZXJlbmNlIHRvICZxdW90O1lBTkcgRGF0
YSBNb2RlbCBmb3IgSUVFRSAxNTg4djImcXVvdDsNCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5z
ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9k
cmFmdC0yRGlldGYtMkR0aWN0b2MtMkQxNTg4djItMkR5YW5nLTJEMDUmYW1wO2Q9RHdNRkF3JmFt
cDtjPUlfMFl3b0t5N3o1TE1UVmR5TzZZQ2lFMnV6STFqalpadUlQZWxjU2ppeEEmYW1wO3I9V0E3
MXNmMm83RHc3Q2JZaEZ0MjREUGp0M2xKdXVwc3dXWWRuYm9LYlo4ayZhbXA7bT1qS0hjelZOTE4t
S3VWMkhSWmtiRVpZMVN6bENEX0F6dGthV1NjY3JxQkk4JmFtcDtzPW1zaDdBN19PZ0haMWw2NURu
Nl9MaGlESVhrWHBGZWlMR21LYkt4c3FYV3cmYW1wO2UiIHRhcmdldD0iX2JsYW5rIj4NCjxzcGFu
IHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3Vy
bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3Jn
X2h0bWxfZHJhZnQtMkRpZXRmLTJEdGljdG9jLTJEMTU4OHYyLTJEeWFuZy0yRDA1JmFtcDtkPUR3
TUZBdyZhbXA7Yz1JXzBZd29LeTd6NUxNVFZkeU82WUNpRTJ1ekkxampaWnVJUGVsY1NqaXhBJmFt
cDtyPVdBNzFzZjJvN0R3N0NiWWhGdDI0RFBqdDNsSnV1cHN3V1lkbmJvS2JaOGsmYW1wO209aktI
Y3pWTkxOLUt1VjJIUlprYkVaWTFTemxDRF9BenRrYVdTY2NycUJJOCZhbXA7cz1tc2g3QTdfT2dI
WjFsNjVEbjZfTGhpRElYa1hwRmVpTEdtS2JLeHNxWFd3JmFtcDtlPC9zcGFuPjwvYT49DQo8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs
YWNrIj5JIGhhdmUgYSBjb25jZXJuIGFib3V0IHRoZSBzdHJ1Y3R1cmUgb2YgdGhlIFlBTkcsIGFu
ZCBob3cgdGhlIGxpc3RzIHBvcnQtZHMtbGlzdCBhbmQgdHJhbnNwYXJlbnQtY2xvY2stcG9ydC1k
cy1saXN0IGFyZSBpbmRleGVkIHdpdGggYSBsZWFmIHdoaWNoIGlzIGEgbGVhZnJlZi48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNr
Ij5UaGUgc3RydWN0dXJlIHNlZW1zIHVubmVjZXNzYXJpbHkgY29tcGxleCAtIHBvcnQtbnVtYmVy
IGlzIHJlcHJlc2VudGVkIGFzIGEgbGVhZiBkaXJlY3RseSBiZW5lYXRoIHRoZSBsaXN0ICh0byBi
ZSB1c2VkIGFzIGtleSkgYW5kIGFnYWluIHVuZGVyIHRoZSBwb3J0LWlkZW50aXR5IGNvbnRhaW5l
ci4gSXQgaXMgc3RydWN0dXJlZCBpbiBhDQogd2F5IHRoYXQgSSBiZWxpZXZlIHdvdWxkIG1ha2Ug
aXQgZGlmZmljdWx0IHRvIHdvcmsgd2l0aCBzb21lIFlBTkcgdG9vbHMgaW4gdGhlIG1hcmtldC48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y
OmJsYWNrIj5UaGUgcHVycG9zZSBvZiBwb3J0LWlkZW50aXR5IGNvbnRhaW5lciBpcyBub3QgY2xl
YXIgZnJvbSB0aGUgZG9jdW1lbnQgLSBpdCB3b3VsZCBhY2hpZXZlIHRoZSBzYW1lIHB1cnBvc2Ug
aWYgaXQgd2FzIGxlZnQgb3V0IG9mIHBvcnQtZHMtZW50cnkgYW5kIHRyYW5zcGFyZW50LWNsb2Nr
LXBvcnQtZHMtZW50cnkgYW5kIGluc3RlYWQgdGhlDQogZ3JvdXBpbmcgcG9ydC1pZGVudGl0eS1n
cm91cGluZyBpbmNsdWRlZCBkaXJlY3RseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4m
bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5TZWUgdGhlIGF0dGFjaGVkIGZpbGVz
IGFzIG9yaWdpbmFsLCBhIG1vZGlmaWVkIHZlcnNpb24gYW5kIGFzIGEgcGF0Y2ggZmlsZS48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs
YWNrIj5TZWFuIENvbmRvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPj09PT09PT09PT09
PT09PT09PT09PT09PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4
dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+U2VhbiBDb25kb248bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5TeXN0ZW0gJmFtcDsgU29mdHdhcmUgQXJjaGl0ZWN0
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+RnJlcXVlbmN5ICZhbXA7IFRpbWluZyBEaXZp
c2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPk1pY3Jvc2VtaSBJbmMuPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOnNlYW4uY29uZG9uQG1pY3Jvc2Vt
aS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0
LWRlY29yYXRpb246bm9uZSI+bWFpbHRvOnNlYW4uY29uZG9uQG1pY3Jvc2VtaS5jb208L3NwYW4+
PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Y29sb3I6YmxhY2siPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+VElDVE9DIG1haWxpbmcgbGlzdDxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpUSUNUT0NAaWV0Zi5vcmci
IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29y
YXRpb246bm9uZSI+VElDVE9DQGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv
bG9yOmJsYWNrIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L3RpY3RvYyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3Rl
eHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L3RpY3RvYzwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_3B0A1BED22CAD649A1B3E97BE5DDD68BBB5CC17Ddggeml507mbxchi_--


From nobody Fri Sep 29 02:38:38 2017
Return-Path: 
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 D8D5E126D0C; Fri, 29 Sep 2017 02:38:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 iPpOq2aUpCJ3; Fri, 29 Sep 2017 02:38:34 -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 7CF141241F3; Fri, 29 Sep 2017 02:38:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21365; q=dns/txt; s=iport; t=1506677911; x=1507887511; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=KH5D4r0/btgiUu5JIoBkFxM1Z9YA9aB/dHqJQ9OD43E=; b=O0agoR8Keq4ZZ8zME9WEN/5fOGFbQeE7AdHeCNwHewD1D2IyLzZaG+zS X63udNfUyJkzF2AXeptcUQFVyyGXmTqNHBg7TAuKIbq/ecsxQtjHf+ISq mqI4NSXHXMSbnqF70sBZXkoKaBSHD7ePitonbI0psa+pOfZB4qlmdCVQi c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CPAQD6E85Z/xbLJq1VCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYRAbieDeIsTkEAiljmCBAoYC4FegmtPAoRtFAECAQEBAQEBAWs?= =?us-ascii?q?ohRgBAQEBAwEBIQQLAQUzAwsMBAsRAQMBAQECAiMDAgInHwMGCAYBDAYCAQGKL?= =?us-ascii?q?RCnLIFtOotEAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBDoIfg1OBaisLgWWBDYM?= =?us-ascii?q?ygRoFAQgKAQcYLIJngmAFoSyHXoNeiSiCFIVug1okhweNdYdZgTk2IYEDCzIhC?= =?us-ascii?q?B0VSYUaHIFoPzYBAYYEgjQBAQE?=
X-IronPort-AV: E=Sophos;i="5.42,452,1500940800"; d="scan'208";a="657906968"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Sep 2017 09:38:26 +0000
Received: from [10.63.23.161] (dhcp-ensft1-uk-vla370-10-63-23-161.cisco.com [10.63.23.161]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8T9cQNt003440; Fri, 29 Sep 2017 09:38:26 GMT
To: Jiangyuanlong , Martin Bjorklund 
Cc: "sean.condon@microsemi.com" , "tictoc@ietf.org" , "netmod@ietf.org" 
References: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5C9C01@dggeml507-mbx.china.huawei.com> <640F4C69F839A64C8949EF04FAAEE44679F25561@avsrvexchmbx1.microsemi.net> <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5CB62E@dggeml507-mbx.china.huawei.com> <20170928.152312.261607006753399632.mbj@tail-f.com> <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5CC14E@dggeml507-mbx.china.huawei.com>
From: Robert Wilton 
Message-ID: 
Date: Fri, 29 Sep 2017 10:38:26 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5CC14E@dggeml507-mbx.china.huawei.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] draft-ietf-tictoc-1588v2-yang-05 - Concern over port identifier
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Sep 2017 09:38:38 -0000

Hi Yuanlong,

I agree with Martin, having a single key is a better data model.

Duplicating the port-number in the data model just makes it that little 
bit more annoying to use.

I think that Information models are often modeled using UML, which I'm 
not particularly familiar with, but seems to follow object orientated 
principles.

YANG is not object-orientated, instead seems to more closely resemble a 
document based "mixin" architecture.

Because of this difference, I think that there will naturally be 
differences between how something in best modeled in UML vs how it is 
best modeled in YANG.

For me, having the YANG model as simple, consistent, and as easy to 
understand as possible is more important that a very close mapping to a 
related information model.  So, in summary, my suggestion is to allow 
these models to diverge where necessary.

Thanks,
Rob


On 29/09/2017 10:22, Jiangyuanlong wrote:
> Martin,
>
> Thank a lot for your instantly reply. Please see my further comments inline.
>
> Cheers,
> Yuanlong
>
> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com]
> Sent: Thursday, September 28, 2017 9:23 PM
> To: Jiangyuanlong
> Cc: sean.condon@microsemi.com; netmod@ietf.org; tictoc@ietf.org
> Subject: Re: [netmod] draft-ietf-tictoc-1588v2-yang-05 - Concern over port identifier
>
> Jiangyuanlong  wrote:
>> Sean,
>>
>> My personal opinion is that it can work, but I would like to ask for
>> more opinions from our netmod experts;)
>>
>> Hi netmod experts,
>> Considering the following sample module, my-list is a list, and it
>> needs to use a leaf member "port-number" in my-port-container as a
>> key.
>> We now have 3 options:
>> 1.
>>    list my-list {
>>      key "port-number";
>>      leaf port-number {
>>         type uint16;
>>      }
>>
>>      container my-port-container {
>>          leaf port-number {
>>            type uint16;
>>          }
>>           leaf other-leaf {
>>             ...
>>           }
>>      }
>>    }
>> But this does not work for there is compiling error.
> Why wouldn't this work?
> [JY] The original intention of the 1588 info model is to use my-port-container.port-number as the key. The code actually parses, but we need to synchronize my-list.port-number and my-list.my-port-container.port-number all the while.
>
> I suspect you meant:
>
>     list my-list {
>       key "port-number";
>   
>       container my-port-container {
>           leaf port-number {
>            type uint16;
>           }
>            leaf other-leaf {
>              ...
>            }
>       }
>     }
>
>
>> 2.
>>    list my-list {
>>      key "port-number";
>>      leaf port-number {
>>         type uint16;
>>      }
>>      container my-port-container {
>>          leaf port-number {
>>              type leafref{
>>                path "../../port-number";
>>              }
>>          }
>>           leaf other-leaf {
>>             ...
>>           }
>>      }
>>    }
>> Option 2 can parse, though leafref in a sub-module seems not very
>> natural.
>>
>> 3.
>>    list my-list {
>>      key "port-number";
>>      leaf port-number {
>>         type leafref{
>>            path "../my-port-container/port-number";
>>         }
>>      }
>>      container my-port-container {
>>          leaf port-number {
>>            type uint16;
>>          }
>>           leaf other-leaf {
>>             ...
>>           }
>>      }
>>    }
>>
>> Option 3 can also parse, though leafref seems not a very natural key.
>> What is your favorite option? Or do you have any better schemes?
>
> Having a leafref like in option 2 or 3 is just redundant and a hassle for the client.  In order to create a a list entry, the client would have to first provide the port-number value once for the key, and then again the exact same value in the container:
>
>    
>      25
>      
>        25
>        ...
>      
>    
>
> Note that both "port-number" MUST be given the exact same value by the client.
>
> In YANG, key leafs cannot be nested under containers.  I would simply have the key on the top of the list, and not in the container.
>
> (It seems this is what others have proposed as well in this thread.)
>
> [JY] Yes, I agree that this model is not very elegant, but the info model was published in IEEE 1588 already, people have been used to this info model for a long time and we would like to stick to it as far as we can.
> As an alternative, option 2 can be enhanced:
>     list my-list {
>       key "port-number";
>       leaf port-number {
>          type uint16;
>       }
>       container my-port-container {
>           leaf port-number {
>               type leafref{
>                 path "../../port-number";
>               }
>               config false;
>           }
>           leaf other-leaf {
>             ...
>         }
>       }
>     }
>
> In this way, the "config false" makes the leafref read-only, so that configuration doesn't need to write twice. How do you think about this scheme?
> Thanks again,
> Yuanlong
>
>
> /martin
>
>
>
>
>
>> Your opinions are very important for our revision of this draft.
>>
>> Thanks,
>> Yuanlong
>>
>>
>> From: Sean Condon [mailto:sean.condon@microsemi.com]
>> Sent: Wednesday, September 27, 2017 7:11 PM
>> To: Jiangyuanlong
>> Cc: tictoc@ietf.org; Rodney Cummings
>> Subject: RE: draft-ietf-tictoc-1588v2-yang-05 - Concern over port
>> identifier
>>
>> Thanks guys for your responses.
>>
>> I accept your points to keep the structure as aligned to the IEEE 1588
>> standard as possible.
>>
>> One alternate suggestion that I would make, is that the port-number
>> currently defined as leafref should be made the real attribute (i.e.
>> uint16) and that the port-number inside port-identity container should
>> be made in to the leaf ref (and set to mandatory true).
>>
>> The reason I say this is that
>>
>>    1.  XML models are usually navigated and constructed root-to-leaf, and
>>    the way it's portrayed at the moment is that port-number leafref
>>    points to something that may not exist at the time it is being
>>    defined. This makes it difficult to implement.
>>    2.  Also port-identity/port-number is not "mandatory true" meaning
>>    that it could be left out altogether. It's not valid for it to have a
>>    default value either since every item in the list will need a
>>    different identifier.
>>
>> With this suggestion the structure you require with port-identity
>> still exists, but now the implementation is more straightforward, and
>> the change will be transparent to an end user.
>>
>>
>> Best regards, Sean
>> =======================
>> Sean Condon
>> System & Software Architect
>> Frequency & Timing Division
>> Microsemi Inc.
>> sean.condon@microsemi.com
>>
>> ________________________________
>> From: Jiangyuanlong [jiangyuanlong@huawei.com]
>> Sent: 27 September 2017 08:05
>> To: Sean Condon
>> Cc: tictoc@ietf.org; Rodney Cummings
>> Subject: RE: draft-ietf-tictoc-1588v2-yang-05 - Concern over port
>> identifier EXTERNAL EMAIL
>>
>> Dear Sean,
>>
>>
>>
>> Thank you a lot for diving into the technical details of this module.
>> Just as Rodney said, it is a challenge of 1588 info model to YANG, and
>> we use the leafref of YANG to work around it.
>>
>> I would like to provide a little more backgrounds on the tradeoff:
>>
>>
>>
>> 1. It says in Sec. 7.5.2.1 in IEEE 1588-2008: portIdentity is a member
>> of the portDS data set. A portIdentity consists of two attributes, as
>>
>> follows:
>>
>> ⎯ portIdentity.clockIdentity
>>
>> ⎯ portIdentity.portNumber
>>
>> Furthermore, the "portDS.portIdentity" attribute is mentioned quite a
>> few times in 1588-2008, especially in Table 17 and under Table 61,
>> with a hint that assignment and comparison can be done on this member
>> directly, thus it seems to me portIdentity is an important and well
>> understood construct in the 1588 specification.
>>
>>
>>
>> 2. If we change portDS.portIdentity from a container to a grouping,
>> then there is no portIdentity for portDS and transparentclockPortDS in
>> the resulting tree diagram:
>>
>>
>>
>> module: ietf-ptp-dataset
>>
>>      +--rw instance-list* [instance-number]
>>
>>      |  +--rw instance-number       uint16
>>
>>      |  +--rw default-ds
>>
>>      |  |  +--rw two-step-flag?    boolean
>>
>>      |  |  +--rw clock-identity?   clock-identity-type
>>
>>      |  |  +--rw number-ports?     uint16
>>
>>      |  |  +--rw clock-quality
>>
>>      |  |  |  +--rw clock-class?                  uint8
>>
>>      |  |  |  +--rw clock-accuracy?               uint8
>>
>>      |  |  |  +--rw offset-scaled-log-variance?   uint16
>>
>>      |  |  +--rw priority1?        uint8
>>
>>      |  |  +--rw priority2?        uint8
>>
>>      |  |  +--rw domain-number?    uint8
>>
>>      |  |  +--rw slave-only?       boolean
>>
>>      |  +--rw current-ds
>>
>>      |  |  +--rw steps-removed?        uint16
>>
>>      |  |  +--rw offset-from-master?   time-interval-type
>>
>>      |  |  +--rw mean-path-delay?      time-interval-type
>>
>>      |  +--rw parent-ds
>>
>>      |  |  +--rw parent-port-identity
>>
>>      |  |  |  +--rw clock-identity?   clock-identity-type
>>
>>      |  |  |  +--rw port-number?      uint16
>>
>>      |  |  +--rw parent-stats?                                 boolean
>>
>>      |  |  +--rw observed-parent-offset-scaled-log-variance?   uint16
>>
>>      |  |  +--rw observed-parent-clock-phase-change-rate?      int32
>>
>>      |  |  +--rw grandmaster-identity?                         binary
>>
>>      |  |  +--rw grandmaster-clock-quality
>>
>>      |  |  |  +--rw clock-class?                  uint8
>>
>>      |  |  |  +--rw clock-accuracy?               uint8
>>
>>      |  |  |  +--rw offset-scaled-log-variance?   uint16
>>
>>      |  |  +--rw grandmaster-priority1?                        uint8
>>
>>      |  |  +--rw grandmaster-priority2?                        uint8
>>
>>      |  +--rw time-properties-ds
>>
>>      |  |  +--rw current-utc-offset-valid?   boolean
>>
>>      |  |  +--rw current-utc-offset?         int16
>>
>>      |  |  +--rw leap59?                     boolean
>>
>>      |  |  +--rw leap61?                     boolean
>>
>>      |  |  +--rw time-traceable?             boolean
>>
>>      |  |  +--rw frequency-traceable?        boolean
>>
>>      |  |  +--rw ptp-timescale?              boolean
>>
>>      |  |  +--rw time-source?                uint8
>>
>>      |  +--rw port-ds-list* [port-number]
>>
>>      |     +--rw clock-identity?                clock-identity-type
>>
>>      |     +--rw port-number                    uint16
>>
>>      |     +--rw port-state?                    port-state-enumeration
>>
>>      |     +--rw underlying-interface?          if:interface-ref
>>
>>      |     +--rw log-min-delay-req-interval?    int8
>>
>>      |     +--rw peer-mean-path-delay?          time-interval-type
>>
>>      |     +--rw log-announce-interval?         int8
>>
>>      |     +--rw announce-receipt-timeout?      uint8
>>
>>      |     +--rw log-sync-interval?             int8
>>
>>      |     +--rw delay-mechanism?               delay-mechanism-enumeration
>>
>>      |     +--rw log-min-pdelay-req-interval?   int8
>>
>>      |     +--rw version-number?                uint8
>>
>>      +--rw transparent-clock-default-ds
>>
>>      |  +--rw clock-identity?    clock-identity-type
>>
>>      |  +--rw number-ports?      uint16
>>
>>      |  +--rw delay-mechanism?   delay-mechanism-enumeration
>>
>>      |  +--rw primary-domain?    uint8
>>
>>      +--rw transparent-clock-port-ds-list* [port-number]
>>
>>         +--rw clock-identity?                clock-identity-type
>>
>>         +--rw port-number                    uint16
>>
>>         +--rw log-min-pdelay-req-interval?   int8
>>
>>         +--rw faulty-flag?                   boolean
>>
>>         +--rw peer-mean-path-delay?          time-interval-type
>>
>>
>>
>> In contrast to the original 1588 YANG tree diagram:
>>
>>     module: ietf-ptp-dataset
>>
>>         +--rw instance-list* [instance-number]
>>
>>         |  +--rw instance-number      uint16
>>
>>         |  +--rw default-ds
>>
>>         |  |  +--rw two-step-flag?    boolean
>>
>>         |  |  +--rw clock-identity?   clock-identity-type
>>
>>         |  |  +--rw number-ports?     uint16
>>
>>         |  |  +--rw clock-quality
>>
>>         |  |  |  +--rw clock-class?                  uint8
>>
>>         |  |  |  +--rw clock-accuracy?               uint8
>>
>>         |  |  |  +--rw offset-scaled-log-variance?   uint16
>>
>>         |  |  +--rw priority1?        uint8
>>
>>         |  |  +--rw priority2?        uint8
>>
>>         |  |  +--rw domain-number?    uint8
>>
>>         |  |  +--rw slave-only?       boolean
>>
>>         |  +--rw current-ds
>>
>>         |  |  +--rw steps-removed?       uint16
>>
>>         |  |  +--rw offset-from-master?  time-interval-type
>>
>>         |  |  +--rw mean-path-delay?     time-interval-type
>>
>>         |  +--rw parent-ds
>>
>>         |  |  +--rw parent-port-identity
>>
>>         |  |  |  +--rw clock-identity?   clock-identity-type
>>
>>         |  |  |  +--rw port-number?      uint16
>>
>>         |  |  +--rw parent-stats?        boolean
>>
>>         |  |  +--rw observed-parent-offset-scaled-log-variance? uint16
>>
>>         |  |  +--rw observed-parent-clock-phase-change-rate?    int32
>>
>>         |  |  +--rw grandmaster-identity?                       binary
>>
>>         |  |  +--rw grandmaster-clock-quality
>>
>>         |  |  |  +--rw clock-class?                  uint8
>>
>>         |  |  |  +--rw clock-accuracy?               uint8
>>
>>         |  |  |  +--rw offset-scaled-log-variance?   uint16
>>
>>         |  |  +--rw grandmaster-priority1?           uint8
>>
>>         |  |  +--rw grandmaster-priority2?           uint8
>>
>>         |  +--rw time-properties-ds
>>
>>         |  |  +--rw current-utc-offset-valid?   boolean
>>
>>         |  |  +--rw current-utc-offset?         int16
>>
>>         |  |  +--rw leap59?                     boolean
>>
>>         |  |  +--rw leap61?                     boolean
>>
>>         |  |  +--rw time-traceable?             boolean
>>
>>         |  |  +--rw frequency-traceable?        boolean
>>
>>         |  |  +--rw ptp-timescale?              boolean
>>
>>         |  |  +--rw time-source?                uint8
>>
>>         |  +--rw port-ds-list* [port-number]
>>
>>         |     +--rw port-number        -> ../port-identity/port-number
>>
>>         |     +--rw port-identity
>>
>>         |     |  +--rw clock-identity?   clock-identity-type
>>
>>         |     |  +--rw port-number?      uint16
>>
>>         |     +--rw port-state?          port-state-enumeration
>>
>>         |     +--rw underlying-interface? if:interface-ref
>>
>>         |     +--rw log-min-delay-req-interval?    int8
>>
>>         |     +--rw peer-mean-path-delay?          time-interval-type
>>
>>         |     +--rw log-announce-interval?         int8
>>
>>         |     +--rw announce-receipt-timeout?      uint8
>>
>>         |     +--rw log-sync-interval?             int8
>>
>>         |     +--rw delay-mechanism?     delay-mechanism-enumeration
>>
>>         |     +--rw log-min-pdelay-req-interval?   int8
>>
>>         |     +--rw version-number?                uint8
>>
>>         +--rw transparent-clock-default-ds
>>
>>         |  +--rw clock-identity?    clock-identity-type
>>
>>         |  +--rw number-ports?      uint16
>>
>>         |  +--rw delay-mechanism?   delay-mechanism-enumeration
>>
>>         |  +--rw primary-domain?    uint8
>>
>>         +--rw transparent-clock-port-ds-list* [port-number]
>>
>>            +--rw port-number           -> ../port-identity/port-number
>>
>>            +--rw port-identity
>>
>>            |  +--rw clock-identity?   clock-identity-type
>>
>>            |  +--rw port-number?      uint16
>>
>>            +--rw log-min-pdelay-req-interval?   int8
>>
>>            +--rw faulty-flag?                   boolean
>>
>>            +--rw peer-mean-path-delay?         time-interval-type
>>
>>
>>
>> I agree, assignment and comparison can still be done on clock-identity
>> and port-number directly (without a portIdentity construct) . But
>> people who are familiar with 1588-2008 may question where portIdentity
>> is gone.
>>
>>
>>
>> 3. I think leafref is a very general semantics thing in YANG language,
>> if any tools have problem with this feature, maybe we need to contact
>> with the tool’s developer to support it.
>>
>>
>>
>> Finally, more inputs from the WG are welcome.
>>
>>
>>
>> Thanks again,
>>
>> Yuanlong
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: TICTOC [mailto:tictoc-bounces@ietf.org] On Behalf Of Rodney
>> Cummings
>> Sent: Wednesday, September 27, 2017 1:24 AM
>> To: tictoc@ietf.org
>> Subject: Re: [TICTOC] draft-ietf-tictoc-1588v2-yang-05 - Concern over
>> port identifier
>>
>>
>>
>> Thanks Sean,
>>
>>
>>
>> Regarding your other comment on TLD... I agree.
>>
>>
>>
>> Regarding the comment below on port-identity, I agree that we need to
>> do it for practical reasons.
>>
>>
>>
>> In 1588-2008, there is a distinct dataset member for
>> portDS.portIdentity, which 5.3.5 specifies as using type PortIdentity:
>>
>>    struct PortIdentity {
>>
>>      ClockIdentity clockIdentity;
>>
>>      UInteger portNumber;
>>
>>    }
>>
>>
>>
>> If we interpret the 1588-2008 datasets as an information model, and
>> apply that as directly as possible to a YANG data model,
>> portDS.portIdentity is a container, which is what we have so far. That
>> introduces a challenge, because we want to use
>> portDS.portIdentity.portNumber as the key to the list of portDS's. We
>> solved that challenge with a leafref, but I'd agree that is ugly.
>>
>>
>>
>> Your proposal changes portDS.portIdentity from a container to a
>> grouping, so that it portDS.portIdentity.portNumber can be used as the
>> key without a leafref.
>>
>>
>>
>> The downside is that if/when a YANG management client tries to "get"
>> portDS.portIdentity, it doesn't work... there is no portIdentity to
>> get.
>>
>>
>>
>> Personally, I think that downside is worth it. One can argue that your
>> proposal still conforms to the 1588-2008 information model for
>> management, in that portDS.portIdentity still "exists" in a manner
>> that makes sense for YANG.
>>
>>
>>
>> Rodney
>>
>>
>>
>>
>>
>>
>>
>> From: TICTOC [mailto:tictoc-bounces@ietf.org] On Behalf Of Sean Condon
>>
>> Sent: Tuesday, September 26, 2017 10:38 AM
>>
>> To: tictoc@ietf.org
>>
>> Subject: [TICTOC] draft-ietf-tictoc-1588v2-yang-05 - Concern over port
>> identifier
>>
>>
>>
>> With reference to "YANG Data Model for IEEE 1588v2"
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_ht
>> ml_draft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D05&d=DwMFAw&c=I_0YwoKy7z5LM
>> TVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnb
>> oKbZ8k&m=jKHczVNLN-KuV2HRZkbEZY1SzlCD_AztkaWSccrqBI8&s=msh7A7_OgHZ1l65
>> Dn6_LhiDIXkXpFeiLGmKbKxsqXWw&e=
>>
>>
>>
>> I have a concern about the structure of the YANG, and how the lists
>> port-ds-list and transparent-clock-port-ds-list are indexed with a
>> leaf which is a leafref.
>>
>>
>>
>> The structure seems unnecessarily complex - port-number is represented
>> as a leaf directly beneath the list (to be used as key) and again
>> under the port-identity container. It is structured in a way that I
>> believe would make it difficult to work with some YANG tools in the
>> market.
>>
>>
>>
>> The purpose of port-identity container is not clear from the document
>> - it would achieve the same purpose if it was left out of
>> port-ds-entry and transparent-clock-port-ds-entry and instead the
>> grouping port-identity-grouping included directly.
>>
>>
>>
>> See the attached files as original, a modified version and as a patch
>> file.
>>
>>
>>
>> Sean Condon
>>
>> =======================
>>
>> Sean Condon
>>
>> System & Software Architect
>>
>> Frequency & Timing Division
>>
>> Microsemi Inc.
>>
>> mailto:sean.condon@microsemi.com
>>
>>
>>
>> _______________________________________________
>>
>> TICTOC mailing list
>>
>> TICTOC@ietf.org
>>
>> https://www.ietf.org/mailman/listinfo/tictoc
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Fri Sep 29 03:46:06 2017
Return-Path: 
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 A0783126C7A; Fri, 29 Sep 2017 03:46:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 i2Y9MYZdJNC7; Fri, 29 Sep 2017 03:46:01 -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 B62A8132076; Fri, 29 Sep 2017 03:46:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9052; q=dns/txt; s=iport; t=1506681961; x=1507891561; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=vFQvXd4NcNd1EJwj8MJO0sBziszLOt0I/cSPtD6jtIU=; b=bWreyUTJrQNS9bJF5Fp6Pigx/YcP95rcvFajnooTsup5nSNrk0artX5s 0ByLHe/u7noSvEn1GG3Jd6ShH6GOvxlDC2mDMh/IpHE7DvJ+gYD9HGybV x+nuzVAGqSuT7dXV/IIuy6rPUr2dJPKPpWMer6Qh7A4zNHntSObCoM33J s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CVAQAEI85Z/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm+CP4QfixOQQSKQbYQ9gxMKhTsChG0VAQIBAQEBAQEBayiFGQE?= =?us-ascii?q?FIwpcCRoqAgJXBgEMCAEBii2JSp1mgicnix4BAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEdgy2DU4FqKwuLCYJgBaEsgW2Sd4IUiUgkhweNdYdZgTk1IoEOMiEIHRWGGIF?= =?us-ascii?q?PP4hwAQEB?=
X-IronPort-AV: E=Sophos;i="5.42,452,1500940800";  d="scan'208,217";a="657908349"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Sep 2017 10:45:56 +0000
Received: from [10.63.23.161] (dhcp-ensft1-uk-vla370-10-63-23-161.cisco.com [10.63.23.161]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v8TAjulp025374; Fri, 29 Sep 2017 10:45:56 GMT
To: wangzitao , Mahesh Jethanandani , netconf , "netmod@ietf.org" 
References: 
From: Robert Wilton 
Message-ID: <598c104e-4e7b-44bf-7328-0a7f6c05bafe@cisco.com>
Date: Fri, 29 Sep 2017 11:45:56 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------C23AC0AA0291209F29A1A142"
Content-Language: en-US
Archived-At: 
Subject: [netmod] Config true/false Read/Write vs Read Only [was Re: [Netconf] WG adoption of NETCONF NDMA draft]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Sep 2017 10:46:04 -0000

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

[Cross posting to Netmod WG]

Hi Michael,

On 26/09/2017 03:27, wangzitao wrote:
>
> Hi WG,
>
> I support adoption of this work. And I have some comments:
>
> ………………………………………………………………………………………………………………………………………………………………………..
>
>          container where {
>
>            description
>
>              "Filter content with the specified criteria.  All given
>
>               criteria are logically AND:ed.";
>
>            leaf config {
>
>              type boolean;
>
>              description
>
>                "Filter for nodes with the given value for their
>
>                 'config' property.";
>
>            }
>
> : Here defined config truth/false as a filter’s criteria. 
> According to NMDA revised datastore, there are four type (ct = config 
> true; cf = config false
>
>        rw = read-write; ro = read-only). Why not define the “rw†and 
> “ro†as other criteria?
The ct/cf and rw/ro are reporting two different things are 2 different 
things:

A YANG schema node can be labelled as config true, or config false.
Some YANG datastores can only be read by a client (e.g.  and 
).
Other YANG datastores can be both read and also written by the client 
(e.g. , , ).

Do you think that the NMDA draft is sufficiently clear on this point, or 
does this need to be clarified in some way?

Thanks,
Rob


--------------C23AC0AA0291209F29A1A142
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    [Cross posting to Netmod WG]

      

      Hi Michael,

    

    
On 26/09/2017 03:27, wangzitao wrote:

    

    

      
      
      
      

        
Hi
            WG,

        
I
            support adoption of this work. And I have some comments:

        
 

        
………………………………………………………………………………………………………………………………………………………………………..

        
         container where {

        
           description

        
             "Filter content with the
            specified criteria.  All given

        
              criteria are logically
            AND:ed.";

        
 

        
           leaf config {

        
             type boolean;

        
             description

        
               "Filter for nodes with
            the given value for their

        
                'config' property.";

        
           }

        
<Michael>:
          Here
            defined config truth/false as a filter’s criteria. According
            to NMDA revised datastore, there are four type (ct = config
            true; cf = config false

        
       rw = read-write; ro = read-only). Why not define the “rw†and “ro†as other criteria?

      

    

    The ct/cf and rw/ro are reporting two different
      things are 2 different things:

      

      A YANG schema node can be labelled as config true, or config
      false.

      Some YANG datastores can only be read by a client (e.g. <intended>
      and <operational>).

      Other YANG datastores can be both read and also written by the
      client (e.g. <running>, <startup>, <candidate>).

       

      Do you think that the NMDA draft is sufficiently clear on this
      point, or does this need to be clarified in some way?

      

      Thanks,

      Rob

    

  


--------------C23AC0AA0291209F29A1A142--


From nobody Fri Sep 29 05:58:03 2017
Return-Path: 
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 4A71713452F for ; Fri, 29 Sep 2017 05:58:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.695
X-Spam-Level: 
X-Spam-Status: No, score=-4.695 tagged_above=-999 required=5 tests=[BASE64_LENGTH_79_INF=1.502, BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, 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 OQYpn6uy4vXR for ; Fri, 29 Sep 2017 05:57:58 -0700 (PDT)
Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F15A134525 for ; Fri, 29 Sep 2017 05:57:57 -0700 (PDT)
Received: from epcas5p4.samsung.com (unknown [182.195.41.42]) by mailout1.samsung.com (KnoxPortal) with ESMTP id 20170929125755epoutp01efa766b78b5caad65042cf42a70aa209~o1nV1NOgI0808508085epoutp01w for ; Fri, 29 Sep 2017 12:57:55 +0000 (GMT)
Received: from epsmges5p1new.samsung.com (unknown [182.195.42.73]) by epcas5p3.samsung.com (KnoxPortal) with ESMTP id 20170929125754epcas5p3f9c3e10ee1bcd42172b88c49e740e39a~o1nVWTu4t2286822868epcas5p31; Fri, 29 Sep 2017 12:57:54 +0000 (GMT)
X-AuditID: b6c32a49-99fff7000000104d-4e-59ce43529384
Received: from epcas5p2.samsung.com ( [182.195.41.40]) by epsmges5p1new.samsung.com (Symantec Messaging Gateway) with SMTP id 34.F0.04173.2534EC95; Fri, 29 Sep 2017 21:57:54 +0900 (KST)
Mime-Version: 1.0
Reply-To: sk.srivastav@samsung.com
Sender: Sudhanshu Kumar Srivastav 
From: Sudhanshu Kumar Srivastav 
To: Robert Wilton , "netmod@ietf.org" 
CC: KARTHIKEYAN SUBRAMANIAM , "cpgs ." , Surendra Pal Sharma 
X-Priority: 3
X-Content-Kind-Code: NORMAL
In-Reply-To: <20170915142859epcms5p526b9d21b55ddd8f0eb13edfec62efcff@epcms5p5>
X-Drm-Type: N,general
X-EPLocale: en_US.EUC-KR
X-EPWebmail-Msg-Type: personal
X-Msg-Generator: Mail
X-Msg-Type: PERSONAL
X-Reply-Demand: N
X-Sender: =?utf-8?B?U2Ftc3VuZyBFbGVjdHJvbmljcxtTUkktQg==?= =?utf-8?B?YW5nYWxvcmUtQ1UbQ2hpZWYgRW5naW5lZXI=?=
X-Sender-IP: 107.110.12.116
X-Local-Sender: =?UTF-8?B?U3VkaGFuc2h1IEt1bWFyIFNyaXZhc3RhdhtTUkktQmFuZ2Fsb3JlLUNV?= =?UTF-8?B?G+yCvOyEseyghOyekBtDaGllZiBFbmdpbmVlcg==?=
X-Global-Sender: =?UTF-8?B?U3VkaGFuc2h1IEt1bWFyIFNyaXZhc3RhdhtTUkktQmFuZ2Fsb3JlLUNV?= =?UTF-8?B?G1NhbXN1bmcgRWxlY3Ryb25pY3MbQ2hpZWYgRW5naW5lZXI=?=
X-Sender-Code: =?UTF-8?B?QzEwGxtDMTBJRDAxSUQwMTA5MTU=?=
Message-ID: <20170929125754epcms5p130f941babd487e94f81407ee2139d6c1@epcms5p1>
Date: Fri, 29 Sep 2017 12:57:54 +0000
X-CMS-MailID: 20170929125754epcms5p130f941babd487e94f81407ee2139d6c1
Content-Type: multipart/related; boundary="=_NamoWEC-ud1bd2lido"
X-CPGSPASS: Y
X-MTR: 20170929125754epcms5p130f941babd487e94f81407ee2139d6c1
CMS-TYPE: 105P
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHKsWRmVeSWpSXmKPExsWy7bCmhm6Q87lIg8k3NC1eHtK0WDDpB7PF /IuNrBYnzvUxW/z8v4PdgdVjyu+NrB5Llvxk8ujbsooxgDmKyyYlNSezLLVI3y6BK+PJlEus BecXMlW8vf6RpYFx2lymLkZODgkBE4nPD5ezdzFycQgJ7GaU+LaghaWLkYODV0BQ4u8OYZAa YQEHicVPjzKD2EICShKNK3pZIOI2Eoe+H2MFsdkErCSe9J8Hs0UEvCRWn7nDAjKTWaCFUWLb p6tsEMt4JWa0P2WBsKUlti/fyghicwr4SUyc2cgKEReVuLn6LTuELSGxeuFzqF45iWlf1zDD 1Lw/Np8RwhaRaL13FiouKPHg526oeK5Ex/52Zphdf/8dYQQ5SEKgm1Hi1ZVbUM4URon9J59A bTCXuNzfC9bNK+ArsfzAOnAQsQioSmz98gDqIheJze0bweqZgcGyrWcvC8xnDRt/Q9XYSsw9 fACqhk+i9/cTJpiaHfNgbDWJs3cesE1gVJ6FCOxZSKZC2IoSU7ofskPYGhKtc+ZC2eIS+6+0 MWOqUZc4tWcJ8wJG9lWMkqkFxbnpqcWmBYZ5qeV6xYm5xaV56XrJ+bmbGMGpSstzB+Oscz6H GAU4GJV4eA0Uz0YKsSaWFVfmHmKU4GBWEuEVdToXKcSbklhZlVqUH19UmpNafIhRmoNFSZz3 2M7SSCGB9MSS1OzU1ILUIpgsEwenVAOj/Cbm/tA6QWaLB3llTq8fqDeXtqbGbYgouSZREPi8 3ZrDr0E85vaCaYeMS3PCmPltJ79a+fpG6J/az5zXnR/02RxM90lhj+NbOVnTvPIqd7iaulXr JJ+7Ou+nPDl0hv0Hz2IG71dTH6VcrPEKmrGlbWH83G0Jt7NX5rm+W/4ktUBHcb6OwQYlluKM REMt5qLiRAAkcqR9UQMAAA==
X-CMS-RootMailID: 20170913073034epcms5p3ba5e2a0c180d8cd9f4464d8e5921d106
X-RootMTR: 20170913073034epcms5p3ba5e2a0c180d8cd9f4464d8e5921d106
References: <20170915142859epcms5p526b9d21b55ddd8f0eb13edfec62efcff@epcms5p5>  <20170913073034epcms5p3ba5e2a0c180d8cd9f4464d8e5921d106@epcms5p3> 
Archived-At: 
Subject: [netmod] FW: RE: Re:  draft-srivastav-netmod-formulae-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Sep 2017 12:58:01 -0000

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

PEhUTUw+PEhFQUQ+DQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiIGh0
dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPFNUWUxFIGlkPW15c2luZ2xlX3N0eWxlIHR5cGU9dGV4
dC9jc3M+LnNlYXJjaC13b3JkIHsNCglCQUNLR1JPVU5ELUNPTE9SOiAjZmZlZTk0DQp9DQpQIHsN
CglNQVJHSU4tQk9UVE9NOiA1cHg7IEZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFs
LCBhcmlhbDsgTUFSR0lOLVRPUDogNXB4DQp9DQpURCB7DQoJTUFSR0lOLUJPVFRPTTogNXB4OyBG
T05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCwgYXJpYWw7IE1BUkdJTi1UT1A6IDVw
eA0KfQ0KTEkgew0KCU1BUkdJTi1CT1RUT006IDVweDsgRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZB
TUlMWTogQXJpYWwsIGFyaWFsOyBNQVJHSU4tVE9QOiA1cHgNCn0NCkJPRFkgew0KCUZPTlQtU0la
RTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsLCBhcmlhbA0KfQ0KPC9TVFlMRT4NCg0KPE1FVEEg
Y29udGVudD1JRT01IGh0dHAtZXF1aXY9WC1VQS1Db21wYXRpYmxlPg0KPE1FVEEgY29udGVudD1J
RT01IGh0dHAtZXF1aXY9WC1VQS1Db21wYXRpYmxlPg0KPE1FVEEgY29udGVudD1JRT01IGh0dHAt
ZXF1aXY9WC1VQS1Db21wYXRpYmxlPg0KPE1FVEEgY29udGVudD1JRT01IGh0dHAtZXF1aXY9WC1V
QS1Db21wYXRpYmxlPg0KPE1FVEEgY29udGVudD1JRT01IGh0dHAtZXF1aXY9WC1VQS1Db21wYXRp
YmxlPg0KPE1FVEEgY29udGVudD1JRT01IGh0dHAtZXF1aXY9WC1VQS1Db21wYXRpYmxlPg0KPFNU
WUxFIGlkPWtub3hfc3R5bGUgdHlwZT10ZXh0L2Nzcz5QIHsNCglNQVJHSU4tQk9UVE9NOiA1cHg7
IEZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsLCBhcmlhbDsgTUFSR0lOLVRPUDog
NXB4DQp9DQo8L1NUWUxFPg0KDQo8TUVUQSBjb250ZW50PUlFPTUgaHR0cC1lcXVpdj1YLVVBLUNv
bXBhdGlibGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250ZW50PSJNU0hUTUwgMTEuMDAuOTYw
MC4xODczOSI+DQo8U1RZTEUgaWQ9a25veF9zdHlsZSB0eXBlPXRleHQvY3NzPlAgew0KCU1BUkdJ
Ti1CT1RUT006IDVweDsgRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwsIGFyaWFs
OyBNQVJHSU4tVE9QOiA1cHgNCn0NCjwvU1RZTEU+DQoNCjxNRVRBIGNvbnRlbnQ9SUU9NSBodHRw
LWVxdWl2PVgtVUEtQ29tcGF0aWJsZT4NCjxTVFlMRSBpZD1rbm94X3N0eWxlIHR5cGU9dGV4dC9j
c3M+UCB7DQoJTUFSR0lOLUJPVFRPTTogNXB4OyBGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZ
OiBBcmlhbCwgYXJpYWw7IE1BUkdJTi1UT1A6IDVweA0KfQ0KPC9TVFlMRT4NCg0KPE1FVEEgY29u
dGVudD1JRT01IGh0dHAtZXF1aXY9WC1VQS1Db21wYXRpYmxlPjwvSEVBRD4NCjxCT0RZIGJnQ29s
b3I9I2ZmZmZmZiB0ZXh0PSMwMDAwMDA+DQo8UD5IaSBSb2JlcnQsPC9QPg0KPFA+Jm5ic3A7PC9Q
Pg0KPFA+UGxlYXNlIGZpbmQgcmVzcG9uc2UgaW5saW5lLjwvUD4NCjxQPiZuYnNwOzwvUD4NCjxQ
PjEpIEluIHBhcnRpY3VsYXIsIHJhdGhlciB0aGFuIG1vZGVsaW5nIHRoZSBleHByZXNzaW9uIGRp
cmVjdGx5IGluIFlBTkcgdXNpbmcgWUFORyBleHRlbnNpb25zLCB3aGljaCBlZmZlY3RpdmVseSBt
YWtlcyB0aGUgZXhwcmVzc2lvbiBsb29rIGxpa2UgcXVpdGUgYSB2ZXJib3NlIGFic3RyYWN0IHN5
bnRheCB0cmVlLCBJIHRoaW5rIHRoYXQgeW91IG1heSBiZSBiZXR0ZXIgb2ZmIGRlZmluaW5nIGEg
c2VwYXJhdGUgZXhwcmVzc2lvbiBsYW5ndWFnZSwgc2ltaWxhciB0byBob3cgWHBhdGggaXMgdXNl
ZCB0b2RheS4mbmJzcDsgUHJvYmFibHkgaXQgY291bGQgYmUgcmVsYXRlZCB0byBYcGF0aCwgcGVy
aGFwcyBpdCBjb3VsZCBiZSBhIHN1cGVyc2V0LjwvUD4NCjxQPjxTUEFOIHN0eWxlPSJDT0xPUjog
IzAwMDBmZiI+W3NyaXZhc3Rhdl0mbmJzcDsmbmJzcDsmbmJzcDsgVGhlcmUgaXMgc2xpZ2h0IGRp
ZmZlcmVuY2UgaW4mbmJzcDtzdWdnZXN0ZWQgaWRlYSZuYnNwO2FuZCB0aGF0Jm5ic3A7aXMmbmJz
cDsiPC9TUEFOPjxTVFJPTkc+PFNQQU4gc3R5bGU9IkNPTE9SOiAjMDAwMGZmIj5Nb2RlbCB0aGUg
Zm9ybXVsYSBhcyBzY2hlbWEsIG5vdCBhcyBEYXRhPC9TUEFOPjwvU1RST05HPjxTUEFOIHN0eWxl
PSJDT0xPUjogIzAwMDBmZiI+Ii4mbmJzcDs8L1NQQU4+PC9QPg0KPFA+Jm5ic3A7PC9QPg0KPFA+
MikgSSB0aGluayB0aGF0IHRoZXJlIGFyZSBzb21lIHF1ZXN0aW9ucyBhYm91dCBob3cgdGhlc2Ug
ZXhwcmVzc2lvbnMgd291bGQgZ2V0IHByb2dyYW1tZWQgaW50byB0aGUgZGV2aWNlLiZuYnNwOyBB
cmUgdGhleSBzdGF0aWNhbGx5IGluY2x1ZGVkIGFzIHBhcnQgb2YgdGhlIHNjaGVtYSBsb2FkZWQg
YnkgdGhlIE5FVENPTkYvUkVTVENPTkYgc2VydmVyPyZuYnNwOyBPciBhcmUgdGhleSBwcm9ncmFt
bWVkIGR5bmFtaWNhbGx5IHZpYSB0aGUgTkVUQ09ORi9SRVNUQ09ORiBjbGllbnQuJm5ic3A7IEZv
ciB0aGUgbGF0dGVyIGNhc2UgaXQgd291bGQgYmUgbmVjZXNzYXJ5IHRvIGVpdGhlciBkZWZpbmUg
bmV3IFJQQyBvcGVyYXRpb25zLCBvciBwZXJoYXBzIGJldHRlciBhIGNvbmZpZ3VyYXRpb24gYW5k
IG9wZXJhdGlvbmFsIFlBTkcgZGF0YSBtb2RlbCB0byBtYW5hZ2UgdGhlIGV4cHJlc3Npb25zLjwv
UD4NCjxQPjxTUEFOIHN0eWxlPSJDT0xPUjogIzAwMDBmZiI+W3NyaXZhc3Rhdl0mbmJzcDsmbmJz
cDtmb3JtdWxhcyBhcmUgZ2V0dGluZyBzdGF0aWNhbGx5IGluY2x1ZGVkIGF0IHNlcnZlciBhbmQg
bm90IHByb2dyYW1tZWQgZHluYW1pY2FsbHkuJm5ic3A7Jm5ic3A7VGhlIGJlbmVmaXQgb2YgdGhp
cyBpcyB3aGVuIGZvcm11bGEgY2hhbmdlcywgSnVzdCBzY2hlbWEgbmVlZCB0byBiZSBjaGFuZ2Vk
IGFuZCB1cGRhdGVkIGF0IHNlcnZlciBhbmQgbm8gY2hhbmdlIGluIHNlcnZlciBpcyByZXF1aXJl
ZC48L1NQQU4+PEJSPjwvUD4NCjxQPiZuYnNwOzwvUD4NCjxQPjMpIEkgdGhpbmsgdGhhdCBpdCB3
b3VsZCBhbHNvIG5lZWQgdG8gYmUgY29uc2lkZXJlZCB3aGV0aGVyIHRoZSBjb25zdHJ1Y3RlZCBl
eHByZXNzaW9uIHZhbHVlcyBhcmUgcmVwcmVzZW50ZWQgYXMgbmV3IG5vZGVzIGluIHRoZSBZQU5H
IHNjaGVtYSAod2hpY2ggd291bGQgcHJvYmFibHkgcHJldmVudCB0aGVtIGZyb20gYmUgY29uc3Ry
dWN0ZWQgZHluYW1pY2FsbHkpLCBvciBwZXJoYXBzIHRoZXkgc2hvdWxkIG1ha2UgdXNlIG9mIFlB
TkcgbWV0YWRhdGEgKFJGQyA3OTUyKSBpbnN0ZWFkIHNvIHRoYXQgdGhlIGJhc2UgdW5kZXJseWlu
ZyBzY2hlbWEgaXNuJ3QgY2hhbmdlZC48L1A+DQo8UD48U1BBTiBzdHlsZT0iQ09MT1I6ICMwMDAw
ZmYiPltzcml2YXN0YXZdJm5ic3A7IFlBTkcgbWV0YWRhdGEgKFJGQyA3OTUyKSBzaGFsbCBiZSB1
c2VkLjwvU1BBTj48L1A+DQo8UD48QlI+NCkgQW55IHNvbHV0aW9uIHNob3VsZCBwcm9iYWJseSBh
bHNvIGNvbnNpZGVyIGhvdyBpdCB3b3VsZCBpbnRlci1vcGVyYXRlIHdpdGggdGhlIHdvcmsgY3Vy
cmVudGx5IGJlaW5nIGRvaW5nIGluIE5FVENPTkYgb24gWUFORyBwdXNoIGFuZCByZWxhdGVkIHRl
Y2hub2xvZ2llcy48QlI+PFNQQU4gc3R5bGU9IkNPTE9SOiAjMDAwMGZmOyBCQUNLR1JPVU5ELUNP
TE9SOiAjZmZmZmZmIj5bc3JpdmFzdGF2XSZuYnNwOyBJIGRvbid0IGZvcmVzZWUgYW55IGludGVy
LW9wZXJhYmlsaXR5IHByb2JsZW0gd2l0aCBZQU5HIHB1c2ggdGVjaG5vbG9neS4gS2luZGx5IGxl
dCBtZSBrbm93IGlmIHlvdSBmb3Jlc2VlIGFueSBwcm9ibGVtLjwvU1BBTj48QlI+PC9QPg0KPFA+
NSkgVGhleSBtYXkgYmUgc2VjdXJpdHkgaW1wbGljYXRpb25zIG9mIGFsbG93aW5nIGEgY2xpZW50
IHRvIGV4ZWN1dGUgYXJiaXRyYXJpbHkgY29tcGxleCBleHByZXNzaW9ucyB3b3VsZCBtYXkgZGVn
cmFkZSB0aGUgcGVyZm9ybWFuY2Ugb2YgdGhlIHN5c3RlbSwgYWx0aG91Z2ggcGVyaGFwcyB0aGUg
bWVtb3J5IGFuZCBjcHUgYXZhaWxhYmxlIHRvIGV4ZWN1dGUgdGhlIGV4cHJlc3Npb25zIGNvdWxk
IGJlIGxpbWl0ZWQuPC9QPg0KPFA+PFNQQU4gc3R5bGU9IkNPTE9SOiAjMDAwMGZmIj5bc3JpdmFz
dGF2XSBNb2RlbGluZyBmb3JtdWxhIGFzIHNjaGVtYSBkb24ndCBwdXQgdGhpcyBzZWN1cml0eSBp
bXBsaWNhdGlvbnMsIGFzIGZvcm11bGEgaXMgbm90IGdldHRpbmcgcHJvZ3JhbW1lZCBkeW5hbWlj
YWxseS4gPC9TUEFOPjwvUD4NCjxQPiZuYnNwOzwvUD4NCjxQPiZuYnNwOzwvUD4NCjxQPktpbmRs
eSBsZXQgbWUga25vdyBob3cgY2FuIEkgcHJvY2VlZCBmdXJ0aGVyIHRvIHRoaXMgaWRlYSBmcm9t
IGNvbmNlcHR1YWxpemF0aW9uIHRvJm5ic3A7IHJlYWxpemF0aW9uIGluIElFVEYgZm9ydW0uPC9Q
Pg0KPFA+Jm5ic3A7PC9QPg0KPFA+UmVnYXJkczwvUD4NCjxQPlN1ZGhhbnNodTwvUD4NCjxQPiZu
YnNwOzwvUD4NCjxQPi0tLS0tLS0tLSA8Qj5PcmlnaW5hbCBNZXNzYWdlPC9CPiAtLS0tLS0tLS08
L1A+DQo8UD48Qj5TZW5kZXI8L0I+IDogU3VkaGFuc2h1IEt1bWFyIFNyaXZhc3RhdiZuYnNwOyZs
dDtzay5zcml2YXN0YXZAc2Ftc3VuZy5jb20mZ3Q7Jm5ic3A7Q2hpZWYgRW5naW5lZXIvU1JJLUJh
bmdhbG9yZS1DVS9TYW1zdW5nIEVsZWN0cm9uaWNzPC9QPg0KPFA+PEI+RGF0ZTwvQj4gOiAyMDE3
LTA5LTE1IDE5OjU4IChHTVQrNTozMCk8L1A+DQo8UD48Qj5UaXRsZTwvQj4gOiBSRTogUmU6IFtu
ZXRtb2RdIGRyYWZ0LXNyaXZhc3Rhdi1uZXRtb2QtZm9ybXVsYWUtMDA8L1A+DQo8UD48Qj5UbyA6
IDwvQj5udWxsJmx0O3J3aWx0b25AY2lzY28uY29tJmd0OywgbnVsbCZsdDtuZXRtb2RAaWV0Zi5v
cmcmZ3Q7PC9QPg0KPFA+PEI+Q0MgOiA8L0I+S0FSVEhJS0VZQU4gU1VCUkFNQU5JQU0mbHQ7a2Fy
dGhpa2V5YW4uc0BzYW1zdW5nLmNvbSZndDssIGNwZ3MgLiZsdDtjcGdzQHNhbXN1bmcuY29tJmd0
OywgU3VyZW5kcmEgUGFsIFNoYXJtYSZsdDtzLnAuc2hhcm1hQHNhbXN1bmcuY29tJmd0OzwvUD4N
CjxQPiZuYnNwOzwvUD4NCjxQPjwvUD4NCjxQPkRlYXImbmJzcDsgUm9iZXJ0LDwvUD4NCjxQPiZu
YnNwOzwvUD4NCjxQPiZuYnNwOyZuYnNwOyBUaGFua3MgYSBsb3QgZm9yIHlvdXIgZmVlZGJhY2su
IEl0IGdhdmUgbWUmbmJzcDtvdGhlciBrZXkgYXJlYXMgdG8gYmUgY29uc2lkZXJlZCB3aGljaCBj
YW4gYmUmbmJzcDtpbXBhY3RlZCBkdWUgdG8gdGhlIHN1Z2dlc3RlZCBpZGVhLjwvUD4NCjxQPiZu
YnNwOzwvUD4NCjxQPiZuYnNwOyZuYnNwOyBXaXRoIHJlc3BlY3QgdG8mbmJzcDtmaXJzdCBmZWVk
YmFjaywgSSB0aGluayB0aGVyZSBpcyBzbGlnaHQgZGlmZmVyZW5jZSBpbiZuYnNwO3N1Z2dlc3Rl
ZCBpZGVhJm5ic3A7YW5kIHRoYXQmbmJzcDtpcyZuYnNwOyI8U1RST05HPk1vZGVsIHRoZSBmb3Jt
dWxhIGFzIHNjaGVtYSwgbm90IGFzIERhdGE8L1NUUk9ORz4iLiZuYnNwOyZuYnNwO1NvIGl0J3Mg
Z2V0dGluZyBzdGF0aWNhbGx5IGluY2x1ZGVkIGF0IHNlcnZlciBhbmQgbm90IHByb2dyYW1tZWQg
ZHluYW1pY2FsbHkuPC9QPg0KPFA+Jm5ic3A7Jm5ic3A7IEFzIEkgdGhpbmsgPFNUUk9ORz4iTW9k
ZWxpbmcgZm9ybXVsYSI8L1NUUk9ORz4gYXMgRGF0YSBtYXkgaGF2ZSBzZWN1cml0eSBpbXBsaWNh
dGlvbnMuJm5ic3A7IDwvUD4NCjxQPiZuYnNwOzwvUD4NCjxQPiZuYnNwOyZuYnNwOyZuYnNwO0km
bmJzcDthbSBnb2luZyB0aHJvdWdoIHRoZSZuYnNwO2ZlZWRiYWNrcyBwcm92aWRlZCBpbiBkZXRh
aWxzLCBJIHdpbGwmbmJzcDtjaGVjayBhbmQgY29tZSBiYWNrIHRvIHRoaXMuPC9QPg0KPFA+Jm5i
c3A7PC9QPg0KPFA+UmVnYXJkczwvUD4NCjxQPlN1ZGhhbnNodTwvUD4NCjxQPiZuYnNwOzwvUD4N
CjxQPi0tLS0tLS0tLSA8Qj5PcmlnaW5hbCBNZXNzYWdlPC9CPiAtLS0tLS0tLS08L1A+DQo8UD48
Qj5TZW5kZXI8L0I+IDogUm9iZXJ0IFdpbHRvbiZuYnNwOyZsdDtyd2lsdG9uQGNpc2NvLmNvbSZn
dDs8L1A+DQo8UD48Qj5EYXRlPC9CPiA6IDIwMTctMDktMTMgMTU6MTEgKEdNVCs1OjMwKTwvUD4N
CjxQPjxCPlRpdGxlPC9CPiA6IFJlOiBbbmV0bW9kXSBkcmFmdC1zcml2YXN0YXYtbmV0bW9kLWZv
cm11bGFlLTAwPC9QPg0KPFA+PEI+VG8gOiA8L0I+U3VkaGFuc2h1IEt1bWFyIFNyaXZhc3RhdiZs
dDtzay5zcml2YXN0YXZAc2Ftc3VuZy5jb20mZ3Q7LCBudWxsJmx0O25ldG1vZEBpZXRmLm9yZyZn
dDs8L1A+DQo8UD48Qj5DQyA6IDwvQj5LQVJUSElLRVlBTiBTVUJSQU1BTklBTSZsdDtrYXJ0aGlr
ZXlhbi5zQHNhbXN1bmcuY29tJmd0OywgY3BncyAuJmx0O2NwZ3NAc2Ftc3VuZy5jb20mZ3Q7PC9Q
Pg0KPFA+Jm5ic3A7PC9QPg0KPFA+SGkgU3VkaGFuc2h1LDwvUD4NCjxQPjxCUj48L1A+DQo8UD5U
aGFua3MgZm9yIHBvc3RpbmcgdGhpcy48QlI+PC9QPg0KPFA+PEJSPjwvUD4NCjxQPlRoZSBwcmVt
aXNlIG9mIHdoYXQgeW91IGFyZSB0cnlpbmcgdG8gYWNoaWV2ZSBoZXJlIGlzIGludGVyZXN0aW5n
LiZuYnNwOyBNeSBpbnRlcnByZXRhdGlvbiBpcyB0aGF0IHlvdXIgaWRlYSBpcyB0byBhbGxvdyBh
IE5FVENPTkYvUkVTVENPTkYgc2VydmVyL2RldmljZSB0byB0YWtlIGV4aXN0aW5nIGRhdGEgaW4g
dGhlIG9wZXJhdGlvbmFsIHN0YXRlIGRhdGEgdHJlZSBhbmQgdG8gY29uc3RydWN0IG5ldyBkZXJp
dmVkIGRhdGEgKG9yIHBlcmhhcHMganVzdCBtZXRhZGF0YSkgYnkgZXhlY3V0aW5nIGEgY2xpZW50
IGRlZmluZWQgYWxnb3JpdGhtIHRoYXQgaXMgZGVzY3JpYmVkIHZpYSBleHRlbnNpb25zIHN0YXRl
bWVudHMgdG8gWUFORy48L1A+DQo8UD48QlI+PC9QPg0KPFA+VGhpcyBicm9hZGx5IHNlZW1zIGEg
cmVhc29uYWJsZSBpZGVhIHRvIG1lLCBidXQgSSdtIG5vdCBzdXJlIHRoYXQgSSB3b3VsZCBpbXBs
ZW1lbnQgaXQgaW4gcXVpdGUgdGhlIHNhbWUgd2F5LCBhbmQgSSd2ZSBwdXQgZm9yd2FyZCBzb21l
IG90aGVyIHBvaW50cyBvciBpc3N1ZXMgdGhhdCB5b3UgbWF5IHdhbnQgdG8gY29uc2lkZXIuPEJS
PjwvUD4NCjxQPjxCUj48L1A+DQo8UD4xKSBJbiBwYXJ0aWN1bGFyLCByYXRoZXIgdGhhbiBtb2Rl
bGluZyB0aGUgZXhwcmVzc2lvbiBkaXJlY3RseSBpbiBZQU5HIHVzaW5nIFlBTkcgZXh0ZW5zaW9u
cywgd2hpY2ggZWZmZWN0aXZlbHkgbWFrZXMgdGhlIGV4cHJlc3Npb24gbG9vayBsaWtlIHF1aXRl
IGEgdmVyYm9zZSBhYnN0cmFjdCBzeW50YXggdHJlZSwgSSB0aGluayB0aGF0IHlvdSBtYXkgYmUg
YmV0dGVyIG9mZiBkZWZpbmluZyBhIHNlcGFyYXRlIGV4cHJlc3Npb24gbGFuZ3VhZ2UsIHNpbWls
YXIgdG8gaG93IFhwYXRoIGlzIHVzZWQgdG9kYXkuJm5ic3A7IFByb2JhYmx5IGl0IGNvdWxkIGJl
IHJlbGF0ZWQgdG8gWHBhdGgsIHBlcmhhcHMgaXQgY291bGQgYmUgYSBzdXBlcnNldC48L1A+DQo8
UD48QlI+PC9QPg0KPFA+RS5nIC50byB0YWtlIHlvdXIgZXhhbXBsZSBpbiAzLjEwLCBJIHRoaW5r
IHRoYXQgaXQgd291bGQgYmUgYmV0dGVyIGlmIHRoZSBleHByZXNzaW9uIHdhcyB3cml0dGVuIG1v
cmUgbGlrZSBhIG5vcm1hbCBtYXRoZW1hdGljYWwgZXhwcmVzc2lvbi4mbmJzcDsgRS5nLiBJIHRo
aW5rIHRoYXQgdGhlIGZvbGxvd2luZyB3b3VsZCBiZSBlYXNpZXIgdG8gcmVhZC91bmRlcnN0YW5k
LiZuYnNwOyBPYnZpb3VzbHkgYW4gaW1wbGVtZW50YXRpb24gbmVlZHMgdG8gcGFyc2UgdGhlIGV4
cHJlc3Npb24sIGJ1dCB0aGF0IHNob3VsZG4ndCBiZSB0b28gZGlmZmljdWx0LCBhbmQgdGhleSB3
b3VsZCBuZWVkIHRvIHdyaXRlIGNvZGUgdG8gaW50ZXJwcmV0IHRoZSBleHByZXNzaW9uIGFueXdh
eS4gPEJSPjwvUD48UFJFIHN0eWxlPSJXT1JELVdSQVA6IGJyZWFrLXdvcmQ7IFdISVRFLVNQQUNF
OiBwcmUtd3JhcDsgV09SRC1TUEFDSU5HOiAwcHg7IFRFWFQtVFJBTlNGT1JNOiBub25lOyBGT05U
LVdFSUdIVDogbm9ybWFsOyBDT0xPUjogcmdiKDAsMCwwKTsgRk9OVC1TVFlMRTogbm9ybWFsOyBP
UlBIQU5TOiAyOyBXSURPV1M6IDI7IExFVFRFUi1TUEFDSU5HOiBub3JtYWw7IFRFWFQtSU5ERU5U
OiAwcHg7IGZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6
IG5vcm1hbDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb24t
c3R5bGU6IGluaXRpYWw7IHRleHQtZGVjb3JhdGlvbi1jb2xvcjogaW5pdGlhbCI+ICAgY29udGFp
bmVyIGZvcm11bGEgew0KICAgICAgbGVhZiBhIHsNCiAgICAgICAgIHR5cGUgaW50MzI7DQogICAg
ICB9DQogICAgICAuLi4gbGVhdmVzIGIgdG8gZCBkZWZpbmVkIHNpbWlsYXJseSAuLi4NCiAgICAg
IGxlYWYgZSB7DQogICAgICAgICB0eXBlIGludDMyOw0KICAgICAgfQ0KICAgICAmbmJzcDttdDpt
YXRoIHggew0KICAgICAgICBsZWFmIHggew0KICAgICAgICAgIHR5cGUgaW50MzI7DQogICAgICAg
ICAgbXQ6ZXhwcmVzc2lvbiIoKGErYikgLSAoYy1kKS8oZSoxMDApKSI7DQogICAgICAgIH0NCiAg
ICAgIH0NCjwvUFJFPg0KPFA+MikgSSB0aGluayB0aGF0IHRoZXJlIGFyZSBzb21lIHF1ZXN0aW9u
cyBhYm91dCBob3cgdGhlc2UgZXhwcmVzc2lvbnMgd291bGQgZ2V0IHByb2dyYW1tZWQgaW50byB0
aGUgZGV2aWNlLiZuYnNwOyBBcmUgdGhleSBzdGF0aWNhbGx5IGluY2x1ZGVkIGFzIHBhcnQgb2Yg
dGhlIHNjaGVtYSBsb2FkZWQgYnkgdGhlIE5FVENPTkYvUkVTVENPTkYgc2VydmVyPyZuYnNwOyBP
ciBhcmUgdGhleSBwcm9ncmFtbWVkIGR5bmFtaWNhbGx5IHZpYSB0aGUgTkVUQ09ORi9SRVNUQ09O
RiBjbGllbnQuJm5ic3A7IEZvciB0aGUgbGF0dGVyIGNhc2UgaXQgd291bGQgYmUgbmVjZXNzYXJ5
IHRvIGVpdGhlciBkZWZpbmUgbmV3IFJQQyBvcGVyYXRpb25zLCBvciBwZXJoYXBzIGJldHRlciBh
IGNvbmZpZ3VyYXRpb24gYW5kIG9wZXJhdGlvbmFsIFlBTkcgZGF0YSBtb2RlbCB0byBtYW5hZ2Ug
dGhlIGV4cHJlc3Npb25zLjwvUD4NCjxQPjxCUj48L1A+DQo8UD4zKSBJIHRoaW5rIHRoYXQgaXQg
d291bGQgYWxzbyBuZWVkIHRvIGJlIGNvbnNpZGVyZWQgd2hldGhlciB0aGUgY29uc3RydWN0ZWQg
ZXhwcmVzc2lvbiB2YWx1ZXMgYXJlIHJlcHJlc2VudGVkIGFzIG5ldyBub2RlcyBpbiB0aGUgWUFO
RyBzY2hlbWEgKHdoaWNoIHdvdWxkIHByb2JhYmx5IHByZXZlbnQgdGhlbSBmcm9tIGJlIGNvbnN0
cnVjdGVkIGR5bmFtaWNhbGx5KSwgb3IgcGVyaGFwcyB0aGV5IHNob3VsZCBtYWtlIHVzZSBvZiBZ
QU5HIG1ldGFkYXRhIChSRkMgNzk1MikgaW5zdGVhZCBzbyB0aGF0IHRoZSBiYXNlIHVuZGVybHlp
bmcgc2NoZW1hIGlzbid0IGNoYW5nZWQuPEJSPjwvUD4NCjxQPjxCUj48L1A+DQo8UD40KSBBbnkg
c29sdXRpb24gc2hvdWxkIHByb2JhYmx5IGFsc28gY29uc2lkZXIgaG93IGl0IHdvdWxkIGludGVy
LW9wZXJhdGUgd2l0aCB0aGUgd29yayBjdXJyZW50bHkgYmVpbmcgZG9pbmcgaW4gTkVUQ09ORiBv
biBZQU5HIHB1c2ggYW5kIHJlbGF0ZWQgdGVjaG5vbG9naWVzLjxCUj48L1A+DQo8UD48QlI+PC9Q
Pg0KPFA+NSkgVGhleSBtYXkgYmUgc2VjdXJpdHkgaW1wbGljYXRpb25zIG9mIGFsbG93aW5nIGEg
Y2xpZW50IHRvIGV4ZWN1dGUgYXJiaXRyYXJpbHkgY29tcGxleCBleHByZXNzaW9ucyB3b3VsZCBt
YXkgZGVncmFkZSB0aGUgcGVyZm9ybWFuY2Ugb2YgdGhlIHN5c3RlbSwgYWx0aG91Z2ggcGVyaGFw
cyB0aGUgbWVtb3J5IGFuZCBjcHUgYXZhaWxhYmxlIHRvIGV4ZWN1dGUgdGhlIGV4cHJlc3Npb25z
IGNvdWxkIGJlIGxpbWl0ZWQuPC9QPg0KPFA+PEJSPjwvUD4NCjxQPkkgaG9wZSB0aGUgYnJpZWYg
ZmVlZGJhY2sgaXMgdXNlZnVsLiZuYnNwOyBJJ20gbm90IHN1cmUgaG93IGZhbWlsaWFyIHlvdSBh
cmUgd2l0aCB0aGUgSUVURiBwcm9jZXNzLCBidXQgcGxlYXNlIG5vdGUgdGhhdCB0aGVzZSBjb21t
ZW50cyBqdXN0IHJlcHJlc2VudCBteSBwZXJzb25hbCBvcGluaW9uIGFuZCBkbyBub3QgbmVjZXNz
YXJpbHkgcmVmbGVjdCB0aG9zZSBvZiB0aGUgd2lkZXIgcGFydGljaXBhbnRzIGluIHRoZSBORVRN
T0QgV0cuIE90aGVyIG9waW5pb25zIG1heSwgYW5kIGluIG15IGV4cGVyaWVuY2UgcHJvYmFibHkg
d2lsbCwgZGlmZmVyIDotKTxCUj48L1A+DQo8UD48QlI+PC9QPg0KPFA+VGhhbmtzLDxCUj5Sb2I8
L1A+DQo8UD48QlI+PC9QPjxCUj4NCjxESVYgY2xhc3M9bW96LWNpdGUtcHJlZml4Pk9uIDEzLzA5
LzIwMTcgMDg6MzAsIFN1ZGhhbnNodSBLdW1hciBTcml2YXN0YXYgd3JvdGU6PEJSPjwvRElWPg0K
PEJMT0NLUVVPVEUgY2l0ZT1taWQ6MjAxNzA5MTMwNzMwMzRlcGNtczVwM2JhNWUyYTBjMTgwZDhj
ZDlmNDQ2NGQ4ZTU5MjFkMTA2QGVwY21zNXAzIHR5cGU9ImNpdGUiPg0KPE1FVEEgY29udGVudD1J
RT01IGh0dHAtZXF1aXY9WC1VQS1Db21wYXRpYmxlPg0KPE1FVEEgY29udGVudD1JRT01IGh0dHAt
ZXF1aXY9WC1VQS1Db21wYXRpYmxlPg0KPFNUWUxFIGlkPWtub3hfc3R5bGUgdHlwZT10ZXh0L2Nz
cz5QIHsNCglNQVJHSU4tQk9UVE9NOiA1cHg7IEZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6
IEFyaWFsLCBhcmlhbDsgTUFSR0lOLVRPUDogNXB4DQp9DQo8L1NUWUxFPg0KDQo8TUVUQSBjb250
ZW50PUlFPTUgaHR0cC1lcXVpdj1YLVVBLUNvbXBhdGlibGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRP
UiBjb250ZW50PUFjdGl2ZVNxdWFyZT4NCjxQPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogQ291
cmllciI+RGVhciBORVRNT0QgVGVhbSw8L1NQQU4+PC9QPg0KPFA+PFNQQU4gc3R5bGU9IkZPTlQt
RkFNSUxZOiBDb3VyaWVyIj48L1NQQU4+Jm5ic3A7PC9QPg0KPFA+PFNQQU4gc3R5bGU9IkZPTlQt
RkFNSUxZOiBDb3VyaWVyIj4mbmJzcDsmbmJzcDtJIGhhdmUgc3VibWl0dGVkIGEmbmJzcDtkcmFm
dCZuYnNwO2ZvciZuYnNwO25ldyBZQU5HIG1vZHVsZSZuYnNwO3RoYXQgZGVmaW5lcyZuYnNwO25l
dyBZQU5HIGV4dGVuc2lvbiZuYnNwO3N0YXRlbWVudHMgYW5kIG1ldGhvZCB0byZuYnNwO21vZGVs
IHRoZSZuYnNwO2Zvcm11bGFlL0tQSSdzLjwvU1BBTj48L1A+DQo8UD48U1BBTiBzdHlsZT0iRk9O
VC1GQU1JTFk6IENvdXJpZXIiPiZuYnNwOyBSZXF1ZXN0IHlvdSZuYnNwO3RvIHBsZWFzZSBjaGVj
ayBhbmQgcHJvdmlkZSB5b3VyIGNvbW1lbnRzLjwvU1BBTj48L1A+DQo8UD48U1BBTiBzdHlsZT0i
Rk9OVC1GQU1JTFk6IENvdXJpZXIiPjwvU1BBTj4mbmJzcDs8L1A+DQo8UD48U1RST05HPjxTUEFO
IHN0eWxlPSJGT05ULUZBTUlMWTogQ291cmllciI+RHJhZnQgRGV0YWlsczo8L1NQQU4+PC9TVFJP
Tkc+PC9QPg0KPFA+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiBDb3VyaWVyIj5OYW1lOiBkcmFm
dC1zcml2YXN0YXYtbmV0bW9kLWZvcm11bGFlPEJSPlJldmlzaW9uOiAwMDxCUj5UaXRsZTogWUFO
RyBleHRlbnNpb24gU3RhdGVtZW50cyBmb3IgZm9ybXVsYWUgbW9kZWxpbmc8QlI+RG9jdW1lbnQg
ZGF0ZTogMjAxNy0wOS0xMjxCUj5Hcm91cDogSW5kaXZpZHVhbCBTdWJtaXNzaW9uPEJSPlBhZ2Vz
OiAyODxCUj5VUkw6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvU1BBTj48QSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y
Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc3JpdmFzdGF2LW5ldG1vZC1mb3JtdWxhZS0wMC50eHQi
IG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiBDb3VyaWVy
Ij5odHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc3JpdmFzdGF2LW5l
dG1vZC1mb3JtdWxhZS0wMC50eHQ8L1NQQU4+PC9BPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTog
Q291cmllciI+PEJSPlN0YXR1czombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgPC9TUEFOPjxBIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv
ZG9jL2RyYWZ0LXNyaXZhc3Rhdi1uZXRtb2QtZm9ybXVsYWUvIiBtb3otZG8tbm90LXNlbmQ9InRy
dWUiPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogQ291cmllciI+aHR0cHM6Ly9kYXRhdHJhY2tl
ci5pZXRmLm9yZy9kb2MvZHJhZnQtc3JpdmFzdGF2LW5ldG1vZC1mb3JtdWxhZS88L1NQQU4+PC9B
PjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogQ291cmllciI+PEJSPkh0bWxpemVkOiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L1NQQU4+PEEgaHJlZj0iaHR0cHM6Ly90b29s
cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNyaXZhc3Rhdi1uZXRtb2QtZm9ybXVsYWUtMDAiIG1vei1k
by1ub3Qtc2VuZD0idHJ1ZSI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiBDb3VyaWVyIj5odHRw
czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc3JpdmFzdGF2LW5ldG1vZC1mb3JtdWxhZS0w
MDwvU1BBTj48L0E+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiBDb3VyaWVyIj48QlI+SHRtbGl6
ZWQ6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvU1BBTj48QSBocmVmPSJo
dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXNyaXZhc3Rhdi1uZXRt
b2QtZm9ybXVsYWUtMDAiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+PFNQQU4gc3R5bGU9IkZPTlQt
RkFNSUxZOiBDb3VyaWVyIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2Ry
YWZ0LXNyaXZhc3Rhdi1uZXRtb2QtZm9ybXVsYWUtMDA8L1NQQU4+PC9BPjwvUD4NCjxQPjxTUEFO
IHN0eWxlPSJGT05ULUZBTUlMWTogQ291cmllciI+PC9TUEFOPiZuYnNwOzwvUD4NCjxQPjxTUEFO
IHN0eWxlPSJGT05ULUZBTUlMWTogQ291cmllciI+UmVnYXJkczwvU1BBTj48L1A+DQo8UD48U1BB
TiBzdHlsZT0iRk9OVC1GQU1JTFk6IENvdXJpZXIiPlN1ZGhhbnNodTwvU1BBTj48L1A+PEJSPg0K
PEZJRUxEU0VUIGNsYXNzPW1pbWVBdHRhY2htZW50SGVhZGVyPjwvRklFTERTRVQ+IDxCUj48UFJF
IHdyYXA9IiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
Cm5ldG1vZCBtYWlsaW5nIGxpc3QNCjxBIGNsYXNzPW1vei10eHQtbGluay1hYmJyZXZpYXRlZCBo
cmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8L0E+DQo8QSBjbGFz
cz1tb3otdHh0LWxpbmstZnJlZXRleHQgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9uZXRtb2QiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
bmV0bW9kPC9BPg0KPC9QUkU+PC9CTE9DS1FVT1RFPjxCUj4NCjx0YWJsZSBpZD1iYW5uZXJzaWdu
aW1nPjx0cj48dGQ+PGRpdiBpZD0iY2FmZS1ub3RlLWNvbnRlbnRzIiBzdHlsZT0ibWFyZ2luOjEw
cHg7Zm9udC1mYW1pbHk6QXJpYWw7Zm9udC1zaXplOjEwcHQ7Ij48cD4mbmJzcDs8L3A+PC9kaXY+
PC90ZD48L3RyPjwvdGFibGU+PHRhYmxlIGlkPWNvbmZpZGVudGlhbHNpZ25pbWc+PHRyPjx0ZD48
ZGl2IGlkPSJjYWZlLW5vdGUtY29udGVudHMiIHN0eWxlPSJtYXJnaW46MTBweDtmb250LWZhbWls
eTpBcmlhbDtmb250LXNpemU6MTBwdDsiPjxwPjxpbWcgdW5zZWxlY3RhYmxlPSJvbiIgZGF0YS1j
dWktaW1hZ2U9InRydWUiIHN0eWxlPSJkaXNwbGF5OiBpbmxpbmUtYmxvY2s7IGJvcmRlcjogMHB4
IHNvbGlkOyB3aWR0aDogNTIwcHg7IGhlaWdodDogMTQ0cHg7IiBzcmM9ImNpZDpjYWZlX2ltYWdl
XzBAcy1jb3JlLmNvLmtyIj48YnI+PC9wPjwvZGl2PjwvdGQ+PC90cj48L3RhYmxlPjwvQk9EWT48
L0hUTUw+PGltZyBzcmM9J2h0dHA6Ly9leHQuc2Ftc3VuZy5uZXQvbWFpbC9leHQvdjEvZXh0ZXJu
YWwvc3RhdHVzL3VwZGF0ZT91c2VyaWQ9c2suc3JpdmFzdGF2JmRvPWJXRnBiRWxFUFRJd01UY3dP
VEk1TVRJMU56VTBaWEJqYlhNMWNERXpNR1k1TkRGaVlXSmtORGczWlRrMFpqZ3hOREEzWldVeU1U
TTVaRFpqTVNaeVpXTnBjR2xsYm5SQlpHUnlaWE56UFc1bGRHMXZaRUJwWlhSbUxtOXlad19fJyBi
b3JkZXI9MCB3aWR0aD0wIGhlaWdodD0wIHN0eWxlPSdkaXNwbGF5Om5vbmUnPg==
--=_NamoWEC-ud1bd2lido
Content-Type: image/gif
Content-Transfer-Encoding: base64
Content-ID: 

R0lGODlhCAKQAIQAAAAAAP///8k6OspMTNRiYtt0dOSOjumiovLExPfZ2fvt7f/+/uvr69TU1Lm5uYyMjG9vb0dHRzMzMyoqKgICAv///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH/C05FVFNDQVBFMi4wAwEBAAAh+QQBAAAVACwAAAAACAKQAAAI/wAZCBxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjxkDiBxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6tzJs6fPnzYFAh1KtKjRo0iTKl3KtGnJBVCjSp1KtarVq1ZVCnXKtavXr2DDih1rE6vZs2iramVAtq3bt3Djyp07Mq3du1lTbg3QwIFfvwwasJUpmK7WBikL41SMkjFLxyIDq+w7uCVkpJJZZo6MWKyDtpdpfl4qFQFWBQnwQk2ggCpqtXorQ4gwgUKECA0ijI6p23DKBw9S9jYJgffuk8NbJh8JPPEE3I+DL0/anKWDCCSvj6XAtUFwk9NLFv93yd3oeJFSB2BFUACtgakFTE9lDxvlXpHaRYZXftw3zvIv7TeSgMj1F0B1J+XHUnMEEoWgSgoGEOFXADL14EsVrpQhUBXaRd9Z6p314VRrlaRgBBBQMAFiDERgW2UBtEgBBdKlOAFbMkbAgAPf8Xhgbd+J1MBsNKaI3Y80xujiigGkmGSTMxbXAJDj2diZSM05GWSTDQzpYnFGIhmclxSM94BtE3z2AJBYormbjEzmyFZvayYJ3AOj4TlSbWCqiNgDKY425QQPoOinki+SBMGZcbqY5KIqOlDbZ1OWKaSKEWwpY5IM8Ildp2Vih+IEYiLKpJYiWZnqoYpGeWCd36X/mCJJwE3qYqxRtijkkUKyKWeTjHY5AaGbBgdBl0SeByVuEEzQp6VQzgolkyNVqmOpP6bZZIoMwLpsXVG1Z8ABAxCQmgIEDGCAuKkl8N4B6b5nwAAFuEuAAQ
 akBi+9CowoVYnZ8XrbgWAWrKiU3NHGAAQGMzxlqg8wQIGwVzowcQM0dirYxSsWSvCUO5JaqEArLtoidmt2SypzD4AsKUm6WbxxlxQ4IDHFMt98s8U2c4xzzcyh3HBxut08pXfAHTlx0N7duOaB10bm8MCAbmv1gChjxzBfCYvqNHbEZhpAmhJvuTXGwJ6c9sA1C+Szx4C6LLLTc6tMq44ap4z2yNJi/+n0xdyNrDGTVe/pAMYLG0y1jg6fnbBfE99cbc0WsyV4x4wHTjfM0kXs881Po+g2xRjvlt4CBbR3gLgHKJA66qbRN4BpAySQwOwIDKCA6wgoUDvqB/gbFcAjnfiZdktLTJJQFgcgtvJLo60tBd1WGWR+5elW+KIeCyQpW52Bnyb1Eoo6GrWvgswXzH4d2Vvg1uen/Xhpbg8c/bt1z1b0j9sPnMQhC5jzzoe0kjDoeNhJXoV6ox3mPe5V5XtYBFe2qOWxpXnk81gGE4gl6+nve+sbzopEeKUY8aV+33kg2lhWPpGUR3wO2Jq2eoUfyaGNgSgLjgMHKL/jcEdBMOzNDf8JOKAxEQxihZOOmqwXgA5FRT3xWYDsWrM62EmxPb9LzQLU86EotmtcwoMK8fAjMAQ2cUYzIom1HtjENroQWA87ExqvpzT98AiNGaNNxKLFoiWNj4zOw2P+jFWmEsbMfZ8JHB7xhMjqaG+RjnyTHvc3kv5BsnMVLJ757HihA7YQjws04xoHCMHrWAyNujnSg0ZZHuQBsjxynFHEJsnHQKLxOoIcCZxQ+MbhVKg52DNVmkBWoQgB6IHaac4oD2lHkvzwSLs0ZS9z2SuxxZJGD6LTIt2InidaUXZQoU8U6QOvKG7xilCJ4rwIQIDgtYcqY2xhM10pJJLM8IHQw9EPnVX/nOqUMJgD9GeMAtOsGHmHelsbIPm0M5wSKrNb5LNjD9so0B5GUqCR1CVBSUU+5WnvO38KDqCWpklSjo1HW4IgDrlpSDP
 ek5TATGVkdqTKLb20lRz8JJZAOtAhkSowZ2qRoExawoR+tJej+WVwgmnUz/BTgBICYIyQmcOxpZCHiHSmPJvqS6KqsXzcq2d1lAjB9XEzAKcbJxbD2R61LoA1qzvAObuIgNVR0Z31Ocl95ElKhi51ZS60XML6KSqRHmlYiAGh2ADpxpjdyHmA0iGNDivN0jFMbd1D350oO6D2NXOfc2KkHR9WOsXiiVSlG0kFPWpYHj42U82RGGAB6bG9/6XUk36V0GxXmsEHxrSJfyrO0gjlTMFCtkmFRa4bTbvayYqkfp/CXIzQJ8SaVQd+B1KqPFUItECVhHoAtOYmkxmc3mK1mZWUZ3V51M/ARfdKZLuO+jL1sJcx8LXlxQ9avenWAsh1XcBbwOoSQIDWjGuu74zPAd6DLrzCMzYmKmMLMeai4zTLWdSjTW0QQ2GSuki1w5otQHtzYdSiKWIhxo7FaJMpUM1murRR1v9SzL6JDmthIVbvZ0q84xw3KcS7oTBxO4wYEufYkSlt4LCA1snJitI2QOtsCy/MLTotFWXPWdqahmW2YXFLyNgZ1HO4WWKuTZLGnYoxjJ2VHTTB9v+qncoyra78xhU/Z6kb2jLCXFRkM54JUF7OsGdN+tw0HcnOLR7Wh9PMZuac+MfDStWkTFrmsd2IO2mNXXsIzM725C514iJAAcy1AHbS1XejxlcYFxDPlhzOJF0yUWV2BKOS9AUmt47Mq/FzpVwfyHK82nWCSqgVm/HFQNmBka+japIdXYnWsDYQ+oY9GWIXz9qwxna0KxPrbC+vhJux9ZuELWwJ/dPay04Qro9TOFs/29iN4bC29QpvIfXn3taGtr2zg21f0zo4aHlNVGxXGvksoF+tmQrCzdJq/8xkTWdCtsNf4qWJWxwoa5L4xXHSLf8IRDUgD7nIr8IyjZtk5Cj/T7lUFNA6lbs85BvPiV9iTnOdfBwvrLlLzl9ul52X5uBaDLnPdZ5woSNg6EM3i8Cn
 4vOlzyfoKXc6wxNTa1xXfSwmhxBQKHV1Wyu76waVSdbDrhcOg73sLbk5VN5zFnOmxe08b7vBvXkAuYq87iDHe8g/DXe4X+U9q3b7qg3QTpUD/p1oOYl3CC2TC+lETytZmIZosiGdBC6lBWJfSibUkspHGEKbfElxOK9XBpxO7nfxe9zzbveQ6x0vr1dN7MM196uEyCqqp0ruQX57u5zEk2RpEGNT4nmWFP8mxy/JcghEepw0f/gweWbaTb92egm4XHYnF6kLsM7UjKtc5yoA/7+s2P23ih9froNK+gcer3QSfuDrGoBc7YWvBBQg4flS3fzbf33ut4v/tyNqrfdW6bJ95HJ/b1Uu/lUa7CRXrjN+32cunLZg+kIvBGAa+zJ/8Scv9OIuByd+8mdFqyEv2pcAJfiACIgvtRN/C2Z918cv81IvDCZ+KViCwyMnkkIohtIoicIwL5IbO9YthERc0+JQdbJENVMp7bUiStgrSfIlRbgqfVNWOcRlUlgeqjJSQVYbTJIptqEfZ1JHwGSFxeI8NjInaqIiW9JAjoInreUjA/IqVrgsNMUlfFEcLqY1yAKFgfRiqmUbksKHjKIp1JeARyeBukNgJkgAqKM67/nxOlWELwsgiQp2f/AyiQbgOu1BagsmFe3UYFvUO1GRO62jO7mzO/FxYAR2Tnj3if7lO/0yO6XWOgt4gbczgIVXRSFYi0cXglFxgacoiZSoOvdXf/GhiLlziL1jirXjO7aDO+LyHqsoeG1FjK7TOsL4iJmYO8/YOhJogLeDAPSRjY0oYIhnNZc1NUKDjkQDAUJlMZ6TPjfyMiPzMo7WFyJzLcQSNig2S8ExTNSzJt6hI/SYOXP2RinTPHzjXgH0NPbUWmXSIuXljmJzeSdVOWdDKgqzNbpxNIhTUo7DUNyRSQg5jwyJIgxlRhxpPjkzMQupRpQTOdTjkRH/NVCn04mTWHdsJ1f9pWlb1C5QxB52Zy66g06SeIHsx1bnx
 IBr52CVKGDvoR51hwCMeEU4CYxVyR6rmJMrd3C6CBV1t5UHthpZ6YwJ+E36BztXWVdsB0YJRjvotDtSFJSj2FY+GUVZRJcfEiJe9IFyxUVYBJRoOTz8o1JmpEAwlTQyBRwgVGTfoVn0U0D2mJKTiRuPZTO5NTZAyDUHSVFXVV3HpZkXgiMalFgJZJqeKUE2s0OL1T9MBEg7xB22sZnpdV2ktCMp+UnAdl4D1BvKo1UW9Zo2SXcDUJzyF3s9iU63F5TmFB8hQh+K2HsfAk6l8U5T+ZalZkVSGTzGSS96/xcfuWOc8WGdA6h9rxMi1wmWrecvyzmYeKdgdqdg3emUcAmd6SJ+IohOydmebrWU6lQuhQeYS3lO/clqx2SYn4RHfYUiECdShHQstjQjg8RJdNZCMYNHMlVSjiKhXcVCnolU03RLTfYcOUVPrsSYvHJCUGZSljRHJTVKaeIszaNVtpkcuWmiLIlIHZpeFrVNM3WTdqcv2TeYblWUvgM75nSBRfkh98J24ZSVa1Wd6klXs1iU2/khu7OWWNov5Ml+qUGd6Slg6/lOy9gaR+pW71lX8ammq4FO2olOSEmgBidOd0k7ZqqX78SXdYWAeCegRoqnhKlPCEpPIUQpgAiIEP8EVCM0VB56VJXJm95zaHXYUCzamRbZRl1FqavEJDi6XByEojX0Ur7ZPzxVUi81G5lCG99VVirkWbwFSMzUm5/xmzzaSKX6o95EYK3hX6tIlUR6l3JVRU95O5ioidVXe7+zgL03l6lhLlQKL2y3nT8JlbcTi7SjL1HZGoX3pOkUpX2qrQOoO864gMLqk2m6iuGoq8BDpX5KRXSplMlJrnbppnraiaAooPI6mGIkXoOaXPZ1PhqZQUnzXDzyKTX5NLblQo5JSlomXKOTTAZbPdlFK6N3qdh1JlAzVUKYHSvDNsZSXh/7oeA1MeaFIhnbkfhVUuYFcRajLB9KUf0EAbn/5TFi82Kxqj0GCZyINF
 9BonalVmCEx05rly6mkZzQSS/J2jvsVHjooi5kuqxzyU6tsaxUyU6Hl06mcYtQIa0H+Dvah5RdW4EN6IlWy4joGawAWp5Wm4DilxpoypO9E7RIKbduGkWmFmr3UjvU+Ktsm7T0irWo1qQ/e7Rtq6+sRmTZVShPVmEm9WEFBUFopmEyFmIO6jc39mN3xGfZgjAU6WVrViEU9mG2yWjc0SKeeyEhVlBo8lirS0nNoWeQliK5sWR9BmkipjWBRjOek1IWC2MTox0rNjBilqPNJCsZMiwTVWm4qn6imABzJ4ppsXBPB5ZUZJ1OKhXOexVaWXt2/7FwJggVpHZw0At0VTG+VSF1qxF00osW5pu9VrG+BBdy63sW61u/5vtg+sYX2Ja/LlFu5fYq/7tvxYMj9dZtx8Zr2UFvK4FvEFIZ1LMbD5wYvUZsyJZuajRvLsG/ZMcZK6EnK6RL9aZG/eGzq4cV8EIuGBind7FqIIcu61KVJRzDMjzDIBcWjldzq6pVOCwak+WyMUHCNDwVUxlO3IsW3+tyJthyQbzETNzEYTFzO4wStxXFonHDMLEXmxFuIgxrYIdSQJHFGGwSfxHCO6HFOsEYfTHGZ8fBEPI/PIGbUFzGYdxsYwcuAwd1TfxWRXcaeMzHVUFwRbx3Kzxyr5F0f/+8O318vomcFXuhIKS3YuAhcbexJj4cFP1kLHzVebehuTsxeim6E8kxG7VxG3P8fD8CaGvcwbsRvJerF5VMHJncEgLZGFsyFfeSx28Ft2gxe+uBeFLRpy8HtVURPAMKcnRKFdcLOyysfu8ygAzXyMH2yTsFEx4zXXXcvymafCgBIO2WE9psE9Nhyp9HfJ1BkjNhowKDeVA1eee8WCbxINg7aricpqu3ary8xLu3wr48FcK8zG56FwNVUrQFK4MyS7LEJT51Hujzat5CJiMVZkSCK0wCJPczm3joItfihVHzRrBaULAieUqiolKSLMsyJCINholSLVy4h9A
 ShjMk0An/XYZ5iCgb3USDURi/IiMxmyaSYilb1hkKwiAFpSpsoio6XdJSwicoXdNjoytO2DJzuF/qaQDyEYHOa3d1FRXfKabp4oAg+F9fNIHcB34EqC7u104HYH+g9oHj17QANnAKyJNlfX8PSGoEZtbA451Sizo5SdYPeJzsZH/VR2pWfb7xwi53XYwdSHj1V7Uh6IGTeNd1t39m7S7n9y/QXFJ6g1DH4jg8BF7pVRISczgrIjMYg2J9kTEBuTkCCRylpTUG84Rbws3CtZoyeTRHxI8tSTOexY9N1Dn2pCa6cdtHwzPjXDmJw5kmMzBbk1CpQl+qNTSdwiOPxY9Tskd8VZFq/8LaHbM5lwWQve2Pvx2a+FEcj3VSiOMwdlxqJsh2kFgvfNl6eieVBUaskkisaqUAxuiIs3iNochyrSOOAEaO42Ksv7iMfxlg/lVFneiKf+mNj5jg742JBEhgpShgBXaJE47MtGiXC8iruCOu4Cl/yPiW8JLE/d1O3GiWYpTZA42QOnRBjzMheRY/deRaEENC5NVGyMNhsjnNlXQbG+ZG9lNB9LUyppRVzyRBGgTk9dQtGTo/BHvc0CTjNp2xiEmxh4KYC1VAqhl6EmIbGsbROh56K9LlPG6ZWJJTD1JBFaSaG2vHq4guWAunZarVdiet5ySXueOeuswevmqOS6l3iv84rUdalFVElk1JoPMn6IgMpf6JgRLuk3xOl+9qLgWaHtWLpI2OYFgb6G756fq3lQtGpS1eGY5cVR+6TINWSbMW56DaWIOWNIK049J3oLA0238R2tckWiaJShP1TPlBTw8iR7dhUd8Rzod2JKz0SgrabFsDSmcFTBhKaJLiF1eSPaPBTBtaMxki7MtO5Db1HGwWIfAcTvRSuGg6Lr4832K6tXMNqPQM6GTqrUOZ5925lCPyIcBMYAvoOp8YnsUZpVEEzG6V2JYuguPpk1TxnHbp73let+JInnRFTg5G73V+6iqt2VfV
 HEQ445+cHJFl42Q+64pbT7aum1Ml7jqswwL/VTakkh+R+lnl86i5rtKmiezoJdD5cVOvVC3FA1iEihitJJlVbu3SrO0Em5vrU/RpbvNOPiV/IX1Rde7rigAHdvDqUp4R7+5xKu9/Hh+QfraCDu9t6vB1qZ7n9KXch8iEt6WR/u6Auq0Jn6SA/s+nR6dsH5US/yGhrsz6F+gYn58BXUmdYU0dX17GFatBjyPDdCMaM2KQgxjSFflVJX38evOhrcOm5TytGVzB/kkLq/m6pR9R7hcmdm/hfuUYW7P+OltRVjVi86+QdV3BhfQmAUthJn3VLGjHdeuj7+Qk+T6jE1uI4U2K3p/it8ed2OfujuhQFKxpWaRum+BiWq3h/yJXvrqAb721zZrgF8ilB3bo2Br3Bu+T0P+mVYTflA513G+XSAlOFd+MzsqIvjPxcl/9VGoahe83ABFhQgQGAR48CBCAgkGEECZMgECBQQQHDiIkxBjAYQQKCDU+hMDAYsKFASg6eAiRAYOBEAM0oADhYICHI2FybKAw4UyMJTP6dPhwJ4WcBgcSHWnSAc0JIx+kLFiSZ8KUDpNS/FgzY4CkSYNGZHBz4EsKHJdidEABKlmzL1My3Hk0p9WESX8mZDmBwlKYIVtCcCuUqdO1Uj3SLGoQ8FOXDzrOXLDgQIHIkQcoKIBgAQLKkjtXTjCgQIEBkg9YXmCAAAEDlxGIHv8tecBkzZwlryagYEFp0wcG/B6AIDRpzQlwf769+nRp3wUIHBj+/DbpBLsjZzZtHbtt1awvq369QMHq4Au2Uz5wGvRx8wiaS19tuz0C3AYiHxc+wED65LnlYy8tgJW2EimxrbZqwMADM2rAAQMbXDAjiyBEKzEKBXSgILwyjLDDAy/8kMMFRdLwpbM85ErBrUREEaMEMwprRRVTlNHFExlk0cEWK7SxLgtPJLHHHT+0MLHKjkQSyf2SVECzJEGrDsojE4gSyQScfJJJ4SpToMopv
 YysSd3E2zKyK8fMMs0FqDyyzMjcRFIB9bgEk8wxxXzyyjbR1BM0LJM8TcAShyTatNAO7TI0UUUXZbRRRx+FNFJJM1IztdwqxTRTTTfltFNPPz0AzU9HzVTOBQSdNFUGDku1VVdfhTVWWRutFDpSb8U1V1135bVXQXdNQNRec4XzTU2DzRMBYW9FdlhM/8z0z2YrhRZaZzm1Vs1s05zW026tXNZbUZGtVlNrBSyqwUEVvXHWD9f1MEaMVtqVv2txVW3OAzTjDVPs4hStTm9P+/fafZ/sV9OE7c3y4IStu9fThxvml9OCMbXvyIsjO3hjUOfM7uHSFMg4zYm5uoiBsmYs1Cd3D5yqRUT/6Y245k0vBvBW+XJlOGKPP51YzZxttvnnXoNOEjujOe25sqB3zvLkkRBl1OWXGZ2ZgSN9I6A6zETTbb8BunbvzfQIbk635gzw0jj9rlOtMnspc7sA3dwu2UwC3uY6yr71A3vNvfNOLYH09ib47da6lqw1BMQmgL7yvn6OvufYTm3s6g6X7sjW7Bb8bfOak61rtxlH7wDlIls8ytZa2xrtwDnWHHDQ0fuN8L7FIw10yCXX7Pe9NeuMvwLSNo/1wE83XHPKvvZ998rYptxL3xQPWDUDMO+77+M7w0xj0s2Lu3XPVucP8IwpI80+8zOHHUmUTYoJr4sEvKgBvQAzaSdW/2MqS0H0p5YGPOAsBtQIATPygIg4aH91eYhHIjKBnByEIAmBQAMmEkAB7e9+eNGa3gxHgNS4zz7OKWFornO23aAtNE0qT2WeM57lKEtu6inN8Ua3gBnqUIah6mGownQ8Bcxmh0HUmHv8Q0LVGc5uqvOMbmLjHDlRZntrKs32EpAZ1cmJif5ZmN0KYJ8ZSseIx9siEE8zGet0MTyTaRIT7RY/ji0HbVwi4hmXs5tgMU6EULziFaeYGzYOsooQS98dmSNGMq5RjKHKognNgx7kcBE9eRtAH6kUnNcoADPC6VoXiZ
 gZxh0AkwbATA2r6MXbxDFkqNQhc0JpN/pEkY6Vmf/fUxJDQcXQ5AEsQYhhfoKQCCBkAgh5QDH5R8GniGQCC7zgMSdizIpIJJnOZIhM3KIRwECgm4CJwAd/xbGMLac6KvRhaSJXRDntsTcZi9x63kSZh9krh6c5Jwk38xnjzLM9SUQkdPQJNS7icJ875KHh1IMd/tjGk5thDsEep57I2ROgTernQXljvOKIh40RRY0Pu4YdFd4woADd6B4zuaatlZOPWPxnQ9mnGZmeNKXa0UyTxOPRmVpnpeisTSXd8zxR/RQ1/3GPS5X2ODL+aaW24Y1I3WPQ9FUHqgcV6RaLI7WLIMqbNKnIM+cnzJ74T0ACuuZCUKIRj/DSrGtFmf7/6mKSthbQgBdhoEJyojKFFCSZMAphdpw22H8xZz+pC+jcsCSfq8YONcaRzmuA8xnG9rQyQ0uPZH8jVIva5l8FvQ5NT2ObuoE0M5+dKmouu9jONJajt4FNGw1KGuBwxkkLc2fPMLtH1V2sZ/3KoWixKlzX5naPvh3bFCsG3H8SVFnOEaLcCFDYg7ZHt8QDZUkHq9HQhtai6fNnaTwLnOBQV35TE6f+YDK/sZq1rHBxzEAuwkxwUsC+e8HITNJyX4qIkyP3dcBB+IqV+9pXJ+wFoUklsxvdFPGf1gnNksD7zvssdqD0RJJFrTpG+Tz0TRd+cHdT2mFRgdY6nnVSRRdK/1zKxFO27fmXilXb3SvVkrvZyUwRN/xinJrpwbg96WptuqYq6ks9y2lwcLOD4iVjOGR17PGVjLPjnF1GPEp2ricTEDfQFPnEnTGxRP/JGsLxprExTu2LzYxhJrPUvEeaH9UgAhi4joSsJPGfeufnzaYoJSEG0u/9VtKViZylgsR0TFRcdOCsybOWOiykfdjIw5um9IWvcWp1Yplh+4QnnlDdHCY1LWYhVzrUSewsJWGq2CYzWDY4HuqqDSo3SdtnpZuGtY1jA9I2Pu8ypny
 1SW9aaihn8lJL0ttmSAjpntaUoaOl56iHDGxT6rqn9/RMc4W6JAfrLWx7RGo/H43dzP9By4hL2ijdeA1SPX452+yk9siqFGdxJvAsRKGrXvP93oPANZyB2UnKJJJfj+A7rxJRWQEFvipkjiXfay2mRsRJM9YND4vUMQ9u/FY845bOxW8a26UeNhzSyMY5NBXNSivzmtVI8U/guWlzVO5dgzoUN2tccau705rm0WY86Jt1mKb71JDr5qbgcQ5rSLhu3q3GPuNxDpCHXfHwPFk1zvGSasoznFuzOKbQttR0Oz6yoVenPiSE+cW7Xt3QRgdkV2dcfMAcPIsjvTYTE03LIfZz6Xx3OdMVORZh6XTxAF68n6H3inzCmAkUJCgR57cxQSLWstgPJAv0iGNwYhSXTOT/8jOBiUdugl/9PWTigX0TmvA0HzQhO0uGuw+Y+pQlnXLJhmG6/ZS29SaBrR5bAuNW27xUrCf5fvZP2hLxkT/8Tyn/TdnKve+9Bfwj+T73m6mS9NWE0SQhAEvaT/3KqwRsJLkmS86vvrX6BKdtoSivQvozy1YELwnJH0MlehGP4sUieQH2Zi+/lDQpIgNAIaIxwANEwARUwAVkQNWxFqRhQA95ina5mgr0P02JLo6hPi5Jj3BhwA8EwRAUwRE0QO97EpARQQ+pCAtkwQMZEAIxkP5rwRUhFBlsEQ2aQQqcFXkBkRGxv0exwQgJwklZiiFskSEcQh0klPzDix+8GiP0/8FCUcJFiREcHBIo7JAXxCAE48IZfC8UobN6QxGsaEGrkZUw5IrKixA0hBWqiRA3nJSFiBlCmUP32gozFBD+EcLFYJU6zEExdEE+bBkivAgy3Ao9lBBARBEt1Ak49EJFwcNHbJFIfBWX8cOycsRIycREnJVLdD9WIbgFwcNNdApQlMRE2cSX2cRRVMR4KZGIoIijAIwGWIwHWiCtGCD+KaayYIyC2MVieghfNKtfFMYN4p+nCCBYpEX8
 4SCZUCCMyCBa5AhENIqOeAmH8CawyMVrdImt+EU8SyC3ioj6GaALQkZWkcb6qcaGWJkMiiCPCDBoLAuUmMa4sMZ54Qhe2v+gC3JGffQgt1DHCHAItHgIa7wgkyiRfXS8+EIJ0tMLXsIrdHzInCBGshgIdFSLiNvGA5ugnNALdnQrqngMgbDGmRhHVjFGe0SIdGSgymNJWLxGDEoQCKjHZRwgCbIvwPhI0LPFisSIi+jHhlyKoNSLIuSIC2KJmADKCrIvgoDJc0SZeOQKU3RB/NuLtMgJpLgI/MI3vCCKp/ClaVKIX3KJiOsIlgCnYDIrg1RLb2KJDMG3YoKJigDKbzIJvPKvatKgrhQQolCvtPDFkAjLYwJMeIkJsZTDxgPLa2KJBoi4Yko4PasLokg4lXGgBLlKp8ygkoA8stBLvYrMkPyrvPr/qq/6t7+SiYmYr18yyxzpCPXSJrmCRrv8N4FYlflair+SQ1bpM91ENLBSGd6ES2NiTbVspsVkJsUUq7gIsMZbq4PQH2yazbe0zL/0y7OkIKwMvca8Cr1MuJFoCpi4zZVITrsKS7P8zbKqTcUsxEJkT26Cz9SsTbj0xQeYy9BskAhYr31zxbvoTjvLCUA7RtnUzYTAipngzNxUS7gQpoUYOB0JULMcqwBdCKxAlJO4H0N8P5nozm1SDEfENzvzM8Q4K/2xiJXsJbZCiwwNMP7RJrWKSOAcOExk0Q09jL8aEHwbsKWwM7/ST7ESUQkRKw59pq/qib2qUAWdn70q0Jhh/9KtzLMhPQzZlAnZFFEyzM5CPIuQLEU8g87Ge4mfKAgHsdGkSFAzNVC6TNP//NG6KAgBaopSJFAohQv1VNKROFCEANC+7CuD0NISldAyxU2VoT8CGRQYXVO8GogbmYquoNM8PTBIbdC1PDB5jKBGpFOdsNC87NChuK+7SlP2sggQrQso/S/7ypB8DM+LNIgCO4zu5AkEzSVkkol6Q1SlcIxPxUdpU
 ogC87MgHdUCy9RSXUvJJAlfhVSnaEoojZlc/TfDSIpGvZ9+E1ZNLTA1PVX8Ilae2M0EyqC7CEWGQFOlGFcMTdREnRlVVdN+u58gjZkkhQs8vdOt9NWSkNdwPP8mnchV+wJVBvqrIzxU9jJXDUqmG828OntUJU1QBqVUhrVXhfMrtexRPt3UjDDXEa3TnOhQhCXV9iLDudBFHbEImRA9TsRVF5XYGO0LULxViuCJGAyLgfQJiuRROh1VQVM0k9UmPrvDRUvWH9VYZp1SXnJXUK1T9mJXENJUQ5ufj+VEboULgp1RRisglC1XNY1UrL1YDCU0IzXXfgNSOn1XPws0stXTTM1KYnVZczTOkrWJmKDKqvRPFp0QMNWmP3umtYrLBZXUUEVQilxQWcWKYsorYMLUfPuriv1JrT0RlKjPTt3bpLBCkmgI47wfosCKuWwKkfjR+lzRNI3Oxjz/XJ7Qi3VpWQfyXAxCiAHT02eq2IijSX07OMXTIKJVx59sXbONSrF61qP1N7ENJo/8H+GVXcCQw5TJUj/toMToUn21IKo4kcG1z8bjzss916xdK8tk075KuMzNTAYF3AMb25/VXTzNXdjV0sLNV7UC02K6igddxEGpCboFypYwEIfAL8bL2b7V3ccLXLUsvWdSGYH4qvlli7isWYtl3IwIirxl0bgIxk4liZZQNJYg4DQUCMJtiYZ4i8/1s68oCAOOVTE04A/u4D8ri3wdvaWo2ABW1M2zGpQACQ3hSxRuC/KtimfqVozIYfFtuEvNr5RoOBjuoAvuCwvuRhQmWS8lukvTY5AOBuGrvVqmEAjGJQyXSIsM/iW4/WEwvbOljdc/LdsVDoyxoAj9IWCdbLwGRlrr7c95YZEDWUE5/pFGYcIOuZAg2ZCEjONF6cEQoWMx1UEd+bMbURf485A87mMVJZBFDgsKLJD6y8IHWWQGsZDlrBEUIWQVtL87dhFKhpdNppBNRuRARhBDnsIdqWQEqW
 NE/mNJieQmdEH+45A/vluAPcVc7sSe1WVoBNNeVuXOBOZhJuZiVhSHKP9UuTXmZYaUuH1E+2TmCCmgaKbmal5maL7CZLbmbebmbvbmbwZnYmbEcCbncjbnc0bndH5jdWbndnbnd4ZnLxzneKbnerbne8ZnZc7nfebnfvZnb57nfxbogSbognaXgDbohFbohWbo+G3oh4boiFboeZaAjKjoDrloD6nojJaAjrborejokM5oFOFokcaIixZpjw6AkV4Qlj7pjz5plU4IlDbpmbbolMZomS7pkXZpnLZpjCbpA+npmA7pl17pml7pmTZplAZpo05qjQZppHbpo+ZpooZpoKZqnV4UpG7pp77pmt7pq3Zqjv5qn1ZqriaUoh5rmfbqCJlqVGlqozb/655W643+aa+u6rgm6qXW65+e6rdWare+arL267F26sM27LYWaqi+a7VubKkW6pRma8Wma8fG67tu7LXGaZYmbMXGa7BO7Msu7Mxe7L7WaLIG7NEWbL3u7NX27L+W7NSW7a8Wa8AqbcwmbZhmaqbO7dd2bco+a942bd1e7M427tzmabNmbZuObdyO6roO7eMebs4O7tvO66x+bp1m6+tGbuuW672W7qcO79r+bMkebbvuavHOaujObuWO7eRG67jeadBubtG2b0Nt6rAO7e9OauFu7fUGbO5Gb7/2adi+6Y8Ob8I27skOatUecKpObweP7vh+bwSvbQHn7+i+beDu/+3HZm/7lu7xBm/LVm/+fnALz2z4HuzDTm1DEW7mpu0In++3ZkQF9275Lmr9du4huW4R524ez/AQT+z3ZnAIl/Ad5/AE3+8dGW+a1mrepu4Ob2vOhuzI7vHtBm+5rvLpFmsFz/Hfxm4pT3AiB/D4Vm0Qt2oNR3ItpO4od24o9+xHGfAXL3EWd/H8jnECd+wWB3I0j+rSVnIpZ2wTH+rLpvO5xnMkH24wX25Bb/AuX3H1rmy+9vOy/u8f5/H6FnIPr3T
 8LhRMh/MZ33MyT/Q4b+kKb2/lXnTyHuz6tnSP1nFTB3Q1X+9UN/NHnPOc5nNFGXPztnJV5+pQ73MjV/TT9v/1Mm/xyibu7g5uGl+XY8ftQt/tQU/rDG/2ZH90ao/wbd/wvp5tbQ/0++72EU/1Xy9yAG/0Xdd1yy70Th/3VY/2wlb3b+dybYf3Yr/xSnd28qbpcafvEcfybO9vfkdsJn93Vi/4Vz/3KU/407byVt9ze/ftNyf4egdu2FZ1ir927Y74jcd2rD5wGD94fAd4+J5rV2d0VCf2KQ94fZ54Ri/uhpf5bG93da94kOf2e9/w/25wPv94mK/5nff3kVf0E7/5dnftXSfyjSb1Ukd4ktf4Yld6Ukd6ojd1BtCNVxd4kFd5ZDd4rS/5re96lSd7lB/0ro/pkIf5pzd1aEf3cj879Vvnd46Pe3Y3e+u++1bB+JN3e49XeFFf+HWXe1lf86yX6MNH/MSPZ6w/FcV3/MeHfIA2/Min/Mq3/Fz/ZvzL1/zN53xZyfzOB/3QF/1E+Xxfd3KtjnTx3vKYbxF6/3QSz/llh3Sc5/odEYDbFwCMuH3dx33e95DdDwDc7/3gz33bL37i533gR/4OUf6MaP4DEf7od/7oP/5EEX7fP2u2j/suz/h7Z/fYJ/oA9/e8l3mjF5DJl/2XJnER7+/tRu3nhvDT5/mqX3fEpnSkj/VJh/WZTwjgBwgBAgcGCCCw4EGDAhAuVMjwocOIBSdSnJgwYsKMDQcSlMiQY0WLDUNCFElSIceOJy+SlDBRAsyYMCu6LFgzwM2bL0/i1Elzp82QMyn6DNozJtCWMpH+bGo0ac+dRQMwULCAqNGi/zlpLmW6NGnNsDidbiUr9KzNrmKB+tS5FitbsGjhjuUJUePdlHn3YhxpVyJelCpNAmY5uOTKlH5JHryouPFCtU9bmp3clefbynXjQuXsdG7nzVDbcnY5tepVqWxldi5bt+3Q10FJP9UaWi1tt3BpZ/2Z
 k+lm22QlU9QIsi/fwMoXJzbeMXDxjcz/flRM3S7kiscFn5zaWu71l26FBxdPNLNnukKJn7/8vffY01bVH4XNu+xU/EjvrwZOfjRduokmGmvgveXabeGJ5NhI2zm33HEs8RRhgypJiJxgjylYnYaJebSceAJ2t56AuMW24VH0jYhWftd552JasYW1H0moxf/IGnqT1adfgfjNplmBXIkI4Gj+fXagb7Xd9tWLCl4YXXLToYjXk4RZ+WSVGVqHopbPSQeRa8CVR12TXP41I24Dwifkmd2Z+KOBcFZkI2Y3DlUmimuZBqSOfabZHp68yQajkiu+9qaZHmLYZZaIbRcegwtuOeVjUkKpnYUNhTkXnkJ+Bah7iX6WXmh2fkpZknHGV+N8dbqq4nhBDrpngKSKCRquhlqmY6ibGtoppnpZGSViITU6YYWYXlqssoxNqih2lv6aoJrgvYqqXQgKZx+vJ4rKq7V6VssAAyqaS+Kp/8k44H4zoelVtvGC6q6nd8IaIn2IVmvsYgx2uKW/k2L/KW2l0vVbYYfNXlkpdRcWjC+18hLIHravxvqpe+/aq2an2jY1nmoVLaBAuaWaPOqY565KpsSm4qhvrrvde63F10kY6bLODsuvzsgq3LNH0Sp8rKT/HiyvibbtiSChdS4dccUsxjw1zVgVNXLJLv8Waoin7hho01F/qyvNXIuN7Z/BPvqwzxxS2JzADLfNqJQJ050o22SzXGjaZ4erdctU9w141ShjPTbiiSu+OOONO/445JFLPjnllVve+OGXa7455517/jnooYs+OuSZk3466qmrvjrrrbuOOcmvyz477bXbfjvuKJqeO++9+/478MEjvvuZJ5qGcb0nt+lyoSr7/80mqcFRfHeXQTv+6F9VYl+ds3Y/RPT30jZ89NxOil++3Q5+Of7bbtedqZYlqc+v983uPniqKLPrZ9dQS292u9a1vDHhjz43W1/OEpY3t3GHOwVDGPf0sj0PaShLk
 MmO+xq1wMLQL27mW9jPeGa97K3vgCKEDgPL17YHFoR4g/qaWFrEInh9TGYfM9KomLavWq0JLNMzofVwtrOcLQyDQqTSQtaWxMM0yzAEseASMWgSogERhE1kDvjklywoMQyFNhNWFQnzLOR08XxBw5kL0UMrwiltN8QpUf7+57WUdU1WKdMYDqNltA6e0WBj1GIVcZYdJTaQggeTIs9AYkIqylrNipdyWCOH5pf6XZGSWizawPhySRUCzYpp3FXzCMQnjoFSRDqUGLBI5DyteUtoktqZF5HlvSN+KX1/JCImLcVCLppxiJt8ZC/ntshDbpFSuGRfMS8YMFjucpP/I2sVDJEEymnChzxBYlqOsjW91lVwkh784isLSSFFRnGL23tgLZfoM3LmEop5G6c3LUnCB7EQQsE8TBZJiJIranJD7aMKNGFlvGimMpqBQ1XSyJbQebkLUX1DJyfhJqzoOKeSJVTn/ArpT4zqspwjzOc8EdhJukEylopC4gYNmdJvgYhL/6ST/jaUnzn26XmlApvi/lM4Zo0UnHDjHi/DJ9R/TrB6e4GiA6cDvnem05VmQiJFM2rSD+JNbmxraVQnCtWCwFSgGQsb/xi6P7CKrWPb1Mo2hwjSiJLxiX6M6oIiGE+lHi1SXuzmSJcq0qIyi5FwLdYy+/lF8o0vhMvK/ygRUbgdOi10W2Q9XgHBRVaCZpNqM4MUFjuKzpX+la/aY6JGmZlIkY42g271KbRMO9XCApZgpNWnEzFrWF+qlbBA66o2M5ZWs8m0XreqKZnOelZ02RGXnG1cPjXYUYkqd4Q9fS50eRrSiTrVqCuMZFw/Ytru3VK6fcWuwnArvPGSt7zmPW/qxIve9bK3ve5974bUC9/50re+9vWdfO+r3/3yt7+ey69/AyzgAROYSzBF3k6V5z/KbM15aGVSHW/1xrIiuI6toSkPx1qbgY7IO2tsj4OJW9xVKoW3KhuS1SAG3CWlVXnA0piLB/i5A0
 uNU9d0kXDtJc3/nTjDJhNUWv9i9iKv6TTDgtoxyODUI1Ly7cYJNmWLV4xi9UBWxy0TU5OG7MY8/q0yMtyRgitHrpl9+csHdezKfOWritEopu+qobm0TE0pX9PKa1KznHpjTRXTMY5UPqhUzCznGImyyjS8o9N0tedRpuu3fV7x5cZs4Rf6OMwGhTOt8BzKFG/YxB/+zWy2dugj+RaVAPJR88SVGyY/GrLTAk2WlXIeUjPYWit7NZjRxmZO8bqH0Xv0DiOdNSKV2abPe3ODPaNDGX34ZGvu8U1vJKp0qWrNyPZUtbBspyVxhdZ6C8+UCRhoehG6yxyDjbdtvW1fj1rdkLacpGFIaXenCNyuimHTTpn/W4qtmrLpjkpMEUeaZPMtz1spaLbNtMZFM9RIy9Z1yMJEbmCzDJuXFTWCi63KGQ8b0KcMFMxmJcclb5pwY3txZDET8oYDutqizHOEN8Znyh48YgiXE8IX/kJr2zFpNZdsWCmuv4+LLt5M5la3bn5vmMNZ6EPP07z2VupvTzbG1aRjs5duWY2jWcQCnDcby4Nkc58N1UA3d9fLza5Wcs7of/qqqXwdcEDhnD3a9nqR566uxyq0xNROcJCV7Gc2XibWOWS1gtQYbE7LhuATC7f/Ml3kv18a7l+Tu7Ava+zKvrvDlo5zxQddVhIjPl82Nby9PZzw3gJ+y1EOcdWzvkrUQMvYspUOdpk4Tzm3vz73ODYx2nrv9zrPGu9RZ7mIr+VhuzMf+Fb3LdufX/tE0b7lkPZ966WPSuFbP/MF/j74wy9cfq52fPzmPz/622v09LO//e7n3frfL//50/908a8//vOvf8ndf//+/z8Aogi5DCABFqABHiACJqACLiADNqADPiAERqAETiAFVqAFXiAGZqAGbiAHdqAHfqAGBgQAOw==


--=_NamoWEC-ud1bd2lido--


From nobody Fri Sep 29 06:10:42 2017
Return-Path: 
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 B5E1013451E for ; Fri, 29 Sep 2017 06:10:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 M-aQS87ogHat for ; Fri, 29 Sep 2017 06:10:38 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3838E134528 for ; Fri, 29 Sep 2017 06:10:38 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 0ED026AE; Fri, 29 Sep 2017 15:10:37 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id Bic_R14artg6; Fri, 29 Sep 2017 15:10:33 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 29 Sep 2017 15:10:36 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id DC9B3200F6; Fri, 29 Sep 2017 15:10:36 +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 phCUgAgvWpWw; Fri, 29 Sep 2017 15:10:35 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F0A53200F4; Fri, 29 Sep 2017 15:10:34 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id C065D411B4C9; Fri, 29 Sep 2017 15:10:34 +0200 (CEST)
Date: Fri, 29 Sep 2017 15:10:34 +0200
From: Juergen Schoenwaelder 
To: Sudhanshu Kumar Srivastav 
Cc: Robert Wilton , "netmod@ietf.org" , KARTHIKEYAN SUBRAMANIAM , Surendra Pal Sharma , "cpgs ." 
Message-ID: <20170929131034.cpgjck7e2umt4zoe@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Sudhanshu Kumar Srivastav , Robert Wilton , "netmod@ietf.org" , KARTHIKEYAN SUBRAMANIAM , Surendra Pal Sharma , "cpgs ." 
References: <20170915142859epcms5p526b9d21b55ddd8f0eb13edfec62efcff@epcms5p5>  <20170913073034epcms5p3ba5e2a0c180d8cd9f4464d8e5921d106@epcms5p3>  <20170929125754epcms5p130f941babd487e94f81407ee2139d6c1@epcms5p1>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170929125754epcms5p130f941babd487e94f81407ee2139d6c1@epcms5p1>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] FW: RE: Re:  draft-srivastav-netmod-formulae-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Sep 2017 13:10:41 -0000

Dear Sudhanshu,

I share Robert's concerns. Hard coding expressions in a syntax tree
format in a schema is hardly readable and highly inflexible. Note that
there has been prior work like this in different contexts and one
thing you entirely ignore is that management data is not static;
counter leaf values have no meaning unless you compute a delta over a
time period etc.

You also seem to confuse basic concepts, i.e., protocols like NETCONF
do not parse schema definitions. So why would NETCONF need
enhancements? It should be a design goal to not require protocol
enhancements.

/js

On Fri, Sep 29, 2017 at 12:57:54PM +0000, Sudhanshu Kumar Srivastav wrote:
>    Hi Robert,
> 
> 
> 
>    Please find response inline.
> 
> 
> 
>    1) In particular, rather than modeling the expression directly in YANG
>    using YANG extensions, which effectively makes the expression look like
>    quite a verbose abstract syntax tree, I think that you may be better off
>    defining a separate expression language, similar to how Xpath is used
>    today.  Probably it could be related to Xpath, perhaps it could be a
>    superset.
> 
>    [srivastav]    There is slight difference in suggested idea and
>    that is "Model the formula as schema, not as Data".
> 
> 
> 
>    2) I think that there are some questions about how these expressions would
>    get programmed into the device.  Are they statically included as part of
>    the schema loaded by the NETCONF/RESTCONF server?  Or are they programmed
>    dynamically via the NETCONF/RESTCONF client.  For the latter case it would
>    be necessary to either define new RPC operations, or perhaps better a
>    configuration and operational YANG data model to manage the expressions.
> 
>    [srivastav]  formulas are getting statically included at server and not
>    programmed dynamically.  The benefit of this is when formula changes, Just
>    schema need to be changed and updated at server and no change in server is
>    required.
> 
> 
> 
>    3) I think that it would also need to be considered whether the
>    constructed expression values are represented as new nodes in the YANG
>    schema (which would probably prevent them from be constructed
>    dynamically), or perhaps they should make use of YANG metadata (RFC 7952)
>    instead so that the base underlying schema isn't changed.
> 
>    [srivastav]  YANG metadata (RFC 7952) shall be used.
> 
>    4) Any solution should probably also consider how it would inter-operate
>    with the work currently being doing in NETCONF on YANG push and related
>    technologies.
>    [srivastav]  I don't foresee any inter-operability problem with YANG push
>    technology. Kindly let me know if you foresee any problem.
> 
>    5) They may be security implications of allowing a client to execute
>    arbitrarily complex expressions would may degrade the performance of the
>    system, although perhaps the memory and cpu available to execute the
>    expressions could be limited.
> 
>    [srivastav] Modeling formula as schema don't put this security
>    implications, as formula is not getting programmed dynamically.
> 
> 
> 
> 
> 
>    Kindly let me know how can I proceed further to this idea from
>    conceptualization to  realization in IETF forum.
> 
> 
> 
>    Regards
> 
>    Sudhanshu
> 
> 
> 
>    --------- Original Message ---------
> 
>    Sender : Sudhanshu Kumar Srivastav  Chief
>    Engineer/SRI-Bangalore-CU/Samsung Electronics
> 
>    Date : 2017-09-15 19:58 (GMT+5:30)
> 
>    Title : RE: Re: [netmod] draft-srivastav-netmod-formulae-00
> 
>    To : null, null
> 
>    CC : KARTHIKEYAN SUBRAMANIAM, cpgs
>    ., Surendra Pal Sharma
> 
> 
> 
>    Dear  Robert,
> 
> 
> 
>       Thanks a lot for your feedback. It gave me other key areas to be
>    considered which can be impacted due to the suggested idea.
> 
> 
> 
>       With respect to first feedback, I think there is slight difference
>    in suggested idea and that is "Model the formula as schema, not as
>    Data".  So it's getting statically included at server and not programmed
>    dynamically.
> 
>       As I think "Modeling formula" as Data may have security implications.
> 
> 
> 
>       I am going through the feedbacks provided in details, I will check and
>    come back to this.
> 
> 
> 
>    Regards
> 
>    Sudhanshu
> 
> 
> 
>    --------- Original Message ---------
> 
>    Sender : Robert Wilton 
> 
>    Date : 2017-09-13 15:11 (GMT+5:30)
> 
>    Title : Re: [netmod] draft-srivastav-netmod-formulae-00
> 
>    To : Sudhanshu Kumar Srivastav,
>    null
> 
>    CC : KARTHIKEYAN SUBRAMANIAM, cpgs
>    .
> 
> 
> 
>    Hi Sudhanshu,
> 
>    Thanks for posting this.
> 
>    The premise of what you are trying to achieve here is interesting.  My
>    interpretation is that your idea is to allow a NETCONF/RESTCONF
>    server/device to take existing data in the operational state data tree and
>    to construct new derived data (or perhaps just metadata) by executing a
>    client defined algorithm that is described via extensions statements to
>    YANG.
> 
>    This broadly seems a reasonable idea to me, but I'm not sure that I would
>    implement it in quite the same way, and I've put forward some other points
>    or issues that you may want to consider.
> 
>    1) In particular, rather than modeling the expression directly in YANG
>    using YANG extensions, which effectively makes the expression look like
>    quite a verbose abstract syntax tree, I think that you may be better off
>    defining a separate expression language, similar to how Xpath is used
>    today.  Probably it could be related to Xpath, perhaps it could be a
>    superset.
> 
>    E.g .to take your example in 3.10, I think that it would be better if the
>    expression was written more like a normal mathematical expression.  E.g. I
>    think that the following would be easier to read/understand.  Obviously an
>    implementation needs to parse the expression, but that shouldn't be too
>    difficult, and they would need to write code to interpret the expression
>    anyway.
> 
>     container formula {
>        leaf a {
>           type int32;
>        }
>        ... leaves b to d defined similarly ...
>        leaf e {
>           type int32;
>        }
>        mt:math x {
>          leaf x {
>            type int32;
>            mt:expression"((a+b) - (c-d)/(e*100))";
>          }
>        }
> 
>    2) I think that there are some questions about how these expressions would
>    get programmed into the device.  Are they statically included as part of
>    the schema loaded by the NETCONF/RESTCONF server?  Or are they programmed
>    dynamically via the NETCONF/RESTCONF client.  For the latter case it would
>    be necessary to either define new RPC operations, or perhaps better a
>    configuration and operational YANG data model to manage the expressions.
> 
>    3) I think that it would also need to be considered whether the
>    constructed expression values are represented as new nodes in the YANG
>    schema (which would probably prevent them from be constructed
>    dynamically), or perhaps they should make use of YANG metadata (RFC 7952)
>    instead so that the base underlying schema isn't changed.
> 
>    4) Any solution should probably also consider how it would inter-operate
>    with the work currently being doing in NETCONF on YANG push and related
>    technologies.
> 
>    5) They may be security implications of allowing a client to execute
>    arbitrarily complex expressions would may degrade the performance of the
>    system, although perhaps the memory and cpu available to execute the
>    expressions could be limited.
> 
>    I hope the brief feedback is useful.  I'm not sure how familiar you are
>    with the IETF process, but please note that these comments just represent
>    my personal opinion and do not necessarily reflect those of the wider
>    participants in the NETMOD WG. Other opinions may, and in my experience
>    probably will, differ :-)
> 
>    Thanks,
>    Rob
> 
>    On 13/09/2017 08:30, Sudhanshu Kumar Srivastav wrote:
> 
>      Dear NETMOD Team,
> 
> 
> 
>        I have submitted a draft for new YANG module that defines new YANG
>      extension statements and method to model the formulae/KPI's.
> 
>        Request you to please check and provide your comments.
> 
> 
> 
>      Draft Details:
> 
>      Name: draft-srivastav-netmod-formulae
>      Revision: 00
>      Title: YANG extension Statements for formulae modeling
>      Document date: 2017-09-12
>      Group: Individual Submission
>      Pages: 28
>      URL:
>      [1]https://www.ietf.org/internet-drafts/draft-srivastav-netmod-formulae-00.txt
>      Status:
>      [2]https://datatracker.ietf.org/doc/draft-srivastav-netmod-formulae/
>      Htmlized:
>      [3]https://tools.ietf.org/html/draft-srivastav-netmod-formulae-00
>      Htmlized:
>      [4]https://datatracker.ietf.org/doc/html/draft-srivastav-netmod-formulae-00
> 
> 
> 
>      Regards
> 
>      Sudhanshu
> 
>  _______________________________________________
>  netmod mailing list
>  [5]netmod@ietf.org
>  [6]https://www.ietf.org/mailman/listinfo/netmod
> 
> 
> 
> References
> 
>    Visible links
>    1. https://www.ietf.org/internet-drafts/draft-srivastav-netmod-formulae-00.txt
>    2. https://datatracker.ietf.org/doc/draft-srivastav-netmod-formulae/
>    3. https://tools.ietf.org/html/draft-srivastav-netmod-formulae-00
>    4. https://datatracker.ietf.org/doc/html/draft-srivastav-netmod-formulae-00
>    5. mailto:netmod@ietf.org
>    6. https://www.ietf.org/mailman/listinfo/netmod



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


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


From nobody Fri Sep 29 09:18:50 2017
Return-Path: 
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 20A821331D9; Fri, 29 Sep 2017 09:18:49 -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 HXbhRJCzpEEV; Fri, 29 Sep 2017 09:18:47 -0700 (PDT)
Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::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 65B4E132CE7; Fri, 29 Sep 2017 09:18:47 -0700 (PDT)
Received: by mail-lf0-x235.google.com with SMTP id k23so107168lfi.11; Fri, 29 Sep 2017 09:18:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=1KYxpqlQOd0c225MaidB5WBzVdXwj3ixPKQ1n6c8x4A=; b=RMwulpWJ2+xKHkUyMDuXmUJhGp1mInn4ixUvn+eic/pK8n2fto/t084ihol2fmqjDE /h0ONniEN3DvtW/doP7PR5o32zD8dGLj/7STxuQbg7AKMCslCrNfPnJfuipQ8oX6lK+6 DUPDwI6D/r7W+Fw4bFIaQdTys3EkAuvea5VhEvwcrgX7K4B/qGMG/NYU9OtNTEgn8wxY w6U8AsDmfUn46dU+3MvFRaSD7akh9fSWHxln9w7JYLR3AkhNlfnkL1L6tSJzSlzj0DOp n4UJP22Dk50qTSxpl2rk7wkUpuadSdX09AdYgXfa4UWbrkzqFa4GTx1S03gDTT0YasYi q6JQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=1KYxpqlQOd0c225MaidB5WBzVdXwj3ixPKQ1n6c8x4A=; b=InsPr6zdn6iPvj3UV6dCuCSwb5AHXEgdGPHrZvt6glv7dWFIGX8uVM8EH0Idg4brSA 7Zu4D1PogIYIlzKj+L68A41gBJzg+2+fzAS1sEjIAhUdBB0qDQbwCMNiPmvUh2kB1gJQ dPpDPeCyjJctSQLQBg0mEfRebNH+QP3WNWdOdaEciQvnlXM4ZrzlnE+1SbTfvWCXTHhy d57Sp1P6i2lQ4ACC4r0AIAzr+Hyi1/NHxqwtY4Xr9+8XOasqozMBPCbqx0AXXzy83Vty BMahUuIxDN0llu10d2J/W9xNOOw3n6ZbFtAf3uY2ghYkFSsowXumOW2LXpdbGjWV0Cow LWkQ==
X-Gm-Message-State: AMCzsaWqifTnwEsJckhapCpOYeM7ufe7e57y/YF4PfrE7QMWE+tdLScL jcl2Wf2fiCEiu10j8cptjhTSjNUJ
X-Google-Smtp-Source: AOwi7QCESEMWtURD0sbkDvh6GfzhGXJ7B37EVRVn2lvLPoys7uDw6Jm/yn9VHWPFuhdQnutJLxPmaw==
X-Received: by 10.25.156.200 with SMTP id f191mr1056161lfe.0.1506701925580; Fri, 29 Sep 2017 09:18:45 -0700 (PDT)
Received: from xliuus (wsip-98-191-72-170.dc.dc.cox.net. [98.191.72.170]) by smtp.gmail.com with ESMTPSA id l17sm610560lfe.76.2017.09.29.09.18.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Sep 2017 09:18:44 -0700 (PDT)
From: "Xufeng Liu" 
To: "'Lou Berger'" , "'NetMod WG'" 
Cc: "'NetMod WG Chairs'" 
References: 
In-Reply-To: 
Date: Fri, 29 Sep 2017 12:18:41 -0400
Message-ID: <029c01d3393e$9f524180$ddf6c480$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGtTvUzA7HAE9sdYwEJ+qTA+l/2haMX3yFQ
Content-Language: en-us
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7223bis-00 (resend)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Sep 2017 16:18:49 -0000

Support.

Thanks,
- Xufeng

> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Lou Berger
> Sent: Monday, September 18, 2017 2:30 PM
> To: NetMod WG 
> Cc: NetMod WG Chairs 
> Subject: [netmod] WG adoption poll draft-bjorklund-netmod-rfc7223bis-00
> (resend)
> 
> All,
> 
> This is start of a two week poll on making
> draft-bjorklund-netmod-rfc7223bis-00 a working group document. Please send
> email to the list indicating "yes/support" or "no/do not support".
> If indicating no, please state your reservations with the document.  If
yes, please
> also feel free to provide comments you'd like to see addressed once the
> document is a WG document.
> 
> The poll ends Oct 2.
> 
> Thanks,
> 
> Lou (and Kent)
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Fri Sep 29 09:19:49 2017
Return-Path: 
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 BB6411331D9; Fri, 29 Sep 2017 09:19:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdEGVYQwrKtI; Fri, 29 Sep 2017 09:19:46 -0700 (PDT)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECBC4132CE7; Fri, 29 Sep 2017 09:19:45 -0700 (PDT)
Received: by mail-lf0-x231.google.com with SMTP id q132so129632lfe.5; Fri, 29 Sep 2017 09:19:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=CRvIPf+M3nS8EPUV5WWmHtOktqwaXCmGDqK9gDWKjBs=; b=KVJyQ06LVFndVZryown5MfcXgXopfMu4Pjb+O/mfx1KOeJ01HujsMCqVqjg381RIp7 kLHgmFmzO86I5DrchPS3iNn70ZjNc5Yjb9Z/QSZTqzvOBLTwCaHKR+/dQhzTA/O9nwFf +zlJkR6NBPODSPYxSth8gUjOruEIb/LYKlpXcJEaOY+nb2cj9GiMVAFkxEpT1CaqofXo hM6Ry19L911Ge5ooUL5JbjNWEJfCMZYnaUhs2/Ayu+p2dqKYDwYrvTMzRTuR9MLNQN5P xKakZ5G6YH801gCtqJgcBiJWIvxLP4fbUrRo5htVzYNK5TAvHxVbjZQCqe5WM9kD7hhx dPkg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=CRvIPf+M3nS8EPUV5WWmHtOktqwaXCmGDqK9gDWKjBs=; b=HjmL625H5W59xuegh0rICZkDgDvcsh4rJfU1DnhhxAD63yeVNgsvmPd4W14TQQ5nih 8vzV3GU5arZBmpMGkyhX1/tRbImgJWAshooujGwRChouBPxv4YRCkpJZTlQpRR1gWlJy xJpHbSwPEOdjEY9pLQ52A8o8XIHRWl5/NdgyHd7C8OVep0eqkoDhUnA5b105V44X4XHw c8R5GgHJA8NbBWBkwxHvxMLa6XtbLj09c3Ei2ADUgCOuIs0+iRKYWtsmBHlKUgJcLSso EUNA22V2t11M68cwazFm/6uFihQZI0QIAeh0DyYFXt+2FWquKXZrDk507Y7rYKx1ZElH VMKA==
X-Gm-Message-State: AMCzsaXM3U7CBguYybe4qreS68G0ZIiuCGIt+Qs9Sw6GPwzHnjlcFAra JOnZe7Rakde4FYJm28/7iYQ=
X-Google-Smtp-Source: AOwi7QDltFO8iyvB3UF4XSmAdbgg9lEgdmnsYO+TGX4stfwhe3W2s1hR5hNNezuqeHihj5tKFJlNAA==
X-Received: by 10.25.199.23 with SMTP id x23mr1421767lff.114.1506701984234; Fri, 29 Sep 2017 09:19:44 -0700 (PDT)
Received: from xliuus (wsip-98-191-72-170.dc.dc.cox.net. [98.191.72.170]) by smtp.gmail.com with ESMTPSA id t5sm845952ljd.53.2017.09.29.09.19.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Sep 2017 09:19:43 -0700 (PDT)
From: "Xufeng Liu" 
To: "'Lou Berger'" , "'NetMod WG'" 
Cc: "'NetMod WG Chairs'" 
References: <9b125d33-1413-00e5-04c2-408a154745e4@labn.net> <2edf2573-c176-5494-cdb3-a6cbb79e46f8@labn.net>
In-Reply-To: <2edf2573-c176-5494-cdb3-a6cbb79e46f8@labn.net>
Date: Fri, 29 Sep 2017 12:19:40 -0400
Message-ID: <029d01d3393e$c25b1120$47113360$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHYcSmxDEMdhmOzYqda28r/Hs27aQEJitxforlOwfA=
Content-Language: en-us
Archived-At: 
Subject: Re: [netmod] Correction: WG adoption poll draft-bjorklund-netmod-rfc7277bis-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Sep 2017 16:19:48 -0000

Support.

Thanks,
- Xufeng

> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Lou Berger
> Sent: Monday, September 18, 2017 3:48 PM
> To: NetMod WG 
> Cc: NetMod WG Chairs 
> Subject: [netmod] Correction: WG adoption poll draft-bjorklund-netmod-
> rfc7277bis-00
> 
> The draft being polled in this thread is
> draft-bjorklund-netmod-rfc7277bis-00
> 
> Lou
> 
> On 9/18/2017 3:15 PM, Lou Berger wrote:
> > All,
> >
> > This is start of a two week poll on making
> > draft-bjorklund-netmod-rfc7227bis-00 a working group document. Please
> > send email to the list indicating "yes/support" or "no/do not support".
> > If indicating no, please state your reservations with the document.
> > If yes, please also feel free to provide comments you'd like to see
> > addressed once the document is a WG document.
> >
> > The poll ends Oct 2.
> >
> > Thanks,
> >
> > Lou (and Kent)
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Fri Sep 29 09:46:24 2017
Return-Path: 
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 05AF11321C7 for ; Fri, 29 Sep 2017 09:46:22 -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 DKDuKgvuqcuY for ; Fri, 29 Sep 2017 09:46:19 -0700 (PDT)
Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4F91126E64 for ; Fri, 29 Sep 2017 09:46:18 -0700 (PDT)
Received: by mail-lf0-x233.google.com with SMTP id m199so206275lfe.3 for ; Fri, 29 Sep 2017 09:46:18 -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=Fb3tlEgZCr7clsK9JBx33XWQBn5cbL/CudRHX3usPik=; b=lgC50tr+kAq62LCYyGrAKtwxotwT4gmY7pwPVWudOfqIwUbaFmUBXuhdwU+gRyQcOR 3zTv03Qi/lHZkl1kHZCHAiYk0AMYNLQ1p4zmwpP4xP2mp33wRv4z4L1xCZHjNHSd4krR /aDWWwv1XboqCdgJw0ooDOP702GZCWNGPBfNk6sacQyqzYEQC1AWboNDkNdYoJZ0ne03 UAcB50S6Vo1PsLVRVgxNhaj76NbVu8X5D9jV3BXxAvfkO1hnTtUSkhwWVmt8LOcMZ8+h uwPcVpIYOZxJ6XEx0OQp5RsSeM/uc+Lg3qTG0ZsLgIz6hqyf3E0xRYP7EGKdACrkbu/7 +bYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Fb3tlEgZCr7clsK9JBx33XWQBn5cbL/CudRHX3usPik=; b=QfifSn7siwwyHcHvAXnoXkM1JKyrkkX9izqmQV7aJkvMUnrPMQkwRPXrVr9iqheXft 908uPVQ9cy6GlMTuY5m2nyxlTajgSI5dqfMJWhcVXMcDOITU8jetgU79K8gfUB0T3EEj w5E0KWOoUSI5di3LZY0RKfQT9H6pIosJeZnR56TILEsKHDkFQs4Lrdc2v8WMW/l/3g2o 3zFjoIGuBjRFGvIrLJYL3CAAziQJihb5Qij+/XX3qVMOXThLm+fMuNpFYkKXHUDQhCOi Ca4ljsnJ1K7YGFghWsBLdvsFXDQIc6YaB7MXde17MTRDMXgtppe6uNn5/LTMjfkUgiem MLxw==
X-Gm-Message-State: AHPjjUgxjeAQBr2ZlFDGRFeW20zENvflEy4kOd7tr39CfdsC/DyobNKh H+FesH/KVGfRBuJudXVVVW0DO8n4qMBotMpqHtFm9g==
X-Google-Smtp-Source: AOwi7QBxbASqOYW2JB8sQTzmGkcwpttxDNnlrxqReEuvLPy8O4jcRWz2h7FuUq7XLv5i2iki2wwTRidDI6AQ6OVRbVo=
X-Received: by 10.25.142.9 with SMTP id q9mr1443098lfd.89.1506703577041; Fri, 29 Sep 2017 09:46:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.18.41 with HTTP; Fri, 29 Sep 2017 09:46:15 -0700 (PDT)
In-Reply-To: 
References: <9ec6b2e4-36a7-87e6-59fa-828855235835@ericsson.com> <20170914.163239.143365521945928900.mbj@tail-f.com> <0605fab0-f879-e02d-4858-52a247571cb8@ericsson.com> 
From: Andy Bierman 
Date: Fri, 29 Sep 2017 09:46:15 -0700
Message-ID: 
To: Robert Wilton 
Cc: Balazs Lengyel , Martin Bjorklund , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="f403045f50707e0d76055a56c3be"
Archived-At: 
Subject: Re: [netmod] Comments on NMDA-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Sep 2017 16:46:22 -0000

--f403045f50707e0d76055a56c3be
Content-Type: text/plain; charset="UTF-8"

On Thu, Sep 28, 2017 at 9:28 AM, Robert Wilton  wrote:

> Hi,
>
> Regarding the issue "Is it allowed to violate uniqueness of key values?",
> https://github.com/netmod-wg/datastore-dt/issues/10
>
> We have discussed this further, and would like to extend the text in the
> draft to explicitly allow key uniqueness to be violated!
>
>
so we can rubber-stamp buggy servers?
I do not agree this is needed.



> We have thought of several cases where it is possible that duplicate
> entries could appear, and we don't want to force any overhead on the device
> to guarantee that this does not occur, nor do we want to force
> synchronization between configuration processing and what is reported in
> .  Of course, in normal circumstances this constraint, like
> the others, should not be violated.  This is already stated in the draft.
>
> Examples of where uniqueness of list keys could be violated include:
> 1) If a device is internally paging the results back for a long list, then
> it is possible that a entry could have been reported near the beginning of
> the list, then moved, and then reported again at the end of the list.
>


The data is question is simply part of an  and it is subject to
the validation
requirements for RPC replies only.  Note also that the payload to represent
an arbitrary
configuration datastore has to be done with anydata or anyxml.  RPC reply
validation
rules for these nodes do not extend to contents of the anydata instance.


2) If the list being stored somewhere in the system has become corrupted
> and contains duplicate entries.  It is better to return truth.
>


It is better to fix the buggy server.
Again, a representation of some portion of a datastore in an 
has nothing to do with the YANG validation of a datastore within a server.




> 3) On a distributed system where the list is being constructed from
> multiple nodes (e.g. linecards or peer devices) then if a list entry is
> moved from one node to another then it is again possible that an entry
> could be reported in both places (or neither) for a short interval before
> the system becomes consistent again.
>


Once again, this is an  representation, not the validation of a
datastore
within a server.




Andy



> Proposed text:
>
> OLD:
>
>     SHOULD conform to any constraints specified in the data
>    model, but given the principal aim of returning "in use" values, it
>    is possible that constraints MAY be violated under some
>    circumstances, e.g., an abnormal value is "in use", or due to remnant
>    configuration (see Section 4.3.1).  Note, that deviations are still
>    used when it is known in advance that a device does not fully conform
>    to the  schema.
>
>    Only semantic constraints MAY be violated, these are the YANG "when",
>    "must", "mandatory", "unique", "min-elements", and "max-elements"
>    statements.
>
> NEW:
>
>     SHOULD conform to any constraints specified in the data
>    model, but given the principal aim of returning "in use" values, it
>    is possible that constraints MAY be violated under some
>    circumstances, e.g., an abnormal value is "in use", the structure of
>    a list is being modified, or due to remnant configuration (see
>    Section 4.3.1).  Note, that deviations are still used when it is
>    known in advance that a device does not fully conform to the
>     schema.
>
>    Only semantic constraints MAY be violated, these are the YANG "when",
>    "must", "mandatory", "unique", "min-elements", and "max-elements"
>    statements; and the uniqueness of key values.
>
> Again, if there are no objections, I will apply this change.
>
> Thanks,
> Rob
>
>
> On 14/09/2017 16:44, Balazs Lengyel wrote:
>
>> See below !
>>
>>
>> On 2017-09-14 16:32, Martin Bjorklund wrote:
>>
>> CH 4.4.)  "Validation is performed on the contents of ."
>>>> This to me means that default data is not considered at validation
>>>>
>>> Note that RFC 7950, section 6.4.1, says:
>>>
>>>     In the accessible tree, all leafs and leaf-lists with default values
>>>     in use exist (see Sections 7.6.1 and 7.7.2).
>>>
>>> So defaults are taken into account when intended is validated.
>>>
>> BALAZS: Yes the two seem to contradict each other. This can be understood
>> in your way, however the current text is not clear enough. I would add:
>> Validation is performed on the contents of  (EXTENDED WITH
>> DEFAULT CONFIGURATION).
>>
>>> which would be a backwards incompatible change. Also if validation
>>>> does not consider system configured data that would allow cases like
>>>> multiple interfaces named lo0. One from  one from system
>>>> configuration. IMHO while it is OK to violate uniqueness because of
>>>> remnant data, the above violation of uniqueness seems a bad idea.
>>>>
>>> If your system adds data to , or to , it will be
>>> validated.
>>>
>>> Ch. 4.7) Is it allowed to violate uniqueness of key values? IMHO it
>>>> should not be.
>>>>
>>> Agreed.  Note that the draft explicitly lists the constraints that can
>>> be violated, and uniqueness of keys is not listed.
>>>
>> BALAZS: If that is the intent I would propose to explicitly state it. For
>> me it was non-trivial.
>> Can a a choice statement be violated? Having to existing branches at the
>> same time? It seems a semantic constraint to me. IMHO yes.
>> Can an if-feature be violated? If  support has just changed and we have
>> some remnant config, I can very well imagine it violated.
>>
>> Also here could you change
>> If a node in   does not meet the syntactic constraints then
>> it cannot   be returned
>> to
>> If a node in   does not meet the syntactic constraints then
>> it MUST NOT be returned
>>
>>> /martin
>>>
>>
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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




On Thu, Sep 28, 2017 at 9:28 AM, Robert Wilton <rwilton@cisco.com&=
gt; wrote:
Hi,



Regarding the issue "Is it allowed to violate uniqueness of key values=
?", https://github.com/netmod-wg/datast=
ore-dt/issues/10



We have discussed this further, and would like to extend the text in the dr=
aft to explicitly allow key uniqueness to be violated!



so we can rubber-stamp buggy servers?<=
/div>
I do not agree this is needed.

=C2=A0

We have thought of several cases where it is possible that duplicate entrie=
s could appear, and we don't want to force any overhead on the device t=
o guarantee that this does not occur, nor do we want to force synchronizati=
on between configuration processing and what is reported in <operational=
>.=C2=A0 Of course, in normal circumstances this constraint, like the ot=
hers, should not be violated.=C2=A0 This is already stated in the draft.


Examples of where uniqueness of list keys could be violated include:

1) If a device is internally paging the results back for a long list, then =
it is possible that a entry could have been reported near the beginning of =
the list, then moved, and then reported again at the end of the list.


The data is question is simpl=
y part of an <rpc-reply> and it is subject to the validation
requirements for RPC replies only.=C2=A0 Note also that the payload to re=
present an arbitrary
configuration datastore has to be done with =
anydata or anyxml.=C2=A0 RPC reply validation
rules for these nod=
es do not extend to contents of the anydata instance.

<=
div>

2) If the list being stored somewhere in the system has become corrupted an=
d contains duplicate entries.=C2=A0 It is better to return truth.


It is better to fix the buggy ser=
ver.
Again, a representation of some portion of a datastore in an=
 <rpc-reply>
has nothing to do with the YANG validation of =
a datastore within a server.


=C2=A0=


3) On a distributed system where the list is being constructed from multipl=
e nodes (e.g. linecards or peer devices) then if a list entry is moved from=
 one node to another then it is again possible that an entry could be repor=
ted in both places (or neither) for a short interval before the system beco=
mes consistent again.


On=
ce again, this is an <rpc-reply> representation, not the validation o=
f a datastore
within a server.

=C2=A0


Andy





Proposed text:



OLD:



=C2=A0=C2=A0 <operational> SHOULD conform to any constraints specifie=
d in the data

=C2=A0=C2=A0 model, but given the principal aim of returning "in use&q=
uot; values, it

=C2=A0=C2=A0 is possible that constraints MAY be violated under some

=C2=A0=C2=A0 circumstances, e.g., an abnormal value is "in use", =
or due to remnant

=C2=A0=C2=A0 configuration (see Section 4.3.1).=C2=A0 Note, that deviations=
 are still

=C2=A0=C2=A0 used when it is known in advance that a device does not fully =
conform

=C2=A0=C2=A0 to the <operational> schema.



=C2=A0=C2=A0 Only semantic constraints MAY be violated, these are the YANG =
"when",

=C2=A0=C2=A0 "must", "mandatory", "unique", &=
quot;min-elements", and "max-elements"

=C2=A0=C2=A0 statements.



NEW:



=C2=A0=C2=A0 <operational> SHOULD conform to any constraints specifie=
d in the data

=C2=A0=C2=A0 model, but given the principal aim of returning "in use&q=
uot; values, it

=C2=A0=C2=A0 is possible that constraints MAY be violated under some

=C2=A0=C2=A0 circumstances, e.g., an abnormal value is "in use", =
the structure of

=C2=A0=C2=A0 a list is being modified, or due to remnant configuration (see=


=C2=A0=C2=A0 Section 4.3.1).=C2=A0 Note, that deviations are still used whe=
n it is

=C2=A0=C2=A0 known in advance that a device does not fully conform to the
=C2=A0=C2=A0 <operational> schema.



=C2=A0=C2=A0 Only semantic constraints MAY be violated, these are the YANG =
"when",

=C2=A0=C2=A0 "must", "mandatory", "unique", &=
quot;min-elements", and "max-elements"

=C2=A0=C2=A0 statements; and the uniqueness of key values.



Again, if there are no objections, I will apply this change.



Thanks,

Rob





On 14/09/2017 16:44, Balazs Lengyel wrote:



See below !





On 2017-09-14 16:32, Martin Bjorklund wrote:





CH 4.4.)=C2=A0 "Validation is performed on the contents of <intende=
d>."

This to me means that default data is not considered at validation



Note that RFC 7950, section 6.4.1, says:



=C2=A0=C2=A0=C2=A0 In the accessible tree, all leafs and leaf-lists with de=
fault values

=C2=A0=C2=A0=C2=A0 in use exist (see Sections 7.6.1 and 7.7.2).



So defaults are taken into account when intended is validated.



BALAZS: Yes the two seem to contradict each other. This can be understood i=
n your way, however the current text is not clear enough. I would add:

Validation is performed on the contents of <intended> (EXTENDED WITH =
DEFAULT CONFIGURATION).



which would be a backwards incompatible change. Also if validation

does not consider system configured data that would allow cases like

multiple interfaces named lo0. One from <intended> one from system
configuration. IMHO while it is OK to violate uniqueness because of

remnant data, the above violation of uniqueness seems a bad idea.



If your system adds data to <running>, or to <intended>, it wil=
l be

validated.





Ch. 4.7) Is it allowed to violate uniqueness of key values? IMHO it

should not be.



Agreed.=C2=A0 Note that the draft explicitly lists the constraints that can=


be violated, and uniqueness of keys is not listed.



BALAZS: If that is the intent I would propose to explicitly state it. For m=
e it was non-trivial.

Can a a choice statement be violated? Having to existing branches at the sa=
me time? It seems a semantic constraint to me. IMHO yes.

Can an if-feature be violated? If=C2=A0 support has just changed and we hav=
e some remnant config, I can very well imagine it violated.



Also here could you change

If a node in=C2=A0 <operational> does not meet the syntactic constrai=
nts then it cannot=C2=A0=C2=A0 be returned

to

If a node in=C2=A0 <operational> does not meet the syntactic constrai=
nts then it MUST NOT be returned



/martin









_______________________________________________

netmod mailing list

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




--f403045f50707e0d76055a56c3be--


From nobody Fri Sep 29 20:57:12 2017
Return-Path: 
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 83382134237; Fri, 29 Sep 2017 20:57:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPUz2TdZgD1q; Fri, 29 Sep 2017 20:57:01 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B39613202D; Fri, 29 Sep 2017 20:56:59 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPQ20072; Sat, 30 Sep 2017 03:56:57 +0000 (GMT)
Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 30 Sep 2017 04:56:55 +0100
Received: from DGGEML507-MBX.china.huawei.com ([169.254.2.79]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0301.000; Sat, 30 Sep 2017 11:56:44 +0800
From: Jiangyuanlong 
To: Robert Wilton , Martin Bjorklund 
CC: "sean.condon@microsemi.com" , "tictoc@ietf.org" , "netmod@ietf.org" 
Thread-Topic: [netmod] draft-ietf-tictoc-1588v2-yang-05 - Concern over port identifier
Thread-Index: AdM20lxp4a4LJ64bREK66XJnd3gJawAF4nRwABKMRUAAEqGn9wA1hiAA//+KVAD//jENcIADInsA//5I7rA=
Date: Sat, 30 Sep 2017 03:56:44 +0000
Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5CC9E4@dggeml507-mbx.china.huawei.com>
References: <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5C9C01@dggeml507-mbx.china.huawei.com> <640F4C69F839A64C8949EF04FAAEE44679F25561@avsrvexchmbx1.microsemi.net> <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5CB62E@dggeml507-mbx.china.huawei.com> <20170928.152312.261607006753399632.mbj@tail-f.com> <3B0A1BED22CAD649A1B3E97BE5DDD68BBB5CC14E@dggeml507-mbx.china.huawei.com> 
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.74.202.215]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.59CF1609.006F, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.2.79, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 819316cabdc3072d1d0c82459966f849
Archived-At: 
Subject: Re: [netmod] draft-ietf-tictoc-1588v2-yang-05 - Concern over port identifier
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 30 Sep 2017 03:57:04 -0000

RGVhciBSb2IsDQoNClRoYW5rIGEgbG90IGZvciB5b3VyIGNvbW1lbnRzLiBJIGFncmVlIHdpdGgg
eW91IHRoYXQgcHJhY3RpY2FsIGNvZGluZyBzdHlsZSBpcyBuZWVkZWQgZm9yIGEgcGFydGljdWxh
ciBsYW5ndWFnZSAoaGVyZSBpcyBZQU5HKS4NCkJ1dCBhcyBJRUVFIDE1ODggd2lsbCBiYXNlIHRo
ZWlyIDE1ODgtMjAxNyBtb2RlbCBvbiB0aGlzIGRvY3VtZW50LCBzbyB3ZSB3b3VsZCBhbHNvIHNv
bGljaXQgdGhlaXIgb3Bpb25zLg0KDQpUaGFua3MgYWdhaW4sDQpZdWFubG9uZw0KDQoNCi0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSb2JlcnQgV2lsdG9uIFttYWlsdG86cndpbHRv
bkBjaXNjby5jb21dIA0KU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMjksIDIwMTcgNTozOCBQTQ0K
VG86IEppYW5neXVhbmxvbmc7IE1hcnRpbiBCam9ya2x1bmQNCkNjOiBzZWFuLmNvbmRvbkBtaWNy
b3NlbWkuY29tOyB0aWN0b2NAaWV0Zi5vcmc7IG5ldG1vZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6
IFtuZXRtb2RdIGRyYWZ0LWlldGYtdGljdG9jLTE1ODh2Mi15YW5nLTA1IC0gQ29uY2VybiBvdmVy
IHBvcnQgaWRlbnRpZmllcg0KDQpIaSBZdWFubG9uZywNCg0KSSBhZ3JlZSB3aXRoIE1hcnRpbiwg
aGF2aW5nIGEgc2luZ2xlIGtleSBpcyBhIGJldHRlciBkYXRhIG1vZGVsLg0KDQpEdXBsaWNhdGlu
ZyB0aGUgcG9ydC1udW1iZXIgaW4gdGhlIGRhdGEgbW9kZWwganVzdCBtYWtlcyBpdCB0aGF0IGxp
dHRsZSBiaXQgbW9yZSBhbm5veWluZyB0byB1c2UuDQoNCkkgdGhpbmsgdGhhdCBJbmZvcm1hdGlv
biBtb2RlbHMgYXJlIG9mdGVuIG1vZGVsZWQgdXNpbmcgVU1MLCB3aGljaCBJJ20gbm90IHBhcnRp
Y3VsYXJseSBmYW1pbGlhciB3aXRoLCBidXQgc2VlbXMgdG8gZm9sbG93IG9iamVjdCBvcmllbnRh
dGVkIHByaW5jaXBsZXMuDQoNCllBTkcgaXMgbm90IG9iamVjdC1vcmllbnRhdGVkLCBpbnN0ZWFk
IHNlZW1zIHRvIG1vcmUgY2xvc2VseSByZXNlbWJsZSBhIGRvY3VtZW50IGJhc2VkICJtaXhpbiIg
YXJjaGl0ZWN0dXJlLg0KDQpCZWNhdXNlIG9mIHRoaXMgZGlmZmVyZW5jZSwgSSB0aGluayB0aGF0
IHRoZXJlIHdpbGwgbmF0dXJhbGx5IGJlIGRpZmZlcmVuY2VzIGJldHdlZW4gaG93IHNvbWV0aGlu
ZyBpbiBiZXN0IG1vZGVsZWQgaW4gVU1MIHZzIGhvdyBpdCBpcyBiZXN0IG1vZGVsZWQgaW4gWUFO
Ry4NCg0KRm9yIG1lLCBoYXZpbmcgdGhlIFlBTkcgbW9kZWwgYXMgc2ltcGxlLCBjb25zaXN0ZW50
LCBhbmQgYXMgZWFzeSB0byB1bmRlcnN0YW5kIGFzIHBvc3NpYmxlIGlzIG1vcmUgaW1wb3J0YW50
IHRoYXQgYSB2ZXJ5IGNsb3NlIG1hcHBpbmcgdG8gYSByZWxhdGVkIGluZm9ybWF0aW9uIG1vZGVs
LsKgIFNvLCBpbiBzdW1tYXJ5LCBteSBzdWdnZXN0aW9uIGlzIHRvIGFsbG93IHRoZXNlIG1vZGVs
cyB0byBkaXZlcmdlIHdoZXJlIG5lY2Vzc2FyeS4NCg0KVGhhbmtzLA0KUm9iDQoNCg0KT24gMjkv
MDkvMjAxNyAxMDoyMiwgSmlhbmd5dWFubG9uZyB3cm90ZToNCj4gTWFydGluLA0KPg0KPiBUaGFu
ayBhIGxvdCBmb3IgeW91ciBpbnN0YW50bHkgcmVwbHkuIFBsZWFzZSBzZWUgbXkgZnVydGhlciBj
b21tZW50cyBpbmxpbmUuDQo+DQo+IENoZWVycywNCj4gWXVhbmxvbmcNCj4NCj4gLS0tLS1Pcmln
aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFydGluIEJqb3JrbHVuZCBbbWFpbHRvOm1iakB0
YWlsLWYuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDI4LCAyMDE3IDk6MjMgUE0N
Cj4gVG86IEppYW5neXVhbmxvbmcNCj4gQ2M6IHNlYW4uY29uZG9uQG1pY3Jvc2VtaS5jb207IG5l
dG1vZEBpZXRmLm9yZzsgdGljdG9jQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBk
cmFmdC1pZXRmLXRpY3RvYy0xNTg4djIteWFuZy0wNSAtIENvbmNlcm4gb3ZlciANCj4gcG9ydCBp
ZGVudGlmaWVyDQo+DQo+IEppYW5neXVhbmxvbmcgPGppYW5neXVhbmxvbmdAaHVhd2VpLmNvbT4g
d3JvdGU6DQo+PiBTZWFuLA0KPj4NCj4+IE15IHBlcnNvbmFsIG9waW5pb24gaXMgdGhhdCBpdCBj
YW4gd29yaywgYnV0IEkgd291bGQgbGlrZSB0byBhc2sgZm9yIA0KPj4gbW9yZSBvcGluaW9ucyBm
cm9tIG91ciBuZXRtb2QgZXhwZXJ0czspDQo+Pg0KPj4gSGkgbmV0bW9kIGV4cGVydHMsDQo+PiBD
b25zaWRlcmluZyB0aGUgZm9sbG93aW5nIHNhbXBsZSBtb2R1bGUsIG15LWxpc3QgaXMgYSBsaXN0
LCBhbmQgaXQgDQo+PiBuZWVkcyB0byB1c2UgYSBsZWFmIG1lbWJlciAicG9ydC1udW1iZXIiIGlu
IG15LXBvcnQtY29udGFpbmVyIGFzIGEgDQo+PiBrZXkuDQo+PiBXZSBub3cgaGF2ZSAzIG9wdGlv
bnM6DQo+PiAxLg0KPj4gICAgbGlzdCBteS1saXN0IHsNCj4+ICAgICAga2V5ICJwb3J0LW51bWJl
ciI7DQo+PiAgICAgIGxlYWYgcG9ydC1udW1iZXIgew0KPj4gICAgICAgICB0eXBlIHVpbnQxNjsN
Cj4+ICAgICAgfQ0KPj4NCj4+ICAgICAgY29udGFpbmVyIG15LXBvcnQtY29udGFpbmVyIHsNCj4+
ICAgICAgICAgIGxlYWYgcG9ydC1udW1iZXIgew0KPj4gICAgICAgICAgICB0eXBlIHVpbnQxNjsN
Cj4+ICAgICAgICAgIH0NCj4+ICAgICAgICAgICBsZWFmIG90aGVyLWxlYWYgew0KPj4gICAgICAg
ICAgICAgLi4uDQo+PiAgICAgICAgICAgfQ0KPj4gICAgICB9DQo+PiAgICB9DQo+PiBCdXQgdGhp
cyBkb2VzIG5vdCB3b3JrIGZvciB0aGVyZSBpcyBjb21waWxpbmcgZXJyb3IuDQo+IFdoeSB3b3Vs
ZG4ndCB0aGlzIHdvcms/DQo+IFtKWV0gVGhlIG9yaWdpbmFsIGludGVudGlvbiBvZiB0aGUgMTU4
OCBpbmZvIG1vZGVsIGlzIHRvIHVzZSBteS1wb3J0LWNvbnRhaW5lci5wb3J0LW51bWJlciBhcyB0
aGUga2V5LiBUaGUgY29kZSBhY3R1YWxseSBwYXJzZXMsIGJ1dCB3ZSBuZWVkIHRvIHN5bmNocm9u
aXplIG15LWxpc3QucG9ydC1udW1iZXIgYW5kIG15LWxpc3QubXktcG9ydC1jb250YWluZXIucG9y
dC1udW1iZXIgYWxsIHRoZSB3aGlsZS4NCj4NCj4gSSBzdXNwZWN0IHlvdSBtZWFudDoNCj4NCj4g
ICAgIGxpc3QgbXktbGlzdCB7DQo+ICAgICAgIGtleSAicG9ydC1udW1iZXIiOw0KPiAgIA0KPiAg
ICAgICBjb250YWluZXIgbXktcG9ydC1jb250YWluZXIgew0KPiAgICAgICAgICAgbGVhZiBwb3J0
LW51bWJlciB7DQo+ICAgICAgICAgICAgdHlwZSB1aW50MTY7DQo+ICAgICAgICAgICB9DQo+ICAg
ICAgICAgICAgbGVhZiBvdGhlci1sZWFmIHsNCj4gICAgICAgICAgICAgIC4uLg0KPiAgICAgICAg
ICAgIH0NCj4gICAgICAgfQ0KPiAgICAgfQ0KPg0KPg0KPj4gMi4NCj4+ICAgIGxpc3QgbXktbGlz
dCB7DQo+PiAgICAgIGtleSAicG9ydC1udW1iZXIiOw0KPj4gICAgICBsZWFmIHBvcnQtbnVtYmVy
IHsNCj4+ICAgICAgICAgdHlwZSB1aW50MTY7DQo+PiAgICAgIH0NCj4+ICAgICAgY29udGFpbmVy
IG15LXBvcnQtY29udGFpbmVyIHsNCj4+ICAgICAgICAgIGxlYWYgcG9ydC1udW1iZXIgew0KPj4g
ICAgICAgICAgICAgIHR5cGUgbGVhZnJlZnsNCj4+ICAgICAgICAgICAgICAgIHBhdGggIi4uLy4u
L3BvcnQtbnVtYmVyIjsNCj4+ICAgICAgICAgICAgICB9DQo+PiAgICAgICAgICB9DQo+PiAgICAg
ICAgICAgbGVhZiBvdGhlci1sZWFmIHsNCj4+ICAgICAgICAgICAgIC4uLg0KPj4gICAgICAgICAg
IH0NCj4+ICAgICAgfQ0KPj4gICAgfQ0KPj4gT3B0aW9uIDIgY2FuIHBhcnNlLCB0aG91Z2ggbGVh
ZnJlZiBpbiBhIHN1Yi1tb2R1bGUgc2VlbXMgbm90IHZlcnkgDQo+PiBuYXR1cmFsLg0KPj4NCj4+
IDMuDQo+PiAgICBsaXN0IG15LWxpc3Qgew0KPj4gICAgICBrZXkgInBvcnQtbnVtYmVyIjsNCj4+
ICAgICAgbGVhZiBwb3J0LW51bWJlciB7DQo+PiAgICAgICAgIHR5cGUgbGVhZnJlZnsNCj4+ICAg
ICAgICAgICAgcGF0aCAiLi4vbXktcG9ydC1jb250YWluZXIvcG9ydC1udW1iZXIiOw0KPj4gICAg
ICAgICB9DQo+PiAgICAgIH0NCj4+ICAgICAgY29udGFpbmVyIG15LXBvcnQtY29udGFpbmVyIHsN
Cj4+ICAgICAgICAgIGxlYWYgcG9ydC1udW1iZXIgew0KPj4gICAgICAgICAgICB0eXBlIHVpbnQx
NjsNCj4+ICAgICAgICAgIH0NCj4+ICAgICAgICAgICBsZWFmIG90aGVyLWxlYWYgew0KPj4gICAg
ICAgICAgICAgLi4uDQo+PiAgICAgICAgICAgfQ0KPj4gICAgICB9DQo+PiAgICB9DQo+Pg0KPj4g
T3B0aW9uIDMgY2FuIGFsc28gcGFyc2UsIHRob3VnaCBsZWFmcmVmIHNlZW1zIG5vdCBhIHZlcnkg
bmF0dXJhbCBrZXkuDQo+PiBXaGF0IGlzIHlvdXIgZmF2b3JpdGUgb3B0aW9uPyBPciBkbyB5b3Ug
aGF2ZSBhbnkgYmV0dGVyIHNjaGVtZXM/DQo+DQo+IEhhdmluZyBhIGxlYWZyZWYgbGlrZSBpbiBv
cHRpb24gMiBvciAzIGlzIGp1c3QgcmVkdW5kYW50IGFuZCBhIGhhc3NsZSBmb3IgdGhlIGNsaWVu
dC4gIEluIG9yZGVyIHRvIGNyZWF0ZSBhIGEgbGlzdCBlbnRyeSwgdGhlIGNsaWVudCB3b3VsZCBo
YXZlIHRvIGZpcnN0IHByb3ZpZGUgdGhlIHBvcnQtbnVtYmVyIHZhbHVlIG9uY2UgZm9yIHRoZSBr
ZXksIGFuZCB0aGVuIGFnYWluIHRoZSBleGFjdCBzYW1lIHZhbHVlIGluIHRoZSBjb250YWluZXI6
DQo+DQo+ICAgIDxteS1saXN0Pg0KPiAgICAgIDxwb3J0LW51bWJlcj4yNTwvcG9ydC1udW1iZXI+
DQo+ICAgICAgPG15LXBvcnQtY29udGFpbmVyPg0KPiAgICAgICAgPHBvcnQtbnVtYmVyPjI1PC9w
b3J0LW51bWJlcj4NCj4gICAgICAgIDxvdGhlci1sZWFmPi4uLjwvb3RoZXItbGVhZj4NCj4gICAg
ICA8L215LXBvcnQtY29udGFpbmVyPg0KPiAgICA8L215LWxpc3Q+DQo+DQo+IE5vdGUgdGhhdCBi
b3RoICJwb3J0LW51bWJlciIgTVVTVCBiZSBnaXZlbiB0aGUgZXhhY3Qgc2FtZSB2YWx1ZSBieSB0
aGUgY2xpZW50Lg0KPg0KPiBJbiBZQU5HLCBrZXkgbGVhZnMgY2Fubm90IGJlIG5lc3RlZCB1bmRl
ciBjb250YWluZXJzLiAgSSB3b3VsZCBzaW1wbHkgaGF2ZSB0aGUga2V5IG9uIHRoZSB0b3Agb2Yg
dGhlIGxpc3QsIGFuZCBub3QgaW4gdGhlIGNvbnRhaW5lci4NCj4NCj4gKEl0IHNlZW1zIHRoaXMg
aXMgd2hhdCBvdGhlcnMgaGF2ZSBwcm9wb3NlZCBhcyB3ZWxsIGluIHRoaXMgdGhyZWFkLikNCj4N
Cj4gW0pZXSBZZXMsIEkgYWdyZWUgdGhhdCB0aGlzIG1vZGVsIGlzIG5vdCB2ZXJ5IGVsZWdhbnQs
IGJ1dCB0aGUgaW5mbyBtb2RlbCB3YXMgcHVibGlzaGVkIGluIElFRUUgMTU4OCBhbHJlYWR5LCBw
ZW9wbGUgaGF2ZSBiZWVuIHVzZWQgdG8gdGhpcyBpbmZvIG1vZGVsIGZvciBhIGxvbmcgdGltZSBh
bmQgd2Ugd291bGQgbGlrZSB0byBzdGljayB0byBpdCBhcyBmYXIgYXMgd2UgY2FuLg0KPiBBcyBh
biBhbHRlcm5hdGl2ZSwgb3B0aW9uIDIgY2FuIGJlIGVuaGFuY2VkOg0KPiAgICAgbGlzdCBteS1s
aXN0IHsNCj4gICAgICAga2V5ICJwb3J0LW51bWJlciI7DQo+ICAgICAgIGxlYWYgcG9ydC1udW1i
ZXIgew0KPiAgICAgICAgICB0eXBlIHVpbnQxNjsNCj4gICAgICAgfQ0KPiAgICAgICBjb250YWlu
ZXIgbXktcG9ydC1jb250YWluZXIgew0KPiAgICAgICAgICAgbGVhZiBwb3J0LW51bWJlciB7DQo+
ICAgICAgICAgICAgICAgdHlwZSBsZWFmcmVmew0KPiAgICAgICAgICAgICAgICAgcGF0aCAiLi4v
Li4vcG9ydC1udW1iZXIiOw0KPiAgICAgICAgICAgICAgIH0NCj4gICAgICAgICAgICAgICBjb25m
aWcgZmFsc2U7DQo+ICAgICAgICAgICB9DQo+ICAgICAgICAgICBsZWFmIG90aGVyLWxlYWYgew0K
PiAgICAgICAgICAgICAuLi4NCj4gICAgICAgICB9DQo+ICAgICAgIH0NCj4gICAgIH0NCj4NCj4g
SW4gdGhpcyB3YXksIHRoZSAiY29uZmlnIGZhbHNlIiBtYWtlcyB0aGUgbGVhZnJlZiByZWFkLW9u
bHksIHNvIHRoYXQgY29uZmlndXJhdGlvbiBkb2Vzbid0IG5lZWQgdG8gd3JpdGUgdHdpY2UuIEhv
dyBkbyB5b3UgdGhpbmsgYWJvdXQgdGhpcyBzY2hlbWU/DQo+IFRoYW5rcyBhZ2FpbiwNCj4gWXVh
bmxvbmcNCj4NCj4NCj4gL21hcnRpbg0KPg0KPg0KPg0KPg0KPg0KPj4gWW91ciBvcGluaW9ucyBh
cmUgdmVyeSBpbXBvcnRhbnQgZm9yIG91ciByZXZpc2lvbiBvZiB0aGlzIGRyYWZ0Lg0KPj4NCj4+
IFRoYW5rcywNCj4+IFl1YW5sb25nDQo+Pg0KPj4NCj4+IEZyb206IFNlYW4gQ29uZG9uIFttYWls
dG86c2Vhbi5jb25kb25AbWljcm9zZW1pLmNvbV0NCj4+IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVt
YmVyIDI3LCAyMDE3IDc6MTEgUE0NCj4+IFRvOiBKaWFuZ3l1YW5sb25nDQo+PiBDYzogdGljdG9j
QGlldGYub3JnOyBSb2RuZXkgQ3VtbWluZ3MNCj4+IFN1YmplY3Q6IFJFOiBkcmFmdC1pZXRmLXRp
Y3RvYy0xNTg4djIteWFuZy0wNSAtIENvbmNlcm4gb3ZlciBwb3J0IA0KPj4gaWRlbnRpZmllcg0K
Pj4NCj4+IFRoYW5rcyBndXlzIGZvciB5b3VyIHJlc3BvbnNlcy4NCj4+DQo+PiBJIGFjY2VwdCB5
b3VyIHBvaW50cyB0byBrZWVwIHRoZSBzdHJ1Y3R1cmUgYXMgYWxpZ25lZCB0byB0aGUgSUVFRSAN
Cj4+IDE1ODggc3RhbmRhcmQgYXMgcG9zc2libGUuDQo+Pg0KPj4gT25lIGFsdGVybmF0ZSBzdWdn
ZXN0aW9uIHRoYXQgSSB3b3VsZCBtYWtlLCBpcyB0aGF0IHRoZSBwb3J0LW51bWJlciANCj4+IGN1
cnJlbnRseSBkZWZpbmVkIGFzIGxlYWZyZWYgc2hvdWxkIGJlIG1hZGUgdGhlIHJlYWwgYXR0cmli
dXRlIChpLmUuDQo+PiB1aW50MTYpIGFuZCB0aGF0IHRoZSBwb3J0LW51bWJlciBpbnNpZGUgcG9y
dC1pZGVudGl0eSBjb250YWluZXIgDQo+PiBzaG91bGQgYmUgbWFkZSBpbiB0byB0aGUgbGVhZiBy
ZWYgKGFuZCBzZXQgdG8gbWFuZGF0b3J5IHRydWUpLg0KPj4NCj4+IFRoZSByZWFzb24gSSBzYXkg
dGhpcyBpcyB0aGF0DQo+Pg0KPj4gICAgMS4gIFhNTCBtb2RlbHMgYXJlIHVzdWFsbHkgbmF2aWdh
dGVkIGFuZCBjb25zdHJ1Y3RlZCByb290LXRvLWxlYWYsIGFuZA0KPj4gICAgdGhlIHdheSBpdCdz
IHBvcnRyYXllZCBhdCB0aGUgbW9tZW50IGlzIHRoYXQgcG9ydC1udW1iZXIgbGVhZnJlZg0KPj4g
ICAgcG9pbnRzIHRvIHNvbWV0aGluZyB0aGF0IG1heSBub3QgZXhpc3QgYXQgdGhlIHRpbWUgaXQg
aXMgYmVpbmcNCj4+ICAgIGRlZmluZWQuIFRoaXMgbWFrZXMgaXQgZGlmZmljdWx0IHRvIGltcGxl
bWVudC4NCj4+ICAgIDIuICBBbHNvIHBvcnQtaWRlbnRpdHkvcG9ydC1udW1iZXIgaXMgbm90ICJt
YW5kYXRvcnkgdHJ1ZSIgbWVhbmluZw0KPj4gICAgdGhhdCBpdCBjb3VsZCBiZSBsZWZ0IG91dCBh
bHRvZ2V0aGVyLiBJdCdzIG5vdCB2YWxpZCBmb3IgaXQgdG8gaGF2ZSBhDQo+PiAgICBkZWZhdWx0
IHZhbHVlIGVpdGhlciBzaW5jZSBldmVyeSBpdGVtIGluIHRoZSBsaXN0IHdpbGwgbmVlZCBhDQo+
PiAgICBkaWZmZXJlbnQgaWRlbnRpZmllci4NCj4+DQo+PiBXaXRoIHRoaXMgc3VnZ2VzdGlvbiB0
aGUgc3RydWN0dXJlIHlvdSByZXF1aXJlIHdpdGggcG9ydC1pZGVudGl0eSANCj4+IHN0aWxsIGV4
aXN0cywgYnV0IG5vdyB0aGUgaW1wbGVtZW50YXRpb24gaXMgbW9yZSBzdHJhaWdodGZvcndhcmQs
IGFuZCANCj4+IHRoZSBjaGFuZ2Ugd2lsbCBiZSB0cmFuc3BhcmVudCB0byBhbiBlbmQgdXNlci4N
Cj4+DQo+Pg0KPj4gQmVzdCByZWdhcmRzLCBTZWFuDQo+PiA9PT09PT09PT09PT09PT09PT09PT09
PQ0KPj4gU2VhbiBDb25kb24NCj4+IFN5c3RlbSAmIFNvZnR3YXJlIEFyY2hpdGVjdA0KPj4gRnJl
cXVlbmN5ICYgVGltaW5nIERpdmlzaW9uDQo+PiBNaWNyb3NlbWkgSW5jLg0KPj4gc2Vhbi5jb25k
b25AbWljcm9zZW1pLmNvbTxtYWlsdG86c2Vhbi5jb25kb25AbWljcm9zZW1pLmNvbT4NCj4+DQo+
PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gRnJvbTogSmlhbmd5dWFubG9u
ZyBbamlhbmd5dWFubG9uZ0BodWF3ZWkuY29tXQ0KPj4gU2VudDogMjcgU2VwdGVtYmVyIDIwMTcg
MDg6MDUNCj4+IFRvOiBTZWFuIENvbmRvbg0KPj4gQ2M6IHRpY3RvY0BpZXRmLm9yZzxtYWlsdG86
dGljdG9jQGlldGYub3JnPjsgUm9kbmV5IEN1bW1pbmdzDQo+PiBTdWJqZWN0OiBSRTogZHJhZnQt
aWV0Zi10aWN0b2MtMTU4OHYyLXlhbmctMDUgLSBDb25jZXJuIG92ZXIgcG9ydCANCj4+IGlkZW50
aWZpZXIgRVhURVJOQUwgRU1BSUwNCj4+DQo+PiBEZWFyIFNlYW4sDQo+Pg0KPj4NCj4+DQo+PiBU
aGFuayB5b3UgYSBsb3QgZm9yIGRpdmluZyBpbnRvIHRoZSB0ZWNobmljYWwgZGV0YWlscyBvZiB0
aGlzIG1vZHVsZS4NCj4+IEp1c3QgYXMgUm9kbmV5IHNhaWQsIGl0IGlzIGEgY2hhbGxlbmdlIG9m
IDE1ODggaW5mbyBtb2RlbCB0byBZQU5HLCANCj4+IGFuZCB3ZSB1c2UgdGhlIGxlYWZyZWYgb2Yg
WUFORyB0byB3b3JrIGFyb3VuZCBpdC4NCj4+DQo+PiBJIHdvdWxkIGxpa2UgdG8gcHJvdmlkZSBh
IGxpdHRsZSBtb3JlIGJhY2tncm91bmRzIG9uIHRoZSB0cmFkZW9mZjoNCj4+DQo+Pg0KPj4NCj4+
IDEuIEl0IHNheXMgaW4gU2VjLiA3LjUuMi4xIGluIElFRUUgMTU4OC0yMDA4OiBwb3J0SWRlbnRp
dHkgaXMgYSANCj4+IG1lbWJlciBvZiB0aGUgcG9ydERTIGRhdGEgc2V0LiBBIHBvcnRJZGVudGl0
eSBjb25zaXN0cyBvZiB0d28gDQo+PiBhdHRyaWJ1dGVzLCBhcw0KPj4NCj4+IGZvbGxvd3M6DQo+
Pg0KPj4g4o6vIHBvcnRJZGVudGl0eS5jbG9ja0lkZW50aXR5DQo+Pg0KPj4g4o6vIHBvcnRJZGVu
dGl0eS5wb3J0TnVtYmVyDQo+Pg0KPj4gRnVydGhlcm1vcmUsIHRoZSAicG9ydERTLnBvcnRJZGVu
dGl0eSIgYXR0cmlidXRlIGlzIG1lbnRpb25lZCBxdWl0ZSBhIA0KPj4gZmV3IHRpbWVzIGluIDE1
ODgtMjAwOCwgZXNwZWNpYWxseSBpbiBUYWJsZSAxNyBhbmQgdW5kZXIgVGFibGUgNjEsIA0KPj4g
d2l0aCBhIGhpbnQgdGhhdCBhc3NpZ25tZW50IGFuZCBjb21wYXJpc29uIGNhbiBiZSBkb25lIG9u
IHRoaXMgbWVtYmVyIA0KPj4gZGlyZWN0bHksIHRodXMgaXQgc2VlbXMgdG8gbWUgcG9ydElkZW50
aXR5IGlzIGFuIGltcG9ydGFudCBhbmQgd2VsbCANCj4+IHVuZGVyc3Rvb2QgY29uc3RydWN0IGlu
IHRoZSAxNTg4IHNwZWNpZmljYXRpb24uDQo+Pg0KPj4NCj4+DQo+PiAyLiBJZiB3ZSBjaGFuZ2Ug
cG9ydERTLnBvcnRJZGVudGl0eSBmcm9tIGEgY29udGFpbmVyIHRvIGEgZ3JvdXBpbmcsIA0KPj4g
dGhlbiB0aGVyZSBpcyBubyBwb3J0SWRlbnRpdHkgZm9yIHBvcnREUyBhbmQgdHJhbnNwYXJlbnRj
bG9ja1BvcnREUyANCj4+IGluIHRoZSByZXN1bHRpbmcgdHJlZSBkaWFncmFtOg0KPj4NCj4+DQo+
Pg0KPj4gbW9kdWxlOiBpZXRmLXB0cC1kYXRhc2V0DQo+Pg0KPj4gICAgICArLS1ydyBpbnN0YW5j
ZS1saXN0KiBbaW5zdGFuY2UtbnVtYmVyXQ0KPj4NCj4+ICAgICAgfCAgKy0tcncgaW5zdGFuY2Ut
bnVtYmVyICAgICAgIHVpbnQxNg0KPj4NCj4+ICAgICAgfCAgKy0tcncgZGVmYXVsdC1kcw0KPj4N
Cj4+ICAgICAgfCAgfCAgKy0tcncgdHdvLXN0ZXAtZmxhZz8gICAgYm9vbGVhbg0KPj4NCj4+ICAg
ICAgfCAgfCAgKy0tcncgY2xvY2staWRlbnRpdHk/ICAgY2xvY2staWRlbnRpdHktdHlwZQ0KPj4N
Cj4+ICAgICAgfCAgfCAgKy0tcncgbnVtYmVyLXBvcnRzPyAgICAgdWludDE2DQo+Pg0KPj4gICAg
ICB8ICB8ICArLS1ydyBjbG9jay1xdWFsaXR5DQo+Pg0KPj4gICAgICB8ICB8ICB8ICArLS1ydyBj
bG9jay1jbGFzcz8gICAgICAgICAgICAgICAgICB1aW50OA0KPj4NCj4+ICAgICAgfCAgfCAgfCAg
Ky0tcncgY2xvY2stYWNjdXJhY3k/ICAgICAgICAgICAgICAgdWludDgNCj4+DQo+PiAgICAgIHwg
IHwgIHwgICstLXJ3IG9mZnNldC1zY2FsZWQtbG9nLXZhcmlhbmNlPyAgIHVpbnQxNg0KPj4NCj4+
ICAgICAgfCAgfCAgKy0tcncgcHJpb3JpdHkxPyAgICAgICAgdWludDgNCj4+DQo+PiAgICAgIHwg
IHwgICstLXJ3IHByaW9yaXR5Mj8gICAgICAgIHVpbnQ4DQo+Pg0KPj4gICAgICB8ICB8ICArLS1y
dyBkb21haW4tbnVtYmVyPyAgICB1aW50OA0KPj4NCj4+ICAgICAgfCAgfCAgKy0tcncgc2xhdmUt
b25seT8gICAgICAgYm9vbGVhbg0KPj4NCj4+ICAgICAgfCAgKy0tcncgY3VycmVudC1kcw0KPj4N
Cj4+ICAgICAgfCAgfCAgKy0tcncgc3RlcHMtcmVtb3ZlZD8gICAgICAgIHVpbnQxNg0KPj4NCj4+
ICAgICAgfCAgfCAgKy0tcncgb2Zmc2V0LWZyb20tbWFzdGVyPyAgIHRpbWUtaW50ZXJ2YWwtdHlw
ZQ0KPj4NCj4+ICAgICAgfCAgfCAgKy0tcncgbWVhbi1wYXRoLWRlbGF5PyAgICAgIHRpbWUtaW50
ZXJ2YWwtdHlwZQ0KPj4NCj4+ICAgICAgfCAgKy0tcncgcGFyZW50LWRzDQo+Pg0KPj4gICAgICB8
ICB8ICArLS1ydyBwYXJlbnQtcG9ydC1pZGVudGl0eQ0KPj4NCj4+ICAgICAgfCAgfCAgfCAgKy0t
cncgY2xvY2staWRlbnRpdHk/ICAgY2xvY2staWRlbnRpdHktdHlwZQ0KPj4NCj4+ICAgICAgfCAg
fCAgfCAgKy0tcncgcG9ydC1udW1iZXI/ICAgICAgdWludDE2DQo+Pg0KPj4gICAgICB8ICB8ICAr
LS1ydyBwYXJlbnQtc3RhdHM/ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYm9vbGVh
bg0KPj4NCj4+ICAgICAgfCAgfCAgKy0tcncgb2JzZXJ2ZWQtcGFyZW50LW9mZnNldC1zY2FsZWQt
bG9nLXZhcmlhbmNlPyAgIHVpbnQxNg0KPj4NCj4+ICAgICAgfCAgfCAgKy0tcncgb2JzZXJ2ZWQt
cGFyZW50LWNsb2NrLXBoYXNlLWNoYW5nZS1yYXRlPyAgICAgIGludDMyDQo+Pg0KPj4gICAgICB8
ICB8ICArLS1ydyBncmFuZG1hc3Rlci1pZGVudGl0eT8gICAgICAgICAgICAgICAgICAgICAgICAg
YmluYXJ5DQo+Pg0KPj4gICAgICB8ICB8ICArLS1ydyBncmFuZG1hc3Rlci1jbG9jay1xdWFsaXR5
DQo+Pg0KPj4gICAgICB8ICB8ICB8ICArLS1ydyBjbG9jay1jbGFzcz8gICAgICAgICAgICAgICAg
ICB1aW50OA0KPj4NCj4+ICAgICAgfCAgfCAgfCAgKy0tcncgY2xvY2stYWNjdXJhY3k/ICAgICAg
ICAgICAgICAgdWludDgNCj4+DQo+PiAgICAgIHwgIHwgIHwgICstLXJ3IG9mZnNldC1zY2FsZWQt
bG9nLXZhcmlhbmNlPyAgIHVpbnQxNg0KPj4NCj4+ICAgICAgfCAgfCAgKy0tcncgZ3JhbmRtYXN0
ZXItcHJpb3JpdHkxPyAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQ4DQo+Pg0KPj4gICAgICB8
ICB8ICArLS1ydyBncmFuZG1hc3Rlci1wcmlvcml0eTI/ICAgICAgICAgICAgICAgICAgICAgICAg
dWludDgNCj4+DQo+PiAgICAgIHwgICstLXJ3IHRpbWUtcHJvcGVydGllcy1kcw0KPj4NCj4+ICAg
ICAgfCAgfCAgKy0tcncgY3VycmVudC11dGMtb2Zmc2V0LXZhbGlkPyAgIGJvb2xlYW4NCj4+DQo+
PiAgICAgIHwgIHwgICstLXJ3IGN1cnJlbnQtdXRjLW9mZnNldD8gICAgICAgICBpbnQxNg0KPj4N
Cj4+ICAgICAgfCAgfCAgKy0tcncgbGVhcDU5PyAgICAgICAgICAgICAgICAgICAgIGJvb2xlYW4N
Cj4+DQo+PiAgICAgIHwgIHwgICstLXJ3IGxlYXA2MT8gICAgICAgICAgICAgICAgICAgICBib29s
ZWFuDQo+Pg0KPj4gICAgICB8ICB8ICArLS1ydyB0aW1lLXRyYWNlYWJsZT8gICAgICAgICAgICAg
Ym9vbGVhbg0KPj4NCj4+ICAgICAgfCAgfCAgKy0tcncgZnJlcXVlbmN5LXRyYWNlYWJsZT8gICAg
ICAgIGJvb2xlYW4NCj4+DQo+PiAgICAgIHwgIHwgICstLXJ3IHB0cC10aW1lc2NhbGU/ICAgICAg
ICAgICAgICBib29sZWFuDQo+Pg0KPj4gICAgICB8ICB8ICArLS1ydyB0aW1lLXNvdXJjZT8gICAg
ICAgICAgICAgICAgdWludDgNCj4+DQo+PiAgICAgIHwgICstLXJ3IHBvcnQtZHMtbGlzdCogW3Bv
cnQtbnVtYmVyXQ0KPj4NCj4+ICAgICAgfCAgICAgKy0tcncgY2xvY2staWRlbnRpdHk/ICAgICAg
ICAgICAgICAgIGNsb2NrLWlkZW50aXR5LXR5cGUNCj4+DQo+PiAgICAgIHwgICAgICstLXJ3IHBv
cnQtbnVtYmVyICAgICAgICAgICAgICAgICAgICB1aW50MTYNCj4+DQo+PiAgICAgIHwgICAgICst
LXJ3IHBvcnQtc3RhdGU/ICAgICAgICAgICAgICAgICAgICBwb3J0LXN0YXRlLWVudW1lcmF0aW9u
DQo+Pg0KPj4gICAgICB8ICAgICArLS1ydyB1bmRlcmx5aW5nLWludGVyZmFjZT8gICAgICAgICAg
aWY6aW50ZXJmYWNlLXJlZg0KPj4NCj4+ICAgICAgfCAgICAgKy0tcncgbG9nLW1pbi1kZWxheS1y
ZXEtaW50ZXJ2YWw/ICAgIGludDgNCj4+DQo+PiAgICAgIHwgICAgICstLXJ3IHBlZXItbWVhbi1w
YXRoLWRlbGF5PyAgICAgICAgICB0aW1lLWludGVydmFsLXR5cGUNCj4+DQo+PiAgICAgIHwgICAg
ICstLXJ3IGxvZy1hbm5vdW5jZS1pbnRlcnZhbD8gICAgICAgICBpbnQ4DQo+Pg0KPj4gICAgICB8
ICAgICArLS1ydyBhbm5vdW5jZS1yZWNlaXB0LXRpbWVvdXQ/ICAgICAgdWludDgNCj4+DQo+PiAg
ICAgIHwgICAgICstLXJ3IGxvZy1zeW5jLWludGVydmFsPyAgICAgICAgICAgICBpbnQ4DQo+Pg0K
Pj4gICAgICB8ICAgICArLS1ydyBkZWxheS1tZWNoYW5pc20/ICAgICAgICAgICAgICAgZGVsYXkt
bWVjaGFuaXNtLWVudW1lcmF0aW9uDQo+Pg0KPj4gICAgICB8ICAgICArLS1ydyBsb2ctbWluLXBk
ZWxheS1yZXEtaW50ZXJ2YWw/ICAgaW50OA0KPj4NCj4+ICAgICAgfCAgICAgKy0tcncgdmVyc2lv
bi1udW1iZXI/ICAgICAgICAgICAgICAgIHVpbnQ4DQo+Pg0KPj4gICAgICArLS1ydyB0cmFuc3Bh
cmVudC1jbG9jay1kZWZhdWx0LWRzDQo+Pg0KPj4gICAgICB8ICArLS1ydyBjbG9jay1pZGVudGl0
eT8gICAgY2xvY2staWRlbnRpdHktdHlwZQ0KPj4NCj4+ICAgICAgfCAgKy0tcncgbnVtYmVyLXBv
cnRzPyAgICAgIHVpbnQxNg0KPj4NCj4+ICAgICAgfCAgKy0tcncgZGVsYXktbWVjaGFuaXNtPyAg
IGRlbGF5LW1lY2hhbmlzbS1lbnVtZXJhdGlvbg0KPj4NCj4+ICAgICAgfCAgKy0tcncgcHJpbWFy
eS1kb21haW4/ICAgIHVpbnQ4DQo+Pg0KPj4gICAgICArLS1ydyB0cmFuc3BhcmVudC1jbG9jay1w
b3J0LWRzLWxpc3QqIFtwb3J0LW51bWJlcl0NCj4+DQo+PiAgICAgICAgICstLXJ3IGNsb2NrLWlk
ZW50aXR5PyAgICAgICAgICAgICAgICBjbG9jay1pZGVudGl0eS10eXBlDQo+Pg0KPj4gICAgICAg
ICArLS1ydyBwb3J0LW51bWJlciAgICAgICAgICAgICAgICAgICAgdWludDE2DQo+Pg0KPj4gICAg
ICAgICArLS1ydyBsb2ctbWluLXBkZWxheS1yZXEtaW50ZXJ2YWw/ICAgaW50OA0KPj4NCj4+ICAg
ICAgICAgKy0tcncgZmF1bHR5LWZsYWc/ICAgICAgICAgICAgICAgICAgIGJvb2xlYW4NCj4+DQo+
PiAgICAgICAgICstLXJ3IHBlZXItbWVhbi1wYXRoLWRlbGF5PyAgICAgICAgICB0aW1lLWludGVy
dmFsLXR5cGUNCj4+DQo+Pg0KPj4NCj4+IEluIGNvbnRyYXN0IHRvIHRoZSBvcmlnaW5hbCAxNTg4
IFlBTkcgdHJlZSBkaWFncmFtOg0KPj4NCj4+ICAgICBtb2R1bGU6IGlldGYtcHRwLWRhdGFzZXQN
Cj4+DQo+PiAgICAgICAgICstLXJ3IGluc3RhbmNlLWxpc3QqIFtpbnN0YW5jZS1udW1iZXJdDQo+
Pg0KPj4gICAgICAgICB8ICArLS1ydyBpbnN0YW5jZS1udW1iZXIgICAgICB1aW50MTYNCj4+DQo+
PiAgICAgICAgIHwgICstLXJ3IGRlZmF1bHQtZHMNCj4+DQo+PiAgICAgICAgIHwgIHwgICstLXJ3
IHR3by1zdGVwLWZsYWc/ICAgIGJvb2xlYW4NCj4+DQo+PiAgICAgICAgIHwgIHwgICstLXJ3IGNs
b2NrLWlkZW50aXR5PyAgIGNsb2NrLWlkZW50aXR5LXR5cGUNCj4+DQo+PiAgICAgICAgIHwgIHwg
ICstLXJ3IG51bWJlci1wb3J0cz8gICAgIHVpbnQxNg0KPj4NCj4+ICAgICAgICAgfCAgfCAgKy0t
cncgY2xvY2stcXVhbGl0eQ0KPj4NCj4+ICAgICAgICAgfCAgfCAgfCAgKy0tcncgY2xvY2stY2xh
c3M/ICAgICAgICAgICAgICAgICAgdWludDgNCj4+DQo+PiAgICAgICAgIHwgIHwgIHwgICstLXJ3
IGNsb2NrLWFjY3VyYWN5PyAgICAgICAgICAgICAgIHVpbnQ4DQo+Pg0KPj4gICAgICAgICB8ICB8
ICB8ICArLS1ydyBvZmZzZXQtc2NhbGVkLWxvZy12YXJpYW5jZT8gICB1aW50MTYNCj4+DQo+PiAg
ICAgICAgIHwgIHwgICstLXJ3IHByaW9yaXR5MT8gICAgICAgIHVpbnQ4DQo+Pg0KPj4gICAgICAg
ICB8ICB8ICArLS1ydyBwcmlvcml0eTI/ICAgICAgICB1aW50OA0KPj4NCj4+ICAgICAgICAgfCAg
fCAgKy0tcncgZG9tYWluLW51bWJlcj8gICAgdWludDgNCj4+DQo+PiAgICAgICAgIHwgIHwgICst
LXJ3IHNsYXZlLW9ubHk/ICAgICAgIGJvb2xlYW4NCj4+DQo+PiAgICAgICAgIHwgICstLXJ3IGN1
cnJlbnQtZHMNCj4+DQo+PiAgICAgICAgIHwgIHwgICstLXJ3IHN0ZXBzLXJlbW92ZWQ/ICAgICAg
IHVpbnQxNg0KPj4NCj4+ICAgICAgICAgfCAgfCAgKy0tcncgb2Zmc2V0LWZyb20tbWFzdGVyPyAg
dGltZS1pbnRlcnZhbC10eXBlDQo+Pg0KPj4gICAgICAgICB8ICB8ICArLS1ydyBtZWFuLXBhdGgt
ZGVsYXk/ICAgICB0aW1lLWludGVydmFsLXR5cGUNCj4+DQo+PiAgICAgICAgIHwgICstLXJ3IHBh
cmVudC1kcw0KPj4NCj4+ICAgICAgICAgfCAgfCAgKy0tcncgcGFyZW50LXBvcnQtaWRlbnRpdHkN
Cj4+DQo+PiAgICAgICAgIHwgIHwgIHwgICstLXJ3IGNsb2NrLWlkZW50aXR5PyAgIGNsb2NrLWlk
ZW50aXR5LXR5cGUNCj4+DQo+PiAgICAgICAgIHwgIHwgIHwgICstLXJ3IHBvcnQtbnVtYmVyPyAg
ICAgIHVpbnQxNg0KPj4NCj4+ICAgICAgICAgfCAgfCAgKy0tcncgcGFyZW50LXN0YXRzPyAgICAg
ICAgYm9vbGVhbg0KPj4NCj4+ICAgICAgICAgfCAgfCAgKy0tcncgb2JzZXJ2ZWQtcGFyZW50LW9m
ZnNldC1zY2FsZWQtbG9nLXZhcmlhbmNlPyANCj4+IHVpbnQxNg0KPj4NCj4+ICAgICAgICAgfCAg
fCAgKy0tcncgb2JzZXJ2ZWQtcGFyZW50LWNsb2NrLXBoYXNlLWNoYW5nZS1yYXRlPyAgICBpbnQz
Mg0KPj4NCj4+ICAgICAgICAgfCAgfCAgKy0tcncgZ3JhbmRtYXN0ZXItaWRlbnRpdHk/ICAgICAg
ICAgICAgICAgICAgICAgICBiaW5hcnkNCj4+DQo+PiAgICAgICAgIHwgIHwgICstLXJ3IGdyYW5k
bWFzdGVyLWNsb2NrLXF1YWxpdHkNCj4+DQo+PiAgICAgICAgIHwgIHwgIHwgICstLXJ3IGNsb2Nr
LWNsYXNzPyAgICAgICAgICAgICAgICAgIHVpbnQ4DQo+Pg0KPj4gICAgICAgICB8ICB8ICB8ICAr
LS1ydyBjbG9jay1hY2N1cmFjeT8gICAgICAgICAgICAgICB1aW50OA0KPj4NCj4+ICAgICAgICAg
fCAgfCAgfCAgKy0tcncgb2Zmc2V0LXNjYWxlZC1sb2ctdmFyaWFuY2U/ICAgdWludDE2DQo+Pg0K
Pj4gICAgICAgICB8ICB8ICArLS1ydyBncmFuZG1hc3Rlci1wcmlvcml0eTE/ICAgICAgICAgICB1
aW50OA0KPj4NCj4+ICAgICAgICAgfCAgfCAgKy0tcncgZ3JhbmRtYXN0ZXItcHJpb3JpdHkyPyAg
ICAgICAgICAgdWludDgNCj4+DQo+PiAgICAgICAgIHwgICstLXJ3IHRpbWUtcHJvcGVydGllcy1k
cw0KPj4NCj4+ICAgICAgICAgfCAgfCAgKy0tcncgY3VycmVudC11dGMtb2Zmc2V0LXZhbGlkPyAg
IGJvb2xlYW4NCj4+DQo+PiAgICAgICAgIHwgIHwgICstLXJ3IGN1cnJlbnQtdXRjLW9mZnNldD8g
ICAgICAgICBpbnQxNg0KPj4NCj4+ICAgICAgICAgfCAgfCAgKy0tcncgbGVhcDU5PyAgICAgICAg
ICAgICAgICAgICAgIGJvb2xlYW4NCj4+DQo+PiAgICAgICAgIHwgIHwgICstLXJ3IGxlYXA2MT8g
ICAgICAgICAgICAgICAgICAgICBib29sZWFuDQo+Pg0KPj4gICAgICAgICB8ICB8ICArLS1ydyB0
aW1lLXRyYWNlYWJsZT8gICAgICAgICAgICAgYm9vbGVhbg0KPj4NCj4+ICAgICAgICAgfCAgfCAg
Ky0tcncgZnJlcXVlbmN5LXRyYWNlYWJsZT8gICAgICAgIGJvb2xlYW4NCj4+DQo+PiAgICAgICAg
IHwgIHwgICstLXJ3IHB0cC10aW1lc2NhbGU/ICAgICAgICAgICAgICBib29sZWFuDQo+Pg0KPj4g
ICAgICAgICB8ICB8ICArLS1ydyB0aW1lLXNvdXJjZT8gICAgICAgICAgICAgICAgdWludDgNCj4+
DQo+PiAgICAgICAgIHwgICstLXJ3IHBvcnQtZHMtbGlzdCogW3BvcnQtbnVtYmVyXQ0KPj4NCj4+
ICAgICAgICAgfCAgICAgKy0tcncgcG9ydC1udW1iZXIgICAgICAgIC0+IC4uL3BvcnQtaWRlbnRp
dHkvcG9ydC1udW1iZXINCj4+DQo+PiAgICAgICAgIHwgICAgICstLXJ3IHBvcnQtaWRlbnRpdHkN
Cj4+DQo+PiAgICAgICAgIHwgICAgIHwgICstLXJ3IGNsb2NrLWlkZW50aXR5PyAgIGNsb2NrLWlk
ZW50aXR5LXR5cGUNCj4+DQo+PiAgICAgICAgIHwgICAgIHwgICstLXJ3IHBvcnQtbnVtYmVyPyAg
ICAgIHVpbnQxNg0KPj4NCj4+ICAgICAgICAgfCAgICAgKy0tcncgcG9ydC1zdGF0ZT8gICAgICAg
ICAgcG9ydC1zdGF0ZS1lbnVtZXJhdGlvbg0KPj4NCj4+ICAgICAgICAgfCAgICAgKy0tcncgdW5k
ZXJseWluZy1pbnRlcmZhY2U/IGlmOmludGVyZmFjZS1yZWYNCj4+DQo+PiAgICAgICAgIHwgICAg
ICstLXJ3IGxvZy1taW4tZGVsYXktcmVxLWludGVydmFsPyAgICBpbnQ4DQo+Pg0KPj4gICAgICAg
ICB8ICAgICArLS1ydyBwZWVyLW1lYW4tcGF0aC1kZWxheT8gICAgICAgICAgdGltZS1pbnRlcnZh
bC10eXBlDQo+Pg0KPj4gICAgICAgICB8ICAgICArLS1ydyBsb2ctYW5ub3VuY2UtaW50ZXJ2YWw/
ICAgICAgICAgaW50OA0KPj4NCj4+ICAgICAgICAgfCAgICAgKy0tcncgYW5ub3VuY2UtcmVjZWlw
dC10aW1lb3V0PyAgICAgIHVpbnQ4DQo+Pg0KPj4gICAgICAgICB8ICAgICArLS1ydyBsb2ctc3lu
Yy1pbnRlcnZhbD8gICAgICAgICAgICAgaW50OA0KPj4NCj4+ICAgICAgICAgfCAgICAgKy0tcncg
ZGVsYXktbWVjaGFuaXNtPyAgICAgZGVsYXktbWVjaGFuaXNtLWVudW1lcmF0aW9uDQo+Pg0KPj4g
ICAgICAgICB8ICAgICArLS1ydyBsb2ctbWluLXBkZWxheS1yZXEtaW50ZXJ2YWw/ICAgaW50OA0K
Pj4NCj4+ICAgICAgICAgfCAgICAgKy0tcncgdmVyc2lvbi1udW1iZXI/ICAgICAgICAgICAgICAg
IHVpbnQ4DQo+Pg0KPj4gICAgICAgICArLS1ydyB0cmFuc3BhcmVudC1jbG9jay1kZWZhdWx0LWRz
DQo+Pg0KPj4gICAgICAgICB8ICArLS1ydyBjbG9jay1pZGVudGl0eT8gICAgY2xvY2staWRlbnRp
dHktdHlwZQ0KPj4NCj4+ICAgICAgICAgfCAgKy0tcncgbnVtYmVyLXBvcnRzPyAgICAgIHVpbnQx
Ng0KPj4NCj4+ICAgICAgICAgfCAgKy0tcncgZGVsYXktbWVjaGFuaXNtPyAgIGRlbGF5LW1lY2hh
bmlzbS1lbnVtZXJhdGlvbg0KPj4NCj4+ICAgICAgICAgfCAgKy0tcncgcHJpbWFyeS1kb21haW4/
ICAgIHVpbnQ4DQo+Pg0KPj4gICAgICAgICArLS1ydyB0cmFuc3BhcmVudC1jbG9jay1wb3J0LWRz
LWxpc3QqIFtwb3J0LW51bWJlcl0NCj4+DQo+PiAgICAgICAgICAgICstLXJ3IHBvcnQtbnVtYmVy
ICAgICAgICAgICAtPiAuLi9wb3J0LWlkZW50aXR5L3BvcnQtbnVtYmVyDQo+Pg0KPj4gICAgICAg
ICAgICArLS1ydyBwb3J0LWlkZW50aXR5DQo+Pg0KPj4gICAgICAgICAgICB8ICArLS1ydyBjbG9j
ay1pZGVudGl0eT8gICBjbG9jay1pZGVudGl0eS10eXBlDQo+Pg0KPj4gICAgICAgICAgICB8ICAr
LS1ydyBwb3J0LW51bWJlcj8gICAgICB1aW50MTYNCj4+DQo+PiAgICAgICAgICAgICstLXJ3IGxv
Zy1taW4tcGRlbGF5LXJlcS1pbnRlcnZhbD8gICBpbnQ4DQo+Pg0KPj4gICAgICAgICAgICArLS1y
dyBmYXVsdHktZmxhZz8gICAgICAgICAgICAgICAgICAgYm9vbGVhbg0KPj4NCj4+ICAgICAgICAg
ICAgKy0tcncgcGVlci1tZWFuLXBhdGgtZGVsYXk/ICAgICAgICAgdGltZS1pbnRlcnZhbC10eXBl
DQo+Pg0KPj4NCj4+DQo+PiBJIGFncmVlLCBhc3NpZ25tZW50IGFuZCBjb21wYXJpc29uIGNhbiBz
dGlsbCBiZSBkb25lIG9uIA0KPj4gY2xvY2staWRlbnRpdHkgYW5kIHBvcnQtbnVtYmVyIGRpcmVj
dGx5ICh3aXRob3V0IGEgcG9ydElkZW50aXR5IA0KPj4gY29uc3RydWN0KSAuIEJ1dCBwZW9wbGUg
d2hvIGFyZSBmYW1pbGlhciB3aXRoIDE1ODgtMjAwOCBtYXkgcXVlc3Rpb24gDQo+PiB3aGVyZSBw
b3J0SWRlbnRpdHkgaXMgZ29uZS4NCj4+DQo+Pg0KPj4NCj4+IDMuIEkgdGhpbmsgbGVhZnJlZiBp
cyBhIHZlcnkgZ2VuZXJhbCBzZW1hbnRpY3MgdGhpbmcgaW4gWUFORyANCj4+IGxhbmd1YWdlLCBp
ZiBhbnkgdG9vbHMgaGF2ZSBwcm9ibGVtIHdpdGggdGhpcyBmZWF0dXJlLCBtYXliZSB3ZSBuZWVk
IA0KPj4gdG8gY29udGFjdCB3aXRoIHRoZSB0b29s4oCZcyBkZXZlbG9wZXIgdG8gc3VwcG9ydCBp
dC4NCj4+DQo+Pg0KPj4NCj4+IEZpbmFsbHksIG1vcmUgaW5wdXRzIGZyb20gdGhlIFdHIGFyZSB3
ZWxjb21lLg0KPj4NCj4+DQo+Pg0KPj4gVGhhbmtzIGFnYWluLA0KPj4NCj4+IFl1YW5sb25nDQo+
Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9t
OiBUSUNUT0MgW21haWx0bzp0aWN0b2MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJv
ZG5leSANCj4+IEN1bW1pbmdzDQo+PiBTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAyNywgMjAx
NyAxOjI0IEFNDQo+PiBUbzogdGljdG9jQGlldGYub3JnPG1haWx0bzp0aWN0b2NAaWV0Zi5vcmc+
DQo+PiBTdWJqZWN0OiBSZTogW1RJQ1RPQ10gZHJhZnQtaWV0Zi10aWN0b2MtMTU4OHYyLXlhbmct
MDUgLSBDb25jZXJuIG92ZXIgDQo+PiBwb3J0IGlkZW50aWZpZXINCj4+DQo+Pg0KPj4NCj4+IFRo
YW5rcyBTZWFuLA0KPj4NCj4+DQo+Pg0KPj4gUmVnYXJkaW5nIHlvdXIgb3RoZXIgY29tbWVudCBv
biBUTEQuLi4gSSBhZ3JlZS4NCj4+DQo+Pg0KPj4NCj4+IFJlZ2FyZGluZyB0aGUgY29tbWVudCBi
ZWxvdyBvbiBwb3J0LWlkZW50aXR5LCBJIGFncmVlIHRoYXQgd2UgbmVlZCB0byANCj4+IGRvIGl0
IGZvciBwcmFjdGljYWwgcmVhc29ucy4NCj4+DQo+Pg0KPj4NCj4+IEluIDE1ODgtMjAwOCwgdGhl
cmUgaXMgYSBkaXN0aW5jdCBkYXRhc2V0IG1lbWJlciBmb3IgDQo+PiBwb3J0RFMucG9ydElkZW50
aXR5LCB3aGljaCA1LjMuNSBzcGVjaWZpZXMgYXMgdXNpbmcgdHlwZSBQb3J0SWRlbnRpdHk6DQo+
Pg0KPj4gICAgc3RydWN0IFBvcnRJZGVudGl0eSB7DQo+Pg0KPj4gICAgICBDbG9ja0lkZW50aXR5
IGNsb2NrSWRlbnRpdHk7DQo+Pg0KPj4gICAgICBVSW50ZWdlciBwb3J0TnVtYmVyOw0KPj4NCj4+
ICAgIH0NCj4+DQo+Pg0KPj4NCj4+IElmIHdlIGludGVycHJldCB0aGUgMTU4OC0yMDA4IGRhdGFz
ZXRzIGFzIGFuIGluZm9ybWF0aW9uIG1vZGVsLCBhbmQgDQo+PiBhcHBseSB0aGF0IGFzIGRpcmVj
dGx5IGFzIHBvc3NpYmxlIHRvIGEgWUFORyBkYXRhIG1vZGVsLCANCj4+IHBvcnREUy5wb3J0SWRl
bnRpdHkgaXMgYSBjb250YWluZXIsIHdoaWNoIGlzIHdoYXQgd2UgaGF2ZSBzbyBmYXIuIA0KPj4g
VGhhdCBpbnRyb2R1Y2VzIGEgY2hhbGxlbmdlLCBiZWNhdXNlIHdlIHdhbnQgdG8gdXNlIA0KPj4g
cG9ydERTLnBvcnRJZGVudGl0eS5wb3J0TnVtYmVyIGFzIHRoZSBrZXkgdG8gdGhlIGxpc3Qgb2Yg
cG9ydERTJ3MuIFdlIA0KPj4gc29sdmVkIHRoYXQgY2hhbGxlbmdlIHdpdGggYSBsZWFmcmVmLCBi
dXQgSSdkIGFncmVlIHRoYXQgaXMgdWdseS4NCj4+DQo+Pg0KPj4NCj4+IFlvdXIgcHJvcG9zYWwg
Y2hhbmdlcyBwb3J0RFMucG9ydElkZW50aXR5IGZyb20gYSBjb250YWluZXIgdG8gYSANCj4+IGdy
b3VwaW5nLCBzbyB0aGF0IGl0IHBvcnREUy5wb3J0SWRlbnRpdHkucG9ydE51bWJlciBjYW4gYmUg
dXNlZCBhcyANCj4+IHRoZSBrZXkgd2l0aG91dCBhIGxlYWZyZWYuDQo+Pg0KPj4NCj4+DQo+PiBU
aGUgZG93bnNpZGUgaXMgdGhhdCBpZi93aGVuIGEgWUFORyBtYW5hZ2VtZW50IGNsaWVudCB0cmll
cyB0byAiZ2V0Ig0KPj4gcG9ydERTLnBvcnRJZGVudGl0eSwgaXQgZG9lc24ndCB3b3JrLi4uIHRo
ZXJlIGlzIG5vIHBvcnRJZGVudGl0eSB0byANCj4+IGdldC4NCj4+DQo+Pg0KPj4NCj4+IFBlcnNv
bmFsbHksIEkgdGhpbmsgdGhhdCBkb3duc2lkZSBpcyB3b3J0aCBpdC4gT25lIGNhbiBhcmd1ZSB0
aGF0IA0KPj4geW91ciBwcm9wb3NhbCBzdGlsbCBjb25mb3JtcyB0byB0aGUgMTU4OC0yMDA4IGlu
Zm9ybWF0aW9uIG1vZGVsIGZvciANCj4+IG1hbmFnZW1lbnQsIGluIHRoYXQgcG9ydERTLnBvcnRJ
ZGVudGl0eSBzdGlsbCAiZXhpc3RzIiBpbiBhIG1hbm5lciANCj4+IHRoYXQgbWFrZXMgc2Vuc2Ug
Zm9yIFlBTkcuDQo+Pg0KPj4NCj4+DQo+PiBSb2RuZXkNCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4N
Cj4+DQo+PiBGcm9tOiBUSUNUT0MgW21haWx0bzp0aWN0b2MtYm91bmNlc0BpZXRmLm9yZ10gT24g
QmVoYWxmIE9mIFNlYW4gDQo+PiBDb25kb24NCj4+DQo+PiBTZW50OiBUdWVzZGF5LCBTZXB0ZW1i
ZXIgMjYsIDIwMTcgMTA6MzggQU0NCj4+DQo+PiBUbzogdGljdG9jQGlldGYub3JnPG1haWx0bzp0
aWN0b2NAaWV0Zi5vcmc+DQo+Pg0KPj4gU3ViamVjdDogW1RJQ1RPQ10gZHJhZnQtaWV0Zi10aWN0
b2MtMTU4OHYyLXlhbmctMDUgLSBDb25jZXJuIG92ZXIgDQo+PiBwb3J0IGlkZW50aWZpZXINCj4+
DQo+Pg0KPj4NCj4+IFdpdGggcmVmZXJlbmNlIHRvICJZQU5HIERhdGEgTW9kZWwgZm9yIElFRUUg
MTU4OHYyIg0KPj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0
dHBzLTNBX190b29scy5pZXRmLm9yZ19oDQo+PiB0IA0KPj4gbWxfZHJhZnQtMkRpZXRmLTJEdGlj
dG9jLTJEMTU4OHYyLTJEeWFuZy0yRDA1JmQ9RHdNRkF3JmM9SV8wWXdvS3k3ejVMDQo+PiBNIA0K
Pj4gVFZkeU82WUNpRTJ1ekkxampaWnVJUGVsY1NqaXhBJnI9V0E3MXNmMm83RHc3Q2JZaEZ0MjRE
UGp0M2xKdXVwc3dXWWRuDQo+PiBiDQo+PiBvS2JaOGsmbT1qS0hjelZOTE4tS3VWMkhSWmtiRVpZ
MVN6bENEX0F6dGthV1NjY3JxQkk4JnM9bXNoN0E3X09nSFoxbDYNCj4+IDUNCj4+IERuNl9MaGlE
SVhrWHBGZWlMR21LYkt4c3FYV3cmZT0NCj4+DQo+Pg0KPj4NCj4+IEkgaGF2ZSBhIGNvbmNlcm4g
YWJvdXQgdGhlIHN0cnVjdHVyZSBvZiB0aGUgWUFORywgYW5kIGhvdyB0aGUgbGlzdHMgDQo+PiBw
b3J0LWRzLWxpc3QgYW5kIHRyYW5zcGFyZW50LWNsb2NrLXBvcnQtZHMtbGlzdCBhcmUgaW5kZXhl
ZCB3aXRoIGEgDQo+PiBsZWFmIHdoaWNoIGlzIGEgbGVhZnJlZi4NCj4+DQo+Pg0KPj4NCj4+IFRo
ZSBzdHJ1Y3R1cmUgc2VlbXMgdW5uZWNlc3NhcmlseSBjb21wbGV4IC0gcG9ydC1udW1iZXIgaXMg
DQo+PiByZXByZXNlbnRlZCBhcyBhIGxlYWYgZGlyZWN0bHkgYmVuZWF0aCB0aGUgbGlzdCAodG8g
YmUgdXNlZCBhcyBrZXkpIA0KPj4gYW5kIGFnYWluIHVuZGVyIHRoZSBwb3J0LWlkZW50aXR5IGNv
bnRhaW5lci4gSXQgaXMgc3RydWN0dXJlZCBpbiBhIA0KPj4gd2F5IHRoYXQgSSBiZWxpZXZlIHdv
dWxkIG1ha2UgaXQgZGlmZmljdWx0IHRvIHdvcmsgd2l0aCBzb21lIFlBTkcgDQo+PiB0b29scyBp
biB0aGUgbWFya2V0Lg0KPj4NCj4+DQo+Pg0KPj4gVGhlIHB1cnBvc2Ugb2YgcG9ydC1pZGVudGl0
eSBjb250YWluZXIgaXMgbm90IGNsZWFyIGZyb20gdGhlIGRvY3VtZW50DQo+PiAtIGl0IHdvdWxk
IGFjaGlldmUgdGhlIHNhbWUgcHVycG9zZSBpZiBpdCB3YXMgbGVmdCBvdXQgb2YgDQo+PiBwb3J0
LWRzLWVudHJ5IGFuZCB0cmFuc3BhcmVudC1jbG9jay1wb3J0LWRzLWVudHJ5IGFuZCBpbnN0ZWFk
IHRoZSANCj4+IGdyb3VwaW5nIHBvcnQtaWRlbnRpdHktZ3JvdXBpbmcgaW5jbHVkZWQgZGlyZWN0
bHkuDQo+Pg0KPj4NCj4+DQo+PiBTZWUgdGhlIGF0dGFjaGVkIGZpbGVzIGFzIG9yaWdpbmFsLCBh
IG1vZGlmaWVkIHZlcnNpb24gYW5kIGFzIGEgcGF0Y2ggDQo+PiBmaWxlLg0KPj4NCj4+DQo+Pg0K
Pj4gU2VhbiBDb25kb24NCj4+DQo+PiA9PT09PT09PT09PT09PT09PT09PT09PQ0KPj4NCj4+IFNl
YW4gQ29uZG9uDQo+Pg0KPj4gU3lzdGVtICYgU29mdHdhcmUgQXJjaGl0ZWN0DQo+Pg0KPj4gRnJl
cXVlbmN5ICYgVGltaW5nIERpdmlzaW9uDQo+Pg0KPj4gTWljcm9zZW1pIEluYy4NCj4+DQo+PiBt
YWlsdG86c2Vhbi5jb25kb25AbWljcm9zZW1pLmNvbQ0KPj4NCj4+DQo+Pg0KPj4gX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+DQo+PiBUSUNUT0MgbWFp
bGluZyBsaXN0DQo+Pg0KPj4gVElDVE9DQGlldGYub3JnPG1haWx0bzpUSUNUT0NAaWV0Zi5vcmc+
DQo+Pg0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90aWN0b2MNCj4g
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0bW9k
IG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0K